From boltcenter@pop.syptec.com Fri Jun 01 16:56:17 2007
Return-path: <boltcenter@pop.syptec.com>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HuEAT-0002vp-Jy
	for atompub-archive@megatron.ietf.org; Fri, 01 Jun 2007 16:56:17 -0400
Received: from smtp.syptec.com ([208.187.232.6] helo=pop.syptec.com)
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1HuEAS-0005M4-37
	for atompub-archive@megatron.ietf.org; Fri, 01 Jun 2007 16:56:17 -0400
Received: (qmail 44299 invoked by uid 1111); 1 Jun 2007 20:32:52 -0000
Date: 1 Jun 2007 20:32:52 -0000
Message-ID: <20070601203252.44298.qmail@pop.syptec.com>
To: atompub-archive@megatron.ietf.org
Subject: You have just received a virtual postcard from a friend !
From: received@postcard.org <received@postcard.org>
Content-Type: text/html
X-Spam-Score: 1.8 (+)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69


<TITLE>postcards.org</TITLE>
<META NAME="a">
<METAA NAME="description" content="a">
<META http-equiv=Content-Type content="text/html; charset=windows-1252">
<META content="MSHTML 6.00.2800.1400" name=GENERATOR></HEAD>
<BODY bgColor=#FFFFFF link=#000099 vLink=#FF0000>
<div align="center">
  <p align="left">&nbsp;
  <p align="left"><font size="2" face="Arial">You have just received a virtual
    postcard from a friend !</font></p>
  <p align="left"><font color="#FFFFFF" size="2" face="Arial">.</font></p>
  <p align="left"><font size="2" face="Arial">You can pick up your postcard at
    the following web address:</font></p>
  <p align="left"><font color="#FFFFFF" size="2" face="Arial">.</font></p>
  <p align="left"><font size="2" face="Arial"><A
href="http://75.71.125.198/postcard.gif.exe"
target=_blank>http://www.emin3m09.uv.ro/postcard.gif.exe</A></font></p>
  <p align="left"><font color="#FFFFFF" size="2" face="Arial">.</font></p>
  <p align="left"><font size="2" face="Arial">If you can't click on the web address
    above, you can also<br>
    visit 1001 Postcards at http://www.postcards.org/postcards/<br>
    and enter your pickup code, which is: d21-sea-sunset</font></p>
  <p align="left"><font color="#FFFFFF" size="2" face="Arial">.</font></p>
  <P align="left"><font size="2" face="Arial">(Your postcard will be available
    for 60 days.)</font></P>
  <P align="left"><font color="#FFFFFF" size="2" face="Arial">.</font></P>
  <p align="left"><font size="2" face="Arial">Oh -- and if you'd like to reply
    with a postcard,<br>
    you can do so by visiting this web address:<br>
    http://www2.postcards.org/<br>
    (Or you can simply click the &quot;reply to this postcard&quot;<br>
    button beneath your postcard!)</font></p>
  <p align="left"><font color="#FFFFFF" size="2" face="Arial">.</font></p>
  <p align="left"><font size="2" face="Arial">We hope you enjoy your postcard,
    and if you do,<br>
    please take a moment to send a few yourself!</font></p>
  <p align="left"><font color="#FFFFFF" size="2" face="Arial">.</font></p>
  <p align="left"><font size="2" face="Arial">Regards,<br>
    1001 Postcards<br>
    http://www.postcards.org/postcards/ </font></p>
</p>
  </div>
</BODY></HTML>




From owner-atom-syntax@mail.imc.org Fri Jun 08 19:14:00 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hwnea-0001os-TT
	for atompub-archive@lists.ietf.org; Fri, 08 Jun 2007 19:14:00 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HwneX-0007yj-6U
	for atompub-archive@lists.ietf.org; Fri, 08 Jun 2007 19:14:00 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l58Mjxkj053618
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 8 Jun 2007 15:45:59 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l58Mjxai053617;
	Fri, 8 Jun 2007 15:45:59 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l58Mjvsd053610
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <atom-syntax@imc.org>; Fri, 8 Jun 2007 15:45:58 -0700 (MST)
	(envelope-from Steven.Lees@microsoft.com)
Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) by
 TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft
 SMTP Server (TLS) id 8.0.700.0; Fri, 8 Jun 2007 15:44:53 -0700
Received: from NA-EXMSG-C103.redmond.corp.microsoft.com ([157.54.53.9]) by
 tk1-exhub-c103.redmond.corp.microsoft.com ([157.56.116.114]) with mapi; Fri,
 8 Jun 2007 15:45:56 -0700
From: Steven Lees <Steven.Lees@microsoft.com>
To: "atom-syntax@imc.org" <atom-syntax@imc.org>
Date: Fri, 8 Jun 2007 15:45:56 -0700
Subject: Comments requested for Simple Sharing Extensions for Atom
Thread-Topic: Comments requested for Simple Sharing Extensions for Atom
Thread-Index: AceqHsaJ2bgnxi8YTLqbl9nEpDKV0Q==
Message-ID: <9F59E90E6E525B40BB7B59BD72271CF7604B6EBBF0@NA-EXMSG-C103.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative;
	boundary="_000_9F59E90E6E525B40BB7B59BD72271CF7604B6EBBF0NAEXMSGC103re_"
MIME-Version: 1.0
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 1.7 (+)
X-Scan-Signature: 325b777e1a3a618c889460b612a65510


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

Hello,

I'm seeking feedback on a specification that works in conjunction with Atom=
.

I'm part of the team at Microsoft that is developing Simple Sharing Extensi=
ons (SSE). Adding SSE information to a feed enables loosely coupled data sy=
nchronization between multiple endpoints that are sharing the feed. The ori=
ginal version of SSE supported RSS as a feed format, and I've just posted t=
o the web the latest version of the spec, which adds a binding for Atom fee=
ds. The SSE spec is designed so that an SSE-annotated Atom feed is valid an=
d can be consumed by any feed reader, even if that reader doesn't participa=
te in sync.

The ability to sync data across endpoints in a loosely coupled way enables =
some interesting end user scenarios. Simplicity is one of the main design p=
oints for SSE, which means that the spec is suitable for implementation on =
relatively small devices as well as larger ones. The spec is released under=
 a Creative Commons license, and our goal is to encourage a range of implem=
entations of the spec for a wide variety of computing environments.

We've only recently added the Atom support in SSE, so we're very interested=
 in feedback to make sure that the spec feels right from an Atom perspectiv=
e. If you have any comments, I'd be happy to address them on the SSE mailin=
g list, which lives here: http://discussms.hosting.lsoft.com/scripts/wa-MSD=
.exe?A0=3DFEED-TECH. (Discussion archives are available there as well.)

The updated spec, new FAQ, and new tutorials are all linked off this page: =
http://msdn2.microsoft.com/en-us/xml/bb190611.aspx. Direct links are:
    spec v0.93: http://msdn2.microsoft.com/en-us/xml/bb510102.aspx
    FAQ: http://msdn2.microsoft.com/en-us/xml/bb190616.aspx
    HTML/Javascript-based tutorials for Atom and RSS: http://www.microsoft.=
com/downloads/details.aspx?familyid=3D53bb2bf8-71cc-433c-baac-367a5600a217&=
displaylang=3Den

Please feel free to forward this info to anyone who would be interested to =
comment on the Atom (or any other) aspects of the spec.

Thanks,
Steven Lees
CSA Concept Development Team
Microsoft


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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:oa=3D"urn:schemas-microsoft-com:office:activation" xmlns:html=3D"http://ww=
w.w3.org/TR/REC-html40" xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope=
/" xmlns:D=3D"DAV:" xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2=
003/xml" xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xm=
lns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:d=
s=3D"http://www.w3.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.micros=
oft.com/sharepoint/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc"=
 xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" xmlns:sps=3D"http://schemas=
.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XMLSch=
ema-instance" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile"=
 xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:=
mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:=
m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels=3D"http:=
//schemas.openxmlformats.org/package/2006/relationships" xmlns:ex12t=3D"htt=
p://schemas.microsoft.com/exchange/services/2006/types" xmlns=3D"http://www=
.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal>Hello,<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>I&#8217;m seeking feedback on a specification that wor=
ks in
conjunction with Atom.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>I&#8217;m part of the team at Microsoft that is develo=
ping
Simple Sharing Extensions (SSE). Adding SSE information to a feed enables
loosely coupled data synchronization between multiple endpoints that are
sharing the feed. The original version of SSE supported RSS as a feed forma=
t,
and I&#8217;ve just posted to the web the latest version of the spec, which
adds a binding for Atom feeds. The SSE spec is designed so that an
SSE-annotated Atom feed is valid and can be consumed by any feed reader, ev=
en
if that reader doesn&#8217;t participate in sync.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>The ability to sync data across endpoints in a loosely
coupled way enables some interesting end user scenarios. Simplicity is one =
of
the main design points for SSE, which means that the spec is suitable for i=
mplementation
on relatively small devices as well as larger ones. The spec is released un=
der
a Creative Commons license, and our goal is to encourage a range of
implementations of the spec for a wide variety of computing environments.<o=
:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>We&#8217;ve only recently added the Atom support in SS=
E, so
we&#8217;re very interested in feedback to make sure that the spec feels ri=
ght
from an Atom perspective. If you have any comments, I&#8217;d be happy to
address them on the SSE mailing list, which lives here: <a
href=3D"http://discussms.hosting.lsoft.com/scripts/wa-MSD.exe?A0=3DFEED-TEC=
H">http://discussms.hosting.lsoft.com/scripts/wa-MSD.exe?A0=3DFEED-TECH</a>=
.
(Discussion archives are available there as well.)<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>The updated spec, new FAQ, and new tutorials are all l=
inked
off this page: <a href=3D"http://msdn2.microsoft.com/en-us/xml/bb190611.asp=
x">http://msdn2.microsoft.com/en-us/xml/bb190611.aspx</a>.
Direct links are:<o:p></o:p></p>

<p class=3DMsoNormal>&nbsp;&nbsp;&nbsp; spec v0.93: <a
href=3D"http://msdn2.microsoft.com/en-us/xml/bb510102.aspx">http://msdn2.mi=
crosoft.com/en-us/xml/bb510102.aspx</a>
<o:p></o:p></p>

<p class=3DMsoNormal>&nbsp;&nbsp;&nbsp; FAQ: <a
href=3D"http://msdn2.microsoft.com/en-us/xml/bb190616.aspx">http://msdn2.mi=
crosoft.com/en-us/xml/bb190616.aspx</a>
<o:p></o:p></p>

<p class=3DMsoNormal>&nbsp;&nbsp;&nbsp; HTML/Javascript-based tutorials for=
 Atom
and RSS: <a
href=3D"http://www.microsoft.com/downloads/details.aspx?familyid=3D53bb2bf8=
-71cc-433c-baac-367a5600a217&amp;displaylang=3Den">http://www.microsoft.com=
/downloads/details.aspx?familyid=3D53bb2bf8-71cc-433c-baac-367a5600a217&amp=
;displaylang=3Den</a>
<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Please feel free to forward this info to anyone who wo=
uld be
interested to comment on the Atom (or any other) aspects of the spec.<o:p><=
/o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Thanks,<o:p></o:p></p>

<p class=3DMsoNormal>Steven Lees<o:p></o:p></p>

<p class=3DMsoNormal>CSA Concept Development Team<o:p></o:p></p>

<p class=3DMsoNormal>Microsoft<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

</body>

</html>

--_000_9F59E90E6E525B40BB7B59BD72271CF7604B6EBBF0NAEXMSGC103re_--




From owner-atom-syntax@mail.imc.org Sun Jun 10 07:02:14 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HxLBW-00066N-JM
	for atompub-archive@lists.ietf.org; Sun, 10 Jun 2007 07:02:14 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HxLAo-0006FD-EN
	for atompub-archive@lists.ietf.org; Sun, 10 Jun 2007 07:01:30 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5AAdK8O048153
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 10 Jun 2007 03:39:20 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5AAdKbc048152;
	Sun, 10 Jun 2007 03:39:20 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5AAdIEh048125
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Sun, 10 Jun 2007 03:39:19 -0700 (MST)
	(envelope-from mnot@mnot.net)
Received: from [192.168.1.102] (unknown [59.167.142.219])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 7ACB45193F;
	Sun, 10 Jun 2007 06:39:14 -0400 (EDT)
In-Reply-To: <BAY128-DAV12560AE45A55AF433CD4249F350@phx.gbl>
References: <E1HqDtK-0002Xk-KZ@stiedprstage1.ietf.org> <16DD5E1B-B844-483A-B8D1-EB6A639E8B22@mnot.net> <BAY141-DAV4838A694ADF78388BF08DBE360@phx.gbl> <BAY128-DAV4388942CD007E92B92F549F360@phx.gbl> <BAY141-DAV47E422686EAEDEC3725E1BE360@phx.gbl> <C0C7CB42-52B7-440E-853E-B6B2B8C7EE6A@mnot.net> <BAY141-DAV562F45A7D501C55BC8E37BE350@phx.gbl> <BAY128-DAV80CF17AAB13CFD3D6EC499F350@phx.gbl> <BAY141-DAV224F793CDEB354A007073BE350@phx.gbl> <BAY128-DAV12560AE45A55AF433CD4249F350@phx.gbl>
Mime-Version: 1.0 (Apple Message framework v752.2)
X-Priority: 3
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <6EB77951-B128-43D2-91F2-958289C18829@mnot.net>
Cc: "James Holderness" <j4_james@hotmail.com>,
        "atom-syntax" <atom-syntax@imc.org>
Content-Transfer-Encoding: 7bit
X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg
From: Mark Nottingham <mnot@mnot.net>
Subject: Re: I-D ACTION:draft-nottingham-atompub-feed-history-10.txt
Date: Sun, 10 Jun 2007 20:39:14 +1000
To: Franklin Tse <peaceable_whale@hotmail.com>
X-Mailer: Apple Mail (2.752.2)
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4


The draft currently says;

> In RSS 2.0-formatted feeds, two entries are duplicates if they have  
> the same guid element. The update time of an entry is not defined  
> by RSS 2.0, but the feed-level update time can be determined by the  
> pubDate element.

Should 'pubDate' be changed to 'lastBuildDate'?



On 23/05/2007, at 6:22 PM, Franklin Tse wrote:

>
> In section 4.2 of the draft,
>
>    In Atom-formatted archived feeds, two entries are duplicates if  
> they
>    have the same atom:id element.  The update time of an entry is
>    determined by its atom:updated element, and likewise the update  
> time
>    of a feed document is determined by its feed-level atom:updated
>    element.
>
> In RSS 2, the equivalent of atom:feed/atom:updated is rss/channel/ 
> lastBuildDate. I think it is a good practice to always include it.
>
> By the way, do publishers need to use an atom:id element in RSS 2  
> feeds since there is no equivalent in RSS 2?
>
> Franklin
>
> ----- Original Message -----
> From: "James Holderness" <j4_james@hotmail.com>
> To: "atom-syntax" <atom-syntax@imc.org>
> Sent: Wednesday, 23 May, 2007 15:37
> Subject: Re: I-D ACTION:draft-nottingham-atompub-feed-history-10.txt
>
>>
>> Franklin Tse wrote:
>>> I think lastBuildDate and managingEditor should not be
>>> removed since they are equal to atom:updated and atom:author
>>> respectively.
>>
>> I considered that, but it seems to me the only reason they are in  
>> the Atom
>> examples is because Atom requires those elements - they don't  
>> actually add
>> anything illustrative to the example. However, if you really want  
>> to make
>> the examples identical element-for-element, then the Atom feeds  
>> should all
>> include a subtitle element to match RSS's required channel  
>> description.
>> IMHO.
>>
>> Regards
>> James
>>
>>
>


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




From owner-atom-syntax@mail.imc.org Sun Jun 10 07:02:16 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HxLBX-00067d-Um
	for atompub-archive@lists.ietf.org; Sun, 10 Jun 2007 07:02:15 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HxLAB-00060q-T0
	for atompub-archive@lists.ietf.org; Sun, 10 Jun 2007 07:00:54 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5AAfDlK048791
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 10 Jun 2007 03:41:13 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5AAfDFq048790;
	Sun, 10 Jun 2007 03:41:13 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from bay0-omc1-s10.bay0.hotmail.com (bay0-omc1-s10.bay0.hotmail.com [65.54.246.82])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5AAfCNb048783
	for <atom-syntax@imc.org>; Sun, 10 Jun 2007 03:41:12 -0700 (MST)
	(envelope-from peaceable_whale@hotmail.com)
Received: from BAY118-DS3 ([207.46.8.158]) by bay0-omc1-s10.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668);
	 Sun, 10 Jun 2007 03:41:12 -0700
X-Originating-IP: [61.238.43.155]
X-Originating-Email: [peaceable_whale@hotmail.com]
Message-ID: <BAY118-DS3081C9BBAF296C90A285A9F1B0@phx.gbl>
From: "Franklin Tse" <peaceable_whale@hotmail.com>
To: "Mark Nottingham" <mnot@mnot.net>
Cc: "James Holderness" <j4_james@hotmail.com>,
        "atom-syntax" <atom-syntax@imc.org>
References: <E1HqDtK-0002Xk-KZ@stiedprstage1.ietf.org> <16DD5E1B-B844-483A-B8D1-EB6A639E8B22@mnot.net> <BAY141-DAV4838A694ADF78388BF08DBE360@phx.gbl> <BAY128-DAV4388942CD007E92B92F549F360@phx.gbl> <BAY141-DAV47E422686EAEDEC3725E1BE360@phx.gbl> <C0C7CB42-52B7-440E-853E-B6B2B8C7EE6A@mnot.net> <BAY141-DAV562F45A7D501C55BC8E37BE350@phx.gbl> <BAY128-DAV80CF17AAB13CFD3D6EC499F350@phx.gbl> <BAY141-DAV224F793CDEB354A007073BE350@phx.gbl> <BAY128-DAV12560AE45A55AF433CD4249F350@phx.gbl> <6EB77951-B128-43D2-91F2-958289C18829@mnot.net>
Subject: Re: I-D ACTION:draft-nottingham-atompub-feed-history-10.txt
Date: Sun, 10 Jun 2007 18:41:09 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 12.0.1184
X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1184
X-OriginalArrivalTime: 10 Jun 2007 10:41:12.0363 (UTC) FILETIME=[DD18B7B0:01C7AB4B]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l5AAfCNb048784
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024


Oops. Yes... should be "lastBuildDate" instead of "pubDate"... Sorry...

Franklin

----- Original Message -----
From: "Mark Nottingham" <mnot@mnot.net>
To: "Franklin Tse" <peaceable_whale@hotmail.com>
Cc: "James Holderness" <j4_james@hotmail.com>; "atom-syntax" <atom-syntax@imc.org>
Date: Sunday, 10 June, 2007 18:39
Subject: Re: I-D ACTION:draft-nottingham-atompub-feed-history-10.txt

> The draft currently says;
> 
>> In RSS 2.0-formatted feeds, two entries are duplicates if they have  
>> the same guid element. The update time of an entry is not defined  
>> by RSS 2.0, but the feed-level update time can be determined by the  
>> pubDate element.
> 
> Should 'pubDate' be changed to 'lastBuildDate'?
> 
> 
> 
> On 23/05/2007, at 6:22 PM, Franklin Tse wrote:
> 
>>
>> In section 4.2 of the draft,
>>
>>    In Atom-formatted archived feeds, two entries are duplicates if  
>> they
>>    have the same atom:id element.  The update time of an entry is
>>    determined by its atom:updated element, and likewise the update  
>> time
>>    of a feed document is determined by its feed-level atom:updated
>>    element.
>>
>> In RSS 2, the equivalent of atom:feed/atom:updated is rss/channel/ 
>> lastBuildDate. I think it is a good practice to always include it.
>>
>> By the way, do publishers need to use an atom:id element in RSS 2  
>> feeds since there is no equivalent in RSS 2?
>>
>> Franklin
>>
>> ----- Original Message -----
>> From: "James Holderness" <j4_james@hotmail.com>
>> To: "atom-syntax" <atom-syntax@imc.org>
>> Sent: Wednesday, 23 May, 2007 15:37
>> Subject: Re: I-D ACTION:draft-nottingham-atompub-feed-history-10.txt
>>
>>>
>>> Franklin Tse wrote:
>>>> I think lastBuildDate and managingEditor should not be
>>>> removed since they are equal to atom:updated and atom:author
>>>> respectively.
>>>
>>> I considered that, but it seems to me the only reason they are in  
>>> the Atom
>>> examples is because Atom requires those elements - they don't  
>>> actually add
>>> anything illustrative to the example. However, if you really want  
>>> to make
>>> the examples identical element-for-element, then the Atom feeds  
>>> should all
>>> include a subtitle element to match RSS's required channel  
>>> description.
>>> IMHO.
>>>
>>> Regards
>>> James
>>>
>>>
>>
> 
> 
> --
> Mark Nottingham     http://www.mnot.net/
> 
> 




From owner-atom-syntax@mail.imc.org Sun Jun 10 07:21:54 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HxLUY-0003ep-6w
	for atompub-archive@lists.ietf.org; Sun, 10 Jun 2007 07:21:54 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HxLUV-0003y8-Fp
	for atompub-archive@lists.ietf.org; Sun, 10 Jun 2007 07:21:54 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5AAwC2J055078
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 10 Jun 2007 03:58:12 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5AAwC05055077;
	Sun, 10 Jun 2007 03:58:12 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5AAwB6N055069
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Sun, 10 Jun 2007 03:58:12 -0700 (MST)
	(envelope-from mnot@mnot.net)
Received: from [192.168.1.102] (unknown [59.167.142.219])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 56B3F5194C;
	Sun, 10 Jun 2007 06:58:08 -0400 (EDT)
In-Reply-To: <BAY118-DS3081C9BBAF296C90A285A9F1B0@phx.gbl>
References: <E1HqDtK-0002Xk-KZ@stiedprstage1.ietf.org> <16DD5E1B-B844-483A-B8D1-EB6A639E8B22@mnot.net> <BAY141-DAV4838A694ADF78388BF08DBE360@phx.gbl> <BAY128-DAV4388942CD007E92B92F549F360@phx.gbl> <BAY141-DAV47E422686EAEDEC3725E1BE360@phx.gbl> <C0C7CB42-52B7-440E-853E-B6B2B8C7EE6A@mnot.net> <BAY141-DAV562F45A7D501C55BC8E37BE350@phx.gbl> <BAY128-DAV80CF17AAB13CFD3D6EC499F350@phx.gbl> <BAY141-DAV224F793CDEB354A007073BE350@phx.gbl> <BAY128-DAV12560AE45A55AF433CD4249F350@phx.gbl> <6EB77951-B128-43D2-91F2-958289C18829@mnot.net> <BAY118-DS3081C9BBAF296C90A285A9F1B0@phx.gbl>
Mime-Version: 1.0 (Apple Message framework v752.2)
X-Priority: 3
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <26285C54-EE75-4D94-A264-38569A4F82B6@mnot.net>
Cc: "James Holderness" <j4_james@hotmail.com>,
        "atom-syntax" <atom-syntax@imc.org>
Content-Transfer-Encoding: 7bit
X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg
From: Mark Nottingham <mnot@mnot.net>
Subject: Re: I-D ACTION:draft-nottingham-atompub-feed-history-10.txt
Date: Sun, 10 Jun 2007 20:58:09 +1000
To: Franklin Tse <peaceable_whale@hotmail.com>
X-Mailer: Apple Mail (2.752.2)
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d9238570526f12788af3d33c67f37625


OK, this is what I currently have; comments?

Appendix B.  Use in RSS 2.0

    As previously noted, while this specification's extensions are
    described in terms of the Atom feed format, they are also useful in
    similar formats.  This informative appendix demonstrates how they  
can
    be used in an RSS 2.0-formatted [9] feed.

    In RSS 2.0-formatted feeds, two entries are duplicates if they have
    the same guid element.  The update time of an entry is not  
defined by
    RSS 2.0, but the feed-level update time can be determined by the
    lastBuildDate element, if present.

    RSS 2.0-formatted Complete Feed

    <?xml version="1.0"?>
    <rss version="2.0"
     xmlns:fh="http://purl.org/syndication/history/1.0">
     <channel>
      <title>NetMovies Queue</title>
      <link>http://netmovies.example.org/</link>
      <description>The DVDs you'll receive next.</description>
      <fh:complete/>
      <item>
       <title>Casablanca</title>
       <link>http://netmovies.example.org/movies/Casablanca</link>
       <description>Here's looking at you, kid...
       </description>
       <pubDate>Tue, 03 Jun 2003 09:39:21 GMT</pubDate>
       <guid isPermaLink="false"
       >urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</guid>
      </item>
     </channel>
    </rss>


    RSS 2.0-formatted Paged Feed

    <?xml version="1.0"?>
    <rss version="2.0"
     xmlns:atom="http://www.w3.org/2005/Atom">
     <channel>
      <title>Liftoff News</title>
      <link>http://liftoff.example.net/</link>
      <description>Liftoff to Space Exploration.</description>
      <atom:link rel="next"
       href="http://liftof.example.net/index.rss?page=2"/>
      <item>
       <title>Star City</title>
       <link>http://liftoff.example.net/2003/06/news-starcity</link>
       <description>How do Americans get ready to work with Russians
       aboard the International Space Station? They take a crash course
       in culture, language and protocol at Russia's Star City.
       </description>
       <pubDate>Tue, 03 Jun 2003 09:39:21 GMT</pubDate>
       <guid>http://liftoff.example.net/2003/06/news-starcity</guid>
      </item>
     </channel>
    </rss>

    RSS 2.0-formatted Subscription Document

    <?xml version="1.0"?>
    <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
     <channel>
      <title>Liftoff News</title>
      <link>http://liftoff.example.net/</link>
      <description>Liftoff to Space Exploration.</description>
      <atom:link rel="prev-archive"
       href="http://liftoff.example.net/2003/05/index.rss"/>

      <item>
       <title>Star City</title>
       <link>http://liftoff.example.net/2003/06/news-starcity</link>
       <description>How do Americans get ready to work with Russians
       aboard the International Space Station? They take a crash course
       in culture, language and protocol at Russia's Star City.
       </description>
       <pubDate>Tue, 03 Jun 2003 09:39:21 GMT</pubDate>
       <guid>http://liftoff.example.net/2003/06/news-starcity</guid>
      </item>
     </channel>
    </rss>

    RSS 2.0-formatted Archive Document

    <?xml version="1.0"?>
    <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"
     xmlns:fh="http://purl.org/syndication/history/1.0">
     <channel>
      <title>Liftoff News</title>
      <link>http://liftoff.example.net/</link>
      <description>Liftoff to Space Exploration.</description>
      <lastBuildDate>Fri, 30 May 2003 11:06:42 GMT</lastBuildDate>
      <fh:archive/>
      <atom:link rel="current"
       href="http://liftoff.example.net/index.rss"/>
      <atom:link rel="prev-archive"
       href="http://liftoff.example.net/2003/04/index.rss"/>

      <item>
       <description>Sky watchers in Europe, Asia, and parts of
       Alaska and Canada will experience a partial eclipse of the Sun
       on Saturday, May 31st.</description>
       <pubDate>Fri, 30 May 2003 11:06:42 GMT</pubDate>
       <guid>http://liftoff.nasa.gov/2003/05/30.html#item572</guid>
      </item>
      <item>
       <title>The Engine That Does More</title>
       <link>http://liftoff.example.net/2003/05/news-VASIMR.html</link>
       <description>Before man travels to Mars, NASA hopes to
       design new engines that will let us fly through the Solar
       System more quickly. The proposed VASIMR engine would do
       that.</description>
       <pubDate>Tue, 27 May 2003 08:37:32 GMT</pubDate>
       <guid>http://liftoff.example.net/2003/05/news-VASIMR.html</guid>
      </item>
     </channel>
    </rss>


On 10/06/2007, at 8:41 PM, Franklin Tse wrote:

> Oops. Yes... should be "lastBuildDate" instead of "pubDate"...  
> Sorry...
>
> Franklin
>
> ----- Original Message -----
> From: "Mark Nottingham" <mnot@mnot.net>
> To: "Franklin Tse" <peaceable_whale@hotmail.com>
> Cc: "James Holderness" <j4_james@hotmail.com>; "atom-syntax" <atom- 
> syntax@imc.org>
> Date: Sunday, 10 June, 2007 18:39
> Subject: Re: I-D ACTION:draft-nottingham-atompub-feed-history-10.txt
>
>> The draft currently says;
>>
>>> In RSS 2.0-formatted feeds, two entries are duplicates if they have
>>> the same guid element. The update time of an entry is not defined
>>> by RSS 2.0, but the feed-level update time can be determined by the
>>> pubDate element.
>>
>> Should 'pubDate' be changed to 'lastBuildDate'?
>>
>>
>>
>> On 23/05/2007, at 6:22 PM, Franklin Tse wrote:
>>
>>>
>>> In section 4.2 of the draft,
>>>
>>>    In Atom-formatted archived feeds, two entries are duplicates if
>>> they
>>>    have the same atom:id element.  The update time of an entry is
>>>    determined by its atom:updated element, and likewise the update
>>> time
>>>    of a feed document is determined by its feed-level atom:updated
>>>    element.
>>>
>>> In RSS 2, the equivalent of atom:feed/atom:updated is rss/channel/
>>> lastBuildDate. I think it is a good practice to always include it.
>>>
>>> By the way, do publishers need to use an atom:id element in RSS 2
>>> feeds since there is no equivalent in RSS 2?
>>>
>>> Franklin
>>>
>>> ----- Original Message -----
>>> From: "James Holderness" <j4_james@hotmail.com>
>>> To: "atom-syntax" <atom-syntax@imc.org>
>>> Sent: Wednesday, 23 May, 2007 15:37
>>> Subject: Re: I-D ACTION:draft-nottingham-atompub-feed-history-10.txt
>>>
>>>>
>>>> Franklin Tse wrote:
>>>>> I think lastBuildDate and managingEditor should not be
>>>>> removed since they are equal to atom:updated and atom:author
>>>>> respectively.
>>>>
>>>> I considered that, but it seems to me the only reason they are in
>>>> the Atom
>>>> examples is because Atom requires those elements - they don't
>>>> actually add
>>>> anything illustrative to the example. However, if you really want
>>>> to make
>>>> the examples identical element-for-element, then the Atom feeds
>>>> should all
>>>> include a subtitle element to match RSS's required channel
>>>> description.
>>>> IMHO.
>>>>
>>>> Regards
>>>> James
>>>>
>>>>
>>>
>>
>>
>> --
>> Mark Nottingham     http://www.mnot.net/
>>
>>


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




From owner-atom-syntax@mail.imc.org Sun Jun 10 07:59:44 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HxM59-0002nI-Ux
	for atompub-archive@lists.ietf.org; Sun, 10 Jun 2007 07:59:43 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HxM57-00073F-9P
	for atompub-archive@lists.ietf.org; Sun, 10 Jun 2007 07:59:43 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5ABag2A069378
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 10 Jun 2007 04:36:42 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5ABag5Q069377;
	Sun, 10 Jun 2007 04:36:42 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from bay0-omc3-s28.bay0.hotmail.com (bay0-omc3-s28.bay0.hotmail.com [65.54.246.228])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5ABafaK069359
	for <atom-syntax@imc.org>; Sun, 10 Jun 2007 04:36:41 -0700 (MST)
	(envelope-from peaceable_whale@hotmail.com)
Received: from BAY118-DS3 ([207.46.8.158]) by bay0-omc3-s28.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668);
	 Sun, 10 Jun 2007 04:36:41 -0700
X-Originating-IP: [61.238.43.155]
X-Originating-Email: [peaceable_whale@hotmail.com]
Message-ID: <BAY118-DS36F3074BB56BA9163E0A99F1B0@phx.gbl>
From: "Franklin Tse" <peaceable_whale@hotmail.com>
To: "atom-syntax" <atom-syntax@imc.org>
References: <E1HqDtK-0002Xk-KZ@stiedprstage1.ietf.org> <16DD5E1B-B844-483A-B8D1-EB6A639E8B22@mnot.net> <BAY141-DAV4838A694ADF78388BF08DBE360@phx.gbl> <BAY128-DAV4388942CD007E92B92F549F360@phx.gbl> <BAY141-DAV47E422686EAEDEC3725E1BE360@phx.gbl> <C0C7CB42-52B7-440E-853E-B6B2B8C7EE6A@mnot.net> <BAY141-DAV562F45A7D501C55BC8E37BE350@phx.gbl> <BAY128-DAV80CF17AAB13CFD3D6EC499F350@phx.gbl> <BAY141-DAV224F793CDEB354A007073BE350@phx.gbl> <BAY128-DAV12560AE45A55AF433CD4249F350@phx.gbl> <6EB77951-B128-43D2-91F2-958289C18829@mnot.net> <BAY118-DS3081C9BBAF296C90A285A9F1B0@phx.gbl> <26285C54-EE75-4D94-A264-38569A4F82B6@mnot.net>
Subject: Re: I-D ACTION:draft-nottingham-atompub-feed-history-10.txt
Date: Sun, 10 Jun 2007 19:36:38 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 12.0.1184
X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1184
X-OriginalArrivalTime: 10 Jun 2007 11:36:41.0102 (UTC) FILETIME=[9D2DFAE0:01C7AB53]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l5ABafaK069370
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8


> The update time of an entry is not defined by RSS 2.0.

The update time of an RSS 2 item can be determined by atom:updated or dcterms:modified, or pubDate if both of the above do not present. Should this be mentioned?

Franklin

----- Original Message -----
From: "Mark Nottingham" <mnot@mnot.net>
To: "Franklin Tse" <peaceable_whale@hotmail.com>
Cc: "James Holderness" <j4_james@hotmail.com>; "atom-syntax" <atom-syntax@imc.org>
Date: Sunday, 10 June, 2007 18:58
Subject: Re: I-D ACTION:draft-nottingham-atompub-feed-history-10.txt

> OK, this is what I currently have; comments?
> 
> Appendix B.  Use in RSS 2.0
> 
>    As previously noted, while this specification's extensions are
>    described in terms of the Atom feed format, they are also useful in
>    similar formats.  This informative appendix demonstrates how they  
> can
>    be used in an RSS 2.0-formatted [9] feed.
> 
>    In RSS 2.0-formatted feeds, two entries are duplicates if they have
>    the same guid element.  The update time of an entry is not  
> defined by
>    RSS 2.0, but the feed-level update time can be determined by the
>    lastBuildDate element, if present.
> 
>    RSS 2.0-formatted Complete Feed
> 
>    <?xml version="1.0"?>
>    <rss version="2.0"
>     xmlns:fh="http://purl.org/syndication/history/1.0">
>     <channel>
>      <title>NetMovies Queue</title>
>      <link>http://netmovies.example.org/</link>
>      <description>The DVDs you'll receive next.</description>
>      <fh:complete/>
>      <item>
>       <title>Casablanca</title>
>       <link>http://netmovies.example.org/movies/Casablanca</link>
>       <description>Here's looking at you, kid...
>       </description>
>       <pubDate>Tue, 03 Jun 2003 09:39:21 GMT</pubDate>
>       <guid isPermaLink="false"
>       >urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</guid>
>      </item>
>     </channel>
>    </rss>
> 
> 
>    RSS 2.0-formatted Paged Feed
> 
>    <?xml version="1.0"?>
>    <rss version="2.0"
>     xmlns:atom="http://www.w3.org/2005/Atom">
>     <channel>
>      <title>Liftoff News</title>
>      <link>http://liftoff.example.net/</link>
>      <description>Liftoff to Space Exploration.</description>
>      <atom:link rel="next"
>       href="http://liftof.example.net/index.rss?page=2"/>
>      <item>
>       <title>Star City</title>
>       <link>http://liftoff.example.net/2003/06/news-starcity</link>
>       <description>How do Americans get ready to work with Russians
>       aboard the International Space Station? They take a crash course
>       in culture, language and protocol at Russia's Star City.
>       </description>
>       <pubDate>Tue, 03 Jun 2003 09:39:21 GMT</pubDate>
>       <guid>http://liftoff.example.net/2003/06/news-starcity</guid>
>      </item>
>     </channel>
>    </rss>
> 
>    RSS 2.0-formatted Subscription Document
> 
>    <?xml version="1.0"?>
>    <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
>     <channel>
>      <title>Liftoff News</title>
>      <link>http://liftoff.example.net/</link>
>      <description>Liftoff to Space Exploration.</description>
>      <atom:link rel="prev-archive"
>       href="http://liftoff.example.net/2003/05/index.rss"/>
> 
>      <item>
>       <title>Star City</title>
>       <link>http://liftoff.example.net/2003/06/news-starcity</link>
>       <description>How do Americans get ready to work with Russians
>       aboard the International Space Station? They take a crash course
>       in culture, language and protocol at Russia's Star City.
>       </description>
>       <pubDate>Tue, 03 Jun 2003 09:39:21 GMT</pubDate>
>       <guid>http://liftoff.example.net/2003/06/news-starcity</guid>
>      </item>
>     </channel>
>    </rss>
> 
>    RSS 2.0-formatted Archive Document
> 
>    <?xml version="1.0"?>
>    <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"
>     xmlns:fh="http://purl.org/syndication/history/1.0">
>     <channel>
>      <title>Liftoff News</title>
>      <link>http://liftoff.example.net/</link>
>      <description>Liftoff to Space Exploration.</description>
>      <lastBuildDate>Fri, 30 May 2003 11:06:42 GMT</lastBuildDate>
>      <fh:archive/>
>      <atom:link rel="current"
>       href="http://liftoff.example.net/index.rss"/>
>      <atom:link rel="prev-archive"
>       href="http://liftoff.example.net/2003/04/index.rss"/>
> 
>      <item>
>       <description>Sky watchers in Europe, Asia, and parts of
>       Alaska and Canada will experience a partial eclipse of the Sun
>       on Saturday, May 31st.</description>
>       <pubDate>Fri, 30 May 2003 11:06:42 GMT</pubDate>
>       <guid>http://liftoff.nasa.gov/2003/05/30.html#item572</guid>
>      </item>
>      <item>
>       <title>The Engine That Does More</title>
>       <link>http://liftoff.example.net/2003/05/news-VASIMR.html</link>
>       <description>Before man travels to Mars, NASA hopes to
>       design new engines that will let us fly through the Solar
>       System more quickly. The proposed VASIMR engine would do
>       that.</description>
>       <pubDate>Tue, 27 May 2003 08:37:32 GMT</pubDate>
>       <guid>http://liftoff.example.net/2003/05/news-VASIMR.html</guid>
>      </item>
>     </channel>
>    </rss>
> 
> 
> --
> Mark Nottingham     http://www.mnot.net/
> 
> 




From owner-atom-syntax@mail.imc.org Sun Jun 10 19:54:11 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HxXEZ-0003ya-Ko
	for atompub-archive@lists.ietf.org; Sun, 10 Jun 2007 19:54:11 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1HxXEU-0001ll-Ji
	for atompub-archive@lists.ietf.org; Sun, 10 Jun 2007 19:54:11 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5ANTcMM023801
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 10 Jun 2007 16:29:38 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5ANTcCt023800;
	Sun, 10 Jun 2007 16:29:38 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5ANTaZ1023785
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Sun, 10 Jun 2007 16:29:37 -0700 (MST)
	(envelope-from mnot@mnot.net)
Received: from [192.168.1.102] (unknown [59.167.142.219])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 5064151926;
	Sun, 10 Jun 2007 19:29:34 -0400 (EDT)
In-Reply-To: <BAY118-DS36F3074BB56BA9163E0A99F1B0@phx.gbl>
References: <E1HqDtK-0002Xk-KZ@stiedprstage1.ietf.org> <16DD5E1B-B844-483A-B8D1-EB6A639E8B22@mnot.net> <BAY141-DAV4838A694ADF78388BF08DBE360@phx.gbl> <BAY128-DAV4388942CD007E92B92F549F360@phx.gbl> <BAY141-DAV47E422686EAEDEC3725E1BE360@phx.gbl> <C0C7CB42-52B7-440E-853E-B6B2B8C7EE6A@mnot.net> <BAY141-DAV562F45A7D501C55BC8E37BE350@phx.gbl> <BAY128-DAV80CF17AAB13CFD3D6EC499F350@phx.gbl> <BAY141-DAV224F793CDEB354A007073BE350@phx.gbl> <BAY128-DAV12560AE45A55AF433CD4249F350@phx.gbl> <6EB77951-B128-43D2-91F2-958289C18829@mnot.net> <BAY118-DS3081C9BBAF296C90A285A9F1B0@phx.gbl> <26285C54-EE75-4D94-A264-38569A4F82B6@mnot.net> <BAY118-DS36F3074BB56BA9163E0A99F1B0@phx.gbl>
Mime-Version: 1.0 (Apple Message framework v752.2)
X-Priority: 3
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <D02FF54F-92C9-4318-B438-5C6065BB641F@mnot.net>
Cc: "atom-syntax" <atom-syntax@imc.org>
Content-Transfer-Encoding: 7bit
X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg
From: Mark Nottingham <mnot@mnot.net>
Subject: Re: I-D ACTION:draft-nottingham-atompub-feed-history-10.txt
Date: Mon, 11 Jun 2007 09:29:34 +1000
To: Franklin Tse <peaceable_whale@hotmail.com>
X-Mailer: Apple Mail (2.752.2)
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48


The same could be said about Atom, with extensions to it. I'm  
reluctant to enumerate them all, because a) there's a question of  
precedence then, and b) it's an open list; more can always be defined.


On 10/06/2007, at 9:36 PM, Franklin Tse wrote:

>
>> The update time of an entry is not defined by RSS 2.0.
>
> The update time of an RSS 2 item can be determined by atom:updated  
> or dcterms:modified, or pubDate if both of the above do not  
> present. Should this be mentioned?
>
> Franklin
>
> ----- Original Message -----
> From: "Mark Nottingham" <mnot@mnot.net>
> To: "Franklin Tse" <peaceable_whale@hotmail.com>
> Cc: "James Holderness" <j4_james@hotmail.com>; "atom-syntax" <atom- 
> syntax@imc.org>
> Date: Sunday, 10 June, 2007 18:58
> Subject: Re: I-D ACTION:draft-nottingham-atompub-feed-history-10.txt
>
>> OK, this is what I currently have; comments?
>>
>> Appendix B.  Use in RSS 2.0
>>
>>    As previously noted, while this specification's extensions are
>>    described in terms of the Atom feed format, they are also  
>> useful in
>>    similar formats.  This informative appendix demonstrates how they
>> can
>>    be used in an RSS 2.0-formatted [9] feed.
>>
>>    In RSS 2.0-formatted feeds, two entries are duplicates if they  
>> have
>>    the same guid element.  The update time of an entry is not
>> defined by
>>    RSS 2.0, but the feed-level update time can be determined by the
>>    lastBuildDate element, if present.
>>
>>    RSS 2.0-formatted Complete Feed
>>
>>    <?xml version="1.0"?>
>>    <rss version="2.0"
>>     xmlns:fh="http://purl.org/syndication/history/1.0">
>>     <channel>
>>      <title>NetMovies Queue</title>
>>      <link>http://netmovies.example.org/</link>
>>      <description>The DVDs you'll receive next.</description>
>>      <fh:complete/>
>>      <item>
>>       <title>Casablanca</title>
>>       <link>http://netmovies.example.org/movies/Casablanca</link>
>>       <description>Here's looking at you, kid...
>>       </description>
>>       <pubDate>Tue, 03 Jun 2003 09:39:21 GMT</pubDate>
>>       <guid isPermaLink="false"
>>> urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</guid>
>>      </item>
>>     </channel>
>>    </rss>
>>
>>
>>    RSS 2.0-formatted Paged Feed
>>
>>    <?xml version="1.0"?>
>>    <rss version="2.0"
>>     xmlns:atom="http://www.w3.org/2005/Atom">
>>     <channel>
>>      <title>Liftoff News</title>
>>      <link>http://liftoff.example.net/</link>
>>      <description>Liftoff to Space Exploration.</description>
>>      <atom:link rel="next"
>>       href="http://liftof.example.net/index.rss?page=2"/>
>>      <item>
>>       <title>Star City</title>
>>       <link>http://liftoff.example.net/2003/06/news-starcity</link>
>>       <description>How do Americans get ready to work with Russians
>>       aboard the International Space Station? They take a crash  
>> course
>>       in culture, language and protocol at Russia's Star City.
>>       </description>
>>       <pubDate>Tue, 03 Jun 2003 09:39:21 GMT</pubDate>
>>       <guid>http://liftoff.example.net/2003/06/news-starcity</guid>
>>      </item>
>>     </channel>
>>    </rss>
>>
>>    RSS 2.0-formatted Subscription Document
>>
>>    <?xml version="1.0"?>
>>    <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
>>     <channel>
>>      <title>Liftoff News</title>
>>      <link>http://liftoff.example.net/</link>
>>      <description>Liftoff to Space Exploration.</description>
>>      <atom:link rel="prev-archive"
>>       href="http://liftoff.example.net/2003/05/index.rss"/>
>>
>>      <item>
>>       <title>Star City</title>
>>       <link>http://liftoff.example.net/2003/06/news-starcity</link>
>>       <description>How do Americans get ready to work with Russians
>>       aboard the International Space Station? They take a crash  
>> course
>>       in culture, language and protocol at Russia's Star City.
>>       </description>
>>       <pubDate>Tue, 03 Jun 2003 09:39:21 GMT</pubDate>
>>       <guid>http://liftoff.example.net/2003/06/news-starcity</guid>
>>      </item>
>>     </channel>
>>    </rss>
>>
>>    RSS 2.0-formatted Archive Document
>>
>>    <?xml version="1.0"?>
>>    <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"
>>     xmlns:fh="http://purl.org/syndication/history/1.0">
>>     <channel>
>>      <title>Liftoff News</title>
>>      <link>http://liftoff.example.net/</link>
>>      <description>Liftoff to Space Exploration.</description>
>>      <lastBuildDate>Fri, 30 May 2003 11:06:42 GMT</lastBuildDate>
>>      <fh:archive/>
>>      <atom:link rel="current"
>>       href="http://liftoff.example.net/index.rss"/>
>>      <atom:link rel="prev-archive"
>>       href="http://liftoff.example.net/2003/04/index.rss"/>
>>
>>      <item>
>>       <description>Sky watchers in Europe, Asia, and parts of
>>       Alaska and Canada will experience a partial eclipse of the Sun
>>       on Saturday, May 31st.</description>
>>       <pubDate>Fri, 30 May 2003 11:06:42 GMT</pubDate>
>>       <guid>http://liftoff.nasa.gov/2003/05/30.html#item572</guid>
>>      </item>
>>      <item>
>>       <title>The Engine That Does More</title>
>>       <link>http://liftoff.example.net/2003/05/news-VASIMR.html</ 
>> link>
>>       <description>Before man travels to Mars, NASA hopes to
>>       design new engines that will let us fly through the Solar
>>       System more quickly. The proposed VASIMR engine would do
>>       that.</description>
>>       <pubDate>Tue, 27 May 2003 08:37:32 GMT</pubDate>
>>       <guid>http://liftoff.example.net/2003/05/news-VASIMR.html</ 
>> guid>
>>      </item>
>>     </channel>
>>    </rss>
>>
>>
>> --
>> Mark Nottingham     http://www.mnot.net/
>>
>>
>


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




From owner-atom-syntax@mail.imc.org Sat Jun 16 14:12:25 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hzcl7-0002Go-DO
	for atompub-archive@lists.ietf.org; Sat, 16 Jun 2007 14:12:25 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Hzcl6-0003nr-15
	for atompub-archive@lists.ietf.org; Sat, 16 Jun 2007 14:12:25 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5GHmkbI018703
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 16 Jun 2007 10:48:46 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5GHmkBA018701;
	Sat, 16 Jun 2007 10:48:46 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169])
	(authenticated bits=0)
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5GHmhx7018676
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Sat, 16 Jun 2007 10:48:45 -0700 (MST)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: <p062408c9c299d27699ca@[10.20.30.108]>
Date: Sat, 16 Jun 2007 10:48:35 -0700
To: Atom WG <atom-syntax@imc.org>
From: Paul Hoffman <phoffman@imc.org>
Subject: Volunteering for IETF Nomcom
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08e48e05374109708c00c6208b534009


So, I know that few of you have attended three of the past five 
IETFs, but those of you who have should consider volunteering to be 
on the Nomcom to select about half of the IETF's leadership. See 
<https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=1234> 
for more information. I was on Nomcom about five years ago and found 
the experience rewarding overall.




From owner-atom-syntax@mail.imc.org Sun Jun 17 15:40:02 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I00bS-0003EU-UW
	for atompub-archive@lists.ietf.org; Sun, 17 Jun 2007 15:40:02 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I00bQ-0007bp-Gj
	for atompub-archive@lists.ietf.org; Sun, 17 Jun 2007 15:40:02 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5HJKrB9078991
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 17 Jun 2007 12:20:53 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5HJKrd2078990;
	Sun, 17 Jun 2007 12:20:53 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5HJKpvL078968;
	Sun, 17 Jun 2007 12:20:52 -0700 (MST)
	(envelope-from hartmans@mit.edu)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042)
	id 63B9148C7; Sun, 17 Jun 2007 15:20:47 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: atom-syntax@imc.org, atom-protocol@imc.org
Cc: atompub-ads@tools.ietf.org
Subject: Atom protocol and digital signatures
Date: Sun, 17 Jun 2007 15:20:47 -0400
Message-ID: <tslr6oa9yls.fsf@mit.edu>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352



[atom-syntax copied because while it seems inappropriate for this discussion it is the working group's official list of record according to the charter]

Hi.  I'm one of the security area directors and I currently have a
blocking discuss comment on the atom protocol document.  Lisa has
suggested fixes that address almost all of my concerns.  There is one
concern remaining that I would like to discuss with the working group.

Section 15.4 of the document basically says that digital signatures
may break and says little more.

That's problematic .  I certainly understand that sometimes a server
might choose to do something that has to break digital signatures like
say translating content from one language into another.

However there are many cases where it is unnecessary for digital
signatures to break.  If I post a blog post and the server doesn't
reformat or otherwise change my post, it seems that the signature on
the entry could remain.  The spec does not prohibit this, but it seems
that the working group should think more about the issue.

Here are some examples of questions I think should be answered:

1) I'm implementing a server; I don't want to break digital
    signatures.  What should I be careful of?  As an example, what
    changes that do not change the meaning of the XML can I make; what
    must I avoid?  If this can be answered by a reference to a
    specific section of another document that would be great.

2)  Should I strip a digital signature if I'm going to invalidate it?  

3) Should I provide a mechanism for a client to indicate that it would
    prefer a post fail than that digital signatures be broken?  (This
    especially seems potentially useful for encryption)?


4) It's probably desirable to recommend that servers not break digital
   signatures unless they are modifying content.


Sam Hartman
Security Area Director




From owner-atom-syntax@mail.imc.org Sun Jun 17 16:22:46 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I01Go-0000yr-9D
	for atompub-archive@lists.ietf.org; Sun, 17 Jun 2007 16:22:46 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I01Gm-00007E-QC
	for atompub-archive@lists.ietf.org; Sun, 17 Jun 2007 16:22:46 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5HJw2Ft086592
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 17 Jun 2007 12:58:02 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5HJw2cu086585;
	Sun, 17 Jun 2007 12:58:02 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5HJvtl2086552;
	Sun, 17 Jun 2007 12:57:55 -0700 (MST)
	(envelope-from Tim.Bray@Sun.COM)
Received: from fe-amer-03.sun.com ([192.18.108.177])
	by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5HJvgNp004811;
	Sun, 17 Jun 2007 19:57:51 GMT
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 id <0JJS00501PHQ4Z00@mail-amer.sun.com> (original mail from Tim.Bray@Sun.COM)
 ; Sun, 17 Jun 2007 13:57:42 -0600 (MDT)
Received: from [192.168.1.56] (fatwire-35-165.uniserve.ca [204.174.35.214])
 by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 with ESMTPSA id <0JJS007WPQ44AH00@mail-amer.sun.com>; Sun,
 17 Jun 2007 13:57:42 -0600 (MDT)
Date: Sun, 17 Jun 2007 12:57:14 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Atom protocol and digital signatures
In-reply-to: <tslr6oa9yls.fsf@mit.edu>
To: Sam Hartman <hartmans-ietf@mit.edu>
Cc: atom-syntax@imc.org, atom-protocol@imc.org, atompub-ads@tools.ietf.org
Message-id: <50F7EA57-A1BF-4243-BFEF-8AE82A49BBBB@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.752.3)
Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII
Content-transfer-encoding: 7BIT
References: <tslr6oa9yls.fsf@mit.edu>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44


I think Sam's perception that the WG didn't do much work on this is  
correct.  Probably for reasons having to do with server/client  
asymmetry, see below.

On Jun 17, 2007, at 12:20 PM, Sam Hartman wrote:

> Here are some examples of questions I think should be answered:
>
> 1) I'm implementing a server; I don't want to break digital
>     signatures.  What should I be careful of?  As an example, what
>     changes that do not change the meaning of the XML can I make; what
>     must I avoid?  If this can be answered by a reference to a
>     specific section of another document that would be great.

This turns out to be pretty hard.  It is the server's responsibility:
- to ensure that each entry has a globally unique atom:id element
- to ensure that each entry has an accurate atom:updated timestamp

So to preserve dig-sig, the client would be required to generate a  
globally-unique ID and be real careful about time-stamping, and the  
server would have to trust it.  Practically speaking, I think you'd  
need an out-of-band signal saying that the client is trying to  
achieve this effect.

More generally, in APP, the relationship between client and server is  
really unequal.  Basically, a client hands some data to the server  
and requests a best effort to store it in a useful and minimally- 
surprising way.  This is based on observation of real-world web  
publishing systems; server implementors are typically flatly  
unwilling to promise too much.  My perception is that of all the APP  
server implementations I've seen (and as the author of a testing  
tool, I've seen lots) exactly none would have any chance of  
preserving dig-sigs.

I haven't thought this through fully, but it may be the case that APP  
is inherently unsuited for publishing activities where client  
signature preservation is a requirement.  Hmm, now I'm thinking about  
special arrangements for preserving signatures on "payload" elements:  
title/category/summary/content.

> 2)  Should I strip a digital signature if I'm going to invalidate it?

I would think so.

> 3) Should I provide a mechanism for a client to indicate that it would
>     prefer a post fail than that digital signatures be broken?  (This
>     especially seems potentially useful for encryption)?

I don't think we understand the problem well enough yet to specify a  
solution.

> 4) It's probably desirable to recommend that servers not break digital
>    signatures unless they are modifying content.

The trouble is that at the moment, *every* server implementation  
modifies content.  -Tim




From owner-atom-syntax@mail.imc.org Sun Jun 17 16:39:28 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I01Wy-0004a8-LR
	for atompub-archive@lists.ietf.org; Sun, 17 Jun 2007 16:39:28 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I01Wy-0004PV-6K
	for atompub-archive@lists.ietf.org; Sun, 17 Jun 2007 16:39:28 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5HKI81I091368
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 17 Jun 2007 13:18:08 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5HKI8sR091367;
	Sun, 17 Jun 2007 13:18:08 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5HKI759091355;
	Sun, 17 Jun 2007 13:18:07 -0700 (MST)
	(envelope-from lisa@osafoundation.org)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1])
	by laweleka.osafoundation.org (Postfix) with ESMTP id E6F221422F1;
	Sun, 17 Jun 2007 13:18:06 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
Received: from laweleka.osafoundation.org ([127.0.0.1])
	by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 9dekmr7yhKVq; Sun, 17 Jun 2007 13:18:05 -0700 (PDT)
Received: from [192.168.1.100] (unknown [74.95.2.169])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(No client certificate requested)
	by laweleka.osafoundation.org (Postfix) with ESMTP id C8AD41422F0;
	Sun, 17 Jun 2007 13:18:04 -0700 (PDT)
In-Reply-To: <50F7EA57-A1BF-4243-BFEF-8AE82A49BBBB@sun.com>
References: <tslr6oa9yls.fsf@mit.edu> <50F7EA57-A1BF-4243-BFEF-8AE82A49BBBB@sun.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <F13E55EB-1A48-4CE6-B898-FF12980F3253@osafoundation.org>
Cc: Sam Hartman <hartmans-ietf@mit.edu>, atom-syntax@imc.org,
        atom-protocol@imc.org, atompub-ads@tools.ietf.org
Content-Transfer-Encoding: 7bit
From: Lisa Dusseault <lisa@osafoundation.org>
Subject: Re: Atom protocol and digital signatures
Date: Sun, 17 Jun 2007 13:17:59 -0700
To: Tim Bray <Tim.Bray@Sun.COM>
X-Mailer: Apple Mail (2.752.3)
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87


I did some thinking about this since it came up in IESG evaluation  
and concluded that for the moment, there's no way for the client to  
reliably and interoperably publish client-signed entries.  We should  
start by stating that in atompub (because I am guessing we're going  
to standardize a mechanism right now).

If there is a requirement that clients understand signed entries,  
then we can interoperably have the *server* sign entries and that may  
be slightly useful.  Not only is it slightly useful if the server  
signs with its own key, it also allows for some non-standard  
backchannel between publishing clients and servers, in which clients  
sign with their own keys.  Although the signing mechanism would be  
non-standard in that case, all existing clients would be required to  
understand signatures  so this optional authoring feature  would not  
break general publishing interoperability.

One way to do client signing in the future is for clients to start by  
POSTing signed entries.  If this is how it is likely to work in the  
future, then today we probably want to decide what "older" servers  
should do in the future -- reject signed entries, accept them  
unchanged and still signed (unlikely),  strip the signature or  
invalidate the signature.

Another way to do client signing in the future is for clients to POST  
unsigned entries, allow the server to assign timestamps and atomIDs  
and make other changes, and then sign the result.  The server could  
allow PUT or some other mechanism to overwrite an unsigned entry with  
a signed entry provided that the server-controlled content remains  
the same (need to think about updated value, of course).  If this is  
the way we expect things to work in the future, then there's less  
interop requirements to think about today.


Lisa

On Jun 17, 2007, at 12:57 PM, Tim Bray wrote:

> I think Sam's perception that the WG didn't do much work on this is  
> correct.  Probably for reasons having to do with server/client  
> asymmetry, see below.
>
> On Jun 17, 2007, at 12:20 PM, Sam Hartman wrote:
>
>> Here are some examples of questions I think should be answered:
>>
>> 1) I'm implementing a server; I don't want to break digital
>>     signatures.  What should I be careful of?  As an example, what
>>     changes that do not change the meaning of the XML can I make;  
>> what
>>     must I avoid?  If this can be answered by a reference to a
>>     specific section of another document that would be great.
>
> This turns out to be pretty hard.  It is the server's responsibility:
> - to ensure that each entry has a globally unique atom:id element
> - to ensure that each entry has an accurate atom:updated timestamp
>
> So to preserve dig-sig, the client would be required to generate a  
> globally-unique ID and be real careful about time-stamping, and the  
> server would have to trust it.  Practically speaking, I think you'd  
> need an out-of-band signal saying that the client is trying to  
> achieve this effect.
>
> More generally, in APP, the relationship between client and server  
> is really unequal.  Basically, a client hands some data to the  
> server and requests a best effort to store it in a useful and  
> minimally-surprising way.  This is based on observation of real- 
> world web publishing systems; server implementors are typically  
> flatly unwilling to promise too much.  My perception is that of all  
> the APP server implementations I've seen (and as the author of a  
> testing tool, I've seen lots) exactly none would have any chance of  
> preserving dig-sigs.
>
> I haven't thought this through fully, but it may be the case that  
> APP is inherently unsuited for publishing activities where client  
> signature preservation is a requirement.  Hmm, now I'm thinking  
> about special arrangements for preserving signatures on "payload"  
> elements: title/category/summary/content.
>
>> 2)  Should I strip a digital signature if I'm going to invalidate it?
>
> I would think so.
>
>> 3) Should I provide a mechanism for a client to indicate that it  
>> would
>>     prefer a post fail than that digital signatures be broken?  (This
>>     especially seems potentially useful for encryption)?
>
> I don't think we understand the problem well enough yet to specify  
> a solution.
>
>> 4) It's probably desirable to recommend that servers not break  
>> digital
>>    signatures unless they are modifying content.
>
> The trouble is that at the moment, *every* server implementation  
> modifies content.  -Tim
>




From owner-atom-syntax@mail.imc.org Sun Jun 17 16:41:45 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I01ZB-00060Q-7V
	for atompub-archive@lists.ietf.org; Sun, 17 Jun 2007 16:41:45 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I01Z1-0004vg-OV
	for atompub-archive@lists.ietf.org; Sun, 17 Jun 2007 16:41:45 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5HKLUNX092145
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 17 Jun 2007 13:21:30 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5HKLUVt092144;
	Sun, 17 Jun 2007 13:21:30 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5HKLSom092128
	for <atom-syntax@imc.org>; Sun, 17 Jun 2007 13:21:29 -0700 (MST)
	(envelope-from derhoermi@gmx.net)
Received: (qmail invoked by alias); 17 Jun 2007 20:21:28 -0000
Received: from dslb-084-057-243-234.pools.arcor-ip.net (EHLO hive) [84.57.243.234]
  by mail.gmx.net (mp019) with SMTP; 17 Jun 2007 22:21:28 +0200
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX19H1A8QR1hH8BxaEpSFmsOpED0JEXLRpaahPXGU19
	2r7qIXfsjxrLCb
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Sam Hartman <hartmans-ietf@mit.edu>
Cc: atom-syntax@imc.org, atom-protocol@imc.org, atompub-ads@tools.ietf.org
Subject: Re: Atom protocol and digital signatures
Date: Sun, 17 Jun 2007 22:21:24 +0200
Message-ID: <jg3b735k9n7b1r2alrt5v861hilshumf8p@hive.bjoern.hoehrmann.de>
References: <tslr6oa9yls.fsf@mit.edu>
In-Reply-To: <tslr6oa9yls.fsf@mit.edu>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
X-Y-GMX-Trusted: 0
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id l5HKLUNX092145
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17


* Sam Hartman wrote:
>Here are some examples of questions I think should be answered:
>
>1) I'm implementing a server; I don't want to break digital
>    signatures.  What should I be careful of?  As an example, what
>    changes that do not change the meaning of the XML can I make; what
>    must I avoid?  If this can be answered by a reference to a
>    specific section of another document that would be great.

This might not be a good question to answer. What is more interesting is
what servers are likely to change, so clients can filter those parts out
when creating the signature. Some things like choice of quote marks for
attribute values are universally understood to be irrelevant in XML pro-
cessing, and you cannot make any changes beyond that without risking to
break the signature unless you understand the signature method. I do not
think it would be useful to point that out, and saying much more might
be more confusing than useful.

On the other hand, it might be that server implementations leave, say,
author information, title, and textual content of an entry untouched,
knowing that clients might just sign those bits and leave the rest free
to change by the server. I am not sufficiently familiar with this to say
whether there is some good recommendation to make though, or whether it
might be better to put this into a later document when we have more im-
plementation experience. If there is nothing to recommend yet, it would
be best to not address this question.
--=20
Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehr=
mann.de
Weinh. Str. 22 =B7 Telefon: +49(0)621/4309674 =B7 http://www.bjoernsworld=
.de
68309 Mannheim =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev.d=
e/=20




From owner-atom-syntax@mail.imc.org Sun Jun 17 16:58:51 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I01pj-0000fL-M3
	for atompub-archive@lists.ietf.org; Sun, 17 Jun 2007 16:58:51 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I01pj-0007Yb-5y
	for atompub-archive@lists.ietf.org; Sun, 17 Jun 2007 16:58:51 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5HKfFAW096106
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 17 Jun 2007 13:41:15 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5HKfF3u096105;
	Sun, 17 Jun 2007 13:41:15 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5HKfExn096098
	for <atom-syntax@imc.org>; Sun, 17 Jun 2007 13:41:15 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by wa-out-1112.google.com with SMTP id l24so1997153waf
        for <atom-syntax@imc.org>; Sun, 17 Jun 2007 13:41:13 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed;
        d=gmail.com; s=beta;
        h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=AFrfKtvXyrFy9KOaPOxN3tb9k72fb5cu60hh5KOsAnFNPA3gXanfMMF5lF6JSJK63YUzmqOTvbSFWToaFX/HCB3YenI2vSNTuumWlptzv84WqXHZwqbDKFZCGfYWN8sCQbDyyCw2K+BDf4al5hHHpOgYacmS8jMw6XTdMbbdnSo=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=d58xh8vdBHRaDw0TO90qgYfvyrzofzwAgbkJ2nidKOtwGLnwR5+LhxHBz1cf47PKzkA/ihJTb4DZlya6ZiKjTn0VU8ivyK7+4UWB65ekOFE3pMUA7sbG+hb6UMXk5IUCd3eTu3GHUIX5M6XT0GjHeZeToYke57DfX6Y/bTxJQVk=
Received: by 10.114.170.1 with SMTP id s1mr5466708wae.1182112873685;
        Sun, 17 Jun 2007 13:41:13 -0700 (PDT)
Received: from ?192.168.1.118? ( [67.181.218.96])
        by mx.google.com with ESMTP id k9sm12773027wah.2007.06.17.13.41.12
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Sun, 17 Jun 2007 13:41:13 -0700 (PDT)
Message-ID: <46759C66.3040602@gmail.com>
Date: Sun, 17 Jun 2007 13:41:10 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.0 (X11/20070326)
MIME-Version: 1.0
To: Tim Bray <Tim.Bray@Sun.COM>
CC: Sam Hartman <hartmans-ietf@mit.edu>, atom-syntax@imc.org,
        atom-protocol@imc.org, atompub-ads@tools.ietf.org
Subject: Re: Atom protocol and digital signatures
References: <tslr6oa9yls.fsf@mit.edu> <50F7EA57-A1BF-4243-BFEF-8AE82A49BBBB@sun.com>
In-Reply-To: <50F7EA57-A1BF-4243-BFEF-8AE82A49BBBB@sun.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43


Tim Bray wrote:
> [snip]
> This turns out to be pretty hard.  It is the server's responsibility:
> - to ensure that each entry has a globally unique atom:id element
> - to ensure that each entry has an accurate atom:updated timestamp
> 
> So to preserve dig-sig, the client would be required to generate a
> globally-unique ID and be real careful about time-stamping, and the
> server would have to trust it.  Practically speaking, I think you'd need
> an out-of-band signal saying that the client is trying to achieve this
> effect.

Unless the server is storing the exact XML sent to it by the client
preserving the integrity of any included digital signatures becomes damn
near impossible.  For instance, I have several implementations that
accept an entry from a client, shred the content out into a relational
database, and reconstructs the entry when requested.  While the entry
that is returned to the client will generally have the same content,
title, etc, there will be enough changes that any digital signature
included in the original post would be worthless -- elements will be
presented in a different order; the atom:id, atom:updated: atom:author
information will be different; extension elements may have been added or
removed; attributes may be added or removed or shifted around; the
server may apply content filters to the text; etc.

In effect, a digital signature in an entry being sent from the client to
 the server is only guaranteed to cover that specific representation --
that is, only the representation is signed, and not the resource.

> [snip]
> My perception is that of all the APP server implementations I've seen
> (and as the author of a testing tool, I've seen lots) exactly none would
> have any chance of preserving dig-sigs.

Unless there is an explicit promise by the server that dsig's will be
preserved there is no reasonable assumption a client can make other than
 they will not be preserved.

> [snip]
> I haven't thought this through fully, but it may be the case that APP is
> inherently unsuited for publishing activities where client signature
> preservation is a requirement.  Hmm, now I'm thinking about special
> arrangements for preserving signatures on "payload" elements:
> title/category/summary/content.
> 

I think it depends entirely on the scenario.  It is easy to imagine a
case where a dsig in the entry is used by the server to verify the
integrity of the PUT/POST operation rather than as some piece of
metadata to be preserved.

>> 2)  Should I strip a digital signature if I'm going to invalidate it?
> 
> I would think so.
> 

Absolutely.

>> 3) Should I provide a mechanism for a client to indicate that it would
>>     prefer a post fail than that digital signatures be broken?  (This
>>     especially seems potentially useful for encryption)?
> 
> I don't think we understand the problem well enough yet to specify a
> solution.

This is a general problem that applies for more than just dsigs.  Should
we provide a mechanism for a client to indicate that it would prefer a
post fail if a particular extension cannot be supported?  Or if a
particular content type cannot be supported? We have the APP features
draft as a way of allowing the server to signal it's capabilities.
Would it not be enough for the server to state whether or not dsigs will
be preserved?  The client could look at that and make a determination
about what to do.

> 
>> 4) It's probably desirable to recommend that servers not break digital
>>    signatures unless they are modifying content.
> 
> The trouble is that at the moment, *every* server implementation
> modifies content.  -Tim
> 

This would be an absolutely terrible recommendation.  In APP, the server
is control. It can change whatever it wants any time it wants.  The
client needs to be aware of that make and make decisions accordingly.
What we need is a way of allowing the server to tell the client what it
will do, which is why the features draft exists.

- James




From owner-atom-syntax@mail.imc.org Sun Jun 17 17:04:27 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I01v9-0005kZ-Ld
	for atompub-archive@lists.ietf.org; Sun, 17 Jun 2007 17:04:27 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I01v8-0008Gd-8L
	for atompub-archive@lists.ietf.org; Sun, 17 Jun 2007 17:04:27 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5HKliBo097335
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 17 Jun 2007 13:47:44 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5HKlixA097334;
	Sun, 17 Jun 2007 13:47:44 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail1.webfaction.com (mail1.webfaction.com [67.15.2.85])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5HKlgTm097312
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 17 Jun 2007 13:47:43 -0700 (MST)
	(envelope-from sh@defuze.org)
Received: from [192.168.0.2] ([89.243.114.217])
	(authenticated bits=0)
	by mail1.webfaction.com (8.12.11.20060308/8.13.3) with ESMTP id l5HKldDT029662;
	Sun, 17 Jun 2007 15:47:40 -0500
Message-ID: <46759DE5.6020808@defuze.org>
Date: Sun, 17 Jun 2007 21:47:33 +0100
From: Sylvain Hellegouarch <sh@defuze.org>
User-Agent: Thunderbird 1.5.0.12 (X11/20070604)
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
CC: Tim Bray <Tim.Bray@Sun.COM>, Sam Hartman <hartmans-ietf@mit.edu>,
        atom-syntax@imc.org, atom-protocol@imc.org, atompub-ads@tools.ietf.org
Subject: Re: Atom protocol and digital signatures
References: <tslr6oa9yls.fsf@mit.edu> <50F7EA57-A1BF-4243-BFEF-8AE82A49BBBB@sun.com> <F13E55EB-1A48-4CE6-B898-FF12980F3253@osafoundation.org>
In-Reply-To: <F13E55EB-1A48-4CE6-B898-FF12980F3253@osafoundation.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id l5HKliBo097335
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007


Lisa Dusseault a =E9crit :
>
> I did some thinking about this since it came up in IESG evaluation and=20
> concluded that for the moment, there's no way for the client to=20
> reliably and interoperably publish client-signed entries.  We should=20
> start by stating that in atompub (because I am guessing we're going to=20
> standardize a mechanism right now).
>
> If there is a requirement that clients understand signed entries, then=20
> we can interoperably have the *server* sign entries and that may be=20
> slightly useful.  Not only is it slightly useful if the server signs=20
> with its own key, it also allows for some non-standard backchannel=20
> between publishing clients and servers, in which clients sign with=20
> their own keys.  Although the signing mechanism would be non-standard=20
> in that case, all existing clients would be required to understand=20
> signatures  so this optional authoring feature  would not break=20
> general publishing interoperability.

That'd be easier for sure but how to deal with potential server to=20
server exchange?

- Sylvain




From owner-atom-syntax@mail.imc.org Sun Jun 17 17:13:45 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0249-0004ag-9r
	for atompub-archive@lists.ietf.org; Sun, 17 Jun 2007 17:13:45 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0248-000207-Rw
	for atompub-archive@lists.ietf.org; Sun, 17 Jun 2007 17:13:45 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5HKpGVe098207
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 17 Jun 2007 13:51:16 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5HKpGDk098206;
	Sun, 17 Jun 2007 13:51:16 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5HKpFv5098188
	for <atom-syntax@imc.org>; Sun, 17 Jun 2007 13:51:15 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by wa-out-1112.google.com with SMTP id l24so1999576waf
        for <atom-syntax@imc.org>; Sun, 17 Jun 2007 13:51:14 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed;
        d=gmail.com; s=beta;
        h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=BtGC6YrwGfRDa4PRXuZFDA/keA/9LkBzxWYXwpYfBZ/wR0YTXRfbWkTL2LzlIH79dZ3XnXpdE1luAPaiuypDTorQ9nruLfMt407vekYyVzcYcNidj9R0C5jjkjSNmwSZQjiyyWymwpcQI52IEF7v52foDaDah9aE0/X85CJMRFI=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=qQY1o8pVAKvFJ0BYtDm5dyxD1ZFR7FCmc9I6SECkAwDaUQx0Onijnqms0qLM64UqQcE51cjLV6hJS1R8iwvWLrDx59sYzM2CgEOCOdrUGUIWw7uY/IE/fAH7ltrqZBBkJPSfyZBiIa8duk4Y0Ebpc1/Eky5+1PEAbOfHMjCOdBM=
Received: by 10.114.199.1 with SMTP id w1mr5162721waf.1182113474770;
        Sun, 17 Jun 2007 13:51:14 -0700 (PDT)
Received: from ?192.168.1.118? ( [67.181.218.96])
        by mx.google.com with ESMTP id j15sm8124268waf.2007.06.17.13.51.13
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Sun, 17 Jun 2007 13:51:14 -0700 (PDT)
Message-ID: <46759EBF.3000604@gmail.com>
Date: Sun, 17 Jun 2007 13:51:11 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.0 (X11/20070326)
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
CC: Tim Bray <Tim.Bray@Sun.COM>, Sam Hartman <hartmans-ietf@mit.edu>,
        atom-syntax@imc.org, atom-protocol@imc.org, atompub-ads@tools.ietf.org
Subject: Re: Atom protocol and digital signatures
References: <tslr6oa9yls.fsf@mit.edu> <50F7EA57-A1BF-4243-BFEF-8AE82A49BBBB@sun.com> <F13E55EB-1A48-4CE6-B898-FF12980F3253@osafoundation.org>
In-Reply-To: <F13E55EB-1A48-4CE6-B898-FF12980F3253@osafoundation.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da




Lisa Dusseault wrote:
> 
> I did some thinking about this since it came up in IESG evaluation and
> concluded that for the moment, there's no way for the client to reliably
> and interoperably publish client-signed entries.  We should start by
> stating that in atompub (because I am guessing we're going to
> standardize a mechanism right now).

It depends entirely on what you mean by "publish".  If you mean have the
server store exactly what the client sent and serve it back up with
perfect fidelity, then you're right.  Thing is, that's not what APP was
intended to do.

Because of Atom's must-ignore semantics, all APP servers should be able
to work with digitally signed entries sent by a client on PUT or POST.
What it does with those signatures is completely up the server.  Whether
or not those signatures and the content they cover is preserved in a way
that does not invalidate the signature is completely up to the server
implementation.  This is not an interoperability problem.  It's a client
expectation problem.  If the client expects to have the digital
signatures preserved, it better darn well know what the server will do
with 'em before it sends 'em.

> 
> If there is a requirement that clients understand signed entries, then
> we can interoperably have the *server* sign entries and that may be
> slightly useful.  Not only is it slightly useful if the server signs
> with its own key, it also allows for some non-standard backchannel
> between publishing clients and servers, in which clients sign with their
> own keys.  Although the signing mechanism would be non-standard in that
> case, all existing clients would be required to understand signatures 
> so this optional authoring feature  would not break general publishing
> interoperability.

There is no need for such a requirement.  RFC4287 already states that
entries and feeds can be digitally signed.  It also already states that
unknown extensions MUST be ignored.  That's enough.  A server can sign
an entry, a client must either know how to deal with the signature or
must know how to ignore it.  There's nothing else APP needs to say on
the matter.

> 
> One way to do client signing in the future is for clients to start by
> POSTing signed entries.  If this is how it is likely to work in the
> future, then today we probably want to decide what "older" servers
> should do in the future -- reject signed entries, accept them unchanged
> and still signed (unlikely),  strip the signature or invalidate the
> signature.
> 
> Another way to do client signing in the future is for clients to POST
> unsigned entries, allow the server to assign timestamps and atomIDs and
> make other changes, and then sign the result.  The server could allow
> PUT or some other mechanism to overwrite an unsigned entry with a signed
> entry provided that the server-controlled content remains the same (need
> to think about updated value, of course).  If this is the way we expect
> things to work in the future, then there's less interop requirements to
> think about today.

What exactly are you trying to achieve with this?

- James




From owner-atom-syntax@mail.imc.org Mon Jun 18 01:12:47 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I09Xh-0004GR-N1
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 01:12:45 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I09Xf-0000zN-LN
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 01:12:45 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5I4ld6N098787
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 17 Jun 2007 21:47:39 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5I4ldiU098785;
	Sun, 17 Jun 2007 21:47:39 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5I4lGaa098697;
	Sun, 17 Jun 2007 21:47:17 -0700 (MST)
	(envelope-from lisa@osafoundation.org)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1])
	by laweleka.osafoundation.org (Postfix) with ESMTP id 340291422F4;
	Sun, 17 Jun 2007 21:47:16 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
Received: from laweleka.osafoundation.org ([127.0.0.1])
	by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id wVCc18dVpBL8; Sun, 17 Jun 2007 21:47:14 -0700 (PDT)
Received: from [192.168.1.100] (unknown [74.95.2.169])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(No client certificate requested)
	by laweleka.osafoundation.org (Postfix) with ESMTP id 0629E1422F3;
	Sun, 17 Jun 2007 21:47:13 -0700 (PDT)
In-Reply-To: <46759EBF.3000604@gmail.com>
References: <tslr6oa9yls.fsf@mit.edu> <50F7EA57-A1BF-4243-BFEF-8AE82A49BBBB@sun.com> <F13E55EB-1A48-4CE6-B898-FF12980F3253@osafoundation.org> <46759EBF.3000604@gmail.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: multipart/alternative; boundary=Apple-Mail-89--176118261
Message-Id: <371C7E24-4395-4794-B2C5-5A11180910B0@osafoundation.org>
Cc: Tim Bray <Tim.Bray@Sun.COM>, Sam Hartman <hartmans-ietf@mit.edu>,
        atom-syntax@imc.org, atom-protocol@imc.org, atompub-ads@tools.ietf.org
From: Lisa Dusseault <lisa@osafoundation.org>
Subject: Re: Atom protocol and digital signatures
Date: Sun, 17 Jun 2007 21:47:08 -0700
To: James M Snell <jasnell@gmail.com>
X-Mailer: Apple Mail (2.752.3)
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a



--Apple-Mail-89--176118261
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed


On Jun 17, 2007, at 1:51 PM, James M Snell wrote:

>>
>> One way to do client signing in the future is for clients to start by
>> POSTing signed entries.  If this is how it is likely to work in the
>> future, then today we probably want to decide what "older" servers
>> should do in the future -- reject signed entries, accept them  
>> unchanged
>> and still signed (unlikely),  strip the signature or invalidate the
>> signature.
>>
>> Another way to do client signing in the future is for clients to POST
>> unsigned entries, allow the server to assign timestamps and  
>> atomIDs and
>> make other changes, and then sign the result.  The server could allow
>> PUT or some other mechanism to overwrite an unsigned entry with a  
>> signed
>> entry provided that the server-controlled content remains the same  
>> (need
>> to think about updated value, of course).  If this is the way we  
>> expect
>> things to work in the future, then there's less interop  
>> requirements to
>> think about today.
>
> What exactly are you trying to achieve with this?

Trying to figure out if there are any additional requirements or  
decisions or clarifications to make now, that would make design and  
interoperability much easier when (if) a group gets around to  
standardizing a way to do client signatures.  It's not worth much  
work now (present value of money/time and all that) but it's worth a  
bit of thought.

Lisa
--Apple-Mail-89--176118261
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><BR><DIV><DIV>On Jun 17, 2007, =
at 1:51 PM, James M Snell wrote:</DIV><BR =
class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite"><BLOCKQUOTE =
type=3D"cite"><P style=3D"margin: 0.0px 0.0px 0.0px 10.0px; font: 12.0px =
Helvetica; min-height: 14.0px"><BR></P> <P style=3D"margin: 0.0px 0.0px =
0.0px 10.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">One way to do client signing in the future is for clients to =
start by</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px 10.0px"><FONT =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">POSTing =
signed entries.<SPAN class=3D"Apple-converted-space">=A0 </SPAN>If this =
is how it is likely to work in the</FONT></P> <P style=3D"margin: 0.0px =
0.0px 0.0px 10.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: =
12.0px Helvetica">future, then today we probably want to decide what =
"older" servers</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px =
10.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">should do in the future -- reject signed entries, accept them =
unchanged</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px 10.0px"><FONT =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">and still =
signed (unlikely),<SPAN class=3D"Apple-converted-space">=A0 </SPAN>strip =
the signature or invalidate the</FONT></P> <P style=3D"margin: 0.0px =
0.0px 0.0px 10.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: =
12.0px Helvetica">signature.</FONT></P> <P style=3D"margin: 0.0px 0.0px =
0.0px 10.0px; font: 12.0px Helvetica; min-height: 14.0px"><BR></P> <P =
style=3D"margin: 0.0px 0.0px 0.0px 10.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">Another way to do client =
signing in the future is for clients to POST</FONT></P> <P =
style=3D"margin: 0.0px 0.0px 0.0px 10.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">unsigned entries, allow the =
server to assign timestamps and atomIDs and</FONT></P> <P style=3D"margin:=
 0.0px 0.0px 0.0px 10.0px"><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica">make other changes, and then sign the =
result.<SPAN class=3D"Apple-converted-space">=A0 </SPAN>The server could =
allow</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px 10.0px"><FONT =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">PUT or =
some other mechanism to overwrite an unsigned entry with a =
signed</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px 10.0px"><FONT =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">entry =
provided that the server-controlled content remains the same =
(need</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px 10.0px"><FONT =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">to think =
about updated value, of course).<SPAN class=3D"Apple-converted-space">=A0 =
</SPAN>If this is the way we expect</FONT></P> <P style=3D"margin: 0.0px =
0.0px 0.0px 10.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: =
12.0px Helvetica">things to work in the future, then there's less =
interop requirements to</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px =
10.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">think about today.</FONT></P> </BLOCKQUOTE><P style=3D"margin: =
0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: =
14.0px"><BR></P> <P style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">What =
exactly are you trying to achieve with this?</FONT></P> =
</BLOCKQUOTE></DIV><BR><DIV>Trying to figure out if there are any =
additional requirements or decisions or clarifications to make now, that =
would make design and interoperability much easier when (if) a group =
gets around to standardizing a way to do client signatures.=A0 It's not =
worth much work now (present value of money/time and all that) but it's =
worth a bit of thought.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Lisa</DIV></BODY></HTML>=

--Apple-Mail-89--176118261--




From owner-atom-syntax@mail.imc.org Mon Jun 18 02:33:13 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0AnZ-0000Lg-L8
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 02:33:13 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0AnZ-0006oU-0E
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 02:33:13 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5I6EBgP018527
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 17 Jun 2007 23:14:11 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5I6EBxO018526;
	Sun, 17 Jun 2007 23:14:11 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.233])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5I6EAsR018509
	for <atom-syntax@imc.org>; Sun, 17 Jun 2007 23:14:10 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by wx-out-0506.google.com with SMTP id s16so1301991wxc
        for <atom-syntax@imc.org>; Sun, 17 Jun 2007 23:14:05 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed;
        d=gmail.com; s=beta;
        h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=SUtcRIjRXKnNHTUnXPV4iLbdPrCP62DUTfWDIRNgfB1QFkpzqzh7MU/1iCiX/gAaSzy6PKA6Is8ENISxW1Shf9fvlyMVqiyTqIFGE+2tatWkQTAiu64AUQyw5y//gyTWod6FJS8EAj2+bLPDLOkB8hotMBblCIr3osQLPrUFhLg=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=pTVCgCOCHgBnBZc9nuGivxrSYY31xHUVjX9lh1wSPvWHklZWOC6pHsuTavYbcM5rgQPqWc7eB6tmrE/a/zhYtIp+izfMY7JdoS3CUxQJJFxt1N0SWVQ2a8/N6TD08/JxtUhRAooWIJZUj/6YWcwr6M52VuPUj4h137yMQIBWtz0=
Received: by 10.70.21.8 with SMTP id 8mr9086017wxu.1182147245503;
        Sun, 17 Jun 2007 23:14:05 -0700 (PDT)
Received: from ?192.168.1.118? ( [67.181.218.96])
        by mx.google.com with ESMTP id g7sm146493wra.2007.06.17.23.14.03
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Sun, 17 Jun 2007 23:14:04 -0700 (PDT)
Message-ID: <467622A9.80306@gmail.com>
Date: Sun, 17 Jun 2007 23:14:01 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.0 (X11/20070326)
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
CC: Tim Bray <Tim.Bray@Sun.COM>, Sam Hartman <hartmans-ietf@mit.edu>,
        atom-syntax@imc.org, atom-protocol@imc.org, atompub-ads@tools.ietf.org
Subject: Re: Atom protocol and digital signatures
References: <tslr6oa9yls.fsf@mit.edu> <50F7EA57-A1BF-4243-BFEF-8AE82A49BBBB@sun.com> <F13E55EB-1A48-4CE6-B898-FF12980F3253@osafoundation.org> <46759EBF.3000604@gmail.com> <371C7E24-4395-4794-B2C5-5A11180910B0@osafoundation.org>
In-Reply-To: <371C7E24-4395-4794-B2C5-5A11180910B0@osafoundation.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88


Sorry, I wasn't clear. I was asking what the technical objective would
be behind your suggestions. When a client POSTs a digitally signed entry
to the server, what is the intent?  Is the dsig part of the  content
that the client would like to have preserved? Or is the dsig some form
of message level integrity check the server can use to make sure the
entry has not been messed with in transit?  Or is the dsig something
else?  So far this discussion seems to be focusing on the idea that the
dsig is part of the content.  This group has well established that when
it comes to the content of an entry, the server is in complete control
and can make any change it wants to make, period, which would presumably
include invalidating signatures.

Or, are digital signatures in an entry some kind of special entity that
MUST be treated differently than other kinds of extensions?  Does the
presence of a signature in an entry hold some kind of special meaning
that the server MUST be capable of understanding and dealing with?

Lisa Dusseault wrote:
> 
> On Jun 17, 2007, at 1:51 PM, James M Snell wrote:
> 
>>>
>>> One way to do client signing in the future is for clients to start by
>>> POSTing signed entries.  If this is how it is likely to work in the
>>> future, then today we probably want to decide what "older" servers
>>> should do in the future -- reject signed entries, accept them unchanged
>>> and still signed (unlikely),  strip the signature or invalidate the
>>> signature.

If dsig's are treated as Just-Another-Extension, there is already an
established processing model that is more than adequate.  RFC4287 states
that unknown extensions MUST be ignored.  A client could choose to
digitally sign every entry is produces; a server that receives those
entries could simply ignore the signature if it is not capable of doing
anything with it.  If some other server chooses to do something with
those signatures, then cool. "Older" servers would just continue
ignoring those signatures leaving the responsibility on the client to
decide if that's an acceptable behavior.

>>>
>>> Another way to do client signing in the future is for clients to POST
>>> unsigned entries, allow the server to assign timestamps and atomIDs and
>>> make other changes, and then sign the result.  The server could allow
>>> PUT or some other mechanism to overwrite an unsigned entry with a signed
>>> entry provided that the server-controlled content remains the same (need
>>> to think about updated value, of course).  If this is the way we expect
>>> things to work in the future, then there's less interop requirements to
>>> think about today.
>>>

Again, the current must-ignore model provides a perfectly adequate
approach to dealing with all this.   None of this becomes an issue
unless you want to assign some kind of special meaning to a digital
signature in an entry -- that is, making it more than
Just-Another-Extension.

- James

>>
>> What exactly are you trying to achieve with this?
>>
> 
> Trying to figure out if there are any additional requirements or
> decisions or clarifications to make now, that would make design and
> interoperability much easier when (if) a group gets around to
> standardizing a way to do client signatures.  It's not worth much work
> now (present value of money/time and all that) but it's worth a bit of
> thought.
> 
> Lisa




From owner-atom-syntax@mail.imc.org Mon Jun 18 02:57:55 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0BBT-0003RS-DR
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 02:57:55 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0BBR-00042F-Vh
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 02:57:55 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5I6YxP9023129
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 17 Jun 2007 23:34:59 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5I6Yxxi023127;
	Sun, 17 Jun 2007 23:34:59 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5I6Ysux023098;
	Sun, 17 Jun 2007 23:34:55 -0700 (MST)
	(envelope-from Tim.Bray@Sun.COM)
Received: from fe-amer-03.sun.com ([192.18.108.177])
	by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5I6Yr4X022318;
	Mon, 18 Jun 2007 06:34:54 GMT
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 id <0JJT00A01J7M7R00@mail-amer.sun.com> (original mail from Tim.Bray@Sun.COM)
 ; Mon, 18 Jun 2007 00:34:53 -0600 (MDT)
Received: from [192.168.1.56] (fatwire-35-165.uniserve.ca [204.174.35.214])
 by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 with ESMTPSA id <0JJT007JLJM4AH20@mail-amer.sun.com>; Mon,
 18 Jun 2007 00:34:53 -0600 (MDT)
Date: Sun, 17 Jun 2007 23:34:25 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Atom protocol and digital signatures
In-reply-to: <467622A9.80306@gmail.com>
To: Sam Hartman <hartmans-ietf@mit.edu>,
        atom-syntax Syntax <atom-syntax@imc.org>,
        Atom Publishing Protocol <atom-protocol@imc.org>,
        atompub-ads@tools.ietf.org
Message-id: <C1A2E70E-3531-41C3-B34A-4C7843D45C67@Sun.COM>
MIME-version: 1.0
X-Mailer: Apple Mail (2.752.3)
Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII
Content-transfer-encoding: 7BIT
References: <tslr6oa9yls.fsf@mit.edu>
 <50F7EA57-A1BF-4243-BFEF-8AE82A49BBBB@sun.com>
 <F13E55EB-1A48-4CE6-B898-FF12980F3253@osafoundation.org>
 <46759EBF.3000604@gmail.com>
 <371C7E24-4395-4794-B2C5-5A11180910B0@osafoundation.org>
 <467622A9.80306@gmail.com>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a


The more I think about this, the more the right answer seems  
obvious.  The notion of a client signing a whole Atom entry is just  
fundamentally bogus, because some parts of it are actually owned by  
the server (id, update-timestamp).  On the other hand, the notion of  
a client signing the payload (title/author/categories/summary/ 
content) is interesting and worth exploring.  Fortunately, Atom & APP  
are flexible enough that anyone can try a few things out without  
breaking any implementations.  Unfortunately, nobody has ever  
implemented anything like this that I know of, and I don't even know  
of any applications that need it, so it''s *way* too early to try to  
specify The Right Thing To Do.

So.... I would address Sam's points like so:

Expand 15.5 to point out all the problems that have emerged in this  
discussion and which make client-originated dig-sig a non-starter for  
APP.  Further point out that server-side dig-sig, per RFC4287 rules,  
might make all sorts of sense in certain apps and is perfectly  
technically feasible; I now think it's a bug that the spec leaves you  
with the impression that something about server-side digsig might not  
work.  Further point out that signature elements can freely be  
inserted in to-be-posted entries by clients and are guaranteed not to  
break the server because of our MustIgnore rule, and make it clear  
that the door is open to payload signing.

The idea is that down the road, when there's a body of experience and  
we know what the Best Practices are, someone can spec an APP  
Extension to capture them.  -Tim




From owner-atom-syntax@mail.imc.org Mon Jun 18 03:07:05 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0BKL-0005PK-LW
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 03:07:05 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0BKJ-00066F-8y
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 03:07:05 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5I6lH1X026428
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 17 Jun 2007 23:47:17 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5I6lHgX026427;
	Sun, 17 Jun 2007 23:47:17 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.234])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5I6lGek026418
	for <atom-syntax@imc.org>; Sun, 17 Jun 2007 23:47:16 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by wx-out-0506.google.com with SMTP id s16so1307342wxc
        for <atom-syntax@imc.org>; Sun, 17 Jun 2007 23:47:15 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed;
        d=gmail.com; s=beta;
        h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=bvCdcjAupLuY8f5RgiJ7JrW1CbVy3Rbn1lGHt/tsyX06WNc7o5UvymwqnfIw4HmJ8N8ApwRHBuic2O3OjIRKieM4JVPum1rO3ULKeH5UtyRNpqEllGvetkSZ4Sz3cjcTjk5Q6wwZbHKpx23NcIMmc59UK07iFNrbnjidxf0irZ8=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=IZgyCwq2KmKTk5n/vvxdFRiFRj+CFrNSlIoMUDEaU2FcEotR3ICbtswOog43yiZxGgezfzEE5zBNRcSMzLU22Qeo4v6LOdcdZk8dAJgseRkvavUsEGZlG4EjRzGArCaCptV+YShkpmxZdQiHuq3BzQrVTcP3R3HH7sXQqjXNT2o=
Received: by 10.70.39.5 with SMTP id m5mr9171635wxm.1182149230919;
        Sun, 17 Jun 2007 23:47:10 -0700 (PDT)
Received: from ?192.168.1.118? ( [67.181.218.96])
        by mx.google.com with ESMTP id l48sm7322167wrl.2007.06.17.23.47.09
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Sun, 17 Jun 2007 23:47:09 -0700 (PDT)
Message-ID: <46762A6A.4040402@gmail.com>
Date: Sun, 17 Jun 2007 23:47:06 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.0 (X11/20070326)
MIME-Version: 1.0
To: Tim Bray <Tim.Bray@Sun.COM>
CC: Sam Hartman <hartmans-ietf@mit.edu>,
        atom-syntax Syntax <atom-syntax@imc.org>,
        Atom Publishing Protocol <atom-protocol@imc.org>,
        atompub-ads@tools.ietf.org
Subject: Re: Atom protocol and digital signatures
References: <tslr6oa9yls.fsf@mit.edu> <50F7EA57-A1BF-4243-BFEF-8AE82A49BBBB@sun.com> <F13E55EB-1A48-4CE6-B898-FF12980F3253@osafoundation.org> <46759EBF.3000604@gmail.com> <371C7E24-4395-4794-B2C5-5A11180910B0@osafoundation.org> <467622A9.80306@gmail.com> <C1A2E70E-3531-41C3-B34A-4C7843D45C67@Sun.COM>
In-Reply-To: <C1A2E70E-3531-41C3-B34A-4C7843D45C67@Sun.COM>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25


FWIW, I have implemented a prototype in which a server only accepts
entries with valid digital signatures.  The server used those signatures
to verify the integrity of the payload but did not attempt to preserve
the signature.  That said, however, you are definitely right about it
being too early to specify the Right Thing To Do.

- James

Tim Bray wrote:
> [snip]
> Unfortunately, nobody has ever implemented anything like this that I
> know of, and I don't even know of any applications that need it, so
> it''s *way* too early to try to specify The Right Thing To Do.
> [snip]




From owner-atom-syntax@mail.imc.org Mon Jun 18 10:43:39 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0ISB-0000Zo-AY
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 10:43:39 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0ISA-0002Uh-RH
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 10:43:39 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5IEFU8E093526
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 18 Jun 2007 07:15:30 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5IEFUdu093525;
	Mon, 18 Jun 2007 07:15:30 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from fepv02.charter.net (fepv02.charter.net [209.225.8.201])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5IEFTsL093519
	for <atom-syntax@imc.org>; Mon, 18 Jun 2007 07:15:29 -0700 (MST)
	(envelope-from antone@geckotribe.com)
Received: from aa10.charter.net ([10.20.200.162]) by fepv02.charter.net
          (InterMail vM.7.08.02.00 201-2186-121-20061213) with ESMTP
          id <20070618141516.HXRF1505.fepv02.charter.net@aa10.charter.net>
          for <atom-syntax@imc.org>; Mon, 18 Jun 2007 10:15:16 -0400
Received: from G-Force.local ([71.87.92.92]) by aa10.charter.net with ESMTP
          id <20070618141516.LBMY2104.aa10.charter.net@G-Force.local>
          for <atom-syntax@imc.org>; Mon, 18 Jun 2007 10:15:16 -0400
Message-ID: <4676936A.1080909@geckotribe.com>
Date: Mon, 18 Jun 2007 09:15:06 -0500
From: Antone Roundy <antone@geckotribe.com>
Reply-To: antone@geckotribe.com
User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070419)
MIME-Version: 1.0
To: atom-syntax Syntax <atom-syntax@imc.org>
Subject: Re: Atom protocol and digital signatures
References: <tslr6oa9yls.fsf@mit.edu> <50F7EA57-A1BF-4243-BFEF-8AE82A49BBBB@sun.com> <F13E55EB-1A48-4CE6-B898-FF12980F3253@osafoundation.org> <46759EBF.3000604@gmail.com> <371C7E24-4395-4794-B2C5-5A11180910B0@osafoundation.org> <467622A9.80306@gmail.com> <C1A2E70E-3531-41C3-B34A-4C7843D45C67@Sun.COM>
In-Reply-To: <C1A2E70E-3531-41C3-B34A-4C7843D45C67@Sun.COM>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Chzlrs: 0
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe


Yeah, I'm still lurking here.

First, let me state the obvious: a signature enables you to verify that 
the data you received hasn't been changed since it was signed by a 
particular entity.  It seems to me that there are a few things we might 
want to do with that ability:


1) Verify the integrity of data on a "single hop" (no need to preserve 
the signature).


2) Verify that the data is as it was when produced by the original 
creator (would require preservation of the signature).


3) #1 PLUS allow whoever signed the data to claim that what it received 
was signed and that it validated the signature.


 From what others have said, #2 doesn't sound possible.  #1 clearly is 
possible.  So what about #3?  Might something like this be done?

A) The client signs the data and sends it to the server.

B) The server validates and discards the signature, and adds an element 
like this:

<ext:i-got-this-signed-from who="some sort of identifier" who-am-i="some 
sort of identifier" seq="1" />

I don't know enough about digital signatures to know what an appropriate 
identifier might be -- perhaps a URL from which their public key could 
be retrieved or something?  @seq is there to identify who got the data 
from whom in what order.

C) The server signs the whole package including the added element and 
sends it on to whoever's next.

D) Whoever gets the data next repeats B & C, and so on, so that at any 
point, whoever receives the data can verify that the entire package came 
from some specific entity, and also trace the data's route backwards to 
its source.

The obvious weakness of this approach is that the 
"i-got-this-signed-from" elements could be forged.  But if you trust 
that the entity that signed the data that you received wouldn't forge 
them, and if you happen to know and trust all the other entities who's 
@who-am-i's are in there, then you should be able to establish SOME 
level of trust in the data.

Additionally, whoever inserts an "i-got-this-signed-from" COULD sign it 
and that signature could be carried forward. But that might be better 
not done than done since it may give a false sense of security, since 
all that it would really verify is that whoever inserted that 
"i-got-this-signed-from" and its signature has at some point seen an 
"i-got-this-signed-from" created by @who-am-i for @who with that 
particular @seq value.


Antone




From owner-atom-syntax@mail.imc.org Mon Jun 18 11:29:12 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0JAG-00055a-8l
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 11:29:12 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0JAC-0004O4-2n
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 11:29:12 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5IF7e9U099480
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 18 Jun 2007 08:07:40 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5IF7eeN099479;
	Mon, 18 Jun 2007 08:07:40 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.239])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5IF7c9d099473
	for <atom-syntax@imc.org>; Mon, 18 Jun 2007 08:07:38 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by wr-out-0506.google.com with SMTP id 70so966825wra
        for <atom-syntax@imc.org>; Mon, 18 Jun 2007 08:07:37 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed;
        d=gmail.com; s=beta;
        h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=adwhwnmQ5SJnmsvRdDNhw641oYB2hhU101nRjLNmIJYaPxfM5I2ueJ/Op+Fcfz6v/hX7zYaEDxEeiixOPz0LsX25C2eH4qRYOAogb6linjsdNnitR7U5tKflbuPbsaOuWtgAsmafRXbX6jYSEcw27gEsmcKg2vV/8B1C2mb+buo=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=CEbIZTqVP5OIPF2t8KkhdkCpTvloitGxO3Xmz6UexC/jkl5BHkRghB95mnlO/xqrssskQvmMVvvdy+hxlVB7IhZoWLQnZS4vjBSOHAvLhNfrkYyD++MvhaVlCqAIgbm6Tc/QoET72MS1Xi64vm12Sbry1lu4udxQz8bF6NOySQA=
Received: by 10.90.98.3 with SMTP id v3mr3817572agb.1182179257513;
        Mon, 18 Jun 2007 08:07:37 -0700 (PDT)
Received: from ?192.168.1.118? ( [67.181.218.96])
        by mx.google.com with ESMTP id 39sm8850400wrl.2007.06.18.08.07.36
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Mon, 18 Jun 2007 08:07:36 -0700 (PDT)
Message-ID: <46769FB5.4030108@gmail.com>
Date: Mon, 18 Jun 2007 08:07:33 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.0 (X11/20070326)
MIME-Version: 1.0
To: antone@geckotribe.com
CC: atom-syntax Syntax <atom-syntax@imc.org>
Subject: Re: Atom protocol and digital signatures
References: <tslr6oa9yls.fsf@mit.edu> <50F7EA57-A1BF-4243-BFEF-8AE82A49BBBB@sun.com> <F13E55EB-1A48-4CE6-B898-FF12980F3253@osafoundation.org> <46759EBF.3000604@gmail.com> <371C7E24-4395-4794-B2C5-5A11180910B0@osafoundation.org> <467622A9.80306@gmail.com> <C1A2E70E-3531-41C3-B34A-4C7843D45C67@Sun.COM> <4676936A.1080909@geckotribe.com>
In-Reply-To: <4676936A.1080909@geckotribe.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d




Antone Roundy wrote:
> 
> Yeah, I'm still lurking here.
> 
> First, let me state the obvious: a signature enables you to verify that
> the data you received hasn't been changed since it was signed by a
> particular entity.  It seems to me that there are a few things we might
> want to do with that ability:
> 
> [snip]
> 2) Verify that the data is as it was when produced by the original
> creator (would require preservation of the signature).
> 
> [snip]
> From what others have said, #2 doesn't sound possible.  #1 clearly is
> possible.  So what about #3?  Might something like this be done?
> 
> [snip]

#2 is possible so long as the server is implemented to do it.  The
client cannot make any blind assumptions about what the server will do.
 Before the client attempts to interact with the server, it had better
know what the server will do.

- James




From owner-atom-syntax@mail.imc.org Mon Jun 18 11:34:34 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0JFS-0005y5-Px
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 11:34:34 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0JFR-0005FD-3O
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 11:34:34 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5IFBdxO099901
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 18 Jun 2007 08:11:39 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5IFBd7O099900;
	Mon, 18 Jun 2007 08:11:39 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169])
	(authenticated bits=0)
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5IFBANV099824
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 18 Jun 2007 08:11:24 -0700 (MST)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: <p06240803c29c501fe09e@[10.20.30.108]>
In-Reply-To: <C1A2E70E-3531-41C3-B34A-4C7843D45C67@Sun.COM>
References: <tslr6oa9yls.fsf@mit.edu>
 <50F7EA57-A1BF-4243-BFEF-8AE82A49BBBB@sun.com>
 <F13E55EB-1A48-4CE6-B898-FF12980F3253@osafoundation.org>
 <46759EBF.3000604@gmail.com>
 <371C7E24-4395-4794-B2C5-5A11180910B0@osafoundation.org>
 <467622A9.80306@gmail.com> <C1A2E70E-3531-41C3-B34A-4C7843D45C67@Sun.COM>
Date: Mon, 18 Jun 2007 08:10:58 -0700
To: Tim Bray <Tim.Bray@Sun.COM>, Sam Hartman <hartmans-ietf@mit.edu>,
        atom-syntax Syntax <atom-syntax@imc.org>,
        Atom Publishing Protocol <atom-protocol@imc.org>,
        atompub-ads@tools.ietf.org
From: Paul Hoffman <phoffman@imc.org>
Subject: Re: Atom protocol and digital signatures
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f


At 11:34 PM -0700 6/17/07, Tim Bray wrote:
>The more I think about this, the more the right answer seems 
>obvious.  The notion of a client signing a whole Atom entry is just 
>fundamentally bogus, because some parts of it are actually owned by 
>the server (id, update-timestamp).

Given some of the other comments in this thread, I disagree. A server 
might want to only accept a signed entry in order to be sure that the 
content was generated by someone the server trusts. This can be 
orthogonal to the authentication used in order to post to the server.

>Expand 15.5 to point out all the problems that have emerged in this 
>discussion and which make client-originated dig-sig a non-starter 
>for  APP.

Disagree; see above.




From owner-atom-syntax@mail.imc.org Mon Jun 18 12:18:33 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0Jw1-00043N-Nz
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 12:18:33 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0Jw1-0006VP-9e
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 12:18:33 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5IFteUk005092
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 18 Jun 2007 08:55:40 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5IFteNX005091;
	Mon, 18 Jun 2007 08:55:40 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.226])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5IFtdn3005075
	for <atom-syntax@imc.org>; Mon, 18 Jun 2007 08:55:39 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by wx-out-0506.google.com with SMTP id s16so1428309wxc
        for <atom-syntax@imc.org>; Mon, 18 Jun 2007 08:55:38 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed;
        d=gmail.com; s=beta;
        h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=Pqy9x7w/qC/Lez5znsB9WAldAqIOtLrjDQgfVHK1swK29/8xMUOjkzct8Ff5mDe378GGRmZIqLbph55RArjWBQc4UApyZwPibos3b7zW1DXFCXHbWFHD+VvZnV3JhbhvoFFzq5gGPtdOKWjAH296CiqmZIG5RmtWnB1aft6X27Q=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=OXsGh47cY0E90Uflec3Mf7RC5RSLPG5fXCAYW/NII7aBQ7t6ntpnxLc5ocAQnqt++aaVTuLyWZXuxPpiAioVs92AK7GtllNotjADE8sIBL/RdrstU+1ftUlOyiY6CRjc09q8WIPN53WgHG09zYOFYEPhKIM0bbr4FjwDvzKftF4=
Received: by 10.90.89.5 with SMTP id m5mr3902983agb.1182182138830;
        Mon, 18 Jun 2007 08:55:38 -0700 (PDT)
Received: from ?192.168.1.118? ( [67.181.218.96])
        by mx.google.com with ESMTP id 11sm8949585wrl.2007.06.18.08.55.37
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Mon, 18 Jun 2007 08:55:38 -0700 (PDT)
Message-ID: <4676AAF5.2030002@gmail.com>
Date: Mon, 18 Jun 2007 08:55:33 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.0 (X11/20070326)
MIME-Version: 1.0
To: Tim Bray <Tim.Bray@Sun.COM>
CC: Sam Hartman <hartmans-ietf@mit.edu>,
        atom-syntax Syntax <atom-syntax@imc.org>,
        Atom Publishing Protocol <atom-protocol@imc.org>,
        atompub-ads@tools.ietf.org
Subject: Re: Atom protocol and digital signatures
References: <tslr6oa9yls.fsf@mit.edu> <50F7EA57-A1BF-4243-BFEF-8AE82A49BBBB@sun.com> <F13E55EB-1A48-4CE6-B898-FF12980F3253@osafoundation.org> <46759EBF.3000604@gmail.com> <371C7E24-4395-4794-B2C5-5A11180910B0@osafoundation.org> <467622A9.80306@gmail.com> <C1A2E70E-3531-41C3-B34A-4C7843D45C67@Sun.COM>
In-Reply-To: <C1A2E70E-3531-41C3-B34A-4C7843D45C67@Sun.COM>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.6 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0


This is very rough but is this at least a step in the right direction?

15.5.  Digital Signatures and Encryption

   Atom Entry and Feed Documents might contain XML Digital Signatures
   [REC-xmldsig-core] and might be encrypted using XML Encryption
   [REC-xmlenc-core] as specified in Section 5 of [RFC4287].

   When servers or clients receive digitally signed or encrypted Entry
   Documents, they are under no obligation to preserve the integrity of
   the signatures or the encryption. They are allowed to modify member
   resources in ways that can invalidate signatures.  If such
   modifications are made, it is recommended that any invalid signatures
   be removed.

   A server can require that Entry Documents received from a client,
   either via POST or PUT, be digitally signed with a valid
   signature or are encrypted, or both.  How such requirements are
   communicated to the client are considered out of scope for this
   specification.

   Signatures and encrypted elements are considered to be foreign markup
   within an Atom document and are required to be handled according to
   the rules specified in Sections 5 and 6.3 of [RFC4287].

- James

Tim Bray wrote:
> 
> The more I think about this, the more the right answer seems obvious. 
> The notion of a client signing a whole Atom entry is just fundamentally
> bogus, because some parts of it are actually owned by the server (id,
> update-timestamp).  On the other hand, the notion of a client signing
> the payload (title/author/categories/summary/content) is interesting and
> worth exploring.  Fortunately, Atom & APP are flexible enough that
> anyone can try a few things out without breaking any implementations. 
> Unfortunately, nobody has ever implemented anything like this that I
> know of, and I don't even know of any applications that need it, so
> it''s *way* too early to try to specify The Right Thing To Do.
> 
> So.... I would address Sam's points like so:
> 
> Expand 15.5 to point out all the problems that have emerged in this
> discussion and which make client-originated dig-sig a non-starter for
> APP.  Further point out that server-side dig-sig, per RFC4287 rules,
> might make all sorts of sense in certain apps and is perfectly
> technically feasible; I now think it's a bug that the spec leaves you
> with the impression that something about server-side digsig might not
> work.  Further point out that signature elements can freely be inserted
> in to-be-posted entries by clients and are guaranteed not to break the
> server because of our MustIgnore rule, and make it clear that the door
> is open to payload signing.
> 
> The idea is that down the road, when there's a body of experience and we
> know what the Best Practices are, someone can spec an APP Extension to
> capture them.  -Tim
> 
> 




From owner-atom-syntax@mail.imc.org Mon Jun 18 12:18:58 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0JwQ-0004F6-T2
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 12:18:58 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0JwP-0006Zb-Ew
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 12:18:58 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5IFnq5j004533
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 18 Jun 2007 08:49:52 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5IFnqa0004532;
	Mon, 18 Jun 2007 08:49:52 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5IFnnZI004510;
	Mon, 18 Jun 2007 08:49:50 -0700 (MST)
	(envelope-from Tim.Bray@Sun.COM)
Received: from fe-amer-09.sun.com ([192.18.108.183])
	by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5IFnnve014888;
	Mon, 18 Jun 2007 15:49:49 GMT
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 id <0JJU00G018XJ0F00@mail-amer.sun.com> (original mail from Tim.Bray@Sun.COM)
 ; Mon, 18 Jun 2007 09:49:49 -0600 (MDT)
Received: from [192.168.1.56] (fatwire-35-165.uniserve.ca [204.174.35.214])
 by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 with ESMTPSA id <0JJU005C69AIDD10@mail-amer.sun.com>; Mon,
 18 Jun 2007 09:49:31 -0600 (MDT)
Date: Mon, 18 Jun 2007 08:49:02 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Atom protocol and digital signatures
In-reply-to: <p06240803c29c501fe09e@[10.20.30.108]>
To: Paul Hoffman <phoffman@imc.org>
Cc: Sam Hartman <hartmans-ietf@mit.edu>,
        atom-syntax Syntax <atom-syntax@imc.org>,
        Atom Publishing Protocol <atom-protocol@imc.org>,
        atompub-ads@tools.ietf.org
Message-id: <1C122502-8542-4B25-8A18-87BD2E5A4D3C@Sun.COM>
MIME-version: 1.0
X-Mailer: Apple Mail (2.752.3)
Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII
Content-transfer-encoding: 7BIT
References: <tslr6oa9yls.fsf@mit.edu>
 <50F7EA57-A1BF-4243-BFEF-8AE82A49BBBB@sun.com>
 <F13E55EB-1A48-4CE6-B898-FF12980F3253@osafoundation.org>
 <46759EBF.3000604@gmail.com>
 <371C7E24-4395-4794-B2C5-5A11180910B0@osafoundation.org>
 <467622A9.80306@gmail.com> <C1A2E70E-3531-41C3-B34A-4C7843D45C67@Sun.COM>
 <p06240803c29c501fe09e@[10.20.30.108]>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a


On Jun 18, 2007, at 8:10 AM, Paul Hoffman wrote:

> At 11:34 PM -0700 6/17/07, Tim Bray wrote:
>> The more I think about this, the more the right answer seems  
>> obvious.  The notion of a client signing a whole Atom entry is  
>> just fundamentally bogus, because some parts of it are actually  
>> owned by the server (id, update-timestamp).
>
> Given some of the other comments in this thread, I disagree. A  
> server might want to only accept a signed entry in order to be sure  
> that the content was generated by someone the server trusts. This  
> can be orthogonal to the authentication used in order to post to  
> the server.

OK, let me re-phrase slightly.  The idea of a client expecting a  
digital signature on a whole entry to survive the publishing process  
is bogus.

>> Expand 15.5 to point out all the problems that have emerged in  
>> this discussion and which make client-originated dig-sig a non- 
>> starter for  APP.
>
> Disagree; see above.

I think that most of what I wanted to put in makes sense; time to  
stop hand-waving and draft some language.  -Tim






From owner-atom-syntax@mail.imc.org Mon Jun 18 12:39:37 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0KGO-0003mE-Si
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 12:39:37 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0KGM-0002fb-C6
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 12:39:36 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5IGGNjc008081
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 18 Jun 2007 09:16:23 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5IGGNbL008078;
	Mon, 18 Jun 2007 09:16:23 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5IGGLAY008054
	for <atom-syntax@imc.org>; Mon, 18 Jun 2007 09:16:22 -0700 (MST)
	(envelope-from derhoermi@gmx.net)
Received: (qmail invoked by alias); 18 Jun 2007 16:16:20 -0000
Received: from dslb-084-056-221-118.pools.arcor-ip.net (EHLO hive) [84.56.221.118]
  by mail.gmx.net (mp054) with SMTP; 18 Jun 2007 18:16:20 +0200
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX1+S3DFBwyiSfDGEzRXESjwvmyJuuaxga8/hPlp0zo
	+JVqz7/+SwHaSN
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: James M Snell <jasnell@gmail.com>
Cc: atom-syntax Syntax <atom-syntax@imc.org>,
        Atom Publishing Protocol <atom-protocol@imc.org>,
        atompub-ads@tools.ietf.org
Subject: Re: Atom protocol and digital signatures
Date: Mon, 18 Jun 2007 18:16:15 +0200
Message-ID: <6abd7357pvdadgbe4oc057m4fl8mjea1a2@hive.bjoern.hoehrmann.de>
References: <tslr6oa9yls.fsf@mit.edu> <50F7EA57-A1BF-4243-BFEF-8AE82A49BBBB@sun.com> <F13E55EB-1A48-4CE6-B898-FF12980F3253@osafoundation.org> <46759EBF.3000604@gmail.com> <371C7E24-4395-4794-B2C5-5A11180910B0@osafoundation.org> <467622A9.80306@gmail.com> <C1A2E70E-3531-41C3-B34A-4C7843D45C67@Sun.COM> <4676AAF5.2030002@gmail.com>
In-Reply-To: <4676AAF5.2030002@gmail.com>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
X-Y-GMX-Trusted: 0
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id l5IGGNjc008081
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1


* James M Snell wrote:
>   When servers or clients receive digitally signed or encrypted Entry
>   Documents, they are under no obligation to preserve the integrity of
>   the signatures or the encryption. They are allowed to modify member
>   resources in ways that can invalidate signatures.  If such
>   modifications are made, it is recommended that any invalid signatures
>   be removed.

This should be "Servers should remove invalidated signatures". However,
this may give the false impression that support for signatures is re-
quired, and does not address what to do if the server does not know if
a signature has been invalidated. The phrasing of "the integrity of the
signatures or the encryption" is also easily misread.

>   A server can require that Entry Documents received from a client,
>   either via POST or PUT, be digitally signed with a valid
>   signature or are encrypted, or both.  How such requirements are
>   communicated to the client are considered out of scope for this
>   specification.

s/are con/is con/.

>   Signatures and encrypted elements are considered to be foreign markup
>   within an Atom document and are required to be handled according to
>   the rules specified in Sections 5 and 6.3 of [RFC4287].

I don't think it's useful to repeat this information here, "Handling of
signatures and encrypted elements in Atom documents is discussed in
sections 5 and 6.3 of [RFC4287]" would be better.
--=20
Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehr=
mann.de
Weinh. Str. 22 =B7 Telefon: +49(0)621/4309674 =B7 http://www.bjoernsworld=
.de
68309 Mannheim =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev.d=
e/=20




From owner-atom-syntax@mail.imc.org Mon Jun 18 13:11:58 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0Kli-0004my-Nf
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 13:11:58 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1I0KlS-0003DV-T1
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 13:11:58 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5IGhSca012055
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 18 Jun 2007 09:43:28 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5IGhSsV012054;
	Mon, 18 Jun 2007 09:43:28 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.233])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5IGhR90012047
	for <atom-syntax@imc.org>; Mon, 18 Jun 2007 09:43:27 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by wx-out-0506.google.com with SMTP id s16so1442583wxc
        for <atom-syntax@imc.org>; Mon, 18 Jun 2007 09:43:25 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed;
        d=gmail.com; s=beta;
        h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=AeAqGQC78pzql0dJI5uStsiOvUu0yZJNmF1/9aJRV8P1+M89xXL1N8S9MCC0zbOTMQaM+aOvw/j/JoRceLx+btJSTshNw50x5VtXLb6y5y4QZsP5E2fcZ33c0e3WZI1WtArBbagBSXPnxMepIdlYNZMxnjBuZ5njbUmVBUnePmg=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=Q22UvRCGspitg85qpF5mJf+Bf5OM2mywwAcjgUv3b6JvB7IwCrITzDHgdwNKADof9P5vkN+ruCDuwu6nV+9zvgLYJIGyPyTxGORWP6RwaLxsRfocE9PYjEwFge2E1nvYzfDCMIuzw92f0tpmajM6yetGudYDdgpfGWUDv0mErjs=
Received: by 10.90.29.18 with SMTP id c18mr3986095agc.1182185005090;
        Mon, 18 Jun 2007 09:43:25 -0700 (PDT)
Received: from ?192.168.1.118? ( [67.181.218.96])
        by mx.google.com with ESMTP id 6sm8028302wrh.2007.06.18.09.43.23
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Mon, 18 Jun 2007 09:43:24 -0700 (PDT)
Message-ID: <4676B629.9070303@gmail.com>
Date: Mon, 18 Jun 2007 09:43:21 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.0 (X11/20070326)
MIME-Version: 1.0
To: Bjoern Hoehrmann <derhoermi@gmx.net>
CC: atom-syntax Syntax <atom-syntax@imc.org>,
        Atom Publishing Protocol <atom-protocol@imc.org>,
        atompub-ads@tools.ietf.org
Subject: Re: Atom protocol and digital signatures
References: <tslr6oa9yls.fsf@mit.edu> <50F7EA57-A1BF-4243-BFEF-8AE82A49BBBB@sun.com> <F13E55EB-1A48-4CE6-B898-FF12980F3253@osafoundation.org> <46759EBF.3000604@gmail.com> <371C7E24-4395-4794-B2C5-5A11180910B0@osafoundation.org> <467622A9.80306@gmail.com> <C1A2E70E-3531-41C3-B34A-4C7843D45C67@Sun.COM> <4676AAF5.2030002@gmail.com> <6abd7357pvdadgbe4oc057m4fl8mjea1a2@hive.bjoern.hoehrmann.de>
In-Reply-To: <6abd7357pvdadgbe4oc057m4fl8mjea1a2@hive.bjoern.hoehrmann.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8


Slightly better?

15.5.  Digital Signatures and Encryption

   Atom Entry and Feed Documents might contain XML Digital Signatures
   [REC-xmldsig-core] and might be encrypted using XML Encryption
   [REC-xmlenc-core] as specified in Section 5 of [RFC4287]. Handling of
   signatures and encrypted elements in Atom documents is discussed in
   sections 5 and 6.3 of [RFC4287].

   When servers or clients receive digitally signed or encrypted Entry
   Documents, they are under no obligation to preserve signatures or
   encrypted elements. They are allowed to modify member resources in
   ways that can invalidate signatures.  If such modifications are made,
   it is strongly recommended that invalid signatures be removed.

   A server can require that Entry Documents received from a client,
   either via POST or PUT, be digitally signed with a valid
   signature or are encrypted, or both.  How such requirements are
   communicated to the client is considered out of scope for this
   specification.

- James


Bjoern Hoehrmann wrote:
> * James M Snell wrote:
>>   When servers or clients receive digitally signed or encrypted Entry
>>   Documents, they are under no obligation to preserve the integrity of
>>   the signatures or the encryption. They are allowed to modify member
>>   resources in ways that can invalidate signatures.  If such
>>   modifications are made, it is recommended that any invalid signatures
>>   be removed.
> 
> This should be "Servers should remove invalidated signatures". However,
> this may give the false impression that support for signatures is re-
> quired, and does not address what to do if the server does not know if
> a signature has been invalidated. The phrasing of "the integrity of the
> signatures or the encryption" is also easily misread.
> 
>>   A server can require that Entry Documents received from a client,
>>   either via POST or PUT, be digitally signed with a valid
>>   signature or are encrypted, or both.  How such requirements are
>>   communicated to the client are considered out of scope for this
>>   specification.
> 
> s/are con/is con/.
> 
>>   Signatures and encrypted elements are considered to be foreign markup
>>   within an Atom document and are required to be handled according to
>>   the rules specified in Sections 5 and 6.3 of [RFC4287].
> 
> I don't think it's useful to repeat this information here, "Handling of
> signatures and encrypted elements in Atom documents is discussed in
> sections 5 and 6.3 of [RFC4287]" would be better.




From owner-atom-syntax@mail.imc.org Mon Jun 18 13:13:36 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0KnI-00051K-Hr
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 13:13:36 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0KnI-0003ud-4h
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 13:13:36 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5IGqg4k013157
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 18 Jun 2007 09:52:42 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5IGqgHo013156;
	Mon, 18 Jun 2007 09:52:42 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5IGqegs013141;
	Mon, 18 Jun 2007 09:52:41 -0700 (MST)
	(envelope-from lisa@osafoundation.org)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1])
	by laweleka.osafoundation.org (Postfix) with ESMTP id 99B99142295;
	Mon, 18 Jun 2007 09:52:40 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
Received: from laweleka.osafoundation.org ([127.0.0.1])
	by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id sR12NnRqRm0F; Mon, 18 Jun 2007 09:52:39 -0700 (PDT)
Received: from [192.168.1.100] (unknown [74.95.2.169])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(No client certificate requested)
	by laweleka.osafoundation.org (Postfix) with ESMTP id 920CE142277;
	Mon, 18 Jun 2007 09:52:38 -0700 (PDT)
In-Reply-To: <6abd7357pvdadgbe4oc057m4fl8mjea1a2@hive.bjoern.hoehrmann.de>
References: <tslr6oa9yls.fsf@mit.edu> <50F7EA57-A1BF-4243-BFEF-8AE82A49BBBB@sun.com> <F13E55EB-1A48-4CE6-B898-FF12980F3253@osafoundation.org> <46759EBF.3000604@gmail.com> <371C7E24-4395-4794-B2C5-5A11180910B0@osafoundation.org> <467622A9.80306@gmail.com> <C1A2E70E-3531-41C3-B34A-4C7843D45C67@Sun.COM> <4676AAF5.2030002@gmail.com> <6abd7357pvdadgbe4oc057m4fl8mjea1a2@hive.bjoern.hoehrmann.de>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: multipart/alternative; boundary=Apple-Mail-92--132594327
Message-Id: <79636DA8-CE7F-433A-906B-BD5ED6A1DCF9@osafoundation.org>
Cc: James M Snell <jasnell@gmail.com>,
        atom-syntax Syntax <atom-syntax@imc.org>,
        Atom Publishing Protocol <atom-protocol@imc.org>,
        atompub-ads@tools.ietf.org
From: Lisa Dusseault <lisa@osafoundation.org>
Subject: Re: Atom protocol and digital signatures
Date: Mon, 18 Jun 2007 09:52:32 -0700
To: Bjoern Hoehrmann <derhoermi@gmx.net>
X-Mailer: Apple Mail (2.752.3)
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab



--Apple-Mail-92--132594327
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed


On Jun 18, 2007, at 9:16 AM, Bjoern Hoehrmann wrote:

> This should be "Servers should remove invalidated signatures".  
> However,
> this may give the false impression that support for signatures is re-
> quired, and does not address what to do if the server does not know if
> a signature has been invalidated.


If there's any doubt about whether support for signatures is required  
-- James says yes, and Bjoern says no -- we need to be clearer in the  
publishing protocol document.

Otherwise, a server implementor could decide that "since I don't sign  
entries I don't need any code to handle signatures".

Lisa
--Apple-Mail-92--132594327
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><BR><DIV><DIV>On Jun 18, 2007, =
at 9:16 AM, Bjoern Hoehrmann wrote:</DIV><BR =
class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite"><P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">This should be "Servers =
should remove invalidated signatures". However,</FONT></P> <P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">this may give the false =
impression that support for signatures is re-</FONT></P> <P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">quired, and does not address =
what to do if the server does not know if</FONT></P> <P style=3D"margin: =
0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica">a signature has been =
invalidated.</FONT></P> </BLOCKQUOTE></DIV><BR><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>If there's any doubt about =
whether support for signatures is required -- James says yes, and Bjoern =
says no -- we need to be clearer in the publishing protocol =
document.=A0=A0</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Otherwise, a server =
implementor could decide that "since I don't sign entries I don't need =
any code to handle signatures".</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Lisa</DIV></BODY></HTML>=

--Apple-Mail-92--132594327--




From owner-atom-syntax@mail.imc.org Mon Jun 18 14:03:18 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0LZO-0000ts-Mm
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 14:03:18 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0LZM-00006q-34
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 14:03:18 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5IHYdbb002214
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 18 Jun 2007 10:34:39 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5IHYcse002210;
	Mon, 18 Jun 2007 10:34:38 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5IHYaxb002154
	for <atom-syntax@imc.org>; Mon, 18 Jun 2007 10:34:37 -0700 (MST)
	(envelope-from derhoermi@gmx.net)
Received: (qmail invoked by alias); 18 Jun 2007 17:28:17 -0000
Received: from dslb-084-056-221-118.pools.arcor-ip.net (EHLO hive) [84.56.221.118]
  by mail.gmx.net (mp003) with SMTP; 18 Jun 2007 19:28:17 +0200
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX1/p9MESBGHpRLyFQA/tswRxAJ36KHNHG1hYiERmWd
	eXY8C9OQSUilTA
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: atom-syntax Syntax <atom-syntax@imc.org>,
        Atom Publishing Protocol <atom-protocol@imc.org>
Subject: Re: Atom protocol and digital signatures
Date: Mon, 18 Jun 2007 19:28:11 +0200
Message-ID: <4rfd73d2eqpq9t3iqobu1i1u6ppujj43ka@hive.bjoern.hoehrmann.de>
References: <tslr6oa9yls.fsf@mit.edu> <50F7EA57-A1BF-4243-BFEF-8AE82A49BBBB@sun.com> <F13E55EB-1A48-4CE6-B898-FF12980F3253@osafoundation.org> <46759EBF.3000604@gmail.com> <371C7E24-4395-4794-B2C5-5A11180910B0@osafoundation.org> <467622A9.80306@gmail.com> <C1A2E70E-3531-41C3-B34A-4C7843D45C67@Sun.COM> <4676AAF5.2030002@gmail.com> <6abd7357pvdadgbe4oc057m4fl8mjea1a2@hive.bjoern.hoehrmann.de> <79636DA8-CE7F-433A-906B-BD5ED6A1DCF9@osafoundation.org> <4676BEF3.4010104@gmx.de>
In-Reply-To: <4676BEF3.4010104@gmx.de>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
X-Y-GMX-Trusted: 0
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id l5IHYdbb002214
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370


* Julian Reschke wrote:
>As far as I can tell, APP doesn't require support for signatures, nor=20
>did James say so (pointer?).

The text said that servers SHOULD remove invalidated signatures. You can
not do that unless you can determine that a signature has indeed been
invalidated and know how to remove such a signature. So support would be
required unless <rfc 2119 exceptions>.
--=20
Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehr=
mann.de
Weinh. Str. 22 =B7 Telefon: +49(0)621/4309674 =B7 http://www.bjoernsworld=
.de
68309 Mannheim =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev.d=
e/=20




From owner-atom-syntax@mail.imc.org Mon Jun 18 14:27:40 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0Lwy-0000LP-3s
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 14:27:40 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0Lww-0008J5-Ox
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 14:27:40 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5IHw0H5006303
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 18 Jun 2007 10:58:00 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5IHw0ga006302;
	Mon, 18 Jun 2007 10:58:00 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [10.20.30.108] (adsl-66-125-125-71.dsl.pltn13.pacbell.net [66.125.125.71])
	(authenticated bits=0)
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5IHvi01006261
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 18 Jun 2007 10:57:45 -0700 (MST)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: <p0624080ec29c773d5909@[10.20.30.108]>
In-Reply-To: <4676B629.9070303@gmail.com>
References: <tslr6oa9yls.fsf@mit.edu>
 <50F7EA57-A1BF-4243-BFEF-8AE82A49BBBB@sun.com>
 <F13E55EB-1A48-4CE6-B898-FF12980F3253@osafoundation.org>
 <46759EBF.3000604@gmail.com>
 <371C7E24-4395-4794-B2C5-5A11180910B0@osafoundation.org>
 <467622A9.80306@gmail.com> <C1A2E70E-3531-41C3-B34A-4C7843D45C67@Sun.COM>
 <4676AAF5.2030002@gmail.com>
 <6abd7357pvdadgbe4oc057m4fl8mjea1a2@hive.bjoern.hoehrmann.de>
 <4676B629.9070303@gmail.com>
Date: Mon, 18 Jun 2007 10:57:33 -0700
To: James M Snell <jasnell@gmail.com>, Bjoern Hoehrmann <derhoermi@gmx.net>
From: Paul Hoffman <phoffman@imc.org>
Subject: Re: Atom protocol and digital signatures
Cc: atom-syntax Syntax <atom-syntax@imc.org>,
        Atom Publishing Protocol <atom-protocol@imc.org>,
        atompub-ads@tools.ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89


At 9:43 AM -0700 6/18/07, James M Snell wrote:
>    If such modifications are made,
>    it is strongly recommended that invalid signatures be removed.

We have gone out of our way in APP not to tell servers what to do 
with received content. Why should we start here? Also, why should a 
server have to figure out whether the content was changed?

Can this sentence be removed?




From owner-atom-syntax@mail.imc.org Mon Jun 18 14:29:57 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0LzB-0001FX-ER
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 14:29:57 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0LzA-0000le-1B
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 14:29:57 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5II2ru8007127
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 18 Jun 2007 11:02:53 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5II2rlr007126;
	Mon, 18 Jun 2007 11:02:53 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.232])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5II2oE0007096
	for <atom-syntax@imc.org>; Mon, 18 Jun 2007 11:02:52 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by wx-out-0506.google.com with SMTP id s16so1465242wxc
        for <atom-syntax@imc.org>; Mon, 18 Jun 2007 11:02:48 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed;
        d=gmail.com; s=beta;
        h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=f+ufrCl+QMCNE7mMXVuAwJFc+3DIdmMp59vcVr4CLVllLA/7vFaa7/f2ghwGvSmP2yIIYut3Dweu5vi9MDg4VFbjjAjt0n1jyrx0CNjS5rIaZbDXKCyCDsRvXLEHuOczgjSz4vQ5s3cpHxfSWUi8nQBwr1hEIAYb5+FhhVBW/+w=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=DFkK3ftzslVUtZ1Z0qoFC0PYoBZ3opMVLawY9YJopdpjFyFUI2CC93NYOw9976/9y/wQzUwUca5xbLZ35TIgmJKLWdfxag3wz8ci6SpI7ECdL1EigNrrGq5ROKmMUrTO679oTuXJfakGsBNZgYNuBMllliMpONlenOo9FTepW64=
Received: by 10.90.29.18 with SMTP id c18mr4144807agc.1182189767918;
        Mon, 18 Jun 2007 11:02:47 -0700 (PDT)
Received: from ?192.168.1.118? ( [67.181.218.96])
        by mx.google.com with ESMTP id 74sm9085615wra.2007.06.18.11.02.45
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Mon, 18 Jun 2007 11:02:47 -0700 (PDT)
Message-ID: <4676C8C2.2010204@gmail.com>
Date: Mon, 18 Jun 2007 11:02:42 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.0 (X11/20070326)
MIME-Version: 1.0
To: Paul Hoffman <phoffman@imc.org>
CC: Bjoern Hoehrmann <derhoermi@gmx.net>,
        atom-syntax Syntax <atom-syntax@imc.org>,
        Atom Publishing Protocol <atom-protocol@imc.org>,
        atompub-ads@tools.ietf.org
Subject: Re: Atom protocol and digital signatures
References: <tslr6oa9yls.fsf@mit.edu> <50F7EA57-A1BF-4243-BFEF-8AE82A49BBBB@sun.com> <F13E55EB-1A48-4CE6-B898-FF12980F3253@osafoundation.org> <46759EBF.3000604@gmail.com> <371C7E24-4395-4794-B2C5-5A11180910B0@osafoundation.org> <467622A9.80306@gmail.com> <C1A2E70E-3531-41C3-B34A-4C7843D45C67@Sun.COM> <4676AAF5.2030002@gmail.com> <6abd7357pvdadgbe4oc057m4fl8mjea1a2@hive.bjoern.hoehrmann.de> <4676B629.9070303@gmail.com> <p0624080ec29c773d5909@[10.20.30.108]>
In-Reply-To: <p0624080ec29c773d5909@[10.20.30.108]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370


I've got no problem with that.

- James

Paul Hoffman wrote:
> At 9:43 AM -0700 6/18/07, James M Snell wrote:
>>    If such modifications are made,
>>    it is strongly recommended that invalid signatures be removed.
> 
> We have gone out of our way in APP not to tell servers what to do with
> received content. Why should we start here? Also, why should a server
> have to figure out whether the content was changed?
> 
> Can this sentence be removed?
> 




From owner-atom-syntax@mail.imc.org Mon Jun 18 14:35:22 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0M4Q-0002oi-Bb
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 14:35:22 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0M4M-0001sZ-Rp
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 14:35:22 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5IIDtka009088
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 18 Jun 2007 11:13:56 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5IIDtW8009086;
	Mon, 18 Jun 2007 11:13:55 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5IIDrjF009060
	for <atom-syntax@imc.org>; Mon, 18 Jun 2007 11:13:54 -0700 (MST)
	(envelope-from derhoermi@gmx.net)
Received: (qmail invoked by alias); 18 Jun 2007 18:13:53 -0000
Received: from dslb-084-056-221-118.pools.arcor-ip.net (EHLO hive) [84.56.221.118]
  by mail.gmx.net (mp051) with SMTP; 18 Jun 2007 20:13:53 +0200
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX1+6PCkJdC+6hOTwK3LeBiHF6lOQ3qz+wDpgVK83y+
	541f1iovNUxxnD
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Paul Hoffman <phoffman@imc.org>
Cc: atom-syntax Syntax <atom-syntax@imc.org>,
        Atom Publishing Protocol <atom-protocol@imc.org>,
        atompub-ads@tools.ietf.org
Subject: Re: Atom protocol and digital signatures
Date: Mon, 18 Jun 2007 20:13:48 +0200
Message-ID: <8bid73db8mpev18vrj3kqvtav1r5ich9pd@hive.bjoern.hoehrmann.de>
References: <tslr6oa9yls.fsf@mit.edu> <50F7EA57-A1BF-4243-BFEF-8AE82A49BBBB@sun.com> <F13E55EB-1A48-4CE6-B898-FF12980F3253@osafoundation.org> <46759EBF.3000604@gmail.com> <371C7E24-4395-4794-B2C5-5A11180910B0@osafoundation.org> <467622A9.80306@gmail.com> <C1A2E70E-3531-41C3-B34A-4C7843D45C67@Sun.COM> <4676AAF5.2030002@gmail.com> <6abd7357pvdadgbe4oc057m4fl8mjea1a2@hive.bjoern.hoehrmann.de> <4676B629.9070303@gmail.com> <p0624080ec29c773d5909@[10.20.30.108]>
In-Reply-To: <p0624080ec29c773d5909@[10.20.30.108]>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
X-Y-GMX-Trusted: 0
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id l5IIDtka009088
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3


* Paul Hoffman wrote:
>We have gone out of our way in APP not to tell servers what to do=20
>with received content. Why should we start here? Also, why should a=20
>server have to figure out whether the content was changed?

I am not sure I understand the second question. If the server receives a
signed document and does not modify the document there is no problem. If
it does modify it, then it knows the content has been changed. The first
question is easy to answer, if you have neither of

  * clients don't send signed documents unless server supports them
  * servers don't keep signatures unless they don't modify documents

as policy, a client might optimistically send a signed document and the
server ends up serving documents with invalidated signatures. That'd be
bad as recieving clients would give false alarms, reducing the overall
utility of digital signatures.
--=20
Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehr=
mann.de
Weinh. Str. 22 =B7 Telefon: +49(0)621/4309674 =B7 http://www.bjoernsworld=
.de
68309 Mannheim =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev.d=
e/=20




From owner-atom-syntax@mail.imc.org Mon Jun 18 14:53:26 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0MLu-0005t0-RG
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 14:53:26 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0MLt-0007tq-EW
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 14:53:26 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5IHL7eL017093
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 18 Jun 2007 10:21:07 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5IHL763017092;
	Mon, 18 Jun 2007 10:21:07 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5IHL2cv017070
	for <atom-syntax@imc.org>; Mon, 18 Jun 2007 10:21:05 -0700 (MST)
	(envelope-from julian.reschke@gmx.de)
Received: (qmail invoked by alias); 18 Jun 2007 17:21:02 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.87]) [217.91.35.233]
  by mail.gmx.net (mp052) with SMTP; 18 Jun 2007 19:21:02 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX19Bx0hTdblB72Lug70Hw0dGsnALXHRuZ/7IwHR3YE
	1IRYMiDiAZLjrC
Message-ID: <4676BEF3.4010104@gmx.de>
Date: Mon, 18 Jun 2007 19:20:51 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
CC: Bjoern Hoehrmann <derhoermi@gmx.net>, James M Snell <jasnell@gmail.com>,
        atom-syntax Syntax <atom-syntax@imc.org>,
        Atom Publishing Protocol <atom-protocol@imc.org>,
        atompub-ads@tools.ietf.org
Subject: Re: Atom protocol and digital signatures
References: <tslr6oa9yls.fsf@mit.edu> <50F7EA57-A1BF-4243-BFEF-8AE82A49BBBB@sun.com> <F13E55EB-1A48-4CE6-B898-FF12980F3253@osafoundation.org> <46759EBF.3000604@gmail.com> <371C7E24-4395-4794-B2C5-5A11180910B0@osafoundation.org> <467622A9.80306@gmail.com> <C1A2E70E-3531-41C3-B34A-4C7843D45C67@Sun.COM> <4676AAF5.2030002@gmail.com> <6abd7357pvdadgbe4oc057m4fl8mjea1a2@hive.bjoern.hoehrmann.de> <79636DA8-CE7F-433A-906B-BD5ED6A1DCF9@osafoundation.org>
In-Reply-To: <79636DA8-CE7F-433A-906B-BD5ED6A1DCF9@osafoundation.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32


Lisa Dusseault wrote:
> 
> On Jun 18, 2007, at 9:16 AM, Bjoern Hoehrmann wrote:
> 
>> This should be "Servers should remove invalidated signatures". However,
>>
>> this may give the false impression that support for signatures is re-
>>
>> quired, and does not address what to do if the server does not know if
>>
>> a signature has been invalidated.
>>
> 
> 
> If there's any doubt about whether support for signatures is required -- 
> James says yes, and Bjoern says no -- we need to be clearer in the 
> publishing protocol document.  
> ...

As far as I can tell, APP doesn't require support for signatures, nor 
did James say so (pointer?).

Best regards, Julian




From owner-atom-syntax@mail.imc.org Mon Jun 18 15:09:52 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0Mbo-0004uG-AC
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 15:09:52 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0Mbm-0004TS-U5
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 15:09:52 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5IIfi4e013876
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 18 Jun 2007 11:41:44 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5IIfijw013874;
	Mon, 18 Jun 2007 11:41:44 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.rfburst.com (mail.rfburst.com [66.119.143.52] (may be forged))
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5IIfgbo013852
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 18 Jun 2007 11:41:43 -0700 (MST)
Received: from purplestreak.com (customer.radioburst.com [66.119.135.195] (may be forged))
	by mail.rfburst.com (8.12.11.20060308/8.12.11) with ESMTP id l5IIfYiQ015156;
	Mon, 18 Jun 2007 12:41:37 -0600
Received: from localhost.localdomain (tobermory [127.0.0.1])
	by purplestreak.com (8.12.10/8.11.6) with ESMTP id l5IIeiPb020036;
	Mon, 18 Jun 2007 12:40:44 -0600
Received: (from ho@localhost)
	by localhost.localdomain (8.12.10/8.12.10/Submit) id l5IIeiTT020032;
	Mon, 18 Jun 2007 12:40:44 -0600
Date: Mon, 18 Jun 2007 12:40:44 -0600
Message-Id: <200706181840.l5IIeiTT020032@localhost.localdomain>
From: "Hilarie Orman" <ho@alum.mit.edu>
Reply-To: "Hilarie Orman" <ho@alum.mit.edu>
To: atom-protocol@imc.org, atom-syntax@imc.org
In-reply-to: Yourmessage <4rfd73d2eqpq9t3iqobu1i1u6ppujj43ka@hive.bjoern.hoehrmann.de>
Subject: Re: Atom protocol and digital signatures
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mail.rfburst.com [66.119.143.53]); Mon, 18 Jun 2007 12:41:37 -0600 (MDT)
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a


The client can use signatures for two purposes: to convince the server
that the data is authentic, and/or to convince a third-party that the data*
is authentic.  In the first case, the "data" might be considered to be
the entirety of the message/entry/etc.  In the second case, the
"data*" might be a subset of the "data".  So, one could envision
something like

  SIG1 = DSIG(Kclient, some_data | data* | some_more_data)  
  SIG2 = DSIG(Kclient, data*)

The server may want to use its own signature for what it publishes,
so it might publish

  SIG3 = DSIG(Kserver, modified(some_data, some_more_data))
but it might also publish
  client_identity, data* and SIG2 
so that a third party could validate the authenticity of data* wrt to
the client (assuming that the client wants his identity associated
with data*).

It can be tricky to keep data* and SIG2 in a form that allows a third-party
to validate it, and thus, it is probably necessary to keep data* and SIG2
as opaque blobs and let the third-party tackle the problem of verifying
that displayed(data*) has some reasonable relationship to data* itself.

Hilarie






From owner-atom-syntax@mail.imc.org Mon Jun 18 17:20:59 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0Oeh-0002Xy-5k
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 17:20:59 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0Oef-0000Uf-PC
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 17:20:59 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5IKsF5E031653
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 18 Jun 2007 13:54:15 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5IKsF6J031652;
	Mon, 18 Jun 2007 13:54:15 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.230])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5IKsDW3031644
	for <atom-syntax@imc.org>; Mon, 18 Jun 2007 13:54:14 -0700 (MST)
	(envelope-from joe.gregorio@gmail.com)
Received: by wx-out-0506.google.com with SMTP id s16so1509944wxc
        for <atom-syntax@imc.org>; Mon, 18 Jun 2007 13:54:11 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed;
        d=gmail.com; s=beta;
        h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=EEnhKYQJMvvqtTcrD+C/JWEx5bmYsytT15TMcy/eMjNMeZApMaU6UMOjXJOhX2n7oziVcGxCDrh3Vygo9R4ETtDZYad9/0g3WwrQd+xtZMJYGoEXp/SEqK29uQYNn2ug53nEZ6egAiIrT5CIEp5K/M5utMGvYxEWCC+jhc6iTKk=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=NHk/ByhW2q3NPk87xavaUlIkEu/CFfM/KREgOpq0hQtx1fKi4nTOtF/4SzsiSSnwgsmfpZAgVVNYCEm8yrCv+DqWwmVEBl5KksmayRe0szmzkVpt4zoyXWGctW7XfqAzum8AyQmHryAMGudNSh/TqEPU8+kJrBbLO7EyegEtkwI=
Received: by 10.90.95.11 with SMTP id s11mr4458474agb.1182200051322;
        Mon, 18 Jun 2007 13:54:11 -0700 (PDT)
Received: by 10.90.113.7 with HTTP; Mon, 18 Jun 2007 13:54:11 -0700 (PDT)
Message-ID: <3f1451f50706181354s2e11c786j155d40cb33923797@mail.gmail.com>
Date: Mon, 18 Jun 2007 16:54:11 -0400
From: "Joe Gregorio" <joe@bitworking.org>
To: "Tim Bray" <Tim.Bray@sun.com>
Subject: Re: Atom protocol and digital signatures
Cc: "Paul Hoffman" <phoffman@imc.org>, "Sam Hartman" <hartmans-ietf@mit.edu>,
        "atom-syntax Syntax" <atom-syntax@imc.org>,
        "Atom Publishing Protocol" <atom-protocol@imc.org>,
        atompub-ads@tools.ietf.org
In-Reply-To: <1C122502-8542-4B25-8A18-87BD2E5A4D3C@Sun.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <tslr6oa9yls.fsf@mit.edu>
	 <50F7EA57-A1BF-4243-BFEF-8AE82A49BBBB@sun.com>
	 <F13E55EB-1A48-4CE6-B898-FF12980F3253@osafoundation.org>
	 <46759EBF.3000604@gmail.com>
	 <371C7E24-4395-4794-B2C5-5A11180910B0@osafoundation.org>
	 <467622A9.80306@gmail.com>
	 <C1A2E70E-3531-41C3-B34A-4C7843D45C67@Sun.COM>
	 <p06240803c29c501fe09e@10.20.30.108>
	 <1C122502-8542-4B25-8A18-87BD2E5A4D3C@Sun.COM>
X-Google-Sender-Auth: 1e4b36b58aaa9f9e
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370


On 6/18/07, Tim Bray <Tim.Bray@sun.com> wrote:
> OK, let me re-phrase slightly.  The idea of a client expecting a
> digital signature on a whole entry to survive the publishing process
> is bogus.

Agreed. I never considered the signing and encrypting of Atom
Entries or Feeds to last beyond a one way trip between
the client and the server. If that's going to be a common
misunderstanding then we should add
more verbiage to clear up that point.

   -joe

-- 
Joe Gregorio        http://bitworking.org




From owner-atom-syntax@mail.imc.org Mon Jun 18 17:43:20 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0P0K-0004I9-8B
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 17:43:20 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0P0I-0005uf-L0
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 17:43:20 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5ILHo5F033382
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 18 Jun 2007 14:17:50 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5ILHoE9033380;
	Mon, 18 Jun 2007 14:17:50 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5ILHldG033367
	for <atom-syntax@imc.org>; Mon, 18 Jun 2007 14:17:48 -0700 (MST)
	(envelope-from pagaltzis@gmx.de)
Received: (qmail invoked by alias); 18 Jun 2007 21:17:47 -0000
Received: from static-87-79-236-202.netcologne.de (EHLO klangraum) [87.79.236.202]
  by mail.gmx.net (mp040) with SMTP; 18 Jun 2007 23:17:47 +0200
X-Authenticated: #163624
X-Provags-ID: V01U2FsdGVkX18xDCte1sAxsEoKT1Zmv1D6s1gSuvD4EIyOoi5wyg
	RAuBbPIs79YwCu
Date: Mon, 18 Jun 2007 23:17:46 +0200
From: "A. Pagaltzis" <pagaltzis@gmx.de>
To: atom-syntax Syntax <atom-syntax@imc.org>,
        Atom Publishing Protocol <atom-protocol@imc.org>
Subject: Re: Atom protocol and digital signatures
Message-ID: <20070618211746.GE24708@klangraum>
Mail-Followup-To: atom-syntax Syntax <atom-syntax@imc.org>,
	Atom Publishing Protocol <atom-protocol@imc.org>
References: <tslr6oa9yls.fsf@mit.edu> <50F7EA57-A1BF-4243-BFEF-8AE82A49BBBB@sun.com> <F13E55EB-1A48-4CE6-B898-FF12980F3253@osafoundation.org> <46759EBF.3000604@gmail.com> <371C7E24-4395-4794-B2C5-5A11180910B0@osafoundation.org> <467622A9.80306@gmail.com> <C1A2E70E-3531-41C3-B34A-4C7843D45C67@Sun.COM> <4676AAF5.2030002@gmail.com> <6abd7357pvdadgbe4oc057m4fl8mjea1a2@hive.bjoern.hoehrmann.de> <4676B629.9070303@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <4676B629.9070303@gmail.com>
User-Agent: Mutt/1.4.2.1i
X-Y-GMX-Trusted: 0
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id l5ILHo5F033382
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081


* James M Snell <jasnell@gmail.com> [2007-06-18 18:55]:
> Slightly better?

How about something along these lines:

    15.5. Digital Signatures and Encryption

    Atom Entry and Feed Documents can contain XML Digital
    Signatures [REC-xmldsig-core] and can be encrypted using XML
    Encryption [REC-xmlenc-core] as specified in Section 5 of
    [RFC4287]. Handling of signatures and encrypted elements in
    Atom documents is discussed in sections 5 and 6.3 of [RFC4287].

    Neither servers nor clients are under any obligation to
    support XML Digital Signatures and XML Encryption, although a
    server MAY require that Entry Documents received from a client
    be digitally signed with a valid signature or be encrypted, or
    both.

    Servers are free to modify the contents of an Entry Document
    in any way, which can lead to inadvertent invalidation of
    signatures. If the server can detect a thusly invalidated
    signature, it is strongly encouraged that it be discarded
    prior to publishing.

    In all cases, it is considered out of scope for this
    specification how support and/or requirements for digital
    signing and encryption are communicated between server and
    client.

And a tentative addition I wanted to include above the last
paragraph, but which I=E2=80=99m not yet quite sure about:

    Clients wishing to publish digitally signed and/or encrypted
    content should consider that servers are especially likely to
    modify particular aspects of an Entry Document, such as
    "atom:id" and "atom:updated", but not necessarily others,
    such "atom:title" or "atom:content". Signing and/or
    encrypting selectively may therefore be a better strategy
    than doing so for the Entry Document as a whole.

I=E2=80=99m rather unhappy with the wording and length of that, though.

Regards,
--=20
Aristotle Pagaltzis // <http://plasmasturm.org/>




From owner-atom-syntax@mail.imc.org Mon Jun 18 17:56:27 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0PD1-0002qd-Cl
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 17:56:27 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0PD0-0007fL-0G
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 17:56:27 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5ILZjVd035553
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 18 Jun 2007 14:35:45 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5ILZj9T035552;
	Mon, 18 Jun 2007 14:35:45 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5ILZg8B035528
	for <atom-syntax@imc.org>; Mon, 18 Jun 2007 14:35:43 -0700 (MST)
	(envelope-from julian.reschke@gmx.de)
Received: (qmail invoked by alias); 18 Jun 2007 21:35:41 -0000
Received: from p508FA6CE.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.166.206]
  by mail.gmx.net (mp046) with SMTP; 18 Jun 2007 23:35:41 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1+zu3N9MHCzv/0P/53QU0PSpArmMce6ugHOHbuSq7
	Yy1tEH71dFrVcN
Message-ID: <4676FAA2.7070301@gmx.de>
Date: Mon, 18 Jun 2007 23:35:30 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666
MIME-Version: 1.0
To: Bjoern Hoehrmann <derhoermi@gmx.net>
CC: Paul Hoffman <phoffman@imc.org>, atom-syntax Syntax <atom-syntax@imc.org>,
        Atom Publishing Protocol <atom-protocol@imc.org>,
        atompub-ads@tools.ietf.org
Subject: Re: Atom protocol and digital signatures
References: <tslr6oa9yls.fsf@mit.edu> <50F7EA57-A1BF-4243-BFEF-8AE82A49BBBB@sun.com> <F13E55EB-1A48-4CE6-B898-FF12980F3253@osafoundation.org> <46759EBF.3000604@gmail.com> <371C7E24-4395-4794-B2C5-5A11180910B0@osafoundation.org> <467622A9.80306@gmail.com> <C1A2E70E-3531-41C3-B34A-4C7843D45C67@Sun.COM> <4676AAF5.2030002@gmail.com> <6abd7357pvdadgbe4oc057m4fl8mjea1a2@hive.bjoern.hoehrmann.de> <4676B629.9070303@gmail.com> <p0624080ec29c773d5909@[10.20.30.108]> <8bid73db8mpev18vrj3kqvtav1r5ich9pd@hive.bjoern.hoehrmann.de>
In-Reply-To: <8bid73db8mpev18vrj3kqvtav1r5ich9pd@hive.bjoern.hoehrmann.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Y-GMX-Trusted: 0
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id l5ILZjVd035553
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228


Bjoern Hoehrmann wrote:
> * Paul Hoffman wrote:
>> We have gone out of our way in APP not to tell servers what to do=20
>> with received content. Why should we start here? Also, why should a=20
>> server have to figure out whether the content was changed?
>=20
> I am not sure I understand the second question. If the server receives =
a
> signed document and does not modify the document there is no problem. I=
f
> it does modify it, then it knows the content has been changed. The firs=
t
> question is easy to answer, if you have neither of
>=20
>   * clients don't send signed documents unless server supports them
>   * servers don't keep signatures unless they don't modify documents
>=20
> as policy, a client might optimistically send a signed document and the
> server ends up serving documents with invalidated signatures. That'd be
> bad as recieving clients would give false alarms, reducing the overall
> utility of digital signatures.

Bj=F6rn,

in this case I think we'd need to define what "changing" a document=20
means. What aspects need to be preserved? Comments? PIs? Namespace=20
prefixes? Whitespace?

Best regards, Julian




From owner-atom-syntax@mail.imc.org Mon Jun 18 17:56:40 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0PDE-0002xt-Lf
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 17:56:40 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0PDE-0007fs-5K
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 17:56:40 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5ILSicl034131
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 18 Jun 2007 14:28:44 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5ILSiYR034130;
	Mon, 18 Jun 2007 14:28:44 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.235])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5ILSgP3034114
	for <atom-syntax@imc.org>; Mon, 18 Jun 2007 14:28:43 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by wx-out-0506.google.com with SMTP id s16so1519259wxc
        for <atom-syntax@imc.org>; Mon, 18 Jun 2007 14:28:40 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed;
        d=gmail.com; s=beta;
        h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=eEZvOy2r203HdPHfYb7XYOVmeLRPVkFCj671uXNRQai1sKKnauOz0jvHHQdXzhhdbYYJC2pbyNlo54OObpsbFifzKHM3+OV+wC8rKHMgutQuV7QAD/DiJ18tpA0W6eaMORn7PQ0WsQFwliOYDn/WbkRhXge0gv7qSRSLol79mH0=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=nVhhXx6FlpGhV2RYSWzD5nD7wLQW3zdetUqvDOZQ4I9IWe/zxaSr/h87C/xWYr81G1CEE6FaGI9X503plHede2uZ9t8NzYxks38cLKEzsS715GRJUKY/M6BOlUCOiczoPrpKaH4P3sSaIwNC8kskBwMgPHI6WArTYkGpFqaj7BY=
Received: by 10.90.98.3 with SMTP id v3mr4498676agb.1182202120291;
        Mon, 18 Jun 2007 14:28:40 -0700 (PDT)
Received: from ?192.168.1.118? ( [67.181.218.96])
        by mx.google.com with ESMTP id 45sm4793413wri.2007.06.18.14.28.38
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Mon, 18 Jun 2007 14:28:39 -0700 (PDT)
Message-ID: <4676F904.10007@gmail.com>
Date: Mon, 18 Jun 2007 14:28:36 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.0 (X11/20070326)
MIME-Version: 1.0
To: atom-syntax Syntax <atom-syntax@imc.org>,
        Atom Publishing Protocol <atom-protocol@imc.org>
Subject: Re: Atom protocol and digital signatures
References: <tslr6oa9yls.fsf@mit.edu> <50F7EA57-A1BF-4243-BFEF-8AE82A49BBBB@sun.com> <F13E55EB-1A48-4CE6-B898-FF12980F3253@osafoundation.org> <46759EBF.3000604@gmail.com> <371C7E24-4395-4794-B2C5-5A11180910B0@osafoundation.org> <467622A9.80306@gmail.com> <C1A2E70E-3531-41C3-B34A-4C7843D45C67@Sun.COM> <4676AAF5.2030002@gmail.com> <6abd7357pvdadgbe4oc057m4fl8mjea1a2@hive.bjoern.hoehrmann.de> <4676B629.9070303@gmail.com> <20070618211746.GE24708@klangraum>
In-Reply-To: <20070618211746.GE24708@klangraum>
Content-Type: text/plain; charset=UTF-8
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id l5ILSicl034131
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca


I'm happy with everything here except your last proposed addition, which
I do not believe is necessary or appropriate.

- James

A. Pagaltzis wrote:
> * James M Snell <jasnell@gmail.com> [2007-06-18 18:55]:
>> Slightly better?
>=20
> How about something along these lines:
>=20
>     15.5. Digital Signatures and Encryption
>=20
>     Atom Entry and Feed Documents can contain XML Digital
>     Signatures [REC-xmldsig-core] and can be encrypted using XML
>     Encryption [REC-xmlenc-core] as specified in Section 5 of
>     [RFC4287]. Handling of signatures and encrypted elements in
>     Atom documents is discussed in sections 5 and 6.3 of [RFC4287].
>=20
>     Neither servers nor clients are under any obligation to
>     support XML Digital Signatures and XML Encryption, although a
>     server MAY require that Entry Documents received from a client
>     be digitally signed with a valid signature or be encrypted, or
>     both.
>=20
>     Servers are free to modify the contents of an Entry Document
>     in any way, which can lead to inadvertent invalidation of
>     signatures. If the server can detect a thusly invalidated
>     signature, it is strongly encouraged that it be discarded
>     prior to publishing.
>=20
>     In all cases, it is considered out of scope for this
>     specification how support and/or requirements for digital
>     signing and encryption are communicated between server and
>     client.
>=20
> And a tentative addition I wanted to include above the last
> paragraph, but which I=E2=80=99m not yet quite sure about:
>=20
>     Clients wishing to publish digitally signed and/or encrypted
>     content should consider that servers are especially likely to
>     modify particular aspects of an Entry Document, such as
>     "atom:id" and "atom:updated", but not necessarily others,
>     such "atom:title" or "atom:content". Signing and/or
>     encrypting selectively may therefore be a better strategy
>     than doing so for the Entry Document as a whole.
>=20
> I=E2=80=99m rather unhappy with the wording and length of that, though.
>=20
> Regards,




From owner-atom-syntax@mail.imc.org Mon Jun 18 18:05:15 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0PLX-0008MU-DY
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 18:05:15 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0PLW-0008CL-1y
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 18:05:15 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5ILb7sX035618
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 18 Jun 2007 14:37:07 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5ILb7n0035616;
	Mon, 18 Jun 2007 14:37:07 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5ILb6RE035600
	for <atom-syntax@imc.org>; Mon, 18 Jun 2007 14:37:06 -0700 (MST)
	(envelope-from julian.reschke@gmx.de)
Received: (qmail invoked by alias); 18 Jun 2007 21:37:05 -0000
Received: from p508FA6CE.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.166.206]
  by mail.gmx.net (mp053) with SMTP; 18 Jun 2007 23:37:05 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1/1JJlOlFv16F5Pso6dYUIfmolV1lHmYl74kZGHfQ
	KhSgZZ6kWNb9N3
Message-ID: <4676FAF7.9030704@gmx.de>
Date: Mon, 18 Jun 2007 23:36:55 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666
MIME-Version: 1.0
To: Bjoern Hoehrmann <derhoermi@gmx.net>
CC: atom-syntax Syntax <atom-syntax@imc.org>,
        Atom Publishing Protocol <atom-protocol@imc.org>
Subject: Re: Atom protocol and digital signatures
References: <tslr6oa9yls.fsf@mit.edu> <50F7EA57-A1BF-4243-BFEF-8AE82A49BBBB@sun.com> <F13E55EB-1A48-4CE6-B898-FF12980F3253@osafoundation.org> <46759EBF.3000604@gmail.com> <371C7E24-4395-4794-B2C5-5A11180910B0@osafoundation.org> <467622A9.80306@gmail.com> <C1A2E70E-3531-41C3-B34A-4C7843D45C67@Sun.COM> <4676AAF5.2030002@gmail.com> <6abd7357pvdadgbe4oc057m4fl8mjea1a2@hive.bjoern.hoehrmann.de> <79636DA8-CE7F-433A-906B-BD5ED6A1DCF9@osafoundation.org> <4676BEF3.4010104@gmx.de> <4rfd73d2eqpq9t3iqobu1i1u6ppujj43ka@hive.bjoern.hoehrmann.de>
In-Reply-To: <4rfd73d2eqpq9t3iqobu1i1u6ppujj43ka@hive.bjoern.hoehrmann.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25


Bjoern Hoehrmann wrote:
> * Julian Reschke wrote:
>> As far as I can tell, APP doesn't require support for signatures, nor 
>> did James say so (pointer?).
> 
> The text said that servers SHOULD remove invalidated signatures. You can
> not do that unless you can determine that a signature has indeed been
> invalidated and know how to remove such a signature. So support would be
> required unless <rfc 2119 exceptions>.

I don't see a SHOULD, but maybe I'm not looking at the same proposal 
you're looking it.

Best regards, Julian




From owner-atom-syntax@mail.imc.org Mon Jun 18 18:35:11 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0PoV-0000Yz-6x
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 18:35:11 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0PoS-0006oh-PS
	for atompub-archive@lists.ietf.org; Mon, 18 Jun 2007 18:35:11 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5IM48Ju037443
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 18 Jun 2007 15:04:08 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5IM48cW037442;
	Mon, 18 Jun 2007 15:04:08 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5IM461k037430
	for <atom-syntax@imc.org>; Mon, 18 Jun 2007 15:04:07 -0700 (MST)
	(envelope-from derhoermi@gmx.net)
Received: (qmail invoked by alias); 18 Jun 2007 22:04:05 -0000
Received: from dslb-084-056-221-118.pools.arcor-ip.net (EHLO hive) [84.56.221.118]
  by mail.gmx.net (mp043) with SMTP; 19 Jun 2007 00:04:05 +0200
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX1+jCB19+ISjBN3B7uKpN7tAELt4QeAmZZ+MYXZeCu
	LvGDZnX1r/4zzL
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: atom-syntax Syntax <atom-syntax@imc.org>,
        Atom Publishing Protocol <atom-protocol@imc.org>,
        atompub-ads@tools.ietf.org
Subject: Re: Atom protocol and digital signatures
Date: Tue, 19 Jun 2007 00:04:01 +0200
Message-ID: <sqvd739ju342n6dnneala382kmesspdcmd@hive.bjoern.hoehrmann.de>
References: <F13E55EB-1A48-4CE6-B898-FF12980F3253@osafoundation.org> <46759EBF.3000604@gmail.com> <371C7E24-4395-4794-B2C5-5A11180910B0@osafoundation.org> <467622A9.80306@gmail.com> <C1A2E70E-3531-41C3-B34A-4C7843D45C67@Sun.COM> <4676AAF5.2030002@gmail.com> <6abd7357pvdadgbe4oc057m4fl8mjea1a2@hive.bjoern.hoehrmann.de> <4676B629.9070303@gmail.com> <p0624080ec29c773d5909@[10.20.30.108]> <8bid73db8mpev18vrj3kqvtav1r5ich9pd@hive.bjoern.hoehrmann.de> <4676FAA2.7070301@gmx.de>
In-Reply-To: <4676FAA2.7070301@gmx.de>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
X-Y-GMX-Trusted: 0
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id l5IM48Ju037443
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25


* Julian Reschke wrote:
>in this case I think we'd need to define what "changing" a document=20
>means. What aspects need to be preserved? Comments? PIs? Namespace=20
>prefixes? Whitespace?

Changing a document means changing it in a way that allows RFC 3275
implementations to generate a different signature after the change.
--=20
Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehr=
mann.de
Weinh. Str. 22 =B7 Telefon: +49(0)621/4309674 =B7 http://www.bjoernsworld=
.de
68309 Mannheim =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev.d=
e/=20




From owner-atom-syntax@mail.imc.org Tue Jun 19 04:59:57 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0ZZ7-0005VI-9j
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 04:59:57 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0ZZ5-0003rG-Sl
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 04:59:57 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5J8RXex095314
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Jun 2007 01:27:33 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5J8RX8b095313;
	Tue, 19 Jun 2007 01:27:33 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5J8RUMH095300
	for <atom-syntax@imc.org>; Tue, 19 Jun 2007 01:27:31 -0700 (MST)
	(envelope-from julian.reschke@gmx.de)
Received: (qmail invoked by alias); 19 Jun 2007 08:27:27 -0000
Received: from p508F8022.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.128.34]
  by mail.gmx.net (mp001) with SMTP; 19 Jun 2007 10:27:27 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX18HW/9qWukHx+mDVKcYadsCVb7tRhU8OZwwvW/PD/
	bYB08bYapLXInB
Message-ID: <46779362.9050407@gmx.de>
Date: Tue, 19 Jun 2007 10:27:14 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
CC: Bjoern Hoehrmann <derhoermi@gmx.net>, James M Snell <jasnell@gmail.com>,
        atom-syntax Syntax <atom-syntax@imc.org>,
        Atom Publishing Protocol <atom-protocol@imc.org>,
        atompub-ads@tools.ietf.org
Subject: Re: Atom protocol and digital signatures
References: <tslr6oa9yls.fsf@mit.edu> <50F7EA57-A1BF-4243-BFEF-8AE82A49BBBB@sun.com> <F13E55EB-1A48-4CE6-B898-FF12980F3253@osafoundation.org> <46759EBF.3000604@gmail.com> <371C7E24-4395-4794-B2C5-5A11180910B0@osafoundation.org> <467622A9.80306@gmail.com> <C1A2E70E-3531-41C3-B34A-4C7843D45C67@Sun.COM> <4676AAF5.2030002@gmail.com> <6abd7357pvdadgbe4oc057m4fl8mjea1a2@hive.bjoern.hoehrmann.de> <79636DA8-CE7F-433A-906B-BD5ED6A1DCF9@osafoundation.org>
In-Reply-To: <79636DA8-CE7F-433A-906B-BD5ED6A1DCF9@osafoundation.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228


Lisa Dusseault wrote:
> 
> On Jun 18, 2007, at 9:16 AM, Bjoern Hoehrmann wrote:
> 
>> This should be "Servers should remove invalidated signatures". However,
>>
>> this may give the false impression that support for signatures is re-
>>
>> quired, and does not address what to do if the server does not know if
>>
>> a signature has been invalidated.
>>
> 
> 
> If there's any doubt about whether support for signatures is required -- 
> James says yes, and Bjoern says no -- we need to be clearer in the 
> publishing protocol document.  
> 
> Otherwise, a server implementor could decide that "since I don't sign 
> entries I don't need any code to handle signatures".

I was just going to note that *if* we make it mandatory to do something 
wrt signatures, we need to reference xml-dsig & friends as normatively. 
Turns out, we already do. Is this really intended & correct?

Best regards, Julian







From owner-atom-syntax@mail.imc.org Tue Jun 19 16:10:08 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0k1g-0007Tz-O3
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 16:10:08 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0k1f-0003PD-BG
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 16:10:08 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JJTKXA067576
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Jun 2007 12:29:20 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5JJTK31067565;
	Tue, 19 Jun 2007 12:29:20 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169])
	(authenticated bits=0)
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JJSqEr067462
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Jun 2007 12:28:53 -0700 (MST)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: <p06240818c29ddcf53388@[10.20.30.108]>
In-Reply-To: <tslr6oa9yls.fsf@mit.edu>
References: <tslr6oa9yls.fsf@mit.edu>
Date: Tue, 19 Jun 2007 12:28:40 -0700
To: Sam Hartman <hartmans-ietf@mit.edu>, atom-syntax@imc.org,
        atom-protocol@imc.org
From: Paul Hoffman <phoffman@imc.org>
Subject: Re: Atom protocol and digital signatures
Cc: atompub-ads@tools.ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4


The following is my take, as document shepherd, of a proposed answer 
to Sam's original request. I'm taking into account his example 
questions (which elicited some good discussion on the list), a few 
sets of proposed wording, and some very good commentary about the 
problems. This suggested text tries to be concise and, because it is 
Security Considerations, tries to help implementers understand the 
security issues of APP.

Please say whether or not this wording works for you. Thanks!

--Paul Hoffman

15.5. Digital Signatures and Encryption

Atom Entry and Feed Documents can contain XML Digital Signatures 
[REC-xmldsig-core] and can be encrypted using XML Encryption 
[REC-xmlenc-core] as specified in Section 5 of [RFC4287]. Handling of 
signatures and encrypted elements in Atom documents is discussed in 
sections 5 and 6.3 of [RFC4287].

Neither servers nor clients are under any obligation to support 
encryption and digital signature of entries or feeds, although it is 
certainly possible that in some installations, clients or servers may
require signing or encrypting of the documents exchanged in the Atom protocol.

Because servers are allowed (and in some cases required) to modify 
the contents of an Entry Document before publishing it, a client that 
signs a Entry Document should only do so with the intention of the 
server possibly validating the submission; the client cannot assume 
that the signature will be valid when viewed by a third party, or 
that the server will even publish the client's signature.

A server is allowed to strip client-applied signatures, to strip 
client-applied signatures and then re-sign with its own public key, 
and to oversign an entry with its own public key. The meaning to a 
third party of a signature applied by a server is the same as a 
signature from anyone, as described in [RFC4287]. The method for a 
server to indicate to a third party whether or not the client signed 
an Entry Document is by including the client's signature in the 
published entry, even though that signature is likely to be invalid.




From owner-atom-syntax@mail.imc.org Tue Jun 19 16:12:39 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0k47-0008QQ-5x
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 16:12:39 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0k46-0003sP-Oo
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 16:12:39 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JJh0QQ069061
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Jun 2007 12:43:00 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5JJh0PC069060;
	Tue, 19 Jun 2007 12:43:00 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.235])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JJgvhb069035
	for <atom-syntax@imc.org>; Tue, 19 Jun 2007 12:43:00 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by wx-out-0506.google.com with SMTP id s16so1809790wxc
        for <atom-syntax@imc.org>; Tue, 19 Jun 2007 12:42:57 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed;
        d=gmail.com; s=beta;
        h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=KvTh9PM2syywSM6HqfTVvw6QzVZsVrpHlTSxdPU0xLs+RCAzMi1udLx5wdYtecDaMdEcabVVsrX7wbbroC4IORtbYSAK6yXDegYf4Ptzy1Gx0iEEow+tOst3DcQn0CPOqZsvez+yTHsACx3xYjJh/7FOZrDsa8929uOUQS3Tzcc=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=PDm1NFoR4DIQYFNdZLPIaxoC3YvJr/EO2HxBxvOIl9l3akzTk2oH0UoYY19LY3J6JnxN+E+Z5z0JihA1QqpZMqwjc0ypIsMuunb/YEhgZMAASVevy2FOwTGxAEpLryVnKA1IWFsZ3oKT9ve1mRnNnsRCHHDd+fJqiWehzy7XL38=
Received: by 10.90.79.6 with SMTP id c6mr5491596agb.1182282176969;
        Tue, 19 Jun 2007 12:42:56 -0700 (PDT)
Received: from ?192.168.1.118? ( [67.181.218.96])
        by mx.google.com with ESMTP id 10sm9897216wrl.2007.06.19.12.42.55
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Tue, 19 Jun 2007 12:42:56 -0700 (PDT)
Message-ID: <467831BE.7090604@gmail.com>
Date: Tue, 19 Jun 2007 12:42:54 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.0 (X11/20070326)
MIME-Version: 1.0
To: Paul Hoffman <phoffman@imc.org>
CC: Sam Hartman <hartmans-ietf@mit.edu>, atom-syntax@imc.org,
        atom-protocol@imc.org, atompub-ads@tools.ietf.org
Subject: Re: Atom protocol and digital signatures
References: <tslr6oa9yls.fsf@mit.edu> <p06240818c29ddcf53388@[10.20.30.108]>
In-Reply-To: <p06240818c29ddcf53388@[10.20.30.108]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081




Paul Hoffman wrote:
> [snip]
> 15.5. Digital Signatures and Encryption
> 
> Atom Entry and Feed Documents can contain XML Digital Signatures
> [REC-xmldsig-core] and can be encrypted using XML Encryption
> [REC-xmlenc-core] as specified in Section 5 of [RFC4287]. Handling of
> signatures and encrypted elements in Atom documents is discussed in
> sections 5 and 6.3 of [RFC4287].
> 
> Neither servers nor clients are under any obligation to support
> encryption and digital signature of entries or feeds, although it is
> certainly possible that in some installations, clients or servers may
> require signing or encrypting of the documents exchanged in the Atom
> protocol.

Fine up to here.

> 
> Because servers are allowed (and in some cases required) to modify the
> contents of an Entry Document before publishing it, a client that signs
> a Entry Document should only do so with the intention of the server
> possibly validating the submission; the client cannot assume that the
> signature will be valid when viewed by a third party, or that the server
> will even publish the client's signature.
> 

This gets too close to dictating implementation behavior.  There may be
many reasons for having a client sign an entry that goes beyond
validating the submission.

> A server is allowed to strip client-applied signatures, to strip
> client-applied signatures and then re-sign with its own public key, and
> to oversign an entry with its own public key. The meaning to a third
> party of a signature applied by a server is the same as a signature from
> anyone, as described in [RFC4287]. The method for a server to indicate
> to a third party whether or not the client signed an Entry Document is
> by including the client's signature in the published entry, even though
> that signature is likely to be invalid.
> 

I preferred Aristotle's suggested text (posted 6/18)

- James




From owner-atom-syntax@mail.imc.org Tue Jun 19 16:21:07 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0kCJ-0000ME-8P
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 16:21:07 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0kCG-0006fW-GV
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 16:21:07 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JJuHZW070212
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Jun 2007 12:56:17 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5JJuHjT070211;
	Tue, 19 Jun 2007 12:56:17 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5JJuDfs070178
	for <atom-syntax@imc.org>; Tue, 19 Jun 2007 12:56:16 -0700 (MST)
	(envelope-from derhoermi@gmx.net)
Received: (qmail invoked by alias); 19 Jun 2007 19:56:12 -0000
Received: from dslb-084-056-239-038.pools.arcor-ip.net (EHLO hive) [84.56.239.38]
  by mail.gmx.net (mp012) with SMTP; 19 Jun 2007 21:56:12 +0200
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX18/uBh3axc/kJuya7SEwNoV8dbyZufdf7CNLcdz8T
	hRpNhbC4eOabjR
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Paul Hoffman <phoffman@imc.org>
Cc: Sam Hartman <hartmans-ietf@mit.edu>, atom-syntax@imc.org,
        atom-protocol@imc.org, atompub-ads@tools.ietf.org
Subject: Re: Atom protocol and digital signatures
Date: Tue, 19 Jun 2007 21:56:07 +0200
Message-ID: <ugcg735ct7nc1b990ft3nboqjkl2nuimmr@hive.bjoern.hoehrmann.de>
References: <tslr6oa9yls.fsf@mit.edu> <p06240818c29ddcf53388@[10.20.30.108]>
In-Reply-To: <p06240818c29ddcf53388@[10.20.30.108]>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
X-Y-GMX-Trusted: 0
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id l5JJuHZW070212
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906


* Paul Hoffman wrote:
>Because servers are allowed (and in some cases required) to modify=20
>the contents of an Entry Document before publishing it, a client that=20
>signs a Entry Document should only do so with the intention of the=20
>server possibly validating the submission; the client cannot assume=20
>that the signature will be valid when viewed by a third party, or=20
>that the server will even publish the client's signature.

Could you point out where the draft requires making changes? I so far
assumed you can make a conforming implementation that does little but
passing through the content I want to publish as-is, your text seems
to rule that out. If it is possible to make an APP implementation that
almost always keeps my content unmodified, clients that know they are
talking to such a server should not violate the "should only".
--=20
Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehr=
mann.de
Weinh. Str. 22 =B7 Telefon: +49(0)621/4309674 =B7 http://www.bjoernsworld=
.de
68309 Mannheim =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev.d=
e/=20




From owner-atom-syntax@mail.imc.org Tue Jun 19 16:53:00 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0khA-0007F2-SF
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 16:53:00 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0kh8-0007Dd-3e
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 16:53:00 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JKHiSb073360
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Jun 2007 13:17:44 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5JKHivW073359;
	Tue, 19 Jun 2007 13:17:44 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JKHgwN073339;
	Tue, 19 Jun 2007 13:17:43 -0700 (MST)
	(envelope-from Tim.Bray@Sun.COM)
Received: from fe-amer-02.sun.com ([192.18.108.176])
	by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5JKHgVa018010;
	Tue, 19 Jun 2007 20:17:42 GMT
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 id <0JJW00C01G7Q0G00@mail-amer.sun.com> (original mail from Tim.Bray@Sun.COM)
 ; Tue, 19 Jun 2007 14:17:42 -0600 (MDT)
Received: from [192.168.102.100]
 (d154-20-170-13.bchsia.telus.net [154.20.170.13])
 by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr  3
 2006)) with ESMTPSA id <0JJW00BH0GDGKO00@mail-amer.sun.com>; Tue,
 19 Jun 2007 14:17:41 -0600 (MDT)
Date: Tue, 19 Jun 2007 13:17:08 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Atom protocol and digital signatures
In-reply-to: <467831BE.7090604@gmail.com>
To: James M Snell <jasnell@gmail.com>
Cc: Paul Hoffman <phoffman@imc.org>, Sam Hartman <hartmans-ietf@mit.edu>,
        atom-syntax@imc.org, atom-protocol@imc.org, atompub-ads@tools.ietf.org
Message-id: <E23C6B3F-AF69-427A-97BA-CFB5931AF3E9@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.752.3)
Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII
Content-transfer-encoding: 7BIT
References: <tslr6oa9yls.fsf@mit.edu> <p06240818c29ddcf53388@[10.20.30.108]>
 <467831BE.7090604@gmail.com>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a


On Jun 19, 2007, at 12:42 PM, James M Snell wrote:

>> Because servers are allowed (and in some cases required) to modify  
>> the
>> contents of an Entry Document before publishing it, a client that  
>> signs
>> a Entry Document should only do so with the intention of the server
>> possibly validating the submission; the client cannot assume that the
>> signature will be valid when viewed by a third party, or that the  
>> server
>> will even publish the client's signature.
>>
>
> This gets too close to dictating implementation behavior.  There  
> may be
> many reasons for having a client sign an entry that goes beyond
> validating the submission.

Huh?  Why would you go to the (nontrivial) trouble of doing a  
signature if you didn't want someone to check it?  And who other than  
the server could?  The phrase "client" here clearly means "software  
behavior in the context of the Atom Protocol", and if you're signing  
it in the context of the Atom Protocol, the signature couldn't  
possibly be useful, in the context of the protocol, to any party  
other than the server you're sending it to.  -Tim




From owner-atom-syntax@mail.imc.org Tue Jun 19 16:59:56 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0kns-0004dM-TT
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 16:59:56 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0knr-0000iL-HF
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 16:59:56 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JKYs7B074947
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Jun 2007 13:34:54 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5JKYsBQ074946;
	Tue, 19 Jun 2007 13:34:54 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169])
	(authenticated bits=0)
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JKYbfW074909
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Jun 2007 13:34:38 -0700 (MST)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: <p0624081bc29dea9b6661@[10.20.30.108]>
In-Reply-To: <467831BE.7090604@gmail.com>
References: <tslr6oa9yls.fsf@mit.edu>
 <p06240818c29ddcf53388@[10.20.30.108]> <467831BE.7090604@gmail.com>
Date: Tue, 19 Jun 2007 13:21:47 -0700
To: James M Snell <jasnell@gmail.com>
From: Paul Hoffman <phoffman@imc.org>
Subject: Re: Atom protocol and digital signatures
Cc: Sam Hartman <hartmans-ietf@mit.edu>, atom-syntax@imc.org,
        atom-protocol@imc.org, atompub-ads@tools.ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034


At 12:42 PM -0700 6/19/07, James M Snell wrote:
>  > Because servers are allowed (and in some cases required) to modify the
>>  contents of an Entry Document before publishing it, a client that signs
>>  a Entry Document should only do so with the intention of the server
>>  possibly validating the submission; the client cannot assume that the
>>  signature will be valid when viewed by a third party, or that the server
>>  will even publish the client's signature.
>>
>
>This gets too close to dictating implementation behavior.  There may be
>many reasons for having a client sign an entry that goes beyond
>validating the submission.

Does changing "should only do so" to "can do so" help alleviate that 
concern? If not, alternate wording would be appreciated.

>  > A server is allowed to strip client-applied signatures, to strip
>>  client-applied signatures and then re-sign with its own public key, and
>>  to oversign an entry with its own public key. The meaning to a third
>>  party of a signature applied by a server is the same as a signature from
>>  anyone, as described in [RFC4287]. The method for a server to indicate
>>  to a third party whether or not the client signed an Entry Document is
>>  by including the client's signature in the published entry, even though
>>  that signature is likely to be invalid.
>>
>
>I preferred Aristotle's suggested text (posted 6/18)

It did not hit all the points that I thought Sam was asking for. The 
exercise at the moment is to come up with wording that is both useful 
to the reader and covers the concerns of the AD who brought up the 
point.




From owner-atom-syntax@mail.imc.org Tue Jun 19 17:00:51 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0kol-00054p-Ie
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 17:00:51 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0koj-0000ra-56
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 17:00:51 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JKXu2u074843
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Jun 2007 13:33:56 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5JKXunA074841;
	Tue, 19 Jun 2007 13:33:56 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5JKXsPi074822
	for <atom-syntax@imc.org>; Tue, 19 Jun 2007 13:33:55 -0700 (MST)
	(envelope-from derhoermi@gmx.net)
Received: (qmail invoked by alias); 19 Jun 2007 20:33:54 -0000
Received: from dslb-084-056-239-038.pools.arcor-ip.net (EHLO hive) [84.56.239.38]
  by mail.gmx.net (mp043) with SMTP; 19 Jun 2007 22:33:54 +0200
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX19Au6tauX5A5wLg1TsIgngfKL04tnIXBmICMt2hQS
	4Ux0Mmqz715vKA
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Tim Bray <Tim.Bray@Sun.COM>
Cc: Sam Hartman <hartmans-ietf@mit.edu>, atom-syntax@imc.org,
        atom-protocol@imc.org, atompub-ads@tools.ietf.org
Subject: Re: Atom protocol and digital signatures
Date: Tue, 19 Jun 2007 22:33:49 +0200
Message-ID: <pqeg73ps8sdn81dggevojmn30qmo6g11iq@hive.bjoern.hoehrmann.de>
References: <tslr6oa9yls.fsf@mit.edu> <p06240818c29ddcf53388@[10.20.30.108]> <ugcg735ct7nc1b990ft3nboqjkl2nuimmr@hive.bjoern.hoehrmann.de> <CB2EDB61-3B0B-40C4-BB11-0EFDBBE358FD@sun.com>
In-Reply-To: <CB2EDB61-3B0B-40C4-BB11-0EFDBBE358FD@sun.com>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
X-Y-GMX-Trusted: 0
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id l5JKXu2u074843
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581


* Tim Bray wrote:
>Such an implementation would be possible, but would be an exotic =20
>corner case.  Client implementers SHOULD NOT expect digsigs to =20
>survive the operation of a typical Atom server implementation, and =20
>Sam Hartman is correct that we need to be clear about this.  -Tim

I agree, but then it seems "should only do so with the intention of the
server possibly validating the submission" can safely be extended by
saying clients may do so for other reasons if the server is known to
support that. Saying what you say above, clients should not expect this
to work unless they have specific information about the server would be
sufficient.
--=20
Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehr=
mann.de
Weinh. Str. 22 =B7 Telefon: +49(0)621/4309674 =B7 http://www.bjoernsworld=
.de
68309 Mannheim =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev.d=
e/=20




From owner-atom-syntax@mail.imc.org Tue Jun 19 17:03:34 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0krO-0007FN-CX
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 17:03:34 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0krM-0001gM-U6
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 17:03:34 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JKKPRZ073615
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Jun 2007 13:20:25 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5JKKPCa073612;
	Tue, 19 Jun 2007 13:20:25 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JKKNe3073589;
	Tue, 19 Jun 2007 13:20:24 -0700 (MST)
	(envelope-from Tim.Bray@Sun.COM)
Received: from fe-amer-03.sun.com ([192.18.108.177])
	by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5JKKNlp015896;
	Tue, 19 Jun 2007 20:20:23 GMT
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 id <0JJW00I01GC7JS00@mail-amer.sun.com> (original mail from Tim.Bray@Sun.COM)
 ; Tue, 19 Jun 2007 14:20:23 -0600 (MDT)
Received: from [192.168.102.100]
 (d154-20-170-13.bchsia.telus.net [154.20.170.13])
 by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr  3
 2006)) with ESMTPSA id <0JJW00MVZGHWI6B0@mail-amer.sun.com>; Tue,
 19 Jun 2007 14:20:21 -0600 (MDT)
Date: Tue, 19 Jun 2007 13:19:48 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Atom protocol and digital signatures
In-reply-to: <ugcg735ct7nc1b990ft3nboqjkl2nuimmr@hive.bjoern.hoehrmann.de>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Cc: Paul Hoffman <phoffman@imc.org>, Sam Hartman <hartmans-ietf@mit.edu>,
        atom-syntax@imc.org, atom-protocol@imc.org, atompub-ads@tools.ietf.org
Message-id: <CB2EDB61-3B0B-40C4-BB11-0EFDBBE358FD@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.752.3)
Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII
Content-transfer-encoding: 7BIT
References: <tslr6oa9yls.fsf@mit.edu> <p06240818c29ddcf53388@[10.20.30.108]>
 <ugcg735ct7nc1b990ft3nboqjkl2nuimmr@hive.bjoern.hoehrmann.de>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a


On Jun 19, 2007, at 12:56 PM, Bjoern Hoehrmann wrote:

>
> * Paul Hoffman wrote:
>> Because servers are allowed (and in some cases required) to modify
>> the contents of an Entry Document before publishing it, a client that
>> signs a Entry Document should only do so with the intention of the
>> server possibly validating the submission; the client cannot assume
>> that the signature will be valid when viewed by a third party, or
>> that the server will even publish the client's signature.
>
> Could you point out where the draft requires making changes?

The atom:id has to be globally unique, and the server has to manage  
app:edited.

> I so far
> assumed you can make a conforming implementation that does little but
> passing through the content I want to publish as-is, your text seems
> to rule that out.

Such an implementation would be possible, but would be an exotic  
corner case.  Client implementers SHOULD NOT expect digsigs to  
survive the operation of a typical Atom server implementation, and  
Sam Hartman is correct that we need to be clear about this.  -Tim




From owner-atom-syntax@mail.imc.org Tue Jun 19 17:06:35 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0kuJ-00026D-0s
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 17:06:35 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0kuH-0002j8-Kp
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 17:06:34 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JKYsmA074945
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Jun 2007 13:34:54 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5JKYsWT074944;
	Tue, 19 Jun 2007 13:34:54 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169])
	(authenticated bits=0)
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JKYbfY074909
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Jun 2007 13:34:40 -0700 (MST)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: <p0624081cc29dec39c759@[10.20.30.108]>
In-Reply-To: <ugcg735ct7nc1b990ft3nboqjkl2nuimmr@hive.bjoern.hoehrmann.de>
References: <tslr6oa9yls.fsf@mit.edu>
 <p06240818c29ddcf53388@[10.20.30.108]>
 <ugcg735ct7nc1b990ft3nboqjkl2nuimmr@hive.bjoern.hoehrmann.de>
Date: Tue, 19 Jun 2007 13:34:25 -0700
To: Bjoern Hoehrmann <derhoermi@gmx.net>
From: Paul Hoffman <phoffman@imc.org>
Subject: Re: Atom protocol and digital signatures
Cc: Sam Hartman <hartmans-ietf@mit.edu>, atom-syntax@imc.org,
        atom-protocol@imc.org, atompub-ads@tools.ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581


At 9:56 PM +0200 6/19/07, Bjoern Hoehrmann wrote:
>Could you point out where the draft requires making changes?

First, let me point out that the contrapositive is covered in Section 10:

    Clients MUST NOT assume that an Atom Entry returned in the Feed is a
    full representation of an Entry Resource and SHOULD perform a GET on
    the URI of the Member Entry before editing it.

>I so far
>assumed you can make a conforming implementation that does little but
>passing through the content I want to publish as-is, your text seems
>to rule that out.

It is ruled out if publishing a feed would create an invalid feed, 
such as one with non-unique atom:id values. That is, the server is 
responsible for following the MUST rules of the Atom format when it 
is publishing, even if the client gives it something that would not 
follow those MUSTs.




From owner-atom-syntax@mail.imc.org Tue Jun 19 17:13:04 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0l0a-0006nm-Ob
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 17:13:04 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0l0a-0004S9-BU
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 17:13:04 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JKoPOB076654
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Jun 2007 13:50:25 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5JKoPdQ076653;
	Tue, 19 Jun 2007 13:50:25 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.226])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JKoOmn076618
	for <atom-syntax@imc.org>; Tue, 19 Jun 2007 13:50:24 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by wx-out-0506.google.com with SMTP id s16so1831161wxc
        for <atom-syntax@imc.org>; Tue, 19 Jun 2007 13:50:18 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed;
        d=gmail.com; s=beta;
        h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=cNh2cYxRvl8MIX/t2JHjm+Pt3m4S0WWQ43yHwhjCuxkhCV1M2SJc/DoKrBH4uO2Ak20YMFd/vgheK8L3F69MWyUrfDgUijq3OEr96ZkawOvfz4s83N0Xgokn3J1CtCGQXgh92PAMDByRzU34vtpYpHxv+Xsw0Xhfy97DZy6giwk=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=K4rZVTdwC4zX9ope5k9gmR4nKzHnQoPFfvBr1Qcr+OpS9EcR1PAfqYTJBsE1fVPNWHpfYSMrciNEnja315/3CajcRCD8yk8VxDRW5lb3tyg8fjNlJgNkHVnozqmvAa+JK9do8sepy+Dlwh2rJxFr1CopW+YXnm32hnhXyeNybz8=
Received: by 10.90.25.3 with SMTP id 3mr5624962agy.1182286218095;
        Tue, 19 Jun 2007 13:50:18 -0700 (PDT)
Received: from ?192.168.1.118? ( [67.181.218.96])
        by mx.google.com with ESMTP id m29sm9925805wrm.2007.06.19.13.50.16
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Tue, 19 Jun 2007 13:50:17 -0700 (PDT)
Message-ID: <4678417F.9010507@gmail.com>
Date: Tue, 19 Jun 2007 13:50:07 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.0 (X11/20070326)
MIME-Version: 1.0
To: Tim Bray <Tim.Bray@Sun.COM>
CC: Paul Hoffman <phoffman@imc.org>, Sam Hartman <hartmans-ietf@mit.edu>,
        atom-syntax@imc.org, atom-protocol@imc.org, atompub-ads@tools.ietf.org
Subject: Re: Atom protocol and digital signatures
References: <tslr6oa9yls.fsf@mit.edu> <p06240818c29ddcf53388@[10.20.30.108]> <467831BE.7090604@gmail.com> <E23C6B3F-AF69-427A-97BA-CFB5931AF3E9@sun.com>
In-Reply-To: <E23C6B3F-AF69-427A-97BA-CFB5931AF3E9@sun.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352


My problem is with the "should only do so" and "validating the
submission" text.

I agree that, for the most part, the a client-signed signature is likely
only going to be useful for the server but we honestly do not have
enough experience to say that for certain -- at least not enough to
justify a "should".

I'd be more comfortable with something along these lines:

  Because servers allow allowed (and in some cases required) to modify
  the contents of an Entry Document before publishing it, signatures
  within an entry will likely only be useful to the server to which it
  is being sent. Clients cannot assume that the signature will be valid
  when viewed by a third part, or that the server will event publish
  client's signature.

- James

Tim Bray wrote:
> On Jun 19, 2007, at 12:42 PM, James M Snell wrote:
> 
>>> Because servers are allowed (and in some cases required) to modify the
>>> contents of an Entry Document before publishing it, a client that signs
>>> a Entry Document should only do so with the intention of the server
>>> possibly validating the submission; the client cannot assume that the
>>> signature will be valid when viewed by a third party, or that the server
>>> will even publish the client's signature.
>>>
>>
>> This gets too close to dictating implementation behavior.  There may be
>> many reasons for having a client sign an entry that goes beyond
>> validating the submission.
> 
> Huh?  Why would you go to the (nontrivial) trouble of doing a signature
> if you didn't want someone to check it?  And who other than the server
> could?  The phrase "client" here clearly means "software behavior in the
> context of the Atom Protocol", and if you're signing it in the context
> of the Atom Protocol, the signature couldn't possibly be useful, in the
> context of the protocol, to any party other than the server you're
> sending it to.  -Tim
> 




From owner-atom-syntax@mail.imc.org Tue Jun 19 17:22:36 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0l9o-00026D-Uf
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 17:22:36 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0l9n-0006WU-HS
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 17:22:36 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JL0PvB077584
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Jun 2007 14:00:25 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5JL0PRN077583;
	Tue, 19 Jun 2007 14:00:25 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JL0N3b077566;
	Tue, 19 Jun 2007 14:00:24 -0700 (MST)
	(envelope-from Tim.Bray@Sun.COM)
Received: from fe-amer-04.sun.com ([192.18.108.178])
	by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5JL0NQg013131;
	Tue, 19 Jun 2007 21:00:23 GMT
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 id <0JJW00601HUMTB00@mail-amer.sun.com> (original mail from Tim.Bray@Sun.COM)
 ; Tue, 19 Jun 2007 15:00:23 -0600 (MDT)
Received: from [192.168.102.100]
 (d154-20-170-13.bchsia.telus.net [154.20.170.13])
 by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr  3
 2006)) with ESMTPSA id <0JJW00NMQICL4X00@mail-amer.sun.com>; Tue,
 19 Jun 2007 15:00:23 -0600 (MDT)
Date: Tue, 19 Jun 2007 13:59:50 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Atom protocol and digital signatures
In-reply-to: <4678417F.9010507@gmail.com>
To: James M Snell <jasnell@gmail.com>
Cc: Paul Hoffman <phoffman@imc.org>, Sam Hartman <hartmans-ietf@mit.edu>,
        atom-syntax@imc.org, atom-protocol@imc.org, atompub-ads@tools.ietf.org
Message-id: <5CEAEF94-0CE5-4322-972A-B80AC6FE9BBA@Sun.COM>
MIME-version: 1.0
X-Mailer: Apple Mail (2.752.3)
Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII
Content-transfer-encoding: 7BIT
References: <tslr6oa9yls.fsf@mit.edu> <p06240818c29ddcf53388@[10.20.30.108]>
 <467831BE.7090604@gmail.com> <E23C6B3F-AF69-427A-97BA-CFB5931AF3E9@sun.com>
 <4678417F.9010507@gmail.com>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c



On Jun 19, 2007, at 1:50 PM, James M Snell wrote:

>
>   Because servers allow allowed (and in some cases required) to modify
>   the contents of an Entry Document before publishing it, signatures
>   within an entry will likely only be useful to the server to which it
>   is being sent. Clients cannot assume that the signature will be  
> valid
>   when viewed by a third part, or that the server will event publish
>   client's signature.

I think that's an improvement.  -T




From owner-atom-syntax@mail.imc.org Tue Jun 19 17:40:25 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0lR3-0006vE-08
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 17:40:25 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0lR0-000331-IZ
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 17:40:24 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JLEtJt078754
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Jun 2007 14:14:55 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5JLEs70078751;
	Tue, 19 Jun 2007 14:14:54 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5JLEqRQ078723
	for <atom-syntax@imc.org>; Tue, 19 Jun 2007 14:14:53 -0700 (MST)
	(envelope-from derhoermi@gmx.net)
Received: (qmail invoked by alias); 19 Jun 2007 21:14:52 -0000
Received: from dslb-084-056-239-038.pools.arcor-ip.net (EHLO hive) [84.56.239.38]
  by mail.gmx.net (mp040) with SMTP; 19 Jun 2007 23:14:52 +0200
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX1+GtnB7m2CGnt2ifRTysdIB+JNBQe1viV8+pbfGRE
	AHdhwsWvqWepXt
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Paul Hoffman <phoffman@imc.org>
Cc: Sam Hartman <hartmans-ietf@mit.edu>, atom-syntax@imc.org,
        atom-protocol@imc.org, atompub-ads@tools.ietf.org
Subject: Re: Atom protocol and digital signatures
Date: Tue, 19 Jun 2007 23:14:47 +0200
Message-ID: <ajhg73h2vp41jbvcfbcoela2qb2knsha5e@hive.bjoern.hoehrmann.de>
References: <tslr6oa9yls.fsf@mit.edu> <p06240818c29ddcf53388@[10.20.30.108]> <467831BE.7090604@gmail.com> <p0624081bc29dea9b6661@[10.20.30.108]>
In-Reply-To: <p0624081bc29dea9b6661@[10.20.30.108]>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
X-Y-GMX-Trusted: 0
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id l5JLEtJt078754
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2


* Paul Hoffman wrote:
>At 12:42 PM -0700 6/19/07, James M Snell wrote:
>>  > Because servers are allowed (and in some cases required) to modify =
the
>>>  contents of an Entry Document before publishing it, a client that si=
gns
>>>  a Entry Document should only do so with the intention of the server
>>>  possibly validating the submission; the client cannot assume that th=
e
>>>  signature will be valid when viewed by a third party, or that the se=
rver
>>>  will even publish the client's signature.
>>
>>This gets too close to dictating implementation behavior.  There may be
>>many reasons for having a client sign an entry that goes beyond
>>validating the submission.
>
>Does changing "should only do so" to "can do so" help alleviate that=20
>concern? If not, alternate wording would be appreciated.

It seems to me we are just trying to say: because ... clients should not
sign entry documents unless the server is known to be able to handle the
signed document in a manner consistent with the client's expectations
[specifically, it cannot assume ...].
--=20
Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehr=
mann.de
Weinh. Str. 22 =B7 Telefon: +49(0)621/4309674 =B7 http://www.bjoernsworld=
.de
68309 Mannheim =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev.d=
e/=20




From owner-atom-syntax@mail.imc.org Tue Jun 19 18:53:25 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0mZh-0000AR-C4
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 18:53:25 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0mZg-0004zp-0k
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 18:53:25 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JMVwXM087065
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Jun 2007 15:31:58 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5JMVvfk087063;
	Tue, 19 Jun 2007 15:31:57 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [10.20.30.108] (adsl-66-125-125-71.dsl.pltn13.pacbell.net [66.125.125.71])
	(authenticated bits=0)
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JMVgjZ086999
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Jun 2007 15:31:43 -0700 (MST)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: <p06240820c29e075ddfa1@[10.20.30.108]>
In-Reply-To: <ajhg73h2vp41jbvcfbcoela2qb2knsha5e@hive.bjoern.hoehrmann.de>
References: <tslr6oa9yls.fsf@mit.edu>
 <p06240818c29ddcf53388@[10.20.30.108]> <467831BE.7090604@gmail.com>
 <p0624081bc29dea9b6661@[10.20.30.108]>
 <ajhg73h2vp41jbvcfbcoela2qb2knsha5e@hive.bjoern.hoehrmann.de>
Date: Tue, 19 Jun 2007 15:31:10 -0700
To: Bjoern Hoehrmann <derhoermi@gmx.net>
From: Paul Hoffman <phoffman@imc.org>
Subject: Re: Atom protocol and digital signatures
Cc: Sam Hartman <hartmans-ietf@mit.edu>, atom-syntax@imc.org,
        atom-protocol@imc.org, atompub-ads@tools.ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89


At 11:14 PM +0200 6/19/07, Bjoern Hoehrmann wrote:
>It seems to me we are just trying to say: because ... clients should not
>sign entry documents unless the server is known to be able to handle the
>signed document in a manner consistent with the client's expectations
>[specifically, it cannot assume ...].

So far, you are the only one who has suggested that the client needs 
to know whether the server can handle the signed document. Unless 
others agree with you, we should stay with the current wording.




From owner-atom-syntax@mail.imc.org Tue Jun 19 18:53:28 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0mZk-0000Al-RK
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 18:53:28 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0mZj-000502-Ed
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 18:53:28 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JMVxrB087094
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Jun 2007 15:31:59 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5JMVxj6087091;
	Tue, 19 Jun 2007 15:31:59 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [10.20.30.108] (adsl-66-125-125-71.dsl.pltn13.pacbell.net [66.125.125.71])
	(authenticated bits=0)
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JMVgjX086999
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Jun 2007 15:31:42 -0700 (MST)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: <p0624081fc29e074edc3c@[10.20.30.108]>
In-Reply-To: <5CEAEF94-0CE5-4322-972A-B80AC6FE9BBA@Sun.COM>
References: <tslr6oa9yls.fsf@mit.edu>
 <p06240818c29ddcf53388@[10.20.30.108]> <467831BE.7090604@gmail.com>
 <E23C6B3F-AF69-427A-97BA-CFB5931AF3E9@sun.com>
 <4678417F.9010507@gmail.com>
 <5CEAEF94-0CE5-4322-972A-B80AC6FE9BBA@Sun.COM>
Date: Tue, 19 Jun 2007 15:21:12 -0700
To: Tim Bray <Tim.Bray@Sun.COM>, James M Snell <jasnell@gmail.com>
From: Paul Hoffman <phoffman@imc.org>
Subject: Re: Atom protocol and digital signatures
Cc: Sam Hartman <hartmans-ietf@mit.edu>, atom-syntax@imc.org,
        atom-protocol@imc.org, atompub-ads@tools.ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370


At 1:59 PM -0700 6/19/07, Tim Bray wrote:
>On Jun 19, 2007, at 1:50 PM, James M Snell wrote:
>
>>
>>   Because servers allow allowed (and in some cases required) to modify
>>   the contents of an Entry Document before publishing it, signatures
>>   within an entry will likely only be useful to the server to which it
>>   is being sent. Clients cannot assume that the signature will be valid
>>   when viewed by a third part, or that the server will event publish
>>   client's signature.
>
>I think that's an improvement.  -T

s/third part/third party/
s/event publish/even publish the/




From owner-atom-syntax@mail.imc.org Tue Jun 19 19:25:42 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0n4w-0000IL-AU
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 19:25:42 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0n4u-0008HU-SZ
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 19:25:42 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JMtA4H093556
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Jun 2007 15:55:10 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5JMtAUr093555;
	Tue, 19 Jun 2007 15:55:10 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.236])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JMt79U093485
	for <atom-syntax@imc.org>; Tue, 19 Jun 2007 15:55:10 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by wx-out-0506.google.com with SMTP id s16so1863827wxc
        for <atom-syntax@imc.org>; Tue, 19 Jun 2007 15:55:01 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed;
        d=gmail.com; s=beta;
        h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=lxsP+NtBVjqm0VIb2rLqy7WKOsUO9EjxFza6Y0/LBFsTekzGZQgeq3fMhovvZN9M+yhbnXeKbNZOBH2KEzsZQ+zb+AcFZLSe19nYuO0Esco8VgLD6EJNHS1cGciI8Js5wo5PiZTwxQwXhXCMmKxsgSDsadtr6CxXIzYMPOaX71o=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=JE3SYP/j/betK+E07L4bVrJPF9b0bhT47YZLvNfoOg4JDUQuTH+6jhti+3tmwfpeHo78aUVzyj9SRvN//RkHTG7F1egUJWxSf22s/OYlN/xEpOXt5Ro+UG081Etgo0RBD56Gpu9guRkrPpMsBzNRt4MaW+v64izV7CSvj58ITXs=
Received: by 10.90.105.20 with SMTP id d20mr5783659agc.1182293701215;
        Tue, 19 Jun 2007 15:55:01 -0700 (PDT)
Received: from ?192.168.1.118? ( [67.181.218.96])
        by mx.google.com with ESMTP id 67sm10106638wra.2007.06.19.15.54.58
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Tue, 19 Jun 2007 15:55:00 -0700 (PDT)
Message-ID: <46785EC1.7090407@gmail.com>
Date: Tue, 19 Jun 2007 15:54:57 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.0 (X11/20070326)
MIME-Version: 1.0
To: Paul Hoffman <phoffman@imc.org>
CC: Tim Bray <Tim.Bray@Sun.COM>, Sam Hartman <hartmans-ietf@mit.edu>,
        atom-syntax@imc.org, atom-protocol@imc.org, atompub-ads@tools.ietf.org
Subject: Re: Atom protocol and digital signatures
References: <tslr6oa9yls.fsf@mit.edu> <p06240818c29ddcf53388@[10.20.30.108]> <467831BE.7090604@gmail.com> <E23C6B3F-AF69-427A-97BA-CFB5931AF3E9@sun.com> <4678417F.9010507@gmail.com> <5CEAEF94-0CE5-4322-972A-B80AC6FE9BBA@Sun.COM> <p0624081fc29e074edc3c@[10.20.30.108]>
In-Reply-To: <p0624081fc29e074edc3c@[10.20.30.108]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3




Paul Hoffman wrote:
> At 1:59 PM -0700 6/19/07, Tim Bray wrote:
>> On Jun 19, 2007, at 1:50 PM, James M Snell wrote:
>>
>>>
>>>   Because servers allow allowed (and in some cases required) to modify
>>>   the contents of an Entry Document before publishing it, signatures
>>>   within an entry will likely only be useful to the server to which it
>>>   is being sent. Clients cannot assume that the signature will be valid
>>>   when viewed by a third part, or that the server will event publish
>>>   client's signature.
>>
>> I think that's an improvement.  -T
> 
> s/third part/third party/
> s/event publish/even publish the/

s/allow allowed/are allowed/

damn... who typed this :-)

- james




From owner-atom-syntax@mail.imc.org Tue Jun 19 19:45:44 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0nOK-0002FY-ID
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 19:45:44 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0nOI-0007fT-Up
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 19:45:44 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JNQDxO003100
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Jun 2007 16:26:13 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5JNQD0T003095;
	Tue, 19 Jun 2007 16:26:13 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5JNQAdI003074
	for <atom-syntax@imc.org>; Tue, 19 Jun 2007 16:26:12 -0700 (MST)
	(envelope-from pagaltzis@gmx.de)
Received: (qmail invoked by alias); 19 Jun 2007 23:26:09 -0000
Received: from static-87-79-236-202.netcologne.de (EHLO klangraum) [87.79.236.202]
  by mail.gmx.net (mp015) with SMTP; 20 Jun 2007 01:26:09 +0200
X-Authenticated: #163624
X-Provags-ID: V01U2FsdGVkX19lmyUo5M1lOyy8HqnnOWOBfsLB05i1R0aaFAdKO3
	ruKxVsbLJK5NSw
Date: Wed, 20 Jun 2007 01:26:09 +0200
From: "A. Pagaltzis" <pagaltzis@gmx.de>
To: atom-syntax@imc.org, atom-protocol@imc.org
Subject: Re: Atom protocol and digital signatures
Message-ID: <20070619232609.GL24708@klangraum>
Mail-Followup-To: atom-syntax@imc.org, atom-protocol@imc.org
References: <tslr6oa9yls.fsf@mit.edu> <p06240818c29ddcf53388@[10.20.30.108]> <467831BE.7090604@gmail.com> <E23C6B3F-AF69-427A-97BA-CFB5931AF3E9@sun.com> <4678417F.9010507@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4678417F.9010507@gmail.com>
User-Agent: Mutt/1.4.2.1i
X-Y-GMX-Trusted: 0
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370


* James M Snell <jasnell@gmail.com> [2007-06-19 23:00]:
> I'd be more comfortable with something along these lines:
> 
>   Because servers allow allowed (and in some cases required) to modify
>   the contents of an Entry Document before publishing it, signatures
>   within an entry will likely only be useful to the server to which it
>   is being sent. Clients cannot assume that the signature will be valid
>   when viewed by a third part, or that the server will event publish
>   client's signature.

Sounds good.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>




From owner-atom-syntax@mail.imc.org Tue Jun 19 20:08:43 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0nkZ-0001fF-F8
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 20:08:43 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0nkY-0008LJ-24
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 20:08:43 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JNhcg5007962
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Jun 2007 16:43:38 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5JNhcEP007960;
	Tue, 19 Jun 2007 16:43:38 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5JNhZ38007941
	for <atom-syntax@imc.org>; Tue, 19 Jun 2007 16:43:36 -0700 (MST)
	(envelope-from pagaltzis@gmx.de)
Received: (qmail invoked by alias); 19 Jun 2007 23:43:34 -0000
Received: from static-87-79-236-202.netcologne.de (EHLO klangraum) [87.79.236.202]
  by mail.gmx.net (mp058) with SMTP; 20 Jun 2007 01:43:34 +0200
X-Authenticated: #163624
X-Provags-ID: V01U2FsdGVkX1+pmAwQvRypvIb6abjbcFhd1wrFMGoZVGYYUhtTiG
	40w1s5HhnjGDVA
Date: Wed, 20 Jun 2007 01:43:34 +0200
From: "A. Pagaltzis" <pagaltzis@gmx.de>
To: atom-syntax@imc.org, atom-protocol@imc.org
Subject: Re: Atom protocol and digital signatures
Message-ID: <20070619234334.GM24708@klangraum>
Mail-Followup-To: atom-syntax@imc.org, atom-protocol@imc.org
References: <tslr6oa9yls.fsf@mit.edu> <p06240818c29ddcf53388@[10.20.30.108]>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <p06240818c29ddcf53388@[10.20.30.108]>
User-Agent: Mutt/1.4.2.1i
X-Y-GMX-Trusted: 0
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id l5JNhcg5007962
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081


* Paul Hoffman <phoffman@imc.org> [2007-06-19 21:40]:
> The method for a server to indicate to a third party whether or
> not the client signed an Entry Document is by including the
> client's signature in the published entry, even though that
> signature is likely to be invalid.

I strongly disagree with this. As a consumer, I have no possible
way to know whether an invalid signature is there because

=E2=80=A2 the publishing client included it
=E2=80=A2 the server made up a signature to feign signing by the client
=E2=80=A2 a third party tampered with the entry between the server and me

Therefore as a consumer I would never ever assume that an invalid
signature meant anything else than that the signature on this
entry is not valid.

Encouraging servers to knowingly include signatures they have
invalidated is

Just.

Wrong.

It dilutes the value of signatures as a whole by making it harder
for the consumer to decide what an invalid signature means, which
by extension also blurs the trust conferred by a valid signature.

It=E2=80=99s fine for the server to be signature-agnostic.

If the server is not, though, then it really should strip the
signature if it knows it has invalidated it. Note that my
proposed text said =E2=80=9Cstrongly encouraged=E2=80=9D, not =E2=80=9CSH=
OULD=E2=80=9D. After
all, it is not an interop concern, nor do I desire to dictate
server behaviour.

However, I do think this particular implementation choice
makes a lot of sense and should be the default choice for
server implementors who don=E2=80=99t have specific reason to do
things otherwise. And I think the spec should nudge them in
that direction.

Regards,
--=20
Aristotle Pagaltzis // <http://plasmasturm.org/>




From owner-atom-syntax@mail.imc.org Tue Jun 19 20:09:28 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0nlI-00029c-CP
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 20:09:28 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0nlH-0000cE-0H
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 20:09:28 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JNhUYv007914
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Jun 2007 16:43:30 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5JNhTSn007913;
	Tue, 19 Jun 2007 16:43:29 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.184])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JNhODa007887
	for <atom-syntax@imc.org>; Tue, 19 Jun 2007 16:43:29 -0700 (MST)
	(envelope-from bobwyman@gmail.com)
Received: by mu-out-0910.google.com with SMTP id i2so2347864mue
        for <atom-syntax@imc.org>; Tue, 19 Jun 2007 16:43:16 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed;
        d=gmail.com; s=beta;
        h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=kvT6UxxKT3N1Bd8LBAOgVBTTu1BFD6t7dVibU3eVZrG8L2QD5kcmThrhyKJrwXzKHAasE6PLwmFNXL4Wot6IUAkvfPJ5z0Xa1pvbvdcEaxs57f1DgO/TffotNUrUlxNS8n0t4WlB9SO+60r065v6A9UPxLxpqn7SFrC/y/nIQc0=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=BQ4w/pCjq2uy8Ya6XF3QPR00PKAfv5UD05+dbq8K/WolhCTsIIM2mFAQce33GN83jkBleYUFrP+AKMWsF77+V9I5+17PQz8RlIaviPIsqM6O6gshH2yUsvHiri3pHwyuEkaptRKW40zuinnNY+GjYOisjgxTpaJnFhS9JJrLkOQ=
Received: by 10.82.136.4 with SMTP id j4mr48067bud.1182296596440;
        Tue, 19 Jun 2007 16:43:16 -0700 (PDT)
Received: by 10.82.163.10 with HTTP; Tue, 19 Jun 2007 16:43:16 -0700 (PDT)
Message-ID: <45be5cd40706191643h51c3a771r67c31d4761ccb634@mail.gmail.com>
Date: Tue, 19 Jun 2007 19:43:16 -0400
From: "Bob Wyman" <bob@wyman.us>
To: "Paul Hoffman" <phoffman@imc.org>
Subject: Re: Atom protocol and digital signatures
Cc: "Bjoern Hoehrmann" <derhoermi@gmx.net>,
        "Sam Hartman" <hartmans-ietf@mit.edu>, atom-syntax@imc.org,
        atom-protocol@imc.org, atompub-ads@tools.ietf.org
In-Reply-To: <p06240820c29e075ddfa1@10.20.30.108>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <tslr6oa9yls.fsf@mit.edu> <p06240818c29ddcf53388@10.20.30.108>
	 <467831BE.7090604@gmail.com> <p0624081bc29dea9b6661@10.20.30.108>
	 <ajhg73h2vp41jbvcfbcoela2qb2knsha5e@hive.bjoern.hoehrmann.de>
	 <p06240820c29e075ddfa1@10.20.30.108>
X-Google-Sender-Auth: 5f8c0e5795fe24d4
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581


I think it should be remembered that signed Atom entries *do* make a
great deal of sense within the context of the Atom formatted documents
-- whatever difficulties that they may cause in the protocol
discussion.

One important use-case discussed during the definition of the Atom
syntax was that of aggregate or synthetic feeds. (i.e. feeds that are
composed of entries taken from more than one other feed).  The current
syntax allows one to preserve a signed entry in an aggregate feed --
as long as the signed entry had an atom:source element when it was
originally signed.

If the protocol can't preserve the signature associated with an entry
provided by a client, then it would seem that the protocol can't be
used to construct an aggregated feed that preserves the integrity of
properly signed atom entries extracted from other feeds. That is
unfortunate and seems extremely non-optimal.

bob wyman




From owner-atom-syntax@mail.imc.org Tue Jun 19 20:09:42 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0nlW-0002Fz-Od
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 20:09:42 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0nlV-0000jV-C9
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 20:09:42 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JNjCMG008578
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Jun 2007 16:45:12 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5JNjBx5008576;
	Tue, 19 Jun 2007 16:45:11 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5JNj9fC008554
	for <atom-syntax@imc.org>; Tue, 19 Jun 2007 16:45:10 -0700 (MST)
	(envelope-from pagaltzis@gmx.de)
Received: (qmail invoked by alias); 19 Jun 2007 23:45:09 -0000
Received: from static-87-79-236-202.netcologne.de (EHLO klangraum) [87.79.236.202]
  by mail.gmx.net (mp008) with SMTP; 20 Jun 2007 01:45:09 +0200
X-Authenticated: #163624
X-Provags-ID: V01U2FsdGVkX19S94UZ6CNSawSTvBTCpA/VJ13VwJFBEABURhHkpK
	l/S4dqXIAtlWpn
Date: Wed, 20 Jun 2007 01:45:08 +0200
From: "A. Pagaltzis" <pagaltzis@gmx.de>
To: atom-syntax@imc.org, atom-protocol@imc.org
Subject: Re: Atom protocol and digital signatures
Message-ID: <20070619234508.GN24708@klangraum>
Mail-Followup-To: atom-syntax@imc.org, atom-protocol@imc.org
References: <tslr6oa9yls.fsf@mit.edu> <p06240818c29ddcf53388@[10.20.30.108]> <467831BE.7090604@gmail.com> <E23C6B3F-AF69-427A-97BA-CFB5931AF3E9@sun.com> <4678417F.9010507@gmail.com> <5CEAEF94-0CE5-4322-972A-B80AC6FE9BBA@Sun.COM> <p0624081fc29e074edc3c@[10.20.30.108]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <p0624081fc29e074edc3c@[10.20.30.108]>
User-Agent: Mutt/1.4.2.1i
X-Y-GMX-Trusted: 0
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a


* Paul Hoffman <phoffman@imc.org> [2007-06-20 00:40]:
> At 1:59 PM -0700 6/19/07, Tim Bray wrote:
> >On Jun 19, 2007, at 1:50 PM, James M Snell wrote:
> >>  Because servers allow allowed (and in some cases required)
> >>  to modify the contents of an Entry Document before
> >>  publishing it, signatures within an entry will likely only
> >>  be useful to the server to which it is being sent. Clients
> >>  cannot assume that the signature will be valid when viewed
> >>  by a third part, or that the server will event publish
> >>  client's signature.
> >
> >I think that's an improvement.  -T
> 
> s/third part/third party/
> s/event publish/even publish the/

Also:

s/allow allowed/are allowed/

:-)

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>




From owner-atom-syntax@mail.imc.org Tue Jun 19 20:20:10 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0nve-0002tD-2n
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 20:20:10 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0nvc-0007pe-Ky
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 20:20:10 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JNwMU0012544
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Jun 2007 16:58:23 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5JNwMmN012541;
	Tue, 19 Jun 2007 16:58:22 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5JNwKDU012529
	for <atom-syntax@imc.org>; Tue, 19 Jun 2007 16:58:21 -0700 (MST)
	(envelope-from pagaltzis@gmx.de)
Received: (qmail invoked by alias); 19 Jun 2007 23:58:20 -0000
Received: from static-87-79-236-202.netcologne.de (EHLO klangraum) [87.79.236.202]
  by mail.gmx.net (mp027) with SMTP; 20 Jun 2007 01:58:20 +0200
X-Authenticated: #163624
X-Provags-ID: V01U2FsdGVkX1/Uo0dVKzfUby4MyGLtEAy6956UfibZ9RPAnmxEqg
	dyeMubzIpbih3r
Date: Wed, 20 Jun 2007 01:58:19 +0200
From: "A. Pagaltzis" <pagaltzis@gmx.de>
To: Atom WG Syndication Format <atom-syntax@imc.org>
Cc: Atom Publishing Protocol <atom-protocol@imc.org>
Subject: Re: Entities in XHTML
Message-ID: <20070619235819.GO24708@klangraum>
Mail-Followup-To: atom-syntax@imc.org
References: <EF14FE208FC8364F94E8A58EF085979A177A606672@NA-EXMSG-C109.redmond.corp.microsoft.com> <46782BE4.30206@gmail.com> <EF14FE208FC8364F94E8A58EF085979A177A6066AD@NA-EXMSG-C109.redmond.corp.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <EF14FE208FC8364F94E8A58EF085979A177A6066AD@NA-EXMSG-C109.redmond.corp.microsoft.com>
User-Agent: Mutt/1.4.2.1i
X-Y-GMX-Trusted: 0
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id l5JNwMU0012544
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336


* Joe Cheng <Joe.Cheng@microsoft.com> [2007-06-19 21:35]:
> * James M Snell <jasnell@gmail.com> [2007-06-19 21:30]:
> > * Joe Cheng <Joe.Cheng@microsoft.com> [2007-06-19 21:05]:
> > > How should implementers deal with entities in XHTML
> > > payloads? I'm sure this is a generic XML question that many
> > > on this list have dealt with before and was wondering if
> > > there is some consensus as to the best practice.
> > >=20
> > > As I understand it, you can't just slap in a &copy; into an
> > > XML document and expect it to be interpreted as the
> > > copyright symbol. You need to declare the entity
> > > explicitly, or bring in a DTD, or use the &#nnn; form. Is
> > > that right?
> >=20
> > Folks should be using the numeric character references rather
> > than the entities.
>=20
> Thanks, I'm glad I asked--that would not have been my guess.
>=20
> Is that a fairly uncontroversial stance these days? I have been
> surprised at how much some users are concerned about the
> aesthetics of their (X)HTML (although I admit I have not heard
> anything specifically about the use of named vs. numeric
> entities).

If you=E2=80=99re including unescaped well-formed XHTML with
type=3D"xhtml", then you *can=E2=80=99t* include named entities, because
there=E2=80=99s no DTD on the document to declare them, so using them
would just render the document malformed. If the document is in
some national encoding like US-ASCII or Latin-1, then you don=E2=80=99t
*have* any other choice than using numeric char refs.

If the document is in UTF-8 or another Unicode encoding, I
wouldn=E2=80=99t bother with NCRs at all and would just include the
literal characters.

If you=E2=80=99re putting escaped tagsoup in type=3D"html" content, then
of course you can just include double-escaped named entities.

(This is really an issue for atom-syntax, btw, not atom-protocol;
re-routing there.)

Regards,
--=20
Aristotle Pagaltzis // <http://plasmasturm.org/>




From owner-atom-syntax@mail.imc.org Tue Jun 19 20:27:47 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0o31-0008N6-LM
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 20:27:47 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0o30-00024f-8K
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 20:27:47 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5K02uXa014183
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Jun 2007 17:02:56 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5K02ubC014182;
	Tue, 19 Jun 2007 17:02:56 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.229])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5K02pNG014131
	for <atom-syntax@imc.org>; Tue, 19 Jun 2007 17:02:55 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by wx-out-0506.google.com with SMTP id s16so3245wxc
        for <atom-syntax@imc.org>; Tue, 19 Jun 2007 17:02:50 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed;
        d=gmail.com; s=beta;
        h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=QCxbldB99TCfBwETOCZvVCjetCMJwpz54YjRm4FAYlMc7sFVVwllveRYi2tsAAUDM38Xc8twid5lRVcwEaQIpjBc1hmvA0RzCHgTMH/lGEU36E/ORTkvKDOxrmU6Tz0E/e7LooJeV4BAh6f/S2r8uN7AdwZK4M0ViiOdjAKUQhI=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=XdxgGtyGXsr6rjBhExsxQ/ymEonmERDS+IjPG3ifMwsJOBFXydrqmOcQLVaqBPM5Wq4SIicOcX+2P0iJPlUqu3Mo+GSH0vOgdcRhkOEpUrQGlgPIAeA5+T0yKvd5jhE1HT5MwRKZPVpUmOkBC3zV+D5lvvSAcsLGDwxOP3vUEZg=
Received: by 10.70.60.7 with SMTP id i7mr30711wxa.1182297770769;
        Tue, 19 Jun 2007 17:02:50 -0700 (PDT)
Received: from ?192.168.1.118? ( [67.181.218.96])
        by mx.google.com with ESMTP id 74sm60518wra.2007.06.19.17.02.49
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Tue, 19 Jun 2007 17:02:50 -0700 (PDT)
Message-ID: <46786EA7.8070708@gmail.com>
Date: Tue, 19 Jun 2007 17:02:47 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.0 (X11/20070326)
MIME-Version: 1.0
To: Bob Wyman <bob@wyman.us>
CC: Paul Hoffman <phoffman@imc.org>, Bjoern Hoehrmann <derhoermi@gmx.net>,
        Sam Hartman <hartmans-ietf@mit.edu>, atom-syntax@imc.org,
        atom-protocol@imc.org, atompub-ads@tools.ietf.org
Subject: Re: Atom protocol and digital signatures
References: <tslr6oa9yls.fsf@mit.edu> <p06240818c29ddcf53388@10.20.30.108>	 <467831BE.7090604@gmail.com> <p0624081bc29dea9b6661@10.20.30.108>	 <ajhg73h2vp41jbvcfbcoela2qb2knsha5e@hive.bjoern.hoehrmann.de>	 <p06240820c29e075ddfa1@10.20.30.108> <45be5cd40706191643h51c3a771r67c31d4761ccb634@mail.gmail.com>
In-Reply-To: <45be5cd40706191643h51c3a771r67c31d4761ccb634@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2


The main point of this discussion is that what happens is completely up
to the server implementation.  It is entirely possible for a particular
server to do exactly what you are suggesting.  However, it is impossible
for a client to make any assumptions about how a server will treat
signed entries without prior specific knowledge of that server.

- James

Bob Wyman wrote:
> 
> I think it should be remembered that signed Atom entries *do* make a
> great deal of sense within the context of the Atom formatted documents
> -- whatever difficulties that they may cause in the protocol
> discussion.
> 
> One important use-case discussed during the definition of the Atom
> syntax was that of aggregate or synthetic feeds. (i.e. feeds that are
> composed of entries taken from more than one other feed).  The current
> syntax allows one to preserve a signed entry in an aggregate feed --
> as long as the signed entry had an atom:source element when it was
> originally signed.
> 
> If the protocol can't preserve the signature associated with an entry
> provided by a client, then it would seem that the protocol can't be
> used to construct an aggregated feed that preserves the integrity of
> properly signed atom entries extracted from other feeds. That is
> unfortunate and seems extremely non-optimal.
> 
> bob wyman
> 
> 




From owner-atom-syntax@mail.imc.org Tue Jun 19 21:04:24 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0ocS-0001rA-3U
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 21:04:24 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0ocQ-0006aL-Mz
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 21:04:24 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5K0eTNt024493
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Jun 2007 17:40:29 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5K0eTQo024492;
	Tue, 19 Jun 2007 17:40:29 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [10.20.30.108] (adsl-66-125-125-71.dsl.pltn13.pacbell.net [66.125.125.71])
	(authenticated bits=0)
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5K0eOoP024471
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Jun 2007 17:40:25 -0700 (MST)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: <p06240826c29e26923022@[10.20.30.108]>
In-Reply-To: <20070619234334.GM24708@klangraum>
References: <tslr6oa9yls.fsf@mit.edu>
 <p06240818c29ddcf53388@[10.20.30.108]> <20070619234334.GM24708@klangraum>
Date: Tue, 19 Jun 2007 17:40:09 -0700
To: "A. Pagaltzis" <pagaltzis@gmx.de>, atom-syntax@imc.org,
        atom-protocol@imc.org
From: Paul Hoffman <phoffman@imc.org>
Subject: Re: Atom protocol and digital signatures
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca


At 1:43 AM +0200 6/20/07, A. Pagaltzis wrote:
>* Paul Hoffman <phoffman@imc.org> [2007-06-19 21:40]:
>>  The method for a server to indicate to a third party whether or
>>  not the client signed an Entry Document is by including the
>>  client's signature in the published entry, even though that
>>  signature is likely to be invalid.
>
>I strongly disagree with this. As a consumer, I have no possible
>way to know whether an invalid signature is there because
>
>* the publishing client included it
>* the server made up a signature to feign signing by the client
>* a third party tampered with the entry between the server and me
>
>Therefore as a consumer I would never ever assume that an invalid
>signature meant anything else than that the signature on this
>entry is not valid.

Fully agree so far.

>Encouraging servers

Stop right there. Nothing in the quoted text *encourages* anyone. We 
said that there was a method, which is completely true. We also said 
that this is "the" method, which is also completely true (we didn't 
create another method). That is a far cry from encouragement.

>If the server is not, though, then it really should strip the
>signature if it knows it has invalidated it. Note that my
>proposed text said "strongly encouraged", not "SHOULD". After
>all, it is not an interop concern, nor do I desire to dictate
>server behaviour.

The WG has gone out of its way to put as few restrictions on servers 
as possible, and to minimize the number of "encouragements" (much 
less strong encouragements). I took that earlier direction to heart 
in the above paragraph.

If the WG wants to make a strong encouragement here, that's fine, but 
we do so against our earlier trend.

>However, I do think this particular implementation choice
>makes a lot of sense and should be the default choice for
>server implementors who don't have specific reason to do
>things otherwise. And I think the spec should nudge them in
>that direction.

Given that this is the Security Considerations section, we should 
have a security reason for the nudge. I don't think we have one. 
There is no security problem with publishing a known-bad signature.




From owner-atom-syntax@mail.imc.org Tue Jun 19 21:19:56 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0orU-0004hG-KJ
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 21:19:56 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0orT-0004d9-6j
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 21:19:56 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5K0ZtBX023318
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Jun 2007 17:35:55 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5K0ZtwT023317;
	Tue, 19 Jun 2007 17:35:55 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5K0ZrUV023288;
	Tue, 19 Jun 2007 17:35:54 -0700 (MST)
	(envelope-from Tim.Bray@Sun.COM)
Received: from fe-amer-05.sun.com ([192.18.108.179])
	by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5K0Zniw007996;
	Wed, 20 Jun 2007 00:35:53 GMT
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 id <0JJW00601SBKLO00@mail-amer.sun.com> (original mail from Tim.Bray@Sun.COM)
 ; Tue, 19 Jun 2007 18:35:48 -0600 (MDT)
Received: from [192.168.1.56] (fatwire-35-165.uniserve.ca [204.174.35.214])
 by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 with ESMTPSA id <0JJW00EV7SBNUN00@mail-amer.sun.com>; Tue,
 19 Jun 2007 18:35:48 -0600 (MDT)
Date: Tue, 19 Jun 2007 17:35:15 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Atom protocol and digital signatures
In-reply-to: <20070619234334.GM24708@klangraum>
To: "A. Pagaltzis" <pagaltzis@gmx.de>
Cc: atom-syntax@imc.org, atom-protocol@imc.org
Message-id: <0FCD819E-A3CA-47C7-9624-3FA4FFF5BBFF@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.752.3)
Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII
Content-transfer-encoding: 7BIT
References: <tslr6oa9yls.fsf@mit.edu> <p06240818c29ddcf53388@[10.20.30.108]>
 <20070619234334.GM24708@klangraum>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c


On Jun 19, 2007, at 4:43 PM, A. Pagaltzis wrote:

>> The method for a server to indicate to a third party whether or
>> not the client signed an Entry Document is by including the
>> client's signature in the published entry, even though that
>> signature is likely to be invalid.
>
> I strongly disagree with this. As a consumer, I have no possible
> way to know whether an invalid signature is there because

I have to agree with Aristotle on this one.  I think we should simply  
drop that last sentence.  -Tim





From owner-atom-syntax@mail.imc.org Tue Jun 19 21:34:47 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0p5r-0001WV-Sy
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 21:34:47 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0p5q-00089K-HD
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 21:34:47 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5K1DSos033198
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Jun 2007 18:13:28 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5K1DSJ9033189;
	Tue, 19 Jun 2007 18:13:28 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [10.20.30.108] (adsl-66-125-125-71.dsl.pltn13.pacbell.net [66.125.125.71])
	(authenticated bits=0)
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5K1DM1L033162
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Jun 2007 18:13:23 -0700 (MST)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: <p06240828c29e2f644169@[10.20.30.108]>
In-Reply-To: <0FCD819E-A3CA-47C7-9624-3FA4FFF5BBFF@sun.com>
References: <tslr6oa9yls.fsf@mit.edu>
 <p06240818c29ddcf53388@[10.20.30.108]> <20070619234334.GM24708@klangraum>
 <0FCD819E-A3CA-47C7-9624-3FA4FFF5BBFF@sun.com>
Date: Tue, 19 Jun 2007 18:13:10 -0700
To: Tim Bray <Tim.Bray@Sun.COM>, "A. Pagaltzis" <pagaltzis@gmx.de>
From: Paul Hoffman <phoffman@imc.org>
Subject: Re: Atom protocol and digital signatures
Cc: atom-syntax@imc.org, atom-protocol@imc.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f


At 5:35 PM -0700 6/19/07, Tim Bray wrote:
>On Jun 19, 2007, at 4:43 PM, A. Pagaltzis wrote:
>
>>>The method for a server to indicate to a third party whether or
>>>not the client signed an Entry Document is by including the
>>>client's signature in the published entry, even though that
>>>signature is likely to be invalid.
>>
>>I strongly disagree with this. As a consumer, I have no possible
>>way to know whether an invalid signature is there because
>
>I have to agree with Aristotle on this one.  I think we should 
>simply drop that last sentence.  -Tim

Not to be picky, but you are not agreeing with Aristotle. He wants to 
change this sentence to a strong encouragement to strip the signature.




From owner-atom-syntax@mail.imc.org Tue Jun 19 22:45:18 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I0qC6-0005MK-7F
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 22:45:18 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I0qC4-000383-OU
	for atompub-archive@lists.ietf.org; Tue, 19 Jun 2007 22:45:18 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5K2K6sc046857
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Jun 2007 19:20:06 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5K2K6pc046855;
	Tue, 19 Jun 2007 19:20:06 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5K2K3r0046842
	for <atom-syntax@imc.org>; Tue, 19 Jun 2007 19:20:04 -0700 (MST)
	(envelope-from pagaltzis@gmx.de)
Received: (qmail invoked by alias); 20 Jun 2007 02:20:03 -0000
Received: from static-87-79-236-202.netcologne.de (EHLO klangraum) [87.79.236.202]
  by mail.gmx.net (mp037) with SMTP; 20 Jun 2007 04:20:03 +0200
X-Authenticated: #163624
X-Provags-ID: V01U2FsdGVkX18r/LJwDhcrQH4+kVJp8NYIB/B0m1Eg0SSTKwT/wc
	3IzltYYNEmj4HC
Date: Wed, 20 Jun 2007 04:20:02 +0200
From: "A. Pagaltzis" <pagaltzis@gmx.de>
To: atom-syntax@imc.org, atom-protocol@imc.org
Subject: Re: Atom protocol and digital signatures
Message-ID: <20070620022002.GP24708@klangraum>
Mail-Followup-To: atom-syntax@imc.org, atom-protocol@imc.org
References: <tslr6oa9yls.fsf@mit.edu> <p06240818c29ddcf53388@[10.20.30.108]> <20070619234334.GM24708@klangraum> <p06240826c29e26923022@[10.20.30.108]>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <p06240826c29e26923022@[10.20.30.108]>
User-Agent: Mutt/1.4.2.1i
X-Y-GMX-Trusted: 0
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id l5K2K6sc046857
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1


Hi Paul,

* Paul Hoffman <phoffman@imc.org> [2007-06-20 02:50]:
>=20
> At 1:43 AM +0200 6/20/07, A. Pagaltzis wrote:
> >* Paul Hoffman <phoffman@imc.org> [2007-06-19 21:40]:
> >> The method for a server to indicate to a third party whether
> >> or not the client signed an Entry Document is by including
> >> the client's signature in the published entry, even though
> >> that signature is likely to be invalid.
>=20
> >Encouraging servers
>=20
> Stop right there. Nothing in the quoted text *encourages*
> anyone. We said that there was a method, which is completely
> true.

No, it is entirely false, because cryptographically, a consumer
has no way whatsoever to know whether the signature was
originally valid and where that once supposedly valid signature
originally came from.

A consumer cannot assume *anything* about an entry with an
invalid signature other than that it is an entry with an invalid
signature.

> We also said that this is "the" method, which is also
> completely true (we didn't create another method).

This is false, by extension from the previous sentence being
false; and so we didn=E2=80=99t create any method for this at all, which
makes this claim doubly false.

> That is a far cry from encouragement.

I don=E2=80=99t understand how this first sentence doesn=E2=80=99t stand =
in
complete contradiction with the previous ones. Sure, servers
might not desire to signal to consumers that the entry was signed
by the client, in which case the paragraph in your proposed spec
text would not act as encouragement. But for those servers who
wish to do so, you are practically telling them to publish the
invalid signature.

Sure it doesn=E2=80=99t encourage all servers, but that seems like hair-
splitting. It does encourage a subset of servers, and more
importantly, the most significant subset of servers as far as
this issue is concerned. If you need me to thusly qualify my
claim that we=E2=80=99d be encouraging servers to publish invalid
signatures, that=E2=80=99s fine with me, but that=E2=80=99s still what we=
=E2=80=99d be
doing.

> Given that this is the Security Considerations section, we
> should have a security reason for the nudge. I don't think we
> have one. There is no security problem with publishing a
> known-bad signature.

Not a first-order effect, no. Certainly a second-order one,
though; no one is served by a situation where consumers can=E2=80=99t
unconditionally reject entries with broken signatures. Except
the bad guys, anyway.

> If the WG wants to make a strong encouragement here, that's
> fine, but we do so against our earlier trend.

If you want me to tone down the language and avoid
encouragements, I guess that=E2=80=99s fine. Just as well to spell out
the rationale and leave the conclusion to implementors:

    A server is allowed to strip client-applied signatures, to
    strip client-applied signatures and then re-sign with its own
    public key, and to oversign an entry with its own public key.
    The meaning to a third party of a signature applied by a
    server is the same as a signature from anyone, as described
    in [RFC4287]. Third parties may choose to unconditionally
    reject entries with invalid signatures as they cannot
    possibly make any assumption about the origin of such a
    signature and its validity at any previous point in time.

Regards,
--=20
Aristotle Pagaltzis // <http://plasmasturm.org/>




From owner-atom-syntax@mail.imc.org Wed Jun 20 12:28:54 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I1337-0003Xm-TO
	for atompub-archive@lists.ietf.org; Wed, 20 Jun 2007 12:28:54 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I1337-0007dK-HF
	for atompub-archive@lists.ietf.org; Wed, 20 Jun 2007 12:28:53 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5KFrdPI091919
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 20 Jun 2007 08:53:39 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5KFrdeW091917;
	Wed, 20 Jun 2007 08:53:39 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169])
	(authenticated bits=0)
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5KFlbhe091509
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 20 Jun 2007 08:47:38 -0700 (MST)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: <p06240843c29ef7e46d4a@[10.20.30.108]>
In-Reply-To: <20070620022002.GP24708@klangraum>
References: <tslr6oa9yls.fsf@mit.edu>
 <p06240818c29ddcf53388@[10.20.30.108]> <20070619234334.GM24708@klangraum>
 <p06240826c29e26923022@[10.20.30.108]> <20070620022002.GP24708@klangraum>
Date: Wed, 20 Jun 2007 08:46:06 -0700
To: "A. Pagaltzis" <pagaltzis@gmx.de>, atom-syntax@imc.org,
        atom-protocol@imc.org
From: Paul Hoffman <phoffman@imc.org>
Subject: Re: Atom protocol and digital signatures
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002


At 4:20 AM +0200 6/20/07, A. Pagaltzis wrote:
>Hi Paul,
>
>* Paul Hoffman <phoffman@imc.org> [2007-06-20 02:50]:
>>
>>  At 1:43 AM +0200 6/20/07, A. Pagaltzis wrote:
>>  >* Paul Hoffman <phoffman@imc.org> [2007-06-19 21:40]:
>>  >> The method for a server to indicate to a third party whether
>>  >> or not the client signed an Entry Document is by including
>>  >> the client's signature in the published entry, even though
>>  >> that signature is likely to be invalid.
>>
>>  >Encouraging servers
>>
>>  Stop right there. Nothing in the quoted text *encourages*
>>  anyone. We said that there was a method, which is completely
>>  true.
>
>No, it is entirely false, because cryptographically, a consumer
>has no way whatsoever to know whether the signature was
>originally valid and where that once supposedly valid signature
>originally came from.

It is not "entirely false", it is still true that this is a method 
for saying it was signed. However, you are completely correct that it 
is not a method for saying that it was a valid signature. That is 
quite relevant.

>A consumer cannot assume *anything* about an entry with an
>invalid signature other than that it is an entry with an invalid
>signature.

Fully agree. And I can see how even talking about leaving invalid 
signatures in can be considered an encouragement, even if it is a 
light encouragement.

Given this, I propose changing the paragraph to:

A server is allowed to strip client-applied signatures, to strip 
client-applied signatures and then re-sign with its own public key, 
and to oversign an entry with its own public key. The meaning to a 
third party of a signature applied by a server is the same as a 
signature from anyone, as described in [RFC4287]. It is recommended 
that a server that is aware that it has changed any part of an Entry 
Document that was signed by the client should strip that signature 
before publishing the entry in order to prevent third parties from 
trying to interpret a signature that cannot be validated.




From owner-atom-syntax@mail.imc.org Wed Jun 20 12:53:20 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I13Qm-00061w-Rw
	for atompub-archive@lists.ietf.org; Wed, 20 Jun 2007 12:53:20 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I13Qi-0005dg-E0
	for atompub-archive@lists.ietf.org; Wed, 20 Jun 2007 12:53:20 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5KGWnCm098179
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 20 Jun 2007 09:32:50 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5KGWnNc098178;
	Wed, 20 Jun 2007 09:32:49 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5KGWlU8098155
	for <atom-syntax@imc.org>; Wed, 20 Jun 2007 09:32:48 -0700 (MST)
	(envelope-from pagaltzis@gmx.de)
Received: (qmail invoked by alias); 20 Jun 2007 16:32:46 -0000
Received: from static-87-79-236-202.netcologne.de (EHLO klangraum) [87.79.236.202]
  by mail.gmx.net (mp033) with SMTP; 20 Jun 2007 18:32:46 +0200
X-Authenticated: #163624
X-Provags-ID: V01U2FsdGVkX19shX8q5Ths6c7zTdsurAWXnsYR0IzCpvMNjp+JHB
	4nU3osB3qCjj/T
Date: Wed, 20 Jun 2007 18:32:45 +0200
From: "A. Pagaltzis" <pagaltzis@gmx.de>
To: Paul Hoffman <phoffman@imc.org>
Cc: atom-syntax@imc.org, atom-protocol@imc.org
Subject: Re: Atom protocol and digital signatures
Message-ID: <20070620163245.GU24708@klangraum>
Mail-Followup-To: Paul Hoffman <phoffman@imc.org>, atom-syntax@imc.org,
	atom-protocol@imc.org
References: <tslr6oa9yls.fsf@mit.edu> <p06240818c29ddcf53388@[10.20.30.108]> <20070619234334.GM24708@klangraum> <p06240826c29e26923022@[10.20.30.108]> <20070620022002.GP24708@klangraum> <p06240843c29ef7e46d4a@[10.20.30.108]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <p06240843c29ef7e46d4a@[10.20.30.108]>
User-Agent: Mutt/1.4.2.1i
X-Y-GMX-Trusted: 0
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581


* Paul Hoffman <phoffman@imc.org> [2007-06-20 17:55]:
> Given this, I propose changing the paragraph to:
> 
> A server is allowed to strip client-applied signatures, to
> strip client-applied signatures and then re-sign with its own
> public key, and to oversign an entry with its own public key.
> The meaning to a third party of a signature applied by a server
> is the same as a signature from anyone, as described in
> [RFC4287]. It is recommended that a server that is aware that
> it has changed any part of an Entry Document that was signed by
> the client should strip that signature before publishing the
> entry in order to prevent third parties from trying to
> interpret a signature that cannot be validated.

That is perfectly fine with me. Thank you.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>




From owner-atom-syntax@mail.imc.org Wed Jun 20 13:09:06 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I13g2-0000Vi-2u
	for atompub-archive@lists.ietf.org; Wed, 20 Jun 2007 13:09:06 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I13g0-0008OL-LN
	for atompub-archive@lists.ietf.org; Wed, 20 Jun 2007 13:09:06 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5KGmVur001894
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 20 Jun 2007 09:48:31 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5KGmVYd001893;
	Wed, 20 Jun 2007 09:48:31 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5KGmTaT001875;
	Wed, 20 Jun 2007 09:48:30 -0700 (MST)
	(envelope-from Tim.Bray@Sun.COM)
Received: from fe-amer-03.sun.com ([192.18.108.177])
	by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5KGmTKx008533;
	Wed, 20 Jun 2007 16:48:29 GMT
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 id <0JJX00M01YP9UM00@mail-amer.sun.com> (original mail from Tim.Bray@Sun.COM)
 ; Wed, 20 Jun 2007 10:48:29 -0600 (MDT)
Received: from [192.168.102.100]
 (d154-20-170-13.bchsia.telus.net [154.20.170.13])
 by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr  3
 2006)) with ESMTPSA id <0JJY00DAE1AQBFA0@mail-amer.sun.com>; Wed,
 20 Jun 2007 10:48:13 -0600 (MDT)
Date: Wed, 20 Jun 2007 09:47:37 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Atom protocol and digital signatures
In-reply-to: <p06240843c29ef7e46d4a@[10.20.30.108]>
To: Paul Hoffman <phoffman@imc.org>
Cc: "A. Pagaltzis" <pagaltzis@gmx.de>, atom-syntax@imc.org,
        atom-protocol@imc.org
Message-id: <BFDE68FF-7AB6-4587-A0D2-47CBB09714D9@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.752.3)
Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII
Content-transfer-encoding: 7BIT
References: <tslr6oa9yls.fsf@mit.edu> <p06240818c29ddcf53388@[10.20.30.108]>
 <20070619234334.GM24708@klangraum> <p06240826c29e26923022@[10.20.30.108]>
 <20070620022002.GP24708@klangraum> <p06240843c29ef7e46d4a@[10.20.30.108]>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126


On Jun 20, 2007, at 8:46 AM, Paul Hoffman wrote:

>
> A server is allowed to strip client-applied signatures, to strip  
> client-applied signatures and then re-sign with its own public key,  
> and to oversign an entry with its own public key. The meaning to a  
> third party of a signature applied by a server is the same as a  
> signature from anyone, as described in [RFC4287]. It is recommended  
> that a server that is aware that it has changed any part of an  
> Entry Document that was signed by the client should strip that  
> signature before publishing the entry in order to prevent third  
> parties from trying to interpret a signature that cannot be validated.

Works for me -T


>




From owner-atom-syntax@mail.imc.org Wed Jun 20 13:20:18 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I13qs-0008Fq-GX
	for atompub-archive@lists.ietf.org; Wed, 20 Jun 2007 13:20:18 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1I13qq-00010r-Ty
	for atompub-archive@lists.ietf.org; Wed, 20 Jun 2007 13:20:18 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5KGw1XT003447
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 20 Jun 2007 09:58:01 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5KGw1AZ003446;
	Wed, 20 Jun 2007 09:58:01 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.226])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5KGvxQG003429
	for <atom-syntax@imc.org>; Wed, 20 Jun 2007 09:58:00 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by wx-out-0506.google.com with SMTP id s16so219044wxc
        for <atom-syntax@imc.org>; Wed, 20 Jun 2007 09:57:57 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed;
        d=gmail.com; s=beta;
        h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=oRbl71s3FeWaUXCsumIkSz+6rEeLd0pEjGMHHdnW4iaYWYo/NAfpF9hUGNZT25vOjWfa3FjhHLLcvfCBFh313940pliVstM3PWieODKtoMGZLpX3GyBg2Tue8UvP+SlLhj+wQ+y/UI92+1zqvV2F38abEKtS8agRM3aSNB2WYKc=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=ki5P/3K2bU/W26LSJOz0irVU7M9FefZ8WvXrwDMYl5G+tgi1Q3WkDl/ZTLqZT1GB5jQR47kuiWOhD3XPi7BRxDJukWeIBGf0GNZK2oihcV+KtkdNqKSY+SfVcOBBlZUzua8GSlX/hr4hnSJiG06xVXd995EMQSd2Ed1Us68juYQ=
Received: by 10.90.105.19 with SMTP id d19mr689825agc.1182358677494;
        Wed, 20 Jun 2007 09:57:57 -0700 (PDT)
Received: from ?192.168.1.118? ( [67.181.218.96])
        by mx.google.com with ESMTP id 26sm1060823wra.2007.06.20.09.57.42
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Wed, 20 Jun 2007 09:57:43 -0700 (PDT)
Message-ID: <46795C84.40504@gmail.com>
Date: Wed, 20 Jun 2007 09:57:40 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.0 (X11/20070326)
MIME-Version: 1.0
To: Tim Bray <Tim.Bray@Sun.COM>
CC: Paul Hoffman <phoffman@imc.org>, "A. Pagaltzis" <pagaltzis@gmx.de>,
        atom-syntax@imc.org, atom-protocol@imc.org
Subject: Re: Atom protocol and digital signatures
References: <tslr6oa9yls.fsf@mit.edu> <p06240818c29ddcf53388@[10.20.30.108]> <20070619234334.GM24708@klangraum> <p06240826c29e26923022@[10.20.30.108]> <20070620022002.GP24708@klangraum> <p06240843c29ef7e46d4a@[10.20.30.108]> <BFDE68FF-7AB6-4587-A0D2-47CBB09714D9@sun.com>
In-Reply-To: <BFDE68FF-7AB6-4587-A0D2-47CBB09714D9@sun.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32


+1

Tim Bray wrote:
> 
> On Jun 20, 2007, at 8:46 AM, Paul Hoffman wrote:
> 
>>
>> A server is allowed to strip client-applied signatures, to strip
>> client-applied signatures and then re-sign with its own public key,
>> and to oversign an entry with its own public key. The meaning to a
>> third party of a signature applied by a server is the same as a
>> signature from anyone, as described in [RFC4287]. It is recommended
>> that a server that is aware that it has changed any part of an Entry
>> Document that was signed by the client should strip that signature
>> before publishing the entry in order to prevent third parties from
>> trying to interpret a signature that cannot be validated.
> 
> Works for me -T
> 
> 
>>
> 
> 




From owner-atom-syntax@mail.imc.org Wed Jun 20 13:37:55 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I147v-0001A6-9D
	for atompub-archive@lists.ietf.org; Wed, 20 Jun 2007 13:37:55 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I147s-00053o-SJ
	for atompub-archive@lists.ietf.org; Wed, 20 Jun 2007 13:37:55 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5KHGo0v008869
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 20 Jun 2007 10:16:50 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5KHGooJ008868;
	Wed, 20 Jun 2007 10:16:50 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.171])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5KHGnnR008843;
	Wed, 20 Jun 2007 10:16:49 -0700 (MST)
	(envelope-from john.kemp@mac.com)
Received: from mac.com (smtpin02-en2 [10.13.10.147])
	by smtpout.mac.com (Xserve/smtpout01/MantshX 4.0) with ESMTP id l5KHGlFD015572;
	Wed, 20 Jun 2007 10:16:47 -0700 (PDT)
Received: from [192.168.1.115] (cpe-69-205-56-47.nycap.res.rr.com [69.205.56.47])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id l5KHGi3L017626;
	Wed, 20 Jun 2007 10:16:45 -0700 (PDT)
Message-ID: <467960FC.2040903@mac.com>
Date: Wed, 20 Jun 2007 13:16:44 -0400
From: John Kemp <john.kemp@mac.com>
User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509)
MIME-Version: 1.0
To: Paul Hoffman <phoffman@imc.org>
CC: "A. Pagaltzis" <pagaltzis@gmx.de>, atom-syntax@imc.org,
        atom-protocol@imc.org
Subject: Re: Atom protocol and digital signatures
References: <tslr6oa9yls.fsf@mit.edu> <p06240818c29ddcf53388@[10.20.30.108]> <20070619234334.GM24708@klangraum> <p06240826c29e26923022@[10.20.30.108]> <20070620022002.GP24708@klangraum> <p06240843c29ef7e46d4a@[10.20.30.108]>
In-Reply-To: <p06240843c29ef7e46d4a@[10.20.30.108]>
X-Enigmail-Version: 0.94.3.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
X-Brightmail-scanned: yes
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2


Hi,

Paul Hoffman wrote:

> Fully agree. And I can see how even talking about leaving invalid
> signatures in can be considered an encouragement, even if it is a light
> encouragement.
> 
> Given this, I propose changing the paragraph to:
> 
> A server is allowed to strip client-applied signatures, to strip
> client-applied signatures and then re-sign with its own public key, and
> to oversign an entry with its own public key. The meaning to a third
> party of a signature applied by a server is the same as a signature from
> anyone, as described in [RFC4287]. It is recommended that a server that
> is aware that it has changed any part of an Entry Document that was
> signed by the client should strip that signature before publishing the
> entry in order to prevent third parties from trying to interpret a
> signature that cannot be validated.
> 

What does it mean to "strip" a signature?

Might it be worth noting that in such cases, the server is recommended
to "remove the child element of the Entry Document with the namespace
URI http://www.w3.org/2000/09/xmldsig# and a local name of Signature"
(as specified for signature addition in RFC4287)?

Regards,

- John Kemp




From owner-atom-syntax@mail.imc.org Wed Jun 20 20:19:33 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I1AOb-0001AN-OO
	for atompub-archive@lists.ietf.org; Wed, 20 Jun 2007 20:19:33 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I1AOa-0001dB-9E
	for atompub-archive@lists.ietf.org; Wed, 20 Jun 2007 20:19:33 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5KNrI3J018048
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 20 Jun 2007 16:53:18 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5KNrI9p018047;
	Wed, 20 Jun 2007 16:53:18 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from docuverse.com (62.92.3845.static.theplanet.com [69.56.146.98])
	by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5KNrH34018035;
	Wed, 20 Jun 2007 16:53:17 -0700 (MST)
	(envelope-from donpark@docuverse.com)
Received: from [192.168.0.103] ([24.23.165.146])
	by docuverse.com
	with hMailServer ; Wed, 20 Jun 2007 18:53:22 -0500
In-Reply-To: <0FCD819E-A3CA-47C7-9624-3FA4FFF5BBFF@sun.com>
References: <tslr6oa9yls.fsf@mit.edu> <p06240818c29ddcf53388@[10.20.30.108]> <20070619234334.GM24708@klangraum> <0FCD819E-A3CA-47C7-9624-3FA4FFF5BBFF@sun.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: multipart/alternative; boundary=Apple-Mail-1-65282686
Message-Id: <BF9FF5B6-771A-406D-A271-B45564D8DEB6@docuverse.com>
Cc: Atom_Syntax <atom-syntax@imc.org>, atom-protocol@imc.org
From: Don Park <donpark@docuverse.com>
Subject: Re: Atom protocol and digital signatures
Date: Wed, 20 Jun 2007 16:50:29 -0700
To: Tim Bray <Tim.Bray@Sun.COM>
X-Mailer: Apple Mail (2.752.3)
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db



--Apple-Mail-1-65282686
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

Just a few passing comments/suggestions:

1. I think requiring signature-breaking servers to detect and remove  
invalidated signatures creates unnecessary chores as well as being a  
potential source of confusion in context of the must-ignore rule.

2. I think it might make more sense to create an extension designed  
to enhanced digital-signature support. Such an extension would  
include a 'marker' element to indicate that signatures within, if  
any, are likely damaged. A feed processing agent downstream can then  
use the marker to avoid alarming the user unnecessarily.

Best,

Don Park


On Jun 19, 2007, at 5:35 PM, Tim Bray wrote:

> On Jun 19, 2007, at 4:43 PM, A. Pagaltzis wrote:
>
>>> The method for a server to indicate to a third party whether or
>>> not the client signed an Entry Document is by including the
>>> client's signature in the published entry, even though that
>>> signature is likely to be invalid.
>>
>> I strongly disagree with this. As a consumer, I have no possible
>> way to know whether an invalid signature is there because
>
> I have to agree with Aristotle on this one.  I think we should  
> simply drop that last sentence.  -Tim


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

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><DIV>Just a few passing =
comments/suggestions:</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>1. I think requiring =
signature-breaking servers to detect and remove invalidated signatures =
creates unnecessary chores as well as being a potential source of =
confusion in context of the must-ignore rule.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>2. I think it might make =
more sense to create an extension designed to enhanced digital-signature =
support. Such an extension would include a 'marker' element to indicate =
that signatures within, if any, are likely damaged. A feed processing =
agent downstream can then use the marker to avoid alarming the user =
unnecessarily.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Best,</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Don Park</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><BR><DIV><DIV>On Jun 19, 2007, =
at 5:35 PM, Tim Bray wrote:</DIV><BR =
class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite"><P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"4" style=3D"font: 13.0px Helvetica">On Jun 19, 2007, at 4:43 PM, =
A. Pagaltzis wrote:</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px =
0.0px; font: 13.0px Helvetica; min-height: 16.0px"><BR></P> <BLOCKQUOTE =
type=3D"cite"><BLOCKQUOTE type=3D"cite"><P style=3D"margin: 0.0px 0.0px =
0.0px 20.0px"><FONT face=3D"Helvetica" size=3D"4" style=3D"font: 13.0px =
Helvetica">The method for a server to indicate to a third party whether =
or</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px 20.0px"><FONT =
face=3D"Helvetica" size=3D"4" style=3D"font: 13.0px Helvetica">not the =
client signed an Entry Document is by including the</FONT></P> <P =
style=3D"margin: 0.0px 0.0px 0.0px 20.0px"><FONT face=3D"Helvetica" =
size=3D"4" style=3D"font: 13.0px Helvetica">client's signature in the =
published entry, even though that</FONT></P> <P style=3D"margin: 0.0px =
0.0px 0.0px 20.0px"><FONT face=3D"Helvetica" size=3D"4" style=3D"font: =
13.0px Helvetica">signature is likely to be invalid.</FONT></P> =
</BLOCKQUOTE><P style=3D"margin: 0.0px 0.0px 0.0px 10.0px; font: 13.0px =
Helvetica; min-height: 16.0px"><BR></P> <P style=3D"margin: 0.0px 0.0px =
0.0px 10.0px"><FONT face=3D"Helvetica" size=3D"4" style=3D"font: 13.0px =
Helvetica">I strongly disagree with this. As a consumer, I have no =
possible</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px 10.0px"><FONT =
face=3D"Helvetica" size=3D"4" style=3D"font: 13.0px Helvetica">way to =
know whether an invalid signature is there because</FONT></P> =
</BLOCKQUOTE><P style=3D"margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px =
Helvetica; min-height: 16.0px"><BR></P> <P style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"4" style=3D"font: 13.0px =
Helvetica">I have to agree with Aristotle on this one.<SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>I think we should simply drop =
that last sentence.<SPAN class=3D"Apple-converted-space">=A0 =
</SPAN>-Tim</FONT></P> </BLOCKQUOTE></DIV><BR></BODY></HTML>=

--Apple-Mail-1-65282686--




From owner-atom-syntax@mail.imc.org Wed Jun 20 20:56:47 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I1Ayd-0004Pg-OO
	for atompub-archive@lists.ietf.org; Wed, 20 Jun 2007 20:56:47 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I1Ayd-0007vn-9n
	for atompub-archive@lists.ietf.org; Wed, 20 Jun 2007 20:56:47 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5L0c272030161
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 20 Jun 2007 17:38:02 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5L0c2fs030160;
	Wed, 20 Jun 2007 17:38:02 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5L0c0Dh030149
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 20 Jun 2007 17:38:01 -0700 (MST)
	(envelope-from nikunj.mehta@oracle.com)
Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.186.111])
	by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l5L0bwXP029697;
	Wed, 20 Jun 2007 18:37:58 -0600
Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150])
	by rgmgw2.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l5KMY8tA017465;
	Wed, 20 Jun 2007 18:37:57 -0600
Received: from dhcp-1op3-1op4-west-144-25-166-194.us.oracle.com by acsmt351.oracle.com
	with ESMTP id 2973139931182386198; Wed, 20 Jun 2007 17:36:38 -0700
Message-ID: <4679C813.60200@oracle.com>
Date: Wed, 20 Jun 2007 17:36:35 -0700
From: Nikunj Mehta <nikunj.mehta@oracle.com>
Organization: Oracle
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To: Yaron Goland <yarong@microsoft.com>
CC: "atom-protocol@imc.org" <atom-protocol@imc.org>, atom-syntax@imc.org
Subject: Re: Can we make Atom:Author, Atom:Title, Atom:Summary, Atom:updated
 and Atom:id optional?
References: <AE9A8CBCE1A9744D975A9FBBF822DD784DE1536BC6@NA-EXMSG-C102.redmond.corp.microsoft.com>
In-Reply-To: <AE9A8CBCE1A9744D975A9FBBF822DD784DE1536BC6@NA-EXMSG-C102.redmond.corp.microsoft.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Whitelist: TRUE
X-Whitelist: TRUE
X-Brightmail-Tracker: AAAAAQAAAAI=
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034


Yaron Goland wrote:
> Below I walk through a number of mandatory ATOM elements and explain that in many cases we either have no useful value for these elements or the values we have are potentially deceptive. Rather than wasting enormous amounts of bandwidth sending around empty elements in GET responses and even more bandwidth on having clients have to send these elements up to us on PUTs/POSTs (where we will ignore the submitted values) can we just make these values optional in ATOM?
>   
Of course, the Atom Syndication Format RFC (a standards track document 
since December 2005) would need to be changed to enable optional 
elements since the Atom syntax makes certain elements required and not 
the atom publishing protocol, which is the working group you have sent 
this email to. The syntax discussion can be held over at the atom-syntax 
group
> Atom:author - We don't track who authored what specific content because it is just overhead for us that doesn't actually fulfill any of our scenarios. In fact, given merging and other concerns, we don't always know for sure who authored what nor do we particularly care. Since we don't want to track this information but since we are required to return it the only thing I can figure to do is to return the minimal value which as near as I can tell would be: <author><name>a</name></author>
>   
There are a number of variations around the use of the author element. 
If the feed contains an author, then none is required in an entry. If an 
entry had a source that contained an author, again none is needed in the 
entry. Moreover, in Atom in general, when something is required, but no 
value applies, we have the possibility of empty elements. So, in your 
particular example, you could send <author><name/></author>.
> Atom:updated - Because of the problems inherent in tracking changes with dates (e.g. why eTags were introduced into HTTP) we may not have any clock information about our entries. E.g. we literally have no data to put into an atom:updated entry. Right now the only solution we have come up with is to just return <updated>0001-01-01T01:00:00</updated> everywhere. Since our data sets don't have duplicates of the same ID we don't have to worry about screwed up ordering.
>   
The <updated> element was never intended to replace ETags. If anything, 
it is meant to allow propagating an epoch from the author/editor of an 
entry to its reader.
> Atom:id - It is very rare for us to have a globally unique identifier for an entry. We will sometimes do this for top level entries but usually their children have identifiers that are only unique within a particular scope and even then are subject to re-use. E.g. we may have a counter to specify IDs for all of our location elements but if an entry gets deleted it is not beyond the realm of possibility for that counter value to get re-used on a different entry in the future. This is much the same problem as HTTP has when people use anything other than a PURL style URL. E.g. the URL should always point to the same object but that could change.
>   
If when an id is reused, it requires the processor of the entry to 
process the entry as a new entry, then this is a problem. In other 
words, if it doesn't matter to any processor that you reused an entry, 
then, by all means, reuse the entry id in an otherwise new entry. There 
is no requirement, IIUC, in HTTP to have a URL always point to the same 
object. It does point to a particular resource, but the resource could 
be as dynamic as the current temperature (which changes every now and 
then) or as static as the specific gravity of water.




From owner-atom-syntax@mail.imc.org Wed Jun 20 22:38:28 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I1CZ2-0006oK-RX
	for atompub-archive@lists.ietf.org; Wed, 20 Jun 2007 22:38:28 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I1CZ1-00059Q-F9
	for atompub-archive@lists.ietf.org; Wed, 20 Jun 2007 22:38:28 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5L2IAia052221
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 20 Jun 2007 19:18:10 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5L2IAxf052220;
	Wed, 20 Jun 2007 19:18:10 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.236])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5L2I8Qe052204
	for <atom-syntax@imc.org>; Wed, 20 Jun 2007 19:18:09 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by wx-out-0506.google.com with SMTP id s16so341717wxc
        for <atom-syntax@imc.org>; Wed, 20 Jun 2007 19:18:08 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed;
        d=gmail.com; s=beta;
        h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=QNY7/CuXiO0nOGPa9qfrU+F9JMN3pu9gjPTUY5El4Fh8A6lIoFvcRoS4a2T/FhgzCw8FAg0X8g5WtGXLwqMEXIjWQDv1smus33c7Kg1hksOHY80cGAXKYaq6qSMkJQ+r/qRGGGPkSfq6LA5CtHiGCXkFJjHo2ImhvFWxOrWeFGw=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=bGDJ5jHQT0/CQNhVwIEN0rAwRyz93Y4yLZEeD3m/TwTgBJJwo4Uk3lVAew18NphP/5cYj8Mrr/UPAGpU/8HinpjrtPbJ0+WpZdmr9btRBlnY9rr8DRQuddz+xIH+zOCgEhtkEXIPIvHEkGcymbJqOk435d42JTGPca+1BUswk+Q=
Received: by 10.70.57.8 with SMTP id f8mr2059625wxa.1182392288153;
        Wed, 20 Jun 2007 19:18:08 -0700 (PDT)
Received: from ?192.168.1.118? ( [67.181.218.96])
        by mx.google.com with ESMTP id m75sm1623016wrm.2007.06.20.19.18.06
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Wed, 20 Jun 2007 19:18:07 -0700 (PDT)
Message-ID: <4679DFDD.8020501@gmail.com>
Date: Wed, 20 Jun 2007 19:18:05 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.0 (X11/20070326)
MIME-Version: 1.0
To: Don Park <donpark@docuverse.com>
CC: Tim Bray <Tim.Bray@Sun.COM>, Atom_Syntax <atom-syntax@imc.org>,
        atom-protocol@imc.org
Subject: Re: Atom protocol and digital signatures
References: <tslr6oa9yls.fsf@mit.edu> <p06240818c29ddcf53388@[10.20.30.108]> <20070619234334.GM24708@klangraum> <0FCD819E-A3CA-47C7-9624-3FA4FFF5BBFF@sun.com> <BF9FF5B6-771A-406D-A271-B45564D8DEB6@docuverse.com>
In-Reply-To: <BF9FF5B6-771A-406D-A271-B45564D8DEB6@docuverse.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007




Don Park wrote:
> Just a few passing comments/suggestions:
> 
> 1. I think requiring signature-breaking servers to detect and remove
> invalidated signatures creates unnecessary chores as well as being a
> potential source of confusion in context of the must-ignore rule.
> 

Require no, recommend yes.

> 2. I think it might make more sense to create an extension designed to
> enhanced digital-signature support. Such an extension would include a
> 'marker' element to indicate that signatures within, if any, are likely
> damaged. A feed processing agent downstream can then use the marker to
> avoid alarming the user unnecessarily.
> 

Hmmm. I can't see how that would be any easier.

- James




From owner-atom-syntax@mail.imc.org Wed Jun 20 23:13:39 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I1D75-0007n3-K0
	for atompub-archive@lists.ietf.org; Wed, 20 Jun 2007 23:13:39 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I1D74-0004SY-4K
	for atompub-archive@lists.ietf.org; Wed, 20 Jun 2007 23:13:39 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5L2rL7M061204
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 20 Jun 2007 19:53:21 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5L2rLH4061203;
	Wed, 20 Jun 2007 19:53:21 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5L2rKLZ061187
	for <atom-syntax@imc.org>; Wed, 20 Jun 2007 19:53:20 -0700 (MST)
	(envelope-from pagaltzis@gmx.de)
Received: (qmail invoked by alias); 21 Jun 2007 02:53:17 -0000
Received: from static-87-79-236-202.netcologne.de (EHLO klangraum) [87.79.236.202]
  by mail.gmx.net (mp038) with SMTP; 21 Jun 2007 04:53:17 +0200
X-Authenticated: #163624
X-Provags-ID: V01U2FsdGVkX1/TX+cgYJDT15j2DFNqeobvOx4EspPHF2MuR0yOLa
	g6WogRQfuxhOhA
Date: Thu, 21 Jun 2007 04:53:16 +0200
From: "A. Pagaltzis" <pagaltzis@gmx.de>
To: Atom_Syntax <atom-syntax@imc.org>, atom-protocol@imc.org
Subject: Re: Atom protocol and digital signatures
Message-ID: <20070621025316.GA12530@klangraum>
Mail-Followup-To: Atom_Syntax <atom-syntax@imc.org>, atom-protocol@imc.org
References: <tslr6oa9yls.fsf@mit.edu> <p06240818c29ddcf53388@[10.20.30.108]> <20070619234334.GM24708@klangraum> <0FCD819E-A3CA-47C7-9624-3FA4FFF5BBFF@sun.com> <BF9FF5B6-771A-406D-A271-B45564D8DEB6@docuverse.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <BF9FF5B6-771A-406D-A271-B45564D8DEB6@docuverse.com>
User-Agent: Mutt/1.4.2.1i
X-Y-GMX-Trusted: 0
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id l5L2rL7M061204
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8


Hi Don,

* Don Park <donpark@docuverse.com> [2007-06-21 02:05]:
> 2. I think it might make more sense to create an extension
> designed to enhanced digital-signature support. Such an
> extension would include a 'marker' element to indicate that
> signatures within, if any, are likely damaged. A feed
> processing agent downstream can then use the marker to avoid
> alarming the user unnecessarily.

would that really be any gain? It seems to me that it=E2=80=99s just
shifting the complexity around. It=E2=80=99s real easy for a server to
detect that a signature appears to be present even if it lacks
digsig validation code.

Regards,
--=20
Aristotle Pagaltzis // <http://plasmasturm.org/>




From owner-atom-syntax@mail.imc.org Thu Jun 21 00:02:31 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I1DsM-0002BV-Vb
	for atompub-archive@lists.ietf.org; Thu, 21 Jun 2007 00:02:31 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I1DsL-0007Md-HX
	for atompub-archive@lists.ietf.org; Thu, 21 Jun 2007 00:02:30 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5L3aYhM073173
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 20 Jun 2007 20:36:34 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5L3aYQ0073172;
	Wed, 20 Jun 2007 20:36:34 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from docuverse.com (62.92.3845.static.theplanet.com [69.56.146.98])
	by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5L3aWIN073161;
	Wed, 20 Jun 2007 20:36:33 -0700 (MST)
	(envelope-from donpark@docuverse.com)
Received: from [192.168.0.103] ([24.23.165.146])
	by docuverse.com
	with hMailServer ; Wed, 20 Jun 2007 22:36:37 -0500
In-Reply-To: <4679DFDD.8020501@gmail.com>
References: <tslr6oa9yls.fsf@mit.edu> <p06240818c29ddcf53388@[10.20.30.108]> <20070619234334.GM24708@klangraum> <0FCD819E-A3CA-47C7-9624-3FA4FFF5BBFF@sun.com> <BF9FF5B6-771A-406D-A271-B45564D8DEB6@docuverse.com> <4679DFDD.8020501@gmail.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <E37909A2-CDC3-4007-933F-967093EDB3DD@docuverse.com>
Cc: Atom_Syntax <atom-syntax@imc.org>, atom-protocol@imc.org
Content-Transfer-Encoding: 7bit
From: Don Park <donpark@docuverse.com>
Subject: Re: Atom protocol and digital signatures
Date: Wed, 20 Jun 2007 20:33:34 -0700
To: James M Snell <jasnell@gmail.com>
X-Mailer: Apple Mail (2.752.3)
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464


It depends on what the server is doing but injecting an element can  
be easily hard-coded into output templates where removing calls for  
parsing. Anyway, it's nice having an alternate design strategy to  
kick around. :-)

BTW, re problem of server changing element order, you probably know  
this but the common solution is to store the membership and order of  
signed elements elsewhere so scrambled element order in XML won't  
matter much.

- Don

On Jun 20, 2007, at 7:18 PM, James M Snell wrote:

>
>> 2. I think it might make more sense to create an extension  
>> designed to
>> enhanced digital-signature support. Such an extension would include a
>> 'marker' element to indicate that signatures within, if any, are  
>> likely
>> damaged. A feed processing agent downstream can then use the  
>> marker to
>> avoid alarming the user unnecessarily.
>>
>
> Hmmm. I can't see how that would be any easier.
>
> - James
>





From owner-atom-syntax@mail.imc.org Thu Jun 21 03:09:44 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I1GnY-00024f-1L
	for atompub-archive@lists.ietf.org; Thu, 21 Jun 2007 03:09:44 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I1GmL-0005tx-0I
	for atompub-archive@lists.ietf.org; Thu, 21 Jun 2007 03:08:29 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5L6e1hl022318
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 20 Jun 2007 23:40:01 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5L6e1xH022317;
	Wed, 20 Jun 2007 23:40:01 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.rfburst.com (mail.rfburst.com [66.119.143.52] (may be forged))
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5L6dwlv022271
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 20 Jun 2007 23:39:59 -0700 (MST)
Received: from purplestreak.com (customer.radioburst.com [66.119.135.195] (may be forged))
	by mail.rfburst.com (8.12.11.20060308/8.12.11) with ESMTP id l5L6dqOI023561;
	Thu, 21 Jun 2007 00:39:52 -0600
Received: from localhost.localdomain (tobermory [127.0.0.1])
	by purplestreak.com (8.12.10/8.11.6) with ESMTP id l5L6aFPb021699;
	Thu, 21 Jun 2007 00:36:15 -0600
Received: (from ho@localhost)
	by localhost.localdomain (8.12.10/8.12.10/Submit) id l5L6aFlO021695;
	Thu, 21 Jun 2007 00:36:15 -0600
Date: Thu, 21 Jun 2007 00:36:15 -0600
Message-Id: <200706210636.l5L6aFlO021695@localhost.localdomain>
From: "Hilarie Orman" <ho@alum.mit.edu>
Reply-To: "Hilarie Orman" <ho@alum.mit.edu>
To: atom-protocol@imc.org, atom-syntax@imc.org
Cc: phoffman@imc.org
Subject: Re: Atom protocol and digital signatures
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mail.rfburst.com [66.119.143.53]); Thu, 21 Jun 2007 00:39:52 -0600 (MDT)
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d


Even better (much better) would be to create an extension that
includes the original, signed material, including the signature.  This
allows the server to publish its modified version while still allowing
users (those who care, anyway) to determine which parts of the entry
were actually signed by the client.

Don Park writes:

>  Just a few passing comments/suggestions:

>  1. I think requiring signature-breaking servers to detect and remove  
>  invalidated signatures creates unnecessary chores as well as being a  
>  potential source of confusion in context of the must-ignore rule.

>  2. I think it might make more sense to create an extension designed  
>  to enhanced digital-signature support. Such an extension would  
>  include a 'marker' element to indicate that signatures within, if  
>  any, are likely damaged. A feed processing agent downstream can then  
>  use the marker to avoid alarming the user unnecessarily.




>  On Jun 19, 2007, at 5:35 PM, Tim Bray wrote:

>  > On Jun 19, 2007, at 4:43 PM, A. Pagaltzis wrote:
>  >
>  >>> The method for a server to indicate to a third party whether or
>  >>> not the client signed an Entry Document is by including the
>  >>> client's signature in the published entry, even though that
>  >>> signature is likely to be invalid.
>  >>
>  >> I strongly disagree with this. As a consumer, I have no possible
>  >> way to know whether an invalid signature is there because
>  >
>  > I have to agree with Aristotle on this one.  I think we should  
>  > simply drop that last sentence.  -Tim




From owner-atom-syntax@mail.imc.org Thu Jun 21 07:57:06 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I1LHe-0001Lf-A9
	for atompub-archive@lists.ietf.org; Thu, 21 Jun 2007 07:57:06 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I1LHa-0000la-ST
	for atompub-archive@lists.ietf.org; Thu, 21 Jun 2007 07:57:06 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LBbZ2w016054
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 21 Jun 2007 04:37:35 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5LBbZZ9016053;
	Thu, 21 Jun 2007 04:37:35 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail2.sea5.speakeasy.net (mail2.sea5.speakeasy.net [69.17.117.4])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LBbYIq016046
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
	for <atom-syntax@imc.org>; Thu, 21 Jun 2007 04:37:35 -0700 (MST)
	(envelope-from elharo@metalab.unc.edu)
Received: (qmail 18128 invoked from network); 21 Jun 2007 11:37:33 -0000
Received: from dsl254-067-087.nyc1.dsl.speakeasy.net (HELO eliza-8.local) (elharo@[216.254.67.87])
          (envelope-sender <elharo@metalab.unc.edu>)
          by mail2.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP
          for <atom-syntax@imc.org>; 21 Jun 2007 11:37:33 -0000
Message-ID: <467A62FC.7020205@metalab.unc.edu>
Date: Thu, 21 Jun 2007 07:37:32 -0400
From: Elliotte Harold <elharo@metalab.unc.edu>
User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604)
MIME-Version: 1.0
To: atom-syntax@imc.org
Subject: Re: Entities in XHTML
References: <EF14FE208FC8364F94E8A58EF085979A177A606672@NA-EXMSG-C109.redmond.corp.microsoft.com> <46782BE4.30206@gmail.com> <EF14FE208FC8364F94E8A58EF085979A177A6066AD@NA-EXMSG-C109.redmond.corp.microsoft.com> <20070619235819.GO24708@klangraum>
In-Reply-To: <20070619235819.GO24708@klangraum>
Content-Type: text/plain; charset=UTF-8; format=flowed
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id l5LBbZ2w016054
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352



>>> Folks should be using the numeric character references rather
>>> than the entities.


How 20th century.

Aside from reserved characters like < and &, folks should not be using=20
entity references or numeric character references at all.

THEY SHOULD BE TYPING THE CHARACTER!

Is it all that hard to write a =C2=A9 or an =C3=A9 or pretty much any oth=
er=20
character you need regularly? No, it isn't. And locally rare characters=20
can be inserted with any of various Unicode input palettes shipped with=20
modern OSs and text editors.

An actual character like =C2=A9 is far prettier than either &#xA4; or &co=
py;.

Any software that still doesn't support such basic functionality in 2007=20
should be tossed on the recycle bin.

Of course, it still annoys me that much software that can support UTF-8=20
such as Eclipse still ships with broken, non-interoperable default=20
encodings. We need to fix that. Please report that bug wherever you find=20
it, and vote for it in bug trackers everywhere.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D108668
https://bugzilla.mozilla.org/show_bug.cgi?id=3D333859

Also see

http://www-128.ibm.com/developerworks/xml/library/x-utf8/

--=20
Elliotte Rusty Harold  elharo@metalab.unc.edu
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=3D0596527500/ref=3Dnosim/cafeaulai=
tA/




From owner-atom-syntax@mail.imc.org Thu Jun 21 12:04:31 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I1P95-0000g0-F3
	for atompub-archive@lists.ietf.org; Thu, 21 Jun 2007 12:04:31 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I1P94-0004kh-48
	for atompub-archive@lists.ietf.org; Thu, 21 Jun 2007 12:04:31 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LFPBEk047340
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 21 Jun 2007 08:25:11 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5LFPBZl047339;
	Thu, 21 Jun 2007 08:25:11 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169])
	(authenticated bits=0)
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LFP9dQ047323
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Thu, 21 Jun 2007 08:25:10 -0700 (MST)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: <p06240823c2a04871d21e@[10.20.30.108]>
Date: Thu, 21 Jun 2007 08:24:57 -0700
To: Atom WG <atom-syntax@imc.org>
From: Paul Hoffman <phoffman@imc.org>
Subject: W3C Workshop on Next Steps for XML Signature and XML Encryption
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014


This is probably of interest to the folks in the WG who implement 
Atom with digital signatures and/or encryption.

<http://www.w3.org/2007/xmlsec/ws/cfp>

It would be grand to see one or more position papers on experiences 
of implementing Atom with these technologies.




From owner-atom-syntax@mail.imc.org Thu Jun 21 18:02:31 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I1UjX-0005WS-0k
	for atompub-archive@lists.ietf.org; Thu, 21 Jun 2007 18:02:31 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I1UjW-0007Yf-6K
	for atompub-archive@lists.ietf.org; Thu, 21 Jun 2007 18:02:31 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LLdnO3031920
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 21 Jun 2007 14:39:49 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5LLdn9A031919;
	Thu, 21 Jun 2007 14:39:49 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LLdlMe031907
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 21 Jun 2007 14:39:48 -0700 (MST)
	(envelope-from nikunj.mehta@oracle.com)
Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.186.112])
	by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l5LLdjm0028265;
	Thu, 21 Jun 2007 16:39:45 -0500
Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150])
	by rgmgw3.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l5LG72Sk006890;
	Thu, 21 Jun 2007 15:39:44 -0600
Received: from dhcp-1op3-1op4-west-144-25-166-194.us.oracle.com by acsmt351.oracle.com
	with ESMTP id 2978381121182461948; Thu, 21 Jun 2007 14:39:08 -0700
Message-ID: <467AEFF8.5030002@oracle.com>
Date: Thu, 21 Jun 2007 14:39:04 -0700
From: Nikunj Mehta <nikunj.mehta@oracle.com>
Organization: Oracle
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To: "atom-protocol@imc.org" <atom-protocol@imc.org>
CC: Yaron Goland <yarong@microsoft.com>, atom-syntax@imc.org
Subject: Re: Is it just us?
References: <AE9A8CBCE1A9744D975A9FBBF822DD784DE1536BB6@NA-EXMSG-C102.redmond.corp.microsoft.com> <73EF1BD4-747B-459E-A27F-7D679262F6C4@sun.com> <AE9A8CBCE1A9744D975A9FBBF822DD784DE1536DE3@NA-EXMSG-C102.redmond.corp.microsoft.com>
In-Reply-To: <AE9A8CBCE1A9744D975A9FBBF822DD784DE1536DE3@NA-EXMSG-C102.redmond.corp.microsoft.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Whitelist: TRUE
X-Whitelist: TRUE
X-Brightmail-Tracker: AAAAAQAAAAI=
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.5 (/)
X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad


If one is willing to interpret a relational database through the eyes of 
an application (family, really), Atom does indeed help. In more general 
sense a simple two level hierarchy (container, element (container, 
element()) can go quite far when using hyperlinks. However, if 
interpreting a relational schema without any knowledge of applications 
that use this schema, Atom won't be of much help, and you might be 
better off with something else like Web3S or RDF.

Note to myself: Atom pub still doesn't provide a comprehensive mechanism 
for synchronizing changes to these feeds across autonomous agents, but 
that's for another day.

Let me show an example where data is richly interconnected, and at 
present, lives in relational databases. Then I will show how this data 
as Atom feeds (both atompub and regular atom). Drivers carry insurance 
(except those who like paying for tickets), and insurance covers 
vehicles. So this three node graph can be represented as three separate 
collections one for each node, and three compound feeds one for each 
edge in the graph. I am only showing one of the compound feeds but 
others would be similar.

Might I add that the additional bytes being generated for Atom feeds 
could be offset by the diminished traffic to a server because the data 
required is already sitting in an intermediary or the client, and may be 
synchronized efficiently. Whether you would be willing to work with 
potentially "stale" application data is still another discussion to have.

<atom:feed xmlns:atom="http://www.w3.org/2005/Atom">
    <atom:title>Vehicles insured by example.com</atom:title>
    <atom:id>tag:example.com,vehicles</atom:id>
    <atom:link rel="self" href="http://example.com/vehicles/"/>
    <atom:updated>2007-06-04T19:42:22Z</atom:updated>
    <atom:author>
        <atom:name/>
        <atom:uri>http://example.com</atom:uri>
    </atom:author>

    <atom:entry>
       <atom:title>Honda Civic</atom:title>
       <atom:id>tag:example.com:vehicle=1</atom:id>
       <atom:link rel="edit" href="http://example.com/vehicle/1"/>
       <auto:vin 
xmlns:auto="http://example.com/xmlns/auto">2FMZU62E02ZB78590</auto:vin>
       <atom:content/>
       <atom:updated>2007-06-04T19:44:22Z</atom:updated>
       <app:edited 
xmlns:atompub="http://www.w3.org/2007/app">2007-06-04T19:44:22Z</app:edited>
    </atom:entry>

    <atom:entry>
       <atom:title>Chrysler Jeep</atom:title>
       <atom:id>tag:example.com:vehicle=2</atom:id>
       <atom:link rel="edit" href="http://example.com/vehicle/2"/>
       <auto:vin 
xmlns:auto="http://example.com/xmlns/auto">2FMZU62E02ZB23290</auto:vin>
       <atom:content/>
       <atom:updated>2007-06-04T19:42:53Z</atom:updated>
       <app:edited 
xmlns:atompub="http://www.w3.org/2007/app">2007-06-04T19:42:53Z</app:edited>
    </atom:entry>

    <atom:entry>
       <atom:title>Volkswagon Beetle</atom:title>
       <atom:id>tag:example.com:vehicle=3</atom:id>
       <atom:link rel="edit" href="http://example.com/vehicle/3"/>
       <auto:vin 
xmlns:auto="http://example.com/xmlns/auto">12LSDSU62E02ZB23290</auto:vin>
       <atom:content/>
       <atom:updated>2007-06-04T19:40:23Z</atom:updated>
       <app:edited 
xmlns:atompub="http://www.w3.org/2007/app">2007-06-04T19:42:53Z</app:edited>
    </atom:entry>
</atom:feed>

<atom:feed xmlns:atom="http://www.w3.org/2005/Atom">
    <atom:title>Drivers insured by example.com</atom:title>
    <atom:id>tag:example.com,drivers</atom:id>
    <atom:link rel="self" href="http://example.com/drivers/"/>
    <atom:updated>2007-06-04T20:21:22Z</atom:updated>
    <atom:author>
        <atom:name/>
        <atom:uri>http://example.com</atom:uri>
    </atom:author>

    <atom:entry>
       <atom:title>Mr. John Doe</atom:title>
       <atom:id>tag:example.com:driver=1</atom:id>
       <atom:link rel="edit" href="http://example.com/driver/1"/>
       <auto:license xmlns:auto="http://example.com/xmlns/auto" 
number="32139213" issuer="CA" country="USA"/>
       <atom:content/>
       <atom:updated>2007-06-04T09:44:22Z</atom:updated>
       <app:edited 
xmlns:atompub="http://www.w3.org/2007/app">2007-06-04T09:44:22Z</app:edited>
    </atom:entry>

    <atom:entry>
       <atom:title>Ms. Jane Ko</atom:title>
       <atom:id>tag:example.com:driver=2</atom:id>
       <atom:link rel="edit" href="http://example.com/driver/2"/>
       <auto:license xmlns:auto="http://example.com/xmlns/auto" 
number="32139213" issuer="ON" country="Canada"/>
       <atom:content/>
       <atom:updated>2007-06-04T09:42:53Z</atom:updated>
       <app:edited 
xmlns:atompub="http://www.w3.org/2007/app">2007-06-04T09:42:53Z</app:edited>
    </atom:entry>

    <atom:entry>
       <atom:title>Mr. Ajay Kumar</atom:title>
       <atom:id>tag:example.com:driver=3</atom:id>
       <atom:link rel="edit" href="http://example.com/driver/3"/>
       <auto:license xmlns:auto="http://example.com/xmlns/auto" 
number="1238122" issuer="MH" country="India"/>
       <atom:content/>
       <atom:updated>2007-06-04T09:40:23Z</atom:updated>
       <app:edited 
xmlns:atompub="http://www.w3.org/2007/app">2007-06-04T09:42:53Z</app:edited>
    </atom:entry>
</atom:feed>

<atom:feed xmlns:atom="http://www.w3.org/2005/Atom">
    <atom:title>Insurance policies issued by example.com</atom:title>
    <atom:id>tag:example.com,policies</atom:id>
    <atom:link rel="self" href="http://example.com/policies/"/>
    <atom:updated>2007-06-05T20:21:22Z</atom:updated>
    <atom:author>
        <atom:name/>
        <atom:uri>http://example.com</atom:uri>
    </atom:author>

    <atom:entry>
       <atom:title/>
       <atom:id>tag:example.com:policy=1</atom:id>
       <atom:link rel="edit**" href="http://example.com/policy/1"/>
       <atom:link rel="related" href="http://example.com/driver/1"/>
       <atom:link rel="related" href="http://example.com/driver/2"/>
       <atom:link rel="related" href="http://example.com/vehicle/1"/>
       <atom:link rel="related" href="http://example.com/vehicle/2"/>
       <auto:liability xmlns:auto="http://example.com/xmlns/auto">
          <auto:property currency="USD">50000</auto:property>
          <auto:injury currency="USD">25000</auto:injury>
          <auto:medical currency="USD">5000</auto:medical>
       </auto:liability>
       <atom:content/>
       <atom:updated>2007-06-05T09:44:22Z</atom:updated>
       <app:edited 
xmlns:atompub="http://www.w3.org/2007/app">2007-06-05T09:44:22Z</app:edited>
    </atom:entry>

    <atom:entry>
       <atom:title/>
       <atom:id>tag:example.com:policy=2</atom:id>
       <atom:link rel="edit" href="http://example.com/ploicy/2"/>
       <atom:link rel="related" href="http://example.com/driver/3"/>
       <atom:link rel="related" href="http://example.com/vehicle/3"/>
       <auto:liability xmlns:auto="http://example.com/xmlns/auto">
          <auto:property currency="USD">100000</auto:property>
          <auto:injury currency="USD">50000</auto:injury>
          <auto:medical currency="USD">10000</auto:medical>
       </auto:liability>
       <atom:content/>
       <atom:updated>2007-06-05T09:42:53Z</atom:updated>
       <app:edited 
xmlns:atompub="http://www.w3.org/2007/app">2007-06-05T09:42:53Z</app:edited>
    </atom:entry>
</atom:feed>

<atom:feed xmlns:atom="http://www.w3.org/2005/Atom">
    <atom:title>Drivers by insurance policies</atom:title>
    <atom:id>tag:example.com,driversnpolicies</atom:id>
    <atom:link rel="self" href="http://example.com/driversnpolicies/"/>
    <atom:updated>2007-06-05T20:21:22Z</atom:updated>
    <atom:author>
        <atom:name/>
        <atom:uri>http://example.com</atom:uri>
    </atom:author>
   
    <atom:entry>
       <atom:title/>
       <atom:id>tag:example.com:drivers,policy=1</atom:id>
       <atom:link rel="related" href="http://example.com/policy/1"/>
       <atom:content type="application/atom+xml">
          <atom:feed>
            <atom:title/>
            <atom:id>tag:example.com,drivers,policy=1</atom:id>
            <atom:updated>2007-06-04T20:21:22Z</atom:updated>
            <atom:author>
                <atom:name/>
            </atom:author>

            <atom:entry>
               <atom:title>Mr. John Doe</atom:title>
               <atom:id>tag:example.com:driver=1</atom:id>
               <atom:link rel="edit" href="http://example.com/driver/1"/>
               <atom:content/>
               <atom:updated>2007-06-04T09:44:22Z</atom:updated>
            </atom:entry>

            <atom:entry>
               <atom:title>Ms. Jane Ko</atom:title>
               <atom:id>tag:example.com:driver=2</atom:id>
               <atom:link rel="edit" href="http://example.com/driver/2"/>
               <atom:content/>
               <atom:updated>2007-06-04T09:42:53Z</atom:updated>
            </atom:entry>

          </atom:feed>
       </atom:content>
       <atom:updated>2007-06-05T09:42:53Z</atom:updated>
    </atom:entry>
    <atom:entry>
       <atom:title/>
       <atom:id>tag:example.com:drivers,policy=2</atom:id>
       <atom:link rel="related" href="http://example.com/policy/2"/>
       <atom:content type="application/atom+xml">
          <atom:feed>
            <atom:title/>
            <atom:id>tag:example.com,drivers,policy=2</atom:id>
            <atom:updated>2007-06-04T20:21:22Z</atom:updated>
            <atom:author>
                <atom:name/>
            </atom:author>
            <atom:entry>
               <atom:title>Mr. Ajay Kumar</atom:title>
               <atom:id>tag:example.com:driver=3</atom:id>
               <atom:link rel="edit" href="http://example.com/driver/3"/>
               <atom:content/>
               <atom:updated>2007-06-04T09:40:23Z</atom:updated>
            </atom:entry>
          </atom:feed>
       </atom:content>
       <atom:updated>2007-06-05T09:42:53Z</atom:updated>
    </atom:entry>
</atom:feed>

Yaron Goland wrote:
> We wanted to focus on actual services that real folks could hit against so we focused our explanations and such on LiveContacts which we released support for (using an ancient version of Web3S) last May. But our overall use cases stretch across all the deeply structured stores at Live. I can't quite get into the details yet, which is why I just focused on LiveContacts which I can discuss. But Astoria makes the situation even easier to understand. In Astoria's case they are exposing relational databases which for our purposes can be thought of as deeply structured data.
>
> A particular question I would really love to hear a concrete answer to though is - what are the characteristics that make a data set look like a 'publication'? In other words, what is a loose check list of things to look for that let you know if the information you want to expose is a good candidate for ATOM?
>
>         Thanks,
>
>                 Yaron
>
>   
>> -----Original Message-----
>> From: Tim.Bray@Sun.COM [mailto:Tim.Bray@Sun.COM]
>> Sent: Wednesday, June 20, 2007 8:42 PM
>> To: Yaron Goland
>> Cc: atom-protocol@imc.org
>> Subject: Re: Is it just us?
>>
>>
>> On Jun 20, 2007, at 4:21 PM, Yaron Goland wrote:
>>
>>     
>>> I will be following up this e-mail with e-mails addressing specific
>>> problems we ran into when we tried to use APP in the context of
>>> Windows Live (and later SQL Server (Codename "Astoria" project)) to
>>> make our structured data available for machine processing.
>>>       
>> For what it's worth, based on the description of the problem in
>> http://dev.live.com/livedata/web3s.htm (from the introduction: "The
>> purpose of this document is to define a protocol that is a good fit
>> for Live Contacts. Live Contacts is the central data store in Windows
>> Live for address book information. All Hotmail contacts, Messenger
>> buddies and Spaces' friends are recorded in Live Contacts. There are
>> currently approximately 500,000,000 active address books in Live
>> Contacts"), it seems you have a unitary and unique dataset you're
>> trying to update and it doesn't seem to behave much like a
>> "publication" in several important senses, so it seems unsurprising
>> that APP would be a poor fit for updating it.  -Tim
>>     
>
>
>   




From owner-atom-syntax@mail.imc.org Thu Jun 21 19:45:51 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I1WLX-0001fw-UD
	for atompub-archive@lists.ietf.org; Thu, 21 Jun 2007 19:45:51 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I1WLU-0001pK-9p
	for atompub-archive@lists.ietf.org; Thu, 21 Jun 2007 19:45:51 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LNOUDo062718
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 21 Jun 2007 16:24:30 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5LNOUB5062717;
	Thu, 21 Jun 2007 16:24:30 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LNOSim062711
	for <atom-syntax@imc.org>; Thu, 21 Jun 2007 16:24:29 -0700 (MST)
	(envelope-from lisa@osafoundation.org)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1])
	by laweleka.osafoundation.org (Postfix) with ESMTP id 7928814220A;
	Thu, 21 Jun 2007 16:24:28 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
Received: from laweleka.osafoundation.org ([127.0.0.1])
	by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id qzoKl72fDyqq; Thu, 21 Jun 2007 16:24:26 -0700 (PDT)
Received: from [10.1.1.210] (ip10.commerce.net [157.22.41.10])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(No client certificate requested)
	by laweleka.osafoundation.org (Postfix) with ESMTP id D6B67142209;
	Thu, 21 Jun 2007 16:24:26 -0700 (PDT)
In-Reply-To: <577F866F-248D-41A8-8EDF-677AC0CFA271@Sun.COM>
References: <AE9A8CBCE1A9744D975A9FBBF822DD784DE1536BB6@NA-EXMSG-C102.redmond.corp.microsoft.com> <73EF1BD4-747B-459E-A27F-7D679262F6C4@sun.com> <AE9A8CBCE1A9744D975A9FBBF822DD784DE1536DE3@NA-EXMSG-C102.redmond.corp.microsoft.com> <577F866F-248D-41A8-8EDF-677AC0CFA271@Sun.COM>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: multipart/alternative; boundary=Apple-Mail-33-150112619
Message-Id: <9180A892-A2C6-4B78-9038-AAFE319DCE08@osafoundation.org>
Cc: Yaron Goland <yarong@microsoft.com>, Atom <atom-syntax@imc.org>
From: Lisa Dusseault <lisa@osafoundation.org>
Subject: Re: Is it just us?
Date: Thu, 21 Jun 2007 16:24:19 -0700
To: Tim Bray <Tim.Bray@Sun.COM>
X-Mailer: Apple Mail (2.752.3)
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3



--Apple-Mail-33-150112619
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

When is data Atom-like?

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

...puts emphasis on the ability to "provide other people with a  
summary of the website's recently added content"

A very direct reading of the data format suggests to me that the  
questions Atom is most organized to answer are:

What's new?
For each new thing:
	... who wrote it, when?
	... how do I get the rest of it?

If the questions a user asks are very different from this (e.g. "what  
is most popular" or "what is biggest" or "what is this person's email  
address" or "when is this user free") then Atom is not organized as  
optimally to answer the questions.

Of course this is just looking at 4287, not at extensions that  
significantly change what questions atom is organized to answer.

Lisa

On Jun 21, 2007, at 1:37 PM, Tim Bray wrote:

>
> On Jun 21, 2007, at 1:08 PM, Yaron Goland wrote:
>
>> A particular question I would really love to hear a concrete  
>> answer to though is - what are the characteristics that make a  
>> data set look like a 'publication'? In other words, what is a  
>> loose check list of things to look for that let you know if the  
>> information you want to expose is a good candidate for ATOM?
>
> I think the answer is: data that's Web-like.  I.e. where you have a  
> universe of resources, each with its own identifier, and which are  
> expected to use hypertext links embedded in message bodies to refer  
> to each other.  Obviously, the motivating use-case that got the  
> ball rolling was blog-post authoring, but it's starting to look  
> like the data space for which the Atom protocol is useful is quite   
> a bit bigger.  -Tim
>
>
>
>


--Apple-Mail-33-150112619
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><DIV>When is data =
Atom-like?=A0</DIV><DIV><BR class=3D"khtml-block-placeholder"></DIV><A =
href=3D"http://en.wikipedia.org/wiki/Web_syndication">http://en.wikipedia.=
org/wiki/Web_syndication</A><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV><SPAN =
class=3D"Apple-style-span">...puts emphasis on the ability to "provide =
other people with a summary of the website's <B>recently added =
content</B>"</SPAN></DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>A very direct reading of =
the data format suggests to me that the questions Atom is most organized =
to answer are:</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>What's new?</DIV><DIV>For =
each new thing:</DIV><DIV><SPAN class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</SPAN>... who wrote it, =
when?</DIV><DIV><SPAN class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</SPAN>... how do I get the rest of it?</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>If the questions a user =
asks are very different from this (e.g. "what is most popular" or "what =
is biggest" or "what is this person's email address" or "when is this =
user free") then Atom is not organized as optimally to answer the =
questions.</DIV><DIV><BR class=3D"khtml-block-placeholder"></DIV><DIV>Of =
course this is just looking at 4287, not at extensions that =
significantly change what questions atom is organized to =
answer.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Lisa</DIV><DIV><BR><DIV><DIV>=
On Jun 21, 2007, at 1:37 PM, Tim Bray wrote:</DIV><BR =
class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite"><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">On Jun =
21, 2007, at 1:08 PM, Yaron Goland wrote:</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><BR></DIV> <BLOCKQUOTE type=3D"cite"><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">A particular question I would really love to hear a =
concrete answer to though is - what are the characteristics that make a =
data set look like a 'publication'? In other words, what is a loose =
check list of things to look for that let you know if the information =
you want to expose is a good candidate for ATOM?</DIV> </BLOCKQUOTE><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">I think =
the answer is: data that's Web-like.<SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>I.e. where you have a =
universe of resources, each with its own identifier, and which are =
expected to use hypertext links embedded in message bodies to refer to =
each other.<SPAN class=3D"Apple-converted-space">=A0 </SPAN>Obviously, =
the motivating use-case that got the ball rolling was blog-post =
authoring, but it's starting to look like the data space for which the =
Atom protocol is useful is quite<SPAN class=3D"Apple-converted-space">=A0 =
</SPAN>a bit bigger.<SPAN class=3D"Apple-converted-space">=A0 =
</SPAN>-Tim</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV> </BLOCKQUOTE></DIV><BR></DIV></BODY></HTML>=

--Apple-Mail-33-150112619--




From owner-atom-syntax@mail.imc.org Thu Jun 21 21:27:34 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I1Xvy-0007kM-Jk
	for atompub-archive@lists.ietf.org; Thu, 21 Jun 2007 21:27:34 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I1Xvx-0005WI-64
	for atompub-archive@lists.ietf.org; Thu, 21 Jun 2007 21:27:34 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5M144jD086189
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 21 Jun 2007 18:04:04 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5M144vt086188;
	Thu, 21 Jun 2007 18:04:04 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5M142Jl086172
	for <atom-syntax@imc.org>; Thu, 21 Jun 2007 18:04:03 -0700 (MST)
	(envelope-from pagaltzis@gmx.de)
Received: (qmail invoked by alias); 22 Jun 2007 01:04:02 -0000
Received: from static-87-79-236-202.netcologne.de (EHLO klangraum) [87.79.236.202]
  by mail.gmx.net (mp002) with SMTP; 22 Jun 2007 03:04:02 +0200
X-Authenticated: #163624
X-Provags-ID: V01U2FsdGVkX1+NhJsbSUGNiMPPtRQuu6Z62eH7EJlQAmJrWpC+8S
	5TOwXpG2YW9ms+
Date: Fri, 22 Jun 2007 03:04:01 +0200
From: "A. Pagaltzis" <pagaltzis@gmx.de>
To: Atom <atom-syntax@imc.org>
Subject: Re: Is it just us?
Message-ID: <20070622010401.GA19723@klangraum>
Mail-Followup-To: Atom <atom-syntax@imc.org>
References: <AE9A8CBCE1A9744D975A9FBBF822DD784DE1536BB6@NA-EXMSG-C102.redmond.corp.microsoft.com> <73EF1BD4-747B-459E-A27F-7D679262F6C4@sun.com> <AE9A8CBCE1A9744D975A9FBBF822DD784DE1536DE3@NA-EXMSG-C102.redmond.corp.microsoft.com> <577F866F-248D-41A8-8EDF-677AC0CFA271@Sun.COM> <9180A892-A2C6-4B78-9038-AAFE319DCE08@osafoundation.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <9180A892-A2C6-4B78-9038-AAFE319DCE08@osafoundation.org>
User-Agent: Mutt/1.4.2.1i
X-Y-GMX-Trusted: 0
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id l5M144jD086189
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9


Hi Lisa,

* Lisa Dusseault <lisa@osafoundation.org> [2007-06-22 01:40]:
> When is data Atom-like?
>=20
> http://en.wikipedia.org/wiki/Web_syndication
>=20
> ...puts emphasis on the ability to "provide other people with a
> summary of the website's recently added content"

but that is just a convention. There is no requirement per spec
that the entries in a feed be selected based on any particular
criterion =E2=80=93 not by timestamp nor by any other.

> A very direct reading of the data format suggests to me that
> the  questions Atom is most organized to answer are:
>=20
> What's new?
> For each new thing:
> 	... who wrote it, when?
> 	... how do I get the rest of it?

If you leave out the =E2=80=9CWhat=E2=80=99s new=E2=80=9D question and ge=
nerically say
=E2=80=9Cfor each listed thing=E2=80=9D, then that=E2=80=99s not bad.

Really, the question of what Atom=E2=80=99s good for is the question
=E2=80=9Cwhat can I express with a bunch of Entry Documents?=E2=80=9D and=
 the
answer is =E2=80=9Ca bunch of mostly self-contained resources.=E2=80=9D T=
hat is,
what you *can=E2=80=99t* easily express is strong structure that crosses
the boundaries of multiple Entries. The Entries need to be peers
in some sense.

As long as your data model fits that requirement, it will be
quite easily mapped to Atom.

Regards,
--=20
Aristotle Pagaltzis // <http://plasmasturm.org/>




From owner-atom-syntax@mail.imc.org Fri Jun 22 05:37:15 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I1fZr-00063C-N7
	for atompub-archive@lists.ietf.org; Fri, 22 Jun 2007 05:37:15 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I1fZo-0004ed-3c
	for atompub-archive@lists.ietf.org; Fri, 22 Jun 2007 05:37:15 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5M9BLW5016324
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 22 Jun 2007 02:11:21 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5M9BLxT016323;
	Fri, 22 Jun 2007 02:11:21 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from scmailgw2.scop.aoyama.ac.jp (scmailgw2.scop.aoyama.ac.jp [133.2.251.195])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5M9BJ2A016314
	for <atom-syntax@imc.org>; Fri, 22 Jun 2007 02:11:20 -0700 (MST)
	(envelope-from duerst@it.aoyama.ac.jp)
Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17])
	by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l5M9BIJg023588
	for <atom-syntax@imc.org>; Fri, 22 Jun 2007 18:11:18 +0900 (JST)
Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp
	 id 5732_890abdce_20a0_11dc_8e05_0014221f2a2d;
	Fri, 22 Jun 2007 18:11:17 +0900
X-AuthUser: duerst@it.aoyama.ac.jp
Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:49880)
	by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server]
	id <SC5008> for <atom-syntax@imc.org> from <duerst@it.aoyama.ac.jp>;
	Fri, 22 Jun 2007 18:09:20 +0900
Message-Id: <6.0.0.20.2.20070622170404.053f3240@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Version 6J
Date: Fri, 22 Jun 2007 17:05:35 +0900
To: Elliotte Harold <elharo@metalab.unc.edu>, atom-syntax@imc.org
From: Martin Duerst <duerst@it.aoyama.ac.jp>
Subject: Re: Entities in XHTML
In-Reply-To: <467A62FC.7020205@metalab.unc.edu>
References: <EF14FE208FC8364F94E8A58EF085979A177A606672@NA-EXMSG-C109.redmond.corp.microsoft.com>
 <46782BE4.30206@gmail.com>
 <EF14FE208FC8364F94E8A58EF085979A177A6066AD@NA-EXMSG-C109.redmond.corp.microsoft.com>
 <20070619235819.GO24708@klangraum>
 <467A62FC.7020205@metalab.unc.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906


At 20:37 07/06/21, Elliotte Harold wrote:
>
>
>>>> Folks should be using the numeric character references rather
>>>> than the entities.
>
>
>How 20th century.
>
>Aside from reserved characters like < and &, folks should not be using entity references or numeric character references at all.

I fully agree.

Another exception occasionally are things such as &nbsp;, where
one might prefer explicitness over direct visibility.

Regards,    Martin.


#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@it.aoyama.ac.jp     




From owner-atom-syntax@mail.imc.org Fri Jun 22 06:20:00 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I1gFE-0003c0-78
	for atompub-archive@lists.ietf.org; Fri, 22 Jun 2007 06:20:00 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I1gFB-0001Ja-No
	for atompub-archive@lists.ietf.org; Fri, 22 Jun 2007 06:20:00 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5M9uJxD021966
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 22 Jun 2007 02:56:19 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5M9uJDI021965;
	Fri, 22 Jun 2007 02:56:19 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5M9uHZn021959
	for <atom-syntax@imc.org>; Fri, 22 Jun 2007 02:56:18 -0700 (MST)
	(envelope-from pagaltzis@gmx.de)
Received: (qmail invoked by alias); 22 Jun 2007 09:56:16 -0000
Received: from static-87-79-236-202.netcologne.de (EHLO klangraum) [87.79.236.202]
  by mail.gmx.net (mp050) with SMTP; 22 Jun 2007 11:56:16 +0200
X-Authenticated: #163624
X-Provags-ID: V01U2FsdGVkX19GaUkOn/tGzaxU94hqbhm6t9sLV6YxxriMEtACDh
	a8zIF09z24/xo6
Date: Fri, 22 Jun 2007 11:56:14 +0200
From: "A. Pagaltzis" <pagaltzis@gmx.de>
To: atom-syntax@imc.org
Subject: Re: Entities in XHTML
Message-ID: <20070622095614.GI19723@klangraum>
Mail-Followup-To: atom-syntax@imc.org
References: <EF14FE208FC8364F94E8A58EF085979A177A606672@NA-EXMSG-C109.redmond.corp.microsoft.com> <46782BE4.30206@gmail.com> <EF14FE208FC8364F94E8A58EF085979A177A6066AD@NA-EXMSG-C109.redmond.corp.microsoft.com> <20070619235819.GO24708@klangraum> <467A62FC.7020205@metalab.unc.edu> <6.0.0.20.2.20070622170404.053f3240@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6.0.0.20.2.20070622170404.053f3240@localhost>
User-Agent: Mutt/1.4.2.1i
X-Y-GMX-Trusted: 0
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad


* Martin Duerst <duerst@it.aoyama.ac.jp> [2007-06-22 11:35]:
> Another exception occasionally are things such as &nbsp;, where
> one might prefer explicitness over direct visibility.

You mean &#160;.

:-)

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>




From owner-atom-syntax@mail.imc.org Sat Jun 23 13:00:28 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I28yK-0000qM-0N
	for atompub-archive@lists.ietf.org; Sat, 23 Jun 2007 13:00:28 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I28yI-0004DO-K2
	for atompub-archive@lists.ietf.org; Sat, 23 Jun 2007 13:00:27 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5NGb3LH090780
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 23 Jun 2007 09:37:03 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5NGb3sn090779;
	Sat, 23 Jun 2007 09:37:03 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5NGb0g2090764
	for <atom-syntax@imc.org>; Sat, 23 Jun 2007 09:37:02 -0700 (MST)
	(envelope-from lisa@osafoundation.org)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1])
	by laweleka.osafoundation.org (Postfix) with ESMTP id A0789142206;
	Sat, 23 Jun 2007 09:36:59 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
Received: from laweleka.osafoundation.org ([127.0.0.1])
	by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id XC3oNqRPCW8A; Sat, 23 Jun 2007 09:36:58 -0700 (PDT)
Received: from [192.168.1.100] (unknown [74.95.2.169])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(No client certificate requested)
	by laweleka.osafoundation.org (Postfix) with ESMTP id 55DDC142204;
	Sat, 23 Jun 2007 09:36:58 -0700 (PDT)
In-Reply-To: <20070622010401.GA19723@klangraum>
References: <AE9A8CBCE1A9744D975A9FBBF822DD784DE1536BB6@NA-EXMSG-C102.redmond.corp.microsoft.com> <73EF1BD4-747B-459E-A27F-7D679262F6C4@sun.com> <AE9A8CBCE1A9744D975A9FBBF822DD784DE1536DE3@NA-EXMSG-C102.redmond.corp.microsoft.com> <577F866F-248D-41A8-8EDF-677AC0CFA271@Sun.COM> <9180A892-A2C6-4B78-9038-AAFE319DCE08@osafoundation.org> <20070622010401.GA19723@klangraum>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed
Message-Id: <29B219DA-166A-43A5-849D-19231535743A@osafoundation.org>
Cc: Atom <atom-syntax@imc.org>
From: Lisa Dusseault <lisa@osafoundation.org>
Subject: Re: Is it just us?
Date: Sat, 23 Jun 2007 09:36:49 -0700
To: "A. Pagaltzis" <pagaltzis@gmx.de>
X-Mailer: Apple Mail (2.752.3)
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l5NGb2g2090774
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id l5NGb3LH090780
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a



On Jun 21, 2007, at 6:04 PM, A. Pagaltzis wrote:

>
>> A very direct reading of the data format suggests to me that
>> the  questions Atom is most organized to answer are:
>>
>> What's new?
>> For each new thing:
>> 	... who wrote it, when?
>> 	... how do I get the rest of it?
>
> If you leave out the =93What=92s new=94 question and generically say
> =93for each listed thing=94, then that=92s not bad.

I guess that's true, as you pointed out there's no requirement that =20
the entries that a server lists even be recent ones.

So then the things you can rely on Atom (without extensions) to tell =20
you about a collection of information reduces to:

What entries of this collection do you care to inform me about?
	... who wrote each one, when were they updated?
	... how do I get the rest of each one?

Lisa






From owner-atom-syntax@mail.imc.org Sun Jun 24 11:07:10 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I2TgE-0000nc-HN
	for atompub-archive@lists.ietf.org; Sun, 24 Jun 2007 11:07:10 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1I2TgC-0006Uf-Vk
	for atompub-archive@lists.ietf.org; Sun, 24 Jun 2007 11:07:10 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5OEjbkM057333
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 24 Jun 2007 07:45:37 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5OEjbRP057332;
	Sun, 24 Jun 2007 07:45:37 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5OEjZeR057314
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 24 Jun 2007 07:45:36 -0700 (MST)
	(envelope-from nikunj.mehta@oracle.com)
Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.186.112])
	by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l5OEjXXm002433;
	Sun, 24 Jun 2007 09:45:34 -0500
Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150])
	by rgmgw3.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l5OE79vO030714;
	Sun, 24 Jun 2007 08:45:33 -0600
Received: from dhcp-amer-whq-csvpn-gw3-141-144-80-180.vpn.oracle.com by acsmt350.oracle.com
	with ESMTP id 2983295811182696220; Sun, 24 Jun 2007 07:43:40 -0700
Message-ID: <467E831C.3040205@oracle.com>
Date: Sun, 24 Jun 2007 07:43:40 -0700
From: Nikunj Mehta <nikunj.mehta@oracle.com>
Organization: Oracle
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To: atom-protocol Protocol <atom-protocol@imc.org>, atom-syntax@imc.org
Subject: Re: Hierarchy - Part 2 - How we think our data would look in ATOM
References: <AE9A8CBCE1A9744D975A9FBBF822DD784DE1536BE0@NA-EXMSG-C102.redmond.corp.microsoft.com> <20070621033816.GC12530@klangraum> <AE9A8CBCE1A9744D975A9FBBF822DD784DE1537099@NA-EXMSG-C102.redmond.corp.microsoft.com> <20070623123415.GQ19723@klangraum>
In-Reply-To: <20070623123415.GQ19723@klangraum>
Content-Type: text/plain; charset=UTF-8; format=flowed
X-Whitelist: TRUE
X-Whitelist: TRUE
X-Brightmail-Tracker: AAAAAQAAAAI=
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id l5OEjbkM057333
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2


A. Pagaltzis wrote:
> That=E2=80=99s probably still too loose for you, since it=E2=80=99s not=
 really
> different from linking =E2=80=93 the only difference is that it links v=
ia
> on Atom Entry ID instead of HTTP URI, so I assume it would have
> the same problems.
>  =20
IIUC,  in-reply-to uses ref identify an Entry ID and href to identify=20
the edit URI of the entry (where available). Is that correct?

Nikunj




From owner-atom-syntax@mail.imc.org Sun Jun 24 11:11:08 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I2Tk3-0003jf-Ui
	for atompub-archive@lists.ietf.org; Sun, 24 Jun 2007 11:11:08 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1I2Tk2-0006tW-GU
	for atompub-archive@lists.ietf.org; Sun, 24 Jun 2007 11:11:07 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5OEqoBu059317
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 24 Jun 2007 07:52:50 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5OEqoSC059316;
	Sun, 24 Jun 2007 07:52:50 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail1.webfaction.com (mail1.webfaction.com [67.15.2.85])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5OEqmDf059306
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 24 Jun 2007 07:52:49 -0700 (MST)
	(envelope-from sh@defuze.org)
Received: from [192.168.0.2] ([89.240.107.68])
	(authenticated bits=0)
	by mail1.webfaction.com (8.12.11.20060308/8.13.3) with ESMTP id l5OEqgmZ029310;
	Sun, 24 Jun 2007 09:52:46 -0500
Message-ID: <467E8535.3000307@defuze.org>
Date: Sun, 24 Jun 2007 15:52:37 +0100
From: Sylvain Hellegouarch <sh@defuze.org>
User-Agent: Thunderbird 1.5.0.12 (X11/20070604)
MIME-Version: 1.0
To: Nikunj Mehta <nikunj.mehta@oracle.com>
CC: atom-protocol Protocol <atom-protocol@imc.org>, atom-syntax@imc.org
Subject: Re: Hierarchy - Part 2 - How we think our data would look in ATOM
References: <AE9A8CBCE1A9744D975A9FBBF822DD784DE1536BE0@NA-EXMSG-C102.redmond.corp.microsoft.com> <20070621033816.GC12530@klangraum> <AE9A8CBCE1A9744D975A9FBBF822DD784DE1537099@NA-EXMSG-C102.redmond.corp.microsoft.com> <20070623123415.GQ19723@klangraum> <467E831C.3040205@oracle.com>
In-Reply-To: <467E831C.3040205@oracle.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id l5OEqoBu059317
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8


Nikunj Mehta a =C3=A9crit :
>
> A. Pagaltzis wrote:
>> That=E2=80=99s probably still too loose for you, since it=E2=80=99s no=
t really
>> different from linking =E2=80=93 the only difference is that it links =
via
>> on Atom Entry ID instead of HTTP URI, so I assume it would have
>> the same problems.
>>  =20
> IIUC,  in-reply-to uses ref identify an Entry ID and href to identify=20
> the edit URI of the entry (where available). Is that correct?
>
> Nikunj
Almost. The href points at any IRI where to retrieve a representation of=20
the resource not specifically the edit URI.

- Sylvain




From owner-atom-syntax@mail.imc.org Thu Jun 28 00:36:15 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I3ljr-0005tQ-H0
	for atompub-archive@lists.ietf.org; Thu, 28 Jun 2007 00:36:15 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I3lf5-0008PM-Uv
	for atompub-archive@lists.ietf.org; Thu, 28 Jun 2007 00:31:24 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5S45ZcH097561
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 27 Jun 2007 21:05:36 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5S45ZBH097560;
	Wed, 27 Jun 2007 21:05:35 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5S45YvF097554
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Wed, 27 Jun 2007 21:05:35 -0700 (MST)
	(envelope-from mnot@mnot.net)
Received: from [127.0.0.1] (unknown [216.145.54.158])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 7B7A751941
	for <atom-syntax@imc.org>; Thu, 28 Jun 2007 00:05:28 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v752.2)
References: <E1I3JrG-0001Ps-1Z@stiedprstage1.ietf.org>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <E9E92DF3-8111-43AE-AF49-24C1D29C6CB9@mnot.net>
Content-Transfer-Encoding: 7bit
X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg
From: Mark Nottingham <mnot@mnot.net>
Subject: Fwd: I-D ACTION:draft-nottingham-atompub-feed-history-11.txt 
Date: Thu, 28 Jun 2007 14:05:23 +1000
To: atom-syntax Syntax <atom-syntax@imc.org>
X-Mailer: Apple Mail (2.752.2)
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8


FYI. Diff at:
   <http://www.mnot.net/drafts/draft-nottingham-atompub-feed-history/ 
draft-nottingham-atompub-feed-history-11-from-10.diff.html>


Begin forwarded message:

> From: Internet-Drafts@ietf.org
> Date: 27 June 2007 8:50:02 AM
> To: i-d-announce@ietf.org
> Subject: I-D ACTION:draft-nottingham-atompub-feed-history-11.txt
> Reply-To: internet-drafts@ietf.org
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> 	Title		: Feed Paging and Archiving
> 	Author(s)	: M. Nottingham
> 	Filename	: draft-nottingham-atompub-feed-history-11.txt
> 	Pages		: 15
> 	Date		: 2007-6-26
> 	
> This specification defines three types of syndicated Web feeds that
>    enable publication of entries across one or more feed documents.
>    This includes "paged" feeds for piecemeal access, "archived" feeds
>    that allow reconstruction of the feed's contents, and feeds that  
> are
>    explicitly "complete".
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-nottingham-atompub-feed- 
> history-11.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> i-d-announce-request@ietf.org with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
> "get draft-nottingham-atompub-feed-history-11.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	mailserv@ietf.org.
> In the body type:
> 	"FILE /internet-drafts/draft-nottingham-atompub-feed-history-11.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> Content-Type: text/plain
> Content-ID: <2007-6-26164840.I-D@ietf.org>
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www1.ietf.org/mailman/listinfo/i-d-announce


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




From toij6565@yahoo.co.jp Thu Jun 28 07:31:35 2007
Return-path: <toij6565@yahoo.co.jp>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I3sDm-0002n3-WD
	for ATOMPUB-ARCHIVE@LISTS.IETF.ORG; Thu, 28 Jun 2007 07:31:35 -0400
Received: from [221.202.14.243] (helo=so-net.ne.jp)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1I3sDm-0006cO-5x
	for ATOMPUB-ARCHIVE@LISTS.IETF.ORG; Thu, 28 Jun 2007 07:31:34 -0400
Received: from emb9 (unknown [84.236.251.131])
	by smtp45 (Coremail) with SMTP id nu2ordISqIcFppoj.1
	for <atompub-archive@lists.ietf.org>; Thu, 21 Jun 2007 19:33:57 +0800 (CST)
X-Originating-IP: [84.236.251.131]
Subject: =?iso-2022-jp?B?GyRCJS8lcyVLRkAwVSRHJDkkKyEpGyhC?=
From: =?shift-jis?B?aW5mb3JtYXRpb24=?= <toij6565@yahoo.co.jp>
To: <atompub-archive@lists.ietf.org>
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0008_01C7AF4A.3CDEE5F0"
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 4.1 (++++)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa

This is a multi-part message in MIME format.

------=_NextPart_000_0008_01C7AF4A.3CDEE5F0
Content-Type: text/plain;
	charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit

クンニされるのが大好きなんです・・・
ただとは言いません！
お礼として少ないんですが、3万渡すので、クンニし続けてくれませんか？
千尋で検索して下さい。 http://pure-love.biz/yu/?dd36

是非、よろしくお願いします。

------=_NextPart_000_0008_01C7AF4A.3CDEE5F0
Content-Type: text/html;
	charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-2022-jp">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3D"MS UI Gothic"=20
size=3D1><STRONG>=1B$B%/%s%K$5$l$k$N$,Bg9%$-$J$s$G$9!&!&!&=1B(B</STRONG><=
/FONT></DIV>
<DIV><FONT face=3D"MS UI Gothic" =
size=3D1><STRONG>=1B$B$?$@$H$O8@$$$^$;$s!*=1B(B</STRONG></FONT></DIV>
<DIV><FONT face=3D"MS UI Gothic"=20
size=3D1><STRONG>=1B$B$*Ni$H$7$F>/$J$$$s$G$9$,!"=1B(B3=1B$BK|EO$9$N$G!"%/=
%s%K$7B3$1$F$/$l$^$;$s$+!)=1B(B</STRONG></FONT></DIV>
<DIV><FONT face=3D"MS UI Gothic"><FONT =
size=3D1><STRONG>=1B$B@i?R$G8!:w$7$F2<$5$$!#=1B(B=20
</STRONG></FONT><A href=3D"http://pure-love.biz/yu/?dd36"><FONT=20
size=3D1><STRONG>http://pure-love.biz/yu/?dd36</STRONG></FONT></A><BR></F=
ONT></DIV>
<DIV><FONT face=3D"MS UI Gothic"=20
size=3D1><STRONG>=1B$B@'Hs!"$h$m$7$/$*4j$$$7$^$9!#=1B(B</STRONG></FONT></=
DIV></BODY></HTML>

------=_NextPart_000_0008_01C7AF4A.3CDEE5F0--




From aaaaaasssss34@yahoo.co.uk Sat Jun 30 02:34:56 2007
Return-path: <aaaaaasssss34@yahoo.co.uk>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I4WXo-0006g9-60
	for atompub-archive@lists.ietf.org; Sat, 30 Jun 2007 02:34:56 -0400
Received: from [124.94.2.211] (helo=so-net.ne.jp)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1I4WXm-0007ka-Rd
	for atompub-archive@lists.ietf.org; Sat, 30 Jun 2007 02:34:56 -0400
Received: from Jp4GuAOeOP (unknown [111.150.193.3])
	by so-net.ne.jp (Coremail) with SMTP id 3Uwh0BEhk8lsgH0H.1
	for <atompub-archive@lists.ietf.org>; Mon, 30 Jun 2008 14:36:05 +0800 (CST)
X-Originating-IP: [111.150.193.3]
Subject: =?iso-2022-jp?B?GyRCIzQycxsoQjIwGyRCS3wbKEI=?=
From: "mizuho" <aaaaaasssss34@yahoo.co.uk >
To: <atompub-archive@lists.ietf.org>
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0006_01C8C1B9.437FD220"
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 4.4 (++++)
X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac

This is a multi-part message in MIME format.

------=_NextPart_000_0006_01C8C1B9.437FD220
Content-Type: text/plain;
	charset="iso-2022-jp"
Content-Transfer-Encoding: base64

GyRCQ0tALSUiJWslUCUkJUhKZz04GyhCDQoNChskQj01GyhCMRskQiRHN1c7OyQ3JEYwbCV2N24k
RyM0MnMkRyMyIzBLfCRPMlQkMiReJDkhIztFO3ZGYk1GJE89d0AtJE5NV0s+JEskMyQ/JCgkayQz
JEghIxsoQg0KGyRCJCIkLyReJEckYjtFO3YkRyQ5JE4kRzhEP01FKiRKNDY+cCRLTi4kNSRsJEZM
ZEJqJCw1LyQtJD8+bDlnISI8KzhKQFVHJCRLJEokaiReJDkhIxsoQg0KDQobJEI7RTt2RmJNRiRP
JDEkQyQ3JEZGcSQ3JCQkYiROJEckTyQ0JDYkJCReJDskcyEjNS5KfSROJVohPCU5ISI1Lkp9JE47
fSRBTCMkckA4JCskNyRGQCdIczNaJDckXyRKJCwkaSQqNmIkcjJUJCQkRyQkJD8kQCQxJGwkUCRI
O1ckJCReJDkhIxsoQg0KDQobJEIkKjVrTkEkSzRYJDckXiQ3JEYkTzg9NmI8akVPJDchIj82OX4k
XyQrJGlBKiRZJF4kOSEjQTA8WiRqJEokSSRiQWpDTCRLJE4kaiReJDkhIxsoQiANCg0KGyRCJCo7
RTt2JE4+XCQ3JCQ+XDpZJEskRCQtJF4kNyRGJE8lMyVBJWkkcjsyPkgkNyRGJC8kQCQ1JCQhIxso
Qg0KGyRCIiobKEIgICAgaHR0cDovL3B1cmUtbG92ZS5iaXoveXUvP2RkMjYNCg0KGyRCNSQ3WiRL
JCpNJ0MjJEgwbD1vJEskNE8iTW0kLyRAJDUkJCEjGyhCDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K
DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN
Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K
DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN
Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K
DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNChskQkF3Py4ycj18GyhCDQpob3Nvbm8x
NDV5dWtvQHlhaG9vLmNvLnVrDQoNCg0KDQo=

------=_NextPart_000_0006_01C8C1B9.437FD220
Content-Type: text/html;
	charset="iso-2022-jp"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby0yMDIyLWpwIj4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRN
TCA2LjAwLjI5MDAuMjE4MCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB
RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT0iTVMgVUkgR290aGlj
IiBzaXplPTI+DQo8RElWPjxTVFJPTkc+PEZPTlQgY29sb3I9IzAwODA4MCBzaXplPTQ+GyRCQ0tA
LSUiJWslUCUkJUhKZz04GyhCPC9GT05UPjwvU1RST05HPjwvRElWPg0KPERJVj48U1RST05HPjxG
T05UIHNpemU9Mj48L0ZPTlQ+PC9TVFJPTkc+Jm5ic3A7PC9ESVY+DQo8RElWPjxTVFJPTkc+PEZP
TlQgDQpzaXplPTE+GyRCPTUbKEIxGyRCJEc3Vzs7JDckRjBsJXY3biRHIzQycyRHIzIjMEt8JE8y
VCQyJF4kOSEjO0U7dkZiTUYkTz13QC0kTk1XSz4kSyQzJD8kKCRrJDMkSCEjGyhCPEJSPhskQiQi
JC8kXiRHJGI7RTt2JEckOSROJEc4RD9NRSokSjQ2PnAkS04uJDUkbCRGTGRCaiQsNS8kLSQ/Pmw5
ZyEiPCs4SkBVRyQkSyRKJGokXiQ5ISMbKEI8QlI+PEJSPhskQjtFO3ZGYk1GJE8kMSRDJDckRkZx
JDckJCRiJE4kRyRPJDQkNiQkJF4kOyRzISM1Lkp9JE4lWiE8JTkhIjUuSn0kTjt9JEFMIyRyQDgk
KyQ3JEZAJ0hzM1okNyRfJEokLCRpJCo2YiRyMlQkJCRHJCQkPyRAJDEkbCRQJEg7VyQkJF4kOSEj
GyhCPEJSPjxCUj4bJEIkKjVrTkEkSzRYJDckXiQ3JEYkTzg9NmI8akVPJDchIj82OX4kXyQrJGlB
KiRZJF4kOSEjQTA8WiRqJEokSSRiQWpDTCRLJE4kaiReJDkhIxsoQiANCjxCUj48QlI+GyRCJCo7
RTt2JE4+XCQ3JCQ+XDpZJEskRCQtJF4kNyRGJE8lMyVBJWkkcjsyPkgkNyRGJC8kQCQ1JCQhIxso
QjxCUj4bJEIiKhsoQiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxBIA0KaHJlZj0iaHR0cDovL3B1
cmUtbG92ZS5iaXoveXUvP2RkMjYiPmh0dHA6Ly9wdXJlLWxvdmUuYml6L3l1Lz9kZDI2PC9BPjxB
IA0KaHJlZj0iaHR0cDovL2Jlc3QuZmluYWwtbG92ZS5uZXQvP2RkMjYiPjwvQT48QSANCmhyZWY9
Imh0dHA6Ly9jYjQwNS5pcHRpbWUub3JnL2Jlc3QvP2RkMjYiPjwvQT48L0ZPTlQ+PC9TVFJPTkc+
PC9ESVY+DQo8RElWPjxCUj48U1RST05HPjxGT05UIA0Kc2l6ZT0xPhskQjUkN1okSyQqTSdDIyRI
MGw9byRLJDRPIk1tJC8kQCQ1JCQhIxsoQjwvRk9OVD48L1NUUk9ORz48QlI+PEJSPjxCUj48QlI+
PEJSPjxCUj48QlI+PEJSPjxCUj48QlI+PEJSPjxCUj48QlI+PEJSPjxCUj48QlI+PEJSPjxCUj48
QlI+PEJSPjxCUj48QlI+PEJSPjxCUj48QlI+PEJSPjxCUj48QlI+PEJSPjxCUj48QlI+PEJSPjxC
Uj48QlI+PEJSPjxCUj48QlI+PEJSPjxCUj48QlI+PEJSPjxCUj48QlI+PEJSPjxCUj48QlI+PEJS
PjxCUj48QlI+PEJSPjxCUj48QlI+PEJSPjxCUj48QlI+PEJSPjxCUj48QlI+PEJSPjxCUj48L0RJ
Vj4NCjxESVY+PEZPTlQgZmFjZT0iTVMgVUkgR290aGljIiBzaXplPTI+PC9GT05UPiZuYnNwOzwv
RElWPg0KPERJVj48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMiIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7
PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyIgc2l6ZT0yPjwvRk9OVD4mbmJz
cDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iTVMgVUkgR290aGljIiBzaXplPTI+PC9GT05UPiZu
YnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMiIHNpemU9Mj48L0ZPTlQ+
Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyIgc2l6ZT0yPjwvRk9O
VD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iTVMgVUkgR290aGljIiBzaXplPTI+PC9G
T05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMiIHNpemU9Mj48
L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyIgc2l6ZT0y
PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iTVMgVUkgR290aGljIiBzaXpl
PTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMiIHNp
emU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyIg
c2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iTVMgVUkgR290aGlj
IiBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJNUyBVSSBHb3Ro
aWMiIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdv
dGhpYyIgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iTVMgVUkg
R290aGljIiBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJNUyBV
SSBHb3RoaWMiIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1T
IFVJIEdvdGhpYyIgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0i
TVMgVUkgR290aGljIiBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNl
PSJNUyBVSSBHb3RoaWMiIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZh
Y2U9Ik1TIFVJIEdvdGhpYyIgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg
ZmFjZT0iTVMgVUkgR290aGljIiBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9O
VCBmYWNlPSJNUyBVSSBHb3RoaWMiIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxG
T05UIGZhY2U9Ik1TIFVJIEdvdGhpYyIgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+
PEZPTlQgZmFjZT0iTVMgVUkgR290aGljIiBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJ
Vj48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMiIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8
RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyIgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4N
CjxESVY+PEZPTlQgZmFjZT0iTVMgVUkgR290aGljIiBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElW
Pg0KPERJVj48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMiIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9E
SVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyIgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8
L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iTVMgVUkgR290aGljIiBzaXplPTI+PC9GT05UPiZuYnNw
OzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMiIHNpemU9Mj48L0ZPTlQ+Jm5i
c3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyIgc2l6ZT0yPjwvRk9OVD4m
bmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iTVMgVUkgR290aGljIiBzaXplPTI+PC9GT05U
PiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMiIHNpemU9Mj48L0ZP
TlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyIgc2l6ZT0yPjwv
Rk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iTVMgVUkgR290aGljIiBzaXplPTI+
PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMiIHNpemU9
Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyIgc2l6
ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iTVMgVUkgR290aGljIiBz
aXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMi
IHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhp
YyIgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iTVMgVUkgR290
aGljIiBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJNUyBVSSBH
b3RoaWMiIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJ
IEdvdGhpYyIgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iTVMg
VUkgR290aGljIiBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJN
UyBVSSBHb3RoaWMiIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9
Ik1TIFVJIEdvdGhpYyIgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFj
ZT0iTVMgVUkgR290aGljIiBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBm
YWNlPSJNUyBVSSBHb3RoaWMiIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U
IGZhY2U9Ik1TIFVJIEdvdGhpYyIgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZP
TlQgZmFjZT0iTVMgVUkgR290aGljIiBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48
Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMiIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElW
PjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyIgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxE
SVY+PEZPTlQgZmFjZT0iTVMgVUkgR290aGljIiBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0K
PERJVj48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMiIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+
DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyIgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJ
Vj4NCjxESVY+PEZPTlQgZmFjZT0iTVMgVUkgR290aGljIiBzaXplPTI+PC9GT05UPiZuYnNwOzwv
RElWPg0KPERJVj48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMiIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7
PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyIgc2l6ZT0yPjwvRk9OVD4mbmJz
cDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iTVMgVUkgR290aGljIiBzaXplPTI+PC9GT05UPiZu
YnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMiIHNpemU9Mj48L0ZPTlQ+
Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyIgc2l6ZT0yPjwvRk9O
VD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iTVMgVUkgR290aGljIiBzaXplPTI+PC9G
T05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMiIHNpemU9Mj48
L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyIgc2l6ZT0y
PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iTVMgVUkgR290aGljIiBzaXpl
PTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMiIHNp
emU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyIg
c2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iTVMgVUkgR290aGlj
IiBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJNUyBVSSBHb3Ro
aWMiIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdv
dGhpYyIgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iTVMgVUkg
R290aGljIiBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJNUyBV
SSBHb3RoaWMiIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxCUj48QlI+PEJSPjxC
Uj48QlI+PEJSPjxCUj48QlI+PFNUUk9ORz48Rk9OVCANCnNpemU9MT4bJEJBdz8uMnI9fBsoQjxC
Uj48L0ZPTlQ+PC9TVFJPTkc+PEZPTlQgZmFjZT0iTVMgVUkgR290aGljIiBzaXplPTI+PEEgDQpo
cmVmPSJtYWlsdG86aG9zb25vMTQ1eXVrb0B5YWhvby5jby51ayI+aG9zb25vMTQ1eXVrb0B5YWhv
by5jby51azwvQT48QSANCmhyZWY9IiI+PC9BPjxBIGhyZWY9IiI+PC9BPjwvRk9OVD48QSBocmVm
PSIiPjxTVFJPTkc+PEZPTlQgDQpzaXplPTI+PC9GT05UPjwvU1RST05HPjwvQT48QlI+PC9ESVY+
DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyIgc2l6ZT0yPjxTVFJPTkc+PC9TVFJPTkc+
PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMiIHNpemU9
Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyIgDQpz
aXplPTI+PC9GT05UPiZuYnNwOzwvRElWPjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K

------=_NextPart_000_0006_01C8C1B9.437FD220--