From owner-atom-syntax@mail.imc.org  Thu Jun  2 12:20:22 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03688
	for <atompub-archive@lists.ietf.org>; Thu, 2 Jun 2005 12:20:21 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j52GCbvO005042;
	Thu, 2 Jun 2005 09:12:37 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j52GCbLX005041;
	Thu, 2 Jun 2005 09:12:37 -0700 (PDT)
X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j52GCZ4o005031;
	Thu, 2 Jun 2005 09:12:35 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j52GCZn0028343;
	Thu, 2 Jun 2005 10:12:35 -0600 (MDT)
Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004))
 with ESMTP id <0IHG0063LT0YCN@edgemail1.Central.Sun.COM>; Thu,
 02 Jun 2005 10:12:35 -0600 (MDT)
Received: from [192.168.1.31] ([216.113.204.6])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004))
 with ESMTPSA id <0IHG00926T0S8J@mail.sun.net>; Thu,
 02 Jun 2005 10:12:29 -0600 (MDT)
Date: Thu, 02 Jun 2005 09:12:21 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Moving along with protocol work
To: Atom Protocol <atom-protocol@imc.org>, Atom Syntax <atom-syntax@imc.org>
Message-id: <BAC36F2C-AF64-4FCE-B83B-DB4012FE039E@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.730)
Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
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>
Content-Transfer-Encoding: 7BIT


<co-chair-mode>

1. For the time being, we'll continue to have the protocol  
discussions on the atom-protocol mailing list.

2. Sam is working on the PubIssuesList, stand by for word from him.

3. We're happy to see good discussion about collections and entry- 
status and so on.  The rules haven't changed: nothing can really be  
decided officially until there's a Pace with specific wording  
suggestions.  So there's nothing wrong with this kind of informal  
discussion, but do please start to think about getting the good ideas  
captured in Paces.

4. Paul has just requested a change to the WG milestones, and Scott  
has approved them:

   Done          First Atom feed format Internet Draft
   Done          First Atom editing protocol Internet Draft
   Done          Request Last Call for Atom feed format
Jun 05          Submit Atom feed format to IESG for consideration as  
a Proposed Standard
Oct 05          Request Last Call for Atom editing protocol
Nov 05          Submit Atom editing protocol to IESG for  
consideration as a Proposed Standard

</co-chair-mode>



From owner-atom-syntax@mail.imc.org  Thu Jun  2 13:45:20 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10847
	for <atompub-archive@lists.ietf.org>; Thu, 2 Jun 2005 13:45:20 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j52HbjXX012507;
	Thu, 2 Jun 2005 10:37:46 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j52HbjLE012503;
	Thu, 2 Jun 2005 10:37:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web52005.mail.yahoo.com (web52005.mail.yahoo.com [206.190.39.61])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j52HbjBi012477
	for <atom-syntax@imc.org>; Thu, 2 Jun 2005 10:37:45 -0700 (PDT)
	(envelope-from ecomputerd@yahoo.com)
Received: (qmail 67783 invoked by uid 60001); 2 Jun 2005 17:37:34 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=zR9oK8CcuAvTQbW6jRj01UWnkBbgGqMS3X4Z05GoX7ou4tnQhyAL71Xl0MybMLckgF7tx2RZMvrqrXw0junSDQ+xIapKtTSrrkGU/9nMoGvkR2PrSWZC5H0CkB23MGUVJn86/Ypl5VAx2IyblH3xbbNNYmswlct8pR2372WGLoc=  ;
Message-ID: <20050602173734.67781.qmail@web52005.mail.yahoo.com>
Received: from [65.15.100.176] by web52005.mail.yahoo.com via HTTP; Thu, 02 Jun 2005 10:37:34 PDT
Date: Thu, 2 Jun 2005 10:37:34 -0700 (PDT)
From: Greg Smith <ecomputerd@yahoo.com>
Subject: Re: Moving along with protocol work
To: Tim Bray <Tim.Bray@Sun.COM>, Atom Protocol <atom-protocol@imc.org>,
        Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <BAC36F2C-AF64-4FCE-B83B-DB4012FE039E@sun.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
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: 8bit


I see that some of the ideas are coming full circle to
what I had posted a few weeks ago on per-collection
list of MIME types. I can take a stab at the Pace, but
I'm very new to this process (think: pre-green, not
even rooted).

Can you point to a link describing maybe the process
and specifically the structure, format, and submission
guidelines for official documents such as a Pace.

I (think I) would use my previous post, which included
example text and example use along with a modification
of an existing example, as a basis for the document.

Greg Smith


--- Tim Bray <Tim.Bray@Sun.COM> wrote:

> 
> <co-chair-mode>
> 
> 1. For the time being, we'll continue to have the
> protocol  
> discussions on the atom-protocol mailing list.
> 
> 2. Sam is working on the PubIssuesList, stand by for
> word from him.
> 
> 3. We're happy to see good discussion about
> collections and entry- 
> status and so on.  The rules haven't changed:
> nothing can really be  
> decided officially until there's a Pace with
> specific wording  
> suggestions.  So there's nothing wrong with this
> kind of informal  
> discussion, but do please start to think about
> getting the good ideas  
> captured in Paces.
> 
> 4. Paul has just requested a change to the WG
> milestones, and Scott  
> has approved them:
> 
>    Done          First Atom feed format Internet
> Draft
>    Done          First Atom editing protocol
> Internet Draft
>    Done          Request Last Call for Atom feed
> format
> Jun 05          Submit Atom feed format to IESG for
> consideration as  
> a Proposed Standard
> Oct 05          Request Last Call for Atom editing
> protocol
> Nov 05          Submit Atom editing protocol to IESG
> for  
> consideration as a Proposed Standard
> 
> </co-chair-mode>
> 
> 



		
__________________________________ 
Discover Yahoo! 
Have fun online with music videos, cool games, IM and more. Check it out! 
http://discover.yahoo.com/online.html



From owner-atom-syntax@mail.imc.org  Thu Jun  2 14:07:15 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12394
	for <atompub-archive@lists.ietf.org>; Thu, 2 Jun 2005 14:07:15 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j52Hu7px015010;
	Thu, 2 Jun 2005 10:56:07 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j52Hu7CZ015008;
	Thu, 2 Jun 2005 10:56:07 -0700 (PDT)
X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j52Hu5Be014994;
	Thu, 2 Jun 2005 10:56:05 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j52Hu5n0011350;
	Thu, 2 Jun 2005 11:56:05 -0600 (MDT)
Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004))
 with ESMTP id <0IHG007MCXTG3J@edgemail1.Central.Sun.COM>; Thu,
 02 Jun 2005 11:56:05 -0600 (MDT)
Received: from [192.168.102.100] ([154.20.140.182])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004))
 with ESMTPSA id <0IHG000TWXTG8A@mail.sun.net>; Thu,
 02 Jun 2005 11:56:04 -0600 (MDT)
Date: Thu, 02 Jun 2005 10:56:01 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Moving along with protocol work
In-reply-to: <20050602173734.67781.qmail@web52005.mail.yahoo.com>
To: Greg Smith <ecomputerd@yahoo.com>
Cc: Atom Protocol <atom-protocol@imc.org>, Atom Syntax <atom-syntax@imc.org>
Message-id: <A28D9A8C-FBF5-4FDB-AD66-9FF3194F3B87@Sun.COM>
MIME-version: 1.0
X-Mailer: Apple Mail (2.730)
Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Content-transfer-encoding: 7BIT
References: <20050602173734.67781.qmail@web52005.mail.yahoo.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>
Content-Transfer-Encoding: 7BIT


On Jun 2, 2005, at 10:37 AM, Greg Smith wrote:

> Can you point to a link describing maybe the process
> and specifically the structure, format, and submission
> guidelines for official documents such as a Pace.

Don't know of such a link, so here's how it works.

Well, go to the wiki (starting at http://www.intertwingly.net/wiki/ 
pie/AtomPubIssuesList) and read a few Paces to get a feel for it.   
What I usually do is find a Pace that's suggesting changes similar in  
flavor to the ones I have in mind, hit "Edit this page", copy, the  
source code, hit "cancel", then if I want to create  
PaceTimsBrainstorm  I go and edit http://www.intertwingly.net/wiki/ 
pie/TimsBrainstorm, the Wiki notices that it doesn't exist, I hit  
"create this page" and paste in all the source I copied from the  
previous page, edit it, and there you go.

Exception: if it's a big complicated hairy thing, I take the saved  
source and paste it into my desktop text editor and fix it up there  
before I paste it into the new page.

If you know some other people on the list who you think might agree  
with you, contact them have them take a look at the Pace and suggest  
improvements.

Once you've done that, send a message to the list saying "I just  
posted PaceXXX".  Some people actually copy the text of the Pace into  
the email, others just post a link,.

Then duck.

-Tim



From owner-atom-syntax@mail.imc.org  Fri Jun  3 17:37:27 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16741
	for <atompub-archive@lists.ietf.org>; Fri, 3 Jun 2005 17:37:27 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j53LSfs8007852;
	Fri, 3 Jun 2005 14:28:41 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j53LSfRD007851;
	Fri, 3 Jun 2005 14:28:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from omr4.netsolmail.com (omr4.netsolmail.com [216.168.230.140])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j53LSeTA007845
	for <atom-syntax@imc.org>; Fri, 3 Jun 2005 14:28:41 -0700 (PDT)
	(envelope-from bob@wyman.us)
Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180])
	by omr4.netsolmail.com (8.12.10/8.12.10) with ESMTP id j53LSdeB018898
	for <atom-syntax@imc.org>; Fri, 3 Jun 2005 17:28:40 -0400 (EDT)
Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34])
	by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA)
	with ESMTP id DID59534 (AUTH bob@wyman.us);
	Fri, 3 Jun 2005 17:28:37 -0400 (EDT)
Message-Id: <200506032128.DID59534@ms8.netsolmail.com>
Reply-To: <bob@wyman.us>
From: "Bob Wyman" <bob@wyman.us>
To: <atom-syntax@imc.org>
Subject: Google Sitemaps: Yet another "RSS" or site-metadata format and Atom "competitor"
Date: Fri, 3 Jun 2005 17:28:35 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00D7_01C56861.AC665070"
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Thread-Index: AcVogzLRBr37GJUpSOuKCy9c+OWmkA==
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>


This is a multi-part message in MIME format.

------=_NextPart_000_00D7_01C56861.AC665070
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Google has released "Sitemaps" which is yet-another-format for doing "site
summary" or site-metadata publication. Unlike commonly used RSS formats or
Atom, Sitemaps are only intended to communicate information about URLs that
have been updated - not the content of those URLs. However, it seems quite
clear to me that even though the goals of Sitemaps are a distinct subset of
those we have for Atom, there isn't really much reason why they needed to go
off and define a completely different and incompatible format.

 

Perhaps if this group had dealt with the issue of "pinging" this divergence
wouldn't have occurred. (Yes, I know it wasn't in-charter.) The Sitemap
format can be thought of as very much like a "ping file" since it basically
contains little more than info on the update time for urls. 

 

I've blogged about SiteMaps at:

http://bobwyman.pubsub.com/main/2005/06/google_sitemaps.html

 

There are two formats defined by Sitemaps:

1.       A Sitemap format which lists URLs and provides their last-update
time, priority, and update-frequency.

2.       A Sitemap index that points to other sitemaps. (One sitemap is
required for each unique path-tree on a site.)

 

Something similar to Sitemaps would actually be quite useful in helping us
work out the issues related to sites that have multiple feeds (i.e. three
flavors of RSS and one or two flavors of Atom.). One might provide a Sitemap
Index that listed each feed. This would make identifying duplicate feeds
much easier than it is today. A Sitemap might also be a really interesting
place to put information on a sites signing and encryption keys.

 

Perhaps we can convince Google to work with the Atom Working Group on
starting an effort to define more compatible formats and also to build a
pinging standard that would be useful to both the blogosphere and the
traditional web. We've proven in the blogosphere that providing
site-metadata and summary information is very useful and we've proven the
value of pinging. Now, it will be wonderful if we can help move those
methods to the rest of the web.

 

            bob wyman

 


------=_NextPart_000_00D7_01C56861.AC665070
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Batang;
	panose-1:2 3 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:"\@Batang";
	panose-1:2 3 6 0 0 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:2037386266;
	mso-list-type:hybrid;
	mso-list-template-ids:-1213940294 -1519452932 67698713 67698715 =
67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-tab-stop:.75in;
	mso-level-number-position:left;
	margin-left:.75in;
	text-indent:-.25in;}
@list l0:level2
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:1.25in;
	mso-level-number-position:left;
	margin-left:1.25in;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>

</head>

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

<div class=3DSection1>

<p class=3DMsoNormal style=3D'text-indent:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Google has released =
&#8220;Sitemaps&#8221;
which is yet-another-format for doing &#8220;site summary&#8221; or
site-metadata publication. Unlike commonly used RSS formats or Atom, =
Sitemaps
are only intended to communicate information about URLs that have been =
updated &#8211;
not the content of those URLs. However, it seems quite clear to me that =
even
though the goals of Sitemaps are a distinct subset of those we have for =
Atom,
there isn&#8217;t really much reason why they needed to go off and =
define a
completely different and incompatible =
format.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-indent:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Perhaps if this group had =
dealt with
the issue of &#8220;pinging&#8221; this divergence wouldn&#8217;t have
occurred. (Yes, I know it wasn&#8217;t in-charter&#8230;) The Sitemap =
format
can be thought of as very much like a &#8220;ping file&#8221; since it
basically contains little more than info on the update time for urls. =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I&#8217;ve blogged about SiteMaps =
at:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><a
href=3D"http://bobwyman.pubsub.com/main/2005/06/google_sitemaps.html">htt=
p://bobwyman.pubsub.com/main/2005/06/google_sitemaps.html</a><o:p></o:p><=
/span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>There are two formats defined by =
Sitemaps:<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.75in;text-indent:-.25in;mso-list:l0 level1 =
lfo1'><![if !supportLists]><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><span
style=3D'mso-list:Ignore'>1.<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>A Sitemap
format which lists URLs and provides their last-update time, priority, =
and
update-frequency.<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.75in;text-indent:-.25in;mso-list:l0 level1 =
lfo1'><![if !supportLists]><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><span
style=3D'mso-list:Ignore'>2.<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>A Sitemap
index that points to other sitemaps. (One sitemap is required for each =
unique
path-tree on a site.)<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-indent:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Something similar to =
Sitemaps would
actually be quite useful in helping us work out the issues related to =
sites
that have multiple feeds (i.e. three flavors of RSS and one or two =
flavors of
Atom&#8230;). One might provide a Sitemap Index that listed each feed. =
This
would make identifying duplicate feeds much easier than it is today. A =
Sitemap
might also be a really interesting place to put information on a sites =
signing
and encryption keys&#8230;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-indent:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Perhaps we can convince =
Google to
work with the Atom Working Group on starting an effort to define more
compatible formats and also to build a pinging standard that would be =
useful to
both the blogosphere and the traditional web. We&#8217;ve proven in the
blogosphere that providing site-metadata and summary information is very =
useful
and we&#8217;ve proven the value of pinging. Now, it will be wonderful =
if we
can help move those methods to the rest of the =
web.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; bob wyman<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_00D7_01C56861.AC665070--



From owner-atom-syntax@mail.imc.org  Fri Jun  3 18:38:10 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21599
	for <atompub-archive@lists.ietf.org>; Fri, 3 Jun 2005 18:38:10 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j53MTeHp011894;
	Fri, 3 Jun 2005 15:29:40 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j53MTe6v011893;
	Fri, 3 Jun 2005 15:29:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from faceman.dreamhost.com (postfix@faceman.dreamhost.com [205.196.210.16])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j53MTdoL011884
	for <atom-syntax@imc.org>; Fri, 3 Jun 2005 15:29:40 -0700 (PDT)
	(envelope-from arve@virtuelvis.com)
Received: from wintermute (ti132110a080-7280.bb.online.no [85.165.156.112])
	by faceman.dreamhost.com (Postfix) with ESMTP
	id EC17C111D8B; Fri,  3 Jun 2005 15:29:36 -0700 (PDT)
Date: Sat, 04 Jun 2005 00:29:34 +0200
To: bob@wyman.us, atom-syntax@imc.org
Subject: Re: Google Sitemaps: Yet another "RSS" or site-metadata format and Atom "competitor"
References: <200506032128.DID59534@ms8.netsolmail.com>
From: "Arve Bersvendsen" <arve@virtuelvis.com>
Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-ID: <op.srtffkx96dxgxk@wintermute>
In-Reply-To: <200506032128.DID59534@ms8.netsolmail.com>
User-Agent: Opera M2/8.01 (Win32, build 7618)
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: 8bit


On Fri, 03 Jun 2005 23:28:35 +0200, Bob Wyman <bob@wyman.us> wrote:

> Perhaps we can convince Google to work with the Atom Working Group on
> starting an effort to define more compatible formats

Actually, Google Sitemaps is already compatible with the Google sitemap  
service. From  
<URL:https://www.google.com/webmasters/sitemaps/docs/en/faq.html#s8>:

# We also support the Open Archives Initiative (OAI) protocol for metadata
# harvesting, a popular protocol in the library world. If your sitemaps are
# already available in OAI-PMH version 2.0 format, you are welcome to  
submit
# these. We also accept RSS 2.0 and Atom 0.3 syndication feeds, using the
# link/lastMod fields.


-- 
Arve



From owner-atom-syntax@mail.imc.org  Fri Jun  3 18:49:32 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22109
	for <atompub-archive@lists.ietf.org>; Fri, 3 Jun 2005 18:49:32 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j53MhcPT012555;
	Fri, 3 Jun 2005 15:43:38 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j53Mhc85012554;
	Fri, 3 Jun 2005 15:43:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from faceman.dreamhost.com (postfix@faceman.dreamhost.com [205.196.210.16])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j53Mhcue012548
	for <atom-syntax@imc.org>; Fri, 3 Jun 2005 15:43:38 -0700 (PDT)
	(envelope-from arve@virtuelvis.com)
Received: from wintermute (ti132110a080-7280.bb.online.no [85.165.156.112])
	by faceman.dreamhost.com (Postfix) with ESMTP
	id B9944111DC4; Fri,  3 Jun 2005 15:43:36 -0700 (PDT)
To: bob@wyman.us, atom-syntax@imc.org
Subject: Re: Google Sitemaps: Yet another "RSS" or site-metadata format and Atom "competitor"
References: <200506032128.DID59534@ms8.netsolmail.com> <op.srtffkx96dxgxk@wintermute>
Message-ID: <op.srtf2wjm6dxgxk@wintermute>
From: "Arve Bersvendsen" <arve@virtuelvis.com>
Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Date: Sat, 04 Jun 2005 00:43:34 +0200
In-Reply-To: <op.srtffkx96dxgxk@wintermute>
User-Agent: Opera M2/8.01 (Win32, build 7618)
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: 8bit


On Sat, 04 Jun 2005 00:29:34 +0200, Arve Bersvendsen <arve@virtuelvis.com>  
wrote:

> Actually, Google Sitemaps is already compatible with the Google sitemap  
> service.

err. Make that "compatible with Atom"

-- 
Arve

http://virtuelvis.com - http://userjs.org



From owner-atom-syntax@mail.imc.org  Fri Jun  3 18:53:43 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22258
	for <atompub-archive@lists.ietf.org>; Fri, 3 Jun 2005 18:53:42 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j53Mmam1012890;
	Fri, 3 Jun 2005 15:48:36 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j53MmakC012889;
	Fri, 3 Jun 2005 15:48:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from omr3.netsolmail.com (omr3.netsolmail.com [216.168.230.164])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j53MmZZV012880
	for <atom-syntax@imc.org>; Fri, 3 Jun 2005 15:48:36 -0700 (PDT)
	(envelope-from bob@wyman.us)
Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180])
	by omr3.netsolmail.com (8.12.10/8.12.10) with ESMTP id j53MmZgt018466;
	Fri, 3 Jun 2005 18:48:35 -0400 (EDT)
Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34])
	by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA)
	with ESMTP id DID79351 (AUTH bob@wyman.us);
	Fri, 3 Jun 2005 18:48:33 -0400 (EDT)
Message-Id: <200506032248.DID79351@ms8.netsolmail.com>
Reply-To: <bob@wyman.us>
From: "Bob Wyman" <bob@wyman.us>
To: "'Arve Bersvendsen'" <arve@virtuelvis.com>, <bob@wyman.us>,
        <atom-syntax@imc.org>
Subject: RE: Google Sitemaps: Yet another "RSS" or site-metadata format and Atom "competitor"
Date: Fri, 3 Jun 2005 18:48:31 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <op.srtffkx96dxgxk@wintermute>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Thread-Index: AcVoi8CKJkXqBmu/TyCp1t3zlgNPoQAAYc3w
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: 7bit


Arve Bersvendsen wrote:
> Actually, Google Sitemaps is already compatible with [Atom].
	Yes, I've had a number of folk send me mail pointing to the FAQ that
I did not read as closely as I should. In fact, it is great that Google is
willing to accept Atom 0.3 files instead of just their Sitemap format.
Hopefully, this move will encourage many traditional web sites to start
producing Atom files to serve the role of "Rich Site Summaries" and allow us
to expand our feed services to cover non-blogs as well. 
	I do still think it unfortunate that Google felt compelled to invent
yet-another-format for Sitemaps. Because of Google's support for the Sitemap
format, it is inevitable that aggregation services are going to have to
start reading Sitemaps in addition to the billions of flavors of legacy RSS
and Atom files. Nonetheless, given the importance of any format that Google
supports, should we be considering providing support in Atom for the
priority element or some easily mapped equivelant? Also, I wonder what it
will take to get Google so say that they'll support Atom 1.0? It seems
obvious that they would, but it would be nice to know when they expect to do
it...
	The Sitemap Index files are proper and useful additions to what we
have now in the blogosphere and we should look carefully at either trying to
figure out how to incorporate this idea into what we do for Atom. Perhaps
something along the lines of Sitemap indexes could be incorporated into the
autodiscovery specification?

	bob wyman



From owner-atom-syntax@mail.imc.org  Fri Jun  3 19:20:19 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24119
	for <atompub-archive@lists.ietf.org>; Fri, 3 Jun 2005 19:20:19 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j53NBf4c015060;
	Fri, 3 Jun 2005 16:11:41 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j53NBfGw015059;
	Fri, 3 Jun 2005 16:11:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j53NBeJj015052
	for <atom-syntax@imc.org>; Fri, 3 Jun 2005 16:11:40 -0700 (PDT)
	(envelope-from jasnell@gmail.com)
Received: by wproxy.gmail.com with SMTP id 71so1049287wri
        for <atom-syntax@imc.org>; Fri, 03 Jun 2005 16:11:34 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=TTALPwHrvRC0P4EGi66eA294Y97ETK/w85LhJzsCqJEc8Otzbw44o2u97vvQqnYozAZO5VpULxgYmMHBZn54ge0CMxKy4r+xBOvIKbBhhl6IHr1qxc+BkzcfyKoynKzOf+MhT+xpD9v5oqff4xcIgLRi4mHRcY3aGenLqTKot4I=
Received: by 10.54.32.48 with SMTP id f48mr1516906wrf;
        Fri, 03 Jun 2005 16:11:06 -0700 (PDT)
Received: from ?192.168.1.102? ([67.181.223.222])
        by mx.gmail.com with ESMTP id g7sm1871808wra.2005.06.03.16.11.05;
        Fri, 03 Jun 2005 16:11:06 -0700 (PDT)
Message-ID: <42A0E384.7070305@gmail.com>
Date: Fri, 03 Jun 2005 16:11:00 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: bob@wyman.us, atom-syntax@imc.org
Subject: Re: Google Sitemaps: Yet another "RSS" or site-metadata format and
 Atom "competitor"
References: <200506032248.DID79351@ms8.netsolmail.com>
In-Reply-To: <200506032248.DID79351@ms8.netsolmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


Bob Wyman wrote:

>Arve Bersvendsen wrote:
>  
>
>>Actually, Google Sitemaps is already compatible with [Atom].
>>    
>>
>	Yes, I've had a number of folk send me mail pointing to the FAQ that
>I did not read as closely as I should. In fact, it is great that Google is
>willing to accept Atom 0.3 files instead of just their Sitemap format.
>Hopefully, this move will encourage many traditional web sites to start
>producing Atom files to serve the role of "Rich Site Summaries" and allow us
>to expand our feed services to cover non-blogs as well. 
>	I do still think it unfortunate that Google felt compelled to invent
>yet-another-format for Sitemaps. Because of Google's support for the Sitemap
>format, it is inevitable that aggregation services are going to have to
>start reading Sitemaps in addition to the billions of flavors of legacy RSS
>and Atom files. Nonetheless, given the importance of any format that Google
>  
>
Unless aggregation services simply choose to ignore the new spec in 
favor of RSS & Atom.  I agree that there appears to be no justification 
for the new format based solely on a read of the spec.  Why else would 
they ALSO support Atom 0.3 and RSS?  If Atom 0.3 and RSS can be used 
adequately, why push yet another XML syntax that duplicates the basic 
form and function? 

>supports, should we be considering providing support in Atom for the
>priority element or some easily mapped equivelant? Also, I wonder what it
>will take to get Google so say that they'll support Atom 1.0? It seems
>obvious that they would, but it would be nice to know when they expect to do
>it...
>	The Sitemap Index files are proper and useful additions to what we
>have now in the blogosphere and we should look carefully at either trying to
>figure out how to incorporate this idea into what we do for Atom. Perhaps
>something along the lines of Sitemap indexes could be incorporated into the
>autodiscovery specification?
>  
>

The sitemap indexes look very similar to Atom protocol collection 
documents with the exception of the changefreq and priority elements.  I 
see absolutely no reason why the following wouldn't work... (other than 
the fact that the Atom spec isn't finished yet.....)

<?xml version="1.0" encoding='utf-8'?>
<collection xmlns="http://purl.org/atom/app#"
   next="http://localhost:8080/roller/atom/myblog/entry/77088a1" >
   <member title="The Connells: Fun and Games"
         href="http://localhost:8080/roller/atom/myblog/entry/7700a0" 
         updated="2005-04-16T23:07:08-0400" 
         gsm:changefreq="daily"
         gsm:priority="0.8"/>
   <member title="The Connells: Boylan Heights"
         href="http://localhost:8080/roller/atom/myblog/entry/7700c9" 
         updated="2005-04-15T23:06:09-0400" 
         gsm:changefreq="weekly"
         gsm:priority="0.1"/>
   <member title="The Connells: Gladiator"
         href="http://localhost:8080/roller/atom/myblog/entry/7700c8" 
         updated="2005-04-14T14:05:31-0400" 
         gsm:changefreq="weekly"
         gsm:priority="0.2"/>
</collection>


>	bob wyman
>
>
>  
>



From owner-atom-syntax@mail.imc.org  Fri Jun  3 19:31:35 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24713
	for <atompub-archive@lists.ietf.org>; Fri, 3 Jun 2005 19:31:34 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j53NQYHu015978;
	Fri, 3 Jun 2005 16:26:34 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j53NQYZ2015977;
	Fri, 3 Jun 2005 16:26:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mx1.verity.com (mx1.verity.com [192.187.147.8])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j53NQXXs015969
	for <atom-syntax@imc.org>; Fri, 3 Jun 2005 16:26:33 -0700 (PDT)
	(envelope-from wunder@verity.com)
Received: from soda.verity.com (soda [10.3.100.96])
	by postal.verity.com (Postfix) with ESMTP id 7C34ADA
	for <atom-syntax@imc.org>; Fri,  3 Jun 2005 16:26:28 -0700 (PDT)
Received: from localhost (spike.verity.com [10.69.100.102])
	by soda.verity.com (8.12.6/8.12.6) with ESMTP id j53NQIng022664
	for <atom-syntax@imc.org>; Fri, 3 Jun 2005 16:26:27 -0700 (PDT)
Date: Fri, 03 Jun 2005 16:26:18 -0700
From: Walter Underwood <wunder@verity.com>
To: atom-syntax@imc.org
Subject: RE: Google Sitemaps: Yet another "RSS" or site-metadata format and Atom "competitor"
Message-ID: <052C2520E2B7374B886228CE@Wunders-Computer.local>
In-Reply-To: <200506032248.DID79351@ms8.netsolmail.com>
References:  <200506032248.DID79351@ms8.netsolmail.com>
X-Mailer: Mulberry/4.0.0 (Mac OS X)
X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i
        (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk
        5E^BlXwR+8}qOwy
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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: 7bit


--On June 3, 2005 6:48:31 PM -0400 Bob Wyman <bob@wyman.us> wrote:
>   I do still think it unfortunate that Google felt compelled to invent
> yet-another-format for Sitemaps.

Yep. The could have used good ol' Infoseek sitelist.txt. Here is a copy
from eight years ago:

<http://web.archive.org/web/19970529104229/http://software.infoseek.com/products/ultraseek/docs/sitelist.html>

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Fri Jun  3 20:11:42 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27160
	for <atompub-archive@lists.ietf.org>; Fri, 3 Jun 2005 20:11:42 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5403Qax018182;
	Fri, 3 Jun 2005 17:03:26 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5403QDc018181;
	Fri, 3 Jun 2005 17:03:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5403NNF018174
	for <atom-syntax@imc.org>; Fri, 3 Jun 2005 17:03:25 -0700 (PDT)
	(envelope-from dtcd@mac.com)
Received: from [161.73.58.69] (data-csmail2 [192.168.2.2])
	by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j5402SW1001421;
	Sat, 4 Jun 2005 01:02:37 +0100 (BST)
In-Reply-To: <200506032128.DID59534@ms8.netsolmail.com>
References: <200506032128.DID59534@ms8.netsolmail.com>
Mime-Version: 1.0 (Apple Message framework v730)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <5A40484E-CC27-4693-9298-A81508F05DB5@mac.com>
Cc: atom-syntax <atom-syntax@imc.org>
Content-Transfer-Encoding: 7bit
From: Graham <dtcd@mac.com>
Subject: Re: Google Sitemaps: Yet another "RSS" or site-metadata format and Atom "competitor"
Date: Sat, 4 Jun 2005 01:02:29 +0100
To: bob@wyman.us
X-Mailer: Apple Mail (2.730)
X-MailScanner-Information: Oxford Brookes University MailScanner
X-MailScanner: Clean
X-MailScanner-From: dtcd@mac.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>
Content-Transfer-Encoding: 7bit


I don't see how a highly specialized format for a particular task is  
a competitor to or even compatible with what Atom does. There's  
nothing in our charter that says we've failed if it isn't possible to  
do everything conceivably related to website updates with Atom. And I  
don't see how Atom would benefit from becoming a jack of all trades.

Graham



From owner-atom-syntax@mail.imc.org  Sat Jun  4 00:52:53 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12443
	for <atompub-archive@lists.ietf.org>; Sat, 4 Jun 2005 00:52:52 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j544jIJu034192;
	Fri, 3 Jun 2005 21:45:18 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j544jIfL034191;
	Fri, 3 Jun 2005 21:45:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from ironclad.net.au ([203.30.247.11])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j544jF9b034178
	for <atom-syntax@imc.org>; Fri, 3 Jun 2005 21:45:17 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] ([203.30.247.18] verified) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.0000470343 for <atom-syntax@imc.org>; Sat, 04 Jun 2005 14:45:11 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sat, 04 Jun 2005 14:45:10 +1000
Subject: Re: Google Sitemaps: Yet another "RSS" or site-metadata format
	and Atom "competitor"
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BEC76EF6.5D625%eric.scheid@ironclad.net.au>
In-Reply-To: <052C2520E2B7374B886228CE@Wunders-Computer.local>
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>
Content-Transfer-Encoding: 7bit


On 4/6/05 9:26 AM, "Walter Underwood" <wunder@verity.com> wrote:

> Yep. The could have used good ol' Infoseek sitelist.txt.

doesn't have revisit interval, doesn't have page-in-site priority, both
which seem important to google for scheduling purposes.

e.



From owner-atom-syntax@mail.imc.org  Sat Jun  4 01:10:33 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13367
	for <atompub-archive@lists.ietf.org>; Sat, 4 Jun 2005 01:10:32 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5453d90036125;
	Fri, 3 Jun 2005 22:03:39 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5453dQP036124;
	Fri, 3 Jun 2005 22:03:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from ironclad.net.au ([203.30.247.11])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j5453aBK036097
	for <atom-syntax@imc.org>; Fri, 3 Jun 2005 22:03:38 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] ([203.30.247.18] verified) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.0000470408 for <atom-syntax@imc.org>; Sat, 04 Jun 2005 15:03:34 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sat, 04 Jun 2005 15:03:32 +1000
Subject: Re: Google Sitemaps: Yet another "RSS" or site-metadata format
	and Atom "competitor"
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BEC77344.5D625%eric.scheid@ironclad.net.au>
In-Reply-To: <5A40484E-CC27-4693-9298-A81508F05DB5@mac.com>
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>
Content-Transfer-Encoding: 7bit


On 4/6/05 10:02 AM, "Graham" <dtcd@mac.com> wrote:

> I don't see how a highly specialized format for a particular task is
> a competitor to or even compatible with what Atom does. There's
> nothing in our charter that says we've failed if it isn't possible to
> do everything conceivably related to website updates with Atom. And I
> don't see how Atom would benefit from becoming a jack of all trades.

Agree. Googles' sitemap format, Infoseek's sitelist.txt, and other similar
things only serve to provide a list of links to updated pages. They don't
serve to carry content or author metadata or such forth.

They are just a glorified "submit your url to be indexed" functionality for
search engines. Only you don't have to submit one URL at a time.

e.



From owner-atom-syntax@mail.imc.org  Sat Jun  4 01:57:31 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15834
	for <atompub-archive@lists.ietf.org>; Sat, 4 Jun 2005 01:57:31 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j545qkF6059432;
	Fri, 3 Jun 2005 22:52:46 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j545qka2059431;
	Fri, 3 Jun 2005 22:52:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from omr5.netsolmail.com (omr5.netsolmail.com [216.168.230.142])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j545qksG059420
	for <atom-syntax@imc.org>; Fri, 3 Jun 2005 22:52:46 -0700 (PDT)
	(envelope-from bob@wyman.us)
Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180])
	by omr5.netsolmail.com (8.12.10/8.12.10) with ESMTP id j545qeqt020889;
	Sat, 4 Jun 2005 01:52:45 -0400 (EDT)
Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137])
	by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA)
	with ESMTP id DIE85231;
	Sat, 4 Jun 2005 01:52:39 -0400 (EDT)
Message-Id: <200506040552.DIE85231@ms8.netsolmail.com>
Reply-To: <bob@wyman.us>
From: "Bob Wyman" <bob@wyman.us>
To: "'Graham'" <dtcd@mac.com>, <bob@wyman.us>
Cc: "'atom-syntax'" <atom-syntax@imc.org>
Subject: RE: Google Sitemaps: Yet another "RSS" or site-metadata format and Atom "competitor"
Date: Sat, 4 Jun 2005 01:52:38 -0400
Organization: PubSub Concepts, Inc.
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <5A40484E-CC27-4693-9298-A81508F05DB5@mac.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcVomNp+lcwhUkZeTAOdW7Oo5u36BAALuoSA
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: 7bit


Graham wrote:
> I don't see how a highly specialized format for a particular task is
> a competitor to or even compatible with what Atom does.
	The "highly specialized task" which is performed using the Sitemap
format is providing lists of changed web pages on sites. This is precisely
the function that is performed in many applications of Atom. The only
difference between the target of Sitemap and Atom is that Sitemap works with
web sites that are not blogs and Atom is usually used with web sites that
are blogs. However, the differences between these two kinds of site are
virtually non-existent. 
	Atom doesn't need to be a "jack of all trades" to handle the job
that Sitemaps handle. It is already quite capable of doing the job.  And, as
James Snell points out in an earlier message, collection documents would
handle well the job of providing Sitemap indexes. 
	It seems quite clear that the Sitemap and Sitemap index formats have
little to offer that isn't already provided by Atom. This obviously leads to
the question of why Google went to the trouble of defining these formats. It
would be real nice if someone from Google could provide a touch of
explanation...

	bob wyman




From owner-atom-syntax@mail.imc.org  Sat Jun  4 03:17:07 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11473
	for <atompub-archive@lists.ietf.org>; Sat, 4 Jun 2005 03:17:06 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5473PxY086278;
	Sat, 4 Jun 2005 00:03:25 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5473Pms086277;
	Sat, 4 Jun 2005 00:03:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5473N1D086233
	for <atom-syntax@imc.org>; Sat, 4 Jun 2005 00:03:24 -0700 (PDT)
	(envelope-from sayrer@gmail.com)
Received: by wproxy.gmail.com with SMTP id 70so2332906wra
        for <atom-syntax@imc.org>; Sat, 04 Jun 2005 00:03:18 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=aA6sO0FsC3+S/G9PZ9xdLYAx0c/Rx3V3l6Xe/b3r0dJsyQqlvzi+gIkVN69GPqwv+6QqF001+5iJRWvML9rO2dGMM4ukNygco6GpYXC72rTq2nvNhtW0h6EbxFIE2TN+Rb85OGHlDCyviRlBI7ahUsTXJiwEeC5oKQxHf2eyZw0=
Received: by 10.54.15.75 with SMTP id 75mr601271wro;
        Sat, 04 Jun 2005 00:03:18 -0700 (PDT)
Received: by 10.54.71.13 with HTTP; Sat, 4 Jun 2005 00:03:18 -0700 (PDT)
Message-ID: <68fba5c50506040003165e7e96@mail.gmail.com>
Date: Sat, 4 Jun 2005 03:03:18 -0400
From: Robert Sayre <sayrer@gmail.com>
Reply-To: Robert Sayre <sayrer@gmail.com>
To: bob@wyman.us
Subject: Re: Google Sitemaps: Yet another "RSS" or site-metadata format and Atom "competitor"
Cc: Graham <dtcd@mac.com>, atom-syntax <atom-syntax@imc.org>
In-Reply-To: <200506040552.DIE85231@ms8.netsolmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
References: <5A40484E-CC27-4693-9298-A81508F05DB5@mac.com>
	 <200506040552.DIE85231@ms8.netsolmail.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j5473O1D086268
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: 8bit


On 6/4/05, Bob Wyman <bob@wyman.us> wrote:
> 
> Graham wrote:
> > I don't see how a highly specialized format for a particular task is
> > a competitor to or even compatible with what Atom does.
>         The "highly specialized task" which is performed using the Sitemap
> format is providing lists of changed web pages on sites. This is precisely
> the function that is performed in many applications of Atom. 

Yes, but the required fields are different. Other than than that, it's
pretty much the same dictionary or a-list situation we're used to.
Like rel=nofollow, this seems geared towards speeding up the crawl,
with a bunch of rhetoric surrounding it. Maybe I'm just cynical.

Robert Sayre



From owner-atom-syntax@mail.imc.org  Sat Jun  4 13:23:51 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18414
	for <atompub-archive@lists.ietf.org>; Sat, 4 Jun 2005 13:23:51 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j54HHduo030973;
	Sat, 4 Jun 2005 10:17:39 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j54HHdLD030972;
	Sat, 4 Jun 2005 10:17:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from omr1.netsolmail.com (omr1.netsolmail.com [216.168.230.162])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j54HHdQ5030965
	for <atom-syntax@imc.org>; Sat, 4 Jun 2005 10:17:39 -0700 (PDT)
	(envelope-from bob@wyman.us)
Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180])
	by omr1.netsolmail.com (8.12.10/8.12.10) with ESMTP id j54HHWTj024603;
	Sat, 4 Jun 2005 13:17:37 -0400 (EDT)
Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137])
	by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA)
	with ESMTP id DIG99851;
	Sat, 4 Jun 2005 13:17:31 -0400 (EDT)
Message-Id: <200506041717.DIG99851@ms8.netsolmail.com>
Reply-To: <bob@wyman.us>
From: "Bob Wyman" <bob@wyman.us>
To: "'Robert Sayre'" <sayrer@gmail.com>
Cc: "'Graham'" <dtcd@mac.com>, "'atom-syntax'" <atom-syntax@imc.org>
Subject: RE: Google Sitemaps: Yet another "RSS" or site-metadata format and Atom "competitor"
Date: Sat, 4 Jun 2005 13:17:31 -0400
Organization: PubSub Concepts, Inc.
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <68fba5c50506040003165e7e96@mail.gmail.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcVo08CuijpHU1JiR+GZJ0vio+TNHgAU772Q
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: 7bit


Robert Sayre wrote:
> it's pretty much the same dictionary or a-list situation we're
> used to. Like rel=nofollow, this seems geared towards speeding up
> the crawl, with a bunch of rhetoric surrounding it. Maybe I'm just
> cynical.
	Why would you have to be cynical to suggest that support for
Sitemaps would speed up the crawl for Google? Wouldn't that be a good thing
for everyone involved? 
	* Google benefits by being able to do things more efficiently. 
	* Google users get timelier and more complete results. 
	* Publishers get their data "visible" more quickly than before.
	This seems like a win-win for everyone! There's no need for cynicism
to see the benefits. Heck, these are all the same benefits that have
motivated at least some of us to invest heavily in Atom and other
syndication formats.
	I think it would be really wonderful if we were to find that
non-blog web sites start producing this data. My only regret is that Google
has confused matters by publishing this new format to muddy the waters...
It's time that the rest of the web got the same kind of excellent service
that we've been providing to blogs.
	My hope is, however, that we'll be able to convince non-blog web
sites to use Atom instead of the Google proprietary format when publishing
this data. Using Atom would mean that a large number of existing systems
would be able to process their data rather than just Google. Also, by using
Atom, people will be able to go beyond merely listing URLs and will be able
to include summary data and other bits of metadata that other applications
can exploit. This could be a good thing for Atom -- if we can convince
people to use it instead of the Google proprietary format. If we don't
convince folk to use Atom, then we're going to find that Sitemaps provides a
"good enough" solution and it will be very hard to convince people to
convert to the more expressive Atom format in the future.

	bob wyman




From owner-atom-syntax@mail.imc.org  Sat Jun  4 13:25:36 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18474
	for <atompub-archive@lists.ietf.org>; Sat, 4 Jun 2005 13:25:35 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j54HFn57030752;
	Sat, 4 Jun 2005 10:15:49 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j54HFnEk030751;
	Sat, 4 Jun 2005 10:15:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j54HFlU2030744
	for <atom-syntax@imc.org>; Sat, 4 Jun 2005 10:15:48 -0700 (PDT)
	(envelope-from jtauber@jtauber.com)
Received: from frontend3.messagingengine.com (frontend3.internal [10.202.2.152])
	by frontend1.messagingengine.com (Postfix) with ESMTP id 887ECC991B8
	for <atom-syntax@imc.org>; Sat,  4 Jun 2005 13:15:46 -0400 (EDT)
X-Sasl-enc: +FZntp+LdtcfA5HyMvv13tazSid182Yy+53L4PD0NHEZEvMxucBf 1117905346
Received: from [64.134.59.234] (dhcp64-134-59-234.burl.bos.wayport.net [64.134.59.234])
	by frontend3.messagingengine.com (Postfix) with ESMTP id 6D60F5F
	for <atom-syntax@imc.org>; Sat,  4 Jun 2005 13:15:46 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v730)
In-Reply-To: <5A40484E-CC27-4693-9298-A81508F05DB5@mac.com>
References: <200506032128.DID59534@ms8.netsolmail.com> <5A40484E-CC27-4693-9298-A81508F05DB5@mac.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <10F1AC09-3C45-4569-ABBC-018BC390AB68@jtauber.com>
Content-Transfer-Encoding: 7bit
From: James Tauber <jtauber@jtauber.com>
Subject: Re: Google Sitemaps: Yet another "RSS" or site-metadata format and Atom "competitor"
Date: Sat, 4 Jun 2005 13:15:43 -0400
To: atom-syntax <atom-syntax@imc.org>
X-Mailer: Apple Mail (2.730)
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: 7bit



I've been serving my site (not the change log but the actual site) as  
an Atom feed for as long as my blog has had an Atom feed.

One nice (and unintentional) side effect of this is that I can  
subscribe to the site map in Bloglines and have Bloglines tell me  
when my non-blog pages are being referenced as well as my blog pages.

James

On 03/06/2005, at 8:02 PM, Graham wrote:

>
> I don't see how a highly specialized format for a particular task  
> is a competitor to or even compatible with what Atom does. There's  
> nothing in our charter that says we've failed if it isn't possible  
> to do everything conceivably related to website updates with Atom.  
> And I don't see how Atom would benefit from becoming a jack of all  
> trades.
>
> Graham
>
>



From owner-atom-syntax@mail.imc.org  Mon Jun  6 04:11:03 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08582
	for <atompub-archive@lists.ietf.org>; Mon, 6 Jun 2005 04:11:02 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j568276A024592;
	Mon, 6 Jun 2005 01:02:07 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j56827JL024591;
	Mon, 6 Jun 2005 01:02:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from bblfish.net (bblfish.net [192.220.66.168])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j56826aM024581
	for <atom-syntax@imc.org>; Mon, 6 Jun 2005 01:02:06 -0700 (PDT)
	(envelope-from henry.story@bblfish.net)
Received: (qmail 15575 invoked by uid 17064); 6 Jun 2005 08:02:06 -0000
Received: from unknown (HELO [192.168.0.10]) ([83.112.4.27])
          (envelope-sender <henry.story@bblfish.net>)
          by 192.220.66.168 (qmail-ldap-1.03) with SMTP
          for <atom-syntax@imc.org>; 6 Jun 2005 08:02:06 -0000
In-Reply-To: <200506032128.DID59534@ms8.netsolmail.com>
References: <200506032128.DID59534@ms8.netsolmail.com>
Mime-Version: 1.0 (Apple Message framework v730)
Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed
Message-Id: <5B015019-03B9-4192-AA4A-E8B6BA260896@bblfish.net>
Cc: <atom-syntax@imc.org>
From: Henry Story <henry.story@bblfish.net>
Subject: Re: Google Sitemaps: Yet another "RSS" or site-metadata format and Atom "competitor"
Date: Mon, 6 Jun 2005 10:02:03 +0200
To: <bob@wyman.us>
X-Mailer: Apple Mail (2.730)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j56827aM024584
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: 8bit


I completely agree. At the core, a feed is just a list of state  
changes to web resources.
It will be  the perfect format for notifying search engines of all  
the changes to a web
site,  thereby massively reducing the time it will take them to crawl  
the web.


Henry Story

On 3 Jun 2005, at 23:28, Bob Wyman wrote:
> Google has released “Sitemaps” which is yet-another-format for  
> doing “site summary” or site-metadata publication. Unlike commonly  
> used RSS formats or Atom, Sitemaps are only intended to communicate  
> information about URLs that have been updated – not the content of  
> those URLs.




From owner-atom-syntax@mail.imc.org  Mon Jun  6 09:25:50 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29823
	for <atompub-archive@lists.ietf.org>; Mon, 6 Jun 2005 09:25:49 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j56DD2OA032706;
	Mon, 6 Jun 2005 06:13:02 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j56DD2c8032705;
	Mon, 6 Jun 2005 06:13:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from bblfish.net (bblfish.net [192.220.66.168])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j56DCs4D032689
	for <atom-syntax@imc.org>; Mon, 6 Jun 2005 06:13:02 -0700 (PDT)
	(envelope-from henry.story@bblfish.net)
Received: (qmail 68818 invoked by uid 17064); 6 Jun 2005 13:12:52 -0000
Received: from unknown (HELO [192.168.0.10]) ([83.112.237.77])
          (envelope-sender <henry.story@bblfish.net>)
          by 192.220.66.168 (qmail-ldap-1.03) with SMTP
          for <atom-syntax@imc.org>; 6 Jun 2005 13:12:52 -0000
Mime-Version: 1.0 (Apple Message framework v730)
Content-Transfer-Encoding: 7bit
Message-Id: <872385FC-3370-4DDD-AD3D-8EF3EF2548C0@bblfish.net>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: atom-syntax Syntax <atom-syntax@imc.org>
From: Henry Story <henry.story@bblfish.net>
Subject: feeds, ids and categories
Date: Mon, 6 Jun 2005 15:12:50 +0200
X-Mailer: Apple Mail (2.730)
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: 7bit


I was wondering if I had understood this correctly: a feed can have  
entries in a number of categories. Each of these categories may  
themselves have feeds. These category feeds will all have the same id  
as the main feed, though they may have different titles and subtitles  
to reflect the category in which they found themselves.

Henry



From owner-atom-syntax@mail.imc.org  Mon Jun  6 10:38:18 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06655
	for <atompub-archive@lists.ietf.org>; Mon, 6 Jun 2005 10:38:18 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j56EUoTp038105;
	Mon, 6 Jun 2005 07:30:50 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j56EUob6038104;
	Mon, 6 Jun 2005 07:30:50 -0700 (PDT)
X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j56EUnll038097
	for <atom-syntax@imc.org>; Mon, 6 Jun 2005 07:30:50 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j56EUin0029691
	for <atom-syntax@imc.org>; Mon, 6 Jun 2005 08:30:49 -0600 (MDT)
Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004))
 with ESMTP id <0IHO000X52Z79F@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Mon, 06 Jun 2005 08:30:44 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.202.7])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004))
 with ESMTPSA id <0IHO00HMK2Z7JS@mail.sun.net> for atom-syntax@imc.org; Mon,
 06 Jun 2005 08:30:43 -0600 (MDT)
Date: Mon, 06 Jun 2005 07:30:45 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: feeds, ids and categories
In-reply-to: <872385FC-3370-4DDD-AD3D-8EF3EF2548C0@bblfish.net>
To: Henry Story <henry.story@bblfish.net>
Cc: atom-syntax Syntax <atom-syntax@imc.org>
Message-id: <9331B85F-BDED-417D-AF15-1F6BEB4232DD@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.730)
Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Content-transfer-encoding: 7BIT
References: <872385FC-3370-4DDD-AD3D-8EF3EF2548C0@bblfish.net>
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: 7BIT



On Jun 6, 2005, at 6:12 AM, Henry Story wrote:

>
> I was wondering if I had understood this correctly: a feed can have  
> entries in a number of categories. Each of these categories may  
> themselves have feeds. These category feeds will all have the same  
> id as the main feed,

No!  A feed ID is a *unique* identifier.  My 'golfing' feed is  
entirely distinct from my 'chemistry' feed, although they may share  
some entries. -Tim



From owner-atom-syntax@mail.imc.org  Mon Jun  6 10:55:42 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07740
	for <atompub-archive@lists.ietf.org>; Mon, 6 Jun 2005 10:55:41 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j56ElGpR039177;
	Mon, 6 Jun 2005 07:47:16 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j56ElGcV039176;
	Mon, 6 Jun 2005 07:47:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from ironclad.net.au ([203.30.247.11])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j56ElE2O039169
	for <atom-syntax@imc.org>; Mon, 6 Jun 2005 07:47:15 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] ([203.30.247.18] verified) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.0000480402 for <atom-syntax@imc.org>; Tue, 07 Jun 2005 00:47:15 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Tue, 07 Jun 2005 00:47:10 +1000
Subject: Re: feeds, ids and categories
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BECA9F0E.5DB84%eric.scheid@ironclad.net.au>
In-Reply-To: <872385FC-3370-4DDD-AD3D-8EF3EF2548C0@bblfish.net>
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>
Content-Transfer-Encoding: 7bit


On 6/6/05 11:12 PM, "Henry Story" <henry.story@bblfish.net> wrote:

> These category feeds will all have the same id
> as the main feed

maybe not.

would every feed at nature.com have the same id?

e.



From owner-atom-syntax@mail.imc.org  Mon Jun  6 16:15:42 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14239
	for <atompub-archive@lists.ietf.org>; Mon, 6 Jun 2005 16:15:42 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j56ErC7m039476;
	Mon, 6 Jun 2005 07:53:12 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j56ErCb7039475;
	Mon, 6 Jun 2005 07:53:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from bblfish.net (bblfish.net [192.220.66.168])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j56ErCai039469
	for <atom-syntax@imc.org>; Mon, 6 Jun 2005 07:53:12 -0700 (PDT)
	(envelope-from henry.story@bblfish.net)
Received: (qmail 9424 invoked by uid 17064); 6 Jun 2005 14:53:12 -0000
Received: from unknown (HELO [192.168.0.10]) ([83.112.237.77])
          (envelope-sender <henry.story@bblfish.net>)
          by 192.220.66.168 (qmail-ldap-1.03) with SMTP
          for <atom-syntax@imc.org>; 6 Jun 2005 14:53:12 -0000
In-Reply-To: <9331B85F-BDED-417D-AF15-1F6BEB4232DD@sun.com>
References: <872385FC-3370-4DDD-AD3D-8EF3EF2548C0@bblfish.net> <9331B85F-BDED-417D-AF15-1F6BEB4232DD@sun.com>
Mime-Version: 1.0 (Apple Message framework v730)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <ED85CDC6-63BD-4771-BE2A-80F3FE1B11CF@bblfish.net>
Cc: atom-syntax Syntax <atom-syntax@imc.org>
Content-Transfer-Encoding: 7bit
From: Henry Story <henry.story@bblfish.net>
Subject: Re: feeds, ids and categories
Date: Mon, 6 Jun 2005 16:53:10 +0200
To: Tim Bray <Tim.Bray@Sun.COM>
X-Mailer: Apple Mail (2.730)
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: 7bit



On 6 Jun 2005, at 16:30, Tim Bray wrote:
> On Jun 6, 2005, at 6:12 AM, Henry Story wrote:
>> I was wondering if I had understood this correctly: a feed can  
>> have entries in a number of categories. Each of these categories  
>> may themselves have feeds. These category feeds will all have the  
>> same id as the main feed,
>>
>
> No!  A feed ID is a *unique* identifier.  My 'golfing' feed is  
> entirely distinct from my 'chemistry' feed, although they may share  
> some entries. -Tim

Phew! Great. Thanks. That is what I was hoping.

Because I was going to say that if two category feeds could share the  
same
id and have different titles, then this id would  (to stick to our
resource/representation distinction introduced in the entry id  
discussion of
Atom entries) simultaneously have two different representations of  
the same type,
and so would have a very different behavior to the ids we have  
associated with
entries.


Henry Story



From owner-atom-syntax@mail.imc.org  Tue Jun  7 06:25:35 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07884
	for <atompub-archive@lists.ietf.org>; Tue, 7 Jun 2005 06:25:34 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j57AHIrR030720;
	Tue, 7 Jun 2005 03:17:18 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j57AHIo2030718;
	Tue, 7 Jun 2005 03:17:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j57AHHVl030676
	for <atom-syntax@imc.org>; Tue, 7 Jun 2005 03:17:17 -0700 (PDT)
	(envelope-from gstein@google.com)
Received: by 216-239-45-4.google.com with SMTP id 7so4434zzb
        for <atom-syntax@imc.org>; Tue, 07 Jun 2005 03:17:11 -0700 (PDT)
Received: by 172.25.12.175 with SMTP id 15mr206zzc;
        Tue, 07 Jun 2005 03:17:05 -0700 (PDT)
Received: by 172.25.12.180 with HTTP; Tue, 7 Jun 2005 03:17:04 -0700 (PDT)
Message-ID: <9c791d0a050607031726930e84@mail.google.com>
Date: Tue, 7 Jun 2005 03:17:04 -0700
From: gstein <gstein@google.com>
Reply-To: gstein <gstein@google.com>
To: bob@wyman.us
Subject: Re: Google Sitemaps: Yet another "RSS" or site-metadata format and Atom "competitor"
Cc: atom-syntax <atom-syntax@imc.org>
In-Reply-To: <200506041717.DIG99851@ms8.netsolmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
References: <68fba5c50506040003165e7e96@mail.gmail.com>
	 <200506041717.DIG99851@ms8.netsolmail.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j57AHHVl030711
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: 8bit


On 6/4/05, Bob Wyman <bob@wyman.us> wrote:
>...
>        I think it would be really wonderful if we were to find that
> non-blog web sites start producing this data. My only regret is that Google
> has confused matters by publishing this new format to muddy the waters...

It was not published "to muddy the waters". That implies a specific
intent which was *definitely* not present.

>...
> can exploit. This could be a good thing for Atom -- if we can convince
> people to use it instead of the Google proprietary format. If we don't

"proprietary" connotes closed. We published the spec and encourage
other search engines to use it. There is no intent to close or control
it.

How about this: you have a web site with 10 *million* URLs on it. What
format are you going to use? Is Atom appropriate at that scale?

[note: I'm not saying one is or isn't... to be honest, I'm not all
that familiar with the sitemaps schema and its features; but I do know
it was designed to scale, whereas I don't think Atom was]

Cheers,
-g



From owner-atom-syntax@mail.imc.org  Tue Jun  7 09:32:27 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22773
	for <atompub-archive@lists.ietf.org>; Tue, 7 Jun 2005 09:32:26 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j57DIZ1c095477;
	Tue, 7 Jun 2005 06:18:35 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j57DIZWr095476;
	Tue, 7 Jun 2005 06:18:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from ns2.safetynetaccess.com (ns2.safetynetaccess.com [64.61.99.3])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j57DIWXQ095462
	for <atom-syntax@imc.org>; Tue, 7 Jun 2005 06:18:34 -0700 (PDT)
	(envelope-from bob@wyman.us)
Received: from boblaptop ([207.42.220.132])
	(authenticated bits=0)
	by ns2.safetynetaccess.com (8.13.1/8.13.1) with ESMTP id j57DIDVT058366;
	Tue, 7 Jun 2005 09:18:19 -0400 (EDT)
Message-Id: <200506071318.j57DIDVT058366@ns2.safetynetaccess.com>
Reply-To: <bob@wyman.us>
From: "Bob Wyman" <bob@wyman.us>
To: "'gstein'" <gstein@google.com>, <bob@wyman.us>
Cc: "'atom-syntax'" <atom-syntax@imc.org>
Subject: RE: Google Sitemaps: Yet another "RSS" or site-metadata format and Atom "competitor"
Date: Tue, 7 Jun 2005 09:18:11 -0400
Organization: PubSub Concepts, Inc.
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Thread-Index: AcVrSjMoxLcAuKCtSjWvRRZeorW63gAF6Rlw
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <9c791d0a050607031726930e84@mail.google.com>
X-Spam-Status: No, hits=0.0 required=5.7 tests= version=2.20
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: 7bit


Greg Stein wrote:
> It was not published "to muddy the waters". That implies a specific
> intent which was *definitely* not present.
	Please accept my apologies for what was poor writing. I can see how
you read my sentence as implying intent to muddy. It wasn't my intent,
however, to imply that. I should have written. "publishing this new format
*and* muddying the waters." My intent was to say that publishing the format
has the effect of muddying the waters. I wasn't trying to say that Google
was intentionally doing this.

> "proprietary" connotes closed.
	I'm using the older definition of proprietary which means simply
"not standard." I see nothing wrong with saying "open and proprietary"
format... I don't think one implies the exclusion of the other.

> How about this: you have a web site with 10 *million* URLs on it. 
> What format are you going to use? Is Atom appropriate at that scale?
	No. I don't think Atom would work well with 10 million URLs. At
least not as currently defined. I do think, however, that it would have been
useful to try to at least have a conversation about defining some subset of
Atom that would address the need. I think a result could have ended up
looking much like the Sitemap format but offered a smoother migration path
from Atom as we know it to the more terse format and the reverse.

	Please understand that I think that on-the-whole, the efforts by
Google to popularize the Sitemap process and "syndication" by non-blogs is
absolutely wonderful! I'm only grumbling about the formats... 

	bob wyman



From owner-atom-syntax@mail.imc.org  Tue Jun  7 11:09:01 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01288
	for <atompub-archive@lists.ietf.org>; Tue, 7 Jun 2005 11:09:01 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j57EwVML001666;
	Tue, 7 Jun 2005 07:58:31 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j57EwVxf001665;
	Tue, 7 Jun 2005 07:58:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mx1.verity.com (mx1.verity.com [192.187.147.8])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j57EwV88001649
	for <atom-syntax@imc.org>; Tue, 7 Jun 2005 07:58:31 -0700 (PDT)
	(envelope-from wunder@verity.com)
Received: from soda.verity.com (soda [10.3.100.96])
	by postal.verity.com (Postfix) with ESMTP id E6EFC8D
	for <atom-syntax@imc.org>; Tue,  7 Jun 2005 07:58:22 -0700 (PDT)
Received: from localhost (spike.verity.com [10.69.100.102])
	by soda.verity.com (8.12.6/8.12.6) with ESMTP id j57EwLng015421
	for <atom-syntax@imc.org>; Tue, 7 Jun 2005 07:58:22 -0700 (PDT)
Date: Tue, 07 Jun 2005 07:58:21 -0700
From: Walter Underwood <wunder@verity.com>
To: atom-syntax <atom-syntax@imc.org>
Subject: Re: Google Sitemaps: Yet another "RSS" or site-metadata format and Atom "competitor"
Message-ID: <0F854671A165863C9EA1D65D@adsl-64-166-133-243.dsl.snfc21.pacbell.net>
In-Reply-To: <9c791d0a050607031726930e84@mail.google.com>
References: <68fba5c50506040003165e7e96@mail.gmail.com>	 <200506041717.DIG99851@ms8.netsolmail.com> <9c791d0a050607031726930e84@mail.google.com>
X-Mailer: Mulberry/4.0.0 (Mac OS X)
X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i
        (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk
        5E^BlXwR+8}qOwy
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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: 7bit


--On June 7, 2005 3:17:04 AM -0700 gstein <gstein@google.com> wrote:
>
> "proprietary" connotes closed. We published the spec and encourage
> other search engines to use it. There is no intent to close or control it.

"Proprietary" means "owned". Google clearly owns "Google Sitemaps".
The license requires derivative works to keep the same license. That is
control.

It was designed in isolation, for Google's use. That is a closed spec.

For example, the priority element is not specified well enough for another
engine to implement it compatibly. Does it apply to ranking, crawl order
or duplicate preference?

An open process would have at least looked at the proposed extensions 
for robots.txt and earlier formats like Infoseek sitelist.txt.

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Wed Jun  8 16:09:28 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05584
	for <atompub-archive@lists.ietf.org>; Wed, 8 Jun 2005 16:09:28 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j58JxlO0097734;
	Wed, 8 Jun 2005 12:59:47 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j58Jxlfi097733;
	Wed, 8 Jun 2005 12:59:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j58Jxk5o097727
	for <atom-syntax@imc.org>; Wed, 8 Jun 2005 12:59:46 -0700 (PDT)
	(envelope-from dinaras@cnri.reston.va.us)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02720;
	Wed, 8 Jun 2005 15:59:43 -0400 (EDT)
Message-Id: <200506081959.PAA02720@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: i-d-announce@ietf.org
Cc: atom-syntax@imc.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-atompub-format-09.txt
Date: Wed, 08 Jun 2005 15:59:43 -0400
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>


--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Atom Publishing Format and Protocol Working Group of the IETF.

	Title		: The Atom Syndication Format
	Author(s)	: R. Sayre, M. Nottingham
	Filename	: draft-ietf-atompub-format-09.txt
	Pages		: 53
	Date		: 2005-6-8
	
This document specifies Atom, an XML-based Web content and metadata
   syndication format.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-09.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-ietf-atompub-format-09.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-ietf-atompub-format-09.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2005-6-8163702.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-atompub-format-09.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-atompub-format-09.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2005-6-8163702.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-atom-syntax@mail.imc.org  Wed Jun  8 16:32:15 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15221
	for <atompub-archive@lists.ietf.org>; Wed, 8 Jun 2005 16:32:14 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j58KQbEA099564;
	Wed, 8 Jun 2005 13:26:37 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j58KQbwi099563;
	Wed, 8 Jun 2005 13:26:37 -0700 (PDT)
X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j58KQaWI099557
	for <atom-syntax@imc.org>; Wed, 8 Jun 2005 13:26:36 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j58KQaau029582
	for <atom-syntax@imc.org>; Wed, 8 Jun 2005 14:26:36 -0600 (MDT)
Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004))
 with ESMTP id <0IHS00EFT8SBEH@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Wed, 08 Jun 2005 14:26:36 -0600 (MDT)
Received: from [10.224.10.240] ([208.54.15.1])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004))
 with ESMTPSA id <0IHS000QO8SBFR@mail.sun.net> for atom-syntax@imc.org; Wed,
 08 Jun 2005 14:26:35 -0600 (MDT)
Date: Wed, 08 Jun 2005 13:26:39 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: I-D ACTION:draft-ietf-atompub-format-09.txt
In-reply-to: <200506081959.PAA02720@ietf.org>
To: atom-syntax Syntax <atom-syntax@imc.org>
Message-id: <AD7818B0-3343-4DDD-8633-0DB79CD8C121@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.730)
Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Content-transfer-encoding: 7BIT
References: <200506081959.PAA02720@ietf.org>
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: 7BIT



On Jun 8, 2005, at 12:59 PM, Internet-Drafts@ietf.org wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
> This draft is a work item of the Atom Publishing Format and  
> Protocol Working Group of the IETF.

<co-chair-mode>
This is what we consider our final product, and what we'll be taking  
forward through the IETF process; stand by for further news on that.

Perhaps more important, this means that it's time to focus 100% of  
our time on the protocol work. -Tim
</co-chair-mode>



From owner-atom-syntax@mail.imc.org  Wed Jun  8 17:09:34 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17985
	for <atompub-archive@lists.ietf.org>; Wed, 8 Jun 2005 17:09:34 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j58KxqkN002214;
	Wed, 8 Jun 2005 13:59:52 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j58KxqTr002213;
	Wed, 8 Jun 2005 13:59:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j58KxoEN002191
	for <atom-syntax@imc.org>; Wed, 8 Jun 2005 13:59:52 -0700 (PDT)
	(envelope-from antone@geckotribe.com)
Received: from geckotribe.com (c-67-169-250-63.hsd1.ut.comcast.net[67.169.250.63])
          by comcast.net (rwcrmhc12) with SMTP
          id <2005060820594201400jk27ee>; Wed, 8 Jun 2005 20:59:42 +0000
Date: Wed, 8 Jun 2005 14:59:40 -0600
Subject: Re: I-D ACTION:draft-ietf-atompub-format-09.txt
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v553)
From: Antone Roundy <antone@geckotribe.com>
To: atom-syntax@imc.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <200506081959.PAA02720@ietf.org>
Message-Id: <3B407288-D860-11D9-B6EE-003065EA6144@geckotribe.com>
X-Mailer: Apple Mail (2.553)
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: 7bit


> 4.1.1:
>     o  atom:feed elements MUST NOT contain more than one atom:image
>       element.
Should be "atom:logo".

4.1.2 says:
>    o  atom:entry elements MUST NOT contain more than one atom:link
>       element with a rel attribute value of "alternate" that has the
>       same combination of type and hreflang attribute values.
4.1.1 says:
>    o  atom:feed elements MUST NOT contain more than one atom:link
>       element with a rel attribute value of "alternate" that has the
>       same type attribute value.
Should 4.1.1 also mention hreflang?

4.1.2 puts this in a separate bullet, but 4.1.1 does not:
>    o  atom:entry elements MAY contain additional atom:link elements
>       beyond those described above.

Nit pick: 4.1.2 says:
>    o  atom:entry elements MUST have exactly one "atom:title" element.
>
>    o  atom:entry elements MUST contain exactly one atom:updated 
> element.
Do we want to be consistent in saying "contain" i/o "have"?

> 4.1.3.2  The "src" attribute
>
>    atom:content MAY have a "src" attribute, whose value MUST be an IRI
>    reference [RFC3987].  If the "src" attribute is present, 
> atom:content
>    MUST be empty.  Atom Processors MAY use the IRI to retrieve the
>    content, and MAY NOT process or present remote content in the same
>    manner as local content.
It took me a second to realize that MAY NOT means "don't have to" 
rather than "aren't allowed to".  The technical meaning of the terms is 
perfectly clear, but it's quite different from the usual meaning of 
those words, and may be misunderstood.  It might be better to say "Atom 
Processors MAY use the IRI to retrieve the content, and MAY process or 
present remote content in a different manner from local content."

Appendix A.  Contributors doesn't appear to have been updated to add 
more names.



From owner-atom-syntax@mail.imc.org  Wed Jun  8 17:22:35 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18964
	for <atompub-archive@lists.ietf.org>; Wed, 8 Jun 2005 17:22:35 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j58LI56B004218;
	Wed, 8 Jun 2005 14:18:05 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j58LI5GS004217;
	Wed, 8 Jun 2005 14:18:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from atlas.jabber.org (postfix@atlas.jabber.org [208.245.212.69])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j58LI5eT004211
	for <atom-syntax@imc.org>; Wed, 8 Jun 2005 14:18:05 -0700 (PDT)
	(envelope-from stpeter@jabber.org)
Received: by atlas.jabber.org (Postfix, from userid 1005)
	id 5FD3C21A5F3; Wed,  8 Jun 2005 16:20:59 -0500 (CDT)
Date: Wed, 8 Jun 2005 16:20:59 -0500
From: Peter Saint-Andre <stpeter@jabber.org>
To: Antone Roundy <antone@geckotribe.com>
Cc: atom-syntax@imc.org
Subject: Re: I-D ACTION:draft-ietf-atompub-format-09.txt
Message-ID: <20050608212059.GE6016@jabber.org>
References: <200506081959.PAA02720@ietf.org> <3B407288-D860-11D9-B6EE-003065EA6144@geckotribe.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3B407288-D860-11D9-B6EE-003065EA6144@geckotribe.com>
User-Agent: Mutt/1.5.6+20040907i
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>


On Wed, Jun 08, 2005 at 02:59:40PM -0600, Antone Roundy wrote:

> Nit pick: 4.1.2 says:
> >   o  atom:entry elements MUST have exactly one "atom:title" element.
> >
> >   o  atom:entry elements MUST contain exactly one atom:updated 
> >element.
>
> Do we want to be consistent in saying "contain" i/o "have"?

The XML specification consistently uses "contain".

Peter



From owner-atom-syntax@mail.imc.org  Wed Jun  8 21:27:32 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12621
	for <atompub-archive@lists.ietf.org>; Wed, 8 Jun 2005 21:27:31 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j591K0io020467;
	Wed, 8 Jun 2005 18:20:00 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j591K0qL020466;
	Wed, 8 Jun 2005 18:20:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.usask.ca (mail.usask.ca [128.233.192.250])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j591K0kD020460
	for <atom-syntax@imc.org>; Wed, 8 Jun 2005 18:20:00 -0700 (PDT)
	(envelope-from ans208@mail.usask.ca)
Received: from conversion-daemon.mail.usask.ca by mail.usask.ca
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 id <0IHS00A01LQXOX@mail.usask.ca> (original mail from ans208@mail.usask.ca)
 for atom-syntax@imc.org; Wed, 08 Jun 2005 19:19:59 -0600 (CST)
Received: from [128.233.152.105] (ascl-a1-10.usask.ca [128.233.152.105])
 by mail.usask.ca
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003)) with ESMTPSA id
 <0IHS00MM7MD7TR@mail.usask.ca> for atom-syntax@imc.org; Wed,
 08 Jun 2005 19:19:59 -0600 (CST)
Date: Wed, 08 Jun 2005 19:19:56 -0600
From: Andreas Sewe <ans208@mail.usask.ca>
Subject: Question on Use Case: Choosing atom:content's type when Archiving
 Mailing Lists
To: atom-syntax@imc.org
Message-id: <42A7993C.1060001@mail.usask.ca>
Organization: Student, University of Saskatchewan
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: de-de, de-at, de-ch, de, en-gb, en-ca, en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2)
 Gecko/20040803
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: 7BIT


I have a question regarding a specific Atom use case: What is 
the preferred way to set up an Atom feed listing the contents of 
a mailing list's archive, given that composite media types (in 
particular "message/rfc822") are disallowed for atom:content's 
type attribute? This prevents me from doing something like the 
following, serving the archived mails "as-is" via HTTP:

<atom:content type="message/rfc822" 
src="http://www.example.org/lists/list/archive/12345"/>

But then again there might be something more fundamentally wrong 
with serving mails as "message/rfc822" via HTTP than I currently 
realize -- and I should better serve the mails as "text/plain" 
or convert them to HTML first (which is the way the atom-syntax 
archive works).

Nevertheless, any advice on this issue would be greatly appreciated.

Regards,

Andreas Sewe



From owner-atom-syntax@mail.imc.org  Thu Jun  9 10:43:24 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07852
	for <atompub-archive@lists.ietf.org>; Thu, 9 Jun 2005 10:43:23 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j59EaZjj039472;
	Thu, 9 Jun 2005 07:36:35 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j59EaZZb039471;
	Thu, 9 Jun 2005 07:36:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231])
	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j59EaWS6039464
	for <atom-syntax@imc.org>; Thu, 9 Jun 2005 07:36:34 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: <p06210223becd3ea7e001@[10.20.30.249]>
In-Reply-To: <p06210233beb287fbf3f6@[10.20.30.249]>
References: <p06210233beb287fbf3f6@[10.20.30.249]>
Date: Thu, 9 Jun 2005 07:36:31 -0700
To: Atom WG <atom-syntax@imc.org>
From: Paul Hoffman <phoffman@imc.org>
Subject: Re: Acknowledgements in the format draft
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>


This is a second call for people who would like to be listed in the 
acknowledgements. There are a number of you who contributed greatly 
to this effort who didn't respond to my first request, and it seems 
almost silly to not have those people listed.

We will add the acknowledgements list in Appendix A after the IESG 
review. Please respond to me off-list. Thanks!


At 1:23 PM -0700 5/19/05, Paul Hoffman wrote:
>Greetings again. The nearly-nearly-complete format draft has a short 
>list of contributors in Appendix A. This WG has been phenomenally 
>active, and much of that activity is reflected in the specific text 
>in the document. Wearing my co-chair hat, I can think of at least a 
>dozen more people who should be listed in Appendix A because they 
>helped shape the final output. Having said that, some people who 
>have actively contributed to the spec may not want their names 
>listed.
>
>If you would like to be listed in Appendix A because you have helped 
>create the format document, please drop me a note. It is unlikely 
>that we will get this into the next draft, but we have another shot 
>after the IESG review, and I can't imagine that the IESG will mind 
>adding more to this section.
>
>--Paul Hoffman, Director
>--Internet Mail Consortium


--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Thu Jun  9 10:44:26 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07953
	for <atompub-archive@lists.ietf.org>; Thu, 9 Jun 2005 10:44:25 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j59EdOaK039671;
	Thu, 9 Jun 2005 07:39:24 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j59EdO6L039670;
	Thu, 9 Jun 2005 07:39:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j59EdN7K039653;
	Thu, 9 Jun 2005 07:39:23 -0700 (PDT)
	(envelope-from sah@428cobrajet.net)
Received: from dul1shollenbl1 ([::ffff:216.168.239.87])
  (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5)
  by mail.verisignlabs.com with esmtp; Thu, 09 Jun 2005 10:39:20 -0400
  id 0059814A.42A85498.00004E0F
From: "Scott Hollenbeck" <sah@428cobrajet.net>
To: "'Paul Hoffman'" <phoffman@imc.org>
Cc: "Tim Bray" <tbray@textuality.com>, "Atom WG" <atom-syntax@imc.org>
Subject: RE: draft-ietf-atompub-format-09.txt is ready for IESG review
Date: Thu, 9 Jun 2005 10:39:43 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Thread-Index: AcVtAIfq7FNU8QVRQqS34DMF7YEiMgAAHQZA
In-Reply-To: <p06210222becd39aeb5e9@[10.20.30.249]>
Message-ID: <courier.42A85498.00004E0F@mail.verisignlabs.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>
Content-Transfer-Encoding: 7bit


I will schedule the document for IESG review during the 23 June telechat.
Thanks for the notes.

-Scott-

> -----Original Message-----
> From: Paul Hoffman [mailto:phoffman@imc.org] 
> Sent: Thursday, June 09, 2005 10:35 AM
> To: Hollenbeck, Scott
> Cc: Tim Bray; Atom WG
> Subject: draft-ietf-atompub-format-09.txt is ready for IESG review
> 
> Greetings again. As the shepherd for this document, I would like to 
> ask you to bring it to the IESG for final review. The WG has worked 
> hard on this document after IETF Last Call, and made many changes 
> that incorporate the WG rough consensus on issues that were brought 
> up during and after IETF Last Call.
> 
> Some members of the Working Group remain unenthusiastic about some 
> sections of the document, but we strongly believe that there is rough 
> (or better) consensus in support of the document as a whole. For some 
> of the parts with the most contention, there cannot be more than very 
> rough consensus due to basic differences in the way people would 
> design parts of the format, particularly given that we have many 
> models in existence with the different flavors of RSS. For some parts 
> of the document, there is contention about whether or not a 
> particular item should or should not be in the Atom core versus being 
> an extension. For some parts, there is contention whether there 
> should be MUST/SHOULD/MAY leeway for content creators in the presence 
> or absence of an element, or the semantic content of an element; we 
> really pushed RFC 2119 around during the past few months.
> 
> The length of the mailing list archive is anomalous in the IETF, but 
> so is the large number of regular active contributors and the breadth 
> of parts of the document to which they contributed. This huge amount 
> of input has caused the document to be more seriously reviewed, by 
> more eyes, than a typical IETF document, but it has also caused more 
> opportunity for disagreement along the way. Yet we still ended up 
> with a format that meets the goals of the charter and the general 
> agreement of most of the participants in the Working Group.
> 
> Please let us know how if the IESG has any concerns with the document 
> during their review.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
> 
> 



From owner-atom-syntax@mail.imc.org  Thu Jun  9 10:44:39 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07985
	for <atompub-archive@lists.ietf.org>; Thu, 9 Jun 2005 10:44:39 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j59EZltk039406;
	Thu, 9 Jun 2005 07:35:47 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j59EZlLH039405;
	Thu, 9 Jun 2005 07:35:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231])
	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j59EZduA039393;
	Thu, 9 Jun 2005 07:35:40 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: <p06210222becd39aeb5e9@[10.20.30.249]>
Date: Thu, 9 Jun 2005 07:34:55 -0700
To: Scott Hollenbeck <shollenbeck@verisign.com>
From: Paul Hoffman <phoffman@imc.org>
Subject: draft-ietf-atompub-format-09.txt is ready for IESG review
Cc: Tim Bray <tbray@textuality.com>, Atom WG <atom-syntax@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>


Greetings again. As the shepherd for this document, I would like to 
ask you to bring it to the IESG for final review. The WG has worked 
hard on this document after IETF Last Call, and made many changes 
that incorporate the WG rough consensus on issues that were brought 
up during and after IETF Last Call.

Some members of the Working Group remain unenthusiastic about some 
sections of the document, but we strongly believe that there is rough 
(or better) consensus in support of the document as a whole. For some 
of the parts with the most contention, there cannot be more than very 
rough consensus due to basic differences in the way people would 
design parts of the format, particularly given that we have many 
models in existence with the different flavors of RSS. For some parts 
of the document, there is contention about whether or not a 
particular item should or should not be in the Atom core versus being 
an extension. For some parts, there is contention whether there 
should be MUST/SHOULD/MAY leeway for content creators in the presence 
or absence of an element, or the semantic content of an element; we 
really pushed RFC 2119 around during the past few months.

The length of the mailing list archive is anomalous in the IETF, but 
so is the large number of regular active contributors and the breadth 
of parts of the document to which they contributed. This huge amount 
of input has caused the document to be more seriously reviewed, by 
more eyes, than a typical IETF document, but it has also caused more 
opportunity for disagreement along the way. Yet we still ended up 
with a format that meets the goals of the charter and the general 
agreement of most of the participants in the Working Group.

Please let us know how if the IESG has any concerns with the document 
during their review.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Thu Jun  9 12:34:41 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19107
	for <atompub-archive@lists.ietf.org>; Thu, 9 Jun 2005 12:34:40 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j59GMSM7047394;
	Thu, 9 Jun 2005 09:22:28 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j59GMSIZ047393;
	Thu, 9 Jun 2005 09:22:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from earth.34sp.com (earth.34sp.com [195.50.105.51])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j59GMQrb047385
	for <atom-syntax@imc.org>; Thu, 9 Jun 2005 09:22:27 -0700 (PDT)
	(envelope-from djpowell@djpowell.net)
Received: (qmail 50704 invoked from network); 9 Jun 2005 16:22:15 -0000
Received: from localhost.34sp.com (HELO localhost) (127.0.0.1)
  by localhost.34sp.com with SMTP; 9 Jun 2005 16:22:15 -0000
Received: from host217-36-49-205.in-addr.btopenworld.com (host217-36-49-205.in-addr.btopenworld.com [217.36.49.205]) 
	by webmail.djpowell.net (IMP) with HTTP 
	for <davep@djpowell.net@localhost>; Thu,  9 Jun 2005 17:22:15 +0100
Message-ID: <1118334135.42a86cb733d81@webmail.djpowell.net>
Date: Thu,  9 Jun 2005 17:22:15 +0100
From: David Powell <djpowell@djpowell.net>
To: atom-syntax@imc.org
Subject: Review of Section 6
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.3
X-Originating-IP: 217.36.49.205
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: 8bit


Apologies for the rubbish timing, but I've been reviewing section 6, and found a
number of problems.


Firstly, there are some mismatches between the RelaxNG grammar and the
specification text.  I know that the RelaxNG grammar isn't normative; but this
doesn't mean that it can be contradictory:

a) Section 6.4 omits atom:source as a valid location for Metadata Extensions,
but it is allowed by the RelaxNG in 4.2.11.  I believe that the RelaxNG
reflects our intent to allow extensions to be preserved in atom:source.

b) Section 6.4.1 and Section 6.4.2 don't place any restrictions on what elements
may be used as Metadata Extensions, but the RelaxNG grammar explicitly excludes
elements in the Atom namespace.  The Atom namespace should be reserved for
future forwards-compatable revisions of Atom.

I actually raised these issues before the new draft was published but I didn't
receive any comments.  I am surprised that nothing has been fixed, these two
issues are simply bugs.


c) It isn't the intent of Section 6.4.1/6.4.2 that namespace declarations should
be considered among the "attributes and child elements" that determine whether
an extension is "Simple" or "Structured".  This should be made explicit, many
implementors don't have control over their placement (luckily).


I also have some problems with the structure of the whole section:

Section 6.3 describes "unknown foreign markup" as markup not defined by the
specification and describes how it should be processed; but Section 6.4
specifies the behaviour of another type of markup.  Is Section 6.4 markup
described by the specification, and therefore distinct from "unknown foreign
markup"?  If so why is it described after describing the catch-all - this
non-linearity is very confusing.  Or is it a subset?  I think that the
definition is rather ambiguous.  I find the distinction between "metadata
elements", "foreign markup", and "unknown foreign markup" to be extremely
confusing.  I wouldn't be surprised if a Venn Diagram of them was totally
different to my interpretation.

It would be better if this section was re-ordered, so that the catch-all
definition of non-Metadata Element extensions was placed after the definition
of Metadata Elements.

The two subsections of Section 6.4 are intended to describe the two subclasses
of Metadata Element.  It would make more sense if the terminology for these
subclasses was uniform.  Why not call them "Metadata Extensions", "Simple
Metadata Extensions", and "Structured Metadata Extensions"; rather than
"Metadata Elements", "Simple Extension Elements", and "Structured Extension
Elements".

I think it is insufficient to describe these subclasses purely in terms of their
syntactic characteristics, rather than in terms of their intent.  It would be
beneficial for publishers if a paragraph was introduced into Section 6.4 to
describe why a publisher/extension author would favor one of these classes. 
The intent is that a given extension would belong to a fixed class, and the
Simple class is designed to offer the advantages of easy generic processing by
simpler implementations (eg storage by servers in custom attributes), amongst
other things.


Finally, on a more fundamental level, I am worried by the class of markup that
is an extension, but isn't a "Metadata Element".  This, I think, is limited to
children of atom:link, and additional attributes on atom elements.

If this markup was reserved for future revisions of Atom, that would be fine,
but it doesn't appear to be the case - I can't really tell?

Acording to the charter Atom should have a seperate model and syntax.  Metadata
Elements were proposed to ensure that extensions could be part of the model, so
that they could be represented in RDBMS/OO/RDF/WebDAV implementations as custom
properties.

This other class of extension, if it is intended to be one, can only be
represented as part of the Atom's XML syntax.  To provide support for
extensions that use this class of markup would require changes to every stage
of the publishing and processing process.

A better alternative would be if these attribute extensions were just
treated as an alternative way of expressing Simple Metadata Extensions - at
least then some generic support for them could be implemented.  Either that or
they should be reserved for use by future Atom specifications.


There are other areas that should be clarified too.  I assume that "Atom
markup vocabulary" is intended to be current and future elements in the Atom
namespace, and un-namespaced attribtues on Atom elements, but this is just my
guess, it isn't defined in the specification.


--
Dave



From owner-atom-syntax@mail.imc.org  Thu Jun  9 12:59:29 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21707
	for <atompub-archive@lists.ietf.org>; Thu, 9 Jun 2005 12:59:28 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j59GqkUb049797;
	Thu, 9 Jun 2005 09:52:46 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j59GqkW8049796;
	Thu, 9 Jun 2005 09:52:46 -0700 (PDT)
X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j59GpqB6049754
	for <atom-syntax@imc.org>; Thu, 9 Jun 2005 09:52:13 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j59Gpq1F019437
	for <atom-syntax@imc.org>; Thu, 9 Jun 2005 10:51:52 -0600 (MDT)
Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004))
 with ESMTP id <0IHT007KHTIFPX@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Thu, 09 Jun 2005 10:51:51 -0600 (MDT)
Received: from [192.168.102.100] ([154.20.140.182])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004))
 with ESMTPSA id <0IHT007K4TIEZ4@mail.sun.net> for atom-syntax@imc.org; Thu,
 09 Jun 2005 10:51:51 -0600 (MDT)
Date: Thu, 09 Jun 2005 09:51:57 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Review of Section 6
In-reply-to: <1118334135.42a86cb733d81@webmail.djpowell.net>
To: David Powell <djpowell@djpowell.net>
Cc: atom-syntax@imc.org
Message-id: <3ACE6F0F-7D87-4603-8AD0-F2001D9CC417@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.730)
Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Content-transfer-encoding: 7BIT
References: <1118334135.42a86cb733d81@webmail.djpowell.net>
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: 7BIT


On Jun 9, 2005, at 9:22 AM, David Powell wrote:

> Apologies for the rubbish timing, but I've been reviewing section  
> 6, and found a
> number of problems.
>
> Firstly, there are some mismatches between the RelaxNG grammar and the
> specification text.  I know that the RelaxNG grammar isn't  
> normative; but this
> doesn't mean that it can be contradictory:

I've asked Paul, and in fact we can fix typos and outright bugs later  
on in the process.  If you're right about the Relax mismatch (Rob?   
Norm?) then let's fix that.

On the other hand, a general re-organization of section 6 is right  
out; it is our finding that the format-09 draft (modulo errors)  
reflects the rough consensus of the WG.  If you disagree, the IETF  
provides appeal procedures.

> a) Section 6.4 omits atom:source as a valid location for Metadata  
> Extensions,
> but it is allowed by the RelaxNG in 4.2.11.  I believe that the  
> RelaxNG
> reflects our intent to allow extensions to be preserved in  
> atom:source.

Sounds right to me.

> b) Section 6.4.1 and Section 6.4.2 don't place any restrictions on  
> what elements
> may be used as Metadata Extensions, but the RelaxNG grammar  
> explicitly excludes
> elements in the Atom namespace.  The Atom namespace should be  
> reserved for
> future forwards-compatable revisions of Atom.

I find this surprising too, will check further.  -Tim



From owner-atom-syntax@mail.imc.org  Thu Jun  9 19:42:31 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00675
	for <atompub-archive@lists.ietf.org>; Thu, 9 Jun 2005 19:42:30 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j59NVtXL087390;
	Thu, 9 Jun 2005 16:31:55 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j59NVtMg087389;
	Thu, 9 Jun 2005 16:31:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mta07-winn.ispmail.ntl.com (mta07-winn.ispmail.ntl.com [81.103.221.47])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j59NVsCV087380
	for <atom-syntax@imc.org>; Thu, 9 Jun 2005 16:31:55 -0700 (PDT)
	(envelope-from djpowell@djpowell.net)
Received: from aamta11-winn.ispmail.ntl.com ([81.103.221.35])
          by mta07-winn.ispmail.ntl.com with ESMTP
          id <20050609233144.PVHN6745.mta07-winn.ispmail.ntl.com@aamta11-winn.ispmail.ntl.com>;
          Fri, 10 Jun 2005 00:31:44 +0100
Received: from cpc1-stok1-5-0-cust163.bagu.cable.ntl.com ([81.97.134.163])
          by aamta11-winn.ispmail.ntl.com with ESMTP
          id <20050609233143.BPCR29707.aamta11-winn.ispmail.ntl.com@cpc1-stok1-5-0-cust163.bagu.cable.ntl.com>;
          Fri, 10 Jun 2005 00:31:43 +0100
Date: Fri, 10 Jun 2005 00:31:42 +0100
From: David Powell <djpowell@djpowell.net>
X-Mailer: The Bat! (v3.5.24) Professional
X-Priority: 3 (Normal)
Message-ID: <1026945406.20050610003142@djpowell.net>
To: Tim Bray <Tim.Bray@Sun.COM>
CC: atom-syntax@imc.org
Subject: Re: Review of Section 6
In-Reply-To: <3ACE6F0F-7D87-4603-8AD0-F2001D9CC417@sun.com>
References: <1118334135.42a86cb733d81@webmail.djpowell.net>
 <3ACE6F0F-7D87-4603-8AD0-F2001D9CC417@sun.com>
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>
Content-Transfer-Encoding: 7bit



Thursday, June 9, 2005, 5:51:57 PM, Tim Bray wrote:

> On Jun 9, 2005, at 9:22 AM, David Powell wrote:

>> Firstly, there are some mismatches between the RelaxNG grammar and the
>> specification text.  I know that the RelaxNG grammar isn't  
>> normative; but this
>> doesn't mean that it can be contradictory:

> I've asked Paul, and in fact we can fix typos and outright bugs later
> on in the process.  If you're right about the Relax mismatch (Rob?
> Norm?) then let's fix that.

> On the other hand, a general re-organization of section 6 is right  
> out; it is our finding that the format-09 draft (modulo errors)  
> reflects the rough consensus of the WG.  If you disagree, the IETF  
> provides appeal procedures.

Last week I thought about how to rework Section 6. Although some of
this reworking might be not acceptable now, I'll post it anyway. It
might be that there are some actual ambiguities in the current draft;
if so, then I guess that ambiguities might be considered to be "bugs",
that still need fixing.

It would be good if people could give section 6 a check to see that it
makes sense, and that the text matched their impression.


This rework itself was done fairly quickly, so it might have made some
things worse, but the major changes are:

1) Namespace attributes are explicitly excluded from the attributes
that determine the class of a Metadata Element.

2) Added namespace rules to section 6.4.1 and 6.4.2.

3) Added atom:source as a valid location for Metadata Elements.

4) Added paragraph about the intent of Metadata Elements.

5) Renamed 6.4 terms to "Metadata Extensions", "Simple Metadata
Extensions", and "Structured Metadata Extensions" for uniformity.

6) Added explicit definition of the term "Atom Vocabulary".

7) Moved sub-sections around so that the section can be read more
linearly.


I won't be available for the next week to discuss this btw.


== Dave's version of Section 6 ==

6.  Extending Atom

6.1  Extensions To the Atom Vocabulary

   Future versions of Atom could add new elements to the Atom
   namespace, and new attributes, in the default namespace, to
   existing Atom-namespaced elements.  Software written to conform to
   this version of the specification will not be able to process such
   markup correctly and, in fact, will not be able to distinguish it
   from markup error.  For the purposes of this discussion,
   unrecognized markup from the Atom vocabulary will be considered
   "foreign markup".

6.2  Extensions From Non-Atom Vocabularies

   This specification describes Atom's XML markup vocabulary.  Markup
   from other vocabularies ("foreign markup") can be used in an Atom
   document.  Note that the atom:content element is designed to support
   the inclusion of arbitrary foreign markup.

6.2.1  Metadata Extensions

   Child elements of atom:entry, atom:feed, atom:source, and Person
   constructs are considered Metadata Extensions, and are described
   below.  Child elements of Person constructs are considered to apply
   to the construct.

   Atom defines two classes of Metadata Extensions.  Simple Metadata
   Extensions are designed to be easier for simpler implementations to
   support.  To prevent sporadic support of an extension by
   implementations that only support Simple Metadata Extensions,
   extension authors SHOULD ensure that an extension is either a
   Simple Metadata Extension, or a Structured Metadata Extension for
   all of the extension's possible values.

6.2.1.1  Simple Metadata Extensions

   A Simple Metadata Extension element MUST NOT have any child
   elements or attributes, other than namespace declarations.  It MUST
   be namespaced-qualified, and MUST be defined outside of the Atom
   namespace.  The element MAY contain character data, or be empty.
   Simple Metadata Extensions are not Language-Sensitive.

   simpleExtensionElement =
      element * - atom:* {
         text
      }

   The element can be interpreted as a simple property (or name/value
   pair) of the parent element that encloses it.  The pair consisting of
   the namespace-URI of the element and the local name of the element
   can be interpreted as the name of the property.  The character data
   content of the element can be interpreted as the value of the
   property.  If the element is empty, then the property value can be
   interpreted as an empty string.

6.2.1.1  Structured Metadata Extensions

   The root element of a Structured Metadata Extension MUST have at
   least child element or attribute, other than namespace
   declarations.  It MUST be namespace-qualified, and MUST be defined
   outside of the Atom namespace.  It MAY have attributes, it MAY
   contain well-formed XML content (including character data), or it
   MAY be empty.  Structured Metadata Extensions are
   Language-Sensitive.

   structuredExtensionElement =
      element * - atom:* {
         (attribute * { text }+,
            (text|anyElement)*)
       | (attribute * { text }*,
          (text?, anyElement+, (text|anyElement)*))
      }

   The structure of a Structured Metadata Extension, including the order
   of its child elements, could be significant.

   This specification does not provide an interpretation of a Structured
   Metadata Extension.  The syntax of the XML contained in the element,
   and an interpretation of how the element relates to its containing
   element is defined by the specification of the Atom extension.

6.2.2  Unknown Foreign Markup

   Atom allows foreign markup anywhere in an Atom document, except
   where it is explicitly forbidden.  Markup in other locations, such
   as namespaced attributes, and child elements of atom-namespaced
   elements (for those elements that this specification does not
   already define a meaning for), are termed Unknown Foreign Markup.
   The role of Unknown Foreign Markup is undefined by this
   specification.

6.3  Processing Foreign Markup

   Atom Processors which encounter foreign markup in a location that is
   legal according to this specification MUST NOT stop processing or
   signal an error.  It might be the case that the Atom Processor is
   able to process the foreign markup correctly and does so.  Otherwise,
   such markup is termed "unknown foreign markup".

   When unknown foreign markup is encountered as a child of atom:entry,
   atom:feed, atom:source or a Person construct, Atom Processors MAY bypass
   the markup and any textual content and MUST NOT change their behavior
   as a result of the markup's presence.

   When unknown foreign markup is encountered in a Text Contruct or
   atom:content element, software SHOULD ignore the markup and process
   any text content of foreign elements as though the surrounding markup
   were not present.


-- 
Dave



From owner-atom-syntax@mail.imc.org  Thu Jun  9 20:11:52 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01982
	for <atompub-archive@lists.ietf.org>; Thu, 9 Jun 2005 20:11:52 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5A03l4B089012;
	Thu, 9 Jun 2005 17:03:47 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5A03laD089011;
	Thu, 9 Jun 2005 17:03:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231])
	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5A03hhY089003;
	Thu, 9 Jun 2005 17:03:45 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: <p06210257bece88273407@[10.20.30.249]>
In-Reply-To: <1026945406.20050610003142@djpowell.net>
References: <1118334135.42a86cb733d81@webmail.djpowell.net>
 <3ACE6F0F-7D87-4603-8AD0-F2001D9CC417@sun.com>
 <1026945406.20050610003142@djpowell.net>
Date: Thu, 9 Jun 2005 17:03:41 -0700
To: David Powell <djpowell@djpowell.net>
From: Paul Hoffman <phoffman@imc.org>
Subject: Re: Review of Section 6
Cc: atom-syntax@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>


At 12:31 AM +0100 6/10/05, David Powell wrote:
>Thursday, June 9, 2005, 5:51:57 PM, Tim Bray wrote:
>  > On the other hand, a general re-organization of section 6 is right
>  > out; it is our finding that the format-09 draft (modulo errors) 
>>  reflects the rough consensus of the WG.  If you disagree, the IETF
>  > provides appeal procedures.
>
>Last week I thought about how to rework Section 6.

Wearing my co-chair hat: we have no opportunity to rework any section 
of the document unless the IESG asks us to. If we find technical 
errors, we will of course fix them.

If you think that Tim and I have made administrative errors in 
preventing this reorganization, you can appeal that decision.

>Although some of
>this reworking might be not acceptable now,

*All* reworking is not acceptable now.

>  I'll post it anyway. It
>might be that there are some actual ambiguities in the current draft;
>if so, then I guess that ambiguities might be considered to be "bugs",
>that still need fixing.

There is a large difference between suggesting a bunch of reworking 
and pointing out specific ambiguities. Please do the latter if you 
find them.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Fri Jun 10 01:40:20 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24892
	for <atompub-archive@lists.ietf.org>; Fri, 10 Jun 2005 01:40:20 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5A5Uexh033082;
	Thu, 9 Jun 2005 22:30:40 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5A5UegJ033081;
	Thu, 9 Jun 2005 22:30:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mta09-winn.ispmail.ntl.com (mta09-winn.ispmail.ntl.com [81.103.221.49])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5A5Udic032990;
	Thu, 9 Jun 2005 22:30:39 -0700 (PDT)
	(envelope-from djpowell@djpowell.net)
Received: from aamta10-winn.ispmail.ntl.com ([81.103.221.35])
          by mta09-winn.ispmail.ntl.com with ESMTP
          id <20050610053033.INBU26596.mta09-winn.ispmail.ntl.com@aamta10-winn.ispmail.ntl.com>;
          Fri, 10 Jun 2005 06:30:33 +0100
Received: from cpc1-stok1-5-0-cust163.bagu.cable.ntl.com ([81.97.134.163])
          by aamta10-winn.ispmail.ntl.com with ESMTP
          id <20050610053033.BZGU24546.aamta10-winn.ispmail.ntl.com@cpc1-stok1-5-0-cust163.bagu.cable.ntl.com>;
          Fri, 10 Jun 2005 06:30:33 +0100
Date: Fri, 10 Jun 2005 06:30:27 +0100
From: David Powell <djpowell@djpowell.net>
X-Mailer: The Bat! (v3.5.24) Professional
X-Priority: 3 (Normal)
Message-ID: <140662533.20050610063027@djpowell.net>
To: Paul Hoffman <phoffman@imc.org>
CC: atom-syntax@imc.org
Subject: Re: Review of Section 6
In-Reply-To: <p06210257bece88273407@[10\.20\.30\.249]>
References: <1118334135.42a86cb733d81@webmail.djpowell.net>
 <3ACE6F0F-7D87-4603-8AD0-F2001D9CC417@sun.com>
 <1026945406.20050610003142@djpowell.net> <p06210257bece88273407@[10.20.30.249]>
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>
Content-Transfer-Encoding: 7bit



Friday, June 10, 2005, 1:03:41 AM, Paul Hoffman wrote:

> *All* reworking is not acceptable now.

> [...]

> There is a large difference between suggesting a bunch of reworking 
> and pointing out specific ambiguities. Please do the latter if you 
> find them.

Yes, I understand. In my previous mail I suggested some areas which
might be ambiguous, such as the distinctions between the various types
of extension markup; and whether we need to say that namespace
attributes don't count as attributes for the purposes of 6.4.1/2.
Whether or not this is serious is up for debate...

I posted this purely as a talking point, so that anyone unsure about
section 6, can take a look, see if it matches their understanding of
section 6; and if not, to see whether this is the draft's fault, their
fault, or my fault.

The reason I posted it at all, is because I will be on holiday for the
next week, so I won't have any more input until after then, which will
probably be a bit late.


-- 
Dave



From owner-atom-syntax@mail.imc.org  Fri Jun 10 05:50:49 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01024
	for <atompub-archive@lists.ietf.org>; Fri, 10 Jun 2005 05:50:47 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5A9fZBO028721;
	Fri, 10 Jun 2005 02:41:35 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5A9fZwT028720;
	Fri, 10 Jun 2005 02:41:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from scmailgw1.scop.aoyama.ac.jp (scmailgw1.scop.aoyama.ac.jp [133.2.251.194])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5A9fVtc028663
	for <atom-syntax@imc.org>; Fri, 10 Jun 2005 02:41:34 -0700 (PDT)
	(envelope-from duerst@it.aoyama.ac.jp)
Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17])
	by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id j5A9fO717987;
	Fri, 10 Jun 2005 18:41:24 +0900 (JST)
Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap 
	 id 47c48092_d995_11d9_87cd_0030482532aa_19094;
	Fri, 10 Jun 2005 18:51:56 +0900 (JST)
Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO003585;
  10 Jun 05 18:45:27 +0900
Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 10 Jun 05 18:45:16 +0900
Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.1) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG003583;
   10 Jun 05 18:45:05 +0900
Message-Id: <6.0.0.20.2.20050610172500.077c20d0@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Version 6J
Date: Fri, 10 Jun 2005 17:32:00 +0900
To: Andreas Sewe <ans208@mail.usask.ca>, atom-syntax@imc.org
From: Martin Duerst <duerst@it.aoyama.ac.jp>
Subject: Re: Question on Use Case: Choosing atom:content's type when
  ArchivingMailing Lists
In-Reply-To: <42A7993C.1060001@mail.usask.ca>
References: <42A7993C.1060001@mail.usask.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
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>
Content-Transfer-Encoding: 7bit


Hello Andreas,

There was quite some discussion between Keith Moore and me
and a few others about how to serve email in the context of
draft-duerst-archived-at-XX.

See e.g. http://www.imc.org/ietf-822/mail-archive/msg05486.html
and many older threads in the same archive.

The general idea seems to be that conversion to HTML is good for
human consumption with a browser, and for human navigation in an
archive. message/rfc822 is the original, and may be very good for
reuse in a mailer (e.g. for replying), except that mailers don't
support it much at the moment.

<atom:content type="message/rfc822" 
src="http://www.example.org/lists/list/archive/12345"/>

looks perfectly okay to me if that's what you want to do.
The average atom software may have difficulties treating
the message in a good way, but special applications could
do very interesting things with it. If the spec prohibits
it, that should maybe be fixed in the long term. To show
that there are good uses for it, and working implementations,
is the best start in that direction.

Regards,    Martin.

At 10:19 05/06/09, Andreas Sewe wrote:
 >
 >I have a question regarding a specific Atom use case: What is the 
preferred way to set up an Atom feed listing the contents of a mailing 
list's archive, given that composite media types (in particular 
"message/rfc822") are disallowed for atom:content's type attribute? This 
prevents me from doing something like the following, serving the archived 
mails "as-is" via HTTP:
 >
 ><atom:content type="message/rfc822" 
src="http://www.example.org/lists/list/archive/12345"/>
 >
 >But then again there might be something more fundamentally wrong with 
serving mails as "message/rfc822" via HTTP than I currently realize -- and 
I should better serve the mails as "text/plain" or convert them to HTML 
first (which is the way the atom-syntax archive works).
 >
 >Nevertheless, any advice on this issue would be greatly appreciated.
 >
 >Regards,
 >
 >Andreas Sewe
 > 



From owner-atom-syntax@mail.imc.org  Fri Jun 10 06:55:35 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06499
	for <atompub-archive@lists.ietf.org>; Fri, 10 Jun 2005 06:55:35 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5AAm0fO051978;
	Fri, 10 Jun 2005 03:48:00 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5AAm0CJ051977;
	Fri, 10 Jun 2005 03:48:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5AAlwbo051935
	for <atom-syntax@imc.org>; Fri, 10 Jun 2005 03:47:59 -0700 (PDT)
	(envelope-from dtcd@mac.com)
Received: from [161.73.58.69] (data-csmail2 [192.168.2.2])
	by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j5AAii6t015004;
	Fri, 10 Jun 2005 11:44:55 +0100 (BST)
In-Reply-To: <3B407288-D860-11D9-B6EE-003065EA6144@geckotribe.com>
References: <3B407288-D860-11D9-B6EE-003065EA6144@geckotribe.com>
Mime-Version: 1.0 (Apple Message framework v730)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <C5EE623D-C2F7-4A0C-A7FB-14036D47F541@mac.com>
Cc: atom-syntax <atom-syntax@imc.org>
Content-Transfer-Encoding: 7bit
From: Graham <dtcd@mac.com>
Subject: Re: I-D ACTION:draft-ietf-atompub-format-09.txt
Date: Fri, 10 Jun 2005 11:44:40 +0100
To: Antone Roundy <antone@geckotribe.com>
X-Mailer: Apple Mail (2.730)
X-MailScanner-Information: Oxford Brookes University MailScanner
X-MailScanner: Clean
X-MailScanner-From: dtcd@mac.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>
Content-Transfer-Encoding: 7bit


On 8 Jun 2005, at 9:59 pm, Antone Roundy wrote:

>>   atom:content MAY have a "src" attribute, whose value MUST be an IRI
>>    reference [RFC3987].  If the "src" attribute is present,  
>> atom:content
>>    MUST be empty.  Atom Processors MAY use the IRI to retrieve the
>>    content, and MAY NOT process or present remote content in the same
>>    manner as local content.
>>
> It took me a second to realize that MAY NOT means "don't have to"  
> rather than "aren't allowed to".  The technical meaning of the  
> terms is perfectly clear, but it's quite different from the usual  
> meaning of those words, and may be misunderstood.  It might be  
> better to say "Atom Processors MAY use the IRI to retrieve the  
> content, and MAY process or present remote content in a different  
> manner from local content."

+1

"and MAY process or present remote content in a different manner to  
local content"

Graham



From owner-atom-syntax@mail.imc.org  Thu Jun 16 08:03:10 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10785
	for <atompub-archive@lists.ietf.org>; Thu, 16 Jun 2005 08:03:09 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5GBjQZM052659;
	Thu, 16 Jun 2005 04:45:26 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5GBjQrC052656;
	Thu, 16 Jun 2005 04:45:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.204])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5GBjP97052531
	for <atom-syntax@imc.org>; Thu, 16 Jun 2005 04:45:25 -0700 (PDT)
	(envelope-from danny.ayers@gmail.com)
Received: by zproxy.gmail.com with SMTP id 18so361280nzp
        for <atom-syntax@imc.org>; Thu, 16 Jun 2005 04:45:20 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=R2qBm5749gX9mNuqHTB/+n2075UE5syPXPh5gv2SXTiV55+C48/bjUNblaSaAGj/3twlE0hlJuzPCsMtCV3+xoeUU98r+B8nh9prPa8LsBy2svk1wONimnEDMi1ollYEncqauPlkHgbsFXRk3U+UA+GWTzbn94cwH+q7mx8F9y4=
Received: by 10.36.221.78 with SMTP id t78mr311365nzg;
        Thu, 16 Jun 2005 04:45:20 -0700 (PDT)
Received: by 10.36.50.4 with HTTP; Thu, 16 Jun 2005 04:45:19 -0700 (PDT)
Message-ID: <1f2ed5cd050616044516a0675f@mail.gmail.com>
Date: Thu, 16 Jun 2005 13:45:19 +0200
From: Danny Ayers <danny.ayers@gmail.com>
Reply-To: Danny Ayers <danny.ayers@gmail.com>
To: Walter Underwood <wunder@verity.com>
Subject: Re: Google Sitemaps: Yet another "RSS" or site-metadata format and Atom "competitor"
Cc: atom-syntax <atom-syntax@imc.org>
In-Reply-To: <0F854671A165863C9EA1D65D@adsl-64-166-133-243.dsl.snfc21.pacbell.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
References: <68fba5c50506040003165e7e96@mail.gmail.com>
	 <200506041717.DIG99851@ms8.netsolmail.com>
	 <9c791d0a050607031726930e84@mail.google.com>
	 <0F854671A165863C9EA1D65D@adsl-64-166-133-243.dsl.snfc21.pacbell.net>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j5GBjQ97052642
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: 8bit


Ach, late to the thread again.

When I saw Google Sitemaps I also thought of RDF Site Summary, and did
a sitemap2rss.xsl. But as noted already the role of RSS has mutated
from site summary to a content delivery format, so it wasn't a very
good fit. But it was straightforward to take their data and express it
as RDF in a more natural fashion, see:
http://dannyayers.com/archives/2005/06/03/google-sitemap/

I think Atom could have been a good format for this purpose without
the need for any other. I disagree with Walter, I believe the Sitemap
terms are defined well enough to be reused.

I've pasted that of priority below - it basically says where a
crawler's resources are limited, URLs with a higher priority on a site
should be crawled first/in preference to others on the site. That
could be a nice like Atom extension.

Cheers,
Danny.

-----

priority
Definition
Optional. The priority of a particular URL relative to other pages on
the same site. The value for this tag is a number between 0.0 and 1.0,
where 0.0 identifies the lowest priority page(s) on your site and 1.0
identifies the highest priority page(s) on your site.

The default priority of a page is 0.5.

Please note that the priority you assign to a page has no influence on
the position of your URLs in a search engine's result pages. Search
engines use this information when selecting between URLs on the same
site, so you can use this tag to increase the likelihood that your
more important pages are present in a search index.

Also, please note that assigning a high priority to all of the URLs on
your site will not help you. Since the priority is relative, it is
only used to select between URLs on your site; the priority of your
pages will not be compared to the priority of pages on other sites.




-- 

http://dannyayers.com



From owner-atom-syntax@mail.imc.org  Thu Jun 16 13:37:36 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17472
	for <atompub-archive@lists.ietf.org>; Thu, 16 Jun 2005 13:37:35 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5GHTqk5050504;
	Thu, 16 Jun 2005 10:29:52 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5GHTqRi050503;
	Thu, 16 Jun 2005 10:29:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5GHTpYt050387
	for <atom-syntax@imc.org>; Thu, 16 Jun 2005 10:29:51 -0700 (PDT)
	(envelope-from sah@428cobrajet.net)
Received: from dul1shollenbl1 ([::ffff:216.168.239.87])
  (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5)
  by mail.verisignlabs.com with esmtp; Thu, 16 Jun 2005 13:29:47 -0400
  id 0059C1A7.42B1B70B.000055FC
From: "Scott Hollenbeck" <sah@428cobrajet.net>
To: atom-syntax@imc.org
Subject: FW: RFC 2119 problem in Atom syndication format
Date: Thu, 16 Jun 2005 13:30:24 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Thread-Index: AcVyklI2Fq44Iq7tQ/WXRK6OVvabuwABpOAA
Message-ID: <courier.42B1B70B.000055FC@mail.verisignlabs.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>
Content-Transfer-Encoding: 7bit


FYI.  This can be addressed post-IESG evaluation.

-Scott-

-----Original Message-----
From: Mark Baker [mailto:distobj@acm.org] 
Sent: Thursday, June 16, 2005 11:07 AM
To: iesg@ietf.org
Cc: mnot@mnot.net; rfsayre@boswijck.com
Subject: RFC 2119 problem in Atom syndication format

Section 4.1.3.2 of draft-ietf-atompub-format-09, the "src" attribute,
includes a common RFC 2119 mistake, "MAY NOT".  I expect that "SHOULD
NOT" was intended.  This was new to -09 AFAICT.

Mark.
-- 
Mark Baker.  Ottawa, Ontario, CANADA.          http://www.markbaker.ca
Coactus; Web-inspired integration strategies   http://www.coactus.com




From owner-atom-syntax@mail.imc.org  Thu Jun 16 13:50:59 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19039
	for <atompub-archive@lists.ietf.org>; Thu, 16 Jun 2005 13:50:58 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5GHiV6o066638;
	Thu, 16 Jun 2005 10:44:31 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5GHiVp1066637;
	Thu, 16 Jun 2005 10:44:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mailhost.netweaver.net (mailhost.netweaver.net [213.160.118.140])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j5GHiUef066555
	for <atom-syntax@imc.org>; Thu, 16 Jun 2005 10:44:30 -0700 (PDT)
	(envelope-from davep@dpawson.co.uk)
Received: (qmail 24235 invoked from network); 16 Jun 2005 17:44:20 -0000
Received: from dpawson.gotadsl.co.uk (HELO ?192.168.2.7?) (davep@dpawson.co.uk@81.6.251.105)
  by 0 with SMTP; 16 Jun 2005 17:44:20 -0000
Subject: feed or entry
From: Dave Pawson <davep@dpawson.co.uk>
Reply-To: davep@dpawson.co.uk
To: atom-syntax@imc.org
Content-Type: text/plain
Date: Thu, 16 Jun 2005 18:44:18 +0100
Message-Id: <1118943858.9048.6.camel@marge>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
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>
Content-Transfer-Encoding: 7bit


I'm not having much luck working
out how I can write (daily or there abouts)
an entry, without having to duplicate
feed metadata.


Am I alone in this?

Xinsert isn't common yet.. is it?



-- 
Regards, 

Dave Pawson
XSLT + Docbook FAQ
http://www.dpawson.co.uk
http://www.dpawson.co.uk/blog/



From owner-atom-syntax@mail.imc.org  Thu Jun 16 15:07:15 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26454
	for <atompub-archive@lists.ietf.org>; Thu, 16 Jun 2005 15:07:15 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5GIvHDq047578;
	Thu, 16 Jun 2005 11:57:17 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5GIvHJK047577;
	Thu, 16 Jun 2005 11:57:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.194])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5GIvGiL047471
	for <atom-syntax@imc.org>; Thu, 16 Jun 2005 11:57:17 -0700 (PDT)
	(envelope-from jasnell@gmail.com)
Received: by wproxy.gmail.com with SMTP id 70so606182wra
        for <atom-syntax@imc.org>; Thu, 16 Jun 2005 11:57:11 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=YnwumUqNADqB1CHH0ZPCFaGNXevIL0ycEzn+gT2zwEWA+Rer5eBp1uzmFPYD+9BIHk5JCKvjkAS1X3iGA71FB+TcGYzUf3GoeezueyJHmik+eZt5Pj0/9fbFc4VviGNXsoTcI+tir8JdF1CECraKROoCtT6BihiEwHxcq7uJ31M=
Received: by 10.54.116.2 with SMTP id o2mr785642wrc;
        Thu, 16 Jun 2005 11:57:11 -0700 (PDT)
Received: from ?192.168.1.103? ([67.181.223.222])
        by mx.gmail.com with ESMTP id 66sm1106496wra.2005.06.16.11.57.10;
        Thu, 16 Jun 2005 11:57:11 -0700 (PDT)
Message-ID: <42B1CB81.3060101@gmail.com>
Date: Thu, 16 Jun 2005 11:57:05 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: atom-syntax@imc.org
Subject: More on Atom XML signatures and encryption
References: <1118943858.9048.6.camel@marge>
In-Reply-To: <1118943858.9048.6.camel@marge>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


I am preparing to write up some thoughts on an initial I-D for XML 
Digital Signatures and Encryption in Atom and wanted to get some initial 
thoughts from the group on a few syntax issues starting first with some 
encryption thoughts:

Below are a few snippets of feeds with different encryptions each with 
their own distinct issues.

1. No encryption  (potentially encrypted in transport using SSL/TLS)
  <feed>
    <entry>
      <content type="text">this is some content</content>
    </entry>
  </feed>

2. Text content of #1 is encrypted.
  <feed>
    <entry>
      <content type="???">
        <EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"
                       type="http://www.w3.org/2001/04/xmlenc#Content">
          <CipherData>
            <CipherValue><!-- cipher of "this is some content" 
--></CipherValue>
          </CipherData>
        </EncryptedData>
      </content>
    </entry>
  </feed>

  What should the value of the type attribute be in this case?  A strict 
reading of the Atom spec would dictate a value of "xml", but doing so 
would cause us to lose the content type of the unencrypted content.  A 
simple solution would be to introduce a new extension attribute on the 
content element that captures the type of the unencrypted content.

    e.g. <content type="xml" enc:type="text"><EncryptedData 
...>...</EncryptedData></content>

3. Content metadata element is encrypted 
  <feed>
    <entry>
        <EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"
                       type="http://www.w3.org/2001/04/xmlenc#Element">
          <CipherData>
            <CipherValue><!-- cipher of "<content type="text">this is 
some content</content>" --></CipherValue>
          </CipherData>
        </EncryptedData>
    </entry>
  </feed>

  In this case, the metadata elements themselves are encrypted opening 
the obvious issue that all of the encrypted elements need to be 
decrypted in order to perform the processing of the Atom elements.  In 
other words, you wouldn't be able to validate that an entry is 
conformant until you decrypted everything.

4. Entry element is encrypted
  <feed>
         <EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"
                       type="http://www.w3.org/2001/04/xmlenc#Element">
          <CipherData>
            <CipherValue><!-- cipher of "<entry>...</entry>" 
--></CipherValue>
          </CipherData>
        </EncryptedData>
  </feed>
 
  Same basic issue as #3 only not so bad. 

5. Entire feed is encrypted
  <EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"
                   type="http://www.w3.org/2001/04/xmlenc#Element">
       <CipherData>
         <CipherValue><!-- cipher of "<feed>...</feed>" --></CipherValue>
       </CipherData>
   </EncryptedData>

   Simple and too the point.  The only challenge is how we identify this 
as being an encrypted Atom feed.  It does not conform to the rules of 
the application/atom+xml media type.  Perhaps a new 
application/atomenc+xml media type could be used or is there a better way?

Thoughts?

- James



From owner-atom-syntax@mail.imc.org  Thu Jun 16 15:15:38 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27577
	for <atompub-archive@lists.ietf.org>; Thu, 16 Jun 2005 15:15:37 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5GJ9MWC059912;
	Thu, 16 Jun 2005 12:09:22 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5GJ9MS2059911;
	Thu, 16 Jun 2005 12:09:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web42208.mail.yahoo.com (web42208.mail.yahoo.com [66.218.93.209])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j5GJ9LML059799
	for <atom-syntax@imc.org>; Thu, 16 Jun 2005 12:09:21 -0700 (PDT)
	(envelope-from jfcst24_public@yahoo.com)
Received: (qmail 73142 invoked by uid 60001); 16 Jun 2005 19:09:06 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=lxfsLRcDsUABSm6HyPBy4mKUViXj1J8h69Cbc+FgbowkV9PUCATEL29oa3saCfPfcFuaf2iQrtntakecFblIwq12QnjRHl4tZvQejNvKOYZ0NfBwUwqQSgEiaFpQxRhfXmK/AdQX6kkj7KCcrgurhJId3eAngVNqrwgIJeI/P0Q=  ;
Message-ID: <20050616190906.73140.qmail@web42208.mail.yahoo.com>
Received: from [4.155.69.133] by web42208.mail.yahoo.com via HTTP; Thu, 16 Jun 2005 12:09:06 PDT
Date: Thu, 16 Jun 2005 12:09:06 -0700 (PDT)
From: James Cerra <jfcst24_public@yahoo.com>
Subject: Re: feed or entry
To: davep@dpawson.co.uk, atom-syntax@imc.org
In-Reply-To: <1118943858.9048.6.camel@marge>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
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: 8bit


Dave Pawson,

> I'm not having much luck working
> out how I can write (daily or there abouts)
> an entry, without having to duplicate
> feed metadata.

I don't follow.  Could you give an example showing the duplicated metadata?


--
Jimmy Cerra
https://nemo.dev.java.net


		
__________________________________ 
Discover Yahoo! 
Use Yahoo! to plan a weekend, have fun online and more. Check it out! 
http://discover.yahoo.com/



From owner-atom-syntax@mail.imc.org  Thu Jun 16 15:20:49 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28089
	for <atompub-archive@lists.ietf.org>; Thu, 16 Jun 2005 15:20:48 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5GJELKl065366;
	Thu, 16 Jun 2005 12:14:21 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5GJELqc065365;
	Thu, 16 Jun 2005 12:14:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail02.svc.cra.dublin.eircom.net (mail02.svc.cra.dublin.eircom.net [159.134.118.18])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j5GJEKCb065327
	for <atom-syntax@imc.org>; Thu, 16 Jun 2005 12:14:21 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 28239 messnum 5243041 invoked from network[83.70.250.40/83-70-250-40.b-ras1.prp.dublin.eircom.net]); 16 Jun 2005 19:14:14 -0000
Received: from 83-70-250-40.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.250.40)
  by mail02.svc.cra.dublin.eircom.net (qp 28239) with SMTP; 16 Jun 2005 19:14:14 -0000
Message-ID: <42B1CF84.5040508@dehora.net>
Date: Thu, 16 Jun 2005 20:14:12 +0100
From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: James M Snell <jasnell@gmail.com>
CC: atom-syntax@imc.org
Subject: Re: More on Atom XML signatures and encryption
References: <1118943858.9048.6.camel@marge> <42B1CB81.3060101@gmail.com>
In-Reply-To: <42B1CB81.3060101@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


James M Snell wrote:

> Thoughts?

The mot straightforward way (imo) to deal with encoded fragments is to 
use two attributes, ie @type and @enc. So defining a new extension 
attribute would work for me.

I'm not sure you need to deal with signalling the type of a fully 
encrypted document in your case 5; if it's not possible to signal the 
type via xmlenc I'd claim it's a spec bug there, not here.

cheers
Bill




From owner-atom-syntax@mail.imc.org  Thu Jun 16 16:00:13 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02115
	for <atompub-archive@lists.ietf.org>; Thu, 16 Jun 2005 16:00:12 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5GJqV2I010695;
	Thu, 16 Jun 2005 12:52:31 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5GJqV6A010694;
	Thu, 16 Jun 2005 12:52:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mailhost.netweaver.net (mailhost.netweaver.net [213.160.118.140])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j5GJqUCt010654
	for <atom-syntax@imc.org>; Thu, 16 Jun 2005 12:52:30 -0700 (PDT)
	(envelope-from davep@dpawson.co.uk)
Received: (qmail 20782 invoked from network); 16 Jun 2005 19:52:29 -0000
Received: from dpawson.gotadsl.co.uk (HELO ?192.168.2.7?) (davep@dpawson.co.uk@81.6.251.105)
  by 0 with SMTP; 16 Jun 2005 19:52:29 -0000
Subject: Re: feed or entry
From: Dave Pawson <davep@dpawson.co.uk>
Reply-To: davep@dpawson.co.uk
To: James Cerra <jfcst24_public@yahoo.com>
Cc: atom-syntax@imc.org
In-Reply-To: <20050616190906.73140.qmail@web42208.mail.yahoo.com>
References: <20050616190906.73140.qmail@web42208.mail.yahoo.com>
Content-Type: text/plain
Date: Thu, 16 Jun 2005 20:52:28 +0100
Message-Id: <1118951548.9048.27.camel@marge>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
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>
Content-Transfer-Encoding: 7bit


On Thu, 2005-06-16 at 12:09 -0700, James Cerra wrote:
> Dave Pawson,
> 
> > I'm not having much luck working
> > out how I can write (daily or there abouts)
> > an entry, without having to duplicate
> > feed metadata.
> 
> I don't follow.  Could you give an example showing the duplicated metadata?

Process. I write an instance. document element is a:feed.

Each successive day (or thereabouts) I write an entry.
I'm processing via XSLT.

I don't want a single monolith of a file,
so I'm writing daily using a document element of a:entry.

The end product is an 'empty' a:feed element (i.e. no entry children)
and 101 orphan a:entry instances, each with a days content.

Possibly because I'm not autogenerating all the 
metadata (child to a:feed, ancestor to a:entry) daily
I'm not in a position to post a single a:feed instance.
Is that any clearer?

(www.dpawson.co.uk/blog is the outcome)




-- 
Regards, 

Dave Pawson
XSLT + Docbook FAQ
http://www.dpawson.co.uk



From owner-atom-syntax@mail.imc.org  Thu Jun 16 16:34:31 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13376
	for <atompub-archive@lists.ietf.org>; Thu, 16 Jun 2005 16:34:31 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5GKSqgU050904;
	Thu, 16 Jun 2005 13:28:52 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5GKSqHD050903;
	Thu, 16 Jun 2005 13:28:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231])
	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5GKSod9050884
	for <atom-syntax@imc.org>; Thu, 16 Jun 2005 13:28:51 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: <p0621024ebed78efa2b25@[10.20.30.249]>
Date: Thu, 16 Jun 2005 13:28:43 -0700
To: Atom WG <atom-syntax@imc.org>
From: Paul Hoffman <phoffman@imc.org>
Subject: Timing guide for Atom implementers
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>


Greetings again. Some people have started asking (mostly off-list) 
when the Atom format would be "done" so they can implement and, more 
importantly, deploy. This message gives our best shot at answering 
the question.

The status of the format document is that the -09 draft is in the 
IESG evaluation queue. This means that the IESG will consider it 
soon. In fact, it has been scheduled for their telechat next 
Thursday. (There are many documents scheduled; see 
<http://www.ietf.org/IESG/agenda.html>.) The IESG members are now 
reading the document in preparation for the telechat, and they may 
(or may not) be discussing it among themselves.

Next Thursday, the IESG might [a] say "this is fine as it is, no 
changes needed". It is much more likely that they will [b] say "this 
will be OK after you make the following changes in the -10 draft" and 
they will list a handful of changes that range from editorial nits to 
adding clarifications. There is a real chance they will [c] say "This 
has some real technical deficiencies, please revise this and show us 
-10 before we make a final decision."

If [a] or [b]:

Because there are no technical changes requested to the document, 
implementers can get ready to deploy. The only significant change 
that will appear in -10 will be that the final Atom 1.0 namespace 
will be included. Tim is responsible for getting that minted, but we 
won't do so until we are sure that there is a technically-stable 
document; we don't expect the namespace creation to take much time. 
As soon as the namespace is minted, we'll tell the WG. (There will be 
other changes in -10, such as the last editorial nits, and the 
addition of the longer acknowledgements list. In fact, even if [a] 
happens, there will be a -10.)

Also, after -10 is published as an Internet Draft, Scott Hollenbeck 
will remove the last "hold" on it and it will become an IETF Proposed 
Standard. Note that it is really a standard at that moment, *not* 
when it gets published as an RFC (which will be 3 or 4 months later 
<sigh>). Implementers can start shipping as soon as it is a standard, 
and not wait for the RFC.

If [c]:

However, in the case of [c], implementers should put their 
development on hold. If the IESG asks for a technical change, it will 
take at least a few weeks for the Atom WG to reply either with the 
change or with a stack of solid arguments why our original text was, 
in fact, correct. In the latter case, the IESG will probably take at 
least a few weeks to agree with us, or for them to say "no, we really 
meant it". There could be multiple rounds, so the -10 might not be 
final.

Summary:

The -09 draft of the format cannot be considered final and 
deployable. The IESG may ask/demand changes in it before it becomes a 
standard, and we will not give it a "final" namespace until the IESG 
says that it won't be changed. At that time, we will quickly get a 
nice namespace minted, and tell the WG what it is. There is a real 
chance that the document will be a standard two weeks from now; there 
is a real chance it will take a few months.

If all this IETF process stuff is confusing, reading the Tao of the 
IETF (<http://www.ietf.org/tao.html>) might help. Also, there is a 
link to the IETF status of the document on the wiki 
(<http://www.intertwingly.net/wiki/pie/FrontPage>).

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Thu Jun 16 17:33:51 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17480
	for <atompub-archive@lists.ietf.org>; Thu, 16 Jun 2005 17:33:50 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5GLPY9i015125;
	Thu, 16 Jun 2005 14:25:34 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5GLPYLV015124;
	Thu, 16 Jun 2005 14:25:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.202])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5GLPXDH015095
	for <atom-syntax@imc.org>; Thu, 16 Jun 2005 14:25:33 -0700 (PDT)
	(envelope-from jasnell@gmail.com)
Received: by wproxy.gmail.com with SMTP id 55so683723wri
        for <atom-syntax@imc.org>; Thu, 16 Jun 2005 14:25:27 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=JMuXLh6duYddCbuP/JGoCyOYEwD1jTKhYy8SmsR+d+6qD8ZfPDbj9FUM/3+Q0IPHS4oY39U9NbzP31f5EsYY2bRhPEuM6P6hDxXyWWxprH77Lm5Gs2CSR8GmhyZqS/rr4lZ9O5JM6KEcnf9wOvTztcQC73lEIK/otRDhFNAhB2Y=
Received: by 10.54.56.77 with SMTP id e77mr716978wra;
        Thu, 16 Jun 2005 14:25:27 -0700 (PDT)
Received: from ?192.168.1.103? ([67.181.223.222])
        by mx.gmail.com with ESMTP id 14sm362033wrl.2005.06.16.14.25.26;
        Thu, 16 Jun 2005 14:25:27 -0700 (PDT)
Message-ID: <42B1EE41.9030304@gmail.com>
Date: Thu, 16 Jun 2005 14:25:21 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net>, atom-syntax@imc.org
Subject: Re: More on Atom XML signatures and encryption
References: <1118943858.9048.6.camel@marge> <42B1CB81.3060101@gmail.com> <42B1CF84.5040508@dehora.net>
In-Reply-To: <42B1CF84.5040508@dehora.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
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: 8bit


Bill de hÓra wrote:

> James M Snell wrote:
>
>> Thoughts?
>
>
> The mot straightforward way (imo) to deal with encoded fragments is to 
> use two attributes, ie @type and @enc. So defining a new extension 
> attribute would work for me.

See my comments below on the type identification.

Here's another challenge... what about Text constructs like summary that 
only allow html, text and xhtml values for their type attribute.  It 
would apear that we cannot embed an EncryptedData element in Text 
constructs.  I dunno, is this a problem?  Outside <content />, I really 
don't think we should be encouraging folks to encrypt individual 
metadata elements as that could get rather silly. 

So perhaps we should limit XML encryption to

    a) The entire feed
    b) individual entries and
    c) the content of content elements. (examples 2, 4 and 5 in my 
original note).

>
> I'm not sure you need to deal with signalling the type of a fully 
> encrypted document in your case 5; if it's not possible to signal the 
> type via xmlenc I'd claim it's a spec bug there, not here.

You know... it really would help if I *re-read* the relevant specs 
before opening my mouth ;-) The EncryptedData element already has 
attributes for specifying the original type of the encrypted data.  Now 
I just feel silly.

Example 1:

    <feed>
      <entry>
        <content type="text">This is some text</content>
      </entry>
    </feed>

Becomes

    <feed>
      <entry>
        <content type="application/xenc+xml">
          <EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Content
                                    
MimeType="text/plain">...</EncryptedData>
        </content>
      </entry>
    </feed>

Example 2:

    <feed>
        <entry>
            <content type="html">&lt;p>This is some HTML&lt;/p></content>
        </entry>
    </feed>

Becomes

    <feed>
      <entry>
        <content type="application/xenc+xml">
          <EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Content"
                                    MimeType="text/html">...</EncryptedData>
        </content>
      </entry>
    </feed>



(note to self: read the damn spec next time  ;-)     )

> cheers
> Bill
>
>
>
- James



From owner-atom-syntax@mail.imc.org  Thu Jun 16 18:43:51 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22903
	for <atompub-archive@lists.ietf.org>; Thu, 16 Jun 2005 18:43:51 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5GMbQ6I091281;
	Thu, 16 Jun 2005 15:37:26 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5GMbQ3l091280;
	Thu, 16 Jun 2005 15:37:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.207])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5GMbQGU091266
	for <atom-syntax@imc.org>; Thu, 16 Jun 2005 15:37:26 -0700 (PDT)
	(envelope-from jasnell@gmail.com)
Received: by wproxy.gmail.com with SMTP id 70so691358wra
        for <atom-syntax@imc.org>; Thu, 16 Jun 2005 15:37:20 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=YpQ17I/8TaeLe4R6lPiLdlC6fAIVn850rI0TTPgsDenHRZwxjpyiXJfi5SH+9c0CRmYlI6Dx/Df33PgOm7SkJNmuATF6cOq9kV7EB5bI9zu2NbDBNALHgF1+39i0p+DoH1xM5vzxa++ITJyGpkqTwkYhxrqOxQDJmHIFVUknqu0=
Received: by 10.54.73.15 with SMTP id v15mr900986wra;
        Thu, 16 Jun 2005 15:37:20 -0700 (PDT)
Received: from ?192.168.1.103? ([67.181.223.222])
        by mx.gmail.com with ESMTP id 27sm2403530wrl.2005.06.16.15.37.20;
        Thu, 16 Jun 2005 15:37:20 -0700 (PDT)
Message-ID: <42B1FF1A.2070202@gmail.com>
Date: Thu, 16 Jun 2005 15:37:14 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: atom-syntax@imc.org
Subject: Atom feed synchronization
References: <p0621024ebed78efa2b25@[10.20.30.249]>
In-Reply-To: <p0621024ebed78efa2b25@[10.20.30.249]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


Ok, question for the group.

Scenario: A content source is updated 100 times per hour.  The Atom feed 
currently only displays the 20 most recent entries.  Users who are not 
checking the feed every 10 minutes or so are missing entries.  How do we 
address this?

Solution: Rather than using a feed with a fixed number of entries, 
provide a mechanism that allows users to specify the last time they 
retrieved the feed and have the feed return all entries added since that 
time.

Question: What is the best way to provide that mechanism: querystring 
parameter or HTTP header or some other way I'm not thinking of

    http://...?last-retrieved=12345

OR

   GET ... HTTP/1.1
   Host: ...
   Last-Retrieved: 12345

 - James



From owner-atom-syntax@mail.imc.org  Thu Jun 16 19:09:05 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24916
	for <atompub-archive@lists.ietf.org>; Thu, 16 Jun 2005 19:09:04 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5GN1F3G005769;
	Thu, 16 Jun 2005 16:01:15 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5GN1FHR005768;
	Thu, 16 Jun 2005 16:01:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.195])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5GN1EAE005760
	for <atom-syntax@imc.org>; Thu, 16 Jun 2005 16:01:14 -0700 (PDT)
	(envelope-from jasnell@gmail.com)
Received: by rproxy.gmail.com with SMTP id a41so210996rng
        for <atom-syntax@imc.org>; Thu, 16 Jun 2005 16:01:14 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:content-type:content-transfer-encoding;
        b=Wm4ADTe0E4S97zqu9PTPDbI0Awmk+oltsRFvBPqluSEZs24s0p3Mc5f+k+qU572H8Az5teinfHiGhK5CqjYq0pmL+DnsCrk1flRVfgm4sh74qt1ccrwOmauN1QTIXqxm8sVBuG8so89MXz9mBiFaiamQ4GWRuMLixI9gI68ghDE=
Received: by 10.38.161.29 with SMTP id j29mr603582rne;
        Thu, 16 Jun 2005 16:01:14 -0700 (PDT)
Received: from ?192.168.1.103? ([67.181.223.222])
        by mx.gmail.com with ESMTP id 74sm164870rnb.2005.06.16.16.01.13;
        Thu, 16 Jun 2005 16:01:14 -0700 (PDT)
Message-ID: <42B204B4.1080905@gmail.com>
Date: Thu, 16 Jun 2005 16:01:08 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: atom-syntax@imc.org
Subject: Re: Atom feed synchronization
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


Just a bit more digging to expand the question a bit:

A third alternative to handling this is to use a Range header with a new 
token value...e.g.

Example 1: Get all entries modified after the specified HTTP-date 
(inclusive)

  GET ... HTTP/1.1
  Host: ...
  Range: modified=[HTTP-date]

Example 2: Get all entries modified between HTTP-date 1 and HTTP-date 2 
(inclusive)

  GET ... HTTP/1.1
  Host: ....
  Range: modified=[HTTP-date 1]-[HTTP-date 2]

(oh, and BTW, in the previous note 12345 is really a HTTP-date... I was 
just being lazy when typing)

- James

-------- Original Message --------
Subject: 	Atom feed synchronization
Date: 	Thu, 16 Jun 2005 15:37:14 -0700
From: 	James M Snell <jasnell@gmail.com>
To: 	atom-syntax@imc.org
References: 	<p0621024ebed78efa2b25@[10.20.30.249]>


Ok, question for the group.

Scenario: A content source is updated 100 times per hour.  The Atom feed 
currently only displays the 20 most recent entries.  Users who are not 
checking the feed every 10 minutes or so are missing entries.  How do we 
address this?

Solution: Rather than using a feed with a fixed number of entries, 
provide a mechanism that allows users to specify the last time they 
retrieved the feed and have the feed return all entries added since that 
time.

Question: What is the best way to provide that mechanism: querystring 
parameter or HTTP header or some other way I'm not thinking of

   http://...?last-retrieved=12345

OR

  GET ... HTTP/1.1
  Host: ...
  Last-Retrieved: 12345

- James




From owner-atom-syntax@mail.imc.org  Thu Jun 16 19:30:48 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26335
	for <atompub-archive@lists.ietf.org>; Thu, 16 Jun 2005 19:30:47 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5GNOM2A029553;
	Thu, 16 Jun 2005 16:24:22 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5GNOMlo029550;
	Thu, 16 Jun 2005 16:24:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5GNOL9W029263
	for <atom-syntax@imc.org>; Thu, 16 Jun 2005 16:24:21 -0700 (PDT)
	(envelope-from antone@geckotribe.com)
Received: from geckotribe.com (c-67-169-250-63.hsd1.ut.comcast.net[67.169.250.63])
          by comcast.net (sccrmhc13) with SMTP
          id <2005061623241101600sv7k9e>; Thu, 16 Jun 2005 23:24:11 +0000
Date: Thu, 16 Jun 2005 17:24:09 -0600
Mime-Version: 1.0 (Apple Message framework v553)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Subject: Re: Atom feed synchronization
From: Antone Roundy <antone@geckotribe.com>
To: atom-syntax@imc.org
Content-Transfer-Encoding: 7bit
Message-Id: <BDDD26C5-DEBD-11D9-B067-003065EA6144@geckotribe.com>
X-Mailer: Apple Mail (2.553)
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: 7bit


On Thursday, June 16, 2005, at 04:37  PM, James M Snell wrote:
> Scenario: A content source is updated 100 times per hour.  The Atom 
> feed currently only displays the 20 most recent entries.  Users who 
> are not checking the feed every 10 minutes or so are missing entries.  
> How do we address this?

1) Tell users to poll more frequently--if they don't, that's their 
problem
2) Make the feed longer than 20 entries
2a) If the feed is SOMETIMES updated 100 times per hour, but sometimes 
only twice per hour, dynamically set the feed length--when regenerating 
the feed, include all entries updated in the last hour or so, down to 
some minimum number
3) Push instead of pull
4) Create a new link @rel to point to the next X entries and keep a 
series of static documents containing the older entries

None of the above would require dynamic generation of the feed or 
returning a different static document based on request headers or query 
parameters.



From owner-atom-syntax@mail.imc.org  Thu Jun 16 19:56:40 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27763
	for <atompub-archive@lists.ietf.org>; Thu, 16 Jun 2005 19:56:40 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5GNmQOg055307;
	Thu, 16 Jun 2005 16:48:26 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5GNmQ0W055306;
	Thu, 16 Jun 2005 16:48:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5GNmPvN055145
	for <atom-syntax@imc.org>; Thu, 16 Jun 2005 16:48:26 -0700 (PDT)
	(envelope-from jasnell@gmail.com)
Received: by wproxy.gmail.com with SMTP id 58so743818wri
        for <atom-syntax@imc.org>; Thu, 16 Jun 2005 16:48:20 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=BVrrQSOdl1jJpTmGRJZ4NwD4tIQ1ZdF6844k5Sdg/VCt84V/uWp9X7ab58lQ8L3A05Rgnwwr4ggetD7Cen/7i36DNSeylCh8G1folv7M53fUElG4IaXU2EdPEzN1EtIvjRVah2DyLqq+pv2dn9xqtSyGFpyJTe7/B5+OwMakEKo=
Received: by 10.54.44.58 with SMTP id r58mr778169wrr;
        Thu, 16 Jun 2005 16:48:20 -0700 (PDT)
Received: from ?192.168.1.103? ([67.181.223.222])
        by mx.gmail.com with ESMTP id 12sm488972wrl.2005.06.16.16.48.19;
        Thu, 16 Jun 2005 16:48:20 -0700 (PDT)
Message-ID: <42B20FBE.2050108@gmail.com>
Date: Thu, 16 Jun 2005 16:48:14 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: atom-syntax@imc.org
Subject: Re: Atom feed synchronization
References: <A9BD28AC-DEBB-11D9-B067-003065EA6144@geckotribe.com>
In-Reply-To: <A9BD28AC-DEBB-11D9-B067-003065EA6144@geckotribe.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


Antone Roundy wrote:

> On Thursday, June 16, 2005, at 04:37  PM, James M Snell wrote:
>
>> Scenario: A content source is updated 100 times per hour.  The Atom 
>> feed currently only displays the 20 most recent entries.  Users who 
>> are not checking the feed every 10 minutes or so are missing 
>> entries.  How do we address this?
>
>
> 1) Tell users to poll more frequently--if they don't, that's their 
> problem

Feed is updated 24 hours a day from sources all over the world.  Would 
be rather impractical for me to keep my system on 24 hours a day pinging 
the server every 10 minutes just to make sure I don't miss any content.  
Further, it just doesn't seem right to constrain Atom to a "Must Be 
Present To Win" mentality.

> 2) Make the feed longer than 20 entries

Possible, but potentially not scalable.  What if the source update rates 
double or triple over a few months time (a strong possibility).  We'd 
have to keep increasing the size of the feed to account for the 
increased publishing rates.  Even then, folks would still miss content 
unless they check regularly. Seems like it would be better to just 
include the entries that were actually modified within a given period of 
time than to keep fiddling with the size.

> 2a) If the feed is SOMETIMES updated 100 times per hour, but sometimes 
> only twice per hour, dynamically set the feed length--when 
> regenerating the feed, include all entries updated in the last hour or 
> so, down to some minimum number

Dynamically setting the feed length based on some calculation of update 
rates just seems silly to me.  But using multiple feeds each reflecting 
a different time window is a strong option.  one feed shows past hour, 
another feed shows past six hours, etc.... not perfect as it requires 
the user to do more work in selecting which feed to subscribe to.  Any 
solution that requires the user to do more work is less than optimum.

> 3) Push instead of pull

Possible but rather impractical for disconnected clients.

> 4) Create a new link @rel to point to the next X entries and keep a 
> series of static documents containing the older entries
>
Possible, but on the surface it doesn't seem to be any better or 
efficient than the header or querystring method.  In fact, it seems 
rather inefficient to me.

Thanks for the input :-)

- James



From owner-atom-syntax@mail.imc.org  Thu Jun 16 20:20:03 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29577
	for <atompub-archive@lists.ietf.org>; Thu, 16 Jun 2005 20:20:02 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5H0BTSj078916;
	Thu, 16 Jun 2005 17:11:29 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5H0BTbG078915;
	Thu, 16 Jun 2005 17:11:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.25])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5H0BRIM078759
	for <atom-syntax@imc.org>; Thu, 16 Jun 2005 17:11:28 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 17 Jun 2005 10:11:50 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Fri, 17 Jun 2005 10:11:22 +1000
Subject: Re: Atom feed synchronization
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BED8524A.5F22D%eric.scheid@ironclad.net.au>
In-Reply-To: <42B1FF1A.2070202@gmail.com>
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>
Content-Transfer-Encoding: 7bit


On 17/6/05 8:37 AM, "James M Snell" <jasnell@gmail.com> wrote:

> Question: What is the best way to provide that mechanism: querystring
> parameter or HTTP header or some other way I'm not thinking of

Something involving eTags would be the simplest from the client end.

e.



From owner-atom-syntax@mail.imc.org  Thu Jun 16 20:32:15 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00524
	for <atompub-archive@lists.ietf.org>; Thu, 16 Jun 2005 20:32:15 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5H0Q1ab093470;
	Thu, 16 Jun 2005 17:26:01 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5H0Q1YB093469;
	Thu, 16 Jun 2005 17:26:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.193])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5H0Q0mR093407
	for <atom-syntax@imc.org>; Thu, 16 Jun 2005 17:26:01 -0700 (PDT)
	(envelope-from jasnell@gmail.com)
Received: by zproxy.gmail.com with SMTP id 13so148898nzp
        for <atom-syntax@imc.org>; Thu, 16 Jun 2005 17:25:55 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=bteLNSXBNixULhiyM22maGjTZRt5vz9fg58Uu8vOVz+TI7vGYH1f8t4odW8ulgqlLvTsLTEBJXI1b2ekqc2r7k+GXz/usQLMKZC5mg6fJgwmM5Vrtn/YzSUkzN3VLG7IZKGGA5uCIIv1nwbDMyK7ved4dRyw+tmjrc474agenzs=
Received: by 10.36.24.6 with SMTP id 6mr949396nzx;
        Thu, 16 Jun 2005 17:25:55 -0700 (PDT)
Received: from ?192.168.1.103? ([67.181.223.222])
        by mx.gmail.com with ESMTP id c12sm755933nzc.2005.06.16.17.25.54;
        Thu, 16 Jun 2005 17:25:55 -0700 (PDT)
Message-ID: <42B2188D.5050402@gmail.com>
Date: Thu, 16 Jun 2005 17:25:49 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Eric Scheid <eric.scheid@ironclad.net.au>, atom-syntax@imc.org
Subject: Re: Atom feed synchronization
References: <BED8524A.5F22D%eric.scheid@ironclad.net.au>
In-Reply-To: <BED8524A.5F22D%eric.scheid@ironclad.net.au>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


Eric Scheid wrote:

>On 17/6/05 8:37 AM, "James M Snell" <jasnell@gmail.com> wrote:
>
>  
>
>>Question: What is the best way to provide that mechanism: querystring
>>parameter or HTTP header or some other way I'm not thinking of
>>    
>>
>
>Something involving eTags would be the simplest from the client end.
>
>e.
>
>
>  
>
Agreed, but it seems to be a bit of a trick to figure out what that 
"something involvig eTags" could be ;-)

None of the existing HTTP Headers that involve etags would seem to 
account for the semantics of "return everything that's been modified 
since..."

- James



From owner-atom-syntax@mail.imc.org  Thu Jun 16 21:15:56 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02638
	for <atompub-archive@lists.ietf.org>; Thu, 16 Jun 2005 21:15:55 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5H17iwc023232;
	Thu, 16 Jun 2005 18:07:44 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5H17iS8023230;
	Thu, 16 Jun 2005 18:07:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.25])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5H17UQu023001
	for <atom-syntax@imc.org>; Thu, 16 Jun 2005 18:07:33 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 17 Jun 2005 11:07:53 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Fri, 17 Jun 2005 11:07:25 +1000
Subject: Re: Atom feed synchronization
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BED85F6D.5F29D%eric.scheid@ironclad.net.au>
In-Reply-To: <42B2188D.5050402@gmail.com>
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>
Content-Transfer-Encoding: 7bit


On 17/6/05 10:25 AM, "James M Snell" <jasnell@gmail.com> wrote:

>> Something involving eTags would be the simplest from the client end.
>> 
>> 
> Agreed, but it seems to be a bit of a trick to figure out what that
> "something involvig eTags" could be ;-)
> 
> None of the existing HTTP Headers that involve etags would seem to
> account for the semantics of "return everything that's been modified
> since..."


http://www.google.com/search?q=atom+etags+diff+http&btnI=I%27m+Feeling+Lucky

RFC3229?

e.



From owner-atom-syntax@mail.imc.org  Thu Jun 16 22:11:03 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05298
	for <atompub-archive@lists.ietf.org>; Thu, 16 Jun 2005 22:11:03 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5H21LNb054148;
	Thu, 16 Jun 2005 19:01:21 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5H21L3X054147;
	Thu, 16 Jun 2005 19:01:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.pubsub.com (mail.pubsub.com [209.11.36.150])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5H21JCS054137
	for <atom-syntax@imc.org>; Thu, 16 Jun 2005 19:01:20 -0700 (PDT)
	(envelope-from bobwyman@pubsub.com)
Received: from mail.pubsub.com (PSRD112 [127.0.0.1])
	by mail.pubsub.com (Postfix) with SMTP id 84B50724E75;
	Thu, 16 Jun 2005 22:01:14 -0400 (EDT)
Received: from 68.174.167.137
        (SquirrelMail authenticated user bobwyman)
        by mail.pubsub.com with HTTP;
        Thu, 16 Jun 2005 22:01:14 -0400 (EDT)
Message-ID: <1287.68.174.167.137.1118973674.squirrel@mail.pubsub.com>
In-Reply-To: <42B2188D.5050402@gmail.com>
References: <BED8524A.5F22D%eric.scheid@ironclad.net.au>
    <42B2188D.5050402@gmail.com>
Date: Thu, 16 Jun 2005 22:01:14 -0400 (EDT)
Subject: Re: Atom feed synchronization
From: bobwyman@pubsub.com
To: "James M Snell" <jasnell@gmail.com>
Cc: "Eric Scheid" <eric.scheid@ironclad.net.au>, atom-syntax@imc.org
User-Agent: SquirrelMail/1.4.1
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3
Importance: Normal
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: 8bit


"James M Snell" <jasnell@gmail.com> wrote:
> Agreed, but it seems to be a bit of a trick to figure out what that
> "something involvig eTags" could be ;-)
>
> None of the existing HTTP Headers that involve etags would seem to
> account for the semantics of "return everything that's been modified
> since..."

Use RFC3229+feed. It does exactly what you want and already has
significant implementation history. See the links below for more info.

http://bobwyman.pubsub.com/main/2004/09/using_rfc3229_w.html

http://bobwyman.pubsub.com/main/2004/09/implementations.html

http://bobwyman.pubsub.com/main/2004/10/massive_bandwid.html

   bob wyman



From owner-atom-syntax@mail.imc.org  Thu Jun 16 23:23:59 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11850
	for <atompub-archive@lists.ietf.org>; Thu, 16 Jun 2005 23:23:58 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5H3GDci094384;
	Thu, 16 Jun 2005 20:16:13 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5H3GC5d094372;
	Thu, 16 Jun 2005 20:16:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.203])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5H3GBnV094194
	for <atom-syntax@imc.org>; Thu, 16 Jun 2005 20:16:11 -0700 (PDT)
	(envelope-from jasnell@gmail.com)
Received: by zproxy.gmail.com with SMTP id 13so194552nzp
        for <atom-syntax@imc.org>; Thu, 16 Jun 2005 20:16:06 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=m29hETAJlxmPiPXMvmm5/TjNd7XDatLNWlseDhizSxayNSRgqAsqUZ4RtDM4GFShnrldVwrkn+CkkDKsxtNpCEOGmWbaPdmliVqWmCZoXQYDQymZ5fes6sb5wI1/Td2++kC3Xcf2MbDQBdf4NOPNjqF5NswWh9nZel3EgQln6pE=
Received: by 10.36.74.16 with SMTP id w16mr1032713nza;
        Thu, 16 Jun 2005 20:16:05 -0700 (PDT)
Received: from ?192.168.1.103? ([67.181.223.222])
        by mx.gmail.com with ESMTP id 34sm1697648nza.2005.06.16.20.16.05;
        Thu, 16 Jun 2005 20:16:05 -0700 (PDT)
Message-ID: <42B2406F.4060707@gmail.com>
Date: Thu, 16 Jun 2005 20:15:59 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: bobwyman@pubsub.com, atom-syntax@imc.org
Subject: Re: Atom feed synchronization
References: <BED8524A.5F22D%eric.scheid@ironclad.net.au>    <42B2188D.5050402@gmail.com> <1287.68.174.167.137.1118973674.squirrel@mail.pubsub.com>
In-Reply-To: <1287.68.174.167.137.1118973674.squirrel@mail.pubsub.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


Nice. I had pulled out of the Atom discussions to work on another 
project back when this was being discussed and missed it. 

Quick question tho.. in your initial post on the concept you state "It 
is my intention to create a Internet Draft describing the ideas here 
once I've had reasonable time to receive comments from folk and work out 
the inevitable bugs"... has that effort progressed at all?  A quick I-D 
formally describing the +feed behavior would be helpful .

bobwyman@pubsub.com wrote:

>"James M Snell" <jasnell@gmail.com> wrote:
>  
>
>>Agreed, but it seems to be a bit of a trick to figure out what that
>>"something involvig eTags" could be ;-)
>>
>>None of the existing HTTP Headers that involve etags would seem to
>>account for the semantics of "return everything that's been modified
>>since..."
>>    
>>
>
>Use RFC3229+feed. It does exactly what you want and already has
>significant implementation history. See the links below for more info.
>
>http://bobwyman.pubsub.com/main/2004/09/using_rfc3229_w.html
>
>http://bobwyman.pubsub.com/main/2004/09/implementations.html
>
>http://bobwyman.pubsub.com/main/2004/10/massive_bandwid.html
>
>   bob wyman
>
>
>  
>



From owner-atom-syntax@mail.imc.org  Fri Jun 17 00:16:04 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18257
	for <atompub-archive@lists.ietf.org>; Fri, 17 Jun 2005 00:16:04 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5H47W1f027476;
	Thu, 16 Jun 2005 21:07:32 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5H47WJR027475;
	Thu, 16 Jun 2005 21:07:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.pubsub.com (mail.pubsub.com [209.11.36.150])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5H47Vxh027438
	for <atom-syntax@imc.org>; Thu, 16 Jun 2005 21:07:31 -0700 (PDT)
	(envelope-from bob@wyman.us)
Received: from IBMC101DE8DFED (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137])
	by mail.pubsub.com (Postfix) with ESMTP id 3A063724E7F;
	Fri, 17 Jun 2005 00:06:40 -0400 (EDT)
Message-ID: <005b01c572f1$f58de890$6600a8c0@IBMC101DE8DFED>
From: "Bob Wyman" <bob@wyman.us>
To: "James M Snell" <jasnell@gmail.com>, <atom-syntax@imc.org>
References: <BED8524A.5F22D%eric.scheid@ironclad.net.au>    <42B2188D.5050402@gmail.com> <1287.68.174.167.137.1118973674.squirrel@mail.pubsub.com> <42B2406F.4060707@gmail.com>
Subject: Re: Atom feed synchronization
Date: Fri, 17 Jun 2005 00:02:43 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2527
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
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: 7bit


James M Snell wrote:
> Nice. I had pulled out of the Atom discussions to work on another project 
> back when this was being discussed and missed it. Quick question tho.. in 
> your initial post on the concept you state "It is my intention to create a 
> Internet Draft describing the ideas here
    I do intend to write an Internet Draft, but I had been waiting to get 
some field experience before doing so. At this point, I guess I'm pretty 
sure it works as described. Many people have implemented RFC3229+feed and so 
far I've heard of no issues with it other than some folk who object on 
principle to RFC3229 itself. Other than waiting for field experience, the 
thing that has held me up is waiting for the working group to get far enough 
along with Atom so that I could propose that the Internet Draft be taken up 
here. Now that Atom V1.0 is almost in the can, I guess it is time to get the 
thing written...
    BTW: I think the "best" way to implement the application you describe is 
probably via a combination of Push and Pull. If you're updating as rapidly 
as you say you are, then it would make sense to push the updates to the 
client using something like "Atom over XMPP"[1]. You would, however, still 
generate Atom files and serve them using RFC3229+feed. The Atom files would 
be used by clients to "catch up" on missed messages when they initially 
connect or reconnect to the push stream after having been off-line for some 
time.
    The hybrid Push+Pull process described above is what we implement at 
PubSub for every subscription. We currently have this implemented in our 
PubSub Sidebars for IE and Firefox[2]. Also, the Gush reader from 2entwine 
implements this hybrid Push+Pull approach when reading our feeds.
    Push+Pull with Atom and Atom over XMPP gives you the best of both 
worlds. You get very efficient and low latency publishing of new entries to 
clients as well as efficient downloading of "catchup" files. What more could 
you want? :-)

    bob wyman

[1] http://www.xmpp.org/drafts/draft-saintandre-atompub-notify-02.html
[2] http://www.pubsub.com/downloads.php
[3] http://www.2entwine.com/features/pubsub.html





From owner-atom-syntax@mail.imc.org  Fri Jun 17 01:15:49 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21957
	for <atompub-archive@lists.ietf.org>; Fri, 17 Jun 2005 01:15:49 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5H56WQR071568;
	Thu, 16 Jun 2005 22:06:32 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5H56Wgq071567;
	Thu, 16 Jun 2005 22:06:32 -0700 (PDT)
X-Authentication-Warning: above.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.51])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5H56V6D071554
	for <atom-syntax@imc.org>; Thu, 16 Jun 2005 22:06:31 -0700 (PDT)
	(envelope-from ho@alum.mit.edu)
Received: from localhost.localdomain (rfb.rfburst.com [66.119.143.249])
	by mail.rfburst.com (8.12.8/8.12.8) with ESMTP id j5H56Lma007088;
	Thu, 16 Jun 2005 23:06:21 -0600
Received: from localhost.localdomain (tobermory [127.0.0.1])
	by localhost.localdomain (8.12.10/8.11.6) with ESMTP id j5H47XeI021506;
	Thu, 16 Jun 2005 22:07:33 -0600
Received: (from ho@localhost)
	by localhost.localdomain (8.12.10/8.12.10/Submit) id j5H47Wgk021502;
	Thu, 16 Jun 2005 22:07:32 -0600
Date: Thu, 16 Jun 2005 22:07:32 -0600
Message-Id: <200506170407.j5H47Wgk021502@localhost.localdomain>
From: "The Purple Streak, Hilarie Orman" <ho@alum.mit.edu>
To: jasnell@gmail.com
Cc: atom-syntax@imc.org
In-reply-to: Yourmessage <42B1CB81.3060101@gmail.com>
Subject: Re: More on Atom XML signatures and encryption
X-esmartscan-MailScanner-Information: Please contact the ISP for more information
X-esmartscan-MailScanner: Found to be clean
X-MailScanner-From: ho@alum.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>


I didn't see any requirement to encrypt feeds.

Please note my email re keyinfo and identification of signer from a few
weeks ago.

Hilarie Orman



From owner-atom-syntax@mail.imc.org  Fri Jun 17 01:23:49 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22285
	for <atompub-archive@lists.ietf.org>; Fri, 17 Jun 2005 01:23:48 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5H5FBXZ079817;
	Thu, 16 Jun 2005 22:15:11 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5H5FBLu079816;
	Thu, 16 Jun 2005 22:15:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231])
	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5H5F9gK079790
	for <atom-syntax@imc.org>; Thu, 16 Jun 2005 22:15:10 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: <p0621025dbed80c5c0f0c@[10.20.30.249]>
In-Reply-To: <42B1EE41.9030304@gmail.com>
References: <1118943858.9048.6.camel@marge> <42B1CB81.3060101@gmail.com>
 <42B1CF84.5040508@dehora.net> <42B1EE41.9030304@gmail.com>
Date: Thu, 16 Jun 2005 22:15:05 -0700
To: atom-syntax@imc.org
From: Paul Hoffman <phoffman@imc.org>
Subject: Re: More on Atom XML signatures and 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>


At 2:25 PM -0700 6/16/05, James M Snell wrote:
>So perhaps we should limit XML encryption to
>
>    a) The entire feed
>    b) individual entries and
>    c) the content of content elements. (examples 2, 4 and 5 in my 
>original note).

Or less. Sections 5.1 and 5.2 of the current spec clearly only cover 
1 and 2. Going beneath that is outside the spec, and likely to be 
ignored by implementers.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Fri Jun 17 06:07:45 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01286
	for <atompub-archive@lists.ietf.org>; Fri, 17 Jun 2005 06:07:44 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5H9tNHM084408;
	Fri, 17 Jun 2005 02:55:23 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5H9tNPS084407;
	Fri, 17 Jun 2005 02:55:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.gmx.net (pop.gmx.de [213.165.64.20])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j5H9tL0d084360
	for <atom-syntax@imc.org>; Fri, 17 Jun 2005 02:55:22 -0700 (PDT)
	(envelope-from pagaltzis@gmx.de)
Received: (qmail invoked by alias); 17 Jun 2005 09:55:14 -0000
Received: from xdsl-213-196-244-117.netcologne.de (EHLO klangraum) [213.196.244.117]
  by mail.gmx.net (mp016) with SMTP; 17 Jun 2005 11:55:14 +0200
X-Authenticated: #163624
Date: Fri, 17 Jun 2005 11:59:20 +0200
From: "A. Pagaltzis" <pagaltzis@gmx.de>
To: atom-syntax@imc.org
Subject: Re: feed or entry
Message-ID: <20050617095920.GA22352@klangraum>
Mail-Followup-To: atom-syntax@imc.org
References: <20050616190906.73140.qmail@web42208.mail.yahoo.com> <1118951548.9048.27.camel@marge>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1118951548.9048.27.camel@marge>
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: 8bit


* Dave Pawson <davep@dpawson.co.uk> [2005-06-16 22:05]:
> Process. I write an instance. document element is a:feed.
> 
> Each successive day (or thereabouts) I write an entry. I'm
> processing via XSLT.
> 
> I don't want a single monolith of a file, so I'm writing daily
> using a document element of a:entry.
> 
> The end product is an 'empty' a:feed element (i.e. no entry
> children) and 101 orphan a:entry instances, each with a days
> content.

I’m not sure I understand what you’re talking about, but would it
be a possibility to use the XPath document() function to slurp
the atom:entry documents into the atom:feed document using a
stylesheet? This is how my own blog works.

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



From owner-atom-syntax@mail.imc.org  Fri Jun 17 09:57:10 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18914
	for <atompub-archive@lists.ietf.org>; Fri, 17 Jun 2005 09:57:10 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5HDosmM053859;
	Fri, 17 Jun 2005 06:50:54 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5HDosFa053855;
	Fri, 17 Jun 2005 06:50:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail06.svc.cra.dublin.eircom.net (mail06.svc.cra.dublin.eircom.net [159.134.118.22])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j5HDorIg053752
	for <atom-syntax@imc.org>; Fri, 17 Jun 2005 06:50:53 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 94959 messnum 2890268 invoked from network[83.70.250.40/83-70-250-40.b-ras1.prp.dublin.eircom.net]); 17 Jun 2005 13:50:47 -0000
Received: from 83-70-250-40.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.250.40)
  by mail06.svc.cra.dublin.eircom.net (qp 94959) with SMTP; 17 Jun 2005 13:50:47 -0000
Message-ID: <42B2D536.80908@dehora.net>
Date: Fri, 17 Jun 2005 14:50:46 +0100
From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: James M Snell <jasnell@gmail.com>
CC: atom-syntax@imc.org
Subject: Re: Atom feed synchronization
References: <p0621024ebed78efa2b25@[10.20.30.249]> <42B1FF1A.2070202@gmail.com>
In-Reply-To: <42B1FF1A.2070202@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


James M Snell wrote:
> 
> Ok, question for the group.
> 
> Scenario: A content source is updated 100 times per hour.  The Atom feed 
> currently only displays the 20 most recent entries.  Users who are not 
> checking the feed every 10 minutes or so are missing entries.  How do we 
> address this?
> 
> Solution: Rather than using a feed with a fixed number of entries, 
> provide a mechanism that allows users to specify the last time they 
> retrieved the feed and have the feed return all entries added since that 
> time.
> 
> Question: What is the best way to provide that mechanism: querystring 
> parameter or HTTP header or some other way I'm not thinking of
> 
>    http://...?last-retrieved=12345
> 
> OR
> 
>   GET ... HTTP/1.1
>   Host: ...
>   Last-Retrieved: 12345


We found shared time imprecise enough, and other workarounds over HTTP 
complex enough, that to solve this problem (must get all entires) we 
pushed the feed out using XMPP. All the technical problems I saw then 
came down to inconsistent rates of change. The simplest answer was to 
get rid of HTTP and use XMPP.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Fri Jun 17 10:00:08 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19175
	for <atompub-archive@lists.ietf.org>; Fri, 17 Jun 2005 10:00:07 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5HDnXn6052189;
	Fri, 17 Jun 2005 06:49:33 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5HDnXah052188;
	Fri, 17 Jun 2005 06:49:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail03.svc.cra.dublin.eircom.net (mail03.svc.cra.dublin.eircom.net [159.134.118.19])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j5HDnVt2052028
	for <atom-syntax@imc.org>; Fri, 17 Jun 2005 06:49:32 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 11081 messnum 279494 invoked from network[83.70.250.40/83-70-250-40.b-ras1.prp.dublin.eircom.net]); 17 Jun 2005 13:49:25 -0000
Received: from 83-70-250-40.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.250.40)
  by mail03.svc.cra.dublin.eircom.net (qp 11081) with SMTP; 17 Jun 2005 13:49:25 -0000
Message-ID: <42B2D4E3.5070503@dehora.net>
Date: Fri, 17 Jun 2005 14:49:23 +0100
From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Antone Roundy <antone@geckotribe.com>
CC: atom-syntax@imc.org
Subject: Re: Atom feed synchronization
References: <BDDD26C5-DEBD-11D9-B067-003065EA6144@geckotribe.com>
In-Reply-To: <BDDD26C5-DEBD-11D9-B067-003065EA6144@geckotribe.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


Antone Roundy wrote:
> 
> On Thursday, June 16, 2005, at 04:37  PM, James M Snell wrote:
> 
>> Scenario: A content source is updated 100 times per hour.  The Atom 
>> feed currently only displays the 20 most recent entries.  Users who 
>> are not checking the feed every 10 minutes or so are missing entries.  
>> How do we address this?
> 
> 
> 1) Tell users to poll more frequently--if they don't, that's their problem

Doesn't solve the problem, probably makes things worse.


> 2) Make the feed longer than 20 entries

Same as 1)

> 2a) If the feed is SOMETIMES updated 100 times per hour, but sometimes 
> only twice per hour, dynamically set the feed length--when regenerating 
> the feed, include all entries updated in the last hour or so, down to 
> some minimum number

Same as 2)

> 3) Push instead of pull

This works.

> 4) Create a new link @rel to point to the next X entries and keep a 
> series of static documents containing the older entries

Might work, but requires at least as much extra mechanism as a query param.


cheers
Bill



From owner-atom-syntax@mail.imc.org  Fri Jun 17 10:14:23 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20986
	for <atompub-archive@lists.ietf.org>; Fri, 17 Jun 2005 10:14:23 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5HE5Kgw072155;
	Fri, 17 Jun 2005 07:05:20 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5HE5KXi072154;
	Fri, 17 Jun 2005 07:05:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from bblfish.net (bblfish.net [192.220.66.168])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5HE5KPn072148
	for <atom-syntax@imc.org>; Fri, 17 Jun 2005 07:05:20 -0700 (PDT)
	(envelope-from henry.story@bblfish.net)
Received: (qmail 53170 invoked by uid 17064); 17 Jun 2005 14:05:19 -0000
Received: from unknown (HELO [192.168.0.3]) ([83.112.233.21])
          (envelope-sender <henry.story@bblfish.net>)
          by 192.220.66.168 (qmail-ldap-1.03) with SMTP
          for <atom-syntax@imc.org>; 17 Jun 2005 14:05:19 -0000
In-Reply-To: <42B1FF1A.2070202@gmail.com>
References: <p0621024ebed78efa2b25@[10.20.30.249]> <42B1FF1A.2070202@gmail.com>
Mime-Version: 1.0 (Apple Message framework v730)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <79147645-2FBC-427B-9C8A-874572208FEA@bblfish.net>
Cc: atom-syntax@imc.org
Content-Transfer-Encoding: 7bit
From: Henry Story <henry.story@bblfish.net>
Subject: Re: Atom feed synchronization
Date: Fri, 17 Jun 2005 16:05:13 +0200
To: James M Snell <jasnell@gmail.com>
X-Mailer: Apple Mail (2.730)
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: 7bit


The best solution is just to add a link types to the atom syntax:  a  
link to the previous feed document that points to the next bunch of  
entries. IE. do what web sites do. If you can't find your answer on  
the first page, go look at the next page.

How do you know when to stop? If the pages are ordered  
chronologically, the client will know to stop
when he has come to a page with entries with update times before the  
date he last looked.

This is:

     - simple,
     - easy to see (no need to look at invisible header fields),
     - easy to understand (no need to read another complicated rfc  
document)
     - easy to implement (well it so simple)
     - low tech (you don't need anything more than a server  
supporting http)


Henry


On 17 Jun 2005, at 00:37, James M Snell wrote:
>
> Ok, question for the group.
>
> Scenario: A content source is updated 100 times per hour.  The Atom  
> feed currently only displays the 20 most recent entries.  Users who  
> are not checking the feed every 10 minutes or so are missing  
> entries.  How do we address this?
>
> Solution: Rather than using a feed with a fixed number of entries,  
> provide a mechanism that allows users to specify the last time they  
> retrieved the feed and have the feed return all entries added since  
> that time.
>
> Question: What is the best way to provide that mechanism:  
> querystring parameter or HTTP header or some other way I'm not  
> thinking of
>
>    http://...?last-retrieved=12345
>
> OR
>
>   GET ... HTTP/1.1
>   Host: ...
>   Last-Retrieved: 12345
>
> - James
>



From owner-atom-syntax@mail.imc.org  Fri Jun 17 10:20:59 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22287
	for <atompub-archive@lists.ietf.org>; Fri, 17 Jun 2005 10:20:58 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5HE4uC9071744;
	Fri, 17 Jun 2005 07:04:56 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5HE4ujd071743;
	Fri, 17 Jun 2005 07:04:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from bork.markbaker.ca (static-80-155.dsl.cuic.ca [216.126.80.155] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5HE4tGH071733
	for <atom-syntax@imc.org>; Fri, 17 Jun 2005 07:04:55 -0700 (PDT)
	(envelope-from distobj@acm.org)
Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian))
	id 1DjHTa-0000YI-00; Fri, 17 Jun 2005 10:05:42 -0400
Date: Fri, 17 Jun 2005 10:05:42 -0400
From: Mark Baker <distobj@acm.org>
To: duerst@it.aoyama.ac.jp
Cc: ans208@mail.usask.ca, atom-syntax@imc.org
Subject: Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
Message-ID: <20050617140542.GX20401@markbaker.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.6+20040907i
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>


Martin,

> The general idea seems to be that conversion to HTML is good for
> human consumption with a browser, and for human navigation in an
> archive. message/rfc822 is the original, and may be very good for
> reuse in a mailer (e.g. for replying), except that mailers don't
> support it much at the moment.
> 
> <atom:content type="message/rfc822"
> src="http://www.example.org/lists/list/archive/12345"/>

Unfortunately, that's bad Atom.  Section 4.1.3.1 of the format spec
says;

  On the atom:content element, the value of the "type" attribute MAY be
  one of "text", "html", or "xhtml".  Failing that, it MUST be a MIME
  media type, but MUST NOT be a composite type (see Section 4.2.6 of
  [MIMEREG]).  If the type attribute is not provided, Atom Processors
  MUST behave as though it were present with a value of "text".

where "composite type" is defined to be multipart/* and message/*.  If
the intent of that restriction was to avoid the whole non-XML
attachments issue, then it seems to have failed to account for the use
of the "src" attribute to include the data by reference rather than by
value.

I'm sorry that I didn't notice this earlier. 8-(

Mark.
-- 
Mark Baker.  Ottawa, Ontario, CANADA.          http://www.markbaker.ca
Coactus; Web-inspired integration strategies   http://www.coactus.com



From owner-atom-syntax@mail.imc.org  Fri Jun 17 12:06:26 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00606
	for <atompub-archive@lists.ietf.org>; Fri, 17 Jun 2005 12:06:26 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5HFwZ30092707;
	Fri, 17 Jun 2005 08:58:35 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5HFwZNU092702;
	Fri, 17 Jun 2005 08:58:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.199])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5HFwWI8092608
	for <atom-syntax@imc.org>; Fri, 17 Jun 2005 08:58:34 -0700 (PDT)
	(envelope-from jasnell@gmail.com)
Received: by zproxy.gmail.com with SMTP id 40so580543nzk
        for <atom-syntax@imc.org>; Fri, 17 Jun 2005 08:58:26 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=VW8VqvuPtf54VSrRvLoMhKuDsEFRqghh7quD+QFaETG9IduNXH90GyOAVZiFkoW54LDJsUtOUhzo3H3bMXx+UIywpGEqhA14s564PbrC7HuHJWqLYgWKC0/7phRdrGATxGoG6MlpqDtpHGzKiYZgID+p1dIJn82ZahevKQQrixU=
Received: by 10.36.43.9 with SMTP id q9mr1402245nzq;
        Fri, 17 Jun 2005 08:58:26 -0700 (PDT)
Received: from ?192.168.1.103? ([67.181.223.222])
        by mx.gmail.com with ESMTP id 39sm2740093nzk.2005.06.17.08.58.26;
        Fri, 17 Jun 2005 08:58:26 -0700 (PDT)
Message-ID: <42B2F31B.6020709@gmail.com>
Date: Fri, 17 Jun 2005 08:58:19 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Hoffman <phoffman@imc.org>, atom-syntax@imc.org
Subject: Re: More on Atom XML signatures and encryption
References: <1118943858.9048.6.camel@marge> <42B1CB81.3060101@gmail.com> <42B1CF84.5040508@dehora.net> <42B1EE41.9030304@gmail.com> <p0621025dbed80c5c0f0c@[10.20.30.249]>
In-Reply-To: <p0621025dbed80c5c0f0c@[10.20.30.249]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


The plus side to the third option is that it is really no different than 
an Atom feed that uses content payloads of any other arbitrary XML media 
type (section 4.1.3.3 item #4).  The current spec is silent on what an 
Atom implementer needs to do with content media types that they don't 
understand.

Paul Hoffman wrote:

>
> At 2:25 PM -0700 6/16/05, James M Snell wrote:
>
>> So perhaps we should limit XML encryption to
>>
>>    a) The entire feed
>>    b) individual entries and
>>    c) the content of content elements. (examples 2, 4 and 5 in my 
>> original note).
>
>
> Or less. Sections 5.1 and 5.2 of the current spec clearly only cover 1 
> and 2. Going beneath that is outside the spec, and likely to be 
> ignored by implementers.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium
>
>



From owner-atom-syntax@mail.imc.org  Fri Jun 17 13:21:23 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06110
	for <atompub-archive@lists.ietf.org>; Fri, 17 Jun 2005 13:21:23 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5HHEWYA071494;
	Fri, 17 Jun 2005 10:14:32 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5HHEVS5071485;
	Fri, 17 Jun 2005 10:14:31 -0700 (PDT)
X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j5HHES7x071433
	for <atom-syntax@imc.org>; Fri, 17 Jun 2005 10:14:28 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j5HHESqg004523
	for <atom-syntax@imc.org>; Fri, 17 Jun 2005 11:14:28 -0600 (MDT)
Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004))
 with ESMTP id <0II800BDGNW3TV@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Fri, 17 Jun 2005 11:14:28 -0600 (MDT)
Received: from [192.168.102.100] ([154.20.140.182])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004))
 with ESMTPSA id <0II80090CNW2KH@mail.sun.net> for atom-syntax@imc.org; Fri,
 17 Jun 2005 11:14:27 -0600 (MDT)
Date: Fri, 17 Jun 2005 10:14:38 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Question on Use Case: Choosing atom:content's type when
 ArchivingMailing Lists
In-reply-to: <20050617140542.GX20401@markbaker.ca>
To: Mark Baker <distobj@acm.org>
Cc: duerst@it.aoyama.ac.jp, ans208@mail.usask.ca, atom-syntax@imc.org
Message-id: <2E68D5C0-189B-4FCC-9D6F-201F28FC2A58@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.730)
Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Content-transfer-encoding: 7BIT
References: <20050617140542.GX20401@markbaker.ca>
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: 7BIT


Uh, has Mark spotted a dumb bug here that we should fix?  Do we care  
if *remote* content is of a composite MIME type?  My feeling was that  
we ruled out composite types in *local* content, for fairly obvious  
reasons.  The fix is obvious, in 4.1.3.1

"Failing that, it MUST be a MIME media type.  If the "src" attribute  
is not provided, i.e. the content is local, the value of the "type"  
attribute MUST NOT be a composite type... "

-Tim

On Jun 17, 2005, at 7:05 AM, Mark Baker wrote:

>> <atom:content type="message/rfc822"
>> src="http://www.example.org/lists/list/archive/12345"/>
>
> Unfortunately, that's bad Atom.  Section 4.1.3.1 of the format spec
> says;
>
>   On the atom:content element, the value of the "type" attribute  
> MAY be
>   one of "text", "html", or "xhtml".  Failing that, it MUST be a MIME
>   media type, but MUST NOT be a composite type (see Section 4.2.6 of
>   [MIMEREG]).  If the type attribute is not provided, Atom Processors
>   MUST behave as though it were present with a value of "text".
>
> where "composite type" is defined to be multipart/* and message/*.  If
> the intent of that restriction was to avoid the whole non-XML
> attachments issue, then it seems to have failed to account for the use
> of the "src" attribute to include the data by reference rather than by
> value.





From owner-atom-syntax@mail.imc.org  Fri Jun 17 14:08:50 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09059
	for <atompub-archive@lists.ietf.org>; Fri, 17 Jun 2005 14:08:49 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5HI1rTw023177;
	Fri, 17 Jun 2005 11:01:53 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5HI1rgl023176;
	Fri, 17 Jun 2005 11:01:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5HI1qip023140
	for <atom-syntax@imc.org>; Fri, 17 Jun 2005 11:01:53 -0700 (PDT)
	(envelope-from jasnell@gmail.com)
Received: by zproxy.gmail.com with SMTP id 9so1163893nzo
        for <atom-syntax@imc.org>; Fri, 17 Jun 2005 11:01:47 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=Bw2M5YJz9ggP4XWa3yyqJq8ksxzWg00+mwC8cIgNFbSX9iyeLngjcBjoO6InDmPWIsJECIvRmMtUK65t/v9B32mhocEZUmaPnzmsBuQJrjGxISMOP6NYS1/hSK/NJQBR1xZ+S39GQjFjcN1nksjwhApPjC7ss+l6ClgF9F04zug=
Received: by 10.36.38.18 with SMTP id l18mr1497804nzl;
        Fri, 17 Jun 2005 11:01:46 -0700 (PDT)
Received: from ?192.168.1.103? ([67.181.223.222])
        by mx.gmail.com with ESMTP id 12sm1949490nzn.2005.06.17.11.01.46;
        Fri, 17 Jun 2005 11:01:46 -0700 (PDT)
Message-ID: <42B31003.70609@gmail.com>
Date: Fri, 17 Jun 2005 11:01:39 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tim Bray <Tim.Bray@Sun.COM>
CC: atom-syntax@imc.org
Subject: Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing
 Lists
References: <20050617140542.GX20401@markbaker.ca> <2E68D5C0-189B-4FCC-9D6F-201F28FC2A58@sun.com>
In-Reply-To: <2E68D5C0-189B-4FCC-9D6F-201F28FC2A58@sun.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


Appears that way.  +1 to making composite types in remote content legal. 

Another question while we're discussing this part of the spec (stemming 
from the XML Enc discussion):  currently there appears to be no language 
about what should happen if an Atom processor encounters a content media 
type that it doesn't understand.  Should it ignore the content? Does it 
report an error?  Should it try to process the content somehow (e.g. 
defer to some external processor)? 

Tim Bray wrote:

>
> Uh, has Mark spotted a dumb bug here that we should fix?  Do we care  
> if *remote* content is of a composite MIME type?  My feeling was that  
> we ruled out composite types in *local* content, for fairly obvious  
> reasons.  The fix is obvious, in 4.1.3.1
>
> "Failing that, it MUST be a MIME media type.  If the "src" attribute  
> is not provided, i.e. the content is local, the value of the "type"  
> attribute MUST NOT be a composite type... "
>
> -Tim
>
> On Jun 17, 2005, at 7:05 AM, Mark Baker wrote:
>
>>> <atom:content type="message/rfc822"
>>> src="http://www.example.org/lists/list/archive/12345"/>
>>
>>
>> Unfortunately, that's bad Atom.  Section 4.1.3.1 of the format spec
>> says;
>>
>>   On the atom:content element, the value of the "type" attribute  MAY be
>>   one of "text", "html", or "xhtml".  Failing that, it MUST be a MIME
>>   media type, but MUST NOT be a composite type (see Section 4.2.6 of
>>   [MIMEREG]).  If the type attribute is not provided, Atom Processors
>>   MUST behave as though it were present with a value of "text".
>>
>> where "composite type" is defined to be multipart/* and message/*.  If
>> the intent of that restriction was to avoid the whole non-XML
>> attachments issue, then it seems to have failed to account for the use
>> of the "src" attribute to include the data by reference rather than by
>> value.
>
>
>
>
>



From owner-atom-syntax@mail.imc.org  Fri Jun 17 14:17:09 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09500
	for <atompub-archive@lists.ietf.org>; Fri, 17 Jun 2005 14:17:09 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5HI3j78024992;
	Fri, 17 Jun 2005 11:03:46 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5HI3iMZ024989;
	Fri, 17 Jun 2005 11:03:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.25])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5HI3gx2024914
	for <atom-syntax@imc.org>; Fri, 17 Jun 2005 11:03:43 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 18 Jun 2005 04:04:08 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sat, 18 Jun 2005 04:03:37 +1000
Subject: Re: Question on Use Case: Choosing atom:content's type when
	ArchivingMailing Lists
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BED94D99.5F4EB%eric.scheid@ironclad.net.au>
In-Reply-To: <2E68D5C0-189B-4FCC-9D6F-201F28FC2A58@sun.com>
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>
Content-Transfer-Encoding: 7bit


On 18/6/05 3:14 AM, "Tim Bray" <Tim.Bray@Sun.COM> wrote:

> 
> Uh, has Mark spotted a dumb bug here that we should fix?  Do we care
> if *remote* content is of a composite MIME type?  My feeling was that
> we ruled out composite types in *local* content, for fairly obvious
> reasons.  The fix is obvious, in 4.1.3.1
> 
> "Failing that, it MUST be a MIME media type.  If the "src" attribute
> is not provided, i.e. the content is local, the value of the "type"
> attribute MUST NOT be a composite type... "

+1



From owner-atom-syntax@mail.imc.org  Fri Jun 17 14:27:50 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10433
	for <atompub-archive@lists.ietf.org>; Fri, 17 Jun 2005 14:27:49 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5HIGqTF040305;
	Fri, 17 Jun 2005 11:16:52 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5HIGqNa040304;
	Fri, 17 Jun 2005 11:16:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5HIGp3H040282
	for <atom-syntax@imc.org>; Fri, 17 Jun 2005 11:16:51 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from [192.168.1.101] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65])
	(authenticated bits=0)
	by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j5HIJIrZ031187;
	Fri, 17 Jun 2005 14:19:18 -0400
Message-ID: <42B31392.2080207@intertwingly.net>
Date: Fri, 17 Jun 2005 14:16:50 -0400
From: Sam Ruby <rubys@intertwingly.net>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tim Bray <Tim.Bray@Sun.COM>
CC: atom-syntax@imc.org
Subject: Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing
 Lists
References: <20050617140542.GX20401@markbaker.ca> <2E68D5C0-189B-4FCC-9D6F-201F28FC2A58@sun.com>
In-Reply-To: <2E68D5C0-189B-4FCC-9D6F-201F28FC2A58@sun.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


Tim Bray wrote:
> 
> Uh, has Mark spotted a dumb bug here that we should fix?  Do we care  if 
> *remote* content is of a composite MIME type?  My feeling was that  we 
> ruled out composite types in *local* content, for fairly obvious  
> reasons.  The fix is obvious, in 4.1.3.1
> 
> "Failing that, it MUST be a MIME media type.  If the "src" attribute  is 
> not provided, i.e. the content is local, the value of the "type"  
> attribute MUST NOT be a composite type... "

I have no objection, but I will point out that for the forseeable future 
the number of tools that are likely to support this is likely to be 
vanishingly small.

- Sam Ruby

> -Tim
> 
> On Jun 17, 2005, at 7:05 AM, Mark Baker wrote:
> 
>>> <atom:content type="message/rfc822"
>>> src="http://www.example.org/lists/list/archive/12345"/>
>>
>>
>> Unfortunately, that's bad Atom.  Section 4.1.3.1 of the format spec
>> says;
>>
>>   On the atom:content element, the value of the "type" attribute  MAY be
>>   one of "text", "html", or "xhtml".  Failing that, it MUST be a MIME
>>   media type, but MUST NOT be a composite type (see Section 4.2.6 of
>>   [MIMEREG]).  If the type attribute is not provided, Atom Processors
>>   MUST behave as though it were present with a value of "text".
>>
>> where "composite type" is defined to be multipart/* and message/*.  If
>> the intent of that restriction was to avoid the whole non-XML
>> attachments issue, then it seems to have failed to account for the use
>> of the "src" attribute to include the data by reference rather than by
>> value.
> 
> 
> 
> 



From owner-atom-syntax@mail.imc.org  Fri Jun 17 14:38:29 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11550
	for <atompub-archive@lists.ietf.org>; Fri, 17 Jun 2005 14:38:28 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5HIWqJi059478;
	Fri, 17 Jun 2005 11:32:52 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5HIWq1Z059472;
	Fri, 17 Jun 2005 11:32:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.pubsub.com (mail.pubsub.com [209.11.36.150])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5HIWoLb059350
	for <atom-syntax@imc.org>; Fri, 17 Jun 2005 11:32:51 -0700 (PDT)
	(envelope-from bobwyman@pubsub.com)
Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34])
	(using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by mail.pubsub.com (Postfix) with ESMTP id AA0DC72521B;
	Fri, 17 Jun 2005 14:32:44 -0400 (EDT)
Reply-To: <bobwyman@pubsub.com>
From: "Bob Wyman" <bobwyman@pubsub.com>
To: "'Henry Story'" <henry.story@bblfish.net>,
        "'James M Snell'" <jasnell@gmail.com>
Cc: <atom-syntax@imc.org>
Subject: Polling Sucks! (was RE: Atom feed synchronization)
Date: Fri, 17 Jun 2005 14:32:41 -0400
Organization: PubSub Concepts, Inc.
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <79147645-2FBC-427B-9C8A-874572208FEA@bblfish.net>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Thread-Index: AcVzR/A3N4R4kbKLS66CgVHLwM0KjAAIJ3lg
Message-Id: <20050617183244.AA0DC72521B@mail.pubsub.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>
Content-Transfer-Encoding: 7bit


Henry Story wrote:
> The best solution is just to add a link types to the atom syntax:
> a link to the previous feed document that points to the next bunch of
> entries. IE. do what web sites do. If you can't find your answer on
> the first page, go look at the next page.
> How do you know when to stop? If the pages are ordered  
> chronologically, the client will know to stop when he has come to a page
> with entries with update times before the date he last looked.

	This is *not* simpler than taking a push feed using Atom over XMPP.
For a push feed, all you do is:
	1. Open a socket
	2. Send a "login" XML Stanza
	3. Process the stanzas as they arrive.

	For your solution, you need to:
	1. Poll the feed to get a pointer to the "first link". (each poll
will cost you a TCP/IP connection).
	2. If you got a new "first link" then go to step 5
	3. Wait some period of time (the polling interval)
	4. GoTo Step 1
	5. Open a new TCP/IP socket to get the next link
	6. Form and send an HTTP request for the next entry
	7. Catch the response from the server
	8. Parse the response to determine if its time stamp is something
you've already seen.
	9. If you haven't seen the current entry before, then go to step 5
	10. Go to step 1 to start over.
	(Note: I've eliminated and compressed a few steps to avoid more
typing... An actual implementation would be more complex than I describe
above.)

	Your solution is more complex and generates much more network
traffic (i.e. because of polling the feed, repeatedly opening new TCP/IP
connections with all the traditional "slow start" overhead, and requesting
each "next link"). Additionally, you end up with reduced latency since the
age of any entry you discover will be, on average, half that of your polling
frequency plus some latency introduced by link following. (Yes, you could
rely on continuous connections and thus remove the overhead of creating so
many TCP/IP connections, however, at that point, you might as well have a
continuous push socket open...)
	The push solution conserves network bandwidth, delivers data with
much less latency and is simpler to implement. 
	Polling sucks! (that was a pun...)

		bob wyman




From owner-atom-syntax@mail.imc.org  Fri Jun 17 14:59:14 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13109
	for <atompub-archive@lists.ietf.org>; Fri, 17 Jun 2005 14:59:14 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5HIquog081707;
	Fri, 17 Jun 2005 11:52:56 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5HIquJ4081699;
	Fri, 17 Jun 2005 11:52:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.gmx.net (pop.gmx.de [213.165.64.20])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j5HIqs2j081577
	for <atom-syntax@imc.org>; Fri, 17 Jun 2005 11:52:55 -0700 (PDT)
	(envelope-from pagaltzis@gmx.de)
Received: (qmail invoked by alias); 17 Jun 2005 18:52:48 -0000
Received: from xdsl-213-196-240-10.netcologne.de (EHLO klangraum) [213.196.240.10]
  by mail.gmx.net (mp018) with SMTP; 17 Jun 2005 20:52:48 +0200
X-Authenticated: #163624
Date: Fri, 17 Jun 2005 20:56:54 +0200
From: "A. Pagaltzis" <pagaltzis@gmx.de>
To: atom-syntax@imc.org
Subject: Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
Message-ID: <20050617185654.GA20938@klangraum>
Mail-Followup-To: atom-syntax@imc.org
References: <20050617140542.GX20401@markbaker.ca> <2E68D5C0-189B-4FCC-9D6F-201F28FC2A58@sun.com> <42B31003.70609@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <42B31003.70609@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: 8bit


* James M Snell <jasnell@gmail.com> [2005-06-17 20:15]:
> currently there appears to be no language about what should
> happen if an Atom processor encounters a content media type
> that it doesn't understand.  Should it ignore the content? Does
> it report an error?  Should it try to process the content
> somehow (e.g. defer to some external processor)? 

The spec is supposed to explain what the bits means, but not to
tell anyone what to do with them, so there’s nothing it can
really mandate here. Certainly it can’t usefully *enforce*
anything.

This might be something that the implementor’s guide should
contain recommendations for. But even then, I don’t think that
doing more than suggesting a few best practices for a handful
of situations is feasible.

I expect that many newsreaders will simply ignore things they
don’t understand.

Personally, in the aggregator I occasionally work on, I plan to
pass the data to a whatever application the user’s mailcap says
is responsible for it. (I suppose you’d use the registry in
Windows; I don’t know what mechanism OS X provides.)

On the other hand, many scenarios will (hopefully!) involve Atom
feeds intended solely for consumption by machines rather humans.
I imagine that in at least a few of those, unexpected content
types should set off alarms.

So I don’t think there is any one course of action that we can
recommend for everyone; let alone mandate, if such a thing even
was in the scope of the spec. The best we could do is to
informally suggest certain practices for certain situations. (I’d
like to see desktop aggregators widely support what I am planning
to do with mine, f.ex; then putting stuff other than HTML in
feeds would have a chance to catch on.) And that too is probably
something the guide should do, not the spec.

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



From owner-atom-syntax@mail.imc.org  Fri Jun 17 15:05:38 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13869
	for <atompub-archive@lists.ietf.org>; Fri, 17 Jun 2005 15:05:36 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5HIrgaO082598;
	Fri, 17 Jun 2005 11:53:42 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5HIrgtD082597;
	Fri, 17 Jun 2005 11:53:42 -0700 (PDT)
X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j5HIrfqJ082577
	for <atom-syntax@imc.org>; Fri, 17 Jun 2005 11:53:41 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from phys-bur-1 ([129.148.9.72])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j5HIrfqg014827
	for <atom-syntax@imc.org>; Fri, 17 Jun 2005 12:53:41 -0600 (MDT)
Received: from conversion-daemon.bur-mail1.east.sun.com by
 bur-mail1.east.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003))
 id <0II800001SHGRA@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com)
 for atom-syntax@imc.org; Fri, 17 Jun 2005 14:53:41 -0400 (EDT)
Received: from localhost (vpn-129-150-35-42.Central.Sun.COM [129.150.35.42])
 by bur-mail1.east.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003))
 with ESMTP id <0II80023WSHGL5@bur-mail1.east.sun.com> for atom-syntax@imc.org;
 Fri, 17 Jun 2005 14:53:41 -0400 (EDT)
Received: from ndw by localhost with local (Exim 4.50)
	id 1DjLyE-0001CN-VL	for atom-syntax@imc.org; Fri, 17 Jun 2005 14:53:38 -0400
X-URL: http://nwalsh.com/
Date: Fri, 17 Jun 2005 14:53:38 -0400
From: Norman Walsh <ndw@nwalsh.com>
Subject: Re: Review of Section 6
In-reply-to: <1118334135.42a86cb733d81@webmail.djpowell.net>
To: atom-syntax@imc.org
Message-id: <87oea4g6h9.fsf@nwalsh.com>
MIME-version: 1.0
Content-type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1;
 protocol="application/pgp-signature"
User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)
References: <1118334135.42a86cb733d81@webmail.djpowell.net>
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-Type: text/plain
Content-Transfer-Encoding: quoted-printable

/ David Powell <djpowell@djpowell.net> was heard to say:
| a) Section 6.4 omits atom:source as a valid location for Metadata Extensi=
ons,
| but it is allowed by the RelaxNG in 4.2.11.  I believe that the RelaxNG
| reflects our intent to allow extensions to be preserved in atom:source.

That seems reasonable to me. I'd be content if we decided this was a
spec bug and agreed to add 'atom:source' to the lext of Metadata
Elements in Section 6.4.

| b) Section 6.4.1 and Section 6.4.2 don't place any restrictions on what e=
lements
| may be used as Metadata Extensions, but the RelaxNG grammar explicitly ex=
cludes
| elements in the Atom namespace.  The Atom namespace should be reserved for
| future forwards-compatable revisions of Atom.

Given that our spec defines what the atom: elments mean and where they
can appear, it would seem bizarre to me to say that in Metadata
Extensions, any atom: element can be used for any purpose.

I conclude that the RELAX NG grammar reflects the groups intent in
these areas, but I'll change it if consensus proves me wrong. :-)

                                        Be seeing you,
                                          norm

=2D-=20
Norman Walsh <ndw@nwalsh.com> | The worst enemy of life, freedom and
http://nwalsh.com/            | the common decencies is total anarchy;
                              | their second worst enemy is total
                              | efficiency.--Aldous Huxley

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBCsxwyOyltUcwYWjsRAgk1AKCSU4o2cH4TNzipgioTkWHQZMrMLwCgl0Ng
QGTk1KGOyDA1omk9OlJpZ0I=
=G/Uk
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Fri Jun 17 15:29:28 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16202
	for <atompub-archive@lists.ietf.org>; Fri, 17 Jun 2005 15:29:27 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5HJG56k006953;
	Fri, 17 Jun 2005 12:16:06 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5HJG5Z8006952;
	Fri, 17 Jun 2005 12:16:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.196])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5HJG4ck006850
	for <atom-syntax@imc.org>; Fri, 17 Jun 2005 12:16:05 -0700 (PDT)
	(envelope-from jasnell@gmail.com)
Received: by zproxy.gmail.com with SMTP id 13so140485nzp
        for <atom-syntax@imc.org>; Fri, 17 Jun 2005 12:15:59 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=bqtrYji9FS5V/DYXML51fxIxlQVxzuj6CqB0THKc/Z4ARdHjKUL84ijzeqRy4OioUse3M3aH1HzgSfdX6N3H7lXTYfXEhKyBlMe8IgFi9V0YX/qNqqRgYbwSm/jXREHyYG+025tNyRrx5Vh5EMYmIStNGnqtdMxEoSVEFZtQfeI=
Received: by 10.36.222.19 with SMTP id u19mr898189nzg;
        Fri, 17 Jun 2005 12:15:58 -0700 (PDT)
Received: from ?192.168.1.103? ([67.181.223.222])
        by mx.gmail.com with ESMTP id 38sm1669199nzk.2005.06.17.12.15.58;
        Fri, 17 Jun 2005 12:15:58 -0700 (PDT)
Message-ID: <42B32167.70002@gmail.com>
Date: Fri, 17 Jun 2005 12:15:51 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: atom-syntax@imc.org
Subject: Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing
 Lists
References: <20050617140542.GX20401@markbaker.ca> <2E68D5C0-189B-4FCC-9D6F-201F28FC2A58@sun.com> <42B31003.70609@gmail.com> <20050617185654.GA20938@klangraum>
In-Reply-To: <20050617185654.GA20938@klangraum>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
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: 8bit


Well, what I'm going for more is an understanding of what should happen 
during parsing.  For example, in Section 5 we dictate that "Atom 
Processors MUST NOT reject an Atom Document containing ... a signature 
because they are not capable of verifying it"... the MOST I think could 
be done in the core spec is a similar statement saying "Atom Processors 
MUST NOT reject an Atom Document containing a content media type that it 
doesn't understand".  Whatever else the processor does with it (e.g. 
ignore it, display a warning to the user, attempt to find an application 
to handle the content, etc) is up to the implementation.

A. Pagaltzis wrote:

>* James M Snell <jasnell@gmail.com> [2005-06-17 20:15]:
>  
>
>>currently there appears to be no language about what should
>>happen if an Atom processor encounters a content media type
>>that it doesn't understand.  Should it ignore the content? Does
>>it report an error?  Should it try to process the content
>>somehow (e.g. defer to some external processor)? 
>>    
>>
>
>The spec is supposed to explain what the bits means, but not to
>tell anyone what to do with them, so there’s nothing it can
>really mandate here. Certainly it can’t usefully *enforce*
>anything.
>
>This might be something that the implementor’s guide should
>contain recommendations for. But even then, I don’t think that
>doing more than suggesting a few best practices for a handful
>of situations is feasible.
>
>I expect that many newsreaders will simply ignore things they
>don’t understand.
>
>Personally, in the aggregator I occasionally work on, I plan to
>pass the data to a whatever application the user’s mailcap says
>is responsible for it. (I suppose you’d use the registry in
>Windows; I don’t know what mechanism OS X provides.)
>
>On the other hand, many scenarios will (hopefully!) involve Atom
>feeds intended solely for consumption by machines rather humans.
>I imagine that in at least a few of those, unexpected content
>types should set off alarms.
>
>So I don’t think there is any one course of action that we can
>recommend for everyone; let alone mandate, if such a thing even
>was in the scope of the spec. The best we could do is to
>informally suggest certain practices for certain situations. (I’d
>like to see desktop aggregators widely support what I am planning
>to do with mine, f.ex; then putting stuff other than HTML in
>feeds would have a chance to catch on.) And that too is probably
>something the guide should do, not the spec.
>
>Regards,
>  
>



From owner-atom-syntax@mail.imc.org  Fri Jun 17 16:09:44 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18677
	for <atompub-archive@lists.ietf.org>; Fri, 17 Jun 2005 16:09:44 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5HK3FYH057437;
	Fri, 17 Jun 2005 13:03:16 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5HK3FRR057435;
	Fri, 17 Jun 2005 13:03:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5HK3FtW057200
	for <atom-syntax@imc.org>; Fri, 17 Jun 2005 13:03:15 -0700 (PDT)
	(envelope-from antone@geckotribe.com)
Received: from geckotribe.com (c-67-169-250-63.hsd1.ut.comcast.net[67.169.250.63])
          by comcast.net (rwcrmhc11) with SMTP
          id <20050617200309013007sm63e>; Fri, 17 Jun 2005 20:03:09 +0000
Date: Fri, 17 Jun 2005 14:03:07 -0600
Subject: Re: Polling Sucks! (was RE: Atom feed synchronization)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v553)
From: Antone Roundy <antone@geckotribe.com>
To: atom-syntax@imc.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <20050617183244.AA0DC72521B@mail.pubsub.com>
Message-Id: <D2A838F2-DF6A-11D9-A030-003065EA6144@geckotribe.com>
X-Mailer: Apple Mail (2.553)
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: 7bit


On Friday, June 17, 2005, at 12:32  PM, Bob Wyman wrote:
> 	This is *not* simpler than taking a push feed using Atom over XMPP.
> For a push feed, all you do is:
> 	1. Open a socket
> 	2. Send a "login" XML Stanza
> 	3. Process the stanzas as they arrive.
...
> 	For your solution, you need to:
> 	1. Poll the feed to get a pointer to the "first link". (each poll
> will cost you a TCP/IP connection).
> 	2. If you got a new "first link" then go to step 5
> 	3. Wait some period of time (the polling interval)
> 	4. GoTo Step 1
> 	5. Open a new TCP/IP socket to get the next link
> 	6. Form and send an HTTP request for the next entry
> 	7. Catch the response from the server
> 	8. Parse the response to determine if its time stamp is something
> you've already seen.
> 	9. If you haven't seen the current entry before, then go to step 5
> 	10. Go to step 1 to start over.

Not to get into a big argument (each method has its advantages 
depending on circumstances), but allow me to revise the above a little. 
  The following assumes applications that attempt to keep you up-to-date 
on changes to the feed that occurred while you were offline:

XMPP:
1. Open a socket
2. Request and get the feed
3. Parse the XML
4. Process the entries (Determine whether each is new/updated or 
not--if so, do the appropriate thing)
5. If the feed had entries that were old and not updated, go to step 7
6. If the feed has a "first" or "next" or whatever link, go to step 1 
using that link
7. Open a socket
8. Send "login" XML stanza
9. Wait for a stanza (sending keep-alive packets periodically), and 
when it arrives...
10. Parse the XML
11. Process it (Determine whether the entry is new/updated or not and 
do the appropriate thing)
12. Go to step 9

Polling:
1. Open a socket
2. Request and get the feed
3. Parse the XML
4. Process the entries (Determine whether the entry is new/updated or 
not and do the appropriate thing)
5. If the feed had entries that were old and not updated, go to step 7
6. If the feed has a "first" or "next" or whatever link, go to step 1 
using that link
7. Wait some period of time
8. Go to step 1

The XMPP app will need to contain a superset of the polling app's code. 
My assessment of which method wins on various issues:

Latency: XMPP
Implementation complexity: Polling
Bandwidth consumption: XMPP
Resource consumption between polls or pushes: Polling
Getting all feed changes while online: XMPP if you're trying to archive 
the feed, otherwise no difference
Getting feed changes that occurred while offline: no difference



If we're not concerned about ensuring that we get all changes, the 
story is different:

XMPP:
1. Open a socket
2. Send "login" XML stanza
3. Wait for a stanza (sending keep-alive packets periodically), and 
when it arrives...
4. Parse the XML
5. Process it (Determine whether the entry is new/updated or not and do 
the appropriate thing)
6. Got to step 3

Polling:
1. Open a socket
2. Request and get the feed
3. Parse the XML
4. Process the entries (Determine whether the entry is new/updated or 
not and do the appropriate thing)
5. Wait some period of time
6. Go to step 1

My assessment:

Latency: XMPP
Implementation complexity: similar
Bandwidth consumption: XMPP
Resource consumption between polls or pushes: Polling
Getting all feed changes while online: XMPP
Getting feed changes that occurred while offline: Polling

XMPP could achieve parity in getting feed changes that occurred while 
offline, at the expense of implementation complexity parity, by polling 
the feed once upon startup.



From owner-atom-syntax@mail.imc.org  Fri Jun 17 17:03:21 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21672
	for <atompub-archive@lists.ietf.org>; Fri, 17 Jun 2005 17:03:20 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5HKvNQC018956;
	Fri, 17 Jun 2005 13:57:23 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5HKvN7Q018948;
	Fri, 17 Jun 2005 13:57:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from omr3.netsolmail.com (omr3.netsolmail.com [216.168.230.164])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5HKvM78018925
	for <atom-syntax@imc.org>; Fri, 17 Jun 2005 13:57:22 -0700 (PDT)
	(envelope-from bob@wyman.us)
Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180])
	by omr3.netsolmail.com (8.12.10/8.12.10) with ESMTP id j5HKvLgt004862;
	Fri, 17 Jun 2005 16:57:21 -0400 (EDT)
Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34])
	by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA)
	with ESMTP id DKU95328 (AUTH bob@wyman.us);
	Fri, 17 Jun 2005 16:57:20 -0400 (EDT)
Message-Id: <200506172057.DKU95328@ms8.netsolmail.com>
Reply-To: <bob@wyman.us>
From: "Bob Wyman" <bob@wyman.us>
To: "'Antone Roundy'" <antone@geckotribe.com>, <atom-syntax@imc.org>
Subject: RE: Polling Sucks! (was RE: Atom feed synchronization)
Date: Fri, 17 Jun 2005 16:57:17 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <D2A838F2-DF6A-11D9-A030-003065EA6144@geckotribe.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Thread-Index: AcVzeT2AL9YuwonuT8WQj1VdE88NhwAA6deQ
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: 7bit


Antone Roundy wrote:
> XMPP:
> 5. If the feed had entries that were old and not updated, go to step 7 6.
> If the feed has a "first" or "next" or whatever link, go to step 1 using
> that link 7. Open a socket 8. Send "login" XML stanza 
	I am assuming that if you are pushing entries via Atom over XMPP,
you would only push new and updated entries. Thus, a client shouldn't need
to check for "old and not updated" entries. Also, I'm assuming that since
you are pushing entries, you wouldn't be inserting "first" or "next" links
that needed to be followed. The client would get all of its entries from the
XMPP stream.

> XMPP could achieve parity in getting feed changes that occurred while
> offline, at the expense of implementation complexity parity, by
> polling the feed once upon startup.
	My assumption is that any well-built XMPP feed reader will, in fact,
also be able to read Atom files via HTTP. This is what we do at PubSub and
Gush does the same. I think Bill's app also does this. 
	The original question dealt can, I think, be summarized as: "How
does one best keep up with a high-volume Atom publisher?" My point was that
the "first" and "next" links don't make things any easier. They just force
the client to do a great deal of work to discover what the server already
knows -- which entries have been updated. The "first" and "next" links
approach just makes the process of working with feed files more complex as
well as more bandwidth intensive. XMPP support is a much better solution for
keeping up with changes while connected.
	Let's keep Atom as it is now -- without the "first" and "next" tags
and encourage folk who need to keep up with high volume streams to use Atom
over XMPP. Lowered bandwidth utilization, reduced latency and simplicity are
good things.

		bob wyman




From owner-atom-syntax@mail.imc.org  Fri Jun 17 17:49:21 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24752
	for <atompub-archive@lists.ietf.org>; Fri, 17 Jun 2005 17:49:20 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5HLgkN0071483;
	Fri, 17 Jun 2005 14:42:46 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5HLgjXe071482;
	Fri, 17 Jun 2005 14:42:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtp.cegetel.net (mf00.sitadelle.com [212.94.174.79])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5HLgigV071211
	for <atom-syntax@imc.org>; Fri, 17 Jun 2005 14:42:44 -0700 (PDT)
	(envelope-from t.broyer@cegetel.net)
Received: from [127.0.0.1] (unknown [84.5.53.124])
	by smtp.cegetel.net (Postfix) with ESMTP id 063391A465F;
	Fri, 17 Jun 2005 23:42:37 +0200 (CEST)
Message-ID: <42B343DF.1000700@cegetel.net>
Date: Fri, 17 Jun 2005 23:42:55 +0200
From: Thomas Broyer <t.broyer@cegetel.net>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: fr, en
MIME-Version: 1.0
To: Mark Baker <distobj@acm.org>
Cc: duerst@it.aoyama.ac.jp, ans208@mail.usask.ca, atom-syntax@imc.org
Subject: Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing
 Lists
References: <20050617140542.GX20401@markbaker.ca>
In-Reply-To: <20050617140542.GX20401@markbaker.ca>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


Mark Baker wrote:

>Martin,
>
>  
>
>>The general idea seems to be that conversion to HTML is good for
>>human consumption with a browser, and for human navigation in an
>>archive. message/rfc822 is the original, and may be very good for
>>reuse in a mailer (e.g. for replying), except that mailers don't
>>support it much at the moment.
>>
>><atom:content type="message/rfc822"
>>src="http://www.example.org/lists/list/archive/12345"/>
>>    
>>
>
>Unfortunately, that's bad Atom.  Section 4.1.3.1 of the format spec
>says;
>
>  On the atom:content element, the value of the "type" attribute MAY be
>  one of "text", "html", or "xhtml".  Failing that, it MUST be a MIME
>  media type, but MUST NOT be a composite type (see Section 4.2.6 of
>  [MIMEREG]).  If the type attribute is not provided, Atom Processors
>  MUST behave as though it were present with a value of "text".
>
>where "composite type" is defined to be multipart/* and message/*.  If
>the intent of that restriction was to avoid the whole non-XML
>attachments issue, then it seems to have failed to account for the use
>of the "src" attribute to include the data by reference rather than by
>value.
>
>I'm sorry that I didn't notice this earlier. 8-(
>  
>

Er, and it seems there's another (related) problem:
In 4.1.3.1:
[
If the type attribute is not provided, Atom Processors MUST behave as 
though it were present with a value of "text".
]
Just below, in 4.1.3.2:
[
If the "src" attribute is present, the "type" attribute SHOULD be 
provided and MUST be a MIME media type [MIMEREG], rather than "text", 
"html", or "xhtml".
]

So what if I provide a "src" attribute but no "type" attribute?
The "type" attribute would "default" to "text", but "text" is forbidden 
if "src" is provided...

I suggest that if src is provided but not type, there is no "type 
value", as this value is just advisory and not authoritative. However, 
if src is not provided (the content is local), processors must "behave 
as though it were present with a value of text".

-- 
Thomas Broyer




From owner-atom-syntax@mail.imc.org  Fri Jun 17 18:23:56 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28033
	for <atompub-archive@lists.ietf.org>; Fri, 17 Jun 2005 18:23:56 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5HM996J001500;
	Fri, 17 Jun 2005 15:09:09 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5HM99xf001499;
	Fri, 17 Jun 2005 15:09:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.199])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5HM98rw001279
	for <atom-syntax@imc.org>; Fri, 17 Jun 2005 15:09:08 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by zproxy.gmail.com with SMTP id 13so204496nzp
        for <atom-syntax@imc.org>; Fri, 17 Jun 2005 15:09:02 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=tjo4jY4M5sW2ZGM0NdGeKPbRc/jieG0ys1IU14nRqDjaPXgyUAuabzTPfxq8s3a6n0szpJjdPERCQvErAWJ//lnPW28wfSqoTorwWAIWOmfWN41aNzrQk/JGo+jn9OWkoQ5M+dA8CREfuKCUUrC8a0AOgp4m6eFgonuuh6nSpwk=
Received: by 10.36.10.18 with SMTP id 18mr1683915nzj;
        Fri, 17 Jun 2005 15:09:02 -0700 (PDT)
Received: by 10.36.61.20 with HTTP; Fri, 17 Jun 2005 15:09:02 -0700 (PDT)
Message-ID: <3f1451f5050617150963c2e5aa@mail.gmail.com>
Date: Fri, 17 Jun 2005 18:09:02 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
Reply-To: Joe Gregorio <joe.gregorio@gmail.com>
To: bob@wyman.us
Subject: Re: Polling Sucks! (was RE: Atom feed synchronization)
Cc: Antone Roundy <antone@geckotribe.com>, atom-syntax@imc.org
In-Reply-To: <200506172057.DKU95328@ms8.netsolmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
References: <D2A838F2-DF6A-11D9-A030-003065EA6144@geckotribe.com>
	 <200506172057.DKU95328@ms8.netsolmail.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j5HM99rw001468
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: 8bit


On 6/17/05, Bob Wyman <bob@wyman.us> wrote:
>         Let's keep Atom as it is now -- without the "first" and "next" tags
> and encourage folk who need to keep up with high volume streams to use Atom
> over XMPP.

-1

Let's keep Atom as it is now explain to folks who need to keep up with 
high volume streams the two options they have, either
streaming over XMPP or "next" links.

>  Lowered bandwidth utilization, reduced latency and simplicity are
> good things.

The one thing missing from the analysis is the overhead, and practicality,
of switching protocols (HTTP to XMPP).

   Thanks,
   -joe

-- 
Joe Gregorio        http://bitworking.org



From owner-atom-syntax@mail.imc.org  Fri Jun 17 18:46:04 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29240
	for <atompub-archive@lists.ietf.org>; Fri, 17 Jun 2005 18:46:03 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5HMf1QZ039957;
	Fri, 17 Jun 2005 15:41:01 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5HMf12i039956;
	Fri, 17 Jun 2005 15:41:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from omr2.netsolmail.com (omr2.netsolmail.com [216.168.230.163])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5HMf0wU039927
	for <atom-syntax@imc.org>; Fri, 17 Jun 2005 15:41:01 -0700 (PDT)
	(envelope-from bob@wyman.us)
Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180])
	by omr2.netsolmail.com (8.12.10/8.12.10) with ESMTP id j5HMewWj010985;
	Fri, 17 Jun 2005 18:40:59 -0400 (EDT)
Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34])
	by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA)
	with ESMTP id DKV29162 (AUTH bob@wyman.us);
	Fri, 17 Jun 2005 18:40:57 -0400 (EDT)
Message-Id: <200506172240.DKV29162@ms8.netsolmail.com>
Reply-To: <bob@wyman.us>
From: "Bob Wyman" <bob@wyman.us>
To: "'Joe Gregorio'" <joe.gregorio@gmail.com>, <bob@wyman.us>
Cc: "'Antone Roundy'" <antone@geckotribe.com>, <atom-syntax@imc.org>
Subject: RE: Polling Sucks! (was RE: Atom feed synchronization)
Date: Fri, 17 Jun 2005 18:40:54 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <3f1451f5050617150963c2e5aa@mail.gmail.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Thread-Index: AcVziU0HRBEcMtBaRxyHULnicDIAMwAAyLIA
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: 7bit


Joe Gregorio wrote:
> The one thing missing from the analysis is the overhead, and
> practicality, of switching protocols (HTTP to XMPP).
	I'm not aware of anything that might be called "overhead." What our
clients do is, upon startup, connect to XMPP and request the list of Atom
files that they are monitoring. They then immediately fetch those files to
establish their start-of-session state. From that point on, they only listen
to XMPP since anything that would be written to the Atom files is also
written to XMPP. HTTP is only used on start-up. It's a pretty clean process.

> Let's keep Atom as it is now explain to folks who need to keep up with 
> high volume streams the two options they have, either streaming over
> XMPP or "next" links.
	Where are these "next" links defined? I don't see them in the Atom
Internet Draft. The word "next" doesn't even appear in the ID... If they
aren't there, how can you call them "Atom as it is now"? I thought Henry
Story was proposing these as extensions.

		bob wyman



From owner-atom-syntax@mail.imc.org  Fri Jun 17 21:41:42 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09729
	for <atompub-archive@lists.ietf.org>; Fri, 17 Jun 2005 21:41:42 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5I1XBJD001078;
	Fri, 17 Jun 2005 18:33:23 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5I1F0fZ086820;
	Fri, 17 Jun 2005 18:15:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.198])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5I1DpEY085888
	for <atom-syntax@imc.org>; Fri, 17 Jun 2005 18:13:53 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by zproxy.gmail.com with SMTP id 13so244912nzp
        for <atom-syntax@imc.org>; Fri, 17 Jun 2005 18:13:46 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=SVbFQSeulOwOl0WQ6gLWyFFWW6jCHJYgshevQBcnKhGpgKojzQQGipVFbFWb9nptgyV6GERl/xoc9frWS6P8hL93BzbwtfZ5UsXazjI1WIJ+zw3ckmV0aQJn6DbcZdJO6kC9XpRRUzaeW5Zw7jC98WpV39eN6Fnqzx5SdZFSaok=
Received: by 10.36.220.71 with SMTP id s71mr1752663nzg;
        Fri, 17 Jun 2005 18:13:46 -0700 (PDT)
Received: by 10.36.61.20 with HTTP; Fri, 17 Jun 2005 18:13:46 -0700 (PDT)
Message-ID: <3f1451f5050617181373895c15@mail.gmail.com>
Date: Fri, 17 Jun 2005 21:13:46 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
Reply-To: Joe Gregorio <joe.gregorio@gmail.com>
To: bob@wyman.us
Subject: Re: Polling Sucks! (was RE: Atom feed synchronization)
Cc: Antone Roundy <antone@geckotribe.com>, atom-syntax@imc.org
In-Reply-To: <200506172240.DKV29162@ms8.netsolmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
References: <3f1451f5050617150963c2e5aa@mail.gmail.com>
	 <200506172240.DKV29162@ms8.netsolmail.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j5I1E6EY086140
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: 8bit


On 6/17/05, Bob Wyman <bob@wyman.us> wrote:
> Joe Gregorio wrote:
> > The one thing missing from the analysis is the overhead, and
> > practicality, of switching protocols (HTTP to XMPP).
>         I'm not aware of anything that might be called "overhead."

I was referring to switching both the client and server from running
HTTP to running XMPP. That may not be practical or even possible
for some people. Yes, I understand that you run this right now.
Yes, I understand that you run a business doing this right now.
Yes, I agree that your solution is one way to solve the problem.

Do you agree that 99.99% of all syndication is done via
HTTP today and also offering an HTTP based solution would be of value?

   -joe

-- 
Joe Gregorio        http://bitworking.org



From owner-atom-syntax@mail.imc.org  Fri Jun 17 22:14:03 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12338
	for <atompub-archive@lists.ietf.org>; Fri, 17 Jun 2005 22:14:03 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5I25iUG036013;
	Fri, 17 Jun 2005 19:05:44 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5I25iuC036012;
	Fri, 17 Jun 2005 19:05:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.25])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5I25gBY035970
	for <atom-syntax@imc.org>; Fri, 17 Jun 2005 19:05:42 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 18 Jun 2005 12:06:09 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sat, 18 Jun 2005 12:05:39 +1000
Subject: Re: Polling Sucks! (was RE: Atom feed synchronization)
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BED9BE93.5F595%eric.scheid@ironclad.net.au>
In-Reply-To: <200506172057.DKU95328@ms8.netsolmail.com>
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>
Content-Transfer-Encoding: 7bit


On 18/6/05 6:57 AM, "Bob Wyman" <bob@wyman.us> wrote:

> Let's keep Atom as it is now -- without the "first" and "next" tags
> and encourage folk who need to keep up with high volume streams to use Atom
> over XMPP. Lowered bandwidth utilization, reduced latency and simplicity are
> good things.

how does Atom over XMPP help in this scenario:

1) wake up
2) scratch myself, stagger around in morning fog
3) turn on computer, launch feed reader
4) wonder what changes happened during the night

e.



From owner-atom-syntax@mail.imc.org  Fri Jun 17 22:19:34 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12595
	for <atompub-archive@lists.ietf.org>; Fri, 17 Jun 2005 22:19:33 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5I26OZ8036669;
	Fri, 17 Jun 2005 19:06:24 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5I26OlB036668;
	Fri, 17 Jun 2005 19:06:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.25])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5I26Ncx036635
	for <atom-syntax@imc.org>; Fri, 17 Jun 2005 19:06:24 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 18 Jun 2005 12:06:53 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sat, 18 Jun 2005 12:06:22 +1000
Subject: Re: Question on Use Case: Choosing atom:content's type when
	ArchivingMailing Lists
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BED9BEBE.5F596%eric.scheid@ironclad.net.au>
In-Reply-To: <42B343DF.1000700@cegetel.net>
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>
Content-Transfer-Encoding: 7bit


On 18/6/05 7:42 AM, "Thomas Broyer" <t.broyer@cegetel.net> wrote:

> So what if I provide a "src" attribute but no "type" attribute?
> The "type" attribute would "default" to "text", but "text" is forbidden
> if "src" is provided...
> 
> I suggest that if src is provided but not type, there is no "type
> value", as this value is just advisory and not authoritative. However,
> if src is not provided (the content is local), processors must "behave
> as though it were present with a value of text".

+1



From owner-atom-syntax@mail.imc.org  Fri Jun 17 22:19:39 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12614
	for <atompub-archive@lists.ietf.org>; Fri, 17 Jun 2005 22:19:38 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5I26Bx4036547;
	Fri, 17 Jun 2005 19:06:11 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5I26BK0036546;
	Fri, 17 Jun 2005 19:06:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5I26Aew036513
	for <atom-syntax@imc.org>; Fri, 17 Jun 2005 19:06:10 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from [192.168.1.101] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65])
	(authenticated bits=0)
	by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j5I28ZR4025488;
	Fri, 17 Jun 2005 22:08:38 -0400
Message-ID: <42B3818C.2020608@intertwingly.net>
Date: Fri, 17 Jun 2005 22:06:04 -0400
From: Sam Ruby <rubys@intertwingly.net>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Joe Gregorio <joe.gregorio@gmail.com>
CC: atom-syntax@imc.org
Subject: Re: Polling Sucks! (was RE: Atom feed synchronization)
References: <3f1451f5050617150963c2e5aa@mail.gmail.com>	 <200506172240.DKV29162@ms8.netsolmail.com> <3f1451f5050617181373895c15@mail.gmail.com>
In-Reply-To: <3f1451f5050617181373895c15@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


Joe Gregorio wrote:
> On 6/17/05, Bob Wyman <bob@wyman.us> wrote:
> 
>>Joe Gregorio wrote:
>>
>>>The one thing missing from the analysis is the overhead, and
>>>practicality, of switching protocols (HTTP to XMPP).
>>
>>        I'm not aware of anything that might be called "overhead."
> 
> I was referring to switching both the client and server from running
> HTTP to running XMPP. That may not be practical or even possible
> for some people. Yes, I understand that you run this right now.
> Yes, I understand that you run a business doing this right now.
> Yes, I agree that your solution is one way to solve the problem.
> 
> Do you agree that 99.99% of all syndication is done via
> HTTP today and also offering an HTTP based solution would be of value?

Joe, I'd be careful with how you structure this argument.  It could be 
applied in a different context, for example:

   Do you agree that 99.99% of all syndication is done via HTTP GET
   and POST today and offering a solution based only on these two
   verbs would be of value?

One can go down this path and cater to the least common denominator 
always, or one can say that perhaps MIDP 1.0 phones are not particularly 
well adapted to perform complex editing tasks beyond simple GET and POST.

Perhaps HTTP is suited to a wide, but not universal, range of 
applications dealing with relatively coarse and relatively infrequently 
updated content; and XMPP is well suited to a different -- always on, 
firehose -- set of applications, with a wide overlap between the two.

And perhaps they could be combined.  I could see a future where there 
was a "feedmesh" backbone with nodes exchanging data via XMPP, serving 
content out to the rest of the universe via HTTP.

- Sam Ruby

P.S.  Why is this on atom-sytax?  Is there a concrete proposal we are 
talking about here?  Is there likely to be?



From owner-atom-syntax@mail.imc.org  Sat Jun 18 00:35:25 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19413
	for <atompub-archive@lists.ietf.org>; Sat, 18 Jun 2005 00:35:25 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5I4RT0A086084;
	Fri, 17 Jun 2005 21:27:29 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5I4RTQT086083;
	Fri, 17 Jun 2005 21:27:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.204])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5I4RSrV086073
	for <atom-syntax@imc.org>; Fri, 17 Jun 2005 21:27:28 -0700 (PDT)
	(envelope-from jasnell@gmail.com)
Received: by rproxy.gmail.com with SMTP id a41so390473rng
        for <atom-syntax@imc.org>; Fri, 17 Jun 2005 21:27:28 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=Is1Bt+41QVthiHwohskb8DB3KIF4vGesCf0sYEhpYsnx0ymQf8aEeSSVOBXocLsYdez6KLRoRQxcWeI1I0PFk0p+klrSR2NStUuHviPmqJ+J0eEv0rbRVrhwZEH7kRy7Vkl68EVCooKE7L8aPvAf/Y52+S7KixGqaXQCXUG8XE0=
Received: by 10.38.13.1 with SMTP id 1mr1149162rnm;
        Fri, 17 Jun 2005 21:27:28 -0700 (PDT)
Received: from ?192.168.1.103? ([67.181.223.222])
        by mx.gmail.com with ESMTP id k22sm797080rnb.2005.06.17.21.27.27;
        Fri, 17 Jun 2005 21:27:28 -0700 (PDT)
Message-ID: <42B3A2AA.40007@gmail.com>
Date: Fri, 17 Jun 2005 21:27:22 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sam Ruby <rubys@intertwingly.net>, atom-syntax@imc.org
Subject: Re: Polling Sucks! (was RE: Atom feed synchronization)
References: <3f1451f5050617150963c2e5aa@mail.gmail.com>	 <200506172240.DKV29162@ms8.netsolmail.com> <3f1451f5050617181373895c15@mail.gmail.com> <42B3818C.2020608@intertwingly.net>
In-Reply-To: <42B3818C.2020608@intertwingly.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


Sam asked
 > P.S.  Why is this on atom-sytax?  Is there a concrete proposal we are 
talking about here?  Is there likely to be?

I launched this discussion here for three reasons:

1. Everyone who care's about it is probably already here

2. Main discussion about the syntax is pretty much complete so there is 
no real risk of derailing anything

3. If there was no already accepted solution to the problem, this would 
be a logical place to begin hunting for and discussing the solution

That said, however, is there a better venue that you could suggest?

Capping out the conversation a bit, Bob Wyman's RFC3229+feed proposal, 
once written up into an Internet-Draft, will provide the solution that 
I'm searching for (e.g. the ability to catch up on what has changed in a 
feed over a given period of time).  The XMPP Push model would likely not 
be implemented in the case I'm considering but I couldn't rule it out 
completely.  I believe it is Bob's intention to draft up the 
RFC3229+feed and pitch it to this group for discussion.

Sam Ruby wrote:

>
> Joe Gregorio wrote:
>
>> On 6/17/05, Bob Wyman <bob@wyman.us> wrote:
>>
>>> Joe Gregorio wrote:
>>>
>>>> The one thing missing from the analysis is the overhead, and
>>>> practicality, of switching protocols (HTTP to XMPP).
>>>
>>>
>>>        I'm not aware of anything that might be called "overhead."
>>
>>
>> I was referring to switching both the client and server from running
>> HTTP to running XMPP. That may not be practical or even possible
>> for some people. Yes, I understand that you run this right now.
>> Yes, I understand that you run a business doing this right now.
>> Yes, I agree that your solution is one way to solve the problem.
>>
>> Do you agree that 99.99% of all syndication is done via
>> HTTP today and also offering an HTTP based solution would be of value?
>
>
> Joe, I'd be careful with how you structure this argument.  It could be 
> applied in a different context, for example:
>
>   Do you agree that 99.99% of all syndication is done via HTTP GET
>   and POST today and offering a solution based only on these two
>   verbs would be of value?
>
> One can go down this path and cater to the least common denominator 
> always, or one can say that perhaps MIDP 1.0 phones are not 
> particularly well adapted to perform complex editing tasks beyond 
> simple GET and POST.
>
> Perhaps HTTP is suited to a wide, but not universal, range of 
> applications dealing with relatively coarse and relatively 
> infrequently updated content; and XMPP is well suited to a different 
> -- always on, firehose -- set of applications, with a wide overlap 
> between the two.
>
> And perhaps they could be combined.  I could see a future where there 
> was a "feedmesh" backbone with nodes exchanging data via XMPP, serving 
> content out to the rest of the universe via HTTP.
>
> - Sam Ruby
>
> P.S.  Why is this on atom-sytax?  Is there a concrete proposal we are 
> talking about here?  Is there likely to be?
>
>



From owner-atom-syntax@mail.imc.org  Sat Jun 18 00:36:04 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19454
	for <atompub-archive@lists.ietf.org>; Sat, 18 Jun 2005 00:36:04 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5I4UJrC089525;
	Fri, 17 Jun 2005 21:30:19 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5I4UJEQ089524;
	Fri, 17 Jun 2005 21:30:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.192])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5I4UIE8089509
	for <atom-syntax@imc.org>; Fri, 17 Jun 2005 21:30:18 -0700 (PDT)
	(envelope-from jasnell@gmail.com)
Received: by rproxy.gmail.com with SMTP id j1so386163rnf
        for <atom-syntax@imc.org>; Fri, 17 Jun 2005 21:30:18 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=HOIAN7qiC8XCXy6kGvpu51iuHk1X7FV9gbYp2Lb/cKunDJNdgU6J5Zgx4ez3RiPTCggD552PK+h9zWJIEWyfu/WkC2xRa1txzm/JoBtJsbzMdLp21fG0EYqzcrFRe/jRCN2S9pxMI6NxLgH+TLP10CnTtIJmuFD8+peqdjqtexQ=
Received: by 10.38.79.33 with SMTP id c33mr1369614rnb;
        Fri, 17 Jun 2005 21:30:18 -0700 (PDT)
Received: from ?192.168.1.103? ([67.181.223.222])
        by mx.gmail.com with ESMTP id m36sm1351164rnd.2005.06.17.21.30.17;
        Fri, 17 Jun 2005 21:30:18 -0700 (PDT)
Message-ID: <42B3A355.80902@gmail.com>
Date: Fri, 17 Jun 2005 21:30:13 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Eric Scheid <eric.scheid@ironclad.net.au>, atom-syntax@imc.org
Subject: Re: Polling Sucks! (was RE: Atom feed synchronization)
References: <BED9BE93.5F595%eric.scheid@ironclad.net.au>
In-Reply-To: <BED9BE93.5F595%eric.scheid@ironclad.net.au>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


That's what I believe Bob's RFC3229+Feed proposal addresses. 

If I understand Bob's solution correctly, it goes something like:

1) wake up
2) scratch whatever you need to scratch
3) turn on computer, launch feed reader
4) feed reader does some RFC3229+feed magic to catch up on what happened 
during the night
5) feed reader opens a XMPP connection to receive the active stream of 
new entries

Eric Scheid wrote:

>On 18/6/05 6:57 AM, "Bob Wyman" <bob@wyman.us> wrote:
>
>  
>
>>Let's keep Atom as it is now -- without the "first" and "next" tags
>>and encourage folk who need to keep up with high volume streams to use Atom
>>over XMPP. Lowered bandwidth utilization, reduced latency and simplicity are
>>good things.
>>    
>>
>
>how does Atom over XMPP help in this scenario:
>
>1) wake up
>2) scratch myself, stagger around in morning fog
>3) turn on computer, launch feed reader
>4) wonder what changes happened during the night
>
>e.
>
>
>  
>



From owner-atom-syntax@mail.imc.org  Sat Jun 18 03:32:23 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20603
	for <atompub-archive@lists.ietf.org>; Sat, 18 Jun 2005 03:32:22 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5I7GIV5083956;
	Sat, 18 Jun 2005 00:16:18 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5I7GILm083955;
	Sat, 18 Jun 2005 00:16:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from bblfish.net (bblfish.net [192.220.66.168])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5I7GIXG083946
	for <atom-syntax@imc.org>; Sat, 18 Jun 2005 00:16:18 -0700 (PDT)
	(envelope-from henry.story@bblfish.net)
Received: (qmail 12663 invoked by uid 17064); 18 Jun 2005 07:16:17 -0000
Received: from unknown (HELO [192.168.0.3]) ([83.112.129.210])
          (envelope-sender <henry.story@bblfish.net>)
          by 192.220.66.168 (qmail-ldap-1.03) with SMTP
          for <rubys@intertwingly.net>; 18 Jun 2005 07:16:17 -0000
In-Reply-To: <42B3A2AA.40007@gmail.com>
References: <3f1451f5050617150963c2e5aa@mail.gmail.com>	 <200506172240.DKV29162@ms8.netsolmail.com> <3f1451f5050617181373895c15@mail.gmail.com> <42B3818C.2020608@intertwingly.net> <42B3A2AA.40007@gmail.com>
Mime-Version: 1.0 (Apple Message framework v730)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <313800B8-40BE-44B1-B80A-696B7653987F@bblfish.net>
Cc: Sam Ruby <rubys@intertwingly.net>,
        atom-syntax Syntax <atom-syntax@imc.org>,
        Danny Ayers <danny.ayers@gmail.com>
Content-Transfer-Encoding: 7bit
From: Henry Story <henry.story@bblfish.net>
Subject: first request for an atom extension: Re: Polling Sucks! (was RE: Atom feed synchronization)
Date: Sat, 18 Jun 2005 09:16:14 +0200
To: James M Snell <jasnell@gmail.com>
X-Mailer: Apple Mail (2.730)
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: 7bit


This is a good venue. I think XMPP and polling can be explored.

But for the needs of BlogEd [1] on which I am working, and for my  
personal needs,
I would really like us to introduce an extension to the link concept,  
to provide
a pointer to the next page in a historically ordered sequence of feed  
documents.
For many people who have dumb internet connections with very minimal  
servers, the
xmpp solution requires a lot more technology than we have available  
or want to be
bothered with. Something like:

<link rel="http://.../next" href="http://bblfish.net/blog/archive/ 
2005-05-10.atom">

would be really useful. It requires only a working apache on the  
server side.
On the client side it is really simple to follow. The client just  
needs to have access
to the base feed url, and can follow these links through all the  
change history of the
feed if he wishes.

It would allow me to have a:
   - a remote backup of my blog
   - provide the means to synchronize it between two editors
   - allow clients and aggregators to get a complete historical view  
of the feed.

And it comes at really no cost, since all it requires is for us to  
mint a new "next"
url. So how does one go about extending atom? This was meant to be a  
feature of it,
and especially of the link concept.

Henry Story

[1] https://bloged.dev.java.net/
[2] http://bblfish.net/blog/

On 18 Jun 2005, at 06:27, James M Snell wrote:
>
> Sam asked
> > P.S.  Why is this on atom-sytax?  Is there a concrete proposal we  
> are talking about here?  Is there likely to be?
>
> I launched this discussion here for three reasons:
>
> 1. Everyone who care's about it is probably already here
>
> 2. Main discussion about the syntax is pretty much complete so  
> there is no real risk of derailing anything
>
> 3. If there was no already accepted solution to the problem, this  
> would be a logical place to begin hunting for and discussing the  
> solution
>
> That said, however, is there a better venue that you could suggest?
>
> Capping out the conversation a bit, Bob Wyman's RFC3229+feed  
> proposal, once written up into an Internet-Draft, will provide the  
> solution that I'm searching for (e.g. the ability to catch up on  
> what has changed in a feed over a given period of time).  The XMPP  
> Push model would likely not be implemented in the case I'm  
> considering but I couldn't rule it out completely.  I believe it is  
> Bob's intention to draft up the RFC3229+feed and pitch it to this  
> group for discussion.
>
> Sam Ruby wrote:
>
>
>>
>> Joe Gregorio wrote:
>>
>>
>>> On 6/17/05, Bob Wyman <bob@wyman.us> wrote:
>>>
>>>
>>>> Joe Gregorio wrote:
>>>>
>>>>
>>>>> The one thing missing from the analysis is the overhead, and
>>>>> practicality, of switching protocols (HTTP to XMPP).
>>>>>
>>>>
>>>>
>>>>        I'm not aware of anything that might be called "overhead."
>>>>
>>>
>>>
>>> I was referring to switching both the client and server from running
>>> HTTP to running XMPP. That may not be practical or even possible
>>> for some people. Yes, I understand that you run this right now.
>>> Yes, I understand that you run a business doing this right now.
>>> Yes, I agree that your solution is one way to solve the problem.
>>>
>>> Do you agree that 99.99% of all syndication is done via
>>> HTTP today and also offering an HTTP based solution would be of  
>>> value?
>>>
>>
>>
>> Joe, I'd be careful with how you structure this argument.  It  
>> could be applied in a different context, for example:
>>
>>   Do you agree that 99.99% of all syndication is done via HTTP GET
>>   and POST today and offering a solution based only on these two
>>   verbs would be of value?
>>
>> One can go down this path and cater to the least common  
>> denominator always, or one can say that perhaps MIDP 1.0 phones  
>> are not particularly well adapted to perform complex editing tasks  
>> beyond simple GET and POST.
>>
>> Perhaps HTTP is suited to a wide, but not universal, range of  
>> applications dealing with relatively coarse and relatively  
>> infrequently updated content; and XMPP is well suited to a  
>> different -- always on, firehose -- set of applications, with a  
>> wide overlap between the two.
>>
>> And perhaps they could be combined.  I could see a future where  
>> there was a "feedmesh" backbone with nodes exchanging data via  
>> XMPP, serving content out to the rest of the universe via HTTP.
>>
>> - Sam Ruby
>>
>> P.S.  Why is this on atom-sytax?  Is there a concrete proposal we  
>> are talking about here?  Is there likely to be?
>>
>>
>



From owner-atom-syntax@mail.imc.org  Sat Jun 18 03:33:02 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20656
	for <atompub-archive@lists.ietf.org>; Sat, 18 Jun 2005 03:33:02 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5I7D6pP080618;
	Sat, 18 Jun 2005 00:13:06 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5I7D6j9080617;
	Sat, 18 Jun 2005 00:13:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.pubsub.com (mail.pubsub.com [209.11.36.150])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5I7D4aw080329
	for <atom-syntax@imc.org>; Sat, 18 Jun 2005 00:13:04 -0700 (PDT)
	(envelope-from bob@wyman.us)
Received: from IBMC101DE8DFED (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137])
	by mail.pubsub.com (Postfix) with ESMTP id 7B333725734;
	Sat, 18 Jun 2005 03:12:55 -0400 (EDT)
Message-ID: <001d01c573d5$24e1e720$6600a8c0@IBMC101DE8DFED>
From: "Bob Wyman" <bob@wyman.us>
To: "James M Snell" <jasnell@gmail.com>,
        "Eric Scheid" <eric.scheid@ironclad.net.au>, <atom-syntax@imc.org>
Cc: "Joe Gregorio" <joe.gregorio@gmail.com>
References: <BED9BE93.5F595%eric.scheid@ironclad.net.au> <42B3A355.80902@gmail.com>
Subject: Re: Polling Sucks! (was RE: Atom feed synchronization)
Date: Sat, 18 Jun 2005 03:12:50 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2527
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
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: 7bit


James M Snell wrote:
> If I understand Bob's solution correctly, it goes something like:
> 1) wake up
> 2) scratch whatever you need to scratch
> 3) turn on computer, launch feed reader
> 4) feed reader does some RFC3229+feed magic to catch up on what happened 
> during the night
> 5) feed reader opens a XMPP connection to receive the active stream of new 
> entries
    This is precisely what I was describing and it is what we implement in 
the PubSub Sidebar clients. This hybrid combination gives you the best of 
both worlds. The result is the lowest possible bandwidth consumption as well 
as the lowest latency in delivering content to clients.
    The Push+Pull approach is particularly well suited to the kind of high 
volume application that James Snell describes -- particularly if the server 
has a large number of readers. While I've previously pointed out the benefit 
to the network (efficient utilization of bandwidth) and to clients (low 
latency), it is important to point out that the Push model offers real 
benefits for the server as well. In extremely high volume applications, it 
is important that the server be able to control and smooth load. Server 
based load control is most easily accomplished with a Push system. In a Pull 
based system, load is almost totally dependent on client-driven scheduling 
and thus load tends to be very bursty. Bursty load is the worst possible 
thing to have in a network-based system. In Push based systems, the server 
is able to eliminate load bursts by spreading delivery of entries over 
time -- without worrying about the need to service bursty client requests 
within the window of their request time-out limits.
    Even though there are all sorts of advantages to using Push-based and 
hybrid Push+Pull systems, the reality is that only a tiny percentage of all 
the millions of servers that support Atom feeds will have sufficient traffic 
or readership to benefit from these methods. As Joe Gregario suggests in his 
recent note: "99.99% of all syndication is done via HTTP" and this will 
probably remain the case in terms of a raw census of servers. However, it is 
also clear we are seeing significant growth in the use of feed aggregators 
like PubSub, FeedBurner and the other blog search and monitoring services. 
Also, we are seeing an increase in the use of feed-readers on mobile devices 
which require that feeds be consolidated and fed through proxies in order to 
reduce the amount of polling and other processing done by those mobile 
devices. As the use of these services increases, it will make sense for 
client developers to implement client-based support for Push+Pull and thus 
provide to their users the benefits of reduced bandwidth, reduced session 
management, and reduced latency. Broad client-based support makes sense even 
if similarly broad server-based support does not.

        bob wyman




From owner-atom-syntax@mail.imc.org  Sat Jun 18 03:38:20 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20988
	for <atompub-archive@lists.ietf.org>; Sat, 18 Jun 2005 03:38:20 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5I7KbBq087728;
	Sat, 18 Jun 2005 00:20:37 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5I7KbPf087726;
	Sat, 18 Jun 2005 00:20:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.pubsub.com (mail.pubsub.com [209.11.36.150])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5I7KaXk087626
	for <atom-syntax@imc.org>; Sat, 18 Jun 2005 00:20:36 -0700 (PDT)
	(envelope-from bob@wyman.us)
Received: from IBMC101DE8DFED (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137])
	by mail.pubsub.com (Postfix) with ESMTP id 5445C725734;
	Sat, 18 Jun 2005 03:20:31 -0400 (EDT)
Message-ID: <001f01c573d6$35121420$6600a8c0@IBMC101DE8DFED>
From: "Bob Wyman" <bob@wyman.us>
To: "Sam Ruby" <rubys@intertwingly.net>,
        "Joe Gregorio" <joe.gregorio@gmail.com>
Cc: <atom-syntax@imc.org>
References: <3f1451f5050617150963c2e5aa@mail.gmail.com>	 <200506172240.DKV29162@ms8.netsolmail.com> <3f1451f5050617181373895c15@mail.gmail.com> <42B3818C.2020608@intertwingly.net>
Subject: Re: Polling Sucks! (was RE: Atom feed synchronization)
Date: Sat, 18 Jun 2005 03:20:25 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2527
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
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: 7bit


Sam Ruby wrote:
> P.S.  Why is this on atom-sytax?  Is there a concrete proposal we are 
> talking about here?  Is there likely to be?
    Because James Snell asked a question?.. But, more seriously:
    I intend to write an Internet draft for RFC3229+feed and hope that I'll 
be able to get the working group to consider it. Given the implemenation 
history, we certainly meet the IETF tradition of having more than three 
independent implementions as well as considerable experience in field use. 
Also, the "Atom over XMPP" Internet Draft is something that I think the 
Working Group should consider once the issues related to the syntax and 
protocol specs are dealt with.
    In any case, I think it is traditional for IETF mailing lists to provide 
a forum for discussion of potential use of the protocols that they define in 
addition to providing a forum for the work of defining the language of the 
specifications themselves. It is only by developing a common understanding 
of the various use cases that we can understand how the future work, if any, 
of the working group should be defined.

        bob wyman




From owner-atom-syntax@mail.imc.org  Sat Jun 18 06:25:21 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28785
	for <atompub-archive@lists.ietf.org>; Sat, 18 Jun 2005 06:25:20 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5IAIjlX017106;
	Sat, 18 Jun 2005 03:18:45 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5IAIjBm017105;
	Sat, 18 Jun 2005 03:18:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail07.svc.cra.dublin.eircom.net (mail07.svc.cra.dublin.eircom.net [159.134.118.23])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j5IAIhSv017033
	for <atom-syntax@imc.org>; Sat, 18 Jun 2005 03:18:44 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 90101 messnum 2892081 invoked from network[83.70.250.40/83-70-250-40.b-ras1.prp.dublin.eircom.net]); 18 Jun 2005 10:18:37 -0000
Received: from 83-70-250-40.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.250.40)
  by mail07.svc.cra.dublin.eircom.net (qp 90101) with SMTP; 18 Jun 2005 10:18:37 -0000
Message-ID: <42B3F4FB.8080500@dehora.net>
Date: Sat, 18 Jun 2005 11:18:35 +0100
From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: bob@wyman.us
CC: "'Joe Gregorio'" <joe.gregorio@gmail.com>,
        "'Antone Roundy'" <antone@geckotribe.com>, atom-syntax@imc.org
Subject: Re: Polling Sucks! (was RE: Atom feed synchronization)
References: <200506172240.DKV29162@ms8.netsolmail.com>
In-Reply-To: <200506172240.DKV29162@ms8.netsolmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


Bob Wyman wrote:
> Joe Gregorio wrote:
> 
>>The one thing missing from the analysis is the overhead, and
>>practicality, of switching protocols (HTTP to XMPP).
> 
> 	I'm not aware of anything that might be called "overhead." What our
> clients do is, upon startup, connect to XMPP and request the list of Atom
> files that they are monitoring. They then immediately fetch those files to
> establish their start-of-session state. From that point on, they only listen
> to XMPP since anything that would be written to the Atom files is also
> written to XMPP. HTTP is only used on start-up. It's a pretty clean process.
> 

I'm guessing Joe is talking about network administration. There's no 
shortage of places that won't even let you use SSH or POP, never mind on 
XMPP. It's port 80 via the proxy or nothing. This is an observation of 
the current state of affairs, please don't confuse it with an advocacy 
of it.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Sat Jun 18 06:25:24 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28803
	for <atompub-archive@lists.ietf.org>; Sat, 18 Jun 2005 06:25:24 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5IALDjn020362;
	Sat, 18 Jun 2005 03:21:13 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5IALDjp020361;
	Sat, 18 Jun 2005 03:21:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail12.svc.cra.dublin.eircom.net (mail12.svc.cra.dublin.eircom.net [159.134.118.28])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j5IALCQc020305
	for <atom-syntax@imc.org>; Sat, 18 Jun 2005 03:21:12 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 92502 messnum 5764055 invoked from network[83.70.250.40/83-70-250-40.b-ras1.prp.dublin.eircom.net]); 18 Jun 2005 10:21:05 -0000
Received: from 83-70-250-40.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.250.40)
  by mail12.svc.cra.dublin.eircom.net (qp 92502) with SMTP; 18 Jun 2005 10:21:05 -0000
Message-ID: <42B3F590.4000007@dehora.net>
Date: Sat, 18 Jun 2005 11:21:04 +0100
From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Eric Scheid <eric.scheid@ironclad.net.au>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Polling Sucks! (was RE: Atom feed synchronization)
References: <BED9BE93.5F595%eric.scheid@ironclad.net.au>
In-Reply-To: <BED9BE93.5F595%eric.scheid@ironclad.net.au>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


Eric Scheid wrote:

> how does Atom over XMPP help in this scenario:
> 
> 1) wake up
> 2) scratch myself, stagger around in morning fog
> 3) turn on computer, launch feed reader
> 4) wonder what changes happened during the night

This is not the thread you're looking for - go back to bed!

cheers
Bill



From owner-atom-syntax@mail.imc.org  Sat Jun 18 07:59:47 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04166
	for <atompub-archive@lists.ietf.org>; Sat, 18 Jun 2005 07:59:46 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5IBp9w1027443;
	Sat, 18 Jun 2005 04:51:09 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5IBp95E027442;
	Sat, 18 Jun 2005 04:51:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mta08-winn.ispmail.ntl.com (mta08-winn.ispmail.ntl.com [81.103.221.48])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5IBp6x0027192
	for <atom-syntax@imc.org>; Sat, 18 Jun 2005 04:51:07 -0700 (PDT)
	(envelope-from djpowell@djpowell.net)
Received: from aamta09-winn.ispmail.ntl.com ([81.103.221.35])
          by mta08-winn.ispmail.ntl.com with ESMTP
          id <20050618115100.EFFU6773.mta08-winn.ispmail.ntl.com@aamta09-winn.ispmail.ntl.com>;
          Sat, 18 Jun 2005 12:51:00 +0100
Received: from cpc2-stok1-5-0-cust90.bagu.cable.ntl.com ([81.111.201.90])
          by aamta09-winn.ispmail.ntl.com with ESMTP
          id <20050618115100.FLWH26865.aamta09-winn.ispmail.ntl.com@cpc2-stok1-5-0-cust90.bagu.cable.ntl.com>;
          Sat, 18 Jun 2005 12:51:00 +0100
Date: Sat, 18 Jun 2005 12:50:58 +0100
From: David Powell <djpowell@djpowell.net>
X-Mailer: The Bat! (v3.5.24) Professional
X-Priority: 3 (Normal)
Message-ID: <1637474612.20050618125058@djpowell.net>
To: Tim Bray <Tim.Bray@Sun.COM>
CC: Mark Baker <distobj@acm.org>, duerst@it.aoyama.ac.jp, ans208@mail.usask.ca,
        <atom-syntax@imc.org>
Subject: Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
In-Reply-To: <2E68D5C0-189B-4FCC-9D6F-201F28FC2A58@sun.com>
References: <20050617140542.GX20401@markbaker.ca>
 <2E68D5C0-189B-4FCC-9D6F-201F28FC2A58@sun.com>
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>
Content-Transfer-Encoding: 7bit



Friday, June 17, 2005, 6:14:38 PM, you wrote:

> Uh, has Mark spotted a dumb bug here that we should fix?  Do we care
> if *remote* content is of a composite MIME type?  My feeling was that
> we ruled out composite types in *local* content, for fairly obvious
> reasons.  The fix is obvious, in 4.1.3.1

> "Failing that, it MUST be a MIME media type.  If the "src" attribute
> is not provided, i.e. the content is local, the value of the "type"
> attribute MUST NOT be a composite type... "

> -Tim

Can somebody give me a link to where we discussed the requirement that
atom:content MUST NOT contain a composite type? I've tried searching my
archive but I couldn't find anything at all. The change was introduced
in draft-08.

I can't agree that this is a mere spec bug until I can find where it
was discussed, and what the intent for this ban was.

I don't really see why we are banning these MIME types from either
local or remote content.

-- 
Dave



From owner-atom-syntax@mail.imc.org  Sat Jun 18 08:03:24 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04505
	for <atompub-archive@lists.ietf.org>; Sat, 18 Jun 2005 08:03:24 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5IBtUrL033646;
	Sat, 18 Jun 2005 04:55:30 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5IBtURm033645;
	Sat, 18 Jun 2005 04:55:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail02.svc.cra.dublin.eircom.net (mail02.svc.cra.dublin.eircom.net [159.134.118.18])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j5IBtT8E033489
	for <atom-syntax@imc.org>; Sat, 18 Jun 2005 04:55:29 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 58767 messnum 5401412 invoked from network[83.70.250.40/83-70-250-40.b-ras1.prp.dublin.eircom.net]); 18 Jun 2005 11:55:23 -0000
Received: from 83-70-250-40.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.250.40)
  by mail02.svc.cra.dublin.eircom.net (qp 58767) with SMTP; 18 Jun 2005 11:55:23 -0000
Message-ID: <42B40BA9.3000803@dehora.net>
Date: Sat, 18 Jun 2005 12:55:21 +0100
From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Henry Story <henry.story@bblfish.net>
CC: James M Snell <jasnell@gmail.com>, Sam Ruby <rubys@intertwingly.net>,
        atom-syntax Syntax <atom-syntax@imc.org>,
        Danny Ayers <danny.ayers@gmail.com>
Subject: Re: first request for an atom extension: Re: Polling Sucks! (was
 RE: Atom feed synchronization)
References: <3f1451f5050617150963c2e5aa@mail.gmail.com>	 <200506172240.DKV29162@ms8.netsolmail.com> <3f1451f5050617181373895c15@mail.gmail.com> <42B3818C.2020608@intertwingly.net> <42B3A2AA.40007@gmail.com> <313800B8-40BE-44B1-B80A-696B7653987F@bblfish.net>
In-Reply-To: <313800B8-40BE-44B1-B80A-696B7653987F@bblfish.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


Henry Story wrote:
> 
> [...]  Something like:
> 
> <link rel="http://.../next" href="http://bblfish.net/blog/archive/ 
> 2005-05-10.atom">
> 
> would be really useful. 

Henry,

Mark Nottingham did something on this a while back; try digging through 
the archives.

cheers
Bill




From owner-atom-syntax@mail.imc.org  Sat Jun 18 08:49:40 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07915
	for <atompub-archive@lists.ietf.org>; Sat, 18 Jun 2005 08:49:40 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5ICexiF095027;
	Sat, 18 Jun 2005 05:40:59 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5ICexsY095025;
	Sat, 18 Jun 2005 05:40:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5ICewFo095008
	for <atom-syntax@imc.org>; Sat, 18 Jun 2005 05:40:58 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from [192.168.1.101] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65])
	(authenticated bits=0)
	by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j5IChPpW027501;
	Sat, 18 Jun 2005 08:43:29 -0400
Message-ID: <42B41654.8030004@intertwingly.net>
Date: Sat, 18 Jun 2005 08:40:52 -0400
From: Sam Ruby <rubys@intertwingly.net>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: David Powell <djpowell@djpowell.net>
CC: atom-syntax@imc.org
Subject: Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing
 Lists
References: <20050617140542.GX20401@markbaker.ca> <2E68D5C0-189B-4FCC-9D6F-201F28FC2A58@sun.com> <1637474612.20050618125058@djpowell.net>
In-Reply-To: <1637474612.20050618125058@djpowell.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


David Powell wrote:
> 
> Friday, June 17, 2005, 6:14:38 PM, you wrote:
> 
>>Uh, has Mark spotted a dumb bug here that we should fix?  Do we care
>>if *remote* content is of a composite MIME type?  My feeling was that
>>we ruled out composite types in *local* content, for fairly obvious
>>reasons.  The fix is obvious, in 4.1.3.1
> 
> 
>>"Failing that, it MUST be a MIME media type.  If the "src" attribute
>>is not provided, i.e. the content is local, the value of the "type"
>>attribute MUST NOT be a composite type... "
> 
>>-Tim
> 
> Can somebody give me a link to where we discussed the requirement that
> atom:content MUST NOT contain a composite type? I've tried searching my
> archive but I couldn't find anything at all. The change was introduced
> in draft-08.
> 
> I can't agree that this is a mere spec bug until I can find where it
> was discussed, and what the intent for this ban was.
> 
> I don't really see why we are banning these MIME types from either
> local or remote content.

http://www.intertwingly.net/wiki/pie/PaceReformedContent3

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Sat Jun 18 10:14:46 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15178
	for <atompub-archive@lists.ietf.org>; Sat, 18 Jun 2005 10:14:45 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5IE1NoB002153;
	Sat, 18 Jun 2005 07:01:23 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5IE1NnS002152;
	Sat, 18 Jun 2005 07:01:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.201])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5IE1M9W002072
	for <atom-syntax@imc.org>; Sat, 18 Jun 2005 07:01:23 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by zproxy.gmail.com with SMTP id 13so62372nzp
        for <atom-syntax@imc.org>; Sat, 18 Jun 2005 07:01:17 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=pX7u+0pqt6vuZAS+LqIA7yzLOBv74a16cIsAPyA4QIPXgHYKySB9ThgD35dZuuMKJ4RoFnLSnZonIIvi/RzbVSe9W6VGHqqZGU3ft1mdZASsyviCuCPfXJl2jL+aXEAkM5kOrX1hxvS0NbwDDrAvnvF0dCDnzBvckIZS4iGCJNM=
Received: by 10.36.220.79 with SMTP id s79mr2029551nzg;
        Sat, 18 Jun 2005 07:01:16 -0700 (PDT)
Received: by 10.36.61.20 with HTTP; Sat, 18 Jun 2005 07:01:16 -0700 (PDT)
Message-ID: <3f1451f505061807016c17d4e0@mail.gmail.com>
Date: Sat, 18 Jun 2005 10:01:16 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
Reply-To: Joe Gregorio <joe.gregorio@gmail.com>
To: Sam Ruby <rubys@intertwingly.net>
Subject: Re: Polling Sucks! (was RE: Atom feed synchronization)
Cc: atom-syntax@imc.org
In-Reply-To: <42B3818C.2020608@intertwingly.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
References: <3f1451f5050617150963c2e5aa@mail.gmail.com>
	 <200506172240.DKV29162@ms8.netsolmail.com>
	 <3f1451f5050617181373895c15@mail.gmail.com>
	 <42B3818C.2020608@intertwingly.net>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j5IE1N9W002146
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: 8bit


On 6/17/05, Sam Ruby <rubys@intertwingly.net> wrote:
> P.S.  Why is this on atom-sytax?  Is there a concrete proposal we are
> talking about here?  Is there likely to be?

Were you expecting [atom-syntax] to vanish in a puff of smoke
once we have a couple RFCs under our belt? Given the technology,
and the participants, I would expect [atom-syntax] to have the 
longevity of [xml-dev].

   -joe

-- 
Joe Gregorio        http://bitworking.org



From owner-atom-syntax@mail.imc.org  Sat Jun 18 10:21:41 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15836
	for <atompub-archive@lists.ietf.org>; Sat, 18 Jun 2005 10:21:41 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5IEEK7r019926;
	Sat, 18 Jun 2005 07:14:20 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5IEEKJt019924;
	Sat, 18 Jun 2005 07:14:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5IEEJ92019640
	for <atom-syntax@imc.org>; Sat, 18 Jun 2005 07:14:19 -0700 (PDT)
	(envelope-from sayrer@gmail.com)
Received: by wproxy.gmail.com with SMTP id 70so74237wra
        for <atom-syntax@imc.org>; Sat, 18 Jun 2005 07:14:14 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=Qpf1E9rU8xe6xtI3r8Ov3TZc2Gw0Qo5vT1WrVJ3G/xLKKOwaZVKz9yaoRT4q1bPGvj5qsKN1bw+EJe14WGD15z/zV4XMpVOoH0v7NFIaWBxWg05mcGM7qFAmuqIGLtOKVc4smoHX/zcLkL96wTOPUKG5hgMrxrVzFcb5vT+23FM=
Received: by 10.54.114.6 with SMTP id m6mr1115935wrc;
        Sat, 18 Jun 2005 07:14:14 -0700 (PDT)
Received: by 10.54.71.13 with HTTP; Sat, 18 Jun 2005 07:14:14 -0700 (PDT)
Message-ID: <68fba5c5050618071433dbcf01@mail.gmail.com>
Date: Sat, 18 Jun 2005 10:14:14 -0400
From: Robert Sayre <sayrer@gmail.com>
Reply-To: Robert Sayre <sayrer@gmail.com>
To: Joe Gregorio <joe.gregorio@gmail.com>
Subject: Re: Polling Sucks! (was RE: Atom feed synchronization)
Cc: Sam Ruby <rubys@intertwingly.net>, atom-syntax@imc.org
In-Reply-To: <3f1451f505061807016c17d4e0@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
References: <3f1451f5050617150963c2e5aa@mail.gmail.com>
	 <200506172240.DKV29162@ms8.netsolmail.com>
	 <3f1451f5050617181373895c15@mail.gmail.com>
	 <42B3818C.2020608@intertwingly.net>
	 <3f1451f505061807016c17d4e0@mail.gmail.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j5IEEJ92019917
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: 8bit


On 6/18/05, Joe Gregorio <joe.gregorio@gmail.com> wrote:
> 
> On 6/17/05, Sam Ruby <rubys@intertwingly.net> wrote:
> > P.S.  Why is this on atom-sytax?  Is there a concrete proposal we are
> > talking about here?  Is there likely to be?
> 
> Were you expecting [atom-syntax] to vanish in a puff of smoke
> once we have a couple RFCs under our belt? Given the technology,
> and the participants, I would expect [atom-syntax] to have the
> longevity of [xml-dev].

Nooooooooooooooooooo



From owner-atom-syntax@mail.imc.org  Sat Jun 18 10:22:06 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15884
	for <atompub-archive@lists.ietf.org>; Sat, 18 Jun 2005 10:22:06 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5IEAn6d014918;
	Sat, 18 Jun 2005 07:10:49 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5IEAneP014917;
	Sat, 18 Jun 2005 07:10:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5IEAm73014880
	for <atom-syntax@imc.org>; Sat, 18 Jun 2005 07:10:48 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from [192.168.1.101] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65])
	(authenticated bits=0)
	by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j5IEDK4a003600;
	Sat, 18 Jun 2005 10:13:20 -0400
Message-ID: <42B42B66.8020501@intertwingly.net>
Date: Sat, 18 Jun 2005 10:10:46 -0400
From: Sam Ruby <rubys@intertwingly.net>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Joe Gregorio <joe.gregorio@gmail.com>
CC: atom-syntax@imc.org
Subject: Re: Polling Sucks! (was RE: Atom feed synchronization)
References: <3f1451f5050617150963c2e5aa@mail.gmail.com>	 <200506172240.DKV29162@ms8.netsolmail.com>	 <3f1451f5050617181373895c15@mail.gmail.com>	 <42B3818C.2020608@intertwingly.net> <3f1451f505061807016c17d4e0@mail.gmail.com>
In-Reply-To: <3f1451f505061807016c17d4e0@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


Joe Gregorio wrote:
> On 6/17/05, Sam Ruby <rubys@intertwingly.net> wrote:
> 
>>P.S.  Why is this on atom-sytax?  Is there a concrete proposal we are
>>talking about here?  Is there likely to be?
> 
> Were you expecting [atom-syntax] to vanish in a puff of smoke
> once we have a couple RFCs under our belt? Given the technology,
> and the participants, I would expect [atom-syntax] to have the 
> longevity of [xml-dev].

Silly me.  And here I thought it fertile grounds for a protocol 
discussion.  Carry on, then.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Sat Jun 18 10:44:57 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17500
	for <atompub-archive@lists.ietf.org>; Sat, 18 Jun 2005 10:44:56 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5IEdGQP052563;
	Sat, 18 Jun 2005 07:39:16 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5IEdGoM052562;
	Sat, 18 Jun 2005 07:39:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mta08-winn.ispmail.ntl.com (mta08-winn.ispmail.ntl.com [81.103.221.48])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5IEdFim052386
	for <atom-syntax@imc.org>; Sat, 18 Jun 2005 07:39:15 -0700 (PDT)
	(envelope-from djpowell@djpowell.net)
Received: from aamta12-winn.ispmail.ntl.com ([81.103.221.35])
          by mta08-winn.ispmail.ntl.com with ESMTP
          id <20050618143909.GTME6773.mta08-winn.ispmail.ntl.com@aamta12-winn.ispmail.ntl.com>;
          Sat, 18 Jun 2005 15:39:09 +0100
Received: from cpc2-stok1-5-0-cust90.bagu.cable.ntl.com ([81.111.201.90])
          by aamta12-winn.ispmail.ntl.com with ESMTP
          id <20050618143909.BWLT15401.aamta12-winn.ispmail.ntl.com@cpc2-stok1-5-0-cust90.bagu.cable.ntl.com>;
          Sat, 18 Jun 2005 15:39:09 +0100
Date: Sat, 18 Jun 2005 15:39:07 +0100
From: David Powell <djpowell@djpowell.net>
X-Mailer: The Bat! (v3.5.24) Professional
X-Priority: 3 (Normal)
Message-ID: <1264126261.20050618153907@djpowell.net>
To: Sam Ruby <rubys@intertwingly.net>
CC: atom-syntax@imc.org
Subject: Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
In-Reply-To: <42B41654.8030004@intertwingly.net>
References: <20050617140542.GX20401@markbaker.ca>
 <2E68D5C0-189B-4FCC-9D6F-201F28FC2A58@sun.com>
 <1637474612.20050618125058@djpowell.net> <42B41654.8030004@intertwingly.net>
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>
Content-Transfer-Encoding: 7bit



Saturday, June 18, 2005, 1:40:52 PM, Sam Ruby wrote:

>> Can somebody give me a link to where we discussed the requirement that
>> atom:content MUST NOT contain a composite type? I've tried searching my
>> archive but I couldn't find anything at all. The change was introduced
>> in draft-08.
>> 
>> I can't agree that this is a mere spec bug until I can find where it
>> was discussed, and what the intent for this ban was.
>> 
>> I don't really see why we are banning these MIME types from either
>> local or remote content.

> http://www.intertwingly.net/wiki/pie/PaceReformedContent3

Thanks, but is that really the same discussion? That proposal was
incorporated into draft-03. The prohibition of "composite types"
wasn't introduced until draft-08.

One of the main effects of PaceReformedContent3 was banning the
Atom-0.3-style "multipart/alternative" envelope that allowed multiple
<content> elements to be embedded.

Fair enough - but I don't see how this is related to the prohibition
of message/* and multipart/*?

Was this a heavy-handed attempt to prevent people from using Atom 0.3-
style alternatives in Atom 1.0, perhaps?

-- 
Dave



From owner-atom-syntax@mail.imc.org  Sat Jun 18 11:14:26 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19642
	for <atompub-archive@lists.ietf.org>; Sat, 18 Jun 2005 11:14:26 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5IF10JP076203;
	Sat, 18 Jun 2005 08:01:00 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5IF10KG076202;
	Sat, 18 Jun 2005 08:01:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mta07-winn.ispmail.ntl.com (mta07-winn.ispmail.ntl.com [81.103.221.47])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5IF0v8Z076135
	for <atom-syntax@imc.org>; Sat, 18 Jun 2005 08:00:58 -0700 (PDT)
	(envelope-from djpowell@djpowell.net)
Received: from aamta10-winn.ispmail.ntl.com ([81.103.221.35])
          by mta07-winn.ispmail.ntl.com with ESMTP
          id <20050618150051.YZXQ6745.mta07-winn.ispmail.ntl.com@aamta10-winn.ispmail.ntl.com>;
          Sat, 18 Jun 2005 16:00:51 +0100
Received: from cpc2-stok1-5-0-cust90.bagu.cable.ntl.com ([81.111.201.90])
          by aamta10-winn.ispmail.ntl.com with ESMTP
          id <20050618150051.EAAS24546.aamta10-winn.ispmail.ntl.com@cpc2-stok1-5-0-cust90.bagu.cable.ntl.com>;
          Sat, 18 Jun 2005 16:00:51 +0100
Date: Sat, 18 Jun 2005 16:00:49 +0100
From: David Powell <djpowell@djpowell.net>
X-Mailer: The Bat! (v3.5.24) Professional
X-Priority: 3 (Normal)
Message-ID: <147735454.20050618160049@djpowell.net>
To: Tim Bray <Tim.Bray@Sun.COM>
CC: Mark Baker <distobj@acm.org>, duerst@it.aoyama.ac.jp, ans208@mail.usask.ca,
        <atom-syntax@imc.org>
Subject: Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
In-Reply-To: <2E68D5C0-189B-4FCC-9D6F-201F28FC2A58@sun.com>
References: <20050617140542.GX20401@markbaker.ca>
 <2E68D5C0-189B-4FCC-9D6F-201F28FC2A58@sun.com>
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>
Content-Transfer-Encoding: 7bit



Friday, June 17, 2005, 6:14:38 PM, Tim Bray wrote:

> My feeling was that we ruled out composite types in *local* content
> [...]

I'm still looking, but my suspicion is that we never did rule them
out, and that this restriction crept in during some editorial
rephrasing.

> [...] for fairly obvious reasons.

I don't know what the obvious reasons are...

Lack of client support? - hardly seems a reason to ban a MIME type,
else there is a huge list of ones that we should ban at IANA.

We are defining a data format here. If publishers want to publish
entries as text, message/rfc-822, application/msword, image/jp2, or
whatever, then that is up to them. I don't see how we can justify a
MUST NOT requirement for "composite types".

> The fix is obvious, in 4.1.3.1

> "Failing that, it MUST be a MIME media type.  If the "src" attribute
> is not provided, i.e. the content is local, the value of the "type"
> attribute MUST NOT be a composite type... "

I'm in favour of replacing:

  "Failing that, it MUST be a MIME media type, but MUST NOT be a
  composite type (see Section 4.2.6 of [MIMEREG])."

with:

  "Failing that, it MUST be a MIME media type."

  
-- 
Dave



From owner-atom-syntax@mail.imc.org  Sat Jun 18 11:47:37 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21547
	for <atompub-archive@lists.ietf.org>; Sat, 18 Jun 2005 11:47:36 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5IFfYll020586;
	Sat, 18 Jun 2005 08:41:34 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5IFfYJP020585;
	Sat, 18 Jun 2005 08:41:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5IFfXqN020478
	for <atom-syntax@imc.org>; Sat, 18 Jun 2005 08:41:33 -0700 (PDT)
	(envelope-from sayrer@gmail.com)
Received: by wproxy.gmail.com with SMTP id 69so98778wra
        for <atom-syntax@imc.org>; Sat, 18 Jun 2005 08:40:54 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=r+ktMC21eLLpuUL4C1aOiRkwUrvA+NHjdsMR6eCxVIpfjtlKhOFK2PJbwfTNlzGuec6v/rkgagW0I75FUPtTU0OSfjvgKJ0bBj3NZNUlXlFjxmkHx9C80D7m+L6kZYgKZoEpUcpSq8QW0xnqtKFyaxyzbnXfO89aGXlH0lP1TWk=
Received: by 10.54.106.2 with SMTP id e2mr1823799wrc;
        Sat, 18 Jun 2005 08:40:54 -0700 (PDT)
Received: by 10.54.71.13 with HTTP; Sat, 18 Jun 2005 08:40:54 -0700 (PDT)
Message-ID: <68fba5c505061808402d75fb88@mail.gmail.com>
Date: Sat, 18 Jun 2005 11:40:54 -0400
From: Robert Sayre <sayrer@gmail.com>
Reply-To: Robert Sayre <sayrer@gmail.com>
To: David Powell <djpowell@djpowell.net>
Subject: Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
Cc: Tim Bray <Tim.Bray@Sun.COM>, Mark Baker <distobj@acm.org>,
        duerst@it.aoyama.ac.jp, ans208@mail.usask.ca, atom-syntax@imc.org
In-Reply-To: <147735454.20050618160049@djpowell.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
References: <20050617140542.GX20401@markbaker.ca>
	 <2E68D5C0-189B-4FCC-9D6F-201F28FC2A58@sun.com>
	 <147735454.20050618160049@djpowell.net>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j5IFfXqN020576
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: 8bit


On 6/18/05, David Powell <djpowell@djpowell.net> wrote:
> 
> 
> Friday, June 17, 2005, 6:14:38 PM, Tim Bray wrote:
> 
> > My feeling was that we ruled out composite types in *local* content
> > [...]
> 
> I'm still looking, but my suspicion is that we never did rule them
> out, and that this restriction crept in during some editorial
> rephrasing.

Incorrect. Multipart content presents an accessibility issue because
the entry metadata is no longer sufficiently granular. There would
have to be Atom metadata for each part.[0]

Robert Sayre

[0] http://www.imc.org/atom-syntax/mail-archive/msg09357.html



From owner-atom-syntax@mail.imc.org  Sat Jun 18 12:13:22 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23574
	for <atompub-archive@lists.ietf.org>; Sat, 18 Jun 2005 12:13:22 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5IG0L6e041555;
	Sat, 18 Jun 2005 09:00:21 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5IG0Kbr041554;
	Sat, 18 Jun 2005 09:00:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.gmx.net (pop.gmx.de [213.165.64.20])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j5IG0I4q041435
	for <atom-syntax@imc.org>; Sat, 18 Jun 2005 09:00:19 -0700 (PDT)
	(envelope-from pagaltzis@gmx.de)
Received: (qmail invoked by alias); 18 Jun 2005 16:00:12 -0000
Received: from xdsl-81-173-174-102.netcologne.de (EHLO klangraum) [81.173.174.102]
  by mail.gmx.net (mp017) with SMTP; 18 Jun 2005 18:00:12 +0200
X-Authenticated: #163624
Date: Sat, 18 Jun 2005 18:04:19 +0200
From: "A. Pagaltzis" <pagaltzis@gmx.de>
To: atom-syntax@imc.org
Subject: Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
Message-ID: <20050618160419.GA25763@klangraum>
Mail-Followup-To: atom-syntax@imc.org
References: <20050617140542.GX20401@markbaker.ca> <2E68D5C0-189B-4FCC-9D6F-201F28FC2A58@sun.com> <147735454.20050618160049@djpowell.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <147735454.20050618160049@djpowell.net>
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: 8bit


* David Powell <djpowell@djpowell.net> [2005-06-18 17:15]:
> We are defining a data format here. If publishers want to
> publish entries as text, message/rfc-822, application/msword,
> image/jp2, or whatever, then that is up to them. I don't see
> how we can justify a MUST NOT requirement for "composite
> types".

I *do* see a problem with how Atom 0.3 overloaded the MIME type
to mean something completely different than “this is data that
you can feed a MIME envelope parser.”

I *don’t* see why composite types should be banned, rather than
handled the exact same way any other non-XML types are. I can
imagine this is because part of a multipart document could be an
XML document and there should not be a way for people to cheat
their way out of the restrictions on XML media types.

But that is only one of many use cases for envelopes. If that
really is reason enough for a blanket ban, then the other use
cases need to be accomodated somehow. E.g. how do I decompose
a message/rfc-822 in such a way that it can be stored in Atom?
And this mechanism should be explicitly designated in the spec as
the suggested way to deal with composite types. Unless we want
people to stick to RSS(+extension?) for that sort of thing…

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



From owner-atom-syntax@mail.imc.org  Sat Jun 18 13:11:50 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27213
	for <atompub-archive@lists.ietf.org>; Sat, 18 Jun 2005 13:11:50 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5IH4IH0010965;
	Sat, 18 Jun 2005 10:04:18 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5IH4Io4010963;
	Sat, 18 Jun 2005 10:04:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [10.20.30.249] (user-38lc0b7.dialup.mindspring.com [209.86.1.103])
	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5IH4Emc010893
	for <atom-syntax@imc.org>; Sat, 18 Jun 2005 10:04:16 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: <p0621021fbeda03280af2@[10.20.30.249]>
In-Reply-To: <42B3818C.2020608@intertwingly.net>
References: <3f1451f5050617150963c2e5aa@mail.gmail.com>	
 <200506172240.DKV29162@ms8.netsolmail.com>
 <3f1451f5050617181373895c15@mail.gmail.com>
 <42B3818C.2020608@intertwingly.net>
Date: Sat, 18 Jun 2005 10:04:01 -0700
To: Atom WG <atom-syntax@imc.org>
From: Paul Hoffman <phoffman@imc.org>
Subject: Re: Polling Sucks! (was RE: Atom feed synchronization)
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>


At 10:06 PM -0400 6/17/05, Sam Ruby wrote:
>P.S.  Why is this on atom-sytax?  Is there a concrete proposal we 
>are talking about here?  Is there likely to be?

Wearing my co-chair hat:

IETF WG mailing lists are normally used for creating specs that are 
listed in the charter. They are also used for general discussion on 
the topic of the WG, even if that general discussion is not covered 
in the charter. The latter is perfectly proper if it does not 
interfere with the former.

This WG is now in a waiting state on the format draft, and is 
actively discussing the protocol draft on a different mailing list 
(atom-protocol@imc.org). Thus, discussions of things related to the 
use of the Atom format is fine on this list as long as it doesn't get 
"out of hand", for some very vague definition of "out of hand".

Discussions that might lead to individual (non-WG) submissions of 
Internet Drafts are expressly encouraged at this time. That is not to 
say "let's start adding a bunch of needless extensions and 
provisions", but certainly "I see a need and I think I might propose 
a solution" is a Very Good Thing for this list.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Sat Jun 18 14:23:49 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01521
	for <atompub-archive@lists.ietf.org>; Sat, 18 Jun 2005 14:23:49 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5IIGgEF092489;
	Sat, 18 Jun 2005 11:16:42 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5IIGgNw092488;
	Sat, 18 Jun 2005 11:16:42 -0700 (PDT)
X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j5IIGdaw092473
	for <atom-syntax@imc.org>; Sat, 18 Jun 2005 11:16:40 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j5IIGdqg026234
	for <atom-syntax@imc.org>; Sat, 18 Jun 2005 12:16:39 -0600 (MDT)
Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004))
 with ESMTP id <0IIA00D95LFQS0@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Sat, 18 Jun 2005 12:16:39 -0600 (MDT)
Received: from [192.168.1.100] ([216.113.202.7])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004))
 with ESMTPSA id <0IIA00GC9LFP1L@mail.sun.net> for atom-syntax@imc.org; Sat,
 18 Jun 2005 12:16:38 -0600 (MDT)
Date: Sat, 18 Jun 2005 11:16:50 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Question on Use Case: Choosing atom:content's type when
 ArchivingMailing Lists
In-reply-to: <147735454.20050618160049@djpowell.net>
To: David Powell <djpowell@djpowell.net>
Cc: Mark Baker <distobj@acm.org>, duerst@it.aoyama.ac.jp, ans208@mail.usask.ca,
        atom-syntax@imc.org
Message-id: <3B14BEB3-8056-4D1F-9498-85B199C45484@Sun.COM>
MIME-version: 1.0
X-Mailer: Apple Mail (2.730)
Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Content-transfer-encoding: 7BIT
X-Priority: 3 (Normal)
References: <20050617140542.GX20401@markbaker.ca>
 <2E68D5C0-189B-4FCC-9D6F-201F28FC2A58@sun.com>
 <147735454.20050618160049@djpowell.net>
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: 7BIT



On Jun 18, 2005, at 8:00 AM, David Powell wrote:

>
> Friday, June 17, 2005, 6:14:38 PM, Tim Bray wrote:
>
>
>> My feeling was that we ruled out composite types in *local* content
>> [...]
>>
>
> I'm still looking, but my suspicion is that we never did rule them
> out, and that this restriction crept in during some editorial
> rephrasing.

<co-chair-mode>I disagree.  Atom 0.3 had explicit built-in support  
for multipart, and there was strong (not rough) consensus support for  
retiring that and replacing it with the language in the current draft.

My recollection of the debate is that it was exclusively focused on  
the problems of multipart in the document, thus I proposed to the WG  
that we did not in fact have consensus of banning it in external  
content; the feedback so far is supportive of the notion that that's  
a bug in the spec.
</co-chair-mode>



From owner-atom-syntax@mail.imc.org  Sat Jun 18 15:46:10 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08598
	for <atompub-archive@lists.ietf.org>; Sat, 18 Jun 2005 15:46:09 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5IJbUB5083927;
	Sat, 18 Jun 2005 12:37:30 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5IJbUqF083926;
	Sat, 18 Jun 2005 12:37:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5IJbTRv083831
	for <atom-syntax@imc.org>; Sat, 18 Jun 2005 12:37:29 -0700 (PDT)
	(envelope-from dtcd@mac.com)
Received: from [10.0.1.2] (data-csmail2 [192.168.2.2])
	by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j5IJaMnS027640;
	Sat, 18 Jun 2005 20:36:32 +0100 (BST)
In-Reply-To: <2E68D5C0-189B-4FCC-9D6F-201F28FC2A58@sun.com>
References: <20050617140542.GX20401@markbaker.ca> <2E68D5C0-189B-4FCC-9D6F-201F28FC2A58@sun.com>
Mime-Version: 1.0 (Apple Message framework v730)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <97E083D2-D625-4CAB-96C3-24EFE6483A99@mac.com>
Cc: Atom Syntax <atom-syntax@imc.org>
Content-Transfer-Encoding: 7bit
From: Graham <dtcd@mac.com>
Subject: Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
Date: Sat, 18 Jun 2005 20:36:20 +0100
To: Tim Bray <Tim.Bray@Sun.COM>
X-Mailer: Apple Mail (2.730)
X-MailScanner-Information: Oxford Brookes University MailScanner
X-MailScanner: Clean
X-MailScanner-From: dtcd@mac.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>
Content-Transfer-Encoding: 7bit


On 17 Jun 2005, at 6:14 pm, Tim Bray wrote:

> Uh, has Mark spotted a dumb bug here that we should fix?  Do we  
> care if *remote* content is of a composite MIME type?  My feeling  
> was that we ruled out composite types in *local* content, for  
> fairly obvious reasons.  The fix is obvious, in 4.1.3.1

I don't think it's a dumb bug. A composite type is more than a single  
piece of content. Using atom:content this way is wrong, since  
conceptually it produces this:

<atom:entry>
   <atom:title>Message Subject<atom:title>
   <atom:author><atom:name>An author</atom:name></atom:author>
   <atom:content>
<!-- Translating the email headers to Atom -->
     <atom:title>Message Subject<atom:title>
     <atom:author><atom:name>An author</atom:name></atom:author>
     <atom:content>Message body</atom:content>
   </atom:content>
</atom:entry>

The better way to do this is to use <atom:link rel="alternate"> to  
reference the messages.

-1 to the proposal, at least for this use case.

Graham



From owner-atom-syntax@mail.imc.org  Sat Jun 18 16:23:43 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10969
	for <atompub-archive@lists.ietf.org>; Sat, 18 Jun 2005 16:23:43 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5IKFoh2026738;
	Sat, 18 Jun 2005 13:15:50 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5IKFoWu026734;
	Sat, 18 Jun 2005 13:15:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtp.wp.pl (smtp.wp.pl [212.77.101.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5IKFnSD026613
	for <atom-syntax@imc.org>; Sat, 18 Jun 2005 13:15:50 -0700 (PDT)
	(envelope-from ddooss@wp.pl)
Received: (wp-smtpd smtp.wp.pl 9158 invoked from network); 18 Jun 2005 22:15:42 +0200
Received: from 50-host.net.bialystok.pl (HELO [127.0.0.1]) (ddooss@[81.15.254.50])
          (envelope-sender <ddooss@wp.pl>)
          by smtp.wp.pl (WP-SMTPD) with SMTP
          for <atom-syntax@imc.org>; 18 Jun 2005 22:15:42 +0200
Message-ID: <42B480F6.5020807@wp.pl>
Date: Sat, 18 Jun 2005 22:15:50 +0200
From: Domel <ddooss@wp.pl>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl-PL; rv:1.7) Gecko/20040616
X-Accept-Language: pl, en-us, en
MIME-Version: 1.0
To: atom-syntax@imc.org
Subject: question about future
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 7bit
X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A.
X-WP-SPAM: NO AS1=NO(Body=1 Fuz1=1) AS2=NO(0.719293) AS3=NO AS4=NO                                 
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: 7bit


How many drafts will you planing to publish to Atom 1.0?


 



From owner-atom-syntax@mail.imc.org  Sat Jun 18 16:50:20 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12726
	for <atompub-archive@lists.ietf.org>; Sat, 18 Jun 2005 16:50:19 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5IKeKnl057204;
	Sat, 18 Jun 2005 13:40:21 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5IKeKdY057203;
	Sat, 18 Jun 2005 13:40:20 -0700 (PDT)
X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j5IKeJT8057140
	for <atom-syntax@imc.org>; Sat, 18 Jun 2005 13:40:19 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j5IKeIw4001374
	for <atom-syntax@imc.org>; Sat, 18 Jun 2005 14:40:18 -0600 (MDT)
Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004))
 with ESMTP id <0IIA00DOGS36S0@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Sat, 18 Jun 2005 14:40:18 -0600 (MDT)
Received: from [192.168.1.100] ([216.113.202.7])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004))
 with ESMTPSA id <0IIA00GG3S2Z1L@mail.sun.net> for atom-syntax@imc.org; Sat,
 18 Jun 2005 14:40:18 -0600 (MDT)
Date: Sat, 18 Jun 2005 13:40:24 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: question about future
In-reply-to: <42B480F6.5020807@wp.pl>
To: Domel <ddooss@wp.pl>
Cc: atom-syntax@imc.org
Message-id: <7FF5D61F-43EE-4AA5-80AE-4702BCE6DD19@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.730)
Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Content-transfer-encoding: 7BIT
References: <42B480F6.5020807@wp.pl>
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: 7BIT



On Jun 18, 2005, at 1:15 PM, Domel wrote:

>
> How many drafts will you planing to publish to Atom 1.0?

That depends on what the IESG says at their meeting of June 23rd.  If  
they say "OK" there will be a last draft to fix some typos and bugs  
that people have turned up in -09 and include the final namespace and  
so on.  If they request changes it gets more complicated. -Tim

>
>
>
>



From owner-atom-syntax@mail.imc.org  Sat Jun 18 17:12:29 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14087
	for <atompub-archive@lists.ietf.org>; Sat, 18 Jun 2005 17:12:28 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5IKxx9D080671;
	Sat, 18 Jun 2005 13:59:59 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5IKxxdJ080667;
	Sat, 18 Jun 2005 13:59:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5IKxxOe080488
	for <atom-syntax@imc.org>; Sat, 18 Jun 2005 13:59:59 -0700 (PDT)
	(envelope-from antone@geckotribe.com)
Received: from geckotribe.com (c-67-169-250-63.hsd1.ut.comcast.net[67.169.250.63])
          by comcast.net (rwcrmhc12) with SMTP
          id <2005061820595301400lmj60e>; Sat, 18 Jun 2005 20:59:53 +0000
Date: Sat, 18 Jun 2005 14:59:51 -0600
Subject: Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v553)
From: Antone Roundy <antone@geckotribe.com>
To: atom-syntax@imc.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <97E083D2-D625-4CAB-96C3-24EFE6483A99@mac.com>
Message-Id: <E9DF99CE-E03B-11D9-BB67-003065EA6144@geckotribe.com>
X-Mailer: Apple Mail (2.553)
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: 7bit


On Saturday, June 18, 2005, at 01:36  PM, Graham wrote:
> On 17 Jun 2005, at 6:14 pm, Tim Bray wrote:
>> Uh, has Mark spotted a dumb bug here that we should fix?  Do we care 
>> if *remote* content is of a composite MIME type?  My feeling was that 
>> we ruled out composite types in *local* content, for fairly obvious 
>> reasons.  The fix is obvious, in 4.1.3.1
I would have no objection to this, since the spec already creates the 
expectation that remote content will be less widely supported than 
local content.

> The better way to do this is to use <atom:link rel="alternate"> to 
> reference the messages.
This is certainly a better solution than multipart local content, and 
would hope that people would do remote content this way too unless they 
have a really good reason for multipart remote content.  But I could 
live with allowing multipart remote content if it's really needed in 
some case.



From owner-atom-syntax@mail.imc.org  Sat Jun 18 20:41:23 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28204
	for <atompub-archive@lists.ietf.org>; Sat, 18 Jun 2005 20:41:23 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5J0SeXa027653;
	Sat, 18 Jun 2005 17:28:40 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5J0Se5d027650;
	Sat, 18 Jun 2005 17:28:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mta07-winn.ispmail.ntl.com (mta07-winn.ispmail.ntl.com [81.103.221.47])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5J0ScMg027416
	for <atom-syntax@imc.org>; Sat, 18 Jun 2005 17:28:38 -0700 (PDT)
	(envelope-from djpowell@djpowell.net)
Received: from aamta12-winn.ispmail.ntl.com ([81.103.221.35])
          by mta07-winn.ispmail.ntl.com with ESMTP
          id <20050619002832.HRLV6745.mta07-winn.ispmail.ntl.com@aamta12-winn.ispmail.ntl.com>;
          Sun, 19 Jun 2005 01:28:32 +0100
Received: from cpc2-stok1-5-0-cust90.bagu.cable.ntl.com ([81.111.201.90])
          by aamta12-winn.ispmail.ntl.com with ESMTP
          id <20050619002832.FSIA15401.aamta12-winn.ispmail.ntl.com@cpc2-stok1-5-0-cust90.bagu.cable.ntl.com>;
          Sun, 19 Jun 2005 01:28:32 +0100
Date: Sun, 19 Jun 2005 01:28:29 +0100
From: David Powell <djpowell@djpowell.net>
X-Mailer: The Bat! (v3.5.28) Professional
X-Priority: 3 (Normal)
Message-ID: <388158077.20050619012829@djpowell.net>
To: Tim Bray <Tim.Bray@Sun.COM>
CC: Mark Baker <distobj@acm.org>, duerst@it.aoyama.ac.jp, ans208@mail.usask.ca,
        <atom-syntax@imc.org>
Subject: Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
In-Reply-To: <3B14BEB3-8056-4D1F-9498-85B199C45484@Sun.COM>
References: <20050617140542.GX20401@markbaker.ca>
 <2E68D5C0-189B-4FCC-9D6F-201F28FC2A58@sun.com>
 <147735454.20050618160049@djpowell.net>
 <3B14BEB3-8056-4D1F-9498-85B199C45484@Sun.COM>
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>
Content-Transfer-Encoding: 7bit



Saturday, June 18, 2005, 7:16:50 PM, Tim Bray wrote:

>>> My feeling was that we ruled out composite types in *local* content
>>> [...]
>>>
>>
>> I'm still looking, but my suspicion is that we never did rule them
>> out, and that this restriction crept in during some editorial
>> rephrasing.

> <co-chair-mode>I disagree.  Atom 0.3 had explicit built-in support  
> for multipart, and there was strong (not rough) consensus support for
> retiring that and replacing it with the language in the current draft.

<process-objection>

I disagree with the co-chair's call.

Yes, the Atom 0.3 "support" for multipart was broken and there was
strong consensus for removing it, as in the text of drafts 03 to 07.

But, there doesn't seem to have been any discussion or consensus
whatsoever for the prohibition of composite MIME types in content,
such as message/*, that was introduced in 08.

In fact the conclusion of the debate that Robert pointed to [1], was
that the types allowed by atom:content remained unrestricted.

</process-objection>


Atom 0.3 multiparts forced a dubious and complex processing model on
everyone wanting to process Atom documents. This problem was solved by
their removal in the 03 to 07 drafts.

The prohibition of composite types in the 08 draft (made many months
later) is something quite different. Composite types don't impose any
change in the processing model of user-agents, they are just blobs
that get passed to a MIME processor; there is no justification for
restricting Atom payloads to a subset of the MIME type space.

The restriction is just arbitrary: it disallows MHTML Word documents
and RFC822 emails, but allows application/msword Word documents and
application/zip.

Let's be clear: composites probably won't be used by bloggers, or
supported by blogging aggregators; but this isn't an excuse for this
explicit blanket ban.

> My recollection of the debate is that it was exclusively focused on
> the problems of multipart in the document, thus I proposed to the WG  
> that we did not in fact have consensus of banning it in external  
> content; the feedback so far is supportive of the notion that that's  
> a bug in the spec.

The earlier debate was on the problems in the 02 draft, which were
solved in the 03 draft. The restriction on the payload of atom:content
made in the 08 draft is a different issue, so the context of the
earlier debate isn't relevant.

[1] http://www.imc.org/atom-syntax/mail-archive/msg09357.html

-- 
Dave



From owner-atom-syntax@mail.imc.org  Sat Jun 18 20:44:51 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28545
	for <atompub-archive@lists.ietf.org>; Sat, 18 Jun 2005 20:44:51 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5J0bTvk037492;
	Sat, 18 Jun 2005 17:37:29 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5J0bRF0037460;
	Sat, 18 Jun 2005 17:37:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mta08-winn.ispmail.ntl.com (mta08-winn.ispmail.ntl.com [81.103.221.48])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5J0bOhX037194
	for <atom-syntax@imc.org>; Sat, 18 Jun 2005 17:37:24 -0700 (PDT)
	(envelope-from djpowell@djpowell.net)
Received: from aamta10-winn.ispmail.ntl.com ([81.103.221.35])
          by mta08-winn.ispmail.ntl.com with ESMTP
          id <20050619003718.OTQG6773.mta08-winn.ispmail.ntl.com@aamta10-winn.ispmail.ntl.com>;
          Sun, 19 Jun 2005 01:37:18 +0100
Received: from cpc2-stok1-5-0-cust90.bagu.cable.ntl.com ([81.111.201.90])
          by aamta10-winn.ispmail.ntl.com with ESMTP
          id <20050619003718.HVKP24546.aamta10-winn.ispmail.ntl.com@cpc2-stok1-5-0-cust90.bagu.cable.ntl.com>;
          Sun, 19 Jun 2005 01:37:18 +0100
Date: Sun, 19 Jun 2005 01:37:15 +0100
From: David Powell <djpowell@djpowell.net>
X-Mailer: The Bat! (v3.5.28) Professional
X-Priority: 3 (Normal)
Message-ID: <663488711.20050619013715@djpowell.net>
To: Robert Sayre <sayrer@gmail.com>
CC: atom-syntax@imc.org
Subject: Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
In-Reply-To: <68fba5c505061808402d75fb88@mail.gmail.com>
References: <20050617140542.GX20401@markbaker.ca>
 <2E68D5C0-189B-4FCC-9D6F-201F28FC2A58@sun.com>
 <147735454.20050618160049@djpowell.net>
 <68fba5c505061808402d75fb88@mail.gmail.com>
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>
Content-Transfer-Encoding: 7bit



Saturday, June 18, 2005, 4:40:54 PM, Robert Sayre wrote:

> Incorrect. Multipart content presents an accessibility issue because
> the entry metadata is no longer sufficiently granular. There would
> have to be Atom metadata for each part.[0]

A message/rfc822 email or an MHTML document with embedded images isn't
any more or less granular than an HTML document with linked images or
an application/zip file.

The granularity problem came from Atom 0.3 allowing multiple payloads,
this is different from allowing a single composite payload.

The earlier discussion was about the rejection of Atom-0.3's multiple
content elements, and the quirky multipart/alternative thing for
nesting content elements.

The conclusion was to reject multiple atom:content elements, and to
require text or html in text fields such as title and summary, leaving
atom:content unrestricted.

Placing a restriction on the MIME types that can be contained as the
payload of atom:content is contrary to the earlier conclusion.

-- 
Dave



From owner-atom-syntax@mail.imc.org  Sun Jun 19 00:15:11 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11731
	for <atompub-archive@lists.ietf.org>; Sun, 19 Jun 2005 00:15:11 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5J47AKo063683;
	Sat, 18 Jun 2005 21:07:10 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5J47AFe063682;
	Sat, 18 Jun 2005 21:07:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5J477kQ063651
	for <atom-syntax@imc.org>; Sat, 18 Jun 2005 21:07:07 -0700 (PDT)
	(envelope-from sayrer@gmail.com)
Received: by wproxy.gmail.com with SMTP id 70so219712wra
        for <atom-syntax@imc.org>; Sat, 18 Jun 2005 21:07:02 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=FJjvc8U4h/+yU1vwYKovp3s7oT/iqFLXXhkRLnUwtLXGY9sVm6546RKqfpbvWD2XIjC49zMdEmg/eed/ir55Jm/pVHvgdOGl8Xhu9byfojLArdi0cWDK7qPDnfKbr14gCBBbH1PuMY+Hdy4YTOslF0v4qzmpCdaEuUMj/1cpTDs=
Received: by 10.54.112.2 with SMTP id k2mr2034763wrc;
        Sat, 18 Jun 2005 21:07:01 -0700 (PDT)
Received: by 10.54.71.13 with HTTP; Sat, 18 Jun 2005 21:07:01 -0700 (PDT)
Message-ID: <68fba5c505061821075a672886@mail.gmail.com>
Date: Sun, 19 Jun 2005 00:07:01 -0400
From: Robert Sayre <sayrer@gmail.com>
Reply-To: Robert Sayre <sayrer@gmail.com>
To: David Powell <djpowell@djpowell.net>
Subject: Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
Cc: Tim Bray <Tim.Bray@Sun.COM>, Mark Baker <distobj@acm.org>,
        duerst@it.aoyama.ac.jp, ans208@mail.usask.ca, atom-syntax@imc.org
In-Reply-To: <388158077.20050619012829@djpowell.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
References: <20050617140542.GX20401@markbaker.ca>
	 <2E68D5C0-189B-4FCC-9D6F-201F28FC2A58@sun.com>
	 <147735454.20050618160049@djpowell.net>
	 <3B14BEB3-8056-4D1F-9498-85B199C45484@Sun.COM>
	 <388158077.20050619012829@djpowell.net>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j5J477kQ063662
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: 8bit


On 6/18/05, David Powell <djpowell@djpowell.net> wrote:
> 
> 
> Saturday, June 18, 2005, 7:16:50 PM, Tim Bray wrote:
> 
> >>> My feeling was that we ruled out composite types in *local* content
> >>> [...]
> >>>
> >>
> >> I'm still looking, but my suspicion is that we never did rule them
> >> out, and that this restriction crept in during some editorial
> >> rephrasing.
> 
> > <co-chair-mode>I disagree.  Atom 0.3 had explicit built-in support
> > for multipart, and there was strong (not rough) consensus support for
> > retiring that and replacing it with the language in the current draft.
> 
> <process-objection>
> ...
> But, there doesn't seem to have been any discussion or consensus
> whatsoever for the prohibition of composite MIME types in content,
> such as message/*, that was introduced in 08.
> </process-objection>
> 
> 
> Atom 0.3 multiparts forced a dubious and complex processing model on
> everyone wanting to process Atom documents. This problem was solved by
> their removal in the 03 to 07 drafts.
> 
> The prohibition of composite types in the 08 draft (made many months
> later) ....

Um, no. One of the drafts reworded the requirement in terms of the new
MIME draft. Previously, the draft cited RFC2045's "discrete type".
From format-03:

"Failing that, it MUST be a MIME media type [RFC2045] in which, to use
the terminology of Section 5 of [RFC2045], the top level is a discrete
type."

We had to, you know, make an editorial change because the new MIME
draft doesn't use the term "discrete type" anymore.

Robert Sayre



From owner-atom-syntax@mail.imc.org  Sun Jun 19 00:49:57 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13612
	for <atompub-archive@lists.ietf.org>; Sun, 19 Jun 2005 00:49:57 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5J4hmFK003950;
	Sat, 18 Jun 2005 21:43:48 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5J4hlb2003943;
	Sat, 18 Jun 2005 21:43:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5J4hhYW003722
	for <atom-syntax@imc.org>; Sat, 18 Jun 2005 21:43:43 -0700 (PDT)
	(envelope-from antone@geckotribe.com)
Received: from geckotribe.com (c-67-169-250-63.hsd1.ut.comcast.net[67.169.250.63])
          by comcast.net (rwcrmhc12) with SMTP
          id <2005061904433701400loke7e>; Sun, 19 Jun 2005 04:43:37 +0000
Date: Sat, 18 Jun 2005 22:43:36 -0600
Subject: Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v553)
From: Antone Roundy <antone@geckotribe.com>
To: atom-syntax@imc.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <388158077.20050619012829@djpowell.net>
Message-Id: <B2B5EDBE-E07C-11D9-BB67-003065EA6144@geckotribe.com>
X-Mailer: Apple Mail (2.553)
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: 7bit


On Saturday, June 18, 2005, at 06:28  PM, David Powell wrote:
> Atom 0.3 multiparts forced a dubious and complex processing model on
> everyone wanting to process Atom documents. This problem was solved by
> their removal in the 03 to 07 drafts.
>
> The prohibition of composite types in the 08 draft (made many months
> later) is something quite different.
I haven't combed through the archives for messages to support this, but 
had you asked me, I would have thought that we had explicitly decided 
to disallow composite types, not just to get rid of 0.3's multipart 
stuff.

> Composite types don't impose any
> change in the processing model of user-agents, they are just blobs
> that get passed to a MIME processor; there is no justification for
> restricting Atom payloads to a subset of the MIME type space.
Not all user-agents have a "MIME processor".  Given the potential 
complexity and messiness of composite types, I'm opposed to leaving the 
door open for them, since they won't, I think, be needed by a 
significant proportion of Atom users. This brings back bad memories of 
some really ugly data I saw coming out of Cyber Dog when I was working 
on Claris Emailer (Japanese)--a very convoluted and in fact buggy mess 
of multipart/alternative and multipart/mixed with lots of duplicated 
data which forced us to handle composite types incorrectly to avoid 
losing data.  Yes, that's just one anecdote.  But it's an example of 
the kinds of ugliness that can spill over from one bad implementation 
and mess things up for everybody.  Unless there's a use case that meets 
the so-called 80/20 threshold, I'd be in favor of requiring publishers 
to keep things a little simpler within Atom feeds. If somebody really 
needs composite types, they can use an extension, and user-agent 
developers can decide whether to support it.



From owner-atom-syntax@mail.imc.org  Sun Jun 19 03:43:51 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14396
	for <atompub-archive@lists.ietf.org>; Sun, 19 Jun 2005 03:43:51 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5J7dJGS050776;
	Sun, 19 Jun 2005 00:39:19 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5J7dJAP050775;
	Sun, 19 Jun 2005 00:39:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mta08-winn.ispmail.ntl.com (mta08-winn.ispmail.ntl.com [81.103.221.48])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5J7dIQG050675
	for <atom-syntax@imc.org>; Sun, 19 Jun 2005 00:39:18 -0700 (PDT)
	(envelope-from djpowell@djpowell.net)
Received: from aamta12-winn.ispmail.ntl.com ([81.103.221.35])
          by mta08-winn.ispmail.ntl.com with ESMTP
          id <20050619073913.QIUC6773.mta08-winn.ispmail.ntl.com@aamta12-winn.ispmail.ntl.com>;
          Sun, 19 Jun 2005 08:39:13 +0100
Received: from cpc2-stok1-5-0-cust90.bagu.cable.ntl.com ([81.111.201.90])
          by aamta12-winn.ispmail.ntl.com with ESMTP
          id <20050619073912.GWRL15401.aamta12-winn.ispmail.ntl.com@cpc2-stok1-5-0-cust90.bagu.cable.ntl.com>;
          Sun, 19 Jun 2005 08:39:12 +0100
Date: Sun, 19 Jun 2005 08:39:10 +0100
From: David Powell <djpowell@djpowell.net>
X-Mailer: The Bat! (v3.5.28) Professional
X-Priority: 3 (Normal)
Message-ID: <9810183198.20050619083910@djpowell.net>
To: Antone Roundy <antone@geckotribe.com>
CC: atom-syntax@imc.org
Subject: Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
In-Reply-To: <B2B5EDBE-E07C-11D9-BB67-003065EA6144@geckotribe.com>
References: <388158077.20050619012829@djpowell.net>
 <B2B5EDBE-E07C-11D9-BB67-003065EA6144@geckotribe.com>
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>
Content-Transfer-Encoding: 7bit



Sunday, June 19, 2005, 5:43:36 AM, Antone Roundy wrote:

> On Saturday, June 18, 2005, at 06:28  PM, David Powell wrote:
>> Atom 0.3 multiparts forced a dubious and complex processing model on
>> everyone wanting to process Atom documents. This problem was solved by
>> their removal in the 03 to 07 drafts.
>>
>> The prohibition of composite types in the 08 draft (made many months
>> later) is something quite different.

> I haven't combed through the archives for messages to support this, but
> had you asked me, I would have thought that we had explicitly decided
> to disallow composite types, not just to get rid of 0.3's multipart 
> stuff.

As Robert pointed out, it has been in all drafts since 03, only it was
worded differently.  My mistake.

>> Composite types don't impose any
>> change in the processing model of user-agents, they are just blobs
>> that get passed to a MIME processor; there is no justification for
>> restricting Atom payloads to a subset of the MIME type space.
> Not all user-agents have a "MIME processor".

Well they all do something with atom:content. They may choose only to
allow the built in types: text, html, and xhtml to be processed; they
may support a fixed set of additional MIME types: image/jpeg and
image/gif; or they may support all MIME types by handing them off to
another component (eg via an OBJECT tag, or just as a download link).
composite types should be dealt with by processors in exactly the same
way as any other unsupported MIME type.

I'm not suggesting that Atom processors do anything with the
composite, like select alternates or present attachments somehow. They
should just treat it as they would any other exotic MIME type, just
like HTTP does.

It is unlikely that desktop aggregators would do anything special with
composite types, but we aren't defining a protocol for desktop
agregators, we are defining a document format and documenting what it
means so that publishers and subscribers have a shared understanding
of it. Allowing message/rfc822 would not cause any additional
interpretability problems, so it is unsuitable for it to be banned
with a MUST level constraint.

> Given the potential complexity and messiness of composite types, I'm
> opposed to leaving the door open for them, since they won't, I
> think, be needed by a significant proportion of Atom users. This
> brings back bad memories of some really ugly data I saw coming out
> of Cyber Dog when I was working on Claris Emailer (Japanese)--a very
> convoluted and in fact buggy mess of multipart/alternative and
> multipart/mixed with lots of duplicated data which forced us to
> handle composite types incorrectly to avoid losing data. Yes, that's
> just one anecdote. But it's an example of the kinds of ugliness that
> can spill over from one bad implementation and mess things up for
> everybody. Unless there's a use case that meets the so-called 80/20
> threshold, I'd be in favor of requiring publishers to keep things a
> little simpler within Atom feeds. If somebody really needs composite
> types, they can use an extension, and user-agent developers can
> decide whether to support it.

Mail user-agents need to unwrap and process composite types (the one
I'm using now does it in a recursive panels and tabs way which works
quite well).

Atom user-agents don't need to unwrap and process composite types
though. They should just treat them as data. If they don't support
them themselves then they should just treat them as they would if they
saw any other MIME type that they don't support.

As I said in another reply, I'm not too bothered about us banning
multipart/* because they aren't really standalone types, but we really
shouldn't ban publishers from including message/rfc822 data, there
isn't any good reason.

-- 
Dave



From owner-atom-syntax@mail.imc.org  Sun Jun 19 03:48:11 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14555
	for <atompub-archive@lists.ietf.org>; Sun, 19 Jun 2005 03:48:11 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5J7auT1047572;
	Sun, 19 Jun 2005 00:36:56 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5J7aulD047571;
	Sun, 19 Jun 2005 00:36:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mta08-winn.ispmail.ntl.com (mta08-winn.ispmail.ntl.com [81.103.221.48])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5J7arAZ047361
	for <atom-syntax@imc.org>; Sun, 19 Jun 2005 00:36:54 -0700 (PDT)
	(envelope-from djpowell@djpowell.net)
Received: from aamta11-winn.ispmail.ntl.com ([81.103.221.35])
          by mta08-winn.ispmail.ntl.com with ESMTP
          id <20050619073646.QHZC6773.mta08-winn.ispmail.ntl.com@aamta11-winn.ispmail.ntl.com>;
          Sun, 19 Jun 2005 08:36:46 +0100
Received: from cpc2-stok1-5-0-cust90.bagu.cable.ntl.com ([81.111.201.90])
          by aamta11-winn.ispmail.ntl.com with ESMTP
          id <20050619073646.IHGT29707.aamta11-winn.ispmail.ntl.com@cpc2-stok1-5-0-cust90.bagu.cable.ntl.com>;
          Sun, 19 Jun 2005 08:36:46 +0100
Date: Sun, 19 Jun 2005 08:36:43 +0100
From: David Powell <djpowell@djpowell.net>
X-Mailer: The Bat! (v3.5.28) Professional
X-Priority: 3 (Normal)
Message-ID: <1396032551.20050619083643@djpowell.net>
To: Robert Sayre <sayrer@gmail.com>
CC: Tim Bray <Tim.Bray@Sun.COM>, Mark Baker <distobj@acm.org>,
        <duerst@it.aoyama.ac.jp>, <ans208@mail.usask.ca>,
        <atom-syntax@imc.org>
Subject: Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
In-Reply-To: <68fba5c505061821075a672886@mail.gmail.com>
References: <20050617140542.GX20401@markbaker.ca>
 <2E68D5C0-189B-4FCC-9D6F-201F28FC2A58@sun.com>
 <147735454.20050618160049@djpowell.net>
 <3B14BEB3-8056-4D1F-9498-85B199C45484@Sun.COM>
 <388158077.20050619012829@djpowell.net>
 <68fba5c505061821075a672886@mail.gmail.com>
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>
Content-Transfer-Encoding: 7bit



Sunday, June 19, 2005, 5:07:01 AM, you wrote:

>> The prohibition of composite types in the 08 draft (made many months
>> later) ....

> Um, no. One of the drafts reworded the requirement in terms of the new
> MIME draft. Previously, the draft cited RFC2045's "discrete type".
> From format-03:

> "Failing that, it MUST be a MIME media type [RFC2045] in which, to use
> the terminology of Section 5 of [RFC2045], the top level is a discrete
> type."

> We had to, you know, make an editorial change because the new MIME
> draft doesn't use the term "discrete type" anymore.

Ah, thanks. I don't know how I missed that.

OK, process-objection withdrawn, but the problem that Mark highlighted
still exists: Atom prohibits message/rfc822; I don't think that it
should. I'd prefer the solution to be to lift the restriction
completely, than to only lift the restriction for remote content.

It is worth looking what HTTP says about composite types in RFC 2616:

> In general, HTTP treats a multipart message-body no differently than
> any other media type: strictly as payload.

message/rfc822 isn't mentioned at all by HTTP, and is therefore also
treated as just data. It is pretty commonly used too, for both email
(eg: Download from webmail interfaces), and for MHTML content (such as
the format that can be saved by Word 2000 (I think?)).


To be honest, I'm not bothered about mulipart/* being banned. I don't
think that it is particularly useful, but I still don't think that we
need to ban it. What if some really useful multipart/* type gets
defined in future - something on the lines of multipart/appledouble
[1], where the multipart is a blob of content that can be passed to
helper applications as a discrete unit.

message/rfc822 is definitely useful though. There is no reason to ban
it, certainly not with a MUST level constraint. Conceptually it is no
more composite than an application/msword document is composite.


[1] http://www.iana.org/assignments/media-types/multipart/appledouble

-- 
Dave



From owner-atom-syntax@mail.imc.org  Sun Jun 19 08:52:26 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02328
	for <atompub-archive@lists.ietf.org>; Sun, 19 Jun 2005 08:52:26 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5JCkiJL066156;
	Sun, 19 Jun 2005 05:46:44 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5JCkikd066155;
	Sun, 19 Jun 2005 05:46:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.gmx.net (pop.gmx.de [213.165.64.20])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j5JCkhJK065931
	for <atom-syntax@imc.org>; Sun, 19 Jun 2005 05:46:43 -0700 (PDT)
	(envelope-from pagaltzis@gmx.de)
Received: (qmail invoked by alias); 19 Jun 2005 12:46:36 -0000
Received: from xdsl-81-173-170-202.netcologne.de (EHLO klangraum) [81.173.170.202]
  by mail.gmx.net (mp006) with SMTP; 19 Jun 2005 14:46:36 +0200
X-Authenticated: #163624
Date: Sun, 19 Jun 2005 14:50:44 +0200
From: "A. Pagaltzis" <pagaltzis@gmx.de>
To: atom-syntax@imc.org
Subject: Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
Message-ID: <20050619125030.GB7716@klangraum>
Mail-Followup-To: atom-syntax@imc.org
References: <388158077.20050619012829@djpowell.net> <B2B5EDBE-E07C-11D9-BB67-003065EA6144@geckotribe.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <B2B5EDBE-E07C-11D9-BB67-003065EA6144@geckotribe.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: 8bit


* Antone Roundy <antone@geckotribe.com> [2005-06-19 06:55]:
> Not all user-agents have a "MIME processor".  Given the
> potential complexity and messiness of composite types, I'm
> opposed to leaving the door open for them, since they won't, I
> think, be needed by a significant proportion of Atom users.

Neither will all user agents have a Zip or tar decompressor.
Shouldn’t we ban application/x-tar and application/zip? What
about MSWord documents with embedded images and OLE objects?
Or PDF documents with images? All of these are conceptually
compound documents, and all of these are likely not to be
processible by most user agents. Shouldn’t these MIME types be
banned as well then?

On the other hand, some automated consumers that use Atom for
something completely different from content syndication, like
maybe logging agents, might not even have any support for
@type=('text','html','xhtml') at the application level, instead
only supporting some form of specific XML envelope document or
maybe a binary blob.

If someone wants to use Atom as an archival format for mailing
lists, and wants to stick message/rfc-822 into the atom:content,
why should the spec stop him?

If someone wants to use Atom as an envelope format for machine
consumption in a company-internal application, and he wants to
push multipart/* around, and he has control of the consumers and
can endow them with a MIME parser – then why should the Atom
format spec stop him?

Of course, the spec is not really stopping him as long as he has
control of all the end points, in which case he can just send
application/octet-stream, and can assume that his feed producers
mean something more specific than “non-descript blob of data” and
that his feed consumers know what to do about it – so instead of
stopping him, the spec has just made him put junk data in his
documents.

I think we’re shooting/have shot ourselves in the foot with this
restriction by disallowing a range of applications that could
have benefitted from Atom but won’t.

> This brings back bad memories of some really ugly data I saw
> coming out of Cyber Dog when I was working on Claris Emailer
> (Japanese)--a very convoluted and in fact buggy mess of
> multipart/alternative and multipart/mixed with lots of
> duplicated data which forced us to handle composite types
> incorrectly to avoid losing data.

How is that relevant? An Atom processor is not a mailer. It is
under no obligation whatesoever to treat a multipart/* or
message/* payload any differently from application/octet-stream.

Composite types should impose no particular duties upon the Atom
processor itself. If the application attached to it which
receives these payloads from the processor knows what to do with
multipart/*, then great. But if it doesn’t, then the Atom
processor certainly won’t care one way or the other.

Funnily enough, that’s exactly the same treatment that any other
known or unknown MIME type receives.

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



From owner-atom-syntax@mail.imc.org  Sun Jun 19 09:01:14 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02826
	for <atompub-archive@lists.ietf.org>; Sun, 19 Jun 2005 09:01:13 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5JClswR067877;
	Sun, 19 Jun 2005 05:47:54 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5JCls7X067876;
	Sun, 19 Jun 2005 05:47:54 -0700 (PDT)
X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with SMTP id j5JClq7c067690
	for <atom-syntax@imc.org>; Sun, 19 Jun 2005 05:47:53 -0700 (PDT)
	(envelope-from pagaltzis@gmx.de)
Received: (qmail invoked by alias); 19 Jun 2005 12:47:47 -0000
Received: from xdsl-81-173-170-202.netcologne.de (EHLO klangraum) [81.173.170.202]
  by mail.gmx.net (mp028) with SMTP; 19 Jun 2005 14:47:47 +0200
X-Authenticated: #163624
Date: Sun, 19 Jun 2005 14:51:55 +0200
From: "A. Pagaltzis" <pagaltzis@gmx.de>
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
Message-ID: <20050619125155.GC7716@klangraum>
Mail-Followup-To: Atom Syntax <atom-syntax@imc.org>
References: <20050617140542.GX20401@markbaker.ca> <2E68D5C0-189B-4FCC-9D6F-201F28FC2A58@sun.com> <97E083D2-D625-4CAB-96C3-24EFE6483A99@mac.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <97E083D2-D625-4CAB-96C3-24EFE6483A99@mac.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>


* Graham <dtcd@mac.com> [2005-06-18 21:50]:
> The better way to do this is to use <atom:link rel="alternate">
> to reference the messages.

Is there any verbiage that would preclude a data: URI with a
multipart payload in atom:link?

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



From owner-atom-syntax@mail.imc.org  Sun Jun 19 17:55:33 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08987
	for <atompub-archive@lists.ietf.org>; Sun, 19 Jun 2005 17:55:33 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5JLeACm089160;
	Sun, 19 Jun 2005 14:40:10 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5JLeAuG089155;
	Sun, 19 Jun 2005 14:40:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from home.fastolfe.net (postfix@adsl-65-71-209-3.dsl.stlsmo.swbell.net [65.71.209.3])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5JLe9Yq089095
	for <atom-syntax@imc.org>; Sun, 19 Jun 2005 14:40:09 -0700 (PDT)
	(envelope-from fastolfe@fastolfe.net)
Received: by home.fastolfe.net (Postfix, from userid 1001)
	id 9B15216EDA; Sun, 19 Jun 2005 16:40:32 -0500 (CDT)
Date: Sun, 19 Jun 2005 16:40:32 -0500
From: David Nesting <david@fastolfe.net>
To: atom-syntax@imc.org
Subject: Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
Message-ID: <20050619214032.GC2194@home.fastolfe.net>
References: <388158077.20050619012829@djpowell.net> <B2B5EDBE-E07C-11D9-BB67-003065EA6144@geckotribe.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <B2B5EDBE-E07C-11D9-BB67-003065EA6144@geckotribe.com>
User-Agent: Mutt/1.4i
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>


On Sat, Jun 18, 2005 at 10:43:36PM -0600, Antone Roundy wrote:
> 
> Not all user-agents have a "MIME processor".  Given the potential 
> complexity and messiness of composite types, I'm opposed to leaving the 
> door open for them, since they won't, I think, be needed by a 
> significant proportion of Atom users. This brings back bad memories of 

But is it really necessary to FORBID using Atom for purposes that might
entail using these media types?

What exactly is the prohibition trying to prevent?

If it's trying to prohibit anything except what the most common Atom
processors are likely to understand, then we should eliminate the ability
to specify arbitrary media types entirely and stick with the most common
Atom uses we've already specified.

If it's trying to prevent compound documents of any kind, while still
allowing flexibility in selecting an appropriate "single-part" media type
based on the application, then it needs to do that better.  Currently it
forbids compound media types but allows other more widely used and less
widely known methods for including compound objects into the content.

If it's trying simply to prevent the use of one class of media types
for reasons not mentioned above, then I think it would help everyone to
have that reason documented.

At this point, I'm with the other posters in that this seems like an
artificial constraint in the absense of more meaningful verbiage.

> losing data.  Yes, that's just one anecdote.  But it's an example of 
> the kinds of ugliness that can spill over from one bad implementation 
> and mess things up for everybody.  Unless there's a use case that meets 

Perhaps a SHOULD-level requirement should be introduced to encourage
implementers to avoid multipart types since they will be unlikely to
be widely supported.  Maybe this should be a SHOULD-level prohibition
on using arbitrary media types entirely.  People SHOULD stick with the
text/html/xml pseudo-types we've explicitly defined unless they have a
good reason to use something else.

> to keep things a little simpler within Atom feeds. If somebody really 
> needs composite types, they can use an extension, and user-agent 
> developers can decide whether to support it.

This seems a little much for an extension.  Specification of a piece of
content is pretty fundamental to Atom.  If I have to do that through
an extension of my own devising, I have to wonder what I'm gaining by
starting with Atom in the first place.

David

-- 
 == David Nesting WL7RO Fastolfe david@fastolfe.net http://fastolfe.net/ ==
 fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882  C41F 3065 57D9 832F AB01



From owner-atom-syntax@mail.imc.org  Mon Jun 20 12:18:58 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14038
	for <atompub-archive@lists.ietf.org>; Mon, 20 Jun 2005 12:18:58 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5KG21wN045907;
	Mon, 20 Jun 2005 09:02:01 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5KG21Ak045906;
	Mon, 20 Jun 2005 09:02:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from atlas.jabber.org (postfix@atlas.jabber.org [208.245.212.69])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5KG20p1045897
	for <atom-syntax@imc.org>; Mon, 20 Jun 2005 09:02:00 -0700 (PDT)
	(envelope-from stpeter@jabber.org)
Received: by atlas.jabber.org (Postfix, from userid 1005)
	id 5273421A53B; Mon, 20 Jun 2005 11:05:04 -0500 (CDT)
Date: Mon, 20 Jun 2005 11:05:04 -0500
From: Peter Saint-Andre <stpeter@jabber.org>
To: atom-syntax@imc.org
Subject: Re: Atom feed synchronization
Message-ID: <20050620160504.GC19922@jabber.org>
References: <BED8524A.5F22D%eric.scheid@ironclad.net.au> <42B2188D.5050402@gmail.com> <1287.68.174.167.137.1118973674.squirrel@mail.pubsub.com> <42B2406F.4060707@gmail.com> <005b01c572f1$f58de890$6600a8c0@IBMC101DE8DFED>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <005b01c572f1$f58de890$6600a8c0@IBMC101DE8DFED>
User-Agent: Mutt/1.5.6+20040907i
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>


On Fri, Jun 17, 2005 at 12:02:43AM -0400, Bob Wyman wrote:

>    BTW: I think the "best" way to implement the application you describe is 
> probably via a combination of Push and Pull. If you're updating as rapidly 
> as you say you are, then it would make sense to push the updates to the 
> client using something like "Atom over XMPP"[1]. You would, however, still 
> generate Atom files and serve them using RFC3229+feed. The Atom files would 
> be used by clients to "catch up" on missed messages when they initially 
> connect or reconnect to the push stream after having been off-line for some 
> time.
>    The hybrid Push+Pull process described above is what we implement at 
> PubSub for every subscription. We currently have this implemented in our 
> PubSub Sidebars for IE and Firefox[2]. Also, the Gush reader from 2entwine 
> implements this hybrid Push+Pull approach when reading our feeds.
>    Push+Pull with Atom and Atom over XMPP gives you the best of both 
> worlds. You get very efficient and low latency publishing of new entries to 
> clients as well as efficient downloading of "catchup" files. What more 
> could you want? :-)
> 
>    bob wyman
> 
> [1] http://www.xmpp.org/drafts/draft-saintandre-atompub-notify-02.html

I see that I-D is due to expire on July 15. I'll review it this week to
bring it up to date with the latest Atom protocol I-D.

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml



From owner-atom-syntax@mail.imc.org  Mon Jun 20 17:32:06 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11982
	for <atompub-archive@lists.ietf.org>; Mon, 20 Jun 2005 17:32:06 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5KLGFNp073626;
	Mon, 20 Jun 2005 14:16:15 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5KLGFaM073624;
	Mon, 20 Jun 2005 14:16:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5KLGAlC073400
	for <atom-syntax@imc.org>; Mon, 20 Jun 2005 14:16:13 -0700 (PDT)
	(envelope-from jasnell@gmail.com)
Received: by wproxy.gmail.com with SMTP id 70so876849wra
        for <atom-syntax@imc.org>; Mon, 20 Jun 2005 14:15:58 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=WBQX+SNjYTk4KOL03ZFoBCKXTJZQy4dXS5i9loswR96reve9szoZ5zeLn0NJF4agkoG4pXlFhV5R5CzEditRqA7vnMhyuhD83WoCXKiv0nfyS6gjZDTbvIVrQHU4S1HOLe/2D9x30h5zljY6ukN7eOmYzbCuvhU0OxExbLXzmOA=
Received: by 10.54.141.13 with SMTP id o13mr1198728wrd;
        Mon, 20 Jun 2005 14:15:58 -0700 (PDT)
Received: from ?192.168.1.103? ([67.181.223.222])
        by mx.gmail.com with ESMTP id 24sm8234077wrl.2005.06.20.14.15.58;
        Mon, 20 Jun 2005 14:15:58 -0700 (PDT)
Message-ID: <42B73208.7030304@gmail.com>
Date: Mon, 20 Jun 2005 14:15:52 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: atom-syntax@imc.org
Subject: Re: More on Atom XML signatures and encryption
References: <1118943858.9048.6.camel@marge> <42B1CB81.3060101@gmail.com> <42B1CF84.5040508@dehora.net> <42B1EE41.9030304@gmail.com> <p0621025dbed80c5c0f0c@[10.20.30.249]>
In-Reply-To: <p0621025dbed80c5c0f0c@[10.20.30.249]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


OK, thanks to the feedback that has already been offered in this thread 
I've been able to make progress on the XML Encryption side of this.  Now 
to the digital signature side.  I'd like to get some opinions on the 
following question:

The spec already allows enveloped XML signatures for the document.  
Question: should we only allow signing of the entire document or are 
there valid use cases for allowing each individual entry in the feed to 
be individually signed?  e.g.

   <!-- Sign entire document -->
   <feed>
     <entry />
     <entry />
     <Signature />
   </feed>

   or

   <!-- Each entry could have it's own signature. -->
   <feed>
      <entry>
        <Signature /> <!-- covers the containing <entry />  -->
      </entry>
   </feed>

   or

   <!-- One signature for the feed, covering specific entries -->
   <feed>
      <entry>
        <id>urn:abc...</id>
      </entry>
      <Signature>
        <!-- use transform to select only the entry with id = urn:abc... -->
      </Signature>
   </feed>

I'm quite happy with limiting it to the first as I don't really see much 
of a reason to support the second and third examples, but wanted to see 
if anyone had any opinions or use cases that could justify the ability 
to independently sign individual entries within a feed.

- James



From owner-atom-syntax@mail.imc.org  Tue Jun 21 00:39:48 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15688
	for <atompub-archive@lists.ietf.org>; Tue, 21 Jun 2005 00:39:48 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5L3QppH067102;
	Mon, 20 Jun 2005 20:26:51 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5L3QpGK067101;
	Mon, 20 Jun 2005 20:26:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from fungible7.mail.rice.edu (fungible7-dmfe1.mail.rice.edu [128.42.59.177])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5L3QoEl067095
	for <atom-syntax@imc.org>; Mon, 20 Jun 2005 20:26:50 -0700 (PDT)
	(envelope-from dsandler@rice.epostmail.org)
Received: from localhost (unknown [128.42.58.160])
	by fungible7.mail.rice.edu (Postfix) with ESMTP id C9CC01DB1D
	for <atom-syntax@imc.org>; Mon, 20 Jun 2005 22:26:49 -0500 (CDT)
Received: from fungible7.mail.rice.edu ([128.42.58.177])
 by localhost (scan1.mail.rice.edu [128.42.58.160]) (amavisd-new, port 10024)
 with LMTP id 06491-01-62 for <atom-syntax@imc.org>;
 Mon, 20 Jun 2005 22:26:49 -0500 (CDT)
Received: from myname (unknown [128.42.129.17])
	by fungible7.mail.rice.edu (Postfix) with SMTP id F27BA1DB18
	for <atom-syntax@imc.org>; Mon, 20 Jun 2005 22:26:48 -0500 (CDT)
In-Reply-To: <42B73208.7030304@gmail.com>
References: <1118943858.9048.6.camel@marge> <42B1CB81.3060101@gmail.com> <42B1CF84.5040508@dehora.net> <42B1EE41.9030304@gmail.com> <p0621025dbed80c5c0f0c@[10.20.30.249]> <42B73208.7030304@gmail.com>
Mime-Version: 1.0 (Apple Message framework v622)
X-Priority: 3
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <c9bd5968a6f3a8e1742d98f727c297e8@rice.epostmail.org>
Content-Transfer-Encoding: 7bit
Reply-To: Dan Sandler <dsandler@cs.rice.edu>
X-Image-Url: http://dsandler.org/art/slashdot/coffee-dude-aim-icon.gif
From: Dan Sandler <dsandler@rice.epostmail.org>
Subject: Re: More on Atom XML signatures and encryption
Date: Mon, 20 Jun 2005 22:26:43 -0500
To: James M Snell <jasnell@gmail.com>, atom-syntax@imc.org
X-Mailer: Apple Mail (2.622)
X-Virus-Scanned: by amavis-2.1.2 at scan1.mail.rice.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>
Content-Transfer-Encoding: 7bit


On Jun 20, 2005, at 4:15 PM, James M Snell wrote:

> Question: should we only allow signing of the entire document or are 
> there valid use cases for allowing each individual entry in the feed 
> to be individually signed?

I believe that individually signed entries are essential for a couple 
of Atom usage contexts:

	(1) aggregation services, e.g. third parties which combine or filter 
portions of feeds
	(2) redistribution applications, e.g. clients which share portions of 
feeds with one another

The common thread here is that these scenarios represent third parties 
interposed between publisher and user.  [In category (1) the third 
party is the aggregator; in category (2) the third party is "some other 
client".  This is a continuous design space, of course, but let's stick 
with these two simple scenarios.]  When a third party is involved, 
signatures are required to verify that the information received by the 
user has not been altered since the publisher released it.

If Atom data may only be signed at the <feed/> level, the granularity 
at which these third parties may slice and dice content is constrained 
to that level also.  The <entry/> seems to me to be more generally 
useful as, well, an "atomic" signature unit for these applications.  
Without individually signed entries, it would be impossible, for 
example, to implement the most basic category (1) service: an 
aggregator which can be *trusted* to combine two Atom feeds into one.  
With signed entries, a client could be sure that each entry found in 
the aggregation is authentic, despite having received the entries from 
a potentially untrustworthy entity.

If this seems a bit far-fetched because there are currently few 
examples of these Atom intermediaries, just wait; aggregators are the 
new clipping services, and I suspect we'll see more of them in the 
future.  (Just as with traditional clipping services, people may even 
pay money for this valuable service, which is a Good Thing for 
technology that enables it.)  And as for (2), I'm working on it :)

---dan
http://www.cs.rice.edu/~dsandler/




From owner-atom-syntax@mail.imc.org  Tue Jun 21 00:56:17 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17013
	for <atompub-archive@lists.ietf.org>; Tue, 21 Jun 2005 00:56:17 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5L4HZHp098195;
	Mon, 20 Jun 2005 21:17:35 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5L4HZ0j098192;
	Mon, 20 Jun 2005 21:17:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.194])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5L4HWlw098171
	for <atom-syntax@imc.org>; Mon, 20 Jun 2005 21:17:33 -0700 (PDT)
	(envelope-from jasnell@gmail.com)
Received: by rproxy.gmail.com with SMTP id j1so315805rnf
        for <atom-syntax@imc.org>; Mon, 20 Jun 2005 21:17:31 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=Ss1xFIwNqIKODS7eY90wN7PVaWhk7M5df+GRSrDiNqy85meW3gkpzkvSgqrIP0ccNJ2tpuHg8Gc8yB0Lf8XZCsYrqLXZA/n/FovxTjBqF2DPITYzUIyRS5PsoipsIirgznTcgp1Z8lGi0ZAgG2Z7tVRlpdHgBJrQhhoIM2pUMNo=
Received: by 10.38.181.17 with SMTP id d17mr2482611rnf;
        Mon, 20 Jun 2005 21:17:31 -0700 (PDT)
Received: from ?192.168.1.103? ([67.181.223.222])
        by mx.gmail.com with ESMTP id 73sm3251447rna.2005.06.20.21.17.30;
        Mon, 20 Jun 2005 21:17:31 -0700 (PDT)
Message-ID: <42B794D4.4040101@gmail.com>
Date: Mon, 20 Jun 2005 21:17:24 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dan Sandler <dsandler@cs.rice.edu>
CC: atom-syntax@imc.org
Subject: Re: More on Atom XML signatures and encryption
References: <1118943858.9048.6.camel@marge> <42B1CB81.3060101@gmail.com> <42B1CF84.5040508@dehora.net> <42B1EE41.9030304@gmail.com> <p0621025dbed80c5c0f0c@[10.20.30.249]> <42B73208.7030304@gmail.com> <c9bd5968a6f3a8e1742d98f727c297e8@rice.epostmail.org>
In-Reply-To: <c9bd5968a6f3a8e1742d98f727c297e8@rice.epostmail.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


Dan Sandler wrote:

> On Jun 20, 2005, at 4:15 PM, James M Snell wrote:
>
>> Question: should we only allow signing of the entire document or are 
>> there valid use cases for allowing each individual entry in the feed 
>> to be individually signed?
>
>
> I believe that individually signed entries are essential for a couple 
> of Atom usage contexts:
>
>     (1) aggregation services, e.g. third parties which combine or 
> filter portions of feeds
>     (2) redistribution applications, e.g. clients which share portions 
> of feeds with one another
>
> The common thread here is that these scenarios represent third parties 
> interposed between publisher and user.  [In category (1) the third 
> party is the aggregator; in category (2) the third party is "some 
> other client".  This is a continuous design space, of course, but 
> let's stick with these two simple scenarios.]  When a third party is 
> involved, signatures are required to verify that the information 
> received by the user has not been altered since the publisher released 
> it.
>
> If Atom data may only be signed at the <feed/> level, the granularity 
> at which these third parties may slice and dice content is constrained 
> to that level also.  The <entry/> seems to me to be more generally 
> useful as, well, an "atomic" signature unit for these applications.  
> Without individually signed entries, it would be impossible, for 
> example, to implement the most basic category (1) service: an 
> aggregator which can be *trusted* to combine two Atom feeds into one.  
> With signed entries, a client could be sure that each entry found in 
> the aggregation is authentic, despite having received the entries from 
> a potentially untrustworthy entity.
>
> If this seems a bit far-fetched because there are currently few 
> examples of these Atom intermediaries, just wait; aggregators are the 
> new clipping services, and I suspect we'll see more of them in the 
> future.  (Just as with traditional clipping services, people may even 
> pay money for this valuable service, which is a Good Thing for 
> technology that enables it.)  And as for (2), I'm working on it :)
>

The thought here then is that feeds would not be considered atomic units 
and that <entry /> elements can be pulled as is out of a containing 
<feed /> element and passed around independently of it.  That really 
doesn't seem to square up with some basic XML signature principles and 
other atom conventions such as the ability to omit the author element 
from a contained <entry /> if the containing feed has an author... for 
example:

   <feed>
      ...
      <author>...</author>
      <entry>...</entry>
   </feed>

as oppose to

   <feed>
      ...
      <entry>
         <author>...</author>
      </entry>
   </feed>

In the first case, the <entry /> is entirely dependent on the containing 
feed for specifying a critical and required piece of metadata making it 
impossible to separate from the feed without first processing it. 

So the question with regards to enabling aggregation services is whether 
or not those services could even exist without performing a level of 
processing against the feed and entries that would necessarily break the 
digital signature.  In other words, if the entry in the first example 
above were to be included in an aggregate feed containing entries from 
multiple authors, the <author /> element from its containing feed would 
need to be added to the entry element's collection of metadata... 
(<entry>...</entry> becomes <entry> .. .<author /> ... </entry>) thereby 
invalidating any signature calculated over the entry.  One would also 
have to contend with the potential problems introduced by namespace 
declarations with the feed.  The bottom line of this is that an entry 
with a signature could not simply be copied over to a new containing 
feed element with the signature in tact making the aggregator scenario 
unworkable.

e.g.

  Feed 1:
    <feed xmlns="...">
       ...
       <entry>
          <id>urn:123</id>
          ...
          <Signature xmlns="..." />
       </entry>
    </feed>

  Feed 2:
    <x:feed xmlns:x="...">
      ...
      <x:entry>
        <x:id>urn:abc</x:id>
        ...
        <ds:Signature xmlns:ds="..." />
      </x:entry>
    </x:feed>

  Perfectly Legal Synthesized Aggregated Feed
    <a:feed xmlns:a="..." >
       <a:entry>
          <a:id>urn:123</a:id>
          ...
          <Signature xmlns="..." /> <!-- invalid signature !! -->
       </a:entry>
      <a:entry>
        <a:id>urn:abc</a:id>
        ...
        <Signature xmlns="..." /> <!-- invalid signature !! -->
      </a:entry>
    </a:feed>

The only potential way around this problem would be to define a standard 
canonicalization mechanism for Atom entries that would make it possible 
to reliably sign and verify them across multiple feeds.  While 
plausible, that approach gets rather complicated and is only justified 
if a) there is enough of a use case justification and b) there's not an 
easier way.  Unless such a canonicalization mechanism is defined, it 
would appear as if there would be no way of ensuring that the individual 
entries within a synthesized aggregate feed are indeed "authentic" 
unless a) they contained a self-referential pointer back to a digitally 
signed version of itself, b) the synthesized feed in which it was 
contained is digitally signed by a trusted entity and c) the version of 
the entry contained in the synthesized feed is identical to its 
digitally signed reference copy.  but even this is obviously imperfect.

  Digitally signed original @ http://myblog.com/entries/1
    <?xml ...?>
    <entry>
       <id>urn:123</id>
       <link rel="self" href="http://myblog.com/entries/1" />
       <Signature xmlns="..."/>   <!-- signed by original source -->
    </entry>

  Synthesized Aggegate Feed @ http://someaggregator/feed
     <?xml ...?>
     <feed>
        ...
       <entry>
          <id>urn:123</id>
          <link rel="self" href="http://myblog.com/entries/1" />
       </entry>
       <Signature xmlns="..." />  <!-- signed by aggregator -->
     </feed>

With this approach, the referenced copy of the entry becomes the 
"authenticated" version (assuming you trust both the aggregator's and 
original source's signatures) while the version of the entry contained 
in the entry is "unauthenticated".  The key challenge with this approach 
is that one would really have to trust the aggregator in order for it to 
work.

Another challenge is the fact that the Atom specification only accounts 
for Signature elements at the document level -- e.g. as a child of the 
top level <feed /> or <entry /> elements -- and not on the child entry 
level.

So... given all this... I think I'm gong to make an assertion and open 
that assertion up for debate:  The need for an end-to-end trust model 
for Atom capable of traversing any number of intermediaries is largely a 
myth. What is really needed is a simple mechanism for protecting feeds 
against spoofed sources (e.g. man-in-the-middle serving up a bogus feed) 
and for indicating that content is trustworthy* on the document level 
(as opposed to individual feed entry level). 

* by which I mean, for example, binary enclosures are trustworthy, the 
feed itself does not contain any malicious content, etc

Thoughts?

> ---dan
> http://www.cs.rice.edu/~dsandler/
>
>
>
- James



From owner-atom-syntax@mail.imc.org  Tue Jun 21 01:41:42 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21355
	for <atompub-archive@lists.ietf.org>; Tue, 21 Jun 2005 01:41:41 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5L4vH0c022701;
	Mon, 20 Jun 2005 21:57:17 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5L4vHQm022700;
	Mon, 20 Jun 2005 21:57:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.pubsub.com (mail.pubsub.com [209.11.36.150])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5L4vGWV022632
	for <atom-syntax@imc.org>; Mon, 20 Jun 2005 21:57:16 -0700 (PDT)
	(envelope-from bob@wyman.us)
Received: from IBMC101DE8DFED (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137])
	by mail.pubsub.com (Postfix) with ESMTP id 38E227243CD;
	Tue, 21 Jun 2005 00:57:11 -0400 (EDT)
Message-ID: <001201c5761d$ae1db9c0$6600a8c0@IBMC101DE8DFED>
From: "Bob Wyman" <bob@wyman.us>
To: "James M Snell" <jasnell@gmail.com>, <atom-syntax@imc.org>
References: <1118943858.9048.6.camel@marge> <42B1CB81.3060101@gmail.com> <42B1CF84.5040508@dehora.net> <42B1EE41.9030304@gmail.com> <p0621025dbed80c5c0f0c@[10.20.30.249]> <42B73208.7030304@gmail.com>
Subject: Re: More on Atom XML signatures and encryption
Date: Tue, 21 Jun 2005 00:57:07 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2527
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
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: 7bit


James M Snell wrote:
> Question: should we only allow signing of the entire document or are there 
> valid use cases for allowing each individual entry in the feed to be 
> individually signed?
    We definitely need to be able to sign each entry. This is necessary so 
that we can passed signed content in aggregated feeds. The mere act of 
aggregation should not force a signature to be removed from an item. (Note: 
Signed entries really *must* include source elements. Otherwise, aggregators 
will be forced to strip off the signatures in order to insert the source 
elements.)

        bob wyman




From owner-atom-syntax@mail.imc.org  Tue Jun 21 02:14:25 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06867
	for <atompub-archive@lists.ietf.org>; Tue, 21 Jun 2005 02:14:23 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5L5CYLL034917;
	Mon, 20 Jun 2005 22:12:35 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5L5CYNE034916;
	Mon, 20 Jun 2005 22:12:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from fungible10.mail.rice.edu (fungible10-dmfe1.mail.rice.edu [128.42.59.180])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5L5CY8r034895
	for <atom-syntax@imc.org>; Mon, 20 Jun 2005 22:12:34 -0700 (PDT)
	(envelope-from dsandler@rice.epostmail.org)
Received: from localhost (unknown [128.42.58.160])
	by fungible10.mail.rice.edu (Postfix) with ESMTP id 7621F1DB20
	for <atom-syntax@imc.org>; Tue, 21 Jun 2005 00:12:33 -0500 (CDT)
Received: from fungible10.mail.rice.edu ([128.42.58.180])
 by localhost (scan1.mail.rice.edu [128.42.58.160]) (amavisd-new, port 10024)
 with LMTP id 04115-01-66 for <atom-syntax@imc.org>;
 Tue, 21 Jun 2005 00:12:32 -0500 (CDT)
Received: from myname (unknown [128.42.129.17])
	by fungible10.mail.rice.edu (Postfix) with SMTP id 87A471DB17
	for <atom-syntax@imc.org>; Tue, 21 Jun 2005 00:12:32 -0500 (CDT)
In-Reply-To: <42B794D4.4040101@gmail.com>
References: <1118943858.9048.6.camel@marge> <42B1CB81.3060101@gmail.com> <42B1CF84.5040508@dehora.net> <42B1EE41.9030304@gmail.com> <p0621025dbed80c5c0f0c@[10.20.30.249]> <42B73208.7030304@gmail.com> <c9bd5968a6f3a8e1742d98f727c297e8@rice.epostmail.org> <42B794D4.4040101@gmail.com>
Mime-Version: 1.0 (Apple Message framework v622)
X-Priority: 3
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <827d923e73ac6587d98287a1959f4309@rice.epostmail.org>
Content-Transfer-Encoding: 7bit
Cc: atom-syntax@imc.org
X-Image-Url: http://dsandler.org/art/slashdot/coffee-dude-aim-icon.gif
From: Dan Sandler <dsandler@rice.epostmail.org>
Subject: Re: More on Atom XML signatures and encryption
Date: Tue, 21 Jun 2005 00:12:27 -0500
To: James M Snell <jasnell@gmail.com>
X-Mailer: Apple Mail (2.622)
X-Virus-Scanned: by amavis-2.1.2 at scan1.mail.rice.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>
Content-Transfer-Encoding: 7bit


On Jun 20, 2005, at 11:17 PM, James M Snell wrote:

> The thought here then is that feeds would not be considered atomic 
> units and that <entry /> elements can be pulled as is out of a 
> containing <feed /> element and passed around independently of it.

That's basically the idea, yes.

> That really doesn't seem to square up with some basic XML signature 
> principles and other atom conventions such as the ability to omit the 
> author element from a contained <entry /> if the containing feed has 
> an author...

Which XML-DSig principles does this violate?  It seems to me that if 
you come across a signed node, as long as you don't break the 
well-formedness of it, you can do what you like with it.

As for Atom conventions, such as the omission of key information from 
an <entry>---yes, this is a complication.  One approach would be to 
make my Atom feeds "disassemblable", such that each entry found in the 
feed could equally stand on its own as an Atom Entry Document.

Then again, this may not be such a big deal.  In the case of an 
aggregator it's an issue, but in the peers-sharing-entries case, it's 
conceivable that each peer already knows the <feed> level metadata and 
can refer to it when necessary.  (Perhaps the peers periodically---but 
rarely!---poll the conventional Atom feed, or perhaps they exchange the 
entire <feed> contents among themselves if it too has been signed by 
the original publisher.)

> So the question with regards to enabling aggregation services is 
> whether or not those services could even exist without performing a 
> level of processing against the feed and entries that would 
> necessarily break the digital signature.  In other words, if the entry 
> in the first example above were to be included in an aggregate feed 
> containing entries from multiple authors, the <author /> element from 
> its containing feed would need to be added to the entry element's 
> collection of metadata... (<entry>...</entry> becomes <entry> .. 
> .<author /> ... </entry>) thereby invalidating any signature 
> calculated over the entry.

I agree that destructively processing the entries is almost certain to 
cause trouble (and relates directly to your canonicalization argument 
below).  This might not be such a big deal; aggregators might simply 
pass along what users can verify as authentic, placing the pressure on 
original Atom content producers (i.e. publishers and their software) to 
create "self-sufficient" entries.

> One would also have to contend with the potential problems introduced 
> by namespace declarations with the feed.  The bottom line of this is 
> that an entry with a signature could not simply be copied over to a 
> new containing feed element with the signature in tact making the 
> aggregator scenario unworkable.

Ugh.  I don't have an answer for the namespaces problem.  (XML isn't 
doing me any favors here.  Or perhaps the reverse is more true?)

I suppose that in my mind, an Atom feed is mostly a vector (pun 
intended) for carrying Atom entries.  After all, the entries are what 
the user (or end processor, or what have you) is really interested in!  
They are stable, mostly-unchanging, "atomic" (!) bits of data that can 
be exchanged and stored and reasoned about.  On the other hand, the 
feed is always changing, even if most of its data remains the same; as 
a sliding window of Atom "events", it's a moving target, almost 
entirely uninteresting in itself from the perspective of processing 
applications.  Digital signatures just bring this point to the fore.

Which brings me to the following heresy: Wouldn't it be nice if an Atom 
feed were just a list of self-contained Atom Entry Documents?  Yes, 
some data will be duplicated between items, but there's a tremendous 
flexibility benefit, to my mind.  Entries are now much more loosely 
coupled to one another, and can survive on their own in any context, 
for any purpose.

(The reason I think that this is a *useful* flexibility is that when I 
look at current applications of newsfeeds, I see a strong focus on 
entries.  Popular newsreaders spend the bulk of their UI energy on 
listing and presenting entries, because that's where the user's focus 
is.  The "objects" in the system, from the user's perspective, are the 
entries.  The feed is just the box they came in.  How long before 
newsreaders allow users to clip and save their favorite entries, 
individually, in a *different* box---like saving email messages to a 
folder?  Even this simple operation is made difficult by binding 
entries tightly to their feeds.  But I digress.)

> The only potential way around this problem would be to define a 
> standard canonicalization mechanism for Atom entries that would make 
> it possible to reliably sign and verify them across multiple feeds.

I agree that canonicalization would also solve this.  (Just to be sure 
we're on the same page: XML Canonicalization is woefully insufficient 
for this domain-specific task.)  You might view the concept of an Atom 
Entry Document as a start in this direction.

> Unless such a canonicalization mechanism is defined, it would appear 
> as if there would be no way of ensuring that the individual entries 
> within a synthesized aggregate feed are indeed "authentic" unless a) 
> they contained a self-referential pointer back to a digitally signed 
> version of itself, b) the synthesized feed in which it was contained 
> is digitally signed by a trusted entity and c) the version of the 
> entry contained in the synthesized feed is identical to its digitally 
> signed reference copy.

That seems pretty complicated.  Also, it requires the client, having 
received an entry signed by an aggregator, to go fetch the entry from 
the original server in order to get the "authentic" version (signed by 
originator).  In that case, why bother distributing the content in the 
aggregator?  The aggregator could save some effort and just publish 
list of URLs for the clients to fetch.

> [...] The key challenge with this approach is that one would really 
> have to trust the aggregator in order for it to work.

Right, which is the kind of trust I'm trying to avoid relying on.

> Another challenge is the fact that the Atom specification only 
> accounts for Signature elements at the document level -- e.g. as a 
> child of the top level <feed /> or <entry /> elements -- and not on 
> the child entry level.

Yes.  This has always struck me as an unnecessary limitation in the 
spec.  I chalked it up to getting 1.0 out the door, and trying to hash 
out all the ugly details of signatures later (in which case, mission 
accomplished).

> So... given all this... I think I'm gong to make an assertion and open 
> that assertion up for debate:  The need for an end-to-end trust model 
> for Atom capable of traversing any number of intermediaries is largely 
> a myth. What is really needed is a simple mechanism for protecting 
> feeds against spoofed sources (e.g. man-in-the-middle serving up a 
> bogus feed) and for indicating that content is trustworthy* on the 
> document level (as opposed to individual feed entry level).
> * by which I mean, for example, binary enclosures are trustworthy, the 
> feed itself does not contain any malicious content, etc

If indeed end-to-end authenticity is unnecessary, then I agree: 
document-level trust is all you need.

However, providing only document-level authenticity locks Atom (as a 
data format) out of other distribution models.  In essence, you're 
stuck with either "client polls source for entire feed" or "client gets 
entire feed from somewhere else".  There's no opportunity to send 
deltas, and there's no opportunity to combine feeds.  (Unless security 
is unimportant to Atom applications, in which case there's no reason to 
sign feeds or entries at all.)

---dan, kicking in way more than his two-cent quota




From owner-atom-syntax@mail.imc.org  Tue Jun 21 02:16:07 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08634
	for <atompub-archive@lists.ietf.org>; Tue, 21 Jun 2005 02:16:07 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5L5YRa0054026;
	Mon, 20 Jun 2005 22:34:27 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5L5YRCk054024;
	Mon, 20 Jun 2005 22:34:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.204])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5L5XqTI053363
	for <atom-syntax@imc.org>; Mon, 20 Jun 2005 22:34:23 -0700 (PDT)
	(envelope-from jasnell@gmail.com)
Received: by wproxy.gmail.com with SMTP id 69so1092325wra
        for <atom-syntax@imc.org>; Mon, 20 Jun 2005 22:33:43 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=Mzhev0tNLAYplUEnE1EWCi1NdLCWkJdFmT/VdurggSA9mzyeEiIWTueG+9hwcJQauehLXVbnfgMBK39OB9doaRvrLELAt1AHpPkStfmaCUFxjwFdEivZgQuvYyiBRvOZNexmoh92zgzX3OUmoVjkD+NZ/Q4wApr5DXkF30L8e8g=
Received: by 10.54.23.3 with SMTP id 3mr3128247wrw;
        Mon, 20 Jun 2005 22:33:43 -0700 (PDT)
Received: from ?192.168.1.103? ([67.181.223.222])
        by mx.gmail.com with ESMTP id 65sm3959283wra.2005.06.20.22.33.43;
        Mon, 20 Jun 2005 22:33:43 -0700 (PDT)
Message-ID: <42B7A6B1.9050803@gmail.com>
Date: Mon, 20 Jun 2005 22:33:37 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Bob Wyman <bob@wyman.us>, atom-syntax@imc.org
Subject: Re: More on Atom XML signatures and encryption
References: <1118943858.9048.6.camel@marge> <42B1CB81.3060101@gmail.com> <42B1CF84.5040508@dehora.net> <42B1EE41.9030304@gmail.com> <p0621025dbed80c5c0f0c@[10.20.30.249]> <42B73208.7030304@gmail.com> <001201c5761d$ae1db9c0$6600a8c0@IBMC101DE8DFED>
In-Reply-To: <001201c5761d$ae1db9c0$6600a8c0@IBMC101DE8DFED>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


OK, so given the arguments I previously posted in my response to Dan + 
the assertion that digitally signing individual entries will be 
necessary, the only real possible solution would be to come up with a 
canonicalization scheme for digitally signed Atom entries.  When applied 
to an entry, the scheme would transform the entry into what is 
effectively a standalone Atom Entry Document with a source and author 
elements included and all necessary namespace declarations.

For example, given the following:

  <feed xmlns:xhtml="..." xmlns="...">
     <author>...</author>
     <entry>
       <id>...</id>
     </entry>
  </feed>

The canonicalized version of the entry would look something like:

<entry xmlns="..." xmlns:xhtml="...">
   <id>...</id>
   <source>
      <author>...</author>
   </source>
</entry>

The digital signature would then be calculated over the canonicalized 
entry. 

What else would the canonicalization scheme have to do?

- James

Bob Wyman wrote:

> James M Snell wrote:
>
>> Question: should we only allow signing of the entire document or are 
>> there valid use cases for allowing each individual entry in the feed 
>> to be individually signed?
>
>    We definitely need to be able to sign each entry. This is necessary 
> so that we can passed signed content in aggregated feeds. The mere act 
> of aggregation should not force a signature to be removed from an 
> item. (Note: Signed entries really *must* include source elements. 
> Otherwise, aggregators will be forced to strip off the signatures in 
> order to insert the source elements.)
>
>        bob wyman
>
>
>



From owner-atom-syntax@mail.imc.org  Tue Jun 21 02:30:36 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15385
	for <atompub-archive@lists.ietf.org>; Tue, 21 Jun 2005 02:30:36 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5L5SI2j048223;
	Mon, 20 Jun 2005 22:28:18 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5L5SIef048222;
	Mon, 20 Jun 2005 22:28:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.pubsub.com (mail.pubsub.com [209.11.36.150])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5L5SH9h048078
	for <atom-syntax@imc.org>; Mon, 20 Jun 2005 22:28:17 -0700 (PDT)
	(envelope-from bob@wyman.us)
Received: from IBMC101DE8DFED (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137])
	by mail.pubsub.com (Postfix) with ESMTP id D07087243CD;
	Tue, 21 Jun 2005 01:28:11 -0400 (EDT)
Message-ID: <001c01c57622$033381c0$6600a8c0@IBMC101DE8DFED>
From: "Bob Wyman" <bob@wyman.us>
To: "James M Snell" <jasnell@gmail.com>, "Dan Sandler" <dsandler@cs.rice.edu>
Cc: <atom-syntax@imc.org>
References: <1118943858.9048.6.camel@marge> <42B1CB81.3060101@gmail.com> <42B1CF84.5040508@dehora.net> <42B1EE41.9030304@gmail.com> <p0621025dbed80c5c0f0c@[10.20.30.249]> <42B73208.7030304@gmail.com> <c9bd5968a6f3a8e1742d98f727c297e8@rice.epostmail.org> <42B794D4.4040101@gmail.com>
Subject: Re: More on Atom XML signatures and encryption
Date: Tue, 21 Jun 2005 01:28:10 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2527
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
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: 7bit


James M Snell wrote:
> the ability to omit the author element from a contained <entry /> if the 
> containing feed has an author...
    Signed entries should include a source element and that source element 
should contain any of the feed level elements that the entry depends on. 
This is one of the reasons that souce elements exist. The use of source 
elements drastically simplifies this part of the canonicalization process.

        bob wyman




From owner-atom-syntax@mail.imc.org  Tue Jun 21 12:04:43 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03662
	for <atompub-archive@lists.ietf.org>; Tue, 21 Jun 2005 12:04:42 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5LFGquT060759;
	Tue, 21 Jun 2005 08:16:52 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5LFGpjX060736;
	Tue, 21 Jun 2005 08:16:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5LFGoWO060564
	for <atom-syntax@imc.org>; Tue, 21 Jun 2005 08:16:50 -0700 (PDT)
	(envelope-from antone@geckotribe.com)
Received: from geckotribe.com (c-67-169-250-63.hsd1.ut.comcast.net[67.169.250.63])
          by comcast.net (sccrmhc13) with SMTP
          id <2005062115163901600kkmbge>; Tue, 21 Jun 2005 15:16:39 +0000
Date: Tue, 21 Jun 2005 09:16:38 -0600
Subject: Re: More on Atom XML signatures and encryption
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v553)
From: Antone Roundy <antone@geckotribe.com>
To: atom-syntax@imc.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <42B7A6B1.9050803@gmail.com>
Message-Id: <7667B767-E267-11D9-816E-003065EA6144@geckotribe.com>
X-Mailer: Apple Mail (2.553)
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: 7bit


On Monday, June 20, 2005, at 11:33  PM, James M Snell wrote:
> OK, so given the arguments I previously posted in my response to Dan + 
> the assertion that digitally signing individual entries will be 
> necessary, the only real possible solution would be to come up with a 
> canonicalization scheme for digitally signed Atom entries.
...or as Bob said, always including a source element in signed entries, 
even if they're in the origin feed.

The following is all academic at this point, but here's "pseudofeed" of 
what I'd like to have seen...part of it only in retrospect:

<feed>

	<head><!--it's baaaack!-->
		[feed metadata]
		<Signature xmlns="..." /><!--the feed head is signed--the entire feed 
could be too, but this is for aggregation-->
	</head>

	<entry>
		[entry metadata and content]
		<feedsig><!--a copy of the feed's head's signature, so that the entry 
can be verifiably linked to the signed feed metadata--></feedsig>
		<Signature xmlns="..." /> <!--the entry is signed, including the 
local copy of the feed head signature-->
	</entry>

	<entry>
		[entry metadata and content]
		<feedsig>...</feedsig>
		<Signature xmlns="..." />
	</entry>

	[etc.]

</feed>

Of course, aggregating this while preserving the signatures' validity 
would require a different aggregation model than what we've 
chosen--like what I proposed for aggregation documents. (Indentation 
added for readability--in practice, that would break the signature, 
right?):

<aggregation>
	[aggregation metadata]

	<feed>
		<head>
			[feed metadata]
			<Signature xmlns="..." />
		</head>
		<entry>
			[entry metadata and content]
			<feedsig>...</feedsig>
			<Signature xmlns="..." />
		</entry>
	</feed>

	<feed>
		[etc.]
	</feed>

	[etc.]
</aggregation>



From owner-atom-syntax@mail.imc.org  Tue Jun 21 12:11:57 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04420
	for <atompub-archive@lists.ietf.org>; Tue, 21 Jun 2005 12:11:57 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5LFevRf087916;
	Tue, 21 Jun 2005 08:40:57 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5LFevZC087914;
	Tue, 21 Jun 2005 08:40:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [165.227.249.220] (dsl2-63-249-92-231.cruzio.com [63.249.92.231])
	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5LFdV27086279;
	Tue, 21 Jun 2005 08:39:31 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: <p0623091dbedde3598a37@[165.227.249.220]>
In-Reply-To: <42B73208.7030304@gmail.com> <42B7A6B1.9050803@gmail.com>
 <42B794D4.4040101@gmail.com>
References: <1118943858.9048.6.camel@marge> <42B1CB81.3060101@gmail.com>
 <42B1CF84.5040508@dehora.net> <42B1EE41.9030304@gmail.com>
 <p0621025dbed80c5c0f0c@[10.20.30.249]> <42B73208.7030304@gmail.com>
 <1118943858.9048.6.camel@marge> <42B1CB81.3060101@gmail.com>
 <42B1CF84.5040508@dehora.net> <42B1EE41.9030304@gmail.com>
 <p0621025dbed80c5c0f0c@[10.20.30.249]> <42B73208.7030304@gmail.com>
 <001201c5761d$ae1db9c0$6600a8c0@IBMC101DE8DFED>
 <42B7A6B1.9050803@gmail.com> <1118943858.9048.6.camel@marge>
 <42B1CB81.3060101@gmail.com> <42B1CF84.5040508@dehora.net>
 <42B1EE41.9030304@gmail.com> <p0621025dbed80c5c0f0c@[10.20.30.249]>
 <42B73208.7030304@gmail.com>
 <c9bd5968a6f3a8e1742d98f727c297e8@rice.epostmail.org>
 <42B794D4.4040101@gmail.com>
Date: Tue, 21 Jun 2005 08:39:23 -0700
To: James M Snell <jasnell@gmail.com>, atom-syntax@imc.org,
        Dan Sandler <dsandler@cs.rice.edu>, Bob Wyman <bob@wyman.us>
From: Paul Hoffman <phoffman@imc.org>
Subject: Re: More on Atom XML signatures and 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>


At 2:15 PM -0700 6/20/05, James M Snell wrote:
>The spec already allows enveloped XML signatures for the document. 
>Question: should we only allow signing of the entire document or are 
>there valid use cases for allowing each individual entry in the feed 
>to be individually signed?

There are many valid use cases for both: that's why the spec 
explicitly allows both.

>I'm quite happy with limiting it to the first as I don't really see 
>much of a reason to support the second and third examples, but 
>wanted to see if anyone had any opinions or use cases that could 
>justify the ability to independently sign individual entries within 
>a feed.

The spec uses MAY for the conformance criteria, so no one has to 
support either.

At 9:17 PM -0700 6/20/05, James M Snell wrote:
>   In other words, if the entry in the first example above were to be 
>included in an aggregate feed containing entries from multiple 
>authors, the <author /> element from its containing feed would need 
>to be added to the entry element's collection of metadata... 
>(<entry>...</entry> becomes <entry> .. .<author /> ... </entry>) 
>thereby invalidating any signature calculated over the entry.

Fully disagree. No one is *forced* to add the collection of metadata 
to the entry. You give a very good reason why someone would not want 
to.

>   One would also have to contend with the potential problems 
>introduced by namespace declarations with the feed.  The bottom line 
>of this is that an entry with a signature could not simply be copied 
>over to a new containing feed element with the signature in tact 
>making the aggregator scenario unworkable.

Again, fully disagree. It is quite reasonable to pass along signed 
entries without changing them.

>So... given all this... I think I'm gong to make an assertion and 
>open that assertion up for debate:  The need for an end-to-end trust 
>model for Atom capable of traversing any number of intermediaries is 
>largely a myth.

How can we debate that before businesses have had a chance to create 
their models?

>  What is really needed is a simple mechanism for protecting feeds 
>against spoofed sources (e.g. man-in-the-middle serving up a bogus 
>feed) and for indicating that content is trustworthy* on the 
>document level (as opposed to individual feed entry level).
>* by which I mean, for example, binary enclosures are trustworthy, 
>the feed itself does not contain any malicious content, etc

This is a very different model than what we chose for Atom. It is 
possibly an interesting idea, but it isn't Atom.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Tue Jun 21 21:21:46 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04875
	for <atompub-archive@lists.ietf.org>; Tue, 21 Jun 2005 21:21:46 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5M0DVfK008754;
	Tue, 21 Jun 2005 17:13:31 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5M0DVjx008753;
	Tue, 21 Jun 2005 17:13:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.201])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5M0DQtJ008496
	for <atom-syntax@imc.org>; Tue, 21 Jun 2005 17:13:28 -0700 (PDT)
	(envelope-from jasnell@gmail.com)
Received: by rproxy.gmail.com with SMTP id a41so7539rng
        for <atom-syntax@imc.org>; Tue, 21 Jun 2005 17:13:14 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=IV6skdnsk/oC1QanE5D2/mlPyHmbThZoH0vh0l5lqBbxjHxGYAZ0haT5X0Ao/SsO2lCtgFwiSjge83m2OwuWJHCU53gw6Z16BhPoZ1p38WouNp8FcyaswGP/U62/sRvJd+qTn1qYd7KnzO2tr/qiCBTzbqpO2Nqdd+siBp0Dk64=
Received: by 10.38.152.40 with SMTP id z40mr86583rnd;
        Tue, 21 Jun 2005 17:13:14 -0700 (PDT)
Received: from ?192.168.1.103? ([67.181.223.222])
        by mx.gmail.com with ESMTP id h18sm113164rnb.2005.06.21.17.13.14;
        Tue, 21 Jun 2005 17:13:14 -0700 (PDT)
Message-ID: <42B8AD18.3030509@gmail.com>
Date: Tue, 21 Jun 2005 17:13:12 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Hoffman <phoffman@imc.org>, atom-syntax@imc.org
Subject: Re: More on Atom XML signatures and encryption
References: <1118943858.9048.6.camel@marge> <42B1CB81.3060101@gmail.com> <42B1CF84.5040508@dehora.net> <42B1EE41.9030304@gmail.com> <p0621025dbed80c5c0f0c@[10.20.30.249]> <42B73208.7030304@gmail.com> <1118943858.9048.6.camel@marge> <42B1CB81.3060101@gmail.com> <42B1CF84.5040508@dehora.net> <42B1EE41.9030304@gmail.com> <p0621025dbed80c5c0f0c@[10.20.30.249]> <42B73208.7030304@gmail.com> <001201c5761d$ae1db9c0$6600a8c0@IBMC101DE8DFED> <42B7A6B1.9050803@gmail.com> <1118943858.9048.6.camel@marge> <42B1CB81.3060101@gmail.com> <42B1CF84.5040508@dehora.net> <42B1EE41.9030304@gmail.com> <p0621025dbed80c5c0f0c@[10.20.30.249]> <42B73208.7030304@gmail.com> <c9bd5968a6f3a8e1742d98f727c297e8@rice.epostmail.org> <42B794D4.4040101@gmail.com> <p0623091dbedde3598a37@[165.227.249.220]>
In-Reply-To: <p0623091dbedde3598a37@[165.227.249.220]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


Paul Hoffman wrote:

>
> At 2:15 PM -0700 6/20/05, James M Snell wrote:
>
>> The spec already allows enveloped XML signatures for the document. 
>> Question: should we only allow signing of the entire document or are 
>> there valid use cases for allowing each individual entry in the feed 
>> to be individually signed?
>
>
> There are many valid use cases for both: that's why the spec 
> explicitly allows both.
>
 From the spec (Section 5)

   The root of an Atom document (i.e., atom:feed in an Atom Feed
   Document, atom:entry in an Atom Entry Document) MAY have an Enveloped
   Signature, as described by XML-Signature and Syntax Processing
   [W3C.REC-xmldsig-core-20020212].

   ...

   Other elements in an Atom Document MUST NOT be signed unless their
   definitions explicitly specify such a capability.

Given this language, the the spec only explicitly allows digital signing 
of the Atom Feed and Entry Documents.  It does not explicitly allow for 
digitally signing individual entries within a Feed document.  In fact, 
it explicitly forbids it given that the definition of <entry /> does not 
"explicitly specify" the capacity to be signed.

   <?xml ...?>
   <feed>
      <entry />
      <Signature />  <!-- is valid atom 1.0 -->
   </feed>

   <?xml ...?>
   <entry>
      <Signature />  <!-- is valid atom 1.0 -->
   </entry>

   <?xml ...?>
   <feed>
      <entry>
          <Signature /> <!-- does *not* appear to be valid atom 1.0 
given my interpretation of Section 5 -->
      </entry>
   </feed>

Is this a bug in the spec or am I reading the spec incorrectly?  If the 
former, then we need to get it resolved, because as it appears to read 
(to me anyway) we are not allowed to put Signatures within a Feeds entry 
elements.  If the latter, I'll thwack my head on the desk to see if that 
helps me to start making better sense of what I'm reading. :-)

>> I'm quite happy with limiting it to the first as I don't really see 
>> much of a reason to support the second and third examples, but wanted 
>> to see if anyone had any opinions or use cases that could justify the 
>> ability to independently sign individual entries within a feed.
>
>
> The spec uses MAY for the conformance criteria, so no one has to 
> support either.
>
> At 9:17 PM -0700 6/20/05, James M Snell wrote:
>
>>   In other words, if the entry in the first example above were to be 
>> included in an aggregate feed containing entries from multiple 
>> authors, the <author /> element from its containing feed would need 
>> to be added to the entry element's collection of metadata... 
>> (<entry>...</entry> becomes <entry> .. .<author /> ... </entry>) 
>> thereby invalidating any signature calculated over the entry.
>
>
> Fully disagree. No one is *forced* to add the collection of metadata 
> to the entry. You give a very good reason why someone would not want to.
>
The only way someone would not be forced to add author or 
source-w/author to the entry would be if digitally signed entry elements 
contained within a feed were required to be complete entries capable of 
standing alone as entry documents and were required to contain source 
elements as Bob has asserted.  If the author and/or source elements are 
missing from the entry, it would not work in an aggregated feed scenario 
without adding in those pieces of metadata.  The only solution for this 
(as has been noted in other notes in this thread) is a canonicalization 
scheme for signed entry elements.

>>   One would also have to contend with the potential problems 
>> introduced by namespace declarations with the feed.  The bottom line 
>> of this is that an entry with a signature could not simply be copied 
>> over to a new containing feed element with the signature in tact 
>> making the aggregator scenario unworkable.
>
>
> Again, fully disagree. It is quite reasonable to pass along signed 
> entries without changing them.
>
Only if such entries are canonicalized in order to remove any problems 
introduced by namespace declarations.

The entry in the example below...

   <feed xmlns:xhtml="http://www.w3.org/1999/xhtml" xmlns="...">
      <entry>
         <id>...</id>
         <content type="xhtml">
            <xhtml:div>...</xhtml:div>
         </content>
         <Signature xmlns="..."/>
      </entry>
   </feed>

Could not simply be reliably passed along unmodified to an aggregate 
feed that could quite possibly use a different set of namespace 
declarations.  e.g.

   <!-- aggregate feed with previous entry copied unmodified and 
obviously wrong -->
   <a:feed xmlns:a="..." xmlns="http://www.w3.org/1999/xhtml">
      <entry>
         <id>...</id>
         <content type="xhtml">
            <xhtml:div>...</xhtml:div>
         </content>
         <Signature xmlns="..."/>
      </entry>
   </a:feed>

Am I missing something fundamental here?

>> So... given all this... I think I'm gong to make an assertion and 
>> open that assertion up for debate:  The need for an end-to-end trust 
>> model for Atom capable of traversing any number of intermediaries is 
>> largely a myth.
>
>
> How can we debate that before businesses have had a chance to create 
> their models?
>
>>  What is really needed is a simple mechanism for protecting feeds 
>> against spoofed sources (e.g. man-in-the-middle serving up a bogus 
>> feed) and for indicating that content is trustworthy* on the document 
>> level (as opposed to individual feed entry level).
>> * by which I mean, for example, binary enclosures are trustworthy, 
>> the feed itself does not contain any malicious content, etc
>
>
> This is a very different model than what we chose for Atom. It is 
> possibly an interesting idea, but it isn't Atom.
>
?? I don't understand.  What part of my post "isn't Atom"?  My comment 
deals with potential security issues that are specifically discussed in 
the Security Considerations (Section 8) portion of the Atom spec. 

Specifically:

8.1 "... Many elements in these languages are considered 'unsafe' in 
that they open clients to one or
    more types of attack. Implementers of software which processes Atom 
should carefully consider
    their handling of every type of element when processing incoming 
(X)HTML in Atom documents.
    See the security sections of [RFC2854] and [HTML] for guidance."

8.4 "...Atom Processors should be aware of the potential for spoofing 
attacks where the attacker
    publishes an atom:entry with the atom:id value of an entry from 
another feed, perhaps with a falsified
    atom:source element duplicating the atom:id of the other feed."



> --Paul Hoffman, Director
> --Internet Mail Consortium
>
>



From owner-atom-syntax@mail.imc.org  Tue Jun 21 22:35:02 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10109
	for <atompub-archive@lists.ietf.org>; Tue, 21 Jun 2005 22:35:01 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5M22kWw074945;
	Tue, 21 Jun 2005 19:02:46 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5M22kuV074944;
	Tue, 21 Jun 2005 19:02:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pragmatix.bangor.ac.uk (pragmatix.bangor.ac.uk [147.143.2.14])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5M22inW074772
	for <atom-syntax@imc.org>; Tue, 21 Jun 2005 19:02:45 -0700 (PDT)
	(envelope-from s.wilson@bangor.ac.uk)
Received: from [192.168.0.5] (ppp1-88.lns1.syd3.internode.on.net [59.167.1.88])
	(authenticated bits=0)
	by pragmatix.bangor.ac.uk (8.13.3/8.13.3) with ESMTP id j5M220wI012138;
	Wed, 22 Jun 2005 03:02:20 +0100 (BST)
In-Reply-To: <42B73208.7030304@gmail.com>
References: <1118943858.9048.6.camel@marge> <42B1CB81.3060101@gmail.com> <42B1CF84.5040508@dehora.net> <42B1EE41.9030304@gmail.com> <p0621025dbed80c5c0f0c@[10.20.30.249]> <42B73208.7030304@gmail.com>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1--715727689; protocol="application/pkcs7-signature"
Message-Id: <c13d61fe149a4f8571c337114cd8c6b4@bangor.ac.uk>
Cc: atom-syntax@imc.org
From: Scott Wilson <s.wilson@bangor.ac.uk>
Subject: Re: More on Atom XML signatures and encryption
Date: Tue, 21 Jun 2005 13:43:12 +1000
To: James M Snell <jasnell@gmail.com>
X-Mailer: Apple Mail (2.622)
X-UWB-MailScanner-Information: Please contact the ISP for more information
X-UWB-MailScanner: Found to be clean
X-UWB-MailScanner-SpamCheck: nid sbam/not spam, SpamAssassin (sgor/score=0,
	yn ofynnol/required 4.5, autolearn=disabled)
X-UWB-MailScanner-From: s.wilson@bangor.ac.uk
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>



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

Here's a use-case:

I aggregate entries from several sources and create a composite feed. I 
want entries that were signed in the source feeds to still carry their 
original signatures in the composite feed, so that parsers can check 
that the entry has not been modified since it was issued by the 
original source.

A particular instance of this use-case is in education, where learning 
systems might export entries as part of evidence of learning (for 
example, posts from a collaborative course blog), which are then 
aggregated by the learner to create a single view across all their 
evidence from multiple providers. If this view is then published and 
used to support a claim (say, of skill competency), its important to be 
able to tell whether individual entries were modified by the learner 
after they were obtained from the providers.

For this use-case, option 2 must be possible.

Scott Wilson
http://www.cetis.ac.uk

On 21 Jun 2005, at 07:15, James M Snell wrote:

>
> OK, thanks to the feedback that has already been offered in this 
> thread I've been able to make progress on the XML Encryption side of 
> this.  Now to the digital signature side.  I'd like to get some 
> opinions on the following question:
>
> The spec already allows enveloped XML signatures for the document.  
> Question: should we only allow signing of the entire document or are 
> there valid use cases for allowing each individual entry in the feed 
> to be individually signed?  e.g.
>
>   <!-- Sign entire document -->
>   <feed>
>     <entry />
>     <entry />
>     <Signature />
>   </feed>
>
>   or
>
>   <!-- Each entry could have it's own signature. -->
>   <feed>
>      <entry>
>        <Signature /> <!-- covers the containing <entry />  -->
>      </entry>
>   </feed>
>
>   or
>
>   <!-- One signature for the feed, covering specific entries -->
>   <feed>
>      <entry>
>        <id>urn:abc...</id>
>      </entry>
>      <Signature>
>        <!-- use transform to select only the entry with id = 
> urn:abc... -->
>      </Signature>
>   </feed>
>
> I'm quite happy with limiting it to the first as I don't really see 
> much of a reason to support the second and third examples, but wanted 
> to see if anyone had any opinions or use cases that could justify the 
> ability to independently sign individual entries within a feed.
>
> - James
>

--Apple-Mail-1--715727689
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHjCCAtcw
ggJAoAMCAQICAw3OujANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIElzc3VpbmcgQ0EwHhcNMDUwMTE0MTEwNzEyWhcNMDYwMTE0MTEwNzEyWjBHMR8wHQYDVQQD
ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSQwIgYJKoZIhvcNAQkBFhVzLndpbHNvbkBiYW5nb3Iu
YWMudWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMwWdbFaYhh8ERJksHJ2MrUqNx
ydKBcqKMRIVC3XxeM4vll07hyNOFy9RjQFEDtkto9j5yX7nR/GkT+mq28nQuaefs2Gfa/y9Z8RSo
484IlwEv7I+gdvpEwX/T22V7giwvfj8+u7Q1WbY09lFtHfCw5GMcSZC49z+B/AxF2u1Yor0fBIWp
+hHjIBTIYm1EnB0JasJmkvGeS1XfxPx7CUUG6yQHfTcp0M9EPkxQwgz7cNFooQiF+M0fMmvJyMj0
vb5/kv7Hb85SDTfbAkJiugaQJ6cG/Io6hylI+fcyeeiV4DzWQJx+eVa5sVUEhuy+lrKrZf+Plpau
ZCHBSiKRxsAFAgMBAAGjMjAwMCAGA1UdEQQZMBeBFXMud2lsc29uQGJhbmdvci5hYy51azAMBgNV
HRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAFHyezlFfj3LiCxlH6ZyCCuJvQTnDfn1OfCdyjSW
BO2ONFULHREInXXA1vpPcet/v//T4vQLgK4MyUEkrmcrtUJuHDiqZ7YKQenfjhDCyRzv+5e525Zg
nSr3z0/GswLFya2VEvMWYyk4WJ5cOleDDZ0w2kRsE54rji3eryvPMomUMIIDPzCCAqigAwIBAgIB
DTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTES
MBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMf
Q2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs
IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29t
MB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT
HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG
cmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK
mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbL
rzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZ
cmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0
cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQD
AgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0B
AQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3h
YWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1
TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV
BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMNzrowCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsG
CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNjIxMDM0MzEzWjAjBgkqhkiG9w0BCQQxFgQU
jzmj1Te0ztwtuxM2iVtgwe8ba2wweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMG
A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv
bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw3OujB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro
YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMNzrowDQYJKoZIhvcNAQEBBQAEggEA
ndx4rVGUvZSB4SvfdxmGidqBOD32TLxJrt7RIM6Z3VoTLcpKvTwellMcn1XphPO3Glq2/XheiLlR
BxlDNYKecHKYvHF0dTgio2RM7rmaBmHm2dHsqTCsC8Fyx/EBE8cRLpFTqVyE37zR1xuljmphU7cj
bmOuAo7F+4RVFAJKjN2GFOnFD+BIsG/XaKMY+Z40DjzNEGeQ6aLbw2LJisWgNTdvWpT0F/hct7Hb
1TihZHl7NtIVjza60vIJmy+YcDCVMJNI5l+lIO2oueH5ds1QVHa+M+rXrlYnMe6EoUplpgKnvp8k
JY822isUDC465v++Xhp9V3cHcpkG95fIBHET+QAAAAAAAA==

--Apple-Mail-1--715727689--



From owner-atom-syntax@mail.imc.org  Wed Jun 22 00:37:34 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19426
	for <atompub-archive@lists.ietf.org>; Wed, 22 Jun 2005 00:37:33 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5M3dGbd025843;
	Tue, 21 Jun 2005 20:39:16 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5M3dG3s025842;
	Tue, 21 Jun 2005 20:39:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.25])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5M3dAw0025672
	for <atom-syntax@imc.org>; Tue, 21 Jun 2005 20:39:15 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Wed, 22 Jun 2005 13:39:01 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Wed, 22 Jun 2005 13:38:22 +1000
Subject: Re: More on Atom XML signatures and encryption
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BEDF1A4E.5FD47%eric.scheid@ironclad.net.au>
In-Reply-To: <p0623091dbedde3598a37@[165.227.249.220]>
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>
Content-Transfer-Encoding: 7bit


On 22/6/05 1:39 AM, "Paul Hoffman" <phoffman@imc.org> wrote:

>>   One would also have to contend with the potential problems
>> introduced by namespace declarations with the feed.  The bottom line
>> of this is that an entry with a signature could not simply be copied
>> over to a new containing feed element with the signature in tact
>> making the aggregator scenario unworkable.
> 
> Again, fully disagree. It is quite reasonable to pass along signed
> entries without changing them.

I think the problem is with clashing xmlns prefixes. Consider these two
separate feeds containing signed entries:

----------------------------------------------------------------
<feed xml:ns1="http://example.com/" ...>
    [...]
    <entry>
        [...]
        <Signature ... />
        <ns1:example-element>foo!</ns1:example-element>
    </entry>
</feed>

<feed xml:ns1="http://foo.com/" ...>
    [...]
    <entry>
        [...]
        <Signature ... />
        <ns1:foo-element>foo!</ns1:foo-element>
    </entry>
</feed>
----------------------------------------------------------------

The problem is the xmlns prefix "ns1" is used for two different namespaces.

Question: is the <entry> element itself included in the signature?

If not, then we can declare the xmlns:ns1 on the <entry> element ... but
we'd also need to disallow any extension or foreign attributes on the
<entry> (and <feed>) elements.

e.



From owner-atom-syntax@mail.imc.org  Wed Jun 22 01:42:49 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24594
	for <atompub-archive@lists.ietf.org>; Wed, 22 Jun 2005 01:42:48 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5M5FEt7091120;
	Tue, 21 Jun 2005 22:15:14 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5M5FE2r091119;
	Tue, 21 Jun 2005 22:15:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5M5F2H0090912
	for <atom-syntax@imc.org>; Tue, 21 Jun 2005 22:15:09 -0700 (PDT)
	(envelope-from jasnell@gmail.com)
Received: by wproxy.gmail.com with SMTP id 70so119368wra
        for <atom-syntax@imc.org>; Tue, 21 Jun 2005 22:14:56 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=Car1KlAWSlm5kcDax/XOlBU90zGaq8qX+IMUghHfiuA1aA4vG0rcuz/0GCVakPHegustQOgvme+oIUAI3OxgAh5I0DFdc7RAZ7PAjUUypfJt1jrmx+i06eXWK2tT9e0W9K7E1XRy6b1EnycW4851SBj6v3pQmz5TQ0pgmw54NVw=
Received: by 10.54.5.47 with SMTP id 47mr222537wre;
        Tue, 21 Jun 2005 22:14:56 -0700 (PDT)
Received: from ?192.168.1.103? ([67.181.223.222])
        by mx.gmail.com with ESMTP id 29sm708394wrl.2005.06.21.22.14.56;
        Tue, 21 Jun 2005 22:14:56 -0700 (PDT)
Message-ID: <42B8F3CD.5060108@gmail.com>
Date: Tue, 21 Jun 2005 22:14:53 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Eric Scheid <eric.scheid@ironclad.net.au>, atom-syntax@imc.org
Subject: Re: More on Atom XML signatures and encryption
References: <BEDF1A4E.5FD47%eric.scheid@ironclad.net.au>
In-Reply-To: <BEDF1A4E.5FD47%eric.scheid@ironclad.net.au>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


Eric Scheid wrote:

>On 22/6/05 1:39 AM, "Paul Hoffman" <phoffman@imc.org> wrote:
>
>  
>
>>>  One would also have to contend with the potential problems
>>>introduced by namespace declarations with the feed.  The bottom line
>>>of this is that an entry with a signature could not simply be copied
>>>over to a new containing feed element with the signature in tact
>>>making the aggregator scenario unworkable.
>>>      
>>>
>>Again, fully disagree. It is quite reasonable to pass along signed
>>entries without changing them.
>>    
>>
>
>I think the problem is with clashing xmlns prefixes. Consider these two
>separate feeds containing signed entries:
>
>----------------------------------------------------------------
><feed xml:ns1="http://example.com/" ...>
>    [...]
>    <entry>
>        [...]
>        <Signature ... />
>        <ns1:example-element>foo!</ns1:example-element>
>    </entry>
></feed>
>
><feed xml:ns1="http://foo.com/" ...>
>    [...]
>    <entry>
>        [...]
>        <Signature ... />
>        <ns1:foo-element>foo!</ns1:foo-element>
>    </entry>
></feed>
>----------------------------------------------------------------
>
>The problem is the xmlns prefix "ns1" is used for two different namespaces.
>
>Question: is the <entry> element itself included in the signature?
>
>  
>
Yes

>If not, then we can declare the xmlns:ns1 on the <entry> element ... but
>we'd also need to disallow any extension or foreign attributes on the
><entry> (and <feed>) elements.
>
>  
>
I am becoming increasingly convinced that a c14n algorithm is the *only* 
way to accomplish the goal here.  The algorithm would recast the entry 
being signed as a standalone entity with all appropriate namespace 
declarations, etc.  Validation of a signed entry would require first 
that the entry is extracted from the feed in accordance with the 
canonicalization. This will make it possible for us to evaluate the 
entry without the messy interference that the containing feed element 
introduces.  The only trick now is in coming up with the right algorithm.

>e.
>
>
>  
>



From owner-atom-syntax@mail.imc.org  Wed Jun 22 11:35:15 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24012
	for <atompub-archive@lists.ietf.org>; Wed, 22 Jun 2005 11:35:14 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5MFPGwK000737;
	Wed, 22 Jun 2005 08:25:16 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5MFPGAF000736;
	Wed, 22 Jun 2005 08:25:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.pubsub.com (mail.pubsub.com [209.11.36.150])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5MFPEwx000665
	for <atom-syntax@imc.org>; Wed, 22 Jun 2005 08:25:15 -0700 (PDT)
	(envelope-from bobwyman@pubsub.com)
Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34])
	(using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by mail.pubsub.com (Postfix) with ESMTP id 3CE73724A2C;
	Wed, 22 Jun 2005 11:25:07 -0400 (EDT)
Reply-To: <bobwyman@pubsub.com>
From: "Bob Wyman" <bobwyman@pubsub.com>
To: "'James M Snell'" <jasnell@gmail.com>,
        "'Eric Scheid'" <eric.scheid@ironclad.net.au>, <atom-syntax@imc.org>
Subject: RE: More on Atom XML signatures and encryption
Date: Wed, 22 Jun 2005 11:25:04 -0400
Organization: PubSub Concepts, Inc.
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
thread-index: AcV3JdDFNJMmL9glQfqPfQuDu74DbgAF2SVw
In-Reply-To: <42B8F3CD.5060108@gmail.com>
Message-Id: <20050622152507.3CE73724A2C@mail.pubsub.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>
Content-Transfer-Encoding: 7bit


James M Snell wrote:
> I am becoming increasingly convinced that a c14n algorithm is
> the *only* way to accomplish the goal here.
	The need for C14N should never have been questioned. Where there are
signatures, there *must* be C14N (Canonicalization). In the absence of
explicitly defined C14N rules, the C14N algorithm is simply: "Leave it as it
is!" -- but that is rarely useful and is certainly not useful in the case of
Atom.
	The only interesting question is "What is the C14N process for
Atom?" The question: "Is C14N required?" is rhetorical at best. The answer
is "Yes."

> The algorithm would recast the entry being signed as a standalone entity
> with all appropriate namespace declarations, etc.
	Precisely. It is also exceptionally important to ensure that a
source element be included in any signed entry in order to ensure that the
signed entry can be copied to other feeds without breaking the signature or
changing the semantics of the entry by allowing feed metadata from the
non-source feed to "bleed" into the entry.

		bob wyman




From owner-atom-syntax@mail.imc.org  Wed Jun 22 12:26:54 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28920
	for <atompub-archive@lists.ietf.org>; Wed, 22 Jun 2005 12:26:53 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5MGHomC057734;
	Wed, 22 Jun 2005 09:17:50 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5MGHoCQ057731;
	Wed, 22 Jun 2005 09:17:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.203])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5MGHkQl057611
	for <atom-syntax@imc.org>; Wed, 22 Jun 2005 09:17:48 -0700 (PDT)
	(envelope-from jasnell@gmail.com)
Received: by zproxy.gmail.com with SMTP id 13so351811nzp
        for <atom-syntax@imc.org>; Wed, 22 Jun 2005 09:17:40 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=XtvGHA+TJkf3Js6/dTIyoGTLCeJDYMLKr2a8zs8q6mCh3e/VKwJoIUcvigFHkfN6ZbXkfnyESmtsHOFfqIJmUck5JUUTFmxv7MfZWuHntXzjWoN0OTtTjOFhv4dZ9KE4EvqJzv+Ez56NKw00uF3T/mGFrR2hFgw9TDytMgz47QI=
Received: by 10.36.222.40 with SMTP id u40mr707569nzg;
        Wed, 22 Jun 2005 09:17:39 -0700 (PDT)
Received: from ?192.168.1.103? ([67.181.223.222])
        by mx.gmail.com with ESMTP id 15sm950224nzp.2005.06.22.09.17.39;
        Wed, 22 Jun 2005 09:17:39 -0700 (PDT)
Message-ID: <42B98F20.6050205@gmail.com>
Date: Wed, 22 Jun 2005 09:17:36 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: bobwyman@pubsub.com
CC: "'Eric Scheid'" <eric.scheid@ironclad.net.au>, atom-syntax@imc.org
Subject: Re: More on Atom XML signatures and encryption
References: <20050622152507.3CE73724A2C@mail.pubsub.com>
In-Reply-To: <20050622152507.3CE73724A2C@mail.pubsub.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


Bob Wyman wrote:

>James M Snell wrote:
>  
>
>>I am becoming increasingly convinced that a c14n algorithm is
>>the *only* way to accomplish the goal here.
>>    
>>
>	The need for C14N should never have been questioned. Where there are
>signatures, there *must* be C14N (Canonicalization). In the absence of
>explicitly defined C14N rules, the C14N algorithm is simply: "Leave it as it
>is!" -- but that is rarely useful and is certainly not useful in the case of
>Atom.
>	The only interesting question is "What is the C14N process for
>Atom?" The question: "Is C14N required?" is rhetorical at best. The answer
>is "Yes."
>
>  
>
Well, yeah, obviously ;-) I was never questioning the need for c14n, I 
was trying to figure out if some Atom specific c14n process is 
required.  Sorry if I wasn't being clear; it was based on the assumption 
that we all already knew that some form of c14n was going to be 
necessary no matter what.

>>The algorithm would recast the entry being signed as a standalone entity
>>with all appropriate namespace declarations, etc.
>>    
>>
>	Precisely. It is also exceptionally important to ensure that a
>source element be included in any signed entry in order to ensure that the
>signed entry can be copied to other feeds without breaking the signature or
>changing the semantics of the entry by allowing feed metadata from the
>non-source feed to "bleed" into the entry.
>
>  
>
Right.   So what else is it going to need to do?

Given that I typically do not use any online aggregation services I'm 
not sure if it is typical for such aggregators to insert metadata into 
the entries they serve up?

>		bob wyman
>
>
>
>  
>



From owner-atom-syntax@mail.imc.org  Wed Jun 22 13:26:31 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05527
	for <atompub-archive@lists.ietf.org>; Wed, 22 Jun 2005 13:26:31 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5MHHXTB016274;
	Wed, 22 Jun 2005 10:17:33 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5MHHXh5016273;
	Wed, 22 Jun 2005 10:17:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231])
	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5MHHVEB016240
	for <atom-syntax@imc.org>; Wed, 22 Jun 2005 10:17:32 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: <p0623090fbedf4d60ef07@[10.20.30.249]>
Date: Wed, 22 Jun 2005 10:17:29 -0700
To: Atom WG <atom-syntax@imc.org>
From: Paul Hoffman <phoffman@imc.org>
Subject: Signature wording
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>


Greetings again. The recent thread on digital signatures has shown a 
few areas that need to be clarified. I propose the following and ask 
for discussion. That is, I am *not* stating this is consensus, 
although it would be grand if it was.

1) We made a mistake, and we really meant to allow signing of 
stand-alone feeds, stand-alone entries, *and* entries in feeds. 
Proposed change:

Current:
    The root of an Atom document (i.e., atom:feed in an Atom Feed
    Document, atom:entry in an Atom Entry Document) MAY have an Enveloped
    Signature, as described by XML-Signature and Syntax Processing
    [W3C.REC-xmldsig-core-20020212].
New:
    The root of an Atom document (i.e., atom:feed in an Atom Feed
    Document, atom:entry in an Atom Entry Document), or any atom:entry
    element, MAY have an Enveloped
    Signature, as described by XML-Signature and Syntax Processing
    [W3C.REC-xmldsig-core-20020212].


2) What you are signing is just the set of bits in the entry, or just 
the set of bits in the feed, with no interpretation of them. No 
pre-canonicalization is needed, and none is to be expected by the 
validating party.

I truly don't believe that any change is needed to the format 
document to reflect this. There is nothing in section 5 that the 
signature is over the "bits plus everything relevant at the time of 
the signature". Bear in mind that because of the compulsory presence 
of <atom:id> and <atom:updated> in every entry, some of the benefits 
of canonicalization (reducing ambiguity in comparisons) are not 
material.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org Wed Jun 22 14:03:57 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dl9Zt-0005oa-FM
	for atompub-archive@megatron.ietf.org; Wed, 22 Jun 2005 14:03:57 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07745
	for <atompub-archive@lists.ietf.org>; Wed, 22 Jun 2005 14:03:55 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5MHnQoo050999;
	Wed, 22 Jun 2005 10:49:26 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5MHnQfU050998;
	Wed, 22 Jun 2005 10:49:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5MHnMUD050815
	for <atom-syntax@imc.org>; Wed, 22 Jun 2005 10:49:22 -0700 (PDT)
	(envelope-from antone@geckotribe.com)
Received: from geckotribe.com (c-67-169-250-63.hsd1.ut.comcast.net[67.169.250.63])
          by comcast.net (sccrmhc11) with SMTP
          id <2005062217491601100qrhife>; Wed, 22 Jun 2005 17:49:16 +0000
Date: Wed, 22 Jun 2005 11:49:15 -0600
Subject: Re: Signature wording
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v553)
From: Antone Roundy <antone@geckotribe.com>
To: atom-syntax@imc.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <42B9A0AF.5040100@gmail.com>
Message-Id: <F32770C8-E345-11D9-AEC4-003065EA6144@geckotribe.com>
X-Mailer: Apple Mail (2.553)
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: 7bit


On Wednesday, June 22, 2005, at 11:32  AM, James M Snell wrote:
> Paul Hoffman wrote:
>> 2) What you are signing is just the set of bits in the entry, or just 
>> the set of bits in the feed, with no interpretation of them. No 
>> pre-canonicalization is needed, and none is to be expected by the 
>> validating party.
>>
> Hmm... not sure about this one.  We've already demonstrated via 
> several examples that things like XML namespaces and the lack of a 
> source element can cause problems in aggregator scenarios and that 
> some form of atom-specific canonicalization may be required.  Can you 
> expand a bit on your assertion with a few examples?  Some angle 
> brackets would really help me understand exactly where you're coming 
> from.

I take it, Paul, that you're suggesting that we punt on ensuring that 
entries can be aggregated without breaking signatures.  If so, we might 
consider suggesting some guidelines for maximizing the probability of a 
signature remaining valid, such as including a <source> element in each 
signed <entry>, using the most commonly used namespace prefixes for any 
namespaces used in the entry, and using UTF-8 (or whatever is most 
common for the language the feed is published in).




From owner-atom-syntax@mail.imc.org Wed Jun 22 14:06:19 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dl9cA-0005yh-V2
	for atompub-archive@megatron.ietf.org; Wed, 22 Jun 2005 14:06:19 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08498
	for <atompub-archive@lists.ietf.org>; Wed, 22 Jun 2005 14:06:16 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5MHsp8h057124;
	Wed, 22 Jun 2005 10:54:51 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5MHspRY057122;
	Wed, 22 Jun 2005 10:54:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231])
	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5MHshUK057039;
	Wed, 22 Jun 2005 10:54:45 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: <p06230912bedf553fc758@[10.20.30.249]>
In-Reply-To: <42B9A0AF.5040100@gmail.com>
References: <p0623090fbedf4d60ef07@[10.20.30.249]>
 <42B9A0AF.5040100@gmail.com>
Date: Wed, 22 Jun 2005 10:54:42 -0700
To: James M Snell <jasnell@gmail.com>, atom-syntax@imc.org
From: Paul Hoffman <phoffman@imc.org>
Subject: Re: Signature wording
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>


At 10:32 AM -0700 6/22/05, James M Snell wrote:
>Paul Hoffman wrote:
>>2) What you are signing is just the set of bits in the entry, or 
>>just the set of bits in the feed, with no interpretation of them. 
>>No pre-canonicalization is needed, and none is to be expected by 
>>the validating party.
>>
>>I truly don't believe that any change is needed to the format 
>>document to reflect this. There is nothing in section 5 that the 
>>signature is over the "bits plus everything relevant at the time of 
>>the signature". Bear in mind that because of the compulsory 
>>presence of <atom:id> and <atom:updated> in every entry, some of 
>>the benefits of canonicalization (reducing ambiguity in 
>>comparisons) are not material.
>>
>Hmm... not sure about this one.  We've already demonstrated via 
>several examples that things like XML namespaces and the lack of a 
>source element can cause problems in aggregator scenarios and that 
>some form of atom-specific canonicalization may be required.

I don't feel like you have demonstrated that. You have demonstrated 
that an aggregator might need to change some signed entries when they 
aggregate: that will inherently break the signature, and the 
aggregator will need to sign the entry themselves. But that's part of 
the aggregator's business model, not the Atom model. "We found this 
entry, we cleaned it up so you can use it, and we sign this set of 
bits so you know it is exactly what we emitted". If they want, they 
can also include the signed-and-unchanged original.

>   Can you expand a bit on your assertion with a few examples?  Some 
>angle brackets would really help me understand exactly where you're 
>coming from.

But that's exactly the point: no angle brackets are needed to 
understand "the set of bits in the entry". The signature is over the 
exact characters being signed, not some understanding of them based 
on namespaces, source elements, and so on. That's the difference 
between "bits" and "bits plus everything relevant at the time of the 
signature".

--Paul Hoffman, Director
--Internet Mail Consortium




From owner-atom-syntax@mail.imc.org Wed Jun 22 14:52:34 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DlAKw-0005dw-A0
	for atompub-archive@megatron.ietf.org; Wed, 22 Jun 2005 14:52:34 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16628
	for <atompub-archive@lists.ietf.org>; Wed, 22 Jun 2005 14:52:31 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5MIkBG4014892;
	Wed, 22 Jun 2005 11:46:11 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5MIkBig014885;
	Wed, 22 Jun 2005 11:46:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231])
	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5MIk8gF014827;
	Wed, 22 Jun 2005 11:46:09 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: <p06230914bedf615d9e89@[10.20.30.249]>
In-Reply-To: <F32770C8-E345-11D9-AEC4-003065EA6144@geckotribe.com>
References: <F32770C8-E345-11D9-AEC4-003065EA6144@geckotribe.com>
Date: Wed, 22 Jun 2005 11:46:06 -0700
To: Antone Roundy <antone@geckotribe.com>, atom-syntax@imc.org
From: Paul Hoffman <phoffman@imc.org>
Subject: Re: Signature wording
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>


At 11:49 AM -0600 6/22/05, Antone Roundy wrote:
>I take it, Paul, that you're suggesting that we punt on ensuring 
>that entries can be aggregated without breaking signatures.

Exactly right.

>If so, we might consider suggesting some guidelines for maximizing 
>the probability of a signature remaining valid, such as including a 
><source> element in each signed <entry>, using the most commonly 
>used namespace prefixes for any namespaces used in the entry, and 
>using UTF-8 (or whatever is most common for the language the feed is 
>published in).

Someone might want to work on a document that advises (not mandates) 
a way to canonicalize the heck out of an entry to reduce the 
likelihood that an aggregator would want to change any bits in the 
entry, regardless of whether or not the entry is signed. We cannot 
tell aggregators that they cannot change bits in an signed entry: 
they might choose to do so even though it would break the signature 
because the bits they are changing are more important than the 
signature. For example, the aggregator may know the end recipient 
can't validate the signature anyway, or the aggregator may know that 
the signature was broken before they got the entry.

Such a document would probably be useful, or it might just be a 
useful entry in the implementer's guide. Getting input from some 
currently-active aggregators would be really useful for that, of 
course.

--Paul Hoffman, Director
--Internet Mail Consortium




From owner-atom-syntax@mail.imc.org Wed Jun 22 15:03:45 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DlAVl-00015e-Ql
	for atompub-archive@megatron.ietf.org; Wed, 22 Jun 2005 15:03:45 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17590
	for <atompub-archive@lists.ietf.org>; Wed, 22 Jun 2005 15:03:43 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5MItJOs024566;
	Wed, 22 Jun 2005 11:55:19 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5MItJQH024565;
	Wed, 22 Jun 2005 11:55:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.201])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5MItHiQ024466
	for <atom-syntax@imc.org>; Wed, 22 Jun 2005 11:55:18 -0700 (PDT)
	(envelope-from jasnell@gmail.com)
Received: by rproxy.gmail.com with SMTP id a41so163324rng
        for <atom-syntax@imc.org>; Wed, 22 Jun 2005 11:55:15 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=eidlFqnTuVCTq9scPxM4t2U2+mIqH46LEYrmMpyhZt6BTgHblr2boLpudZx2AepZFhf8nRYRd5+8sQsQLX+IOj+Dvg7y8qCYVo4IiAfPAsKxF6gH3VZYl1144Z9IQuFM3bXBi9s26r0TktxefL8X1WuMnQnoyx3qi5R+xcgjoyg=
Received: by 10.38.73.41 with SMTP id v41mr470302rna;
        Wed, 22 Jun 2005 11:55:15 -0700 (PDT)
Received: from ?192.168.1.103? ([67.181.223.222])
        by mx.gmail.com with ESMTP id 79sm688106rnc.2005.06.22.11.55.14;
        Wed, 22 Jun 2005 11:55:15 -0700 (PDT)
Message-ID: <42B9B40F.2070605@gmail.com>
Date: Wed, 22 Jun 2005 11:55:11 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Hoffman <phoffman@imc.org>, atom-syntax@imc.org
Subject: Re: Signature wording
References: <p0623090fbedf4d60ef07@[10.20.30.249]> <42B9A0AF.5040100@gmail.com> <p06230912bedf553fc758@[10.20.30.249]>
In-Reply-To: <p06230912bedf553fc758@[10.20.30.249]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


Paul Hoffman wrote:

> At 10:32 AM -0700 6/22/05, James M Snell wrote:
>
>> Paul Hoffman wrote:
>>
>>> 2) What you are signing is just the set of bits in the entry, or 
>>> just the set of bits in the feed, with no interpretation of them. No 
>>> pre-canonicalization is needed, and none is to be expected by the 
>>> validating party.
>>>
>>> I truly don't believe that any change is needed to the format 
>>> document to reflect this. There is nothing in section 5 that the 
>>> signature is over the "bits plus everything relevant at the time of 
>>> the signature". Bear in mind that because of the compulsory presence 
>>> of <atom:id> and <atom:updated> in every entry, some of the benefits 
>>> of canonicalization (reducing ambiguity in comparisons) are not 
>>> material.
>>>
>> Hmm... not sure about this one.  We've already demonstrated via 
>> several examples that things like XML namespaces and the lack of a 
>> source element can cause problems in aggregator scenarios and that 
>> some form of atom-specific canonicalization may be required.
>
>
> I don't feel like you have demonstrated that. You have demonstrated 
> that an aggregator might need to change some signed entries when they 
> aggregate: that will inherently break the signature, and the 
> aggregator will need to sign the entry themselves. But that's part of 
> the aggregator's business model, not the Atom model. "We found this 
> entry, we cleaned it up so you can use it, and we sign this set of 
> bits so you know it is exactly what we emitted". If they want, they 
> can also include the signed-and-unchanged original.
>
Ok, I think this clears up the disconnect a bit.  What I'm shooting for 
is a way of allowing aggregators to pass entries along as is without 
breaking the original signature -- something that you do not seem to 
think is important (correct?).  The demonstrations I've provided to this 
point have shown that an aggregator would almost certainly have to break 
the signature even if it is not adding any value or peforming any 
processing on the entry, which obviously misses the mark a bit. 

Three models:

1. Subscriber directly accesses a digitally signed source feed.
2. Subscriber receives entries via an aggregator that modifies entries, 
breaking any signatures that exist, potentially re-signs the entries
3. Subscriber receives entries via an aggregator that does not modify 
entries, aggregator wishes to pass those along in a way that does not 
break any of the original signatures

1 and 2 are easy.  They really don't require a lot of discussion.  #3 is 
where the problem appears to exists.

The only reason I've seen thus far to digitally sign individual entries 
within a feed is to enable aggregation scenarios so it really doesn't 
seem to make a lot of sense if the solution requires aggregators to 
break signatures within entries in order to aggregate those entries.  If 
breaking the signature is required, might as well just sign the source 
feed document and skip signing the entries at all. So your change in #1 
would be unnecessary

Note that I am not trying to change Atom's model or the core spec, I am 
trying to define an Atom extension that is capable of meeting a specific 
problem space that happens to include the types of things aggregators 
are going to want to be able to do.  I just don't want Atom to get in 
the way like it does now with not allowing Signatures on child <entry /> 
elements.  Adding any kind of language that precludes the ability to 
accomplish #3 unnecessarily gets in the way of the solution.  I'm not 
sure if the second item in your original note is suggesting that such 
language be added ???

>>   Can you expand a bit on your assertion with a few examples?  Some 
>> angle brackets would really help me understand exactly where you're 
>> coming from.
>
>
> But that's exactly the point: no angle brackets are needed to 
> understand "the set of bits in the entry". The signature is over the 
> exact characters being signed, not some understanding of them based on 
> namespaces, source elements, and so on. That's the difference between 
> "bits" and "bits plus everything relevant at the time of the signature".
>
An example would be necessary to show how to accomplish #3 ONLY IF you 
agreed that providing an aggregators ability to pass along an entry 
unmodified with the original signature in tact was an important thing to 
do, which does not appear to be the case (please correct me if I'm wrong)

> --Paul Hoffman, Director
> --Internet Mail Consortium
>

- James





From owner-atom-syntax@mail.imc.org Wed Jun 22 15:10:43 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DlAcV-0003CB-PQ
	for atompub-archive@megatron.ietf.org; Wed, 22 Jun 2005 15:10:43 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18614
	for <atompub-archive@lists.ietf.org>; Wed, 22 Jun 2005 15:10:41 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5MJ3rn6033355;
	Wed, 22 Jun 2005 12:03:54 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5MJ3r01033349;
	Wed, 22 Jun 2005 12:03:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.202])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5MJ3quj033210
	for <atom-syntax@imc.org>; Wed, 22 Jun 2005 12:03:52 -0700 (PDT)
	(envelope-from jasnell@gmail.com)
Received: by wproxy.gmail.com with SMTP id 55so516209wri
        for <atom-syntax@imc.org>; Wed, 22 Jun 2005 12:03:46 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=hhxjaUpljv0X4I6nvfDg/443JFgWUl1aWPqc5u+UHGYdH8oojopPJZo5gecaDR+w5c59x3T7ALXCdAVNBbwxYgBDPY4tXmK51eJbYmF+mTonQ4SZxZY8GU35QnV8GDbfkei4cc/vb99Z/BZtwabuIL7gFUlGNQncv5QoSH+c/S8=
Received: by 10.54.57.56 with SMTP id f56mr633199wra;
        Wed, 22 Jun 2005 12:03:46 -0700 (PDT)
Received: from ?192.168.1.103? ([67.181.223.222])
        by mx.gmail.com with ESMTP id g9sm1949188wra.2005.06.22.12.03.45;
        Wed, 22 Jun 2005 12:03:46 -0700 (PDT)
Message-ID: <42B9B60C.3030108@gmail.com>
Date: Wed, 22 Jun 2005 12:03:40 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Hoffman <phoffman@imc.org>
CC: Antone Roundy <antone@geckotribe.com>, atom-syntax@imc.org
Subject: Re: Signature wording
References: <F32770C8-E345-11D9-AEC4-003065EA6144@geckotribe.com> <p06230914bedf615d9e89@[10.20.30.249]>
In-Reply-To: <p06230914bedf615d9e89@[10.20.30.249]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


Paul Hoffman wrote:

>
> At 11:49 AM -0600 6/22/05, Antone Roundy wrote:
>
>> I take it, Paul, that you're suggesting that we punt on ensuring that 
>> entries can be aggregated without breaking signatures.
>
>
> Exactly right.
>
In the core Atom spec, absolutely.

>> If so, we might consider suggesting some guidelines for maximizing 
>> the probability of a signature remaining valid, such as including a 
>> <source> element in each signed <entry>, using the most commonly used 
>> namespace prefixes for any namespaces used in the entry, and using 
>> UTF-8 (or whatever is most common for the language the feed is 
>> published in).
>
>
> Someone might want to work on a document that advises (not mandates) a 
> way to canonicalize the heck out of an entry to reduce the likelihood 
> that an aggregator would want to change any bits in the entry, 
> regardless of whether or not the entry is signed. We cannot tell 
> aggregators that they cannot change bits in an signed entry: they 
> might choose to do so even though it would break the signature because 
> the bits they are changing are more important than the signature. For 
> example, the aggregator may know the end recipient can't validate the 
> signature anyway, or the aggregator may know that the signature was 
> broken before they got the entry.
>
I'm planning to write a separate Internet-Draft that discusses digital 
signing of Atom feeds and entries.  Some parts of that document will 
includes mandates; other parts will include recommendations.  We can 
describe for entry producers a way of producing signed entries that can 
be aggregated with original signatures in tact and a set of 
recommendations to aggregators that wish to pass those signed entries 
around with signatures in tact.  Sure, it's all up to the aggregators 
and content providers to decide whether or not they want to support 
those methods -- which is the whole point of I'm working on this as a 
separate I-D and positioning it as an optional extension to Atom. :-)

> Such a document would probably be useful, or it might just be a useful 
> entry in the implementer's guide. Getting input from some 
> currently-active aggregators would be really useful for that, of course.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium
>
>
- James




From owner-atom-syntax@mail.imc.org Wed Jun 22 16:05:23 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DlBTP-0003TP-A2
	for atompub-archive@megatron.ietf.org; Wed, 22 Jun 2005 16:05:23 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26979
	for <atompub-archive@lists.ietf.org>; Wed, 22 Jun 2005 16:05:20 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5MJKXFJ049823;
	Wed, 22 Jun 2005 12:20:34 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5MJKX0F049814;
	Wed, 22 Jun 2005 12:20:33 -0700 (PDT)
X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j5MJKVaC049753;
	Wed, 22 Jun 2005 12:20:31 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j5MJKVw4004225;
	Wed, 22 Jun 2005 13:20:31 -0600 (MDT)
Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004))
 with ESMTP id <0III0080R326MR@edgemail1.Central.Sun.COM>; Wed,
 22 Jun 2005 13:20:31 -0600 (MDT)
Received: from [192.168.102.100] ([154.20.140.182])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004))
 with ESMTPSA id <0III00BRS325A7@mail.sun.net>; Wed,
 22 Jun 2005 13:20:30 -0600 (MDT)
Date: Wed, 22 Jun 2005 12:20:47 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Signature wording
In-reply-to: <42B9B40F.2070605@gmail.com>
To: James M Snell <jasnell@gmail.com>
Cc: Paul Hoffman <phoffman@imc.org>, atom-syntax@imc.org
Message-id: <BF87D16D-FB0D-4E32-9E52-D66311EDA795@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.730)
Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Content-transfer-encoding: 7BIT
References: <p0623090fbedf4d60ef07@[10.20.30.249]> <42B9A0AF.5040100@gmail.com>
 <p06230912bedf553fc758@[10.20.30.249]> <42B9B40F.2070605@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>
Content-Transfer-Encoding: 7BIT


On Jun 22, 2005, at 11:55 AM, James M Snell wrote:

>
> Note that I am not trying to change Atom's model or the core spec,

We do agree on Paul's suggested changed saying "it's OK to sign  
entries" though, I think.

> I am trying to define an Atom extension that is capable of meeting  
> a specific problem space that happens to include the types of  
> things aggregators are going to want to be able to do.

I think this is a good idea.  I'd be pretty strongly against us  
trying to write some sort of c14n language into the format spec  
because we have little prior art to draw on with respect to XML  
DigSig in general, and exactly zero (as far as I know) to draw on for  
digsig in a feed or aggregated-feed context.  So we just totally  
don't know how this is going to shake down in the market.

So I agree.  Remove the prohibition on signing entries, and let the  
engineers figure out what works. -Tim




From owner-atom-syntax@mail.imc.org Wed Jun 22 16:06:45 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DlBUj-0003vy-3Q
	for atompub-archive@megatron.ietf.org; Wed, 22 Jun 2005 16:06:45 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27027
	for <atompub-archive@lists.ietf.org>; Wed, 22 Jun 2005 16:06:42 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5MJMFCE051497;
	Wed, 22 Jun 2005 12:22:15 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5MJMFxW051491;
	Wed, 22 Jun 2005 12:22:15 -0700 (PDT)
X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j5MJMEcF051477;
	Wed, 22 Jun 2005 12:22:14 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j5MJMDqg001727;
	Wed, 22 Jun 2005 13:22:13 -0600 (MDT)
Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004))
 with ESMTP id <0III008OS351L1@edgemail1.Central.Sun.COM>; Wed,
 22 Jun 2005 13:22:13 -0600 (MDT)
Received: from [192.168.102.100] ([154.20.140.182])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004))
 with ESMTPSA id <0III00BXN350AA@mail.sun.net>; Wed,
 22 Jun 2005 13:22:13 -0600 (MDT)
Date: Wed, 22 Jun 2005 12:22:29 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Signature wording
In-reply-to: <42B9B60C.3030108@gmail.com>
To: James M Snell <jasnell@gmail.com>
Cc: Paul Hoffman <phoffman@imc.org>, Antone Roundy <antone@geckotribe.com>,
        atom-syntax@imc.org
Message-id: <79555C5A-D775-48B8-8BBD-1BF630F860D4@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.730)
Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Content-transfer-encoding: 7BIT
References: <F32770C8-E345-11D9-AEC4-003065EA6144@geckotribe.com>
 <p06230914bedf615d9e89@[10.20.30.249]> <42B9B60C.3030108@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>
Content-Transfer-Encoding: 7BIT


On Jun 22, 2005, at 12:03 PM, James M Snell wrote:

> I'm planning to write a separate Internet-Draft that discusses  
> digital signing of Atom feeds and entries.  Some parts of that  
> document will includes mandates; other parts will include  
> recommendations.  We can describe for entry producers a way of  
> producing signed entries that can be aggregated with original  
> signatures in tact and a set of recommendations to aggregators that  
> wish to pass those signed entries around with signatures in tact.   
> Sure, it's all up to the aggregators and content providers to  
> decide whether or not they want to support those methods -- which  
> is the whole point of I'm working on this as a separate I-D and  
> positioning it as an optional extension to Atom. :-)

A man who spots a problem, then volunteers to do the work around  
fixing it!  We need more like that.  I suspect that there's an  
excellent chance that this might become a WG draft, but I remained  
concerned about our lack of hands-on experience. -Tim




From owner-atom-syntax@mail.imc.org Wed Jun 22 16:42:05 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DlC2v-0007PO-1l
	for atompub-archive@megatron.ietf.org; Wed, 22 Jun 2005 16:42:05 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03257
	for <atompub-archive@lists.ietf.org>; Wed, 22 Jun 2005 16:42:01 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5MJXU4S063336;
	Wed, 22 Jun 2005 12:33:30 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5MJXUwL063334;
	Wed, 22 Jun 2005 12:33:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5MJXShF063309
	for <atom-syntax@imc.org>; Wed, 22 Jun 2005 12:33:29 -0700 (PDT)
	(envelope-from jasnell@gmail.com)
Received: by zproxy.gmail.com with SMTP id 18so566806nzp
        for <atom-syntax@imc.org>; Wed, 22 Jun 2005 12:33:23 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=MBjT3fQfkVyxLJ83CnmXMR4v4mSO9qe2T1MWKUHch3vZUnK7YS/eX2OSCTIDDxDI8xaoNvvS5oxtiyZHyorC++OQiuVpuf8QNsFFhotw4VkjigC4nw1/6nyG9297SnVQFd6aCzdvtGL72WWLGXBgq+k2nriUCj9ra5a0tttktjM=
Received: by 10.36.108.16 with SMTP id g16mr779825nzc;
        Wed, 22 Jun 2005 12:33:23 -0700 (PDT)
Received: from ?192.168.1.103? ([67.181.223.222])
        by mx.gmail.com with ESMTP id m2sm735658nzf.2005.06.22.12.33.21;
        Wed, 22 Jun 2005 12:33:23 -0700 (PDT)
Message-ID: <42B9BCFD.7010105@gmail.com>
Date: Wed, 22 Jun 2005 12:33:17 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tim Bray <Tim.Bray@Sun.COM>
CC: Paul Hoffman <phoffman@imc.org>, Antone Roundy <antone@geckotribe.com>,
        atom-syntax@imc.org
Subject: Re: Signature wording
References: <F32770C8-E345-11D9-AEC4-003065EA6144@geckotribe.com> <p06230914bedf615d9e89@[10.20.30.249]> <42B9B60C.3030108@gmail.com> <79555C5A-D775-48B8-8BBD-1BF630F860D4@sun.com>
In-Reply-To: <79555C5A-D775-48B8-8BBD-1BF630F860D4@sun.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


Tim Bray wrote:

> On Jun 22, 2005, at 12:03 PM, James M Snell wrote:
>
>> I'm planning to write a separate Internet-Draft that discusses  
>> digital signing of Atom feeds and entries.  Some parts of that  
>> document will includes mandates; other parts will include  
>> recommendations.  We can describe for entry producers a way of  
>> producing signed entries that can be aggregated with original  
>> signatures in tact and a set of recommendations to aggregators that  
>> wish to pass those signed entries around with signatures in tact.   
>> Sure, it's all up to the aggregators and content providers to  decide 
>> whether or not they want to support those methods -- which  is the 
>> whole point of I'm working on this as a separate I-D and  positioning 
>> it as an optional extension to Atom. :-)
>
>
> A man who spots a problem, then volunteers to do the work around  
> fixing it!  We need more like that.  I suspect that there's an  
> excellent chance that this might become a WG draft, but I remained  
> concerned about our lack of hands-on experience. -Tim
>
>
The lack of hands on experience is a big issue.  What I'd like to see is 
a) I/we draft the I-D describing the details, b) get some aggregator 
folks (Bob?) to implement a prototype based on it, c) start iterating 
the I-D and implementations accordingly.  If we can get some committment 
from the aggregator folks to start doing some implementation work, our 
job is going to become much easier.




From owner-atom-syntax@mail.imc.org Wed Jun 22 19:01:07 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DlEDT-0004vM-Ff
	for atompub-archive@megatron.ietf.org; Wed, 22 Jun 2005 19:01:07 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15488
	for <atompub-archive@lists.ietf.org>; Wed, 22 Jun 2005 19:01:03 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5MHWg3S032603;
	Wed, 22 Jun 2005 10:32:42 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5MHWg3t032602;
	Wed, 22 Jun 2005 10:32:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5MHWfEZ032516
	for <atom-syntax@imc.org>; Wed, 22 Jun 2005 10:32:41 -0700 (PDT)
	(envelope-from jasnell@gmail.com)
Received: by zproxy.gmail.com with SMTP id 13so394023nzp
        for <atom-syntax@imc.org>; Wed, 22 Jun 2005 10:32:35 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=JVmzIUvAMb069Cno6t+u0vFFufoD2/Nq1hTFzBsPRQQ1tt0WuI5GkESBKF63q7GoVwfgXkgZcsEQe8xHG8VJ0dF4ikffNyRY8d5Psa+3czONU22PLtUYhXmWOY2NmPy2zyo9x7XvlHPixRdWABnJ595/dTksKuER3gkQ7WXdPrA=
Received: by 10.36.23.9 with SMTP id 9mr733394nzw;
        Wed, 22 Jun 2005 10:32:35 -0700 (PDT)
Received: from ?192.168.1.103? ([67.181.223.222])
        by mx.gmail.com with ESMTP id 15sm1018279nzp.2005.06.22.10.32.35;
        Wed, 22 Jun 2005 10:32:35 -0700 (PDT)
Message-ID: <42B9A0AF.5040100@gmail.com>
Date: Wed, 22 Jun 2005 10:32:31 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Hoffman <phoffman@imc.org>, atom-syntax@imc.org
Subject: Re: Signature wording
References: <p0623090fbedf4d60ef07@[10.20.30.249]>
In-Reply-To: <p0623090fbedf4d60ef07@[10.20.30.249]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


Paul Hoffman wrote:

>
> Greetings again. The recent thread on digital signatures has shown a 
> few areas that need to be clarified. I propose the following and ask 
> for discussion. That is, I am *not* stating this is consensus, 
> although it would be grand if it was.
>
> 1) We made a mistake, and we really meant to allow signing of 
> stand-alone feeds, stand-alone entries, *and* entries in feeds. 
> Proposed change:
>
> Current:
>    The root of an Atom document (i.e., atom:feed in an Atom Feed
>    Document, atom:entry in an Atom Entry Document) MAY have an Enveloped
>    Signature, as described by XML-Signature and Syntax Processing
>    [W3C.REC-xmldsig-core-20020212].
> New:
>    The root of an Atom document (i.e., atom:feed in an Atom Feed
>    Document, atom:entry in an Atom Entry Document), or any atom:entry
>    element, MAY have an Enveloped
>    Signature, as described by XML-Signature and Syntax Processing
>    [W3C.REC-xmldsig-core-20020212].
>
+1

>
> 2) What you are signing is just the set of bits in the entry, or just 
> the set of bits in the feed, with no interpretation of them. No 
> pre-canonicalization is needed, and none is to be expected by the 
> validating party.
>
> I truly don't believe that any change is needed to the format document 
> to reflect this. There is nothing in section 5 that the signature is 
> over the "bits plus everything relevant at the time of the signature". 
> Bear in mind that because of the compulsory presence of <atom:id> and 
> <atom:updated> in every entry, some of the benefits of 
> canonicalization (reducing ambiguity in comparisons) are not material.
>
Hmm... not sure about this one.  We've already demonstrated via several 
examples that things like XML namespaces and the lack of a source 
element can cause problems in aggregator scenarios and that some form of 
atom-specific canonicalization may be required.  Can you expand a bit on 
your assertion with a few examples?  Some angle brackets would really 
help me understand exactly where you're coming from.

- James




From owner-atom-syntax@mail.imc.org Thu Jun 23 10:27:41 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DlSg9-0005LA-CL
	for atompub-archive@megatron.ietf.org; Thu, 23 Jun 2005 10:27:41 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16589
	for <atompub-archive@lists.ietf.org>; Thu, 23 Jun 2005 10:27:39 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5NEIAbb037568;
	Thu, 23 Jun 2005 07:18:10 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5NEIABY037567;
	Thu, 23 Jun 2005 07:18:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231])
	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5NEI83J037523
	for <atom-syntax@imc.org>; Thu, 23 Jun 2005 07:18:09 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: <p06230930bee073006577@[10.20.30.249]>
Date: Thu, 23 Jun 2005 07:18:05 -0700
To: Atom WG <atom-syntax@imc.org>
From: Paul Hoffman <phoffman@imc.org>
Subject: IESG defers discussion of the format document for two weeks
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>


Greetings again. So, it turns out that the IESG won't consider the 
Atom format document today, as we had hoped. As you can see at 
<https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11964&rfc_flag=0>, 
one of the Security Area Directors, Russ Housley, put a "defer" vote 
in. Procedurally, this means that he wants to wait for another 
telechat in order to think more about the document. "Defer" votes 
aren't common but aren't rare, and they can mean anything. And, a 
document can only be deferred once (that is, the IESG cannot use 
"defer" votes to keep ignoring a draft).

As you can also see from the ID tracker, we have a bunch of "no 
objection" votes and a couple of "discuss" votes. We need to clear 
all the "discuss" votes before we are accepted as a standard, but so 
far, these are all reasonable things that RobJoe can do in the -10 
draft. Other IESG members may have other "discuss" votes later on, 
and those can be more difficult, but we'll see when it happens.

In other words, this isn't bad news, just a delay. Tim and I have 
already opened a line of communications with Russ and Sam about 
security issues, so if they want to ask questions or probe further 
before voting, they can.

Stay tuned, and it won't be that long until we know for sure.

--Paul Hoffman, Director
--Internet Mail Consortium




From owner-atom-syntax@mail.imc.org Thu Jun 23 11:38:11 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DlTmN-0004VJ-Fu
	for atompub-archive@megatron.ietf.org; Thu, 23 Jun 2005 11:38:11 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25132
	for <atompub-archive@lists.ietf.org>; Thu, 23 Jun 2005 11:38:09 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5NFSj5G013597;
	Thu, 23 Jun 2005 08:28:45 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5NFSj5k013596;
	Thu, 23 Jun 2005 08:28:45 -0700 (PDT)
X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j5NFSi5V013559;
	Thu, 23 Jun 2005 08:28:44 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j5NFShqg008121;
	Thu, 23 Jun 2005 09:28:43 -0600 (MDT)
Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004))
 with ESMTP id <0IIJ0054IMZVW4@edgemail1.Central.Sun.COM>; Thu,
 23 Jun 2005 09:28:43 -0600 (MDT)
Received: from [192.168.1.100] ([216.113.202.7])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004))
 with ESMTPSA id <0IIJ00J27MZUF3@mail.sun.net>; Thu,
 23 Jun 2005 09:28:43 -0600 (MDT)
Date: Thu, 23 Jun 2005 08:28:42 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: IESG defers discussion of the format document for two weeks
In-reply-to: <p06230930bee073006577@[10.20.30.249]>
To: Paul Hoffman <phoffman@imc.org>
Cc: Atom WG <atom-syntax@imc.org>
Message-id: <121C199C-C1EA-4D7B-906B-EAF81E5852A1@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.730)
Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Content-transfer-encoding: 7BIT
References: <p06230930bee073006577@[10.20.30.249]>
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: 7BIT



On Jun 23, 2005, at 7:18 AM, Paul Hoffman wrote:

> In other words, this isn't bad news, just a delay.

Fully disagree.  The world has many implementors eagerly awaiting the  
arrival of Atom so they can start using it.  If there are problems  
that require repair, I don't want to wait two more weeks to find out  
about them.  This is very disappointing. -Tim




From owner-atom-syntax@mail.imc.org Thu Jun 23 11:51:45 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DlTzV-0007AQ-G8
	for atompub-archive@megatron.ietf.org; Thu, 23 Jun 2005 11:51:45 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26559
	for <atompub-archive@lists.ietf.org>; Thu, 23 Jun 2005 11:51:42 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5NFfWo7026899;
	Thu, 23 Jun 2005 08:41:32 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5NFfWS6026896;
	Thu, 23 Jun 2005 08:41:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5NFfV4f026883
	for <atom-syntax@imc.org>; Thu, 23 Jun 2005 08:41:31 -0700 (PDT)
	(envelope-from sah@428cobrajet.net)
Received: from dul1shollenbl1 ([::ffff:216.168.239.87])
  (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5)
  by mail.verisignlabs.com with esmtp; Thu, 23 Jun 2005 11:41:30 -0400
  id 0059C198.42BAD82A.00005C33
From: "Scott Hollenbeck" <sah@428cobrajet.net>
To: "'Tim Bray'" <Tim.Bray@Sun.COM>
Cc: "'Atom WG'" <atom-syntax@imc.org>
Subject: RE: IESG defers discussion of the format document for two weeks
Date: Thu, 23 Jun 2005 11:41:10 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <121C199C-C1EA-4D7B-906B-EAF81E5852A1@sun.com>
Thread-Index: AcV4CGuW1wNxVVqhQLqhOB2Ousw5jgAAR3lw
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Message-ID: <courier.42BAD82A.00005C33@mail.verisignlabs.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>
Content-Transfer-Encoding: 7bit


> -----Original Message-----
> From: Tim Bray [mailto:Tim.Bray@Sun.COM] 
> Sent: Thursday, June 23, 2005 11:29 AM
> To: Paul Hoffman
> Cc: Atom WG
> Subject: Re: IESG defers discussion of the format document 
> for two weeks
> 
> 
> 
> On Jun 23, 2005, at 7:18 AM, Paul Hoffman wrote:
> 
> > In other words, this isn't bad news, just a delay.
> 
> Fully disagree.  The world has many implementors eagerly 
> awaiting the  
> arrival of Atom so they can start using it.  If there are problems  
> that require repair, I don't want to wait two more weeks to find out  
> about them.  This is very disappointing. -Tim

ADs often defer when they haven't been able to review and digest the
document.  I put this one on the agenda almost two weeks ago to give
everyone plenty of time; I don't know why Russ has been unable to get
through it.  He did tell me that he hopes to have his comments (if any)
recorded before the week of the 7th.

-Scott-




From owner-atom-syntax@mail.imc.org Thu Jun 23 12:14:27 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DlULT-0004aR-0u
	for atompub-archive@megatron.ietf.org; Thu, 23 Jun 2005 12:14:27 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29352
	for <atompub-archive@lists.ietf.org>; Thu, 23 Jun 2005 12:14:24 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5NG4dEX050539;
	Thu, 23 Jun 2005 09:05:08 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5NFoE9D037049;
	Thu, 23 Jun 2005 08:50:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231])
	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5NFo5Ni036681
	for <atom-syntax@imc.org>; Thu, 23 Jun 2005 08:50:06 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: <p0623093fbee089f9c7c5@[10.20.30.249]>
In-Reply-To: <p06230930bee073006577@[10.20.30.249]>
References: <p06230930bee073006577@[10.20.30.249]>
Date: Thu, 23 Jun 2005 08:50:03 -0700
To: Atom WG <atom-syntax@imc.org>
From: Paul Hoffman <phoffman@imc.org>
Subject: Re: IESG defers discussion of the format document for two weeks
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>


In my previous post, I said "RobJoe" when I should have said "Rob and 
Mark". Also, I said "Russ and Sam" when I should have said "the two 
Security Area Directors, Russ Housley and Sam Hartman" (that is, not 
our WG secretary, Sam Ruby).

Also, I agree with Tim that waiting two weeks unnecessarily is a 
bummer for anxious implementers. I guess I'm just used to much worse 
things happening in the IESG in the past, like really long delays.

--Paul Hoffman, Director
--Internet Mail Consortium




From owner-atom-syntax@mail.imc.org Thu Jun 23 12:21:49 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DlUSa-000729-In
	for atompub-archive@megatron.ietf.org; Thu, 23 Jun 2005 12:21:49 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00024
	for <atompub-archive@lists.ietf.org>; Thu, 23 Jun 2005 12:21:45 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5NGD4me060918;
	Thu, 23 Jun 2005 09:13:04 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5NGD4kQ060917;
	Thu, 23 Jun 2005 09:13:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.25])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5NGD3YA060866
	for <atom-syntax@imc.org>; Thu, 23 Jun 2005 09:13:04 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 24 Jun 2005 02:13:31 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Fri, 24 Jun 2005 02:12:56 +1000
Subject: Re: IESG defers discussion of the format document for two weeks
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BEE11CA8.600D6%eric.scheid@ironclad.net.au>
In-Reply-To: <121C199C-C1EA-4D7B-906B-EAF81E5852A1@sun.com>
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>
Content-Transfer-Encoding: 7bit


On 24/6/05 1:28 AM, "Tim Bray" <Tim.Bray@Sun.COM> wrote:

>> In other words, this isn't bad news, just a delay.
> 
> Fully disagree.  The world has many implementors eagerly awaiting the
> arrival of Atom so they can start using it.  If there are problems
> that require repair, I don't want to wait two more weeks to find out
> about them.  This is very disappointing. -Tim
> 

we can start with these two...

<https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=
36536>

<https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=
36539>

e.




From owner-atom-syntax@mail.imc.org Thu Jun 23 12:27:47 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DlUYL-0007zV-TD
	for atompub-archive@megatron.ietf.org; Thu, 23 Jun 2005 12:27:47 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01110
	for <atompub-archive@lists.ietf.org>; Thu, 23 Jun 2005 12:27:43 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5NGMENQ071563;
	Thu, 23 Jun 2005 09:22:14 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5NGMEJG071562;
	Thu, 23 Jun 2005 09:22:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from bblfish.net (bblfish.net [192.220.66.168])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5NGMEN3071556
	for <atom-syntax@imc.org>; Thu, 23 Jun 2005 09:22:14 -0700 (PDT)
	(envelope-from henry.story@bblfish.net)
Received: (qmail 54812 invoked by uid 17064); 23 Jun 2005 16:22:14 -0000
Received: from unknown (HELO [192.168.0.5]) ([83.112.143.66])
          (envelope-sender <henry.story@bblfish.net>)
          by 192.220.66.168 (qmail-ldap-1.03) with SMTP
          for <atom-syntax@imc.org>; 23 Jun 2005 16:22:14 -0000
Mime-Version: 1.0 (Apple Message framework v730)
In-Reply-To: <55BDF86D-4063-411C-AA37-258CE92C4F54@bblfish.net>
References: <55BDF86D-4063-411C-AA37-258CE92C4F54@bblfish.net>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <499F004C-9196-42C7-BBAB-5C7C31BB71F0@bblfish.net>
Content-Transfer-Encoding: 7bit
From: Henry Story <henry.story@bblfish.net>
Subject: Re: CVS branch merge conflicts
Date: Thu, 23 Jun 2005 18:22:06 +0200
To: atom-syntax Syntax <atom-syntax@imc.org>
X-Mailer: Apple Mail (2.730)
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: 7bit


A couple of people pointed me to Eclipse for this, and it does indeed  
work well for this (thoug
the quality of the diffs is not so good as IntelliJs). If it were not  
so complicated to transform
a checked out CVS project into an eclipse project it would be perfect.

Henry

On 23 Jun 2005, at 12:36, Henry Story wrote:
> Hi, I am looking for a tool to make it pleasant to resolve merge  
> conflicts between a branch and the
> HEAD of a cvs repository. This aspect of IntelliJ is broken. Anyone  
> know a good tool that one could
> use for this?
>
> Henry Story




From owner-atom-syntax@mail.imc.org Thu Jun 23 12:31:53 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DlUcL-0000iy-8q
	for atompub-archive@megatron.ietf.org; Thu, 23 Jun 2005 12:31:53 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01660
	for <atompub-archive@lists.ietf.org>; Thu, 23 Jun 2005 12:31:50 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5NGPi5J075802;
	Thu, 23 Jun 2005 09:25:44 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5NGPhFO075801;
	Thu, 23 Jun 2005 09:25:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from bblfish.net (bblfish.net [192.220.66.168])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5NGPhn6075795
	for <atom-syntax@imc.org>; Thu, 23 Jun 2005 09:25:43 -0700 (PDT)
	(envelope-from henry.story@bblfish.net)
Received: (qmail 57107 invoked by uid 17064); 23 Jun 2005 16:25:43 -0000
Received: from unknown (HELO [192.168.0.5]) ([83.112.143.66])
          (envelope-sender <henry.story@bblfish.net>)
          by 192.220.66.168 (qmail-ldap-1.03) with SMTP
          for <atom-syntax@imc.org>; 23 Jun 2005 16:25:43 -0000
Mime-Version: 1.0 (Apple Message framework v730)
In-Reply-To: <499F004C-9196-42C7-BBAB-5C7C31BB71F0@bblfish.net>
References: <55BDF86D-4063-411C-AA37-258CE92C4F54@bblfish.net> <499F004C-9196-42C7-BBAB-5C7C31BB71F0@bblfish.net>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <6F096DC8-3760-4222-8B99-685C32991943@bblfish.net>
Content-Transfer-Encoding: 7bit
From: Henry Story <henry.story@bblfish.net>
Subject: Re: CVS branch merge conflicts
Date: Thu, 23 Jun 2005 18:25:39 +0200
To: atom-syntax Syntax <atom-syntax@imc.org>
X-Mailer: Apple Mail (2.730)
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: 7bit


Sorry, wrong list. :-/

Henry

On 23 Jun 2005, at 18:22, Henry Story wrote:
>
> A couple of people pointed me to Eclipse for this, and it does  
> indeed work well for this (thoug
> the quality of the diffs is not so good as IntelliJs). If it were  
> not so complicated to transform
> a checked out CVS project into an eclipse project it would be perfect.
>
> Henry
>
> On 23 Jun 2005, at 12:36, Henry Story wrote:
>
>> Hi, I am looking for a tool to make it pleasant to resolve merge  
>> conflicts between a branch and the
>> HEAD of a cvs repository. This aspect of IntelliJ is broken.  
>> Anyone know a good tool that one could
>> use for this?
>>
>> Henry Story
>




From owner-atom-syntax@mail.imc.org Thu Jun 23 12:59:55 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DlV3S-0006qv-U9
	for atompub-archive@megatron.ietf.org; Thu, 23 Jun 2005 12:59:55 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04504
	for <atompub-archive@lists.ietf.org>; Thu, 23 Jun 2005 12:59:52 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5NGt7iP007460;
	Thu, 23 Jun 2005 09:55:07 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5NGt72U007458;
	Thu, 23 Jun 2005 09:55:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mailhost.netweaver.net (mailhost.netweaver.net [213.160.118.140])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j5NGt6UH007450
	for <atom-syntax@imc.org>; Thu, 23 Jun 2005 09:55:06 -0700 (PDT)
	(envelope-from davep@dpawson.co.uk)
Received: (qmail 4296 invoked from network); 23 Jun 2005 16:55:05 -0000
Received: from dpawson.gotadsl.co.uk (HELO ?192.168.2.7?) (davep@dpawson.co.uk@81.6.251.105)
  by 0 with SMTP; 23 Jun 2005 16:55:05 -0000
Subject: Re: More on Atom XML signatures and encryption
From: Dave Pawson <davep@dpawson.co.uk>
Reply-To: davep@dpawson.co.uk
To: James M Snell <jasnell@gmail.com>
Cc: atom-syntax@imc.org
In-Reply-To: <42B8AD18.3030509@gmail.com>
References: <1118943858.9048.6.camel@marge> <42B1CB81.3060101@gmail.com>
	 <42B1CF84.5040508@dehora.net> <42B1EE41.9030304@gmail.com>
	 <p0621025dbed80c5c0f0c@[10.20.30.249]> <42B73208.7030304@gmail.com>
	 <1118943858.9048.6.camel@marge> <42B1CB81.3060101@gmail.com>
	 <42B1CF84.5040508@dehora.net> <42B1EE41.9030304@gmail.com>
	 <p0621025dbed80c5c0f0c@[10.20.30.249]> <42B73208.7030304@gmail.com>
	 <001201c5761d$ae1db9c0$6600a8c0@IBMC101DE8DFED>
	 <42B7A6B1.9050803@gmail.com> <1118943858.9048.6.camel@marge>
	 <42B1CB81.3060101@gmail.com> <42B1CF84.5040508@dehora.net>
	 <42B1EE41.9030304@gmail.com> <p0621025dbed80c5c0f0c@[10.20.30.249]>
	 <42B73208.7030304@gmail.com>
	 <c9bd5968a6f3a8e1742d98f727c297e8@rice.epostmail.org>
	 <42B794D4.4040101@gmail.com> <p0623091dbedde3598a37@[165.227.249.220]>
	 <42B8AD18.3030509@gmail.com>
Content-Type: text/plain
Date: Thu, 23 Jun 2005 17:55:04 +0100
Message-Id: <1119545704.5189.4.camel@marge>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
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>
Content-Transfer-Encoding: 7bit


On Tue, 2005-06-21 at 17:13 -0700, James M Snell wrote:

>    The root of an Atom document (i.e., atom:feed in an Atom Feed
>    Document, atom:entry in an Atom Entry Document) MAY have an Enveloped
>    Signature, as described by XML-Signature and Syntax Processing
>    [W3C.REC-xmldsig-core-20020212].

> Given this language, the the spec only explicitly allows digital signing 
> of the Atom Feed and Entry Documents.  It does not explicitly allow for 
> digitally signing individual entries within a Feed document. 

Makes sense to me James.
Which bit of 'only explicitly' don't you grok?


-- 
Regards, 

Dave Pawson
XSLT + Docbook FAQ
http://www.dpawson.co.uk




From owner-atom-syntax@mail.imc.org Thu Jun 23 15:12:10 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DlX7S-0005hy-12
	for atompub-archive@megatron.ietf.org; Thu, 23 Jun 2005 15:12:10 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17607
	for <atompub-archive@lists.ietf.org>; Thu, 23 Jun 2005 15:12:08 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5NILiI3099311;
	Thu, 23 Jun 2005 11:21:44 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5NILiLt099310;
	Thu, 23 Jun 2005 11:21:44 -0700 (PDT)
X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j5NILgIo099222
	for <atom-syntax@imc.org>; Thu, 23 Jun 2005 11:21:42 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j5NILew4028001
	for <atom-syntax@imc.org>; Thu, 23 Jun 2005 12:21:40 -0600 (MDT)
Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004))
 with ESMTP id <0IIJ008DIV048P@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Thu, 23 Jun 2005 12:21:40 -0600 (MDT)
Received: from [192.168.102.100] ([154.20.140.182])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004))
 with ESMTPSA id <0IIJ00HTDV03T2@mail.sun.net> for atom-syntax@imc.org; Thu,
 23 Jun 2005 12:21:40 -0600 (MDT)
Date: Thu, 23 Jun 2005 11:21:38 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: IESG defers discussion of the format document for two weeks
In-reply-to: <BEE11CA8.600D6%eric.scheid@ironclad.net.au>
To: Eric Scheid <eric.scheid@ironclad.net.au>
Cc: Atom Syntax <atom-syntax@imc.org>
Message-id: <DDFC74BE-E509-478F-8948-91DCCCFB0837@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.730)
Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Content-transfer-encoding: 7BIT
References: <BEE11CA8.600D6%eric.scheid@ironclad.net.au>
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: 7BIT



On Jun 23, 2005, at 9:12 AM, Eric Scheid wrote:

>> If there are problems
>> that require repair, I don't want to wait two more weeks to find out
>> about them.  This is very disappointing. -Tim
>>
>>
>
> we can start with these two...
>
> <https://datatracker.ietf.org/public/pidtracker.cgi? 
> command=view_comment&id=
> 36536>
>
> <https://datatracker.ietf.org/public/pidtracker.cgi? 
> command=view_comment&id=
> 36539>

Nope, these are non-controversial editorial improvements which need  
not slow us down, they can go into that last draft that we'd have to  
do anyhow to fix the errors that have been turned up and put in the  
contributors and so on.  Specifically, they want us to make it  
clearer that yes, we do have two similar-looking instances of type=  
with different rules, and to make it clear that to dereference a IRI  
you have to turn it into a URI.  The person who put the "defer" on  
didn't raise these issues.  -Tim





From owner-atom-syntax@mail.imc.org Fri Jun 24 05:13:08 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DlkFH-00079n-G2
	for atompub-archive@megatron.ietf.org; Fri, 24 Jun 2005 05:13:08 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19225
	for <atompub-archive@lists.ietf.org>; Fri, 24 Jun 2005 05:13:03 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5O91ue3053903;
	Fri, 24 Jun 2005 02:01:56 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5O91urv053902;
	Fri, 24 Jun 2005 02:01:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from scmailgw1.scop.aoyama.ac.jp (scmailgw1.scop.aoyama.ac.jp [133.2.251.194])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5O91rk7053837
	for <atom-syntax@imc.org>; Fri, 24 Jun 2005 02:01:54 -0700 (PDT)
	(envelope-from duerst@it.aoyama.ac.jp)
Received: from scmse1.scbb.aoyama.ac.jp ([133.2.253.16])
	by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id j5O91kC20299;
	Fri, 24 Jun 2005 18:01:46 +0900 (JST)
Received: from nodnsquery(133.2.206.133) by scmse1.scbb.aoyama.ac.jp via csmap 
	 id 1c485416_e48f_11d9_83b1_0030482533a1_29560;
	Fri, 24 Jun 2005 18:05:29 +0900 (JST)
Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO00571C;
  24 Jun 05 18:06:29 +0900
Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 24 Jun 05 18:06:09 +0900
Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.64) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG005718;
   24 Jun 05 18:06:05 +0900
Message-Id: <6.0.0.20.2.20050624175622.08e1a7d0@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Version 6J
Date: Fri, 24 Jun 2005 18:01:15 +0900
To: Tim Bray <Tim.Bray@Sun.COM>, Eric Scheid <eric.scheid@ironclad.net.au>,
        Ted Hardie <hardie@qualcomm.com>
From: Martin Duerst <duerst@it.aoyama.ac.jp>
Subject: Re: IESG defers discussion of the format document for two weeks
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <DDFC74BE-E509-478F-8948-91DCCCFB0837@sun.com>
References: <BEE11CA8.600D6%eric.scheid@ironclad.net.au>
 <DDFC74BE-E509-478F-8948-91DCCCFB0837@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
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>
Content-Transfer-Encoding: 7bit


At 03:21 05/06/24, Tim Bray wrote:
 >
 >
 >On Jun 23, 2005, at 9:12 AM, Eric Scheid wrote:
 >
 >>> If there are problems
 >>> that require repair, I don't want to wait two more weeks to find out
 >>> about them.  This is very disappointing. -Tim
 >>>
 >>>
 >>
 >> we can start with these two...
 >>
 >> <https://datatracker.ietf.org/public/pidtracker.cgi? 
command=view_comment&id=>> 36536>
 >>
 >> <https://datatracker.ietf.org/public/pidtracker.cgi? 
command=view_comment&id=>> 36539>
 >
 >Nope, these are non-controversial editorial improvements

Mostly, yes.

 >which need
 >not slow us down, they can go into that last draft that we'd have to
 >do anyhow to fix the errors that have been turned up and put in the
 >contributors and so on.  Specifically, they want us to make it
 >clearer that yes, we do have two similar-looking instances of type=
 >with different rules, and to make it clear that to dereference a IRI
 >you have to turn it into a URI.  The person who put the "defer" on
 >didn't raise these issues.  -Tim

Some care (and some headstart) is nonetheless helpful.
Ted at 
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=36539
says " This is true for any scheme which does not support IRIs natively."
This is slightly inaccurate; schemes are irrelevant here, it's protocols
that count (which is the word used in most of the rest of the text).


Regards,    Martin. 




From owner-atom-syntax@mail.imc.org Fri Jun 24 10:47:36 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DlpSy-0001DJ-HA
	for atompub-archive@megatron.ietf.org; Fri, 24 Jun 2005 10:47:36 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15320
	for <atompub-archive@lists.ietf.org>; Fri, 24 Jun 2005 10:47:33 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5OEcDsu026732;
	Fri, 24 Jun 2005 07:38:13 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5OEcDp2026728;
	Fri, 24 Jun 2005 07:38:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5OEcDkm026558
	for <atom-syntax@imc.org>; Fri, 24 Jun 2005 07:38:13 -0700 (PDT)
	(envelope-from hardie@qualcomm.com)
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150])
	by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5OEc5cQ028098;
	Fri, 24 Jun 2005 07:38:05 -0700 (PDT)
Received: from [192.168.1.4] (vpn-10-50-0-20.qualcomm.com [10.50.0.20])
	by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5OEc1Wb025285;
	Fri, 24 Jun 2005 07:38:03 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p06210200bee1caa65cd1@[192.168.1.4]>
In-Reply-To: <6.0.0.20.2.20050624175622.08e1a7d0@localhost>
References: <BEE11CA8.600D6%eric.scheid@ironclad.net.au>
 <DDFC74BE-E509-478F-8948-91DCCCFB0837@sun.com>
 <6.0.0.20.2.20050624175622.08e1a7d0@localhost>
Date: Fri, 24 Jun 2005 07:38:00 -0700
To: Martin Duerst <duerst@it.aoyama.ac.jp>, Tim Bray <Tim.Bray@Sun.COM>,
        Eric Scheid <eric.scheid@ironclad.net.au>
From: Ted Hardie <hardie@qualcomm.com>
Subject: Re: IESG defers discussion of the format document for two weeks
Cc: Atom Syntax <atom-syntax@imc.org>
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>


At 6:01 PM +0900 6/24/05, Martin Duerst wrote:
>
>Some care (and some headstart) is nonetheless helpful.
>Ted at https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=36539
>says " This is true for any scheme which does not support IRIs natively."
>This is slightly inaccurate; schemes are irrelevant here, it's protocols
>that count (which is the word used in most of the rest of the text).

Martin's right; I should have said "protocols" instead of "scheme" in
the text above.  I have adjusted the discuss text in the tracker to
fix that.
			Ted




From owner-atom-syntax@mail.imc.org Fri Jun 24 18:46:51 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dlwwl-0005WR-8N
	for atompub-archive@megatron.ietf.org; Fri, 24 Jun 2005 18:46:51 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03752
	for <atompub-archive@lists.ietf.org>; Fri, 24 Jun 2005 18:46:48 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5OMbDuc045660;
	Fri, 24 Jun 2005 15:37:13 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5OMbDbR045659;
	Fri, 24 Jun 2005 15:37:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.203])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5OMbCYd045568
	for <atom-syntax@imc.org>; Fri, 24 Jun 2005 15:37:12 -0700 (PDT)
	(envelope-from jasnell@gmail.com)
Received: by zproxy.gmail.com with SMTP id 16so608322nzp
        for <atom-syntax@imc.org>; Fri, 24 Jun 2005 15:37:06 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=q81Hz8ZAcNzvz4oFxJb51mMa++YQLyae+6MtN1y8Zs5Esn8ANgZcsgMp2bdA/0ljFr8D+rPz8XHBJxTHTBU6G6Np3VgmeVIg03V6arxfx1yGYQ4wULur8SzRocaGO1x98lukzf4+P8JnSCLirDA0IYHBTVkk1UDa9jCixJPQObs=
Received: by 10.36.101.2 with SMTP id y2mr2360537nzb;
        Fri, 24 Jun 2005 15:37:06 -0700 (PDT)
Received: from ?192.168.1.103? ([67.181.223.222])
        by mx.gmail.com with ESMTP id 15sm3533216nzo.2005.06.24.15.37.06;
        Fri, 24 Jun 2005 15:37:06 -0700 (PDT)
Message-ID: <42BC8B0A.8070305@gmail.com>
Date: Fri, 24 Jun 2005 15:36:58 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: atom-syntax@imc.org
Subject: Microsoft, RSS & Atom
References: <BEE11CA8.600D6%eric.scheid@ironclad.net.au> <DDFC74BE-E509-478F-8948-91DCCCFB0837@sun.com> <6.0.0.20.2.20050624175622.08e1a7d0@localhost> <p06210200bee1caa65cd1@[192.168.1.4]>
In-Reply-To: <p06210200bee1caa65cd1@[192.168.1.4]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


I hesitated posting this but someone has to start what is bound to be an 
inevitable conversation on this list.... so here goes

Whatever your opinion of it, Microsoft's announcement is significant and 
important.  I've posted some thoughts on what it could mean for Atom if 
Microsoft doesn't play fair on my IBM developerWorks blog here 
http://www-128.ibm.com/developerworks/blogs/dw_blog_comments.jspa?blog=351&entry=84636.  


Regarding the list extensions themselves, technically they're actually 
rather boring ;-) ... however, the fact that they were released under a 
creative commons license is very promising.  Further, I see nothing in 
the spec that would keep it from working with Atom.. again, a very 
promising thing. 

My key concern, however, is the potential for folks in the Atom 
community overreacting to all of this.  There is a lot of momentum 
behind RSS right now and coming out too strongly against RSS simply 
because we feel there are technical and process deficiencies associated 
with it is not going to do this community any favors.  Let's make sure 
that we're focusing on getting Atom out the door as quickly as we can; 
that we're demonstrating the value of Atom with real implementations 
rather than rhetoric; and that we work on educating developers on the 
advantages of Atom relative to RSS with specific use cases and code 
examples.

- James




From owner-atom-syntax@mail.imc.org Sat Jun 25 07:54:40 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dm9FA-0000dG-NJ
	for atompub-archive@megatron.ietf.org; Sat, 25 Jun 2005 07:54:40 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19878
	for <atompub-archive@lists.ietf.org>; Sat, 25 Jun 2005 07:54:39 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5PBkjM2053420;
	Sat, 25 Jun 2005 04:46:45 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5PBkjep053419;
	Sat, 25 Jun 2005 04:46:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.201])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5PBkiTb053163
	for <atom-syntax@imc.org>; Sat, 25 Jun 2005 04:46:45 -0700 (PDT)
	(envelope-from danny.ayers@gmail.com)
Received: by zproxy.gmail.com with SMTP id 40so36457nzk
        for <atom-syntax@imc.org>; Sat, 25 Jun 2005 04:46:37 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=JfXEPUROGsene1B4itUDU5n+GHfKdNCuyDlV7A8/K+cyS2ahY1FSqFSaccWayM4WxnB1IetvWcC24SJ1i1e1yVSHKessFInR6TrtcQ1gUiNrwkSKXUx9YwEJLKRiaqfrgT63wsLHo9/jOfUOtOQeK0aDLHcAlF2OVTBQ2MZxKNc=
Received: by 10.36.135.4 with SMTP id i4mr2638493nzd;
        Sat, 25 Jun 2005 04:46:37 -0700 (PDT)
Received: by 10.36.47.13 with HTTP; Sat, 25 Jun 2005 04:46:37 -0700 (PDT)
Message-ID: <1f2ed5cd050625044622d522c7@mail.gmail.com>
Date: Sat, 25 Jun 2005 13:46:37 +0200
From: Danny Ayers <danny.ayers@gmail.com>
Reply-To: Danny Ayers <danny.ayers@gmail.com>
To: James M Snell <jasnell@gmail.com>
Subject: Re: Microsoft, RSS & Atom
Cc: atom-syntax@imc.org
In-Reply-To: <42BC8B0A.8070305@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
References: <BEE11CA8.600D6%eric.scheid@ironclad.net.au>
	 <DDFC74BE-E509-478F-8948-91DCCCFB0837@sun.com>
	 <6.0.0.20.2.20050624175622.08e1a7d0@localhost>
	 <p06210200bee1caa65cd1@192.168.1.4> <42BC8B0A.8070305@gmail.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j5PBkjTb053413
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: 8bit


On 6/25/05, James M Snell <jasnell@gmail.com> wrote:

[snip]

> http://www-128.ibm.com/developerworks/blogs/dw_blog_comments.jspa?blog=351&entry=84636.

I generally agree. Strongly, when you talk of the best advocacy being
through demonstration.
 
The MS extension is a little unusual in that it impacts other elements
(giving them a datatype), it's an architectural forms kind of thing.
But I *think* it'll still play ok in Atom. Hopefully someone will have
time to look deeper. Has anyone done Yahoo!'s Media RSS as Atom yet,
btw?

Other comments & some links at:
http://dannyayers.com/archives/2005/06/24/ms-rss/

Cheers,
Danny.

-- 

http://dannyayers.com




From owner-atom-syntax@mail.imc.org Sat Jun 25 16:07:44 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DmGwK-0002b8-0Z
	for atompub-archive@megatron.ietf.org; Sat, 25 Jun 2005 16:07:44 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03097
	for <atompub-archive@lists.ietf.org>; Sat, 25 Jun 2005 16:07:41 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5PK0JDW036277;
	Sat, 25 Jun 2005 13:00:19 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5PK0Jnm036276;
	Sat, 25 Jun 2005 13:00:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail11.svc.cra.dublin.eircom.net (mail11.svc.cra.dublin.eircom.net [159.134.118.27])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j5PK0Hdw036200
	for <atom-syntax@imc.org>; Sat, 25 Jun 2005 13:00:18 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 94542 messnum 11066481 invoked from network[83.70.29.246/83-70-29-246.b-ras1.prp.dublin.eircom.net]); 25 Jun 2005 20:00:10 -0000
Received: from 83-70-29-246.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.29.246)
  by mail11.svc.cra.dublin.eircom.net (qp 94542) with SMTP; 25 Jun 2005 20:00:10 -0000
Message-ID: <42BDB7C9.7080700@dehora.net>
Date: Sat, 25 Jun 2005 21:00:09 +0100
From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: atom-syntax@imc.org
Subject: Re: Microsoft, RSS & Atom
References: <BEE11CA8.600D6%eric.scheid@ironclad.net.au> <DDFC74BE-E509-478F-8948-91DCCCFB0837@sun.com> <6.0.0.20.2.20050624175622.08e1a7d0@localhost> <p06210200bee1caa65cd1@[192.168.1.4]> <42BC8B0A.8070305@gmail.com>
In-Reply-To: <42BC8B0A.8070305@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


James M Snell wrote:

> Regarding the list extensions themselves, technically they're actually 
> rather boring ;-)

Having lists that can live outside the server or application they were 
created for is a big deal. If we were talking about the next step in 
bringing the web to its full potential, then machine readable lists are 
that step. There's oceans and oceans of data in list form.

cheers
Bill





From owner-atom-syntax@mail.imc.org Sat Jun 25 16:44:25 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DmHVo-0001dg-UH
	for atompub-archive@megatron.ietf.org; Sat, 25 Jun 2005 16:44:25 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05263
	for <atompub-archive@lists.ietf.org>; Sat, 25 Jun 2005 16:44:22 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5PKaxfX076709;
	Sat, 25 Jun 2005 13:36:59 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5PKaxwb076708;
	Sat, 25 Jun 2005 13:36:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.205])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5PKawZ4076690
	for <atom-syntax@imc.org>; Sat, 25 Jun 2005 13:36:59 -0700 (PDT)
	(envelope-from jasnell@gmail.com)
Received: by zproxy.gmail.com with SMTP id z31so48527nzd
        for <atom-syntax@imc.org>; Sat, 25 Jun 2005 13:36:53 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=UZeQKOtPPdReFgVbvuyyXaoktirMRVE8kQ4pFxvBUw8sDt25DSdhzVr0qdOHJOjqqJ9ymh9gtefMeIlSYFuAMa5M0HlpCKHgCITgAhfx9s4O3znz0OImD9suZwPMFUx8+0l8T2C7qhBi+XjrE59uzAqMrXb9opF1HDpgdC64GNM=
Received: by 10.36.10.18 with SMTP id 18mr1246248nzj;
        Sat, 25 Jun 2005 13:36:53 -0700 (PDT)
Received: from ?192.168.1.103? ([67.181.223.222])
        by mx.gmail.com with ESMTP id 36sm4148678nza.2005.06.25.13.36.52;
        Sat, 25 Jun 2005 13:36:53 -0700 (PDT)
Message-ID: <42BDC05A.40808@gmail.com>
Date: Sat, 25 Jun 2005 13:36:42 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net>
CC: atom-syntax@imc.org
Subject: Re: Microsoft, RSS & Atom
References: <BEE11CA8.600D6%eric.scheid@ironclad.net.au> <DDFC74BE-E509-478F-8948-91DCCCFB0837@sun.com> <6.0.0.20.2.20050624175622.08e1a7d0@localhost> <p06210200bee1caa65cd1@[192.168.1.4]> <42BC8B0A.8070305@gmail.com> <42BDB7C9.7080700@dehora.net>
In-Reply-To: <42BDB7C9.7080700@dehora.net>
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 ietf.org id QAA05263


Bill de h=D3ra wrote:

>
> James M Snell wrote:
>
>> Regarding the list extensions themselves, technically they're=20
>> actually rather boring ;-)
>
>
> Having lists that can live outside the server or application they were=20
> created for is a big deal. If we were talking about the next step in=20
> bringing the web to its full potential, then machine readable lists=20
> are that step. There's oceans and oceans of data in list form.
>
> cheers
> Bill
>
>
>
No doubt.  I didn't say the applications that could be built with the=20
extensions are boring... I said the extensions themselves were boring. =20
In other words, while I (and quite a few others it would appear) would=20
have done it differently, they're so minimal and simple that there's=20
really not a lot to debate about 'em.  The real question is going to be=20
whether or not MS will make changes to the approach based on community=20
feedback.=20

- James




From owner-atom-syntax@mail.imc.org Sat Jun 25 17:01:10 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DmHm1-0004aY-VK
	for atompub-archive@megatron.ietf.org; Sat, 25 Jun 2005 17:01:10 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06231
	for <atompub-archive@lists.ietf.org>; Sat, 25 Jun 2005 17:01:07 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5PKtbkR098568;
	Sat, 25 Jun 2005 13:55:37 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5PKtbc5098566;
	Sat, 25 Jun 2005 13:55:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail03.svc.cra.dublin.eircom.net (mail03.svc.cra.dublin.eircom.net [159.134.118.19])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j5PKtab7098286
	for <atom-syntax@imc.org>; Sat, 25 Jun 2005 13:55:36 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 34444 messnum 276304 invoked from network[83.70.29.246/83-70-29-246.b-ras1.prp.dublin.eircom.net]); 25 Jun 2005 20:55:30 -0000
Received: from 83-70-29-246.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.29.246)
  by mail03.svc.cra.dublin.eircom.net (qp 34444) with SMTP; 25 Jun 2005 20:55:30 -0000
Message-ID: <42BDC4C1.4010507@dehora.net>
Date: Sat, 25 Jun 2005 21:55:29 +0100
From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: atom-syntax@imc.org
Subject: Re: Microsoft, RSS & Atom
References: <BEE11CA8.600D6%eric.scheid@ironclad.net.au> <DDFC74BE-E509-478F-8948-91DCCCFB0837@sun.com> <6.0.0.20.2.20050624175622.08e1a7d0@localhost> <p06210200bee1caa65cd1@[192.168.1.4]> <42BC8B0A.8070305@gmail.com> <42BDB7C9.7080700@dehora.net> <42BDC05A.40808@gmail.com>
In-Reply-To: <42BDC05A.40808@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>
Content-Transfer-Encoding: 7bit


James M Snell wrote:

> No doubt.  I didn't say the applications that could be built with the
> extensions are boring... I said the extensions themselves were boring. 
> In other words, while I (and quite a few others it would appear) would
> have done it differently, they're so minimal and simple that there's
> really not a lot to debate about 'em.  

I bet someone said that about line feeds once, now look where we are :)

cheers
Bill




From owner-atom-syntax@mail.imc.org Mon Jun 27 07:46:15 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dms47-0006aP-Jj
	for atompub-archive@megatron.ietf.org; Mon, 27 Jun 2005 07:46:15 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10243
	for <atompub-archive@lists.ietf.org>; Mon, 27 Jun 2005 07:46:13 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5RBaaqS016664;
	Mon, 27 Jun 2005 04:36:36 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5RBaa4B016663;
	Mon, 27 Jun 2005 04:36:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5RBaZDD016607
	for <atom-syntax@imc.org>; Mon, 27 Jun 2005 04:36:36 -0700 (PDT)
	(envelope-from asbjorn@tigerstaden.no)
Received: from osl1sminn1.broadpark.no ([80.202.4.59])
 by osl1smout1.broadpark.no
 (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004))
 with ESMTP id <0IIQ00J8BQXRTZC0@osl1smout1.broadpark.no> for
 atom-syntax@imc.org; Mon, 27 Jun 2005 13:37:03 +0200 (CEST)
Received: from quark ([84.48.117.231]) by osl1sminn1.broadpark.no
 (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004))
 with ESMTP id <0IIQ00EE1R2S9V71@osl1sminn1.broadpark.no> for
 atom-syntax@imc.org; Mon, 27 Jun 2005 13:40:04 +0200 (CEST)
Date: Mon, 27 Jun 2005 13:42:26 +0200
From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>
Subject: Re: The atom:uri element
In-reply-to: <BEBC24B2.5C5B3%eric.scheid@ironclad.net.au>
To: Atom-Syntax <atom-syntax@imc.org>
Message-id: <op.ss01g0gc16f2qb@quark>
MIME-version: 1.0
Content-type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1
References: <BEBC24B2.5C5B3%eric.scheid@ironclad.net.au>
User-Agent: Opera M2/8.01 (Win32, build 7642)
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 ietf.org id HAA10243


On Thu, 26 May 2005 17:13:22 +0200, Eric Scheid =20
<eric.scheid@ironclad.net.au> wrote:

>> See http://www.imc.org/atom-syntax/mail-archive/msg13864.html
>
> There are two arguments in parallel here:
>     (1) which is the proper term for a url/uri/iri ?
>     (2) is naming an element after the data type sensible ?
>
> I say the first argument is a red herring, a bike shed, and entirely
> redundant as we've already extensively used "IRI" in the spec.
>
> Consider also:
>     http://www.imc.org/atom-syntax/mail-archive/msg13860.html
>
> We have /author/name and not /author/string for a reason. Why then do w=
e
> have /author/uri?

I guess we won't be nuking the atom:uri element before Atom goes gold? =20
I've created a Pace just to have a final stab at it, if it's possible to =
=20
do anything about it:

<http://intertwingly.net/wiki/pie/PaceRenameUriElement>

=3D=3D Abstract =3D=3D

The "atom:uri" element should be renamed or changed.

=3D=3D Author =3D=3D

AsbjornUlsberg

=3D=3D Status =3D=3D

Open.

=3D=3D Rationale =3D=3D

The "atom:uri" element says nothing about its semantics or meaning, just =
=20
about the datatype of its content. As =20
[http://www.imc.org/atom-syntax/mail-archive/msg13860.html Danny Ayers =20
writes]: "Using atom:uri/atom:iri is only marginally better than saying =20
atom:string - it describes how the identifier is put together, it tells =20
you nothing about what's being identified.". It is also in conflict with =
=20
the term "IRI" which is the one used in the rest of the specification.

=3D=3D Proposal =3D=3D

Rename the "atom:uri" element or change its type to a Link Construct.

=3D=3D Impacts =3D=3D

Atom parsers which expects "atom:uri" in the documents, although they are=
 =20
based on a non-standard nor final version of the Atom document format.

=3D=3D Notes =3D=3D

As this change is mostly editorial and not technical, I think the authors=
 =20
are free to find the best suited name for the element.

--=20
Asbj=F8rn Ulsberg     -=3D|=3D-    http://virtuelvis.com/quark/
=ABHe's a loathsome offensive brute, yet I can't look away=BB




From owner-atom-syntax@mail.imc.org Mon Jun 27 08:34:55 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DmspC-00071f-Ux
	for atompub-archive@megatron.ietf.org; Mon, 27 Jun 2005 08:34:55 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15049
	for <atompub-archive@lists.ietf.org>; Mon, 27 Jun 2005 08:34:52 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5RCMbHD039240;
	Mon, 27 Jun 2005 05:22:37 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5RCMbEw039239;
	Mon, 27 Jun 2005 05:22:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mailhost.netweaver.net (mailhost.netweaver.net [213.160.118.140])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j5RCMZZI039219
	for <atom-syntax@imc.org>; Mon, 27 Jun 2005 05:22:36 -0700 (PDT)
	(envelope-from davep@dpawson.co.uk)
Received: (qmail 14894 invoked from network); 27 Jun 2005 12:22:34 -0000
Received: from dpawson.gotadsl.co.uk (HELO ?192.168.2.7?) (davep@dpawson.co.uk@81.6.251.105)
  by 0 with SMTP; 27 Jun 2005 12:22:34 -0000
Subject: Re: The atom:uri element
From: Dave Pawson <davep@dpawson.co.uk>
Reply-To: davep@dpawson.co.uk
To: =?ISO-8859-1?Q?Asbj=F8rn?= Ulsberg <asbjorn@tigerstaden.no>
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <op.ss01g0gc16f2qb@quark>
References: <BEBC24B2.5C5B3%eric.scheid@ironclad.net.au>
	 <op.ss01g0gc16f2qb@quark>
Content-Type: text/plain; charset=utf-8
Date: Mon, 27 Jun 2005 13:22:34 +0100
Message-Id: <1119874954.3339.29.camel@marge>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.2 (2.2.2-5) 
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 ietf.org id IAA15049


On Mon, 2005-06-27 at 13:42 +0200, Asbj=C3=B8rn Ulsberg wrote:

>=20
> The "atom:uri" element should be renamed or changed.


> =3D=3D Rationale =3D=3D
>=20
> The "atom:uri" element says nothing about its semantics or meaning, jus=
t =20
> about the datatype of its content.

>=20
> =3D=3D Proposal =3D=3D
>=20
> Rename the "atom:uri" element or change its type to a Link Construct.

I support the rationale for changing. I'd appreciate even more
some semantics for the element?
  Were you going to add those to the proposal?


--=20
Regards,=20

Dave Pawson
XSLT + Docbook FAQ
http://www.dpawson.co.uk




From owner-atom-syntax@mail.imc.org Mon Jun 27 09:10:24 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DmtNY-0006z6-E3
	for atompub-archive@megatron.ietf.org; Mon, 27 Jun 2005 09:10:24 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18553
	for <atompub-archive@lists.ietf.org>; Mon, 27 Jun 2005 09:10:21 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5RCw40a057399;
	Mon, 27 Jun 2005 05:58:04 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5RCw4TN057398;
	Mon, 27 Jun 2005 05:58:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5RCw2wJ057305
	for <atom-syntax@imc.org>; Mon, 27 Jun 2005 05:58:03 -0700 (PDT)
	(envelope-from asbjorn@tigerstaden.no)
Received: from osl1sminn1.broadpark.no ([80.202.4.59])
 by osl1smout1.broadpark.no
 (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004))
 with ESMTP id <0IIQ00K9ZUPHPB20@osl1smout1.broadpark.no> for
 atom-syntax@imc.org; Mon, 27 Jun 2005 14:58:30 +0200 (CEST)
Received: from quark ([84.48.117.231]) by osl1sminn1.broadpark.no
 (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004))
 with ESMTP id <0IIQ00FNFUUI1K70@osl1sminn1.broadpark.no> for
 atom-syntax@imc.org; Mon, 27 Jun 2005 15:01:31 +0200 (CEST)
Date: Mon, 27 Jun 2005 15:03:54 +0200
From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>
Subject: Re: The atom:uri element
In-reply-to: <1119874954.3339.29.camel@marge>
To: davep@dpawson.co.uk
Cc: Atom-Syntax <atom-syntax@imc.org>
Message-id: <op.ss048sem16f2qb@quark>
MIME-version: 1.0
Content-type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1
References: <BEBC24B2.5C5B3%eric.scheid@ironclad.net.au>
 <op.ss01g0gc16f2qb@quark> <1119874954.3339.29.camel@marge>
User-Agent: Opera M2/8.01 (Win32, build 7642)
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 ietf.org id JAA18553


On Mon, 27 Jun 2005 14:22:34 +0200, Dave Pawson <davep@dpawson.co.uk> =20
wrote:

> I support the rationale for changing. I'd appreciate even more
> some semantics for the element?

I agree and have added text to the pace that describes this. I will try t=
o =20
add wording for the specification when I find time for it. Not describing=
 =20
what we mean with this element might hurt interop and that should be =20
avioded.

--=20
Asbj=F8rn Ulsberg     -=3D|=3D-    http://virtuelvis.com/quark/
=ABHe's a loathsome offensive brute, yet I can't look away=BB




From owner-atom-syntax@mail.imc.org Mon Jun 27 10:40:11 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DmumR-0000Lt-30
	for atompub-archive@megatron.ietf.org; Mon, 27 Jun 2005 10:40:11 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28607
	for <atompub-archive@lists.ietf.org>; Mon, 27 Jun 2005 10:40:08 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5REQYhN088400;
	Mon, 27 Jun 2005 07:26:34 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5REQYkk088399;
	Mon, 27 Jun 2005 07:26:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231])
	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5REQTDw088367;
	Mon, 27 Jun 2005 07:26:30 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: <p06230936bee5bcffa274@[10.20.30.249]>
In-Reply-To: <op.ss01g0gc16f2qb@quark>
References: <BEBC24B2.5C5B3%eric.scheid@ironclad.net.au>
 <op.ss01g0gc16f2qb@quark>
Date: Mon, 27 Jun 2005 07:26:27 -0700
To: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?=  <asbjorn@tigerstaden.no>,
        Atom-Syntax <atom-syntax@imc.org>
From: Paul Hoffman <phoffman@imc.org>
Subject: Re: The atom:uri element
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 ietf.org id KAA28607


At 1:42 PM +0200 6/27/05, Asbj=F8rn Ulsberg wrote:
>I guess we won't be nuking the atom:uri element before Atom goes gold?

Correct.

--Paul Hoffman, Director
--Internet Mail Consortium




From owner-atom-syntax@mail.imc.org Mon Jun 27 12:50:25 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DmwoT-00062M-J4
	for atompub-archive@megatron.ietf.org; Mon, 27 Jun 2005 12:50:25 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12029
	for <atompub-archive@lists.ietf.org>; Mon, 27 Jun 2005 12:50:21 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5RGZU2w015904;
	Mon, 27 Jun 2005 09:35:30 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5RGZUuP015903;
	Mon, 27 Jun 2005 09:35:30 -0700 (PDT)
X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with SMTP id j5RGZSlp015861
	for <atom-syntax@imc.org>; Mon, 27 Jun 2005 09:35:29 -0700 (PDT)
	(envelope-from pagaltzis@gmx.de)
Received: (qmail invoked by alias); 27 Jun 2005 16:35:22 -0000
Received: from xdsl-213-196-243-149.netcologne.de (EHLO klangraum) [213.196.243.149]
  by mail.gmx.net (mp008) with SMTP; 27 Jun 2005 18:35:22 +0200
X-Authenticated: #163624
Date: Mon, 27 Jun 2005 18:39:39 +0200
From: "A. Pagaltzis" <pagaltzis@gmx.de>
To: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: The atom:uri element
Message-ID: <20050627163939.GA31625@klangraum>
Mail-Followup-To: Atom-Syntax <atom-syntax@imc.org>
References: <BEBC24B2.5C5B3%eric.scheid@ironclad.net.au> <op.ss01g0gc16f2qb@quark>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <op.ss01g0gc16f2qb@quark>
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 ietf.org id MAA12029


* Asbj=C3=B8rn Ulsberg <asbjorn@tigerstaden.no> [2005-06-27 13:50]:
> Rename the "atom:uri" element or change its type to a Link
> Construct.

The problem with that proposal, even if it wasn=E2=80=99t too late to
make any changes, is that, well, it replaces atom:uri with a Link
Construct.

A Link Construct has more semantics than the atom:uri element is
supposed to. Firstly, the @rel attribute is unwarranted in this
context, since there is only kind of relation the URI in atom:uri
can have with the entity described by the Name Construct it=E2=80=99s in.
Secondly, the @rel is necessary for Link Constructs because they
are meant to appear in mulitplicity, while atom:uri is not.

You could avoid these problems by removing the restriction to a
maximum of one URI, of course. Then the Link Construct becomes an
obvious choice. But that would require complicating the Name
Construct spec and require significant additionaly complexity in
Atom consumers =E2=80=93 for what benefit? I don=E2=80=99t see any tangib=
le gain
in that.

The basic idea to rename the element to something more
descriptive is, of course, not bad. It might have been warranted
to lobby for renaming atom:uri to something other than atom:link,
or maybe for replacing it with a @link attribute on the Name
Construct=E2=80=99s root element.

But, as mentioned, the spec, modulo bugs, is a done deal at this
point.

And if the atom:uri element=E2=80=99s naming really turns out to be the
biggest wart in the spec, then I=E2=80=99ll gladly suffer it. :-)

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




From owner-atom-syntax@mail.imc.org Mon Jun 27 13:29:07 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DmxPv-0007tx-Dy
	for atompub-archive@megatron.ietf.org; Mon, 27 Jun 2005 13:29:07 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16252
	for <atompub-archive@lists.ietf.org>; Mon, 27 Jun 2005 13:29:03 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5RHLDHD027315;
	Mon, 27 Jun 2005 10:21:13 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5RHLDqb027314;
	Mon, 27 Jun 2005 10:21:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mailhost.netweaver.net (mailhost.netweaver.net [213.160.118.140])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j5RHLBFY027299
	for <atom-syntax@imc.org>; Mon, 27 Jun 2005 10:21:12 -0700 (PDT)
	(envelope-from davep@dpawson.co.uk)
Received: (qmail 4614 invoked from network); 27 Jun 2005 17:21:10 -0000
Received: from dpawson.gotadsl.co.uk (HELO ?192.168.2.7?) (davep@dpawson.co.uk@81.6.251.105)
  by 0 with SMTP; 27 Jun 2005 17:21:10 -0000
Subject: Re: The atom:uri element
From: Dave Pawson <davep@dpawson.co.uk>
Reply-To: davep@dpawson.co.uk
To: "A. Pagaltzis" <pagaltzis@gmx.de>
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <20050627163939.GA31625@klangraum>
References: <BEBC24B2.5C5B3%eric.scheid@ironclad.net.au>
	 <op.ss01g0gc16f2qb@quark>  <20050627163939.GA31625@klangraum>
Content-Type: text/plain; charset=utf-8
Date: Mon, 27 Jun 2005 18:21:09 +0100
Message-Id: <1119892869.3339.46.camel@marge>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.2 (2.2.2-5) 
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 ietf.org id NAA16252


On Mon, 2005-06-27 at 18:39 +0200, A. Pagaltzis wrote:
> * Asbj=C3=B8rn Ulsberg <asbjorn@tigerstaden.no> [2005-06-27 13:50]:
> > Rename the "atom:uri" element or change its type to a Link
> > Construct.
>=20
> The problem with that proposal, even if it wasn=E2=80=99t too late to
> make any changes, is that, well, it replaces atom:uri with a Link
> Construct.
>=20
> A Link Construct has more semantics than the atom:uri element is
> supposed to.

Whereas the current construct has no semantics to speak of?


>=20
> The basic idea to rename the element to something more
> descriptive is, of course, not bad.=20

With little, or no, semantics?

> But, as mentioned, the spec, modulo bugs, is a done deal at this
> point.

Which, as was pointed out, is not good for interop

Please can we have an informative version of the spec,
with the semantics explained.

Current version, for thicko's|users, like me, is ....=20
not good.


--=20
Regards,=20

Dave Pawson
XSLT + Docbook FAQ
http://www.dpawson.co.uk




From owner-atom-syntax@mail.imc.org Mon Jun 27 15:55:05 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DmzhA-00008x-PA
	for atompub-archive@megatron.ietf.org; Mon, 27 Jun 2005 15:55:05 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01437
	for <atompub-archive@lists.ietf.org>; Mon, 27 Jun 2005 15:55:01 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5RJk89q089449;
	Mon, 27 Jun 2005 12:46:08 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5RJk8PR089448;
	Mon, 27 Jun 2005 12:46:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web42210.mail.yahoo.com (web42210.mail.yahoo.com [66.218.93.221])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j5RJk7Rd089436
	for <atom-syntax@imc.org>; Mon, 27 Jun 2005 12:46:07 -0700 (PDT)
	(envelope-from jfcst24_public@yahoo.com)
Received: (qmail 63396 invoked by uid 60001); 27 Jun 2005 19:46:02 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=A4o1lul++0Aar3N0Mc/hMKaXTxQ4NvRLLGwq7UNeKLaNAghMweNcThExd7wi0R2XocwiqfR76JbcGUCe431p+5xWKfy/cpx0Y21CGtZWHmX66y5w6mQQmOAlGkcJ7r82X6pj9dSQckhagQCTTGaLE81gQAwa1PQrWOyx+4IVyMw=  ;
Message-ID: <20050627194602.63394.qmail@web42210.mail.yahoo.com>
Received: from [130.49.145.103] by web42210.mail.yahoo.com via HTTP; Mon, 27 Jun 2005 12:46:02 PDT
Date: Mon, 27 Jun 2005 12:46:02 -0700 (PDT)
From: James Cerra <jfcst24_public@yahoo.com>
Subject: Re: The atom:uri element
To: davep@dpawson.co.uk, "A. Pagaltzis" <pagaltzis@gmx.de>
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <1119892869.3339.46.camel@marge>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
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 ietf.org id PAA01437


> > > Rename the "atom:uri" element or change its type to a Link
> > > Construct.
> >=20
> > The problem with that proposal, even if it wasn=E2=80=99t too late to
> > make any changes, is that, well, it replaces atom:uri with a Link
> > Construct.
> >=20
> > A Link Construct has more semantics than the atom:uri element is
> > supposed to.
>=20
> Whereas the current construct has no semantics to speak of?
>=20
> > But, as mentioned, the spec, modulo bugs, is a done deal at this
> > point.
>=20
> Which, as was pointed out, is not good for interop
>=20
> Please can we have an informative version of the spec,
> with the semantics explained.
>=20
> Current version, for thicko's|users, like me, is ....=20
> not good.

How hard is one little change?  There are two possibilities that I see as=
 easy
to do:

1) Use atom:id instead of atom:uri, and change atom:id intro paragraph so=
 it
'conveys a permanent, universally unique identifier for an entry, feed, p=
erson,
or other resource.'

2) Renaming atom:uri to atom:reference and add to the beginning of the
description that it 'conveys an identifier used to reference the person. =
 It
MAY permanently and uniquely identify the person.'

Just a quick proposal in case anyone thinks there isn't enough time to ge=
t
something.  If there isn't enough time to change it (although I think the=
re is
enough time left), that's OK - it will just be a quirk of the spec IMHO.

--
Jimmy Cerra
https://nemo.dev.java.net


	=09
____________________________________________________=20
Yahoo! Sports=20
Rekindle the Rivalries. Sign up for Fantasy Football=20
http://football.fantasysports.yahoo.com




From owner-atom-syntax@mail.imc.org Mon Jun 27 17:21:55 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dn13D-00058k-7I
	for atompub-archive@megatron.ietf.org; Mon, 27 Jun 2005 17:21:55 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20765
	for <atompub-archive@lists.ietf.org>; Mon, 27 Jun 2005 17:21:51 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5RLFSAJ025874;
	Mon, 27 Jun 2005 14:15:28 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5RLFSIJ025873;
	Mon, 27 Jun 2005 14:15:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65])
	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5RLFFJR025763;
	Mon, 27 Jun 2005 14:15:16 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: <p06230959bee61c6ff798@[10.20.30.249]>
In-Reply-To: <20050627194602.63394.qmail@web42210.mail.yahoo.com>
References: <20050627194602.63394.qmail@web42210.mail.yahoo.com>
Date: Mon, 27 Jun 2005 14:15:14 -0700
To: James Cerra <jfcst24_public@yahoo.com>, davep@dpawson.co.uk,
        "A. Pagaltzis" <pagaltzis@gmx.de>
From: Paul Hoffman <phoffman@imc.org>
Subject: Re: The atom:uri element
Cc: Atom-Syntax <atom-syntax@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>


At 12:46 PM -0700 6/27/05, James Cerra wrote:
>If there isn't enough time to change it

Again: there isn't. The spec is in front of the IESG for 
consideration, and it has been for many weeks now.

>  (although I think there is
>enough time left)

Could you explain that? Are you proposing that we pull the spec back 
from the IESG, make this change, and then ask them to look again? Or 
something else I'm missing?

--Paul Hoffman, Director
--Internet Mail Consortium




From owner-atom-syntax@mail.imc.org Mon Jun 27 21:34:32 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dn4zf-0004Q0-Tm
	for atompub-archive@megatron.ietf.org; Mon, 27 Jun 2005 21:34:32 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21196
	for <atompub-archive@lists.ietf.org>; Mon, 27 Jun 2005 21:34:29 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5S1LQE7087264;
	Mon, 27 Jun 2005 18:21:26 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5S1LQS3087263;
	Mon, 27 Jun 2005 18:21:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web42207.mail.yahoo.com (web42207.mail.yahoo.com [66.218.93.208])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j5S1LPoZ087236
	for <atom-syntax@imc.org>; Mon, 27 Jun 2005 18:21:25 -0700 (PDT)
	(envelope-from jfcst24_public@yahoo.com)
Received: (qmail 50081 invoked by uid 60001); 28 Jun 2005 01:21:19 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=Pw+WAMUoNT0xaunZ3OadKGk7PldbR8WeDHFHgltNkibkrvUr67W1fyTeoL9n2ET5zfRcHzCS+VIDz5ue4ogNI51rAvvF+ukSmbzzomulvF5GCh0THYBFmY3ggRp4s1Qpkpka9GkXLykjgbaMiId2x7+p5Z00sE2PDHzMoxOG9pY=  ;
Message-ID: <20050628012119.50079.qmail@web42207.mail.yahoo.com>
Received: from [136.142.21.200] by web42207.mail.yahoo.com via HTTP; Mon, 27 Jun 2005 18:21:19 PDT
Date: Mon, 27 Jun 2005 18:21:19 -0700 (PDT)
From: James Cerra <jfcst24_public@yahoo.com>
Subject: Re: The atom:uri element
To: Paul Hoffman <phoffman@imc.org>, davep@dpawson.co.uk,
        "A. Pagaltzis" <pagaltzis@gmx.de>
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <p06230959bee61c6ff798@[10.20.30.249]>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
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: 8bit


Paul Hoffman, Director,

> >If there isn't enough time to change it
> 
> Again: there isn't. The spec is in front of the IESG for 
> consideration, and it has been for many weeks now.

I knew that, but I was unaware of how un-updatable a step that was.  I
apologize for my ignorance.

> >  (although I think there is
> >enough time left)
> 
> Could you explain that? Are you proposing that we pull the spec back 
> from the IESG, make this change, and then ask them to look again? Or 
> something else I'm missing?

No.  I thought that there was room for updates to the draft during IESG
consideration.  That stemmed from unwarranted assumptions on my part, though. 
I feel the proposed changes are too small to worry about recalling it.  On the
other hand, if the spec is sent back by the IESG for other reasons then I
suggest revisiting this issue.

--
Jimmy Cerra
https://nemo.dev.java.net


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search. 
http://info.mail.yahoo.com/mail_250




From owner-atom-syntax@mail.imc.org Tue Jun 28 13:25:47 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DnJqF-0007Cp-7j
	for atompub-archive@megatron.ietf.org; Tue, 28 Jun 2005 13:25:47 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02713
	for <atompub-archive@lists.ietf.org>; Tue, 28 Jun 2005 13:25:43 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5SHIH0J093183;
	Tue, 28 Jun 2005 10:18:17 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5SHIH6c093182;
	Tue, 28 Jun 2005 10:18:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mailhost.netweaver.net (mailhost.netweaver.net [213.160.118.140])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j5SHIFd6093109
	for <atom-syntax@imc.org>; Tue, 28 Jun 2005 10:18:15 -0700 (PDT)
	(envelope-from davep@dpawson.co.uk)
Received: (qmail 22681 invoked from network); 28 Jun 2005 17:18:14 -0000
Received: from dpawson.gotadsl.co.uk (HELO ?192.168.2.7?) (davep@dpawson.co.uk@81.6.251.105)
  by 0 with SMTP; 28 Jun 2005 17:18:14 -0000
Subject: Re: The atom:uri element
From: Dave Pawson <davep@dpawson.co.uk>
Reply-To: davep@dpawson.co.uk
To: James Cerra <jfcst24_public@yahoo.com>
Cc: "A. Pagaltzis" <pagaltzis@gmx.de>, Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <20050627194602.63394.qmail@web42210.mail.yahoo.com>
References: <20050627194602.63394.qmail@web42210.mail.yahoo.com>
Content-Type: text/plain
Date: Tue, 28 Jun 2005 18:18:12 +0100
Message-Id: <1119979092.3345.14.camel@marge>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.2 (2.2.2-5) 
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>
Content-Transfer-Encoding: 7bit


On Mon, 2005-06-27 at 12:46 -0700, James Cerra wrote:
> > Please can we have an informative version of the spec,
> > with the semantics explained.
> > 
> > Current version, for thicko's|users, like me, is .... 
> > not good.
> 
> How hard is one little change?  

I'm not looking for a change. That has been submitted.

I'm looking for an informative, not normative,
version of the spec, which takes time to explain things
instead of being exact, but backed by the 
experience of this list?

Yes, I know the spec is for implementors,
but there are authors out here too,
who need that information.

That I believe is the interop issue.




-- 
Regards, 

Dave Pawson
XSLT + Docbook FAQ
http://www.dpawson.co.uk




From owner-atom-syntax@mail.imc.org Tue Jun 28 16:46:55 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DnMyt-0004Y4-5m
	for atompub-archive@megatron.ietf.org; Tue, 28 Jun 2005 16:46:55 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19837
	for <atompub-archive@lists.ietf.org>; Tue, 28 Jun 2005 16:46:52 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5SKesCN098690;
	Tue, 28 Jun 2005 13:40:54 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5SKesHd098689;
	Tue, 28 Jun 2005 13:40:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from relay01.pair.com (relay01.pair.com [209.68.5.15])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j5SKerfn098663
	for <atom-syntax@imc.org>; Tue, 28 Jun 2005 13:40:53 -0700 (PDT)
	(envelope-from rooneg@electricjellyfish.net)
Received: (qmail 31519 invoked from network); 28 Jun 2005 20:40:52 -0000
Received: from unknown (HELO ?10.0.100.15?) (unknown)
  by unknown with SMTP; 28 Jun 2005 20:40:52 -0000
X-pair-Authenticated: 206.80.1.253
Message-ID: <42C1B585.6000606@electricjellyfish.net>
Date: Tue, 28 Jun 2005 13:39:33 -0700
From: Garrett Rooney <rooneg@electricjellyfish.net>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mark Nottingham <mnot@mnot.net>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: FWD: I-D ACTION:draft-nottingham-atompub-feed-history-00.txt
References: <097CC973-BC19-4838-9076-019A9FD614EC@mnot.net>
In-Reply-To: <097CC973-BC19-4838-9076-019A9FD614EC@mnot.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


Mark Nottingham wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
> 
> 
>         Title           : Feed History: Enabling Stateful Syndication
>         Author(s)       : M. Nottingham
>         Filename        : draft-nottingham-atompub-feed-history-00.txt
>         Pages           : 6
>         Date            : 2005-6-27
> 
>    This document specifies mechanisms that allow feed publishers to  give
>    hints about the nature of the feed's statefulness, and a means of
>    retrieving ^missed^ entries from a stateful feed.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-nottingham-atompub-feed- 
> history-00.txt

I imagine someone else has already noticed this, but there's a typo in 
the example.  The open tag uses the prefix 'fh', but the close tag uses 
'fs'.

Also, why is Stateful capitalized?  All the other parts of atom use 
lower case tag names, IIRC.

-garrett




From owner-atom-syntax@mail.imc.org Tue Jun 28 18:01:45 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DnO9J-0004Pu-LM
	for atompub-archive@megatron.ietf.org; Tue, 28 Jun 2005 18:01:45 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01743
	for <atompub-archive@lists.ietf.org>; Tue, 28 Jun 2005 18:01:42 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5SLsQJA076619;
	Tue, 28 Jun 2005 14:54:27 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5SLsQLh076617;
	Tue, 28 Jun 2005 14:54:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5SLsQTt076525
	for <atom-syntax@imc.org>; Tue, 28 Jun 2005 14:54:26 -0700 (PDT)
	(envelope-from antone@geckotribe.com)
Received: from geckotribe.com (c-67-169-250-63.hsd1.ut.comcast.net[67.169.250.63])
          by comcast.net (rwcrmhc13) with SMTP
          id <2005062821542001500bnhaqe>; Tue, 28 Jun 2005 21:54:20 +0000
Date: Tue, 28 Jun 2005 15:54:18 -0600
Subject: Re: I-D ACTION:draft-nottingham-atompub-feed-history-00.txt
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v553)
From: Antone Roundy <antone@geckotribe.com>
To: atom-syntax@imc.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <097CC973-BC19-4838-9076-019A9FD614EC@mnot.net>
Message-Id: <2D508554-E81F-11D9-BC21-003065EA6144@geckotribe.com>
X-Mailer: Apple Mail (2.553)
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: 7bit


Let's say we are planning to keep the latest 15 entries in our stateful 
feed.  We publish the first entry, and have a feed with 1 entry in it.  
It has a "this" link, but no "prev" link.

Then we add an entry.  The old "this" link can't be used to point to 
the new instance of the feed, right?  Because that would violate this 
requirement:

    "The value of the "this" link relation's href attribute MUST be a URI
    indicating a permanent location that is unique to that Feed Document
    instance; i.e., the content obtained by dereferencing that URI SHOULD
    NOT change over time."

So the new feed instance has a new "this" link and perhaps a "prev" 
link pointing to the first instance.  But maybe the "prev" link could 
be omitted at this point, because the "this" link will point to a feed 
with all the information in the original feed and then some.

Now let's say someone tries to fetch the original "this" feed.  The 
draft says:

    "Note that publishers are not required to make all previous Feed
    Documents available."

This seems like a likely circumstance where the publisher might not 
want to both to continue making the original instance available.  If 
that's what they decide, then what?  Do they return a 410 (gone)?  
Presumably, some will return a 404 (not found), even though 410 would 
be better.  What should a client do if it receives a 404 or 410?  Is 
there a way for them to find the new instance?  Should there be?  
(Presumably they're subscribed to the feed from a URI different than 
the one in the "this" link, so in this case, it's probably not such a 
big deal, but read on, and you'll see where it could become an issue).

Now let's look further down the road--we have 15 entries in the feed, 
and the latest instance has it's "this" and maybe a "prev" or maybe 
not.  We add another entry.  One reasonable thing to do would be to 
continue to provide the instance with the first 15 entries and point to 
it as the "prev".  Another reasonable thing to do would be to point to 
the original single-entry instance as the "prev"--ie. the most recent 
instance which doesn't share any entries with this one.

As time goes by, the publisher could end up providing every old 
instance, or just one old instance for each 15 entries.  The latter 
would provide for much more efficient catching up on the feed state.  
But if the in between instances are dropped, clients could easily end 
up running into dead ends (410 or 404) often when trying to catch up, 
even though there is older data available at a different URI.

Perhaps the best solution would be to have no "prev" for the first 15 
instances, then point to the instance with the first fifteen entries 
from each of the next 15 instances, then point to the instance with 
entries 16-30 from the next fifteen instances, etc., so that one is 
never pointing to an instance that won't continue to be provided 
(unless, for example, you only continue to provide the most recent 10 
(for example) groups of 15 entries).

If this is to be "allowed", then one word ought to be changed in the 
draft (and I'd think that fleshing out some of these details would be 
very useful, though of course it wouldn't be normative):

    The value of the "prev" link relation's href attribute MUST be a URI
    indicating the location of the previous representation of the feed;
    i.e., the last Feed Document's "this" URI.

"THE previous representation" => "A previous representation" or 
something along the lines of "THE previous representation in the chain 
or representations".

I'm noticing now that " i.e., the last Feed Document's "this" URI." 
sounds like it's disallowing the batches-of-15 method outlined above.  
If we don't wish to disallow that, that should be changed to something 
like " i.e., a previous Feed Document's "this" URI."

Also, I just noticed that in some places, the word "representation" is 
used, and in some places "instance" is used, apparently to mean the 
same thing.  In my opinion, "instance" is better.

Antone




From owner-atom-syntax@mail.imc.org Tue Jun 28 21:10:05 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DnR5Z-0003CQ-23
	for atompub-archive@megatron.ietf.org; Tue, 28 Jun 2005 21:10:05 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18984
	for <atompub-archive@lists.ietf.org>; Tue, 28 Jun 2005 21:10:02 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5SKPcQU082523;
	Tue, 28 Jun 2005 13:25:38 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5SKPcH5082522;
	Tue, 28 Jun 2005 13:25:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5SKPbcJ082509
	for <atom-syntax@imc.org>; Tue, 28 Jun 2005 13:25:38 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [172.16.1.3] (sj-ez-63-96-162-1.bea.com [63.96.162.1])
	(using TLSv1 with cipher RC4-SHA (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 8994BA32AA
	for <atom-syntax@imc.org>; Tue, 28 Jun 2005 16:25:36 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v730)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <097CC973-BC19-4838-9076-019A9FD614EC@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-00.txt
Date: Tue, 28 Jun 2005 13:25:34 -0700
To: Atom Syntax <atom-syntax@imc.org>
X-Mailer: Apple Mail (2.730)
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: 7bit


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


         Title           : Feed History: Enabling Stateful Syndication
         Author(s)       : M. Nottingham
         Filename        : draft-nottingham-atompub-feed-history-00.txt
         Pages           : 6
         Date            : 2005-6-27

    This document specifies mechanisms that allow feed publishers to  
give
    hints about the nature of the feed's statefulness, and a means of
    retrieving ^missed^ entries from a stateful feed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-nottingham-atompub-feed- 
history-00.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request at 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-00.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 at ietf.org.
In the body type:
         "FILE /internet-drafts/draft-nottingham-atompub-feed- 
history-00.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.


_______________________________________________
I-D-Announce mailing list
I-D-Announce at ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce


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




From owner-atom-syntax@mail.imc.org Tue Jun 28 21:14:23 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DnR9i-0004dl-8Z
	for atompub-archive@megatron.ietf.org; Tue, 28 Jun 2005 21:14:23 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19361
	for <atompub-archive@lists.ietf.org>; Tue, 28 Jun 2005 21:14:20 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5T166QV054455;
	Tue, 28 Jun 2005 18:06:06 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5T166uH054453;
	Tue, 28 Jun 2005 18:06:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5T165XW054437
	for <atom-syntax@imc.org>; Tue, 28 Jun 2005 18:06:05 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [172.16.1.3] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	(using TLSv1 with cipher RC4-SHA (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 1A027A32B7;
	Tue, 28 Jun 2005 21:06:03 -0400 (EDT)
In-Reply-To: <2D508554-E81F-11D9-BC21-003065EA6144@geckotribe.com>
References: <2D508554-E81F-11D9-BC21-003065EA6144@geckotribe.com>
Mime-Version: 1.0 (Apple Message framework v730)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <05C5A8E9-63C4-4C47-AE11-D1245B7EF75D@mnot.net>
Cc: 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-00.txt
Date: Tue, 28 Jun 2005 18:05:59 -0700
To: Antone Roundy <antone@geckotribe.com>
X-Mailer: Apple Mail (2.730)
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: 7bit


Hi Antone,

Thanks for the comments. This draft was admittedly rough, but I  
wanted to get an idea of people's general reactions before refining  
it too much. In particular, I'd be interested in implementors'  
reactions (e.g., aggregators, publishers).

Responses below.


> Then we add an entry.  The old "this" link can't be used to point  
> to the new instance of the feed, right?  Because that would violate  
> this requirement:
>
>    "The value of the "this" link relation's href attribute MUST be  
> a URI
>    indicating a permanent location that is unique to that Feed  
> Document
>    instance; i.e., the content obtained by dereferencing that URI  
> SHOULD
>    NOT change over time."

This is poorly worded; your 'batches of 15' scenario is what I had in  
mind. I'll work on better language for -01.

> Now let's say someone tries to fetch the original "this" feed.  The  
> draft says:
>
>    "Note that publishers are not required to make all previous Feed
>    Documents available."
>
> This seems like a likely circumstance where the publisher might not  
> want to both to continue making the original instance available.   
> If that's what they decide, then what?  Do they return a 410  
> (gone)?  Presumably, some will return a 404 (not found), even  
> though 410 would be better.  What should a client do if it receives  
> a 404 or 410?  Is there a way for them to find the new instance?   
> Should there be?  (Presumably they're subscribed to the feed from a  
> URI different than the one in the "this" link, so in this case,  
> it's probably not such a big deal, but read on, and you'll see  
> where it could become an issue).

I'm not sure what you're looking for; the semantics of 404 and 410  
are clearly defined by HTTP. If the server says it can't find it, or  
it's gone, the client is unable to reconstruct the full state of the  
feed, and SHOULD warn the user.

> Also, I just noticed that in some places, the word "representation"  
> is used, and in some places "instance" is used, apparently to mean  
> the same thing.  In my opinion, "instance" is better.

I'll take a look.

Thanks again!

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




From owner-atom-syntax@mail.imc.org Tue Jun 28 21:14:23 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DnR9j-0004dm-KG
	for atompub-archive@megatron.ietf.org; Tue, 28 Jun 2005 21:14:23 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19364
	for <atompub-archive@lists.ietf.org>; Tue, 28 Jun 2005 21:14:21 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5T16ScL054849;
	Tue, 28 Jun 2005 18:06:28 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5T16S94054848;
	Tue, 28 Jun 2005 18:06:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5T16S6a054841
	for <atom-syntax@imc.org>; Tue, 28 Jun 2005 18:06:28 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [172.16.1.3] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	(using TLSv1 with cipher RC4-SHA (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 6F138A32AB;
	Tue, 28 Jun 2005 21:06:26 -0400 (EDT)
In-Reply-To: <42C1B585.6000606@electricjellyfish.net>
References: <097CC973-BC19-4838-9076-019A9FD614EC@mnot.net> <42C1B585.6000606@electricjellyfish.net>
Mime-Version: 1.0 (Apple Message framework v730)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <801C681E-5FC7-48AB-B3E4-072A9582B7CB@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-00.txt
Date: Tue, 28 Jun 2005 18:06:24 -0700
To: Garrett Rooney <rooneg@electricjellyfish.net>
X-Mailer: Apple Mail (2.730)
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: 7bit


Thanks Garrett, I'll take this into account if I do another draft.

Cheers,

On 28/06/2005, at 1:39 PM, Garrett Rooney wrote:

> Mark Nottingham wrote:
>
>> A New Internet-Draft is available from the on-line Internet- 
>> Drafts  directories.
>>         Title           : Feed History: Enabling Stateful Syndication
>>         Author(s)       : M. Nottingham
>>         Filename        : draft-nottingham-atompub-feed- 
>> history-00.txt
>>         Pages           : 6
>>         Date            : 2005-6-27
>>    This document specifies mechanisms that allow feed publishers  
>> to  give
>>    hints about the nature of the feed's statefulness, and a means of
>>    retrieving ^missed^ entries from a stateful feed.
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-nottingham-atompub-feed-  
>> history-00.txt
>>
>
> I imagine someone else has already noticed this, but there's a typo  
> in the example.  The open tag uses the prefix 'fh', but the close  
> tag uses 'fs'.
>
> Also, why is Stateful capitalized?  All the other parts of atom use  
> lower case tag names, IIRC.
>
> -garrett
>
>


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




From owner-atom-syntax@mail.imc.org Tue Jun 28 23:56:57 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DnTh3-0007nJ-ND
	for atompub-archive@megatron.ietf.org; Tue, 28 Jun 2005 23:56:57 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29759
	for <atompub-archive@lists.ietf.org>; Tue, 28 Jun 2005 23:56:54 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5T3mcPj038921;
	Tue, 28 Jun 2005 20:48:38 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5T3mcsW038920;
	Tue, 28 Jun 2005 20:48:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5T3mbqK038874
	for <atom-syntax@imc.org>; Tue, 28 Jun 2005 20:48:37 -0700 (PDT)
	(envelope-from antone@geckotribe.com)
Received: from geckotribe.com (c-67-169-250-63.hsd1.ut.comcast.net[67.169.250.63])
          by comcast.net (sccrmhc13) with SMTP
          id <2005062903482101600i6f89e>; Wed, 29 Jun 2005 03:48:31 +0000
Date: Tue, 28 Jun 2005 21:48:20 -0600
Subject: Re: I-D ACTION:draft-nottingham-atompub-feed-history-00.txt
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v553)
From: Antone Roundy <antone@geckotribe.com>
To: atom-syntax@imc.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <05C5A8E9-63C4-4C47-AE11-D1245B7EF75D@mnot.net>
Message-Id: <A247578A-E850-11D9-BC21-003065EA6144@geckotribe.com>
X-Mailer: Apple Mail (2.553)
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: 7bit


Thinking a little more about this, I'm not sure what the "this" link 
would be used for.  The "prev" link seems to be doing all the work, and 
especially assuming a "batches of 15" sort of model, the "this" link 
seems likely to end up pointing to a document that's going to disappear 
soon 14 times out of 15.

On Tuesday, June 28, 2005, at 07:05  PM, Mark Nottingham wrote:
>> Now let's say someone tries to fetch the original "this" feed.  The 
>> draft says:
>>
>>    "Note that publishers are not required to make all previous Feed
>>    Documents available."
>>
>> This seems like a likely circumstance where the publisher might not 
>> want to both to continue making the original instance available.  If 
>> that's what they decide, then what?  Do they return a 410 (gone)?  
>> Presumably, some will return a 404 (not found), even though 410 would 
>> be better.  What should a client do if it receives a 404 or 410?  Is 
>> there a way for them to find the new instance?  Should there be?  
>> (Presumably they're subscribed to the feed from a URI different than 
>> the one in the "this" link, so in this case, it's probably not such a 
>> big deal, but read on, and you'll see where it could become an >> issue).
>
> I'm not sure what you're looking for; the semantics of 404 and 410 are 
> clearly defined by HTTP. If the server says it can't find it, or it's 
> gone, the client is unable to reconstruct the full state of the feed, 
> and SHOULD warn the user.
>
What I'm saying is that if instance 16 of the feed points back to 
instance 15, instance 17 to instance 16, instance 18 to instance 17, 
etc., but at some point your drop all but instance 15, instance 30, 
etc., then the links to all the instances in between are going to end 
up returning 404s or 410s.  So I'd suggest that there be no 
per-instance "this" link, and that the "prev" link be updated only when 
a new batch-of-n document is created.  Doing it that way, n-1 times out 
of n, there would be overlap between the current feed and that most 
recent batch-of-n document (but that wouldn't be a big deal), but no 
overlap between any previous batch-of-n documents, and no intermediate 
documents would disappear.




From owner-atom-syntax@mail.imc.org Wed Jun 29 02:27:57 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DnW3B-0001TZ-LN
	for atompub-archive@megatron.ietf.org; Wed, 29 Jun 2005 02:27:57 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08264
	for <atompub-archive@lists.ietf.org>; Wed, 29 Jun 2005 02:27:56 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5T6B0Vb053942;
	Tue, 28 Jun 2005 23:11:00 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5T6B05p053938;
	Tue, 28 Jun 2005 23:11:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5T6AxfF053895
	for <atom-syntax@imc.org>; Tue, 28 Jun 2005 23:10:59 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [172.16.1.3] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	(using TLSv1 with cipher RC4-SHA (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 438C2A32E1;
	Wed, 29 Jun 2005 02:10:57 -0400 (EDT)
In-Reply-To: <A247578A-E850-11D9-BC21-003065EA6144@geckotribe.com>
References: <A247578A-E850-11D9-BC21-003065EA6144@geckotribe.com>
Mime-Version: 1.0 (Apple Message framework v730)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <3F0562C1-9FA9-4EB3-8CFE-89AF52E9303E@mnot.net>
Cc: 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-00.txt
Date: Tue, 28 Jun 2005 23:10:52 -0700
To: Antone Roundy <antone@geckotribe.com>
X-Mailer: Apple Mail (2.730)
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: 7bit


You need to be able to figure out which documents you've seen before  
and which ones you haven't, so you don't recurse down the entire  
stack. Although you can come up with some heuristics to determine  
when you've seen a document before, most (if not all) of them can be  
fooled by particular sequences of entries. Remembering which ones  
you've seen (using their 'this' URI) allows you to easily figure this  
out.


On 28/06/2005, at 8:48 PM, Antone Roundy wrote:


> Thinking a little more about this, I'm not sure what the "this"  
> link would be used for.  The "prev" link seems to be doing all the  
> work, and especially assuming a "batches of 15" sort of model, the  
> "this" link seems likely to end up pointing to a document that's  
> going to disappear soon 14 times out of 15.
>

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




From owner-atom-syntax@mail.imc.org Wed Jun 29 03:40:49 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DnXBg-00058B-Q9
	for atompub-archive@megatron.ietf.org; Wed, 29 Jun 2005 03:40:49 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19363
	for <atompub-archive@lists.ietf.org>; Wed, 29 Jun 2005 03:40:47 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5T7WcUR024552;
	Wed, 29 Jun 2005 00:32:38 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5T7WcIJ024551;
	Wed, 29 Jun 2005 00:32:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mailhost.netweaver.net (mailhost.netweaver.net [213.160.118.140])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j5T7WaHC024528
	for <atom-syntax@imc.org>; Wed, 29 Jun 2005 00:32:37 -0700 (PDT)
	(envelope-from davep@dpawson.co.uk)
Received: (qmail 17005 invoked from network); 29 Jun 2005 07:32:35 -0000
Received: from dpawson.gotadsl.co.uk (HELO ?192.168.2.7?) (davep@dpawson.co.uk@81.6.251.105)
  by 0 with SMTP; 29 Jun 2005 07:32:35 -0000
Subject: Re: FWD: I-D ACTION:draft-nottingham-atompub-feed-history-00.txt
From: Dave Pawson <davep@dpawson.co.uk>
Reply-To: davep@dpawson.co.uk
To: Mark Nottingham <mnot@mnot.net>
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <097CC973-BC19-4838-9076-019A9FD614EC@mnot.net>
References: <097CC973-BC19-4838-9076-019A9FD614EC@mnot.net>
Content-Type: text/plain
Date: Wed, 29 Jun 2005 08:32:35 +0100
Message-Id: <1120030355.3386.10.camel@marge>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.2 (2.2.2-5) 
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>
Content-Transfer-Encoding: 7bit


On Tue, 2005-06-28 at 13:25 -0700, Mark Nottingham wrote:

>     This document specifies mechanisms that allow feed publishers to  
> give
>     hints about the nature of the feed's statefulness, and a means of
>     retrieving ^missed^ entries from a stateful feed.

This tries to address my concern earlier, about an author generating
entries, with only one feed. 
  I like the basic idea of enabling differentiation between 'stable' and
other feeds.

Now I'm confused about the feed metadata and stability of feed uri's.

Any one site could now have n instances, each being a feed, the only
variant (apart from entries) being the links to previous feeds. 
If I'm to say *this* is my feed, I guess I point to the most recent...
which will change over time?

With the example of 15 entries per,

feed1 1..15
feed4 45..60

my 'feed' for my site rolls over from feed1...n as time progresses?

This smells like a kludge to me Mark. I'd *like* to have a single
url which is my feed. Using this logic presented, if I'm going to 
chunk my feed then I can't have a stable feed url?

Equally I'm not happy about a moderate blog keeping all entries
in one feed. It won't take long for the instance to become significant
in size.


-- 
Regards, 

Dave Pawson
XSLT + Docbook FAQ
http://www.dpawson.co.uk




From owner-atom-syntax@mail.imc.org Wed Jun 29 05:04:41 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DnYUr-0004Hp-DY
	for atompub-archive@megatron.ietf.org; Wed, 29 Jun 2005 05:04:41 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24664
	for <atompub-archive@lists.ietf.org>; Wed, 29 Jun 2005 05:04:39 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5T8vNAH099986;
	Wed, 29 Jun 2005 01:57:23 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5T8vN1Y099984;
	Wed, 29 Jun 2005 01:57:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.205])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5T8vMpN099859
	for <atom-syntax@imc.org>; Wed, 29 Jun 2005 01:57:22 -0700 (PDT)
	(envelope-from danny.ayers@gmail.com)
Received: by zproxy.gmail.com with SMTP id q3so433148nzb
        for <atom-syntax@imc.org>; Wed, 29 Jun 2005 01:57:17 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=NB2DYU540OhTXo9xyhJ91qY8pwt9+KcoQgh7vWbzNW1ox6NJeWnnuO3Nzag0vl+ryM+JZfQdg6oO/08ihMpYoRlxiqxeLFcTb+NMTjD9oGBgbtUci05muECOPEjduI7ypiE6GRdtvoFT4XmoxG+M7PiXXsYZW9CMFxfsL7/zxqo=
Received: by 10.36.84.10 with SMTP id h10mr5491138nzb;
        Wed, 29 Jun 2005 01:57:17 -0700 (PDT)
Received: by 10.36.47.13 with HTTP; Wed, 29 Jun 2005 01:57:17 -0700 (PDT)
Message-ID: <1f2ed5cd05062901577845007@mail.gmail.com>
Date: Wed, 29 Jun 2005 10:57:17 +0200
From: Danny Ayers <danny.ayers@gmail.com>
Reply-To: Danny Ayers <danny.ayers@gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Subject: Re: I-D ACTION:draft-nottingham-atompub-feed-history-00.txt
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <097CC973-BC19-4838-9076-019A9FD614EC@mnot.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
References: <097CC973-BC19-4838-9076-019A9FD614EC@mnot.net>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j5T8vNpN099977
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: 8bit


On 6/28/05, Mark Nottingham <mnot@mnot.net> wrote:

>          Title           : Feed History: Enabling Stateful Syndication

Interesting, sounds like it could be useful. On a first read,what came to mind:

Trivial: might 1/0 be confusing compared to something clearly binary: 
true/false or yes/no, and difficult to extend: true/false/unknown

What is the Stateful nature of a feed *without* a Stateful element,
the default if you will? (Could be per-case or 'indeterminate', but I
think some comment on this would be helpful).

 If you're talking about feed reconstruction, might it not make sense
to have something like an "all" (which could appear as a minimal list
of dated URIs of entries) to avoid countless GET/interpret cycles?

Cheers,
Danny.

-- 

http://dannyayers.com




From owner-atom-syntax@mail.imc.org Wed Jun 29 05:43:08 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DnZ64-0006Zo-Jh
	for atompub-archive@megatron.ietf.org; Wed, 29 Jun 2005 05:43:08 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27599
	for <atompub-archive@lists.ietf.org>; Wed, 29 Jun 2005 05:43:04 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5T9aimU031350;
	Wed, 29 Jun 2005 02:36:44 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5T9aiuk031349;
	Wed, 29 Jun 2005 02:36:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5T9afR8031289
	for <atom-syntax@imc.org>; Wed, 29 Jun 2005 02:36:42 -0700 (PDT)
	(envelope-from stefan.eissing@greenbytes.de)
Received: from [192.168.1.26] by greenbytes.de
	(Cipher TLSv1:RC4-MD5:128) (MDaemon.PRO.v8.0.2.T)
	with ESMTP id md50000117500.msg
	for <atom-syntax@imc.org>; Wed, 29 Jun 2005 11:32:56 +0200
In-Reply-To: <097CC973-BC19-4838-9076-019A9FD614EC@mnot.net>
References: <097CC973-BC19-4838-9076-019A9FD614EC@mnot.net>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <94d7a13c91143b564dc85ca38c29eb65@greenbytes.de>
Content-Transfer-Encoding: 7bit
Cc: Atom Syntax <atom-syntax@imc.org>
From: Stefan Eissing <stefan.eissing@greenbytes.de>
Subject: Re: I-D ACTION:draft-nottingham-atompub-feed-history-00.txt
Date: Wed, 29 Jun 2005 11:36:19 +0200
To: Mark Nottingham <mnot@mnot.net>
X-Mailer: Apple Mail (2.622)
X-Authenticated-Sender: se@greenbytes.de
X-Spam-Processed: greenbytes.de, Wed, 29 Jun 2005 11:32:56 +0200
	(not processed: message from valid local sender)
X-MDRemoteIP: 192.168.1.26
X-Return-Path: stefan.eissing@greenbytes.de
X-MDaemon-Deliver-To: atom-syntax@imc.org
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: 7bit


What little I can add to this, not being an atom boy:

Most versioning system cannot reliably predict the URI of the next  
version. So, embedding the URI of the document inside the document  
itself, either requires document changes on submitting a new version or  
a try-and-error approach. (WebDAV deltav offers a try-and-error  
mechanism)

One could work around this by inventing a "version history" document  
which keeps the URIs of all feed versions (and the prev/next relations,  
so a reader could find out that there is a newer one also). Since the  
version history URI never changes for a feed, embedding the history URI  
inside the feed poses no challenge.

I cannot judge weather coming up with an extra document for this  
feature is overkill or not. But it would allow for easier integration  
into existing versioning mechanisms.

Best Regards, Stefan - wondering if the version history would be a feed  
of its own...

Am 28.06.2005 um 22:25 schrieb Mark Nottingham:

>
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
>
>
>         Title           : Feed History: Enabling Stateful Syndication
>         Author(s)       : M. Nottingham
>         Filename        : draft-nottingham-atompub-feed-history-00.txt
>         Pages           : 6
>         Date            : 2005-6-27
>
>    This document specifies mechanisms that allow feed publishers to  
> give
>    hints about the nature of the feed's statefulness, and a means of
>    retrieving ^missed^ entries from a stateful feed.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-nottingham-atompub-feed- 
> history-00.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> i-d-announce-request at 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-00.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 at ietf.org.
> In the body type:
>         "FILE  
> /internet-drafts/draft-nottingham-atompub-feed-history-00.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.
>
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce at ietf.org
> https://www1.ietf.org/mailman/listinfo/i-d-announce
>
>
> --
> Mark Nottingham     http://www.mnot.net/
>





From owner-atom-syntax@mail.imc.org Wed Jun 29 09:13:26 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DncNa-0001n9-8I
	for atompub-archive@megatron.ietf.org; Wed, 29 Jun 2005 09:13:26 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17226
	for <atompub-archive@lists.ietf.org>; Wed, 29 Jun 2005 09:13:24 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5TD3DCv063049;
	Wed, 29 Jun 2005 06:03:13 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5TD3ALv062968;
	Wed, 29 Jun 2005 06:03:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtp.cegetel.net (mf00.sitadelle.com [212.94.174.67])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5TD36w0062646
	for <atom-syntax@imc.org>; Wed, 29 Jun 2005 06:03:08 -0700 (PDT)
	(envelope-from t.broyer@cegetel.net)
Received: from cegetel.net (217-19-192-102.dti.cegetel.net [217.19.192.102])
	by smtp.cegetel.net (Postfix) with SMTP id 7D6881A43C6;
	Wed, 29 Jun 2005 15:02:55 +0200 (CEST)
Received: from 82.127.77.43
        (SquirrelMail authenticated user t.broyer@cegetel.net)
        by ssl-webmail.sitadelle.com with HTTP;
        Wed, 29 Jun 2005 15:03:00 +0200 (CEST)
Message-ID: <2143.82.127.77.43.1120050180.squirrel@ssl-webmail.sitadelle.com>
Date: Wed, 29 Jun 2005 15:03:00 +0200 (CEST)
Subject: Re: FWD: I-D ACTION:draft-nottingham-atompub-feed-history-00.txt
From: "Thomas Broyer" <t.broyer@cegetel.net>
To: <davep@dpawson.co.uk>
In-Reply-To: <1120030355.3386.10.camel@marge>
References: <097CC973-BC19-4838-9076-019A9FD614EC@mnot.net>
        <1120030355.3386.10.camel@marge>
X-Priority: 3
Importance: Normal
Cc: <mnot@mnot.net>, <atom-syntax@imc.org>
X-Mailer: SquirrelMail (version 1.2.10)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
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: 8bit



Dave Pawson wrote:
> Any one site could now have n instances, each being a feed, the only
> variant (apart from entries) being the links to previous feeds.
> If I'm to say *this* is my feed, I guess I point to the most recent...
> which will change over time?
>
> With the example of 15 entries per,
>
> feed1 1..15
> feed4 45..60
>
> my 'feed' for my site rolls over from feed1...n as time progresses?

I guess the answer is:
http://example.com/latest is your feed, e.g. containing the latest 10 entries
http://example.com/archive-1 through n are your "archive" feeds.

"latest" is likely to contain entries which are also "archived" in
"archive-n", but I don't see it as a problem (and it doesn't violate Atom
Feed Document rules wrt uniqueness of entries), at most I will retrieve 14
entries (if using 15 entries per "archive feed document") which I already
got from the "live" feed.

You can see "latest" as an Atom alternate for your home page (or latest
news page) and "archive-1" through "archive-n" as Atom alternates for your
"archive" pages.

What I'm wondering is, if I had "archive feeds" on a per-day basis
(instead of "N entries per archive feed", although what follows also
applies) and say I published 3 entries yesterday, 5 entries the day before
and no entry yet today:
 - http://example.net/archive/2005/06/27: 5 entries
 - http://example.net/archive/2005/06/28: 3 entries
 - http://example.net/archive/2005/06/29: doesn't exist yet
Say I'm having a "live feed" showing the latest 5 entries: it will contain
all the 3 yesterday entries and the 2 latest entries from 2005/06/27.
Could I "prev"-link to "archive/2005/06/28" or should I try to figure out
the "archive feed" containing the "previous to earliest" entry (here,
"archive/2005/06/27", but it could have been "archive/2005/06/25" if I had
only 2 entries last monday and not at all on sunday) ?
If I can just link to the "latest archive feed document", shouldn't we
then just have an "archive" link@rel in the "live feeds" (similar to the
"List-Archive" header in mail messages) and use "prev" only between
"archive feed documents" (similar to the "Next Page" link in the HTML list
archive).

-- 
Thomas Broyer





From owner-atom-syntax@mail.imc.org Wed Jun 29 09:28:29 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dncc9-0006v2-9e
	for atompub-archive@megatron.ietf.org; Wed, 29 Jun 2005 09:28:29 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18357
	for <atompub-archive@lists.ietf.org>; Wed, 29 Jun 2005 09:28:27 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5TDM7gd088542;
	Wed, 29 Jun 2005 06:22:07 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5TDM7na088537;
	Wed, 29 Jun 2005 06:22:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from rwcrmhc14.comcast.net (rwcrmhc14.comcast.net [216.148.227.89])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5TDM6SH088420
	for <atom-syntax@imc.org>; Wed, 29 Jun 2005 06:22:06 -0700 (PDT)
	(envelope-from antone@geckotribe.com)
Received: from geckotribe.com (c-67-169-250-63.hsd1.ut.comcast.net[67.169.250.63])
          by comcast.net (rwcrmhc14) with SMTP
          id <2005062913220001400mcmuve>; Wed, 29 Jun 2005 13:22:00 +0000
Date: Wed, 29 Jun 2005 07:21:58 -0600
Subject: Re: I-D ACTION:draft-nottingham-atompub-feed-history-00.txt
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v553)
From: Antone Roundy <antone@geckotribe.com>
To: atom-syntax@imc.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <3F0562C1-9FA9-4EB3-8CFE-89AF52E9303E@mnot.net>
Message-Id: <C5255329-E8A0-11D9-9869-003065EA6144@geckotribe.com>
X-Mailer: Apple Mail (2.553)
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: 7bit


If it's for identification rather than retrieval, maybe it could be an 
Identity Construct...except Identity Constructs got nuked in 
format-06...not necessarily dereferencable.  Another option would be to 
identify whether you need to continue by checking whether you've seen 
the "prev" link before.  Would not that be as reliable as checking the 
"this" link?

On Wednesday, June 29, 2005, at 12:10  AM, Mark Nottingham wrote:

> You need to be able to figure out which documents you've seen before 
> and which ones you haven't, so you don't recurse down the entire 
> stack. Although you can come up with some heuristics to determine when 
> you've seen a document before, most (if not all) of them can be fooled 
> by particular sequences of entries. Remembering which ones you've seen 
> (using their 'this' URI) allows you to easily figure this out.
>
>
> On 28/06/2005, at 8:48 PM, Antone Roundy wrote:
>
>
>> Thinking a little more about this, I'm not sure what the "this" link 
>> would be used for.  The "prev" link seems to be doing all the work, 
>> and especially assuming a "batches of 15" sort of model, the "this" 
>> link seems likely to end up pointing to a document that's going to 
>> disappear soon 14 times out of 15.
>>
>
> --
> Mark Nottingham     http://www.mnot.net/
>




From owner-atom-syntax@mail.imc.org Wed Jun 29 09:34:52 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DnciK-0008E0-3I
	for atompub-archive@megatron.ietf.org; Wed, 29 Jun 2005 09:34:52 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18881
	for <atompub-archive@lists.ietf.org>; Wed, 29 Jun 2005 09:34:50 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5TDS29n095871;
	Wed, 29 Jun 2005 06:28:02 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5TDS2AX095870;
	Wed, 29 Jun 2005 06:28:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mailhost.netweaver.net (mailhost.netweaver.net [213.160.118.140])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j5TDS0QG095822
	for <atom-syntax@imc.org>; Wed, 29 Jun 2005 06:28:01 -0700 (PDT)
	(envelope-from davep@dpawson.co.uk)
Received: (qmail 14988 invoked from network); 29 Jun 2005 13:28:00 -0000
Received: from dpawson.gotadsl.co.uk (HELO ?192.168.2.7?) (davep@dpawson.co.uk@81.6.251.105)
  by 0 with SMTP; 29 Jun 2005 13:28:00 -0000
Subject: Re: FWD: I-D ACTION:draft-nottingham-atompub-feed-history-00.txt
From: Dave Pawson <davep@dpawson.co.uk>
Reply-To: davep@dpawson.co.uk
To: Thomas Broyer <t.broyer@cegetel.net>
Cc: mnot@mnot.net, atom-syntax@imc.org
In-Reply-To: <2143.82.127.77.43.1120050180.squirrel@ssl-webmail.sitadelle.com>
References: <097CC973-BC19-4838-9076-019A9FD614EC@mnot.net>
	 <1120030355.3386.10.camel@marge>
	 <2143.82.127.77.43.1120050180.squirrel@ssl-webmail.sitadelle.com>
Content-Type: text/plain
Date: Wed, 29 Jun 2005 14:27:55 +0100
Message-Id: <1120051675.3359.5.camel@marge>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.2 (2.2.2-5) 
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>
Content-Transfer-Encoding: 7bit


On Wed, 2005-06-29 at 15:03 +0200, Thomas Broyer wrote:
> Dave Pawson wrote:
> > Any one site could now have n instances, each being a feed, the only
> > variant (apart from entries) being the links to previous feeds.
> > If I'm to say *this* is my feed, I guess I point to the most recent...
> > which will change over time?
> >
> > With the example of 15 entries per,
> >
> > feed1 1..15
> > feed4 45..60
> >
> > my 'feed' for my site rolls over from feed1...n as time progresses?
> 
> I guess the answer is:
> http://example.com/latest is your feed, e.g. containing the latest 10 entries
> http://example.com/archive-1 through n are your "archive" feeds.

Which would mean that the instance at /latest keeps changing?
I need to keep swapping old ones out, new ones in, i.e. rebuilding
each time?

  I guess that's another reason it feels like a kludge.


> 
> You can see "latest" as an Atom alternate for your home page (or latest
> news page) and "archive-1" through "archive-n" as Atom alternates for your
> "archive" pages.

I can see the logic of your suggestion. 
  Doesn't seem clean though?


<snip/> Other issues.

regards DaveP






From owner-atom-syntax@mail.imc.org Wed Jun 29 10:05:41 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DndC9-0002ea-Kp
	for atompub-archive@megatron.ietf.org; Wed, 29 Jun 2005 10:05:41 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22654
	for <atompub-archive@lists.ietf.org>; Wed, 29 Jun 2005 10:05:39 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5TDib6S018251;
	Wed, 29 Jun 2005 06:44:37 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5TDibnk018249;
	Wed, 29 Jun 2005 06:44:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5TDibvs018166
	for <atom-syntax@imc.org>; Wed, 29 Jun 2005 06:44:37 -0700 (PDT)
	(envelope-from antone@geckotribe.com)
Received: from geckotribe.com (c-67-169-250-63.hsd1.ut.comcast.net[67.169.250.63])
          by comcast.net (rwcrmhc13) with SMTP
          id <2005062913443101500bml76e>; Wed, 29 Jun 2005 13:44:31 +0000
Date: Wed, 29 Jun 2005 07:44:30 -0600
Subject: Re: I-D ACTION:draft-nottingham-atompub-feed-history-00.txt
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v553)
From: Antone Roundy <antone@geckotribe.com>
To: atom-syntax@imc.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <1120051675.3359.5.camel@marge>
Message-Id: <EAF10613-E8A3-11D9-9869-003065EA6144@geckotribe.com>
X-Mailer: Apple Mail (2.553)
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: 7bit


On Wednesday, June 29, 2005, at 07:27  AM, Dave Pawson wrote:
>> I guess the answer is:
>> http://example.com/latest is your feed, e.g. containing the latest 10 
>> entries
>> http://example.com/archive-1 through n are your "archive" feeds.
>
> Which would mean that the instance at /latest keeps changing?
> I need to keep swapping old ones out, new ones in, i.e. rebuilding
> each time?
>
>   I guess that's another reason it feels like a kludge.
>
Replace http://example.com/latest with http://example.com/atom.xml.  Of 
course the latest document keeps changing and has to be rebuilt and 
replaced each time.  It's the feed document just like what we see 
today.  At least that's how I read what was written 
above--"http://example.com/latest" was intended as the URI to which 
you'd subscribe.




From owner-atom-syntax@mail.imc.org Wed Jun 29 12:17:34 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DnfFm-0008Kn-5t
	for atompub-archive@megatron.ietf.org; Wed, 29 Jun 2005 12:17:34 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07000
	for <atompub-archive@lists.ietf.org>; Wed, 29 Jun 2005 12:17:31 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5TG9iSg085137;
	Wed, 29 Jun 2005 09:09:45 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5TG9iSX085131;
	Wed, 29 Jun 2005 09:09:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5TG9hgo085044
	for <atom-syntax@imc.org>; Wed, 29 Jun 2005 09:09:43 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [172.16.1.3] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	(using TLSv1 with cipher RC4-SHA (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 60E3FA34CE;
	Wed, 29 Jun 2005 12:09:42 -0400 (EDT)
In-Reply-To: <1f2ed5cd05062901577845007@mail.gmail.com>
References: <097CC973-BC19-4838-9076-019A9FD614EC@mnot.net> <1f2ed5cd05062901577845007@mail.gmail.com>
Mime-Version: 1.0 (Apple Message framework v730)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <788DD8A0-45CB-4E6F-8E36-B13184D009B7@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-00.txt
Date: Wed, 29 Jun 2005 09:09:40 -0700
To: Danny Ayers <danny.ayers@gmail.com>
X-Mailer: Apple Mail (2.730)
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: 7bit


Hi Danny,

Thanks for the comments.

On 29/06/2005, at 1:57 AM, Danny Ayers wrote:
>
> Trivial: might 1/0 be confusing compared to something clearly binary:
> true/false or yes/no, and difficult to extend: true/false/unknown

ack

> What is the Stateful nature of a feed *without* a Stateful element,
> the default if you will? (Could be per-case or 'indeterminate', but I
> think some comment on this would be helpful).

Yes, that's the intent; if you don't have a flag, there isn't any  
information about what it is (or isn't), and you act as you would today.

>  If you're talking about feed reconstruction, might it not make sense
> to have something like an "all" (which could appear as a minimal list
> of dated URIs of entries) to avoid countless GET/interpret cycles?

I put that forth in the original Pace <http://www.intertwingly.net/ 
wiki/pie/PaceFeedState> (see history), and it got very negative  
reviews, because it requires a lot of work to maintain, and can be a  
bandwidth hog. I'm of two minds about it.

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




From owner-atom-syntax@mail.imc.org Wed Jun 29 12:17:43 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DnfFv-0008SI-EQ
	for atompub-archive@megatron.ietf.org; Wed, 29 Jun 2005 12:17:43 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07078
	for <atompub-archive@lists.ietf.org>; Wed, 29 Jun 2005 12:17:38 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5TG96gU084516;
	Wed, 29 Jun 2005 09:09:06 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5TG96ap084515;
	Wed, 29 Jun 2005 09:09:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5TG95fB084437
	for <atom-syntax@imc.org>; Wed, 29 Jun 2005 09:09:05 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [172.16.1.3] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	(using TLSv1 with cipher RC4-SHA (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id C1B0AA34D8;
	Wed, 29 Jun 2005 12:09:03 -0400 (EDT)
In-Reply-To: <C5255329-E8A0-11D9-9869-003065EA6144@geckotribe.com>
References: <C5255329-E8A0-11D9-9869-003065EA6144@geckotribe.com>
Mime-Version: 1.0 (Apple Message framework v730)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <9F820B18-F5F5-4B1B-A97A-DC39392A8062@mnot.net>
Cc: 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-00.txt
Date: Wed, 29 Jun 2005 09:09:00 -0700
To: Antone Roundy <antone@geckotribe.com>
X-Mailer: Apple Mail (2.730)
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: 7bit


I think you're right... I was concerned about servers doing  
redirection, so that a client might miss the fact that it's already  
seen an archive, but as long as it uses the same identifiers to  
locate documents, it should be fine.

On 29/06/2005, at 6:21 AM, Antone Roundy wrote:


>
> If it's for identification rather than retrieval, maybe it could be  
> an Identity Construct...except Identity Constructs got nuked in  
> format-06...not necessarily dereferencable.  Another option would  
> be to identify whether you need to continue by checking whether  
> you've seen the "prev" link before.  Would not that be as reliable  
> as checking the "this" link?
>
> On Wednesday, June 29, 2005, at 12:10  AM, Mark Nottingham wrote:
>
>
>
>> You need to be able to figure out which documents you've seen  
>> before and which ones you haven't, so you don't recurse down the  
>> entire stack. Although you can come up with some heuristics to  
>> determine when you've seen a document before, most (if not all) of  
>> them can be fooled by particular sequences of entries. Remembering  
>> which ones you've seen (using their 'this' URI) allows you to  
>> easily figure this out.
>>
>>
>> On 28/06/2005, at 8:48 PM, Antone Roundy wrote:
>>
>>
>>
>>
>>> Thinking a little more about this, I'm not sure what the "this"  
>>> link would be used for.  The "prev" link seems to be doing all  
>>> the work, and especially assuming a "batches of 15" sort of  
>>> model, the "this" link seems likely to end up pointing to a  
>>> document that's going to disappear soon 14 times out of 15.
>>>
>>>
>>>
>>
>> --
>> Mark Nottingham     http://www.mnot.net/
>>
>>
>>
>
>
>
>


--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems



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




From owner-atom-syntax@mail.imc.org Wed Jun 29 13:17:33 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DngBp-0007RH-ED
	for atompub-archive@megatron.ietf.org; Wed, 29 Jun 2005 13:17:33 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12869
	for <atompub-archive@lists.ietf.org>; Wed, 29 Jun 2005 13:17:30 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5THA78x047274;
	Wed, 29 Jun 2005 10:10:07 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5THA70k047256;
	Wed, 29 Jun 2005 10:10:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.206])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5THA2jZ047124
	for <atom-syntax@imc.org>; Wed, 29 Jun 2005 10:10:03 -0700 (PDT)
	(envelope-from jasnell@gmail.com)
Received: by rproxy.gmail.com with SMTP id a41so2087978rng
        for <atom-syntax@imc.org>; Wed, 29 Jun 2005 10:10:01 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=LQ9VoAvQasJps7BRExO4q/N2n9Plb5G2KkAk3q/xqgh/Nn9aQOJqdjQ2GGH+8PFRucbPqB0Ek0JoeHCFZXQQExPtyZuYkzQjsq57oc1lmJJmUCD4+VYgyzjwMnCDbEzKruk2g1UjC8kqSLlY6++K6eEIjBxzMUZU8N9VmYgjw5k=
Received: by 10.38.24.68 with SMTP id 68mr1310161rnx;
        Wed, 29 Jun 2005 10:10:00 -0700 (PDT)
Received: from ?192.168.1.103? ([67.181.223.222])
        by mx.gmail.com with ESMTP id k22sm812222rnb.2005.06.29.10.09.59;
        Wed, 29 Jun 2005 10:10:00 -0700 (PDT)
Message-ID: <42C2D5E0.10205@gmail.com>
Date: Wed, 29 Jun 2005 10:09:52 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mark Nottingham <mnot@mnot.net>
CC: Danny Ayers <danny.ayers@gmail.com>, Atom Syntax <atom-syntax@imc.org>
Subject: Re: I-D ACTION:draft-nottingham-atompub-feed-history-00.txt
References: <097CC973-BC19-4838-9076-019A9FD614EC@mnot.net> <1f2ed5cd05062901577845007@mail.gmail.com> <788DD8A0-45CB-4E6F-8E36-B13184D009B7@mnot.net>
In-Reply-To: <788DD8A0-45CB-4E6F-8E36-B13184D009B7@mnot.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


Hey Mark,

A few comments after my first read through on this:

1. This appears to be addressed at solving the same problem as Bob 
Wyman's RFC3229+feed proposal 
[http://bobwyman.pubsub.com/main/2004/09/using_rfc3229_w.html].  Do you 
have any empiracle data similar to what Bob provides @ 
http://bobwyman.pubsub.com/main/2004/10/massive_bandwid.html that would 
indicate that your approach is a better solution to this problem?  These 
are actually not mutually exclusive solutions, they're just different 
and could be used for different scenarios -- e.g. Bob's tends to make a 
lot of sense for blog dashboard feeds like what we use within IBM to 
show all post and commenting activity within our internal blogs server 
while your mechanism would work rather well for things like Top Ten 
lists, etc.  I would just like to see a bit of a compare/contrast on the 
two approaches.

2. Is the feed state mechanism a way of paging through the current 
contents of a collection or a snapshot-in-time view of a feed?  That is...

    is it

        A) Collection has a bunch of entries.  Each feed representation 
has 15 entries and the prev link
             acts like a paging mechanism similar to what we see 
currently use in search results.  Deleting
             the first ten entries out of the collection would cause all 
of the entries in the feed to "shift backwards"
             in the feeds

         B) Each prev link is representative of how the feed looked at a 
given point in time.  E.g. the feed as it would
              have appeared at a given hour of a given day

    If it's A, then Bob's RFC3229+feed solution seems much more 
efficient. (see #1)

    If it's B, then I'm wondering why you don't just use an ETag based 
approach, e.g.

       <fs:Stateful>1</fs:Stateful>
       <fs:prev>{ETag}</fs:prev>

    This would allow clients to only ever have to deal with a single URI 
for a feed and use conditional-gets with ETag to differentiate which 
snapshot of the feed they want to get and would likely make it easier to 
remediate potential recursive reference attacks, (e.g. feed A references 
feed B which references feed C which is a blind redirect to Feed A).

3. Microsoft's RSS Lists spec uses <cf:treatAs /> to attach behavioral 
semantics to a feed.  This proposal uses <fs:Stateful /> to attach 
behavioral semantics.  It would be nice if we could come up with a 
relatively simple and standardizable way of attaching behavioral 
semantics.  For example, a standardized <treatAs /> element:

    <atomex:treatAs>stateful</atomex:treatAs>

    The value of the treatAs element would be a list of tokens with 
defined semantics.  Each token SHOULD be registered with IANA.  Unknown 
tokens would be ignored.  Incompatible tokens would be ignored with  
first-in-the-list takes precedence semantics. For example:

    <atomex:treatAs>stateful list</atomex:treatAs>

    Indicates that the feed should be treated as a list whose past 
states can be queried using the kind of mechanism you've defined.

- James


Mark Nottingham wrote:

>
> Hi Danny,
>
> Thanks for the comments.
>
> On 29/06/2005, at 1:57 AM, Danny Ayers wrote:
>
>>
>> Trivial: might 1/0 be confusing compared to something clearly binary:
>> true/false or yes/no, and difficult to extend: true/false/unknown
>
>
> ack
>
>> What is the Stateful nature of a feed *without* a Stateful element,
>> the default if you will? (Could be per-case or 'indeterminate', but I
>> think some comment on this would be helpful).
>
>
> Yes, that's the intent; if you don't have a flag, there isn't any  
> information about what it is (or isn't), and you act as you would today.
>
>>  If you're talking about feed reconstruction, might it not make sense
>> to have something like an "all" (which could appear as a minimal list
>> of dated URIs of entries) to avoid countless GET/interpret cycles?
>
>
> I put that forth in the original Pace <http://www.intertwingly.net/ 
> wiki/pie/PaceFeedState> (see history), and it got very negative  
> reviews, because it requires a lot of work to maintain, and can be a  
> bandwidth hog. I'm of two minds about it.
>
> -- 
> Mark Nottingham     http://www.mnot.net/
>
>




From owner-atom-syntax@mail.imc.org Wed Jun 29 15:58:30 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dniha-0006Ta-7K
	for atompub-archive@megatron.ietf.org; Wed, 29 Jun 2005 15:58:30 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06622
	for <atompub-archive@lists.ietf.org>; Wed, 29 Jun 2005 15:58:27 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5TJlPDa019176;
	Wed, 29 Jun 2005 12:47:25 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5TJlPlc019175;
	Wed, 29 Jun 2005 12:47:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.207])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5TJlOYq018952
	for <atom-syntax@imc.org>; Wed, 29 Jun 2005 12:47:24 -0700 (PDT)
	(envelope-from jasnell@gmail.com)
Received: by zproxy.gmail.com with SMTP id 40so520691nzk
        for <atom-syntax@imc.org>; Wed, 29 Jun 2005 12:47:18 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=MALw3q947KuyDeNrakDNi1iLBR0sXVCBfgSsQ7Y0as3jd3XUc8I78t0Go6GnJGgG4QKRnGJJIiMhkg05uiJL/WKrT9YvYvGA1rJjUA2dWQnoq4Bljc9dYK54jDMHAxOZuPEWNyipTKdeBWhl2mXTaWoVEGPEFDszUXPxUaBkhw8=
Received: by 10.36.50.11 with SMTP id x11mr4577533nzx;
        Wed, 29 Jun 2005 12:47:18 -0700 (PDT)
Received: from ?192.168.1.103? ([67.181.223.222])
        by mx.gmail.com with ESMTP id r9sm8500187nza.2005.06.29.12.47.18;
        Wed, 29 Jun 2005 12:47:18 -0700 (PDT)
Message-ID: <42C2FAC2.4000802@gmail.com>
Date: Wed, 29 Jun 2005 12:47:14 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: atom-syntax@imc.org
Subject: Re: More on Atom XML signatures and encryption
References: <20050622152507.3CE73724A2C@mail.pubsub.com>
In-Reply-To: <20050622152507.3CE73724A2C@mail.pubsub.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


Ok, I've been going back through all of the discussion on this thread 
and use scenarios, etc and should have an I-D ready for this by this 
weekend.  Here's the summary (in no particular order)

1. After going through a bunch of potential XML encryption use cases, it 
really doesn't seem to make any sense at all to use XML Encryption below 
the document element level.  The I-D will not cover anything about 
encryption of Atom documents as there are really no special 
considerations that are specific to Atom.

2. The I-D will allow a KeyInfo element to included as a child of the 
atom:feed, atom:entry and atom:source elements.  These will be used to 
identify the signing key. (e.g. the KeyInfo in the Signature can 
reference another KeyInfo contained elsewhere in the Feed).

3. When signing complete Atom documents (atom:feed and top level 
atom:entry), Inclusive Canonicalization with no pre-c14n normalization 
is required.

4. The signature should cover the signing key. (e.g. if a x509 cert 
stored externally from the feed is used, the Signature should reference 
and cover that x509 cert).  Failing to do so opens up a security risk.

5. When signing individual atom:entry elements within a feed, Exclusive 
Canonicalization MUST be used.  If a separate KeyInfo is used to 
identify the signing key, it MUST be contained as either a child of the 
entry or source elements.  A source element SHOULD be included in the 
entry. 

6. If an entry contains any "enclosure" links, the digital signature 
SHOULD cover the referenced resources.  Enclosure links that are not 
covered are considered untrusted and pose a potential security risk

7. If an entry contains a content element that uses @src, the digital 
signature MUST cover the referenced resource.

8. Aggregators and Intermediaries MUST NOT alter/augment the content of 
digitally signed entry elements.

9. In addition to serving as a message authenticator, the Signature may 
be used by implementations to assert that potentially untrustworthy 
content within a feed can be trusted (e.g. binary enclosures, scripts, etc)

10. The I-D will not introduce any new elements or attributes

11. Certain types of [X]HTML content will be forbidden in unsigned 
feeds. e.g. <frameset>, <frame>, <script>, <link>, <style>, <object>, 
<embed>, <meta>, etc.  Even in feeds signed with trusted keys, 
aggregators should handle these with care.  (ref: 
http://diveintomark.org/archives/2003/06/12/how_to_consume_rss_safely).

Like I said, I'll be trying to have the draft put together by this 
weekend. 

- James




From owner-atom-syntax@mail.imc.org Wed Jun 29 16:26:07 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dnj8J-0008FB-CO
	for atompub-archive@megatron.ietf.org; Wed, 29 Jun 2005 16:26:07 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19353
	for <atompub-archive@lists.ietf.org>; Wed, 29 Jun 2005 16:26:04 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5TKHRZi041469;
	Wed, 29 Jun 2005 13:17:27 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5TKHRwZ041468;
	Wed, 29 Jun 2005 13:17:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5TKHQ1p041393
	for <atom-syntax@imc.org>; Wed, 29 Jun 2005 13:17:27 -0700 (PDT)
	(envelope-from antone@geckotribe.com)
Received: from geckotribe.com (c-67-169-250-63.hsd1.ut.comcast.net[67.169.250.63])
          by comcast.net (rwcrmhc13) with SMTP
          id <2005062920172001500brfj0e>; Wed, 29 Jun 2005 20:17:20 +0000
Date: Wed, 29 Jun 2005 14:17:19 -0600
Subject: Annotating signed entries (was Re: More on Atom XML signatures and encryption)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v553)
From: Antone Roundy <antone@geckotribe.com>
To: atom-syntax@imc.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <42C2FAC2.4000802@gmail.com>
Message-Id: <CB1BBEDC-E8DA-11D9-9869-003065EA6144@geckotribe.com>
X-Mailer: Apple Mail (2.553)
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: 7bit


On Wednesday, June 29, 2005, at 01:47  PM, James M Snell wrote:
> 8. Aggregators and Intermediaries MUST NOT alter/augment the content 
> of digitally signed entry elements.
>
Just mulling over things...

Obviously, we don't have any way to annotate signed entries without 
breaking the signature.  I hesitate to introduce new complexity, so I 
don't know whether I LIKE the idea I'm about to write about, but here 
it is.  If you want to annotate a signed entry, or even annotate an 
unsigned one but keep your annotations separate, you might do something 
like this:

<feed ... >
	[feed metadata]
	<ex:annotation entry-id="foo">
		<ex:entry-signature>the entry's signature goes 
here</ex:entry-signature>
		[this annotation could be signed here]
		<ex:some-annotation-element>...</ex:some-annotation-element>
		...
	</ex:annotation>
	...
	<entry>
		<id>foo</id>
		[entry's signature here if signed]
		...
	</entry>
</feed>

Notes:
1) <ex:entry-signature> is optional, but recommended if the entry is 
signed and the annotation is signed.
2) Multiple annotations could point to the same entry
3) It could be requested that aggregators forward annotations along 
with their entries...but of course, that's optional, and they could 
certainly be dropped at the request of the end user if they only want 
to see the originals.
4) It might be recommended or required that <ex:annotation> elements 
appear before the entries they annotate (whether above all entries or 
interspersed with them) to make life easier for processors that 
finalize their processing of entries as soon as they hit </entry> 
rather than doing it after they've parsed the whole document.
5) Aggregators COULD attach annotations from various sources when 
outputting entries, even if those annotations never appeared together 
within a feed before.
6) I don't see any way to choose between conflicting annotations.




From owner-atom-syntax@mail.imc.org Wed Jun 29 16:33:07 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DnjF4-0007I2-Vs
	for atompub-archive@megatron.ietf.org; Wed, 29 Jun 2005 16:33:07 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21919
	for <atompub-archive@lists.ietf.org>; Wed, 29 Jun 2005 16:33:04 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5TKRXHY052813;
	Wed, 29 Jun 2005 13:27:33 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5TKRWNi052790;
	Wed, 29 Jun 2005 13:27:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.201])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5TKRUAB052617
	for <atom-syntax@imc.org>; Wed, 29 Jun 2005 13:27:30 -0700 (PDT)
	(envelope-from jasnell@gmail.com)
Received: by zproxy.gmail.com with SMTP id z31so618966nzd
        for <atom-syntax@imc.org>; Wed, 29 Jun 2005 13:27:25 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=M3I8Ag3Cyf5gTVk0oa1DUp/C0fcpuxSFDxv0n07DNpV6TwgZtyi/vOxdI00nqTeYsDYbVv28P1/d9WVeLFTfRnrzUTrW+EJ/oUM+JySys9IzBxhnco8b8M8aL8XJLUdRZa6rXJY1QrtaAikfK0U0ennxgMAKVjR0wG9Al16d1gg=
Received: by 10.36.222.5 with SMTP id u5mr5633346nzg;
        Wed, 29 Jun 2005 13:27:25 -0700 (PDT)
Received: from ?192.168.1.103? ([67.181.223.222])
        by mx.gmail.com with ESMTP id 8sm4591nzn.2005.06.29.13.27.17;
        Wed, 29 Jun 2005 13:27:25 -0700 (PDT)
Message-ID: <42C30421.4050507@gmail.com>
Date: Wed, 29 Jun 2005 13:27:13 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Antone Roundy <antone@geckotribe.com>
CC: atom-syntax@imc.org
Subject: Re: Annotating signed entries (was Re: More on Atom XML signatures
 and encryption)
References: <CB1BBEDC-E8DA-11D9-9869-003065EA6144@geckotribe.com>
In-Reply-To: <CB1BBEDC-E8DA-11D9-9869-003065EA6144@geckotribe.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


Another possible alternative approach would be to have signed entries 
include a special container for metadata additions that is expressly not 
covered by the Signature via a Transform. (the name "annotations" for 
the tag is just a strawman for discussion purposes)

e.g.

<entry>
   <annotations xmlns="...">
   </annotations>
   <Signature>
      <!-- enveloped signature transform + transform that excludes any 
child <annotation xmlns="..." elements />
   </Signature>
</entry>

I'm still thinking through this.

- James


Antone Roundy wrote:

>
> On Wednesday, June 29, 2005, at 01:47  PM, James M Snell wrote:
>
>> 8. Aggregators and Intermediaries MUST NOT alter/augment the content 
>> of digitally signed entry elements.
>>
> Just mulling over things...
>
> Obviously, we don't have any way to annotate signed entries without 
> breaking the signature.  I hesitate to introduce new complexity, so I 
> don't know whether I LIKE the idea I'm about to write about, but here 
> it is.  If you want to annotate a signed entry, or even annotate an 
> unsigned one but keep your annotations separate, you might do 
> something like this:
>
> <feed ... >
>     [feed metadata]
>     <ex:annotation entry-id="foo">
>         <ex:entry-signature>the entry's signature goes 
> here</ex:entry-signature>
>         [this annotation could be signed here]
>         <ex:some-annotation-element>...</ex:some-annotation-element>
>         ...
>     </ex:annotation>
>     ...
>     <entry>
>         <id>foo</id>
>         [entry's signature here if signed]
>         ...
>     </entry>
> </feed>
>
> Notes:
> 1) <ex:entry-signature> is optional, but recommended if the entry is 
> signed and the annotation is signed.
> 2) Multiple annotations could point to the same entry
> 3) It could be requested that aggregators forward annotations along 
> with their entries...but of course, that's optional, and they could 
> certainly be dropped at the request of the end user if they only want 
> to see the originals.
> 4) It might be recommended or required that <ex:annotation> elements 
> appear before the entries they annotate (whether above all entries or 
> interspersed with them) to make life easier for processors that 
> finalize their processing of entries as soon as they hit </entry> 
> rather than doing it after they've parsed the whole document.
> 5) Aggregators COULD attach annotations from various sources when 
> outputting entries, even if those annotations never appeared together 
> within a feed before.
> 6) I don't see any way to choose between conflicting annotations.
>
>




From owner-atom-syntax@mail.imc.org Wed Jun 29 16:56:42 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dnjbr-0003Xw-B4
	for atompub-archive@megatron.ietf.org; Wed, 29 Jun 2005 16:56:39 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24832
	for <atompub-archive@lists.ietf.org>; Wed, 29 Jun 2005 16:56:36 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5TKj14R071589;
	Wed, 29 Jun 2005 13:45:01 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5TKj1jK071588;
	Wed, 29 Jun 2005 13:45:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5TKj1j0071523
	for <atom-syntax@imc.org>; Wed, 29 Jun 2005 13:45:01 -0700 (PDT)
	(envelope-from antone@geckotribe.com)
Received: from geckotribe.com (c-67-169-250-63.hsd1.ut.comcast.net[67.169.250.63])
          by comcast.net (sccrmhc12) with SMTP
          id <2005062920445501200h92nge>; Wed, 29 Jun 2005 20:44:55 +0000
Date: Wed, 29 Jun 2005 14:44:53 -0600
Mime-Version: 1.0 (Apple Message framework v553)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Subject: Dealing with namespace prefixes when syndicating signed entries
From: Antone Roundy <antone@geckotribe.com>
To: atom-syntax@imc.org
Content-Transfer-Encoding: 7bit
Message-Id: <A4FDF1B6-E8DE-11D9-9869-003065EA6144@geckotribe.com>
X-Mailer: Apple Mail (2.553)
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: 7bit


Mulling more...

Let's say an aggregator is putting these two entries into the same 
aggregate feed:

<feed ... xmlns:a="foo" xmlns:b="bar">
	...
	<entry>
		[signature]
		<a:foo ... />
		<b:bar ... />
		...
	</entry>
</feed>

<feed ... xmlns:b="foo" xmlns:a="bar">
	...
	<entry>
		[signature]
		<b:foo ... />
		<a:bar ... />
		...
	</entry>
</feed>

Perhaps a reasonable way to deal with the namespace prefix conflict 
would be for the signature to be applied after a transform that yielded 
this (putting full namespace names in where the prefixes were):

	<[atom's namespace]:entry>
		[signature]
		<foo:foo ... />
		<bar:bar ... />
		...
	</[atom's namespace]:entry>

Unprefixed attributes would naturally remain unprefixed, but elements 
in the default namespace would need to have their namespace names 
prepended.




From owner-atom-syntax@mail.imc.org Wed Jun 29 19:18:51 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DnlpT-0002pG-Ij
	for atompub-archive@megatron.ietf.org; Wed, 29 Jun 2005 19:18:51 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09052
	for <atompub-archive@lists.ietf.org>; Wed, 29 Jun 2005 19:18:48 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5TNADnX029219;
	Wed, 29 Jun 2005 16:10:13 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5TNACdi029172;
	Wed, 29 Jun 2005 16:10:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.192])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5TNA8rm028932
	for <atom-syntax@imc.org>; Wed, 29 Jun 2005 16:10:08 -0700 (PDT)
	(envelope-from jasnell@gmail.com)
Received: by zproxy.gmail.com with SMTP id q3so1570nzb
        for <atom-syntax@imc.org>; Wed, 29 Jun 2005 16:10:01 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=ja9krS93wHCOhZH29Vp7H6qCN3wZXagrH4o0XK0ajmqCsC0frxuMZlWQSwzzTK3NS7EFYXRUDx8Udj5qSlVEBLebazfg9REdatSDmdKLcdsCfBJYa9mNxnBigeuvpsNArqq5l4mrsjTg3d8E/Veohi310ieupzzh8GzioV2Y3E0=
Received: by 10.36.50.18 with SMTP id x18mr59390nzx;
        Wed, 29 Jun 2005 16:10:01 -0700 (PDT)
Received: from ?192.168.1.103? ([67.181.223.222])
        by mx.gmail.com with ESMTP id 12sm19832nzn.2005.06.29.16.10.01;
        Wed, 29 Jun 2005 16:10:01 -0700 (PDT)
Message-ID: <42C32A45.4000805@gmail.com>
Date: Wed, 29 Jun 2005 16:09:57 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Antone Roundy <antone@geckotribe.com>
CC: atom-syntax@imc.org
Subject: Re: Dealing with namespace prefixes when syndicating signed entries
References: <A4FDF1B6-E8DE-11D9-9869-003065EA6144@geckotribe.com>
In-Reply-To: <A4FDF1B6-E8DE-11D9-9869-003065EA6144@geckotribe.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


After digging through things a bit I *believe* the Exclusive 
Canonicalization spec handles this.  It was designed to allow a chunk of 
signed XML to be portable from one containing element to another.  
http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/ 

Antone Roundy wrote:

>
> Mulling more...
>
> Let's say an aggregator is putting these two entries into the same 
> aggregate feed:
>
> <feed ... xmlns:a="foo" xmlns:b="bar">
>     ...
>     <entry>
>         [signature]
>         <a:foo ... />
>         <b:bar ... />
>         ...
>     </entry>
> </feed>
>
> <feed ... xmlns:b="foo" xmlns:a="bar">
>     ...
>     <entry>
>         [signature]
>         <b:foo ... />
>         <a:bar ... />
>         ...
>     </entry>
> </feed>
>
> Perhaps a reasonable way to deal with the namespace prefix conflict 
> would be for the signature to be applied after a transform that 
> yielded this (putting full namespace names in where the prefixes were):
>
>     <[atom's namespace]:entry>
>         [signature]
>         <foo:foo ... />
>         <bar:bar ... />
>         ...
>     </[atom's namespace]:entry>
>
> Unprefixed attributes would naturally remain unprefixed, but elements 
> in the default namespace would need to have their namespace names 
> prepended.
>
>




From owner-atom-syntax@mail.imc.org Wed Jun 29 20:53:15 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DnnIn-0005Z9-KA
	for atompub-archive@megatron.ietf.org; Wed, 29 Jun 2005 20:53:15 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20540
	for <atompub-archive@lists.ietf.org>; Wed, 29 Jun 2005 20:53:11 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5U0jusd024456;
	Wed, 29 Jun 2005 17:45:56 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5U0juPW024455;
	Wed, 29 Jun 2005 17:45:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.gmx.net (pop.gmx.de [213.165.64.20])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j5U0jsaV024387
	for <atom-syntax@imc.org>; Wed, 29 Jun 2005 17:45:55 -0700 (PDT)
	(envelope-from pagaltzis@gmx.de)
Received: (qmail invoked by alias); 30 Jun 2005 00:45:48 -0000
Received: from xdsl-213-196-245-105.netcologne.de (EHLO klangraum) [213.196.245.105]
  by mail.gmx.net (mp028) with SMTP; 30 Jun 2005 02:45:48 +0200
X-Authenticated: #163624
Date: Thu, 30 Jun 2005 02:50:23 +0200
From: "A. Pagaltzis" <pagaltzis@gmx.de>
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: FWD: I-D ACTION:draft-nottingham-atompub-feed-history-00.txt
Message-ID: <20050630005023.GA1281@klangraum>
Mail-Followup-To: Atom Syntax <atom-syntax@imc.org>
References: <097CC973-BC19-4838-9076-019A9FD614EC@mnot.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <097CC973-BC19-4838-9076-019A9FD614EC@mnot.net>
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 ietf.org id UAA20540


Hi Mark,

* Mark Nottingham <mnot@mnot.net> [2005-06-28 22:40]:
>    This document specifies mechanisms that allow feed
>    publishers to  give hints about the nature of the feed's
>    statefulness, and a means of retrieving ^missed^ entries
>    from a stateful feed.

I agree with Antone Roundy that the =E2=80=9Cthis=E2=80=9D link is unnces=
sary
for the reasons already stated.

My first thought upon reading the draft was what I assume is
what Stefan Eissing said: I would rather have a single,
entry-less =E2=80=9Carchive hub=E2=80=9D feed which contains =E2=80=9Cpre=
v=E2=80=9D links to
*all* previous instances, leading to a setup like

    http://example.com/latest
    =E2=94=94=E2=94=80> http://example.com/archive/feed/
        =E2=94=9C=E2=94=80> http://example.com/archive/feed/2005/05/
        =E2=94=9C=E2=94=80> http://example.com/archive/feed/2005/04/
        =E2=94=9C=E2=94=80> http://example.com/archive/feed/2005/03/
        =E2=94=9C=E2=94=80> http://example.com/archive/feed/2005/02/
        =E2=94=94=E2=94=80> http://example.com/archive/feed/2005/01/=20

so that it=E2=80=99s only necessary for the aggregator to fetch one
document to find out about all previous versions. It seems
cleaner and more robust to keep a global history list, rather
than encoding it implicitly as a chain of documents.

I don=E2=80=99t see anything in the draft that would preclude this use,
and as far as I can tell, aggregators which support the draft
should have no trouble handling this scenario correctly. Is it
acceptable, or did you intend to outlaw it? If yes, what is the
reasoning?

In fact, I=E2=80=99d probably go one step further and add a =E2=80=9Cprev=
=E2=80=9D
link to each version, which points back to the archive list
feed.

    http://example.com/latest
    =E2=94=94=E2=94=80> http://example.com/archive/feed/ <=E2=94=80=E2=94=
=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=
=E2=94=80=E2=94=80=E2=94=90
        =E2=94=9C=E2=94=80> http://example.com/archive/feed/2005/05/ =E2=94=
=80=E2=94=A4
        =E2=94=9C=E2=94=80> http://example.com/archive/feed/2005/04/ =E2=94=
=80=E2=94=A4
        =E2=94=9C=E2=94=80> http://example.com/archive/feed/2005/03/ =E2=94=
=80=E2=94=A4
        =E2=94=9C=E2=94=80> http://example.com/archive/feed/2005/02/ =E2=94=
=80=E2=94=A4
        =E2=94=94=E2=94=80> http://example.com/archive/feed/2005/01/ =E2=94=
=80=E2=94=98

In that way, any of the files can be copied around the place,
but they never lose their association with the originals.

Again, I don=E2=80=99t see anything in the draft that would preclude
this use, and as far as I can tell, aggregators which support
the draft should have no trouble handling this scenario
correctly. Is it acceptable, or did you intend to outlaw it? If
yes, what is the reasoning?

Note how the archive directory feed being static makes this
painlessly possible, while it would be a pain to achive
something similar using the paginated approach with local
=E2=80=9Cprev=E2=80=9D links (you=E2=80=99d need to go back and change th=
e previously
newest old version every time a new one was added). It would
in fact require a =E2=80=9Cprev=E2=80=9D link to what is actually the =E2=
=80=9Cnext=E2=80=9D
page.

Funnily enough, I don=E2=80=99t see anything in the draft that would
preclude this counterintuitive use of the =E2=80=9Cprev=E2=80=9D link to =
point
to the =E2=80=9Cnext=E2=80=9D version, and as far as I can tell, aggregat=
ors
which support the draft [etc]?

Overall, I must say this feels kludgy to me, any way I turn it.
I=E2=80=99d much rather have a single archive feed containing all
entries, and use RFC3229+feed to return partial versions of it;
as far as I can tell, this is a use case which your draft does
*NOT* allow. Is that so?

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




From owner-atom-syntax@mail.imc.org Wed Jun 29 21:24:07 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dnnmh-0000rT-Ay
	for atompub-archive@megatron.ietf.org; Wed, 29 Jun 2005 21:24:07 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22740
	for <atompub-archive@lists.ietf.org>; Wed, 29 Jun 2005 21:24:05 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5U1EwxW043719;
	Wed, 29 Jun 2005 18:14:58 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5U1EwAZ043718;
	Wed, 29 Jun 2005 18:14:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231])
	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5U1ElJF043610;
	Wed, 29 Jun 2005 18:14:48 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: <p06230932bee8f2a4e9cd@[10.20.30.249]>
In-Reply-To: <42C2FAC2.4000802@gmail.com>
References: <20050622152507.3CE73724A2C@mail.pubsub.com>
 <42C2FAC2.4000802@gmail.com>
Date: Wed, 29 Jun 2005 18:14:27 -0700
To: James M Snell <jasnell@gmail.com>, atom-syntax@imc.org
From: Paul Hoffman <phoffman@imc.org>
Subject: Re: More on Atom XML signatures and 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>


At 12:47 PM -0700 6/29/05, James M Snell wrote:
>1. After going through a bunch of potential XML encryption use 
>cases, it really doesn't seem to make any sense at all to use XML 
>Encryption below the document element level.  The I-D will not cover 
>anything about encryption of Atom documents as there are really no 
>special considerations that are specific to Atom.

Good.

>2. The I-D will allow a KeyInfo element to included as a child of 
>the atom:feed, atom:entry and atom:source elements.  These will be 
>used to identify the signing key. (e.g. the KeyInfo in the Signature 
>can reference another KeyInfo contained elsewhere in the Feed).

This is OK from a security standpoint, but why have it? Why not 
always have the signature contain all the validating information?

>3. When signing complete Atom documents (atom:feed and top level 
>atom:entry), Inclusive Canonicalization with no pre-c14n 
>normalization is required.

There seems to be many more interoperability issues with Inclusive 
Canonicalization than with Exclusive. What is your reasoning here?

>4. The signature should cover the signing key. (e.g. if a x509 cert 
>stored externally from the feed is used, the Signature should 
>reference and cover that x509 cert).  Failing to do so opens up a 
>security risk.

Please explain the "security risk". I probably disagree with this 
requirement, but want to hear your risk analysis.

>5. When signing individual atom:entry elements within a feed, 
>Exclusive Canonicalization MUST be used.  If a separate KeyInfo is 
>used to identify the signing key, it MUST be contained as either a 
>child of the entry or source elements.  A source element SHOULD be 
>included in the entry.

Why is this different than #3?

>6. If an entry contains any "enclosure" links, the digital signature 
>SHOULD cover the referenced resources.  Enclosure links that are not 
>covered are considered untrusted and pose a potential security risk

Fully disagree. We are signing the bits in the document, not the 
outside. There is "security risk", those items are simply unsigned.

>7. If an entry contains a content element that uses @src, the 
>digital signature MUST cover the referenced resource.

Fully disagree.

>8. Aggregators and Intermediaries MUST NOT alter/augment the content 
>of digitally signed entry elements.

Also disagree, but for a different reason. Aggregators and 
intermediaries should be free to diddle bits if they strip the 
signatures that they have broken.

>9. In addition to serving as a message authenticator, the Signature 
>may be used by implementations to assert that potentially 
>untrustworthy content within a feed can be trusted (e.g. binary 
>enclosures, scripts, etc)

How will you assert that?

>10. The I-D will not introduce any new elements or attributes

Thank you!

>11. Certain types of [X]HTML content will be forbidden in unsigned 
>feeds. e.g. <frameset>, <frame>, <script>, <link>, <style>, 
><object>, <embed>, <meta>, etc.  Even in feeds signed with trusted 
>keys, aggregators should handle these with care.  (ref: 
>http://diveintomark.org/archives/2003/06/12/how_to_consume_rss_safely).

Disagree, for the same reasons as above. We are signing the bits 
only, not some representation of the universe at the time of signing.

>Like I said, I'll be trying to have the draft put together by this weekend.

Hopefully, my comments above cause you to put discussion of your 
reasoning in there. Please don't read my comments as "don't do this", 
but rather "if you're going to do this, you have to justify it". That 
will make the document stronger and more likely to be implemented 
properly.

--Paul Hoffman, Director
--Internet Mail Consortium




From owner-atom-syntax@mail.imc.org Wed Jun 29 22:04:46 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DnoQ2-0007CU-65
	for atompub-archive@megatron.ietf.org; Wed, 29 Jun 2005 22:04:46 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25690
	for <atompub-archive@lists.ietf.org>; Wed, 29 Jun 2005 22:04:43 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5U1sNX9066465;
	Wed, 29 Jun 2005 18:54:23 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5U1sNkP066464;
	Wed, 29 Jun 2005 18:54:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from rwcrmhc14.comcast.net (rwcrmhc14.comcast.net [216.148.227.89])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5U1sNKE066432
	for <atom-syntax@imc.org>; Wed, 29 Jun 2005 18:54:23 -0700 (PDT)
	(envelope-from antone@geckotribe.com)
Received: from geckotribe.com (c-67-169-250-63.hsd1.ut.comcast.net[67.169.250.63])
          by comcast.net (rwcrmhc14) with SMTP
          id <2005063001541801400ma8i7e>; Thu, 30 Jun 2005 01:54:18 +0000
Date: Wed, 29 Jun 2005 19:54:16 -0600
Subject: Re: I-D ACTION:draft-nottingham-atompub-feed-history-00.txt
Content-Type: text/plain; charset=ISO-2022-JP; format=flowed
Mime-Version: 1.0 (Apple Message framework v553)
From: Antone Roundy <antone@geckotribe.com>
To: atom-syntax@imc.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <20050630005023.GA1281@klangraum>
Message-Id: <DDB2762A-E909-11D9-9869-003065EA6144@geckotribe.com>
X-Mailer: Apple Mail (2.553)
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: 7bit


On Wednesday, June 29, 2005, at 06:50  PM, A. Pagaltzis wrote:
> My first thought upon reading the draft was what I assume is
> what Stefan Eissing said: I would rather have a single,
> entry-less $B!H(Barchive hub$B!I(B feed which contains $B!H(Bprev$B!I(B links to
> *all* previous instances
For an active feed, that document could easily grow till it was larger 
than many feed instances.  I prefer the chain of instances method.

> , leading to a setup like
>
>     http://example.com/latest
>     $B(&(!(B> http://example.com/archive/feed/
>         $B('(!(B> http://example.com/archive/feed/2005/05/
>         $B('(!(B> http://example.com/archive/feed/2005/04/
>         $B('(!(B> http://example.com/archive/feed/2005/03/
>         $B('(!(B> http://example.com/archive/feed/2005/02/
>         $B(&(!(B> http://example.com/archive/feed/2005/01/
I don't quite get what the "hub feed" would look like.  Could you show 
us some XML?

> I don$B!G(Bt see anything in the draft that would preclude this use,
> and as far as I can tell, aggregators which support the draft
> should have no trouble handling this scenario correctly.
The draft doesn't explicitly say that a feed can only contain one 
"prev" link, but I find it hard to read "a" to mean "one or more" in 
'and optionally a Link element with the relation "prev"'.

> Again, I don$B!G(Bt see anything in the draft that would preclude
> this use, and as far as I can tell, aggregators which support
> the draft should have no trouble handling this scenario
> correctly.
...unless they expected only to find one "prev" link per document.

> Note how the archive directory feed being static makes this
> painlessly possible, while it would be a pain to achive
> something similar using the paginated approach with local
> $B!H(Bprev$B!I(B links (you$B!G(Bd need to go back and change the previously
> newest old version every time a new one was added).
I don't see why this would be any more difficult.  The paginated 
approach could easily use static documents that never need to be 
updated, as I described earlier.  I'll re-explain at the end of this 
email.

> It would in fact require a $B!H(Bprev$B!I(B link to what is actually the $B!H(Bnext$B!I(B
> page.
>
> Funnily enough, I don$B!G(Bt see anything in the draft that would
> preclude this counterintuitive use of the $B!H(Bprev$B!I(B link to point
> to the $B!H(Bnext$B!I(B version
Could you explain what you mean by that?

> I$B!G(Bd much rather have a single archive feed containing all
> entries, and use RFC3229+feed to return partial versions of it;
That might be good for those who can support it, but many people won't 
be able to.  On the other hand, if that single feed grows to where it's 
hundreds of MB, it could cause real problems if someone requests the 
whole thing or a large portion of it.


Getting back to how to use static documents for a chain of instances, 
that could easily be done as follows. The following assumes that the 
current feed document and the archive documents will each contain 15 
entries.

The first 15 instances of the feed document do not contain a "prev" 
link (assuming one entry is added each time).

When the 16th entry is added, a static document is created containing 
the first 15 entries, and a "prev" link pointing to it is added to the 
current feed document. This link remains unchanged until the 31st entry 
is added.

When the 31st entry is added, another static document is created 
containing the 16th through 30th entries. It has a prev link pointing 
to the first static document. The current feed document's prev link is 
updated to point to the second static document, and it continues to 
point to the second static document until the 46th entry is added.

When the 46th entry is added, a third static document is created 
containing the 31st through 45th entries, etc.

If you want to reduce the number of requests required to get the entire 
history (which I don't imagine would happen often enough that it would 
necessary be worth bothering), you could put more entries into each 
static document.  If you didn't correspondingly increase the number of 
entries in the current feed document, you'd have to update the most 
recent static document a number of times rather than only outputting it 
once as described above, but even that would only require multiple 
updates to the most recent static document at any time.




From owner-atom-syntax@mail.imc.org Wed Jun 29 22:40:00 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dnoy8-0001xw-2i
	for atompub-archive@megatron.ietf.org; Wed, 29 Jun 2005 22:40:00 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28002
	for <atompub-archive@lists.ietf.org>; Wed, 29 Jun 2005 22:39:57 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5U2VErw090023;
	Wed, 29 Jun 2005 19:31:14 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5U2VE1g090022;
	Wed, 29 Jun 2005 19:31:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail07.svc.cra.dublin.eircom.net (mail07.svc.cra.dublin.eircom.net [159.134.118.23])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j5U2VD9p090009
	for <atom-syntax@imc.org>; Wed, 29 Jun 2005 19:31:14 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 69840 messnum 2891438 invoked from network[83.70.29.246/83-70-29-246.b-ras1.prp.dublin.eircom.net]); 30 Jun 2005 02:31:07 -0000
Received: from 83-70-29-246.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.29.246)
  by mail07.svc.cra.dublin.eircom.net (qp 69840) with SMTP; 30 Jun 2005 02:31:07 -0000
Message-ID: <42C35967.7030903@dehora.net>
Date: Thu, 30 Jun 2005 03:31:03 +0100
From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Antone Roundy <antone@geckotribe.com>
CC: atom-syntax@imc.org
Subject: Re: Dealing with namespace prefixes when syndicating signed entries
References: <A4FDF1B6-E8DE-11D9-9869-003065EA6144@geckotribe.com>
In-Reply-To: <A4FDF1B6-E8DE-11D9-9869-003065EA6144@geckotribe.com>
X-Enigmail-Version: 0.92.0.0
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>
Content-Transfer-Encoding: 7bit


Antone Roundy wrote:

> [...]
> Perhaps a reasonable way to deal with the namespace prefix conflict
> would be for the signature to be applied after a transform that yielded
> this (putting full namespace names in where the prefixes were):
> [...]

ex-c14n is where to deal with this - it's a necessary preprocessing step
to dsigging XML and walks the line between the Infoset and bytewise
needs. IIRC it can result in moving the namespace declarations around.

cheers
Bill





From owner-atom-syntax@mail.imc.org Wed Jun 29 23:13:08 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DnpUB-0004HL-Ji
	for atompub-archive@megatron.ietf.org; Wed, 29 Jun 2005 23:13:08 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00912
	for <atompub-archive@lists.ietf.org>; Wed, 29 Jun 2005 23:13:04 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5U326CL005464;
	Wed, 29 Jun 2005 20:02:06 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5U3269c005463;
	Wed, 29 Jun 2005 20:02:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.25])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5U322AS005430
	for <atom-syntax@imc.org>; Wed, 29 Jun 2005 20:02:05 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Thu, 30 Jun 2005 13:02:35 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Thu, 30 Jun 2005 13:01:55 +1000
Subject: Re: I-D ACTION:draft-nottingham-atompub-feed-history-00.txt
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BEE99DC3.611C2%eric.scheid@ironclad.net.au>
In-Reply-To: <DDB2762A-E909-11D9-9869-003065EA6144@geckotribe.com>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j5U325AS005457
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 ietf.org id XAA00912


On 30/6/05 11:54 AM, "Antone Roundy" <antone@geckotribe.com> wrote:

>> I=B9d much rather have a single archive feed containing all
>> entries, and use RFC3229+feed to return partial versions of it;
> That might be good for those who can support it, but many people won't
> be able to.  On the other hand, if that single feed grows to where it's
> hundreds of MB, it could cause real problems if someone requests the
> whole thing or a large portion of it.

also, how can RFC3229+feed provide subsets where one end isn't tied to th=
e
most recent entry?

e.





From owner-atom-syntax@mail.imc.org Wed Jun 29 23:19:05 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DnpZx-0006fX-51
	for atompub-archive@megatron.ietf.org; Wed, 29 Jun 2005 23:19:05 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01265
	for <atompub-archive@lists.ietf.org>; Wed, 29 Jun 2005 23:19:02 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5U3BGUq010123;
	Wed, 29 Jun 2005 20:11:16 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5U3BG8U010122;
	Wed, 29 Jun 2005 20:11:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.25])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5U3BETg010104
	for <atom-syntax@imc.org>; Wed, 29 Jun 2005 20:11:15 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Thu, 30 Jun 2005 13:11:52 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Thu, 30 Jun 2005 13:00:02 +1000
Subject: Re: I-D ACTION:draft-nottingham-atompub-feed-history-00.txt
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BEE99D52.611C1%eric.scheid@ironclad.net.au>
In-Reply-To: <DDB2762A-E909-11D9-9869-003065EA6144@geckotribe.com>
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>
Content-Transfer-Encoding: 7bit


On 30/6/05 11:54 AM, "Antone Roundy" <antone@geckotribe.com> wrote:

> I don't quite get what the "hub feed" would look like.  Could you show
> us some XML?

I think something like this:

<feed>
    ...
    <title>archives hub for x</title>
    <link href="http://example.com/archive/feed/2005/05/"
          type="application/atom+xml"
          rel="prev" />
    <link href="http://example.com/archive/feed/2005/04/"
          type="application/atom+xml"
          rel="prev" />
    <link href="http://example.com/archive/feed/2005/03/"
          type="application/atom+xml"
          rel="prev" />
    <link href="http://example.com/archive/feed/2005/02/"
          type="application/atom+xml"
          rel="prev" />
    <!-- no entries -->
</feed>

... although ... now that I've typed that out ... the semantics of "prev"
are borked.

So maybe something more like this would make better sense

<feed>
    ...
    <entry>
        <id .../>
        <link href="http://example.com/archive/feed/2005/05/"
            type="application/atom+xml"/>
        <title>Archive for 2005/05</title>
        <summary>27 posts</summary>
    </entry>
</feed>

That is: "here is a resource representation providing a list of entries
which are representative of some other resources, not necessarily in
text/html format"

e.




From owner-atom-syntax@mail.imc.org Thu Jun 30 06:14:14 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dnw3i-0002aT-KW
	for atompub-archive@megatron.ietf.org; Thu, 30 Jun 2005 06:14:14 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22338
	for <atompub-archive@lists.ietf.org>; Thu, 30 Jun 2005 06:14:11 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5UA45r8068179;
	Thu, 30 Jun 2005 03:04:05 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5UA44ga068168;
	Thu, 30 Jun 2005 03:04:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtp.cegetel.net (mf00.sitadelle.com [212.94.174.67])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5UA4027068008
	for <atom-syntax@imc.org>; Thu, 30 Jun 2005 03:04:00 -0700 (PDT)
	(envelope-from t.broyer@cegetel.net)
Received: from cegetel.net (217-19-192-103.dti.cegetel.net [217.19.192.103])
	by smtp.cegetel.net (Postfix) with SMTP id 27B181A4338;
	Thu, 30 Jun 2005 12:03:53 +0200 (CEST)
Received: from 82.127.77.43
        (SquirrelMail authenticated user t.broyer@cegetel.net)
        by ssl-webmail.sitadelle.com with HTTP;
        Thu, 30 Jun 2005 12:03:54 +0200 (CEST)
Message-ID: <2768.82.127.77.43.1120125834.squirrel@ssl-webmail.sitadelle.com>
Date: Thu, 30 Jun 2005 12:03:54 +0200 (CEST)
Subject: Re: I-D ACTION:draft-nottingham-atompub-feed-history-00.txt
From: "Thomas Broyer" <t.broyer@cegetel.net>
To: <antone@geckotribe.com>
In-Reply-To: <DDB2762A-E909-11D9-9869-003065EA6144@geckotribe.com>
References: <20050630005023.GA1281@klangraum>
        <DDB2762A-E909-11D9-9869-003065EA6144@geckotribe.com>
X-Priority: 3
Importance: Normal
Cc: <atom-syntax@imc.org>
X-Mailer: SquirrelMail (version 1.2.10)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
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: 8bit



Antone Roundy wrote:
> Getting back to how to use static documents for a chain of instances,
> that could easily be done as follows. The following assumes that the
> current feed document and the archive documents will each contain 15
> entries.
>
> The first 15 instances of the feed document do not contain a "prev"
> link (assuming one entry is added each time).
>
> When the 16th entry is added, a static document is created containing
> the first 15 entries, and a "prev" link pointing to it is added to the
> current feed document. This link remains unchanged until the 31st entry
> is added.
>
> When the 31st entry is added, another static document is created
> containing the 16th through 30th entries. It has a prev link pointing
> to the first static document. The current feed document's prev link is
> updated to point to the second static document, and it continues to
> point to the second static document until the 46th entry is added.
>
> When the 46th entry is added, a third static document is created
> containing the 31st through 45th entries, etc.

However, there should then be a "this" link in the "live" feed, otherwise
I'll have to retrieve (as a reader/aggregator) the "prev" feed each 15
entries:

Say I retrieved the feed when it was 15-entries long. When the 16th entry
is added and the first static document created, the "live" feed is added a
"prev" link, pointing to a document I never retrieved, so I guess I might
have missed entries and retrieve it. I end up retrieving back the 15
entries I already know of.
When the 31st entry is added, the feed's "prev" link is changed to
reference the new 16th-to-31st archive feed. This is an URI I never
dereferenced, so I guess I might have missed some entries and then
dereference the URI and retrieve the archive feed. If I had retrieved the
feed when it was 30-entries long, I end up retrieving back the 16th to
31st entries I already know of.

One could argue that I don't need to retrieve the archive feed as the live
feed already contains 14 entries (2nd to 15th, or 17th to 30th) I already
retrieved, using atom:updated and atom:id to notive them.
Well, nothing precludes an entry to be "pushed to front" even if its
atom:updated hasn't changed, so the entry following such a "puished to
front" entry could be one I never saw and I might have missed it.
And actually, this doesn't otherwise change the problem, which would still
arise if I retrieve the "live" feed when, say, it was 15-entries long and
15 entries later: I never saw the "prev" archive feed or any of the 15
entries in the "live" feed (so I can't conclude anything based on
atom:id+atom:updated), I then retrieve the "-prev" linked archive feed and
end up retrieving 15 entries I already know of, because it happens than I
actually didn't miss any entry between my two "live" feed retrievals...

So we need a mean to either identify the *next* "prev" link (a "this" or
"permalink" link in the "live" feed (no need to have one in "archive"
feeds, as already said on the list), which means it must be predictable),
or something to tell us we didn't missed entries, such as the atom:updated
of the "prev"-linked archive feed (is atom:updated enough?).

We'll end up with the "live" feed being either:
<feed xmlns="..." xmlns:fs="...">
  <link rel="archive" href="http://example.com/2005/05/" />
  <!-- I didn't use a link construct as the document not yet exists) -->
  <fs:predicted-archive-uri>
        http://example.com/2005/06/
  </fs:predicted-archive-uri>
  ...
</feed>

or

<feed xmlns="..." xmlns:fs="...">
  <!-- I used an "extension attribute", even if it's not clearly
       defined by the Atom Syndication Format -->
  <link rel="prev" href="http://example.com/2005/05/"
        fs:updated="2005-05-31T23:59:59" />
  ...
</feed>

One advantage of the latter is that you don't rely on URIs as identifiers
for the feed archive documents and they can be moved/split/merged without
readers and aggregators being then implicitly told to retrieve back the
whole archives (if you change URIs, they'll think they missed entries...).

-- 
Thomas Broyer





From owner-atom-syntax@mail.imc.org Thu Jun 30 15:13:50 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Do4Tu-0008FY-Rg
	for atompub-archive@megatron.ietf.org; Thu, 30 Jun 2005 15:13:50 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13730
	for <atompub-archive@lists.ietf.org>; Thu, 30 Jun 2005 15:13:48 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5UIx0J6053805;
	Thu, 30 Jun 2005 11:59:00 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5UIx08Y053804;
	Thu, 30 Jun 2005 11:59:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.207])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5UIx0NV053725
	for <atom-syntax@imc.org>; Thu, 30 Jun 2005 11:59:00 -0700 (PDT)
	(envelope-from jasnell@gmail.com)
Received: by wproxy.gmail.com with SMTP id i27so136723wra
        for <atom-syntax@imc.org>; Thu, 30 Jun 2005 11:58:54 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=Pf3ooyHCHrct2VfqkiAtlovWWjcL8GUZgemAiy9mjOTRCWo+lb3G0tlRLNf1AW2IrkiBr0nKCxfJ07TXr9hBTV8mc+5fWMC4Zwq9Df5v7VVdNQYTLeqCOMwVfAkezOfBERlWN28DNU5gzHojlfBbxyBzAFlDFheb57d3XqxRA2I=
Received: by 10.54.38.64 with SMTP id l64mr566655wrl;
        Thu, 30 Jun 2005 11:58:54 -0700 (PDT)
Received: from ?192.168.1.103? ([67.181.223.222])
        by mx.gmail.com with ESMTP id g5sm119397wra.2005.06.30.11.58.53;
        Thu, 30 Jun 2005 11:58:54 -0700 (PDT)
Message-ID: <42C440E9.2070700@gmail.com>
Date: Thu, 30 Jun 2005 11:58:49 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Hoffman <phoffman@imc.org>
CC: atom-syntax@imc.org
Subject: Re: More on Atom XML signatures and encryption
References: <20050622152507.3CE73724A2C@mail.pubsub.com> <42C2FAC2.4000802@gmail.com> <p06230932bee8f2a4e9cd@[10.20.30.249]>
In-Reply-To: <p06230932bee8f2a4e9cd@[10.20.30.249]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


Paul Hoffman wrote:

> At 12:47 PM -0700 6/29/05, James M Snell wrote:
>
>> 1. After going through a bunch of potential XML encryption use cases, 
>> it really doesn't seem to make any sense at all to use XML Encryption 
>> below the document element level.  The I-D will not cover anything 
>> about encryption of Atom documents as there are really no special 
>> considerations that are specific to Atom.
>
>
> Good.
>
>> 2. The I-D will allow a KeyInfo element to included as a child of the 
>> atom:feed, atom:entry and atom:source elements.  These will be used 
>> to identify the signing key. (e.g. the KeyInfo in the Signature can 
>> reference another KeyInfo contained elsewhere in the Feed).
>
>
> This is OK from a security standpoint, but why have it? Why not always 
> have the signature contain all the validating information?
>
You know, if you had asked me this when I wrote this requirement down in 
my notes three days ago I would have been able to give you the answer.  
The fact that I'm staring at my screen trying to recall what that answer 
is indicates that it's not a very good one ;-) ... You're right, there 
really is no need to separate the keyinfo from the signature in this 
situation.

>> 3. When signing complete Atom documents (atom:feed and top level 
>> atom:entry), Inclusive Canonicalization with no pre-c14n 
>> normalization is required.
>
>
> There seems to be many more interoperability issues with Inclusive 
> Canonicalization than with Exclusive. What is your reasoning here?
>
Two reasons:
a. No need to re-envelope things at the document level
b. Ignorance on my part as to what all the interoperability issues are.  
Can you elaborate or point me to some relevant discussions?

>> 4. The signature should cover the signing key. (e.g. if a x509 cert 
>> stored externally from the feed is used, the Signature should 
>> reference and cover that x509 cert).  Failing to do so opens up a 
>> security risk.
>
>
> Please explain the "security risk". I probably disagree with this 
> requirement, but want to hear your risk analysis.
>
This is mostly tied to #2 above and comes from a lesson learned from 
WS-Security. Specifically section 13.2.4 of 
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf

    "Implementers should be aware of the possibility of a token 
substitution attack. In any
     situation where a digital signature is verified by reference to a 
token provided in the
     message, which specifies the key, it may be possible for an 
unscrupulous producer
     to later claim that a different token, containing the same key, but 
different information
     was intended."

If we don't verify-by-reference to a key contained elsewhere in the feed 
(or other location), this no longer becomes an issue.

>> 5. When signing individual atom:entry elements within a feed, 
>> Exclusive Canonicalization MUST be used.  If a separate KeyInfo is 
>> used to identify the signing key, it MUST be contained as either a 
>> child of the entry or source elements.  A source element SHOULD be 
>> included in the entry.
>
>
> Why is this different than #3?
>
These entries are subject to re-enveloping in a way that document level 
elements are not. It is possible to use ex-c14n throughout so that the 
behavior is consistent. The KeyInfo statement relates to #2 and thus 
becomes irrelevant.

>> 6. If an entry contains any "enclosure" links, the digital signature 
>> SHOULD cover the referenced resources.  Enclosure links that are not 
>> covered are considered untrusted and pose a potential security risk
>
>
> Fully disagree. We are signing the bits in the document, not the 
> outside. There is "security risk", those items are simply unsigned.
>
I tend to consider enclosures to be part of the document, even if they 
are included by reference.  As a potential consumer of an enclosure I 
want to know whether or not the referenced enclosure can be trusted.  Is 
it accepted to change the SHOULD to a MAY with a caveat outlining the 
security risk?

>> 7. If an entry contains a content element that uses @src, the digital 
>> signature MUST cover the referenced resource.
>
>
> Fully disagree.
>
Same as above.  Even though it is included-by-reference, the referenced 
content is still a part of the message. 

>> 8. Aggregators and Intermediaries MUST NOT alter/augment the content 
>> of digitally signed entry elements.
>
>
> Also disagree, but for a different reason. Aggregators and 
> intermediaries should be free to diddle bits if they strip the 
> signatures that they have broken.
>
Ok, my fault. I wasn't clear.  Reword to "Aggregators and Intermediaries 
MUST NOT alter/augment the content of digitally signed entry elements 
unless they strip the Signature from the entry"

>> 9. In addition to serving as a message authenticator, the Signature 
>> may be used by implementations to assert that potentially 
>> untrustworthy content within a feed can be trusted (e.g. binary 
>> enclosures, scripts, etc)
>
>
> How will you assert that?
>
Not so much a normative assertion.  More of a "if you know who produced 
this feed/entry and you decide that you can trust their signature, you 
can make finer grained decisions about whether or not to trust the 
content". 

>> 10. The I-D will not introduce any new elements or attributes
>
>
> Thank you!
>
;-)

>> 11. Certain types of [X]HTML content will be forbidden in unsigned 
>> feeds. e.g. <frameset>, <frame>, <script>, <link>, <style>, <object>, 
>> <embed>, <meta>, etc.  Even in feeds signed with trusted keys, 
>> aggregators should handle these with care.  (ref: 
>> http://diveintomark.org/archives/2003/06/12/how_to_consume_rss_safely).
>
>
> Disagree, for the same reasons as above. We are signing the bits only, 
> not some representation of the universe at the time of signing.
>
>> Like I said, I'll be trying to have the draft put together by this 
>> weekend.
>
>
> Hopefully, my comments above cause you to put discussion of your 
> reasoning in there. Please don't read my comments as "don't do this", 
> but rather "if you're going to do this, you have to justify it". That 
> will make the document stronger and more likely to be implemented 
> properly.
>
Absolutely.  I am by far not an expert in digital signatures and very 
much appreciate the feedback.  comments like these are precisely why I 
kicked off this thread in the first place.  I would especially like to 
hear more thoughts on the inc-c14n vs. ex-c14n issue.

> --Paul Hoffman, Director
> --Internet Mail Consortium
>
- James




From owner-atom-syntax@mail.imc.org Thu Jun 30 16:13:55 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Do5Q3-0004yd-Os
	for atompub-archive@megatron.ietf.org; Thu, 30 Jun 2005 16:13:55 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19425
	for <atompub-archive@lists.ietf.org>; Thu, 30 Jun 2005 16:13:53 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5UK577Q023263;
	Thu, 30 Jun 2005 13:05:08 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5UK57vR023261;
	Thu, 30 Jun 2005 13:05:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5UK56j7023244
	for <atom-syntax@imc.org>; Thu, 30 Jun 2005 13:05:07 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [172.16.1.3] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	(using TLSv1 with cipher RC4-SHA (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id CB695A34BD;
	Thu, 30 Jun 2005 16:05:04 -0400 (EDT)
In-Reply-To: <42C2D5E0.10205@gmail.com>
References: <097CC973-BC19-4838-9076-019A9FD614EC@mnot.net> <1f2ed5cd05062901577845007@mail.gmail.com> <788DD8A0-45CB-4E6F-8E36-B13184D009B7@mnot.net> <42C2D5E0.10205@gmail.com>
Mime-Version: 1.0 (Apple Message framework v730)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <7B9235E7-4FB3-4EE1-84B6-A242A1AA0575@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-00.txt
Date: Thu, 30 Jun 2005 13:04:58 -0700
To: James M Snell <jasnell@gmail.com>
X-Mailer: Apple Mail (2.730)
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: 7bit


Hi James,

On 29/06/2005, at 10:09 AM, James M Snell wrote:
>
> 1. This appears to be addressed at solving the same problem as Bob  
> Wyman's RFC3229+feed proposal [http://bobwyman.pubsub.com/main/ 
> 2004/09/using_rfc3229_w.html].  Do you have any empiracle data  
> similar to what Bob provides @ http://bobwyman.pubsub.com/main/ 
> 2004/10/massive_bandwid.html that would indicate that your approach  
> is a better solution to this problem?  These are actually not  
> mutually exclusive solutions, they're just different and could be  
> used for different scenarios -- e.g. Bob's tends to make a lot of  
> sense for blog dashboard feeds like what we use within IBM to show  
> all post and commenting activity within our internal blogs server  
> while your mechanism would work rather well for things like Top Ten  
> lists, etc.  I would just like to see a bit of a compare/contrast  
> on the two approaches.

It's orthoganal to RFC3229. The problem I'm solving is how to  
reconstruct the *entire* state of the logical feed, not just one  
partial representation of it; although RFC3229 could be used to do  
that, it would require feed authors to post the entire content of  
their feed (potentially, many megabytes). This would incur a huge  
load, because any clients that don't support RFC3229 would have to  
GET the entire feed, leading to severe bandwidth problems.

To give a concrete example, Dave Winer would have to post one RSS  
file containing every entry he's made in Scripting News for the past  
10+ years to use RFC3229 to meet the same goal; with this proposal,  
he'd just have to add a 'prev' to each archived feed (assuming he has  
archives around, which if he doesn't, I imagine he could reconstruct).

> 2. Is the feed state mechanism a way of paging through the current  
> contents of a collection or a snapshot-in-time view of a feed?   
> That is...
>
>    is it
>
>        A) Collection has a bunch of entries.  Each feed  
> representation has 15 entries and the prev link
>             acts like a paging mechanism similar to what we see  
> currently use in search results.  Deleting
>             the first ten entries out of the collection would cause  
> all of the entries in the feed to "shift backwards"
>             in the feeds
>
>         B) Each prev link is representative of how the feed looked  
> at a given point in time.  E.g. the feed as it would
>              have appeared at a given hour of a given day
>
>    If it's A, then Bob's RFC3229+feed solution seems much more  
> efficient. (see #1)
>
>    If it's B, then I'm wondering why you don't just use an ETag  
> based approach, e.g.
>
>       <fs:Stateful>1</fs:Stateful>
>       <fs:prev>{ETag}</fs:prev>
>
>    This would allow clients to only ever have to deal with a single  
> URI for a feed and use conditional-gets with ETag to differentiate  
> which snapshot of the feed they want to get and would likely make  
> it easier to remediate potential recursive reference attacks, (e.g.  
> feed A references feed B which references feed C which is a blind  
> redirect to Feed A).

This proposal doesn't handle deletion or other aspects of identity in  
feeds; I tried to introduce language like that earlier in Atom  
itself, but we failed to gain consensus around it.

How does an ETag help you locate a previous feed to reconstruct  
state? Even if it could, I'm not sure intermingling HTTP protocol  
details with application semantics; although there's nothing to  
prevent this theoretically, in many implementations, it might be  
problematic to predict what the ETag is.


> 3. Microsoft's RSS Lists spec uses <cf:treatAs /> to attach  
> behavioral semantics to a feed.  This proposal uses <fs:Stateful />  
> to attach behavioral semantics.  It would be nice if we could come  
> up with a relatively simple and standardizable way of attaching  
> behavioral semantics.  For example, a standardized <treatAs />  
> element:
>
>    <atomex:treatAs>stateful</atomex:treatAs>
>
>    The value of the treatAs element would be a list of tokens with  
> defined semantics.  Each token SHOULD be registered with IANA.   
> Unknown tokens would be ignored.  Incompatible tokens would be  
> ignored with  first-in-the-list takes precedence semantics. For  
> example:
>
>    <atomex:treatAs>stateful list</atomex:treatAs>
>
>    Indicates that the feed should be treated as a list whose past  
> states can be queried using the kind of mechanism you've defined.

That seems like an awfully heavyweight solution. What does defining  
the container and an IANA registry add?


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




From owner-atom-syntax@mail.imc.org Thu Jun 30 16:48:39 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Do5xe-0006lf-V4
	for atompub-archive@megatron.ietf.org; Thu, 30 Jun 2005 16:48:39 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22398
	for <atompub-archive@lists.ietf.org>; Thu, 30 Jun 2005 16:48:36 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5UKfJse063269;
	Thu, 30 Jun 2005 13:41:19 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5UKfJGd063268;
	Thu, 30 Jun 2005 13:41:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.204])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5UKfIO7063217
	for <atom-syntax@imc.org>; Thu, 30 Jun 2005 13:41:19 -0700 (PDT)
	(envelope-from jasnell@gmail.com)
Received: by wproxy.gmail.com with SMTP id 58so166118wri
        for <atom-syntax@imc.org>; Thu, 30 Jun 2005 13:41:10 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=Hycjo93H07qB06q9HF6w9oasw/YP2K2LkPjTSv2RLJntzpAz3yVhkZ9Av51V9aR2bhdfzlN0iwmT2FZocZ3znJmLIGcDI5n7fAjdYI/yPq95FQBClicXUlX5FEix6Jb1tUfJK6A0OuwY9pfxwZ//q526xXmgloGFBEeIoojMYjc=
Received: by 10.54.57.21 with SMTP id f21mr697625wra;
        Thu, 30 Jun 2005 13:41:09 -0700 (PDT)
Received: from ?192.168.1.103? ([67.181.223.222])
        by mx.gmail.com with ESMTP id 33sm224289wra.2005.06.30.13.41.09;
        Thu, 30 Jun 2005 13:41:09 -0700 (PDT)
Message-ID: <42C458E0.3000406@gmail.com>
Date: Thu, 30 Jun 2005 13:41:04 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mark Nottingham <mnot@mnot.net>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: I-D ACTION:draft-nottingham-atompub-feed-history-00.txt
References: <097CC973-BC19-4838-9076-019A9FD614EC@mnot.net> <1f2ed5cd05062901577845007@mail.gmail.com> <788DD8A0-45CB-4E6F-8E36-B13184D009B7@mnot.net> <42C2D5E0.10205@gmail.com> <7B9235E7-4FB3-4EE1-84B6-A242A1AA0575@mnot.net>
In-Reply-To: <7B9235E7-4FB3-4EE1-84B6-A242A1AA0575@mnot.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


Mark Nottingham wrote:

> Hi James,
>
> On 29/06/2005, at 10:09 AM, James M Snell wrote:
>
>>
>> 1. This appears to be addressed at solving the same problem as Bob  
>> Wyman's RFC3229+feed proposal [http://bobwyman.pubsub.com/main/ 
>> 2004/09/using_rfc3229_w.html].  Do you have any empiracle data  
>> similar to what Bob provides @ http://bobwyman.pubsub.com/main/ 
>> 2004/10/massive_bandwid.html that would indicate that your approach  
>> is a better solution to this problem?  These are actually not  
>> mutually exclusive solutions, they're just different and could be  
>> used for different scenarios -- e.g. Bob's tends to make a lot of  
>> sense for blog dashboard feeds like what we use within IBM to show  
>> all post and commenting activity within our internal blogs server  
>> while your mechanism would work rather well for things like Top Ten  
>> lists, etc.  I would just like to see a bit of a compare/contrast  on 
>> the two approaches.
>
>
> It's orthoganal to RFC3229. The problem I'm solving is how to  
> reconstruct the *entire* state of the logical feed, not just one  
> partial representation of it; although RFC3229 could be used to do  
> that, it would require feed authors to post the entire content of  
> their feed (potentially, many megabytes). This would incur a huge  
> load, because any clients that don't support RFC3229 would have to  
> GET the entire feed, leading to severe bandwidth problems.
>
> To give a concrete example, Dave Winer would have to post one RSS  
> file containing every entry he's made in Scripting News for the past  
> 10+ years to use RFC3229 to meet the same goal; with this proposal,  
> he'd just have to add a 'prev' to each archived feed (assuming he has  
> archives around, which if he doesn't, I imagine he could reconstruct).
>
At times we do get spolied by the ability to dynamically generate 
responses don't we ;-) You're obviously correct when it comes to 
statically generated content - RFC3229+feed does not provide a workable 
solution in that case.

>> 2. Is the feed state mechanism a way of paging through the current  
>> contents of a collection or a snapshot-in-time view of a feed?   That 
>> is...
>>
>>    is it
>>
>>        A) Collection has a bunch of entries.  Each feed  
>> representation has 15 entries and the prev link
>>             acts like a paging mechanism similar to what we see  
>> currently use in search results.  Deleting
>>             the first ten entries out of the collection would cause  
>> all of the entries in the feed to "shift backwards"
>>             in the feeds
>>
>>         B) Each prev link is representative of how the feed looked  
>> at a given point in time.  E.g. the feed as it would
>>              have appeared at a given hour of a given day
>>
>>    If it's A, then Bob's RFC3229+feed solution seems much more  
>> efficient. (see #1)
>>
>>    If it's B, then I'm wondering why you don't just use an ETag  
>> based approach, e.g.
>>
>>       <fs:Stateful>1</fs:Stateful>
>>       <fs:prev>{ETag}</fs:prev>
>>
>>    This would allow clients to only ever have to deal with a single  
>> URI for a feed and use conditional-gets with ETag to differentiate  
>> which snapshot of the feed they want to get and would likely make  it 
>> easier to remediate potential recursive reference attacks, (e.g.  
>> feed A references feed B which references feed C which is a blind  
>> redirect to Feed A).
>
>
> This proposal doesn't handle deletion or other aspects of identity in  
> feeds; I tried to introduce language like that earlier in Atom  
> itself, but we failed to gain consensus around it.
>
> How does an ETag help you locate a previous feed to reconstruct  
> state? Even if it could, I'm not sure intermingling HTTP protocol  
> details with application semantics; although there's nothing to  
> prevent this theoretically, in many implementations, it might be  
> problematic to predict what the ETag is.
>
It's not so much using ETag to reconstruct state as much as it is to 
view access previous views of the feed.  Btw, I threw this out for 
discussions sake and not because I think it's the "right" solution.  I'm 
not particularly in love with it myself.

>
>> 3. Microsoft's RSS Lists spec uses <cf:treatAs /> to attach  
>> behavioral semantics to a feed.  This proposal uses <fs:Stateful />  
>> to attach behavioral semantics.  It would be nice if we could come  
>> up with a relatively simple and standardizable way of attaching  
>> behavioral semantics.  For example, a standardized <treatAs />  element:
>>
>>    <atomex:treatAs>stateful</atomex:treatAs>
>>
>>    The value of the treatAs element would be a list of tokens with  
>> defined semantics.  Each token SHOULD be registered with IANA.   
>> Unknown tokens would be ignored.  Incompatible tokens would be  
>> ignored with  first-in-the-list takes precedence semantics. For  
>> example:
>>
>>    <atomex:treatAs>stateful list</atomex:treatAs>
>>
>>    Indicates that the feed should be treated as a list whose past  
>> states can be queried using the kind of mechanism you've defined.
>
>
> That seems like an awfully heavyweight solution. What does defining  
> the container and an IANA registry add?
>
The value is that I would really like to see a common and consistent way 
of attaching behavioral semantics to the feed rather than each 
individual vendor / spec defining their own app and impl specific 
methods.  It could be done without IANA support, of course, but it's 
just annoying to see relatively similar tasks done in completely 
different ways. 

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




From owner-atom-syntax@mail.imc.org Thu Jun 30 16:53:33 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Do62P-0006X9-5R
	for atompub-archive@megatron.ietf.org; Thu, 30 Jun 2005 16:53:33 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22700
	for <atompub-archive@lists.ietf.org>; Thu, 30 Jun 2005 16:53:30 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5UKkoYW069570;
	Thu, 30 Jun 2005 13:46:50 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5UKkoPC069569;
	Thu, 30 Jun 2005 13:46:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5UKknDe069503
	for <atom-syntax@imc.org>; Thu, 30 Jun 2005 13:46:49 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [172.16.1.3] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	(using TLSv1 with cipher RC4-SHA (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 980C2A32BA;
	Thu, 30 Jun 2005 16:46:48 -0400 (EDT)
In-Reply-To: <42C458E0.3000406@gmail.com>
References: <097CC973-BC19-4838-9076-019A9FD614EC@mnot.net> <1f2ed5cd05062901577845007@mail.gmail.com> <788DD8A0-45CB-4E6F-8E36-B13184D009B7@mnot.net> <42C2D5E0.10205@gmail.com> <7B9235E7-4FB3-4EE1-84B6-A242A1AA0575@mnot.net> <42C458E0.3000406@gmail.com>
Mime-Version: 1.0 (Apple Message framework v730)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <141FD8AF-9B6E-456C-9BBA-46226113710E@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-00.txt
Date: Thu, 30 Jun 2005 13:46:46 -0700
To: James M Snell <jasnell@gmail.com>
X-Mailer: Apple Mail (2.730)
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: 7bit



On 30/06/2005, at 1:41 PM, James M Snell wrote:

> The value is that I would really like to see a common and  
> consistent way of attaching behavioral semantics to the feed rather  
> than each individual vendor / spec defining their own app and impl  
> specific methods.  It could be done without IANA support, of  
> course, but it's just annoying to see relatively similar tasks done  
> in completely different ways.

I totally agree that we should have neutral, non-vendor-specific  
semantics defined. I just don't see how having this container  
defined, along with the IANA registry, helps; if it was the intent of  
the WG to forbid all vendor-specific mechanisms, we should have  
disallowed all extensions except for those that are in an IANA  
registry (for example).

That's an extreme, of course, but it points out that Atom -- and RSS,  
for that matter -- is still in the period of its lifetime where  
vendors and individuals have to experiment to figure out what's  
valuable, and let the market sort out what becomes commonly deployed.  
It's not pretty, but it works pretty well in the long run.

Cheers,


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




From owner-atom-syntax@mail.imc.org Thu Jun 30 17:24:53 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Do6Wj-0006hG-JP
	for atompub-archive@megatron.ietf.org; Thu, 30 Jun 2005 17:24:53 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25313
	for <atompub-archive@lists.ietf.org>; Thu, 30 Jun 2005 17:24:50 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5ULGZ4H002222;
	Thu, 30 Jun 2005 14:16:35 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5ULGZ43002220;
	Thu, 30 Jun 2005 14:16:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5ULGY2X002047
	for <atom-syntax@imc.org>; Thu, 30 Jun 2005 14:16:34 -0700 (PDT)
	(envelope-from antone@geckotribe.com)
Received: from geckotribe.com (c-67-169-250-63.hsd1.ut.comcast.net[67.169.250.63])
          by comcast.net (rwcrmhc11) with SMTP
          id <2005063021161001300rkma8e>; Thu, 30 Jun 2005 21:16:10 +0000
Date: Thu, 30 Jun 2005 15:16:08 -0600
Subject: Re: More on Atom XML signatures and encryption
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v553)
From: Antone Roundy <antone@geckotribe.com>
To: atom-syntax@imc.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <42C440E9.2070700@gmail.com>
Message-Id: <2D4BEEB0-E9AC-11D9-AC47-003065EA6144@geckotribe.com>
X-Mailer: Apple Mail (2.553)
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: 7bit


On Thursday, June 30, 2005, at 12:58  PM, James M Snell wrote:
>>> 6. If an entry contains any "enclosure" links, the digital signature 
>>> SHOULD cover the referenced resources.  Enclosure links that are not 
>>> covered are considered untrusted and pose a potential security risk
>>
>> Fully disagree. We are signing the bits in the document, not the 
>> outside. There is "security risk", those items are simply unsigned.
>>
> I tend to consider enclosures to be part of the document, even if they 
> are included by reference.  As a potential consumer of an enclosure I 
> want to know whether or not the referenced enclosure can be trusted.  
> Is it accepted to change the SHOULD to a MAY with a caveat outlining 
> the security risk?
>
Perhaps a good approach would be for the signed entry to contain a 
separate signature for the enclosure--so the entry's signature would 
cover the bits in the enclosure's signature, but not the bits in the 
enclosure itself.  That way, the signature for the entry could be 
verified without having to fetch the enclosure.

Where would that signature go?  Did we decide that <link> doesn't have 
to be empty?  If so, that might be a good place...but then I don't have 
any experience with signed XML, so I don't know whether there would be 
technical difficulties with putting it in any particular place.




From owner-atom-syntax@mail.imc.org Thu Jun 30 17:25:08 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Do6Wy-0007pr-BF
	for atompub-archive@megatron.ietf.org; Thu, 30 Jun 2005 17:25:08 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25355
	for <atompub-archive@lists.ietf.org>; Thu, 30 Jun 2005 17:25:05 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5ULHAfI002931;
	Thu, 30 Jun 2005 14:17:10 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j5ULHAk9002930;
	Thu, 30 Jun 2005 14:17:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.203])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j5ULH9LK002801
	for <atom-syntax@imc.org>; Thu, 30 Jun 2005 14:17:10 -0700 (PDT)
	(envelope-from jasnell@gmail.com)
Received: by zproxy.gmail.com with SMTP id q3so110528nzb
        for <atom-syntax@imc.org>; Thu, 30 Jun 2005 14:17:03 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=hhRPTnFFea6F+xlY/KznfhI+Ihb2Koyj1oMJmEBeBos0e+bFK221wabY6B/mdd/IiDKmLzT4rmcUbLFX1dDb49WLEO8aAOcemyiW8+l0G1gLuFCPvTTH+Cg+qLu3ks/+rAbJVQqtq4LZ2fL+PLiYWVfsyJ+XScfIgCuHTlCRybc=
Received: by 10.36.104.16 with SMTP id b16mr550257nzc;
        Thu, 30 Jun 2005 14:17:03 -0700 (PDT)
Received: from ?192.168.1.103? ([67.181.223.222])
        by mx.gmail.com with ESMTP id i5sm90646nzi.2005.06.30.14.16.59;
        Thu, 30 Jun 2005 14:17:03 -0700 (PDT)
Message-ID: <42C46146.2070307@gmail.com>
Date: Thu, 30 Jun 2005 14:16:54 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mark Nottingham <mnot@mnot.net>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: I-D ACTION:draft-nottingham-atompub-feed-history-00.txt
References: <097CC973-BC19-4838-9076-019A9FD614EC@mnot.net> <1f2ed5cd05062901577845007@mail.gmail.com> <788DD8A0-45CB-4E6F-8E36-B13184D009B7@mnot.net> <42C2D5E0.10205@gmail.com> <7B9235E7-4FB3-4EE1-84B6-A242A1AA0575@mnot.net> <42C458E0.3000406@gmail.com> <141FD8AF-9B6E-456C-9BBA-46226113710E@mnot.net>
In-Reply-To: <141FD8AF-9B6E-456C-9BBA-46226113710E@mnot.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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>
Content-Transfer-Encoding: 7bit


Mark Nottingham wrote:

>
> On 30/06/2005, at 1:41 PM, James M Snell wrote:
>
>> The value is that I would really like to see a common and  consistent 
>> way of attaching behavioral semantics to the feed rather  than each 
>> individual vendor / spec defining their own app and impl  specific 
>> methods.  It could be done without IANA support, of  course, but it's 
>> just annoying to see relatively similar tasks done  in completely 
>> different ways.
>
>
> I totally agree that we should have neutral, non-vendor-specific  
> semantics defined. I just don't see how having this container  
> defined, along with the IANA registry, helps; if it was the intent of  
> the WG to forbid all vendor-specific mechanisms, we should have  
> disallowed all extensions except for those that are in an IANA  
> registry (for example).
>
> That's an extreme, of course, but it points out that Atom -- and RSS,  
> for that matter -- is still in the period of its lifetime where  
> vendors and individuals have to experiment to figure out what's  
> valuable, and let the market sort out what becomes commonly deployed.  
> It's not pretty, but it works pretty well in the long run.
>
<Sigh> Why can't technology work well AND be pretty. 

- James




From owner-atom-syntax@mail.imc.org Thu Jun 30 21:37:35 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DoATH-0007lX-8c
	for atompub-archive@megatron.ietf.org; Thu, 30 Jun 2005 21:37:35 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27485
	for <atompub-archive@lists.ietf.org>; Thu, 30 Jun 2005 21:37:32 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j611QI2e054019;
	Thu, 30 Jun 2005 18:26:18 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j611QIqH054015;
	Thu, 30 Jun 2005 18:26:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231])
	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j611QEbB053949;
	Thu, 30 Jun 2005 18:26:14 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: <p0623094fbeea2aaefd0f@[10.20.30.249]>
Date: Thu, 30 Jun 2005 18:26:08 -0700
To: Atom WG <atom-syntax@imc.org>
From: Paul Hoffman <phoffman@imc.org>
Subject: Clearing a "discuss" vote on the Atom format
Cc: Russ Housley <housley@vigilsec.com>
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>


Greetings again. Russ Housley, one of the two Security Area 
Directors, has placed a "discuss" vote on the Atom format document. 
You can read it at 
<https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=36890>>. 
Fortunately, it seems reasonably easy to clear this discuss.

Below is what Russ asks for, and my suggested changes. The WG should 
let me know if they agree or disagree with my wording. I'm Cc'ing 
Russ on this thread so he can agree or disagree that the suggested 
wording is sufficient for him.

>   Section 5 does not provide sufficient detail for interoperability.
>   Unfortunately, the complexity of XML and the variety of contexts in
>   which it is used made it impossible for the XMLDSIG WG to come up
>   with one set of canonicalization rules that are "distinguished."
>   By distinguished, I mean that there is exactly one way to represent
>   the XML object.  There are two canonicalization rule sets: the
>   Canonical XML and the Exclusive XML Canonicalization.  Specify
>   which one is mandatory-to-implement.

To be added near the end of Section 5.1 of atompub-format:

    Section 6.5.1 of [W3C.REC-xmldsig-core-20020212] requires support
    for Canonical XML. Atom Processors that sign Atom Documents MUST
    use Canonical XML.

>   Section 5 should tell the reader when the use of digital signatures
>   and encryption are desirable.

To be added near the beginning of Section 5 of atompub-format:

    Producers of feeds and/or entries, and intermediaries who aggregate
    feeds and/or entries, may have sound business reasons for signing
    and/or encrypting otherwise-unprotected content. For example,
    a merchant might digitally sign a message that contains a discount
    coupon for its products. A bank that uses Atom to deliver customer
    statements is very likely to want to sign and encrypt those
    messages to protect their customers' financial information and to
    assure the customer of their authenticity. Intermediaries may want
    to encrypt aggregated feeds so that a passive observer cannot tell
    what topics the recipient is interested in. There are hundreds
    of other reasons why Atom documents might be signed, encrypted,
    or both.

>   Also, I would like to see mandatory-
>   to-implement algorithms specified.

To be added near the end of Section 5.1 of atompub-format:

    Section 4.4.2 of [W3C.REC-xmldsig-core-20020212] requires support
    for DSA signatures and recommends support for RSA signatures.
    However, because of the much greater popularity in the market of
    RSA versus DSA, Atom Processors that verify signed Atom Documents MUST
    be able to verify RSA signatures, but do not need be able to verify DSA
    signatures. Atom documents MAY use HMACs for signatures, but this
    type of signature is not expected to have wide adoption any time soon.

To be added near the end of Section 5.2 of atompub-format:

    Section 5.1 of [W3C.REC-xmlenc-core-20021210] requires support of
    TripleDES, AES-128, and AES-256. Atom Processors that decrypt Atom
    Documents MUST be able to decrypt with AES-128.

>   If appropriate, use MUST- and
>   SHOULD+ as they were defined by the IPsec WG to tell implementors
>   about future algorithm requirements.

I do not think it is appropriate to do that here because we could get 
out of sync with the requirements if the W3C documents evolve.

>   In section 5, please state the order of the nesting if both digital
>   signature and encryption are used.  I believe that signing the
>   plaintext is the correct ordering in this situation.

To be added to a new subsection 5.3 of atompub-format:

    Encryption based on [W3C.REC-xmlenc-core-20021210] does not assure
    integrity of the original document. When an Atom Document is to be
    signed and encrypted, it is generally a good idea to first sign the
    document, then encrypt the signed document. This provides integrity
    to the base document while encrypting all the information, including
    the identity of the entity that signed the document.

>   Since XML encryption does not provide integrity, it is important to use
>   XML digital signature whenever encryption is used.  When a digital
>   signature algorithm is used, this should be straightforward; however,
>   the XML digital signature specification also supports message
>   authentication codes (MACs).  When MACs are used, the symmetric keys
>   for the encryption and the MAC calculation need to use the same key
>   management technique.  When digital signatures are used, the recipient
>   must have a way to verify the public key of the signer.  This is
>   usually done with a certificate.

I believe the somewhat-negative wording on HMACs above should 
preclude any need to add (probably-confusing) text about key 
management for HMACs. If there is a community that wants to use 
HMACs, they can write up a document on how to do secure key 
management for it in XMLDigSig.

>   Section 8.5 needs to be expanded.  When digital signature or encryption
>   are used, what threats do they protect against?

    Digital signatures provide authentication, message integrity, and
    non-repudiation with proof of origin. Encryption provides data
    confidentiality.

That text is lifted directly from the abstract of the S/MIME spec. 
There was no parallel text in the Security Considerations section of 
the S/MIME spec that I could re-purpose.


--Paul Hoffman, Director
--Internet Mail Consortium




From owner-atom-syntax@mail.imc.org Thu Jun 30 21:49:35 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DoAet-0004CL-Ji
	for atompub-archive@megatron.ietf.org; Thu, 30 Jun 2005 21:49:35 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28205
	for <atompub-archive@lists.ietf.org>; Thu, 30 Jun 2005 21:49:33 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j611gj2a061854;
	Thu, 30 Jun 2005 18:42:45 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j611gjQd061853;
	Thu, 30 Jun 2005 18:42:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231])
	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j611ggH6061835;
	Thu, 30 Jun 2005 18:42:43 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: <p06230955beea4f90a1fd@[10.20.30.249]>
In-Reply-To: <2D4BEEB0-E9AC-11D9-AC47-003065EA6144@geckotribe.com>
References: <2D4BEEB0-E9AC-11D9-AC47-003065EA6144@geckotribe.com>
Date: Thu, 30 Jun 2005 18:42:41 -0700
To: Antone Roundy <antone@geckotribe.com>, atom-syntax@imc.org
From: Paul Hoffman <phoffman@imc.org>
Subject: Re: More on Atom XML signatures and 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>


At 3:16 PM -0600 6/30/05, Antone Roundy wrote:
>On Thursday, June 30, 2005, at 12:58  PM, James M Snell wrote:
>>>>6. If an entry contains any "enclosure" links, the digital 
>>>>signature SHOULD cover the referenced resources.  Enclosure links 
>>>>that are not covered are considered untrusted and pose a 
>>>>potential security risk
>>>
>>>Fully disagree. We are signing the bits in the document, not the 
>>>outside. There is "security risk", those items are simply unsigned.
>>>
>>I tend to consider enclosures to be part of the document, even if 
>>they are included by reference.  As a potential consumer of an 
>>enclosure I want to know whether or not the referenced enclosure 
>>can be trusted.  Is it accepted to change the SHOULD to a MAY with 
>>a caveat outlining the security risk?
>>
>Perhaps a good approach would be for the signed entry to contain a 
>separate signature for the enclosure--so the entry's signature would 
>cover the bits in the enclosure's signature, but not the bits in the 
>enclosure itself.  That way, the signature for the entry could be 
>verified without having to fetch the enclosure.
>
>Where would that signature go?  Did we decide that <link> doesn't 
>have to be empty?  If so, that might be a good place...but then I 
>don't have any experience with signed XML, so I don't know whether 
>there would be technical difficulties with putting it in any 
>particular place.

This is possible. It translates to "I say that the bits gotten from 
<here> have a hash of <value>". If the hash doesn't match, you can't 
assume anything about the bits; if it does, the other semantic data 
in the message can apply to them ("...and it is a picture of me", 
"...and it is a program that will delete your data"...).

--Paul Hoffman, Director
--Internet Mail Consortium




From owner-atom-syntax@mail.imc.org Thu Jun 30 21:49:40 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DoAey-0004CX-1x
	for atompub-archive@megatron.ietf.org; Thu, 30 Jun 2005 21:49:40 -0400
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28227
	for <atompub-archive@lists.ietf.org>; Thu, 30 Jun 2005 21:49:37 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j611gkJV061871;
	Thu, 30 Jun 2005 18:42:46 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id j611gkk0061870;
	Thu, 30 Jun 2005 18:42:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231])
	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j611ggH4061835;
	Thu, 30 Jun 2005 18:42:42 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: <p06230954beea4c8aec89@[10.20.30.249]>
In-Reply-To: <42C440E9.2070700@gmail.com>
References: <20050622152507.3CE73724A2C@mail.pubsub.com>
 <42C2FAC2.4000802@gmail.com> <p06230932bee8f2a4e9cd@[10.20.30.249]>
 <42C440E9.2070700@gmail.com>
Date: Thu, 30 Jun 2005 18:40:06 -0700
To: James M Snell <jasnell@gmail.com>
From: Paul Hoffman <phoffman@imc.org>
Subject: Re: More on Atom XML signatures and encryption
Cc: atom-syntax@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>


At 11:58 AM -0700 6/30/05, James M Snell wrote:
>>>3. When signing complete Atom documents (atom:feed and top level 
>>>atom:entry), Inclusive Canonicalization with no pre-c14n 
>>>normalization is required.
>>
>>
>>There seems to be many more interoperability issues with Inclusive 
>>Canonicalization than with Exclusive. What is your reasoning here?
>>
>Two reasons:
>a. No need to re-envelope things at the document level

There is no reason to do that with Canonical XML.

>b. Ignorance on my part as to what all the interoperability issues 
>are.  Can you elaborate or point me to some relevant discussions?

The description of how to pull things down from the outside info is 
well-defined for Canonical XML, and Canonical XML is required for 
XMLDigSig, so folks have worked harder on it than Inclusive.

>>>4. The signature should cover the signing key. (e.g. if a x509 
>>>cert stored externally from the feed is used, the Signature should 
>>>reference and cover that x509 cert).  Failing to do so opens up a 
>>>security risk.
>>
>>
>>Please explain the "security risk". I probably disagree with this 
>>requirement, but want to hear your risk analysis.
>>
>This is mostly tied to #2 above and comes from a lesson learned from 
>WS-Security. Specifically section 13.2.4 of 
>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf
>
>    "Implementers should be aware of the possibility of a token 
>substitution attack. In any
>     situation where a digital signature is verified by reference to 
>a token provided in the
>     message, which specifies the key, it may be possible for an 
>unscrupulous producer
>     to later claim that a different token, containing the same key, 
>but different information
>     was intended."
>
>If we don't verify-by-reference to a key contained elsewhere in the 
>feed (or other location), this no longer becomes an issue.

We have no intention of doing HMACs, so I believe that this falls 
out. I have added words about that in a different message I just sent.

>>>5. When signing individual atom:entry elements within a feed, 
>>>Exclusive Canonicalization MUST be used.  If a separate KeyInfo is 
>>>used to identify the signing key, it MUST be contained as either a 
>>>child of the entry or source elements.  A source element SHOULD be 
>>>included in the entry.
>>
>>
>>Why is this different than #3?
>>
>These entries are subject to re-enveloping in a way that document 
>level elements are not. It is possible to use ex-c14n throughout so 
>that the behavior is consistent. The KeyInfo statement relates to #2 
>and thus becomes irrelevant.

Consistency will probably lead to more interoperability, particularly 
in an area as tricky as canonicalization.

>>>6. If an entry contains any "enclosure" links, the digital 
>>>signature SHOULD cover the referenced resources.  Enclosure links 
>>>that are not covered are considered untrusted and pose a potential 
>>>security risk
>>
>>
>>Fully disagree. We are signing the bits in the document, not the 
>>outside. There is "security risk", those items are simply unsigned.
>>
>I tend to consider enclosures to be part of the document, even if 
>they are included by reference.  As a potential consumer of an 
>enclosure I want to know whether or not the referenced enclosure can 
>be trusted.  Is it accepted to change the SHOULD to a MAY with a 
>caveat outlining the security risk?

You have to define exactly what is covered by the signature. No 
SHOULDs, no MAYs. So you either have to define exactly how to bring 
in referenced data (and do you follow links in that data, and links 
in links...?), or you say "it's just the bits you see here". As 
another example, how would you sign an entry that points to a page 
that is known to change all the time because it shows the current 
date? Or a hit counter?

There is no "security risk" if you state exactly what is signed. You 
should point out that the referenced material can change and is not 
covered by the signature.

>>>7. If an entry contains a content element that uses @src, the 
>>>digital signature MUST cover the referenced resource.
>>
>>
>>Fully disagree.
>>
>Same as above.  Even though it is included-by-reference, the 
>referenced content is still a part of the message.

No, it isn't. The reference is part of the message.

>>>8. Aggregators and Intermediaries MUST NOT alter/augment the 
>>>content of digitally signed entry elements.
>>
>>
>>Also disagree, but for a different reason. Aggregators and 
>>intermediaries should be free to diddle bits if they strip the 
>>signatures that they have broken.
>>
>Ok, my fault. I wasn't clear.  Reword to "Aggregators and 
>Intermediaries MUST NOT alter/augment the content of digitally 
>signed entry elements unless they strip the Signature from the entry"

That works for me. You might also consider adding "and they are 
allowed to add their own signatures in the place of stripped 
signatures".

>>>9. In addition to serving as a message authenticator, the 
>>>Signature may be used by implementations to assert that 
>>>potentially untrustworthy content within a feed can be trusted 
>>>(e.g. binary enclosures, scripts, etc)
>>
>>
>>How will you assert that?
>>
>Not so much a normative assertion.  More of a "if you know who 
>produced this feed/entry and you decide that you can trust their 
>signature, you can make finer grained decisions about whether or not 
>to trust the content".

Not unless you can define "trust the content". All you can trust is 
that it is part of the assertion made by the semantic content of the 
signed message. That might be "I saw this program", it might be "I 
wrote this program", it might be "this program erased my hard drive", 
and so on. I think you were suggesting that signatures over active 
content could be automatically parsed to mean something; that's not 
OK without a lot of additional words and a different type of 
signature.

Suggestion (and only a suggestion): don't go there.

--Paul Hoffman, Director
--Internet Mail Consortium