From owner-atom-syntax@mail.imc.org Fri Dec 01 12:11:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqBvW-0001S7-6e for atompub-archive@lists.ietf.org; Fri, 01 Dec 2006 12:11:54 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqBvU-0005bM-Qb for atompub-archive@lists.ietf.org; Fri, 01 Dec 2006 12:11:54 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB1GoAOU049250; Fri, 1 Dec 2006 09:50:10 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB1GoA14049249; Fri, 1 Dec 2006 09:50:10 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.235]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB1Go80b049235 for ; Fri, 1 Dec 2006 09:50:08 -0700 (MST) (envelope-from mbaker@gmail.com) Received: by wr-out-0506.google.com with SMTP id i20so1070760wra for ; Fri, 01 Dec 2006 08:50:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=GihbEUix3dHtxOdOp/PVu5WOyczRhrsp0qahV429Ikwj9V/6YEGz/zGEasY/EgUcnpXX00yAKYNz/SWTukA+7VQDdYyzpl3JcPhltZalDJ2UfNrP+zssOMGNR4Gu/dQiUFLXJ2rLKSecrcg1JGZg/35jXFkFFEXbE8dvco7qi5Q= Received: by 10.78.170.17 with SMTP id s17mr5037243hue.1164991805428; Fri, 01 Dec 2006 08:50:05 -0800 (PST) Received: by 10.78.174.19 with HTTP; Fri, 1 Dec 2006 08:50:05 -0800 (PST) Message-ID: Date: Fri, 1 Dec 2006 11:50:05 -0500 From: "Mark Baker" To: "Thomas Broyer" Subject: Re: PaceEntryMediatype Cc: Atom-Syntax , Atom-Protocol , whatwg@whatwg.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <456DB265.5090804@gmail.com> X-Google-Sender-Auth: 74852a4b527a6f47 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Urgh, sorry for my tardiness; I'm falling behind on my reading. On 11/30/06, Thomas Broyer wrote: > I'd prefer basing autodiscovery on the media types and not at all on > the relationships. All a media type tells you (non-authoritatively too) is the spec you need to interpret the document at the other end of the link. That has very little to do with the reasons that you might want to follow the link, subscribe to it, etc.. Which is why you need a mechanism independent from the media type. Like link types. Consider hAtom. If you went by media types alone, you'd be confronted with; Not particularly useful for subscription (or anything else for that matter) is it? This would be better; Autodiscovery should ideally be based primarily on link types, and only secondarily - as an optimization - on media types. Even this should work; Mark. From owner-atom-syntax@mail.imc.org Fri Dec 01 12:39:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqCM2-0005yT-3z for atompub-archive@lists.ietf.org; Fri, 01 Dec 2006 12:39:18 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqCM0-0002Jn-Fy for atompub-archive@lists.ietf.org; Fri, 01 Dec 2006 12:39:18 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB1HHjjY053620; Fri, 1 Dec 2006 10:17:45 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB1HHjva053619; Fri, 1 Dec 2006 10:17:45 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB1HHhB5053612 for ; Fri, 1 Dec 2006 10:17:44 -0700 (MST) (envelope-from kmarvin@google.com) Received: from spaceape7.eur.corp.google.com (spaceape7.eur.corp.google.com [172.28.16.141]) by smtp-out.google.com with ESMTP id kB1HHXh4016195 for ; Fri, 1 Dec 2006 17:17:33 GMT DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:references; b=Q8MHko3gnkvxV+5kEfYZsSm21bE8ik5ZoNZx+7icN2PlRrRRN+maOBdx8ot87sZBm IcHE1tHekDNm2xCmOtXpA== Received: from nz-out-0102.google.com (nzhi11.prod.google.com [10.36.235.11]) by spaceape7.eur.corp.google.com with ESMTP id kB1HHFBQ006815 for ; Fri, 1 Dec 2006 17:17:18 GMT Received: by nz-out-0102.google.com with SMTP id i11so1448531nzh for ; Fri, 01 Dec 2006 09:17:05 -0800 (PST) Received: by 10.65.20.3 with SMTP id x3mr7238926qbi.1164993424598; Fri, 01 Dec 2006 09:17:04 -0800 (PST) Received: by 10.64.183.12 with HTTP; Fri, 1 Dec 2006 09:17:04 -0800 (PST) Message-ID: <192fc9640612010917k4d6cda0ag4ca431f481bb169b@mail.gmail.com> Date: Fri, 1 Dec 2006 11:17:04 -0600 From: "Kyle Marvin" To: "Mark Baker" Subject: Re: PaceEntryMediatype Cc: "Thomas Broyer" , Atom-Syntax , Atom-Protocol , whatwg@whatwg.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3511_7133533.1164993424506" References: <456DB265.5090804@gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.4 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 ------=_Part_3511_7133533.1164993424506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I'm still listening to the debate, but Mark's argument resonates with me. It seems like 'content-type' is more about the expected syntax of the resource at the other end of the wire, not it's semantic meaning. I don't see Atom feeds and entries as syntactically different enough to warrant unique media types, there's lots of existing parsers that seem able to navigate this split just fine already. I expect that if you associated a 'rel' value with links that point to "application/atom+xml", whether it is expected to be a feed or an entry would probably be part of the 'rel' description and thus not ambiguous at all. I think the discussion started because of the aforementioned issues with the HTML5 link semantics, which is what should probably be fixed. On top of that, the procedural and back compat issues associated with splitting the mime type now just don't seem to make it a win to me. Crazy busy and largely silent, but not completely awol, -- Kyle On 12/1/06, Mark Baker wrote: > > > Urgh, sorry for my tardiness; I'm falling behind on my reading. > > On 11/30/06, Thomas Broyer wrote: > > I'd prefer basing autodiscovery on the media types and not at all on > > the relationships. > > All a media type tells you (non-authoritatively too) is the spec you > need to interpret the document at the other end of the link. That has > very little to do with the reasons that you might want to follow the > link, subscribe to it, etc.. Which is why you need a mechanism > independent from the media type. Like link types. > > Consider hAtom. If you went by media types alone, you'd be confronted > with; > > > > Not particularly useful for subscription (or anything else for that > matter) is it? This would be better; > > > > Autodiscovery should ideally be based primarily on link types, and > only secondarily - as an optimization - on media types. Even this > should work; > > > > Mark. > > ------=_Part_3511_7133533.1164993424506 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I'm still listening to the debate, but Mark's argument resonates with me.  It seems like 'content-type' is more about the expected syntax of the resource at the other end of the wire, not it's semantic meaning.  I don't see Atom feeds and entries as syntactically different enough to warrant unique media types, there's lots of existing parsers that seem able to navigate this split just fine already.

I expect that if you associated a 'rel' value with links that point to "application/atom+xml", whether it is expected to be a feed or an entry would probably be part of the 'rel' description and thus not ambiguous at all.   I think the discussion started because of the aforementioned issues with the HTML5 link semantics, which is what should probably be fixed.

On top of that, the procedural and back compat issues associated with splitting the mime type now just don't seem to make it a win to me.

Crazy busy and largely silent, but not completely awol,

-- Kyle

On 12/1/06, Mark Baker <distobj@acm.org> wrote:

Urgh, sorry for my tardiness; I'm falling behind on my reading.

On 11/30/06, Thomas Broyer <t.broyer@gmail.com> wrote:
> I'd prefer basing autodiscovery on the media types and not at all on
> the relationships.

All a media type tells you (non-authoritatively too) is the spec you
need to interpret the document at the other end of the link.  That has
very little to do with the reasons that you might want to follow the
link, subscribe to it, etc..  Which is why you need a mechanism
independent from the media type.  Like link types.

Consider hAtom.  If you went by media types alone, you'd be confronted with;

<link type="text/html" href=" hatom.html" />

Not particularly useful for subscription (or anything else for that
matter) is it?  This would be better;

<link rel="feed" type="text/html" href="hatom.html " />

Autodiscovery should ideally be based primarily on link types, and
only secondarily - as an optimization - on media types.  Even this
should work;

<link rel="feed" href=" hatom.html" />

Mark.


------=_Part_3511_7133533.1164993424506-- From owner-atom-syntax@mail.imc.org Fri Dec 01 13:10:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqCqR-0004B0-7F for atompub-archive@lists.ietf.org; Fri, 01 Dec 2006 13:10:43 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqCqP-0002Js-O0 for atompub-archive@lists.ietf.org; Fri, 01 Dec 2006 13:10:43 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB1Hs1D5057544; Fri, 1 Dec 2006 10:54:01 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB1Hs1WI057543; Fri, 1 Dec 2006 10:54:01 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.230]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB1Hs0s6057537 for ; Fri, 1 Dec 2006 10:54:00 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i20so1086745wra for ; Fri, 01 Dec 2006 09:53:55 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=a5BhJHgosK4w+HekWICWhpM08h+jzjXcNoTFED8VBgY9R1bL/vAQbwHZdwrNr6p/amMRrH8umdOEAr5QZmix8cGB3DRL8w7zjBrsg1viwgLqJ2+cSGl6sWGnLC4OyUd0nLGJSrbJyJucdiFHM01ArKiwY/yR8ANTAYF93kv/00o= Received: by 10.100.94.3 with SMTP id r3mr1539298anb.1164995635339; Fri, 01 Dec 2006 09:53:55 -0800 (PST) Received: from ?192.168.1.101? ( [67.181.218.96]) by mx.google.com with ESMTP id 43sm37136263wri.2006.12.01.09.53.53; Fri, 01 Dec 2006 09:53:54 -0800 (PST) Message-ID: <45706C20.6090306@gmail.com> Date: Fri, 01 Dec 2006 09:53:36 -0800 From: James M Snell User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: Kyle Marvin CC: Mark Baker , Thomas Broyer , Atom-Syntax , Atom-Protocol , whatwg@whatwg.org Subject: Re: PaceEntryMediatype References: <456DB265.5090804@gmail.com> <192fc9640612010917k4d6cda0ag4ca431f481bb169b@mail.gmail.com> In-Reply-To: <192fc9640612010917k4d6cda0ag4ca431f481bb169b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Kyle Marvin wrote: > [snip] > I expect that if you associated a 'rel' value with links that point to > "application/atom+xml", whether it is expected to be a feed or an entry > would probably be part of the 'rel' description and thus not ambiguous > at all. I think the discussion started because of the aforementioned > issues with the HTML5 link semantics, which is what should probably be > fixed. > Not necessarily. Consider: What is the purpose of using alternate links? What is a UA supposed to do with 'em? Why did I as a content publisher choose to use the "alternate" link relation? Are all of these links of equal value to all UA's? Are they all expected to be processed in the same basic way? Should an "archive" feed be treated the same way as a "subscription" feed? Consider this use case: In IBM's Activities implementation, each of our "Activity" collections are entries in a top level master collection. Every "Activity" has several representations: An Atom entry, An Atom feed, A RSS feed, A HTML page, etc. On the html page I want to be able to link to each of the various representations as alternates. I also want folks to be able to subscribe to the Atom feed and allow the folks who are building APP-enabled editing tools to autodiscover the edit uri of the entry. I don't want UIs to show a subscription link to the Atom entry representation. What I want is something like this: Given these links I have all of the information I need: * There are three alternate representations: An Atom Entry, An Atom Feed and an RSS Feed. * There are two links I can subscribe to: An Atom Feed and an RSS Feed * There is one edit link Note that this clearly separates the purpose of the link (rel) from the resource type. I don't care what the value of the type attribute is, if rel includes the keyword "subscribe" (or "feed", doesn't matter) then I know I can subscribe to that resource. If the rel contains the keyword "alternate" I know it's an alternate representation, no other semantics are implied. Each of the keywords in the rel attribute are completely orthogonal to one another. Note also that there is a clear separation between the Atom Feed and Entry types. These are different document types intended for different audiences and deserve different media types. - James From owner-atom-syntax@mail.imc.org Fri Dec 01 13:56:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqDZD-0000Fn-B3 for atompub-archive@lists.ietf.org; Fri, 01 Dec 2006 13:56:59 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqDZB-00080z-JJ for atompub-archive@lists.ietf.org; Fri, 01 Dec 2006 13:56:59 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB1IgcGW062951; Fri, 1 Dec 2006 11:42:38 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB1Igcdm062950; Fri, 1 Dec 2006 11:42:38 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.12]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB1Igb7T062944 for ; Fri, 1 Dec 2006 11:42:37 -0700 (MST) (envelope-from kmarvin@google.com) Received: from zps78.corp.google.com (zps78.corp.google.com [172.25.146.78]) by smtp-out.google.com with ESMTP id kB1IgX3t023211 for ; Fri, 1 Dec 2006 10:42:33 -0800 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:references; b=LI4NCg5rgnEO8H0ZUoHheIlJ2kwFdxlBF7CwjDTWEe8x0lTPMOrlsSbWagniBSSkj fxdKdUTcPDR60Oi/Swuaw== Received: from nz-out-0102.google.com (nzcx7.prod.google.com [10.36.125.7]) by zps78.corp.google.com with ESMTP id kB1IgAWh017661 for ; Fri, 1 Dec 2006 10:42:20 -0800 Received: by nz-out-0102.google.com with SMTP id x7so1655324nzc for ; Fri, 01 Dec 2006 10:42:20 -0800 (PST) Received: by 10.65.228.5 with SMTP id f5mr7376903qbr.1164998540494; Fri, 01 Dec 2006 10:42:20 -0800 (PST) Received: by 10.64.183.12 with HTTP; Fri, 1 Dec 2006 10:42:20 -0800 (PST) Message-ID: <192fc9640612011042h2f0727b8oaf2cf82708ad9dab@mail.gmail.com> Date: Fri, 1 Dec 2006 12:42:20 -0600 From: "Kyle Marvin" To: "James M Snell" Subject: Re: PaceEntryMediatype Cc: "Mark Baker" , "Thomas Broyer" , Atom-Syntax , Atom-Protocol , whatwg@whatwg.org In-Reply-To: <45706C20.6090306@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4716_9472067.1164998540386" References: <456DB265.5090804@gmail.com> <192fc9640612010917k4d6cda0ag4ca431f481bb169b@mail.gmail.com> <45706C20.6090306@gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.4 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c ------=_Part_4716_9472067.1164998540386 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 12/1/06, James M Snell wrote: > > > Kyle Marvin wrote: > > [snip] > > I expect that if you associated a 'rel' value with links that point to > > "application/atom+xml", whether it is expected to be a feed or an entry > > would probably be part of the 'rel' description and thus not ambiguous > > at all. I think the discussion started because of the aforementioned > > issues with the HTML5 link semantics, which is what should probably be > > fixed. > > > > Not necessarily. > > Consider: > > > > > > What is the purpose of using alternate links? What is a UA supposed to > do with 'em? Why did I as a content publisher choose to use the > "alternate" link relation? Are all of these links of equal value to all > UA's? Are they all expected to be processed in the same basic way? > Should an "archive" feed be treated the same way as a "subscription" feed? This points out that the above rel+type don't carry sufficient semantic meaning to help a UA decide what to do with them. I don't think anyone on this thread is disagreeing with that. This discussion (as I understand it) is about what to do given that ambiguity. You can either get more specific with the rel value, with the content-type, or with both. Consider this use case: > > In IBM's Activities implementation, each of our "Activity" collections > are entries in a top level master collection. Every "Activity" has > several representations: An Atom entry, An Atom feed, A RSS feed, A HTML > page, etc. On the html page I want to be able to link to each of the > various representations as alternates. I also want folks to be able to > subscribe to the Atom feed and allow the folks who are building > APP-enabled editing tools to autodiscover the edit uri of the entry. I > don't want UIs to show a subscription link to the Atom entry > representation. > > What I want is something like this: > > type="application/atom+xml" > href="feed.xml" /> > type="application/atom.entry+xml" > href="entry.xml" /> > type="application/rss+xml" > href="rss.xml" /> > > Given these links I have all of the information I need: > > * There are three alternate representations: An Atom Entry, An Atom > Feed and an RSS Feed. > * There are two links I can subscribe to: An Atom Feed and an RSS Feed > * There is one edit link > > Note that this clearly separates the purpose of the link (rel) from the > resource type. I don't care what the value of the type attribute is, if > rel includes the keyword "subscribe" (or "feed", doesn't matter) then I > know I can subscribe to that resource. If the rel contains the keyword > "alternate" I know it's an alternate representation, no other semantics > are implied. Each of the keywords in the rel attribute are completely > orthogonal to one another. So you've solved the above problem by changing both the rel value and the content-type (in a few cases). I'd propose that changing the rel value (alone) would a sufficient solution. The above "rel" values provide sufficient information with some implied expectations about feed vs. entry resource and potential usage of the href. The implied nature could be explicit if these rel values were enumerated somewhere (for example, you subscribe to feeds, and you edit entries). Note also that there is a clear separation between the Atom Feed and > Entry types. These are different document types intended for different > audiences and deserve different media types. I see the separation but I'm still missing a clear justifiication for it. I don't see content-type as having anything to do with the "audience". It's about what media format you'd get back if you dereference the href and rel is about how you can interpret/interact with it. I feel like the primary audience for content-type is likely to be used in selecting some type of parser when retrieving the resource. Orthogonal to this, the "rel" value assigns some semantic meaning to the resource (what does the entry or feed describe) and might also specify what interaction model you might expect via the href (ex. "edit" implies APP edit semantics on an entry resource). Cheers! ------=_Part_4716_9472067.1164998540386 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 12/1/06, James M Snell <jasnell@gmail.com> wrote:

Kyle Marvin wrote:
> [snip]
> I expect that if you associated a 'rel' value with links that point to
> "application/atom+xml", whether it is expected to be a feed or an entry
> would probably be part of the 'rel' description and thus not ambiguous
> at all.   I think the discussion started because of the aforementioned
> issues with the HTML5 link semantics, which is what should probably be
> fixed.
>

Not necessarily.

Consider:

  <link rel="alternate" type="application/atom+xml" href="feed.xml" />
  <link rel="alternate" type="application/atom+xml" href="archive.xml" />
  <link rel="alternate" type="application/atom+xml" href="entry.xml" />

What is the purpose of using alternate links? What is a UA supposed to
do with 'em? Why did I as a content publisher choose to use the
"alternate" link relation? Are all of these links of equal value to all
UA's?  Are they all expected to be processed in the same basic way?
Should an "archive" feed be treated the same way as a "subscription" feed?

This points out that the above rel+type don't carry sufficient semantic meaning to help a UA decide what to do with them.   I don't think anyone on this thread is disagreeing with that.   This discussion (as I understand it) is about what to do given that ambiguity.   You can either get more specific with the rel value, with the content-type, or with both.

Consider this use case:

In IBM's Activities implementation, each of our "Activity" collections
are entries in a top level master collection.  Every "Activity" has
several representations: An Atom entry, An Atom feed, A RSS feed, A HTML
page, etc.  On the html page I want to be able to link to each of the
various representations as alternates.  I also want folks to be able to
subscribe to the Atom feed and allow the folks who are building
APP-enabled editing tools to autodiscover the edit uri of the entry.  I
don't want UIs to show a subscription link to the Atom entry representation.

What I want is something like this:

  <link rel="alternate subscribe"
        type="application/atom+xml"
        href="feed.xml" />
  <link rel="alternate edit"
        type="application/atom.entry+xml"
        href="entry.xml" />
  <link rel="alternate subsribe"
        type="application/rss+xml"
        href="rss.xml" />

Given these links I have all of the information I need:

  * There are three alternate representations: An Atom Entry, An Atom
Feed and an RSS Feed.
  * There are two links I can subscribe to: An Atom Feed and an RSS Feed
  * There is one edit link

Note that this clearly separates the purpose of the link (rel) from the
resource type.  I don't care what the value of the type attribute is, if
rel includes the keyword "subscribe" (or "feed", doesn't matter) then I
know I can subscribe to that resource.  If the rel contains the keyword
"alternate" I know it's an alternate representation, no other semantics
are implied.  Each of the keywords in the rel attribute are completely
orthogonal to one another.

So you've solved the above problem by changing both the rel value and the content-type (in a few cases).  I'd propose that changing the rel value (alone) would a sufficient solution.  The above "rel" values provide sufficient information with some implied expectations about feed vs. entry resource and potential usage of the href.  The implied nature could be explicit if these rel values were enumerated somewhere (for example, you subscribe to feeds, and you edit entries).

Note also that there is a clear separation between the Atom Feed and
Entry types.  These are different document types intended for different
audiences and deserve different media types.

I see the separation but I'm still missing a clear justifiication for it.  I don't see content-type as having anything to do with the "audience".  It's about what media format you'd get back if you dereference the href and rel is about how you can interpret/interact with it.   I feel like the primary audience for content-type is likely to be used in selecting some type of parser when retrieving the resource.  Orthogonal to this, the "rel" value assigns some semantic meaning to the resource (what does the entry or feed describe) and might also specify what interaction model you might expect via the href (ex. "edit" implies APP edit semantics on an entry resource).

Cheers!

------=_Part_4716_9472067.1164998540386-- From owner-atom-syntax@mail.imc.org Fri Dec 01 14:18:56 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqDuS-0007vC-GM for atompub-archive@lists.ietf.org; Fri, 01 Dec 2006 14:18:56 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GqDuQ-0003RY-RS for atompub-archive@lists.ietf.org; Fri, 01 Dec 2006 14:18:56 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB1IsY4p063930; Fri, 1 Dec 2006 11:54:34 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB1IsYlP063929; Fri, 1 Dec 2006 11:54:34 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB1IsWdR063909; Fri, 1 Dec 2006 11:54:32 -0700 (MST) (envelope-from prabhaka@apple.com) Received: from relay8.apple.com (relay8.apple.com [17.128.113.38]) by mail-out3.apple.com (8.13.6/8.13.6) with ESMTP id kB1IsNgq029695; Fri, 1 Dec 2006 10:54:23 -0800 (PST) Received: from [17.203.42.167] (unknown [17.203.42.167]) by relay8.apple.com (Apple SCV relay) with ESMTP id 01FD8264; Fri, 1 Dec 2006 10:54:23 -0800 (PST) In-Reply-To: <192fc9640612011042h2f0727b8oaf2cf82708ad9dab@mail.gmail.com> References: <456DB265.5090804@gmail.com> <192fc9640612010917k4d6cda0ag4ca431f481bb169b@mail.gmail.com> <45706C20.6090306@gmail.com> <192fc9640612011042h2f0727b8oaf2cf82708ad9dab@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/alternative; boundary=Apple-Mail-6--139014026 Message-Id: Cc: Atom-Syntax , Atom-Protocol , whatwg@whatwg.org From: Ernest Prabhakar Subject: Re: PaceEntryMediatype - rel-type instead Date: Fri, 1 Dec 2006 10:54:23 -0800 To: Kyle Marvin X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 --Apple-Mail-6--139014026 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Dec 1, 2006, at 10:42 AM, Kyle Marvin wrote: > I see the separation but I'm still missing a clear justifiication > for it. I don't see content-type as having anything to do with the > "audience". It's about what media format you'd get back if you > dereference the href and rel is about how you can interpret/ > interact with it. I feel like the primary audience for content- > type is likely to be used in selecting some type of parser when > retrieving the resource. Orthogonal to this, the "rel" value > assigns some semantic meaning to the resource (what does the entry > or feed describe) and might also specify what interaction model you > might expect via the href (ex. "edit" implies APP edit semantics on > an entry resource). +1 to what Kyle said -- Ernie P. --Apple-Mail-6--139014026 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Dec 1, 2006, at = 10:42 AM, Kyle Marvin wrote:
I see the = separation but I'm still missing a clear justifiication for it.=A0 I = don't see content-type as having anything to do with the "audience".=A0 = It's about what media format you'd get back if you dereference the href = and rel is about how you can interpret/interact with it.=A0=A0 I feel = like the primary audience for content-type is likely to be used in = selecting some type of parser when retrieving the resource.=A0 = Orthogonal to this, the "rel" value assigns some semantic meaning to the = resource (what does the entry or feed describe) and might also specify = what interaction model you might expect via the href (ex. "edit" implies = APP edit semantics on an entry resource).=A0

+1 to what Kyle said

-- Ernie = P.

= --Apple-Mail-6--139014026-- From owner-atom-syntax@mail.imc.org Fri Dec 01 14:45:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqEKP-0005D0-Ha for atompub-archive@lists.ietf.org; Fri, 01 Dec 2006 14:45:45 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqEKO-0006Lp-4y for atompub-archive@lists.ietf.org; Fri, 01 Dec 2006 14:45:45 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB1JPpJV067719; Fri, 1 Dec 2006 12:25:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB1JPpT7067718; Fri, 1 Dec 2006 12:25:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB1JPmT1067702 for ; Fri, 1 Dec 2006 12:25:49 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i20so1108747wra for ; Fri, 01 Dec 2006 11:25:48 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=gpdu561fMA4QvomNlFPgTXrvitTBfHo44pTCyMNSKgzusFyBtZeHM0yV9pJkarvdl/d9jl054JcZlPwXa9xWIA78vd912mdxSJrofTPUJp8jcVK/MwBbk7An3Jn0bJ1qqiVvVFUAJrCoxYrkm4efdcbMKPAYZiyW6DZQcauJUWM= Received: by 10.100.7.18 with SMTP id 18mr808537ang.1165001148235; Fri, 01 Dec 2006 11:25:48 -0800 (PST) Received: from ?192.168.1.101? ( [67.181.218.96]) by mx.google.com with ESMTP id g3sm681504wra.2006.12.01.11.25.46; Fri, 01 Dec 2006 11:25:47 -0800 (PST) Message-ID: <457081B0.8080908@gmail.com> Date: Fri, 01 Dec 2006 11:25:36 -0800 From: James M Snell User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: Kyle Marvin CC: Mark Baker , Thomas Broyer , Atom-Syntax , Atom-Protocol , whatwg@whatwg.org Subject: Re: PaceEntryMediatype References: <456DB265.5090804@gmail.com> <192fc9640612010917k4d6cda0ag4ca431f481bb169b@mail.gmail.com> <45706C20.6090306@gmail.com> <192fc9640612011042h2f0727b8oaf2cf82708ad9dab@mail.gmail.com> In-Reply-To: <192fc9640612011042h2f0727b8oaf2cf82708ad9dab@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a You're right that the differentiation in the content-type is of less importance but without it there's no way for me to unambiguously indicate that a resource has both an Atom Feed representation and an Atom Entry representation. The best I could do is say "This things has two Atom representations". Keep in mind that I want to be able to differentiate the types of alternate representations available without having to look at any of the other rel keywords. - James Kyle Marvin wrote: > [snip] > I see the separation but I'm still missing a clear justifiication for > it. I don't see content-type as having anything to do with the > "audience". It's about what media format you'd get back if you > dereference the href and rel is about how you can interpret/interact > with it. I feel like the primary audience for content-type is likely > to be used in selecting some type of parser when retrieving the > resource. Orthogonal to this, the "rel" value assigns some semantic > meaning to the resource (what does the entry or feed describe) and might > also specify what interaction model you might expect via the href (ex. > "edit" implies APP edit semantics on an entry resource). > > Cheers! > From owner-atom-syntax@mail.imc.org Fri Dec 01 14:51:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqEPn-0006Ns-DX for atompub-archive@lists.ietf.org; Fri, 01 Dec 2006 14:51:19 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqEPk-0001XO-Vd for atompub-archive@lists.ietf.org; Fri, 01 Dec 2006 14:51:19 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB1JZNbj068646; Fri, 1 Dec 2006 12:35:23 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB1JZMZr068645; Fri, 1 Dec 2006 12:35:22 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB1JZLCo068634; Fri, 1 Dec 2006 12:35:22 -0700 (MST) (envelope-from prabhaka@apple.com) Received: from relay6.apple.com (relay6.apple.com [17.128.113.36]) by mail-out4.apple.com (8.13.6/8.13.6) with ESMTP id kB1JZCDg028585; Fri, 1 Dec 2006 11:35:12 -0800 (PST) Received: from [17.203.42.167] (unknown [17.203.42.167]) by relay6.apple.com (Apple SCV relay) with ESMTP id 47578104; Fri, 1 Dec 2006 11:35:12 -0800 (PST) In-Reply-To: <457081B0.8080908@gmail.com> References: <456DB265.5090804@gmail.com> <192fc9640612010917k4d6cda0ag4ca431f481bb169b@mail.gmail.com> <45706C20.6090306@gmail.com> <192fc9640612011042h2f0727b8oaf2cf82708ad9dab@mail.gmail.com> <457081B0.8080908@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <76AFE365-E56F-4C27-90F7-EB619B2F2D80@apple.com> Cc: Atom-Syntax Syntax , Atom-Protocol , whatwg@whatwg.org Content-Transfer-Encoding: 7bit From: Ernest Prabhakar Subject: Re: PaceEntryMediatype Date: Fri, 1 Dec 2006 11:35:12 -0800 To: James M Snell X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Hi James, On Dec 1, 2006, at 11:25 AM, James M Snell wrote: > You're right that the differentiation in the content-type is of less > importance but without it there's no way for me to unambiguously > indicate that a resource has both an Atom Feed representation and an > Atom Entry representation. The best I could do is say "This things > has > two Atom representations". Keep in mind that I want to be able to > differentiate the types of alternate representations available without > having to look at any of the other rel keywords. I understand that this is *what* you want, but I'm still unclear "why." From where I sit, Kyle's argument makes sense: keep the syntax in content-type, and the semantics in rel-type. This seems both simpler and more consistent with how the web works today. No? Or is there some overriding reason for ignoring rel-type? -- Ernie P. From owner-atom-syntax@mail.imc.org Fri Dec 01 14:58:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqEWN-00029U-1v for atompub-archive@lists.ietf.org; Fri, 01 Dec 2006 14:58:07 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqEWL-0006dI-K3 for atompub-archive@lists.ietf.org; Fri, 01 Dec 2006 14:58:07 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB1JeYfv069157; Fri, 1 Dec 2006 12:40:34 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB1JeYXF069156; Fri, 1 Dec 2006 12:40:34 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB1JeW9Q069149 for ; Fri, 1 Dec 2006 12:40:33 -0700 (MST) (envelope-from kmarvin@google.com) Received: from spaceape7.eur.corp.google.com (spaceape7.eur.corp.google.com [172.28.16.141]) by smtp-out.google.com with ESMTP id kB1JeSvF026303 for ; Fri, 1 Dec 2006 19:40:28 GMT DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:references; b=plGOb4DHcLng4JYdGnKcNo8mMYbqfKD/ogdS4Qx2PkwE++4sx9ccjO+QY7nTQSeRF PQPh8xoEge1497z7HX+xQ== Received: from nz-out-0102.google.com (nzfl8.prod.google.com [10.36.188.8]) by spaceape7.eur.corp.google.com with ESMTP id kB1JeDrb012738 for ; Fri, 1 Dec 2006 19:40:16 GMT Received: by nz-out-0102.google.com with SMTP id l8so1686489nzf for ; Fri, 01 Dec 2006 11:39:59 -0800 (PST) Received: by 10.64.242.5 with SMTP id p5mr7466213qbh.1165001999215; Fri, 01 Dec 2006 11:39:59 -0800 (PST) Received: by 10.64.183.12 with HTTP; Fri, 1 Dec 2006 11:39:54 -0800 (PST) Message-ID: <192fc9640612011139y3a416269vd6cac6c21ea93eb2@mail.gmail.com> Date: Fri, 1 Dec 2006 13:39:54 -0600 From: "Kyle Marvin" To: "James M Snell" Subject: Re: PaceEntryMediatype Cc: "Mark Baker" , "Thomas Broyer" , Atom-Syntax , Atom-Protocol , whatwg@whatwg.org In-Reply-To: <457081B0.8080908@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5445_8840925.1165001994087" References: <456DB265.5090804@gmail.com> <192fc9640612010917k4d6cda0ag4ca431f481bb169b@mail.gmail.com> <45706C20.6090306@gmail.com> <192fc9640612011042h2f0727b8oaf2cf82708ad9dab@mail.gmail.com> <457081B0.8080908@gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: -0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 ------=_Part_5445_8840925.1165001994087 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 12/1/06, James M Snell wrote: > > You're right that the differentiation in the content-type is of less > importance but without it there's no way for me to unambiguously > indicate that a resource has both an Atom Feed representation and an > Atom Entry representation. I can see that it's possible to have two different representations for the same resource (GData does this too) but a key question is whether they have the same relation (semantic meaning/purpose relative to the linking content). In your earlier example, they did not (subscription vs. edit). The best I could do is say "This things has > two Atom representations". Keep in mind that I want to be able to > differentiate the types of alternate representations available without > having to look at any of the other rel keywords. Can you explain why you want this? I'm not trying to be relentless I just want to make sure I'm not missing something important while pushing back. -- Kyle ------=_Part_5445_8840925.1165001994087 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
On 12/1/06, James M Snell <jasnell@gmail.com> wrote:
You're right that the differentiation in the content-type is of less
importance but without it there's no way for me to unambiguously
indicate that a resource has both an Atom Feed representation and an
Atom Entry representation.  

I can see that it's possible to have two different representations for the same resource (GData does this too) but a key question is whether they have the same relation (semantic meaning/purpose relative to the linking content).   In your earlier example, they did not (subscription vs. edit).

The best I could do is say "This things has
two Atom representations".  Keep in mind that I want to be able to
differentiate the types of alternate representations available without
having to look at any of the other rel keywords.

Can you explain why you want this?   I'm not trying to be relentless I just want to make sure I'm not missing something important while pushing back.

-- Kyle


------=_Part_5445_8840925.1165001994087-- From owner-atom-syntax@mail.imc.org Fri Dec 01 15:25:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqEwk-0006IV-HE for atompub-archive@lists.ietf.org; Fri, 01 Dec 2006 15:25:22 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqEwf-00023i-4b for atompub-archive@lists.ietf.org; Fri, 01 Dec 2006 15:25:22 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB1K8fOt072319; Fri, 1 Dec 2006 13:08:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB1K8fH5072317; Fri, 1 Dec 2006 13:08:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB1K8exE072305 for ; Fri, 1 Dec 2006 13:08:41 -0700 (MST) (envelope-from henry.story@bblfish.net) Received: (qmail 81427 invoked by uid 17064); 1 Dec 2006 20:08:38 -0000 Received: from unknown (HELO localhost) ([127.0.0.1]) (envelope-sender ) by 127.0.0.1 (qmail-ldap-1.03) with SMTP for ; 1 Dec 2006 20:08:38 -0000 Date: Fri, 1 Dec 2006 12:08:38 -0800 (PST) From: Henry Story X-X-Sender: hjs@bblfish.net To: atom-protocol@imc.org cc: atom-syntax@imc.org Subject: Re: In San Francisco/Bay Area Message-ID: <20061201120233.Y74708@bblfish.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Ok I suggest trying December 6th. Onion or no Onion rings at Tied House. What is dinner time in the bay? 6pm? 7pm? Henry >On 28 Nov 2006, at 21:31, John Panzer wrote: > >Any of those would be good for me. Be careful of the deep fried onion >rings at Tied House, though. > >>Henry Story wrote: >> >>It has been suggested that a good meeting location might be Tied House in >>Mountain View [1]. It has a back room that's like a patio but covered and >>heated for dinner on either >> >>Wednesday 6th Dec >>Friday 8th Dec >>Monday 11th Dec >>Wednesday 13th Dec >> >>Any preferences? >> >>Henry Story >> >>[1] http://www.tiedhouse.com/ >> >>>On 16 Nov 2006, at 18:23, Henry Story wrote: >>> >>>Hi, >>> >>>I am in the San Francisco/Bay Area region for the coming month. Would >>>anyone in the area be up for a group meeting? >>> >>>Henry >>> From owner-atom-syntax@mail.imc.org Fri Dec 01 17:23:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqGn4-0000tk-Cr for atompub-archive@lists.ietf.org; Fri, 01 Dec 2006 17:23:30 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqGn3-0003Ru-0w for atompub-archive@lists.ietf.org; Fri, 01 Dec 2006 17:23:30 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB1M5F0M085070; Fri, 1 Dec 2006 15:05:15 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB1M5Fof085069; Fri, 1 Dec 2006 15:05:15 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.239]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB1M5E23085061 for ; Fri, 1 Dec 2006 15:05:14 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id i30so3075875wxd for ; Fri, 01 Dec 2006 14:05:13 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=UJuhw2wIZfWDWXdN1xREnJvdVwie8cfSchpyftLQbrMakFyEaakOld/Lr1zoxoZ1Sc5MWKeSxRqe7r11QS7J9pgvimn3GVJqvh6GdRYhiiTGP64JYhyM03HQbizVgbcQGDyNjIYPPWtiBPEUofjVm2nnBIMN7R2nI2oASrOhGb8= Received: by 10.90.80.8 with SMTP id d8mr5827535agb.1165010713753; Fri, 01 Dec 2006 14:05:13 -0800 (PST) Received: from ?192.168.1.101? ( [67.181.218.96]) by mx.google.com with ESMTP id 6sm7977956wrh.2006.12.01.14.05.09; Fri, 01 Dec 2006 14:05:13 -0800 (PST) Message-ID: <4570A710.7090302@gmail.com> Date: Fri, 01 Dec 2006 14:05:04 -0800 From: James M Snell User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: Kyle Marvin CC: Mark Baker , Thomas Broyer , Atom-Syntax , Atom-Protocol , whatwg@whatwg.org Subject: Re: PaceEntryMediatype References: <456DB265.5090804@gmail.com> <192fc9640612010917k4d6cda0ag4ca431f481bb169b@mail.gmail.com> <45706C20.6090306@gmail.com> <192fc9640612011042h2f0727b8oaf2cf82708ad9dab@mail.gmail.com> <457081B0.8080908@gmail.com> <192fc9640612011139y3a416269vd6cac6c21ea93eb2@mail.gmail.com> In-Reply-To: <192fc9640612011139y3a416269vd6cac6c21ea93eb2@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 I could but after the discussions this week I'm not sure its worth it. Yes, everything can be done using different rel values; the content-type thing is more just an annoyance than anything else. I'll just make sure that I never link my Atom entry documents using "alternate" (even tho that's what they are). - James Kyle Marvin wrote: > [snip] > Can you explain why you want this? I'm not trying to be relentless I > just want to make sure I'm not missing something important while pushing > back. > > -- Kyle > > From owner-atom-syntax@mail.imc.org Fri Dec 01 21:42:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqKpR-0005fm-3w for atompub-archive@lists.ietf.org; Fri, 01 Dec 2006 21:42:13 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqKpQ-0005n7-Fp for atompub-archive@lists.ietf.org; Fri, 01 Dec 2006 21:42:13 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB22RVcs006443; Fri, 1 Dec 2006 19:27:31 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB22RVNv006441; Fri, 1 Dec 2006 19:27:31 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB22RTdw006431; Fri, 1 Dec 2006 19:27:30 -0700 (MST) (envelope-from lisa@osafoundation.org) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 843A7142279; Fri, 1 Dec 2006 18:27:29 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04709-05; Fri, 1 Dec 2006 18:27:28 -0800 (PST) Received: from [192.168.1.101] (c-69-181-78-47.hsd1.ca.comcast.net [69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 46C3E142276; Fri, 1 Dec 2006 18:27:28 -0800 (PST) In-Reply-To: <192fc9640612010917k4d6cda0ag4ca431f481bb169b@mail.gmail.com> References: <456DB265.5090804@gmail.com> <192fc9640612010917k4d6cda0ag4ca431f481bb169b@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/alternative; boundary=Apple-Mail-8--111831628 Message-Id: Cc: "Mark Baker" , "Thomas Broyer" , Atom-Syntax , Atom-Protocol , whatwg@whatwg.org From: Lisa Dusseault Subject: Re: PaceEntryMediatype Date: Fri, 1 Dec 2006 18:27:25 -0800 To: Kyle Marvin X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.5 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a --Apple-Mail-8--111831628 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Supporting data or ideas: Some interesting links, semantically speaking, don't even have a fixed MIME type (or not just one, anyhow). If we wanted to add link relations for photo shares on WebDAV repositories, or personal calendars on CalDAV repositories, you'd want to point to the URL to the appropriate WebDAV collection, which could return results in HTML (response to GET without any special stuff), XML (response to PROPFIND), or iCalendar (in the CalDAV case). Not sure how to fully convey all of that, but at least not overloading MIME type with semantic meaning helps the situation. Lisa On Dec 1, 2006, at 9:17 AM, Kyle Marvin wrote: > I'm still listening to the debate, but Mark's argument resonates > with me. It seems like 'content-type' is more about the expected > syntax of the resource at the other end of the wire, not it's > semantic meaning. I don't see Atom feeds and entries as > syntactically different enough to warrant unique media types, > there's lots of existing parsers that seem able to navigate this > split just fine already. > > I expect that if you associated a 'rel' value with links that point > to "application/atom+xml", whether it is expected to be a feed or > an entry would probably be part of the 'rel' description and thus > not ambiguous at all. I think the discussion started because of > the aforementioned issues with the HTML5 link semantics, which is > what should probably be fixed. > > On top of that, the procedural and back compat issues associated > with splitting the mime type now just don't seem to make it a win > to me. > > Crazy busy and largely silent, but not completely awol, > > -- Kyle > > On 12/1/06, Mark Baker wrote: > > Urgh, sorry for my tardiness; I'm falling behind on my reading. > > On 11/30/06, Thomas Broyer wrote: > > I'd prefer basing autodiscovery on the media types and not at all on > > the relationships. > > All a media type tells you (non-authoritatively too) is the spec you > need to interpret the document at the other end of the link. That has > very little to do with the reasons that you might want to follow the > link, subscribe to it, etc.. Which is why you need a mechanism > independent from the media type. Like link types. > > Consider hAtom. If you went by media types alone, you'd be > confronted with; > > > > Not particularly useful for subscription (or anything else for that > matter) is it? This would be better; > > > > Autodiscovery should ideally be based primarily on link types, and > only secondarily - as an optimization - on media types. Even this > should work; > > > > Mark. > > --Apple-Mail-8--111831628 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

Supporting data or ideas: = Some interesting links, semantically speaking, don't even have a fixed = MIME type (or not just one, anyhow).=A0 If we wanted to add link = relations for photo shares on WebDAV repositories, or personal calendars = on CalDAV repositories, you'd want to point to the URL to the = appropriate WebDAV collection, which could return results in HTML = (response to GET without any special stuff), XML (response to PROPFIND), = or iCalendar (in the CalDAV case).=A0 Not sure how to fully convey all = of that, but at least not overloading MIME type with semantic meaning = helps the situation.

Lisa

On = Dec 1, 2006, at 9:17 AM, Kyle Marvin wrote:

I'm still = listening to the debate, but Mark's argument resonates with me.=A0 It = seems like 'content-type' is more about the expected syntax of the = resource at the other end of the wire, not it's semantic meaning.=A0 I = don't see Atom feeds and entries as syntactically different enough to = warrant unique media types, there's lots of existing parsers that seem = able to navigate this split just fine already.

I expect that if = you associated a 'rel' value with links that point to = "application/atom+xml", whether it is expected to be a feed or an entry = would probably be part of the 'rel' description and thus not ambiguous = at all.=A0=A0 I think the discussion started because of the = aforementioned issues with the HTML5 link semantics, which is what = should probably be fixed.

On top of that, the procedural and = back compat issues associated with splitting the mime type now just = don't seem to make it a win to me.

Crazy busy and largely silent, = but not completely awol,

-- Kyle

On 12/1/06, Mark = Baker <distobj@acm.org> = wrote:

Urgh, sorry for my tardiness; I'm falling behind on my = reading.

On 11/30/06, Thomas Broyer <t.broyer@gmail.com> = wrote:
> I'd prefer basing autodiscovery on the media types and = not at all on
> the relationships.

All a media type tells = you (non-authoritatively too) is the spec you
need to interpret the = document at the other end of the link.=A0=A0That has
very little to = do with the reasons that you might want to follow the
link, = subscribe to it, etc..=A0=A0Which is why you need a = mechanism
independent from the media type.=A0=A0Like link = types.

Consider hAtom.=A0=A0If you went by media types alone, = you'd be confronted with;

<link type=3D"text/html" href=3D" = hatom.html" />

Not particularly useful for subscription (or = anything else for that
matter) is it?=A0=A0This would be = better;

<link rel=3D"feed" type=3D"text/html" href=3D"hatom.html= " />

Autodiscovery should ideally be based primarily on link = types, and
only secondarily - as an optimization - on media = types.=A0=A0Even this
should work;

<link rel=3D"feed" = href=3D" hatom.html" = />

Mark.



= --Apple-Mail-8--111831628-- From owner-atom-syntax@mail.imc.org Fri Dec 01 21:42:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqKpR-0005fy-TN for atompub-archive@lists.ietf.org; Fri, 01 Dec 2006 21:42:13 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqKpQ-0005nK-Fp for atompub-archive@lists.ietf.org; Fri, 01 Dec 2006 21:42:13 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB22MLHW006172; Fri, 1 Dec 2006 19:22:21 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB22MLYT006171; Fri, 1 Dec 2006 19:22:21 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB22MKLc006159; Fri, 1 Dec 2006 19:22:20 -0700 (MST) (envelope-from lisa@osafoundation.org) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1F29A142273; Fri, 1 Dec 2006 18:22:20 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04769-02; Fri, 1 Dec 2006 18:22:18 -0800 (PST) Received: from [192.168.1.101] (c-69-181-78-47.hsd1.ca.comcast.net [69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id B1050142256; Fri, 1 Dec 2006 18:22:16 -0800 (PST) In-Reply-To: <20061201120233.Y74708@bblfish.net> References: <20061201120233.Y74708@bblfish.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Atom Protocol , Atom Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: In San Francisco/Bay Area Date: Fri, 1 Dec 2006 18:22:14 -0800 To: Henry Story X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Thanks for setting this up Henry, I can be there Dec 6. 7pm is much easier to make than 6pm if anybody's coming far, even just from SF. Lisa On Dec 1, 2006, at 12:08 PM, Henry Story wrote: > > Ok I suggest trying December 6th. > Onion or no Onion rings at Tied House. > > What is dinner time in the bay? 6pm? 7pm? > > Henry > >> On 28 Nov 2006, at 21:31, John Panzer wrote: >> >> Any of those would be good for me. Be careful of the deep fried >> onion rings at Tied House, though. >> >>> Henry Story wrote: >>> >>> It has been suggested that a good meeting location might be Tied >>> House in Mountain View [1]. It has a back room that's like a >>> patio but covered and heated for dinner on either >>> >>> Wednesday 6th Dec >>> Friday 8th Dec >>> Monday 11th Dec >>> Wednesday 13th Dec >>> >>> Any preferences? >>> >>> Henry Story >>> >>> [1] http://www.tiedhouse.com/ >>> >>>> On 16 Nov 2006, at 18:23, Henry Story wrote: >>>> >>>> Hi, >>>> >>>> I am in the San Francisco/Bay Area region for the coming month. >>>> Would anyone in the area be up for a group meeting? >>>> >>>> Henry >>>> > From owner-atom-syntax@mail.imc.org Fri Dec 01 22:57:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqM0F-0002fJ-DO for atompub-archive@lists.ietf.org; Fri, 01 Dec 2006 22:57:27 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqM0D-0007ZQ-UK for atompub-archive@lists.ietf.org; Fri, 01 Dec 2006 22:57:27 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB23fwRl011003; Fri, 1 Dec 2006 20:41:58 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB23fw9G011002; Fri, 1 Dec 2006 20:41:58 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxsf29.cluster1.charter.net (mxsf29.cluster1.charter.net [209.225.28.229]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB23fvs7010993 for ; Fri, 1 Dec 2006 20:41:58 -0700 (MST) (envelope-from antone@geckotribe.com) Received: from mxip25a.cluster1.charter.net (mxip25a.cluster1.charter.net [209.225.28.155]) by mxsf29.cluster1.charter.net (8.12.11.20060308/8.12.11) with ESMTP id kB23foNJ029082 for ; Fri, 1 Dec 2006 22:41:50 -0500 Received: from 68-118-146-150.dhcp.gdis.ne.charter.com (HELO [192.168.2.3]) ([68.118.146.150]) by mxip25a.cluster1.charter.net with ESMTP; 01 Dec 2006 22:41:50 -0500 X-IronPort-AV: i="4.09,486,1157342400"; d="scan'208"; a="898967767:sNHT34870486" Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: <456DB265.5090804@gmail.com> <192fc9640612010917k4d6cda0ag4ca431f481bb169b@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Antone Roundy Subject: Re: PaceEntryMediatype Date: Fri, 1 Dec 2006 21:41:48 -0600 To: atom-syntax@imc.org X-Mailer: Apple Mail (2.752.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc On 12/1/06, Mark Baker wrote: > On 11/30/06, Thomas Broyer wrote: > All a media type tells you (non-authoritatively too) is the spec you > need to interpret the document at the other end of the link. That has > very little to do with the reasons that you might want to follow the > link, subscribe to it, etc.. Which is why you need a mechanism > independent from the media type. Like link types. Now that this has sunk in, it makes a lot of sense--the @rel value says "you can subscribe to that", "that is an alternative representation of this", "that is where you'd go to edit this", and so on. The media type helps the user agent figure out whether it has the capability to do those things. For example, a feed reader that only handles RSS could ignore subscription links to resources of type "application/atom+xml" (ie. not present the subscription option to the user). The "subscribe to hAtom feed" case where @type is "text/ html" might be a little difficult to make a decision on, because there's no indication of what microformat is being used by the "feed" (or even if there's a microformat in use at all--maybe it really is just an HTML page, and "subscribing" to it just means "watch for changes to the entire document"). But in the case of bare syndication formats, things should be clear enough. So if it really is possible to do option 5 (new media type for entry documents, and @rel values to solve the rest of the issues), and do it cleanly, then that'd be my first choice. If that's doomed (due to a need to be backwards compatible with existing practice) to be a mess of ambiguities and counter-intuitivities (eg. "alternate" means "subscribe" when combined with a syndication type, except when it might really mean "alternate" because it points to a feed archive document, but anything with "feed" in it always means "subscribe"...) then oh my. One problem that I hadn't really thought clearly about till right now is that understanding the nature of the think linked TO may require some understanding of the nature of the thing linked FROM. For example, an "alternate" link from a typical blog homepage to its feed really does point to the same thing in an alternative format. Both are live documents in which new data gets added to the top, and old data drops off the bottom. But if you don't know that the webpage is a live document, you wouldn't know whether the link pointed to a static or live document. "alternate" is perfectly accurate, but it's not helpful enough. "subscribe" would be much more explicit. Which raises the question of how to point to a static alternative representation of the data currently found in the document. "alternate" WOULD be a good word to use for that except that it's already being used to point to live feeds. An option that would almost surely cause confusion would be to use "alternative" for static alternative representations. The meaning of "static" wouldn't exactly be intuitively clear. Maybe something more long-winded like (oh no! hyphenation!) "static-alternate" would do. Or would "static alternate" (and "alternate static" and "static foo alternate",etc., or perhaps "archive alternate", etc.) be better? For backwards compatibility (at least with UAs that don't expect only one value in @rel), "subscribe alternate" (and "alternate subscribe", etc.) could be used rather than simply "subscribe". BTW, am I remembering correctly that "feed" is being promoted for use the way I'm considering "subscribe" above? If it's not already in use, I'd thinK "subscribe" would be much better than "feed", because "feed" could as easily mean "archive feed" as "subscription feed"-- it's just not explicit enough. But perhaps this discussion all belongs in a different venue anyway... But before I end, what about the question of a different media type for entry documents? For the APP accept element issue, it sounds like maybe they do. But for autodiscovery, maybe they don't. Perhaps neither @type nor @rel is the place to distinguish, for example, between the edit links for entries, their parent feeds, their per-entry comment feeds, monolithic comment feeds, etc. (A media type for entry documents would only help with one of those). Perhaps that is the domain of @title (title="Edit this entry", etc.) Do UAs really need to know the difference, or do only the users need to know? Would making that information machine readable be worth the pain involved (rel="edit monolithic parent comments"???) Okay, that's all I can take for now. From owner-atom-syntax@mail.imc.org Sat Dec 02 03:52:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqQc9-0000b7-3c for atompub-archive@lists.ietf.org; Sat, 02 Dec 2006 03:52:53 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqQc4-0006LE-Gs for atompub-archive@lists.ietf.org; Sat, 02 Dec 2006 03:52:53 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB28Y7wi030621; Sat, 2 Dec 2006 01:34:07 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB28Y7oR030620; Sat, 2 Dec 2006 01:34:07 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB28Y48J030614 for ; Sat, 2 Dec 2006 01:34:05 -0700 (MST) (envelope-from duck1123@gmail.com) Received: by nf-out-0910.google.com with SMTP id m18so3291595nfc for ; Sat, 02 Dec 2006 00:34:04 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=hfPf8NYsGE3NOEioxA8uRAAHFNngij8m5D4VCSWAzmnqp1mX9JffOgTSBkunMVuhyOMAEV6qdRMS1cHlTx6MPKJerqaceORGZmN5CtUSjWW1UWVMrdg/C+YF9hgZi3UjQE0PyhiEkhvB388BFvb0cgTVhcrltrNYkGI8WZchK8Q= Received: by 10.82.135.13 with SMTP id i13mr1190611bud.1165048443662; Sat, 02 Dec 2006 00:34:03 -0800 (PST) Received: by 10.82.153.3 with HTTP; Sat, 2 Dec 2006 00:34:03 -0800 (PST) Message-ID: <36bd6e0b0612020034p66bb5431y2dbafdeac406f031@mail.gmail.com> Date: Sat, 2 Dec 2006 03:34:03 -0500 From: "Daniel E. Renfer" To: "Lisa Dusseault" Subject: Re: PaceEntryMediatype Cc: "Kyle Marvin" , "Mark Baker" , "Thomas Broyer" , Atom-Syntax , Atom-Protocol , whatwg@whatwg.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <456DB265.5090804@gmail.com> <192fc9640612010917k4d6cda0ag4ca431f481bb169b@mail.gmail.com> X-Google-Sender-Auth: 34a133aae87d78fd Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b The difference between a collection of entries and a single entry is an important one. Sure, once you get inside the Entry, everything is the same, but knowing ahead of time that you are requesting a single Entry assists in processing. If I'm getting an application/atom.entry+xml I know to use my stylesheet for only a single Entry, whereas when I'm getting an application/atom+xml resource, I know I have a collection containing 1 or more Entries. It's the difference between having a variable, or a list of variables. Imagine a system that uses conneg to give atom representations of a file system. I could request http://www.example.com/db/foo/ and depending on what I put in my accept could determine whether I'm getting back the collection of contents of foo/ or if I'm getting the information on the foo/ folder. There are times when you need to differentiate between the two types when rel="" values are not available. I agree with James that there should also be a different rel="" value to tell the UA what to do with it, but you still need that different type to signal the difference in what it actually is. Since most UA's out there don't really deal with single atom entries as it is right now, and most parsers will have to accept that they might get back only a single entry from an application/atom+xml and the ones that don't understand how to work with a single Entry will just ignore the application/atom.entry+xml link anyway, the impact isn't all that great to clear up this difference in semantics now and for good. Daniel E. Renfer http://kronkltd.net/ On 12/1/06, Lisa Dusseault wrote: > > > Supporting data or ideas: Some interesting links, semantically speaking, > don't even have a fixed MIME type (or not just one, anyhow). If we wanted > to add link relations for photo shares on WebDAV repositories, or personal > calendars on CalDAV repositories, you'd want to point to the URL to the > appropriate WebDAV collection, which could return results in HTML (response > to GET without any special stuff), XML (response to PROPFIND), or iCalendar > (in the CalDAV case). Not sure how to fully convey all of that, but at > least not overloading MIME type with semantic meaning helps the situation. > > Lisa > > > On Dec 1, 2006, at 9:17 AM, Kyle Marvin wrote: > I'm still listening to the debate, but Mark's argument resonates with me. > It seems like 'content-type' is more about the expected syntax of the > resource at the other end of the wire, not it's semantic meaning. I don't > see Atom feeds and entries as syntactically different enough to warrant > unique media types, there's lots of existing parsers that seem able to > navigate this split just fine already. > > I expect that if you associated a 'rel' value with links that point to > "application/atom+xml", whether it is expected to be a feed or an entry > would probably be part of the 'rel' description and thus not ambiguous at > all. I think the discussion started because of the aforementioned issues > with the HTML5 link semantics, which is what should probably be fixed. > > On top of that, the procedural and back compat issues associated with > splitting the mime type now just don't seem to make it a win to me. > > Crazy busy and largely silent, but not completely awol, > > -- Kyle > > On 12/1/06, Mark Baker wrote: > > > > Urgh, sorry for my tardiness; I'm falling behind on my reading. > > > > On 11/30/06, Thomas Broyer wrote: > > > I'd prefer basing autodiscovery on the media types and not at all on > > > the relationships. > > > > All a media type tells you (non-authoritatively too) is the spec you > > need to interpret the document at the other end of the link. That has > > very little to do with the reasons that you might want to follow the > > link, subscribe to it, etc.. Which is why you need a mechanism > > independent from the media type. Like link types. > > > > Consider hAtom. If you went by media types alone, you'd be confronted > with; > > > > > > > > Not particularly useful for subscription (or anything else for that > > matter) is it? This would be better; > > > > > > > > Autodiscovery should ideally be based primarily on link types, and > > only secondarily - as an optimization - on media types. Even this > > should work; > > > > > > > > Mark. > > From owner-atom-syntax@mail.imc.org Sat Dec 02 04:09:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqQrs-0006Ha-RG for atompub-archive@lists.ietf.org; Sat, 02 Dec 2006 04:09:08 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqQrn-0002C4-2t for atompub-archive@lists.ietf.org; Sat, 02 Dec 2006 04:09:08 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB28sM8I031988; Sat, 2 Dec 2006 01:54:22 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB28sMrP031986; Sat, 2 Dec 2006 01:54:22 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.webfaction.com (mail1.webfaction.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB28sKco031975; Sat, 2 Dec 2006 01:54:21 -0700 (MST) (envelope-from sh@defuze.org) Received: from [192.168.1.3] (host81-159-21-245.range81-159.btcentralplus.com [81.159.21.245]) (authenticated bits=0) by mail1.webfaction.com (8.12.11.20060308/8.13.3) with ESMTP id kB28sCkF030849; Sat, 2 Dec 2006 02:54:13 -0600 Message-ID: <45713F2D.2050408@defuze.org> Date: Sat, 02 Dec 2006 08:54:05 +0000 From: Sylvain Hellegouarch User-Agent: Thunderbird 1.5.0.8 (X11/20061117) MIME-Version: 1.0 To: "Daniel E. Renfer" CC: Lisa Dusseault , Kyle Marvin , Mark Baker , Thomas Broyer , Atom-Syntax , Atom-Protocol , whatwg@whatwg.org Subject: Re: PaceEntryMediatype References: <456DB265.5090804@gmail.com> <192fc9640612010917k4d6cda0ag4ca431f481bb169b@mail.gmail.com> <36bd6e0b0612020034p66bb5431y2dbafdeac406f031@mail.gmail.com> In-Reply-To: <36bd6e0b0612020034p66bb5431y2dbafdeac406f031@mail.gmail.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Daniel E. Renfer wrote: > > The difference between a collection of entries and a single entry is > an important one. Sure, once you get inside the Entry, everything is > the same, but knowing ahead of time that you are requesting a single > Entry assists in processing. If I'm getting an > application/atom.entry+xml I know to use my stylesheet for only a > single Entry, whereas when I'm getting an application/atom+xml > resource, I know I have a collection containing 1 or more Entries. > It's the difference between having a variable, or a list of variables. > > Imagine a system that uses conneg to give atom representations of a > file system. I could request http://www.example.com/db/foo/ and > depending on what I put in my accept could determine whether I'm > getting back the collection of contents of foo/ or if I'm getting the > information on the foo/ folder. There are times when you need to > differentiate between the two types when rel="" values are not > available. > > I agree with James that there should also be a different rel="" value > to tell the UA what to do with it, but you still need that different > type to signal the difference in what it actually is. > > Since most UA's out there don't really deal with single atom entries > as it is right now, and most parsers will have to accept that they > might get back only a single entry from an application/atom+xml and > the ones that don't understand how to work with a single Entry will > just ignore the application/atom.entry+xml link anyway, the impact > isn't all that great to clear up this difference in semantics now and > for good. > > Daniel E. Renfer > http://kronkltd.net/ > I wholeheartedly agree with you here. The problem is that so far most of the discussion has been carried from the client side of things without trying to understand the limit of the server side. There are cases where not having a specific media type (or at least a way within the media type to distinguish them) will be a problem. Maybe the impact of those issues is not worth the trouble but if application/atom+xml leads us to the same situation of the unusable application/xml media type then I predict quite mess. My issue here is that most of the discussion has been centered around how an Atom document was consumed until now. With the versatility of Atom and the power of APP it is more than likely that new use of those formats will show up. They may or may not benefit from having several media types. But they will certainly not be hurt by having the choice. Therefore I do believe a new media type should be brought up. - Sylvain From owner-atom-syntax@mail.imc.org Sat Dec 02 10:23:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqWiJ-0002x3-5V for atompub-archive@lists.ietf.org; Sat, 02 Dec 2006 10:23:39 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqWiH-0007UM-PW for atompub-archive@lists.ietf.org; Sat, 02 Dec 2006 10:23:39 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB2F8a5B061437; Sat, 2 Dec 2006 08:08:36 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB2F8ahu061435; Sat, 2 Dec 2006 08:08:36 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.182]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB2F8YBC061422; Sat, 2 Dec 2006 08:08:35 -0700 (MST) (envelope-from algermissen1971@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/8.12.11/smtpout12/MantshX 4.0) with ESMTP id kB2F8HGS008559; Sat, 2 Dec 2006 07:08:19 -0800 (PST) Received: from [85.182.67.137] (e182067137.adsl.alicedsl.de [85.182.67.137]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id kB2F8BNN022016; Sat, 2 Dec 2006 07:08:13 -0800 (PST) In-Reply-To: <45713F2D.2050408@defuze.org> References: <456DB265.5090804@gmail.com> <192fc9640612010917k4d6cda0ag4ca431f481bb169b@mail.gmail.com> <36bd6e0b0612020034p66bb5431y2dbafdeac406f031@mail.gmail.com> <45713F2D.2050408@defuze.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: "Daniel E. Renfer" , Lisa Dusseault , Kyle Marvin , Mark Baker , Thomas Broyer , Atom-Syntax , Atom-Protocol , whatwg@whatwg.org Content-Transfer-Encoding: 7bit From: Jan Algermissen Subject: Re: PaceEntryMediatype Date: Sat, 2 Dec 2006 16:08:32 +0100 To: Sylvain Hellegouarch X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.5 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Maybe this perspective helps: Is there any other media type that covers more than one document type (root element in the case of XML, but could also be non-XML mime types)? It would be interesting to see how those (if any) deal with the issue. An example would maybe be iCalendar, Ithink. Also: If feeds and entries get their own media types, then a feed (consisting essentially of a bunch of entry documents comes pretty close to a multipart/related message - which would make the very existence of the feed media type questionable. And another thought: HTML has in a sense also two processing models within a single mime type (normal body and frames) and does not have a substantial problem with that, does it? Jan From owner-atom-syntax@mail.imc.org Sat Dec 02 12:48:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqYyZ-0002vw-C7 for atompub-archive@lists.ietf.org; Sat, 02 Dec 2006 12:48:35 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqYyX-00006S-W6 for atompub-archive@lists.ietf.org; Sat, 02 Dec 2006 12:48:35 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB2HSZ4Z073209; Sat, 2 Dec 2006 10:28:35 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB2HSZoK073208; Sat, 2 Dec 2006 10:28:35 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB2HSWWi073192 for ; Sat, 2 Dec 2006 10:28:34 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by ug-out-1314.google.com with SMTP id j3so2904954ugf for ; Sat, 02 Dec 2006 09:28:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=uKxWS8bP11Z290TnIb5io6hMtzVnoyOKdf6CmIAp/bv1yXUoS9Q+p/g3PwGq2S482m5ppczFIhptfCq0HYa4ADT4oQ9AM/JDH9krQl11gNtxLzJTGl0d+UawkdczzzxTdsITFj8lRVh7NJ82Ah+OHAyz4xQmGsFce6OZYHc8Zok= Received: by 10.78.203.13 with SMTP id a13mr6012055hug.1165080510906; Sat, 02 Dec 2006 09:28:30 -0800 (PST) Received: from ?192.168.1.101? ( [67.181.218.96]) by mx.google.com with ESMTP id y18sm26403588hua.2006.12.02.09.28.27; Sat, 02 Dec 2006 09:28:30 -0800 (PST) Message-ID: <4571B7B8.9040908@gmail.com> Date: Sat, 02 Dec 2006 09:28:24 -0800 From: James M Snell User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: Jan Algermissen CC: Sylvain Hellegouarch , "Daniel E. Renfer" , Lisa Dusseault , Kyle Marvin , Mark Baker , Thomas Broyer , Atom-Syntax , Atom-Protocol , whatwg@whatwg.org Subject: Re: PaceEntryMediatype References: <456DB265.5090804@gmail.com> <192fc9640612010917k4d6cda0ag4ca431f481bb169b@mail.gmail.com> <36bd6e0b0612020034p66bb5431y2dbafdeac406f031@mail.gmail.com> <45713F2D.2050408@defuze.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Jan Algermissen wrote: > [snip] > Is there any other media type that covers more than one document type > (root element in the case of XML, but could also be non-XML mime types)? > application/xml > It would be interesting to see how those (if any) deal with the issue. > An example would maybe be iCalendar, Ithink. > application/xhtml+xml application/atom+xml ... > > Also: If feeds and entries get their own media types, then a feed > (consisting essentially of a bunch of entry documents comes pretty close > to a multipart/related message - which would make the very existence of > the feed media type questionable. > -1. > > And another thought: HTML has in a sense also two processing models > within a single mime type (normal body and frames) and does not have a > substantial problem with that, does it? > Different issue. Frames and body are both used by the same types of clients for the same purpose (rendering a UI). They just lead to different results. - James From owner-atom-syntax@mail.imc.org Sat Dec 02 22:52:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqiOq-0006tM-KV for atompub-archive@lists.ietf.org; Sat, 02 Dec 2006 22:52:20 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqiOp-00069c-94 for atompub-archive@lists.ietf.org; Sat, 02 Dec 2006 22:52:20 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB33WdXD017444; Sat, 2 Dec 2006 20:32:39 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB33Wd5w017443; Sat, 2 Dec 2006 20:32:39 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB33WZUV017426 for ; Sat, 2 Dec 2006 20:32:38 -0700 (MST) (envelope-from mbaker@gmail.com) Received: by nf-out-0910.google.com with SMTP id m18so3475160nfc for ; Sat, 02 Dec 2006 19:32:35 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=rT9TEPZU28VWCByq/Qx7zplFgIVyttvsBOhIJyzZp/vf+Z3pmnOEXvyxOhrMwFnKr0GM5q1lhsUgzNvBdVj9AGbMCyUNG7ngyFdfSdyWd9/UYSHgoaTiQXD8imyaIPINIlXD4u6KhLmd+KP2GEbj9lM5fsuzx8IucxUZd60dZgo= Received: by 10.78.149.15 with SMTP id w15mr6340257hud.1165116754828; Sat, 02 Dec 2006 19:32:34 -0800 (PST) Received: by 10.78.174.19 with HTTP; Sat, 2 Dec 2006 19:32:34 -0800 (PST) Message-ID: Date: Sat, 2 Dec 2006 22:32:34 -0500 From: "Mark Baker" To: "Daniel E. Renfer" Subject: Re: PaceEntryMediatype Cc: "Lisa Dusseault" , "Kyle Marvin" , "Thomas Broyer" , Atom-Syntax , Atom-Protocol , whatwg@whatwg.org In-Reply-To: <36bd6e0b0612020034p66bb5431y2dbafdeac406f031@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <456DB265.5090804@gmail.com> <192fc9640612010917k4d6cda0ag4ca431f481bb169b@mail.gmail.com> <36bd6e0b0612020034p66bb5431y2dbafdeac406f031@mail.gmail.com> X-Google-Sender-Auth: 7ba6763749f8175a Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 On 12/2/06, Daniel E. Renfer wrote: > The difference between a collection of entries and a single entry is > an important one. Sure, once you get inside the Entry, everything is > the same, but knowing ahead of time that you are requesting a single > Entry assists in processing. But then you're talking about a different resource than the feed, and so should use a different URI than the feed URI. Mark. From owner-atom-syntax@mail.imc.org Sun Dec 03 07:33:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqqXR-00081C-0r for atompub-archive@lists.ietf.org; Sun, 03 Dec 2006 07:33:45 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqqXP-0000FM-Jh for atompub-archive@lists.ietf.org; Sun, 03 Dec 2006 07:33:45 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB3CEPSG054839; Sun, 3 Dec 2006 05:14:25 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB3CEPph054838; Sun, 3 Dec 2006 05:14:25 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB3CENQc054831 for ; Sun, 3 Dec 2006 05:14:24 -0700 (MST) (envelope-from t.broyer@gmail.com) Received: by nf-out-0910.google.com with SMTP id m18so3545227nfc for ; Sun, 03 Dec 2006 04:14:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=at4CdXrLjKtW7AsKbz9TopvPaZhZNqu/YpwIanW/hH1Yx9ukKpgpguo/HISYWaKIHUQl8wq02jsjOQN2rxkPhnvlmiQt1I6g47WfnlxpfjjK572/8y4GTJnxYFw1grsHrNtNerNwVd6r3S72RZXNnhuiGClg6jckA1RreRJpE6A= Received: by 10.49.19.18 with SMTP id w18mr11668766nfi.1165148062251; Sun, 03 Dec 2006 04:14:22 -0800 (PST) Received: by 10.49.28.6 with HTTP; Sun, 3 Dec 2006 04:14:21 -0800 (PST) Message-ID: Date: Sun, 3 Dec 2006 13:14:21 +0100 From: "Thomas Broyer" To: Atom-Syntax Subject: Re: PaceEntryMediatype In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <456DB265.5090804@gmail.com> <192fc9640612010917k4d6cda0ag4ca431f481bb169b@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 2006/12/2, Antone Roundy: > > Now that this has sunk in, it makes a lot of sense--the @rel value > says "you can subscribe to that", Why would I subscribe? is it an alternate representation of what I'm looking at? or the feed containing the article I'm looking at? or a totally distinct resource that might interest me if I'm interested in what I'm looking at (think about blogrolls and the "people who bought this also bought that and that" links)? By saying "you can subscribe to that", you're not describing a relation. Maybe you're describing a facet of the resource the link points to, but is this objective or subjective? If it's meant to be objective, then the media type is enough (am I *able* to subscribe to such a thing), or maybe there's a need for another kind of metadata (I proposed a new 'subscribable' attribute on the WHATWG list). > The media type helps the user agent figure out whether it has > the capability to do those things. For example, a feed reader that > only handles RSS could ignore subscription links to resources of type > "application/atom+xml" (ie. not present the subscription option to > the user). And if an UA has the capability to subscribe to something, why couldn't it provide a mean to subscribe, whichever the relationship? What would be important is to reflect the relationship on the UI so the user have all the information available to choose whether he *wants* to subscribe. > The "subscribe to hAtom feed" case where @type is "text/ > html" might be a little difficult to make a decision on, because > there's no indication of what microformat is being used by the > "feed" (or even if there's a microformat in use at all--maybe it > really is just an HTML page, and "subscribing" to it just means > "watch for changes to the entire document"). ...or it's an HTML5 page making use of the new
element... > One problem that I hadn't really thought clearly about till right now > is that understanding the nature of the think linked TO may require > some understanding of the nature of the thing linked FROM. For > example, an "alternate" link from a typical blog homepage to its feed > really does point to the same thing in an alternative format. Both > are live documents in which new data gets added to the top, and old > data drops off the bottom. But if you don't know that the webpage is > a live document, you wouldn't know whether the link pointed to a > static or live document. "alternate" is perfectly accurate, but it's > not helpful enough. "subscribe" would be much more explicit. Why should it be automated? When you go read a web site every morning because you know it's "live", it's not automated. What you could automate is how to go read that site (e.g. use it as your browser's "start page", or include it in a bunch of bookmarks you "open in tabs" every morning). There's not always a need to automate everything. Things like "whether it'd be interesting to subscribe to something" are better handled by humans than computers. -- Thomas Broyer From owner-atom-syntax@mail.imc.org Sun Dec 03 16:14:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gqyfo-0003NA-IG for atompub-archive@lists.ietf.org; Sun, 03 Dec 2006 16:14:56 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gqyfj-0007Fu-Vz for atompub-archive@lists.ietf.org; Sun, 03 Dec 2006 16:14:56 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB3KxJ5Z008175; Sun, 3 Dec 2006 13:59:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB3KxJlx008174; Sun, 3 Dec 2006 13:59:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from csmtp1.b-one.net (csmtp.b-one.net [195.47.247.21]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB3KxHRb008149; Sun, 3 Dec 2006 13:59:18 -0700 (MST) (envelope-from asbjorn@tigerstaden.no) Received: from quark (72.84-48-117.nextgentel.com [84.48.117.72]) by csmtp1.b-one.net (Postfix) with ESMTP id 5681B1911FB85; Sun, 3 Dec 2006 21:59:11 +0100 (CET) Date: Sun, 03 Dec 2006 22:01:00 +0100 To: "Thomas Broyer" , Atom-Syntax , Atom-Protocol Subject: Re: PaceEntryMediatype From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <456DB265.5090804@gmail.com> Message-ID: In-Reply-To: User-Agent: Opera Mail/9.10 (Win32) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id kB3KxJ5Z008175 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb On Wed, 29 Nov 2006 20:03:22 +0100, Thomas Broyer =20 wrote: > I'd largely prefer augmenting the existing media type with a 'type' =20 > parameter: > - application/atom+xml =3D> either feed or entry (as defined in RFC428= 7) > - application/atom+xml;type=3Dfeed =3D> feed > - application/atom+xml;type=3Dentry =3D> entry +1. > How about defining a "tree" similar to the */vnd.* one? > - application/atom+xml =3D> feed or entry document > - application/atom.categories+xml =3D> category document > - application/atom.service+xml =3D> service document > ...and of course, if this proposal is finally accepted: > - application/atom.entry+xml =3D> entry document I think 'type=3D*' is a cleaner solution, but both serves the same purpos= e =20 so I'm not religious about which solution we choose. But I agree that =20 distinguishing between entries, feeds and every other atom resource is =20 indeed useful. +1. > As for Tim's concerns, I'd also prefer having it done outside the APP. Yep. > Also, the APP draft would need to be updated to remove the "entry" > special value for app:accept, as it would be equivalent to the new or > revised media type (app:accept=3Dapplication/atom+xml;type=3Dentry or > app:accept=3DapplicationAtom.entry+xml) Of course. --=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 Sun Dec 03 16:23:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gqynh-0000dI-Em for atompub-archive@lists.ietf.org; Sun, 03 Dec 2006 16:23:05 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gqynf-0000rG-So for atompub-archive@lists.ietf.org; Sun, 03 Dec 2006 16:23:05 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB3LBE1p008996; Sun, 3 Dec 2006 14:11:14 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB3LBETA008995; Sun, 3 Dec 2006 14:11:14 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from csmtp1.b-one.net (csmtp.b-one.net [195.47.247.21]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB3LB7wL008971; Sun, 3 Dec 2006 14:11:07 -0700 (MST) (envelope-from asbjorn@tigerstaden.no) Received: from quark (72.84-48-117.nextgentel.com [84.48.117.72]) by csmtp1.b-one.net (Postfix) with ESMTP id 72759191168A3; Sun, 3 Dec 2006 22:11:01 +0100 (CET) Date: Sun, 03 Dec 2006 22:12:51 +0100 To: "Kyle Marvin" , "James M Snell" Subject: Re: PaceEntryMediatype From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Cc: "Mark Baker" , "Thomas Broyer" , Atom-Syntax , Atom-Protocol , whatwg@whatwg.org Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <456DB265.5090804@gmail.com> <192fc9640612010917k4d6cda0ag4ca431f481bb169b@mail.gmail.com> <45706C20.6090306@gmail.com> <192fc9640612011042h2f0727b8oaf2cf82708ad9dab@mail.gmail.com> Message-ID: In-Reply-To: <192fc9640612011042h2f0727b8oaf2cf82708ad9dab@mail.gmail.com> User-Agent: Opera Mail/9.10 (Win32) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id kB3LBE1p008996 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 On Fri, 01 Dec 2006 19:42:20 +0100, Kyle Marvin wrot= e: > This points out that the above rel+type don't carry sufficient semantic > meaning to help a UA decide what to do with them. I don't think anyon= e =20 > on this thread is disagreeing with that. This discussion (as I =20 > understand it) is about what to do given that ambiguity. You can =20 > either get more specific with the rel value, with the content-type, or = =20 > with both. The problem with baking the necessary information for this particular use= =20 case inside the 'rel' value is that we possibly need a million different = =20 'rel' values for a million diffierent use cases, or what we'll see is =20 semantic overloading where 'rel' values are abused to mean different =20 things in different use cases and that again will hurt interoperability. Instead, we can let consumers define their own use cases upon the given =20 content type and not push our pre-defined use cases (in the form of 'rel'= =20 values) down their throat because we're too reluctant to expand the MIME = =20 type of atom with a 'type' attribute (or something similar). Are we =20 confident enough about Atom's entire spectre of use cases to say that =20 different 'rel' values are sufficient? I think not. Give consumers the correct content type of the resource =20 instead, and they can themselves decide what to do with it, on the base o= f =20 a more general 'rel' value that don't dictate what they can and can't do = =20 with it. 'rel' values are not sufficient to solve this issue imo. We need= =20 something less fine-grained and more generic. We need to define this at =20 the HTTP level. --=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 Dec 04 14:42:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrJhV-0001iv-ES for atompub-archive@lists.ietf.org; Mon, 04 Dec 2006 14:42:05 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrJhS-00023c-0v for atompub-archive@lists.ietf.org; Mon, 04 Dec 2006 14:42:05 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB4JNTLA062522; Mon, 4 Dec 2006 12:23:29 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB4JNTru062521; Mon, 4 Dec 2006 12:23:29 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.231]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB4JNRBK062503 for ; Mon, 4 Dec 2006 12:23:28 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i20so1329976wra for ; Mon, 04 Dec 2006 11:23:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=pzTbEwf+0XAUJBHz2EhyXCufuUkMQ0cdHZBW8rVGtbZmmGRlogsAveUQw2/xckvn+Kq5gHNwr+29op7Z7lZ5zncOF8nOxzPFb3KT5d5AzMbZsq9lsIVZ4CheWYwm0AC0gzsBEEZU2Ty3Zg7CJ93fxgrz08QeFD5EDY6qDjAiA3U= Received: by 10.100.137.18 with SMTP id k18mr2214898and.1165260204230; Mon, 04 Dec 2006 11:23:24 -0800 (PST) Received: from ?192.168.1.101? ( [67.181.218.96]) by mx.google.com with ESMTP id 15sm6154030wrl.2006.12.04.11.23.22; Mon, 04 Dec 2006 11:23:23 -0800 (PST) Message-ID: <4574759D.1070904@gmail.com> Date: Mon, 04 Dec 2006 11:23:09 -0800 From: James M Snell User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: Mark Baker CC: Sylvain Hellegouarch , Jan Algermissen , atom-protocol , atom-syntax Subject: Re: PaceEntryMediatype References: <456DB265.5090804@gmail.com> <456E7DE0.8040002@gmail.com> <456EF996.7060009@defuze.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c And therein lies the problem: entry documents are NOT aliases for single-entry feeds. - James Mark Baker wrote: > [snip] > True, but if entry documents are more or less aliases for single-entry > feeds, why would anybody need to negotiate for one or the other? I > suggest that would have to be pretty obscure use case. 8-) > > Mark. > From owner-atom-syntax@mail.imc.org Mon Dec 04 15:39:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrKaw-0000F4-VH for atompub-archive@lists.ietf.org; Mon, 04 Dec 2006 15:39:22 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrKat-0001qL-K6 for atompub-archive@lists.ietf.org; Mon, 04 Dec 2006 15:39:22 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB4KFNiX070105; Mon, 4 Dec 2006 13:15:23 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB4KFNrw070102; Mon, 4 Dec 2006 13:15:23 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB4KFLtJ070084 for ; Mon, 4 Dec 2006 13:15:22 -0700 (MST) (envelope-from mbaker@gmail.com) Received: by ug-out-1314.google.com with SMTP id j3so3387831ugf for ; Mon, 04 Dec 2006 12:15:20 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=SzJWnmulZAfEXM4bUbbr/6lWYatDyGJ6bKsgxha+nrE1Jp9V2PwweyjXMZzcfJRqHLtF/BzN144PeKCzWtbo2XWQS3szf/7sMtef6pqoyOFsD8RWXs38S/k3mVoSg4tLNfbmWsKqL9+QiyFozBbKHX6rFnauhip2La/pa/Gbd+g= Received: by 10.78.201.15 with SMTP id y15mr8062814huf.1165263319729; Mon, 04 Dec 2006 12:15:19 -0800 (PST) Received: by 10.78.174.19 with HTTP; Mon, 4 Dec 2006 12:15:19 -0800 (PST) Message-ID: Date: Mon, 4 Dec 2006 15:15:19 -0500 From: "Mark Baker" To: "James M Snell" Subject: Re: PaceEntryMediatype Cc: atom-protocol , atom-syntax In-Reply-To: <4574759D.1070904@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <456DB265.5090804@gmail.com> <456E7DE0.8040002@gmail.com> <456EF996.7060009@defuze.org> <4574759D.1070904@gmail.com> X-Google-Sender-Auth: ebc475f025d1015c Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 I'd be happy to believe you James, if I could find where in the spec that was stated. If it looks like an alias, and acts like an alias ... 8-) Mark. On 12/4/06, James M Snell wrote: > And therein lies the problem: entry documents are NOT aliases for > single-entry feeds. > > - James > > Mark Baker wrote: > > [snip] > > True, but if entry documents are more or less aliases for single-entry > > feeds, why would anybody need to negotiate for one or the other? I > > suggest that would have to be pretty obscure use case. 8-) > > > > Mark. > > > From owner-atom-syntax@mail.imc.org Mon Dec 04 15:58:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrKtB-0005JP-AS for atompub-archive@lists.ietf.org; Mon, 04 Dec 2006 15:58:13 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrKsu-0006kU-Cd for atompub-archive@lists.ietf.org; Mon, 04 Dec 2006 15:58:13 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB4KXDCf073041; Mon, 4 Dec 2006 13:33:13 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB4KXDcp073038; Mon, 4 Dec 2006 13:33:13 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.webfaction.com (mail1.webfaction.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB4KXBGt073025; Mon, 4 Dec 2006 13:33:11 -0700 (MST) (envelope-from sh@defuze.org) Received: from [192.168.1.3] (host81-159-21-245.range81-159.btcentralplus.com [81.159.21.245]) (authenticated bits=0) by mail1.webfaction.com (8.12.11.20060308/8.13.3) with ESMTP id kB4KX2E5016811; Mon, 4 Dec 2006 14:33:06 -0600 Message-ID: <457485F6.2070906@defuze.org> Date: Mon, 04 Dec 2006 20:32:54 +0000 From: Sylvain Hellegouarch User-Agent: Thunderbird 1.5.0.8 (X11/20061117) MIME-Version: 1.0 To: Mark Baker CC: James M Snell , atom-protocol , atom-syntax Subject: Re: PaceEntryMediatype References: <456DB265.5090804@gmail.com> <456E7DE0.8040002@gmail.com> <456EF996.7060009@defuze.org> <4574759D.1070904@gmail.com> In-Reply-To: X-Enigmail-Version: 0.94.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: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Mark Baker wrote: > > I'd be happy to believe you James, if I could find where in the spec > that was stated. Neither does it state they are a 1-to-1 relationship. > > If it looks like an alias, and acts like an alias ... 8-) > Calling them aliases won't make them necessarily aliases. I find unfortunate that RFC 4287 doesn't actually precise that particular point. We only have one media type and no clear definition of the distinction between an entry element and an entry document. So we have this discussion. - Sylvain From owner-atom-syntax@mail.imc.org Mon Dec 04 15:58:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrKtB-0005Jq-W5 for atompub-archive@lists.ietf.org; Mon, 04 Dec 2006 15:58:13 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrKsv-0006lV-45 for atompub-archive@lists.ietf.org; Mon, 04 Dec 2006 15:58:13 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB4KZVTO073337; Mon, 4 Dec 2006 13:35:31 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB4KZVHP073336; Mon, 4 Dec 2006 13:35:31 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.232]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB4KZSIA073320 for ; Mon, 4 Dec 2006 13:35:31 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i20so1350020wra for ; Mon, 04 Dec 2006 12:35:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=cE8QJLCJ5WFG4AZq9H22rEizoyB+mHLq/UVuQuhOhEnhfjKBV54QuGpp4CU57Mh6W5p8iKaJBDG7SZabzbY4mXSK3JLIWaJlPnb+F3hv6CBtRnY7UfaMS9Oc8zamDT0b7ka3vby2E1SGV3PTU+Vs2IFaYifEJskOVGfPrP+aVVM= Received: by 10.90.51.17 with SMTP id y17mr8645226agy.1165264527389; Mon, 04 Dec 2006 12:35:27 -0800 (PST) Received: from ?192.168.1.101? ( [67.181.218.96]) by mx.google.com with ESMTP id 14sm4769479wrl.2006.12.04.12.35.25; Mon, 04 Dec 2006 12:35:26 -0800 (PST) Message-ID: <45748679.70602@gmail.com> Date: Mon, 04 Dec 2006 12:35:05 -0800 From: James M Snell User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: Mark Baker CC: atom-protocol , atom-syntax Subject: Re: PaceEntryMediatype References: <456DB265.5090804@gmail.com> <456E7DE0.8040002@gmail.com> <456EF996.7060009@defuze.org> <4574759D.1070904@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 All I can go on is evidence of how folks are actually using 'em... and they ain't using 'em as aliases. :-) - James Mark Baker wrote: > I'd be happy to believe you James, if I could find where in the spec > that was stated. > > If it looks like an alias, and acts like an alias ... 8-) > > Mark. > > On 12/4/06, James M Snell wrote: >> And therein lies the problem: entry documents are NOT aliases for >> single-entry feeds. >> >> - James >> >> Mark Baker wrote: >> > [snip] >> > True, but if entry documents are more or less aliases for single-entry >> > feeds, why would anybody need to negotiate for one or the other? I >> > suggest that would have to be pretty obscure use case. 8-) >> > >> > Mark. >> > >> > From owner-atom-syntax@mail.imc.org Mon Dec 04 16:32:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrLQD-0004tb-6A for atompub-archive@lists.ietf.org; Mon, 04 Dec 2006 16:32:21 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrLQB-0004NP-R7 for atompub-archive@lists.ietf.org; Mon, 04 Dec 2006 16:32:21 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB4LD4sp078607; Mon, 4 Dec 2006 14:13:04 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB4LD4UG078606; Mon, 4 Dec 2006 14:13:04 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB4LD0va078589 for ; Mon, 4 Dec 2006 14:13:03 -0700 (MST) (envelope-from mbaker@gmail.com) Received: by ug-out-1314.google.com with SMTP id j3so3404343ugf for ; Mon, 04 Dec 2006 13:13:00 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Px6PxFBj7yrf8EXNBTQCp+C97Ehe27v6kkctXgx21rBLQBhio9ioSKxN+8ENa6NFK8+digispvoDInVs1CQjr5yYefbTwzE5EooUtuJfIrZlZwVHQZ6FOKCH+TTPxKoT2rts5Klo+U2jFBlE/O1awylxcMjXKNTgWEn20sPKxHE= Received: by 10.78.201.2 with SMTP id y2mr8096033huf.1165266779769; Mon, 04 Dec 2006 13:12:59 -0800 (PST) Received: by 10.78.174.19 with HTTP; Mon, 4 Dec 2006 13:12:59 -0800 (PST) Message-ID: Date: Mon, 4 Dec 2006 16:12:59 -0500 From: "Mark Baker" To: "James M Snell" Subject: Re: PaceEntryMediatype Cc: atom-protocol , atom-syntax In-Reply-To: <45748679.70602@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <456DB265.5090804@gmail.com> <456E7DE0.8040002@gmail.com> <456EF996.7060009@defuze.org> <4574759D.1070904@gmail.com> <45748679.70602@gmail.com> X-Google-Sender-Auth: 271994bac47f82a4 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 On 12/4/06, James M Snell wrote: > All I can go on is evidence of how folks are actually using 'em... and > they ain't using 'em as aliases. :-) Ok, I'll take empirical evidence too 8-) Point the way ... Mark. From owner-atom-syntax@mail.imc.org Tue Dec 05 15:22:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrgoX-0007wg-76 for atompub-archive@lists.ietf.org; Tue, 05 Dec 2006 15:22:53 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrgoV-00081J-RU for atompub-archive@lists.ietf.org; Tue, 05 Dec 2006 15:22:53 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB5K4Q1H040296; Tue, 5 Dec 2006 13:04:26 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB5K4Qjq040294; Tue, 5 Dec 2006 13:04:26 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB5K4NtE040281; Tue, 5 Dec 2006 13:04:26 -0700 (MST) (envelope-from algermissen1971@mac.com) Received: from mac.com (smtpin06-en2 [10.13.10.151]) by smtpout.mac.com (Xserve/8.12.11/smtpout03/MantshX 4.0) with ESMTP id kB5K4pvW009109; Tue, 5 Dec 2006 12:04:51 -0800 (PST) Received: from [10.0.1.2] (e176048248.adsl.alicedsl.de [85.176.48.248]) (authenticated bits=0) by mac.com (Xserve/smtpin06/MantshX 4.0) with ESMTP id kB5K4GK9012833; Tue, 5 Dec 2006 12:04:18 -0800 (PST) In-Reply-To: References: <456DB265.5090804@gmail.com> <456E7DE0.8040002@gmail.com> <456EF996.7060009@defuze.org> <4574759D.1070904@gmail.com> <45748679.70602@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: James M Snell , atom-protocol , atom-syntax Content-Transfer-Encoding: 7bit From: Jan Algermissen Subject: Re: PaceEntryMediatype Date: Tue, 5 Dec 2006 21:04:39 +0100 To: Mark Baker X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.5 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 On Dec 4, 2006, at 10:12 PM, Mark Baker wrote: > > On 12/4/06, James M Snell wrote: >> All I can go on is evidence of how folks are actually using 'em... >> and >> they ain't using 'em as aliases. :-) > > Ok, I'll take empirical evidence too 8-) Point the way ... Question: what does it mean (what do we have to look for) to use them as aliases?? Jan > > Mark. > From owner-atom-syntax@mail.imc.org Tue Dec 05 15:36:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grh1h-0005af-Up for atompub-archive@lists.ietf.org; Tue, 05 Dec 2006 15:36:29 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Grh1g-00021K-Ep for atompub-archive@lists.ietf.org; Tue, 05 Dec 2006 15:36:29 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB5KGIsT041215; Tue, 5 Dec 2006 13:16:18 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB5KGI3V041214; Tue, 5 Dec 2006 13:16:18 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.230]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB5KGHIR041198 for ; Tue, 5 Dec 2006 13:16:17 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i20so1574300wra for ; Tue, 05 Dec 2006 12:16:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Y1svdsHj3c/WjyhtF75qig4aXsB7Vf31yPGvQ4S7he9XCDiCg5GaOQXbJrI1K13KYzwr+f8eHs770HzPzkp4EbCiUesnYfARFvsbuj2EgRqXXuqSj4hoiylYI9dvsSy0NBEV2YwpTG96/LIwwbb0qz1bllb6Dxt4dWEt3AAiKy8= Received: by 10.90.50.1 with SMTP id x1mr10098941agx.1165349774578; Tue, 05 Dec 2006 12:16:14 -0800 (PST) Received: from ?192.168.1.101? ( [67.181.218.96]) by mx.google.com with ESMTP id 15sm9538002wrl.2006.12.05.12.16.12; Tue, 05 Dec 2006 12:16:14 -0800 (PST) Message-ID: <4575D37D.8080909@gmail.com> Date: Tue, 05 Dec 2006 12:15:57 -0800 From: James M Snell User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: Mark Baker CC: atom-protocol , atom-syntax Subject: Re: PaceEntryMediatype References: <456DB265.5090804@gmail.com> <456E7DE0.8040002@gmail.com> <456EF996.7060009@defuze.org> <4574759D.1070904@gmail.com> <45748679.70602@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 When I process this entry, http://www.google.com/calendar/feeds/jasnell%40gmail.com/public/basic/10ge5k2k7c488algfbau5q9qc0 What is the implied feed? Where do I get the implied feeds metadata? Title? ID? Anything? If the entry contained an atom:source element you might be able to assume that a logical feed is implied but absent any other evidence, this is a standalone entry document that can be processed without any assumption that a feed exists. - James Mark Baker wrote: > On 12/4/06, James M Snell wrote: >> All I can go on is evidence of how folks are actually using 'em... and >> they ain't using 'em as aliases. :-) > > Ok, I'll take empirical evidence too 8-) Point the way ... > > Mark. > From owner-atom-syntax@mail.imc.org Tue Dec 05 16:23:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrhlE-0006GI-8t for atompub-archive@lists.ietf.org; Tue, 05 Dec 2006 16:23:32 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrhlC-000862-IP for atompub-archive@lists.ietf.org; Tue, 05 Dec 2006 16:23:32 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB5LAaXl047287; Tue, 5 Dec 2006 14:10:36 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB5LAa9U047286; Tue, 5 Dec 2006 14:10:36 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.175]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB5LAZHl047276; Tue, 5 Dec 2006 14:10:36 -0700 (MST) (envelope-from algermissen1971@mac.com) Received: from mac.com (smtpin06-en2 [10.13.10.151]) by smtpout.mac.com (Xserve/8.12.11/smtpout05/MantshX 4.0) with ESMTP id kB5LAWSI015015; Tue, 5 Dec 2006 13:10:32 -0800 (PST) Received: from [10.0.1.2] (e176048248.adsl.alicedsl.de [85.176.48.248]) (authenticated bits=0) by mac.com (Xserve/smtpin06/MantshX 4.0) with ESMTP id kB5LAS1p011642; Tue, 5 Dec 2006 13:10:29 -0800 (PST) In-Reply-To: <4575D37D.8080909@gmail.com> References: <456DB265.5090804@gmail.com> <456E7DE0.8040002@gmail.com> <456EF996.7060009@defuze.org> <4574759D.1070904@gmail.com> <45748679.70602@gmail.com> <4575D37D.8080909@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <82C2B52A-0420-4EDE-9C1A-D679B0453759@mac.com> Cc: Mark Baker , atom-protocol , atom-syntax Content-Transfer-Encoding: 7bit From: Jan Algermissen Subject: Re: PaceEntryMediatype Date: Tue, 5 Dec 2006 22:10:50 +0100 To: James M Snell X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.5 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 On Dec 5, 2006, at 9:15 PM, James M Snell wrote: > > When I process this entry, > > http://www.google.com/calendar/feeds/jasnell%40gmail.com/public/ > basic/10ge5k2k7c488algfbau5q9qc0 Funny, Safari switches to feed://www.google.com.... :-) And then says it cannot process the entity (presumably because it is an ). Jan From owner-atom-syntax@mail.imc.org Tue Dec 05 16:24:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrhmU-0006xR-0F for atompub-archive@lists.ietf.org; Tue, 05 Dec 2006 16:24:50 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrhmQ-0008HC-Gz for atompub-archive@lists.ietf.org; Tue, 05 Dec 2006 16:24:49 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB5L9FBu047189; Tue, 5 Dec 2006 14:09:15 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB5L9FmP047188; Tue, 5 Dec 2006 14:09:15 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB5L9Era047182 for ; Tue, 5 Dec 2006 14:09:15 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.2.180] (unknown [83.70.238.233]) by chilco.textdrive.com (Postfix) with ESMTP id 7714FDC5D0 for ; Tue, 5 Dec 2006 21:09:07 +0000 (UTC) Message-ID: <4575DFEF.7010906@dehora.net> Date: Tue, 05 Dec 2006 21:09:03 +0000 From: Bill de hOra User-Agent: Thunderbird 1.5.0.8 (X11/20061117) MIME-Version: 1.0 To: atom-syntax Subject: Re: PaceEntryMediatype References: <456DB265.5090804@gmail.com> <456E7DE0.8040002@gmail.com> <456EF996.7060009@defuze.org> <4574759D.1070904@gmail.com> <45748679.70602@gmail.com> In-Reply-To: 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: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Mark Baker wrote: > > On 12/4/06, James M Snell wrote: >> All I can go on is evidence of how folks are actually using 'em... and >> they ain't using 'em as aliases. :-) > > Ok, I'll take empirical evidence too 8-) Point the way ... Mark, since you introduced it, what's an "alias", exactly? cheers Bill From owner-atom-syntax@mail.imc.org Tue Dec 05 16:25:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrhnY-00006U-K3 for atompub-archive@lists.ietf.org; Tue, 05 Dec 2006 16:25:56 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrhnX-0008Ms-7G for atompub-archive@lists.ietf.org; Tue, 05 Dec 2006 16:25:56 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB5LBJHP047349; Tue, 5 Dec 2006 14:11:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB5LBJSE047348; Tue, 5 Dec 2006 14:11:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB5LBIBt047342 for ; Tue, 5 Dec 2006 14:11:18 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.2.180] (unknown [83.70.238.233]) by chilco.textdrive.com (Postfix) with ESMTP id CC2CBDC756 for ; Tue, 5 Dec 2006 21:11:12 +0000 (UTC) Message-ID: <4575E06D.1080905@dehora.net> Date: Tue, 05 Dec 2006 21:11:09 +0000 From: Bill de hOra User-Agent: Thunderbird 1.5.0.8 (X11/20061117) MIME-Version: 1.0 To: atom-syntax Subject: Re: PaceEntryMediatype References: <456DB265.5090804@gmail.com> <456E7DE0.8040002@gmail.com> <456EF996.7060009@defuze.org> <4574759D.1070904@gmail.com> <45748679.70602@gmail.com> <4575D37D.8080909@gmail.com> In-Reply-To: <4575D37D.8080909@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: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 James M Snell wrote: > When I process this entry, > > http://www.google.com/calendar/feeds/jasnell%40gmail.com/public/basic/10ge5k2k7c488algfbau5q9qc0 I had problems subscribing to that entry in bloglines. Will somebody file a bug? cheers Bill From owner-atom-syntax@mail.imc.org Tue Dec 05 16:29:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrhrR-000398-0O for atompub-archive@lists.ietf.org; Tue, 05 Dec 2006 16:29:57 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrhrP-0000Qe-Kb for atompub-archive@lists.ietf.org; Tue, 05 Dec 2006 16:29:56 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB5LGqmN047788; Tue, 5 Dec 2006 14:16:52 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB5LGq95047787; Tue, 5 Dec 2006 14:16:52 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.235]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB5LGp85047780 for ; Tue, 5 Dec 2006 14:16:52 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i20so1589419wra for ; Tue, 05 Dec 2006 13:16:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=QxTqKgmwC2HZXc/2C23aypH9E2iV95DC0y3Eyu8snHnTviCYZNHFmNQwap8lXOc5LD+PyGhWDs0+loXi3p+AgguxdXGCvLBdr/mQIcB0/O1PumkG+6VkDRHXXRhcKsGuZ5dvnnLdowq+WTtOo8u5JN2i09mqed4xkPeEVKgt8g4= Received: by 10.90.63.16 with SMTP id l16mr10117709aga.1165353411013; Tue, 05 Dec 2006 13:16:51 -0800 (PST) Received: from ?192.168.1.101? ( [67.181.218.96]) by mx.google.com with ESMTP id 9sm5588031wrl.2006.12.05.13.16.48; Tue, 05 Dec 2006 13:16:49 -0800 (PST) Message-ID: <4575E1A7.1040806@gmail.com> Date: Tue, 05 Dec 2006 13:16:23 -0800 From: James M Snell User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: Jan Algermissen CC: Mark Baker , atom-protocol , atom-syntax Subject: Re: PaceEntryMediatype References: <456DB265.5090804@gmail.com> <456E7DE0.8040002@gmail.com> <456EF996.7060009@defuze.org> <4574759D.1070904@gmail.com> <45748679.70602@gmail.com> <4575D37D.8080909@gmail.com> <82C2B52A-0420-4EDE-9C1A-D679B0453759@mac.com> In-Reply-To: <82C2B52A-0420-4EDE-9C1A-D679B0453759@mac.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Indeed. The application was written to expect a feed because of the content-type but gets an entry instead and blows up. - James Jan Algermissen wrote: > > On Dec 5, 2006, at 9:15 PM, James M Snell wrote: > >> >> When I process this entry, >> >> http://www.google.com/calendar/feeds/jasnell%40gmail.com/public/basic/10ge5k2k7c488algfbau5q9qc0 >> > > Funny, Safari switches to feed://www.google.com.... :-) > > And then says it cannot process the entity (presumably because it is an > ). > > Jan > > > > From owner-atom-syntax@mail.imc.org Tue Dec 05 21:42:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrmjW-00082D-Ok for atompub-archive@lists.ietf.org; Tue, 05 Dec 2006 21:42:06 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrmjV-0006c9-Cm for atompub-archive@lists.ietf.org; Tue, 05 Dec 2006 21:42:06 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB62Jln5079156; Tue, 5 Dec 2006 19:19:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB62Jlse079155; Tue, 5 Dec 2006 19:19:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from leucothea.site5.com (leucothea.redline.site5.com [216.118.97.161]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB62JkHQ079147 for ; Tue, 5 Dec 2006 19:19:47 -0700 (MST) (envelope-from fantasai.lists@inkedblade.net) Received: from 121-72-128-96.dsl.telstraclear.net ([121.72.128.96] helo=[10.1.1.4]) by leucothea.site5.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.52) id 1GrmNs-00020w-HG for atom-syntax@imc.org; Tue, 05 Dec 2006 21:19:44 -0500 Message-ID: <457628B7.6050605@inkedblade.net> Date: Tue, 05 Dec 2006 21:19:35 -0500 From: fantasai User-Agent: Thunderbird 1.5.0.8 (X11/20061117) MIME-Version: 1.0 To: Atom Syntax Subject: Re: PaceAutoDiscoveryDraftIsPointless References: <456C65AF.1080609@gmail.com> <456C6C81.4070600@lachy.id.au> <456C713B.4090203@gmail.com> <456C7B0D.2060908@mozilla.com> <456C80DB.8060705@gmail.com> <456C8470.1050007@mozilla.com> <456C8864.5000607@gmail.com> <456C8CA5.60200@mozilla.com> <86hcwjbabh.fsf@rakim.cfhp.org> In-Reply-To: <86hcwjbabh.fsf@rakim.cfhp.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: This message has been scanned by ClamAV. X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - leucothea.site5.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - inkedblade.net X-Source: X-Source-Args: X-Source-Dir: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Edward O'Connor wrote: > Robert Sayre wrote: >> Don't move forward with the autodiscovery draft. > [...] >> At this point there seems to be no reason for the autodiscovery draft >> to exist, since the WHAT-WG has ably covered the subject in Web >> Applications 1.0. > > I am worried that there are three simultaneous efforts to spec out feed > autodiscovery: WA1, the RSS board's recent spec, and this draft. Ideally > this stuff would get specced just once. WHAT WG seems like a neutral > ground, syndication-format wise, so perhaps they're best positioned to > spec feed autodiscovery in a way that makes everybody happy. +1 to speccing this through the WHAT-WG. I'm sure Ian would be happy to address any concerns brought up by this community. ~fantasai From owner-atom-syntax@mail.imc.org Tue Dec 05 23:35:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GroVP-0006dS-Vs for atompub-archive@lists.ietf.org; Tue, 05 Dec 2006 23:35:39 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GroVN-0002TS-K8 for atompub-archive@lists.ietf.org; Tue, 05 Dec 2006 23:35:39 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB64MROQ090410; Tue, 5 Dec 2006 21:22:27 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB64MR6V090407; Tue, 5 Dec 2006 21:22:27 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB64MPrR090383 for ; Tue, 5 Dec 2006 21:22:26 -0700 (MST) (envelope-from mbaker@gmail.com) Received: by ug-out-1314.google.com with SMTP id j3so33254ugf for ; Tue, 05 Dec 2006 20:22:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=P6ov4gWPAFtenMTYOvDRUoz7Rg2TVLes6OL0vtiFp52t8zXU6p6crjPCTilj2LNVH/5k521xJhFODe2MHWYMY9HJSbaVY32n0Q7gIxqOPj53f/EZSH4Opq3pds2TrRHptpJheVLJHJ3cCTF6AHNXP5GqMd9pOjwYvd/3/DEJZEE= Received: by 10.78.200.3 with SMTP id x3mr184045huf.1165378944500; Tue, 05 Dec 2006 20:22:24 -0800 (PST) Received: by 10.78.174.19 with HTTP; Tue, 5 Dec 2006 20:22:24 -0800 (PST) Message-ID: Date: Tue, 5 Dec 2006 23:22:24 -0500 From: "Mark Baker" To: "Jan Algermissen" Subject: Re: PaceEntryMediatype Cc: "James M Snell" , atom-protocol , atom-syntax In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <456DB265.5090804@gmail.com> <456E7DE0.8040002@gmail.com> <456EF996.7060009@defuze.org> <4574759D.1070904@gmail.com> <45748679.70602@gmail.com> X-Google-Sender-Auth: 8185c1e0ee73ca1e Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad On 12/5/06, Jan Algermissen wrote: > Question: what does it mean (what do we have to look for) to use them > as aliases?? It wasn't the most illustrative choice of words, but what I'm looking for is evidence that an entry is interpreted differently if it's found in an entry document, than if it were found in a feed document. If we turn up multiple interoperable examples of that, then a new media type is warranted because it's really two formats masquerading as one. Mark. From owner-atom-syntax@mail.imc.org Tue Dec 05 23:50:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grojq-00048w-7q for atompub-archive@lists.ietf.org; Tue, 05 Dec 2006 23:50:34 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Grojn-00065K-S2 for atompub-archive@lists.ietf.org; Tue, 05 Dec 2006 23:50:34 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB64b0mH091740; Tue, 5 Dec 2006 21:37:00 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB64b0JP091739; Tue, 5 Dec 2006 21:37:00 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB64awwF091731 for ; Tue, 5 Dec 2006 21:36:59 -0700 (MST) (envelope-from mbaker@gmail.com) Received: by ug-out-1314.google.com with SMTP id j3so36493ugf for ; Tue, 05 Dec 2006 20:36:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=idk+7px05+zGCxOF9/SBvFb8Ygzdu5nPQPbc5pU1oGktg5gfmjBa0rkVZ6nR5DiiCyFfrzVwZvGYDjozzaZ36x4JqQABVs0QoPf5xNwMup0LfhHl6m1i1/KmSv0pUVLwyVaRPVszYWkG5eo13cR4oETYYeYBKmnu2gbcNRwSSRY= Received: by 10.78.138.6 with SMTP id l6mr163269hud.1165379817725; Tue, 05 Dec 2006 20:36:57 -0800 (PST) Received: by 10.78.174.19 with HTTP; Tue, 5 Dec 2006 20:36:57 -0800 (PST) Message-ID: Date: Tue, 5 Dec 2006 23:36:57 -0500 From: "Mark Baker" To: "James M Snell" Subject: Re: PaceEntryMediatype Cc: atom-protocol , atom-syntax In-Reply-To: <4575D37D.8080909@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <456DB265.5090804@gmail.com> <456E7DE0.8040002@gmail.com> <456EF996.7060009@defuze.org> <4574759D.1070904@gmail.com> <45748679.70602@gmail.com> <4575D37D.8080909@gmail.com> X-Google-Sender-Auth: 85660966a6e91e2b Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab On 12/5/06, James M Snell wrote: > When I process this entry, > > http://www.google.com/calendar/feeds/jasnell%40gmail.com/public/basic/10ge5k2k7c488algfbau5q9qc0 > > What is the implied feed? Where do I get the implied feeds metadata? > Title? ID? Anything? If the entry contained an atom:source element you > might be able to assume that a logical feed is implied but absent any > other evidence, this is a standalone entry document that can be > processed without any assumption that a feed exists. Ok, but I don't see that this would necessitate a new media type. It's just an entry without a feed. You'd use the same code path to process that entry whether it were found in an entry or feed document, right? Sorry if I wasn't clear what I was looking for earlier by my use of the word "alias". Mark. From owner-atom-syntax@mail.imc.org Wed Dec 06 00:09:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grp2W-0004Xb-Lq for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 00:09:52 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Grp2V-00037B-9f for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 00:09:52 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB64qHBL092750; Tue, 5 Dec 2006 21:52:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB64qHt4092749; Tue, 5 Dec 2006 21:52:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.237]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB64qGYT092742 for ; Tue, 5 Dec 2006 21:52:16 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id i30so91631wxd for ; Tue, 05 Dec 2006 20:52:15 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=VDEIOyMCuiavE7KI6f5lofqg7L9x0Wy2iO1b+QXnv9txjZjxv/KLOWlhNqMLqIc9YLsiY/hbkiXFBq8g7500o/SLntBJ4mvKgEXaKfPyqoPBl8D5jmPJTd9lqWM4RONmhDxDMAJlo9eH6cXYqnWH0kqW/xtjU4sAHGaAw9tO49s= Received: by 10.70.29.14 with SMTP id c14mr563976wxc.1165380735172; Tue, 05 Dec 2006 20:52:15 -0800 (PST) Received: from ?192.168.1.101? ( [67.181.218.96]) by mx.google.com with ESMTP id 66sm6869596wra.2006.12.05.20.52.13; Tue, 05 Dec 2006 20:52:14 -0800 (PST) Message-ID: <45764C7A.5040008@gmail.com> Date: Tue, 05 Dec 2006 20:52:10 -0800 From: James M Snell User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: Mark Baker CC: atom-protocol , atom-syntax Subject: Re: PaceEntryMediatype References: <456DB265.5090804@gmail.com> <456E7DE0.8040002@gmail.com> <456EF996.7060009@defuze.org> <4574759D.1070904@gmail.com> <45748679.70602@gmail.com> <4575D37D.8080909@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Mark Baker wrote: > [snip] > Ok, but I don't see that this would necessitate a new media type. > It's just an entry without a feed. You'd use the same code path to > process that entry whether it were found in an entry or feed document, > right? > Not necessarily. Sure, it might be the same parser code, but not necessarily the same bit of code using the parser. Look at the way Firefox, IE7, Bloglines, Liferea, etc all handle (or don't handle) Entry documents versus Feed documents. The majority of applications that most frequently handle Atom Feed Documents have no idea how to deal with Atom Entry Documents and I would wager that most applications that understand how to process Atom Entry Documents and Atom Feed Documents typically don't fall into the same category as most feed readers. - James From owner-atom-syntax@mail.imc.org Wed Dec 06 00:29:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrpLP-0004D6-1z for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 00:29:23 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrpLL-0000k8-Li for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 00:29:23 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB65DMEf094251; Tue, 5 Dec 2006 22:13:22 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB65DMN9094250; Tue, 5 Dec 2006 22:13:22 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironclad.net.au ([203.30.247.11]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id kB65DKwn094240 for ; Tue, 5 Dec 2006 22:13:21 -0700 (MST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.118] (HELO [192.168.1.2]) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.0007390887 for ; Wed, 06 Dec 2006 16:13:16 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 06 Dec 2006 16:13:17 +1100 Subject: Re: PaceEntryMediatype From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <45764C7A.5040008@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: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 On 6/12/06 3:52 PM, "James M Snell" wrote: > Not necessarily. Sure, it might be the same parser code, but not > necessarily the same bit of code using the parser. Look at the way > Firefox, IE7, Bloglines, Liferea, etc all handle (or don't handle) Entry > documents versus Feed documents. The majority of applications that most > frequently handle Atom Feed Documents have no idea how to deal with Atom > Entry Documents and I would wager that most applications that understand > how to process Atom Entry Documents and Atom Feed Documents typically > don't fall into the same category as most feed readers. If an agent found an entry document, should it assume that it's a feed with one entry (so far) and allocate resources accordingly (ie. allow for cardinality of n++)? If an agent found an entry document, and then later returned to find a feed containing multiple entries, would it consider that a problem? Would an agent finding multiple atom:content elements inside the one entry consider that a problem (other than it being a spec violation)? Are XML processors optimised for the fact that any given attribute can only occur once per element, and not twice or more .. eg. ? e. From owner-atom-syntax@mail.imc.org Wed Dec 06 00:42:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrpXk-0001Vi-Ng for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 00:42:08 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrpXf-0002oi-V9 for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 00:42:08 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB65R4tU095477; Tue, 5 Dec 2006 22:27:04 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB65R49g095476; Tue, 5 Dec 2006 22:27:04 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mcom.com (c3po.aoltw.net [64.236.137.25]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB65R2kj095462; Tue, 5 Dec 2006 22:27:03 -0700 (MST) (envelope-from jpanzer@aol.net) Received: from areophany.nscp.aoltw.net (areophany.nscp.aoltw.net [10.169.155.201]) by mcom.com (8.10.0/8.10.0) with ESMTP id kB65QdW09610; Tue, 5 Dec 2006 21:26:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by areophany.nscp.aoltw.net (Postfix) with ESMTP id B907FBE1EB; Tue, 5 Dec 2006 21:26:39 -0800 (PST) Received: from areophany.nscp.aoltw.net ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26646-09; Tue, 5 Dec 2006 21:26:38 -0800 (PST) Received: from [10.169.186.21] (sera-10-169-186-21.nscp.aoltw.net [10.169.186.21]) by areophany.nscp.aoltw.net (Postfix) with ESMTP id 2A5E0BE1DC; Tue, 5 Dec 2006 21:26:37 -0800 (PST) Message-ID: <4576548B.9040008@aol.net> Date: Tue, 05 Dec 2006 21:26:35 -0800 From: John Panzer User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault Cc: Henry Story , Atom Protocol , Atom Subject: Re: In San Francisco/Bay Area References: <20061201120233.Y74708@bblfish.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030804000904080204010807" X-Spam-Status: No, hits=-1.414 tagged_above=-999 required=5 tests=ALL_TRUSTED, AWL, HTML_50_60, HTML_MESSAGE, HTML_TITLE_EMPTY X-Spam-Level: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.2 (/) X-Scan-Signature: 73f7847c44628482de9d5f1018acf469 This is a multi-part message in MIME format. --------------030804000904080204010807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Lisa ran in to me today and reminded me about the meet up (thanks!). I will try hard to make it; is there a definite time set? (6pm is slightly better for me, but 7pm is okay too.) -John Lisa Dusseault wrote: > > Thanks for setting this up Henry, I can be there Dec 6. 7pm is much > easier to make than 6pm if anybody's coming far, even just from SF. > > Lisa > > On Dec 1, 2006, at 12:08 PM, Henry Story wrote: > >> >> Ok I suggest trying December 6th. >> Onion or no Onion rings at Tied House. >> >> What is dinner time in the bay? 6pm? 7pm? >> >> Henry >> >>> On 28 Nov 2006, at 21:31, John Panzer wrote: >>> >>> Any of those would be good for me. Be careful of the deep fried >>> onion rings at Tied House, though. >>> >>>> Henry Story wrote: >>>> >>>> It has been suggested that a good meeting location might be Tied >>>> House in Mountain View [1]. It has a back room that's like a >>>> patio but covered and heated for dinner on either >>>> >>>> Wednesday 6th Dec >>>> Friday 8th Dec >>>> Monday 11th Dec >>>> Wednesday 13th Dec >>>> >>>> Any preferences? >>>> >>>> Henry Story >>>> >>>> [1] http://www.tiedhouse.com/ >>>> >>>>> On 16 Nov 2006, at 18:23, Henry Story wrote: >>>>> >>>>> Hi, >>>>> >>>>> I am in the San Francisco/Bay Area region for the coming month. >>>>> Would anyone in the area be up for a group meeting? >>>>> >>>>> Henry >>>>> >> > -- Abstractioneer John Panzer System Architect http://abstractioneer.org --------------030804000904080204010807 Content-Type: multipart/related; boundary="------------080502010300010303000009" --------------080502010300010303000009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Lisa ran in to me today and reminded me about the meet up (thanks!).  I will try hard to make it; is there a definite time set?  (6pm is slightly better for me, but 7pm is okay too.)

-John

Lisa Dusseault wrote:

Thanks for setting this up Henry, I can be there Dec 6.  7pm is much  easier to make than 6pm if anybody's coming far, even just from SF.

Lisa

On Dec 1, 2006, at 12:08 PM, Henry Story wrote:


Ok I suggest trying December 6th.
Onion or no Onion rings at Tied House.

What is dinner time in the bay? 6pm? 7pm?

Henry

On 28 Nov 2006, at 21:31, John Panzer wrote:

Any of those would be good for me.  Be careful of the deep fried  onion rings at Tied House, though.

Henry Story wrote:

It has been suggested that a good meeting location might be Tied   House in Mountain View [1]. It has a back room that's like a  patio  but covered and heated for dinner on either

Wednesday 6th Dec
Friday 8th Dec
Monday 11th Dec
Wednesday 13th Dec

Any preferences?

Henry Story

[1] http://www.tiedhouse.com/

On 16 Nov 2006, at 18:23, Henry Story wrote:

Hi,

I am in the San Francisco/Bay Area region for the coming month.   Would anyone in the area be up for a group meeting?

Henry





--

AbstractioneerJohn Panzer
System Architect
http://abstractioneer.org
--------------080502010300010303000009 Content-Type: image/gif; name="SzHO.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="SzHO.gif" R0lGODlhLAFDAPcAAP///5mZmTMzM2ZmZuathN57MeZ7MeaEMe+MMe+MOuaMOuZ7OuZzMe+E MfeUOvecOvecQuaMSve9nO+lY/+cOu+cY//37/fFnO+USvfWtf/v5v+1cwAzmfeta//v3v/F hPela//mzvfFjP/etfe1c+97Mf+tWv/Wte+MQvelUve9hPetWvelSu+UQvetc+ZrMd5zMf/e vfe1hOaMUt5rMfe1a/e9jPfWve+tjN5jKf+tUvfOpf/m1u+1lO+UY+Z7SuaMY95zQt5aKd5z OqWlpQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH/C05FVFNDQVBFMi4wAwEAAAAh+QQA9AEAACwA AAAALAFDAAAI/gABAAhAsKDBgwgTEhTIsKHDhxAjSpxIsaLFixgzatzIsaPHjxsVihxZEKTJ kyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtCnEgxmhPl0osGRV qgOxOt3KtSdVrRTBOgxwNavZhWjJdl3LFudXtVazqr0qdizZtGfvxm3Lt+/Kt3nNRqxbNjBe vH4TK/YIGCphwQ+xHtYbeLHlyxUbz4XMEC7lzpsnG96MubRpqXI9k7aqVWrc149Ny56tkTTt 27hz697Nu7fv38CDCx9OvPhlAQKMKz+JPDlD5BCbO5cuEDoA69avN29I/fl27tmz/i8fv/F7 decPxYefzv68e+3vsaMXD5+8fYzQ5Zv3Dp5/ffr/tRfge+Dtd9+BDuU3H3oJMqhecgqmt2B8 Ako3YX0IZujeehE9WKCFDfY34IjyEajhgRaWGJ2DLLLHYogkVijjiRlyiCGMJo6YY4wU9ngj jeTZqB2DQ7r44o0pevfgkgsaCOSTUEYp5ZRUVmnllVhmqeWWXHbJ2wADrASml2RCFKZJYJ4J wJgSsZkRm26WKZyaH6XJUJwP4WmRnnIGZ2eYZ7r5J50CjQmnnYUamuafawqq6KKBHuqomoga 2udakRaq6ZqbEqpooo2GemekdH46KqifpgroqqEieilX/oHe2emsDUGK6qqHgpqoqbqq2iqu j/L66lax0lpsqZSy6mivmQqbq6/OIjtsV8Xqyum10t4qaa2Ljrrtrt+a2m2jwk5r7rnopqvu uuy26+678MYr77zmElCAAfgacMC+ByCQgAIE0NsnAQswgG8DDSCAgAMMP/AABAELTGYBDEQg gQQTKMywAw5T8MABEpOJbwUMWXABBBw/4LEDIIfcJb4YXJCBBgJZsIHKDziAQMsXccCBRz67 nJsBCGvcgQcCfZAzAg0Y4JDPP0MUtEZBTy00bUSDYEEIIkDwwAgCkcB0CU4zNHXUT6O9kdVX y9ZvByWbQMEJAFiAAtllC8R2+dU/Q4021HrzDQDgfpvN9uCABx614Ie3zVO/DqSgAs0WrOAA zRIYwAADaS/e9+eIhx644aAzDrrhoZueutqOP77xAyyArUELLtTNwAswSF367ogLPvrqqyc+ uuqqt+7TAQzHEMIHENAsQwkWADADDbmbPTzvVvsuOvGsXw/89t0bn9PCNQgUggM2AHCDATcA gEMO1ZNO+udnZ+873/bvfbrw9YvvUwIP0EH0doAAEACABwzoAQB6kAMa+K9KClBZCjowtgr4 4AU/AEIQhBC/B0aJAF7TWQPIdjsa5CAHQhhCxDwoJQLwK18MgIEMqbdCFtrwhjjMYUwCAgAh +QQAGQAAACwCAAYAUwAWAAAI9QABCBxIsKDBgwgTKlzIsCCRhw8bDoQY8SDEiRUBXBS4USLD ihk/ElE4UuPIiChPqvToEWTJjh1NhrS4MqVJmSVZknxZcyXCmQRd3rRpU2dCoRR90vyZk2jP m0aZclQKNejUqlidDqUaNShFjC5zTuXpdSPMjDG7qiW5tq3bt3Djyp1Lt67du3jz6o0LFKxX mmHJQkUb8ytYsTIxHg3ZN2tTwUIHQxaMtbLiwIgdK5ZsMLJnyocRF7V8dfPV0aY/l066mbHS xq7Lsv7bevJq22MNwxbrmidv0bhVcy49vPNvh6CBCl9OmbBf2blp9z47HXrunAEBACH5BAAZ AAAALAIABgBTABYAAAhGAAEIHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOK HEmypMmTKFOqXMmypcuXMGPKnEmzps2bOHPq3IkzIAAh+QQAGQAAACwCAAYAogAYAAAI/gAB CBxIsKDBgwgTKlzIsKHDhxAjJiRCkCJEIhgHYrR4cKPGjAI9hgQpsaTJkyZJcmxoMaPLlRpH Ang5kyJNlDhz6uwIsmVPmzBl3kRIsyhQkjuTKr1Yc2ZTowZ/NiXq8ylQq0uzap048irUihyH FlTptezUrWi3hjVbEybSrzI/YoWbtm7SlT7Xut2YN27Xn3o/BrVLuHDEwYYTK17MuLHjx5Aj S55MubLly5GR3tWMWS3ivxI5c7742aFIwWQnniY82m9pnllbP1yd+izVxLJH8wULuDZfvLt5 95Yr+qrrqgrJ+q76kvZp5chv254qlTry4nKtrxa6NrvsuNXDbO+uDhb8Xp4iNYs3z35sd+uq zy5fuB6+bfK/zdcub9/79f9+ZWdfa7/hF5109ZE3IICgydeeegwmGNR80wloYICwLdjegwxa 6Nxz6UUYXX7uCSdgiceBGFyDLLaloIEhtvjYd53VmNaKNlYWEAAh+QQA9AEAACwCAAYAogAY AAAI/gABCBxIsKDBgwgTKlzIsKHDhxAjJgxAkCLEABgHYrR4cKPGjAI9hgQpsaTJkyZJcmxo MaPLlRpHAng5kyJNlDhz6uwIsmVPmzBl3kRIsyhQkjuTKr1Yc2ZTowZ/NiXq8ylQq0uzap04 8irUihyHFlTptezUrWi3hjVbEybSrzI/YoWbtm7SlT7Xut2YN27Xn3o/BrVLuHDEwYYTK17M uLHjx5AjS55MubLly5EFCNCqeTNmu5oVdvYMMXRB0yZRp1YNYDRp1gRHJ4Y9EDVph7Rx5n7Y OfZrz7sFBs+6m7bs2r1bH1cufLny5MiTLw8Nm/pv5M0X2oZuuvtm69Cfi19v7l008NvM05dX f97g9uzi0TN/D3/4+vvne6/3XR+98eOs4dffgKeNt597343HnnbtLegggfH1Rx9/DxIoYIXw OZiba/sdeNCFF1rY4HYdiligiRrKR5+H2EHI4okpQhgjhiTe5lp0I+aY4Y0wkqdgjzX+5tyQ 4fGoWocA5idfY8N95iRazj1JWUAAIfkEABkAAAAsAgAGAKIAGAAACP4AAQgcSLCgwYMIEypc yLChw4cQIyYkQpAiRCIYB2K0eHCjxowCPYYEKbGkyZMmSXJsaDGjy5UaRwJ4OZMiTZQ4c+rs CLJlT5swZd5ESLMoUJI7kyq9WHNmU6MGfzYl6vMpUKtLs2qdOPIq1IochxZU6bXs1K1ot4Y1 WxMm0q8yP2KFm7Zu0pU+17rdmDdu1596Pwa1S7hwxMGGEytezLix48eQI0ueTLmy5cuRkd7V jFkt4r8SOXO++NmhSMFkJ54mPNpvaZ5ZWz9cnfos1cSyR/MFC7g2X7y7efeWK/qq66oKyfqu +pL2aeXIb9ueKpU68uJyra8Wuja77LjVw2zvrg4W/F6eIjWLN89+bHfrqs8uX7gevm3yv83X Lm/f+/X/fmVnX2u/4ReddPWRNyCAoMnXnnoMJhjUfNMJaGCAsC3Y3oMMWujcc+lFGF1+7gkn YInHgRhcgyy2paCBIbb42Hed1ZjWijZWFhAAIfkEABkAAAAsAgAGAKIAGAAACGYAAQgcSLCg wYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pcybKly5cwY8qcSbOm zZs4c+rcybOnz59AgwodSrSo0aNIkypdyrSp06dQo0qdSrWq1as8AwIAIfkEABkAAAAsAgAG AJcAFgAACP4AAQgcSLCgwYMIEypcyLChw4cQHxIhODEikYoALmI0qHFgR4EfM16MSLKkSYkY Nzb8OHIkR5ATW8acKfKkzZs4RVbc6VImR541E/ocOtNlzqNIhdakSfSnR6MHezKdGjSpVas8 qfosKLUq15RaqV4dexTs0qxRgW6FSTHsWbJwb25EC1OlTrpQNUoFyzeu378k7QIeTLiw4cOI EytezLix48eQIw+G+rerZId6y5rNSRloUMol9WauK/qpaL6l22p+qnmzaq8m7aZ8CZJ2Rtts SZvOyzJzat2kBfu2bPku67UebctOzpU5xa+5icv2/Hl69OUdpV+/nn1589rfb1uH9866+vbg uc2jV/9cvPbqo0HjBi++fX3n5M+/f69+f/7+noEmX3j4KWcggQDqF+Bm/qXnnILnuTfXf/WR ZyFtowHH3m/dpZdacQ8mWFWGvP102m4knobaaAEBACH5BAD0AQAALAIABgCXABYAAAj+AAEI HEiwoMGDCBMqXMiwocOHEB8GIDgxYoCKAC5iNKhxYEeBHzNejEiypEmJGDc2/DhyJEeQE1vG nCnypM2bOEVW3OlSJkeeNRP6HDrTZc6jSIXWpEn0p0ejB3synRo0qVWrPKn6LCi1KteUWqle HXsU7NKsUYFuhUkx7FmycG9uRAtTpU66UDVKBcs3rt+/JO0CHky4sOHDiBMrXsy4sePHkCMP FiCgMGWBlyU7pJwZZ+fON0EDqDyadGbRJTmrJl16NWvXn2EXRG0y9lHOA1GfZn2SN+bcBl8H Bz579mvcmFUTVN768urlyJv7Tu58d/Lr1I+X3l68++jhv71+T/dtnXt56NjNjzfNfjju8vDb S+e+HPx38fbHG8cePzdz2/Q9px548vUnnXwK6RdefQsSdx+D/vFX4ITpGWgghBJmSF+ECyn4 oIMeeqihhRSOWKJu+w2o4n2goYjfixAqyFx2HMYW3XsICniegyZWeCNvusmW3YywHeeaQAEB ACH5BAAZAAAALAIABgCXABYAAAj+AAEIHEiwoMGDCBMqXMiwocOHEB8SITgxIpGKAC5iNKhx YEeBHzNejEiypEmJGDc2/DhyJEeQE1vGnCnypM2bOEVW3OlSJkeeNRP6HDrTZc6jSIXWpEn0 p0ejB3synRo0qVWrPKn6LCi1KteUWqleHXsU7NKsUYFuhUkx7FmycG9uRAtTpU66UDVKBcs3 rt+/JO0CHky4sOHDiBMrXsy4sePHkCMPhvq3q2SHesuazUkZaFDKJfVmriv6qWi+pdtqfqp5 s2qvJu2mfAmSdkbbbEmbzssyc2rdpAX7tmz5Luu1Hm3LTs6VOcWvuYnL9vx5evTlHaVfv559 efPa329bh/fOuvr24LnNo1f/XLz26qNB4wYvvn195+TPv3+vfn/+/p6BJl94+ClnIIEA6hfg Zv6l55yC57k313/1kWchbaMBx95v3aWXWnEPJlhVhrz9dNpuJJ6G2mgBAQAh+QQAGQAAACwC AAYAlwAWAAAIXwABCBxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJ kyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKnTp1CjAggIACH5 BAAZAAAALAIABgAQARgAAAj+AAEIHEiwoMGDCBMqXMiwocOHECNKnEixosWJRAhmjEhkY8eP CEEKFAmAJMmLKFOqXMmyZcqOAzc+FAkzoceMMHPi3Omyp8+fQINyrHnzZkmZMYsiPajzqFOd NYVKnUq1qkSeWLMajDpyqUajTcN6tUq2rNmfRZ9qLcjVKVOZYtW6PUu3rt2KcNeeTDqy69y/ cePeHUy48FaNXfN6/ZgWMOPESRUbnky5ssqxljNr3sy5s+fPoEOLHk26tOnTqFOrRt12NcPW rj+3hp2YMU+MXB//LXkYsU3MuCGe1N0W6d6QuWkuVQocre6Gs5v75Yt7ueTpX30jX0kbufXI 1Hf+K9wb1aRR8UGJSg/Pfnvk5LSbhn983OT72lrLm5frFrZ87PSpN9NtAIKkXIHw6ZfgeOcJ iN97DRon4XQOskXgXDtd2BdRFJ4nl4PqGUigfxeWd9Rttr1WIlwn9uchdSBGCN1zMXZoo2PZ ufhcdsnF1Jd4YOHnoWA13qcijj/KiB6PEybZ4XDERRhldzcWWeSJ38H44la25eVjjtodaCFf 8l2JpYopAjimiwymieGa0VW5ZW0MymknhuQ1WeFiXqoJ5pc38oakfoHyB2Sfb+ZoZoHzwcnn nSYq+iiblJoZp5ZGrqmjR5oC+uOZ4FFKJ3aVTrrppwgiOp9SqIr6lXkhsCqm6oMQ1korqbGl RqVVu3JJVa+5hraeVDs6NCx3SAUEACH5BAD0AQAALAIABgAQARgAAAj+AAEIHEiwoMGDCBMq XMiwocOHECNKnEixosWJAQhmjBhgY8ePCEEKFAmAJMmLKFOqXMmyZcqOAzc+FAkzoceMMHPi 3Omyp8+fQINyrHnzZkmZMYsiPajzqFOdNYVKnUq1qkSeWLMajDpyqUajTcN6tUq2rNmfRZ9q LcjVKVOZYtW6PUu3rt2KcNeeTDqy69y/cePeHUy48FaNXfN6/ZgWMOPESRUbnky5ssqxljNr 3sy5s+fPoEOLHk26tOnTqFOrRi1AwOqIrV+Xjl2Q9sHWuHEDsA2bd26BvHcbdE2QOMLgFpEr 1D3w927jwIsrH+6beXDiuaFPzf4Q+XTp4Cf+Mm9ufLx36Nprp6/4/fb18rbjrz/+njx84Njn /6TdPrz/hNWN99x0sVVnn2sC4lfegQoWiOCDDOL33IQUKuegf79Zpx91FErY4IAeyhegiOgl qF6I+R0In4Yetlhhih2CZ2B0unlXIYotXsgfjNxd6CJ5McYH4o4mcjijcDXymN6OOL7YEHdN MunklC5Kmd16PuYYXYxbFtiglBP6aGWJ/Ul4JHZRbhhmic11mZ+AUI7pnHMAKplmkwNqNyOY 7kHZoZ5L2vfjnxCOWWWR6vkpZHh8UqfogowuaSeV0rVn6JSX5nkikFRKyumfmxYXaZtBwogp m/JxmCOknGb6aapLW7bq6alajrrppbiyGWqnRcI6566xxkoniJTSuaepr76JJobmzfoif7di aey0JH6qYqUkrnikbKqVSZW3/wUFLrefqbkdostVxVtAACH5BAAZAAAALAIABgAQARgAAAj+ AAEIHEiwoMGDCBMqXMiwocOHECNKnEixosWJRAhmjEhkY8ePCEEKFAmAJMmLKFOqXMmyZcqO Azc+FAkzoceMMHPi3Omyp8+fQINyrHnzZkmZMYsiPajzqFOdNYVKnUq1qkSeWLMajDpyqUaj TcN6tUq2rNmfRZ9qLcjVKVOZYtW6PUu3rt2KcNeeTDqy69y/cePeHUy48FaNXfN6/ZgWMOPE SRUbnky5ssqxljNr3sy5s+fPoEOLHk26tOnTqFOrRt12NcPWrj+3hp2YMU+MXB//LXkYsU3M uCGe1N0W6d6QuWkuVQocre6Gs5v75Yt7ueTpX30jX0kbufXI1Hf+K9wb1aRR8UGJSg/Pfnvk 5LSbhn983OT72lrLm5frFrZ87PSpN9NtAIKkXIHw6ZfgeOcJiN97DRon4XQOskXgXDtd2BdR FJ4nl4PqGUigfxeWd9Rttr1WIlwn9uchdSBGCN1zMXZoo2PZufhcdsnF1Jd4YOHnoWA13qci jj/KiB6PEybZ4XDERRhldzcWWeSJ38H44la25eVjjtodaCFf8l2JpYopAjimiwymieGa0VW5 ZW0MymknhuQ1WeFiXqoJ5pc38oakfoHyB2Sfb+ZoZoHzwcnnnSYq+iiblJoZp5ZGrqmjR5oC +uOZ4FFKJ3aVTrrppwgiOp9SqIr6lXkhsCqm6oMQ1korqbGlRqVVu3JJVa+5hraeVDs6NCx3 SAUEACH5BAAZAAAALAIABgAQARgAAAiDAAEIHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq 3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMq Xcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmzaNOqXcu2rdu3cONeDQgAIfkEABkA AAAsAgAGANkAGAAACP4AAQgcSLCgwYMIEypcyLChw4cQI0qcSPEgEYIXIxLJOHAjwo0cQXb0 KFBkxZMoU6pc2ZAkAI4OTZZ0iXHmy4sec+KEybKnz59AP5LMaFKnQZc7FRpdupNm0KdQo2q8 +ZIq06NEbQq1edWo1K9gw3acmfRqwaEgnWq1Wrat2LdwgYZ0e5PnWq4waXalG7evX4p5yY60 mxZj0sFo5yr+y7hxY7uOI0ueTLmy5cuYM2vezLmz58+gQ7NUqxaszL6lT2uErLJ0xbSsR2Jt GXui67eka9MOejsm0cAJc+8erds04eILe59UzhCtUKSKU4uETXYu1bo8qWOXnVtmYcSGVbpr /149vPDEeU9r3463/HXpWp1fN3wWMvrDFq2/Jx//d///88kGoHzymXeYcPsNWJhTBDaoIFbQ GXgXfwImGCB9FjpoIYbY3effhQHCFt2HHk7o3YcZkoiieWtpCF59AhYIY4oPghjhjBgieFeN Mu74XYEaujjbfEJWWGGRMarI43FHtgggh0Qu6SSIVIr4IpEUsidYhybCd+Vt6/EnZpZ6qWem aheOeeKa+rlHpWitIQfnnJ1lSSdcAQEAIfkEAPQBAAAsAgAGANkAGAAACP4AAQgcSLCgwYMI EypcyLChw4cQI0qcSPFgAIIXIwbIOHAjwo0cQXb0KFBkxZMoU6pc2ZAkAI4OTZZ0iXHmy4se c+KEybKnz59AP5LMaFKnQZc7FRpdupNm0KdQo2q8+ZIq06NEbQq1edWo1K9gw3acmfRqwaEg nWq1Wrat2LdwgYZ0e5PnWq4waXalG7evX4p5yY60mxZj0sFo5yr+y7hxY7uOI0ueTLmy5cuY M2vezLmz58+gQ7MUIMAg6b6kS/89bZr1RNc+YadMLbu1bYa1T+aGW3v3Q98ogTdkDVs1wt7G FQqPuPwr8uDJezZXrno37YGuaUcXeF0799TYS9oTB0/QO4Dr389vN6++OPnv7+GPd0//+fzk 6OUbz3/6fnr1B433n4AFyZbbfeJtF96CALZnYHUQDhhhg89JaCGF63U3YXkTEohggwzOd6GH GWaHH3r1BbhfhwpiOCKL/3EYHormESjjjO/VyCKNHJoYI4kvqmgjkD1mGOKGBcLo4pIVgsjg jU06GeSSN+J4IZNK+jakkknehuVxWYYZ45PZ/XjlkyCKSSWSaOJooo/6tUZfnE7mV6WDbRa5 YopueomnlX12WaSegf5ZZ44tijZbooo2GpqdjvYVEAAh+QQAGQAAACwCAAYA2QAYAAAI/gAB CBxIsKDBgwgTKlzIsKHDhxAjSpxI8SARghcjEsk4cCPCjRxBdvQoUGTFkyhTqlzZkCQAjg5N lnSJcebLix5z4oTJsqfPn0A/ksxoUqdBlzsVGl26k2bQp1Cjarz5kirTo0RtCrV51ajUr2DD dpyZ9GrBoSCdarVatq3Yt3CBhnR7k+darjBpdqUbt69finnJjrSbFmPSwWjnKv7LuHFju44j S55MubLly5gza97MubPnz6BDs1SrFqzMvqVPa4SssnTFtKxHYm0Ze6Lrt6Rr0w56OybRwAlz 7x6t2zTh4gt7n1TOEK1QpIpTi4RNdi7VujypY5edW2ZhxIZVumv/Xj288MR5T2vfjrf8dela nV83fBYy+sMWrb8nH/93///zyQagfPKZd5hw+w1YmFMENqggVtAZeBd/AiYYIH0WOmghhtjd 59+FAcIW3YceTujdhxmSiKJ5a2kIXn0CFghjig+CGOGMGCJ4V40y7vhdgRq6ONt8QlZYYZEx qsjjcUe2CCCHRC7pJIhUivgikRSyJ1iHJsJ35W3r8SdmlnqpZ6ZqF4554pr6uUelaK0hB+ec nWVJJ1wBAQAh+QQA+gAAACwCAAYA2QAYAAAIdQABCBxIsKDBgwgTKlzIsKHDhxAjSpxIsaLF ixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fPn0CDCh1KtKjR o0iTKl3KtKnTp1CjSp1KtarVq1izat3KtavXr2DDih1LtmzOgAA7 --------------080502010300010303000009-- --------------030804000904080204010807-- From owner-atom-syntax@mail.imc.org Wed Dec 06 00:49:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrpfB-0004d4-Nc for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 00:49:49 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrpfA-0004V0-Bk for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 00:49:49 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB65W3Lv095863; Tue, 5 Dec 2006 22:32:03 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB65W34W095862; Tue, 5 Dec 2006 22:32:03 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB65W23k095855 for ; Tue, 5 Dec 2006 22:32:03 -0700 (MST) (envelope-from mbaker@gmail.com) Received: by ug-out-1314.google.com with SMTP id j3so46740ugf for ; Tue, 05 Dec 2006 21:32:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=ZtFsPvyhCxBus3vDeSxmj4iNKInLF2Tbl9wQZH86+EmLKBgv2EkefvXKubnmJmqX1UGMiU7PoC31mn/ci1PwhYlHSXgcTFapY0V+K0Hl9MXCZ+3JUwkgEy8eKBJvVtnXjFry+/zb+qgqjzyl98+3GuDnLtAkz11sT/9faGaHccM= Received: by 10.78.180.16 with SMTP id c16mr247795huf.1165383121454; Tue, 05 Dec 2006 21:32:01 -0800 (PST) Received: by 10.78.174.19 with HTTP; Tue, 5 Dec 2006 21:32:01 -0800 (PST) Message-ID: Date: Wed, 6 Dec 2006 00:32:01 -0500 From: "Mark Baker" To: "James M Snell" Subject: Re: PaceEntryMediatype Cc: atom-protocol , atom-syntax In-Reply-To: <45764C7A.5040008@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <456DB265.5090804@gmail.com> <456EF996.7060009@defuze.org> <4574759D.1070904@gmail.com> <45748679.70602@gmail.com> <4575D37D.8080909@gmail.com> <45764C7A.5040008@gmail.com> X-Google-Sender-Auth: 71794fbb9678f2d8 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d On 12/5/06, James M Snell wrote: > Mark Baker wrote: > > [snip] > > Ok, but I don't see that this would necessitate a new media type. > > It's just an entry without a feed. You'd use the same code path to > > process that entry whether it were found in an entry or feed document, > > right? > > > > Not necessarily. Sure, it might be the same parser code, but not > necessarily the same bit of code using the parser. Look at the way > Firefox, IE7, Bloglines, Liferea, etc all handle (or don't handle) Entry > documents versus Feed documents. The majority of applications that most > frequently handle Atom Feed Documents have no idea how to deal with Atom > Entry Documents and I would wager that most applications that understand > how to process Atom Entry Documents and Atom Feed Documents typically > don't fall into the same category as most feed readers. Isn't that just a case of people not implementing the whole spec though? FWIW, if that practice is widespread, then I think the group should consider deprecating entry documents. Minting a new media type won't help. Or, are there applications which only process entry documents and not feed documents? Mark. From owner-atom-syntax@mail.imc.org Wed Dec 06 00:55:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grpkc-00075C-DP for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 00:55:26 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrpkZ-0005P5-Rn for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 00:55:26 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB65fpA5096967; Tue, 5 Dec 2006 22:41:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB65fprN096966; Tue, 5 Dec 2006 22:41:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB65fo1f096947 for ; Tue, 5 Dec 2006 22:41:51 -0700 (MST) (envelope-from henry.story@bblfish.net) Received: (qmail 84622 invoked by uid 17064); 6 Dec 2006 05:41:50 -0000 Received: from unknown (HELO [10.1.1.108]) ([64.162.56.198]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 6 Dec 2006 05:41:50 -0000 In-Reply-To: <4576548B.9040008@aol.net> References: <20061201120233.Y74708@bblfish.net> <4576548B.9040008@aol.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <48A4A0F0-4673-441C-B3D6-B2FD7EA6FA9E@bblfish.net> Cc: Lisa Dusseault , Atom Protocol , Atom Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: In San Francisco/Bay Area Date: Tue, 5 Dec 2006 21:41:50 -0800 To: John Panzer X-Mailer: Apple Mail (2.752.3) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a I'll be there at 6:30pm then. I imagine people will not be wanting to stay very late. Henry On 5 Dec 2006, at 21:26, John Panzer wrote: > Lisa ran in to me today and reminded me about the meet up > (thanks!). I will try hard to make it; is there a definite time > set? (6pm is slightly better for me, but 7pm is okay too.) > > -John > > Lisa Dusseault wrote: >> >> Thanks for setting this up Henry, I can be there Dec 6. 7pm is >> much easier to make than 6pm if anybody's coming far, even just >> from SF. >> >> Lisa >> >> On Dec 1, 2006, at 12:08 PM, Henry Story wrote: >> >>> >>> Ok I suggest trying December 6th. >>> Onion or no Onion rings at Tied House. >>> >>> What is dinner time in the bay? 6pm? 7pm? >>> >>> Henry >>> >>>> On 28 Nov 2006, at 21:31, John Panzer wrote: >>>> >>>> Any of those would be good for me. Be careful of the deep >>>> fried onion rings at Tied House, though. >>>> >>>>> Henry Story wrote: >>>>> >>>>> It has been suggested that a good meeting location might be >>>>> Tied House in Mountain View [1]. It has a back room that's >>>>> like a patio but covered and heated for dinner on either >>>>> >>>>> Wednesday 6th Dec >>>>> Friday 8th Dec >>>>> Monday 11th Dec >>>>> Wednesday 13th Dec >>>>> >>>>> Any preferences? >>>>> >>>>> Henry Story >>>>> >>>>> [1] http://www.tiedhouse.com/ >>>>> >>>>>> On 16 Nov 2006, at 18:23, Henry Story wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I am in the San Francisco/Bay Area region for the coming >>>>>> month. Would anyone in the area be up for a group meeting? >>>>>> >>>>>> Henry >>>>>> >>> >> > > > -- > > > John Panzer > System Architect > http://abstractioneer.org From owner-atom-syntax@mail.imc.org Wed Dec 06 01:10:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grpzd-0005nJ-Jz for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 01:10:57 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Grpzb-0000Gp-6V for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 01:10:57 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB65x6f3099174; Tue, 5 Dec 2006 22:59:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB65x6ij099173; Tue, 5 Dec 2006 22:59:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.230]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB65x5SY099167 for ; Tue, 5 Dec 2006 22:59:06 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id i30so105512wxd for ; Tue, 05 Dec 2006 21:59:05 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=DpWsTrEzI3rx7IvWqgn9hj9fovqQC0IbucHgqkXxmqc8ZEdqMpzIGi+02JMlk/ztp/qwYQcjqLTZDdhEm3QLOxFGJVlgMqkvjiw3CAVzKFKo9Nd9cM9EYUwt1E6ld6KES/WKPgXVumNfulrAXuKjWYUrYotHE3N+fTJakAbV/z4= Received: by 10.70.19.20 with SMTP id 20mr655047wxs.1165384745319; Tue, 05 Dec 2006 21:59:05 -0800 (PST) Received: from ?192.168.1.101? ( [67.181.218.96]) by mx.google.com with ESMTP id 9sm6375485wrl.2006.12.05.21.58.59; Tue, 05 Dec 2006 21:59:01 -0800 (PST) Message-ID: <45765C1F.50802@gmail.com> Date: Tue, 05 Dec 2006 21:58:55 -0800 From: James M Snell User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: Mark Baker CC: atom-protocol , atom-syntax Subject: Re: PaceEntryMediatype References: <456DB265.5090804@gmail.com> <456EF996.7060009@defuze.org> <4574759D.1070904@gmail.com> <45748679.70602@gmail.com> <4575D37D.8080909@gmail.com> <45764C7A.5040008@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Mark Baker wrote: > [snip] > Isn't that just a case of people not implementing the whole spec > though? FWIW, if that practice is widespread, then I think the group > should consider deprecating entry documents. Minting a new media type > won't help. > The interesting question is *why* haven't those applications implemented support for Entry Documents. My guess is that Entry documents aren't particularly interesting to their use cases which is likely because they serve a different purpose. Entry documents serve an extremely useful purpose in the Atom Publishing Protocol. They serve a significantly less useful purpose for your typical feed reader. That doesn't make them worthy of deprecation; it just means entry documents are different than feed documents. > Or, are there applications which only process entry documents and not > feed documents? > Wrong question. APP clients process both entry documents and feed documents but do so for entirely different reasons than feed readers. - James From owner-atom-syntax@mail.imc.org Wed Dec 06 01:16:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grq4p-0008BC-0S for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 01:16:19 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Grq4n-0001Sy-Kt for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 01:16:18 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB663Kvk099457; Tue, 5 Dec 2006 23:03:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB663K7i099456; Tue, 5 Dec 2006 23:03:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironclad.net.au ([203.30.247.11]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id kB663EJg099445 for ; Tue, 5 Dec 2006 23:03:19 -0700 (MST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.118] (HELO [192.168.1.2]) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.0007391150 for ; Wed, 06 Dec 2006 17:03:12 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 06 Dec 2006 17:03:11 +1100 Subject: Re: PaceEntryMediatype From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: 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: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 On 6/12/06 4:32 PM, "Mark Baker" wrote: > Or, are there applications which only process entry documents and not > feed documents? That would be unusual. I can imagine though that an application would easily be designed to expect only entry documents for specific situations. An editor application, for example, would know how to handle collection feeds and entry documents, but would reasonably not be expected to know what to do if it retrieved a feed document when attempting to edit a specific entry (especially if it PUT/POSTed the entry as an entry document in the first place). Similarly, if an atom:entry element was wrapped inside some other unexpected XML document (eg. RSS 1.0) ... should applications be prepared to cope with that? e. From owner-atom-syntax@mail.imc.org Wed Dec 06 01:18:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grq6U-0000Pn-KO for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 01:18:02 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Grq6T-0001h7-6r for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 01:18:02 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB666Icg099879; Tue, 5 Dec 2006 23:06:18 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB666ICs099878; Tue, 5 Dec 2006 23:06:18 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.236]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB666G5m099871 for ; Tue, 5 Dec 2006 23:06:17 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id i30so107035wxd for ; Tue, 05 Dec 2006 22:06:16 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=GaY7Yajdi4j2Dczk1xDqKCsL54vaTfCIBYN5eWLAsm04jAqcYMyg4sJOtZVIMbGq6bvFVwJ8K9rISOEapj//t33jCMJXtUv9u/Ut3QzoA3qDZvsG5hXi9VNM+f41EQ5WRCh998V3XXJ1M65uObar89VmN+qJblUdyO+QEKCKdP8= Received: by 10.70.113.16 with SMTP id l16mr647375wxc.1165385176311; Tue, 05 Dec 2006 22:06:16 -0800 (PST) Received: from ?192.168.1.101? ( [67.181.218.96]) by mx.google.com with ESMTP id g3sm2623497wra.2006.12.05.22.06.15; Tue, 05 Dec 2006 22:06:15 -0800 (PST) Message-ID: <45765DD3.7080507@gmail.com> Date: Tue, 05 Dec 2006 22:06:11 -0800 From: James M Snell User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: Eric Scheid CC: Atom Syntax Subject: Re: PaceEntryMediatype References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Eric Scheid wrote: > [snip] > If an agent found an entry document, should it assume that it's a feed with > one entry (so far) and allocate resources accordingly (ie. allow for > cardinality of n++)? > No. In particular, if an atom:source element is not included there is no way of knowing anything about the implied feed; no atom:id, no atom:updated, no atom:title, none of the minimal bits of information the atom spec requires for a feed. An implied feed would serve no purpose. > If an agent found an entry document, and then later returned to find a feed > containing multiple entries, would it consider that a problem? That obviously depends on how the code was written. If it's an APP client that's expecting to edit an Atom entry then, yeah, it'll quite likely be a problem. Now reverse it. If an agent (e.g. firefox) finds a feed document and then later returned to find an entry, would it consider that a problem? > > Would an agent finding multiple atom:content elements inside the one entry > consider that a problem (other than it being a spec violation)? > > Are XML processors optimised for the fact that any given attribute can only > occur once per element, and not twice or more .. eg. /> ? > Ok, you lost me on these last two. I'm not sure what you're getting at. - James From owner-atom-syntax@mail.imc.org Wed Dec 06 01:48:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrqaN-0005dF-12 for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 01:48:55 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrqaL-0005GN-Lv for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 01:48:55 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB66YijN003561; Tue, 5 Dec 2006 23:34:44 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB66YigF003560; Tue, 5 Dec 2006 23:34:44 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironclad.net.au ([203.30.247.11]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id kB66YgSL003553 for ; Tue, 5 Dec 2006 23:34:43 -0700 (MST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.118] (HELO [192.168.1.2]) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.0007391308 for ; Wed, 06 Dec 2006 17:34:40 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 06 Dec 2006 17:34:41 +1100 Subject: Re: PaceEntryMediatype From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <45765DD3.7080507@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: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f On 6/12/06 5:06 PM, "James M Snell" wrote: >> Would an agent finding multiple atom:content elements inside the one entry >> consider that a problem (other than it being a spec violation)? >> >> Are XML processors optimised for the fact that any given attribute can only >> occur once per element, and not twice or more .. eg. > /> ? >> > > Ok, you lost me on these last two. I'm not sure what you're getting at. It's just the cardinality question in a different context. Argument by analogy. e. From owner-atom-syntax@mail.imc.org Wed Dec 06 02:50:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrrY2-0007yI-Ap for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 02:50:34 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrrY0-0004QH-TY for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 02:50:34 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB67aM0K008806; Wed, 6 Dec 2006 00:36:22 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB67aMKD008805; Wed, 6 Dec 2006 00:36:22 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.webfaction.com (mail1.webfaction.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB67aKJQ008793; Wed, 6 Dec 2006 00:36:21 -0700 (MST) (envelope-from sh@defuze.org) Received: from mail1.webfaction.com (localhost.localdomain [127.0.0.1]) by mail1.webfaction.com (8.12.11.20060308/8.13.3) with ESMTP id kB67aIOs014759; Wed, 6 Dec 2006 01:36:18 -0600 Received: (from apache@localhost) by mail1.webfaction.com (8.12.11.20060308/8.12.11/Submit) id kB67aIEZ014756; Wed, 6 Dec 2006 07:36:18 GMT X-Authentication-Warning: mail1.webfaction.com: apache set sender to sh@defuze.org using -f Received: from 194.221.74.7 (proxying for unknown) (SquirrelMail authenticated user platom_sylvain) by mail1.webfaction.com with HTTP; Wed, 6 Dec 2006 07:36:18 -0000 (GMT) Message-ID: <36112.194.221.74.7.1165390578.squirrel@mail1.webfaction.com> In-Reply-To: References: <456DB265.5090804@gmail.com> <456EF996.7060009@defuze.org> <4574759D.1070904@gmail.com> <45748679.70602@gmail.com> <4575D37D.8080909@gmail.com> <45764C7A.5040008@gmail.com> Date: Wed, 6 Dec 2006 07:36:18 -0000 (GMT) Subject: Re: PaceEntryMediatype From: "Sylvain Hellegouarch" To: "Mark Baker" Cc: "James M Snell" , "atom-protocol" , "atom-syntax" Reply-To: sh@defuze.org User-Agent: SquirrelMail/1.4.8-2.el3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 > > On 12/5/06, James M Snell wrote: >> Mark Baker wrote: >> > [snip] >> > Ok, but I don't see that this would necessitate a new media type. >> > It's just an entry without a feed. You'd use the same code path to >> > process that entry whether it were found in an entry or feed document, >> > right? >> > >> >> Not necessarily. Sure, it might be the same parser code, but not >> necessarily the same bit of code using the parser. Look at the way >> Firefox, IE7, Bloglines, Liferea, etc all handle (or don't handle) Entry >> documents versus Feed documents. The majority of applications that most >> frequently handle Atom Feed Documents have no idea how to deal with Atom >> Entry Documents and I would wager that most applications that understand >> how to process Atom Entry Documents and Atom Feed Documents typically >> don't fall into the same category as most feed readers. > > Isn't that just a case of people not implementing the whole spec > though? FWIW, if that practice is widespread, then I think the group > should consider deprecating entry documents. Minting a new media type > won't help. > > Or, are there applications which only process entry documents and not > feed documents? > > Mark. Mark, Since the beginning you seem to solely focus on what feed readers do or don't do. Suggesting deprecating the entry document on the APP list is quite missing the point really. If people keep seeing Atom as a RSS alternative then there is a big communication failure from the Atom folks. Atom feeds are actually less worthy than Atom entries which should have been pushed even harder as the first class citizen within the RFC. The Atom entry element is the one carrying the information and is the one that needs a media-type on its own, or at least a way to mint that media-type to make it clear to UAs what they're dealing with. In fact I will be really interested to hearing from folks who write APP client extensions for Firefox, Opera or else. Certainly they will tell us that they don't care about Atom feeds as much as they do about Atom entries. The thing is that adding a new media-type now would not impact thoroughly current implementations if for instance we were to say that application/atom+xml is for Atom feed and application/atomentry+xml was newly introduced for Atom entry. I actually do not understand why people get so reluctant at it. - Sylvain From owner-atom-syntax@mail.imc.org Wed Dec 06 03:07:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grrol-00076R-46 for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 03:07:51 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Grroc-0006JI-No for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 03:07:51 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB67qg0U010858; Wed, 6 Dec 2006 00:52:42 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB67qgOV010856; Wed, 6 Dec 2006 00:52:42 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id kB67qcOl010817 for ; Wed, 6 Dec 2006 00:52:40 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 06 Dec 2006 07:52:33 -0000 Received: from xdsl-87-79-236-202.netcologne.de (EHLO klangraum) [87.79.236.202] by mail.gmx.net (mp029) with SMTP; 06 Dec 2006 08:52:33 +0100 X-Authenticated: #163624 Date: Wed, 6 Dec 2006 08:52:32 +0100 From: "A. Pagaltzis" To: atom-protocol , atom-syntax Subject: Re: PaceEntryMediatype Message-ID: <20061206075232.GU12859@klangraum> Mail-Followup-To: atom-protocol , atom-syntax References: <456DB265.5090804@gmail.com> <456E7DE0.8040002@gmail.com> <456EF996.7060009@defuze.org> <4574759D.1070904@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Organization: haphazard X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id kB67qg0U010858 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 * Mark Baker [2006-12-04 21:35]: > If it looks like an alias, and acts like an alias ... 8-) It doesn=E2=80=99t. For resource creation this specification only defines cases where the POST body has an Atom Entry entity declared as an Atom media type ("application/atom+xml"), or a non-Atom entity declared as a non-Atom media type. It does not specify any request semantics or server behavior in the case where the POSTed media-type is "application/atom+xml" but the body is something other than an Atom Entry. In particular, what happens on POSTing an Atom Feed Document to a Collection using the "application/atom+xml" media type is undefined. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Wed Dec 06 03:32:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrsD5-00020T-7Y for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 03:32:59 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrsD3-00017E-QA for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 03:32:59 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB68ILA8013461; Wed, 6 Dec 2006 01:18:21 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB68ILXL013460; Wed, 6 Dec 2006 01:18:21 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from leucothea.site5.com (leucothea.redline.site5.com [216.118.97.161]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB68IJ8C013447; Wed, 6 Dec 2006 01:18:20 -0700 (MST) (envelope-from fantasai.lists@inkedblade.net) Received: from 121-72-128-96.dsl.telstraclear.net ([121.72.128.96] helo=[10.1.1.4]) by leucothea.site5.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.52) id 1Grryq-0007lW-HZ; Wed, 06 Dec 2006 03:18:17 -0500 Message-ID: <45767CBF.1020908@inkedblade.net> Date: Wed, 06 Dec 2006 03:18:07 -0500 From: fantasai User-Agent: Thunderbird 1.5.0.8 (X11/20061117) MIME-Version: 1.0 To: Mark Baker CC: James M Snell , atom-protocol , atom-syntax , whatwg@whatwg.org Subject: Re: PaceEntryMediatype References: <456DB265.5090804@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: This message has been scanned by ClamAV. X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - leucothea.site5.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - inkedblade.net X-Source: X-Source-Args: X-Source-Dir: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Mark Baker wrote: > > The real problem here AIUI - at least in the context of HTML 5's > inferred rel="feed" bit - is not just entry documents, it's any Atom > document which wouldn't normally be considered a "feed" by a typical > user; something that most people would be interested in subscribing > to. An example I gave on the whatwg list was an MHTML-like (MIME > multipart) package, but there are many other possible examples of > course; not all RFC 4287 feed documents are "feeds" in this sense. > > If HTML 5 (and current practice) doesn't change, but we defer to them > for the specification of autodiscovery, then a new media type would be > one way forward. But it should be reusable for all non-"feed" (i.e. > from a user POV, as above) Atom documents, not just entry documents; > perhaps application/atom-no-feed+xml. It's an ugly hack, but it's > better than the alternative of many more specific Atom-related media > types, which atomentry+xml might set a precedent for. Note that HTML 5's special handling of alternate+Atom is triggered on a literal value for the 'type' attribute: # If the 'alternate' keyword is used with the 'type' attribute set to the value # 'application/rss+xml' or the value 'application/atom+xml', then the user # agent must treat the link as it would if it had the 'feed' keyword specified # as well. That means rel="feed" won't be implied on an Atom Entry document whether the new MIME type syntax is chosen to be application/atom.entry+xml or application/atom+xml;type=entry It also won't be implied on an Atom feed document if the syntax application/atom+xml;type=feed or application/atom+xml;type=archive is used, as was suggested earlier. This gives us a way to say without implying and without dropping the 'type' attribute entirely (which was the other solution pointed out on the whatwg list). ~fantasai From owner-atom-syntax@mail.imc.org Wed Dec 06 03:41:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrsLc-0005Er-OT for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 03:41:48 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrsLb-0002O5-Bl for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 03:41:48 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB68RjcA014496; Wed, 6 Dec 2006 01:27:45 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB68RjpM014494; Wed, 6 Dec 2006 01:27:45 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.227]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB68RgPT014414 for ; Wed, 6 Dec 2006 01:27:45 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id i30so135725wxd for ; Wed, 06 Dec 2006 00:27:42 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=DgDqC08gi82FAjtmb0EuwIQJiiX47BLivwY2Ikt5k7gXqfEC+jqzCv9WRQrEvNS7W+X2zItJzfRV6xLSUwgaiZh/4etp4zXEfmpauysm6wvmeUfEYJ53NOTz4VJUlPAe3ZExI+9HjxAqkMjrIJRFQq99kJ3ryoxj4TfCeu2ypzc= Received: by 10.70.117.1 with SMTP id p1mr922448wxc.1165393662146; Wed, 06 Dec 2006 00:27:42 -0800 (PST) Received: from ?192.168.1.101? ( [67.181.218.96]) by mx.google.com with ESMTP id 26sm65962944wrl.2006.12.06.00.27.40; Wed, 06 Dec 2006 00:27:41 -0800 (PST) Message-ID: <45767EF8.6080505@gmail.com> Date: Wed, 06 Dec 2006 00:27:36 -0800 From: James M Snell User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: fantasai CC: Mark Baker , atom-protocol , atom-syntax , whatwg@whatwg.org Subject: Re: PaceEntryMediatype References: <456DB265.5090804@gmail.com> <45767CBF.1020908@inkedblade.net> In-Reply-To: <45767CBF.1020908@inkedblade.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Actually, for the form "application/atom+xml;type=entry" it's more likely that browsers will completely ignore the type param as they do currently. - James fantasai wrote: > [snip] > That means rel="feed" won't be implied on an Atom Entry document whether > the > new MIME type syntax is chosen to be > application/atom.entry+xml > or > application/atom+xml;type=entry > > It also won't be implied on an Atom feed document if the syntax > application/atom+xml;type=feed > or > application/atom+xml;type=archive > is used, as was suggested earlier. This gives us a way to say > > without implying > > and without dropping the 'type' attribute entirely (which was the other > solution pointed out on the whatwg list). > > ~fantasai > > From owner-atom-syntax@mail.imc.org Wed Dec 06 03:43:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrsNK-00063h-3I for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 03:43:34 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrsNI-0002yC-Nh for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 03:43:34 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB68RxMU014529; Wed, 6 Dec 2006 01:27:59 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB68RxUk014528; Wed, 6 Dec 2006 01:27:59 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from leucothea.site5.com (leucothea.redline.site5.com [216.118.97.161]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB68RwIp014517; Wed, 6 Dec 2006 01:27:59 -0700 (MST) (envelope-from fantasai.lists@inkedblade.net) Received: from 121-72-128-96.dsl.telstraclear.net ([121.72.128.96] helo=[10.1.1.4]) by leucothea.site5.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.52) id 1Grs8D-00019Z-4g; Wed, 06 Dec 2006 03:27:57 -0500 Message-ID: <45767F05.7030804@inkedblade.net> Date: Wed, 06 Dec 2006 03:27:49 -0500 From: fantasai User-Agent: Thunderbird 1.5.0.8 (X11/20061117) MIME-Version: 1.0 To: Thomas Broyer CC: Atom-Syntax , Atom-Protocol Subject: Re: PaceEntryMediatype References: <456DB265.5090804@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: This message has been scanned by ClamAV. X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - leucothea.site5.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - inkedblade.net X-Source: X-Source-Args: X-Source-Dir: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Thomas Broyer wrote: > > 2006/11/29, James M Snell: >> Create a new media type for Atom Entry Documents: >> application/atomentry+xml >> >> Deprecate the use of application/atom+xml for Entry Documents. > > I'd largely prefer augmenting the existing media type with a 'type' > parameter: > - application/atom+xml => either feed or entry (as defined in RFC4287) > - application/atom+xml;type=feed => feed > - application/atom+xml;type=entry => entry I also think this is a nicer solution. It reflects that the two document types are fundamentally the same format. If there's no practical reason to have two actually separate MIME types, I think it would make more sense to differentiate entry and feed documents like this. ~fantasai From owner-atom-syntax@mail.imc.org Wed Dec 06 05:20:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrttD-0007sc-Ee for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 05:20:35 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrttA-0008Pa-UH for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 05:20:35 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB69wLBD024242; Wed, 6 Dec 2006 02:58:21 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB69wLSl024241; Wed, 6 Dec 2006 02:58:21 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB69wJIA024226; Wed, 6 Dec 2006 02:58:20 -0700 (MST) (envelope-from sewe@rbg.informatik.tu-darmstadt.de) Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.62) (envelope-from ) id 1GrtXe-0001e4-1h; Wed, 06 Dec 2006 10:58:18 +0100 Received: from ultra15.rbg.informatik.tu-darmstadt.de ([130.83.160.105]:39110) by mx2.freenet.de with esmtpsa (ID sewe2004@freenet.de) (TLSv1:AES256-SHA:256) (port 25) (Exim 4.62 #12) id 1GrtXd-00058e-K5; Wed, 06 Dec 2006 10:58:17 +0100 Message-ID: <45769431.4030409@rbg.informatik.tu-darmstadt.de> Date: Wed, 06 Dec 2006 10:58:09 +0100 From: Andreas Sewe Organization: Fachbereich Informatik, TU Darmstadt User-Agent: Thunderbird 1.5.0.8 (X11/20061110) MIME-Version: 1.0 To: James M Snell CC: atom-protocol , atom-syntax Subject: Re: PaceEntryMediatype References: <456DB265.5090804@gmail.com> <45767CBF.1020908@inkedblade.net> <45767EF8.6080505@gmail.com> In-Reply-To: <45767EF8.6080505@gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b James M Snell wrote: > Actually, for the form "application/atom+xml;type=entry" it's more > likely that browsers will completely ignore the type param as they do > currently. Well, if a browser ignores a media type's parameters, it will have to face the consequences: In the case of "application/atom+xml;type=entry" it would get "application/atom+xml" which means 'either an Atom Feed or Entry Document'; if it cannot handle Atom Entry Documents without breaking, it does not properly implement RFC 4287. But your point that *current* browsers silent discard a "type" parameter on "application/atom+xml" is moot anyway since the *current* Atom RFC specifies no such parameter. That being said, an *optional* type parameter offers the cleanest solution to distinguishing between the following three cases: 1) Either an Atom Feed or Entry Document 2) An Atom Feed Document 3) An Atom Entry Document If RFC 4287 had defined separate media types for the latter two cases, we wouldn't have this problem, of course: "Accept: application/atomfeed+xml, application/atomentry+xml" would cover the first case just fine. But since the RFC sadly doesn't I am extremely reluctant to either deprecating the use of "application/atom+xml" for Atom Entry Documents or to introducing three media types overall when an optional parameter suffices. So, James, what is wrong with "application/atom+xml;type=[entry|feed]"? (A slim majority on this list seems to prefer it over defining separate media types.) Regards, Andreas Sewe From owner-atom-syntax@mail.imc.org Wed Dec 06 09:22:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrxfZ-0002xV-Ug for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 09:22:45 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrxfV-00040s-72 for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 09:22:45 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB6E77vb057010; Wed, 6 Dec 2006 07:07:07 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB6E77de057008; Wed, 6 Dec 2006 07:07:07 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB6E75s3056993 for ; Wed, 6 Dec 2006 07:07:05 -0700 (MST) (envelope-from kmarvin@google.com) Received: from zps38.corp.google.com (zps38.corp.google.com [172.25.146.38]) by smtp-out.google.com with ESMTP id kB6E6w9P019236 for ; Wed, 6 Dec 2006 14:06:58 GMT DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:references; b=ABBkCoh6pDZfEfC9hxUcwYvfUJlNOmepdPg8EdwEtXeNk5Hx1O/M/YcqmW+4fiFvu NckeMaLhWI7RY+f81QRXQ== Received: from nz-out-0102.google.com (nzfm7.prod.google.com [10.36.189.7]) by zps38.corp.google.com with ESMTP id kB6E6sS8021754 for ; Wed, 6 Dec 2006 06:06:54 -0800 Received: by nz-out-0102.google.com with SMTP id m7so130810nzf for ; Wed, 06 Dec 2006 06:06:54 -0800 (PST) Received: by 10.65.236.14 with SMTP id n14mr1397637qbr.1165414014279; Wed, 06 Dec 2006 06:06:54 -0800 (PST) Received: by 10.64.183.10 with HTTP; Wed, 6 Dec 2006 06:06:54 -0800 (PST) Message-ID: <192fc9640612060606x5de9a988k8796a87e8fef153c@mail.gmail.com> Date: Wed, 6 Dec 2006 08:06:54 -0600 From: "Kyle Marvin" To: "Andreas Sewe" Subject: Re: PaceEntryMediatype Cc: "James M Snell" , atom-protocol , atom-syntax In-Reply-To: <45769431.4030409@rbg.informatik.tu-darmstadt.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_21504_28670432.1165414014093" References: <456DB265.5090804@gmail.com> <45767CBF.1020908@inkedblade.net> <45767EF8.6080505@gmail.com> <45769431.4030409@rbg.informatik.tu-darmstadt.de> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.2 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b ------=_Part_21504_28670432.1165414014093 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I feel like this whole discussion about whether an entry is logically equivalent to a feed is a little bit of a red herring. To me, the important justification for forking the Atom content type comes from a belief that this is useful information that you need *before* you retrieve/process the target document. I think we can all agree that parsing/syntax alone isn't enough to justify this; there are many existing Atom parsing impls that can handle the current approach just fine, and lots of counter examples of other MIME types that do even more overloading of multiple semantic content types under a single syntactic content type (ex "text/xml"). Something which can't handle the current range of potential Atom document contents for "application/atom+xml" doesn't seem like a strong argument either. We all know it's _possible_, it's just that in some contexts (like feed reading) it hasn't been considered _interesting_ to implement entry handling. I don't think a new MIME type fixes this, there are lots of real world cases of software developers who only implement a subset of a spec that they find is interesting or useful, it's always gonna happen but often gets fixed. I'm still looking for one or two use cases where having the distinction between whether a referenced document points to a feed or an entry is a vital thing. I can honestly say from the GData side we haven't seen this need yet, but that doesn't mean it exists. A link relation mght imply the content type (ex 'subscribe') or might be a logical relation that can apply to multiple content-types (as Lisa noted), but in the latter case what benefits do feed vs. entry doc distinction buy you? -- Kyle On 12/6/06, Andreas Sewe wrote: > > > James M Snell wrote: > > Actually, for the form "application/atom+xml;type=entry" it's more > > likely that browsers will completely ignore the type param as they do > > currently. > > Well, if a browser ignores a media type's parameters, it will have to > face the consequences: In the case of "application/atom+xml;type=entry" > it would get "application/atom+xml" which means 'either an Atom Feed or > Entry Document'; if it cannot handle Atom Entry Documents without > breaking, it does not properly implement RFC 4287. But your point that > *current* browsers silent discard a "type" parameter on > "application/atom+xml" is moot anyway since the *current* Atom RFC > specifies no such parameter. > > That being said, an *optional* type parameter offers the cleanest > solution to distinguishing between the following three cases: > > 1) Either an Atom Feed or Entry Document > 2) An Atom Feed Document > 3) An Atom Entry Document > > If RFC 4287 had defined separate media types for the latter two cases, > we wouldn't have this problem, of course: "Accept: > application/atomfeed+xml, application/atomentry+xml" would cover the > first case just fine. > > But since the RFC sadly doesn't I am extremely reluctant to either > deprecating the use of "application/atom+xml" for Atom Entry Documents > or to introducing three media types overall when an optional parameter > suffices. > > So, James, what is wrong with "application/atom+xml;type=[entry|feed]"? > (A slim majority on this list seems to prefer it over defining separate > media types.) > > Regards, > > Andreas Sewe > > ------=_Part_21504_28670432.1165414014093 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I feel like this whole discussion about whether an entry is logically equivalent to a feed is a little bit of a red herring.   To me, the important justification for forking the Atom content type comes from a belief that this is useful information that you need *before* you retrieve/process the target document.

I think we can all agree that parsing/syntax alone isn't enough to justify this;  there are many existing Atom parsing impls that can handle the current approach just fine, and lots of counter examples of other MIME types that do even more overloading of multiple semantic content types under a single syntactic content type (ex "text/xml").  

Something which can't handle the current range of potential Atom document contents for "application/atom+xml" doesn't seem like a strong argument either.   We all know it's _possible_, it's just that in some contexts (like feed reading) it hasn't been considered _interesting_ to implement entry handling.  I don't think a new MIME type fixes this, there are lots of real world cases of software developers who only implement a subset of a spec that they find is interesting or useful, it's always gonna happen but often gets fixed.

I'm still looking for one or two use cases where having the distinction between whether a referenced document points to a feed or an entry is a vital thing.   I can honestly say from the GData side we haven't seen this need yet, but that doesn't mean it exists.   A link relation mght imply the content type (ex 'subscribe') or might be a logical relation that can apply to multiple content-types (as Lisa noted), but in the latter case what benefits do feed vs. entry doc distinction buy you?

-- Kyle

On 12/6/06, Andreas Sewe <sewe@rbg.informatik.tu-darmstadt.de> wrote:

James M Snell wrote:
> Actually, for the form "application/atom+xml;type=entry" it's more
> likely that browsers will completely ignore the type param as they do
> currently.

Well, if a browser ignores a media type's parameters, it will have to
face the consequences: In the case of "application/atom+xml;type=entry"
it would get "application/atom+xml" which means 'either an Atom Feed or
Entry Document'; if it cannot handle Atom Entry Documents without
breaking, it does not properly implement RFC 4287. But your point that
*current* browsers silent discard a "type" parameter on
"application/atom+xml" is moot anyway since the *current* Atom RFC
specifies no such parameter.

That being said, an *optional* type parameter offers the cleanest
solution to distinguishing between the following three cases:

   1) Either an Atom Feed or Entry Document
   2) An Atom Feed Document
   3) An Atom Entry Document

If RFC 4287 had defined separate media types for the latter two cases,
we wouldn't have this problem, of course: "Accept:
application/atomfeed+xml, application/atomentry+xml" would cover the
first case just fine.

But since the RFC sadly doesn't I am extremely reluctant to either
deprecating the use of "application/atom+xml" for Atom Entry Documents
or to introducing three media types overall when an optional parameter
suffices.

So, James, what is wrong with "application/atom+xml;type=[entry|feed]"?
(A slim majority on this list seems to prefer it over defining separate
media types.)

Regards,

Andreas Sewe


------=_Part_21504_28670432.1165414014093-- From owner-atom-syntax@mail.imc.org Wed Dec 06 11:03:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrzF5-0000Co-O7 for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 11:03:31 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrzF0-0003m1-Bm for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 11:03:31 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB6FikDX068277; Wed, 6 Dec 2006 08:44:46 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB6FikGe068276; Wed, 6 Dec 2006 08:44:46 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB6Fijfm068260; Wed, 6 Dec 2006 08:44:45 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.213.125] (unknown [193.120.101.26]) by chilco.textdrive.com (Postfix) with ESMTP id 28659DC777; Wed, 6 Dec 2006 15:44:39 +0000 (UTC) Message-ID: <4576E564.5010100@dehora.net> Date: Wed, 06 Dec 2006 15:44:36 +0000 From: Bill de hOra User-Agent: Thunderbird 1.5.0.8 (X11/20061117) MIME-Version: 1.0 To: atom-syntax CC: atom-protocol Subject: Re: PaceEntryMediatype References: <456DB265.5090804@gmail.com> <456EF996.7060009@defuze.org> <4574759D.1070904@gmail.com> <45748679.70602@gmail.com> <4575D37D.8080909@gmail.com> <45764C7A.5040008@gmail.com> In-Reply-To: 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: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Mark Baker wrote: > Isn't that just a case of people not implementing the whole spec > though? Not really. The RFC defines the structure, not so much the interaction model around feeds (which is driven by UIs more than anything else, so I can buy into it being somewhat arbitrary) > Or, are there applications which only process entry documents and not > feed documents? Anything based on Atom Protocol will be making a distinction. cheers Bill From owner-atom-syntax@mail.imc.org Wed Dec 06 11:43:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grzs3-0000my-HF for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 11:43:47 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Grzrv-0002ez-7b for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 11:43:47 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB6GPxWK072949; Wed, 6 Dec 2006 09:25:59 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB6GPxaK072948; Wed, 6 Dec 2006 09:25:59 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.238]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB6GPvKn072942 for ; Wed, 6 Dec 2006 09:25:58 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i20so161994wra for ; Wed, 06 Dec 2006 08:25:57 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=IS4K/zGDWofcKIFZXM2xIrOL+uFZyEIwlWjD1KecuskY7FyGcQgZ9FkMhlxVHxszeXiAcIU960fjDcZZk04EDC5INDkV0NSI40MBXsTFU+wBC/XRA32CbXI8rIm1rSEcv45UsExslVBLiKd5lmIQOzk/1l9jCzpOTvU/aRwiRLo= Received: by 10.100.58.4 with SMTP id g4mr628936ana.1165422357294; Wed, 06 Dec 2006 08:25:57 -0800 (PST) Received: from ?192.168.1.101? ( [67.181.218.96]) by mx.google.com with ESMTP id 33sm48115617wra.2006.12.06.08.25.55; Wed, 06 Dec 2006 08:25:56 -0800 (PST) Message-ID: <4576EF10.5000600@gmail.com> Date: Wed, 06 Dec 2006 08:25:52 -0800 From: James M Snell User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: Andreas Sewe CC: atom-protocol , atom-syntax Subject: Re: PaceEntryMediatype References: <456DB265.5090804@gmail.com> <45767CBF.1020908@inkedblade.net> <45767EF8.6080505@gmail.com> <45769431.4030409@rbg.informatik.tu-darmstadt.de> In-Reply-To: <45769431.4030409@rbg.informatik.tu-darmstadt.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c The key problem I have with the ;type=param is that it's optional and likely to be ignored by a good number of implementations (which ends up buying us nothing in terms of interop). A separate media type is less ideal but has greater practical value in that it addresses the problem immediately. - James Andreas Sewe wrote: > James M Snell wrote: >> Actually, for the form "application/atom+xml;type=entry" it's more >> likely that browsers will completely ignore the type param as they do >> currently. > > Well, if a browser ignores a media type's parameters, it will have to > face the consequences: In the case of "application/atom+xml;type=entry" > it would get "application/atom+xml" which means 'either an Atom Feed or > Entry Document'; if it cannot handle Atom Entry Documents without > breaking, it does not properly implement RFC 4287. But your point that > *current* browsers silent discard a "type" parameter on > "application/atom+xml" is moot anyway since the *current* Atom RFC > specifies no such parameter. > > That being said, an *optional* type parameter offers the cleanest > solution to distinguishing between the following three cases: > > 1) Either an Atom Feed or Entry Document > 2) An Atom Feed Document > 3) An Atom Entry Document > > If RFC 4287 had defined separate media types for the latter two cases, > we wouldn't have this problem, of course: "Accept: > application/atomfeed+xml, application/atomentry+xml" would cover the > first case just fine. > > But since the RFC sadly doesn't I am extremely reluctant to either > deprecating the use of "application/atom+xml" for Atom Entry Documents > or to introducing three media types overall when an optional parameter > suffices. > > So, James, what is wrong with "application/atom+xml;type=[entry|feed]"? > (A slim majority on this list seems to prefer it over defining separate > media types.) > > Regards, > > Andreas Sewe > > From owner-atom-syntax@mail.imc.org Wed Dec 06 12:35:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs0fs-0002VW-I9 for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 12:35:16 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs0eJ-00028N-Gb for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 12:33:40 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB6HBDOx077930; Wed, 6 Dec 2006 10:11:13 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB6HBD5Q077929; Wed, 6 Dec 2006 10:11:13 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB6HBBiv077914; Wed, 6 Dec 2006 10:11:12 -0700 (MST) (envelope-from sewe@rbg.informatik.tu-darmstadt.de) Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.62) (envelope-from ) id 1Gs0IY-0002We-7k; Wed, 06 Dec 2006 18:11:10 +0100 Received: from ultra15.rbg.informatik.tu-darmstadt.de ([130.83.160.105]:42256) by mx2.freenet.de with esmtpsa (ID sewe2004@freenet.de) (TLSv1:AES256-SHA:256) (port 25) (Exim 4.62 #12) id 1Gs0IY-0003Z0-5L; Wed, 06 Dec 2006 18:11:10 +0100 Message-ID: <4576F9A7.1040200@rbg.informatik.tu-darmstadt.de> Date: Wed, 06 Dec 2006 18:11:03 +0100 From: Andreas Sewe Organization: Fachbereich Informatik, TU Darmstadt User-Agent: Thunderbird 1.5.0.8 (X11/20061110) MIME-Version: 1.0 To: James M Snell CC: atom-protocol , atom-syntax Subject: Re: PaceEntryMediatype References: <456DB265.5090804@gmail.com> <45767CBF.1020908@inkedblade.net> <45767EF8.6080505@gmail.com> <45769431.4030409@rbg.informatik.tu-darmstadt.de> <4576EF10.5000600@gmail.com> In-Reply-To: <4576EF10.5000600@gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 James M Snell wrote: > The key problem I have with the ;type=param is that it's optional and > likely to be ignored by a good number of implementations (which ends up > buying us nothing in terms of interop). A separate media type is less > ideal but has greater practical value in that it addresses the problem > immediately. Understood. I don't think, however, that a separate media type for Entry Documents will solve more problems than it causes: Applications which adhere to RFC 4287 and accept both Feed and Entry Documents labeled as "application/atom+xml" won't recognize "application/atomentry+xml"; they will have to be updated. But, honestly, I would rather see those buggy applications updated which break whenever they encounter an Entry Document labeled correctly as "application/atom+xml". That's a bug waiting to be fixed anyway, whether we immediately deprecate the labeling of Entry Documents "application/atom+xml" or not; some Entry Documents have already escaped into the wild. Regards, Andreas Sewe From owner-atom-syntax@mail.imc.org Wed Dec 06 12:38:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs0iY-0004tX-L0 for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 12:38:02 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs0iT-0002wm-VF for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 12:38:02 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB6HF1BT078330; Wed, 6 Dec 2006 10:15:01 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB6HF1Xj078328; Wed, 6 Dec 2006 10:15:01 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from csmtp1.b-one.net (csmtp.b-one.net [195.47.247.21]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB6HEw8h078293; Wed, 6 Dec 2006 10:15:01 -0700 (MST) (envelope-from asbjorn@tigerstaden.no) Received: from quark (72.84-48-117.nextgentel.com [84.48.117.72]) by csmtp1.b-one.net (Postfix) with ESMTP id 2B77C19114EE7; Wed, 6 Dec 2006 18:14:52 +0100 (CET) Date: Wed, 06 Dec 2006 18:17:06 +0100 To: "Mark Baker" , "Jan Algermissen" Subject: Re: PaceEntryMediatype From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Cc: "James M Snell" , atom-protocol , atom-syntax Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <456DB265.5090804@gmail.com> <456E7DE0.8040002@gmail.com> <456EF996.7060009@defuze.org> <4574759D.1070904@gmail.com> <45748679.70602@gmail.com> Message-ID: In-Reply-To: User-Agent: Opera Mail/9.10 (Win32) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id kB6HF1BT078330 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 On Wed, 06 Dec 2006 05:22:24 +0100, Mark Baker wrote: > It wasn't the most illustrative choice of words, but what I'm looking > for is evidence that an entry is interpreted differently if it's found > in an entry document, than if it were found in a feed document. If we > turn up multiple interoperable examples of that, then a new media type > is warranted because it's really two formats masquerading as one. To turn it a bit around: Would you ever want to subscribe to a single Ato= m =20 Entry? If not, wouldn't it be good to know that it was an Atom Entry and = =20 not an Atom Feed before you started subscribing to it? --=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 Wed Dec 06 13:35:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs1cI-0005Xo-T8 for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 13:35:38 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs1cG-0003TZ-CO for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 13:35:38 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB6IKjWL085538; Wed, 6 Dec 2006 11:20:45 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB6IKie9085536; Wed, 6 Dec 2006 11:20:44 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB6IKf9L085522 for ; Wed, 6 Dec 2006 11:20:44 -0700 (MST) (envelope-from henry.story@bblfish.net) Received: (qmail 97995 invoked by uid 17064); 6 Dec 2006 18:20:41 -0000 Received: from unknown (HELO [10.1.1.108]) ([64.162.56.198]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 6 Dec 2006 18:20:41 -0000 In-Reply-To: <3D25545BFA30684F8403E7A8C1C4422C025C35A0@sfoexch1.mm-ads.com> References: <3D25545BFA30684F8403E7A8C1C4422C025C35A0@sfoexch1.mm-ads.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <50810085-D476-4A96-B377-79319AF844BD@bblfish.net> Cc: Atom Protocol Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: In San Francisco/Bay Area Date: Wed, 6 Dec 2006 10:20:41 -0800 To: Terris Linenbach , Atom Syntax X-Mailer: Apple Mail (2.752.3) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Sorry for being so imprecise. I was assuming so too. I don't know why I did not make it clearer. But if there were others who misread this and there are enough of them, we can also do it on Wednesday 13th. Henry On 6 Dec 2006, at 10:14, Terris Linenbach wrote: > It is unclear reading this thread whether it's for today which I > assume > it is. > > Terris > > -----Original Message----- > From: Henry Story [mailto:henry.story@bblfish.net] > Sent: Tuesday, December 05, 2006 9:42 PM > To: John Panzer > Cc: Lisa Dusseault; Atom Protocol; Atom > Subject: Re: In San Francisco/Bay Area > > > I'll be there at 6:30pm then. I imagine people will not be wanting to > stay very late. > > Henry > > On 5 Dec 2006, at 21:26, John Panzer wrote: > >> Lisa ran in to me today and reminded me about the meet up >> (thanks!). I will try hard to make it; is there a definite time >> set? (6pm is slightly better for me, but 7pm is okay too.) >> >> -John >> >> Lisa Dusseault wrote: >>> >>> Thanks for setting this up Henry, I can be there Dec 6. 7pm is >>> much easier to make than 6pm if anybody's coming far, even just >>> from SF. >>> >>> Lisa >>> >>> On Dec 1, 2006, at 12:08 PM, Henry Story wrote: >>> >>>> >>>> Ok I suggest trying December 6th. >>>> Onion or no Onion rings at Tied House. >>>> >>>> What is dinner time in the bay? 6pm? 7pm? >>>> >>>> Henry >>>> >>>>> On 28 Nov 2006, at 21:31, John Panzer wrote: >>>>> >>>>> Any of those would be good for me. Be careful of the deep >>>>> fried onion rings at Tied House, though. >>>>> >>>>>> Henry Story wrote: >>>>>> >>>>>> It has been suggested that a good meeting location might be >>>>>> Tied House in Mountain View [1]. It has a back room that's >>>>>> like a patio but covered and heated for dinner on either >>>>>> >>>>>> Wednesday 6th Dec >>>>>> Friday 8th Dec >>>>>> Monday 11th Dec >>>>>> Wednesday 13th Dec >>>>>> >>>>>> Any preferences? >>>>>> >>>>>> Henry Story >>>>>> >>>>>> [1] http://www.tiedhouse.com/ >>>>>> >>>>>>> On 16 Nov 2006, at 18:23, Henry Story wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I am in the San Francisco/Bay Area region for the coming >>>>>>> month. Would anyone in the area be up for a group meeting? >>>>>>> >>>>>>> Henry >>>>>>> >>>> >>> >> >> >> -- >> >> >> John Panzer >> System Architect >> http://abstractioneer.org > From owner-atom-syntax@mail.imc.org Wed Dec 06 13:35:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs1cM-0005Y3-88 for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 13:35:42 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs1cK-0003U5-Rx for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 13:35:42 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB6IEACk084941; Wed, 6 Dec 2006 11:14:10 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB6IEAQh084938; Wed, 6 Dec 2006 11:14:10 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.46]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB6IE909084928; Wed, 6 Dec 2006 11:14:10 -0700 (MST) (envelope-from algermissen1971@mac.com) Received: from mac.com (webmail020-S [10.13.128.20]) by smtpout.mac.com (Xserve/8.12.11/smtpout10/MantshX 4.0) with ESMTP id kB6IE6Y4008711; Wed, 6 Dec 2006 10:14:06 -0800 (PST) Received: from webmail020 (localhost [127.0.0.1]) by mac.com (8.13.8/webmail020/MantshX 4.0) with ESMTP id kB6IE4ov028841; Wed, 6 Dec 2006 10:14:05 -0800 (PST) Date: Wed, 06 Dec 2006 10:14:04 -0800 From: Jan Algermissen To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= Cc: Mark Baker , James M Snell , atom-protocol , atom-syntax Message-ID: in-reply-to: references: <456DB265.5090804@gmail.com> <456E7DE0.8040002@gmail.com> <456EF996.7060009@defuze.org> <4574759D.1070904@gmail.com> <45748679.70602@gmail.com> Subject: Re: PaceEntryMediatype MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 193.7.250.35 Received: from [193.7.250.35] from webmail.mac.com with HTTP; Wed, 06 Dec 2006 10:14:04 -0800 X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.5 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 >To turn it a bit around: Would you ever want to subscribe to a single Atom >Entry? If not, wouldn't it be good to know that it was an Atom Entry and >not an Atom Feed before you started subscribing to it? This is misleading wording (and maybe part of the overall problem)! Following a link is not the same thing as subscribing to something. The act of subscribing is a local activity performed by the user agent. What you do when you follow the link to a feed is a GET. Your agent then decides if subscribing to that resource is a good idea. To make that decision, the agent has to look at the representation and the it is insignificant overhead to see if the thing returnes or . Anyhow, why not monitor a single entry? I think this is far more a user agent configuration issue than it is a problem of the media type being returned. FWIW, I think the question of media type (or the feed-ness of some resource) and the issue of whether to subscribe or not are completely orthogonal. Maybe I want to monitor a single media resource; an Atom media entry would be an ideal thing to do so (I'd rather look at the meta data than at the media resource upon each poll). I'd say: stick with the one media type that is currently there - there is no problem, just misconception about what it means to subscribe. Jan From owner-atom-syntax@mail.imc.org Wed Dec 06 14:30:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs2TL-0006pQ-TC for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 14:30:27 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs2TJ-0002xG-Fn for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 14:30:27 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB6JBWim091133; Wed, 6 Dec 2006 12:11:32 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB6JBWgP091132; Wed, 6 Dec 2006 12:11:32 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxsf33.cluster1.charter.net (mxsf33.cluster1.charter.net [209.225.28.158]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB6JBTJ6091111 for ; Wed, 6 Dec 2006 12:11:31 -0700 (MST) (envelope-from antone@geckotribe.com) Received: from mxip24a.cluster1.charter.net (mxip24a.cluster1.charter.net [209.225.28.154]) by mxsf33.cluster1.charter.net (8.12.11.20060308/8.12.11) with ESMTP id kB6JBK5b010359 for ; Wed, 6 Dec 2006 14:11:23 -0500 Received: from 68-118-146-150.dhcp.gdis.ne.charter.com (HELO [192.168.2.3]) ([68.118.146.150]) by mxip24a.cluster1.charter.net with ESMTP; 06 Dec 2006 14:11:21 -0500 X-IronPort-AV: i="4.09,505,1157342400"; d="scan'208"; a="925948475:sNHT17309588" Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: <456DB265.5090804@gmail.com> <456E7DE0.8040002@gmail.com> <456EF996.7060009@defuze.org> <4574759D.1070904@gmail.com> <45748679.70602@gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Antone Roundy Subject: Re: PaceEntryMediatype Date: Wed, 6 Dec 2006 13:11:17 -0600 To: atom-syntax@imc.org X-Mailer: Apple Mail (2.752.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 On Dec 6, 2006, at 12:14 PM, Jan Algermissen wrote: > Following a link is not the same thing as subscribing to something. > The act of subscribing is a local activity performed by the user > agent. What you do when you follow the link to a feed is a GET. > Your agent then decides if subscribing to that resource is a good > idea. To make that decision, the agent has to look at the > representation and the it is insignificant overhead to see if the > thing returnes or . > > ... > > Maybe I want to monitor a single media resource; an Atom media > entry would be an ideal thing to do so (I'd rather look at the meta > data than at the media resource upon each poll). > > I'd say: stick with the one media type that is currently there - > there is no problem, just misconception about what it means to > subscribe. A few reasons why a user agent might want to be able to tell the difference between a link to a feed and a link to an entry beforehand is in order to: 1) be able to ignore the link to the entry (ie. not present it to the user) if the user agent doesn't handle entry documents (rather than presenting it as a "subscribe" link, only to have to say "sorry, it's not a feed" after the user tries to subscribe). 2) be able to say "subscribe" to links to feeds, and "monitor" links to entries (the user may not be interested in monitoring a single entry for changes--if they can't tell that that's what the link is for, they may end up needlessly doing so but think that they've added another feed to their subscription list). From owner-atom-syntax@mail.imc.org Wed Dec 06 14:56:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs2sV-0004Y6-1f for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 14:56:27 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs2sT-0006Qu-Ko for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 14:56:27 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB6JghCN094580; Wed, 6 Dec 2006 12:42:43 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB6JghfC094579; Wed, 6 Dec 2006 12:42:43 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.46]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB6Jghbd094566 for ; Wed, 6 Dec 2006 12:42:43 -0700 (MST) (envelope-from algermissen1971@mac.com) Received: from mac.com (webmail020-S [10.13.128.20]) by smtpout.mac.com (Xserve/8.12.11/smtpout10/MantshX 4.0) with ESMTP id kB6JggjR010617; Wed, 6 Dec 2006 11:42:42 -0800 (PST) Received: from webmail020 (localhost [127.0.0.1]) by mac.com (8.13.8/webmail020/MantshX 4.0) with ESMTP id kB6JgeQb001695; Wed, 6 Dec 2006 11:42:41 -0800 (PST) Date: Wed, 06 Dec 2006 11:42:40 -0800 From: Jan Algermissen To: Antone Roundy Cc: atom-syntax@imc.org Message-ID: <8B583D59-010F-1000-826F-7EB2F9E7E3CB-Webmail-10013@mac.com> in-reply-to: references: <456DB265.5090804@gmail.com> <456E7DE0.8040002@gmail.com> <456EF996.7060009@defuze.org> <4574759D.1070904@gmail.com> <45748679.70602@gmail.com> Subject: Re: PaceEntryMediatype MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 193.7.250.35 Received: from [193.7.250.35] from webmail.mac.com with HTTP; Wed, 06 Dec 2006 11:42:40 -0800 X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.5 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f On Wednesday, December 06, 2006, at 08:30PM, "Antone Roundy" wrote: > >On Dec 6, 2006, at 12:14 PM, Jan Algermissen wrote: >> >> I'd say: stick with the one media type that is currently there - >> there is no problem, just misconception about what it means to >> subscribe. > >A few reasons why a user agent might want to be able to tell the >difference between a link to a feed and a link to an entry beforehand >is in order to: But that is an issue of linking semantics, not link target media types. I'd expect the user agent to look for links with 'here is a feed' semantics instead of looking for (arbitrary) links to certain media types. IMHO, there is something going wrong somewhere - and it ain't the media type. Jan > >1) be able to ignore the link to the entry (ie. not present it to the >user) if the user agent doesn't handle entry documents (rather than >presenting it as a "subscribe" link, only to have to say "sorry, it's >not a feed" after the user tries to subscribe). > >2) be able to say "subscribe" to links to feeds, and "monitor" links >to entries (the user may not be interested in monitoring a single >entry for changes--if they can't tell that that's what the link is >for, they may end up needlessly doing so but think that they've added >another feed to their subscription list). > > > > From owner-atom-syntax@mail.imc.org Wed Dec 06 16:32:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs4NS-0007Vv-Uh for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 16:32:30 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs4N9-0001zb-3A for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 16:32:30 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB6L7hbG003805; Wed, 6 Dec 2006 14:07:43 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB6L7hwV003804; Wed, 6 Dec 2006 14:07:43 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB6L7glT003796 for ; Wed, 6 Dec 2006 14:07:42 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.2.180] (unknown [83.70.238.233]) by chilco.textdrive.com (Postfix) with ESMTP id 90F92DC7A5 for ; Wed, 6 Dec 2006 21:07:36 +0000 (UTC) Message-ID: <45773116.4010302@dehora.net> Date: Wed, 06 Dec 2006 21:07:34 +0000 From: Bill de hOra User-Agent: Thunderbird 1.5.0.8 (X11/20061117) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: PaceEntryMediatype References: <456DB265.5090804@gmail.com> <456E7DE0.8040002@gmail.com> <456EF996.7060009@defuze.org> <4574759D.1070904@gmail.com> <45748679.70602@gmail.com> In-Reply-To: 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: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Antone Roundy wrote: > > On Dec 6, 2006, at 12:14 PM, Jan Algermissen wrote: >> Following a link is not the same thing as subscribing to something. >> The act of subscribing is a local activity performed by the user >> agent. What you do when you follow the link to a feed is a GET. Your >> agent then decides if subscribing to that resource is a good idea. To >> make that decision, the agent has to look at the representation and >> the it is insignificant overhead to see if the thing returnes >> or . >> >> ... >> >> Maybe I want to monitor a single media resource; an Atom media entry >> would be an ideal thing to do so (I'd rather look at the meta data >> than at the media resource upon each poll). >> >> I'd say: stick with the one media type that is currently there - >> there is no problem, just misconception about what it means to subscribe. > > A few reasons why a user agent might want to be able to tell the > difference between a link to a feed and a link to an entry beforehand is > in order to: > > 1) be able to ignore the link to the entry (ie. not present it to the > user) if the user agent doesn't handle entry documents (rather than > presenting it as a "subscribe" link, only to have to say "sorry, it's > not a feed" after the user tries to subscribe). > > 2) be able to say "subscribe" to links to feeds, and "monitor" links to > entries (the user may not be interested in monitoring a single entry for > changes--if they can't tell that that's what the link is for, they may > end up needlessly doing so but think that they've added another feed to > their subscription list). 3) to open an entry in an editing app. Datapoint: double clicking on an Atom Entry file in Ubuntu results in the following: [[[ The filename "LE1100_1254262_1_4E760C4E-36D9-065D-7AF7-FB168427888D_1081337005687.xml" indicates that this file is of type "XML document". The contents of the file indicate that the file is of type "Draft journal entry". If you open this file, the file might present a security risk to your system. Do not open the file unless you created the file yourself, or received the file from a trusted source. To open the file, rename the file to the correct extension for "Draft journal entry", then open the file normally. Alternatively, use the Open With menu to choose a specific application for the file. ]]] I believe this is because I had drivel installed at one point. Double clicking on an Atom Feed document opens it in Firefox. I'm kind of surprised by this, but thinking about it, you don't really write feeds, but you do write entries. cheers Bill From owner-atom-syntax@mail.imc.org Wed Dec 06 17:02:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs4q7-0004c8-0V for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 17:02:07 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs4py-0006P1-4l for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 17:02:06 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB6Lhwgk007015; Wed, 6 Dec 2006 14:43:58 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB6Lhw30007014; Wed, 6 Dec 2006 14:43:58 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.237]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB6Lhsp8006986 for ; Wed, 6 Dec 2006 14:43:57 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i20so245059wra for ; Wed, 06 Dec 2006 13:43:52 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=O8TqI1oMTdXdXQA2LJoDrSjsfI4M3FB4kGq86u4YoCm0LnuhO5XASGQy28+8PFWetgf2rJI7BM7oWSZJ81V3LxF7bV72nCpkKGivPkYxBHPsSQnt5tZemN5oOyslrzKydhFzXNHQ1d1nnzt2L7cK5qiXzg6tbdjCv8cge0tdNeI= Received: by 10.100.154.13 with SMTP id b13mr976932ane.1165441432144; Wed, 06 Dec 2006 13:43:52 -0800 (PST) Received: from ?192.168.1.101? ( [67.181.218.96]) by mx.google.com with ESMTP id 12sm16642189wrl.2006.12.06.13.43.40; Wed, 06 Dec 2006 13:43:51 -0800 (PST) Message-ID: <4577397F.1020906@gmail.com> Date: Wed, 06 Dec 2006 13:43:27 -0800 From: James M Snell User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: Andreas Sewe CC: atom-protocol , atom-syntax Subject: Re: PaceEntryMediatype References: <456DB265.5090804@gmail.com> <45767CBF.1020908@inkedblade.net> <45767EF8.6080505@gmail.com> <45769431.4030409@rbg.informatik.tu-darmstadt.de> <4576EF10.5000600@gmail.com> <4576F9A7.1040200@rbg.informatik.tu-darmstadt.de> In-Reply-To: <4576F9A7.1040200@rbg.informatik.tu-darmstadt.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Andreas Sewe wrote: > [snip] > Applications which adhere to RFC 4287 and accept both Feed and Entry > Documents labeled as "application/atom+xml" won't recognize > "application/atomentry+xml"; they will have to be updated. > In consider that a feature. - James From owner-atom-syntax@mail.imc.org Wed Dec 06 17:26:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs5Dy-0007bq-VO for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 17:26:46 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs5Dg-0002a2-8b for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 17:26:46 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB6LxwCE008632; Wed, 6 Dec 2006 14:59:58 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB6LxwpR008631; Wed, 6 Dec 2006 14:59:58 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from csmtp1.b-one.net (csmtp.b-one.net [195.47.247.21]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB6LxuiS008608; Wed, 6 Dec 2006 14:59:57 -0700 (MST) (envelope-from asbjorn@tigerstaden.no) Received: from quark (72.84-48-117.nextgentel.com [84.48.117.72]) by csmtp1.b-one.net (Postfix) with ESMTP id E43F31911EDD4; Wed, 6 Dec 2006 22:59:50 +0100 (CET) Date: Wed, 06 Dec 2006 23:01:31 +0100 To: "Jan Algermissen" Subject: Re: PaceEntryMediatype From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Cc: "Mark Baker" , "James M Snell" , atom-protocol , atom-syntax Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <456DB265.5090804@gmail.com> <456E7DE0.8040002@gmail.com> <456EF996.7060009@defuze.org> <4574759D.1070904@gmail.com> <45748679.70602@gmail.com> Message-ID: In-Reply-To: User-Agent: Opera Mail/9.10 (Win32) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id kB6LxwCE008632 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 On Wed, 06 Dec 2006 19:14:04 +0100, Jan Algermissen =20 wrote: > This is misleading wording (and maybe part of the overall problem)! Perhaps, but it describes one of the most important use-cases with feeds = =20 -- which won't be the one with entries. > Following a link is not the same thing as subscribing to something. Of course not. > The act of subscribing is a local activity performed by the user agent. > What you do when you follow the link to a feed is a GET. Yep. But why would you do the GET in the first place? In what use case =20 scenario would you put GET-ing an URI that returns an Atom Entry compared= =20 to one that returns an Atom Feed? > Your agent then decides if subscribing to that resource is a good idea. How does it decide? By parsing the whole document first, e.g. content =20 sniffing? > To make that decision, the agent has to look at the representation and > the it is insignificant overhead to see if the thing returnes > or . Not if the resource needn't be GET in the first place. If the whole =20 operation can be decided upon the Content-Type returned in a HEAD request= , =20 or even better; by the value in the @type attribute of whatever element =20 referring to this resource, the client won't have to do a GET at all on =20 resources it doesn't know how to handle properly. Most feed readers knows= =20 how to handle feeds, but have no idea how to handle entries. When pointed at a URI they can say "Hey, I can't subscribe to this!" if =20 the Content-Type is 'text/html', 'application/octet-stream' or whatever, = =20 but if the Content-Type is 'application/atom+xml', they think "Hey, this = =20 is a feed I can subscribe to!" and will in most cases fail because what =20 they're trying to subscribe to isn't an Atom Feed but an Atom Entry. Knowing before the GET whether the resource can be subscribed to (or =20 whatever you may want to do with either entries or feeds separately) or =20 not is useful information. And please note that "subscribe" is used here = =20 as a single use-case for the endless amounts of use-cases that will diffe= r =20 for Atom Feeds and Atom Entries. > Anyhow, why not monitor a single entry? That's of course possible, but you will be monitoring indirectly if you'r= e =20 subscribing to a feed that has that entry and changes to that entry gets = =20 re-published to the same feed. However, that's not the issue at hand here. > I think this is far more a user agent configuration issue than it is a > problem of the media type being returned. I disagree. > FWIW, I think the question of media type (or the feed-ness of some =20 > resource) and the issue of whether to subscribe or not are completely =20 > orthogonal. They are and they aren't. --=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 Wed Dec 06 17:50:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs5ap-0002Am-F7 for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 17:50:23 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs5an-0008BU-Sf for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 17:50:23 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB6MQ1x3012342; Wed, 6 Dec 2006 15:26:01 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB6MQ11l012340; Wed, 6 Dec 2006 15:26:01 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.174]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB6MQ0Ps012325; Wed, 6 Dec 2006 15:26:01 -0700 (MST) (envelope-from algermissen1971@mac.com) Received: from mac.com (smtpin06-en2 [10.13.10.151]) by smtpout.mac.com (Xserve/8.12.11/smtpout04/MantshX 4.0) with ESMTP id kB6MPu82023680; Wed, 6 Dec 2006 14:25:56 -0800 (PST) Received: from [10.0.1.2] (d192106.adsl.hansenet.de [80.171.192.106]) (authenticated bits=0) by mac.com (Xserve/smtpin06/MantshX 4.0) with ESMTP id kB6MPobW022183; Wed, 6 Dec 2006 14:25:52 -0800 (PST) In-Reply-To: References: <456DB265.5090804@gmail.com> <456E7DE0.8040002@gmail.com> <456EF996.7060009@defuze.org> <4574759D.1070904@gmail.com> <45748679.70602@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <836A6AB5-5E29-455D-B210-84E85FA51D3B@mac.com> Cc: Mark Baker , James M Snell , atom-protocol , atom-syntax From: Jan Algermissen Subject: Re: PaceEntryMediatype Date: Wed, 6 Dec 2006 23:26:10 +0100 To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kB6MQ1Ps012328 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id kB6MQ1x3012342 X-Spam-Score: 0.5 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab On Dec 6, 2006, at 11:01 PM, Asbj=F8rn Ulsberg wrote: > On Wed, 06 Dec 2006 19:14:04 +0100, Jan Algermissen =20 > wrote: > >> This is misleading wording (and maybe part of the overall problem)! > > Perhaps, but it describes one of the most important use-cases with =20 > feeds -- which won't be the one with entries. Sorry, I do not understand what you mean. > >> Following a link is not the same thing as subscribing to something. > > Of course not. > >> The act of subscribing is a local activity performed by the user =20 >> agent. >> What you do when you follow the link to a feed is a GET. > > Yep. But why would you do the GET in the first place? In what use =20 > case scenario would you put GET-ing an URI that returns an Atom =20 > Entry compared to one that returns an Atom Feed? Again, sorry, I am unable to see what you are trying to tell me. Can =20 you explain? > >> Your agent then decides if subscribing to that resource is a good =20 >> idea. > > How does it decide? By parsing the whole document first, e.g. =20 > content sniffing? Not sniffing, but parsing. This would be done anyhow, no? You get =20 back a doc element object, look at the name of the root elemet and =20 dispatch. > >> To make that decision, the agent has to look at the representation =20 >> and >> the it is insignificant overhead to see if the thing returnes >> or . > > Not if the resource needn't be GET in the first place. If the whole =20 > operation can be decided upon the Content-Type returned in a HEAD =20 > request, or Ok, HEAD would save the extra payload, but....I still think the =20 reason for subscribing is NOT how the representation at the other end =20 looks, it is based on the link semantics. > even better; by the value in the @type attribute of whatever =20 > element referring to this resource, the client won't have to do a =20 > GET at all on resources it doesn't know how to handle properly. This would be against Web arch: Content-Type is authoritative and can =20 well overide whatever the type attribute says or said a year ago. > Most feed readers knows how to handle feeds, but have no idea how =20 > to handle entries. So they should be fixed, should they not? They seem to only have =20 implemented half a media type. > > When pointed at a URI they can say "Hey, I can't subscribe to this!" What about chaging that to have them open a 'select plugin for this =20 media type' dialog? How come the desire for making the user agent =20 rely on a certain, rather limited circumstance (getting a ). =20 Shouldn't Web agents be more actively-trying? > if the Content-Type is 'text/html', 'application/octet-stream' or =20 > whatever, but if the Content-Type is 'application/atom+xml', they =20 > think "Hey, this is a feed I can subscribe to!" Then they implemented the RFC incorrectly I'd say. > and will in most cases fail because what they're trying to =20 > subscribe to isn't an Atom Feed but an Atom Entry. Again, why be so defensive? If your browser behaved like that you'd =20 kick it out (I'd do so at least). > > Knowing before the GET whether the resource can be subscribed to =20 > (or whatever you may want to do with either entries or feeds =20 > separately) or not is useful information. Ok, but it is simply not authoritative. > And please note that "subscribe" is used here as a single use-case =20 > for the endless amounts of use-cases that will differ for Atom =20 > Feeds and Atom Entries. That is one of the concerns I have: subscribing is just *one* use =20 case...and not even an Atom specific one. > >> Anyhow, why not monitor a single entry? > > That's of course possible, but you will be monitoring indirectly if =20 > you're subscribing to a feed that has that entry and changes to =20 > that entry gets re-published to the same feed. However, that's not =20 > the issue at hand here. > >> I think this is far more a user agent configuration issue than it =20 >> is a >> problem of the media type being returned. > > I disagree. > >> FWIW, I think the question of media type (or the feed-ness of some =20 >> resource) and the issue of whether to subscribe or not are =20 >> completely orthogonal. > > They are and they aren't. Then, in what sense are they not orthogonal??? [good discusion anyhow :-)] Jan > > --=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 Wed Dec 06 17:51:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs5cD-0002f8-0U for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 17:51:49 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs5cB-0008Ph-Kb for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 17:51:48 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB6MUb2E013156; Wed, 6 Dec 2006 15:30:37 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB6MUbTM013155; Wed, 6 Dec 2006 15:30:37 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.237]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB6MUW80013127 for ; Wed, 6 Dec 2006 15:30:37 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i20so256500wra for ; Wed, 06 Dec 2006 14:30:32 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Lzhkky9L8+6l4IXFeTYZkbymyyhoa94o4mR/siSZ7DB/0k5O1MjzWMIAXq6W8E2IBPvLAJgdGK8TJMMSmCsRMcZ9r9E12ZCiTb5Vnwsym+rO5AuNqVU44sryNkfeP0X+OES03c5k5d/Bagzc6glohTdFjScPEBKkqvsQTlcSamE= Received: by 10.90.101.19 with SMTP id y19mr1632945agb.1165444232280; Wed, 06 Dec 2006 14:30:32 -0800 (PST) Received: from ?192.168.1.101? ( [67.181.218.96]) by mx.google.com with ESMTP id 34sm27662014wra.2006.12.06.14.30.30; Wed, 06 Dec 2006 14:30:31 -0800 (PST) Message-ID: <45774483.1050205@gmail.com> Date: Wed, 06 Dec 2006 14:30:27 -0800 From: James M Snell User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: Jan Algermissen CC: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= , Mark Baker , atom-protocol , atom-syntax Subject: Re: PaceEntryMediatype References: <456DB265.5090804@gmail.com> <456E7DE0.8040002@gmail.com> <456EF996.7060009@defuze.org> <4574759D.1070904@gmail.com> <45748679.70602@gmail.com> <836A6AB5-5E29-455D-B210-84E85FA51D3B@mac.com> In-Reply-To: <836A6AB5-5E29-455D-B210-84E85FA51D3B@mac.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Jan Algermissen wrote: > [snip] > So they should be fixed, should they not? They seem to only have > implemented half a media type. > The half they're interested in. Why aren't they interested in the other half? - James From owner-atom-syntax@mail.imc.org Wed Dec 06 17:58:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs5ib-0005hS-LG for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 17:58:25 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs5iS-0000oo-Rn for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 17:58:25 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB6MasGO014328; Wed, 6 Dec 2006 15:36:54 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB6MasAd014326; Wed, 6 Dec 2006 15:36:54 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.186]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB6Mar78014313; Wed, 6 Dec 2006 15:36:54 -0700 (MST) (envelope-from algermissen1971@mac.com) Received: from mac.com (smtpin06-en2 [10.13.10.151]) by smtpout.mac.com (Xserve/8.12.11/smtpout16/MantshX 4.0) with ESMTP id kB6MaoLN015798; Wed, 6 Dec 2006 14:36:50 -0800 (PST) Received: from [10.0.1.2] (d192106.adsl.hansenet.de [80.171.192.106]) (authenticated bits=0) by mac.com (Xserve/smtpin06/MantshX 4.0) with ESMTP id kB6MakPP026821; Wed, 6 Dec 2006 14:36:47 -0800 (PST) In-Reply-To: <45774483.1050205@gmail.com> References: <456DB265.5090804@gmail.com> <456E7DE0.8040002@gmail.com> <456EF996.7060009@defuze.org> <4574759D.1070904@gmail.com> <45748679.70602@gmail.com> <836A6AB5-5E29-455D-B210-84E85FA51D3B@mac.com> <45774483.1050205@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <582CE04E-B2AE-4546-9CB1-5F2A5579536F@mac.com> Cc: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= , Mark Baker , atom-protocol , atom-syntax Content-Transfer-Encoding: 7bit From: Jan Algermissen Subject: Re: PaceEntryMediatype Date: Wed, 6 Dec 2006 23:37:08 +0100 To: James M Snell X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.5 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 On Dec 6, 2006, at 11:30 PM, James M Snell wrote: > > > Jan Algermissen wrote: >> [snip] >> So they should be fixed, should they not? They seem to only have >> implemented half a media type. >> > > The half they're interested in. Why aren't they interested in the > other > half? Ha! Forget about the media type - let's drop entry documents. Jan > > - James From owner-atom-syntax@mail.imc.org Wed Dec 06 18:07:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs5rM-0000y7-K4 for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 18:07:28 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs5rJ-0002Jz-6x for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 18:07:28 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB6MiSvA015875; Wed, 6 Dec 2006 15:44:28 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB6MiS4e015874; Wed, 6 Dec 2006 15:44:28 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.232]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB6MiRh6015866 for ; Wed, 6 Dec 2006 15:44:28 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id i30so347077wxd for ; Wed, 06 Dec 2006 14:44:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=ZAYfqTfEto+lqdffZrl/K4+atBeGbMMupzmE2vBeQxhep7wGMI9tmrAnbXm1c7skQDJ6jb1nCG+w5+uYqNJPV+UfID+MUT3WCI65wKRbSPRvmrxevvonb7ErwsBU6KMJO6NDsDouYUBdYCJ8n0J5na7vrf89zY1CTJojnAhaDLQ= Received: by 10.90.50.1 with SMTP id x1mr1694310agx.1165445067240; Wed, 06 Dec 2006 14:44:27 -0800 (PST) Received: from ?192.168.1.101? ( [67.181.218.96]) by mx.google.com with ESMTP id 8sm48767954wrl.2006.12.06.14.44.25; Wed, 06 Dec 2006 14:44:26 -0800 (PST) Message-ID: <457747C4.9090405@gmail.com> Date: Wed, 06 Dec 2006 14:44:20 -0800 From: James M Snell User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: Jan Algermissen CC: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= , Mark Baker , atom-protocol , atom-syntax Subject: Re: PaceEntryMediatype References: <456DB265.5090804@gmail.com> <456E7DE0.8040002@gmail.com> <456EF996.7060009@defuze.org> <4574759D.1070904@gmail.com> <45748679.70602@gmail.com> <836A6AB5-5E29-455D-B210-84E85FA51D3B@mac.com> <45774483.1050205@gmail.com> <582CE04E-B2AE-4546-9CB1-5F2A5579536F@mac.com> In-Reply-To: <582CE04E-B2AE-4546-9CB1-5F2A5579536F@mac.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 I certainly hope you're kidding about dropping entry docs. Let's just label 'em differently and move on. - James Jan Algermissen wrote: > > On Dec 6, 2006, at 11:30 PM, James M Snell wrote: > >> >> >> Jan Algermissen wrote: >>> [snip] >>> So they should be fixed, should they not? They seem to only have >>> implemented half a media type. >>> >> >> The half they're interested in. Why aren't they interested in the other >> half? > > > Ha! Forget about the media type - let's drop entry documents. > > Jan > >> >> - James > > From owner-atom-syntax@mail.imc.org Wed Dec 06 18:32:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs6FD-0004ND-8o for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 18:32:07 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs6FA-0006d4-T4 for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 18:32:07 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB6NBsIu018949; Wed, 6 Dec 2006 16:11:54 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB6NBsnr018948; Wed, 6 Dec 2006 16:11:54 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB6NBr9I018934 for ; Wed, 6 Dec 2006 16:11:53 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.2.180] (unknown [83.70.238.233]) by chilco.textdrive.com (Postfix) with ESMTP id A662FDC781 for ; Wed, 6 Dec 2006 23:11:45 +0000 (UTC) Message-ID: <45774E2E.2000300@dehora.net> Date: Wed, 06 Dec 2006 23:11:42 +0000 From: Bill de hOra User-Agent: Thunderbird 1.5.0.8 (X11/20061117) MIME-Version: 1.0 To: Atom Syntax Subject: feeds: what does atom:id denote? 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: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Hi, I'm sending entries over XMPP packaged up as feeds. A question that has come up - should the feed's atom:id change each time a feed is sent, or should it remain the same for all feeds issued from a client? cheers Bill From owner-atom-syntax@mail.imc.org Wed Dec 06 18:34:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs6Hl-0006G5-5a for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 18:34:45 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs6Hj-0007GB-Po for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 18:34:45 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB6NHYSL019967; Wed, 6 Dec 2006 16:17:34 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB6NHYD2019966; Wed, 6 Dec 2006 16:17:34 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from fepv02.charter.net (rems01.cluster1.charter.net [209.225.8.201]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB6NHX14019949 for ; Wed, 6 Dec 2006 16:17:33 -0700 (MST) (envelope-from antone@geckotribe.com) Received: from aa11.charter.net ([10.20.200.163]) by fepv02.charter.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20061206231727.KXSZ11844.fepv02.charter.net@aa11.charter.net> for ; Wed, 6 Dec 2006 18:17:27 -0500 Received: from [192.168.2.3] (really [68.118.146.150]) by aa11.charter.net with ESMTP id <20061206231727.MPOS25648.aa11.charter.net@[192.168.2.3]> for ; Wed, 6 Dec 2006 18:17:27 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <836A6AB5-5E29-455D-B210-84E85FA51D3B@mac.com> References: <456DB265.5090804@gmail.com> <456E7DE0.8040002@gmail.com> <456EF996.7060009@defuze.org> <4574759D.1070904@gmail.com> <45748679.70602@gmail.com> <836A6AB5-5E29-455D-B210-84E85FA51D3B@mac.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <72171380-6ADE-43A5-AA25-69812C97D4CD@geckotribe.com> Content-Transfer-Encoding: 7bit From: Antone Roundy Subject: Re: PaceEntryMediatype Date: Wed, 6 Dec 2006 17:17:21 -0600 To: atom-syntax@imc.org X-Mailer: Apple Mail (2.752.2) X-Chzlrs: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f On Dec 6, 2006, at 4:26 PM, Jan Algermissen wrote: >> Most feed readers knows how to handle feeds, but have no idea how >> to handle entries. > > So they should be fixed, should they not? If the purpose of a feed reader is to subscribe to feeds and bring new and updated entries to the user's attention, then if they don't also handle the monitoring of single entry documents (interesting to some people in some cases, but I doubt interesting to most people), that's not necessarily something that needs fixing. > They seem to only have implemented half a media type. ...or they've implemented all of what should be covered by one media type. From owner-atom-syntax@mail.imc.org Wed Dec 06 18:49:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs6WR-0004b4-2P for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 18:49:55 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs6WF-00020U-2M for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 18:49:55 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB6NWSwt021812; Wed, 6 Dec 2006 16:32:28 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB6NWSnK021811; Wed, 6 Dec 2006 16:32:28 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.237]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB6NWRal021803 for ; Wed, 6 Dec 2006 16:32:27 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id i30so357571wxd for ; Wed, 06 Dec 2006 15:32:26 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=UfvkTA8xhV5QO7Jq/EPMX1U5cw2P5aR5IEVA/3NZxyH8R40KrdbMKoeo5KcjfUpSd+GEaZzXT6Df93W449cRaRc/Ip+v7BtqGbcriEmWG7379RSyy1P8yvLk6E12pLd0yJBVT+BwabetE3NU7Q5itPzYm/1j+9OVhzMZ+hJcJ18= Received: by 10.90.56.14 with SMTP id e14mr1809173aga.1165447946837; Wed, 06 Dec 2006 15:32:26 -0800 (PST) Received: from ?192.168.1.101? ( [67.181.218.96]) by mx.google.com with ESMTP id 45sm28742553wri.2006.12.06.15.32.25; Wed, 06 Dec 2006 15:32:26 -0800 (PST) Message-ID: <457752F9.7030607@gmail.com> Date: Wed, 06 Dec 2006 15:32:09 -0800 From: James M Snell User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: Bill de hOra CC: Atom Syntax Subject: Re: feeds: what does atom:id denote? References: <45774E2E.2000300@dehora.net> In-Reply-To: <45774E2E.2000300@dehora.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Depends... is the client expected to process each discreet set of entries as part of a single logical set or is each discreet set expected to be processed as it's own complete set? The former would be equivalent to the way most feed readers work today. The latter would be equivalent to subscribing to a new feed each time. In the former, each feed should have the same atom:id; in the latter, each feed should have a unique atom:id. - James Bill de hOra wrote: > > Hi, > > I'm sending entries over XMPP packaged up as feeds. A question that has > come up - should the feed's atom:id change each time a feed is sent, or > should it remain the same for all feeds issued from a client? > > cheers > Bill > > From owner-atom-syntax@mail.imc.org Wed Dec 06 19:24:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs73l-0006hl-Md for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 19:24:21 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs73k-0000g7-9k for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 19:24:21 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB704VT6024858; Wed, 6 Dec 2006 17:04:31 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB704V4T024857; Wed, 6 Dec 2006 17:04:31 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.228]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB704TE1024841 for ; Wed, 6 Dec 2006 17:04:31 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id i30so365126wxd for ; Wed, 06 Dec 2006 16:04:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=Tv0O9y+Fe9oZgftKc+bv7WmjJaKi20o4/75IZ8Gq96SWtMxied1MSaSo7IJmZNVPet2Yw5PJaeRefZ1Eh0VL9DZGTAinF/A+zAW9YJIBNJAN20bDUvNTpjxOG9HXpo02VH5KdO8IrfaCjQu5LEx5DKwfs24W2saPGC6wNseck7E= Received: by 10.90.27.6 with SMTP id a6mr1767210aga.1165449868565; Wed, 06 Dec 2006 16:04:28 -0800 (PST) Received: from ?192.168.1.101? ( [67.181.218.96]) by mx.google.com with ESMTP id 8sm13343501wra.2006.12.06.16.04.27; Wed, 06 Dec 2006 16:04:28 -0800 (PST) Message-ID: <45775A83.7060007@gmail.com> Date: Wed, 06 Dec 2006 16:04:19 -0800 From: James M Snell User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: atom-syntax Subject: Atom Bidi Update Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 FYI, I've posted an update to the proposed Atom bidi spec. http://www.ietf.org/internet-drafts/draft-snell-atompub-bidi-02.txt Refresher: this adds a dir attribute to Atom Common Attributes that is used to specify the base direction of text in Atom documents. Changes: this draft has two significant changes. 1. It drops the rlo and lro values. 2. It specifies that UA's MAY right-align RTL text using the same rules defined for HTML. - James From owner-atom-syntax@mail.imc.org Wed Dec 06 21:26:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs8yG-0005tf-4c for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 21:26:48 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs8yB-0002El-6r for atompub-archive@lists.ietf.org; Wed, 06 Dec 2006 21:26:48 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB725PsO035669; Wed, 6 Dec 2006 19:05:25 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB725Pcw035668; Wed, 6 Dec 2006 19:05:25 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mcom.com (c3po.aoltw.net [64.236.137.25]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB725Nva035651; Wed, 6 Dec 2006 19:05:24 -0700 (MST) (envelope-from jpanzer@aol.net) Received: from areophany.nscp.aoltw.net (areophany.nscp.aoltw.net [10.169.155.201]) by mcom.com (8.10.0/8.10.0) with ESMTP id kB7255W09956; Wed, 6 Dec 2006 18:05:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by areophany.nscp.aoltw.net (Postfix) with ESMTP id 5F21DBF26E; Wed, 6 Dec 2006 18:05:05 -0800 (PST) Received: from areophany.nscp.aoltw.net ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12579-03; Wed, 6 Dec 2006 18:05:04 -0800 (PST) Received: from [10.169.186.24] (sera-10-169-186-24.nscp.aoltw.net [10.169.186.24]) by areophany.nscp.aoltw.net (Postfix) with ESMTP id 62F31BF258; Wed, 6 Dec 2006 18:05:03 -0800 (PST) Message-ID: <457776CE.7030302@aol.net> Date: Wed, 06 Dec 2006 18:05:02 -0800 From: John Panzer User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henry Story Cc: Terris Linenbach , Atom Syntax , Atom Protocol Subject: Re: In San Francisco/Bay Area References: <3D25545BFA30684F8403E7A8C1C4422C025C35A0@sfoexch1.mm-ads.com> <50810085-D476-4A96-B377-79319AF844BD@bblfish.net> In-Reply-To: <50810085-D476-4A96-B377-79319AF844BD@bblfish.net> Content-Type: multipart/alternative; boundary="------------010309030309000607060207" X-Spam-Status: No, hits=-1.42 tagged_above=-999 required=5 tests=ALL_TRUSTED, AWL, HTML_50_60, HTML_MESSAGE X-Spam-Level: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: d094b18a574860cb9e2fe5fedfbcc179 This is a multi-part message in MIME format. --------------010309030309000607060207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I'll be there around 6:30ish; hope to see whoever is coming. Wish I had an Atom logo to wear. Henry Story wrote: > > Sorry for being so imprecise. I was assuming so too. I don't know why > I did not make it clearer. > But if there were others who misread this and there are enough of > them, we can also do it on Wednesday 13th. > > Henry > > On 6 Dec 2006, at 10:14, Terris Linenbach wrote: > >> It is unclear reading this thread whether it's for today which I assume >> it is. >> >> Terris >> >> -----Original Message----- >> From: Henry Story [mailto:henry.story@bblfish.net] >> Sent: Tuesday, December 05, 2006 9:42 PM >> To: John Panzer >> Cc: Lisa Dusseault; Atom Protocol; Atom >> Subject: Re: In San Francisco/Bay Area >> >> >> I'll be there at 6:30pm then. I imagine people will not be wanting to >> stay very late. >> >> Henry >> >> On 5 Dec 2006, at 21:26, John Panzer wrote: >> >>> Lisa ran in to me today and reminded me about the meet up >>> (thanks!). I will try hard to make it; is there a definite time >>> set? (6pm is slightly better for me, but 7pm is okay too.) >>> >>> -John >>> >>> Lisa Dusseault wrote: >>> >>>> >>>> Thanks for setting this up Henry, I can be there Dec 6. 7pm is >>>> much easier to make than 6pm if anybody's coming far, even just >>>> from SF. >>>> >>>> Lisa >>>> >>>> On Dec 1, 2006, at 12:08 PM, Henry Story wrote: >>>> >>>>> >>>>> Ok I suggest trying December 6th. >>>>> Onion or no Onion rings at Tied House. >>>>> >>>>> What is dinner time in the bay? 6pm? 7pm? >>>>> >>>>> Henry >>>>> >>>>>> On 28 Nov 2006, at 21:31, John Panzer wrote: >>>>>> >>>>>> Any of those would be good for me. Be careful of the deep >>>>>> fried onion rings at Tied House, though. >>>>>> >>>>>>> Henry Story wrote: >>>>>>> >>>>>>> It has been suggested that a good meeting location might be >>>>>>> Tied House in Mountain View [1]. It has a back room that's >>>>>>> like a patio but covered and heated for dinner on either >>>>>>> >>>>>>> Wednesday 6th Dec >>>>>>> Friday 8th Dec >>>>>>> Monday 11th Dec >>>>>>> Wednesday 13th Dec >>>>>>> >>>>>>> Any preferences? >>>>>>> >>>>>>> Henry Story >>>>>>> >>>>>>> [1] http://www.tiedhouse.com/ >>>>>>> >>>>>>>> On 16 Nov 2006, at 18:23, Henry Story wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I am in the San Francisco/Bay Area region for the coming >>>>>>>> month. Would anyone in the area be up for a group meeting? >>>>>>>> >>>>>>>> Henry >>>>>>>> >>>>> >>>> >>> >>> >>> -- >>> >>> >>> John Panzer >>> System Architect >>> http://abstractioneer.org >> >> > -- Abstractioneer John Panzer System Architect http://abstractioneer.org --------------010309030309000607060207 Content-Type: multipart/related; boundary="------------070107030101090606040804" --------------070107030101090606040804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I'll be there around 6:30ish; hope to see whoever is coming.  Wish I had an Atom logo to wear.

Henry Story wrote:

Sorry for being so imprecise. I was assuming so too. I don't know why  I did not make it clearer.
But if there were others who misread this and there are enough of  them, we can also do it on Wednesday 13th.

Henry

On 6 Dec 2006, at 10:14, Terris Linenbach wrote:

It is unclear reading this thread whether it's for today which I  assume
it is.

Terris

-----Original Message-----
From: Henry Story [mailto:henry.story@bblfish.net]
Sent: Tuesday, December 05, 2006 9:42 PM
To: John Panzer
Cc: Lisa Dusseault; Atom Protocol; Atom
Subject: Re: In San Francisco/Bay Area


I'll be there at 6:30pm then. I imagine people will not be wanting to
stay very late.

Henry

On 5 Dec 2006, at 21:26, John Panzer wrote:

Lisa ran in to me today and reminded me about the meet up
(thanks!).  I will try hard to make it; is there a definite time
set?  (6pm is slightly better for me, but 7pm is okay too.)

-John

Lisa Dusseault wrote:

Thanks for setting this up Henry, I can be there Dec 6.  7pm is
much  easier to make than 6pm if anybody's coming far, even just
from SF.

Lisa

On Dec 1, 2006, at 12:08 PM, Henry Story wrote:


Ok I suggest trying December 6th.
Onion or no Onion rings at Tied House.

What is dinner time in the bay? 6pm? 7pm?

Henry

On 28 Nov 2006, at 21:31, John Panzer wrote:

Any of those would be good for me.  Be careful of the deep
fried  onion rings at Tied House, though.

Henry Story wrote:

It has been suggested that a good meeting location might be
Tied   House in Mountain View [1]. It has a back room that's
like a  patio  but covered and heated for dinner on either

Wednesday 6th Dec
Friday 8th Dec
Monday 11th Dec
Wednesday 13th Dec

Any preferences?

Henry Story

[1] http://www.tiedhouse.com/

On 16 Nov 2006, at 18:23, Henry Story wrote:

Hi,

I am in the San Francisco/Bay Area region for the coming
month.   Would anyone in the area be up for a group meeting?

Henry





-- 

<SzHO.gif>
John Panzer
System Architect
http://abstractioneer.org




--

AbstractioneerJohn Panzer
System Architect
http://abstractioneer.org
--------------070107030101090606040804 Content-Type: image/gif; name="SzHO.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="SzHO.gif" R0lGODlhLAFDAPcAAP///5mZmTMzM2ZmZuathN57MeZ7MeaEMe+MMe+MOuaMOuZ7OuZzMe+E MfeUOvecOvecQuaMSve9nO+lY/+cOu+cY//37/fFnO+USvfWtf/v5v+1cwAzmfeta//v3v/F hPela//mzvfFjP/etfe1c+97Mf+tWv/Wte+MQvelUve9hPetWvelSu+UQvetc+ZrMd5zMf/e vfe1hOaMUt5rMfe1a/e9jPfWve+tjN5jKf+tUvfOpf/m1u+1lO+UY+Z7SuaMY95zQt5aKd5z OqWlpQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH/C05FVFNDQVBFMi4wAwEAAAAh+QQA9AEAACwA AAAALAFDAAAI/gABAAhAsKDBgwgTEhTIsKHDhxAjSpxIsaLFixgzatzIsaPHjxsVihxZEKTJ kyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtCnEgxmhPl0osGRV qgOxOt3KtSdVrRTBOgxwNavZhWjJdl3LFudXtVazqr0qdizZtGfvxm3Lt+/Kt3nNRqxbNjBe vH4TK/YIGCphwQ+xHtYbeLHlyxUbz4XMEC7lzpsnG96MubRpqXI9k7aqVWrc149Ny56tkTTt 27hz697Nu7fv38CDCx9OvPhlAQKMKz+JPDlD5BCbO5cuEDoA69avN29I/fl27tmz/i8fv/F7 decPxYefzv68e+3vsaMXD5+8fYzQ5Zv3Dp5/ffr/tRfge+Dtd9+BDuU3H3oJMqhecgqmt2B8 Ako3YX0IZujeehE9WKCFDfY34IjyEajhgRaWGJ2DLLLHYogkVijjiRlyiCGMJo6YY4wU9ngj jeTZqB2DQ7r44o0pevfgkgsaCOSTUEYp5ZRUVmnllVhmqeWWXHbJ2wADrASml2RCFKZJYJ4J wJgSsZkRm26WKZyaH6XJUJwP4WmRnnIGZ2eYZ7r5J50CjQmnnYUamuafawqq6KKBHuqomoga 2udakRaq6ZqbEqpooo2GemekdH46KqifpgroqqEieilX/oHe2emsDUGK6qqHgpqoqbqq2iqu j/L66lax0lpsqZSy6mivmQqbq6/OIjtsV8Xqyum10t4qaa2Ljrrtrt+a2m2jwk5r7rnopqvu uuy26+678MYr77zmElCAAfgacMC+ByCQgAIE0NsnAQswgG8DDSCAgAMMP/AABAELTGYBDEQg gQQTKMywAw5T8MABEpOJbwUMWXABBBw/4LEDIIfcJb4YXJCBBgJZsIHKDziAQMsXccCBRz67 nJsBCGvcgQcCfZAzAg0Y4JDPP0MUtEZBTy00bUSDYEEIIkDwwAgCkcB0CU4zNHXUT6O9kdVX y9ZvByWbQMEJAFiAAtllC8R2+dU/Q4021HrzDQDgfpvN9uCABx614Ie3zVO/DqSgAs0WrOAA zRIYwAADaS/e9+eIhx644aAzDrrhoZueutqOP77xAyyArUELLtTNwAswSF367ogLPvrqqyc+ uuqqt+7TAQzHEMIHENAsQwkWADADDbmbPTzvVvsuOvGsXw/89t0bn9PCNQgUggM2AHCDATcA gEMO1ZNO+udnZ+873/bvfbrw9YvvUwIP0EH0doAAEACABwzoAQB6kAMa+K9KClBZCjowtgr4 4AU/AEIQhBC/B0aJAF7TWQPIdjsa5CAHQhhCxDwoJQLwK18MgIEMqbdCFtrwhjjMYUwCAgAh +QQAGQAAACwCAAYAUwAWAAAI9QABCBxIsKDBgwgTKlzIsCCRhw8bDoQY8SDEiRUBXBS4USLD ihk/ElE4UuPIiChPqvToEWTJjh1NhrS4MqVJmSVZknxZcyXCmQRd3rRpU2dCoRR90vyZk2jP m0aZclQKNejUqlidDqUaNShFjC5zTuXpdSPMjDG7qiW5tq3bt3Djyp1Lt67du3jz6o0LFKxX mmHJQkUb8ytYsTIxHg3ZN2tTwUIHQxaMtbLiwIgdK5ZsMLJnyocRF7V8dfPV0aY/l066mbHS xq7Lsv7bevJq22MNwxbrmidv0bhVcy49vPNvh6CBCl9OmbBf2blp9z47HXrunAEBACH5BAAZ AAAALAIABgBTABYAAAhGAAEIHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOK HEmypMmTKFOqXMmypcuXMGPKnEmzps2bOHPq3IkzIAAh+QQAGQAAACwCAAYAogAYAAAI/gAB CBxIsKDBgwgTKlzIsKHDhxAjJiRCkCJEIhgHYrR4cKPGjAI9hgQpsaTJkyZJcmxoMaPLlRpH Ang5kyJNlDhz6uwIsmVPmzBl3kRIsyhQkjuTKr1Yc2ZTowZ/NiXq8ylQq0uzap048irUihyH FlTptezUrWi3hjVbEybSrzI/YoWbtm7SlT7Xut2YN27Xn3o/BrVLuHDEwYYTK17MuLHjx5Aj S55MubLly5GR3tWMWS3ivxI5c7742aFIwWQnniY82m9pnllbP1yd+izVxLJH8wULuDZfvLt5 95Yr+qrrqgrJ+q76kvZp5chv254qlTry4nKtrxa6NrvsuNXDbO+uDhb8Xp4iNYs3z35sd+uq zy5fuB6+bfK/zdcub9/79f9+ZWdfa7/hF5109ZE3IICgydeeegwmGNR80wloYICwLdjegwxa 6Nxz6UUYXX7uCSdgiceBGFyDLLaloIEhtvjYd53VmNaKNlYWEAAh+QQA9AEAACwCAAYAogAY AAAI/gABCBxIsKDBgwgTKlzIsKHDhxAjJgxAkCLEABgHYrR4cKPGjAI9hgQpsaTJkyZJcmxo MaPLlRpHAng5kyJNlDhz6uwIsmVPmzBl3kRIsyhQkjuTKr1Yc2ZTowZ/NiXq8ylQq0uzap04 8irUihyHFlTptezUrWi3hjVbEybSrzI/YoWbtm7SlT7Xut2YN27Xn3o/BrVLuHDEwYYTK17M uLHjx5AjS55MubLly5EFCNCqeTNmu5oVdvYMMXRB0yZRp1YNYDRp1gRHJ4Y9EDVph7Rx5n7Y OfZrz7sFBs+6m7bs2r1bH1cufLny5MiTLw8Nm/pv5M0X2oZuuvtm69Cfi19v7l008NvM05dX f97g9uzi0TN/D3/4+vvne6/3XR+98eOs4dffgKeNt597343HnnbtLegggfH1Rx9/DxIoYIXw OZiba/sdeNCFF1rY4HYdiligiRrKR5+H2EHI4okpQhgjhiTe5lp0I+aY4Y0wkqdgjzX+5tyQ 4fGoWocA5idfY8N95iRazj1JWUAAIfkEABkAAAAsAgAGAKIAGAAACP4AAQgcSLCgwYMIEypc yLChw4cQIyYkQpAiRCIYB2K0eHCjxowCPYYEKbGkyZMmSXJsaDGjy5UaRwJ4OZMiTZQ4c+rs CLJlT5swZd5ESLMoUJI7kyq9WHNmU6MGfzYl6vMpUKtLs2qdOPIq1IochxZU6bXs1K1ot4Y1 WxMm0q8yP2KFm7Zu0pU+17rdmDdu1596Pwa1S7hwxMGGEytezLix48eQI0ueTLmy5cuRkd7V jFkt4r8SOXO++NmhSMFkJ54mPNpvaZ5ZWz9cnfos1cSyR/MFC7g2X7y7efeWK/qq66oKyfqu +pL2aeXIb9ueKpU68uJyra8Wuja77LjVw2zvrg4W/F6eIjWLN89+bHfrqs8uX7gevm3yv83X Lm/f+/X/fmVnX2u/4ReddPWRNyCAoMnXnnoMJhjUfNMJaGCAsC3Y3oMMWujcc+lFGF1+7gkn YInHgRhcgyy2paCBIbb42Hed1ZjWijZWFhAAIfkEABkAAAAsAgAGAKIAGAAACGYAAQgcSLCg wYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pcybKly5cwY8qcSbOm zZs4c+rcybOnz59AgwodSrSo0aNIkypdyrSp06dQo0qdSrWq1as8AwIAIfkEABkAAAAsAgAG AJcAFgAACP4AAQgcSLCgwYMIEypcyLChw4cQHxIhODEikYoALmI0qHFgR4EfM16MSLKkSYkY Nzb8OHIkR5ATW8acKfKkzZs4RVbc6VImR541E/ocOtNlzqNIhdakSfSnR6MHezKdGjSpVas8 qfosKLUq15RaqV4dexTs0qxRgW6FSTHsWbJwb25EC1OlTrpQNUoFyzeu378k7QIeTLiw4cOI EytezLix48eQIw+G+rerZId6y5rNSRloUMol9WauK/qpaL6l22p+qnmzaq8m7aZ8CZJ2Rtts SZvOyzJzat2kBfu2bPku67UebctOzpU5xa+5icv2/Hl69OUdpV+/nn1589rfb1uH9866+vbg uc2jV/9cvPbqo0HjBi++fX3n5M+/f69+f/7+noEmX3j4KWcggQDqF+Bm/qXnnILnuTfXf/WR ZyFtowHH3m/dpZdacQ8mWFWGvP102m4knobaaAEBACH5BAD0AQAALAIABgCXABYAAAj+AAEI HEiwoMGDCBMqXMiwocOHEB8GIDgxYoCKAC5iNKhxYEeBHzNejEiypEmJGDc2/DhyJEeQE1vG nCnypM2bOEVW3OlSJkeeNRP6HDrTZc6jSIXWpEn0p0ejB3synRo0qVWrPKn6LCi1KteUWqle HXsU7NKsUYFuhUkx7FmycG9uRAtTpU66UDVKBcs3rt+/JO0CHky4sOHDiBMrXsy4sePHkCMP FiCgMGWBlyU7pJwZZ+fON0EDqDyadGbRJTmrJl16NWvXn2EXRG0y9lHOA1GfZn2SN+bcBl8H Bz579mvcmFUTVN768urlyJv7Tu58d/Lr1I+X3l68++jhv71+T/dtnXt56NjNjzfNfjju8vDb S+e+HPx38fbHG8cePzdz2/Q9px548vUnnXwK6RdefQsSdx+D/vFX4ITpGWgghBJmSF+ECyn4 oIMeeqihhRSOWKJu+w2o4n2goYjfixAqyFx2HMYW3XsICniegyZWeCNvusmW3YywHeeaQAEB ACH5BAAZAAAALAIABgCXABYAAAj+AAEIHEiwoMGDCBMqXMiwocOHEB8SITgxIpGKAC5iNKhx YEeBHzNejEiypEmJGDc2/DhyJEeQE1vGnCnypM2bOEVW3OlSJkeeNRP6HDrTZc6jSIXWpEn0 p0ejB3synRo0qVWrPKn6LCi1KteUWqleHXsU7NKsUYFuhUkx7FmycG9uRAtTpU66UDVKBcs3 rt+/JO0CHky4sOHDiBMrXsy4sePHkCMPhvq3q2SHesuazUkZaFDKJfVmriv6qWi+pdtqfqp5 s2qvJu2mfAmSdkbbbEmbzssyc2rdpAX7tmz5Luu1Hm3LTs6VOcWvuYnL9vx5evTlHaVfv559 efPa329bh/fOuvr24LnNo1f/XLz26qNB4wYvvn195+TPv3+vfn/+/p6BJl94+ClnIIEA6hfg Zv6l55yC57k313/1kWchbaMBx95v3aWXWnEPJlhVhrz9dNpuJJ6G2mgBAQAh+QQAGQAAACwC AAYAlwAWAAAIXwABCBxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJ kyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKnTp1CjAggIACH5 BAAZAAAALAIABgAQARgAAAj+AAEIHEiwoMGDCBMqXMiwocOHECNKnEixosWJRAhmjEhkY8eP CEEKFAmAJMmLKFOqXMmyZcqOAzc+FAkzoceMMHPi3Omyp8+fQINyrHnzZkmZMYsiPajzqFOd NYVKnUq1qkSeWLMajDpyqUajTcN6tUq2rNmfRZ9qLcjVKVOZYtW6PUu3rt2KcNeeTDqy69y/ cePeHUy48FaNXfN6/ZgWMOPESRUbnky5ssqxljNr3sy5s+fPoEOLHk26tOnTqFOrRt12NcPW rj+3hp2YMU+MXB//LXkYsU3MuCGe1N0W6d6QuWkuVQocre6Gs5v75Yt7ueTpX30jX0kbufXI 1Hf+K9wb1aRR8UGJSg/Pfnvk5LSbhn983OT72lrLm5frFrZ87PSpN9NtAIKkXIHw6ZfgeOcJ iN97DRon4XQOskXgXDtd2BdRFJ4nl4PqGUigfxeWd9Rttr1WIlwn9uchdSBGCN1zMXZoo2PZ ufhcdsnF1Jd4YOHnoWA13qcijj/KiB6PEybZ4XDERRhldzcWWeSJ38H44la25eVjjtodaCFf 8l2JpYopAjimiwymieGa0VW5ZW0MymknhuQ1WeFiXqoJ5pc38oakfoHyB2Sfb+ZoZoHzwcnn nSYq+iiblJoZp5ZGrqmjR5oC+uOZ4FFKJ3aVTrrppwgiOp9SqIr6lXkhsCqm6oMQ1korqbGl RqVVu3JJVa+5hraeVDs6NCx3SAUEACH5BAD0AQAALAIABgAQARgAAAj+AAEIHEiwoMGDCBMq XMiwocOHECNKnEixosWJAQhmjBhgY8ePCEEKFAmAJMmLKFOqXMmyZcqOAzc+FAkzoceMMHPi 3Omyp8+fQINyrHnzZkmZMYsiPajzqFOdNYVKnUq1qkSeWLMajDpyqUajTcN6tUq2rNmfRZ9q LcjVKVOZYtW6PUu3rt2KcNeeTDqy69y/cePeHUy48FaNXfN6/ZgWMOPESRUbnky5ssqxljNr 3sy5s+fPoEOLHk26tOnTqFOrRi1AwOqIrV+Xjl2Q9sHWuHEDsA2bd26BvHcbdE2QOMLgFpEr 1D3w927jwIsrH+6beXDiuaFPzf4Q+XTp4Cf+Mm9ufLx36Nprp6/4/fb18rbjrz/+njx84Njn /6TdPrz/hNWN99x0sVVnn2sC4lfegQoWiOCDDOL33IQUKuegf79Zpx91FErY4IAeyhegiOgl qF6I+R0In4Yetlhhih2CZ2B0unlXIYotXsgfjNxd6CJ5McYH4o4mcjijcDXymN6OOL7YEHdN MunklC5Kmd16PuYYXYxbFtiglBP6aGWJ/Ul4JHZRbhhmic11mZ+AUI7pnHMAKplmkwNqNyOY 7kHZoZ5L2vfjnxCOWWWR6vkpZHh8UqfogowuaSeV0rVn6JSX5nkikFRKyumfmxYXaZtBwogp m/JxmCOknGb6aapLW7bq6alajrrppbiyGWqnRcI6566xxkoniJTSuaepr76JJobmzfoif7di aey0JH6qYqUkrnikbKqVSZW3/wUFLrefqbkdostVxVtAACH5BAAZAAAALAIABgAQARgAAAj+ AAEIHEiwoMGDCBMqXMiwocOHECNKnEixosWJRAhmjEhkY8ePCEEKFAmAJMmLKFOqXMmyZcqO Azc+FAkzoceMMHPi3Omyp8+fQINyrHnzZkmZMYsiPajzqFOdNYVKnUq1qkSeWLMajDpyqUaj TcN6tUq2rNmfRZ9qLcjVKVOZYtW6PUu3rt2KcNeeTDqy69y/cePeHUy48FaNXfN6/ZgWMOPE SRUbnky5ssqxljNr3sy5s+fPoEOLHk26tOnTqFOrRt12NcPWrj+3hp2YMU+MXB//LXkYsU3M uCGe1N0W6d6QuWkuVQocre6Gs5v75Yt7ueTpX30jX0kbufXI1Hf+K9wb1aRR8UGJSg/Pfnvk 5LSbhn983OT72lrLm5frFrZ87PSpN9NtAIKkXIHw6ZfgeOcJiN97DRon4XQOskXgXDtd2BdR FJ4nl4PqGUigfxeWd9Rttr1WIlwn9uchdSBGCN1zMXZoo2PZufhcdsnF1Jd4YOHnoWA13qci jj/KiB6PEybZ4XDERRhldzcWWeSJ38H44la25eVjjtodaCFf8l2JpYopAjimiwymieGa0VW5 ZW0MymknhuQ1WeFiXqoJ5pc38oakfoHyB2Sfb+ZoZoHzwcnnnSYq+iiblJoZp5ZGrqmjR5oC +uOZ4FFKJ3aVTrrppwgiOp9SqIr6lXkhsCqm6oMQ1korqbGlRqVVu3JJVa+5hraeVDs6NCx3 SAUEACH5BAAZAAAALAIABgAQARgAAAiDAAEIHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq 3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMq Xcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmzaNOqXcu2rdu3cONeDQgAIfkEABkA AAAsAgAGANkAGAAACP4AAQgcSLCgwYMIEypcyLChw4cQI0qcSPEgEYIXIxLJOHAjwo0cQXb0 KFBkxZMoU6pc2ZAkAI4OTZZ0iXHmy4sec+KEybKnz59AP5LMaFKnQZc7FRpdupNm0KdQo2q8 +ZIq06NEbQq1edWo1K9gw3acmfRqwaEgnWq1Wrat2LdwgYZ0e5PnWq4waXalG7evX4p5yY60 mxZj0sFo5yr+y7hxY7uOI0ueTLmy5cuYM2vezLmz58+gQ7NUqxaszL6lT2uErLJ0xbSsR2Jt GXui67eka9MOejsm0cAJc+8erds04eILe59UzhCtUKSKU4uETXYu1bo8qWOXnVtmYcSGVbpr /149vPDEeU9r3463/HXpWp1fN3wWMvrDFq2/Jx//d///88kGoHzymXeYcPsNWJhTBDaoIFbQ GXgXfwImGCB9FjpoIYbY3effhQHCFt2HHk7o3YcZkoiieWtpCF59AhYIY4oPghjhjBgieFeN Mu74XYEaujjbfEJWWGGRMarI43FHtgggh0Qu6SSIVIr4IpEUsidYhybCd+Vt6/EnZpZ6qWem aheOeeKa+rlHpWitIQfnnJ1lSSdcAQEAIfkEAPQBAAAsAgAGANkAGAAACP4AAQgcSLCgwYMI EypcyLChw4cQI0qcSPFgAIIXIwbIOHAjwo0cQXb0KFBkxZMoU6pc2ZAkAI4OTZZ0iXHmy4se c+KEybKnz59AP5LMaFKnQZc7FRpdupNm0KdQo2q8+ZIq06NEbQq1edWo1K9gw3acmfRqwaEg nWq1Wrat2LdwgYZ0e5PnWq4waXalG7evX4p5yY60mxZj0sFo5yr+y7hxY7uOI0ueTLmy5cuY M2vezLmz58+gQ7MUIMAg6b6kS/89bZr1RNc+YadMLbu1bYa1T+aGW3v3Q98ogTdkDVs1wt7G FQqPuPwr8uDJezZXrno37YGuaUcXeF0799TYS9oTB0/QO4Dr389vN6++OPnv7+GPd0//+fzk 6OUbz3/6fnr1B433n4AFyZbbfeJtF96CALZnYHUQDhhhg89JaCGF63U3YXkTEohggwzOd6GH GWaHH3r1BbhfhwpiOCKL/3EYHormESjjjO/VyCKNHJoYI4kvqmgjkD1mGOKGBcLo4pIVgsjg jU06GeSSN+J4IZNK+jakkknehuVxWYYZ45PZ/XjlkyCKSSWSaOJooo/6tUZfnE7mV6WDbRa5 YopueomnlX12WaSegf5ZZ44tijZbooo2GpqdjvYVEAAh+QQAGQAAACwCAAYA2QAYAAAI/gAB CBxIsKDBgwgTKlzIsKHDhxAjSpxI8SARghcjEsk4cCPCjRxBdvQoUGTFkyhTqlzZkCQAjg5N lnSJcebLix5z4oTJsqfPn0A/ksxoUqdBlzsVGl26k2bQp1Cjarz5kirTo0RtCrV51ajUr2DD dpyZ9GrBoSCdarVatq3Yt3CBhnR7k+darjBpdqUbt69finnJjrSbFmPSwWjnKv7LuHFju44j S55MubLly5gza97MubPnz6BDs1SrFqzMvqVPa4SssnTFtKxHYm0Ze6Lrt6Rr0w56OybRwAlz 7x6t2zTh4gt7n1TOEK1QpIpTi4RNdi7VujypY5edW2ZhxIZVumv/Xj288MR5T2vfjrf8dela nV83fBYy+sMWrb8nH/93///zyQagfPKZd5hw+w1YmFMENqggVtAZeBd/AiYYIH0WOmghhtjd 59+FAcIW3YceTujdhxmSiKJ5a2kIXn0CFghjig+CGOGMGCJ4V40y7vhdgRq6ONt8QlZYYZEx qsjjcUe2CCCHRC7pJIhUivgikRSyJ1iHJsJ35W3r8SdmlnqpZ6ZqF4554pr6uUelaK0hB+ec nWVJJ1wBAQAh+QQA+gAAACwCAAYA2QAYAAAIdQABCBxIsKDBgwgTKlzIsKHDhxAjSpxIsaLF ixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fPn0CDCh1KtKjR o0iTKl3KtKnTp1CjSp1KtarVq1izat3KtavXr2DDih1LtmzOgAA7 --------------070107030101090606040804-- --------------010309030309000607060207-- From owner-atom-syntax@mail.imc.org Thu Dec 07 02:03:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsDIR-00052D-2l for atompub-archive@lists.ietf.org; Thu, 07 Dec 2006 02:03:55 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsDIM-0000kq-MM for atompub-archive@lists.ietf.org; Thu, 07 Dec 2006 02:03:55 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB76hwqt061591; Wed, 6 Dec 2006 23:43:58 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB76hwJF061590; Wed, 6 Dec 2006 23:43:58 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id kB76htWM061571 for ; Wed, 6 Dec 2006 23:43:56 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 07 Dec 2006 06:43:47 -0000 Received: from xdsl-87-79-236-202.netcologne.de (EHLO klangraum) [87.79.236.202] by mail.gmx.net (mp004) with SMTP; 07 Dec 2006 07:43:47 +0100 X-Authenticated: #163624 Date: Thu, 7 Dec 2006 07:43:46 +0100 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: PaceEntryMediatype Message-ID: <20061207064346.GZ12859@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <4574759D.1070904@gmail.com> <45748679.70602@gmail.com> <8B583D59-010F-1000-826F-7EB2F9E7E3CB-Webmail-10013@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8B583D59-010F-1000-826F-7EB2F9E7E3CB-Webmail-10013@mac.com> User-Agent: Mutt/1.4.2.1i Organization: haphazard X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 * Jan Algermissen [2006-12-06 20:55]: > But that is an issue of linking semantics, not link target > media types. I'd expect the user agent to look for links with > 'here is a feed' semantics instead of looking for (arbitrary) > links to certain media types. > > IMHO, there is something going wrong somewhere - and it ain't > the media type. It seems pointless for atom:link to have a type attribute at all then. You should be able to decide anything you need to decide by GETting the resource (and sometimes parsing it). Why did we add such a useless feature to the spec? Regards, -- Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Thu Dec 07 02:40:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsDrR-0005fY-2U for atompub-archive@lists.ietf.org; Thu, 07 Dec 2006 02:40:05 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsDrL-0006oW-Kq for atompub-archive@lists.ietf.org; Thu, 07 Dec 2006 02:40:05 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB77MbNB064755; Thu, 7 Dec 2006 00:22:37 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB77MbY0064754; Thu, 7 Dec 2006 00:22:37 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.183]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB77MaWp064748 for ; Thu, 7 Dec 2006 00:22:37 -0700 (MST) (envelope-from algermissen1971@mac.com) Received: from mac.com (smtpin03-en2 [10.13.10.148]) by smtpout.mac.com (Xserve/8.12.11/smtpout13/MantshX 4.0) with ESMTP id kB77MYga020045; Wed, 6 Dec 2006 23:22:34 -0800 (PST) Received: from [10.0.1.2] (d191144.adsl.hansenet.de [80.171.191.144]) (authenticated bits=0) by mac.com (Xserve/smtpin03/MantshX 4.0) with ESMTP id kB77MVD5029560; Wed, 6 Dec 2006 23:22:32 -0800 (PST) In-Reply-To: <20061207064346.GZ12859@klangraum> References: <4574759D.1070904@gmail.com> <45748679.70602@gmail.com> <8B583D59-010F-1000-826F-7EB2F9E7E3CB-Webmail-10013@mac.com> <20061207064346.GZ12859@klangraum> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax@imc.org Content-Transfer-Encoding: 7bit From: Jan Algermissen Subject: Re: PaceEntryMediatype Date: Thu, 7 Dec 2006 08:22:50 +0100 To: "A. Pagaltzis" X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.5 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d On Dec 7, 2006, at 7:43 AM, A. Pagaltzis wrote: > > It seems pointless for atom:link to have a type attribute at all > then. You should be able to decide anything you need to decide by > GETting the resource (and sometimes parsing it). Why did we add > such a useless feature to the spec? > I am pretty sure it wasn't added for being able to tell people: "Look, at the other end of this link is a feed". Seriously: how many feed readers are out there that base the decision wheter something is subscribeable on the type attribute of a link rather then on the link type? As an analogy: HTML browsers look for stylesheets where it says and not Eh? Jan > Regards, > -- > Aristotle Pagaltzis // > From owner-atom-syntax@mail.imc.org Thu Dec 07 02:41:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsDt6-0005zR-E7 for atompub-archive@lists.ietf.org; Thu, 07 Dec 2006 02:41:48 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsDt5-00075W-1x for atompub-archive@lists.ietf.org; Thu, 07 Dec 2006 02:41:48 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB77RRrE065215; Thu, 7 Dec 2006 00:27:27 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB77RRDw065214; Thu, 7 Dec 2006 00:27:27 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.186]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB77RQQB065201; Thu, 7 Dec 2006 00:27:26 -0700 (MST) (envelope-from algermissen1971@mac.com) Received: from mac.com (smtpin03-en2 [10.13.10.148]) by smtpout.mac.com (Xserve/8.12.11/smtpout16/MantshX 4.0) with ESMTP id kB77ROCG000518; Wed, 6 Dec 2006 23:27:24 -0800 (PST) Received: from [10.0.1.2] (d191144.adsl.hansenet.de [80.171.191.144]) (authenticated bits=0) by mac.com (Xserve/smtpin03/MantshX 4.0) with ESMTP id kB77RJa4000810; Wed, 6 Dec 2006 23:27:21 -0800 (PST) In-Reply-To: <457747C4.9090405@gmail.com> References: <456DB265.5090804@gmail.com> <456E7DE0.8040002@gmail.com> <456EF996.7060009@defuze.org> <4574759D.1070904@gmail.com> <45748679.70602@gmail.com> <836A6AB5-5E29-455D-B210-84E85FA51D3B@mac.com> <45774483.1050205@gmail.com> <582CE04E-B2AE-4546-9CB1-5F2A5579536F@mac.com> <457747C4.9090405@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= , Mark Baker , atom-protocol , atom-syntax Content-Transfer-Encoding: 7bit From: Jan Algermissen Subject: Re: PaceEntryMediatype Date: Thu, 7 Dec 2006 08:27:41 +0100 To: James M Snell X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.5 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca On Dec 6, 2006, at 11:44 PM, James M Snell wrote: > > I certainly hope you're kidding about dropping entry docs. Sure, yes. But your wording IMHO seemed to imply that what feed readers do should guide a decision. So, given they are not interested in the entries, dropping them is not too farfetched, is it? > Let's just > label 'em differently and move on. > I still do not see the use cases justifying a new media type - it might be the right thing to do but for the time being it looks like a workaround. Jan > - James > > Jan Algermissen wrote: >> >> On Dec 6, 2006, at 11:30 PM, James M Snell wrote: >> >>> >>> >>> Jan Algermissen wrote: >>>> [snip] >>>> So they should be fixed, should they not? They seem to only have >>>> implemented half a media type. >>>> >>> >>> The half they're interested in. Why aren't they interested in >>> the other >>> half? >> >> >> Ha! Forget about the media type - let's drop entry documents. >> >> Jan >> >>> >>> - James >> >> > From owner-atom-syntax@mail.imc.org Thu Dec 07 03:03:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsEDw-00011i-PC for atompub-archive@lists.ietf.org; Thu, 07 Dec 2006 03:03:20 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsEDt-00028I-AE for atompub-archive@lists.ietf.org; Thu, 07 Dec 2006 03:03:20 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB77faJp066656; Thu, 7 Dec 2006 00:41:36 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB77fa2H066655; Thu, 7 Dec 2006 00:41:36 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.webfaction.com (mail1.webfaction.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB77fYIL066623; Thu, 7 Dec 2006 00:41:34 -0700 (MST) (envelope-from sh@defuze.org) Received: from [192.168.136.144] ([194.221.10.144]) (authenticated bits=0) by mail1.webfaction.com (8.12.11.20060308/8.13.3) with ESMTP id kB77fPaT020002; Thu, 7 Dec 2006 01:41:25 -0600 Message-ID: <4577C59F.8040706@defuze.org> Date: Thu, 07 Dec 2006 07:41:19 +0000 From: Sylvain Hellegouarch User-Agent: Thunderbird 1.5.0.8 (X11/20061117) MIME-Version: 1.0 To: Jan Algermissen CC: James M Snell , =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= , Mark Baker , atom-protocol , atom-syntax Subject: Re: PaceEntryMediatype References: <456DB265.5090804@gmail.com> <456E7DE0.8040002@gmail.com> <456EF996.7060009@defuze.org> <4574759D.1070904@gmail.com> <45748679.70602@gmail.com> <836A6AB5-5E29-455D-B210-84E85FA51D3B@mac.com> <45774483.1050205@gmail.com> <582CE04E-B2AE-4546-9CB1-5F2A5579536F@mac.com> <457747C4.9090405@gmail.com> In-Reply-To: X-Enigmail-Version: 0.94.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: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Jan Algermissen wrote: > > > On Dec 6, 2006, at 11:44 PM, James M Snell wrote: > >> >> I certainly hope you're kidding about dropping entry docs. > > Sure, yes. But your wording IMHO seemed to imply that what feed readers > do should guide a decision. So, given they are not interested in the > entries, dropping them is not too farfetched, is it? > > >> Let's just >> label 'em differently and move on. >> > > I still do not see the use cases justifying a new media type - it might > be the right thing to do but for the time being it looks like a workaround. Considering you seem to only discuss their value from a feed reader point of view, I'm not surprised you don't see the use for at least minting the current media-type, let alone an entirely new one. I think at this stage having further discussion won't help anymore and I would like the WG-chairmans and editors to tell us what they think about this issue because we aren't going anywhere right now. - Sylvain > > Jan > > >> - James >> >> Jan Algermissen wrote: >>> >>> On Dec 6, 2006, at 11:30 PM, James M Snell wrote: >>> >>>> >>>> >>>> Jan Algermissen wrote: >>>>> [snip] >>>>> So they should be fixed, should they not? They seem to only have >>>>> implemented half a media type. >>>>> >>>> >>>> The half they're interested in. Why aren't they interested in the >>>> other >>>> half? >>> >>> >>> Ha! Forget about the media type - let's drop entry documents. >>> >>> Jan >>> >>>> >>>> - James >>> >>> >> From owner-atom-syntax@mail.imc.org Thu Dec 07 03:18:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsESO-0008Cm-6Z for atompub-archive@lists.ietf.org; Thu, 07 Dec 2006 03:18:16 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsESM-000587-RD for atompub-archive@lists.ietf.org; Thu, 07 Dec 2006 03:18:16 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB77t3P2068325; Thu, 7 Dec 2006 00:55:03 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB77t3lE068324; Thu, 7 Dec 2006 00:55:03 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.185]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB77t0nI068286; Thu, 7 Dec 2006 00:55:02 -0700 (MST) (envelope-from algermissen1971@mac.com) Received: from mac.com (smtpin03-en2 [10.13.10.148]) by smtpout.mac.com (Xserve/8.12.11/smtpout15/MantshX 4.0) with ESMTP id kB77suQs011345; Wed, 6 Dec 2006 23:54:56 -0800 (PST) Received: from [10.0.1.2] (d191144.adsl.hansenet.de [80.171.191.144]) (authenticated bits=0) by mac.com (Xserve/smtpin03/MantshX 4.0) with ESMTP id kB77spm3007712; Wed, 6 Dec 2006 23:54:53 -0800 (PST) In-Reply-To: <4577C59F.8040706@defuze.org> References: <456DB265.5090804@gmail.com> <456E7DE0.8040002@gmail.com> <456EF996.7060009@defuze.org> <4574759D.1070904@gmail.com> <45748679.70602@gmail.com> <836A6AB5-5E29-455D-B210-84E85FA51D3B@mac.com> <45774483.1050205@gmail.com> <582CE04E-B2AE-4546-9CB1-5F2A5579536F@mac.com> <457747C4.9090405@gmail.com> <4577C59F.8040706@defuze.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <760FB8D0-8CA2-4ADF-9345-8726C86771A6@mac.com> Cc: James M Snell , =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= , Mark Baker , atom-protocol , atom-syntax Content-Transfer-Encoding: 7bit From: Jan Algermissen Subject: Re: PaceEntryMediatype Date: Thu, 7 Dec 2006 08:55:13 +0100 To: Sylvain Hellegouarch X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.5 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 On Dec 7, 2006, at 8:41 AM, Sylvain Hellegouarch wrote: > Considering you seem to only discuss their value from a feed reader > point of view Hmm, strange. Feed readers are actually the last thing I am thinking about wrt Atom (no intention to show disrespect for the blogosphere of course). Jan From owner-atom-syntax@mail.imc.org Thu Dec 07 03:29:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsEdB-0005B7-1A for atompub-archive@lists.ietf.org; Thu, 07 Dec 2006 03:29:25 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsEd4-0006yD-JH for atompub-archive@lists.ietf.org; Thu, 07 Dec 2006 03:29:25 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB78DsnR070382; Thu, 7 Dec 2006 01:13:54 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB78DsrB070381; Thu, 7 Dec 2006 01:13:54 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id kB78DqCj070360 for ; Thu, 7 Dec 2006 01:13:53 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 07 Dec 2006 08:13:46 -0000 Received: from xdsl-87-79-236-202.netcologne.de (EHLO klangraum) [87.79.236.202] by mail.gmx.net (mp042) with SMTP; 07 Dec 2006 09:13:46 +0100 X-Authenticated: #163624 Date: Thu, 7 Dec 2006 09:13:45 +0100 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: PaceEntryMediatype Message-ID: <20061207081345.GA12859@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <45748679.70602@gmail.com> <8B583D59-010F-1000-826F-7EB2F9E7E3CB-Webmail-10013@mac.com> <20061207064346.GZ12859@klangraum> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Organization: haphazard X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 * Jan Algermissen [2006-12-07 08:25]: > As an analogy: HTML browsers look for stylesheets where it says > > > > and not > > > > Eh? What do browsers do with this? And what with this? Is their behaviour right? Wrong? Why? Regards, -- Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Thu Dec 07 03:45:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsEsc-0004Kw-NC for atompub-archive@lists.ietf.org; Thu, 07 Dec 2006 03:45:22 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsEsY-0001Jz-7T for atompub-archive@lists.ietf.org; Thu, 07 Dec 2006 03:45:22 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB78Vfn9072262; Thu, 7 Dec 2006 01:31:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB78Vf0e072261; Thu, 7 Dec 2006 01:31:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB78VbTB072250 for ; Thu, 7 Dec 2006 01:31:38 -0700 (MST) (envelope-from t.broyer@gmail.com) Received: by ug-out-1314.google.com with SMTP id j3so446443ugf for ; Thu, 07 Dec 2006 00:31:36 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=r/a2cKfnZ83LMaTLDnjhosSCNcvbDTW79wyGj4toEU4ljfXSBqayIMfqii5a54SSX7tTE9OcqqDj5nm7uOerOxBsA7aI/TzXwFgdkl0URCGyBAi9mRnQtKmvyPo9JeP2+qrGAOdH5o12LioCl0jikZTa7bO18jZyo+RqXPBKdT8= Received: by 10.48.202.19 with SMTP id z19mr3519375nff.1165480294218; Thu, 07 Dec 2006 00:31:34 -0800 (PST) Received: by 10.49.28.6 with HTTP; Thu, 7 Dec 2006 00:31:32 -0800 (PST) Message-ID: Date: Thu, 7 Dec 2006 09:31:32 +0100 From: "Thomas Broyer" To: Atom-Syntax , whatwg@whatwg.org Subject: Re: PaceEntryMediatype In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4574759D.1070904@gmail.com> <8B583D59-010F-1000-826F-7EB2F9E7E3CB-Webmail-10013@mac.com> <20061207064346.GZ12859@klangraum> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.9 (+) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 [CC'ing the WHATWG list] 2006/12/7, Jan Algermissen: > > Seriously: how many feed readers are out there that base the decision > wheter something is subscribeable on the type attribute of a link > rather then on the link type? Every one? Oh, they also look at the rel="alternate", but I'm pretty sure they won't "process" the link if the 'type' attribute is absent, and they don't "process" it if it's present with a value different from the Atom or RSS media type. > As an analogy: HTML browsers look for stylesheets where it says > > > > and not > > > > Eh? Let's take two files, index.html and style.css. Now, let's describe the relationship between them. What is style.css wrt index.html? a stylesheet that browsers should use to present index.html. What is index.html wrt style.css? a page that uses style.css as a stylesheet. The relation really *is* "stylesheet" (when taken from the page to the stylesheet), whether it is written in CSS, XSLT->XSL-FO, DSSSL, etc. Now, let's take a "blog entry page" and the "blog feed" and try to describe the relationship between them. What is the blog entry page wrt the blog feed? a resource that is being or has been linked from the feed as one of its "items". If you see a feed as a set of entries not restricted to the limited set exposed by its representations, the entry is still part of the feed. What is the blog feed wrt the blog entry page? a feed (set of entries, bla bla bla) which is linking or has been linking to the entry page as one of its "items". The relation in this case is "feed" (when taken from the entry page to the feed; note that rel="feed" here is *not* the same as the one from the current HTML5 draft). What's clear is that it is not "alternate", as used today for feed autodiscovery. This rel="feed" is IMO useful because that's what people are generally looking at when they want to "subscribe to a site" and are not already looking at an "HTML feed": where's the feed which contains this item? Last example, in two parts: Let's start with Mozillazine's homepage and its Atom0.3 feed; they are clearly rel="alternate" representations of the same thing: a feed (set of entries, bla bla bla). The HTML version also contains sidebars with additional information, but they're not part of the "main content". Now, let's take, say the Mozilla.org homepage. It is linking to Mozillazine and its feed. I don't know how we could describe the relationship between Mozilla.org and Mozillazine and that's not the point here, so let's call it "X". If Mozilla.org is linking to Mozillazine using rel="X" and given that Mozillazine's homepage and Atom0.3 feed are alternates; Mozilla.org should also be linking to Mozillazine's Atom0.3 feed using rel="X" (which it does in an in the of the page, where actually it uses no rel="" at all). So why the hell is it using rel="alternate"? (in a in the section). As Mozillazine's Atom0.3 feed is an alternate representation of the Mozillazine's homepage, does it mean that Mozilla.org and Mozillazine also are rel="alternate"? I'd say no, however that's what rel="alternate" implies (it has been re-enforced in HTML5 that rel="alternate" is transitive). If rel="" on and had a default value (let's say rel="related"), then this value could be used in the required rel="" attribute of when linking to feeds which are neither rel="alternate" or rel="feed" (with the definition given above, *not* the one from HTML5): My last point: if the rel="feed" as described above seems useless, then I'm not opposed to having a rel="feed" "marker" as defined in the current HTML5 draft, with an addition: that this "feed" marker be "combinable" with any link rel: rel="feed alternate", rel="feed up", rel="feed index", etc. (and at the condition that it is explicitely defined as a "marker" and not as a relationship; rel="prefetch" and rel="nofollow" would also need this distinction). -- Thomas Broyer From owner-atom-syntax@mail.imc.org Thu Dec 07 03:58:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsF5N-0001ZI-Pg for atompub-archive@lists.ietf.org; Thu, 07 Dec 2006 03:58:33 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsF5I-00046N-Bg for atompub-archive@lists.ietf.org; Thu, 07 Dec 2006 03:58:33 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB78kS8T073335; Thu, 7 Dec 2006 01:46:28 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB78kSht073334; Thu, 7 Dec 2006 01:46:28 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bay0-omc3-s8.bay0.hotmail.com (bay0-omc3-s8.bay0.hotmail.com [65.54.246.208]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB78kRjT073311 for ; Thu, 7 Dec 2006 01:46:27 -0700 (MST) (envelope-from peaceable_whale@hotmail.com) Received: from hotmail.com ([207.46.8.25]) by bay0-omc3-s8.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 7 Dec 2006 00:46:22 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 7 Dec 2006 00:46:21 -0800 Message-ID: Received: from 61.238.43.155 by BAY117-DAV15.phx.gbl with DAV; Thu, 07 Dec 2006 08:46:20 +0000 X-Originating-IP: [61.238.43.155] X-Originating-Email: [peaceable_whale@hotmail.com] X-Sender: peaceable_whale@hotmail.com From: "Franklin Tse" To: "'A. Pagaltzis'" , References: <45748679.70602@gmail.com> <8B583D59-010F-1000-826F-7EB2F9E7E3CB-Webmail-10013@mac.com> <20061207064346.GZ12859@klangraum> <20061207081345.GA12859@klangraum> In-Reply-To: <20061207081345.GA12859@klangraum> Subject: RE: PaceEntryMediatype Date: Thu, 7 Dec 2006 16:46:05 +0800 Message-ID: <000001c719dc$220a7a40$661f6ec0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AccZ2W/ww8lld8/KQOy/P4g8s0dBOwAAVHyg Content-Language: en-us x-cr-hashedpuzzle: Xm0= A8Is C9Y0 Ei83 FR7j FbQY GUVJ IatP I4os KeGy R/j2 T+n5 UCN9 VPdF VyF7 W4yx;2;YQB0AG8AbQAtAHMAeQBuAHQAYQB4AEAAaQBtAGMALgBvAHIAZwA7AHAAYQBnAGEAbAB0AHoAaQBzAEAAZwBtAHgALgBkAGUA;Sosha1_v1;7;{80C7ECEE-1FB6-41BC-B428-A5824F872D29};cABlAGEAYwBlAGEAYgBsAGUAXwB3AGgAYQBsAGUAQABoAG8AdABtAGEAaQBsAC4AYwBvAG0A;Thu, 07 Dec 2006 08:45:53 GMT;UgBFADoAIABQAGEAYwBlAEUAbgB0AHIAeQBNAGUAZABpAGEAdAB5AHAAZQA= x-cr-puzzleid: {80C7ECEE-1FB6-41BC-B428-A5824F872D29} X-OriginalArrivalTime: 07 Dec 2006 08:46:21.0254 (UTC) FILETIME=[2B412E60:01C719DC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kB78kRjT073329 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c > What do browsers do with this? > Browsers should get the /style.css, check the Content-Type field of the HTTP Response Header and determine whether they support the stylesheet or not. > And what with this? > If browsers support text/plain as a stylesheet, they should get the /style.css and use the Content-Type field of the HTTP Response Header to confirm whether they really support the stylesheet. If browsers do not support text/plain as a stylesheet, they should just simply ignore . Franklin Tse -----Original Message----- From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of A. Pagaltzis Sent: Thursday, December 07, 2006 16:14 To: atom-syntax@imc.org Subject: Re: PaceEntryMediatype * Jan Algermissen [2006-12-07 08:25]: > As an analogy: HTML browsers look for stylesheets where it says > > > > and not > > > > Eh? What do browsers do with this? And what with this? Is their behaviour right? Wrong? Why? Regards, -- Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Thu Dec 07 04:09:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsFFb-0000Su-AL for atompub-archive@lists.ietf.org; Thu, 07 Dec 2006 04:09:07 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsFFV-00065A-Qr for atompub-archive@lists.ietf.org; Thu, 07 Dec 2006 04:09:07 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB78vNBQ075159; Thu, 7 Dec 2006 01:57:23 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB78vNkX075158; Thu, 7 Dec 2006 01:57:23 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB78vLMN075151 for ; Thu, 7 Dec 2006 01:57:22 -0700 (MST) (envelope-from duck1123@gmail.com) Received: by ug-out-1314.google.com with SMTP id j3so451432ugf for ; Thu, 07 Dec 2006 00:57:20 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=TqZ5QZshQ7fe7YfgJb6SIjHaH4puIoSKORsfuEObYOwUDNIRYTHE6557HAv7qgzqSeQcYlM/HL8LgfiSfnJqPdizRNCNJUV+lAayz3x45CDftlPG9YelZY9aKcHMNvI2I1pbz1IXsQrmIPm2VO+76r7GtSCl6ZWIN8f53M6q3Ns= Received: by 10.49.29.3 with SMTP id g3mr3564747nfj.1165481840432; Thu, 07 Dec 2006 00:57:20 -0800 (PST) Received: by 10.82.158.4 with HTTP; Thu, 7 Dec 2006 00:57:20 -0800 (PST) Message-ID: <36bd6e0b0612070057k245a61a9i1a2753a3ac754bc8@mail.gmail.com> Date: Thu, 7 Dec 2006 03:57:20 -0500 From: "Daniel E. Renfer" To: "Jan Algermissen" Subject: Re: PaceEntryMediatype Cc: "Sylvain Hellegouarch" , "James M Snell" , "=?UTF-8?Q?Asbj=C3=B8rn_Ulsberg?=" , "Mark Baker" , atom-protocol , atom-syntax In-Reply-To: <760FB8D0-8CA2-4ADF-9345-8726C86771A6@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <456DB265.5090804@gmail.com> <836A6AB5-5E29-455D-B210-84E85FA51D3B@mac.com> <45774483.1050205@gmail.com> <582CE04E-B2AE-4546-9CB1-5F2A5579536F@mac.com> <457747C4.9090405@gmail.com> <4577C59F.8040706@defuze.org> <760FB8D0-8CA2-4ADF-9345-8726C86771A6@mac.com> X-Google-Sender-Auth: 90118b1fed385fa3 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a People in this thread keep asking for a use case where one would want to have a separate mediatype for both feeds and entry documents, so here is my attempt at providing one. I view a web page (blog post) that defines the proper link tags to both the Atom Entry for the current post, and the Atom Feed for all the posts on that blog. These links have the proper type and rel information attached to each respective links. No problem there, the browser can decide what to do with those links based off rel information alone. Now, in the template of this page, the author also includes standard html anchors to these two resources for the benefit of users using a browser that doesn't understand Atom Entries let alone Atom Feeds. He's linked the feed to a png image of the standard feed icon, and a similar image for the Entry. These anchors have @href attributes, but no @type or @rel information. I have two programs on my system; A feed reader, which I use to subscribe to Atom Feeds, but has a very limited support for Entry documents; and an APP Editor, which allows me to create and edit Atom Entries, but has limited support for Feeds. If I click on one of these two links on the page, I want that resource to be handled by it's respective program. If these two documents were each to be served with a different mediatype, then it is trivial to tell my OS/Browser to send the Feeds to my feed reader, but send my Entries to my editor. As it stands right now, there would be no way to do this aside from having a third program taking in both, sniffing the content and sending the document to the appropriate program. This is a horrible solution. The @rel attribute is still useful. The @rel exists to tell the browser what to do with the document, the @type exists to say what that document actually IS. I dislike the idea of using ;type=[feed|entry] mostly because I'm afraid that this information will far too likely be either diregarded or dropped. Also, once Entries become their own type, the next logical step would be to have something like: application/atom.entry+xml;type=xhtml application/atom.entry+xml;type=html application/atom.entry+xml;type=text application/atom.entry+xml;type=markdown etc... Of course, let's reach a consensus on this issue before that particular can of worms gets opened up. Daniel E. Renfer http://kronkltd.net/ On 12/7/06, Jan Algermissen wrote: > > > On Dec 7, 2006, at 8:41 AM, Sylvain Hellegouarch wrote: > > > Considering you seem to only discuss their value from a feed reader > > point of view > > > Hmm, strange. Feed readers are actually the last thing I am thinking > about wrt Atom (no intention to show disrespect for the blogosphere > of course). > > Jan > > From owner-atom-syntax@mail.imc.org Thu Dec 07 05:05:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsG8W-00041y-Cq for atompub-archive@lists.ietf.org; Thu, 07 Dec 2006 05:05:52 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsG8S-00015P-0i for atompub-archive@lists.ietf.org; Thu, 07 Dec 2006 05:05:52 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB79pndu081479; Thu, 7 Dec 2006 02:51:50 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB79pnWZ081477; Thu, 7 Dec 2006 02:51:49 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id kB79plDA081448 for ; Thu, 7 Dec 2006 02:51:48 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 07 Dec 2006 09:51:42 -0000 Received: from xdsl-87-79-236-202.netcologne.de (EHLO klangraum) [87.79.236.202] by mail.gmx.net (mp040) with SMTP; 07 Dec 2006 10:51:42 +0100 X-Authenticated: #163624 Date: Thu, 7 Dec 2006 10:51:41 +0100 From: "'A. Pagaltzis'" To: atom-syntax@imc.org Subject: Re: PaceEntryMediatype Message-ID: <20061207095141.GB12859@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <8B583D59-010F-1000-826F-7EB2F9E7E3CB-Webmail-10013@mac.com> <20061207064346.GZ12859@klangraum> <20061207081345.GA12859@klangraum> <000001c719dc$220a7a40$661f6ec0$@com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000001c719dc$220a7a40$661f6ec0$@com> User-Agent: Mutt/1.4.2.1i Organization: haphazard X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 * Franklin Tse [2006-12-07 10:00]: > If browsers do not support text/plain as a stylesheet, they > should just simply ignore type="text/plain" href="/style.css" />. Exactly. Regards, -- Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Thu Dec 07 08:26:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsJGQ-00078d-GO for atompub-archive@lists.ietf.org; Thu, 07 Dec 2006 08:26:15 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsJGP-0001PJ-1O for atompub-archive@lists.ietf.org; Thu, 07 Dec 2006 08:26:14 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB7Cx6cw003900; Thu, 7 Dec 2006 05:59:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB7Cx6uF003899; Thu, 7 Dec 2006 05:59:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB7Cx3w1003888 for ; Thu, 7 Dec 2006 05:59:06 -0700 (MST) (envelope-from algermissen1971@mac.com) Received: from mac.com (webmail023-S [10.13.128.23]) by smtpout.mac.com (Xserve/8.12.11/smtpout09/MantshX 4.0) with ESMTP id kB7Cwwbh003817; Thu, 7 Dec 2006 04:58:59 -0800 (PST) Received: from webmail023 (localhost [127.0.0.1]) by mac.com (8.13.8/webmail023/MantshX 4.0) with ESMTP id kB7CwtC3023676; Thu, 7 Dec 2006 04:58:56 -0800 (PST) Date: Thu, 07 Dec 2006 04:58:55 -0800 From: Jan Algermissen To: "Daniel E. Renfer" Cc: Sylvain Hellegouarch , James M Snell , =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= , Mark Baker , atom-protocol , atom-syntax Message-ID: in-reply-to: <36bd6e0b0612070057k245a61a9i1a2753a3ac754bc8@mail.gmail.com> references: <456DB265.5090804@gmail.com> <836A6AB5-5E29-455D-B210-84E85FA51D3B@mac.com> <45774483.1050205@gmail.com> <582CE04E-B2AE-4546-9CB1-5F2A5579536F@mac.com> <457747C4.9090405@gmail.com> <4577C59F.8040706@defuze.org> <760FB8D0-8CA2-4ADF-9345-8726C86771A6@mac.com> <36bd6e0b0612070057k245a61a9i1a2753a3ac754bc8@mail.gmail.com> Subject: Re: PaceEntryMediatype MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 10.201.82.16, 145.253.233.58 Received: from [10.201.82.16] from webmail.mac.com with HTTP; Thu, 07 Dec 2006 04:58:55 -0800 Received: from [ 145.253.233.58] from webmail.mac.com with HTTP; Thu, 07 Dec 2006 04:58:55 -0800 X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.5 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 On Thursday, December 07, 2006, at 10:18AM, "Daniel E. Renfer" wrote: >I have two programs on my system; A feed reader, which I use to >subscribe to Atom Feeds, but has a very limited support for Entry >documents; and an APP Editor, which allows me to create and edit Atom >Entries, but has limited support for Feeds. > >If I click on one of these two links on the page, I want that resource >to be handled by it's respective program. If these two documents were >each to be served with a different mediatype, then it is trivial to >tell my OS/Browser to send the Feeds to my feed reader, but send my >Entries to my editor. Ok, that is IMO heading in the right direction. This example makes sense because it strongly emphasizes a difference between feeds and entries, saying feeds are for viewing collections and entries are more or less for editing web resources (if we include the media resource case). If the Atom specs never considered feed readers to be dealing with individual entries anyhow (at least that is the impression I get by now) then having a new media type does indeed make sense. Question to Atom editors and others involved with the specs: What was the intention behind having entry documents in Atom in the first place? Thanks, Jan > >As it stands right now, there would be no way to do this aside from >having a third program taking in both, sniffing the content and >sending the document to the appropriate program. This is a horrible >solution. > >The @rel attribute is still useful. The @rel exists to tell the >browser what to do with the document, the @type exists to say what >that document actually IS. > >I dislike the idea of using ;type=[feed|entry] mostly because I'm >afraid that this information will far too likely be either diregarded >or dropped. Also, once Entries become their own type, the next logical >step would be to have something like: > >application/atom.entry+xml;type=xhtml >application/atom.entry+xml;type=html >application/atom.entry+xml;type=text >application/atom.entry+xml;type=markdown >etc... > >Of course, let's reach a consensus on this issue before that >particular can of worms gets opened up. > > >Daniel E. Renfer >http://kronkltd.net/ > >On 12/7/06, Jan Algermissen wrote: >> >> >> On Dec 7, 2006, at 8:41 AM, Sylvain Hellegouarch wrote: >> >> > Considering you seem to only discuss their value from a feed reader >> > point of view >> >> >> Hmm, strange. Feed readers are actually the last thing I am thinking >> about wrt Atom (no intention to show disrespect for the blogosphere >> of course). >> >> Jan >> >> > > > From owner-atom-syntax@mail.imc.org Thu Dec 07 12:05:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsMgN-0006bG-1H for atompub-archive@lists.ietf.org; Thu, 07 Dec 2006 12:05:15 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsMgF-00029t-Pf for atompub-archive@lists.ietf.org; Thu, 07 Dec 2006 12:05:15 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB7Gapbb035243; Thu, 7 Dec 2006 09:36:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB7GapAt035242; Thu, 7 Dec 2006 09:36:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB7GaoD7035227 for ; Thu, 7 Dec 2006 09:36:50 -0700 (MST) (envelope-from joe.gregorio@gmail.com) Received: by an-out-0708.google.com with SMTP id d33so55876and for ; Thu, 07 Dec 2006 08:36:48 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Fsz8MKhE1cUw4myKTxdecCJ/GQqRKfnxTkFGWYSlG9gZ9je91TjGy7X44Th7aPRuic77/MgVwpuazZ/g/w7zdpWsSCAEy7SoPU5SVGZh45K7PRpK3U/mkqExzIdUIzlq8M2x988ZuqLXi8gjs5aTuj2e0p9gOCElnDruEKfdKnU= Received: by 10.78.149.15 with SMTP id w15mr1565136hud.1165509405877; Thu, 07 Dec 2006 08:36:45 -0800 (PST) Received: by 10.78.205.2 with HTTP; Thu, 7 Dec 2006 08:36:45 -0800 (PST) Message-ID: <3f1451f50612070836h45091080k851cece2198c464a@mail.gmail.com> Date: Thu, 7 Dec 2006 11:36:45 -0500 From: "Joe Gregorio" To: "Lisa Dusseault" Subject: Re: AD Evaluation of draft-ietf-atompub-protocol-11 Cc: Atom , "atom-protocol Protocol" In-Reply-To: <8BD53B7C-5B43-4F2D-8DC5-0281CCB84B84@commerce.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline References: <8BD53B7C-5B43-4F2D-8DC5-0281CCB84B84@commerce.net> X-Google-Sender-Auth: 33ae368a1ea67e5c X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kB7GapD7035237 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id kB7Gapbb035243 X-Spam-Score: 1.1 (+) X-Scan-Signature: 6cf0511842947ba7c2eb8ab72c43e5b6 Lisa, Thanks for the very detailed review of this draft. More comments in-li= ne. On 10/17/06, Lisa Dusseault wrote: > > > It would probably not be useful at this point for me to suggest a resol= ution > to absolutely everything, especially if that involves specific wording. > It's much more likely the WG/editors would choose different wording and > organization anyway. But when I get back from vacation (1st day of > November) and catch up on the mailing list traffic, I will see if there= 's > any place where I can suggest wording to capture what I meant in a way = that > the WG can agree. I understand there's often a balance between leaving > options open for different implementations and extensions, and closing > options down so that specific behavior can be depended on, and sometime= s > there are ways you can have a little of both. > > High-level comments, summarizing comments > > - The mechanism for creating a media resource and a media link entry i= n > response to a single POST conflicts with at least one statement elsewhe= re in > the draft, and has no example. This is one of those cases where I > personally had some assumptions > (that not every media resource had its own > media link entry if the media resource had been created manually) There may be 'other' media resources, but if they don't have an associate= d Media Link Entry then they are not 'in' the collection. > that > weren't ever quite cleared up by the spec. If the client CAN create a m= edia > resource without also creating a media link entry, that should be a sep= arate > example. > - Overall, the responsibility model needs to be slightly better define= d. > E.g. we know the server is responsible for choosing a URL for new entri= es; > it's not clear who's responsible for cleaning up linked entries if a us= er > ever needs to clean up historical entries. Atom sometimes seems to spl= it > the responsibility, and those are the most complicated cases. More exa= mples > below as it's probably more useful to discuss specifics. That used to be in the spec: http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-06.html#e= ntry-constraints It should go back in. > - To an outsider or newcomer -- including me even though I've been > following discussions closely for a while -- there's a part of the Atom > model that's subtle but important to understand. Consumers of Atom fee= ds > are supposed to look at the regular feed document, whereas publishers o= f > Atom feeds are supposed to look at other, different resources to see ho= w to > edit or create posts. Publishers effectively look at a different feed = than > users do, one with extra metadata (the rel=3D"edit" links). It's a dif= ferent > model than that of WebDAV or IMAP, because rather than have the client > specify which metadata it's interested in, the server offers two choice= s > with different addresses. I believe it would be useful to cover that p= art > of the model upfront in addition to the other useful stuff already ther= e. Agreed. > > Creating resources > > Explicit result of POST, section 4. > > Are there zero, one or more resources created with a POST? There's a li= ne at > the top of section 4 which says that "POST is used to create a new, > dynamically-named, resource". However, that implies ONE, whereas with = media > entries, a POST could create TWO resources. I believe a successful POS= T > request as described here MUST either result in one or two resources, n= ever > zero, and never 3 or more (in the absence of extensions). A POST can create any number of resources. In the case of an entry collection it will be at least one. In the case of a media entries it will be at least two. Many other resources could be created but this spec should only concern itself with the ones of interest for the operation of the protocol, otherwise the protocol isn't of much use. For example, if we say that POSTing an entry MUST only create one resource then how does the associated weblog HTML page get created? > What is the expected behavior of seeing a POST to an entry URL (rather = than > a collection URL)? I see that this is currently undefined; Yes, it is undefined. So is the effect of sending it a PROPPATCH, COPY, L= OCK, PATCH or MEGAFOO. Agreed, a note to the effect that anything not defined in the spec is, well, un-defined. I.e. we aren't holding any other methods on the resources 'in reserve'. > it may be worth > stating that to warn clients. (I'm pretty indifferent on this one, as = in > this case I can't see any obvious harm in different server behaviors > existing, if un-warned clients try it intentionally without knowing th= e > results. The only possible harm is if clients got confused, did a POST= to > an entry URL when a collection URL was intended, and the server does a > success response which creates new resources or modifies existing resou= rces > in a way the client did not expect. An error response would certainly = be > harmless for this undefined case but a success response could be real > interesting.) > > Creating entries with multiple media resources > > It's never explained how a client would go about creating a feed entry = with > a number of media resources. I imagine that it could be iterative; a c= lient > could create any of the resources at any time, and at any time after > creating the feed entry, use PUT to update the feed entry to link to ne= w > media resources. I assume -- though I didn't see it stated in the docu= ment > -- that it's the client's responsibility in almost all cases to put lin= ks in > the feed entry to point to the media resources, otherwise the media > resources are unlinked (effectively hidden to readers). Agreed, that's how it should work and the text and examples should be bolstered to make that clear. > > The exception to this general process is if the client first uses POST = to > create both the media resource and the "Media Link Entry" in one go. I= n > this case, can the "Media Link Entry" (MLE) be transformed to a regular > "Member Entry Resource" (MER)? I thought it would be possible, but > discussed just a bit with Tim today and he says no, so there you have t= wo > different readings of the spec. I'll agree with Tim on that. > I guess a related question is what would > happen if a client does a PUT of media content to an entry resource, or > entry content to a media resource. I think that falls in the "un-defined" territory. > It's not clear to me whether a linked media entry is always listed in t= he > metadata or not. > - When one or more "edit-media" link relations appear, who has been > responsible for putting them there? The server. > - When a media resource is deleted, who is responsible for removing th= e > media resource link from the MLE? The MLE itself should be removed, and this is done by the server. > - Section 4 says that the MLE contains the metadata for a Media Resour= ce, > but that seems to only assume a single Media Resource. In the case of > multiple Media Resources which the user intends to link into a single p= ost, > it's unclear to me whether there's one MLE for every Media Resource, or= one > MER for all the Media Resources created, or some other situation. Agai= n, in > quick discussion with Tim, he says there is one Media Link Entry per Me= dia > Resource. I can see how that would work but that was not at all my > understanding before the discussion! Tim is right, it's a 1-1 relationship. Obviously more text and examples are needed. > This document would benefit greatly from further examples: > 1. An example of creating a MLE and MR in a single POST; the request, > response and the result (resource URLs) described. > 2. An example of modifying a MER to contain a new image or other medi= a > resource link: the request(s), possibly the responses (if it's interest= ing, > it may not be), and definitely the result. > 3. An example of modifying a MER to change metadata (e.g. category or > adding a new link relation element or both); possibly a failed request > example would be even more interesting than a successful one. +1 > Can a client modify an entry to contain a link relation element in the > following cases: > - To result in an "edit" or "edit-media" link relation, where the reso= urce > represented does not meet the requirements in section 11.1 or 11.2? No. > - To result in an "edit" link relation that actually points to a media > resource, or a "edit-media" link relation that actually points to a MER= ? > - To point to a resource on a different server entirely? There is no reason to believe that any of these resource are on the same machine to begin with. I could POST to media to machine A and have the MLE could be created on machine B and the editable media resource itself created on machine C. > - To point to a valid media resource or MER that happen to be in a > different collection than the one normally used for this feed? > - Will some servers forbid adding a link relation element entirely? I= s it > important for the client to know that that will always be forbidden for= that > server -- can it detect the "always forbidden" case separately from the > "this particular edit is forbidden" case? > Which of these are errors, and if so how is the error handled? Which o= f > these MUST the server allow and handle? I understand there may be some= need > for flexibility here. Perhaps it's just standardized error messages > required here. For example, if there are some servers which allow a gi= ven > link relation to point to another server, and some servers which do not > allow, how would the servers which do not allow respond with a sufficie= ntly > specific error, so that the client can avoid trying the same thing agai= n? I think some text explaining up front that for all intents and purposes t= he server is in charge and could reject/modify entries as it sees fit is in = order. > Multiple formats/langs for media resources > > Multiple formats are not sufficiently defined -- e.g. JPG and PNG versi= ons > of an image resource. > Format negotiation is hard. I will agree with that last statement and would like to punt on stating anything concrete about creating variants beyond saying it's "un-defined". > I found guidance for how > to select among different "edit-media" link relations depending on form= at > and language, but I found no guidance on how to create multiple version= s. > If there's no guidance to clients or servers how to do it (would the cl= ient > create multiple resources in different formats? could the server > automatically do it as variants? could the server automatically do it a= s > multiple resources, and would all formats be therefore listed?), it's > probably worth considering whether there's possible interoperability ha= rm > here. I can imagine clients creating alternate-format versions quite > successfully because the operations would be explicit, but when I imagi= ne > how servers would go about it, I can easily see ways it could go wrong = (e.g. > creating new URLs for resources that are invisible to the media collect= ion, > having multiple URLs in locations where clients expect only one). > > I think there may be a very basic confusion here -- in my head or in th= e > document or both -- about what the "edit-media" link relation does and = is > for. When I read the text it seems to offer the possibility for multip= le > formats for a single media resource, as suggested by the text: "If a cl= ient > encounters multiple "edit-media" link relations in an entry then it SHO= ULD > choose a link based on the client preferences for type and hreflang". > However, when I try to think about how a client would create a post wit= h a > totally independent set of JPG images (e.g. one of the Eiffel Tower, on= e of > the Louvre and one of the Arche de Triomphe), the "edit-media" link rel= ation > also seems to have relevance. Which is it or both? (and as always, who = is > responsible for filling it in or removing it when new media resources a= re > created or destroyed?) Media to MLE is a 1-1 relationship. Other variants, such as PNG, JPEG and GIF of an image might be created for an image at the whim of a server. > Thomas Broyer said in email July 24 that "Having the Content-Location = value > equal to the Location one tells the client that the response body is a > representation of the newly created resource". This is a subtle readi= ng of > HTTP and, if it's true, I want to make sure that implementors understa= nd > this without having to read the mailing list. The spec reads " the res= ponse > from the server SHOULD contain a Content-Location header that contains = the > same character-by-character value as the Location header." If the resp= onse > from the server does not contain both headers identical, what should th= e > client conclude? I think this is one of those SHOULD recommendations w= here > the consequence of it not being a MUST need to be considered. Possibly= the > spec needs to say under what conditions the server would do otherwise; > possibly the spec should say what the client knows, or does not know, o= r > must do, if the server does otherwise. Personally I'd rather drop all that verbage about Content-Location and ju= st point to RFC 2616 and the definition of Location and Content-Location. > Deleting Resources > > In the case of an entry that points to multiple media resources, can th= e > server delete all those media resources and their MLEs? (I think not).= If > a client issues a DELETE to a media resource, is its MLE deleted? (The = spec > covers the opposite case already when a client issues a DELETE to an ML= E.) This is covered by M<->MLE 1-1. > Can collections be DELETEd? It's fine for servers to allow or no, but = if > servers don't support, what error to use. "un-defined" > Editing resources > > Overall, the process for editing a resource is not entirely clear. I f= ind > the description of creating a resource (POST), and what the server can > accept, ignore or reject, more clear than the description of editing a > resource (PUT) . For example, there's normative text in section 9.2.1 = (an > example) relative to creating resources and handling metadata, but that= text > isn't duplicated for editing resources or obviously apply to editing > resources. Thus: > - Can the client change the category? (probably yes; MUST the server > allow?) > - Can the client change the atom:id? (probably never) > - Can the client change the "updated" value to be some time in the fut= ure? > Some time long ago? Or are there only two non-error changes -- "now" o= r > "the previous value"? MUST the server accept the value if it's the sam= e as > the previous value? Or can there be servers that always ignore "update= d" > values from clients? (and if so, is it important for the client to know= that > the server does this) > - Can the client change the set of link relations? (probably yes; but = does > that include "edit" and "edit-media" link relations only or also > first/previous/next/last link relations?) > In general the possible edits need to be covered to consider whether th= e > server MUST allow these kinds of edits, or MAY, and if refused, what er= ror > for what reason. Agreed, like I said, this was in previous versions and should be updated and restored: http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-06.html#e= ntry-constraints > > I already threw in a request for an example of modifying a resource abo= ve, > because one of the cases for editing a resource is to add a media resou= rce > to it. > > The spec says "The value of atom:updated is only changed when the chang= e to > a member resource is considered significant. " The use of passive voic= e > obscures who does what here. When the client doesn't suggest a value f= or > "atom:updated", does the server provide one, and if so, how does the se= rver > know what is "significant"? I thought it would always be the client > suggesting values, but Tim says that the server controls atom:updated w= hich > could imply that the client doesn't even need to suggest values. See a= bove > about whether the server MUST accept certain values for "updated", or m= ore > likely, MUST NOT accept suggested values for "updated" when they're cle= arly > wrong (e.g. this entry was last updated on October 16, 1906). > > Can a server ever ignore part of an edit and successfully process the r= est? Yes. Think of a client that throws in a slew of random link elements with relations my server implementation doesn't understand. Same with foreign markup. The server is in charge. Here is another example, a server could take in an entry with content that was HTML and clean it up and the next time the entry is accessed the content could be XHTML. > For example, the server receives a PUT request that tries to edit the t= ext > of a MER and includes a new category value, the server accepts the new = text > but silently ignores the category value. I suggest the answer would be= MUST > NOT silently ignore suggested changes, particularly since there's no wa= y in > a PUT response to say "here's what the server actually stored". It ma= y be > my opinion differs here from that of the WG. I find silently ignoring = input > to be scary. The client can always do a follow-up GET. I believe it's unavoidable and trying to specify it would either become a rat-hole or would end up making the spec impossible to implement. > > Synchronization > > I predict that some AtomPub authoring clients will attempt to synchroni= ze: > to maintain an offline copy of the feed including all its MERs and medi= a > resources, and to keep that offline copy up-to-date. Some will probabl= y > even allow offline authoring of new posts, and offer to synchronize whe= n the > client next goes online -- because of the possibility of multiple autho= rs, > this may mean at times that the client would download new entries creat= ed by > other authors, upload new entries created offline, and reconcile its of= fline > copy of feed documents. > > Because authoring clients will attempt to do this based on Last-Modifie= d and > ETag -- after all, the functionality is all there in some form or anoth= er -- > the spec needs a little more clarity on how the client can rely on this > working. Otherwise, some servers may omit features that these authorin= g > clients require, or implement them oddly. While I would never suggest > repeating all the requirements from other specs (in this case HTTP), th= ere > are cases where clarity and interoperability are greatly improved by at > least referencing explicitly requirements from HTTP. It's also possibl= e to > add new requirements based on features in HTTP, that apply to Atom serv= ers > alone. Agreed, a little verbage and a link to http://www.w3.org/1999/04/Editing/ would be good. > > You can see that I lean more towards the "explain confusing things" sid= e and > "add more stringent requirements" than to the "it's already written > elsewhere side" by peeking at section 8.2 of CalDAV > . > A mostly-explanatory guidelines section helps clients quickly understa= nd a > clear path towards synchronization, and new requirements for supporting > ETags make things easier for what is, after all, a more limited use cas= e of > HTTP (calendaring) than the general case. If HTTP synchronization in > authoring cases were clearly defined and had not lead to years of argum= ents > since the last HTTP update, I would probably feel differently about jus= t > silently relying on the mechanisms in HTTP. > > In any case, I have very specific brief suggestions to cover synchroniz= ation > so that it's implemented more successfully than not. Hey, we used to have that in there too: http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-04.html#c= ollections_model_usage > - Consider adding a brief section offering clients non-normative guide= lines > on synchronization. It doesn't have to limit server behavior so much a= s > point out with green and red lights where the fairway is (mixing > transportation and golfing metaphors in my head) > - Make a few requirements of servers to avoid some of those HTTP > ambiguities. For example: > "The ETag or Last-Modified values for a member resource MUST change wh= en > any metadata in the resource changes, as well as text/content, and this > includes "next" and "last" link relation values. The ETag or Last-Modi= fied > values of a member resource MUST NOT change solely because an associate= d > other resource (e.g. the media resource being an associated resource to= the > media link entry resource) changed. " > > More open questions that might be related to synch or might have releva= nce > even for clients that don't do full synch: > - What is the relationship, if any, between the "atom:updated" value a= nd > the HTTP "Last-Modified" value. Can the "atom:updated" value ever be l= ater > (greater) than the "Last-Modified" value? I believe it can be the same= or > earlier, but the spec doesn't disallow the broken case. > - Is it clear whether the client MUST GET the entry after modifying it= in > order to have an accurate offline cache? (this was mentioned in a post= by > Broyer Jul 13, but not in the document). I believe this is made clear > already for the cases of getting the feed and also for POST/create, but= not > for PUT/modify. > - Am I correct that the general assumption is that id's are there to s= ee > what entries are new, and URLs are there to see where to get them? Tha= t may > mean that URLs could change, for a given ID -- Perhaps a feature to cha= nge > the slug name of a image after attaching it. Is that theoretically > possible? Yes. > There are also efficiency considerations. > - The spec could require that servers MUST return either the ETag, or = the > Last-Modified value, in any successful POST or PUT response. I persona= lly > favour this so that clients can rely on it, though obviously other opin= ions > are valid here. > - I really liked the idea of putting ETag in the author's feed, as > discussed on the list but not appearing in the document, again for > efficiency. > Certainly, the spec could ignore these considerations for now. However= , I > have noted that many client implementations choose a single way to impl= ement > their logic that can be relied upon if a reliable approach is available= , > rather than respond differently to different implementations. Thus, I > predict that if some servers implement more-efficient synchronization a= nd > others don't, clients will behave as if they're always talking to the > less-efficient servers. The more-efficient servers will find it difficu= lt to > achieve better scalability through synch efficiency improvements becaus= e > clients have already implemented reliable but inefficient synchronizati= on > and don't have reason to add a second logic path for the more-efficient > servers. > > Internationalization > > How are categories compared? Case-sensitive, insensitive, according to = which > language? Would the categories "donn=E9" and "donne" map to the same ca= tegory > as "Donne" and "DONNE"? I believe it's currently up to the server, whic= h > means unpredictable behavior from the point of view of clients. See > http://www.ietf.org/internet-drafts/draft-newman-i18n-comparator-14.txt= , > which has passed IESG Evaluation except for some IANA actions. This i= s a > danger area for any draft going before the IESG which looks carefully a= t > i18n these days. > > How do lang tags inside the document relate to Content-Language informa= tion > in headers? Does the most granular override the other possible values? = What > about when client provides to server? Does the server ignore or handle? > > Other > > The requirements for the link relations "next", "previous", "first" and > "last" aren't as rigorous as for "edit" and "edit-media" link relations. > Also they're defined quite separately -- I kind of thought that all the= link > relation types could be usefully defined in one section but if the edit= ors > prefer a different organization that's fine. But; is it OK if the reso= urce > pointed to by one of these link relations is on another server, in anot= her > feed, is a different kind of resource than you might normally expect, e= tc... > ? I think the normal cases for these link relations are well-understoo= d but > not necessarily what a client should do if it encounters abnormal cases. > > Discovering feed reading URL > > A very minor feature request for the introspection document: it SHOULD > contain the public or published read-only feed URL of the blog (Tim sug= gests > using link rel=3D"alternate" type=3D"application/atom+xml", although I'= m not > sure that makes it sufficiently clear what it's for). This so that my= blog > editing tool can show me not only all the entries and media resources (= all > discoverable from the introspection doc already) but also where the blo= g is > published, so that I can copy that link to my friends when telling them > about my blog. > > Extensions > > When the client puts extension elements in a MER, MUST the server store > those unrecognized extension elements? No. > I think the answer to this is > actually that servers often do not and should not be required to do so. > That makes it hard for clients to extend AtomPub's syntax in ways that = other > clients will understand but servers don't care about. Consider the > consequences: when some enterprising client developer decides to do > something cool and useful and encounters servers that don't store their > metadata in the obvious place, the client developer is going to quickly= work > around that by storing in some unobvious place. For example in HTML > comments in the atom entry content, or microformats, etc. Is that all = cool? > > > (Aside: an example of clients working around servers like this is that = some > WebDAV servers in the very early days didn't actually allow clients to > PROPPATCH custom properties as the authors clearly intended. Some clie= nt > wanted to put extra structured information on a resource when it was lo= cked. > Instead of putting it in properties, since that didn't work reliably, = the > client instead put it in the LOCK entry's "owner" element! Of course t= hat > didn't reliably interoperate either because some servers overwrote the > "owner" element with authoritative information -- the lock's actual own= er as > known by the server. So the workaround solution was also harmful to > interoperability, only it was discovered after the client had shipped.) > > Workspaces > > What are workspaces? I would like to see a definition. I believe I > understand that basically, a workspace corresponds to a single publishe= d > feed; that a workspace contains the collections with the content author= ed > for that feed. I know the WG discussed this so maybe I can suggest wor= ding > at some point or simply register my vote for saying what it *is*. I'll make you a deal, you define what a "web site" is and then I'll define a workspace :) I think this is murky sematic territory best handled by the W3C TAG. > Besides the definition, I also wonder about workspace titles. That see= ms > redundant with the title of the entry collection and possibly also the = title > of the feed (inside the main feed document). Is there any understandin= g of > some of these values being identical, or any understanding of what diff= erent > purpose they serve if they're not identical? > > OPTIONS response > > HTTP is unclear about where PUT and POST show up in Allow headers. Web= DAV > ran into this as an interoperability problem -- some clients assumed th= at if > they didn't see PUT in the Allow header for a collection, they couldn't > write to that collection (the client might be checking for permissions = or > policy, having already established that the server was a WebDAV server = but > not certain if PUT would be allowed to this particular place). Some se= rvers > had PUT in the Allow header value for a collection, some servers didn't= , > based on the literal reading that you couldn't actually PUT straight to= a > collection URL. Clients had to end up with the OPTIONS Allow: header > response being useless in this case. With somebody else's hindsight, A= tom > doesn't have to leave this ambiguous for the special kinds of resources= it > defines... > > Cookie support, sessions, authentication > > Is there an assumption that clients MUST support cookies? without such= a > requirement explicitly stated, some clients won't, for reasonable secur= ity > concerns. Instead, is there an assumption that clients MUST repeat > authentication headers with each request? Or will servers effectively = end > up constantly "reminding" clients (through 401 errors) to authenticate? > This might seem obvious but it definitely differs from regular HTTP pra= ctice > where clients authenticate once and then stop sending authentication > information automatically and it just works because of cookies. Also w= e'd > experienced this as an interoperability problem in WebDAV interoperabil= ity > tests where some server implementors insisted that certain WebDAV clien= ts > were completely broken in not supporting cookies. > > Are there assumptions that sessions will be maintained through persiste= nt > connections? I believe there should be none. That is, if you're a cli= ent > implementor thinking that the first request will contain authorization = and > subsequent requests on the same connection have no authorization, think > again. I've stated my piece on authentication and the IETF requirements. Just let me know the boiler plate that needs to be put in there and i'll do it. I have no more energy for the subject. > ANCHOR sections > > It's not clear to me that the RFC Editor will know what to do with all = the > [[anchor... ]] sections. Most difficult of all, "anchor37" says "incom= plete > section". For the rest, sometimes the RFC Editor may need to know what= to > replace with what on publication. I'm sure the doc editors know what t= hey > meant but I personally was left guessing. Agreed, will clean up. > > Lisa Thanks again for the close reading. -joe --=20 Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Thu Dec 07 14:37:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsP3f-0004JC-1T for atompub-archive@lists.ietf.org; Thu, 07 Dec 2006 14:37:27 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsP3c-0008S6-De for atompub-archive@lists.ietf.org; Thu, 07 Dec 2006 14:37:27 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB7JFpm9055006; Thu, 7 Dec 2006 12:15:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB7JFoIp055005; Thu, 7 Dec 2006 12:15:50 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB7JFmTW054998 for ; Thu, 7 Dec 2006 12:15:48 -0700 (MST) (envelope-from henry.story@bblfish.net) Received: (qmail 32393 invoked by uid 17064); 7 Dec 2006 19:15:47 -0000 Received: from unknown (HELO [10.1.1.108]) ([64.162.56.198]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 7 Dec 2006 19:15:47 -0000 In-Reply-To: <8B583D59-010F-1000-826F-7EB2F9E7E3CB-Webmail-10013@mac.com> References: <456DB265.5090804@gmail.com> <456E7DE0.8040002@gmail.com> <456EF996.7060009@defuze.org> <4574759D.1070904@gmail.com> <45748679.70602@gmail.com> <8B583D59-010F-1000-826F-7EB2F9E7E3CB-Webmail-10013@mac.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Antone Roundy , atom-syntax@imc.org Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: PaceEntryMediatype Date: Thu, 7 Dec 2006 11:15:48 -0800 To: Jan Algermissen X-Mailer: Apple Mail (2.752.3) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Just to say that I strongly agree with Jan's points below. We should work to use the link relation type properly, and not get dazzled by the current misuse of the alternate relation. I have been wondering if there would not be a case for different mime types if one wanted to place a number of representations at the same url. One could for example have the following at the same place: - an html version of a blog post - an representation of that blog post - a for the history of changes to that blog post That would suggest having different media types because one could not place them at the same location if one only has application/atom +xml . That does not decide the issue as to whether it is a good idea to do so. For the moment I find the application/atom+xml;type=entry application/ atom+xml;type=feed more appealing than the other new media types by the way. On the other hand having different mime types for every document format is also crazy. If someone invents a doc to describe cats, and someone else a doc to describe mice, are they going to need a new mime type? And what about a doc to describe policemen, and a doc to describe people? We could end up quickly with an infinite number of mime types which clearly would not help interoperability. Henry On 6 Dec 2006, at 23:22, Jan Algermissen wrote: > On Dec 7, 2006, at 7:43 AM, A. Pagaltzis wrote: > >> >> It seems pointless for atom:link to have a type attribute at all >> then. You should be able to decide anything you need to decide by >> GETting the resource (and sometimes parsing it). Why did we add >> such a useless feature to the spec? >> > > I am pretty sure it wasn't added for being able to tell people: > "Look, at the other end of this link is a feed". > > Seriously: how many feed readers are out there that base the > decision wheter something is subscribeable on the type attribute of > a link rather then on the link type? > > As an analogy: HTML browsers look for stylesheets where it says > > > > and not > > > > Eh? > > Jan On 6 Dec 2006, at 11:42, Jan Algermissen wrote: > On Wednesday, December 06, 2006, at 08:30PM, "Antone Roundy" > wrote: >> >> On Dec 6, 2006, at 12:14 PM, Jan Algermissen wrote: >>> >>> I'd say: stick with the one media type that is currently there - >>> there is no problem, just misconception about what it means to >>> subscribe. >> >> A few reasons why a user agent might want to be able to tell the >> difference between a link to a feed and a link to an entry beforehand >> is in order to: > > But that is an issue of linking semantics, not link target media > types. I'd expect the user agent to look for links with 'here is a > feed' semantics instead of looking for (arbitrary) links to certain > media types. > > IMHO, there is something going wrong somewhere - and it ain't the > media type. I completely agree. > On 6 Dec 2006, at 14:26, Jan Algermissen wrote: >>> To make that decision, the agent has to look at the >>> representation and >>> the it is insignificant overhead to see if the thing returnes >>> or . >>> >> >> Not if the resource needn't be GET in the first place. If the >> whole operation can be decided upon the Content-Type returned in a >> HEAD request, or >> > > Ok, HEAD would save the extra payload, but....I still think the > reason for subscribing is NOT how the representation at the other > end looks, it is based on the link semantics. From owner-atom-syntax@mail.imc.org Thu Dec 07 14:54:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsPKX-0004Yq-52 for atompub-archive@lists.ietf.org; Thu, 07 Dec 2006 14:54:53 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsPKU-0002OT-Hb for atompub-archive@lists.ietf.org; Thu, 07 Dec 2006 14:54:53 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB7Jc1uA057746; Thu, 7 Dec 2006 12:38:01 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB7Jc1cY057745; Thu, 7 Dec 2006 12:38:01 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB7Jbx1Y057735 for ; Thu, 7 Dec 2006 12:38:00 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by nf-out-0910.google.com with SMTP id m18so849023nfc for ; Thu, 07 Dec 2006 11:37:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=XLZEQgn6e+SD9NDpCmNj1lZdXF6zcL7ZA84HXt7/2GFW1HwVkzj7CvdHb+uTfWEiVkxPeTwNkyXi6XvRqLFLdhJpj/Md6zpzChPv7DCwHhxsYk/QgWsL5KXqQ9NYPFMtdmf/xTS9H32Wu5uaGuDtOoWUB4f4AMFbBcb6L1IO+uY= Received: by 10.49.91.6 with SMTP id t6mr4549864nfl.1165520278113; Thu, 07 Dec 2006 11:37:58 -0800 (PST) Received: from ?192.168.1.101? ( [67.181.218.96]) by mx.google.com with ESMTP id d2sm7338139nfe.2006.12.07.11.37.50; Thu, 07 Dec 2006 11:37:57 -0800 (PST) Message-ID: <45786D72.8030205@gmail.com> Date: Thu, 07 Dec 2006 11:37:22 -0800 From: James M Snell User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: Henry Story CC: Jan Algermissen , Antone Roundy , atom-syntax@imc.org Subject: Re: PaceEntryMediatype References: <456DB265.5090804@gmail.com> <456E7DE0.8040002@gmail.com> <456EF996.7060009@defuze.org> <4574759D.1070904@gmail.com> <45748679.70602@gmail.com> <8B583D59-010F-1000-826F-7EB2F9E7E3CB-Webmail-10013@mac.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content types are only useful when they help to differentiate how a document is to processed. If it was all about the format we could have just used application/xml all along. IMHO, There is already sufficient evidence that entry documents and feed documents are processed differently and thus deserve different content types. - James Henry Story wrote: > > Just to say that I strongly agree with Jan's points below. We should > work to use the link relation type properly, and not get dazzled by the > current misuse of the alternate relation. > > I have been wondering if there would not be a case for different mime > types if one wanted to place a number of representations at the same url. > > One could for example have the following at the same place: > > - an html version of a blog post > - an representation of that blog post > - a for the history of changes to that blog post > > That would suggest having different media types because one could not > place them at the same location if one only has application/atom+xml . > That does not decide the issue as to whether it is a good idea to do so. > > For the moment I find the application/atom+xml;type=entry > application/atom+xml;type=feed more appealing than the other new media > types by the way. > > On the other hand having different mime types for every document format > is also crazy. If someone invents a doc to describe cats, and someone > else a doc to describe mice, are they going to need a new mime type? And > what about a doc to describe policemen, and a doc to describe people? We > could end up quickly with an infinite number of mime types which clearly > would not help interoperability. > > Henry > > > On 6 Dec 2006, at 23:22, Jan Algermissen wrote: >> On Dec 7, 2006, at 7:43 AM, A. Pagaltzis wrote: >> >>> >>> It seems pointless for atom:link to have a type attribute at all >>> then. You should be able to decide anything you need to decide by >>> GETting the resource (and sometimes parsing it). Why did we add >>> such a useless feature to the spec? >>> >> >> I am pretty sure it wasn't added for being able to tell people: "Look, >> at the other end of this link is a feed". >> >> Seriously: how many feed readers are out there that base the decision >> wheter something is subscribeable on the type attribute of a link >> rather then on the link type? >> >> As an analogy: HTML browsers look for stylesheets where it says >> >> >> >> and not >> >> >> >> Eh? >> >> Jan > > > > > On 6 Dec 2006, at 11:42, Jan Algermissen wrote: >> On Wednesday, December 06, 2006, at 08:30PM, "Antone Roundy" >> wrote: >>> >>> On Dec 6, 2006, at 12:14 PM, Jan Algermissen wrote: >>>> >>>> I'd say: stick with the one media type that is currently there - >>>> there is no problem, just misconception about what it means to >>>> subscribe. >>> >>> A few reasons why a user agent might want to be able to tell the >>> difference between a link to a feed and a link to an entry beforehand >>> is in order to: >> >> But that is an issue of linking semantics, not link target media >> types. I'd expect the user agent to look for links with 'here is a >> feed' semantics instead of looking for (arbitrary) links to certain >> media types. >> >> IMHO, there is something going wrong somewhere - and it ain't the >> media type. > > I completely agree. > > >> On 6 Dec 2006, at 14:26, Jan Algermissen wrote: >>>> To make that decision, the agent has to look at the representation and >>>> the it is insignificant overhead to see if the thing returnes >>>> or . >>>> >>> >>> Not if the resource needn't be GET in the first place. If the whole >>> operation can be decided upon the Content-Type returned in a HEAD >>> request, or >>> >> >> Ok, HEAD would save the extra payload, but....I still think the reason >> for subscribing is NOT how the representation at the other end looks, >> it is based on the link semantics. > > From owner-atom-syntax@mail.imc.org Thu Dec 07 15:02:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsPRo-00073F-46 for atompub-archive@lists.ietf.org; Thu, 07 Dec 2006 15:02:24 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsPRk-0003aV-M0 for atompub-archive@lists.ietf.org; Thu, 07 Dec 2006 15:02:24 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB7JbYVM057711; Thu, 7 Dec 2006 12:37:34 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB7JbY0L057709; Thu, 7 Dec 2006 12:37:34 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from csmtp1.b-one.net (csmtp.b-one.net [195.47.247.21]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB7JbXhO057689; Thu, 7 Dec 2006 12:37:34 -0700 (MST) (envelope-from asbjorn@tigerstaden.no) Received: from quark (72.84-48-117.nextgentel.com [84.48.117.72]) by csmtp1.b-one.net (Postfix) with ESMTP id 0FD0019124BE9; Thu, 7 Dec 2006 20:37:27 +0100 (CET) Date: Thu, 07 Dec 2006 20:39:12 +0100 To: "Jan Algermissen" , "Daniel E. Renfer" Subject: Re: PaceEntryMediatype From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Cc: "Sylvain Hellegouarch" , "James M Snell" , "Mark Baker" , atom-protocol , atom-syntax Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <456DB265.5090804@gmail.com> <836A6AB5-5E29-455D-B210-84E85FA51D3B@mac.com> <45774483.1050205@gmail.com> <582CE04E-B2AE-4546-9CB1-5F2A5579536F@mac.com> <457747C4.9090405@gmail.com> <4577C59F.8040706@defuze.org> <760FB8D0-8CA2-4ADF-9345-8726C86771A6@mac.com> <36bd6e0b0612070057k245a61a9i1a2753a3ac754bc8@mail.gmail.com> Message-ID: In-Reply-To: User-Agent: Opera Mail/9.10 (Win32) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id kB7JbYVM057711 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 On Thu, 07 Dec 2006 13:58:55 +0100, Jan Algermissen =20 wrote: > Ok, that is IMO heading in the right direction. This example makes sens= e > because it strongly emphasizes a difference between feeds and entries, > saying feeds are for viewing collections and entries are more or less f= or > editing web resources (if we include the media resource case). Yay, the discussion is progressing! :) > If the Atom specs never considered feed readers to be dealing with =20 > individual entries anyhow (at least that is the impression I get by > now) then having a new media type does indeed make sense. Yes indeed. > Question to Atom editors and others involved with the specs: What was =20 > the intention behind having entry documents in Atom in the first place? I don't remember all about the original discussion, but here's three of m= y =20 entries from back in the days: Although the topics in which the messages appear are unrelated, they all = =20 talk about the same thing, namely having Atom Entries as first-class web = =20 citizens. Back then, reaching this goal was enough of a struggle; definin= g =20 Atom Entries' own MIME type was unthinkable. --=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 Thu Dec 07 22:45:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsWg1-0004s5-8o for atompub-archive@lists.ietf.org; Thu, 07 Dec 2006 22:45:33 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsWfy-0003kq-LW for atompub-archive@lists.ietf.org; Thu, 07 Dec 2006 22:45:33 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB83TfvI010650; Thu, 7 Dec 2006 20:29:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB83TfUC010649; Thu, 7 Dec 2006 20:29:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB83TcfS010632 for ; Thu, 7 Dec 2006 20:29:40 -0700 (MST) (envelope-from mbaker@gmail.com) Received: by ug-out-1314.google.com with SMTP id j3so755258ugf for ; Thu, 07 Dec 2006 19:29:37 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=DA/UaAlbPoOFPoGMGq4QoZ/tcV0z0yA/a/pE3KhubFnvIRtfa8m5338joghVsN/s8RPByji7JkZzawur97kUAc3oPTW0PbWZwJHhjP1LZ8TmjDiAvHqvMOGWiax1hlxrrfQyFSQeofB3XNfSaUNOFWDixnPa8da2Fq45W6XeTxA= Received: by 10.78.160.2 with SMTP id i2mr1698572hue.1165548576764; Thu, 07 Dec 2006 19:29:36 -0800 (PST) Received: by 10.78.174.19 with HTTP; Thu, 7 Dec 2006 19:29:36 -0800 (PST) Message-ID: Date: Thu, 7 Dec 2006 22:29:36 -0500 From: "Mark Baker" To: "James M Snell" Subject: Re: PaceEntryMediatype Cc: atom-protocol , atom-syntax In-Reply-To: <45765C1F.50802@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <456DB265.5090804@gmail.com> <4574759D.1070904@gmail.com> <45748679.70602@gmail.com> <4575D37D.8080909@gmail.com> <45764C7A.5040008@gmail.com> <45765C1F.50802@gmail.com> X-Google-Sender-Auth: ce2acdc273baab99 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 On 12/6/06, James M Snell wrote: > > > Mark Baker wrote: > > [snip] > > Isn't that just a case of people not implementing the whole spec > > though? FWIW, if that practice is widespread, then I think the group > > should consider deprecating entry documents. Minting a new media type > > won't help. > > > > The interesting question is *why* haven't those applications implemented > support for Entry Documents. My guess is that Entry documents aren't > particularly interesting to their use cases which is likely because they > serve a different purpose. Makes sense. I forgot that entry documents were used for creation in APP. But serving different purposes does not necessitate a different media type. Both Firefox and Googlebot are voracious consumers of text/html documents, yet for very different purposes. Mark. From owner-atom-syntax@mail.imc.org Fri Dec 08 12:18:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsjMw-0005tP-Ai for atompub-archive@lists.ietf.org; Fri, 08 Dec 2006 12:18:42 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsjMt-0005PI-Mu for atompub-archive@lists.ietf.org; Fri, 08 Dec 2006 12:18:42 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB8H6G4Z099895; Fri, 8 Dec 2006 10:06:16 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB8H6GWD099894; Fri, 8 Dec 2006 10:06:16 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nz-out-0102.google.com (nz-out-0506.google.com [64.233.162.228]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB8H6FI4099888 for ; Fri, 8 Dec 2006 10:06:16 -0700 (MST) (envelope-from bobwyman@gmail.com) Received: by nz-out-0102.google.com with SMTP id z3so571732nzf for ; Fri, 08 Dec 2006 09:06:13 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=kJCVGECTU6tq8cH65pmXU1qvg7QSdgiOqCVVRFriti+cJDW/XeTuwPkIVOi72Qovq9cMC5yF1RqAOFUhJYA3YIyzFASEqBEpI/Dl+3uv0j2It5QyreDEZdTaqQosTM5yUtYukkDWWMK8MjLksiMHFYNAf1dlA5NHm5DXLuvmsvQ= Received: by 10.35.65.17 with SMTP id s17mr4078958pyk.1165597572878; Fri, 08 Dec 2006 09:06:12 -0800 (PST) Received: by 10.35.15.12 with HTTP; Fri, 8 Dec 2006 09:06:12 -0800 (PST) Message-ID: <45be5cd40612080906m130d30c5ybfd5af5a74c085aa@mail.gmail.com> Date: Fri, 8 Dec 2006 12:06:12 -0500 From: "Bob Wyman" To: atom-syntax@imc.org Subject: Fwd: PaceEntryMediatype In-Reply-To: <45be5cd40612071836s4e110ea2v165a41e501102730@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_50427_22152777.1165597572693" References: <456DB265.5090804@gmail.com> <4574759D.1070904@gmail.com> <45748679.70602@gmail.com> <4575D37D.8080909@gmail.com> <45764C7A.5040008@gmail.com> <45be5cd40612071836s4e110ea2v165a41e501102730@mail.gmail.com> X-Google-Sender-Auth: 7a458fd6245f57af Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.3 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 ------=_Part_50427_22152777.1165597572693 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 12/5/06, James M Snell wrote: >>Mark Baker wrote: >> It's just an entry without a feed. You'd use the same code >> path to process that entry whether it were found in an entry >> or feed document, right? > Not necessarily... The majority of applications that most > frequently handle Atom Feed Documents have no idea how > to deal with Atom Entry Documents and I would wager that > most applications that understand how to process Atom Entry > Documents and Atom Feed Documents typically don't fall into > the same category as most feed readers. What you seem to be implying is that the majority of applications that process Atom Feed documents are not, in fact, supporting extremely important parts of the atom specification. I believe that any properly constructed Atom Feed parser will contain all the code needed to parse the most complex Atom Entry document. And, an entry document with an atom:source is semantically equivelant to an atom:feed with a single entry... The problem here is that people insist on building Atom parsers that aren't capable of handling more semantics than legacy RSS. What we should be doing is encouraging people to exploit Atom and use its features -- atom:source among others -- that aren't supported by RSS. For a parser that properly handles the case of an atom:entry appearing within atom:feed, it should be trivially simple code to recognize and handle an entry without a feed wrapper. I think there are even cases where this makes sense -- and you would even want to subscribe to such a thing: Consider a "feed" that communicates "current weather" or "current stock price", etc. We wouldn't be surprised if such a "feed" never contained more than a single entry. We also wouldn't be surprised if the publisher of this single entry feed decided that he wanted to sign the entry in this single-entry-feed and was thus forced to insert all of the feed data into the entry's atom:source. Of course, once you've got a single-entry Atom feed which contains a signed entry, you have all the feed data duplicated -- so, it wouldn't be surprising to see authors of such feeds argue that they shouldn't be forced to waste bits on duplicated feed data when an atom entry document provides exactly what they need. In any case, while it appears reasonable (and sometimes efficient) for people to subscribe to Entry documents, I don't think we should do anything disruptive unless someone can establish actual harm being caused by the current state of affairs. bob wyman ------=_Part_50427_22152777.1165597572693 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
On 12/5/06, James M Snell <jasnell@gmail.com > wrote:
>>Mark Baker wrote:
>> It's just an entry without a feed.  You'd use the same code
>> path to process that entry whether it were found in an entry
>> or feed document, right?
> Not necessarily... The majority of applications that most
> frequently handle Atom Feed Documents have no idea how
> to deal with Atom Entry Documents and I would wager that
> most applications that understand how to process Atom Entry
> Documents and Atom Feed Documents typically don't fall into
> the same category as most feed readers.
    What you seem to be implying is that the majority of applications that process Atom Feed documents are not, in fact, supporting extremely important parts of the atom specification. I believe that any properly constructed Atom Feed parser will contain all the code needed to parse the most complex Atom Entry document. And, an entry document with an atom:source is semantically equivelant to an atom:feed with a single entry...  The problem here is that people insist on building Atom parsers that aren't capable of handling more semantics than legacy RSS. What we should be doing is encouraging people to exploit Atom and use its features -- atom:source among others -- that aren't supported by RSS.
     For a parser that properly handles the case of an atom:entry appearing within atom:feed, it should be trivially simple code to recognize  and handle an entry without a feed wrapper. I think there are even cases where this makes sense -- and you would even want to subscribe to such a thing:
    Consider a "feed" that communicates "current weather" or "current stock price", etc. We wouldn't be surprised if such a "feed" never contained more than a single entry. We also wouldn't be surprised if the publisher of this single entry feed decided that he wanted to sign the entry in this single-entry-feed and was thus forced to insert all of the feed data into the entry's atom:source. Of course, once you've got a single-entry Atom feed which contains a signed entry, you have all the feed data duplicated -- so, it wouldn't be surprising to see authors of such feeds argue that they shouldn't be forced to waste bits on duplicated feed data when an atom entry document provides exactly what they need.
    In any case, while it appears reasonable (and sometimes efficient) for people to subscribe to Entry documents, I don't think we should do anything disruptive unless someone can establish actual harm being caused by the current state of affairs.

bob wyman

 ------=_Part_50427_22152777.1165597572693-- From owner-atom-syntax@mail.imc.org Fri Dec 08 13:10:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GskB2-0000an-EL for atompub-archive@lists.ietf.org; Fri, 08 Dec 2006 13:10:28 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GskAz-0003K7-V6 for atompub-archive@lists.ietf.org; Fri, 08 Dec 2006 13:10:28 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB8HqISx005477; Fri, 8 Dec 2006 10:52:18 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB8HqItL005476; Fri, 8 Dec 2006 10:52:18 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.228]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB8HqHF2005468 for ; Fri, 8 Dec 2006 10:52:17 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i20so565175wra for ; Fri, 08 Dec 2006 09:52:16 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=BNQn+wM2W5944IpoNovf5s2o4W1UUdGg169wD5X2/OznWfd6Kv1qff38SiklEvbJr09Y2VqJJwDUi0kwpAGeN1rkMhDHM0I2nCVuybOQDwh1j36+F5IvwP7x3uYZpMRmYRrUD+eY/V+r0Wiphk52QHmzb5WuzBF6dQr83P/NCds= Received: by 10.90.101.19 with SMTP id y19mr4403392agb.1165600336449; Fri, 08 Dec 2006 09:52:16 -0800 (PST) Received: from ?192.168.1.101? ( [67.181.218.96]) by mx.google.com with ESMTP id 38sm5310612wrl.2006.12.08.09.52.14; Fri, 08 Dec 2006 09:52:16 -0800 (PST) Message-ID: <4579A645.3000209@gmail.com> Date: Fri, 08 Dec 2006 09:52:05 -0800 From: James M Snell User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: Bob Wyman CC: atom-syntax@imc.org Subject: Re: Fwd: PaceEntryMediatype References: <456DB265.5090804@gmail.com> <456DCFF0.4000007@gmail.com> <28CAF6FA-75C5-456D-BAC5-18AEAA6EA1FE@geckotribe.com> <456F0A31.4050703@gmail.com> <45be5cd40612071806h525fa94kfd2a7e33cf4e0e7@mail.gmail.com> <45be5cd40612080903q75e9cc9bucaf348ca6aa1838@mail.gmail.com> In-Reply-To: <45be5cd40612080903q75e9cc9bucaf348ca6aa1838@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 I'm fine with the type parameter approach so long as it is effective. By effective I mean: Will existing implementations actually take the time to update their behavior to properly handle the optional type parameter. - James Bob Wyman wrote: >[snip] > James suggests: "the type parameter is [a] potentially more elegant > solution." Elegance is goodness. Let's insist on elegant solutions in > the absence of compelling reasons to be inelegant. > > bob wyman From owner-atom-syntax@mail.imc.org Fri Dec 08 13:21:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GskLK-00059X-53 for atompub-archive@lists.ietf.org; Fri, 08 Dec 2006 13:21:06 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GskLI-0004Rt-JG for atompub-archive@lists.ietf.org; Fri, 08 Dec 2006 13:21:06 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB8H3WAC099705; Fri, 8 Dec 2006 10:03:32 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB8H3WdT099704; Fri, 8 Dec 2006 10:03:32 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB8H3VLb099698 for ; Fri, 8 Dec 2006 10:03:32 -0700 (MST) (envelope-from bobwyman@gmail.com) Received: by py-out-1112.google.com with SMTP id f31so441034pyh for ; Fri, 08 Dec 2006 09:03:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=Eukvjro8fXta/F/YGmNiToHPPbstO5rhGPUFCy9Qas0nSnRfir5qSuprcahf9yFHB++CLAcR0mL6hQe8Ogy5Cn5SiCz3tZrB6EotsTGQfsc+DI82cOi5P862pE1YeSVA2BcdY27dYYJ8NCAncnZTpiCJyzy406CQm5e7/QWh0g4= Received: by 10.35.43.10 with SMTP id v10mr6168906pyj.1165597409375; Fri, 08 Dec 2006 09:03:29 -0800 (PST) Received: by 10.35.15.12 with HTTP; Fri, 8 Dec 2006 09:03:28 -0800 (PST) Message-ID: <45be5cd40612080903q75e9cc9bucaf348ca6aa1838@mail.gmail.com> Date: Fri, 8 Dec 2006 12:03:28 -0500 From: "Bob Wyman" To: atom-syntax@imc.org Subject: Fwd: PaceEntryMediatype In-Reply-To: <45be5cd40612071806h525fa94kfd2a7e33cf4e0e7@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_50383_24230654.1165597408790" References: <456DB265.5090804@gmail.com> <456DCFF0.4000007@gmail.com> <28CAF6FA-75C5-456D-BAC5-18AEAA6EA1FE@geckotribe.com> <456F0A31.4050703@gmail.com> <45be5cd40612071806h525fa94kfd2a7e33cf4e0e7@mail.gmail.com> X-Google-Sender-Auth: a0875e5a8c7a813b Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.5 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 ------=_Part_50383_24230654.1165597408790 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 11/30/06, James M Snell wrote: > > > > The key problem with "application/atom+xml;type=entry" is that at least > > one major browser (Firefox 2.0) still treats it as a feed and shows the > > "subscribe" link. So while the type parameter is a potentially more > > elegant solution, the new media type approach would likely be far less > > disruptive. > I don't understand the logic behind saying that it would be "far less > disruptive" to rely on the type parameter in lieu of creating new media > types. Personally, I think the type parameter is the solution to this > alleged "problem"... It appears to me that the disruption that would be > avoided by orphaning atom entries behind a "weird" new media-type is nothing > more than the effort of a minor update in a future revision of Firefox. > Prior to that update, behavior would be as it is today and frankly, that > isn't a really big problem since, as far as I can see, there haven't been > many reports of harm being caused by hordes of people accidently trying to > subscribe to atom entries. The issues being discussed in this thread seem to be largely hypothetical at best. Nobody has actually established that any harm is currently being done as a result of the "ambiguity" of having both atom document types share a single atom media type. The discussion would be a great deal more engaging if someone could cite an actual history of issues. Barring discovery of real, pressing problems, I think we should take the more conservative approach of using the disambiguation tools provided by the media-type specification -- i.e. use the type parameter. We've got more important issues to focus on... James suggests: "the type parameter is [a] potentially more elegant solution." Elegance is goodness. Let's insist on elegant solutions in the absence of compelling reasons to be inelegant. bob wyman ------=_Part_50383_24230654.1165597408790 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 11/30/06, James M Snell <jasnell@gmail.com > wrote:

> The key problem with "application/atom+xml;type=entry" is that at least
> one major browser (Firefox 2.0) still treats it as a feed and shows the
> "subscribe" link. So while the type parameter is a potentially more
> elegant solution, the new media type approach would likely be far less
> disruptive.
   I don't understand the logic behind saying that it would be "far less disruptive" to rely on the type parameter in lieu of creating new media types. Personally, I think the type parameter is the solution to this alleged "problem"... It appears to me that the disruption that would be avoided by orphaning atom entries behind a "weird" new media-type is nothing more than the effort of a minor update in a future revision of Firefox. Prior to that update, behavior would be as it is today and frankly, that isn't a really big problem since, as far as I can see, there haven't been many reports of harm being caused by hordes of people accidently trying to subscribe to atom entries.
     The issues being discussed in this thread seem to be largely hypothetical at best. Nobody has actually established that any harm is currently being done as a result of the "ambiguity" of having both atom document types share a single atom media type. The discussion would be a great deal more engaging if someone could cite an actual history of issues. Barring discovery of real, pressing problems, I think we should take the more conservative approach of using the disambiguation tools provided by the media-type specification -- i.e. use the type parameter. We've got more important issues to focus on...
     James suggests: "the type parameter is [a] potentially more elegant solution." Elegance is goodness. Let's insist on elegant solutions in the absence of compelling reasons to be inelegant.

bob wyman
------=_Part_50383_24230654.1165597408790-- From owner-atom-syntax@mail.imc.org Fri Dec 08 14:11:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsl8Z-0007ob-PT for atompub-archive@lists.ietf.org; Fri, 08 Dec 2006 14:11:59 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gsl8Y-0002Ep-C2 for atompub-archive@lists.ietf.org; Fri, 08 Dec 2006 14:11:59 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB8HnnVV005081; Fri, 8 Dec 2006 10:49:49 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB8HnnmM005080; Fri, 8 Dec 2006 10:49:49 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.239]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB8HnmvA005073 for ; Fri, 8 Dec 2006 10:49:48 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id i30so849756wxd for ; Fri, 08 Dec 2006 09:49:47 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Ktopt5vXbGNNMukU2IRK+zAHcKSKOiVZwP7pBcAGY7bbg2k3LOy3uxUmq5UYE7cOCe+FW+7vbhJtWWL2FZoPxLCCLltgtNO4NgnM5mykdZJSATVdkQmjamAeMIYHuIvyHmK9XLdrx+KfTWFQ5C/wwezB+HThy9btlhge2b0GhA8= Received: by 10.90.101.19 with SMTP id y19mr4399135agb.1165600187413; Fri, 08 Dec 2006 09:49:47 -0800 (PST) Received: from ?192.168.1.101? ( [67.181.218.96]) by mx.google.com with ESMTP id 38sm5303930wrl.2006.12.08.09.49.45; Fri, 08 Dec 2006 09:49:46 -0800 (PST) Message-ID: <4579A5B3.3080803@gmail.com> Date: Fri, 08 Dec 2006 09:49:39 -0800 From: James M Snell User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: Bob Wyman CC: atom-syntax@imc.org Subject: Re: Fwd: PaceEntryMediatype References: <456DB265.5090804@gmail.com> <4574759D.1070904@gmail.com> <45748679.70602@gmail.com> <4575D37D.8080909@gmail.com> <45764C7A.5040008@gmail.com> <45be5cd40612071836s4e110ea2v165a41e501102730@mail.gmail.com> <45be5cd40612080906m130d30c5ybfd5af5a74c085aa@mail.gmail.com> In-Reply-To: <45be5cd40612080906m130d30c5ybfd5af5a74c085aa@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Bob Wyman wrote: >[snip] > What you seem to be implying is that the majority of applications > that process Atom Feed documents are not, in fact, supporting extremely > important parts of the atom specification. I believe that any properly >[snip] Not quite. What I'm implying is that not all applications have the need to implement the entire specification. Atom Entry Documents and Atom Feed Documents are each very useful but for different reasons. > constructed Atom Feed parser will contain all the code needed to parse > the most complex Atom Entry document. And, an entry document with an > atom:source is semantically equivelant to an atom:feed with a single > entry... The problem here is that people insist on building Atom > parsers that aren't capable of handling more semantics than legacy RSS. > What we should be doing is encouraging people to exploit Atom and use > its features -- atom:source among others -- that aren't supported by RSS. +1 on all points. > For a parser that properly handles the case of an atom:entry > appearing within atom:feed, it should be trivially simple code to > recognize and handle an entry without a feed wrapper. I think there are > even cases where this makes sense -- and you would even want to > subscribe to such a thing: Trivial, yes. That's not really the issue for me. >[snip] > In any case, while it appears reasonable (and sometimes efficient) > for people to subscribe to Entry documents, I don't think we should do > anything disruptive unless someone can establish actual harm being > caused by the current state of affairs. > The fact that I cannot link to an Atom Entry Document from a browser without it trying (and failing) to process it as a Feed Document is harmful. - James From owner-atom-syntax@mail.imc.org Fri Dec 08 18:11:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsos7-0007Rc-Ty for atompub-archive@lists.ietf.org; Fri, 08 Dec 2006 18:11:15 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gsos5-00081i-Hd for atompub-archive@lists.ietf.org; Fri, 08 Dec 2006 18:11:15 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB8Moupq040426; Fri, 8 Dec 2006 15:50:56 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB8MoulB040425; Fri, 8 Dec 2006 15:50:56 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.183]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB8MotGQ040419 for ; Fri, 8 Dec 2006 15:50:56 -0700 (MST) (envelope-from algermissen1971@mac.com) Received: from mac.com (smtpin05-en2 [10.13.10.150]) by smtpout.mac.com (Xserve/8.12.11/smtpout13/MantshX 4.0) with ESMTP id kB8MopVF019311; Fri, 8 Dec 2006 14:50:52 -0800 (PST) Received: from [10.0.1.2] (d192001.adsl.hansenet.de [80.171.192.1]) (authenticated bits=0) by mac.com (Xserve/smtpin05/MantshX 4.0) with ESMTP id kB8MoiCO003499; Fri, 8 Dec 2006 14:50:49 -0800 (PST) In-Reply-To: <4579A5B3.3080803@gmail.com> References: <456DB265.5090804@gmail.com> <4574759D.1070904@gmail.com> <45748679.70602@gmail.com> <4575D37D.8080909@gmail.com> <45764C7A.5040008@gmail.com> <45be5cd40612071836s4e110ea2v165a41e501102730@mail.gmail.com> <45be5cd40612080906m130d30c5ybfd5af5a74c085aa@mail.gmail.com> <4579A5B3.3080803@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Bob Wyman , atom-syntax@imc.org Content-Transfer-Encoding: 7bit From: Jan Algermissen Subject: Re: PaceEntryMediatype Date: Fri, 8 Dec 2006 23:48:06 +0100 To: James M Snell X-Mailer: Apple Mail (2.752.3) X-Brightmail-scanned: yes Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.5 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 On Dec 8, 2006, at 6:49 PM, James M Snell wrote: > Not quite. What I'm implying is that not all applications have the > need > to implement the entire specification. At this point it would be a really good idea to be clear about the original intention of the specification and then propably align the specs with that as opposed to having software that only implements half of a specs. People out there might be caused to think this is good practice.... Jan From owner-atom-syntax@mail.imc.org Fri Dec 08 19:48:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsqO4-0000dh-BZ for atompub-archive@lists.ietf.org; Fri, 08 Dec 2006 19:48:20 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsqNz-0005ZZ-TG for atompub-archive@lists.ietf.org; Fri, 08 Dec 2006 19:48:20 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB90WGPJ048854; Fri, 8 Dec 2006 17:32:16 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB90WGB7048853; Fri, 8 Dec 2006 17:32:16 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from csmtp1.b-one.net (csmtp.b-one.net [195.47.247.21]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB90WFR8048844 for ; Fri, 8 Dec 2006 17:32:16 -0700 (MST) (envelope-from asbjorn@tigerstaden.no) Received: from quark (72.84-48-117.nextgentel.com [84.48.117.72]) by csmtp1.b-one.net (Postfix) with ESMTP id 506FA19116701; Sat, 9 Dec 2006 01:32:09 +0100 (CET) Date: Sat, 09 Dec 2006 01:33:39 +0100 To: "Jan Algermissen" , "Antone Roundy" Subject: Re: PaceEntryMediatype From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Cc: atom-syntax@imc.org Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <456DB265.5090804@gmail.com> <456E7DE0.8040002@gmail.com> <456EF996.7060009@defuze.org> <4574759D.1070904@gmail.com> <45748679.70602@gmail.com> <8B583D59-010F-1000-826F-7EB2F9E7E3CB-Webmail-10013@mac.com> Message-ID: In-Reply-To: <8B583D59-010F-1000-826F-7EB2F9E7E3CB-Webmail-10013@mac.com> User-Agent: Opera Mail/9.10 (Win32) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id kB90WGPJ048854 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca On Wed, 06 Dec 2006 20:42:40 +0100, Jan Algermissen =20 wrote: > But that is an issue of linking semantics, not link target media types. Wrong. The link relation 'alternate' is perfectly valid for both Entry an= d =20 Feed documents, depending on what type of resource they are linked from. = =20 An index page of a website can have an 'alternate' relation to an Atom =20 Feed, while an individual article page (or "entry" page) can have an =20 'alternate' relation to an Atom Entry. Both link relations are identical,= =20 but the client has absolutely no clue before it GETs the URI whether what= =20 sits on the other end is an Atom Feed or an Atom Entry. Let's take Firefox as an example of a feed reader. When you browse to a =20 page saying it has 'alternate' resources, you get a nice little orange =20 "subscribe" button in the address field. Pushing it makes you a subscribe= r =20 of that alternate resource. On an index page, that's fine, because the =20 "alternate" resource is an Atom Feed. However, on an individual article =20 page, Firefox will still display the "subscribe" button although it =20 doesn't support subscribtion to the resource and subscribing to it in the= =20 first place doesn't make much sense. Wouldn't it be a better experience to not get the "subscribe" button on =20 the article page at all? Or do you prefer that it's there and that you =20 need to press it and get an error message (that you most probably won't =20 understand if you're not a technical user like you and me) to know that =20 you can't subscribe to this alternate resource after all? What do you =20 think? > I'd expect the user agent to look for links with 'here is a feed' =20 > semantics instead of looking for (arbitrary) links to certain media =20 > types. The 'alternate' relation is fine for both uses. However, the WHATWG =20 propsed 'feed' relation is a bit more explicit on the "subscribe to me" =20 part. Still, an Atom Feed can be 'alternate' of an index page just as an = =20 Atom Entry can be 'alternate' of an article page. People shouldn't be =20 forced to use the 'feed' relation, and I highly doubt that the widely =20 deployed 'alternate' relation can be replaced that easilly. --=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 Fri Dec 08 19:56:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsqVs-0002uT-Mz for atompub-archive@lists.ietf.org; Fri, 08 Dec 2006 19:56:24 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsqVq-0006zj-7I for atompub-archive@lists.ietf.org; Fri, 08 Dec 2006 19:56:24 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB90dkiP049401; Fri, 8 Dec 2006 17:39:46 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB90dkOi049400; Fri, 8 Dec 2006 17:39:46 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from csmtp1.b-one.net (csmtp.b-one.net [195.47.247.21]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB90djkX049392 for ; Fri, 8 Dec 2006 17:39:45 -0700 (MST) (envelope-from asbjorn@tigerstaden.no) Received: from quark (72.84-48-117.nextgentel.com [84.48.117.72]) by csmtp1.b-one.net (Postfix) with ESMTP id 9FB2919116054; Sat, 9 Dec 2006 01:39:39 +0100 (CET) Date: Sat, 09 Dec 2006 01:41:11 +0100 To: "Henry Story" , "Jan Algermissen" Subject: Re: PaceEntryMediatype From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Cc: "Antone Roundy" , atom-syntax@imc.org Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <456DB265.5090804@gmail.com> <456E7DE0.8040002@gmail.com> <456EF996.7060009@defuze.org> <4574759D.1070904@gmail.com> <45748679.70602@gmail.com> <8B583D59-010F-1000-826F-7EB2F9E7E3CB-Webmail-10013@mac.com> Message-ID: In-Reply-To: User-Agent: Opera Mail/9.10 (Win32) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id kB90dkiP049401 X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 On Thu, 07 Dec 2006 20:15:48 +0100, Henry Story = =20 wrote: > Just to say that I strongly agree with Jan's points below. We should =20 > work to use the link relation type properly, and not get dazzled by the= =20 > current misuse of the alternate relation. This problem isn't only with link relations. Or, if it is, it demands tha= t =20 all existing and future link relations remain different for Feed and Entr= y =20 documents, since the use cases and processing of the documents will =20 differ. Although the relations themselves might actually be the same, =20 semantically speaking, they need to be named differently because =20 processing an entry with that relation is different from processing a fee= d =20 with that relation. Should we expand the relations with a 'type' attribut= e =20 instead? (/irony) > One could for example have the following at the same place: > > - an html version of a blog post > - an representation of that blog post > - a for the history of changes to that blog post > > That would suggest having different media types because one could not =20 > place them at the same location if one only has application/atom+xml . Another good example. > That does not decide the issue as to whether it is a good idea to do so. I think it adds more weight to the "we need a new MIME type" scale. > For the moment I find the application/atom+xml;type=3Dentry application= /=20 > atom+xml;type=3Dfeed more appealing than the other new media types by t= he =20 > way. So do I. > On the other hand having different mime types for every document format= =20 > is also crazy. A new MIME type is useful when the processing of the resource differs and= =20 at least knowing this beforehand is substantial information. Knowing this= =20 for Atom Entry documents is substantial imo. --=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 Fri Dec 08 19:59:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsqZB-0004y8-AF for atompub-archive@lists.ietf.org; Fri, 08 Dec 2006 19:59:49 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsqZ9-0008W1-SB for atompub-archive@lists.ietf.org; Fri, 08 Dec 2006 19:59:49 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB90YTsI049047; Fri, 8 Dec 2006 17:34:29 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB90YTJ2049046; Fri, 8 Dec 2006 17:34:29 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from csmtp1.b-one.net (csmtp.b-one.net [195.47.247.21]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB90YSDs049036 for ; Fri, 8 Dec 2006 17:34:29 -0700 (MST) (envelope-from asbjorn@tigerstaden.no) Received: from quark (72.84-48-117.nextgentel.com [84.48.117.72]) by csmtp1.b-one.net (Postfix) with ESMTP id 55E6619116063; Sat, 9 Dec 2006 01:34:23 +0100 (CET) To: "James M Snell" , "Henry Story" Subject: Re: PaceEntryMediatype From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Cc: "Jan Algermissen" , "Antone Roundy" , atom-syntax@imc.org Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <456DB265.5090804@gmail.com> <456E7DE0.8040002@gmail.com> <456EF996.7060009@defuze.org> <4574759D.1070904@gmail.com> <45748679.70602@gmail.com> <8B583D59-010F-1000-826F-7EB2F9E7E3CB-Webmail-10013@mac.com> <45786D72.8030205@gmail.com> Date: Sat, 09 Dec 2006 01:35:54 +0100 Message-ID: In-Reply-To: <45786D72.8030205@gmail.com> User-Agent: Opera Mail/9.10 (Win32) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id kB90YTsI049047 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 On Thu, 07 Dec 2006 20:37:22 +0100, James M Snell =20 wrote: > Content types are only useful when they help to differentiate how a > document is to processed. If it was all about the format we could have > just used application/xml all along. IMHO, There is already sufficient > evidence that entry documents and feed documents are processed > differently and thus deserve different content types. Indeed. +1. --=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 Fri Dec 08 20:02:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsqbW-0005br-7q for atompub-archive@lists.ietf.org; Fri, 08 Dec 2006 20:02:14 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsqbT-0000SS-OU for atompub-archive@lists.ietf.org; Fri, 08 Dec 2006 20:02:14 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB90mZMK051008; Fri, 8 Dec 2006 17:48:35 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB90mYQm051007; Fri, 8 Dec 2006 17:48:34 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from csmtp1.b-one.net (csmtp.b-one.net [195.47.247.21]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB90mXoA050835 for ; Fri, 8 Dec 2006 17:48:34 -0700 (MST) (envelope-from asbjorn@tigerstaden.no) Received: from quark (72.84-48-117.nextgentel.com [84.48.117.72]) by csmtp1.b-one.net (Postfix) with ESMTP id 6AD1B1911604B; Sat, 9 Dec 2006 01:48:23 +0100 (CET) To: "James M Snell" , "Bob Wyman" Subject: Re: Fwd: PaceEntryMediatype From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Cc: atom-syntax@imc.org Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <456DB265.5090804@gmail.com> <456DCFF0.4000007@gmail.com> <28CAF6FA-75C5-456D-BAC5-18AEAA6EA1FE@geckotribe.com> <456F0A31.4050703@gmail.com> <45be5cd40612071806h525fa94kfd2a7e33cf4e0e7@mail.gmail.com> <45be5cd40612080903q75e9cc9bucaf348ca6aa1838@mail.gmail.com> <4579A645.3000209@gmail.com> Date: Sat, 09 Dec 2006 01:49:55 +0100 Message-ID: In-Reply-To: <4579A645.3000209@gmail.com> User-Agent: Opera Mail/9.10 (Win32) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id kB90mZMK051008 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 On Fri, 08 Dec 2006 18:52:05 +0100, James M Snell =20 wrote: > I'm fine with the type parameter approach so long as it is effective. > By effective I mean: Will existing implementations actually take the > time to update their behavior to properly handle the optional type > parameter. Seeing how eager most applications have been to implement Atom support, I= =20 believe the answer to this question is "yes". I'm optimistic at least. --=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 Sat Dec 09 00:59:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsvEs-0006Wj-GD for atompub-archive@lists.ietf.org; Sat, 09 Dec 2006 00:59:10 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsvEr-00049y-3v for atompub-archive@lists.ietf.org; Sat, 09 Dec 2006 00:59:10 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB95eYvW078814; Fri, 8 Dec 2006 22:40:34 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB95eYah078813; Fri, 8 Dec 2006 22:40:34 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB95eXVG078806 for ; Fri, 8 Dec 2006 22:40:34 -0700 (MST) (envelope-from mbaker@gmail.com) Received: by nf-out-0910.google.com with SMTP id m18so1177018nfc for ; Fri, 08 Dec 2006 21:40:32 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=cDtPu7DMs34fBUHZhOrWozr2u+3mCXPlZ2/AsGaAqKUbAjYjKQIcFj1afIKvbY6xNzGd6qaPILvNz7cFn1niw8BI/zKrojniF8av4SKYE7EVsrM4ZKAGX9ICrvBb1B6tipgLf4hqdt3zatl4seVdCrFzRFE3iRKmvSB2r0bXzvQ= Received: by 10.78.97.7 with SMTP id u7mr116097hub.1165642832330; Fri, 08 Dec 2006 21:40:32 -0800 (PST) Received: by 10.78.174.19 with HTTP; Fri, 8 Dec 2006 21:40:22 -0800 (PST) Message-ID: Date: Sat, 9 Dec 2006 00:40:22 -0500 From: "Mark Baker" To: "=?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?=" Subject: Re: PaceEntryMediatype Cc: "Jan Algermissen" , "Antone Roundy" , atom-syntax@imc.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline References: <456DB265.5090804@gmail.com> <45748679.70602@gmail.com> <8B583D59-010F-1000-826F-7EB2F9E7E3CB-Webmail-10013@mac.com> X-Google-Sender-Auth: 378168df2f910d62 X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kB95eYVG078808 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id kB95eYvW078814 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d On 12/8/06, Asbj=F8rn Ulsberg wrote: > > On Wed, 06 Dec 2006 20:42:40 +0100, Jan Algermissen > wrote: > > > But that is an issue of linking semantics, not link target media type= s. > > Wrong. The link relation 'alternate' is perfectly valid for both Entry = and > Feed documents, depending on what type of resource they are linked from. > An index page of a website can have an 'alternate' relation to an Atom > Feed, while an individual article page (or "entry" page) can have an > 'alternate' relation to an Atom Entry. As it can to a feed with one entry. > Both link relations are identical, > but the client has absolutely no clue before it GETs the URI whether wh= at > sits on the other end is an Atom Feed or an Atom Entry. Nor should it need to distinguish, just like it doesn't need to distinguish between a feed with multiple entries, versus one with one entry. Mark. From owner-atom-syntax@mail.imc.org Sat Dec 09 01:35:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsvoQ-0001dp-GQ for atompub-archive@lists.ietf.org; Sat, 09 Dec 2006 01:35:54 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsvoO-0003Gr-Kv for atompub-archive@lists.ietf.org; Sat, 09 Dec 2006 01:35:54 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB96GeeY081241; Fri, 8 Dec 2006 23:16:40 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB96Ge7l081240; Fri, 8 Dec 2006 23:16:40 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB96Gexo081234 for ; Fri, 8 Dec 2006 23:16:40 -0700 (MST) (envelope-from henry.story@bblfish.net) Received: (qmail 69964 invoked by uid 17064); 9 Dec 2006 06:16:39 -0000 Received: from unknown (HELO [192.168.1.117]) ([64.167.141.156]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 9 Dec 2006 06:16:39 -0000 In-Reply-To: References: <456DB265.5090804@gmail.com> <45748679.70602@gmail.com> <8B583D59-010F-1000-826F-7EB2F9E7E3CB-Webmail-10013@mac.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <1A956ADE-65D1-46AC-89BD-2F61A22E7F62@bblfish.net> Cc: =?ISO-8859-1?Q?"Asbj=F8rn_Ulsberg"?= , "Jan Algermissen" , "Antone Roundy" , atom-syntax@imc.org From: Henry Story Subject: Re: PaceEntryMediatype Date: Fri, 8 Dec 2006 22:16:41 -0800 To: "Mark Baker" X-Mailer: Apple Mail (2.752.3) X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kB96Gexo081235 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id kB96GeeY081241 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 I can see a reason to distinguish more strongly between a feed and an =20 entry. And this is with regards to creating new collections. The best way I see to create a new collection would be to POST a =20 containing no entries to a collection end point. =20 Though that is very similar to POSTing an I think the =20 distinction is worth preserving at that point. I am not sure if this has any bearing on mime types though. Henry On 8 Dec 2006, at 21:40, Mark Baker wrote: > > On 12/8/06, Asbj=F8rn Ulsberg wrote: >> >> On Wed, 06 Dec 2006 20:42:40 +0100, Jan Algermissen >> wrote: >> >> > But that is an issue of linking semantics, not link target media =20 >> types. >> >> Wrong. The link relation 'alternate' is perfectly valid for both =20 >> Entry and >> Feed documents, depending on what type of resource they are linked =20 >> from. >> An index page of a website can have an 'alternate' relation to an =20 >> Atom >> Feed, while an individual article page (or "entry" page) can have an >> 'alternate' relation to an Atom Entry. > > As it can to a feed with one entry. > >> Both link relations are identical, >> but the client has absolutely no clue before it GETs the URI =20 >> whether what >> sits on the other end is an Atom Feed or an Atom Entry. > > Nor should it need to distinguish, just like it doesn't need to > distinguish between a feed with multiple entries, versus one with one > entry. > > Mark. From owner-atom-syntax@mail.imc.org Sat Dec 09 07:21:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt1CU-0007j0-G2 for atompub-archive@lists.ietf.org; Sat, 09 Dec 2006 07:21:06 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gt1CT-0000o5-3D for atompub-archive@lists.ietf.org; Sat, 09 Dec 2006 07:21:06 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB9BvjJD011659; Sat, 9 Dec 2006 04:57:45 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB9Bvjh7011658; Sat, 9 Dec 2006 04:57:45 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB9Bvjc6011651 for ; Sat, 9 Dec 2006 04:57:45 -0700 (MST) (envelope-from algermissen1971@mac.com) Received: from mac.com (smtpin03-en2 [10.13.10.148]) by smtpout.mac.com (Xserve/8.12.11/smtpout08/MantshX 4.0) with ESMTP id kB9Bve7V015616; Sat, 9 Dec 2006 03:57:40 -0800 (PST) Received: from [10.0.1.2] (e176051050.adsl.alicedsl.de [85.176.51.50]) (authenticated bits=0) by mac.com (Xserve/smtpin03/MantshX 4.0) with ESMTP id kB9BvZnP018631; Sat, 9 Dec 2006 03:57:37 -0800 (PST) In-Reply-To: References: <456DB265.5090804@gmail.com> <45748679.70602@gmail.com> <8B583D59-010F-1000-826F-7EB2F9E7E3CB-Webmail-10013@mac.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <5ABE6F26-430A-4645-AFCA-D4481B562A4B@mac.com> Cc: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= , Antone Roundy , atom-syntax@imc.org From: Jan Algermissen Subject: Re: PaceEntryMediatype Date: Sat, 9 Dec 2006 12:57:57 +0100 To: Mark Baker X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kB9Bvjc6011653 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id kB9BvjJD011659 X-Spam-Score: 0.5 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 On Dec 9, 2006, at 6:40 AM, Mark Baker wrote: On 12/8/06, Asbj=F8rn Ulsberg wrote: >> Both link relations are identical, >> but the client has absolutely no clue before it GETs the URI =20 >> whether what >> sits on the other end is an Atom Feed or an Atom Entry. > > Nor should it need to distinguish Asbj=F8rn, the link is to the resource, not a particular representation =20 of it. The media type is just a hint, what you get upon a GET can vary and your client should prepare for that. You can make use of that hint, but it does in no way tell you what the actual media type is you'll get upon a GET; it is not authoritative, the Content-Type header is. What you can rely on is that the server uses the correct link =20 relation. IOW, that the server informs you about the relationship correctly, that it =20 does not tell you X is an alternate of A if it isn't. Something else: Suppose there were two representation formats for atom feeds one in =20 XML and one in some space optimized text format. Conceptually they server up =20 the same information - what type goes into the type attribute? And yet in other words: Media type are telling you hw to process a representation, not of =20 what kind the resource is (resources are not typed, BTW). Jan From owner-atom-syntax@mail.imc.org Sat Dec 09 08:58:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt2iI-0004Dq-Pw for atompub-archive@lists.ietf.org; Sat, 09 Dec 2006 08:58:02 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gt2iE-0007X1-ES for atompub-archive@lists.ietf.org; Sat, 09 Dec 2006 08:58:02 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB9DdJJm020295; Sat, 9 Dec 2006 06:39:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB9DdJkk020294; Sat, 9 Dec 2006 06:39:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from gregerhaga.net (gregerhaga.net [84.234.70.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB9DdIwR020286 for ; Sat, 9 Dec 2006 06:39:19 -0700 (MST) (envelope-from boss@gregerhaga.net) Received: from ssl.gregerhaga.net (gregerhaga.net [127.0.0.1]) by gregerhaga.net (8.13.1/8.13.1) with ESMTP id kB9DdG6S023628 for ; Sat, 9 Dec 2006 15:39:17 +0200 From: "Greger" To: atom-syntax@imc.org Subject: rss reader Date: Sat, 9 Dec 2006 15:39:16 +0200 Message-Id: <20061209133740.M49034@gregerhaga.net> X-Mailer: Open WebMail 2.51 20050228 X-OriginatingIP: 85.156.199.247 (boss) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.5 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 hi I have made a prototype rss reader. All is good. just wondering if anyone would be interested in getting down to create a C++ library for in particular atom, but also the other used rss feed types. anyone working on this kinds of things? thank's -- http://www.gregerhaga.net/ http://hack-space.biz/ From owner-atom-syntax@mail.imc.org Sat Dec 09 13:32:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt70E-0005CZ-Mt for atompub-archive@lists.ietf.org; Sat, 09 Dec 2006 13:32:50 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gt70D-0007EN-A9 for atompub-archive@lists.ietf.org; Sat, 09 Dec 2006 13:32:50 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB9IIe5f048969; Sat, 9 Dec 2006 11:18:40 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB9IIeBi048968; Sat, 9 Dec 2006 11:18:40 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web33205.mail.mud.yahoo.com (web33205.mail.mud.yahoo.com [209.191.69.153]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id kB9IIc87048865 for ; Sat, 9 Dec 2006 11:18:39 -0700 (MST) (envelope-from rcade@yahoo.com) Received: (qmail 58491 invoked by uid 60001); 9 Dec 2006 18:18:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=B1aTfvYSuXiDRxUZ1zU7mecnyQ2368WWRDHjgzxEqADK3GfrTSYiRTPD596/Ln3wmaTEHl0qUl6f6sY4k5L43GlDkIdFiBZKVw14p/HqzSRLXat/9ARBo4s6662Rsy+5TmmYgX1jq1FzTBhCvpkbw7vXkz30Ene6aFGMs9nUoQw=; X-YMail-OSG: rqS6UK0VM1nQOJV4zxq3iRb0v7IMGkHAov.9O704Z3YJsaEX3X1C3zIzFybXeyy3g7qHboSJZWFMvmYs.RkJcJ68t.jmwyzpi2OK5h1vtcOT75MRzyW4UJJ659l1CrnbyWl3YzdDzfSfuQ-- Received: from [68.17.221.213] by web33205.mail.mud.yahoo.com via HTTP; Sat, 09 Dec 2006 10:18:32 PST Date: Sat, 9 Dec 2006 10:18:32 -0800 (PST) From: Rogers Cadenhead Subject: Atom in Java (was rss reader) To: atom-syntax@imc.org In-Reply-To: <20061209133740.M49034@gregerhaga.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <494582.50550.qm@web33205.mail.mud.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de --- Greger wrote: > anyone working on this kinds of things? Don't know of any C++ efforts, but Apache Abdera's a new Java class library to implement the Atom syndication format and publication protocol: http://incubator.apache.org/abdera From owner-atom-syntax@mail.imc.org Sat Dec 09 13:41:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt78d-00088d-Ef for atompub-archive@lists.ietf.org; Sat, 09 Dec 2006 13:41:31 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gt78R-0001R0-LH for atompub-archive@lists.ietf.org; Sat, 09 Dec 2006 13:41:31 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB9IRHSl050570; Sat, 9 Dec 2006 11:27:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB9IRHHU050569; Sat, 9 Dec 2006 11:27:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB9IRF0u050555 for ; Sat, 9 Dec 2006 11:27:16 -0700 (MST) (envelope-from henry.story@bblfish.net) Received: (qmail 18236 invoked by uid 17064); 9 Dec 2006 18:27:14 -0000 Received: from unknown (HELO [192.168.1.105]) ([63.204.10.130]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 9 Dec 2006 18:27:14 -0000 In-Reply-To: <5ABE6F26-430A-4645-AFCA-D4481B562A4B@mac.com> References: <456DB265.5090804@gmail.com> <45748679.70602@gmail.com> <8B583D59-010F-1000-826F-7EB2F9E7E3CB-Webmail-10013@mac.com> <5ABE6F26-430A-4645-AFCA-D4481B562A4B@mac.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: multipart/mixed; boundary=Apple-Mail-57-550558534 Message-Id: <7E1DA2EE-A1D5-486F-93A0-680E6F51219E@bblfish.net> Cc: Baker Mark , =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= , Roundy Antone , Atom Syntax , atom-owl@googlegroups.com From: Henry Story Subject: Re: PaceEntryMediatype Date: Sat, 9 Dec 2006 10:27:15 -0800 To: Jan Algermissen X-Mailer: Apple Mail (2.752.3) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.5 (/) X-Scan-Signature: 0a1b1a6d35de6f81974769730a8306bf --Apple-Mail-57-550558534 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed On 9 Dec 2006, at 03:57, Jan Algermissen wrote: > On Dec 9, 2006, at 6:40 AM, Mark Baker wrote: > > On 12/8/06, Asbj=F8rn Ulsberg wrote: > >>> Both link relations are identical, >>> but the client has absolutely no clue before it GETs the URI =20 >>> whether what >>> sits on the other end is an Atom Feed or an Atom Entry. >> >> Nor should it need to distinguish > > Asbj=F8rn, the link is to the resource, not a particular =20 > representation of it. > The media type is just a hint, what you get upon a GET can vary and > your client should prepare for that. This is a problem that has been concerning me for a while. In Atom Owl I have been toying with representing a link relation as =20 pointing to a representation, by thinking of it as follows --Apple-Mail-57-550558534 Content-Transfer-Encoding: base64 Content-Type: image/jpeg; x-mac-type=4A504547; x-unix-mode=0644; x-mac-hide-extension=yes; name=content-example.jpg Content-Disposition: inline; filename=content-example.jpg /9j/4AAQSkZJRgABAQAAAQABAAD/7QAcUGhvdG9zaG9wIDMuMAA4QklNBAQAAAAAAAD/4hEoSUND X1BST0ZJTEUAAQEAABEYYXBwbAIAAABtbnRyUkdCIFhZWiAH1gALABsAEgAaABVhY3NwQVBQTAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA9tYAAQAAAADTLWFwcGzHJ3uyX5VB5P5gBasG81a+AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5yWFlaAAABLAAAABRnWFlaAAABQAAAABRiWFla AAABVAAAABR3dHB0AAABaAAAABRjaGFkAAABfAAAACxyVFJDAAABqAAAAA5nVFJDAAABuAAAAA5i VFJDAAAByAAAAA52Y2d0AAAB2AAABhJuZGluAAAH7AAABj5kZXNjAAAOLAAAAGRkc2NtAAAOkAAA Ai5tbW9kAAAQwAAAAChjcHJ0AAAQ6AAAAC1YWVogAAAAAAAAXzEAADdZAAAGa1hZWiAAAAAAAABx RwAAsQsAACEOWFlaIAAAAAAAACZeAAAXtwAAq6xYWVogAAAAAAAA81IAAQAAAAEWz3NmMzIAAAAA AAEMQgAABd7///MmAAAHkgAA/ZH///ui///9owAAA9wAAMBsY3VydgAAAAAAAAABAc0AAGN1cnYA AAAAAAAAAQHNAABjdXJ2AAAAAAAAAAEBzQAAdmNndAAAAAAAAAAAAAMBAAACAAAAGwBeAMMBXwIq Au8D2ATmBhQHagjcCmsMFQ3SD5oRbxNFFRwW5RipGmAcCh2eHysgoiIRI28kxiYWJ1sonCnbKxYs Ui2ILr8v9DEnMlozjDS9New3GjhHOXA6mTvBPOg+Dz80QFhBekKdQ8BE4UYERydISEloSopLrEzN Te5PDlAuUU9SblONVK1VzVbtWA1ZLVpNW21cjV2uXs9f8GERYjJjU2R0ZZVmt2fZaPtqHmtAbGNt hW6pb81w8XIVczp0XXWAdqN3xHjmegd7J3xGfWR+gX+dgLeB0ILng/6FE4YmhziISYlYimeLdIyA jY2Omo+nkLWRw5LSk+OU9JYHlxqYLZlAmlObZZx2nYWekp+eoKehrqK0o7akuKW4prantKiwqauq pKucrJOtiK5+r3GwY7FUskOzMbQftQu19rbgt8q4srmZuoC7ZrxLvS++Er70v9XAtcGVwnPDUcQv xQzF6cbGx6LIf8lbyjfLE8vvzMvNps6Cz1zQNtEQ0enSwdOX1GvVP9YR1uLXr9h72UbaDtrV25jc Wt0a3drelt9R4AzgxeF84jPi6uOf5FTlCeW+5nLnJ+fb6I/pROn56q7rY+wY7M7thO467vHvqPBf 8RbxzfKE8zzz8/Sq9WH2GfbQ94f4Pvj0+ar6YPsV+8r8f/00/ej+m/9O//8AAAAaAFsAvQFPAhcC 1QOvBK4F2AchCIUKBAueDUgPAhDJEo8UVRYaF88ZehsdHKYeKh+ZIQIiXCOqJPUmNydwKKcp2SsL LDctYi6NL7Qw2DH8Mx80PzVcNnk3lDisOcI61zvpPPo+CT8UQCBBKUIxQzdEPUVDRklHTkhTSVpK YktqTHVNgE6OT5xQrFG8Us5T4VT0VghXHFgwWUVaWltvXINdl16tX8Jg12HsYwBkFWUpZj9nVGho aX1qkWumbLltzm7gb/NxBXIWcyZ0NHVCdk53WnhkeW16dnt/fId9kX6cf6eAs4HAgs6D3YTthf2H DogfiTCKQYtSjGGNcI6Aj46QnJGqkrmTx5TUleCW7Jf3mQCaB5sMnBCdEZ4PnwygBqD/ofai7KPg pNSlyKa6p62ooKmRqoOrdaxlrVauR683sCixGrILsv6z8rTntdy207fLuMS5vbq2u6+8p72evpS/ iMB7wWzCW8NHxDPFHcYFxu3H08i6yaHKh8tuzFbNPs4nzxHP+9Dm0dHSvNOm1JDVetZi10rYMNkV 2fja29u73Jvded5W3zLgDeDn4cDil+Nu5ETlGeXt5sHnk+hk6TTqA+rR657sau017gDuyO+Q8Ffx HfHh8qTzZfQl9OP1nvZZ9xL3yPh9+TH54/qT+0P78vyf/U39+v6m/1L//wAAABcAUACnARwBvgJn Ax0D9ATvBgMHJghvCcELIwyVDgYPfBDuElkTuxUXFl0XmBjFGeca/xwLHRAeDB8DH/Yg5SHTIr4j qCSQJXkmYCdIKDApFSn6Kt4rwSykLYcuaS9KMCsxDDHrMsszqjSINWc2RjclOAI44Dm8Opg7czxO PSc9/z7VP6tAf0FTQiVC9kPGRJZFZkY1RwVH1EilSXZKSEsaS+1Mwk2XTmxPQ1AZUO9RxlKeU3VU S1UhVfdWzFegWHVZSVobWu5bwFySXWVeNl8JX9xgr2GDYldjLGQBZNhlr2aHZ2BoOmkVafFqzmus bIxtbW5PbzNwGXD/cedy0XO7dKd1k3Z/d2t4WHlDei57F3wAfOh9z361f5qAf4FjgkiDLYQShPmF 34bHh6+ImImBimuLVIw+jSiOEY76j+OQzJG0kpyThJRrlVGWOJcemASY6pnRmrebnZyEnWueUp87 oCOhDaH4ouOjzqS6paamk6eAqG2pW6pJqzisJ60Xrgmu+6/vsOSx2rLSs8u0xrXBtr63vbi8ubu6 u7u8vLy9vb6+v7/AwcHCwsXDx8TKxc/G1MfbyOTJ78r9zA7NIs45z1TQc9GV0r3T6NUZ1k/XitjK 2hPbYty53hvfiOEB4ovkI+XL54rpXOtB7TrvSfFx86/14vgz+pz9L///AABuZGluAAAAAAAABjYA AJfbAABZpgAAU+oAAIsPAAAnzwAAFqgAAFANAABUOQACWZkAAoAAAAGXCgADAQAAAgAAAB0AMwBP AGoAhACeALcA0ADpAQIBGwE0AU0BZwGBAZwBtwHSAe8CDAIqAkkCagKLAq4C0gL4Ax8DSQN0A6ED 0QQDBDcEbgSoBOMFIQViBaUF6gYxBnoGxAcRB18HrwgBCFUIqgkBCVoJtAoRCm8KzwsyC5YL/Axk DM4NOQ2nDhYOiA77D28P5hBeENcRUhHPEk4SzhNPE9IUVxTdFWUV7xZ6FwcXlhgmGLcZShneGnQb CxukHD4c2h13HhUetB9VH/ggnCFBIegikCM5I+QkkCU9JesmmydMJ/8osilnKh0q1CuMLEYtAi2/ Ln4vPzABMMUxizJTMx0z6TS3NYc2WjcvOAY44Dm8Ops7fDxgPUc+MD8bQAlA+UHqQt1D0UTGRbxG s0eqSKJJm0qUS45Mik2ITodPiVCNUZRSn1OsVL5V01brWAhZKFpLW3JcnF3JXvlgLWFkYp5j3GUc ZmFnqWj1akVrmGzvbklvp3EIcm1z1XVAdq94InmZexN8kX4Tf5mBIoKvhD6F0IdliPyKlowyjdGP cZEUkrqUYpYPl76ZcpsqnOieq6B1okWkHqX+p+ep2avVrdqv57H+tB62Rbh0uqi8478jwWfDrsX5 yEbKlcznzzrRj9Pm1j7Ymdr13VTfteIa5IHm6+lY68nuP/C58zj1u/hD+s/9Yv//AAAAHgA1AFIA bwCKAKQAvgDYAPIBDAEmAUABWwF1AZEBrAHJAeYCBAIjAkICYwKFAqkCzgL0AxwDRwNzA6ED0gQF BDoEcgStBOoFKQVrBbAF9wZABowG2QcpB3sHzggkCHwI1wkzCZEJ8gpVCroLIQuLC/cMZgzXDUsN wQ46DrYPNA+1EDgQvhFGEdASXBLqE3oUCxSdFTEVxRZbFvEXiRghGLsZVhnxGo8bLRvNHG4dER21 HlsfAh+rIFYhAiGvIl4jDyPBJHUlKyXiJponVCgQKM0pjCpMKw8r0iyYLWAuKS71L8MwlDFnMjwz FDPuNMs1qjaLN204Ujk3Oh07BDvsPNU9vj6oP5NAf0FsQlpDSkQ7RS5GI0caSBNJDUoKSwhMCE0J TgxPEVAYUSJSLlM8VE5VZFZ9V5pYvFnhWwtcOl1sXqFf2mEWYlRjlWTYZh1nZWiuafprSWyZbexv QHCVcexzQ3SadfJ3Sniiefp7U3ytfgh/ZoDGgiqDkYT8hmyH4IlaitmMXI3kj3CQ/5KQlCSVuZdP mOaafZwVna2fRqDhon6kHaW/p2SpDaq7rG2uJK/fsaCzZrUxtwC41bqtvIu+bcBUwkDEMcYmyCHK IcwmzjHQQtJX1HPWldi92uzdIt9g4afj+OZT6LnrKu2m8C7yv/Va9/v6ov1R//8AAAAiAD8AYgCD AKIAwQDhAP8BHgE+AV4BfgGfAcIB5QIKAjACWAKCAq4C3AMOA0IDewO3A/cEOwSEBNEFIwV5BdMG MQaSBvcHXwfKCDgIqQkcCZMKDQqKCwoLjQwTDJwNKA23DkkO3g92EBEQrhFOEfESlxNBE+4UnhVS FgoWxheGGEoZEhneGq4bgRxXHTAeCx7oH8cgqCGKIm4jVCQ7JSUmESb/J/Ao5CnbKtUr0yzULdgu 4C/rMPkyCTMdNDI1STZiN304mTm3OtU79T0WPjc/WkB9QaBCxEPoRQxGMEdUSHlJnUrCS+dNDk42 T2BQjFG7Uu1UI1VcVplX2VkcWmJbq1z1XkFfjmDcYitjemTLZh1ncGjFahxrdWzQbi5vjnDxclZz vnUpdpZ4BXl3eut8YX3Zf1OAzYJJg8aFRIbCiEGJwItBjMKORY/JkU6S1JRbleOXbJj2moCcCZ2S nxugo6Iqo7ClNqa8qEGpxqtLrNGuWK/fsWiy8rR+tgq3mLknura8R73Yv2jA+cKIxBbFo8ctyLTK Ocu7zTnOtNAs0aDTENR91eXXStir2gjbYdy03gLfTOCQ4c7jBeQ35WLmheei6LnpyOrU69Xs0u3J 7rrvqPCQ8XXyVPMx9Af02vWo9nL3PvgP+OD5pvpt+y777vyp/Vz+EP63/1v//wAAZGVzYwAAAAAA AAAKQ29sb3IgTENEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAG1sdWMAAAAAAAAAEAAAAAxpdElUAAAA FAAAANBmckZSAAAAQgAAAORuYk5PAAAAEgAAASZlc0VTAAAAEgAAAThmaUZJAAAAEAAAAUpwdFBU AAAAGAAAAVp6aFRXAAAADgAAAXJqYUpQAAAADgAAAYBubE5MAAAAFgAAAY5kZURFAAAAEAAAAaRy dVJVAAAAJAAAAbRrb0tSAAAADAAAAdhlblVTAAAAEgAAAeRzdlNFAAAAEAAAAfZkYURLAAAAHAAA AgZ6aENOAAAADAAAAiIATABDAEQAIABjAG8AbABvAHIAaQDJAGMAcgBhAG4AIADgACAAYwByAGkA cwB0AGEAdQB4ACAAbABpAHEAdQBpAGQAZQBzACAAYwBvAHUAbABlAHUAcgBGAGEAcgBnAGUALQBM AEMARABMAEMARAAgAGMAbwBsAG8AcgBWAOQAcgBpAC0ATABDAEQATABDAEQAIABjAG8AbABvAHIA aQBkAG9faYJybbJmdphveTpWaDCrMOkw/AAgAEwAQwBEAEsAbABlAHUAcgBlAG4ALQBMAEMARABG AGEAcgBiAC0ATABDAEQEJgQyBDUEQgQ9BD4EOQAgBBYEGgAtBDQEOARBBD8EOwQ1BDnO7LfsACAA TABDAEQAQwBvAGwAbwByACAATABDAEQARgDkAHIAZwAtAEwAQwBEAEwAQwBEAC0AZgBhAHIAdgBl AHMAawDmAHIAbV9pgnIAIABMAEMARAAAbW1vZAAAAAAAAAYQAACcYgAAAADAXf8AAAAAAAAAAAAA AAAAAAAAAHRleHQAAAAAQ29weXJpZ2h0IEFwcGxlIENvbXB1dGVyLCBJbmMuLCAyMDA1AAAAAP/b AEMACAUGBwYFCAcGBwkICAkMFA0MCwsMGBESDhQdGR4eHBkcGyAkLSYgIisiGxwnNigrLzAzMzMf Jjg8NzE7LTIzMf/bAEMBCAkJDAoMFw0NFzEhHCExMTExMTExMTExMTExMTExMTExMTExMTExMTEx MTExMTExMTExMTExMTExMTExMTExMf/AABEIAYoBtQMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAA AAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEU MoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2Rl ZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK 0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUG BwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS 8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4 eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri 4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/APf6KKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiikJA6mgBaKie5jQEswAFQRanaTFhDPHIU+8FYHH1oAuUVX+2Rf3hR9 si/vCgCxRVf7ZF/eFH2yL+8KALFFV/tkX94UfbIv7woAsUVX+2Rf3hR9si/vCgCxRVf7ZF/eFH2y L+8KALFFV/tkX94UfbIv7woAsUVX+1xf3hTluYz0agCaimq6t0NOoAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoopGOFJ oAjmmWJSSa5X+09V8S3EkPh5o7awicxy6nKu8Fh95YU/jI6FidoP94ggR+L7mbULqy0K1leJ9Tm8 qSRDho4VBaUg9jtUqD2LA11tlawWNnDaWcKQW8CCOKNBhUUDAAHpigDBh8D6K2H1WOXWpurSalIZ gT7Rn92v/AVFWJvBnhaZVWbw1o0gT7oexiO36fLW5QTgE+lAHP8A/CCeD/8AoVND/wDBdD/8TR/w gng//oVND/8ABdD/APE1HZ+O/Dt14ek1oalBHBDai6niaRTNAhGRvRSSCegHc8DNWLPxj4dvLm7t 4NYsy9mIzKTMoUB13KQxOCCO4oAj/wCEE8H/APQqaH/4Lof/AImj/hBPB/8A0Kmh/wDguh/+JrXt tRsbuC3ntby3nhuf9RJHKrLLwT8pBw3AJ49KzbXxTp1zNDGnmp5zXO1nAVQkD7JJCc8JuwAe+RQB F/wgng//AKFTQ/8AwXQ//E0f8IJ4P/6FTQ//AAXQ/wDxNaK65pDaYNTXVbFrAnAuhcJ5ROcffzjr 70661O3h0qbUYSLuGJGf9w6nft6gEkLnIxyQKAMz/hBPB/8A0Kmh/wDguh/+Jo/4QTwf/wBCpof/ AILof/ia0m1nS1vfsTalZrdkMfIM6iTCjLHbnPHf0rM0fxtoWp6VDqRvreztbm4e3t3uriJPPZTj 5cMc5xwOG9hQFxf+EE8H/wDQqaH/AOC6H/4mj/hBPB//AEKmh/8Aguh/+Jq7e69p9jqiWF3MsLGA ztLIyrGihgAGJPVvmx/uN6U+XXtHh02LUptWsY7CYgR3TXKCJ89MPnB/OgDP/wCEE8H/APQqaH/4 Lof/AImj/hBPB/8A0Kmh/wDguh/+JrTn1fTLe8trO41G0iursZt4XnVXmH+ypOW/Csibx74ai0o6 j/asDwfams12MGaSYNtKKO5zz9CD05oAk/4QTwf/ANCpof8A4Lof/iaa3gXwzj/R9JisW7PYs1qw /wCBRlTXRUUAcnPpuv6APO0q7l1uzXlrO6Ki4Uf9M5MAN/uvyf73rsaDrdprFkl1Zyb42yOQVZWB wVYHkMCCCDyCK1K4zX4h4f8AFdpqNt8lrrLm3ukHT7Qqbo5MepRHUnvhKAOzoqC0l82IGp6ACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAqO4OImqSmyjchFAHAS3S23xE0WWc4jl862DHoHZNy/nsI+pFeg155460h7qBjE7xSoyyRS p96N1O5WHuCAfwrW8C+NItdjGn6p5dprkIxLb7uJgP8AlpHnqp6kdVPB7EgHW0jDKkD0paKGrgeV f8IJqSeFdKsYNKgjuI/D19Z3Chox/pEqxlQTnnLKxzyM8k1X8UWF1ZatDeTeGi8d/qmmyxQeZAC7 JEwaI/PjepGR/Ccfer12msivjeobacjIzg+tHVev63G3dNev4nC6bp+rWOmale2/htRe3t/cXlla PJDmxYwbFYndtBdlOdhOPNOf4qpa94J1G40O8s7RHYWdtZWlou+PfcRxOssxG7K7nOFw4wSgyMGv SaKP+B+AjyNNLuND1C11nVLK4mW41NpBY6hcWaTTN9m2CQKgSFXGDxuyVyc54q14as9Q1P4QXWl6 dpCxjUbfUWgEU0flRlp38uNeQCpDZDD5cL7ivTbm2gu4TDdQxzxHqkihlP4GpFVUUKgCqBgADAAp p2A4tvC0huZbn+zoTcPryXhlOzcYgoXdnPpkY64zxzXP6f4Y1XRbOFZfC66ss2kPY/ZkkgC28hld ju3MBscOuSuT8nIPFeq0VNtLf1tYFo7/ANb3PJNY0S+0jTdJl1ayXVLwapp9pFCJE3XEUERxgsQu S5lcAkdRnFXLHQtVsddPiCbwvJc29xNeMmlJJAZLXzRAA5DOI8t5LltrEjze/NemsivjeobacjIz g+tOqrvV9/8AJf5Ctt/Xf/M8ij8Ia9pw0+C30qWScW9pHIyyW81mfLkZtkiyYkTy93ytH1444xXU QaJqC+Ddb0tdO8i4kv7mSEB4ws6POZFYEHj5WAw2DlTx0rtaKQ3qFFFFABXGfFC4URaHZqQZ5tRW RR3CIjFm+mdo/wCBCul1vWdP0LT3vtWuo7a3Tjcx5Y9lUdWY9gOTXm1hPe+KvEba3fRPBGF8qztm OTBFkE7scb2IBPphRzjJAPRdDYtbrn0rSqnpkPlQAe1XKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAo6jZLcRkEZzXnni fwglywcIQ6NvR0JVkYdCrDkH3Feo1BNbJKOQKAPJbTX/ABroSiKO9h1OBeAuoRFnA/66KQT9W3Gr 6fE/xBGuJvDFlK3dl1F0H5eSf513NzocMv8AAKpP4ZhJ+4PyoA5T/haeuf8AQp2v/g1b/wCMUf8A C09c/wChTtf/AAat/wDGK6j/AIRiH/nmPyo/4RiH/nmPyoA5f/haeuf9Cna/+DVv/jFH/C09c/6F O1/8Grf/ABiuo/4RiH/nmPyrC8e+H5LXwhqU+n3aWFykWY5jHv5yMKB1y33RjnLDHNAGUvxl1B9S OnJ4as2u1jMjRrqrEquQOf3HHUVa/wCFp65/0Kdr/wCDVv8A4xXKfBP4c6zpupa5c+J7CW3uMpFG 8pDebnLOQ3II+5yO+R1Br1P/AIRiH/nmPyoA5f8A4Wnrn/Qp2v8A4NW/+MVV1H4yajpkKTX3hm0h iZxHvbVHwCemT5HA967L/hGIf+eY/KuZ+J/gl9R8CarBYW7S3SxCWJI0LMxVg2ABySQCMD1oAYvx V1plDL4UtCCMgjVW5/8AIFL/AMLT1z/oU7X/AMGrf/GK5z4LeEddsUv9P8STCI26o0enyLukjVxl XDZxtOGGOeVPQg59L/4RiH/nmPyoA5f/AIWnrn/Qp2v/AINW/wDjFH/C09c/6FO1/wDBq3/xiuo/ 4RiH/nmPyo/4RiH/AJ5j8qAOXHxS1w9PClr/AODRv/jFVp/HXjO/BS1tNM05W/iCvO4+hJUfmDXZ DwxD/cH5VZg8PwofuCgDzux8OX2qagl9rV3cajdDO2S4bOzPUIowqD2UCvQ9D0dLWNflrUt9PihH CiraqFHFAAqhRgUtFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFcyP8AipPEufvaVokuB6XF2P5r GD/32fVKt+KtRuIIYNN0pgNU1JjFbsRkQqPvzEeiA592KjvWhpGnW+k6bb2FkpWC3QKu45J9ST3J OST3JJoAt0UUUAFFFFAHP+K7We3e38QabE0t5pwPmwoObm3OPMj92GA6/wC0oH8Rras7qC+tIbu0 lWa3nQSRyKch1IyCPwqaua0n/intffRX+XT9QZ7jTz2jk+9LB/N1HoXHRaAOlooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACoru5hs7Wa6upVhggQySSOcBFAySfwqWsbX9MuNYu7K0l 2DSo38+6GfmnZSDHHj+7n5m9doHIJoAr+Fbaa7mn8RajE0V1fqFt4XGDbWwOUQjszZ3t7kD+EV0N FFABRRRQAUUUUAFZviLSRrOlvbLKYLhGEttOBkwyqco4+h6juCR0NaVFAGX4a1Y6vpglniEF5C5g u4M58mZfvL7joQe6kHvWpWNLplxbeJ01TT9nk3cfk38RON20fu5V/wBocqfVSP7oFbNABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABUV45jtJnVirLGxDBdxHHXA6/SpaQkKCSQAOSTSaurDR4lpO u30+lS2dr4iubi4nk04SX1nqX2pAZblUdgHXdBIwJzEQVGOBwa6PTrqG38U/Y73xHqsWq2+opa2u nmdpfOtRGMM0Z++GG5mmPIPGeMHtfDWpyaxbT36wpFYyyn7GwB3TRjjzT7Mclf8AZwe+Bq4Gc459 apP+vu/r5ktX/r+vUWiiikMKKKKACiiigAooooA8w1rWprT4k+WdWlkzeW8EdlDfNHLGjIoINqy7 JYyWLmVTuXkZ+XFZunXbRaL4bm8T+KtVs9P1SwmvLm8kvTDm4Aj8uMSDG0BS7BB94rk7ua9g2jdu wMjvjmqmtSXsOmTzaZBHc3US70hkOBLjkqD2JGQD0BIzS6W/r+uo76jPD8jy6Fp8kk007vbRsZZ4 vKkkJUfMyfwk9SOxq/VXStQttW023v7Jy8FwgdCRgj2I7EdCOxBFWqpu7uJBRRRSAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACub8TO+sX0fhm1ZgkyCbUpFODHbZxsz2aQgr/uhz1ArV13VYdG0ua9mVpNmFji T780jHCIvuzEAfWq/hfSptOspJr9ll1O+k+0Xki9C5AAVf8AZUAKPZc9SaANWNEjjWONVREACqow AB0AFOoooAKKKKACiiigAooooAKKKKACiiigDmof+Kc8TGA/LpetSF4vSC7xll9hIAWH+0G7sK6W qWuaXBrOlz2FyWVZQNsiHDRuDlXU9mVgCD6gVU8LapPf2UlvqIVNUsJPs94ijALgAh1H911IYfXH UGgDYooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAopGYKOawLrxz4VtLiW3ufEekQzQuUkje9iVkYHBBBbIIPagDoKK5r/hYPhD/oZ9G/8A A+L/AOKo/wCFg+EP+hn0b/wPi/8AiqAOlormv+Fg+EP+hn0b/wAD4v8A4qj/AIWD4Q/6GfRv/A+L /wCKoA6Wiua/4WD4Q/6GfRv/AAPi/wDiqP8AhYPhD/oZ9G/8D4v/AIqgDpaK5r/hYPhD/oZ9G/8A A+L/AOKrH8UfETw/LbQ6bpXibS4ri/fymu1vYsWseMvJnOA2OFHdiOwNAGvZf8VH4iOoN82l6TI0 VoO09xyskvuE5RfcufQ101UtESwi0mzi0gxGwSFBbmJgyGPA2kEdQRjnvV2gAooooAKKKKACiiig AooooAKKKKACiiigArm/E6No19F4mtlJSBPJ1JFGfMts5349YyS3+6XHUiukqC9ube1tZZrySOK3 jQtK8rBUVQMksTwBjrmgCZHWRFdGDKwyGByCPWlrzvwx448MaNcXOhP4j0prG3AksJ/tsZUQk/6k nd1Q8Ad1K9cGt/8A4WD4Q/6GfRv/AAPi/wDiqAOlormv+Fg+EP8AoZ9G/wDA+L/4qj/hYPhD/oZ9 G/8AA+L/AOKoA6Wiua/4WD4Q/wChn0b/AMD4v/iqP+Fg+EP+hn0b/wAD4v8A4qgDpaK5r/hYPhD/ AKGfRv8AwPi/+Ko/4WD4Q/6GfRv/AAPi/wDiqAOlorn7Xxz4Vu7iK3tvEekTTTOEjjS9iZnYnAAA bJJPat9WDDigBaKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAKGq3HkxMc9 K5vwhrFppHgG61XUZDHbQ3+oO7AZPN7NgD3JIH41seIyRbv9KwvA2l2+tfDl9PvN4imvb35kOGRh eysrKfUEAj3FJgi3D4/sprUyRaZqEk6zrbNbRGCRlkcZjG5ZCmG9Q2Bzuxim3XjSU3WipZ6VeE3l 7NaXcDonmwtHE7FPv7c5UHILArnB5FTN4K3pGZPEGrtOtyly0wFuC7IMINvlbQo5+6Bkk5JqO48B w3EE0cmvav5kl090JgYA8bPG0bhcRYwUYjkEjAIINUvP+tv+CL+vz/4A+68cwW2rvpzaNqrOlx9l MirFtaUoZFVcyZO5RnIGBkZxzizo3i+01i6soLSyvv8ATbc3KO6IFSMMVy/zZU5AGCM89OGw2LQb /RYNWudE1Ga9vbzDw2+olBbxuqhVAMaBgNqqvJPTJ5yS3wV4dfR5NTv7uKOG71S5aZoYpTIlumSR GrEDjczucADdI31KQ2dLRRRQAUUUUAcV8K7syeCNBTP3dPt1/KNa7WvOvhGT/wAIho3/AF5Q/wDo Ar0QdBQAtFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFcV8VLsx+CNeTP3tPuF/ONq7Q9DXnfxcJ/4R DWf+vKb/ANANAHUeLNSvdJXT7qzVpo2ulhmto4g0k4cEKELMoU7sck4xnOOtZt140lN1oqWelXh+ 2Xs1pdQOiebC0cTsU+/tzlQcgsCucHkVt65ozavLYuNTvbH7HMJgtt5WJWHTdvRuMZ4GOv0xjXPg OG4gmSTXdX8yW6e6WYGAPGzxtG4XEWMFHI5BIwCCDRHrf+tv+CD3X9d/+ASah43hsbq5hfRdWkFr cJbSyRpFtEr7fKUZkBO8soBAwNw3becDeI7m5vtENtFJZpcahJY3lpdRKZEZYZJBhlYr1ReQSCGp s3gfzBcqviPWokuLqK62obfEbRbdgXMJ+UbE4Oc7RnOTlR4JP9pRXreI9Zdor03yxt9m2eYUKEf6 nO3YSuM9D6801br/AFt/wfwB+X9f07HVUUUUgCiiigDmfiU/l+FhJ/d1HTz+V5DWvpVx50SnPWsP 4qceDZP+v6x/9K4a0PDhJt0+lAG3RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQBieJP+PdvpWf8Kv+RMj/AOv6+/8ASuatDxJ/x7t9Kz/hV/yJkf8A1/X3/pXNQB1dFFFABRRR QAUUUUAFFFFAHnPwi/5FHRv+vKH/ANAFeijoK86+EX/Io6N/15Q/+gCvRR0FAC0UUyaaKBQ00iRq SFBdgBk9BzQA+oTd24uWtzcReeiq7RbxuCsSFJHXBIIB7kGuO+KOp/Y00q2a8azjuZZCztqR0+Jt qZCtMqs4OTkKvLYOeOK8/N5/belx6hrGoTKY7HSWublJjEV2ahKrl2GCCoBJJAwRngjgWrsO2n9d 7Hu9FeQadrmtz+MikmqxJdjUriGWyN/I7i1UPs/0URbUG0I4lL85HPzBRPoFlqGq2Xh2K88Ra4Rq Ohzajcul4yO0v+jhQGXG1V3HAGM85zlsi1V/62b/AEF1t/XY9YpFZWztYHBwcHoa8N1DxlqD2em6 hJqzwXsNjp8zLLqJgD7wrSulsqETKQTuZyAuDjGM1LPdSaTc3llbambeyuNdvXvpLnV3sgjYDRKZ lVmjDgswwBu2jnsW9G0/61S/UFqv67N/oe3UVgfD+6vL3wdptzqNx9qnkjJ87DDzF3HY3zKhJK7e doz1xzW/Q1Z2EndBRRRSGIehrzr4u/8AIo6z/wBeU3/oBr0U9DXnXxd/5FHWf+vKb/0A0AejUUUU AFFFFABRRRQAUUUUAcp8Vf8AkTJP+v6x/wDSuGtDw3/x7r9Kz/ir/wAiZJ/1/WP/AKVw1oeG/wDj 3X6UAbdFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAGJ4k/492+lZ/wq/5E yP8A6/r7/wBK5q0PEn/Hu30rP+FX/ImR/wDX9ff+lc1AHV0UUUAFFFFABRRRQAUUUUAeV/DbWdM0 nwdoranqFtaBrKHb50oUt8g6A8n8K7IeJ5r0Y0LQ9Qvwek8yfZIfrukwxHuqtXI/BrTLC28NaVc2 9lbxXEtpEzyrGA7koMkt1NenjoKAOf8A7P8AEuo/8hDV4NLiPWHTIg7/AEM0oOfwjU+9TWXhLRbW 5S7e0+2XiHK3V67XMqn1VnJK/wDAcCtuigBCAeoBpcCiigBMDOcDPrS0UUAIQCckDOMUEAjBAINL RQAVz7eELCJi+lXWo6S5Of8AQ7phGP8Atk26P/x2ugooA577J4qsv+PbVLDVEH8F7bmGQ/WSM7f/ ACHR/wAJDqNpxq/hu/iA6zWLLdx/gFxIf++K6GigDi/E3xR8MaBpD301200iOiGzVfLucE4J8t9r YAyeRXN+O/EGl+JPh/q1/ot5Hd27WU2Sp5U7DwwPKn2Ndh8RPA2n+PNLtrDVLm6t4Lefz/8ARioL HaVxlgfWvMfFHw10Hwb4Y1m40hr0zfYZ1ZpbgncPLbqowD+IoA92ooooAKKKKACiiigAooooA5T4 q/8AImSf9f1j/wClcNaHhv8A491+lZ/xV/5EyT/r+sf/AErhrQ8N/wDHuv0oA26KKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAMTxJ/x7t9Kz/hV/yJkf8A1/X3/pXNWh4k/wCP dvpWf8Kv+RMj/wCv6+/9K5qAOrooooAKKKKACiiigAooooA85+EX/Io6N/15Q/8AoAr0UdBXl/wp 1TT7fwxo8E99axTCygJjeZVYfIvYnNemwTRTxh4ZEkX+8jAigCSiiigAooooAKKKKACiiigAoooo AKKKKAEPQ1518Xf+RR1n/rym/wDQDXoc0kcMLyTOscaDLMxwAPUmvJPil4lsNQ8M6tFpPnakptZl aa2TdCnyHJMhwhx6Ak+1AHr1FFFABRRRQAUUUUAFFFFAHKfFX/kTJP8Ar+sf/SuGtDw3/wAe6/Ss /wCKv/ImSf8AX9Y/+lcNaHhv/j3X6UAbdFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UVQ17VYtG017uSN5n3LHDBH9+aRjhUX3JP4ck8CgC/WZqPiLRNMJXUtY0+zYdp7lEP5E1mw+GZtU Uz+LLqS8kfn7DBK8dpCP7u0Y833Z856gL0rX07RtL0xQNN02zswO1vAsf8gKAOU8QeLtMuoGXS1u 9TYjj7JbOyH/ALaECMfi1W/hIzv4Gt2kjMbteXpZCQdp+1zZGR1rT8Sf8e7fSs/4Vf8AImR/9f19 /wClc1AHV0UUUAFFFFABRRRQAUUUUAfPP/CtoPGvw/0i5sSsGswWEPlSHhZgEHyN/Q9vpXafCnw9 r/w88KRR3emJfreN9puktm/0m3cgDbtJ2yAAD7pBBzgN1q58Iv8AkUdG/wCvKH/0AV6KOgoApaPr Gn6zA02m3KzBDtkTBV4m/uuhwyn2IBq9WTrHh2w1SdbsiW01BBtjvbV/LmUemejL/ssCvtVH7fr+ ifLqtp/bNmv/AC+WCYnUerwfxfWMkn+4KAOkoqjpGtabrMTSaZew3IQ4dUb5oz6Mp5U+xANXqACi iigAoopssiQxtJK6xogyzMcAD1JoAdRXPP4wsbhzFoMFxrsoOP8AQVDRKfeZiIx9NxPtSfYfEmrf 8hG/i0a3PW30795MR6GZxgf8BQH0agDS1jXNM0ZUOpXkcLycRxctJKfREGWY+wBrM/tHxDq3Glac mlW5/wCXrUxukI9VgU5/77ZSP7prR0fw/pejs8lhaKs8n+suJGMk0v8AvSMSzfia0qAOej8I2U0i z67NPrlwp3A3xDRIfVYQBGPY7c+5rmfi2oXwfrCqAALKYADoPkNejHoa86+Lv/Io6z/15Tf+gGgD 0aiiigAooooAKKKKACiiigDkvi0zJ4HndIzIy3lkQgIBY/a4eOeKp+H/ABho9tAq6nNLpbAc/boW hUf8DI2H6hiKvfFX/kTJP+v6x/8ASuGtDw3/AMe6/SgC3p+u6RqRA07VbG8J6eRcJJn8jWhWfqGg 6PqQI1HSbG7z18+3R/5isqfwxLpqGfwndyWEyci0mleS0l/2ShJ8vP8AeTGOuG6EA6WiqGg6rHrO mR3iRPA5LRywP96GRSVdD7ggj3696v0AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFc9qA+3eOdMt m5i061lvSv8A01YiOM/gvnfnXQ1j2llcL4x1K/kjxbS2NrBE+RyyvOzjHUffT/OaANiiiigDE8Sf 8e7fSs/4Vf8AImR/9f19/wClc1aHiT/j3b6Vn/Cr/kTI/wDr+vv/AErmoA6uiiigAooooAKKKKAC iiigDzn4Rf8AIo6N/wBeUP8A6AK9FHQV518Iv+RR0b/ryh/9AFeijoKAFooooAy9W8O6Vq0qz3lo PtSDCXULtDOg9FkQhgPbNUPGOpXPhfwTdXdhvuri2RI43nIc5ZlTexJAON2TkjpyR1ro6ZPDFcQv DcRpLFIpV0dQysDwQQeopPYa3PMLfxB4qe9i0V7+S1mk1OC3+03cVq9ysbwSyMrJC7ID+7BUkDhh kHHNe+1jxBaytey65I8+mabrI2iJAlw0EiBHdcY3YKk4wMqcYBIPpOn6Bo2mwRw6fpNjaxRS+dGk NuiBJMFd4AHDYJGeuDinXOh6TdbftOl2U20yMPMt0bBkBEh5H8QJDeueaHvdf1p/w4K2l/63/wCA cNqWv+I9BMGnXepJfX2tWsY06b7KqBLkyhZBtHVVSVGAJJxG2T1r0K5tYLu2Nvewx3MTY3JKgZWw cgkHjqAaoXehRXeu2GpTzOY9OVvs9qFUIkjAqZM4znaSoGcc9M1q1RIiqqKFRQqqMAAYAFLRRSGF FFFACHoa86+Lv/Io6z/15Tf+gGvRT0NedfF3/kUdZ/68pv8A0A0AejUUUUAFFFFABRRRQAUUUUAc p8Vf+RMk/wCv6x/9K4a0PDf/AB7r9Kz/AIq/8iZJ/wBf1j/6Vw1oeGwTbKcdBQBt0UUUAc/4fHke J/ElqvCNNBdAeheIKcfUxZ+pNdBWLpNpPH4m1y7liZIpvIjiY9HCoSSPxYj8K2qACiiigAooooAK KKKACiiigAooooAK88+JfifVtJurwaLc3AOm6f8AbJYoYICgJZgpmeVgdh2EbYxv4PPIFeh1nalo Gjarcx3Op6TY3s8SlEkuLdJGVT1AJHA5NHUZy/jf+0ZLzRTa6+1qkmr2wMMCKCimN8qxJO4MRnBH 51g3/jbxAulXkcN5BBe6FA0epzSQjaZzcCOJiOgUoryEDHDLXo7aDo7wGBtKsWhPlkxm3QqfLACc Y/hAGPTHFcvP4ctri41Tw3fzzXEutoNQub1lQF9jxoI9m3btCqg98nuc0d1/XRf5sXb5fqzH1rxP 4i0rVpPD9tfSapJLdW6JewwQLPEJY5naMBisRceSNpbs4yGOM9f4B1PUdU0FpdXC/aYbmaAtujLM qOQC4jZkD4GGAOAQenSrcfhfw/Hpculx6HpqafM/mSWq2qCJ24+YrjBPA59hWhZWltYWsdrY28Vt bxDbHFCgREHoAOBTEUdbhMsLADtXmMsPibREkttE1+9trUzSyrCILdwhkdnbBaItjcx6k16/JGHG DVCfSYpSSVFIZ5L/AGv48/6Ga8/8BLX/AONUf2v48/6Ga8/8BLX/AONV6n/YUP8AdFH9hQ/3RQB5 Z/a/jz/oZrz/AMBLX/41R/a/jz/oZrz/AMBLX/41Xqf9hQ/3RR/YUP8AdFAHkWq+IvHthp092fEt 2VgXe2bS1+6Op/1XpmrX9r+PP+hmvP8AwEtf/jVelar4YgvtMu7MquLiF4uf9pSP61U8J2EWp+F9 JvnUb7mzikYHqGKAkfnmgDgP7X8ef9DNef8AgJa//Gqs2WoeOJnAl8T3wHta2n/xmvSv7Ch/uipI 9GiQ5CigDH8EaSuk6TaWURcx20SRKX5YhQAM+/FdaOlQwW6xDAFTUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAB6VyXjfSV1bSbuylLiO5ieJinDAMCDj35rrahnt1lGCKAPIr3UPHELkReJ74j3tbT/ AOM1W/tfx5/0M15/4CWv/wAar1eTRonOSoqP+wof7ooA8s/tfx5/0M15/wCAlr/8aqrqfiLx7Y2n n/8ACS3Z/eRpzaWv8Tqv/PL3r13+wof7orG8baAjeENXaFR5sVrJLH/voNy/qooA4X+1/Hn/AEM1 5/4CWv8A8ao/tfx5/wBDNef+Alr/APGq9PttIt7i3injUbJUDrx2IzUn9hQ/3RQB5Z/a/jz/AKGa 8/8AAS1/+NUf2v48/wChmvP/AAEtf/jVep/2FD/dFH9hQ/3RQB5tFD4m1tI7bW9fvbm1E0UrQmC3 QOY3V1yViDY3KOhFeoaFEYbbB9qINJiiOQoq/FGI1wKAPO7jxVq8fjW3WG4uJdMm1U6bsaCCO34Q 7gpLec0gYHkDZjjHeneIG8Qw+I1k0rX2urhdJvpobdIUEMjpPHtQjn5sMEJzn5SRjJFdi/hrQpNQ fUH0XT2vZHV3uDbIZGZSCpLYzkEAg+wqtr9hpmn6PdalHb21lNp9vcTxXcdtGZLYsC0jpkYyeSfU 9c0LRff+Vvz1H18v+CcnH4r1PxDdWU+j6slhpOq6iLO1nEKOxRbZ5HZdwI3GQFBkEDZ0OcHKl8a+ J7oGztZpC9hBdTSX1rFbBbnyp5IldxNIqiPEeX2HOW4Kjr2Vr4J0i78O+H9PvrQS2umgTG1ukSUS u0bKfMBGCcuWyAPmFbF34Z0G8tbW1u9F06e3sxi3iktUZIR6KCML0HSm99BLbUsaJdS32jWN5cIk c1xbxyusbBlVmUEgEdRk9auUAYGBwKKG7u6EtEFFFFIYUUUUAFFFFABRRRQAUUUUAFc/qf7rx3oc vQS2V5bn3JaBx+kbV0Fc/wCKv3WreGrrtHqRjY/7LwTL/wChFKAOgooooAKKKKACiiigAooooAK5 /wABfu9BktD1sr26twPRVnfZ/wCOba6Cuf8ADP7jXfEtp2F6lwg/2ZII8/8Aj6PQB0FFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABWL44uDa+DdalUZcWUqxr/ecqQo/EkD8a 2q53xMf7R1jSNDTlWmF/de0UJBUH6ymP6hW9KANyxtxa2UFuDkQxqmfXAxU1FFABRRRQAUUUUAFc 947/AH+jwaYOW1S8htCPVC4aUf8AfpJK6Guevv8ATvHenW/WPTLSS7f2kkPlRn/vkT0AdDRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAVz/j393oMd0OtpfWk+fRVuI93/ju6ugrF8cWzXfgzW4I/ 9Y9jN5fs2wlT+eKANqiobG5W8sbe6j+5PGsi/QjP9amoAKKKKACiiigAooooAK5+P/RviFMOg1DS 0YD1MErAn8p1/SugrE1y1nOv6Df20TSCGaWCcqPuxSRk5+m9IqANuiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKqatqEel6dNezRTzLEB+7gjMkjkkAAKOpyR/XAoAt0Vh6Z4ng1GFylh fwzw3YtJ7eSIM8DlA4LlCy7drKdwJHI71haZ8R7U6DYXmpWtxJM1hFe6g9lDuiskfOGfLZx8rcDc QASRjmgDt5ZEhieWV1SNFLMzHAUDqSawPB0b3ou/ENyjLLqrKYFYYMdqufKXHYkFnI7GQjtVe68W aTe30uj3enXk1pJcGxmuHgBtTIV3bGOckMD1wR2JGaoX/wAS7GHSLm7sNK1KYrYzXtn5kIjju4ow MurE5C/MDyAcc4PGTpcPI7iiuItPiAV1m/tNT0q+ht4Lm2hWdYRtt/OjjKiU7z8299vyA4yM8c12 9ABRRRQAUUUUAFc94V/0zU9e1Y8ie8+yxH/pnANhH/f3zvzrV1vUY9I0a+1KYZjs4HmYeoVScfpV bwnp0mleG9Pspzm4jgXz2/vSnlz+LFj+NAGrRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU2R FljaNxlXBUj1Bp1RXVzBZ20lzdzR28ESl5JZXCoijqSTwBQBjfD52fwRoyyHMkNokDn1aMbD+qmt 6uL+HHiTRLyK50ix1WzubmK9vJI44pg5aI3DurDHUbXWu0oAKKKKACiiigArhPGHja+0TXWt7RLa e2tjAJ4ltp5pG8xwDmVR5cOAQRvzu9utd3WBrPgvQtau57nULed3uAvmql3NGjlfusUVgpZeMNjI wMHgUdUHQy/GWu3/AIeuY9RuwrWlsLqdIbeRgZ40t9wD543bw2Ooxg9ayYfHniD7PNG+mQyXLPaL BLJZ3VpDmaYRGM+aoYlcg714Oegxiu1n8O6VcSyyXFr55mZ2cSyM6tvjEbDaTjBQAYxjqepJqpY+ DNCslIjtppWLwv5lxdSzOPKbfEAzsSFVuQuce1NWur7af8ET2MGz8V+IbnVD4eWLSzrEV1Mkt1sk FuYo44ZMhNxbcfPRcbsDBPPAOJ4h8UeJLrSHu0ureyjl8O39y8Nvu3pNE6KGWTPYsMHA/i9Rjd1z QbfWNbvbXToIbW/t51vJ2mkmRrhZIhGJEkidXQfuipUcHZyOQa0tO8BaRDoen6dqEZujZWclnvSS SFXjkx5i7Vb7pwMA5IwOcjNEWrpv+tP8xv8Ar7ybwzq2rza3qWka6lkbi1hguUezDhdkpcbDuJJZ TGfmGAQRwK6OqsWnWsWpT6jHFi7uIkhkk3H5kQsVGM4GC7dPX6VaoYkFFFFIYUUUUAFFFFABRRRQ AUUUUAFFFFABWR4u0V/EOgz6alyLYysjbmTejBXDFHUEbkbG1hkZBNa9FDVwOT8K+Ebzw6l1Ha3+ nww3d2lzJDaaaII1AjCOiqHIAO1SD1Bzndnjnrz4W2cFpbeff6W0cVlBZT3GoaZHMyiMkB4S7YjY 7schxnbxxz6bXNXH/FReJ1th82maLIskx7TXWMonuIwQ5/2in900ASP4WVoHhF1hG1EX2BHjAAA2 dfbr+lcTo3hjXtVkh0vUWurbTbPRbnTY3uLREeIybEUFlkYTMFTJYBV4HcnHq9FHS39bW/IFo7r+ tbnJv4Nmns9RjutSR59QvLS7kkjttqq0AhyAu88MYfXjd3xz1lFFABRRRQAUUUjMFUsxAAGST2oA 5/xr/pUOmaSOf7Sv4o3H/TOPMz59isRX/gVdDXF6T4j0XxR46t30rVLS7i0/T2ZBHKCWkmfBwOuV WE59BJ712lABRRRQAUUUUAFFFFABRRTJW2oTQA4sB1NJ5ietcXqcaa54407Tbm4vY7VdPu5mjtb2 a23OslsqkmNlJwHbr6mtP/hCNH/57a1/4PL3/wCO0AdD5ietHmJ61z3/AAhGj/8APbWv/B5e/wDx 2j/hCNH/AOe2tf8Ag8vf/jtAHQ+YnrR5ietc9/whGj/89ta/8Hl7/wDHaP8AhCNH/wCe2tf+Dy9/ +O0AdD5ietV9Qt7XUbC4sbxFlt7mNopUPRlYYI/I1jf8IRo//PbWv/B5e/8Ax2j/AIQjR/8AntrX /g8vf/jtAHm3wI8CT+FPG3iiS+V/9D22ltKwwJkY79w/BU/MivavMT1rnv8AhCNH/wCe2tf+Dy9/ +O0f8IRo/wDz21r/AMHl7/8AHaAOh8xPWjzE9a57/hCNH/57a1/4PL3/AOO0f8IRo/8Az21r/wAH l7/8doA6HzE9aPMT1rnv+EI0f/ntrX/g8vf/AI7R/wAIRo//AD21r/weXv8A8doA6HzE9aPMT1rn v+EI0f8A57a1/wCDy9/+O0f8IRo//PbWv/B5e/8Ax2gDogwPQ0tcVpkaaH431HTba4vZLVtPtJlj ur2a52u0lyrEGRmIyEXp6CuyibcgNAGB4tjk0+a18R2qM76aGW6RBlpbVseYAO5UhXH+6QPvVvwy xzwpNC6yRyKGR1OQwPIIPpTzz1rmfD5/4R/Vn8OTfLaS7p9KY9PL6vB9UJyo/uEY+6aAOmooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKRiFUsxAA5JPagDJ8UapNptgkdgqy6leyC3s426GQgn cf8AZUAu3sp74qzoWlw6NpUNjAzSeWCXlf70rscu7f7TMST7msjw0DrmpS+JpgfIdDBpin+GDOWl +shAP+6qeprpaACiiigAppdR1NRXcvlITXG6HpVt4j1bxFcahdaofI1FYIlg1S5gREFrA2Akcir9 5mPTvQB2/mJ60eYnrXPf8IRo/wDz21r/AMHl7/8AHaP+EI0f/ntrX/g8vf8A47QB0PmJ60nmIepF c/8A8IRo/wDz21r/AMHl7/8AHaP+EI0f/ntrX/g8vf8A47QB5R8Bvhr9g8Q3/iHWIiFsriW309HH 3irFWlx6DoPfJ7CvePMT1rnv+EI0f/ntrX/g8vf/AI7R/wAIRo//AD21r/weXv8A8doA6HzE9aPM X1rnv+EI0f8A57a1/wCDy9/+O0v/AAhGkf8APfWv/B5e/wDx2gDoQQehpa5HwDdsNNuLV555vs2o XsCNPM0r7EupVQF2JY4UAck9K64cigAooooAKgvTiBqnqvff6hvpQBxGjOW+KFsD20q7/wDR1rXT +IfECaIYlOnahfvIjyFbSJW8tFxuZmZlUdRxncewODXLaH/yVGD/ALBV3/6Ota1PHHgtvFF9az/a rNYoYJIWgvbEXSDeV/eIpYKsg2kBiGHJ4pO/Qat1Fn+IekRySGO3v57WCOGa4u44MxQRyruR2JIO MHnAJHUgDmnx+OtPlv2tUtL9E+0y2SXkkIEDXCbsxg5zztODjaemc8VzWneBdfaTVtHn1WKHSJ7a 0s5n+xZa6jSIK5jPmfuyQNp3BvUVpaH4T1idmXUtQWDTotWu72KyFtiQkyyeXmQPgodwfG0HJAz2 py62Ettd/wDgf5kmiePvN0eyutRga4vL23tDDZ2MB3ySyxGQqpZsYwrHJICgHJNXbrx9YW1gl62m au0KxPNcn7MF+xojFH8zcw5BVuE3HAyARg1StPh/cafa6cdP1hEvtMS2EEstrujJiheFtyBwSGV2 4DAg45NVNf8Ahpd66CdT1q1vpZrRreSW804TNCxd2L243gRH5wvRjhF5yM05Nc2m1xR21NIeNmbW riymtHsYbbVFsvOnTcs6m2MxKkN8h4zkgjbjucK9PiHpX2WW5ubLU7SIWrXsBmtwPtUAKgvGAT/e X5W2thhxUdx4Flvrx5NR1OOWCW6S7kijtShLi0Ns4DbzhWBDDgkYIyc5ES+Bb+5ijj1fXI7r7JZG ys2js/LKIWQs8nzne5EaDjaOvHPCXb+tv8xsu3XjHzNIv3s7G5tdSgmito7a/h2kyTMqxMQrHKHd k4OQAc4IqLUfH0FrDfbdJ1LzYba4ntfOiEaXvkj5wnJYc/3lGRyM1oT+GfP8TJqz3h8tZUm+ziPq 6Rui5bPQeYTjHUD0rmbL4Xvb3v2h9SssmK5gkli07bcXCTKQWllLku4JBBwBweOQQnezsONrq5qw /EKy+yQT3Om6jGohhlvpEiDR2BkAKiQ7s9CCdobAILYBp0vxCsFu2todK1i5b7VLZRNFbDbPPHnd GhLDsrHccLgHJBBFUv8AhAtS+yXNj/bsAstTihj1FFsSHk2IsZ8tjIdgZFVSCGxyRjNalp4QFtPY SC+3fYtVutSx5WN/nCUbOvGPN699vQZ4t2uSr8vn/wAD/M0bXxHY3Ok6fqSCZYb+RIo1eMh1djja w7YIINVLjxnpdvr50KVbgamZkjS28sbpUZS3mrzzGAGy3YqR1wDnXfw20O/tLGPUrSzvLi0mDtcS 2oZpI/MZ/L5PA+YjqfpTv+EF8vxFBrVnqbW01nsgtII4cQQ2YXDW+wNg7jlt/UELxhcGV/X9f1+V zUhi+JumzQRTQaPrkqT27XUG20GZYUIDuMt0XI64zkbd2RWz4a119Z1DWIwI/s1nNEtu6qQXR4I5 Mtnvlz6cYqhpvgn7Db6VF/aHmf2dpM2mZ8nHmeYY/n+9xjy+nPXrxWh4X8O/2A1632r7R9raFv8A V7dvlwRxepzny8/jj3oX9fe/0sN76f1t/wAE53WHK/FC5A76Taf+jrmu3sjmBa4bW/8AkqFx/wBg m0/9HXNdxY/6hfpQBYrN8RaQus6cYBKbe4icTW1woy0Eq/dcevoR3BIPBrSooAyvDertqtk4uohb 6haP5F5bg58qQDPHqpBDKe4IrVrz74qeJ7DwFc2XiIsTez5t5LQAj7bEOfvYIVkLbgT2LDvxrfC3 xj/wnPhKPWHgS3m86SKWJGLBCDwMn/ZKn8aAOrooooAKKKKACiiigAooooAKKKKACiiigArm/FDt rF7D4ZtmIS4TztRdTgx22cbM9jIQV/3Q56gVkfF/4gv8PtM027htIrx7q62PC7FSYwpLbSOhzt5I I56VY+Emr2niPw1Lr8Jla71C4Z7tpIyu1wABGpPVEXaoI4OCTglhQB2KIsaKkahUUYVVGAB6CnUU UAFFFFAGdrTYgbHpXPfDFix8Sk/9Bf8A9tbet/XP+PdvpXPfC/8A5mX/ALC//trb0AdJ4j1J9H0D UNSjt2uns7d5hCpwXKqTj9K5+L4hWS2ttNdadqMYMEM166xBo7DzANokOc98/KGwMFsCum1ayXUt Lu7F3Ma3ULwlwMlQykZ/WuEn+FouLlJ57rSppJY4EupptISWXMQC5hZ3Pl7lUAgh8HJGM0LfXy/W /wCgPbTz/S36mpqXxE063j1GCytbu61TT47h5bEIA8YiXO5+eEbK7W53buAcHFLWPH17a2ulXVvp 21JoLae9gkQvNEJ5440VQp5YjziOvKirX/CBSnVNR1J9bma61aOeC+zF8kkLKREiLuwhjGMNzuy2 fvcTWfgqZLDyr7U0uLn7VZTGZLbYAlsYysYUueCUY5zwZDxTja6v5frf9Afl5/pb9Ro8erJfabbQ 6LqKNcXstndpMqK9myRGT5gGIOV2sMEjaSc5GDAvxQ0trYXK6TrZhNr9uV/soAa2/imGW+6vcfeP UAgg1bufBsr6w2o2+pJG76ob8o9vuG02ot2j+8OcZYN2PY0jeCAdAXSxqBAXQjo/meT6qF8zG72+ 7+tDtb+uz/WyDr/Xf/I0/Dmsy6tfa3FIsYisL1YIWQEFkMEUmWyeuZD6cYrarI8O6H/Ys2pyfafP +33Kz42bdmIY48dTn/V5zx1x2zWvQ7dBK/U898CuftGqL2GrX/8A6VS16An3BXnngX/j71X/ALC1 /wD+lUtehx/cFIY6iiigAqC9GYGqemSrvQigDzSXVrTw94+ttR1T7QlodPuYfMhtZZ8O0luQCI1Y jIRuvpW2fir4PBwb+8H/AHC7r/43VnWtDF3nIzmubk8GIzE7P0oA2/8Aha3g7/oIXf8A4LLr/wCN 0f8AC1vB3/QQu/8AwWXX/wAbrC/4QpP7n6Uf8IUn9z9KAN3/AIWt4O/6CF3/AOCy6/8AjdH/AAtb wd/0ELv/AMFl1/8AG6wv+EKT+5+lH/CFJ/c/SgDd/wCFreDv+ghd/wDgsuv/AI3R/wALW8Hf9BC7 /wDBZdf/ABusL/hCk/ufpR/whSf3P0oA3f8Aha3g7/oIXf8A4LLr/wCN0f8AC1vB3/QQu/8AwWXX /wAbrC/4QpP7n6Uf8IUn9z9KAN3/AIWt4O/6CF3/AOCy6/8AjdH/AAtbwd/0ELv/AMFl1/8AG6wv +EKT+5+lH/CFJ/c/SgDd/wCFreDv+ghd/wDgsuv/AI3R/wALW8Hf9BC7/wDBZdf/ABusL/hCk/uf pR/whSf3P0oA3f8Aha3g7/oIXf8A4LLr/wCN0D4q+DycC/vD/wBwu6/+N1hf8IUn9z9KdH4MRWB2 fpQAsOrWniHx9dajpf2h7QafbQ+ZNaywZdZLhiAJFUnAdenrXolqQluM+lc/omhi0xgYravm8i2O OwoAzLvxlp1vfXNmsWpXEtq4jm+y6Zc3CoxVXALJGVztZTjPcVF/wmtn/wBA/Xf/AAR3v/xqoPh3 KZrjxPIe+rD/ANJLauuoA4nXNd0LX9Nl07WNE1i8tJhho5NCvT+IPlZB9CORXPfDiOw8CLqlnYrr 9xpt3Os9vDJoN7vhO3DAt5WGzhcHA6V6vVe6v7O0ZVuruCBmGQJJApI/GgDA/wCE1s/+gfrv/gjv f/jVH/Ca2f8A0D9d/wDBHe//ABqt06lYCW3iN7bCS5GYE81cyj/ZGefwp63to141mt1C10i72gEg 3qvqV64oA5//AITWz/6B+u/+CO9/+NUf8JrZ/wDQP13/AMEd7/8AGq6eigDmR41su9hro/7gd7/8 ara0rU7bVdPtr6yk822uolmifBG5GAIODyOCOtXK4X4U3JfwVoa5+7p8A/KNaAOu1XU7bStPub69 k8q2tYmmlfBO1FBJOByeAelYp8a2Xaw10/8AcDvf/jVZfxWuSngrXFz96wnH/kNq7qgDmP8AhNbP /oH67/4I73/41R/wmtn/ANA/Xf8AwR3v/wAarp6KAOY/4TWz/wCgfrv/AII73/41R/wmtn/0D9d/ 8Ed7/wDGq6Bb60e8azS6ga6RdzQCQF1HqV64psGo2NzHNJb3lvMluSsrJKrCMjqGIPGPegDy/wAe WWi+ONZ0e41m28QNYaaJSbRNCvVMzMU6t5fA+XnHPuK6yz8WaXZWsVrZ6TrMFvCoSOKPQbxVRR0A Ai4FdRaXVveQLPZzxXEL/dkicMp+hHFS0Acx/wAJrZ/9A/Xf/BHe/wDxqlXxvpokiWeDVrcSypCr 3GkXcSb3YKoLtGFGWYDkjrXTVy/xNfy/Ce/+7qFgf/JyGgDpo3DjIp1ZmjTmWFST2rToAztaXNu2 PSuC8K+K9I8L3Wv2+tvd27z6iJoylhPKrp9ngXIZEI+8rDr2r0e7i82MiuP1jw2t05JXrQBJ/wAL W8H/APQQu/8AwWXX/wAbo/4Wt4O/6CF3/wCCy6/+N1hHwWmfufpR/wAIUn9z9KAN3/ha3g7/AKCF 3/4LLr/43R/wtbwd/wBBC7/8Fl1/8brC/wCEKT+5+lH/AAhSf3P0oA3f+FreDv8AoIXf/gsuv/jd H/C1vB3/AEELv/wWXX/xusL/AIQpP7n6Uf8ACFJ/c/SgDd/4Wt4O/wCghd/+Cy6/+N0q/FPwi5wl 9eMfbS7s/wDtOsH/AIQpP7n6VPa+DkjkB2fpQA/4enzxe3SJKsdzqN5PH5sbRsUe4kZSVYAjKkHk d69ET7grG0bTBaoABitocCgBaKKKACiiigBCqnqKb5Sf3RT6KAGeUn90UeUn90U+igBnlJ/dFHlJ /dFPooAZ5Sf3RR5Sf3RT6KAGeUn90UeUn90U+igBnlJ/dFHlJ/dFPooAZ5Sf3RR5Sf3RT6KAGeUn 90UeUn90U+igBAqjoKzdb/492+ladZmuf8e7fSgDnvhf/wAzL/2F/wD21t67SuL+F/8AzMv/AGF/ /bW3rtKACuS+I9tBe2ljpotbeS91a5FjHPJCrtBGVZ5WUkHBEaPj/axXW0Ueo72PIvEltpOmSeJt HMEMGpypaRaFCE/eFFRREIe/yzByccjqccGpNJeyfVtOsUER8Sw+JLqe6UL/AKQkBM3zueuwxNGo J+U5UDoMesFQSCQCR0PpRtG7dgZ6ZoXT+u3+Woull/WlhaKKKACvOfhGf+KQ0f8A68of/QBXo1ec /CMf8Uho/wD15Q/+gCgA+LZ/4pDWP+vKb/0A16NXnPxbH/FIax/15Tf+gGvRqACiiigDwmFLyNZr fT7q1vPEMt1qm7TxbIt3ZsyTlZ/MHzgnMa5b5SHQDoCbery6JdwW03hpIn0e00+zTVhbx/u1jF1C dkoHJKxifcpyQpOQM8+1YGc4GfWgKBnAAzyeOtC0d/66/wCY5e9/Xnc5HwDJZ3OreJLzRTC+kz3c Zgkt8eTK4hQSMhHBGQASO6muvpFAUYUAAdhS0CCuU+Kv/ImSf9f1j/6Vw11dcp8Vf+RMk/6/rH/0 rhoA0PDf/Huv0rbrE8N/8e6fStugAppRT1FOooAZ5Sf3RR5Sf3RT6KAGeUn90UeUn90U+igBnlJ/ dFHlJ/dFPooAZ5Sf3RR5af3RT6KAEAA6CloooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACqWpxGSEgelXaa6hhg0AeVX1hr2k3l7JoWtXljHeTCeSJIYHXfsVMjfGx+6i8 ZqgdQ8d5/wCRmvf/AAEtf/jNeszadHKckCoP7Gh/uigDy3+0fHf/AEM15/4CWv8A8ao/tHx3/wBD Nef+Alr/APGq9S/saH+6KP7Gh/uigDy3+0fHf/QzXn/gJa//ABqj+0fHf/QzXn/gJa//ABqvUv7G h/uij+xof7ooA8t/tHx3/wBDNef+Alr/APGqP7R8d/8AQzXn/gJa/wDxqvUv7Gh/uij+xof7ooA8 2s7rxvK4Evii+A9rW0/+M12XgrR10jSbWyiLmO2hWJS/LEKABn34raj0mFDkKKuQwrGMAUAcx410 ddX0m7spS4juYXiYpwwDAg49+a468uvG8TkReKL4j3tbT/4zXrE0KyDBFU5NJhc5KigDyr+0fHf/ AEM15/4CWv8A8ao/tHx3/wBDNef+Alr/APGq9S/saH+6KP7Gh/uigDy3+0fHf/QzXn/gJa//ABqj +0fHf/QzXn/gJa//ABqvUv7Gh/uij+xof7ooA8t/tHx3/wBDNef+Alr/APGqP7R8d/8AQzXn/gJa /wDxqvUv7Gh/uij+xof7ooA8t/tDx3/0M15/4CWv/wAZqzHaeJdaSO21rX766tRNFM0JgtkDmN1d clYg2NyjoRXpP9jQ/wB0VLFpkUZyFFAEejQGKFQfStOmxoEGBTqACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooA//9k= --Apple-Mail-57-550558534 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed or in N3 [] :alternate [ a :Content; a:type "text/html"; a:length 600; :src ; ] . [] :entry [ a :Content; a:type "application/atom+xml"; a:length 700; :src ; ] . This way of doing things is looking at representations as linking to each other, and that is probably what a lot of people dealing with representations are thinking. I like it, but I am also finding it very difficult to decide the issue. The other way of seeing things is to apply the properties to the resources. If we look at this from a web architectural point of view with a URI "http://eg.info/post1" naming a resource (the circle below) which returns two representations, one in html and one in xml we get the following diagram. --Apple-Mail-57-550558534 Content-Transfer-Encoding: base64 Content-Type: image/jpeg; x-mac-type=4A504547; x-unix-mode=0644; x-mac-hide-extension=yes; name=content-2.jpg Content-Disposition: inline; filename=content-2.jpg /9j/4AAQSkZJRgABAQAAAQABAAD/7QAcUGhvdG9zaG9wIDMuMAA4QklNBAQAAAAAAAD/4hEoSUND X1BST0ZJTEUAAQEAABEYYXBwbAIAAABtbnRyUkdCIFhZWiAH1gALABsAEgAaABVhY3NwQVBQTAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA9tYAAQAAAADTLWFwcGzHJ3uyX5VB5P5gBasG81a+AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5yWFlaAAABLAAAABRnWFlaAAABQAAAABRiWFla AAABVAAAABR3dHB0AAABaAAAABRjaGFkAAABfAAAACxyVFJDAAABqAAAAA5nVFJDAAABuAAAAA5i VFJDAAAByAAAAA52Y2d0AAAB2AAABhJuZGluAAAH7AAABj5kZXNjAAAOLAAAAGRkc2NtAAAOkAAA Ai5tbW9kAAAQwAAAAChjcHJ0AAAQ6AAAAC1YWVogAAAAAAAAXzEAADdZAAAGa1hZWiAAAAAAAABx RwAAsQsAACEOWFlaIAAAAAAAACZeAAAXtwAAq6xYWVogAAAAAAAA81IAAQAAAAEWz3NmMzIAAAAA AAEMQgAABd7///MmAAAHkgAA/ZH///ui///9owAAA9wAAMBsY3VydgAAAAAAAAABAc0AAGN1cnYA AAAAAAAAAQHNAABjdXJ2AAAAAAAAAAEBzQAAdmNndAAAAAAAAAAAAAMBAAACAAAAGwBeAMMBXwIq Au8D2ATmBhQHagjcCmsMFQ3SD5oRbxNFFRwW5RipGmAcCh2eHysgoiIRI28kxiYWJ1sonCnbKxYs Ui2ILr8v9DEnMlozjDS9New3GjhHOXA6mTvBPOg+Dz80QFhBekKdQ8BE4UYERydISEloSopLrEzN Te5PDlAuUU9SblONVK1VzVbtWA1ZLVpNW21cjV2uXs9f8GERYjJjU2R0ZZVmt2fZaPtqHmtAbGNt hW6pb81w8XIVczp0XXWAdqN3xHjmegd7J3xGfWR+gX+dgLeB0ILng/6FE4YmhziISYlYimeLdIyA jY2Omo+nkLWRw5LSk+OU9JYHlxqYLZlAmlObZZx2nYWekp+eoKehrqK0o7akuKW4prantKiwqauq pKucrJOtiK5+r3GwY7FUskOzMbQftQu19rbgt8q4srmZuoC7ZrxLvS++Er70v9XAtcGVwnPDUcQv xQzF6cbGx6LIf8lbyjfLE8vvzMvNps6Cz1zQNtEQ0enSwdOX1GvVP9YR1uLXr9h72UbaDtrV25jc Wt0a3drelt9R4AzgxeF84jPi6uOf5FTlCeW+5nLnJ+fb6I/pROn56q7rY+wY7M7thO467vHvqPBf 8RbxzfKE8zzz8/Sq9WH2GfbQ94f4Pvj0+ar6YPsV+8r8f/00/ej+m/9O//8AAAAaAFsAvQFPAhcC 1QOvBK4F2AchCIUKBAueDUgPAhDJEo8UVRYaF88ZehsdHKYeKh+ZIQIiXCOqJPUmNydwKKcp2SsL LDctYi6NL7Qw2DH8Mx80PzVcNnk3lDisOcI61zvpPPo+CT8UQCBBKUIxQzdEPUVDRklHTkhTSVpK YktqTHVNgE6OT5xQrFG8Us5T4VT0VghXHFgwWUVaWltvXINdl16tX8Jg12HsYwBkFWUpZj9nVGho aX1qkWumbLltzm7gb/NxBXIWcyZ0NHVCdk53WnhkeW16dnt/fId9kX6cf6eAs4HAgs6D3YTthf2H DogfiTCKQYtSjGGNcI6Aj46QnJGqkrmTx5TUleCW7Jf3mQCaB5sMnBCdEZ4PnwygBqD/ofai7KPg pNSlyKa6p62ooKmRqoOrdaxlrVauR683sCixGrILsv6z8rTntdy207fLuMS5vbq2u6+8p72evpS/ iMB7wWzCW8NHxDPFHcYFxu3H08i6yaHKh8tuzFbNPs4nzxHP+9Dm0dHSvNOm1JDVetZi10rYMNkV 2fja29u73Jvded5W3zLgDeDn4cDil+Nu5ETlGeXt5sHnk+hk6TTqA+rR657sau017gDuyO+Q8Ffx HfHh8qTzZfQl9OP1nvZZ9xL3yPh9+TH54/qT+0P78vyf/U39+v6m/1L//wAAABcAUACnARwBvgJn Ax0D9ATvBgMHJghvCcELIwyVDgYPfBDuElkTuxUXFl0XmBjFGeca/xwLHRAeDB8DH/Yg5SHTIr4j qCSQJXkmYCdIKDApFSn6Kt4rwSykLYcuaS9KMCsxDDHrMsszqjSINWc2RjclOAI44Dm8Opg7czxO PSc9/z7VP6tAf0FTQiVC9kPGRJZFZkY1RwVH1EilSXZKSEsaS+1Mwk2XTmxPQ1AZUO9RxlKeU3VU S1UhVfdWzFegWHVZSVobWu5bwFySXWVeNl8JX9xgr2GDYldjLGQBZNhlr2aHZ2BoOmkVafFqzmus bIxtbW5PbzNwGXD/cedy0XO7dKd1k3Z/d2t4WHlDei57F3wAfOh9z361f5qAf4FjgkiDLYQShPmF 34bHh6+ImImBimuLVIw+jSiOEY76j+OQzJG0kpyThJRrlVGWOJcemASY6pnRmrebnZyEnWueUp87 oCOhDaH4ouOjzqS6paamk6eAqG2pW6pJqzisJ60Xrgmu+6/vsOSx2rLSs8u0xrXBtr63vbi8ubu6 u7u8vLy9vb6+v7/AwcHCwsXDx8TKxc/G1MfbyOTJ78r9zA7NIs45z1TQc9GV0r3T6NUZ1k/XitjK 2hPbYty53hvfiOEB4ovkI+XL54rpXOtB7TrvSfFx86/14vgz+pz9L///AABuZGluAAAAAAAABjYA AJfbAABZpgAAU+oAAIsPAAAnzwAAFqgAAFANAABUOQACWZkAAoAAAAGXCgADAQAAAgAAAB0AMwBP AGoAhACeALcA0ADpAQIBGwE0AU0BZwGBAZwBtwHSAe8CDAIqAkkCagKLAq4C0gL4Ax8DSQN0A6ED 0QQDBDcEbgSoBOMFIQViBaUF6gYxBnoGxAcRB18HrwgBCFUIqgkBCVoJtAoRCm8KzwsyC5YL/Axk DM4NOQ2nDhYOiA77D28P5hBeENcRUhHPEk4SzhNPE9IUVxTdFWUV7xZ6FwcXlhgmGLcZShneGnQb CxukHD4c2h13HhUetB9VH/ggnCFBIegikCM5I+QkkCU9JesmmydMJ/8osilnKh0q1CuMLEYtAi2/ Ln4vPzABMMUxizJTMx0z6TS3NYc2WjcvOAY44Dm8Ops7fDxgPUc+MD8bQAlA+UHqQt1D0UTGRbxG s0eqSKJJm0qUS45Mik2ITodPiVCNUZRSn1OsVL5V01brWAhZKFpLW3JcnF3JXvlgLWFkYp5j3GUc ZmFnqWj1akVrmGzvbklvp3EIcm1z1XVAdq94InmZexN8kX4Tf5mBIoKvhD6F0IdliPyKlowyjdGP cZEUkrqUYpYPl76ZcpsqnOieq6B1okWkHqX+p+ep2avVrdqv57H+tB62Rbh0uqi8478jwWfDrsX5 yEbKlcznzzrRj9Pm1j7Ymdr13VTfteIa5IHm6+lY68nuP/C58zj1u/hD+s/9Yv//AAAAHgA1AFIA bwCKAKQAvgDYAPIBDAEmAUABWwF1AZEBrAHJAeYCBAIjAkICYwKFAqkCzgL0AxwDRwNzA6ED0gQF BDoEcgStBOoFKQVrBbAF9wZABowG2QcpB3sHzggkCHwI1wkzCZEJ8gpVCroLIQuLC/cMZgzXDUsN wQ46DrYPNA+1EDgQvhFGEdASXBLqE3oUCxSdFTEVxRZbFvEXiRghGLsZVhnxGo8bLRvNHG4dER21 HlsfAh+rIFYhAiGvIl4jDyPBJHUlKyXiJponVCgQKM0pjCpMKw8r0iyYLWAuKS71L8MwlDFnMjwz FDPuNMs1qjaLN204Ujk3Oh07BDvsPNU9vj6oP5NAf0FsQlpDSkQ7RS5GI0caSBNJDUoKSwhMCE0J TgxPEVAYUSJSLlM8VE5VZFZ9V5pYvFnhWwtcOl1sXqFf2mEWYlRjlWTYZh1nZWiuafprSWyZbexv QHCVcexzQ3SadfJ3Sniiefp7U3ytfgh/ZoDGgiqDkYT8hmyH4IlaitmMXI3kj3CQ/5KQlCSVuZdP mOaafZwVna2fRqDhon6kHaW/p2SpDaq7rG2uJK/fsaCzZrUxtwC41bqtvIu+bcBUwkDEMcYmyCHK IcwmzjHQQtJX1HPWldi92uzdIt9g4afj+OZT6LnrKu2m8C7yv/Va9/v6ov1R//8AAAAiAD8AYgCD AKIAwQDhAP8BHgE+AV4BfgGfAcIB5QIKAjACWAKCAq4C3AMOA0IDewO3A/cEOwSEBNEFIwV5BdMG MQaSBvcHXwfKCDgIqQkcCZMKDQqKCwoLjQwTDJwNKA23DkkO3g92EBEQrhFOEfESlxNBE+4UnhVS FgoWxheGGEoZEhneGq4bgRxXHTAeCx7oH8cgqCGKIm4jVCQ7JSUmESb/J/Ao5CnbKtUr0yzULdgu 4C/rMPkyCTMdNDI1STZiN304mTm3OtU79T0WPjc/WkB9QaBCxEPoRQxGMEdUSHlJnUrCS+dNDk42 T2BQjFG7Uu1UI1VcVplX2VkcWmJbq1z1XkFfjmDcYitjemTLZh1ncGjFahxrdWzQbi5vjnDxclZz vnUpdpZ4BXl3eut8YX3Zf1OAzYJJg8aFRIbCiEGJwItBjMKORY/JkU6S1JRbleOXbJj2moCcCZ2S nxugo6Iqo7ClNqa8qEGpxqtLrNGuWK/fsWiy8rR+tgq3mLknura8R73Yv2jA+cKIxBbFo8ctyLTK Ocu7zTnOtNAs0aDTENR91eXXStir2gjbYdy03gLfTOCQ4c7jBeQ35WLmheei6LnpyOrU69Xs0u3J 7rrvqPCQ8XXyVPMx9Af02vWo9nL3PvgP+OD5pvpt+y777vyp/Vz+EP63/1v//wAAZGVzYwAAAAAA AAAKQ29sb3IgTENEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAG1sdWMAAAAAAAAAEAAAAAxpdElUAAAA FAAAANBmckZSAAAAQgAAAORuYk5PAAAAEgAAASZlc0VTAAAAEgAAAThmaUZJAAAAEAAAAUpwdFBU AAAAGAAAAVp6aFRXAAAADgAAAXJqYUpQAAAADgAAAYBubE5MAAAAFgAAAY5kZURFAAAAEAAAAaRy dVJVAAAAJAAAAbRrb0tSAAAADAAAAdhlblVTAAAAEgAAAeRzdlNFAAAAEAAAAfZkYURLAAAAHAAA AgZ6aENOAAAADAAAAiIATABDAEQAIABjAG8AbABvAHIAaQDJAGMAcgBhAG4AIADgACAAYwByAGkA cwB0AGEAdQB4ACAAbABpAHEAdQBpAGQAZQBzACAAYwBvAHUAbABlAHUAcgBGAGEAcgBnAGUALQBM AEMARABMAEMARAAgAGMAbwBsAG8AcgBWAOQAcgBpAC0ATABDAEQATABDAEQAIABjAG8AbABvAHIA aQBkAG9faYJybbJmdphveTpWaDCrMOkw/AAgAEwAQwBEAEsAbABlAHUAcgBlAG4ALQBMAEMARABG AGEAcgBiAC0ATABDAEQEJgQyBDUEQgQ9BD4EOQAgBBYEGgAtBDQEOARBBD8EOwQ1BDnO7LfsACAA TABDAEQAQwBvAGwAbwByACAATABDAEQARgDkAHIAZwAtAEwAQwBEAEwAQwBEAC0AZgBhAHIAdgBl AHMAawDmAHIAbV9pgnIAIABMAEMARAAAbW1vZAAAAAAAAAYQAACcYgAAAADAXf8AAAAAAAAAAAAA AAAAAAAAAHRleHQAAAAAQ29weXJpZ2h0IEFwcGxlIENvbXB1dGVyLCBJbmMuLCAyMDA1AAAAAP/b AEMACAUGBwYFCAcGBwkICAkMFA0MCwsMGBESDhQdGR4eHBkcGyAkLSYgIisiGxwnNigrLzAzMzMf Jjg8NzE7LTIzMf/bAEMBCAkJDAoMFw0NFzEhHCExMTExMTExMTExMTExMTExMTExMTExMTExMTEx MTExMTExMTExMTExMTExMTExMTExMf/AABEIAXYBsQMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAA AAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEU MoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2Rl ZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK 0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUG BwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS 8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4 eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri 4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/APf6KKKACiiigAooooAKKKKACiiigAooooAK KKKACimNKi9TTftMf94UAS0VF9pj/vCj7TH/AHhQBLRUX2mP+8KPtMf94UAS0VF9pj/vCj7TH/eF AEtFRfaY/wC8KPtMf94UAS0VF9pj/vCj7TH/AHhQBLRUX2mP+8KPtMf94UAS0UxZUboafQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFQ3Unlxk1NVPVTi3b6UAcdY6To/iPx5rLazpVjqP2fTrJY/tdukuzMl1 nG4HGcDOPQVu/wDCCeD/APoVND/8F0P/AMTWL4EJbxt4iz/z5WP/AKHdU7xF4u1XQ/EesCPT/t+l 6dYW93OfOWIwKWmEhX5SXYhAQpIHynkE8tK4Gx/wgng//oVND/8ABdD/APE0f8IJ4P8A+hU0P/wX Q/8AxNYCeLvEjeIlshpdibU64bDeLk7vJ+y+dnG3738X/juP4qvaD41vtUWykm8PS20WqWr3Gnn7 SrtKVUHY4wAhYHKnJyOu08UraX/ruBo/8IJ4P/6FTQ//AAXQ/wDxNH/CCeD/APoVND/8F0P/AMTW X4h8QapHcXsVi32WSGyhgRCqyAXty4WME9/LwCQOCHz2FUIfizpKajJBciH7KjXEYlS7je43QK7O 0luPmRSI22nnPGQuRQG50f8Awgng/wD6FTQ//BdD/wDE0f8ACCeD/wDoVND/APBdD/8AE03w94jv tS1P7DqWjNpsj2gu4z9oWUMhbABwBhhxkcgZ4J61mz+LdQh1dtL07TH1W7nuLoRiW4SBIliEZOWC k4PmADgnPtyD+vu0D+vwuan/AAgng/8A6FTQ/wDwXQ//ABNH/CCeD/8AoVND/wDBdD/8TXML471K XVl1BLKb+ym0y0kgshJGJJbi5lMaBsrkYK4zuAABODkAatz4q1Ca3l077Iuna4t9BZlFkE6YcCRp EYqN2IhIeVHK4x6gf1+ppf8ACCeD/wDoVND/APBdD/8AE0f8IJ4P/wChU0P/AMF0P/xNYlv8R5E0 231LVNAns7K+tGubJknWV5iuP3bLgBWbcCvJyOu08U7UviBc6PFcw61o0dlfwmAhTeg2wSZmVXeb b8gBRg2V4OMZzRtoOxs/8IJ4P/6FTQ//AAXQ/wDxNH/CCeD/APoVND/8F0P/AMTWZpXivWNU1zTI INNsktL3Tbi53fbVkBkjkRRtdAQYzuGGHJD5wCuDp+BNU1HV9Gnn1gQLdxX1zbssBJRRHKyAAkAk YXqQM+gp2/r52F/X6mFe6To/hzx7ozaNpVjp32jTr1ZPslukW/ElrjO0DOMnGfU129rJ5kYNcZ46 JHjfw5j/AJ8r7/0O1rrdKObdfpSAuUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFUtV/49m+lXaqaku63I9qA OP8AAf8AyO3iP/rysf8A0O6rodW8L2OqjWBcSXC/2xZpZTlGA2ovmYK5Bwf3rdc9uK4aTU9U8K+I 9Rv7LS7bUIb23giIku2gZDG0p7RvkHzR6dKD8V9aBx/widr/AODRv/jFAHXyeDrY6jJexahfRyNf pqCorR7VkWHySBlCdrJwQSfUEVneD/A0mlaVpo1LVb+a8s7A20SeYhSzZ1AkMRCAnkcF92BwOKwP +Fsa1/0Kdt/4NG/+MUf8LY1r/oU7b/waN/8AGKAO4t/C1nDPFO1xdTSpefbXeR1Jlk8nyhuwBkBc YAxyAaz28DWyJcxx317PZOtwYtMllVbZXmDb8lVDlSXbhmIG44HAxy//AAtjWv8AoU7b/wAGjf8A xij/AIWxrX/Qp23/AING/wDjFD1VgWhr+FfCutpqFxdaxfX1vmyitIibyOaRNr7jsKxqAvGMsCzZ OcYFdHbeGbK31xdWSSc3CtOwUsNn77y93GM/8slxz3PXtwv/AAtjWv8AoU7b/wAGjf8AxioR8SvE EcEOrNp1pLDc3ctmum+aV8rYitv87YSxPzcbAOR6ZIK39fgdkfAmmfYGtVuLxf8ARreCOUOu+IwS NJHIvy43BnzyCDgcdczaX4QtrHURqU99eahf7nkea5KfvHZFQEhVUDagKgKAMM2ck5rjf+Fsa1/0 Kdt/4NG/+MUf8LY1r/oU7b/waN/8Yo6WKbu7mx4f+HEKeHrGz8Q397eyQWH2VYDKvl2pYLvMTKqs eVG0sTgDjFaa+Ch++nfxBq76nK0f/EwLxCRUj3bY9gjEZT53yCpyWyeQMcp/wtjWv+hTtv8AwaN/ 8Yo/4WxrX/Qp23/g0b/4xQI7DRfBlno13Y3VreXZltFuVfd5eLjz3EjlwEAHzqCNm0DGOnFa2jaV Bo9vPDbNIyz3M1yxkIJDSOXYDAHGWOPavOf+Fsa1/wBCnbf+DRv/AIxSj4r60Tj/AIRO1/8ABo3/ AMYp3A2fHf8AyO/hz/rzvf8A0O1rrdK/49l+lecxanqninxJp1/e6XbafDY288QEd207OZGiPeNM AeUfXrXpGmrttwPakBbooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKZKm9cGn0UAYd/osdyTlQazG8Kwk/wCr H5V19FAHIf8ACKQ/88x+VH/CKQ/88x+VdfRQByH/AAikP/PMflR/wikP/PMflXX0UAch/wAIpD/z zH5Vy1ppSSala2BUbV1q84/7d1NesV5/pv8AyOMH/Yavf/SdaANH/hFIf+eY/Kj/AIRSH/nmPyrr 6KAOQ/4RSH/nmPyo/wCEUh/55j8q6+igDkP+EUh/55j8qF8Kwg/6sflXX0UAYen6LHbEEKBWzEmx cCn0UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAV5/pv8AyOMP/Yavf/Sda9Ar z/Tf+Rxh/wCw1e/+k60AegUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFACEgDmsTUfGPhvTLyS01HXtMt LmPG+Ga7jR1yARlScjgg/jWlqEvlRE+1c14Iu1Eniy7lJ2Jqm5iOeBZ22f5UN21Dcs/8LC8If9DP o3/gfF/8VR/wsLwh/wBDPo3/AIHxf/FViw/Em5bTLq/l0CRIo7FtRiHmyDdCuMq5aIKsmGBCqWB5 +bjJm1vxZrkFtdWo0uC21S2ubD5Y7zfG8VxPsHzmMYbKsrDbwDkE0+V/19wLU1P+FheEP+hn0b/w Pi/+Ko/4WF4Q/wChn0b/AMD4v/iqq3fi7Vo9QNvZ6DDfRxJC80ltemQgPIY2VAsZ3MrK+clRhckj kBbbxjfTamumnRUW8+3NZyR/a87AsQlMv3PuFWGD6so4J4QWLP8AwsLwh/0M+jf+B8X/AMVR/wAL C8If9DPo3/gfF/8AFV01FAHM/wDCwvCH/Qz6N/4Hxf8AxVKPiD4QP/Mz6N/4Hxf/ABVdLRQBV03U rLVLRLvTbuC7tpM7JoJBIjYJBww4PII/CrVcV4EuiItQhz93VtQ/9LJjXaKcqKAFooooAK8/03/k cYf+w1e/+k616BXn+m/8jjD/ANhq9/8ASdaAPQKKKKACiikY4U0AVtS1Ky0u0e71K7gtLaPG+aeQ RouSAMseByQPxrEPxB8ID/mZ9G/8D4v/AIqs/wAd3RMWnw5+9q2n/wDpZCa0fElxq1pr+lto6/am uElje0mn8mDgBhIzBGYEcjgc7h9QAN/4WF4Q/wChn0b/AMD4v/iqP+FheEP+hn0b/wAD4v8A4qs6 DxXqV54g0hoLWKHT7rTZpp457kJ5cqzRIcnYc7SxAwcNuPoKW18Za5etbLaeHrQm8mnt4TJqRUB4 WZZC+Ijhco20jcTxkLnIdtL/ANdv0A0P+FheEP8AoZ9G/wDA+L/4qj/hYXhD/oZ9G/8AA+L/AOKq HS9am1TxDoN3DJPDaanpU872jlSqurwbTwOo8xh1weK6ykBzP/CwvCH/AEM+jf8AgfF/8VR/wsLw h/0M+jf+B8X/AMVXTUUAcz/wsLwh/wBDPo3/AIHxf/FVa07xj4b1O8jtNO17TLu5kzshhu43dsAk 4UHJ4BP4VuVynxAm8i78LyDtqzfraXIoA6oEEcUtVdPl82IH2q1QAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBm62f9Hb6VzvwyAdfEyuAwbVsEHkEfZbeuh1 z/j3b6Vz3wv/AOZl/wCwv/7a29AF4+APDhtZ7VrW5aCaLyChv7jCRZB8pPn+RDgZRcA4AIwBUreC dDaS6kkivZHu4Y4ZWk1G4cssZBTq5wykZDD5gSTnJOehop3YGHpXhHSdIvmvtNS6iuWh8ks97PKp UZIyjOVJyS2cZyzHqSTV8M+GLqx1ibW9dvbfUdXktI7L7RDbeRmNCSSRk/MzHJxgcKABjnpqKQBR RRQAUUUUAed+BSftWqj/AKi1/wD+lUtehJ9wV554F/4+9V/7C1//AOlUtehx/cFADqKKKACvP9N/ 5HGH/sNXv/pOtegV5/pv/I4w/wDYavf/AEnWgD0CiiigApr/AHDTqbJ9w0Aee+OiftWlD/qLWH/p VFXYaj4f0/UdTt9RuhdfarZGjiaK8miVQ3X5UYLk+uM8D0Fcd46/4+9K/wCwtYf+lUVei0Ac2PAf h4QWkP2a6KWbM0Wb+4LDcysVLF8su5FbaSRkZxS23gXQbX7P5EeoJ9meSSL/AIml0drSffP+s6nJ J9yT3NdHRQBz+meC9E0u7srqyjvUlsY2it9+o3MiojHJXa0hUg8cEHoPQY6CiigAooooAK4z4oHH /CNf9hf/ANtbiuzri/ih/wAy1/2F/wD21uKAOi0Q/wCjr9K0qzND/wCPdfpWnQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBma5/x7t9K574X/wDMy/8AYX/9 tbeuh1z/AI92+lc98L/+Zl/7C/8A7a29AHaUUUUAFFFFABRRRQAUUUUAedeBf+PvVf8AsLX/AP6V S16HH9wV554F/wCPvVf+wtf/APpVLXocf3BQA6iiigArz/Tf+Rxh/wCw1e/+k616BXn+m/8AI4w/ 9hq9/wDSdaAPQKKKKACmyfcNOpsn3DQB5546/wCPvSv+wtYf+lUVei15146/4+9K/wCwtYf+lUVe i0AFFFFABRRRQAUUUUAFcX8UP+Za/wCwv/7a3FdpXF/FD/mWv+wv/wC2txQB0Oh/8e6/StOszQ/+ PdfpWnQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBma5/ x7t9K574X/8AMy/9hf8A9tbeuh1z/j3b6Vz3wv8A+Zl/7C//ALa29AHaUUUUAFFFFABRRRQAUUUU AedeBf8Aj71X/sLX/wD6VS16HH9wV554F/4+9V/7C1//AOlUtehx/cFADqKKKACvP9N/5HGH/sNX v/pOtegV5/pv/I4w/wDYavf/AEnWgD0CiiigApsn3DTqbJ9w0AeeeOv+PvSv+wtYf+lUVei15146 /wCPvSv+wtYf+lUVei0AFFFFABRRRQAUUUUAFcX8UP8AmWv+wv8A+2txXaVxfxQ/5lr/ALC//trc UAdDof8Ax7r9K06zND/491+ladABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFAGZrn/AB7t9K574X/8zL/2F/8A21t66HXP+PdvpXPfC/8A5mX/ALC//trb0Adp RRRQAUUUUAFFFFABRRRQB514F/4+9V/7C1//AOlUtehx/cFeeeBf+PvVf+wtf/8ApVLXocf3BQA6 iiigArz/AE3/AJHGH/sNXv8A6TrXoFef6b/yOMP/AGGr3/0nWgD0CiiigApsn3DTqbJ9w0AeeeOv +PvSv+wtYf8ApVFXotedeOv+PvSv+wtYf+lUVei0AFFFFABRRRQAUUUUAFcX8UP+Za/7C/8A7a3F dpXF/FD/AJlr/sL/APtrcUAdDof/AB7r9K06zND/AOPdfpWnQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBma5/x7t9K574X/APMy/wDYX/8AbW3rodc/492+ lc98L/8AmZf+wv8A+2tvQB2lFFFABRRRQAUUUUAFFFFAHnXgX/j71X/sLX//AKVS16HH9wV554F/ 4+9V/wCwtf8A/pVLXocf3BQA6iiigArz/Tf+Rxh/7DV7/wCk616BXn+m/wDI4w/9hq9/9J1oA9Ao oooAKbJ9w06myfcNAHnnjr/j70r/ALC1h/6VRV6LXnXjr/j70r/sLWH/AKVRV6LQAUUUUAFFFFAB RRRQAVxfxQ/5lr/sL/8AtrcV2lcX8UP+Za/7C/8A7a3FAHQ6H/x7r9K06zND/wCPdfpWnQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBma5/x7t9K574X/wDM y/8AYX/9tbeun1SMyQkD0rzK/tNf0i8vZNC1q8sY7yYTyRJDA679ipkb42P3UXjNAHrVFeKHVfHm f+RmvP8AwEtf/jVH9rePP+hmvP8AwEtf/jVAHtdFeKf2t48/6Ga8/wDAS1/+NUf2t48/6Ga8/wDA S1/+NUAe10V4p/a3jz/oZrz/AMBLX/41R/a3jz/oZrz/AMBLX/41QB7XRXin9rePP+hmvP8AwEtf /jVTWuo+OZXAk8T3oHtaWv8A8ZoA6DwL/wAfeq/9ha//APSqWvQ4/uCvCrDxzF4A8WPo/igSvaXh N4mobQX3SuzOZFUAY3l/ugYGBg17fpt7a6jYw3dhcRXNtKu5JYmDKw9iKALFFFFABXn+m/8AI4w/ 9hq9/wDSda9Arz/Tf+Rxh/7DV7/6TrQB6BRRRQAU2T7hp1Udd1fT9D0ya/1e8is7WIfNJK2B9B3J 9AOTQBxHjr/j70r/ALC1h/6VRV6LXhkHjBviTrl7b6HDLaabpvlzpeYUzGdZVeMhSCoGUY4IOcdu lXrrUfHMTkR+J70j3tLX/wCM0Aey0V4p/a3jz/oZrz/wEtf/AI1R/a3jz/oZrz/wEtf/AI1QB7XR Xin9rePP+hmvP/AS1/8AjVH9rePP+hmvP/AS1/8AjVAHtdFeKf2t48/6Ga8/8BLX/wCNUf2t48/6 Ga8/8BLX/wCNUAe11xfxQ/5lr/sL/wDtrcVxA1Xx5n/kZrz/AMBLX/41WjYWmv6veWUmu61eX0dn MZ44nhgRd+xkydkan7rtxmgD0fQ/+PdfpWnVLS4zHCAfSrtABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFADXUMMGqM+mRynlRWhRQBkf2HD/dFJ/YcP90VsUUA Y/8AYcP90Uf2HD/dFbFFAGP/AGHD/dFH9hw/3RWxRQBj/wBhw/3RTk0WFTkKK1qKAPBP2pvDwXSN H1qFADDK1rIQOSGG5fwG1vzqj+zjpXiHTdat5rvUZdP0m+SV4rNwGW9dMowHP7tkOD2YhT1GcfQd 3aW15Gsd5bxXCK6yBZUDAMpBVsHuCAQexFcb4y0hLC4kvlka20+8lSSeZBzYXQ4ju19uiyDoRgnj dkA7iisnw1q8mp2skV7GtvqVm/k3kCnhXxkMvqjDDKfQ+oIrWoAK8/03/kcYf+w1e/8ApOtegV5/ pv8AyOMP/Yavf/SdaAPQKKKKACvlz4/aT4iuvEV9qMmoy6to9rP5KEAIlq7AuYQoPzFVAywH+9yD X0L4s1eWzij0/TpY49RvFYrK+NlrEv8ArJ3zxhQeM9WKjpkjM8D6PDKsOqmF0s4o2j0uGbJcRscv cPnrJKeSTyFI6FmoA479mnw6tt4Bm1KVB5mp3LMresafKP8Ax7fXpj6LCxyVFaFlaW1hax2tjbxW 1vENscUSBEQegA4AqagDH/sOH+6KP7Dh/uitiigDH/sOH+6KP7Dh/uitiigDH/sOH+6KP7Dh/uit iigDI/sOH+6Kng0yOI8KK0KKAGooUYFOoooAKKKKACiikJwDQAjOF6mmG4jH8Qrj/iI8N3p1rY3U Uc8FxqdhHJFIoZXU3cOQQeCCO1av/CCeD/8AoVND/wDBdD/8TQBt/aI/7wo+0R/3hWJ/wgng/wD6 FTQ//BdD/wDE0f8ACCeD/wDoVND/APBdD/8AE0Abf2iP+8KPtEf94Vif8IJ4P/6FTQ//AAXQ/wDx NH/CCeD/APoVND/8F0P/AMTQBt/aI/7wo+0R/wB4Vif8IJ4P/wChU0P/AMF0P/xNH/CCeD/+hU0P /wAF0P8A8TQBt/aI/wC8KcsqN0NYX/CCeD/+hU0P/wAF0P8A8TWF4m0DQfD+r+GL3SNF03T5zqbR tLa2scTFTaXHykqAcZA49hQB3oOaKrWUvmxg+1WaACiiigAooooAKKKKAOR1rxsNE8RahZ3un3c9 jZ2cF1JcWsO8W6s0odpDu+6NgOFBP3jggcamo+JI7NXEWmaneyecsMSW8A/fkpv3KzELtAzliQMg jrxWX4k8I6jq2p6jLaa1FaWWrWUdjeQNZ+Y+xTJlo33gKxEjDlWA64NM8XeGn1hrO1m1bT1jiuRJ bWN9aedDIgi2FHTzF8whiXB7HHBxmhh1KmufEU2enjUtL06S/tjaiUQbdkof7QsLKecDBLevI645 rYHjXT/7UWza0v1iM4tDeGEeQtwRnyS2c7u2cbd3G7PFYtr8N5bfQG0z+148rA8MMiWYQJm4Eyko GxwRjA2jHTFOtvhvFD4jGp+bphU3pvnf+ykN0ZDyVE7MSE3/ADAY3DoGo7L1/P8AyF3/AK6f5lm2 +JGn3cFnJZaPrdwb9ZHtI0tVDTqgUsw3MAF+bGWIBI4zkZs3Pj7TIbO2vo7PUbiwmto7qS7jgAjt 43OFL7iCTwchQxGOQOKk0Lwj/ZJ8Pn7d539i2Etn/qtvnb/L+bqduPL6c9evFc1q3wokv7dIP7Vs 3VbGO1WS600TyQMhY74SZMR7tw3YBPy8EHBAtynaxuReO0FzqNtc6Rfi4t9RNhaQRqjSXjCISEr8 wAwuTliBjHOTgdDoerWuuabHfWXmCN2ZCsiFHjdWKsrA9CGBB+lclq/w9k1O4ubi5vdPuGe+W+jh u9O86AP5CwuroZPmBChlwVKnua6bwroieHtDg06NoW8sszNBbpAhZmLHbGvCjnAHJwBkk809Py/L X8RGrRWBNJ4psZXZIdP1i23EqqM1rOq9hzuRz+KCkj8Y6ZHIsOri40SdjgJqMflKT6CXJjY+ysaQ HQUUiMrqGRgysMgg5BFLQAUyeGO4hkhnjWSKRSjowyGUjBBHcU+igDzqSC98Na1FHbLJcXFpCfso zltQsQctbknrNDnKE8kH/acjvtPvbfUbGC9spVmt7hBJHIvRlI4NVPEOkJrOn+SJTb3MTia1uVGW glX7rj19CO4JB4Ncp4Z1d9K1CSO7iW1tbq58m7twcrYXzc8f9MpshlP95vV8AA7uR0jRnkZURRks xwAK8403ULIeLoWN5bhf7YvGz5q4wbdcHrXceJdHg8QeH7/SLrHlXsDRE4ztJHDD3Bwfwr4w0Lwz fal43t/DLq8d2959mlA5MeGw5/4CAT+FAH2+CCAQQQehFU9a1S30bTZr67LeXGAAiDLyMThUUd2Y kAD1NT2drBY2UFpaxrFb28axxovARVGAB9AK4PUtTufEGr2s2mFW3O6aOrDcmR8st847ogO2MfxF v9sEABpmmXPiDV7qHUwr7nR9YZTuQkfNFYoe6IDuc/xE/wC2QPQqpaLplvo+mw2NoG8uIHLOctIx OWdj3ZiSSe5Jq7QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUVTvtX03TgTqGoWloB18+ZU/may/ +E38Nt/x7arFe/8AXkrXP/osNQB0FNf7hrB/4StZf+PHQ9du/T/QWgz/AN/ileVfFrxz490nxbpc Ph+zvLBLy3wmnyxQXDTOrHccIX7FRwe1AHZeOmP2nSx2/taw/wDSqKvQ68WW58WXdvpk3jK0sbSd tW07yo7YneB9qjzv5IB+7jB9c4r2mgApsgZo2EbbHIIVsZwfXFOooA84vdf8SafPq5h1S21CDT/J svMksxGv2yZ0VR8rZKosis3ruAHQ1Nc67r9nryeFW1GOW6uLmFY9SNsoZInimkYbB8pbNuwB4GGB IOOelPhTTm0C90d2neC+nluJJC+JBI8hk3KwAwVYjae20dcVQPgW2eJpZdW1KTVTcpcrqhaMTo6K UUABPL27WYbduDuYnk5oB+Rf8G6leajp1ympPHLdWN5NaPLGmwS7GwG25OCVxkeuccVuVn6Bo8Gh 6atnbyTTfO8sk0zbnlkdizuxAAySSeAAOwArQoDuFcZ8TyQfDRH/AEF//bW4rs64v4of8y1/2F// AG1uKAOi0Q5t1+laVZmh/wDHuv0rToAKKKKACiiigAoormtbV/EGuHQN7Jp1vCs+o7SQZw5YJDns p2szY7ADoxoAQ6ze+I3aHws6RWIJWTV3UOjEcEQL0kPbefkH+1yBp6LoFho7SS26NLdzD99eTt5k 83+855x6KMAdgK0IYo4IUhhjWOKNQqIgwqgcAADoKfQAUUUUAFFFFABRRRQAU2WNJY2jlRXRhhlY ZBHoRTqKAOefwhY27mXQp7nQ5Sc4sXAiJ94WBjP12g+9J9q8T6X/AMfljb63AP8AlrYnyJ8e8Tna fqHHstdFRQBj6Z4o0nUbkWiXJt74/wDLndo0E/4I4BI9xke9bFVdT0yx1W2NtqdnBeQk52Txhxn1 57+9Y/8Awjd3p/Ph7WrqzUdLa7zd2/5Md6j2VwPagDoq5bxrowkR9Vt7Q3ZEJgv7RRzeW3JKj/bT JZD1zkcbsif+2ta07jWtBkmjHW50t/PX6mM7ZB9FD/WmzeN9B+xXNxFqMRNtGZJYGykyADvG2HB9 iKAI/B2t+ZGNMvLsXcscKz2l5ni+tj92T/eGQrj1weAwrmtN8OeH7H4v6h4r/tbTSbm3CxW3nr5k c5+V2x7qPXJLt7Z0NB8CRagRqHiaImOSWSe30bINvaCTBYNxl2OMsudgJOAcbj1g8P6KLf7ONIsB DjHl/Zk249MYxQBz3jbWoZ1n0sSyJZQosmqTQ5L7GOEt0xyZJTxgchT2LLWp4T0iWzik1DUYo49R vFUNGmNlrEv+rgTHG1QecdWLHuAMXUPA0elTLqPhhSFtrg3i6MdiW0kmzYSmFyj4A25JUEdBnI6X QdXt9Y06C9tWJinQMAwwy+oI7EHgjsQaANOikYhQSxAA5JNY954t8O2UnlXOuaekv/PL7Qhc/RQc n8qANmiuf/4TCyl4sLHV749jDp0yqfo7qqn86P7Z1+4/48/C0kOeh1C+iiH/AJD80/pQB0FZPjK9 uNN8I6zfWUnlXNrYzSxPtDbXVCQcHIPI71V8vxfc/eudF04HqEgluiPoS0Y/T8Ku3OkPqHhy50jV rx7k3cEkE08aLGxVwQcDkDAOB16d6T20HGyauZWmeJtVnmns73w9Jb3628dzBCt0jiWNm2nLYAV1 7ryOmCa59/iQ2kxvb35tZ7yS9vwhu7uOyjWGGcoFDsMM+CABjnBJI610uneEUsvPkfWtVuruWKO3 W7mkj82KJG3BFwgHJzkkFj3PSoZvAtoJPP0/VNR066MlyzXFu0Zdlnk8x0w6MuN2CDjcMdetN7/f /wAD/g/MS218vy1KA+IUlzCt7pmiS3WmLb21zNcNcLGyRzdMJg7mXqRkDHfPBnbxtePdxrbaC72d 1eTWFrcvcqnmSxiTJZMEqhMTAHknqQOM6h8KWH2K7tRLdeXdwwwuWl3MFjGFO5gST6k5zXNWvhDV x4stJS0lvpNlqVxfLELxZIT5iyD5E8sOGLSFiGcqvO3rwPXRCV7akeneMvEstjpF62kQ3clzopv7 i3juFjRSGX5gxUnJU8J0zwTxmu7imOpaSk9pI9ubqAPFIVBaPcuQcHIJGenSsrSfCNnplnDbJd3k 6w2LWCNKybhETkDhRyBgA+g5yea2rG1Sysre0iLGOCNY1LdSFGBn34p9P67v/gB1/rsv+CYv/CM3 Mv8Ax/eJtbuPVVkigH4eVGp/Wj/hCtCf/j6gub71+23s9wD+DuRXQUUhmXY+GtB04g2Gi6dakd4b VEP6CtSiigApkiKTvKguoIDY5APX+Q/Kn0HkUAeefECOZEtbmC3kuTa31rctFGVDMsc6OwG4gZ2q epFLL8XNPibEnh3Xgf8Adtv/AI9XWappy3SkEZrmrjwlFI5OygCr/wALh0z/AKF7Xv8Avi2/+PUf 8Lh0z/oXte/74tv/AI9Uv/CHRf3KP+EOi/uUARf8Lh0z/oXte/74tv8A49R/wuHTP+he17/vi2/+ PVL/AMIdF/co/wCEOi/uUARf8Lh0z/oXte/74tv/AI9R/wALh0z/AKF7Xv8Avi2/+PVL/wAIdF/c o/4Q6L+5QBF/wuDTP+he17/vi2/+PVQ1rxUPGF1okNloup2i2l+bmWW68gKF8iZMDZIxJ3SL29a1 B4Piz9ytTTPDqWzAhcYoA29GXbAoPpWjUNtEIkAFTUAFFFFABRRRQAViapoly+pnVdFvxY3zxrFM ssXnQXCKSVDplSCNzYZSDzzkAAbdFAHP/avFsHEmk6TeAfxw38kTH/gDRED/AL6o/tvXE/1vhO8f /rheW7f+hOtdBRQBz/8AwkWoj7/g/XF/7aWbfyno/wCElvO/hXXB+Fuf5S10FFAHP/8ACS3X/Qra 5/3xB/8AHaP+ElvO3hTXD+FsP/a1dBRQBz//AAkeoH7vhDXD/wADtB/Oej/hIdVPTwbrQ/3p7If+ 3FdBRQBz/wDbusn7vhHUR/vXVqP5Smj+2teP3fClwP8AevYB/JjXQUUAc/8A2t4jP3fDCj/e1BB/ IGj+0vE56eHLQf72p4/lGa6CigDn/t/is9PD+mD/AHtWb+kBo+2+Lj00HRvx1iX/AORq6CigDwT4 n+JfiRYfEayt9BgeKdtPjdrKwle9gYebIN7Bo1AJxgnHAA+b03jc69qw0M+OtH0+yuhqlsFMLh2x vzyOduWCDhjnJBA6H0LU/FOm2lxJZW7S6jfp960sU82Rf9/Hyx/Vyoryfx34lS/mS1vNYsNMmeVP JtLJ/tl0JQwKbioKoQwBwAf96gD3OiuS8FeN7TXVXT9QZLLW4hiW2c4E3+3ET95T1wOV6HsT1tAB Xkdvd6LB4m1qz1LxFcaZbrqEvlwrefZYzuIZ8OMHO9n/AIvyrsvGnjaz8PxmzszHfazIMRWat9zP 8chH3VHXnk9BmsjwFp0lvZqtw5nlkZpJpGH+sdyWdiPdiT+NAG1YeFfCV/Es6Wlrq69RJdTm9/WR mrfs7G0sY/LsrWC2T+7DGEH5Csy58IeHbtxLcaJYGb/nssCpIP8AgYAP61F/wiNvD/yDtV1mwPby 795VH0WXeo/KgDoKK5/+zfE1t/x6eIbe7Ufw39gCx/4FEyAf98n6Ufb/ABTbf8fOh2N4o/is78qx /wCASIoH/fZoA6Ciuf8A+Eq8n/kI6Drll6/6J9pH/kAyVf1TWrTTNLj1G48z7PJJDGDt2kea6opI bGAC4JzyBnjtQBo0VTtNX029tEurLULW5t5H2JLDMro7f3QQcE8dKp6b4o0m/wBN0u9N5FaDVYw9 rDdSJHJJkZwFzyfYZoA2KKp/2vph1BdPGo2n21s7bbzl8w46/LnPHeqmoeKdC0+zvrm51Wz2aerN cqkys0e0AkFQc7uRx15HrQBr0Vh6f4v0O/1KbT4tQt1uEkSOJXmQfad0SyAxDdlxtcduxrcoAKKK KACiiigAoPAorF1fxZoOkarDpWqarbWV7cRebHHO2wMucfePy5zxjOaAK/jDV7rTtOQ6c0C3U93b WyNPGZEXzZ0jLFQyk4Dk4yOlRnS/Fx/5mDRf/BNL/wDJNYnjiffJpYVgytq2nkEHg/6XFXoNAHMf 2V4u/wChg0b/AME0v/yTR/ZXi7/oYNG/8E0v/wAk109NmkSGJ5ZWCoilmJ7AdaNgOa/srxd/0MGj f+CaX/5Jo/srxd/0MGjf+CaX/wCSaztP+JFvd6dcaj/Zkv2VYFmi8m5imkYuyiOJ0VsxyPvUgHjB 5IxirTeNpYpTp1xo0ia4biOCOxWdWV96M4fzegULHITkZyhAByMmwE/9leLv+hg0b/wTS/8AyTR/ ZXi7/oYNG/8ABNL/APJNanhzWF1vT2uPs8lrNFNJbzwSEExSIxVhkcEcZB7gg1p0Acx/ZXi7/oYN G/8ABNL/APJNVbu68RaHqmjrqWpaXe2uoXbWzrBp8kDr+4lkDBjM46xgYx3rsa474luY38MsO2rn /wBJLmgDrYJBIoIqSs/R3LwKT6VoUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRWTq3iT StKnFtcXPmXjDKWluhmnYeojUFse5GPegDWqG8u7axtnub24itoIxl5ZXCKo9yeBWH9o8Tat/wAe trBoNsf+Wt3ie5I9o1OxfqWb3WpbPwnp0dyl3qBm1e9Q5W4v380ofVEwEj/4AooAh/4SebUfl8M6 XNqIPS7nJt7Ue4dhuce6Kw96P+Eev9T+bxJq8s8Z62Vjm2g+jEHzH/Fgp/u10ZOBk8CuYk1S98Sy PbeHJjbacpKzasADvx1W3B4Y9jIcqO245wAQa6NN/s658H6DpVvcyXEJjmtYh5UFrG4xulZfu5HI A+Zu3GSPP/hz8FJvDXiTUNQ1iWO7S3OzT3X+MEcyFexAO3Hrn2NexaPpVno9kLXT4fKjyWYklmkY 9WZjyzHuTyauEZ60AeU+JvBsV5uEkCyLnIDLnBrlBourf22dNGqaoLYWvmGEX02zlsDjdjoDXvUt rHJ1ArmtO0+KfxzrMm0bLeztYB/vbpnb9GSgDzpfCQ0BI9YtrcCK0JN5Gi/fhP3m9yv3voGHevXt Hs44oEaMqykAhgcgj1q2lnEqlSgKkYII4IrE8Ik6ZPd+Gpif+JfiSzJ/jtXzsH/ACGj+iqT1oA6O iiigAooooAK534iadc6r4VmtbLT11KUz28htHdVWZUnR2UluMFVPWuiooBaHG6Fp10t9qGoz+Gxb R399C8VrI8Je32R7TcNhiobPGFJOAPfHESeA/EA0yG0nsr6Q3WjW1iyW01pshdC24SPKrMqgsGDR ZOQeMgV7TRQBwzeFJwZplso/tba2l39oJQv5YULv3demRjr145rhtNtRrNrYaHpmk2f2qHwxe2xn guIZEunPlqrAqxIVnBIMgU5LcZBr3Kooba3geR4II4mlO52RAC59TjrQtFb+trAtHf8Are557ceF b67h1q7XRkgu73UNNngV2i8xYohblxuBIG0rJxn1xnIz32pWjXto0CXdxZsxB823Khxg9sgj9Ks0 UAc//wAIzcf9DPrn/f2H/wCN0f8ACLyH73iPXD/28IP5JXQUUAc//wAIqD97XdcP/b6R/IUf8IlA fvavrh/7iUo/ka6CigDn/wDhELI/e1LXD/3F7kfyevPviH8FH8VeIrO6ttYmtrCG38uVrqea7mLb ifl8xjgYP94YPY17DTX+4aAPG28H2Hg220yx064u51fV7As1xKW5+1R9F4VevYc8ZzivZq84+Ics VqdPubqVIYIdUsXklkYKqKLqIliTwABzmun/AOE78H/9DXof/gxh/wDiqAOgqK7gFzaTW7MVEqMh I6jIxWJ/wnfg/wD6GvQ//BjD/wDFUf8ACd+D/wDoa9D/APBjD/8AFUmrqzGnbU46D4capJZWlu8e kafJpNgLa0ntS7fa5FlikR5htXau6EEqCxy7HPrqXHhjxFdaqviWVdNTV4LqGSKyE7tAYUiljKmX YG3Hz5GB2YHAweTW7/wnfg//AKGvQ/8AwYw//FUf8J34P/6GvQ//AAYw/wDxVVd/194ulibwjpV1 pWmSjUXia8u7qW7nEJJRGkYnapOCQowM4GcZwM1tVz//AAnfg/8A6GvQ/wDwYw//ABVH/Cd+D/8A oa9D/wDBjD/8VSA6CuL+KH/Mtf8AYX/9tbitT/hO/B//AENeh/8Agxh/+KrmPHXiTQtaufDlto+t 6bqE66oXaK1uo5WCi1uAWIUk4yQM+4oA7TQ/+PdfpWnWbogxbr9K0qACiiigAooooAKKKKACiiig AooooAKKp6nqlnpkW+7kbJ+7HFG0sj/7qKCx/AVkfb/EWrcaZp8ekW5/5edR+eUj1WBDx/wJwR3W gDoJ5oreF5riRIokGWd2Cqo9ST0rAPitL47PDNhPrJ6faE/dWo9/Obhh/uB/pT4PCVi8yXOtSz63 codyvfMGjQ+qRACNfqFz7mt8DAwOBQBzv9i6xqnOvaw0EJ62elkwr9Gm/wBY31XZ9K1dJ0jTtHgM Ol2UFojHLeWgBc+rHqx9zzV2igAqvqN/a6ZZS3l/OlvbxDLyOcAf/X7Y71V1zW7XRoo/NWSe6uDs trSEbpZ29FHt3JwAOSQKoadol1e3sWreJmjluojutrOM7oLP3GfvyerkcdFAGcgFcWl94tO/VIpb DQzyli2VmvB6zd1T/pn1P8Xda6eKNIo1jiRUjQBVVRgKB0AFOooAKKKKACuf8Jfvr3xDe9RcamyK faKKOIj/AL6jb8zW+xCqWYgADJJ7VgfD4E+D9PuWBDXyvetnrmZ2lP8A6HQBZ0jxLpOq3Mlpb3kK 3kck0ZtXlQTYjkaNm2Ak7cqcH0x0rOvtW8PXHi7T4hrEEOqWsLSKokXE0MjbChPQ5cIQAc5VfXnn 9L0DUxq0NvJ4cFoYdeuNSbVDLERJEzyFcbW372VlTBGNo5PajxDoCzy3V1eaXb6JYzaK1v8AaTJC q2EySl0ZiCOM7WBXPI5xSvs3/Wl/z0G1q0v61t+Wp3V9rWlaf5n2/U7O18rl/OnVNnGecnjjmnXO r6ZaC2N1qNpALshbcyTqvnE8gJk/MfpXlViLsX3hPXb/AEQ6lqesy3eoTWkTxh0DQoqFfNKg7Ywg wSOpNQT+A9fjtmR7C7eO+057ZbSyls9lpvnlk8l2mVtqBZUG6LJ/dng4Wm01v/X9bCVmrntFFQ2M LW9lBAzF2ijVCxOSSBjOe9TU3uJbBRRRSGFFFFABRRRQAUUUUAFFFFABRRRQAUhGQaWigDn9d0z7 UhGOtcVeeDfMkJ2/pXqbIG6imG3jP8IoA8o/4Qn/AGP0o/4Qn/Y/SvV/s8f90UfZ4/7ooA8o/wCE J/2P0o/4Qn/Y/SvV/s8f90UfZ4/7ooA8o/4Qn/Y/Sj/hCf8AY/SvV/s8f90UfZ4/7ooA8oHgnn7n 6Vu6H4a+yup29K7r7PH/AHRTliRegoAhsovKjA9qs0AYooAKKKKACiiigAoopsjrGjPIwRFGWZjg AepoA891jXvEGka74r1C0a0uNK0pbeaW3uGfzCvlbnWLBwnHOSDk8e40fF/ijVdFvLaxght/O1CW RraVbS4u/LgjRCxeKIbixdscEADBJzxSDTfCfijXJb+2s7rUXdk+0XMMsq2k3l42BvmEcwUjgAMA fxrb1LwtpOosz3MU6ytP9oE0N1LFIjlAhKurAqCoAIBAPcZpdB9Tjz458TXdrNPY6ZY2pstJ/tG5 ivFlDuwklUxoDtKhhESGYZGRlT2c3ibxRFqV7DbNptwbzWYrKzSdHVbdGsxMSSDlscHHGTu5AI29 daeFNDs7aS2tbBYoZbMWLqrsMwgsdvXrmRzu6knk0qeF9HTUft62rC4E0c4PnSbRIkZiVtu7bnYx XpzxnOBh9f67/wCQdP67f53MfSPFt7e63baJLb266hHdXSXwXOI4YgCjqM9XEsB5/vN6V2FYOi+H 2s/Emr67dtbvd6hsiTyYyuyGPO0MSTljnk8DhRjit6johdQoopCQASTgDqTQAtYesa9Il6dJ0KBb 7VcAuGOIbVT0eVh09lHzN2wMkVJNUvfErtbeHJTbacCVm1bAO/1W3B4Y/wDTQ/KO249NvSNKs9Hs haafD5ceSzEks0jHqzMeWY9yeTQBU0PQY9NlkvLqdr/VLhcT3kowxHXYg6Ig7KPqcnJOvRRQAUUU UAFFFFAGN42unsvB+s3EX+tSzl8serlSFH5kVpafapY2FtaRfct4liX6KAB/Ksbx38+i29t/z86j ZxH3U3EZb/x0NXQUAFMlijmjMc0ayI3VWGQfwp9FAGb4gsru608tpU629/ARJbs33GYfwN/ssPlP pnI5ApdA1iHWrH7REjQyxsYri3k/1lvIPvIw9R69CCCMgitGsPWNDma//tjQpo7PVQgSQyKTFdoM 4SUDnjJ2sOVyeoJBANyiudXxdb2f7vxJaz6JKOrzjfbt7iZflx/vbT7VrWerabfJvstQtLleuYpl cfoaALlFQy3dtEMy3ESD1ZwKzLrxb4btDi68QaXCfR7yMH8s0AbNRzSiNcmuH8c/EvT9G8K32paD NHqF5AFMamGVojl1By6jA4J7jnFcp4X+Ntr4slSwk0S+trxyBmAefEO25iACo/AgdzQB2+ja14t1 rRrHVLTRNGjgvreO4jWTV5QwV1DAHFsRnB9TVrz/ABp/0CNC/wDBvN/8jVN8OP8Aknnhr/sFWv8A 6JWneONW1LRtGiutHtYbm4a8toCk0mxdskqoecHk7se2c84wQCv5/jT/AKBGhf8Ag3m/+RqPP8af 9AjQv/BvN/8AI1ZMHxOsrnxH/ZVvBbP5l1JYxf6cnnmdA2d0ONyxkqVD9eh24INQXHxD1DUNLluP D+inzLS8tbO7F5L5YineZUkhHB3FQwBYcDeCN2CKFrsGxu+f40/6BGhf+Deb/wCRqPP8af8AQI0L /wAG83/yNWTf+I9f/wCErEekwC8tTctZR2rOkSO0cBd5DJtLAbmCcZ5j6cmoD8QdUF9JcDRVOmx6 QLxovOHnibzTGUB6EZGP174o/r8Livv/AF1sbvn+NP8AoEaF/wCDeb/5Go8/xp/0CNC/8G83/wAj VnR+OtRj1KS2v/Dv2aG1vobK6nW9V/Lebb5RRQuX/wBYm77uM8bsV0PhG9uNQ0C3uryTzJnaQM20 DOJGA4HHQCjpcfWxiazrXi7RtGvtUutF0Z4LG3kuJFj1aUsVRSxAzbAZwPUV1FrdLMoIOayPiP8A 8k88S/8AYKuv/RLVV8KXTTQISe1AHVUUDpRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUVz3iK S51PVbfw9aXElrHNC1xezxHbIIQQojQ/ws5J+YcgK2MEggAffeIzJeS6d4ftf7VvojtlIfZb2x/6 aSYOD/sqGb2A5qOPwudQdZ/FN3/a0gIZbXb5dpGfaLJ3kerlj6Yra0+xtdNs4rOwt47a2hG1I41w qirFACKoVQqgBQMADoKWiigAooooAKKKwtS8RH7ZJpmg2/8AaeppxIobbDa+80nO3/dGWPpjmgDR 1fVbLR7M3WoziKPIVRgs0jHoqqOWY9gASaxBp1/4oIl16N7HSeqaXu+ecetwR2/6Zg4/vFuguaR4 fEF4NT1e4OpatggTsu1IAeqwpyEHqeWPcmtugBsaLGipGoRFACqowAPQCnUUUAFFFFABRRRQAUVy 3xQd4/CDvFcR2rre2ZWeVdyRH7VFhmGRkDqeR0qDRLrVZL3U9JuNfjmbT7yJVvHt4xJKrx7jCQMK HBIIIHQjI70Aa/iazuL19JFvGZFh1COaXkDaihufzxWzXj+h+I9e0DwppkcupPqUurWMkWnSXCAl b3ztqKSOWBEgPPaJq1k8Ra7bzTXsmsxXSW2ujSv7OEEY81CyrnI+YSAMXGONoOQeoN3Zf1rb9UDV v68rnpVFebfD/wAU+ItX1XS5NTV/smr2clz5cv2ZFiI27fJCSGRlG7DeYM5x937tek0WAKKKKACs u78NaDetuvNE024b1ltI3P6itSigDFi8H+GIjmLw5pCH1WxiH/staVrY2lmMWlrBAPSKML/KrFFA FLW9Jsdd0q40zVYBcWdyu2WIsV3DIPUEEcgdKxLzSNO0XSzaaRY29lbqP9XBGEBPqcdT7muorL1q EywsB6UAU/hx/wAk88Nf9gq1/wDRK1oa/pMet6Y9jNPPbAyRyrNAVDo6OrqRuBHDKOoNeXND4q0O yt9O0rxLqCWlpEsMKNb2rbUUAKMmHJwAOtVf7V8ef9DNef8AgJa//GqAPRYPBkNtevNbaxqkFuZp bmO0jkjEUU0gbc4+TceWZgrEqCc44GK0Pw60m1s5rbT7q/slnWAyNFIhLzRSCRbg7lOZSQNzHhu4 4GOD/tbx5/0M15/4CWv/AMao/tbx5/0M15/4CWv/AMaoA9TsfDlnZGxaKSdmspZplZmBMjyli5bj uWJ4xWfJ4F09iu28vo1+zNbOqsmJEMhkGcqeQxOMY685rzz+1vHn/QzXn/gJa/8Axqj+1vHn/QzX n/gJa/8AxqjzFY9Ou/ClhdS3skktwDe31vfSbWXiSHy9gHH3T5S578nkdtLSNOh0rT47O3Z2jjLE FyCfmYsegHc14/8A2t48/wChmvP/AAEtf/jVH9rePP8AoZrz/wABLX/41R0sPzPS/iP/AMk88S/9 gq6/9EtWZ4L/AOPdPpXESnxfrNlc6fqfiO+ktLuJoZkFtaruRgQwyIsjIJ6V6J4Ys2ghUEY4oA6U dBS0DpRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAVz/AIitb611O117SoPtUlvG0F1aAgNPAxDf ITxvVgCAeCCw4JBHQUUAUNH1nT9ZgaXTrlZdh2yRkFZIm/uuhwyn2IBq/WVq3hzStVnW5urbbdoM JdQO0M6j0EiENj2ziqY0TW7XjTvE87qOiajax3AH4p5bH8WJoA6Giuf8vxgnH2rQ5vf7NNFn8PMb H50eR4vl4OoaJbD1WyllP6yrQB0FZeseIdN0iRILqcvdyDMVpAhlnk/3Y1yce/QdyKpHw5fXf/IX 8R6jOh6w2m20jP4oPM/8frS0jRdM0aN00uyhtvMOZGRfmkPqzdWPuSaAMk2uueIP+Qi76Hpx/wCX W3lBupR6PKvEY9kJP+2Olbmm6fZ6XZpaadbR21vH92ONcD3PuT3PerNFABRRRQAUUUUAFFFFABRR RQBBfWVpqNq9rqFrDd2743RTxh0bByMg8HBAP4VXs9D0mxtIbWy0uyt7eCTzooooFVY3/vgAYDcn nrV+igDBl8K2LatYXUQS2tbGV7lLKCFEje4YMplYgZLYZu/U5OSBWV4O0fQhreq3Mum26+IYr2Wa Z5okaeJZCdpSQKCY2UHB/wB5TyCK7OsrW9Ct9VkhuVllstQtgRBe25AkjB6ryCGU4GVYEHg9QCBa ATafoek6beXF3p2l2Vpc3RJnmggVHlJOTuIGTzzzV+udW98Tab8t7pkOsxDpPp8iwyn6xSEKPwkP 0FO/4THTo+L611Wxbv5+mz7R/wADVSn60AdBRXP/APCc+Fh/rNesIfaaYRkf99Yo/wCE78If9DTo n0+3xZ/9CoA6Ciuf/wCE68J/w+I9Lb/dukP8jR/wm/hs/c1WKT/rmjP/ACBoA6Ciuf8A+E00Q/ce +k/656bcv/KM0f8ACY6cfuWWuP8ATRbwfzjFAHQUyVFZfmrhfHfxEOieEtQ1LTNN1AXUCKYze6bP HDksB8xIXHX1HOK5rwP8cbfxRNFp99pF1a3z4G+2UzQntk45QZ9cgdzQB6ZcWNu5O7FQf2Zaf7Nc /wCB/C3hvV9Emv8AUvD+lXl1PqV+Xmns45Hb/S5gMsRk4AA/Ct3/AIQTwf8A9Cpof/guh/8AiaAH /wBmWn+zR/Zlp/s0z/hBPB//AEKmh/8Aguh/+JqnqXhnwHpmz7Z4Z0VC6u6qmlI5YIpZsBUJJwOn U9s0AX/7MtP9mj+zLT/ZqNPA3g50V18KaHhhkZ06If8AstR3ng7wRZWst1d+GtAgghUvJI9hCFRR 1JO3gUAWP7MtP9mj+zLT/Zqtb+DvBVzJOkXhXRS1vJ5b7tLjUbtobglPmGGHIyOo6g1N/wAIJ4P/ AOhU0P8A8F0P/wATQBNHYWqHI21egaCIYBFYn/CI+B/7QNgPDOhG5EXnGMabFwmcAk7cDkH8j6U5 /B3ghLuO0fw1oAuJUaRIzYQ7mVSoYgbegLLn6igDf+0xf3hR9pi/vCsX/hBPB/8A0Kmh/wDguh/+ Jo/4QTwf/wBCpof/AILof/iaANr7TF/eFH2mL+8Kxf8AhBPB/wD0Kmh/+C6H/wCJo/4QTwf/ANCp of8A4Lof/iaANr7TF/eFKLiM/wAQrm9U8J+BtK0651C/8M6HDa2sbSyyf2bE21QMk4Cknj0qwPAv g9gCPCuhkHkf8S6H/wCJoA31dW6GnVwvwtv/ADPBegx5+5p9uv5RqK7kHIFAC0UUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQBU1jS7HWtOl0/VbZLq0mx5kUn3WwQwz+IB/CsTVNPsdJ0022l2dvZQKOI4IxGo/ACumrE8So Wt2x6UAZ/wAKznwbGf8Ap+vv/SuavM7uLUbY6nfrp1zYtPp2pLesmn3MbK5jZkEtw7ETY2naygKv AB5APV+C/G2heHNAOm6xLe291FeXjMo065cYa5ldSGWMqQVYHg961Lz4meCL20mtLu6uZredDHLG +l3RV1IwQR5fQik0NOxx+p21nb2U02maTrNnpDnTkvYnhmjluJ/tS79qkB3k2ZDOud2RyasXWl3r aZqzaDpmowaYxvjptubeSNowbIL8kZG6MNLu2rgcngc101z8SvA13EkVzdXEqRukiq2lXRCshDKf 9X1BAI+lT/8AC1fB/wD0ELv/AMFl1/8AG6p6xa9fxsStGn6fgYNtY+Vr8kuoaJq91r4vVe1u4UdU S2EQwvnfcVOGDR5yWOccg1ylvpN3d6TqsDaFdBLzQZme3XSbmLdeKVdVkeRmM0o5/eYXcemeg9J/ 4Wr4P/6CF3/4LLr/AON0f8LV8H/9BC7/APBZdf8AxuhOzv8A1tb+vMLaf13v/Xkc3dWKnVWfWdI1 C58LNfSMLX7FNKBm1thCzQgFigKzD7pAbqARkVLfwreanYX76xp2ou8Ggk6csxkaSF/OuGiA5OZk TyRnlh+Ndf8A8LV8H/8AQQu//BZdf/G6P+Fq+D/+ghd/+Cy6/wDjdKWqt/W1ik7P+u9zA8RWl7d2 M1/faZNMt5qENs/nWc84it4Y2w0kEZDyq0pkwOh3qxyBWNbaNqJ020eDS79dXgsdXtLWf7HLCYXa QPAFzny18ssEJYgZ27s13H/C1fB//QQu/wDwWXX/AMbo/wCFq+D/APoIXf8A4LLr/wCN07/18rCW ljln0aK+kki8NaTqljosr6elzE8E1sZJBdKZXCsA2RHnfIOvqccXrPwp/ZOs2Vzo+nT28keuSxo+ 2QrDaG3fCgZ4h8zBwMLn8K2/+Fq+D/8AoIXf/gsuv/jdH/C1fB//AEELv/wWXX/xuj+vy/y+5it/ Xya/4PqZX2PxKsPiv/hIhDqOnyy4NtY2M6zXBNvEF+zsZDtG7Azg4ZWOR2zND8Oape/2Zp/i+zvL y+GqM+q3DbmguYvssnlYYAKYx8iFem7OR83PUf8AC1fB/wD0ELv/AMFl1/8AG6P+Fq+D/wDoIXf/ AILLr/43QnYb1OM1DwrdWPh9103TL8z3ei6nDcnbJI8jB08hGzkkhchAe2cV7JECIkBGCFFcd/wt Xwf/ANBC7/8ABZdf/G6Vfin4Rc4S+vWPtpd2f/adLpYDn/hG5PhjSB6WcP8A6AK9QT7grzL4UW0s Hh3S45o2jkS1iDIwwVIUZBHY16an3BQA6iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACqmoW/nxkVbooA4XVPC63Lkl c5rM/wCELT+5+lellFPUCk8tP7ooA81/4QpP7n6Uf8IUn9z9K9K8tP7oo8tP7ooA81/4QpP7n6Uf 8IUn9z9K9K8tP7oo8tP7ooA81/4QpP7n6Uf8IUn9z9K9K8tP7oo8tP7ooA81/wCEKT+5+lH/AAhS f3P0r0ry0/uijy0/uigDzX/hCk/ufpR/whSf3P0r0ry0/uijy0/uigDzX/hCk/ufpR/whSf3P0r0 ry0/uijy0/uigDzX/hCk/ufpU1r4PSNwdleieWn90Uvlp/dFAGNo+mC1UADGK2hwKAAOgpaACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigD//2Q== --Apple-Mail-57-550558534 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I have changed the name of the relations to make a point that we are not here trying to decide which of a:type or b:type is correct. They are both equally valid relations. But as is clear from the above diagram the value of the b:length relation is slightly lost. Attaching the b:length relation to the resource cannot help decide the issue of which representation to choose, since we don't know which representation that length is associated with. In N3 we could express the above graph as b:length 700, 600; b:type "text/html", "application/atom+xml"; b:alternate ; b:entry . > You can make use of that hint, but it does in no way tell you what the > actual media type is you'll get upon a GET; it is not authoritative, > the Content-Type header is. > > What you can rely on is that the server uses the correct link > relation. IOW, > that the server informs you about the relationship correctly, that > it does not > tell you X is an alternate of A if it isn't. > > Something else: > > Suppose there were two representation formats for atom feeds one in > XML and > one in some space optimized text format. Conceptually they server > up the same > information - what type goes into the type attribute? Now I completely agree with you that I think that both mime type and link relation type are very important. For some reason different people in this group only want to see part of the elephant. If we don't know how another document is linked to the current one, the information is not particularly helpful. We might as well have used an ... anchor. We would get a little metadata there through the containing text, but this would not be very machine processable. > And yet in other words: > > Media type are telling you hw to process a representation, not of > what kind the > resource is (resources are not typed, BTW). I think one can make a case that a media type is a class of representations. Resources can be typed by the way. For example see my foaf name. The following is true: a foaf:Person . I am a person. (And to some that may come as a revelation. ;-) Henry > Jan Home page: http://bblfish.net/ Sun Blog: http://blogs.sun.com/bblfish/ Foaf name: http://bblfish.net/people/henry/card#me --Apple-Mail-57-550558534-- From owner-atom-syntax@mail.imc.org Sat Dec 09 14:19:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt7jm-0002Ef-9L for atompub-archive@lists.ietf.org; Sat, 09 Dec 2006 14:19:54 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gt7g5-00085t-Lw for atompub-archive@lists.ietf.org; Sat, 09 Dec 2006 14:16:10 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB9J0sc8053703; Sat, 9 Dec 2006 12:00:54 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB9J0s0Z053702; Sat, 9 Dec 2006 12:00:54 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from gregerhaga.net (gregerhaga.net [84.234.70.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB9J0rJ5053693 for ; Sat, 9 Dec 2006 12:00:54 -0700 (MST) (envelope-from boss@gregerhaga.net) Received: from ssl.gregerhaga.net (gregerhaga.net [127.0.0.1]) by gregerhaga.net (8.13.1/8.13.1) with ESMTP id kB9J0pBo028571; Sat, 9 Dec 2006 21:00:51 +0200 From: "Greger" To: Rogers Cadenhead , atom-syntax@imc.org Subject: Re: Atom in Java (was rss reader) Date: Sat, 9 Dec 2006 21:00:51 +0200 Message-Id: <20061209190028.M84731@gregerhaga.net> In-Reply-To: <494582.50550.qm@web33205.mail.mud.yahoo.com> References: <20061209133740.M49034@gregerhaga.net> <494582.50550.qm@web33205.mail.mud.yahoo.com> X-Mailer: Open WebMail 2.51 20050228 X-OriginatingIP: 85.156.199.247 (boss) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.5 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 On Sat, 9 Dec 2006 10:18:32 -0800 (PST), Rogers Cadenhead wrote > --- Greger wrote: > > anyone working on this kinds of things? > > Don't know of any C++ efforts, but Apache Abdera's a > new Java class library to implement the Atom > syndication format and publication protocol: > > http://incubator.apache.org/abdera yes, thank's. but not suitable for my needs. I prefer C++. -- http://www.gregerhaga.net/ http://hack-space.biz/ From owner-atom-syntax@mail.imc.org Sat Dec 09 20:05:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtD7w-0001FL-A9 for atompub-archive@lists.ietf.org; Sat, 09 Dec 2006 20:05:12 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtD4b-0001GL-20 for atompub-archive@lists.ietf.org; Sat, 09 Dec 2006 20:01:46 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBA0kqpn085922; Sat, 9 Dec 2006 17:46:52 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBA0kqQc085921; Sat, 9 Dec 2006 17:46:52 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBA0kpIH085915 for ; Sat, 9 Dec 2006 17:46:51 -0700 (MST) (envelope-from bobwyman@gmail.com) Received: by py-out-1112.google.com with SMTP id f31so626013pyh for ; Sat, 09 Dec 2006 16:46:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=gEpWlcZxIN2jXsRXbbLThoiMF48TK0MOGXNyzQLVlgS45Rc08b+v8VZ3LH4qLPu0n6cJ9lpzhIyshcGU7CmEsGgfwv/JvRKyVF0u42LV0ycNecDuGCy9/h/0hzDwk4uCrQIvKHazL0lUU3DH45jGHAYroPAFdUS1XwOxQgdGCWc= Received: by 10.35.41.14 with SMTP id t14mr8938034pyj.1165711611042; Sat, 09 Dec 2006 16:46:51 -0800 (PST) Received: by 10.35.15.12 with HTTP; Sat, 9 Dec 2006 16:46:50 -0800 (PST) Message-ID: <45be5cd40612091646t6f3e132dq78bb1829f1010983@mail.gmail.com> Date: Sat, 9 Dec 2006 19:46:50 -0500 From: "Bob Wyman" To: "James M Snell" Subject: Re: Fwd: PaceEntryMediatype Cc: atom-syntax@imc.org In-Reply-To: <4579A645.3000209@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_61738_2816404.1165711610957" References: <456DB265.5090804@gmail.com> <456DCFF0.4000007@gmail.com> <28CAF6FA-75C5-456D-BAC5-18AEAA6EA1FE@geckotribe.com> <456F0A31.4050703@gmail.com> <45be5cd40612071806h525fa94kfd2a7e33cf4e0e7@mail.gmail.com> <45be5cd40612080903q75e9cc9bucaf348ca6aa1838@mail.gmail.com> <4579A645.3000209@gmail.com> X-Google-Sender-Auth: f581ff3d075a01f4 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.3 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b ------=_Part_61738_2816404.1165711610957 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 12/8/06, James M Snell wrote: > > I'm fine with the type parameter approach so long as it is effective. > By effective I mean: Will existing implementations actually take the > time to update their behavior to properly handle the optional type > parameter. > It would be useful to define better what is meant by "properly handle the optional type parameter." Those that don't understand the parameter should simply continue to operate on the current assumption that they can't really be sure if they are reading a feed or an entry until they read the first few bytes. Those that do understand the meaning of the optional parameter will be writing code in the future and we can hope that if they become aware of the type parameter and decide to care about it, they will have sufficient awareness to do whatever they do in a "proper" manner. The only case where I can see a problem would be those folk who match against the existing media type as an opaque string and don't have any code to handle opional type parameters. Such sloppy code would be broken by the use of the optional type parameters since the presence of the parameter would break the simple string matches used by these coders. However, I must admit that I don't have much sympathy for such folk. Making basic design decisions to adress the concerns of these sloppy folk is something like the old prejudice against using XML attributes since it tended to make it harder to create sloppy, regex based parsers... In any case, the alternative proposal, create a new media type for entries, would tend to confuse people who have their code written properly today --- those whose code understands that the existing atom mediatype can be used for both a feed and and entry. What we would be doing by creating a new media type is break the code of the folk who paid attention to the spec in order to preserve the code of those who didn't read the spec (or those who refused to see Atom as anything other than some twisted form of RSS...) This doesn't make sense to me. We should use the type parameter if anything is changed here. bob wyman ------=_Part_61738_2816404.1165711610957 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 12/8/06, James M Snell <jasnell@gmail.com> wrote:
I'm fine with the type parameter approach so long as it is effective.
By= effective I mean: Will existing implementations actually take the
time = to update their behavior to properly handle the optional type
parameter.

It would be useful to define better what is mean= t by "properly handle the optional type parameter." Those that do= n't understand the parameter should simply continue to operate on the curre= nt assumption that they can't really be sure if they are reading a feed or = an entry until they read the first few bytes. Those that do understand the = meaning of the optional parameter will be writing code in the future and we= can hope that if they become aware of the type parameter and decide to car= e about it, they will have sufficient awareness to do whatever they do in a= "proper" manner.

The only case where I can see a problem would be those folk who mat= ch against the existing media type as an opaque string and don't have any c= ode to handle opional type parameters. Such sloppy code would be broken by = the use of the optional type parameters since the presence of the parameter= would break the simple string matches used by these coders. However, I mus= t admit that I don't have much sympathy for such folk. Making basic design = decisions to adress the concerns of these sloppy folk is something like the= old prejudice against using XML attributes since it tended to make it hard= er to create sloppy, regex based parsers... In any case, the alternative pr= oposal, create a new media type for entries, would tend to confuse people w= ho have their code written properly today --- those whose code understands = that the existing atom mediatype can be used for both a feed and and entry.= What we would be doing by creating a new media type is break the code of t= he folk who paid attention to the spec in order to preserve the code of tho= se who didn't read the spec (or those who refused to see Atom as anything o= ther than some twisted form of RSS...) This doesn't make sense to me. We sh= ould use the type parameter if anything is changed here.

bob wyman

------=_Part_61738_2816404.1165711610957-- From owner-atom-syntax@mail.imc.org Sat Dec 09 20:14:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtDGy-0004hq-Q9 for atompub-archive@lists.ietf.org; Sat, 09 Dec 2006 20:14:32 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtDGx-0003mH-D3 for atompub-archive@lists.ietf.org; Sat, 09 Dec 2006 20:14:32 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBA0tB1j086645; Sat, 9 Dec 2006 17:55:11 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBA0tBYt086644; Sat, 9 Dec 2006 17:55:11 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBA0tAWH086634 for ; Sat, 9 Dec 2006 17:55:10 -0700 (MST) (envelope-from bobwyman@gmail.com) Received: by py-out-1112.google.com with SMTP id f31so626822pyh for ; Sat, 09 Dec 2006 16:55:10 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=uj1IOFs5JWmCUoSHGCRXPyzvz64H0s2XbqHpg57rKnXq0c8WPLbV2jiPYoqlZrNfcSKLxnCl9AocrymtLQToUYGbRV7LpRvEGfxoVZo8+h5HHeHcW8+rUsaHnbeVMZ+cdF8xPlBT5Ko1+oPT7CLmEaroiXUv/Ed4Zx/VFJ2LyZA= Received: by 10.35.41.14 with SMTP id t14mr8949213pyj.1165712109829; Sat, 09 Dec 2006 16:55:09 -0800 (PST) Received: by 10.35.15.12 with HTTP; Sat, 9 Dec 2006 16:55:09 -0800 (PST) Message-ID: <45be5cd40612091655u7f5d538fk117edd339a6b012@mail.gmail.com> Date: Sat, 9 Dec 2006 19:55:09 -0500 From: "Bob Wyman" To: Greger Subject: Re: rss reader Cc: atom-syntax@imc.org In-Reply-To: <20061209133740.M49034@gregerhaga.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_61755_9394704.1165712109790" References: <20061209133740.M49034@gregerhaga.net> X-Google-Sender-Auth: bac2893e9c942b4c Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb ------=_Part_61755_9394704.1165712109790 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 12/9/06, Greger wrote: > > > > hi > I have made a prototype rss reader. All is good. just wondering if anyone > would be interested in getting down to create a C++ library for in > particular > atom, but also the other used rss feed types. > anyone working on this kinds of things? If you're going to be building a C++ library for syndication, you might want to look at the Microsoft RSS Platform for some inspiration. See: http://msdn.microsoft.com/XML/rss/default.aspx I believe that Microsoft's is currently the most comprehensive platform for handling syndication feeds. But, there is much that can be done to improve on what they've done. bob wyman ------=_Part_61755_9394704.1165712109790 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 12/9/06, Greger <boss@gregerhaga.net> wrote:


hi
I have made a prototype rss reader. All is good. just wondering if anyone
would be interested in getting down to create a C++ library for in particular
atom, but also the other used rss feed types.
anyone working on this kinds of things?

If you're going to be building a C++ library for syndication, you might want to look at the Microsoft RSS Platform for some inspiration. See: http://msdn.microsoft.com/XML/rss/default.aspx

I believe that Microsoft's is currently the most comprehensive platform for handling syndication feeds. But, there is much that can be done to improve on what they've done.

bob wyman

------=_Part_61755_9394704.1165712109790-- From owner-atom-syntax@mail.imc.org Sun Dec 10 14:29:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtUMt-0007Wx-AB for atompub-archive@lists.ietf.org; Sun, 10 Dec 2006 14:29:47 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtUMr-0004o4-Sd for atompub-archive@lists.ietf.org; Sun, 10 Dec 2006 14:29:47 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBAJDGqf088867; Sun, 10 Dec 2006 12:13:16 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBAJDFxl088866; Sun, 10 Dec 2006 12:13:15 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBAJDEpC088859 for ; Sun, 10 Dec 2006 12:13:14 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by py-out-1112.google.com with SMTP id f31so743559pyh for ; Sun, 10 Dec 2006 11:13:13 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=a4ZpW86swd9u9Ant8OgKPS5K2ZRWMX6ML8fd3PrO0ZsdRxyXVDqxjzf3yWehKg4FPKYnNloMAM4uKElikMcYnrvZqS01SQckKoHtJOkFCcVEqymWhjGb3rHKWBTaV9tvzt3yN/94gO/Ww3x6UOd7aGnfhJOMbJfCwEbGSGwsbe8= Received: by 10.65.185.13 with SMTP id m13mr9424414qbp.1165777993663; Sun, 10 Dec 2006 11:13:13 -0800 (PST) Received: from ?192.168.1.109? ( [67.181.218.96]) by mx.google.com with ESMTP id e18sm5558369qbe.2006.12.10.11.13.11; Sun, 10 Dec 2006 11:13:12 -0800 (PST) Message-ID: <457C5C35.7010802@gmail.com> Date: Sun, 10 Dec 2006 11:12:53 -0800 From: James M Snell User-Agent: Thunderbird 1.5.0.8 (X11/20061115) MIME-Version: 1.0 To: Bob Wyman CC: atom-syntax@imc.org Subject: Re: Fwd: PaceEntryMediatype References: <456DB265.5090804@gmail.com> <456DCFF0.4000007@gmail.com> <28CAF6FA-75C5-456D-BAC5-18AEAA6EA1FE@geckotribe.com> <456F0A31.4050703@gmail.com> <45be5cd40612071806h525fa94kfd2a7e33cf4e0e7@mail.gmail.com> <45be5cd40612080903q75e9cc9bucaf348ca6aa1838@mail.gmail.com> <4579A645.3000209@gmail.com> <45be5cd40612091646t6f3e132dq78bb1829f1010983@mail.gmail.com> In-Reply-To: <45be5cd40612091646t6f3e132dq78bb1829f1010983@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Bob Wyman wrote: > [snip] > The only case where I can see a problem would be those folk who match > against the existing media type as an opaque string and don't have any > code to handle opional type parameters. Such sloppy code would be broken > by the use of the optional type parameters since the presence of the > parameter would break the simple string matches used by these coders. Well, quite a few don't even seem to account for uppercase or mixed case media types. > However, I must admit that I don't have much sympathy for such folk. Ditto > Making basic design decisions to adress the concerns of these sloppy > folk is something like the old prejudice against using XML attributes > since it tended to make it harder to create sloppy, regex based > parsers... In any case, the alternative proposal, create a new media > type for entries, would tend to confuse people who have their code > written properly today --- those whose code understands that the > existing atom mediatype can be used for both a feed and and entry. What > we would be doing by creating a new media type is break the code of the > folk who paid attention to the spec in order to preserve the code of > those who didn't read the spec (or those who refused to see Atom as > anything other than some twisted form of RSS...) This doesn't make sense > to me. We should use the type parameter if anything is changed here. > Like I said before, I'm definitely not against the type param approach so if that's what the majority of folks want, then I'm happy with that. - James From owner-atom-syntax@mail.imc.org Sun Dec 10 14:35:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtUSa-0001EZ-54 for atompub-archive@lists.ietf.org; Sun, 10 Dec 2006 14:35:40 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtUSY-0005zN-9B for atompub-archive@lists.ietf.org; Sun, 10 Dec 2006 14:35:40 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBAJKDk0089526; Sun, 10 Dec 2006 12:20:13 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBAJKDaT089525; Sun, 10 Dec 2006 12:20:13 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nz-out-0102.google.com (nz-out-0506.google.com [64.233.162.231]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBAJKCg8089518 for ; Sun, 10 Dec 2006 12:20:12 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by nz-out-0102.google.com with SMTP id z3so699341nzf for ; Sun, 10 Dec 2006 11:20:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=oL8PjVhRtJCCWk35NWvmD/nyuJtX3ARS0uRX1TWT7yfdv1XhD7lklBLnbVa/tYgXH5rOlx9JaH1imt4a2tVN0LiOxNuaG1pW/P2w+Z7Y7kCmbaR6VGPdJQrtaTi+rD+A/6tAI8BuaIfLI0OfFSAHtbeMmL5tw2gz3yC6CD2/n/Y= Received: by 10.65.210.18 with SMTP id m18mr2568948qbq.1165778411823; Sun, 10 Dec 2006 11:20:11 -0800 (PST) Received: from ?192.168.1.109? ( [67.181.218.96]) by mx.google.com with ESMTP id f13sm5584878qba.2006.12.10.11.20.10; Sun, 10 Dec 2006 11:20:11 -0800 (PST) Message-ID: <457C5DD9.9070309@gmail.com> Date: Sun, 10 Dec 2006 11:19:53 -0800 From: James M Snell User-Agent: Thunderbird 1.5.0.8 (X11/20061115) MIME-Version: 1.0 To: atom-syntax Subject: Atom Entry Documents Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Ok, the recent discussion seems to point towards a consensus towards distinctly flagging Entry Documents in the media type. The only question is whether or not to use a new media type or an optional type param. I'm going to write up an I-D this week. Please let me know which of the two approaches below y'all prefer... Option A) Optional Type Param application/atom+xml; type=entry application/atom+xml; type=feed Option B) New Entry media type application/atom.entry+xml - James From owner-atom-syntax@mail.imc.org Sun Dec 10 16:24:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtWA5-0004sv-TG for atompub-archive@lists.ietf.org; Sun, 10 Dec 2006 16:24:42 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtWA2-0005Ec-Gu for atompub-archive@lists.ietf.org; Sun, 10 Dec 2006 16:24:41 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBALB9Ib002680; Sun, 10 Dec 2006 14:11:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBALB9l7002679; Sun, 10 Dec 2006 14:11:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.172]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBALB8pe002672 for ; Sun, 10 Dec 2006 14:11:09 -0700 (MST) (envelope-from algermissen1971@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (Xserve/8.12.11/smtpout02/MantshX 4.0) with ESMTP id kBALB7h3024387; Sun, 10 Dec 2006 13:11:07 -0800 (PST) Received: from [10.0.1.2] (d055071.adsl.hansenet.de [80.171.55.71]) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id kBALB2IS009877; Sun, 10 Dec 2006 13:11:04 -0800 (PST) In-Reply-To: <457C5DD9.9070309@gmail.com> References: <457C5DD9.9070309@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Jan Algermissen Subject: Re: Atom Entry Documents Date: Sun, 10 Dec 2006 22:11:24 +0100 To: James M Snell X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes X-Proofpoint-Virus-Version: vendor=fsecure engine=4.65.5446:2.3.11,1.2.37,4.0.164 definitions=2006-12-10_01:2006-12-08,2006-12-08,2006-12-10 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=3.1.0-0611300000 definitions=main-0612100016 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.5 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 On Dec 10, 2006, at 8:19 PM, James M Snell wrote: > > Please let me know which of the two approaches below y'all prefer... > > > Option B) New Entry media type > > application/atom.entry+xml > +1 Jan > > - James > From owner-atom-syntax@mail.imc.org Sun Dec 10 16:24:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtWA8-0004t8-0O for atompub-archive@lists.ietf.org; Sun, 10 Dec 2006 16:24:44 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtWA2-0005Eh-Gu for atompub-archive@lists.ietf.org; Sun, 10 Dec 2006 16:24:43 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBALAW9X002601; Sun, 10 Dec 2006 14:10:32 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBALAWxo002600; Sun, 10 Dec 2006 14:10:32 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBALAVU3002591 for ; Sun, 10 Dec 2006 14:10:32 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.2.180] (unknown [83.70.238.233]) by chilco.textdrive.com (Postfix) with ESMTP id 786C9DC69D for ; Sun, 10 Dec 2006 21:10:25 +0000 (UTC) Message-ID: <457C77BD.2050904@dehora.net> Date: Sun, 10 Dec 2006 21:10:21 +0000 From: Bill de hOra User-Agent: Thunderbird 1.5.0.8 (X11/20061117) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Fwd: PaceEntryMediatype References: <456DB265.5090804@gmail.com> <4574759D.1070904@gmail.com> <45748679.70602@gmail.com> <4575D37D.8080909@gmail.com> <45764C7A.5040008@gmail.com> <45be5cd40612071836s4e110ea2v165a41e501102730@mail.gmail.com> <45be5cd40612080906m130d30c5ybfd5af5a74c085aa@mail.gmail.com> In-Reply-To: <45be5cd40612080906m130d30c5ybfd5af5a74c085aa@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: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Bob Wyman wrote: > What you seem to be implying is that the majority of applications > that process Atom Feed documents are not, in fact, supporting extremely > important parts of the atom specification. I believe that any properly > constructed Atom Feed parser will contain all the code needed to parse > the most complex Atom Entry document. And, an entry document with an > atom:source is semantically equivelant to an atom:feed with a single > entry... Yet that's an optional semantic (which we could argue means it's not semantically significant). This argument that entries are feed aliases all feels like coulda woulda shoulda to me. I mean was this not discussed and dealt with during the RFC's development? cheers Bill From owner-atom-syntax@mail.imc.org Sun Dec 10 17:28:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtX9y-0002m5-6G for atompub-archive@lists.ietf.org; Sun, 10 Dec 2006 17:28:38 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtX9u-00061U-Th for atompub-archive@lists.ietf.org; Sun, 10 Dec 2006 17:28:37 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBAMDYg9010055; Sun, 10 Dec 2006 15:13:34 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBAMDYJ0010054; Sun, 10 Dec 2006 15:13:34 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBAMDXha010048 for ; Sun, 10 Dec 2006 15:13:34 -0700 (MST) (envelope-from foolistbar@googlemail.com) Received: by an-out-0708.google.com with SMTP id d33so186451and for ; Sun, 10 Dec 2006 14:13:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:mime-version:in-reply-to:references:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer; b=EKCdN37oGRGMzmD8jdGsuhTKM/r3vp7pkyeoxOm7Coj4sa2ExMggt2JZRjGtxV2id6HFtrN7NWfBbtolA6ocD+A5ss/UxWiKc8BBObp1VBWeYwAuzuR5D6So3Ktb+PbN02d+ZcAy1tZsjch8fheaS9YP716igX3/ywxqbzJjUA4= Received: by 10.100.94.3 with SMTP id r3mr7468869anb.1165788810976; Sun, 10 Dec 2006 14:13:30 -0800 (PST) Received: from ?192.168.0.7? ( [86.139.123.225]) by mx.google.com with ESMTP id c16sm6252936anc.2006.12.10.14.13.29; Sun, 10 Dec 2006 14:13:30 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <457C5DD9.9070309@gmail.com> References: <457C5DD9.9070309@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0B8DAA23-34F4-4FA4-958A-30A7E9F837E8@googlemail.com> Content-Transfer-Encoding: 7bit From: Geoffrey Sneddon Subject: Re: Atom Entry Documents Date: Sun, 10 Dec 2006 22:13:27 +0000 To: atom-syntax X-Mailer: Apple Mail (2.752.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 On 10 Dec 2006, at 19:19, James M Snell wrote: > Option B) New Entry media type > > application/atom.entry+xml +1 - Geoffrey Sneddon From owner-atom-syntax@mail.imc.org Sun Dec 10 17:49:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtXTx-0001jh-Vh for atompub-archive@lists.ietf.org; Sun, 10 Dec 2006 17:49:17 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtXTt-00048w-7Q for atompub-archive@lists.ietf.org; Sun, 10 Dec 2006 17:49:17 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBAMSdPi012256; Sun, 10 Dec 2006 15:28:39 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBAMSdvh012255; Sun, 10 Dec 2006 15:28:39 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBAMScjT012249 for ; Sun, 10 Dec 2006 15:28:38 -0700 (MST) (envelope-from bobwyman@gmail.com) Received: by py-out-1112.google.com with SMTP id f31so766314pyh for ; Sun, 10 Dec 2006 14:28:35 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=FyVcYLkQe3B/SJPmXRLLcS1IIpyTz4eaYXr9b2tUHGDTdGTGBqWjGInkNUIKgt/Dpq58HxT2wclQzQDAHcqXOdpa/k+brLOqBDzMs0HARGD5TBzPhDPEajsEpWZA3YCaPgcSL76p1Ha0wTasVHGa7la82hHE09LCIqi7xctFyf4= Received: by 10.35.121.2 with SMTP id y2mr8804459pym.1165789715508; Sun, 10 Dec 2006 14:28:35 -0800 (PST) Received: by 10.35.15.12 with HTTP; Sun, 10 Dec 2006 14:28:35 -0800 (PST) Message-ID: <45be5cd40612101428s5afe565am52db53f62cbd1faa@mail.gmail.com> Date: Sun, 10 Dec 2006 17:28:35 -0500 From: "Bob Wyman" To: "Bill de hOra" Subject: Re: Fwd: PaceEntryMediatype Cc: atom-syntax@imc.org In-Reply-To: <457C77BD.2050904@dehora.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_68298_28877418.1165789715401" References: <456DB265.5090804@gmail.com> <45748679.70602@gmail.com> <4575D37D.8080909@gmail.com> <45764C7A.5040008@gmail.com> <45be5cd40612071836s4e110ea2v165a41e501102730@mail.gmail.com> <45be5cd40612080906m130d30c5ybfd5af5a74c085aa@mail.gmail.com> <457C77BD.2050904@dehora.net> X-Google-Sender-Auth: 4b26cff7e8f99445 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.3 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 ------=_Part_68298_28877418.1165789715401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 12/10/06, Bill de hOra wrote: > > This argument that entries are feed aliases > all feels like coulda woulda shoulda to me. I mean was this not > discussed and dealt with during the RFC's development? > This was, in fact, discussed on frequent occasions, but with different terminology. Personally, I don't like this "alias" terminology... What we're talking about here is equivalence. The term "alias" is usually used in the context of naming. If we were to use a term other than "equivalence" I think it would be better to talk about "feed proxies" since a "proxy" is often used to indicate one thing that can stand for another thing. The semantic equivalence between an atom:feed and an atom:entry (if it contains an atom:source) is an essential requirement for the proper functioning of aggregators and for streamers (such as those anticipated by "Atom over XMPP" [1]). In part, the need for this equivalence originates in the *wise* decision to avoid supporting the recursive hell that would have resulted from permitting "feeds of feeds." The problem being addressed is that some systems need to present "feeds" which are composed of entries extracted from other feeds. This is a non-trivial problem since some of the semantics of an entry is derived from data external to the entry -- i.e. data recorded in feed-global elements. Since we cannot say a prioi what part of the feed's data is relevant to proper interpretation of the entry, we must have a mechanism for including in an entry enough data so that the entry is, in fact, semantically equivalent to a feed containing a single entry. There are at least four elements of the Atom syntax specification that are relevant here. First, is that discussed above. We have the atom:source element which allows feed data to be encapsulated within an entry. Second, the atom syntax states that there should be no semantics implied by the order between items in a feed. This second element is important in that it permits an entry to be isolated from a feed without any loss of data or semantics. If inter-entry order within a feed was significant, then we would have to support "Feeds of Feeds" when producing aggregate feeds. We couldn't simply extract a single entry, we'd have to insert all entries "around" the extracted entry in order to preserve the information content of the extracted entry. I believe the equivelance between an entry and a single-entry feeds is also strengthened by the fact that we have the top-level atom:entry in the first place. An atom entry is not "complete" without feed data, thus, if we support an atom:entry in isolation, we're implying that it must be possible to construct an entry which is semantically equivalent to a singe-entry feed. I should also mention that the support for signing an entry within a signed feed is also important to the aggregation and streaming cases while also strengthening the ability of an entry to serve as a proxy for a single-entry feed. If we weren't supporting aggregate feeds, there would be less of a requirement to support signed entries in signed feeds. The following aspects of the atom-syntax spec work together to make "proper" aggregation and streaming possible without supporting "Feeds of Feeds": 1) atom:source as a place to stash feed data 2) Refusal to permit derivation of semantics from inter-entry sequence 3) atom:entry as a top-level element 4) support for signing entries which are contained in signed feeds Although most aggregators still don't do aggregation "properly" we at least have defined in Atom what they need if they get around to it... (We're still stuck with people who insist on seeing equivalence between RSS and Atom. They insist on building things the "RSS way" and then import their broken methods into their Atom implementations. RSS, of course, does NOT provide proper support for aggregate feeds.) To summarize: Yes, I think this business of an entry being semantically equivalent to a single-entry feed was discussed at great length during development of the RFC. Those involved in the discussions will remember that I personally argued this case on a regular (sometimes too regular...) basis. bob wyman [1] http://www.xmpp.org/internet-drafts/draft-saintandre-atompub-notify-05.html ------=_Part_68298_28877418.1165789715401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 12/10/06, Bill de hOra <bill@dehora.net> wrote:
This argument that entries are feed aliases
all feels like coulda woulda shoulda to me. I mean was this not
discussed and dealt with during the RFC's development?

This was, in fact, discussed on frequent occasions, but with different terminology. Personally, I don't like this "alias" terminology... What we're talking about here is equivalence. The term "alias" is usually used in the context of naming. If we were to use a term other than "equivalence" I think it would be better to talk about "feed proxies" since a "proxy" is often used to indicate one thing that can stand for another thing.

The semantic equivalence between an atom:feed and an atom:entry (if it contains an atom:source) is an essential requirement for the proper functioning of aggregators and for streamers (such as those anticipated by "Atom over XMPP" [1]).

In part, the need for this equivalence originates in the *wise* decision to avoid supporting the recursive hell that would have resulted from permitting "feeds of feeds." The problem being addressed is that some systems need to present "feeds" which are composed of entries extracted from other feeds. This is a non-trivial problem since some of the semantics of an entry is derived from data external to the entry -- i.e. data recorded in feed-global elements. Since we cannot say a prioi what part of the feed's data is relevant to proper interpretation of the entry, we must have a mechanism for including in an entry enough data so that the entry is, in fact, semantically equivalent to a feed containing a single entry.

There are at least four elements of the Atom syntax specification that are relevant here. First, is that discussed above. We have the atom:source element which allows feed data to be encapsulated within an entry. Second, the atom syntax states that there should be no semantics implied by the order between items in a feed. This second element is important in that it permits an entry to be isolated from a feed without any loss of data or semantics. If inter-entry order within a feed was significant, then we would have to support "Feeds of Feeds" when producing aggregate feeds. We couldn't simply extract a single entry, we'd have to insert all entries "around" the extracted entry in order to preserve the information content of the extracted entry.

I believe the equivelance between an entry and a single-entry feeds is also strengthened by the fact that we have the top-level atom:entry in the first place. An atom entry is not "complete" without feed data, thus, if we support an atom:entry in isolation, we're implying that it must be possible to construct an entry which is semantically equivalent to a singe-entry feed.

I should also mention that the support for signing an entry within a signed feed is also important to the aggregation and streaming cases while also strengthening the ability of an entry to serve as a proxy for a single-entry feed. If we weren't supporting aggregate feeds, there would be less of a requirement to support signed entries in signed feeds.

The following aspects of the atom-syntax spec work together to make "proper" aggregation and streaming possible without supporting "Feeds of Feeds":

    1) atom:source as a place to stash feed data
    2) Refusal to permit derivation of semantics from inter-entry sequence
    3) atom:entry as a top-level element
    4) support for signing entries which are contained in signed feeds

Although most aggregators still don't do aggregation "properly" we at least have defined in Atom what they need if they get around to it... (We're still stuck with people who insist on seeing equivalence between RSS and Atom. They insist on building things the "RSS way" and then import their broken methods into their Atom implementations. RSS, of course, does NOT provide proper support for aggregate feeds.)

To summarize: Yes, I think this business of an entry being semantically equivalent to a single-entry feed was discussed at great length during development of the RFC. Those involved in the discussions will remember that I personally argued this case on a regular (sometimes too regular...) basis.

bob wyman

[1] http://www.xmpp.org/internet-drafts/draft-saintandre-atompub-notify-05.html

------=_Part_68298_28877418.1165789715401-- From owner-atom-syntax@mail.imc.org Sun Dec 10 17:49:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtXUB-0001qw-9i for atompub-archive@lists.ietf.org; Sun, 10 Dec 2006 17:49:31 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtXU9-0004Ac-Tn for atompub-archive@lists.ietf.org; Sun, 10 Dec 2006 17:49:31 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBAMW9TY012612; Sun, 10 Dec 2006 15:32:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBAMW9kH012611; Sun, 10 Dec 2006 15:32:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBAMW8Eq012604 for ; Sun, 10 Dec 2006 15:32:09 -0700 (MST) (envelope-from bobwyman@gmail.com) Received: by py-out-1112.google.com with SMTP id f31so766739pyh for ; Sun, 10 Dec 2006 14:32:06 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=kRfivMtXwZFkeUiXIqk/aRkmnbxyK5XZy+wPHNH0p7CcKOQkhsErHqBbS0+GF/DPqeSt5Efn8HOtiCraECeKVHSEIvyh9IbPzV2QNaL4zJC9xMGFJeGdOJzGj/qnzLpXxlWAjlkpZprwydnu/CsgcWUldXJW5TowIR1D2WbcFt8= Received: by 10.35.119.11 with SMTP id w11mr10994612pym.1165789925195; Sun, 10 Dec 2006 14:32:05 -0800 (PST) Received: by 10.35.15.12 with HTTP; Sun, 10 Dec 2006 14:32:05 -0800 (PST) Message-ID: <45be5cd40612101432o53f237calbdf5fd5eed667001@mail.gmail.com> Date: Sun, 10 Dec 2006 17:32:05 -0500 From: "Bob Wyman" To: "James M Snell" Subject: Re: Atom Entry Documents Cc: atom-syntax In-Reply-To: <457C5DD9.9070309@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_68362_12856073.1165789925158" References: <457C5DD9.9070309@gmail.com> X-Google-Sender-Auth: 55ff4b642de24c62 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_Part_68362_12856073.1165789925158 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 12/10/06, James M Snell wrote: > > Option A) Optional Type Param > > application/atom+xml; type=entry > application/atom+xml; type=feed > +1 to Optional Type Parameter. The alternative of a new media type for entries is too disruptive and breaks existing implementations based on the current RFC. Such "violence" should not be permitted unless an exceptionally compelling case has been made. No such case has been presented. (In my opinion...) bob wyman ------=_Part_68362_12856073.1165789925158 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 12/10/06, James M Snell <jasnell@gmail.com> wrote:
Option A) Optional Type Param

  application/atom+xml; type=entry
  application/atom+xml; type=feed

+1 to Optional Type Parameter. The alternative of a new media type for entries is too disruptive and breaks existing implementations based on the current RFC. Such "violence" should not be permitted unless an exceptionally compelling case has been made. No such case has been presented. (In my opinion...)

bob wyman

------=_Part_68362_12856073.1165789925158-- From owner-atom-syntax@mail.imc.org Sun Dec 10 20:49:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtaIS-00048G-On for atompub-archive@lists.ietf.org; Sun, 10 Dec 2006 20:49:36 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtaIP-0007bZ-WB for atompub-archive@lists.ietf.org; Sun, 10 Dec 2006 20:49:36 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBB1Wpc2031896; Sun, 10 Dec 2006 18:32:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBB1WpAn031895; Sun, 10 Dec 2006 18:32:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bay0-omc3-s6.bay0.hotmail.com (bay0-omc3-s6.bay0.hotmail.com [65.54.246.206]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBB1WosW031875 for ; Sun, 10 Dec 2006 18:32:51 -0700 (MST) (envelope-from peaceable_whale@hotmail.com) Received: from hotmail.com ([207.46.8.23]) by bay0-omc3-s6.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sun, 10 Dec 2006 17:32:45 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 10 Dec 2006 17:32:45 -0800 Message-ID: Received: from 61.238.43.155 by BAY117-DAV13.phx.gbl with DAV; Mon, 11 Dec 2006 01:32:40 +0000 X-Originating-IP: [61.238.43.155] X-Originating-Email: [peaceable_whale@hotmail.com] X-Sender: peaceable_whale@hotmail.com From: "Franklin Tse" To: "'atom-syntax'" References: <457C5DD9.9070309@gmail.com> In-Reply-To: <457C5DD9.9070309@gmail.com> Subject: RE: Atom Entry Documents Date: Mon, 11 Dec 2006 09:32:36 +0800 Message-ID: <000601c71cc4$3cd52d80$b67f8880$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AccckgZPGcJxxlM9TjmUW9pZom5moQAMhmVw Content-Language: en-us X-OriginalArrivalTime: 11 Dec 2006 01:32:45.0271 (UTC) FILETIME=[422C3670:01C71CC4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kBB1WpsW031890 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 > Option B) New Entry media type > application/atom.entry+xml +1 Franklin Tse -----Original Message----- From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of James M Snell Sent: Monday, December 11, 2006 03:20 To: atom-syntax Subject: Atom Entry Documents Ok, the recent discussion seems to point towards a consensus towards distinctly flagging Entry Documents in the media type. The only question is whether or not to use a new media type or an optional type param. I'm going to write up an I-D this week. Please let me know which of the two approaches below y'all prefer... Option A) Optional Type Param application/atom+xml; type=entry application/atom+xml; type=feed Option B) New Entry media type application/atom.entry+xml - James From owner-atom-syntax@mail.imc.org Sun Dec 10 22:46:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtc81-0001KZ-Sk for atompub-archive@lists.ietf.org; Sun, 10 Dec 2006 22:46:57 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gtc7u-0000Ul-LO for atompub-archive@lists.ietf.org; Sun, 10 Dec 2006 22:46:57 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBB3QWgl045221; Sun, 10 Dec 2006 20:26:32 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBB3QWwY045220; Sun, 10 Dec 2006 20:26:32 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBB3QTbw045210 for ; Sun, 10 Dec 2006 20:26:30 -0700 (MST) (envelope-from joe.gregorio@gmail.com) Received: by ug-out-1314.google.com with SMTP id j3so1447878ugf for ; Sun, 10 Dec 2006 19:26:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=AlFC/mbtfbFm4liJk0X6tRbMZ5/od/FNxInUyroHioG+usAvTuA7oMKqWSpbBYGQQv5gjiwS+pPMRRT6f72nDddV6iYNF84oGXNj715zrbgKV6HzMPXOOM9PMiNyW9BfdylFul1AJ/eTSC6ynW5ZZ8hfsTx56wQLeKgv+G9hrmo= Received: by 10.78.17.1 with SMTP id 1mr1364168huq.1165807588926; Sun, 10 Dec 2006 19:26:28 -0800 (PST) Received: by 10.78.205.2 with HTTP; Sun, 10 Dec 2006 19:26:28 -0800 (PST) Message-ID: <3f1451f50612101926s1595f9c6kc63ca0128d0ad413@mail.gmail.com> Date: Sun, 10 Dec 2006 22:26:28 -0500 From: "Joe Gregorio" To: "Jan Algermissen" Subject: Re: PaceEntryMediatype Cc: "Daniel E. Renfer" , "Sylvain Hellegouarch" , "James M Snell" , "=?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?=" , "Mark Baker" , atom-protocol , atom-syntax In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <456DB265.5090804@gmail.com> <836A6AB5-5E29-455D-B210-84E85FA51D3B@mac.com> <45774483.1050205@gmail.com> <582CE04E-B2AE-4546-9CB1-5F2A5579536F@mac.com> <457747C4.9090405@gmail.com> <4577C59F.8040706@defuze.org> <760FB8D0-8CA2-4ADF-9345-8726C86771A6@mac.com> <36bd6e0b0612070057k245a61a9i1a2753a3ac754bc8@mail.gmail.com> X-Google-Sender-Auth: 0c8f800a46f7982c Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a On 12/7/06, Jan Algermissen wrote: > Ok, that is IMO heading in the right direction. This example makes sense > because it strongly emphasizes a difference between feeds and entries, > saying feeds are for viewing collections and entries are more or less for > editing web resources (if we include the media resource case). > > If the Atom specs never considered feed readers to be dealing with individual > entries anyhow (at least that is the impression I get by now) then having > a new media type does indeed make sense. Adding an optional parameter that indicated an entry or a feed would be a more elegant solution: application/atom+xml;type=entry application/atom+xml;type=feed > Question to Atom editors and others involved with the specs: What was the intention > behind having entry documents in Atom in the first place? Having entries as documents on their own was critical for the Atom Publishing Protocol, where you GET/PUT/POST/DELETE Entry Documents in the course of updating a collection. -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Sun Dec 10 23:35:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtcsq-0001CD-0s for atompub-archive@lists.ietf.org; Sun, 10 Dec 2006 23:35:20 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gtcso-0000vh-HK for atompub-archive@lists.ietf.org; Sun, 10 Dec 2006 23:35:20 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBB4BwPj050648; Sun, 10 Dec 2006 21:11:58 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBB4BwIs050647; Sun, 10 Dec 2006 21:11:58 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironclad.net.au ([203.30.247.11]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id kBB4BreN050638 for ; Sun, 10 Dec 2006 21:11:56 -0700 (MST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.118] (HELO [192.168.1.2]) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.0007422670 for ; Mon, 11 Dec 2006 15:11:49 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 11 Dec 2006 15:11:49 +1100 Subject: Re: PaceEntryMediatype From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <3f1451f50612101926s1595f9c6kc63ca0128d0ad413@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kBB4BweN050642 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id kBB4BwPj050648 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 On 11/12/06 2:26 PM, "Joe Gregorio" wrote: > Adding an optional parameter that indicated an entry or > a feed would be a more elegant solution: >=20 > application/atom+xml;type=3Dentry > application/atom+xml;type=3Dfeed I certainly agree it would be more elegant. A more pragmatic solution would be to go with "application/atom.entry+xml= " ... if WHATWG don't update their spec, we're safe; if anyone has implemen= ted per the current draft WHATWG spec, we're safe; if any implementations use na=EFve string matching, we're safe. The only danger is if someone has implemented APP per the moving target which is Draft-[n++] ... they shoul= d revise their test implementations as the draft updates, and certainly upd= ate once it reaches RFC status, so no sympathies there. e. From owner-atom-syntax@mail.imc.org Mon Dec 11 00:22:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtdct-0000Ni-Nk for atompub-archive@lists.ietf.org; Mon, 11 Dec 2006 00:22:55 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gtdcr-0006ee-AA for atompub-archive@lists.ietf.org; Mon, 11 Dec 2006 00:22:55 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBB57MdZ056566; Sun, 10 Dec 2006 22:07:22 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBB57MMS056565; Sun, 10 Dec 2006 22:07:22 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBB57Ltx056559 for ; Sun, 10 Dec 2006 22:07:21 -0700 (MST) (envelope-from bobwyman@gmail.com) Received: by py-out-1112.google.com with SMTP id f31so812975pyh for ; Sun, 10 Dec 2006 21:07:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=spk+UquOjDqolvxyzdQxbtWuN1fFpunI64xZIiIxhV3UU3nLSHIqTusLj4nYvaG/wi9wRjLf1wCo6rNIPL8/TnWe/dwFRR6Q5p+LFMGC5Dg5R1NqLW8p7worJkpZo2BUzfg9gdOFa+RDiCgF40RtsvS6fkvNDIYrJJtCAO0DHe8= Received: by 10.35.111.14 with SMTP id o14mr11639306pym.1165813640531; Sun, 10 Dec 2006 21:07:20 -0800 (PST) Received: by 10.35.15.12 with HTTP; Sun, 10 Dec 2006 21:07:20 -0800 (PST) Message-ID: <45be5cd40612102107o1806d693vf21365a6e40d20ba@mail.gmail.com> Date: Mon, 11 Dec 2006 00:07:20 -0500 From: "Bob Wyman" To: "Eric Scheid" Subject: Re: PaceEntryMediatype Cc: "Atom Syntax" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_71491_23017228.1165813640323" References: <3f1451f50612101926s1595f9c6kc63ca0128d0ad413@mail.gmail.com> X-Google-Sender-Auth: 96d540022e15578c Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.3 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 ------=_Part_71491_23017228.1165813640323 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 12/10/06, Eric Scheid wrote: > The only danger [of defining a new media type] is if someone has implemented > APP per the moving target which is Draft-[n++] ... they should > revise their test implementations as the draft updates, and certainly > update once it reaches RFC status, so no sympathies there. The impact here is not just limited to APP implementations. If a new media type is defined, it will undoubtedly appear in other contexts as well. Given the current definition of the atom syntax, it is perfectly reasonable for an "aggregator" to treat a single entry as the semantic equivelant of a single-entry feed. If a new media type is defined, such an application would end up having to be modified. That's not right... APP is not the only context within which Atom is used. bob wyman ------=_Part_71491_23017228.1165813640323 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 12/10/06, Eric Scheid <eric.scheid@ironclad.net.au> wrote:
> The only danger [of defining a new media type] is if someone has implemented
> APP per the moving target which is Draft-[n++] ... they should
> revise their test implementations as the draft updates, and certainly
> update once it reaches RFC status, so no sympathies there.

The impact here is not just limited to APP implementations. If a new media type is defined, it will undoubtedly appear in other contexts as well. Given the current definition of the atom syntax, it is perfectly reasonable for an "aggregator" to treat a single entry as the semantic equivelant of a single-entry feed. If a new media type is defined, such an application would end up having to be modified. That's not right... APP is not the only context within which Atom is used.

bob wyman

------=_Part_71491_23017228.1165813640323-- From owner-atom-syntax@mail.imc.org Mon Dec 11 03:08:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtgCi-0000BO-J4 for atompub-archive@lists.ietf.org; Mon, 11 Dec 2006 03:08:04 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gtg8g-0002Nj-5r for atompub-archive@lists.ietf.org; Mon, 11 Dec 2006 03:03:57 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBB7j1YK073094; Mon, 11 Dec 2006 00:45:01 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBB7j1MI073093; Mon, 11 Dec 2006 00:45:01 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.webfaction.com (mail1.webfaction.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBB7j0uq073079 for ; Mon, 11 Dec 2006 00:45:00 -0700 (MST) (envelope-from sh@defuze.org) Received: from [192.168.136.224] ([194.221.10.224]) (authenticated bits=0) by mail1.webfaction.com (8.12.11.20060308/8.13.3) with ESMTP id kBB7irqZ005361; Mon, 11 Dec 2006 01:44:56 -0600 Message-ID: <457D0C6F.2020603@defuze.org> Date: Mon, 11 Dec 2006 07:44:47 +0000 From: Sylvain Hellegouarch User-Agent: Thunderbird 1.5.0.5 (X11/20060728) MIME-Version: 1.0 To: Bob Wyman CC: Eric Scheid , Atom Syntax Subject: Re: PaceEntryMediatype References: <3f1451f50612101926s1595f9c6kc63ca0128d0ad413@mail.gmail.com> <45be5cd40612102107o1806d693vf21365a6e40d20ba@mail.gmail.com> In-Reply-To: <45be5cd40612102107o1806d693vf21365a6e40d20ba@mail.gmail.com> X-Enigmail-Version: 0.94.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: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Bob Wyman wrote: > On 12/10/06, Eric Scheid wrote: >> The only danger [of defining a new media type] is if someone has > implemented >> APP per the moving target which is Draft-[n++] ... they should >> revise their test implementations as the draft updates, and certainly >> update once it reaches RFC status, so no sympathies there. > > The impact here is not just limited to APP implementations. If a new media > type is defined, it will undoubtedly appear in other contexts as well. > Given > the current definition of the atom syntax, it is perfectly reasonable > for an > "aggregator" to treat a single entry as the semantic equivelant of a > single-entry feed. If a new media type is defined, such an application > would > end up having to be modified. That's not right... APP is not the only > context within which Atom is used. I still don't understand the meaning of equivalence between an entry document and a single-entry-feed document. I have read your other message and I'm still nowhere near an understanding of it. In fine if you accept that an entry document is just equivalent to a single-entry-feed you have to detail precisely how this equivalence takes place and can be measured. Is it based on the atom:id? If yes is it on the atom:id of the entry or the feed? Is it based on its metadata? Again which ones since an entry embedded in a feed can overwrite the feed metadata. You should also explain why we have entry document at all if they are equivalent to single-entry-feed ones. Moreover you claim that it's going to break implementations. Which ones? How? Why? Can't those applications be updated? Why shouldn't APP be set straight because of those applications? There is a large feeling on the WG that there could be a use for distinction at the message level. We all acknowledge that could be disruptive but I don't think I can agree that it would bring down a all set of applications. You say those in favor haven't brought good use cases but neither have you. - Sylvain From owner-atom-syntax@mail.imc.org Mon Dec 11 05:01:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GthyF-0003ex-Bu for atompub-archive@lists.ietf.org; Mon, 11 Dec 2006 05:01:15 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gthy9-0008G1-E4 for atompub-archive@lists.ietf.org; Mon, 11 Dec 2006 05:01:15 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBB9TVC3086820; Mon, 11 Dec 2006 02:29:31 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBB9TVuH086819; Mon, 11 Dec 2006 02:29:31 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.internode.on.net (bld-mail01.adl2.internode.on.net [203.16.214.65]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBB9TT1u086811 for ; Mon, 11 Dec 2006 02:29:30 -0700 (MST) (envelope-from arsptr@internode.on.net) Received: from [192.168.1.3] (unverified [59.167.35.114]) by mail.internode.on.net (SurgeMail 3.2f) with ESMTP id 254892467 for ; Mon, 11 Dec 2006 19:59:26 +1030 (CDT) Mime-Version: 1.0 (Apple Message framework v752.2) To: atom-syntax@imc.org Message-Id: <40B67D18-E0AB-4D65-A18D-45E16E32E1F8@internode.on.net> Content-Type: multipart/alternative; boundary=Apple-Mail-1-691101398 From: Alastair Rankine Subject: Reviving Atom Export Date: Mon, 11 Dec 2006 20:29:38 +1100 X-Mailer: Apple Mail (2.752.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 69aba9e925a1047819f53b40fa4fc4e6 --Apple-Mail-1-691101398 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed So I got a bit distracted for a bit. Here's what we were talking about. ### What is it? Atom Export is a proposal for a standard/convention/something for the export of content from a CMS (think blogging engine) in a format that is similar to other Atom standards. The assumption here is that the content being exported is a good fit for Atom. I believe this to be the case (hence discussing it on this list) but it is not established yet. More rationale, and initial attempt, here: http://girtby.net/articles/ 2006/08/14/towards-a-common-blog-export-format ### Where did we get up to? We have a list of requirements for the export format, specifically the data from a typical blogging engine that should be included in the export. We also had identified some preliminary issues with representing the content in an Atom-based document format. Lastly we had clarified some scope, namely that the primary use case should be for migrating from one content engine to another, and not necessarily for backup purposes within a single application. ### What data is to be represented by this? Here is a list of data to be included in the export. For convenience a blog engine is assumed, although other compatible CMSs may implement this as well: 1. Complete list of authors defined. For each author: 1. Name 2. URI 3. email 2. Complete list of categories defined: 1. Name 2. URI 3. All articles. For each article: 1. Source text 2. All the relevant metadata from the Atom spec, namely: author, ID, published, rights, title, updated, summary, categories 3. Some other metadata: draft status, syntax of source 4. All comments and trackbacks. For each comment or trackback: 1. Source text 2. Atom spec metadata: author, ID, title, published, summary, avatar? 3. Additional metadata: pointer to parent article or comment (ie "in-reply-to") 5. All "Owned" media. For each media object: 1. URI 2. MIME type 3. Binary data ### What are the issues identified so far? Briefly: * It was felt that the inclusion of binary media objects warrants the use of a binary archive format. The issue of how to organise the content within the archive file is unresolved. * There was some discussion about the inclusion of generated text, specifically HTML generated from the source text. It is redundant but may be useful. ### What now? I think the best way to proceed is to propose a fresh mapping of the above data requirements to Atom-derived constructs. I already had a go at this previously, but I think it might be better to start afresh. This time I'd like to try an approach based around the concepts introduced in APP, particularly that of collections, which look like a good fit for items 3,4, and 5 above. --Apple-Mail-1-691101398 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 So I got a bit distracted for a = bit. Here's what we were talking about.

### = What is it?

Atom = Export is a proposal for a standard/convention/something for the export = of content from a CMS (think blogging engine) in a format that is = similar to other Atom standards.=A0The assumption here is that the = content being exported is a good fit for Atom. I believe this to be the = case (hence discussing it on this list) but it is not established = yet.


### = Where did we get up to?

We = have a list of requirements for the export format, specifically the data = from a typical blogging engine that should be included in the export. We = also had identified some preliminary issues with representing the = content in an Atom-based document format. Lastly we had clarified some = scope, namely that the primary use case should be for migrating from one = content engine to another, and not necessarily for backup purposes = within a single application.

### = What data is to be represented by = this?

Here = is a list of data to be included in the export. For convenience a blog = engine is assumed, although other compatible CMSs may implement this as = well:

=A0 =A01. = Complete list of authors defined. For each = author:
=A0=A0= =A0 =A0 =A0 1. = Name
=A0=A0= =A0 =A0 =A0 2. = URI
=A0=A0= =A0 =A0 =A0 3. = email
=A0=A0= 2. Complete list of categories = defined:
=A0=A0= =A0 =A0 =A0 1. = Name
=A0=A0= =A0 =A0 =A0 2. = URI
=A0=A0= 3. All articles. For each = article:
=A0=A0= =A0 =A0 =A0 1. Source = text
=A0=A0= =A0 =A0 =A0 2. All the relevant metadata = from the Atom spec, namely: author, ID, published, rights, title, = updated, summary, categories
=A0=A0 =A0 =A0 =A0 = 3. Some other metadata: draft = status, syntax of source
=A0=A0 = 4. All comments and trackbacks. = For each comment or trackback:
=A0=A0 =A0 =A0 =A0 = 1. Source = text
=A0=A0= =A0 =A0 =A0 2. Atom spec metadata: author, = ID, title, published, summary, avatar?
=A0=A0 =A0 =A0 =A0 = 3. Additional metadata: pointer = to parent article or comment (ie = "in-reply-to")
=A0=A0= 5. All "Owned" media. For each = media object:
=A0=A0= =A0 =A0 =A0 1. = URI
=A0=A0= =A0 =A0 =A0 2. MIME = type
=A0=A0= =A0 =A0 =A0 3. Binary = data

### = What are the issues identified so far?

Briefly:

=A0* It was felt that the = inclusion of binary media objects warrants the use of a binary archive = format. The issue of how to organise the content within the archive file = is unresolved.
=A0* = There was some discussion about the inclusion of generated text, = specifically HTML generated from the source text. It is redundant but = may be useful.
### What = now?
I = think the best way to proceed is to propose a fresh mapping of the above = data requirements to Atom-derived constructs. I already had a go at this = previously, but I think it might be better to start afresh. This time = I'd like to try an approach based around the concepts introduced in APP, = particularly that of collections, which look like a good fit for items = 3,4, and 5 above.

= --Apple-Mail-1-691101398-- From owner-atom-syntax@mail.imc.org Mon Dec 11 05:23:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtiJn-0003is-1G for atompub-archive@lists.ietf.org; Mon, 11 Dec 2006 05:23:31 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtiJg-0000oG-KF for atompub-archive@lists.ietf.org; Mon, 11 Dec 2006 05:23:31 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBBA3a0N091519; Mon, 11 Dec 2006 03:03:36 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBBA3aaY091518; Mon, 11 Dec 2006 03:03:36 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBBA3ZVD091505 for ; Mon, 11 Dec 2006 03:03:36 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.213.125] (unknown [193.120.101.26]) by chilco.textdrive.com (Postfix) with ESMTP id 08AEEDB796 for ; Mon, 11 Dec 2006 10:03:29 +0000 (UTC) Message-ID: <457D2CEE.5030902@dehora.net> Date: Mon, 11 Dec 2006 10:03:26 +0000 From: Bill de hOra User-Agent: Thunderbird 1.5.0.8 (X11/20061117) MIME-Version: 1.0 To: Atom Syntax Subject: Re: PaceEntryMediatype References: <3f1451f50612101926s1595f9c6kc63ca0128d0ad413@mail.gmail.com> <45be5cd40612102107o1806d693vf21365a6e40d20ba@mail.gmail.com> In-Reply-To: <45be5cd40612102107o1806d693vf21365a6e40d20ba@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: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Bob Wyman wrote: > The impact here is not just limited to APP implementations. If a new > media type is defined, it will undoubtedly appear in other contexts as > well. Given the current definition of the atom syntax, it is perfectly > reasonable for an "aggregator" to treat a single entry as the semantic > equivelant of a single-entry feed. I don't agree. atom:source is optional, and even then that does not cater for situations where entries have been annotated downstream. > If a new media type is defined, such > an application would end up having to be modified. That's not right... > APP is not the only context within which Atom is used. What matters is whether atom:feed is the only context within which atom:entry is used, and/or whether atom:entry is an atom:feed in masquerade. After who knows how many posts and having gone back to the RFC, as I see it, neither of those is true or supported by the spec. There'll have to be another rationale presented for not spinning out a new media type. cheers Bill From owner-atom-syntax@mail.imc.org Mon Dec 11 05:23:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtiJp-0003jK-6v for atompub-archive@lists.ietf.org; Mon, 11 Dec 2006 05:23:33 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtiJn-0000rJ-Rf for atompub-archive@lists.ietf.org; Mon, 11 Dec 2006 05:23:33 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBBA4QA8091745; Mon, 11 Dec 2006 03:04:26 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBBA4QWR091744; Mon, 11 Dec 2006 03:04:26 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBBA4Qfh091711 for ; Mon, 11 Dec 2006 03:04:26 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.213.125] (unknown [193.120.101.26]) by chilco.textdrive.com (Postfix) with ESMTP id 93E35DC739 for ; Mon, 11 Dec 2006 10:04:20 +0000 (UTC) Message-ID: <457D2D21.20608@dehora.net> Date: Mon, 11 Dec 2006 10:04:17 +0000 From: Bill de hOra User-Agent: Thunderbird 1.5.0.8 (X11/20061117) MIME-Version: 1.0 To: Atom Syntax Subject: Re: PaceEntryMediatype References: <3f1451f50612101926s1595f9c6kc63ca0128d0ad413@mail.gmail.com> <45be5cd40612102107o1806d693vf21365a6e40d20ba@mail.gmail.com> <457D0C6F.2020603@defuze.org> In-Reply-To: <457D0C6F.2020603@defuze.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: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Sylvain Hellegouarch wrote: > I still don't understand the meaning of equivalence between an entry > document and a single-entry-feed document. You don't need to; it doesn't exist. This is string theory for syndication. cheers Bill From owner-atom-syntax@mail.imc.org Mon Dec 11 12:26:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtov1-0008Ti-O2 for atompub-archive@lists.ietf.org; Mon, 11 Dec 2006 12:26:23 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gtouu-0001x6-GV for atompub-archive@lists.ietf.org; Mon, 11 Dec 2006 12:26:23 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBBH71HT045950; Mon, 11 Dec 2006 10:07:01 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBBH71a4045949; Mon, 11 Dec 2006 10:07:01 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from csmtp1.b-one.net (csmtp.b-one.net [195.47.247.21]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBBH70v1045933 for ; Mon, 11 Dec 2006 10:07:01 -0700 (MST) (envelope-from asbjorn@tigerstaden.no) Received: from quark (72.84-48-117.nextgentel.com [84.48.117.72]) by csmtp1.b-one.net (Postfix) with ESMTP id 5E7C51911FBC9; Mon, 11 Dec 2006 18:06:54 +0100 (CET) Date: Mon, 11 Dec 2006 18:08:31 +0100 To: "James M Snell" , atom-syntax Subject: Re: Atom Entry Documents From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <457C5DD9.9070309@gmail.com> Message-ID: In-Reply-To: <457C5DD9.9070309@gmail.com> User-Agent: Opera Mail/9.10 (Win32) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id kBBH71HT045950 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 On Sun, 10 Dec 2006 20:19:53 +0100, James M Snell =20 wrote: > Option A) Optional Type Param > > application/atom+xml; type=3Dentry > application/atom+xml; type=3Dfeed +1. I believe that a type parameter allows more smoothly for new types to= =20 be introduced in the future, plus it more clearly states that it is an =20 Atom resource than a completely new MIME type. All in my humble opinion o= f =20 course. This is just a matter of taste, afaict. --=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 Dec 11 14:03:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtqR7-0008Td-23 for atompub-archive@lists.ietf.org; Mon, 11 Dec 2006 14:03:37 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtqR5-0003nx-DG for atompub-archive@lists.ietf.org; Mon, 11 Dec 2006 14:03:37 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBBIVtLq059260; Mon, 11 Dec 2006 11:31:55 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBBIVtvZ059257; Mon, 11 Dec 2006 11:31:55 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.230]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBBIVrCL059243 for ; Mon, 11 Dec 2006 11:31:54 -0700 (MST) (envelope-from judy.piper@gmail.com) Received: by wx-out-0506.google.com with SMTP id i30so1551274wxd for ; Mon, 11 Dec 2006 10:31:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=M3DLXvmpIeMNrcGByMfEBjFH/ay6hYvYOvpgnVMR7OqfH9opBViPRPFD0bpITqtOCQKUYX+SRDzFVVzcAwdNxSVS6hhc9AVaxYgweRQ+AECQKiCuh/tFikdZbsS5O5CdW5XfIBmWMefy0KdJNcgKry/F8LY8KrlLuG3oHOru8v4= Received: by 10.90.68.15 with SMTP id q15mr7198369aga.1165861912995; Mon, 11 Dec 2006 10:31:52 -0800 (PST) Received: by 10.90.51.10 with HTTP; Mon, 11 Dec 2006 10:31:52 -0800 (PST) Message-ID: Date: Mon, 11 Dec 2006 13:31:52 -0500 From: "Judy Piper" To: "James M Snell" Subject: Re: Atom Entry Documents Cc: atom-syntax In-Reply-To: <457C5DD9.9070309@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_69224_25432350.1165861912849" References: <457C5DD9.9070309@gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 ------=_Part_69224_25432350.1165861912849 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline >Option A) Optional Type Param > >application/atom+xml; type=entry >application/atom+xml; type=feed +1 IMO, new optional type parameters make more sense. Judy- On 12/10/06, James M Snell wrote: > > > Ok, the recent discussion seems to point towards a consensus towards > distinctly flagging Entry Documents in the media type. The only > question is whether or not to use a new media type or an optional type > param. I'm going to write up an I-D this week. > > Please let me know which of the two approaches below y'all prefer... > > Option A) Optional Type Param > > application/atom+xml; type=entry > application/atom+xml; type=feed > > > Option B) New Entry media type > > application/atom.entry+xml > > > - James > > ------=_Part_69224_25432350.1165861912849 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline >Option A) Optional Type Param
>
  >application/atom+xml; type=entry
  >application/atom+xml; type=feed

+1

IMO, new optional type parameters make more sense. 
Judy-

On 12/10/06, James M Snell <jasnell@gmail.com> wrote:

Ok, the recent discussion seems to point towards a consensus towards
distinctly flagging Entry Documents in the media type.  The only
question is whether or not to use a new media type or an optional type
param.  I'm going to write up an I-D this week.

Please let me know which of the two approaches below y'all prefer...

Option A) Optional Type Param

  application/atom+xml; type=entry
  application/atom+xml; type=feed


Option B) New Entry media type

  application/atom.entry+xml


- James


------=_Part_69224_25432350.1165861912849-- From owner-atom-syntax@mail.imc.org Mon Dec 11 14:23:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtqkW-0001Jn-2Z for atompub-archive@lists.ietf.org; Mon, 11 Dec 2006 14:23:40 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtqkU-0006ns-JK for atompub-archive@lists.ietf.org; Mon, 11 Dec 2006 14:23:40 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBBIu4Qd061795; Mon, 11 Dec 2006 11:56:04 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBBIu4Jh061794; Mon, 11 Dec 2006 11:56:04 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBBIu1NK061771 for ; Mon, 11 Dec 2006 11:56:03 -0700 (MST) (envelope-from prabhaka@apple.com) Received: from relay6.apple.com (relay6.apple.com [17.128.113.36]) by mail-out4.apple.com (8.13.6/8.13.6) with ESMTP id kBBItsHK005942; Mon, 11 Dec 2006 10:55:54 -0800 (PST) Received: from [17.203.42.167] (unknown [17.203.42.167]) by relay6.apple.com (Apple SCV relay) with ESMTP id AC798123; Mon, 11 Dec 2006 10:55:53 -0800 (PST) In-Reply-To: <457C5DD9.9070309@gmail.com> References: <457C5DD9.9070309@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Ernest Prabhakar Subject: Re: Atom Entry Documents Date: Mon, 11 Dec 2006 10:55:54 -0800 To: James M Snell X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f On Dec 10, 2006, at 11:19 AM, James M Snell wrote: > Option B) New Entry media type > > application/atom.entry+xml > +1 I presume the whole reason we need this is that *existing* parsers are "blindly" assuming that application/atom+xml means a feed document. If that is an invalid assumption, then I think (B) is the way to go. If not, them I'm unclear what the problem is. -- Ernie P. From owner-atom-syntax@mail.imc.org Mon Dec 11 15:19:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtrcU-0004C8-Ee for atompub-archive@lists.ietf.org; Mon, 11 Dec 2006 15:19:26 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtrcR-0008M9-4X for atompub-archive@lists.ietf.org; Mon, 11 Dec 2006 15:19:26 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBBIuVVc061824; Mon, 11 Dec 2006 11:56:31 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBBIuVCV061823; Mon, 11 Dec 2006 11:56:31 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBBIuUtP061817 for ; Mon, 11 Dec 2006 11:56:30 -0700 (MST) (envelope-from kmarvin@google.com) Received: from spaceape10.eur.corp.google.com (spaceape10.eur.corp.google.com [172.28.16.144]) by smtp-out.google.com with ESMTP id kBBIuOor012500 for ; Mon, 11 Dec 2006 18:56:24 GMT DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:references; b=UC4Vdc1T5MaimcFMSAFTuuTNVRHHHrwtdhkWLYWFR2szoesazvITLsoEF5SXNUdde Zo3omngZ+NYox3jGGWLkQ== Received: from nz-out-0102.google.com (nzdx3.prod.google.com [10.36.150.3]) by spaceape10.eur.corp.google.com with ESMTP id kBBItUjC002647 for ; Mon, 11 Dec 2006 18:56:16 GMT Received: by nz-out-0102.google.com with SMTP id x3so895624nzd for ; Mon, 11 Dec 2006 10:56:16 -0800 (PST) Received: by 10.65.154.2 with SMTP id g2mr11425449qbo.1165863375793; Mon, 11 Dec 2006 10:56:15 -0800 (PST) Received: by 10.64.183.12 with HTTP; Mon, 11 Dec 2006 10:56:15 -0800 (PST) Message-ID: <192fc9640612111056j64a9e618m20f9d72dbacd5e1d@mail.gmail.com> Date: Mon, 11 Dec 2006 12:56:15 -0600 From: "Kyle Marvin" To: "James M Snell" Subject: Re: Atom Entry Documents Cc: atom-syntax In-Reply-To: <457C5DD9.9070309@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_77130_4054040.1165863375634" References: <457C5DD9.9070309@gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: -0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 ------=_Part_77130_4054040.1165863375634 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 12/10/06, James M Snell wrote: > > > Ok, the recent discussion seems to point towards a consensus towards > distinctly flagging Entry Documents in the media type. The only > question is whether or not to use a new media type or an optional type > param. I'm going to write up an I-D this week. > > Please let me know which of the two approaches below y'all prefer... > > Option A) Optional Type Param > > application/atom+xml; type=entry > application/atom+xml; type=feed +1. I believe other UA-visible Atom document syntax qualifiers will be needed/coming downstream. For example. ones describing the expected extension model(s) of the target Atom document. Feed vs. entry is just one syntax variant of an Atom document, others of UA interest might be "this is an Atom document containing OpenSearch results" or "this is an Atom Document that describes media using Media RSS extensions". I'm not sure that treating each syntax variant as a unique MIME type is a scalable approach for the long haul. One specific issue is that you will also have to deal with combinations (ex "this Atom document is a feed that contains OpenSearch results listing Media RSS entries"). Cheers! -- Kyle ------=_Part_77130_4054040.1165863375634 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 12/10/06, James M Snell <jasnell@gmail.com> wrote:

Ok, the recent discussion seems to point towards a consensus towards
distinctly flagging Entry Documents in the media type.  The only
question is whether or not to use a new media type or an optional type
param.  I'm going to write up an I-D this week.

Please let me know which of the two approaches below y'all prefer...

Option A) Optional Type Param

  application/atom+xml; type=entry
  application/atom+xml; type=feed


+1.   I believe other UA-visible Atom document syntax qualifiers will be needed/coming downstream.  For example. ones describing the expected extension model(s) of the target Atom document.  Feed vs. entry is just one syntax variant of an Atom document, others of UA interest might be "this is an Atom document containing OpenSearch results" or "this is an Atom Document that describes media using Media RSS extensions". 

I'm not sure that treating each syntax variant as a unique MIME type is a scalable approach for the long haul.  One specific issue is that you will also have to deal with combinations (ex "this Atom document is a feed that contains OpenSearch results listing Media RSS entries").

Cheers!

-- Kyle


------=_Part_77130_4054040.1165863375634-- From owner-atom-syntax@mail.imc.org Mon Dec 11 19:57:47 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtvxr-0007V2-IF for atompub-archive@lists.ietf.org; Mon, 11 Dec 2006 19:57:47 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GtvxT-0001AB-QP for atompub-archive@lists.ietf.org; Mon, 11 Dec 2006 19:57:30 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBC0KCmm098853; Mon, 11 Dec 2006 17:20:12 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBC0KCPp098852; Mon, 11 Dec 2006 17:20:12 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scmailgw2.scop.aoyama.ac.jp (scmailgw2.scop.aoyama.ac.jp [133.2.251.195]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBC0KAxs098836 for ; Mon, 11 Dec 2006 17:20:12 -0700 (MST) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id kBC0K4To028542 for ; Tue, 12 Dec 2006 09:20:05 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 62d9_83d8d8c0_8976_11db_8021_0014221fa3c9; Tue, 12 Dec 2006 09:20:04 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:59143) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 12 Dec 2006 09:19:25 +0900 Message-Id: <6.0.0.20.2.20061211164851.05f22810@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 11 Dec 2006 16:49:03 +0900 To: "Franklin Tse" , "'atom-syntax'" From: Martin Duerst Subject: RE: Atom Entry Documents In-Reply-To: References: <457C5DD9.9070309@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: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 At 10:32 06/12/11, Franklin Tse wrote: > >> Option B) New Entry media type > >> application/atom.entry+xml > >+1 +1 #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From owner-atom-syntax@mail.imc.org Mon Dec 11 21:34:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtxT1-00077a-Dx for atompub-archive@lists.ietf.org; Mon, 11 Dec 2006 21:34:03 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtxSw-0004Lg-09 for atompub-archive@lists.ietf.org; Mon, 11 Dec 2006 21:34:03 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBC25HGX009482; Mon, 11 Dec 2006 19:05:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBC25H2b009481; Mon, 11 Dec 2006 19:05:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironclad.net.au ([203.30.247.11]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id kBC25DOb009468 for ; Mon, 11 Dec 2006 19:05:16 -0700 (MST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.118] (HELO [192.168.1.2]) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.0007428887 for ; Tue, 12 Dec 2006 13:04:57 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 12 Dec 2006 13:05:10 +1100 Subject: Re: Atom Entry Documents From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <192fc9640612111056j64a9e618m20f9d72dbacd5e1d@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: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 On 12/12/06 5:56 AM, "Kyle Marvin" wrote: >> application/atom+xml; type=entry >> application/atom+xml; type=feed > I believe other UA-visible Atom document syntax qualifiers will be > needed/coming downstream. For example. ones describing the expected extension > model(s) of the target Atom document. Feed vs. entry is just one syntax > variant of an Atom document, others of UA interest might be "this is an Atom > document containing OpenSearch results" or "this is an Atom Document that > describes media using Media RSS extensions". I'm not so sure. I see the difference between the two being "one" vs "many", and nothing more. What you want could however be accommodated by additional parameters.. > I'm not sure that treating each syntax variant as a unique MIME type is a > scalable approach for the long haul. One specific issue is that you will also > have to deal with combinations (ex "this Atom document is a feed that contains > OpenSearch results listing Media RSS entries"). application/atom+xml; type=feed,option=OpenSearch,option=MediaRSS (or syntax to that effect) e. From owner-atom-syntax@mail.imc.org Mon Dec 11 22:39:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtyUd-0002g7-Oc for atompub-archive@lists.ietf.org; Mon, 11 Dec 2006 22:39:47 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtyUZ-0002Gy-WE for atompub-archive@lists.ietf.org; Mon, 11 Dec 2006 22:39:47 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBC3QwBS019043; Mon, 11 Dec 2006 20:26:58 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBC3QwB2019042; Mon, 11 Dec 2006 20:26:58 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBC3QurZ019036 for ; Mon, 11 Dec 2006 20:26:57 -0700 (MST) (envelope-from mbaker@gmail.com) Received: by ug-out-1314.google.com with SMTP id j3so1823059ugf for ; Mon, 11 Dec 2006 19:26:55 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=pri+V/eBNHEnVzJhTacROjIkEVYyMxXeLyqZZZSJYUA6z2G+E8waWNMTeI7UYJkfBbV+xW+nViY+nN2HhBDQMUEJtno0f8nLddGC63ZN4rlS/21Kid+PssIHlJeb/0ASh8LqptM1Z6/0pltp61P4bxDX3XiBs4SAh6uV34UpuCU= Received: by 10.78.127.3 with SMTP id z3mr2000604huc.1165894015082; Mon, 11 Dec 2006 19:26:55 -0800 (PST) Received: by 10.78.174.19 with HTTP; Mon, 11 Dec 2006 19:26:55 -0800 (PST) Message-ID: Date: Mon, 11 Dec 2006 22:26:55 -0500 From: "Mark Baker" To: "James M Snell" Subject: Re: Atom Entry Documents Cc: atom-syntax In-Reply-To: <457C5DD9.9070309@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <457C5DD9.9070309@gmail.com> X-Google-Sender-Auth: 7436b471998eeed4 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 On 12/10/06, James M Snell wrote: > Ok, the recent discussion seems to point towards a consensus towards > distinctly flagging Entry Documents in the media type. Erm, isn't it up to the chairs to declare concensus? AFAICT, the discussion I was involved in failed to achieve it. If I'm mistaken, I'll be happy to put in my 2c on a solution of course. Mark. From owner-atom-syntax@mail.imc.org Mon Dec 11 22:46:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtyax-0004id-UZ for atompub-archive@lists.ietf.org; Mon, 11 Dec 2006 22:46:19 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gtyas-0004DV-Fs for atompub-archive@lists.ietf.org; Mon, 11 Dec 2006 22:46:19 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBC3X3rn019987; Mon, 11 Dec 2006 20:33:03 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBC3X3Ek019986; Mon, 11 Dec 2006 20:33:03 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBC3X2xq019979 for ; Mon, 11 Dec 2006 20:33:03 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i20so842935wra for ; Mon, 11 Dec 2006 19:33:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=GNE9ZW1Lb/7ziwOzM1oQIWrvcnpxhYIx2PvF0QT8f/FqjnrCwx1Jqr3CtRaI7Wb0gIxmlpeBz1SmCjbmwY7sSEO9R/ZBmIDbLPxJeFK26938RruoI3iZ3CD9pgSaDFrQNKF8Ey+OJb7WJ0cfG+xl7AcUteLEmZ2gmdyVciJ4CK4= Received: by 10.90.83.14 with SMTP id g14mr7810134agb.1165894381775; Mon, 11 Dec 2006 19:33:01 -0800 (PST) Received: from ?192.168.1.109? ( [67.181.218.96]) by mx.google.com with ESMTP id 8sm9509629wrl.2006.12.11.19.33.00; Mon, 11 Dec 2006 19:33:01 -0800 (PST) Message-ID: <457E22E9.3010805@gmail.com> Date: Mon, 11 Dec 2006 19:32:57 -0800 From: James M Snell User-Agent: Thunderbird 1.5.0.8 (X11/20061115) MIME-Version: 1.0 To: Mark Baker CC: atom-syntax Subject: Re: Atom Entry Documents References: <457C5DD9.9070309@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Mark Baker wrote: > On 12/10/06, James M Snell wrote: >> Ok, the recent discussion seems to point towards a consensus towards >> distinctly flagging Entry Documents in the media type. > > Erm, isn't it up to the chairs to declare concensus? > The I-D would be an individual draft, not a WG draft. The chairs only decide consensus on WG stuff. Once I get the initial version of the draft up, we can see if it makes sense to move it forward as a WG draft, in which case, I'll gladly let the chairs handle it. :-) > AFAICT, the discussion I was involved in failed to achieve it. If I'm > mistaken, I'll be happy to put in my 2c on a solution of course. > I think there was consensus that some form of mechanism for identifying entry documents would be helpful. Where I see a lack of consensus is on the specific mechanism to use. - James From owner-atom-syntax@mail.imc.org Tue Dec 12 00:44:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu0RY-000828-IZ for atompub-archive@lists.ietf.org; Tue, 12 Dec 2006 00:44:44 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gu0RX-0005sf-5f for atompub-archive@lists.ietf.org; Tue, 12 Dec 2006 00:44:44 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBC5MKCs030172; Mon, 11 Dec 2006 22:22:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBC5MK6P030171; Mon, 11 Dec 2006 22:22:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.236]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBC5MJ0t030165 for ; Mon, 11 Dec 2006 22:22:19 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id i30so1677606wxd for ; Mon, 11 Dec 2006 21:22:18 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=LHAbevHlxPw4khVLINuas39dy0Sfp3gcGCy3X83FOzlhUnLPXc/hjcD7msTHiJSC46e9nqpp2ryFY2I7I8X9B10KhsFrzuTC1OC4OptrdW//njE7kZd6ltJxFLPj9U+j/gT2sxK4CRFJboimn/Lij+WmPsJc3BMIed16zqKmjt8= Received: by 10.90.75.10 with SMTP id x10mr7899952aga.1165900938614; Mon, 11 Dec 2006 21:22:18 -0800 (PST) Received: from ?192.168.1.109? ( [67.181.218.96]) by mx.google.com with ESMTP id 44sm9798999wri.2006.12.11.21.22.17; Mon, 11 Dec 2006 21:22:18 -0800 (PST) Message-ID: <457E3C86.2030105@gmail.com> Date: Mon, 11 Dec 2006 21:22:14 -0800 From: James M Snell User-Agent: Thunderbird 1.5.0.8 (X11/20061115) MIME-Version: 1.0 To: Hugh Winkler CC: atom-syntax Subject: Re: Atom Entry Documents References: <457C5DD9.9070309@gmail.com> <927441b30612111527o333399d5wc5ad0351afffa872@mail.gmail.com> In-Reply-To: <927441b30612111527o333399d5wc5ad0351afffa872@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Sure you can. Adding this to mime.types... application/atom+xml atom application/atom+xml;type=entry entry application/atom+xml;type=feed feed works just fine in apache2. Ask for a static file *.atom, and you get application/atom+xml. Ask for a static file *.entry and you get application/atom+xml;type=entry. - James Hugh Winkler wrote: >> >> application/atom.entry+xml >> >> > > Another reason for +1 for B: consider serving static files, some of > type entry, some of type feed. You can give each file type a different > extension (.atom, .atom-entry) and configure Apache to serve the > correct mime type for each. You could not configure Apache to serve > files with the right type parameter, if you choose A. > From owner-atom-syntax@mail.imc.org Tue Dec 12 01:02:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu0iM-0006yz-FE for atompub-archive@lists.ietf.org; Tue, 12 Dec 2006 01:02:06 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gu0iK-0001OS-RE for atompub-archive@lists.ietf.org; Tue, 12 Dec 2006 01:02:06 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBC5nH8B032232; Mon, 11 Dec 2006 22:49:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBC5nHIK032231; Mon, 11 Dec 2006 22:49:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.12]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBC5nGo8032218 for ; Mon, 11 Dec 2006 22:49:17 -0700 (MST) (envelope-from kmarvin@google.com) Received: from zps76.corp.google.com (zps76.corp.google.com [172.25.146.76]) by smtp-out.google.com with ESMTP id kBC5n6QG007286 for ; Mon, 11 Dec 2006 21:49:06 -0800 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:references; b=fjJaXuxl/VsZPYeHk9e/2BDuEYEv+RceZm2Bu30FX5YjYq0RhK75uQ/L1L2PfEW3F mTdYELmkW/9Z57OMttyZg== Received: from nz-out-0102.google.com (nzcx7.prod.google.com [10.36.125.7]) by zps76.corp.google.com with ESMTP id kBC5mX0H027372 for ; Mon, 11 Dec 2006 21:49:01 -0800 Received: by nz-out-0102.google.com with SMTP id x7so987451nzc for ; Mon, 11 Dec 2006 21:49:01 -0800 (PST) Received: by 10.64.125.17 with SMTP id x17mr5593013qbc.1165902541213; Mon, 11 Dec 2006 21:49:01 -0800 (PST) Received: by 10.64.183.12 with HTTP; Mon, 11 Dec 2006 21:49:01 -0800 (PST) Message-ID: <192fc9640612112149u2ee9497cid76cc09ea9a4311c@mail.gmail.com> Date: Mon, 11 Dec 2006 23:49:01 -0600 From: "Kyle Marvin" To: "Eric Scheid" Subject: Re: Atom Entry Documents Cc: "Atom Syntax" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_82404_14218949.1165902541163" References: <192fc9640612111056j64a9e618m20f9d72dbacd5e1d@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: -0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 ------=_Part_82404_14218949.1165902541163 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 12/11/06, Eric Scheid wrote: > > > On 12/12/06 5:56 AM, "Kyle Marvin" wrote: > > >> application/atom+xml; type=entry > >> application/atom+xml; type=feed > > > I believe other UA-visible Atom document syntax qualifiers will be > > needed/coming downstream. For example. ones describing the expected > extension > > model(s) of the target Atom document. Feed vs. entry is just one syntax > > variant of an Atom document, others of UA interest might be "this is an > Atom > > document containing OpenSearch results" or "this is an Atom Document > that > > describes media using Media RSS extensions". > > I'm not so sure. I see the difference between the two being "one" vs > "many", > and nothing more. What you want could however be accommodated by > additional > parameters.. Exactly. But the key point is that at some point you _need_ the additional parameters, so let's stop thinking we can cram everything into the base media type/subtype and be limited by UAs that understand them (only) and start using parameters! > I'm not sure that treating each syntax variant as a unique MIME type is a > > scalable approach for the long haul. One specific issue is that you > will also > > have to deal with combinations (ex "this Atom document is a feed that > contains > > OpenSearch results listing Media RSS entries"). > > application/atom+xml; type=feed,option=OpenSearch,option=MediaRSS > > (or syntax to that effect) Yup. Pretty close to what I was thinking. Cheers! -- Kyle ------=_Part_82404_14218949.1165902541163 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
On 12/11/06, Eric Scheid <eric.scheid@ironclad.net.au> wrote:

On 12/12/06 5:56 AM, "Kyle Marvin" <kmarvin@google.com> wrote:

>> application/atom+xml; type=entry
>> application/atom+xml; type=feed

> I believe other UA-visible Atom document syntax qualifiers will be
> needed/coming downstream.  For example. ones describing the expected extension
> model(s) of the target Atom document.  Feed vs. entry is just one syntax
> variant of an Atom document, others of UA interest might be "this is an Atom
> document containing OpenSearch results" or "this is an Atom Document that
> describes media using Media RSS extensions".

I'm not so sure. I see the difference between the two being "one" vs "many",
and nothing more. What you want could however be accommodated by additional
parameters..

Exactly.  But the key point is that at some point you _need_ the additional parameters, so let's stop thinking we can cram everything into the base media type/subtype and be limited by UAs that understand them (only) and start using parameters!

> I'm not sure that treating each syntax variant as a unique MIME type is a
> scalable approach for the long haul.  One specific issue is that you will also
> have to deal with combinations (ex "this Atom document is a feed that contains
> OpenSearch results listing Media RSS entries").

    application/atom+xml; type=feed,option=OpenSearch,option=MediaRSS

(or syntax to that effect)

Yup.   Pretty close to what I was thinking.

Cheers!

-- Kyle

 


------=_Part_82404_14218949.1165902541163-- From owner-atom-syntax@mail.imc.org Tue Dec 12 02:33:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu28d-0005gr-Hh for atompub-archive@lists.ietf.org; Tue, 12 Dec 2006 02:33:19 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gu28Z-0001m3-VZ for atompub-archive@lists.ietf.org; Tue, 12 Dec 2006 02:33:19 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBC7IWhC040507; Tue, 12 Dec 2006 00:18:32 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBC7IWfv040506; Tue, 12 Dec 2006 00:18:32 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.186]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBC7IV2u040500 for ; Tue, 12 Dec 2006 00:18:32 -0700 (MST) (envelope-from algermissen1971@mac.com) Received: from mac.com (smtpin05-en2 [10.13.10.150]) by smtpout.mac.com (Xserve/8.12.11/smtpout16/MantshX 4.0) with ESMTP id kBC7IVfg014144 for ; Mon, 11 Dec 2006 23:18:31 -0800 (PST) Received: from [10.0.1.2] (e176049110.adsl.alicedsl.de [85.176.49.110]) (authenticated bits=0) by mac.com (Xserve/smtpin05/MantshX 4.0) with ESMTP id kBC7IRSS002833 for ; Mon, 11 Dec 2006 23:18:30 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <264B46E1-B3DE-4F33-9EBE-2429B4DF2347@mac.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: atom-syntax From: Jan Algermissen Subject: Atom namespace really not ending with / or # ? Date: Tue, 12 Dec 2006 08:18:49 +0100 X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.5 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Hi, is it really true that the Atom namespace is http://www.w3.org/2005/ Atom ? Meaning that it is somewhat difficult to identify Atom elements with URIs: http://www.w3.org/2005/Atomauthor http://www.w3.org/2005/Atomconributor .... Was that simply a mistake or a design feature when Atom was standardized? Thanks, Jan From owner-atom-syntax@mail.imc.org Tue Dec 12 02:39:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu2Ef-0008Om-85 for atompub-archive@lists.ietf.org; Tue, 12 Dec 2006 02:39:33 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gu2Ea-0002mu-Q4 for atompub-archive@lists.ietf.org; Tue, 12 Dec 2006 02:39:33 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBC7MK6H040889; Tue, 12 Dec 2006 00:22:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBC7MKG9040888; Tue, 12 Dec 2006 00:22:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBC7MJ22040882 for ; Tue, 12 Dec 2006 00:22:20 -0700 (MST) (envelope-from mnot@mnot.net) Received: from [192.168.1.3] (unknown [71.131.50.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 4A2EA5193C; Tue, 12 Dec 2006 02:22:17 -0500 (EST) In-Reply-To: <457E22E9.3010805@gmail.com> References: <457C5DD9.9070309@gmail.com> <457E22E9.3010805@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Cc: Mark Baker , atom-syntax Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: Atom Entry Documents Date: Mon, 11 Dec 2006 23:22:16 -0800 To: James M Snell X-Mailer: Apple Mail (2.752.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 What would the relationship of that document be to RFC4287? Cheers, On 2006/12/11, at 7:32 PM, James M Snell wrote: > The I-D would be an individual draft, not a WG draft. -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Tue Dec 12 03:03:35 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu2bv-0001aw-Pm for atompub-archive@lists.ietf.org; Tue, 12 Dec 2006 03:03:35 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gu2bt-0001fl-7I for atompub-archive@lists.ietf.org; Tue, 12 Dec 2006 03:03:35 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBC7dU6g042479; Tue, 12 Dec 2006 00:39:30 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBC7dULK042478; Tue, 12 Dec 2006 00:39:30 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.237]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBC7dTec042472 for ; Tue, 12 Dec 2006 00:39:29 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id i30so1702830wxd for ; Mon, 11 Dec 2006 23:39:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=CZix/E4B6++6MiaRBiUjR8nIytFj2VriYxMl5rq7iI7CH0hK6Bxys8kJlzcvw2NU3reuXBQtVtzjHvDj1QdW+DoQ0SlGW717zu8/sELK0YEDUNPbRV7rlF9jkeZqFK9bTmQUj2ciPh1eCwbUF+2hJxI2S+gw0CYPmYSzs3aUYBk= Received: by 10.90.83.14 with SMTP id g14mr7935294agb.1165909168946; Mon, 11 Dec 2006 23:39:28 -0800 (PST) Received: from ?192.168.1.109? ( [67.181.218.96]) by mx.google.com with ESMTP id 12sm14326956wrl.2006.12.11.23.39.27; Mon, 11 Dec 2006 23:39:28 -0800 (PST) Message-ID: <457E5CAD.8010605@gmail.com> Date: Mon, 11 Dec 2006 23:39:25 -0800 From: James M Snell User-Agent: Thunderbird 1.5.0.8 (X11/20061115) MIME-Version: 1.0 To: Mark Nottingham CC: Mark Baker , atom-syntax Subject: Re: Atom Entry Documents References: <457C5DD9.9070309@gmail.com> <457E22E9.3010805@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d *If* the document proceeds to Proposed Standard, the new RFC would update RFC4287 either by adding a new type param or by deprecating the use of application/atom+xml for atom entry documents in favor of a new media type. No other part of RFC4287 would be affected. Ideally, I would much rather this be a WG draft. I pinged Tim about it the other day and he suggested that I go ahead with a I-D for now and that we can explore whether or not to move forward with it as a WG draft later. - James Mark Nottingham wrote: > What would the relationship of that document be to RFC4287? > > Cheers, > > > On 2006/12/11, at 7:32 PM, James M Snell wrote: > >> The I-D would be an individual draft, not a WG draft. > > > -- > Mark Nottingham http://www.mnot.net/ > > From owner-atom-syntax@mail.imc.org Tue Dec 12 03:13:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu2lp-0006tM-6L for atompub-archive@lists.ietf.org; Tue, 12 Dec 2006 03:13:49 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gu2lk-0004s2-MC for atompub-archive@lists.ietf.org; Tue, 12 Dec 2006 03:13:49 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBC7um7W044701; Tue, 12 Dec 2006 00:56:48 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBC7umJ9044700; Tue, 12 Dec 2006 00:56:48 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sam.opera.com (sam.opera.com [193.69.113.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBC7uiaQ044682 for ; Tue, 12 Dec 2006 00:56:47 -0700 (MST) (envelope-from annevk@opera.com) Received: from id-c0020 (5352D470.cable.casema.nl [83.82.212.112]) (authenticated bits=0) by sam.opera.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id kBC7ugDJ012947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Dec 2006 07:56:42 GMT Date: Tue, 12 Dec 2006 08:56:40 +0100 To: "Jan Algermissen" , atom-syntax Subject: Re: Atom namespace really not ending with / or # ? From: "Anne van Kesteren" Organization: Opera Software Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <264B46E1-B3DE-4F33-9EBE-2429B4DF2347@mac.com> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <264B46E1-B3DE-4F33-9EBE-2429B4DF2347@mac.com> User-Agent: Opera Mail/9.02 (Win32) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a On Tue, 12 Dec 2006 08:18:49 +0100, Jan Algermissen wrote: > is it really true that the Atom namespace is http://www.w3.org/2005/Atom > ? Yes. > Meaning that it is somewhat difficult to identify Atom elements with > URIs: > > http://www.w3.org/2005/Atomauthor > http://www.w3.org/2005/Atomconributor > .... Isn't that only relevant for RDF vocabularies? > Was that simply a mistake or a design feature when Atom was standardized? It wasn't really relevant, I'd say. (That it says "Atom" and not "atom" was a mistake.) -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Tue Dec 12 03:29:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu31T-0005Ir-SM for atompub-archive@lists.ietf.org; Tue, 12 Dec 2006 03:29:59 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gu31O-0000fm-Fe for atompub-archive@lists.ietf.org; Tue, 12 Dec 2006 03:29:59 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBC8GOZ0046966; Tue, 12 Dec 2006 01:16:24 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBC8GO8X046965; Tue, 12 Dec 2006 01:16:24 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBC8GLq1046958 for ; Tue, 12 Dec 2006 01:16:24 -0700 (MST) (envelope-from alexander.johannesen@gmail.com) Received: by nf-out-0910.google.com with SMTP id m18so168428nfc for ; Tue, 12 Dec 2006 00:16:20 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JoLz5nZdBHXYdbJoCiOIxHiBVAatO1dNum5z/xcyxfEJs2/hocCKCUIPbkzr3lc98TP4t/2t/Fdt7z2OCx7/6W2zHEJO2dkInqoC8Ij3bGvVttgiuXs6TPpdQP2iRZMqyd4W+pDx9LRyKo0vA+Jg9AOa7FpBp7EDG6HkALXXc9M= Received: by 10.82.138.6 with SMTP id l6mr611321bud.1165911380055; Tue, 12 Dec 2006 00:16:20 -0800 (PST) Received: by 10.82.189.11 with HTTP; Tue, 12 Dec 2006 00:16:19 -0800 (PST) Message-ID: Date: Tue, 12 Dec 2006 19:16:19 +1100 From: "Alexander Johannesen" To: "Anne van Kesteren" Subject: Re: Atom namespace really not ending with / or # ? Cc: "Jan Algermissen" , atom-syntax In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <264B46E1-B3DE-4F33-9EBE-2429B4DF2347@mac.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab > > http://www.w3.org/2005/Atomauthor > > http://www.w3.org/2005/Atomconributor > > .... On 12/12/06, Anne van Kesteren wrote: > Isn't that only relevant for RDF vocabularies? No, it's relevant for all types of XML work, from XLink to Topic Maps to XHTML. But there's a difference between http://www.w3.org/2005/Atom used as a namespace declaration and a document pointer, though. For a lot of us data modeling types it would be good to use bits of the Atom spec in controlled vocabularies, for example, and we mix these types of models up all the time. Umm, at least I do. :) Alex -- "Ultimately, all things are known because you want to believe you know." - Frank Herbert __ http://shelter.nu/ __________________________________________________ From owner-atom-syntax@mail.imc.org Tue Dec 12 09:47:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu8uh-0005pY-SW for atompub-archive@lists.ietf.org; Tue, 12 Dec 2006 09:47:23 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gu8uZ-0004aF-Km for atompub-archive@lists.ietf.org; Tue, 12 Dec 2006 09:47:23 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBCEQCus093986; Tue, 12 Dec 2006 07:26:12 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBCEQCtl093985; Tue, 12 Dec 2006 07:26:12 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBCEQ9jp093965 for ; Tue, 12 Dec 2006 07:26:12 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.213.125] (unknown [193.120.101.26]) by chilco.textdrive.com (Postfix) with ESMTP id 87074DC751 for ; Tue, 12 Dec 2006 14:26:03 +0000 (UTC) Message-ID: <457EBBF7.4040507@dehora.net> Date: Tue, 12 Dec 2006 14:25:59 +0000 From: Bill de hOra User-Agent: Thunderbird 1.5.0.8 (X11/20061117) MIME-Version: 1.0 To: atom-syntax Subject: Re: Atom namespace really not ending with / or # ? References: <264B46E1-B3DE-4F33-9EBE-2429B4DF2347@mac.com> In-Reply-To: <264B46E1-B3DE-4F33-9EBE-2429B4DF2347@mac.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: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Jan Algermissen wrote: > > Hi, > > is it really true that the Atom namespace is http://www.w3.org/2005/Atom ? > > Meaning that it is somewhat difficult to identify Atom elements with URIs: > > http://www.w3.org/2005/Atomauthor > http://www.w3.org/2005/Atomconributor > .... > > > Was that simply a mistake or a design feature when Atom was standardized? Thinks I asked for a trailing '/' at some point; certainly for fnalising APP, I want a trailing '/'. cheers Bill From owner-atom-syntax@mail.imc.org Tue Dec 12 11:10:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuADR-0005a4-80 for atompub-archive@lists.ietf.org; Tue, 12 Dec 2006 11:10:49 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuADP-0004gz-Qe for atompub-archive@lists.ietf.org; Tue, 12 Dec 2006 11:10:49 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBCFm2Zs004534; Tue, 12 Dec 2006 08:48:02 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBCFm2OF004533; Tue, 12 Dec 2006 08:48:02 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBCFm0Ga004524 for ; Tue, 12 Dec 2006 08:48:01 -0700 (MST) (envelope-from kmarvin@google.com) Received: from spaceape11.eur.corp.google.com (spaceape11.eur.corp.google.com [172.28.16.145]) by smtp-out.google.com with ESMTP id kBCFlsCN030507 for ; Tue, 12 Dec 2006 15:47:54 GMT DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:references; b=h7uyYQDBb1INKDudBGo8LF5xIXqofwCfaYP5FAvCma9VeC1/4z4CxV+oFknqOAfr/ W8mSx9c4GvzR4zqOAAcAA== Received: from nz-out-0102.google.com (nzdz6.prod.google.com [10.36.152.6]) by spaceape11.eur.corp.google.com with ESMTP id kBCFlPtO017684 for ; Tue, 12 Dec 2006 15:47:48 GMT Received: by nz-out-0102.google.com with SMTP id z6so1082077nzd for ; Tue, 12 Dec 2006 07:47:47 -0800 (PST) Received: by 10.65.43.5 with SMTP id v5mr13373287qbj.1165938467085; Tue, 12 Dec 2006 07:47:47 -0800 (PST) Received: by 10.64.183.12 with HTTP; Tue, 12 Dec 2006 07:47:46 -0800 (PST) Message-ID: <192fc9640612120747n5cc01ca5y272598b5bfdabd5e@mail.gmail.com> Date: Tue, 12 Dec 2006 09:47:46 -0600 From: "Kyle Marvin" To: "Mark Nottingham" Subject: Re: Atom Entry Documents Cc: "James M Snell" , "Mark Baker" , atom-syntax In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_88627_14003442.1165938466873" References: <457C5DD9.9070309@gmail.com> <457E22E9.3010805@gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: -0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca ------=_Part_88627_14003442.1165938466873 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Mark, I realize the question is part process and part technical, but here's my wish for the technical portion: I'm hoping that whatever is done can be additive and optional, such that it can enable new capabilities without disrupting existing usage of 4287 (only). This is one of the reasons why I prefer that we use optional type qualifiers (Option A) rather than deprecating one mime type and creating two new ones (Option B). Cheers! -- Kyle On 12/12/06, Mark Nottingham wrote: > > > What would the relationship of that document be to RFC4287? > > Cheers, > > > On 2006/12/11, at 7:32 PM, James M Snell wrote: > > > The I-D would be an individual draft, not a WG draft. > > > -- > Mark Nottingham http://www.mnot.net/ > > ------=_Part_88627_14003442.1165938466873 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Mark,

I realize the question is part process and part technical, but here's my wish for the technical portion:  I'm hoping that whatever is done can be additive and optional, such that it can enable new capabilities without disrupting existing usage of 4287 (only). 

This is one of the reasons why I prefer that we use optional type qualifiers (Option A) rather than deprecating one mime type and creating two new ones (Option B).

Cheers!

-- Kyle

On 12/12/06, Mark Nottingham <mnot@mnot.net> wrote:

What would the relationship of that document be to RFC4287?

Cheers,


On 2006/12/11, at 7:32 PM, James M Snell wrote:

> The I-D would be an individual draft, not a WG draft.


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


------=_Part_88627_14003442.1165938466873-- From owner-atom-syntax@mail.imc.org Tue Dec 12 12:18:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuBGi-0000kR-1d for atompub-archive@lists.ietf.org; Tue, 12 Dec 2006 12:18:16 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuBGg-0000Jf-Lv for atompub-archive@lists.ietf.org; Tue, 12 Dec 2006 12:18:16 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBCGkJji010568; Tue, 12 Dec 2006 09:46:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBCGkJYC010567; Tue, 12 Dec 2006 09:46:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBCGkIUZ010560 for ; Tue, 12 Dec 2006 09:46:19 -0700 (MST) (envelope-from mbaker@gmail.com) Received: by ug-out-1314.google.com with SMTP id j3so2037487ugf for ; Tue, 12 Dec 2006 08:46:17 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=ch4BRvWVdCgS9PN+prIIbvgKzn2qgE+HpZOxmwJy0nSy3huTv0ummOoXeu0h7CwCPyUS2kNLRUX9sk9O78W/XHeJvEry0Zbeof4MdxeXneEyVMvv+S7LNx3Zh3P/acNT3463cTEfs+WWOF1UX5BNURKxl4bg3X8znI7jythOVT0= Received: by 10.78.166.7 with SMTP id o7mr2363379hue.1165941976967; Tue, 12 Dec 2006 08:46:16 -0800 (PST) Received: by 10.78.174.19 with HTTP; Tue, 12 Dec 2006 08:46:16 -0800 (PST) Message-ID: Date: Tue, 12 Dec 2006 11:46:16 -0500 From: "Mark Baker" To: "James M Snell" Subject: Re: Atom Entry Documents Cc: "Mark Nottingham" , atom-syntax In-Reply-To: <457E5CAD.8010605@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <457C5DD9.9070309@gmail.com> <457E22E9.3010805@gmail.com> <457E5CAD.8010605@gmail.com> X-Google-Sender-Auth: 10f070d47d54f347 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 On 12/12/06, James M Snell wrote: > *If* the document proceeds to Proposed Standard, the new RFC would > update RFC4287 either by adding a new type param or by deprecating the > use of application/atom+xml for atom entry documents in favor of a new > media type. No other part of RFC4287 would be affected. > > Ideally, I would much rather this be a WG draft. I pinged Tim about it > the other day and he suggested that I go ahead with a I-D for now and > that we can explore whether or not to move forward with it as a WG draft > later. I'm uncomfortable with this. If there's consensus to do something about identifying entry documents, let's do that. If there isn't, let's not. Mark. From owner-atom-syntax@mail.imc.org Tue Dec 12 17:43:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuGLJ-0007Qa-L2 for atompub-archive@lists.ietf.org; Tue, 12 Dec 2006 17:43:21 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuGLI-0004qA-8G for atompub-archive@lists.ietf.org; Tue, 12 Dec 2006 17:43:21 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBCMKKei048551; Tue, 12 Dec 2006 15:20:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBCMKKWb048550; Tue, 12 Dec 2006 15:20:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBCMKJl2048543 for ; Tue, 12 Dec 2006 15:20:20 -0700 (MST) (envelope-from Tim.Bray@Sun.COM) Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kBCMKJY3011835 for ; Tue, 12 Dec 2006 15:20:19 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JA600701LZJKK00@mail-amer.sun.com> (original mail from Tim.Bray@Sun.COM) for atom-syntax@imc.org; Tue, 12 Dec 2006 15:20:19 -0700 (MST) Received: from [192.168.1.45] (fatwire-204-250.uniserve.ca [216.113.204.251]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JA60044UM1UJI00@mail-amer.sun.com> for atom-syntax@imc.org; Tue, 12 Dec 2006 15:20:19 -0700 (MST) Date: Tue, 12 Dec 2006 14:20:48 -0800 From: Tim Bray Subject: Re: Atom namespace really not ending with / or # ? In-reply-to: To: atom-syntax Message-id: <457F2B40.80404@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT References: <264B46E1-B3DE-4F33-9EBE-2429B4DF2347@mac.com> User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Anne van Kesteren wrote: > Jan Algermissen > wrote: >> is it really true that the Atom namespace is >> http://www.w3.org/2005/Atom ? > It wasn't really relevant, I'd say. (That it says "Atom" and not "atom" > was a mistake.) I'd agree. Sigh. But not a big one, I think -Tim From owner-atom-syntax@mail.imc.org Tue Dec 12 17:50:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuGS5-0001Ss-33 for atompub-archive@lists.ietf.org; Tue, 12 Dec 2006 17:50:21 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuGS3-00061D-M5 for atompub-archive@lists.ietf.org; Tue, 12 Dec 2006 17:50:21 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBCMPTaG049062; Tue, 12 Dec 2006 15:25:29 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBCMPTEV049061; Tue, 12 Dec 2006 15:25:29 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBCMPSAP049055 for ; Tue, 12 Dec 2006 15:25:29 -0700 (MST) (envelope-from Tim.Bray@Sun.COM) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kBCMPSO5016179 for ; Tue, 12 Dec 2006 15:25:28 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JA600C01LPM0B00@mail-amer.sun.com> (original mail from Tim.Bray@Sun.COM) for atom-syntax@imc.org; Tue, 12 Dec 2006 15:25:28 -0700 (MST) Received: from [192.168.1.45] (fatwire-204-250.uniserve.ca [216.113.204.251]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JA600A5NMA2B700@mail-amer.sun.com> for atom-syntax@imc.org; Tue, 12 Dec 2006 15:25:20 -0700 (MST) Date: Tue, 12 Dec 2006 14:25:44 -0800 From: Tim Bray Subject: Re: Atom Entry Documents In-reply-to: To: atom-syntax Message-id: <457F2C68.3090504@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <457C5DD9.9070309@gmail.com> User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Mark Baker wrote: >> Ok, the recent discussion seems to point towards a consensus towards >> distinctly flagging Entry Documents in the media type. > > Erm, isn't it up to the chairs to declare concensus? I agree that there exists sentiment in favor of there being a way to distinguish between Feed and Entry documents. I think the notion of consensus is only meaningful in the context of actual spec language, so it seems to me that it would be helpful to have some proposed language to look at. So I see no downside in James doing an I-D. -Tim From owner-atom-syntax@mail.imc.org Tue Dec 12 18:08:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuGjw-0003Gs-OS for atompub-archive@lists.ietf.org; Tue, 12 Dec 2006 18:08:48 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuGjv-0008Rd-AK for atompub-archive@lists.ietf.org; Tue, 12 Dec 2006 18:08:48 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBCMheYW050751; Tue, 12 Dec 2006 15:43:40 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBCMheDk050750; Tue, 12 Dec 2006 15:43:40 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBCMhcrT050742 for ; Tue, 12 Dec 2006 15:43:39 -0700 (MST) (envelope-from Tim.Bray@Sun.COM) Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kBCMhcSH025243 for ; Tue, 12 Dec 2006 15:43:38 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JA600F01N1RDF00@mail-amer.sun.com> (original mail from Tim.Bray@Sun.COM) for atom-syntax@imc.org; Tue, 12 Dec 2006 15:43:38 -0700 (MST) Received: from [192.168.1.45] (fatwire-204-250.uniserve.ca [216.113.204.251]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JA6003IHN4PPR00@mail-amer.sun.com> for atom-syntax@imc.org; Tue, 12 Dec 2006 15:43:38 -0700 (MST) Date: Tue, 12 Dec 2006 14:44:07 -0800 From: Tim Bray Subject: Atom Entry docs To: atom-syntax Message-id: <457F30B7.1020100@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 I seems obvious to me that Atom Feed and Entry docs are potentially quite different things which can be used for entirely different purposes. The contention that an Entry doc is somehow really the same as a one-entry Feed doc is entirely unconvincing. The Architecture of the Web (http://www.w3.org/TR/webarch) and the TAG finding on Authoritative Metadata (http://www.w3.org/2001/tag/doc/mime-respect.html) make it pretty clear that it's advantageous to use HTTP headers to distinguish between different kinds of representations. So I guess I'm in favor of us writing something down to address this problem. RFC4287 is now pretty widely implemented, so there is a distinct cost to screwing around with the well-known application/atom+xml. On the other hand, my perception is that virtually all software that knows about 4287 knows about feeds, rather than entries. Thus, it seems to me that introducing a parameter so that existing software might see application/atom+xml;type=feed *might* break some software. But introducing a new media-type application/atom-entry+xml which only goes with standalone feed documents is very unlikely to break anything. So I'm for James' option B) application/atom-entry+xml (James, did you really mean "atom.entry" with the ugly dot?) -Tim From owner-atom-syntax@mail.imc.org Tue Dec 12 23:40:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuLvI-00035j-Gq for atompub-archive@lists.ietf.org; Tue, 12 Dec 2006 23:40:52 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuLvF-0006Tv-34 for atompub-archive@lists.ietf.org; Tue, 12 Dec 2006 23:40:52 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBD4EaEI084592; Tue, 12 Dec 2006 21:14:36 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBD4Eaar084591; Tue, 12 Dec 2006 21:14:36 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.234]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBD4EZJl084585 for ; Tue, 12 Dec 2006 21:14:35 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id i30so51005wxd for ; Tue, 12 Dec 2006 20:14:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=PDLNGrQ3HQZFMFicpBpsByLQX4MWvvbN6pIHAGHT0HUgXljQdujLy/7ujV+wFUKojaYAer+ilTBqwiJsdpRscq9uLzATCjUIP9M9ykJZM8Ypju5kg59s16sZO+gwqTko0N45eZjcaG5KxFj7NqAlmwoQQ1Ci5FlVTr5bJg6awOk= Received: by 10.70.34.3 with SMTP id h3mr720157wxh.1165983274564; Tue, 12 Dec 2006 20:14:34 -0800 (PST) Received: from ?192.168.1.109? ( [67.181.218.96]) by mx.google.com with ESMTP id g7sm371561wra.2006.12.12.20.14.33; Tue, 12 Dec 2006 20:14:34 -0800 (PST) Message-ID: <457F7E25.8050704@gmail.com> Date: Tue, 12 Dec 2006 20:14:29 -0800 From: James M Snell User-Agent: Thunderbird 1.5.0.8 (X11/20061115) MIME-Version: 1.0 To: Tim Bray CC: atom-syntax Subject: Re: Atom Entry docs References: <457F30B7.1020100@sun.com> In-Reply-To: <457F30B7.1020100@sun.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c I think atom.entry and atom-entry are equally ugly; atom.entry would, however, appear to be more consistent with typical mime conventions. - James Tim Bray wrote: > > [snip] > (James, did you really mean "atom.entry" with the ugly dot?) > > -Tim > > From owner-atom-syntax@mail.imc.org Wed Dec 13 00:12:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuMPR-0007Il-99 for atompub-archive@lists.ietf.org; Wed, 13 Dec 2006 00:12:01 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuMPP-0007VP-RV for atompub-archive@lists.ietf.org; Wed, 13 Dec 2006 00:12:01 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBD4vV65088777; Tue, 12 Dec 2006 21:57:31 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBD4vVnT088776; Tue, 12 Dec 2006 21:57:31 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBD4vTk4088770 for ; Tue, 12 Dec 2006 21:57:30 -0700 (MST) (envelope-from mbaker@gmail.com) Received: by ug-out-1314.google.com with SMTP id j3so77487ugf for ; Tue, 12 Dec 2006 20:57:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=WPQTQS3uqWwxk3EvSztFofKf08xeWTLUKPyClebN7UlHJH6JMqQ8oxWOjp8Gc1K0cHXU51XaRwEs7CXBb/6CIVNTzP9hgcldWgfrb/dbamrnPxnl0RdsrvEWiq7s0vmmptz5EUQ5udh+9kHzPi6Xx8MOmuHhtTW69t8p1llwclc= Received: by 10.78.127.2 with SMTP id z2mr321833huc.1165985848139; Tue, 12 Dec 2006 20:57:28 -0800 (PST) Received: by 10.78.174.19 with HTTP; Tue, 12 Dec 2006 20:57:28 -0800 (PST) Message-ID: Date: Tue, 12 Dec 2006 23:57:28 -0500 From: "Mark Baker" To: "Tim Bray" Subject: Re: Atom Entry docs Cc: atom-syntax In-Reply-To: <457F30B7.1020100@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <457F30B7.1020100@sun.com> X-Google-Sender-Auth: c9283a3741e3a6c5 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Tim, On 12/12/06, Tim Bray wrote: > > I seems obvious to me that Atom Feed and Entry docs are potentially > quite different things which can be used for entirely different > purposes. The contention that an Entry doc is somehow really the same > as a one-entry Feed doc is entirely unconvincing. > > The Architecture of the Web (http://www.w3.org/TR/webarch) and the TAG > finding on Authoritative Metadata > (http://www.w3.org/2001/tag/doc/mime-respect.html) make it pretty clear > that it's advantageous to use HTTP headers to distinguish between > different kinds of representations. Ok, well, I've already voiced my disagreement that "entirely different purposes" necessitates a new media type using HTML as an example. I also disagree that the TAG finding has any relevance here, except insofar as it says that a media type authoritatively determines meaning by virtue of pointing at a spec ... but every option on the table, including doing nothing, does that. But so be it, I'm happy to move on ... > So I guess I'm in favor of us writing something down to address this > problem. > > RFC4287 is now pretty widely implemented, so there is a distinct cost to > screwing around with the well-known application/atom+xml. On the other > hand, my perception is that virtually all software that knows about 4287 > knows about feeds, rather than entries. Thus, it seems to me that > introducing a parameter so that existing software might see > application/atom+xml;type=feed *might* break some software. Maybe, but I'd be surprised. Though not, AFAIK, prescribed behaviour, convention is that unknown extension parameters are ignored. Implementors? > But > introducing a new media-type application/atom-entry+xml which only goes > with standalone feed documents is very unlikely to break anything. I think it would break servers. Consider GData apps. Their docs aren't clear (tsk, tsk!) about the use of a media type when inserting entries[1], but if they're doing it properly then their services should be keying off of "application/atom+xml", and so will break if that's changed. Other server implementations should have the same issue, of course. > So I'm for James' option B) > application/atom-entry+xml I'm -1 on that, but +1 on the type parameter. Cheers, [1] http://code.google.com/apis/gdata/protocol.html#Inserting-a-new-entry Mark. From owner-atom-syntax@mail.imc.org Wed Dec 13 03:04:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuP6M-0004NB-SZ for atompub-archive@lists.ietf.org; Wed, 13 Dec 2006 03:04:30 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuP6I-0003o3-0s for atompub-archive@lists.ietf.org; Wed, 13 Dec 2006 03:04:30 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBD7llsr003570; Wed, 13 Dec 2006 00:47:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBD7llSd003569; Wed, 13 Dec 2006 00:47:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.webfaction.com (mail1.webfaction.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBD7lkM1003563 for ; Wed, 13 Dec 2006 00:47:46 -0700 (MST) (envelope-from sh@defuze.org) Received: from [192.168.136.75] ([194.221.10.75]) (authenticated bits=0) by mail1.webfaction.com (8.12.11.20060308/8.13.3) with ESMTP id kBD7lcth023123; Wed, 13 Dec 2006 01:47:42 -0600 Message-ID: <457FB015.8000706@defuze.org> Date: Wed, 13 Dec 2006 07:47:33 +0000 From: Sylvain Hellegouarch User-Agent: Thunderbird 1.5.0.5 (X11/20060728) MIME-Version: 1.0 To: Mark Baker CC: atom-syntax Subject: Re: Atom Entry docs References: <457F30B7.1020100@sun.com> In-Reply-To: X-Enigmail-Version: 0.94.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: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 > Consider GData apps. Their docs aren't clear (tsk, tsk!) about the > use of a media type when inserting entries[1], but if they're doing it > properly then their services should be keying off of > "application/atom+xml", and so will break if that's changed. > And? Should a status quo be better on the long term? > Other server implementations should have the same issue, of course. So please explain me what a server currently does upon receiving an Atom feed on a POST to a collection that only (app:)accept (atom:)entry(ies)? Returning a 415 error code seems like the wrong option since the media-type is perfectly valid. So what should servers do? Should they pick-up randomly one of the entries part of the feed? How should UA deal with the returned message? > >> So I'm for James' option B) >> application/atom-entry+xml > > I'm -1 on that, but +1 on the type parameter. > I'm still +1 on the new media-type and +0.5 on the parameter type option. - Sylvain From owner-atom-syntax@mail.imc.org Wed Dec 13 03:47:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuPlX-00073o-U8 for atompub-archive@lists.ietf.org; Wed, 13 Dec 2006 03:47:03 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuPlV-0004Nu-Ae for atompub-archive@lists.ietf.org; Wed, 13 Dec 2006 03:47:03 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBD8QdEC007396; Wed, 13 Dec 2006 01:26:39 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBD8Qdxu007395; Wed, 13 Dec 2006 01:26:39 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scmailgw2.scop.aoyama.ac.jp (scmailgw2.scop.aoyama.ac.jp [133.2.251.195]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBD8QcK4007386 for ; Wed, 13 Dec 2006 01:26:39 -0700 (MST) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id kBD8QV8I018057 for ; Wed, 13 Dec 2006 17:26:32 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 5c03_a3159698_8a83_11db_8d7d_0014221f2a2d; Wed, 13 Dec 2006 17:26:31 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:53529) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 13 Dec 2006 17:25:48 +0900 Message-Id: <6.0.0.20.2.20061213164048.094c3190@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 13 Dec 2006 16:41:56 +0900 To: James M Snell , Tim Bray From: Martin Duerst Subject: Re: Atom Entry docs Cc: atom-syntax In-Reply-To: <457F7E25.8050704@gmail.com> References: <457F30B7.1020100@sun.com> <457F7E25.8050704@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: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a At 13:14 06/12/13, James M Snell wrote: > >I think atom.entry and atom-entry are equally ugly; atom.entry would, >however, appear to be more consistent with typical mime conventions. The dot is used for prefixes like vnd. (vendor) and so on. In the case of atom entries, atom-entry is more in line with the convention in other types. Regards, Martin. >- James > >Tim Bray wrote: >> >> [snip] >> (James, did you really mean "atom.entry" with the ugly dot?) >> >> -Tim >> >> #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From owner-atom-syntax@mail.imc.org Wed Dec 13 09:04:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuUiM-0006gH-5Y for atompub-archive@lists.ietf.org; Wed, 13 Dec 2006 09:04:06 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuUiJ-0001nV-LM for atompub-archive@lists.ietf.org; Wed, 13 Dec 2006 09:04:06 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBDDasCX044428; Wed, 13 Dec 2006 06:36:54 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBDDasdF044427; Wed, 13 Dec 2006 06:36:54 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBDDaqDa044419 for ; Wed, 13 Dec 2006 06:36:53 -0700 (MST) (envelope-from sewe@rbg.informatik.tu-darmstadt.de) Received: from [194.97.50.138] (helo=mx0.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.62) (envelope-from ) id 1GuUHw-00028H-Cw; Wed, 13 Dec 2006 14:36:48 +0100 Received: from www3.emo.freenet-rz.de ([194.97.107.200]:42420) by mx0.freenet.de with esmtp (port 25) (Exim 4.62 #12) id 1GuUHw-0005P9-8e; Wed, 13 Dec 2006 14:36:48 +0100 Received: from www-data by www3.emo.freenet-rz.de with local (Exim 4.60 1 (Panther_1)) id 1GuUHt-0005tm-VY; Wed, 13 Dec 2006 14:36:46 +0100 To: "Martin Duerst", "James M Snell" From: sewe@rbg.informatik.tu-darmstadt.de Subject: Re: Atom Entry docs Cc: "atom-syntax" X-Priority: 3 X-Abuse: 505883552 / 193.10.176.20 User-Agent: freenetMail MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Message-Id: Date: Wed, 13 Dec 2006 14:36:45 +0100 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kBDDarDa044421 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.2 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Martin Duerst wrote: > James M Snell wrote: >> I think atom.entry and atom-entry are equally ugly; atom.entry would, >> however, appear to be more consistent with typical mime conventions. > > The dot is used for prefixes like vnd. (vendor) and so on. > In the case of atom entries, atom-entry is more in line with > the convention in other types. Right. Please drop the (dot-separated) prefix, especially since there is not such thing as a hierachy here -- unless you are proposing "appliction/atom.feed+xml" as well, James. (Which you hopefully won't ;-) And while you are at it, why does "application/atom-entry+xml" contain a hyphen? Both "application/atomsvc+xml" and "application/atomcat+xml" do not. We should maintain some consistency here. Speaking of which: What file extension do you recommend for use with "application/atomentry+xml"? ".atomentry"? Just ".entry"? Something else entirely? Regards, Andreas, who still is +1 on a type parameter, but now +0 on a (consistently named!) new media type From owner-atom-syntax@mail.imc.org Wed Dec 13 11:23:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuWtS-0008PM-4V for atompub-archive@lists.ietf.org; Wed, 13 Dec 2006 11:23:42 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuWtQ-0005Pn-OZ for atompub-archive@lists.ietf.org; Wed, 13 Dec 2006 11:23:42 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBDFpps0064063; Wed, 13 Dec 2006 08:51:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBDFppwv064062; Wed, 13 Dec 2006 08:51:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBDFpoH6064053 for ; Wed, 13 Dec 2006 08:51:50 -0700 (MST) (envelope-from mbaker@gmail.com) Received: by an-out-0708.google.com with SMTP id d33so46696and for ; Wed, 13 Dec 2006 07:51:47 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=LreS4f/KsvElae1araTdSE6Wx2KtVnhuPKSWHbQFFaYaDU4zPUK9o1V2SXzildd0ZlYTNdBiC9HtvJGwLuILhE+U2AMNQ3Nq82QVOkyDnka/rWtFhEIJfhxUB8Suxl9p3NRgNexTKxzjD5gs5rx4y9oBIFCK2nx3Ie9z9jiKq8M= Received: by 10.78.180.18 with SMTP id c18mr752843huf.1166025106709; Wed, 13 Dec 2006 07:51:46 -0800 (PST) Received: by 10.78.174.19 with HTTP; Wed, 13 Dec 2006 07:51:46 -0800 (PST) Message-ID: Date: Wed, 13 Dec 2006 10:51:46 -0500 From: "Mark Baker" To: "Sylvain Hellegouarch" Subject: Re: Atom Entry docs Cc: atom-syntax In-Reply-To: <457FB015.8000706@defuze.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <457F30B7.1020100@sun.com> <457FB015.8000706@defuze.org> X-Google-Sender-Auth: 64aad5720ae94947 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 On 12/13/06, Sylvain Hellegouarch wrote: > > > Consider GData apps. Their docs aren't clear (tsk, tsk!) about the > > use of a media type when inserting entries[1], but if they're doing it > > properly then their services should be keying off of > > "application/atom+xml", and so will break if that's changed. > > > > And? Should a status quo be better on the long term? I was just disagreeing with Tim's assertion that nothing will break. > > Other server implementations should have the same issue, of course. > > So please explain me what a server currently does upon receiving an Atom > feed on a POST to a collection that only (app:)accept (atom:)entry(ies)? > > Returning a 415 error code seems like the wrong option since the > media-type is perfectly valid. So what should servers do? Should they > pick-up randomly one of the entries part of the feed? How should UA deal > with the returned message? AIUI, that's undefined, and will remain so no matter what is decided here. I don't understand what that has to do with a new media type breaking existing servers though. Of course, APP isn't finished yet, and so technically we shouldn't be worrying about breaking implementations that "jumped the gun". But given that an alternative exists which shouldn't break those servers, why not use it when there's no apparent downside? Mark. From owner-atom-syntax@mail.imc.org Wed Dec 13 11:25:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuWuw-00005E-2Y for atompub-archive@lists.ietf.org; Wed, 13 Dec 2006 11:25:14 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuWuu-0005bK-Be for atompub-archive@lists.ietf.org; Wed, 13 Dec 2006 11:25:14 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBDFqEWf064131; Wed, 13 Dec 2006 08:52:14 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBDFqEg1064130; Wed, 13 Dec 2006 08:52:14 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBDFqDUV064123 for ; Wed, 13 Dec 2006 08:52:13 -0700 (MST) (envelope-from kmarvin@google.com) Received: from zps77.corp.google.com (zps77.corp.google.com [172.25.146.77]) by smtp-out.google.com with ESMTP id kBDFppgw027130 for ; Wed, 13 Dec 2006 15:51:51 GMT DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:references; b=T9XnBIcW3XysBvuJv7qQT35Of1qh1N71ico9swv9NwA7dBxkHwzy4uE+SVjXmZlfh uA7I3sB+9+erJ0jZzCKgQ== Received: from nz-out-0506.google.com (nzii11.prod.google.com [10.36.35.11]) by zps77.corp.google.com with ESMTP id kBDFpiqH005875 for ; Wed, 13 Dec 2006 07:51:44 -0800 Received: by nz-out-0506.google.com with SMTP id i11so103243nzi for ; Wed, 13 Dec 2006 07:51:44 -0800 (PST) Received: by 10.65.194.13 with SMTP id w13mr1723460qbp.1166025103898; Wed, 13 Dec 2006 07:51:43 -0800 (PST) Received: by 10.64.183.12 with HTTP; Wed, 13 Dec 2006 07:51:43 -0800 (PST) Message-ID: <192fc9640612130751y6f4bcc7au5f18c32f68d723c2@mail.gmail.com> Date: Wed, 13 Dec 2006 09:51:43 -0600 From: "Kyle Marvin" To: "Sylvain Hellegouarch" Subject: Re: Atom Entry docs Cc: "Mark Baker" , atom-syntax In-Reply-To: <457FB015.8000706@defuze.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_104104_22505832.1166025103754" References: <457F30B7.1020100@sun.com> <457FB015.8000706@defuze.org> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.4 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 ------=_Part_104104_22505832.1166025103754 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 12/13/06, Sylvain Hellegouarch wrote: > > > > > Consider GData apps. Their docs aren't clear (tsk, tsk!) about the > > use of a media type when inserting entries[1], but if they're doing it > > properly then their services should be keying off of > > "application/atom+xml", and so will break if that's changed. > > > > And? Should a status quo be better on the long term? Hi Sylvain, Speaking as an implementer, we've shown ourselves quite willing to change the GData implementation to track the APP draft as it has evolved. The above response didn't come from me, and if you check the history of my messages on the Atom lists I think you'll find I've generally only cited the current GData implementation to inform the discussion, not to constrain it. It's important to Google that the right things be done for the long haul, too. This being said, Mark was responding to Tim's message that just changing the content-type for Atom entries was less likely to break existing implementations. What he is saying is correct and this will break our existing implementation (and any other current server impl that validates Content-type headers). More details below. > Other server implementations should have the same issue, of course. > > So please explain me what a server currently does upon receiving an Atom > feed on a POST to a collection that only (app:)accept (atom:)entry(ies)? The GData server implementation requires a Content-Type value of "application/atom+xml" when POSTing or PUTting an Atom entry to a collection (for all non-media collections). It will respond with a 400 (Bad Request) http error on any other content type. It will also do the same if the request body contains an Atom feed document and not an Atom entry document. So without modification, the server would reject entries that use "application/atom.entry+xml". Even with modification, it likely still would need to accept requests that contain "application/atom+xml" due to propagation delays in clients conforming to whatever new convention is established. This would be contrary to the cited TAG finding [1], because such a server would no longer be considering the Content-Type header to be authoritative and would be peeking past it to the posted document. This seems bad. Having an ambiguous common base type ("application/atom+xml") and a more specific qualified type syntax ("application/atom+xml, type="entry|feed") avoid this ugliness and the Content-Type remains authoritative whether using the old or new syntax. Returning a 415 error code seems like the wrong option since the > media-type is perfectly valid. So what should servers do? Should they > pick-up randomly one of the entries part of the feed? How should UA deal > with the returned message? > > > > >> So I'm for James' option B) > >> application/atom-entry+xml > > > > I'm -1 on that, but +1 on the type parameter. > > > > I'm still +1 on the new media-type and +0.5 on the parameter type option. > It feels like we're just trying to avoid the pain of UAs having to learn about and use content-type qualifying attributes (like "type"). But as I noted in my previous message [2], I see this as inevitable if you think Atom is going to be extended in ways that might need to be UA visible, so all we're doing is delaying that pain (and letting more UA infrastructure be built up that will feel it) rather than setting ourselves on what I see as the right path for long-term growth. Using attributes enables evolution in directions that are not strictly hierarchical in nature, whereas continuing to evolve using only the base type/subtype does not. For that reason (mostly), I'm +1 on using "type" and -0.5 on using a new MIME type. Cheers! -- Kyle [1] - http://www.w3.org/2001/tag/doc/mime-respect.html [1] - http://www.imc.org/atom-syntax/mail-archive/msg19384.html ------=_Part_104104_22505832.1166025103754 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 12/13/06, Sylvain Hellegouarch <sh@defuze.org> wrote:


> Consider GData apps.  Their docs aren't clear (tsk, tsk!) about the
> use of a media type when inserting entries[1], but if they're doing it
> properly then their services should be keying off of
> "application/atom+xml", and so will break if that's changed.
>

And? Should a status quo be better on the long term?

Hi Sylvain, 

Speaking as an implementer, we've shown ourselves quite willing to change the GData implementation to track the APP draft as it has evolved.   The above response didn't come from me, and if you check the history of my messages on the Atom lists I think you'll find I've generally only cited the current GData implementation to inform the discussion, not to constrain it.   It's important to Google that the right things be done for the long haul, too.

This being said, Mark was responding to Tim's message that just changing the content-type for Atom entries was less likely to break existing implementations.  What he is saying is correct and this will break our existing implementation (and any other current server impl that validates Content-type headers).   More details below.


> Other server implementations should have the same issue, of course.

So please explain me what a server currently does upon receiving an Atom
feed on a POST to a collection that only (app:)accept (atom:)entry(ies)?

The GData server implementation requires a Content-Type value of "application/atom+xml" when POSTing or PUTting an Atom entry to a collection (for all non-media collections).   It will respond with a 400 (Bad Request) http error on any other content type.   It will also do the same if the request body contains an Atom feed document and not an Atom entry document.

So without modification, the server would reject entries that use "application/atom.entry+xml".    Even with modification, it likely still would need to accept requests that contain "application/atom+xml" due to propagation delays in clients conforming to whatever new convention is established.   This would be contrary to the cited TAG finding [1], because such a server would no longer be considering the Content-Type header to be authoritative and would be peeking past it to the posted document.   This seems bad.   Having an ambiguous common base type ("application/atom+xml") and a more specific qualified type syntax ("application/atom+xml, type="entry|feed") avoid this ugliness and the Content-Type remains authoritative whether using the old or new syntax.

Returning a 415 error code seems like the wrong option since the
media-type is perfectly valid. So what should servers do? Should they
pick-up randomly one of the entries part of the feed? How should UA deal
with the returned message?

>
>> So I'm for James' option B)
>>   application/atom-entry+xml
>
> I'm -1 on that, but +1 on the type parameter.
>

I'm still +1 on the new media-type and +0.5 on the parameter type option.

It feels like we're just trying to avoid the pain of UAs having to learn about and use content-type qualifying attributes (like "type").   But as I noted in my previous message [2], I see this as inevitable if you think Atom is going to be extended in ways that might need to be UA visible, so all we're doing is delaying that pain (and letting more UA infrastructure be built up that will feel it) rather than setting ourselves on what I see as the right path for long-term growth.    Using attributes enables evolution in directions that are not strictly hierarchical in nature, whereas continuing to evolve using only the base type/subtype does not.

For that reason (mostly), I'm +1 on using "type" and -0.5 on using a new MIME type.

Cheers!

-- Kyle

[1] - http://www.w3.org/2001/tag/doc/mime-respect.html
[1] - http://www.imc.org/atom-syntax/mail-archive/msg19384.html
------=_Part_104104_22505832.1166025103754-- From owner-atom-syntax@mail.imc.org Wed Dec 13 11:33:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuX2Z-0002lX-VG for atompub-archive@lists.ietf.org; Wed, 13 Dec 2006 11:33:07 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuX2X-0006dl-JN for atompub-archive@lists.ietf.org; Wed, 13 Dec 2006 11:33:07 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBDG0i9Y066390; Wed, 13 Dec 2006 09:00:44 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBDG0i1V066389; Wed, 13 Dec 2006 09:00:44 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.101] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBDG0hQC066375 for ; Wed, 13 Dec 2006 09:00:43 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <6.0.0.20.2.20061213164048.094c3190@localhost> References: <457F30B7.1020100@sun.com> <457F7E25.8050704@gmail.com> <6.0.0.20.2.20061213164048.094c3190@localhost> Date: Wed, 13 Dec 2006 08:00:31 -0800 To: atom-syntax From: Paul Hoffman Subject: Re: Atom Entry docs Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad At 4:41 PM +0900 12/13/06, Martin Duerst wrote: >At 13:14 06/12/13, James M Snell wrote: >> >>I think atom.entry and atom-entry are equally ugly; atom.entry would, >>however, appear to be more consistent with typical mime conventions. > >The dot is used for prefixes like vnd. (vendor) and so on. >In the case of atom entries, atom-entry is more in line with >the convention in other types. +1 From owner-atom-syntax@mail.imc.org Wed Dec 13 12:15:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuXhG-0001K2-2c for atompub-archive@lists.ietf.org; Wed, 13 Dec 2006 12:15:10 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuXhD-00066g-Ks for atompub-archive@lists.ietf.org; Wed, 13 Dec 2006 12:15:10 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBDGYA1o071759; Wed, 13 Dec 2006 09:34:10 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBDGYAUO071758; Wed, 13 Dec 2006 09:34:10 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.228]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBDGY9Th071751 for ; Wed, 13 Dec 2006 09:34:10 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id i30so189636wxd for ; Wed, 13 Dec 2006 08:34:09 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=ZZ0ggszQ+7Kab3LPRoxAPH+Mk7JLKnfYYXGDsfKBh7DCqH+kVjvWZHF2njDllmqlxxfHvnkXTcxt/Pld4oyJKLPfaovqStQmlBGmI/65RMiWaZn/WJxankEBE8iWF6FGyeRWazPeaeD2kq2OJ/53MCsKEvM6YdQa5s1rwKWUdXg= Received: by 10.70.61.1 with SMTP id j1mr1858979wxa.1166027649260; Wed, 13 Dec 2006 08:34:09 -0800 (PST) Received: from ?192.168.1.109? ( [67.181.218.96]) by mx.google.com with ESMTP id 33sm1363441wra.2006.12.13.08.34.04; Wed, 13 Dec 2006 08:34:05 -0800 (PST) Message-ID: <45802B74.6000204@gmail.com> Date: Wed, 13 Dec 2006 08:33:56 -0800 From: James M Snell User-Agent: Thunderbird 1.5.0.8 (X11/20061115) MIME-Version: 1.0 To: Martin Duerst CC: Tim Bray , atom-syntax Subject: Re: Atom Entry docs References: <457F30B7.1020100@sun.com> <457F7E25.8050704@gmail.com> <6.0.0.20.2.20061213164048.094c3190@localhost> In-Reply-To: <6.0.0.20.2.20061213164048.094c3190@localhost> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Very helpful. Thank you. - James Martin Duerst wrote: > At 13:14 06/12/13, James M Snell wrote: >> I think atom.entry and atom-entry are equally ugly; atom.entry would, >> however, appear to be more consistent with typical mime conventions. > > The dot is used for prefixes like vnd. (vendor) and so on. > In the case of atom entries, atom-entry is more in line with > the convention in other types. > > Regards, Martin. > >> - James >> >> Tim Bray wrote: >>> [snip] >>> (James, did you really mean "atom.entry" with the ugly dot?) >>> >>> -Tim >>> >>> > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > > From owner-atom-syntax@mail.imc.org Wed Dec 13 12:58:58 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuYNe-00055V-KE for atompub-archive@lists.ietf.org; Wed, 13 Dec 2006 12:58:58 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GuYNc-0004hW-Vz for atompub-archive@lists.ietf.org; Wed, 13 Dec 2006 12:58:58 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBDHVSKr079045; Wed, 13 Dec 2006 10:31:28 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBDHVShJ079044; Wed, 13 Dec 2006 10:31:28 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.webfaction.com (mail1.webfaction.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBDHVPG4079022 for ; Wed, 13 Dec 2006 10:31:27 -0700 (MST) (envelope-from sh@defuze.org) Received: from [192.168.1.3] (host81-159-21-245.range81-159.btcentralplus.com [81.159.21.245]) (authenticated bits=0) by mail1.webfaction.com (8.12.11.20060308/8.13.3) with ESMTP id kBDHVDtx019627; Wed, 13 Dec 2006 11:31:17 -0600 Message-ID: <458038D9.8000809@defuze.org> Date: Wed, 13 Dec 2006 17:31:05 +0000 From: Sylvain Hellegouarch User-Agent: Thunderbird 1.5.0.5 (X11/20060728) MIME-Version: 1.0 To: Kyle Marvin CC: atom-syntax Subject: Re: Atom Entry docs References: <457F30B7.1020100@sun.com> <457FB015.8000706@defuze.org> <192fc9640612130751y6f4bcc7au5f18c32f68d723c2@mail.gmail.com> In-Reply-To: <192fc9640612130751y6f4bcc7au5f18c32f68d723c2@mail.gmail.com> X-Enigmail-Version: 0.94.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: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Hi Kyle, > Hi Sylvain, > > Speaking as an implementer, we've shown ourselves quite willing to change > the GData implementation to track the APP draft as it has evolved. The > above response didn't come from me, and if you check the history of my > messages on the Atom lists I think you'll find I've generally only cited > the > current GData implementation to inform the discussion, not to constrain > it. It's important to Google that the right things be done for the long > haul, too. Agreed. > > This being said, Mark was responding to Tim's message that just changing > the > content-type for Atom entries was less likely to break existing > implementations. Funnily my comment was solely directed at Mark based on his own comment. I'm sorry if things weren't clear enough. I didn't mean more than "what do you mean Mark?". > > >> Other server implementations should have the same issue, of course. >> >> So please explain me what a server currently does upon receiving an Atom >> feed on a POST to a collection that only (app:)accept (atom:)entry(ies)? > > > The GData server implementation requires a Content-Type value of > "application/atom+xml" when POSTing or PUTting an Atom entry to a > collection > (for all non-media collections). It will respond with a 400 (Bad Request) > http error on any other content type. It will also do the same if the > request body contains an Atom feed document and not an Atom entry document. Right and I find that abusive of the mime type already. An UA that respects RFC 4287 and sends a feed to a collection that would state it accepts such media-type would not understand why it gets a 400 Bad Request (it's fairly interesting to point actually that because of that umbrella mime type you could not use the proper 415). > > So without modification, the server would reject entries that use > "application/atom.entry+xml". Even with modification, it likely still > would need to accept requests that contain "application/atom+xml" due to > propagation delays in clients conforming to whatever new convention is > established. This would be contrary to the cited TAG finding [1], because > such a server would no longer be considering the Content-Type header to be > authoritative and would be peeking past it to the posted document. This > seems bad. Having an ambiguous common base type ("application/atom+xml") > and a more specific qualified type syntax ("application/atom+xml, > type="entry|feed") avoid this ugliness and the Content-Type remains > authoritative whether using the old or new syntax. Agreed. > > It feels like we're just trying to avoid the pain of UAs having to learn > about and use content-type qualifying attributes (like "type"). But as I > noted in my previous message [2], I see this as inevitable if you think > Atom > is going to be extended in ways that might need to be UA visible, so all > we're doing is delaying that pain (and letting more UA infrastructure be > built up that will feel it) rather than setting ourselves on what I see as > the right path for long-term growth. Using attributes enables evolution > in directions that are not strictly hierarchical in nature, whereas > continuing to evolve using only the base type/subtype does not. > > For that reason (mostly), I'm +1 on using "type" and -0.5 on using a new > MIME type. You make a good case regarding the evolution being less hierarchical. The only thing I'd be afraid of however is that we try to put too much semantic in the mime-type if we use the type parameter. Thanks for your feedback. - Sylvain From owner-atom-syntax@mail.imc.org Wed Dec 13 13:02:42 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuYRG-0005W3-3W for atompub-archive@lists.ietf.org; Wed, 13 Dec 2006 13:02:42 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GuYRD-00051n-ML for atompub-archive@lists.ietf.org; Wed, 13 Dec 2006 13:02:42 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBDHYPiD079825; Wed, 13 Dec 2006 10:34:25 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBDHYPt9079824; Wed, 13 Dec 2006 10:34:25 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.webfaction.com (mail1.webfaction.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBDHYO7d079818 for ; Wed, 13 Dec 2006 10:34:24 -0700 (MST) (envelope-from sh@defuze.org) Received: from [192.168.1.3] (host81-159-21-245.range81-159.btcentralplus.com [81.159.21.245]) (authenticated bits=0) by mail1.webfaction.com (8.12.11.20060308/8.13.3) with ESMTP id kBDHYH6l020306; Wed, 13 Dec 2006 11:34:19 -0600 Message-ID: <45803993.20202@defuze.org> Date: Wed, 13 Dec 2006 17:34:11 +0000 From: Sylvain Hellegouarch User-Agent: Thunderbird 1.5.0.5 (X11/20060728) MIME-Version: 1.0 To: Mark Baker CC: atom-syntax Subject: Re: Atom Entry docs References: <457F30B7.1020100@sun.com> <457FB015.8000706@defuze.org> In-Reply-To: X-Enigmail-Version: 0.94.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: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 >> > Other server implementations should have the same issue, of course. >> >> So please explain me what a server currently does upon receiving an Atom >> feed on a POST to a collection that only (app:)accept (atom:)entry(ies)? >> >> Returning a 415 error code seems like the wrong option since the >> media-type is perfectly valid. So what should servers do? Should they >> pick-up randomly one of the entries part of the feed? How should UA deal >> with the returned message? > > AIUI, that's undefined, and will remain so no matter what is decided > here. I don't understand what that has to do with a new media type > breaking existing servers though. It has everything to do within the APP context in fact. We have only one mime type for two distinct semantics (well you disagree on that statement so I can understand why we disagree with the rest). Having a new media-type (or at least the type parameter) would help APP server implementors. Therefore the way servers would handle requests. > > Of course, APP isn't finished yet, and so technically we shouldn't be > worrying about breaking implementations that "jumped the gun". But > given that an alternative exists which shouldn't break those servers, > why not use it when there's no apparent downside? We still disagree on this alternative you suggest I'm afraid. - Sylvain From owner-atom-syntax@mail.imc.org Wed Dec 13 13:32:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuYti-0005Nk-D6 for atompub-archive@lists.ietf.org; Wed, 13 Dec 2006 13:32:06 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuYqt-0003O0-GK for atompub-archive@lists.ietf.org; Wed, 13 Dec 2006 13:29:13 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBDHwEJY082546; Wed, 13 Dec 2006 10:58:14 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBDHwE9J082545; Wed, 13 Dec 2006 10:58:14 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.230]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBDHwCoG082536 for ; Wed, 13 Dec 2006 10:58:14 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id i30so206832wxd for ; Wed, 13 Dec 2006 09:58:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=WyUIltIyIi95HC0kAj40PVBpPNsM21GjGM81OgUj4LPmTyQ/pX/8mpFe4bTETFWRkoQzDumHq62A7XpxCvOj6uQE4CGefv5xacagNAZHhYYWgS9WeROIxlxZ+xwbM5kI/eBayDtNPubRwfa4zu9Va1r9DHG2dNAxUnPXMwggbDk= Received: by 10.90.94.2 with SMTP id r2mr1051850agb.1166032691399; Wed, 13 Dec 2006 09:58:11 -0800 (PST) Received: from ?192.168.1.109? ( [67.181.218.96]) by mx.google.com with ESMTP id 7sm1527037wrl.2006.12.13.09.58.09; Wed, 13 Dec 2006 09:58:10 -0800 (PST) Message-ID: <45803F2A.1020702@gmail.com> Date: Wed, 13 Dec 2006 09:58:02 -0800 From: James M Snell User-Agent: Thunderbird 1.5.0.8 (X11/20061115) MIME-Version: 1.0 To: Sylvain Hellegouarch CC: Kyle Marvin , atom-syntax Subject: Re: Atom Entry docs References: <457F30B7.1020100@sun.com> <457FB015.8000706@defuze.org> <192fc9640612130751y6f4bcc7au5f18c32f68d723c2@mail.gmail.com> <458038D9.8000809@defuze.org> In-Reply-To: <458038D9.8000809@defuze.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Sylvain Hellegouarch wrote: >> [snip] >> The GData server implementation requires a Content-Type value of >> "application/atom+xml" when POSTing or PUTting an Atom entry to a >> collection >> (for all non-media collections). It will respond with a 400 (Bad Request) >> http error on any other content type. It will also do the same if the >> request body contains an Atom feed document and not an Atom entry document. > > Right and I find that abusive of the mime type already. An UA that > respects RFC 4287 and sends a feed to a collection that would state it > accepts such media-type would not understand why it gets a 400 Bad > Request (it's fairly interesting to point actually that because of that > umbrella mime type you could not use the proper 415). > Which is precisely why entry exists. Existing implementations already have to basically ignore the content-type and sniff the content. Implementations will have to continue to do so with the optional type param because it's optional. - James From owner-atom-syntax@mail.imc.org Wed Dec 13 13:36:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuYy5-0007Lu-O7 for atompub-archive@lists.ietf.org; Wed, 13 Dec 2006 13:36:37 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuYy4-0006UF-Bu for atompub-archive@lists.ietf.org; Wed, 13 Dec 2006 13:36:37 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBDI8XxR084123; Wed, 13 Dec 2006 11:08:33 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBDI8XE1084122; Wed, 13 Dec 2006 11:08:33 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.webfaction.com (mail1.webfaction.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBDI8VkW084105 for ; Wed, 13 Dec 2006 11:08:32 -0700 (MST) (envelope-from sh@defuze.org) Received: from [192.168.1.3] (host81-159-21-245.range81-159.btcentralplus.com [81.159.21.245]) (authenticated bits=0) by mail1.webfaction.com (8.12.11.20060308/8.13.3) with ESMTP id kBDI82Nf028455; Wed, 13 Dec 2006 12:08:04 -0600 Message-ID: <45804175.1090700@defuze.org> Date: Wed, 13 Dec 2006 18:07:49 +0000 From: Sylvain Hellegouarch User-Agent: Thunderbird 1.5.0.5 (X11/20060728) MIME-Version: 1.0 To: James M Snell CC: Kyle Marvin , atom-syntax Subject: Re: Atom Entry docs References: <457F30B7.1020100@sun.com> <457FB015.8000706@defuze.org> <192fc9640612130751y6f4bcc7au5f18c32f68d723c2@mail.gmail.com> <458038D9.8000809@defuze.org> <45803F2A.1020702@gmail.com> In-Reply-To: <45803F2A.1020702@gmail.com> X-Enigmail-Version: 0.94.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: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 James M Snell wrote: > > Sylvain Hellegouarch wrote: >>> [snip] >>> The GData server implementation requires a Content-Type value of >>> "application/atom+xml" when POSTing or PUTting an Atom entry to a >>> collection >>> (for all non-media collections). It will respond with a 400 (Bad Request) >>> http error on any other content type. It will also do the same if the >>> request body contains an Atom feed document and not an Atom entry document. >> Right and I find that abusive of the mime type already. An UA that >> respects RFC 4287 and sends a feed to a collection that would state it >> accepts such media-type would not understand why it gets a 400 Bad >> Request (it's fairly interesting to point actually that because of that >> umbrella mime type you could not use the proper 415). >> > > Which is precisely why entry exists. Existing > implementations already have to basically ignore the content-type and > sniff the content. Implementations will have to continue to do so with > the optional type param because it's optional. > True but I've always found the "entry" awkward. - Sylvain From owner-atom-syntax@mail.imc.org Wed Dec 13 23:58:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuifT-00035r-RO for atompub-archive@lists.ietf.org; Wed, 13 Dec 2006 23:58:04 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuifR-0002gM-Ry for atompub-archive@lists.ietf.org; Wed, 13 Dec 2006 23:58:03 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBE4NKFt059312; Wed, 13 Dec 2006 21:23:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBE4NKO5059311; Wed, 13 Dec 2006 21:23:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBE4NJqP059304 for ; Wed, 13 Dec 2006 21:23:19 -0700 (MST) (envelope-from bobwyman@gmail.com) Received: by py-out-1112.google.com with SMTP id f31so198727pyh for ; Wed, 13 Dec 2006 20:23:16 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=uejeeTF9eYsZdu1pMECt5WfYCjTrQTngkex9ROnQ34Jph6Eng1RNuz1ykerUa9xk8PESapOtqgwS+f+FZqTOiunRi4UDv84J4wVQI9dGKMPDLDYSpHnyWuhNZkY1zkUbNzGu8/CSqyqEkXBuwYlA2jKzEIp6zg78onkfKiASSqw= Received: by 10.35.20.14 with SMTP id x14mr829209pyi.1166070196794; Wed, 13 Dec 2006 20:23:16 -0800 (PST) Received: by 10.35.15.12 with HTTP; Wed, 13 Dec 2006 20:23:16 -0800 (PST) Message-ID: <45be5cd40612132023t76f58abcnf5426a2ef7c1320d@mail.gmail.com> Date: Wed, 13 Dec 2006 23:23:16 -0500 From: "Bob Wyman" To: "Tim Bray" Subject: Re: Atom Entry docs Cc: atom-syntax In-Reply-To: <457F30B7.1020100@sun.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_110993_7622066.1166070196744" References: <457F30B7.1020100@sun.com> X-Google-Sender-Auth: dd35b9aa53955ba8 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.2 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b ------=_Part_110993_7622066.1166070196744 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline There is, I think, a compromise position here which will avoid breaking those existing implementations which follow the existing RFC's. 1) Define ;type=feed and ;type=entry as optional parameters. (i.e. get them defined, registered, and "ready to use.") 2) Leave RFC4287 unchanged. i.e. do NOT re-define "application/atom-xml" 3) New specifications MAY require that ;type=entry be used. (Note: Just because ;type=entry is used DOES NOT imply that ;type=feed must also be used....) Thus, APP would accept application/atom+xml when looking for a feed but might insist that entries be explicitly identified with a disambiguating type parameter. Thus, no code which currently uses "application/atom+xml" to designate a feed would be broken. Additionally, any code which is "properly" built and thus ignores unknown types will not be hurt when it sees "application/atom+xml;type=entry" since it will ignore the type parameter and dig around inside the data to figure out if it is feed or entry. The only code which will be hurt is some potential code that does not follow the existing RFCs for Atom or mime types. It is, I think, OK to occasionally break code that doesn't follow the specs. Whatever the technical arguments may be, I believe it is important from a "political" point of view that we do not change the definition of things defined in Atom. I am all for extending Atom, but not for changing Atom. We must not change the exiting specification unless there is some really serious harm being done. If we do, we risk losing the trust of at least some members of the community that we've built these last few years... Folk will remember that one of the "advantages" that is claimed for RSS is that it has been declared to be eternally free from modification. While I personally believe that that is silly, the proponents of RSS do have a point when they speak of the value of stable specs. If we allow the Atom spec to be *changed* so soon after it was accepted and we don't have a really, really good reason for doing it, we will simply have proven the often made claim that standards groups simply can't be trusted with important specifications. We will be encouraging more of the kind of "standards making" that resulted in the mess that is RSS... bob wyman PS: Since Kyle points out that GData, a Google product, is potentially impacted by the results of this discussion, I should state that I currently work for Google -- although I am not currently assigned to any product or project that has a direct interest in the definition of Atom, APP, etc... My participation in this discussion, at this time, is driven purely by personal interest. ------=_Part_110993_7622066.1166070196744 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
There is, I think, a compromise position here which will avoid breaking those existing implementations which follow the existing RFC's.

1) Define ;type=feed and ;type=entry as optional parameters. (i.e. get them defined, registered, and "ready to use.")
2) Leave RFC4287 unchanged. i.e. do NOT re-define "application/atom-xml"
3) New specifications MAY require that ;type=entry be used. (Note: Just because ;type=entry is used DOES NOT imply that ;type=feed must also be used....)

Thus, APP would accept application/atom+xml when looking for a feed but might insist that entries be explicitly identified with a disambiguating type parameter. Thus, no code which currently uses "application/atom+xml" to designate a feed would be broken. Additionally, any code which is "properly" built and thus ignores unknown types will not be hurt when it sees "application/atom+xml;type=entry" since it will ignore the type parameter and dig around inside the data to figure out if it is feed or entry. The only code which will be hurt is some potential code that does not follow the existing RFCs for Atom or mime types. It is, I think, OK to occasionally break code that doesn't follow the specs.

Whatever the technical arguments may be, I believe it is important from a "political" point of view that we do not change the definition of things defined in Atom. I am all for extending Atom, but not for changing Atom. We must not change the exiting specification unless there is some really serious harm being done. If we do, we risk losing the trust of at least some members of the community that we've built these last few years... Folk will remember that one of the "advantages" that is claimed for RSS is that it has been declared to be eternally free from modification. While I personally believe that that is silly, the proponents of RSS do have a point when they speak of the value of stable specs. If we allow the Atom spec to be *changed* so soon after it was accepted and we don't have a really, really good reason for doing it, we will simply have proven the often made claim that standards groups simply can't be trusted with important specifications. We will be encouraging more of the kind of "standards making" that resulted in the mess that is RSS...

bob wyman

PS: Since Kyle points out that GData, a Google product, is potentially impacted by the results of this discussion, I should state that I currently work for Google -- although I am not currently assigned to any product or project that has a direct interest in the definition of Atom, APP, etc... My participation in this discussion, at this time, is driven purely by personal interest.

------=_Part_110993_7622066.1166070196744-- From owner-atom-syntax@mail.imc.org Thu Dec 14 02:04:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gukdz-0005xB-P6 for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 02:04:39 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gukdy-0001hu-Dx for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 02:04:39 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBE6j3Vc070935; Wed, 13 Dec 2006 23:45:03 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBE6j3ru070934; Wed, 13 Dec 2006 23:45:03 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBE6j1av070928 for ; Wed, 13 Dec 2006 23:45:02 -0700 (MST) (envelope-from mbaker@gmail.com) Received: by nf-out-0910.google.com with SMTP id m18so722083nfc for ; Wed, 13 Dec 2006 22:44:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=aXiub+rIE2Qr2wH7Q4Fha+9XgHiXNXQR5Y048TQSbbricksLVmY5qe8x1BnqcM89zeR+H+qlvT1zLIwP9k1B5URGidnckp0muSTXchIjuqq+sNe5eBjCM9H8fa0BSjH9/LSeLZzoWf8WdqFevofctXmrVT2b2xaFnXFK2KG2hOU= Received: by 10.78.183.15 with SMTP id g15mr443282huf.1166078698167; Wed, 13 Dec 2006 22:44:58 -0800 (PST) Received: by 10.78.174.19 with HTTP; Wed, 13 Dec 2006 22:44:58 -0800 (PST) Message-ID: Date: Thu, 14 Dec 2006 01:44:58 -0500 From: "Mark Baker" To: "Bob Wyman" Subject: Re: Atom Entry docs Cc: atom-syntax In-Reply-To: <45be5cd40612132023t76f58abcnf5426a2ef7c1320d@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <457F30B7.1020100@sun.com> <45be5cd40612132023t76f58abcnf5426a2ef7c1320d@mail.gmail.com> X-Google-Sender-Auth: abbd0f2b87238f76 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 On 12/13/06, Bob Wyman wrote: > There is, I think, a compromise position here which will avoid breaking > those existing implementations which follow the existing RFC's. That's what I thought the type parameter option was, so sure, +1 on that too 8-) Mark. From owner-atom-syntax@mail.imc.org Thu Dec 14 03:01:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GulX1-0006GF-Hf for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 03:01:31 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GulX0-0001Qn-6a for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 03:01:31 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBE7abEI075526; Thu, 14 Dec 2006 00:36:37 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBE7abjF075525; Thu, 14 Dec 2006 00:36:37 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from hu-out-0506.google.com (hu-out-0506.google.com [72.14.214.227]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBE7aZHo075519 for ; Thu, 14 Dec 2006 00:36:36 -0700 (MST) (envelope-from t.broyer@gmail.com) Received: by hu-out-0506.google.com with SMTP id 23so300847huc for ; Wed, 13 Dec 2006 23:36:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MlGBMsqPnlPhFL41MC3HH/jvAPUdXW3tWr7YT1Y1KQ8FK7wvHkLNeAMYD9ai8T3bARQiLTjkUVA3FwQ/ZBBStzNZCiu1AuT6CKJiTKvBuIgtdsoHXJeoMp2B2q2nzvIEuMbwp3qbnkT2d25XKEzY/3KVUNFEgeC70kwXw7sAk2w= Received: by 10.49.34.11 with SMTP id m11mr334873nfj.1166081794559; Wed, 13 Dec 2006 23:36:34 -0800 (PST) Received: by 10.49.28.6 with HTTP; Wed, 13 Dec 2006 23:36:34 -0800 (PST) Message-ID: Date: Thu, 14 Dec 2006 08:36:34 +0100 From: "Thomas Broyer" To: Atom-Syntax Subject: Re: Atom Entry docs In-Reply-To: <45be5cd40612132023t76f58abcnf5426a2ef7c1320d@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <457F30B7.1020100@sun.com> <45be5cd40612132023t76f58abcnf5426a2ef7c1320d@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 2006/12/14, Bob Wyman: > There is, I think, a compromise position here which will avoid breaking > those existing implementations which follow the existing RFC's. It was exactly the point behind my proposal for this 'type' parameter. -- Thomas Broyer From owner-atom-syntax@mail.imc.org Thu Dec 14 04:25:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gumql-0004iu-C3 for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 04:25:59 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gumqj-0005zk-Vp for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 04:25:59 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBE94I9J085748; Thu, 14 Dec 2006 02:04:18 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBE94Ica085747; Thu, 14 Dec 2006 02:04:18 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.fimug.fi (mail.fimug.fi [212.149.83.83]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBE94Ha4085741 for ; Thu, 14 Dec 2006 02:04:18 -0700 (MST) (envelope-from hsivonen@iki.fi) Received: from [84.239.175.108] (a175-108.24online.fi [84.239.175.108]) by posti.fidisk.fi (Postfix) with ESMTP id CBC4410C6F0F; Thu, 14 Dec 2006 11:04:15 +0200 (EET) In-Reply-To: References: <457F30B7.1020100@sun.com> <457FB015.8000706@defuze.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <38ADFD5F-2C0F-49FE-87D0-C218EDF59075@iki.fi> Cc: "Sylvain Hellegouarch" , atom-syntax Content-Transfer-Encoding: 7bit From: Henri Sivonen Subject: Re: Atom Entry docs Date: Thu, 14 Dec 2006 11:04:00 +0200 To: Mark Baker X-Mailer: Apple Mail (2.752.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab On Dec 13, 2006, at 17:51, Mark Baker wrote: > But > given that an alternative exists which shouldn't break those servers, > why not use it when there's no apparent downside? The downside is that implementations that (quite reasonably) assume that application/atom+xml == feed are also reasonable when they ignore unknown media type parameters. Given the options of a new type or a new parameter, I am +1 on the new type. (Although in general, I don't like the proliferation of application/*+xml types, because apps need to do root sniffing for application/xml anyway.) -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Thu Dec 14 10:34:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gusau-0004Ef-W3 for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 10:34:00 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gusas-0007nT-GJ for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 10:34:00 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBEF8aPe032654; Thu, 14 Dec 2006 08:08:36 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBEF8acf032653; Thu, 14 Dec 2006 08:08:36 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web33205.mail.mud.yahoo.com (web33205.mail.mud.yahoo.com [209.191.69.153]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id kBEF8WLY032641 for ; Thu, 14 Dec 2006 08:08:35 -0700 (MST) (envelope-from rcade@yahoo.com) Received: (qmail 97159 invoked by uid 60001); 14 Dec 2006 15:08:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=b171l1ES/PJGufV/QCDgOUU/tkNIDaR5uFh+i5ipSUpj6wNE+PQHoqkNqgVyc/vue2RXRvhfv4mQ/ZlMKk71zBQf5FD/4P8IylG+9I6fYlDzKfZBbTkc3MfMiLUbKDHFzD2qTbylQhaZEad+qg7g2KJVa2tuVbON2ksp3H8xJ1A=; X-YMail-OSG: RLz1IygVM1m6EtJ6qK9SbZ.snhMiRo8uUaBPqnmgHBANwepZ3k_E8OQFBBy7lKgkRvpi2CwXoz8tIzpYLWMRc.FpDbcKGjrMgWeIZgn__zNT9gIWGfFmlw1c2Nzi.auAWHtDkUOwJms8B1iIwbf6nCdWQpO6xGReXw8vcFuLZwRzAs3MQXB6ZYTYYkcs Received: from [68.17.221.213] by web33205.mail.mud.yahoo.com via HTTP; Thu, 14 Dec 2006 07:08:32 PST Date: Thu, 14 Dec 2006 07:08:32 -0800 (PST) From: Rogers Cadenhead Subject: Re: Atom Entry docs To: atom-syntax@imc.org In-Reply-To: <45be5cd40612132023t76f58abcnf5426a2ef7c1320d@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <255196.96760.qm@web33205.mail.mud.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 --- Bob Wyman wrote: > 1) Define ;type=feed and ;type=entry as optional > parameters. (i.e. get them > defined, registered, and "ready to use.") > 2) Leave RFC4287 unchanged. i.e. do NOT re-define > "application/atom-xml" > 3) New specifications MAY require that ;type=entry > be used. (Note: Just > because ;type=entry is used DOES NOT imply that > ;type=feed must also be > used....) +1 on this approach. RFC4287 is a powerful argument in Atom's favor. Chip away at that spec and we're going to start hearing from Mr. Safe again. From owner-atom-syntax@mail.imc.org Thu Dec 14 11:27:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GutQp-0001zE-UN for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 11:27:39 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GutQn-0006G8-Hz for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 11:27:39 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBEFxCp5038746; Thu, 14 Dec 2006 08:59:12 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBEFxCPi038745; Thu, 14 Dec 2006 08:59:12 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBEFxBMa038738 for ; Thu, 14 Dec 2006 08:59:11 -0700 (MST) (envelope-from mbaker@gmail.com) Received: by nz-out-0506.google.com with SMTP id z3so269579nzf for ; Thu, 14 Dec 2006 07:59:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=qKQJwv+ykIfei25qMdaneJ9Gann99wd/Dhv3b652lzmb+hnjJgVKTEXUgKdxbVwqln15PNM5ymIU+WH9k/eSIcbeLVeHoiR/Mqm+0FeM/DiQ/8OSu6Wv/jeVTzmDgdXW1xLI8TXR/f+ddoqe8wR8kqOOAirSu1X3urcxU6aqs+8= Received: by 10.78.146.11 with SMTP id t11mr846375hud.1166111947755; Thu, 14 Dec 2006 07:59:07 -0800 (PST) Received: by 10.78.174.19 with HTTP; Thu, 14 Dec 2006 07:59:07 -0800 (PST) Message-ID: Date: Thu, 14 Dec 2006 10:59:07 -0500 From: "Mark Baker" To: "Henri Sivonen" Subject: Re: Atom Entry docs Cc: "Sylvain Hellegouarch" , atom-syntax In-Reply-To: <38ADFD5F-2C0F-49FE-87D0-C218EDF59075@iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <457F30B7.1020100@sun.com> <457FB015.8000706@defuze.org> <38ADFD5F-2C0F-49FE-87D0-C218EDF59075@iki.fi> X-Google-Sender-Auth: 58252126caccae0a Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 On 12/14/06, Henri Sivonen wrote: > On Dec 13, 2006, at 17:51, Mark Baker wrote: > > > But > > given that an alternative exists which shouldn't break those servers, > > why not use it when there's no apparent downside? > > The downside is that implementations that (quite reasonably) assume > that application/atom+xml == feed are also reasonable when they > ignore unknown media type parameters. True, but I think it's quite reasonable to interpret that behaviour as a bug. > Given the options of a new type or a new parameter, I am +1 on the > new type. (Although in general, I don't like the proliferation of > application/*+xml types, because apps need to do root sniffing for > application/xml anyway.) Let's not go there 8-) See; http://www.w3.org/2001/tag/doc/mime-respect.html#embedded Mark. From owner-atom-syntax@mail.imc.org Thu Dec 14 12:32:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuuRq-0005nO-IF for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 12:32:46 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuuRn-0004v8-2I for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 12:32:46 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBEGxo95047359; Thu, 14 Dec 2006 09:59:50 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBEGxouA047358; Thu, 14 Dec 2006 09:59:50 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBEGxmZ2047349 for ; Thu, 14 Dec 2006 09:59:49 -0700 (MST) (envelope-from Tim.Bray@Sun.COM) Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kBEGxmHV023408 for ; Thu, 14 Dec 2006 09:59:48 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JA900401WIOS900@mail-amer.sun.com> (original mail from Tim.Bray@Sun.COM) for atom-syntax@imc.org; Thu, 14 Dec 2006 09:59:48 -0700 (MST) Received: from [192.168.1.104] (zz151244.cipherkey.net [64.114.151.244]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JA9005U2WJIYH30@mail-amer.sun.com>; Thu, 14 Dec 2006 09:59:48 -0700 (MST) Date: Thu, 14 Dec 2006 09:00:17 -0800 From: Tim Bray Subject: Re: Atom Entry docs In-reply-to: <45be5cd40612132023t76f58abcnf5426a2ef7c1320d@mail.gmail.com> To: Bob Wyman Cc: atom-syntax Message-id: <45818321.5080908@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <457F30B7.1020100@sun.com> <45be5cd40612132023t76f58abcnf5426a2ef7c1320d@mail.gmail.com> User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Bob Wyman wrote: > There is, I think, a compromise position here which will avoid breaking > those existing implementations which follow the existing RFC's. In case you haven't noticed, the WG is hopelessly split between the new-media-type option and the media-type-parameter option. If a few people were to put up their hands and say "yeah what Bob said" your co-chairs would probably do a hasty consensus grab. -Tim > > 1) Define ;type=feed and ;type=entry as optional parameters. (i.e. get > them defined, registered, and "ready to use.") > 2) Leave RFC4287 unchanged. i.e. do NOT re-define "application/atom-xml" > 3) New specifications MAY require that ;type=entry be used. (Note: Just > because ;type=entry is used DOES NOT imply that ;type=feed must also be > used....) > > Thus, APP would accept application/atom+xml when looking for a feed but > might insist that entries be explicitly identified with a disambiguating > type parameter. Thus, no code which currently uses > "application/atom+xml" to designate a feed would be broken. > Additionally, any code which is "properly" built and thus ignores > unknown types will not be hurt when it sees > "application/atom+xml;type=entry" since it will ignore the type > parameter and dig around inside the data to figure out if it is feed or > entry. The only code which will be hurt is some potential code that does > not follow the existing RFCs for Atom or mime types. It is, I think, OK > to occasionally break code that doesn't follow the specs. > > Whatever the technical arguments may be, I believe it is important from > a "political" point of view that we do not change the definition of > things defined in Atom. I am all for extending Atom, but not for > changing Atom. We must not change the exiting specification unless there > is some really serious harm being done. If we do, we risk losing the > trust of at least some members of the community that we've built these > last few years... Folk will remember that one of the "advantages" that > is claimed for RSS is that it has been declared to be eternally free > from modification. While I personally believe that that is silly, the > proponents of RSS do have a point when they speak of the value of stable > specs. If we allow the Atom spec to be *changed* so soon after it was > accepted and we don't have a really, really good reason for doing it, we > will simply have proven the often made claim that standards groups > simply can't be trusted with important specifications. We will be > encouraging more of the kind of "standards making" that resulted in the > mess that is RSS... > > bob wyman > > PS: Since Kyle points out that GData, a Google product, is potentially > impacted by the results of this discussion, I should state that I > currently work for Google -- although I am not currently assigned to any > product or project that has a direct interest in the definition of Atom, > APP, etc... My participation in this discussion, at this time, is driven > purely by personal interest. > From owner-atom-syntax@mail.imc.org Thu Dec 14 13:02:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guuui-0000AP-8P for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 13:02:36 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Guuug-0007pI-Sk for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 13:02:36 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBEHZVIE052097; Thu, 14 Dec 2006 10:35:31 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBEHZV8F052096; Thu, 14 Dec 2006 10:35:31 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.webfaction.com (mail1.webfaction.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBEHZTqm052085 for ; Thu, 14 Dec 2006 10:35:30 -0700 (MST) (envelope-from sh@defuze.org) Received: from mail1.webfaction.com (localhost.localdomain [127.0.0.1]) by mail1.webfaction.com (8.12.11.20060308/8.13.3) with ESMTP id kBEHZRXq005008; Thu, 14 Dec 2006 11:35:27 -0600 Received: (from apache@localhost) by mail1.webfaction.com (8.12.11.20060308/8.12.11/Submit) id kBEHZP9M004986; Thu, 14 Dec 2006 17:35:25 GMT X-Authentication-Warning: mail1.webfaction.com: apache set sender to sh@defuze.org using -f Received: from 81.159.21.245 (SquirrelMail authenticated user platom_sylvain) by mail1.webfaction.com with HTTP; Thu, 14 Dec 2006 17:35:25 -0000 (GMT) Message-ID: <1816.81.159.21.245.1166117725.squirrel@mail1.webfaction.com> In-Reply-To: <45818321.5080908@sun.com> References: <457F30B7.1020100@sun.com> <45be5cd40612132023t76f58abcnf5426a2ef7c1320d@mail.gmail.com> <45818321.5080908@sun.com> Date: Thu, 14 Dec 2006 17:35:25 -0000 (GMT) Subject: Re: Atom Entry docs From: "Sylvain Hellegouarch" To: "Tim Bray" Cc: "Bob Wyman" , "atom-syntax" Reply-To: sh@defuze.org User-Agent: SquirrelMail/1.4.8-2.el3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 > > Bob Wyman wrote: >> There is, I think, a compromise position here which will avoid breaking >> those existing implementations which follow the existing RFC's. > > In case you haven't noticed, the WG is hopelessly split > between the new-media-type option and the media-type-parameter option. > If a few people were to put up their hands and say "yeah what Bob said" > your co-chairs would probably do a hasty consensus grab. > Personally, I would say that if we find the proper way to notify implementors they can't dismiss the type parameter then I'll +1 that option over the new media type. However we know that implementations won't make the effort to take it into account then what's the point over the current status? - Sylvain From owner-atom-syntax@mail.imc.org Thu Dec 14 13:11:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guv2x-0003hW-RX for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 13:11:07 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Guv2v-0000Bc-5Q for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 13:11:07 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBEHg6gB052709; Thu, 14 Dec 2006 10:42:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBEHg6BS052708; Thu, 14 Dec 2006 10:42:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBEHg4rv052700 for ; Thu, 14 Dec 2006 10:42:05 -0700 (MST) (envelope-from kmarvin@google.com) Received: from spaceape9.eur.corp.google.com (spaceape9.eur.corp.google.com [172.28.16.143]) by smtp-out.google.com with ESMTP id kBEHfl4t028055 for ; Thu, 14 Dec 2006 17:41:48 GMT DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:references; b=BhQ2oYyMeSe9qdFFxIq8yA0hKffECgbIIWmIV8DFBx6lAra0uNniia2RyU3P0vcU8 orIvdCE5eszS089iTob/w== Received: from nz-out-0506.google.com (nzhi1.prod.google.com [10.36.235.1]) by spaceape9.eur.corp.google.com with ESMTP id kBEHfdNh014984 for ; Thu, 14 Dec 2006 17:41:40 GMT Received: by nz-out-0506.google.com with SMTP id i1so291118nzh for ; Thu, 14 Dec 2006 09:41:39 -0800 (PST) Received: by 10.65.176.3 with SMTP id d3mr1939860qbp.1166118098845; Thu, 14 Dec 2006 09:41:38 -0800 (PST) Received: by 10.64.183.12 with HTTP; Thu, 14 Dec 2006 09:41:38 -0800 (PST) Message-ID: <192fc9640612140941j53539a37ybec4aca32876bcf7@mail.gmail.com> Date: Thu, 14 Dec 2006 11:41:38 -0600 From: "Kyle Marvin" To: "Tim Bray" Subject: Re: Atom Entry docs Cc: "Bob Wyman" , atom-syntax In-Reply-To: <45818321.5080908@sun.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_120824_9081917.1166118098530" References: <457F30B7.1020100@sun.com> <45be5cd40612132023t76f58abcnf5426a2ef7c1320d@mail.gmail.com> <45818321.5080908@sun.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.2 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 ------=_Part_120824_9081917.1166118098530 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline +1 to "yeah, what Bob said". We'll still have to manage the transition around clients that don't send "type=entry" to GData services, but if we can point at an APP spec where this param is required on POST/PUT, it's possible to push through this. -- Kyle On 12/14/06, Tim Bray wrote: > > > Bob Wyman wrote: > > There is, I think, a compromise position here which will avoid breaking > > those existing implementations which follow the existing RFC's. > > In case you haven't noticed, the WG is hopelessly split > between the new-media-type option and the media-type-parameter option. > If a few people were to put up their hands and say "yeah what Bob said" > your co-chairs would probably do a hasty consensus grab. > > -Tim > > > > > 1) Define ;type=feed and ;type=entry as optional parameters. (i.e. get > > them defined, registered, and "ready to use.") > > 2) Leave RFC4287 unchanged. i.e. do NOT re-define "application/atom-xml" > > 3) New specifications MAY require that ;type=entry be used. (Note: Just > > because ;type=entry is used DOES NOT imply that ;type=feed must also be > > used....) > > > > Thus, APP would accept application/atom+xml when looking for a feed but > > might insist that entries be explicitly identified with a disambiguating > > type parameter. Thus, no code which currently uses > > "application/atom+xml" to designate a feed would be broken. > > Additionally, any code which is "properly" built and thus ignores > > unknown types will not be hurt when it sees > > "application/atom+xml;type=entry" since it will ignore the type > > parameter and dig around inside the data to figure out if it is feed or > > entry. The only code which will be hurt is some potential code that does > > not follow the existing RFCs for Atom or mime types. It is, I think, OK > > to occasionally break code that doesn't follow the specs. > > > > Whatever the technical arguments may be, I believe it is important from > > a "political" point of view that we do not change the definition of > > things defined in Atom. I am all for extending Atom, but not for > > changing Atom. We must not change the exiting specification unless there > > is some really serious harm being done. If we do, we risk losing the > > trust of at least some members of the community that we've built these > > last few years... Folk will remember that one of the "advantages" that > > is claimed for RSS is that it has been declared to be eternally free > > from modification. While I personally believe that that is silly, the > > proponents of RSS do have a point when they speak of the value of stable > > specs. If we allow the Atom spec to be *changed* so soon after it was > > accepted and we don't have a really, really good reason for doing it, we > > will simply have proven the often made claim that standards groups > > simply can't be trusted with important specifications. We will be > > encouraging more of the kind of "standards making" that resulted in the > > mess that is RSS... > > > > bob wyman > > > > PS: Since Kyle points out that GData, a Google product, is potentially > > impacted by the results of this discussion, I should state that I > > currently work for Google -- although I am not currently assigned to any > > product or project that has a direct interest in the definition of Atom, > > APP, etc... My participation in this discussion, at this time, is driven > > purely by personal interest. > > > > ------=_Part_120824_9081917.1166118098530 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline +1 to "yeah, what Bob said".   We'll still have to manage the transition around clients that don't send "type=entry" to GData services, but if we can point at an APP spec where this param is required on POST/PUT, it's possible to push through this.

-- Kyle

On 12/14/06, Tim Bray <Tim.Bray@sun.com> wrote:

Bob Wyman wrote:
> There is, I think, a compromise position here which will avoid breaking
> those existing implementations which follow the existing RFC's.

<co-chair-mode>In case you haven't noticed, the WG is hopelessly split
between the new-media-type option and the media-type-parameter option.
If a few people were to put up their hands and say "yeah what Bob said"
your co-chairs would probably do a hasty consensus grab.</co-chair-mode>

  -Tim

>
> 1) Define ;type=feed and ;type=entry as optional parameters. (i.e. get
> them defined, registered, and "ready to use.")
> 2) Leave RFC4287 unchanged. i.e. do NOT re-define "application/atom-xml"
> 3) New specifications MAY require that ;type=entry be used. (Note: Just
> because ;type=entry is used DOES NOT imply that ;type=feed must also be
> used....)
>
> Thus, APP would accept application/atom+xml when looking for a feed but
> might insist that entries be explicitly identified with a disambiguating
> type parameter. Thus, no code which currently uses
> "application/atom+xml" to designate a feed would be broken.
> Additionally, any code which is "properly" built and thus ignores
> unknown types will not be hurt when it sees
> "application/atom+xml;type=entry" since it will ignore the type
> parameter and dig around inside the data to figure out if it is feed or
> entry. The only code which will be hurt is some potential code that does
> not follow the existing RFCs for Atom or mime types. It is, I think, OK
> to occasionally break code that doesn't follow the specs.
>
> Whatever the technical arguments may be, I believe it is important from
> a "political" point of view that we do not change the definition of
> things defined in Atom. I am all for extending Atom, but not for
> changing Atom. We must not change the exiting specification unless there
> is some really serious harm being done. If we do, we risk losing the
> trust of at least some members of the community that we've built these
> last few years... Folk will remember that one of the "advantages" that
> is claimed for RSS is that it has been declared to be eternally free
> from modification. While I personally believe that that is silly, the
> proponents of RSS do have a point when they speak of the value of stable
> specs. If we allow the Atom spec to be *changed* so soon after it was
> accepted and we don't have a really, really good reason for doing it, we
> will simply have proven the often made claim that standards groups
> simply can't be trusted with important specifications. We will be
> encouraging more of the kind of "standards making" that resulted in the
> mess that is RSS...
>
> bob wyman
>
> PS: Since Kyle points out that GData, a Google product, is potentially
> impacted by the results of this discussion, I should state that I
> currently work for Google -- although I am not currently assigned to any
> product or project that has a direct interest in the definition of Atom,
> APP, etc... My participation in this discussion, at this time, is driven
> purely by personal interest.
>


------=_Part_120824_9081917.1166118098530-- From owner-atom-syntax@mail.imc.org Thu Dec 14 13:36:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuvR8-00064n-48 for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 13:36:06 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuvR5-0002TV-K2 for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 13:36:06 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBEIGVLq056973; Thu, 14 Dec 2006 11:16:31 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBEIGUrF056972; Thu, 14 Dec 2006 11:16:31 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBEIGTgo056965 for ; Thu, 14 Dec 2006 11:16:30 -0700 (MST) (envelope-from prabhaka@apple.com) Received: from relay8.apple.com (relay8.apple.com [17.128.113.38]) by mail-out3.apple.com (8.13.6/8.13.6) with ESMTP id kBEIGTxR006992 for ; Thu, 14 Dec 2006 10:16:29 -0800 (PST) Received: from [17.203.42.167] (unknown [17.203.42.167]) by relay8.apple.com (Apple SCV relay) with ESMTP id A7E824AA for ; Thu, 14 Dec 2006 10:16:29 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <255196.96760.qm@web33205.mail.mud.yahoo.com> References: <255196.96760.qm@web33205.mail.mud.yahoo.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <481A4B11-DE3F-4CCD-91EC-5042A4393CEB@apple.com> Content-Transfer-Encoding: 7bit From: Ernest Prabhakar Subject: Re: Atom Entry docs "what Bob said" Date: Thu, 14 Dec 2006 10:16:33 -0800 To: atom-syntax Syntax X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a "yeah what Bob said" I'm not sure it is ideal, but it seems the closest to consensus we're ever going to get. +1 On Dec 14, 2006, at 7:08 AM, Rogers Cadenhead wrote: > > --- Bob Wyman wrote: >> 1) Define ;type=feed and ;type=entry as optional >> parameters. (i.e. get them >> defined, registered, and "ready to use.") >> 2) Leave RFC4287 unchanged. i.e. do NOT re-define >> "application/atom-xml" >> 3) New specifications MAY require that ;type=entry >> be used. (Note: Just >> because ;type=entry is used DOES NOT imply that >> ;type=feed must also be >> used....) > > +1 on this approach. RFC4287 is a powerful argument in > Atom's favor. Chip away at that spec and we're going > to start hearing from Mr. Safe again. > From owner-atom-syntax@mail.imc.org Thu Dec 14 14:02:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuvqS-0006wn-QH for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 14:02:16 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuvqQ-00054h-6E for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 14:02:16 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBEIhbb4059103; Thu, 14 Dec 2006 11:43:37 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBEIhbYf059102; Thu, 14 Dec 2006 11:43:37 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.249]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBEIhaWQ059079 for ; Thu, 14 Dec 2006 11:43:37 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by an-out-0708.google.com with SMTP id d33so191533and for ; Thu, 14 Dec 2006 10:43:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=bmFMkbDodpuZoYGhgf1cRp+tvzgFDuw6GpdntDilotUpwDdmKJ70HqT45ola9Ptr+J6iW+TeYB17xM21UG6JuRbooFIChMCE2/hyaCoSZBtjL6vcamArmkMzCZaz5YVKh2OBD+DiQp4jHlUcDCEfNFPT2sdy0tYNsnAUvkH1Ceg= Received: by 10.100.119.14 with SMTP id r14mr1145402anc.1166121814266; Thu, 14 Dec 2006 10:43:34 -0800 (PST) Received: from ?192.168.1.109? ( [67.181.218.96]) by mx.google.com with ESMTP id i18sm2593227wxd.2006.12.14.10.43.32; Thu, 14 Dec 2006 10:43:33 -0800 (PST) Message-ID: <45819B50.7000907@gmail.com> Date: Thu, 14 Dec 2006 10:43:28 -0800 From: James M Snell User-Agent: Thunderbird 1.5.0.8 (X11/20061115) MIME-Version: 1.0 To: Tim Bray CC: Bob Wyman , atom-syntax Subject: Re: Atom Entry docs References: <457F30B7.1020100@sun.com> <45be5cd40612132023t76f58abcnf5426a2ef7c1320d@mail.gmail.com> <45818321.5080908@sun.com> In-Reply-To: <45818321.5080908@sun.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 I've found the arguments in favor of the type param to be more convincing than those in favor of the new media type... ...so +1 to what Bob said. - James Tim Bray wrote: > > Bob Wyman wrote: >> There is, I think, a compromise position here which will avoid >> breaking those existing implementations which follow the existing RFC's. > > In case you haven't noticed, the WG is hopelessly split > between the new-media-type option and the media-type-parameter option. > If a few people were to put up their hands and say "yeah what Bob said" > your co-chairs would probably do a hasty consensus grab. > > -Tim > >> >> 1) Define ;type=feed and ;type=entry as optional parameters. (i.e. get >> them defined, registered, and "ready to use.") >> 2) Leave RFC4287 unchanged. i.e. do NOT re-define "application/atom-xml" >> 3) New specifications MAY require that ;type=entry be used. (Note: >> Just because ;type=entry is used DOES NOT imply that ;type=feed must >> also be used....) >> >> Thus, APP would accept application/atom+xml when looking for a feed >> but might insist that entries be explicitly identified with a >> disambiguating type parameter. Thus, no code which currently uses >> "application/atom+xml" to designate a feed would be broken. >> Additionally, any code which is "properly" built and thus ignores >> unknown types will not be hurt when it sees >> "application/atom+xml;type=entry" since it will ignore the type >> parameter and dig around inside the data to figure out if it is feed >> or entry. The only code which will be hurt is some potential code that >> does not follow the existing RFCs for Atom or mime types. It is, I >> think, OK to occasionally break code that doesn't follow the specs. >> >> Whatever the technical arguments may be, I believe it is important >> from a "political" point of view that we do not change the definition >> of things defined in Atom. I am all for extending Atom, but not for >> changing Atom. We must not change the exiting specification unless >> there is some really serious harm being done. If we do, we risk losing >> the trust of at least some members of the community that we've built >> these last few years... Folk will remember that one of the >> "advantages" that is claimed for RSS is that it has been declared to >> be eternally free from modification. While I personally believe that >> that is silly, the proponents of RSS do have a point when they speak >> of the value of stable specs. If we allow the Atom spec to be >> *changed* so soon after it was accepted and we don't have a really, >> really good reason for doing it, we will simply have proven the often >> made claim that standards groups simply can't be trusted with >> important specifications. We will be encouraging more of the kind of >> "standards making" that resulted in the mess that is RSS... >> >> bob wyman >> >> PS: Since Kyle points out that GData, a Google product, is potentially >> impacted by the results of this discussion, I should state that I >> currently work for Google -- although I am not currently assigned to >> any product or project that has a direct interest in the definition of >> Atom, APP, etc... My participation in this discussion, at this time, >> is driven purely by personal interest. >> > > From owner-atom-syntax@mail.imc.org Thu Dec 14 14:22:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuwAN-0007JJ-Mt for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 14:22:51 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuwAM-0007eh-AG for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 14:22:51 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBEJ2k70061819; Thu, 14 Dec 2006 12:02:46 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBEJ2kJx061818; Thu, 14 Dec 2006 12:02:46 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBEJ2isw061804 for ; Thu, 14 Dec 2006 12:02:45 -0700 (MST) (envelope-from t.broyer@gmail.com) Received: by nf-out-0910.google.com with SMTP id m18so875309nfc for ; Thu, 14 Dec 2006 11:02:44 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=X4R7VyBd9gNfKto77Vb6Ozs7Y5fjpX7s0Gm3JW2qnhLokTN9sVI2mYgAdl/F9h8SumRQaJPB+QuBybaZ0zJ0gghZvKsVMsQnZjMGnwZWk3gEMhi01FAQFLAjrbWiRIwagb0OVDKpqdHzW2TK3CXQtoaThqFdfeEVz2DogyUAxYg= Received: by 10.49.92.18 with SMTP id u18mr1225965nfl.1166122963166; Thu, 14 Dec 2006 11:02:43 -0800 (PST) Received: by 10.49.28.6 with HTTP; Thu, 14 Dec 2006 11:02:42 -0800 (PST) Message-ID: Date: Thu, 14 Dec 2006 20:02:42 +0100 From: "Thomas Broyer" To: Atom-Syntax Subject: Re: Atom Entry docs In-Reply-To: <45818321.5080908@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <457F30B7.1020100@sun.com> <45be5cd40612132023t76f58abcnf5426a2ef7c1320d@mail.gmail.com> <45818321.5080908@sun.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 2006/12/14, Tim Bray: > > Bob Wyman wrote: > > There is, I think, a compromise position here which will avoid breaking > > those existing implementations which follow the existing RFC's. > > In case you haven't noticed, the WG is hopelessly split > between the new-media-type option and the media-type-parameter option. > If a few people were to put up their hands and say "yeah what Bob said" > your co-chairs would probably do a hasty consensus grab. Just in case: "yeah what Bob said" ;-) -- Thomas Broyer From owner-atom-syntax@mail.imc.org Thu Dec 14 14:46:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuwXU-0000jh-Ry for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 14:46:44 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuwXT-0001xT-DM for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 14:46:44 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBEJSRM7064977; Thu, 14 Dec 2006 12:28:27 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBEJSRfG064976; Thu, 14 Dec 2006 12:28:27 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mcom.com (r2d2.aoltw.net [64.236.137.26]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBEJSQis064970 for ; Thu, 14 Dec 2006 12:28:26 -0700 (MST) (envelope-from jpanzer@aol.net) Received: from areophany.nscp.aoltw.net (areophany.nscp.aoltw.net [10.169.155.201]) by mcom.com (8.10.0/8.10.0) with ESMTP id kBEJS6d20648; Thu, 14 Dec 2006 11:28:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by areophany.nscp.aoltw.net (Postfix) with ESMTP id BA8E8C969A; Thu, 14 Dec 2006 11:28:05 -0800 (PST) Received: from areophany.nscp.aoltw.net ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26920-09; Thu, 14 Dec 2006 11:28:04 -0800 (PST) Received: from [10.169.155.201] (areophany.nscp.aoltw.net [10.169.155.201]) by areophany.nscp.aoltw.net (Postfix) with ESMTP id 9CE88C9688; Thu, 14 Dec 2006 11:28:04 -0800 (PST) Message-ID: <4581A5C4.2030404@aol.net> Date: Thu, 14 Dec 2006 11:28:04 -0800 From: John Panzer User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Tim Bray Cc: Bob Wyman , atom-syntax Subject: Re: Atom Entry docs References: <457F30B7.1020100@sun.com> <45be5cd40612132023t76f58abcnf5426a2ef7c1320d@mail.gmail.com> <45818321.5080908@sun.com> In-Reply-To: <45818321.5080908@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.903 tagged_above=-999 required=5 tests=ALL_TRUSTED, AWL X-Spam-Level: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Tim Bray wrote: > > Bob Wyman wrote: >> There is, I think, a compromise position here which will avoid >> breaking those existing implementations which follow the existing RFC's. > > In case you haven't noticed, the WG is hopelessly split > between the new-media-type option and the media-type-parameter option. > If a few people were to put up their hands and say "yeah what Bob > said" your co-chairs would probably do a hasty consensus > grab. > hand up... From owner-atom-syntax@mail.imc.org Thu Dec 14 14:49:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuwaV-0001Qx-6X for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 14:49:51 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuwaT-0002Jg-JP for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 14:49:51 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBEJUfkr065304; Thu, 14 Dec 2006 12:30:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBEJUfVT065297; Thu, 14 Dec 2006 12:30:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mcom.com (r2d2.aoltw.net [64.236.137.26]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBEJUc7T065256 for ; Thu, 14 Dec 2006 12:30:38 -0700 (MST) (envelope-from jpanzer@aol.net) Received: from areophany.nscp.aoltw.net (areophany.nscp.aoltw.net [10.169.155.201]) by mcom.com (8.10.0/8.10.0) with ESMTP id kBEJUbd20814; Thu, 14 Dec 2006 11:30:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by areophany.nscp.aoltw.net (Postfix) with ESMTP id 58799C96D4; Thu, 14 Dec 2006 11:30:37 -0800 (PST) Received: from areophany.nscp.aoltw.net ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04155-09; Thu, 14 Dec 2006 11:30:36 -0800 (PST) Received: from [10.169.155.201] (areophany.nscp.aoltw.net [10.169.155.201]) by areophany.nscp.aoltw.net (Postfix) with ESMTP id C0D1BC96C3; Thu, 14 Dec 2006 11:30:36 -0800 (PST) Message-ID: <4581A65C.5060302@aol.net> Date: Thu, 14 Dec 2006 11:30:36 -0800 From: John Panzer User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Tim Bray Cc: Bob Wyman , atom-syntax Subject: Re: Atom Entry docs References: <457F30B7.1020100@sun.com> <45be5cd40612132023t76f58abcnf5426a2ef7c1320d@mail.gmail.com> <45818321.5080908@sun.com> In-Reply-To: <45818321.5080908@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.904 tagged_above=-999 required=5 tests=ALL_TRUSTED, AWL X-Spam-Level: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Tim Bray wrote: > > Bob Wyman wrote: >> There is, I think, a compromise position here which will avoid >> breaking those existing implementations which follow the existing RFC's. > > In case you haven't noticed, the WG is hopelessly split > between the new-media-type option and the media-type-parameter option. > If a few people were to put up their hands and say "yeah what Bob > said" your co-chairs would probably do a hasty consensus > grab. From owner-atom-syntax@mail.imc.org Thu Dec 14 15:45:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuxS8-0005uo-QZ for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 15:45:16 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuxS6-0007yB-2D for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 15:45:16 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBEKHDv0069886; Thu, 14 Dec 2006 13:17:13 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBEKHDVV069885; Thu, 14 Dec 2006 13:17:13 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBEKHCms069865; Thu, 14 Dec 2006 13:17:12 -0700 (MST) (envelope-from ldusseault@commerce.net) Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by gateout01.mbox.net (Postfix) with ESMTP id 661BD21EA; Thu, 14 Dec 2006 20:17:11 +0000 (GMT) Received: from GW2.EXCHPROD.USA.NET [165.212.116.254] by gateout01.mbox.net via smtad (C8.MAIN.3.32M); Thu, 14 Dec 2006 20:17:11 GMT X-USANET-Source: 165.212.116.254 IN ldusseault@commerce.net GW2.EXCHPROD.USA.NET X-USANET-MsgId: XID443kLNuRL5023Xo1 Received: from [192.168.1.101] ([69.181.78.47]) by GW2.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Dec 2006 13:17:10 -0700 In-Reply-To: <3f1451f50612070836h45091080k851cece2198c464a@mail.gmail.com> References: <8BD53B7C-5B43-4F2D-8DC5-0281CCB84B84@commerce.net> <3f1451f50612070836h45091080k851cece2198c464a@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/alternative; boundary=Apple-Mail-3-989137205 Message-Id: Cc: Atom , "atom-protocol Protocol" From: Lisa Dusseault Subject: Re: AD Evaluation of draft-ietf-atompub-protocol-11 Date: Thu, 14 Dec 2006 12:16:54 -0800 To: Joe Gregorio X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 14 Dec 2006 20:17:10.0439 (UTC) FILETIME=[D5C92370:01C71FBC] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.2 (+) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 --Apple-Mail-3-989137205 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Thanks for responding to my review. I look forward to seeing a revised draft. Below I've excerpted the stuff that is still giving me serious problems. On Dec 7, 2006, at 8:36 AM, Joe Gregorio wrote: > > >> Can a client modify an entry to contain a link relation element in >> the >> following cases: >> - To point to a resource on a different server entirely? > > There is no reason to believe that any of these resource are on > the same machine to begin with. I could POST to media to machine A > and have the MLE could be created on machine B and the editable media > resource itself created on machine C. This requirement has to be stated explicitly, at least as a SHOULD. This is the kind of thing that clients come to completely rely on, and then you find some special-purpose server that decides this doesn't fit in its model. "Well, the spec doesn't require me to accept link relations which point to other servers." Finger- pointing rather than interoperability. If that's completely unacceptable, the only alternative that would allow good interoperability is to have an error code or feature advertisement that allows the client to detect that the server won't allow this. A generic "Forbidden" error (or other choice that could be made by the server) is not enough to know what is disallowed and whether it is always disallowed. "What did I do wrong?" the client plaintively asks. >> >> Can a server ever ignore part of an edit and successfully process >> the rest? >> > > Yes. Think of a client that throws in a slew of random link > elements with > relations my server implementation doesn't understand. Same with > foreign > markup. The server is in charge. I completely disagree with this. It is way too unpredictable for clients to deal with. Clients are left with the illusion of flexibility -- it *seems* you can use Atom syntax extensions and do creative things that other extended clients can understand -- but in fact the server can alter this at will leaving the client without any control over what it's really publishing. In many cases, the client won't even want the server to store some stripped version of what it POSTed, because it can really change the meaning of some entry to have the server strip some of the content and markup. Imagine removing the start time and location when I'm trying to publish an event entry to what I believe ought to be a calendar feed. Some server changes to submitted documents is of course going to be allowable (edit dates, server-provided IDs, changes which are effectively XML canonicalization) but I believe these need to be limited. The general case, which is how servers deal with unrecognized elements, needs to be severely limited so that the server can either reject the whole request or store as provided. Lisa --Apple-Mail-3-989137205 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Thanks for responding to my = review.=A0 I look forward to seeing a revised draft.=A0 Below I've = excerpted the stuff that is still giving me serious = problems.=A0

On Dec 7, 2006, at 8:36 AM, Joe Gregorio = wrote:


Can a = client modify an entry to contain a link relation element in = the
following = cases:

=A0- To point to = a resource on a different server entirely?


There is no reason to believe that any of these resource are = on

the same = machine to begin with. I could POST to media to machine A

and have the MLE could be = created on machine B and the editable media

resource itself created on machine = C.


This requirement has to be = stated explicitly, at least as a SHOULD.=A0 This is the kind of thing = that clients come to completely rely on, and then you find some = special-purpose server that decides this doesn't fit in its model.=A0 = "Well, the spec doesn't require me to accept link relations which point = to other servers."=A0 =A0Finger-pointing rather than = interoperability.

If that's completely = unacceptable, the only alternative that would allow good = interoperability is to have an error code or=A0 feature advertisement = that allows the client to detect that the server won't allow this.=A0 A = generic "Forbidden" error (or other choice that could be made by the = server) is not enough to know what is disallowed and whether it is = always disallowed.=A0 "What did I do wrong?" the client plaintively = asks.


Can a server ever ignore part of = an edit and successfully process the rest?


Yes. = Think of a client that throws in a slew of random link elements = with
relations my server = implementation doesn't understand. Same with foreign
markup. The server is in = charge.

I completely disagree with this.=A0 = It is way too unpredictable for clients to deal with.=A0 Clients are = left with the illusion of flexibility -- it *seems* you can use Atom = syntax extensions and do creative things that other extended clients can = understand -- but in fact the server can alter this at will leaving the = client without any control over what it's really publishing.=A0 In many = cases, the client won't even want the server to store some stripped = version of what it POSTed, because it can really change the meaning of = some entry to have the server strip some of the content and markup.=A0 = Imagine removing the start time and location when I'm trying to publish = an event entry to what I believe ought to be a calendar = feed.=A0=A0

Some server changes to = submitted documents is of course going to be allowable (edit dates, = server-provided IDs, changes which are effectively XML canonicalization) = but I believe these need to be limited.=A0 The general case, which is = how servers deal with unrecognized elements, needs to be severely = limited so that the server can either reject the whole request or store = as provided.=A0=A0

Lisa


= --Apple-Mail-3-989137205-- From owner-atom-syntax@mail.imc.org Thu Dec 14 15:47:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuxUQ-0007OD-MC for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 15:47:38 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuxUO-0008GH-6V for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 15:47:38 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBEKTLU8071523; Thu, 14 Dec 2006 13:29:21 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBEKTLQb071522; Thu, 14 Dec 2006 13:29:21 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.webfaction.com (mail1.webfaction.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBEKTJm2071509; Thu, 14 Dec 2006 13:29:20 -0700 (MST) (envelope-from sh@defuze.org) Received: from [192.168.1.3] (host81-159-21-245.range81-159.btcentralplus.com [81.159.21.245]) (authenticated bits=0) by mail1.webfaction.com (8.12.11.20060308/8.13.3) with ESMTP id kBEKT94M013317; Thu, 14 Dec 2006 14:29:13 -0600 Message-ID: <4581B40F.5020402@defuze.org> Date: Thu, 14 Dec 2006 20:29:03 +0000 From: Sylvain Hellegouarch User-Agent: Thunderbird 1.5.0.5 (X11/20060728) MIME-Version: 1.0 To: Lisa Dusseault CC: Joe Gregorio , Atom , atom-protocol Protocol Subject: Re: AD Evaluation of draft-ietf-atompub-protocol-11 References: <8BD53B7C-5B43-4F2D-8DC5-0281CCB84B84@commerce.net> <3f1451f50612070836h45091080k851cece2198c464a@mail.gmail.com> In-Reply-To: X-Enigmail-Version: 0.94.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: List-Unsubscribe: List-ID: X-Spam-Score: 1.1 (+) X-Scan-Signature: 25620135586de10c627e3628c432b04a >>> Can a client modify an entry to contain a link relation element in the >>> following cases: >>> - To point to a resource on a different server entirely? >> >> There is no reason to believe that any of these resource are on >> the same machine to begin with. I could POST to media to machine A >> and have the MLE could be created on machine B and the editable media >> resource itself created on machine C. > > This requirement has to be stated explicitly, at least as a SHOULD. > This is the kind of thing that clients come to completely rely on, and > then you find some special-purpose server that decides this doesn't fit > in its model. "Well, the spec doesn't require me to accept link > relations which point to other servers." Finger-pointing rather than > interoperability. I didn't quite understand your statement here. You make things more complicated than what Joe actually said. > > If that's completely unacceptable, the only alternative that would allow > good interoperability is to have an error code or feature advertisement > that allows the client to detect that the server won't allow this. A > generic "Forbidden" error (or other choice that could be made by the > server) is not enough to know what is disallowed and whether it is > always disallowed. "What did I do wrong?" the client plaintively asks. A generic error code would mean there was an error in the first place. Why is this the case? > >>> >>> Can a server ever ignore part of an edit and successfully process the >>> rest? >>> >> >> Yes. Think of a client that throws in a slew of random link elements with >> relations my server implementation doesn't understand. Same with foreign >> markup. The server is in charge. > > I completely disagree with this. It is way too unpredictable for > clients to deal with. Clients are left with the illusion of flexibility > -- it *seems* you can use Atom syntax extensions and do creative things > that other extended clients can understand -- but in fact the server can > alter this at will leaving the client without any control over what it's > really publishing. In many cases, the client won't even want the server > to store some stripped version of what it POSTed, because it can really > change the meaning of some entry to have the server strip some of the > content and markup. Imagine removing the start time and location when > I'm trying to publish an event entry to what I believe ought to be a > calendar feed. > > Some server changes to submitted documents is of course going to be > allowable (edit dates, server-provided IDs, changes which are > effectively XML canonicalization) but I believe these need to be > limited. The general case, which is how servers deal with unrecognized > elements, needs to be severely limited so that the server can either > reject the whole request or store as provided. This is a fundamental change to what has been said over and over on this mailing-list. Allowing the client to have more power than the current draft allows on the Atom member would mean we have to detail all those cases within the draft itself and would strongly limit its simplicity IMO. Besides, if you want to do fancy thing with a member, simply post a media resource which is an atom entry. This won't be modified by the server and will solely be treated a media resource. Then the client will have full control on it. The server must keep full control of the member resource. - Sylvain From owner-atom-syntax@mail.imc.org Thu Dec 14 16:41:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuyKx-0004GY-4j for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 16:41:55 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuyKv-0005tJ-Oy for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 16:41:55 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBELJ0mp078428; Thu, 14 Dec 2006 14:19:00 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBELJ0kt078427; Thu, 14 Dec 2006 14:19:00 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-02.southeast.rr.com (ms-smtp-02.southeast.rr.com [24.25.9.101]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBELIxrW078418 for ; Thu, 14 Dec 2006 14:19:00 -0700 (MST) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.105] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) by ms-smtp-02.southeast.rr.com (8.13.6/8.13.6) with ESMTP id kBELIvcn005998; Thu, 14 Dec 2006 16:18:58 -0500 (EST) Message-ID: <4581BFC1.2080405@intertwingly.net> Date: Thu, 14 Dec 2006 16:18:57 -0500 From: Sam Ruby User-Agent: Thunderbird 1.5.0.8 (X11/20061115) MIME-Version: 1.0 To: Tim Bray CC: atom-syntax Subject: Re: Atom Entry docs References: <457F30B7.1020100@sun.com> <45be5cd40612132023t76f58abcnf5426a2ef7c1320d@mail.gmail.com> <45818321.5080908@sun.com> In-Reply-To: <45818321.5080908@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Tim Bray wrote: > > Bob Wyman wrote: >> There is, I think, a compromise position here which will avoid >> breaking those existing implementations which follow the existing RFC's. > > In case you haven't noticed, the WG is hopelessly split > between the new-media-type option and the media-type-parameter option. > If a few people were to put up their hands and say "yeah what Bob said" > your co-chairs would probably do a hasty consensus grab. +1 to "what Bob said" - Sam Ruby From owner-atom-syntax@mail.imc.org Thu Dec 14 16:56:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuyYr-0000QW-86 for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 16:56:17 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuyYp-0007K1-RM for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 16:56:17 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBELc0pP080036; Thu, 14 Dec 2006 14:38:00 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBELc04P080034; Thu, 14 Dec 2006 14:38:00 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-04.southeast.rr.com (ms-smtp-04.southeast.rr.com [24.25.9.103]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBELbwDo080022; Thu, 14 Dec 2006 14:37:58 -0700 (MST) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.105] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) by ms-smtp-04.southeast.rr.com (8.13.6/8.13.6) with ESMTP id kBELbsVG014375; Thu, 14 Dec 2006 16:37:55 -0500 (EST) Message-ID: <4581C432.3010208@intertwingly.net> Date: Thu, 14 Dec 2006 16:37:54 -0500 From: Sam Ruby User-Agent: Thunderbird 1.5.0.8 (X11/20061115) MIME-Version: 1.0 To: Lisa Dusseault CC: Joe Gregorio , Atom , atom-protocol Protocol Subject: Re: AD Evaluation of draft-ietf-atompub-protocol-11 References: <8BD53B7C-5B43-4F2D-8DC5-0281CCB84B84@commerce.net> <3f1451f50612070836h45091080k851cece2198c464a@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.1 (+) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Lisa Dusseault wrote: > >>> >>> Can a server ever ignore part of an edit and successfully process the >>> rest? >> >> Yes. Think of a client that throws in a slew of random link elements with >> relations my server implementation doesn't understand. Same with foreign >> markup. The server is in charge. > > I completely disagree with this. It is way too unpredictable for > clients to deal with. Clients are left with the illusion of flexibility > -- it *seems* you can use Atom syntax extensions and do creative things > that other extended clients can understand -- but in fact the server can > alter this at will leaving the client without any control over what it's > really publishing. In many cases, the client won't even want the server > to store some stripped version of what it POSTed, because it can really > change the meaning of some entry to have the server strip some of the > content and markup. Imagine removing the start time and location when > I'm trying to publish an event entry to what I believe ought to be a > calendar feed. > > Some server changes to submitted documents is of course going to be > allowable (edit dates, server-provided IDs, changes which are > effectively XML canonicalization) but I believe these need to be > limited. The general case, which is how servers deal with unrecognized > elements, needs to be severely limited so that the server can either > reject the whole request or store as provided. I believe I first saw this in a response made by Roy Fielding to an assertion that servers must treat HTTP PUT as a bit-for-bit copy, but I can't immediately find the reference. In any case: clients must always consider the possibility that the server processes other requests (even internally generated ones) between the time the one the client issued and the next request the server choses to process. Such requests could partially or completely change the representation of the resource. - Sam Ruby From owner-atom-syntax@mail.imc.org Thu Dec 14 17:08:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuykO-0006mZ-8D for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 17:08:12 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuykL-00008E-RJ for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 17:08:12 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBELltU6081709; Thu, 14 Dec 2006 14:47:55 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBELltaJ081708; Thu, 14 Dec 2006 14:47:55 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.webfaction.com (mail1.webfaction.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBELlqZS081667; Thu, 14 Dec 2006 14:47:53 -0700 (MST) (envelope-from sh@defuze.org) Received: from [192.168.1.3] (host81-159-21-245.range81-159.btcentralplus.com [81.159.21.245]) (authenticated bits=0) by mail1.webfaction.com (8.12.11.20060308/8.13.3) with ESMTP id kBELljMq030447; Thu, 14 Dec 2006 15:47:46 -0600 Message-ID: <4581C67B.6020502@defuze.org> Date: Thu, 14 Dec 2006 21:47:39 +0000 From: Sylvain Hellegouarch User-Agent: Thunderbird 1.5.0.5 (X11/20060728) MIME-Version: 1.0 To: Sam Ruby CC: Lisa Dusseault , Joe Gregorio , Atom , atom-protocol Protocol Subject: Re: AD Evaluation of draft-ietf-atompub-protocol-11 References: <8BD53B7C-5B43-4F2D-8DC5-0281CCB84B84@commerce.net> <3f1451f50612070836h45091080k851cece2198c464a@mail.gmail.com> <4581C432.3010208@intertwingly.net> In-Reply-To: <4581C432.3010208@intertwingly.net> X-Enigmail-Version: 0.94.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: List-Unsubscribe: List-ID: X-Spam-Score: 1.1 (+) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 > > I believe I first saw this in a response made by Roy Fielding to an > assertion that servers must treat HTTP PUT as a bit-for-bit copy, but I > can't immediately find the reference. > Could it be? http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0228.html - Sylvain From owner-atom-syntax@mail.imc.org Thu Dec 14 17:36:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuzBZ-00009p-Pu for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 17:36:17 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuzBY-0002pX-E6 for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 17:36:17 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBEMIDnt085089; Thu, 14 Dec 2006 15:18:13 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBEMIDE5085088; Thu, 14 Dec 2006 15:18:13 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironclad.net.au ([203.30.247.11]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id kBEMIAor085077 for ; Thu, 14 Dec 2006 15:18:11 -0700 (MST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.118] (HELO [192.168.1.2]) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.0007451007 for ; Fri, 15 Dec 2006 09:18:06 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 15 Dec 2006 09:18:10 +1100 Subject: Re: Atom Entry docs From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <45be5cd40612132023t76f58abcnf5426a2ef7c1320d@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: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 On 14/12/06 3:23 PM, "Bob Wyman" wrote: > 1) Define ;type=feed and ;type=entry as optional parameters. (i.e. get them > defined, registered, and "ready to use.") > 2) Leave RFC4287 unchanged. i.e. do NOT re-define "application/atom-xml" > 3) New specifications MAY require that ;type=entry be used. (Note: Just > because ;type=entry is used DOES NOT imply that ;type=feed must also be > used....) +1 From owner-atom-syntax@mail.imc.org Thu Dec 14 19:26:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gv0uD-0002AN-Tq for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 19:26:29 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gv0uA-0004zP-Hs for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 19:26:29 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBF04iQP096162; Thu, 14 Dec 2006 17:04:44 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBF04iqG096161; Thu, 14 Dec 2006 17:04:44 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironclad.net.au ([203.30.247.11]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id kBF04gpY096153 for ; Thu, 14 Dec 2006 17:04:42 -0700 (MST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.118] (HELO [192.168.1.2]) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.0007451457 for ; Fri, 15 Dec 2006 11:04:36 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 15 Dec 2006 11:04:40 +1100 Subject: Re: AD Evaluation of draft-ietf-atompub-protocol-11 From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <4581B40F.5020402@defuze.org> 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: List-Unsubscribe: List-ID: X-Spam-Score: 1.1 (+) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 On 15/12/06 7:29 AM, "Sylvain Hellegouarch" wrote: > Besides, if you want to do fancy thing with a member, simply post a > media resource which is an atom entry. This won't be modified by the > server and will solely be treated a media resource. promise? does the spec support this assertion? or is this another case of "the server is in charge and can accept or change whatever it wants"? e. From owner-atom-syntax@mail.imc.org Thu Dec 14 19:49:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gv1GO-0002L3-8D for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 19:49:24 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gv1GK-00082s-IF for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 19:49:24 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBF0QR0T099026; Thu, 14 Dec 2006 17:26:27 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBF0QRp5099025; Thu, 14 Dec 2006 17:26:27 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from csmtp1.b-one.net (csmtp.b-one.net [195.47.247.21]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBF0QOSn099016 for ; Thu, 14 Dec 2006 17:26:24 -0700 (MST) (envelope-from asbjorn@tigerstaden.no) Received: from quark (72.84-48-117.nextgentel.com [84.48.117.72]) by csmtp1.b-one.net (Postfix) with ESMTP id 5907E1911605B; Fri, 15 Dec 2006 01:26:23 +0100 (CET) To: "James M Snell" , "Mark Nottingham" Subject: Re: Atom Entry Documents From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Cc: "Mark Baker" , atom-syntax Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <457C5DD9.9070309@gmail.com> <457E22E9.3010805@gmail.com> <457E5CAD.8010605@gmail.com> Date: Fri, 15 Dec 2006 01:28:50 +0100 Message-ID: In-Reply-To: <457E5CAD.8010605@gmail.com> User-Agent: Opera Mail/9.10 (Win32) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id kBF0QR0T099026 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f On Tue, 12 Dec 2006 08:39:25 +0100, James M Snell =20 wrote: > Ideally, I would much rather this be a WG draft. I pinged Tim about it > the other day and he suggested that I go ahead with a I-D for now and > that we can explore whether or not to move forward with it as a WG draf= t > later. Can't just the APP specification include language that specifies a new =20 MIME type for Atom Entries, since it's mostly APP implementations that =20 have a use for it? Or would that be totally out of place? --=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 Thu Dec 14 19:49:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gv1GO-0002LG-JD for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 19:49:24 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gv1GJ-00082S-T4 for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 19:49:24 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBF0V9LB000113; Thu, 14 Dec 2006 17:31:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBF0V98M000112; Thu, 14 Dec 2006 17:31:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from csmtp1.b-one.net (csmtp.b-one.net [195.47.247.21]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBF0V8tm099994 for ; Thu, 14 Dec 2006 17:31:09 -0700 (MST) (envelope-from asbjorn@tigerstaden.no) Received: from quark (72.84-48-117.nextgentel.com [84.48.117.72]) by csmtp1.b-one.net (Postfix) with ESMTP id 6E89319115570; Fri, 15 Dec 2006 01:31:08 +0100 (CET) Date: Fri, 15 Dec 2006 01:33:36 +0100 To: "Tim Bray" , atom-syntax Subject: Re: Atom Entry Documents From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <457C5DD9.9070309@gmail.com> <457F2C68.3090504@sun.com> Message-ID: In-Reply-To: <457F2C68.3090504@sun.com> User-Agent: Opera Mail/9.10 (Win32) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id kBF0V9LB000113 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 On Tue, 12 Dec 2006 23:25:44 +0100, Tim Bray wrote: > [...] So I see no downside in James doing an I-D. But is a separate I-D really necessary? If, like Kyle Marvin suggests, th= e =20 new MIME type for Atom Entries actually becomes a type parameter of the =20 existing Atom MIME type, can't the language that specifies this be =20 included in the APP specification? By that, APP will only extend RFC 4287 and not deprecate anything. It =20 might include wording like "SHOULD use the type parameter", but that stil= l =20 makes the old and bare MIME type valid. Thus, implementing RFC 4287 will = =20 not require you to use a type parameter, but implementing the APP =20 specification will strongly encourage you to do so. Won't that solve it =20 all? --=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 Thu Dec 14 19:56:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gv1Ng-0005ca-Rx for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 19:56:56 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gv1Nf-0000tA-2T for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 19:56:56 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBF0e6FT001284; Thu, 14 Dec 2006 17:40:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBF0e6jU001283; Thu, 14 Dec 2006 17:40:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.231]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBF0e53k001277 for ; Thu, 14 Dec 2006 17:40:05 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i20so345699wra for ; Thu, 14 Dec 2006 16:40:05 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=b13boUFSUZmyM3G7a8vNJBJtgk484OoGgkmVsQ7+VeuT4/LA9fJpCoFHVtFtTrDZT0ju3V+f5V9wDTrHhfFkIqonSVZwEwADWJss7w1G4PK8wiaQI9oR6BgXmoQxT8T21lgPwGbmuPETzwVNTxjs/pWUf+p3EBou5Zls+Iv1aac= Received: by 10.90.79.6 with SMTP id c6mr159365agb.1166143204953; Thu, 14 Dec 2006 16:40:04 -0800 (PST) Received: from ?192.168.1.109? ( [67.181.218.96]) by mx.google.com with ESMTP id 24sm6024749wrl.2006.12.14.16.40.03; Thu, 14 Dec 2006 16:40:04 -0800 (PST) Message-ID: <4581EEE1.8050209@gmail.com> Date: Thu, 14 Dec 2006 16:40:01 -0800 From: James M Snell User-Agent: Thunderbird 1.5.0.8 (X11/20061115) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= CC: Mark Nottingham , Mark Baker , atom-syntax Subject: Re: Atom Entry Documents References: <457C5DD9.9070309@gmail.com> <457E22E9.3010805@gmail.com> <457E5CAD.8010605@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id kBF0e6FT001284 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Quite a few folks seemed to have a preference to a separate doc. - James Asbj=F8rn Ulsberg wrote: > On Tue, 12 Dec 2006 08:39:25 +0100, James M Snell > wrote: >=20 >> Ideally, I would much rather this be a WG draft. I pinged Tim about i= t >> the other day and he suggested that I go ahead with a I-D for now and >> that we can explore whether or not to move forward with it as a WG dra= ft >> later. >=20 > Can't just the APP specification include language that specifies a new > MIME type for Atom Entries, since it's mostly APP implementations that > have a use for it? Or would that be totally out of place? >=20 > --Asbj=F8rn Ulsberg -=3D|=3D- http://virtuelvis.com/quark/ > =ABHe's a loathsome offensive brute, yet I can't look away=BB >=20 From owner-atom-syntax@mail.imc.org Thu Dec 14 19:57:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gv1Nr-0005cv-Ra for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 19:57:07 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gv1Nq-0000uN-1N for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 19:57:07 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBF0ee1b001315; Thu, 14 Dec 2006 17:40:40 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBF0eehe001314; Thu, 14 Dec 2006 17:40:40 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from csmtp1.b-one.net (csmtp.b-one.net [195.47.247.21]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBF0edxO001308 for ; Thu, 14 Dec 2006 17:40:40 -0700 (MST) (envelope-from asbjorn@tigerstaden.no) Received: from quark (72.84-48-117.nextgentel.com [84.48.117.72]) by csmtp1.b-one.net (Postfix) with ESMTP id 4B8751911559F; Fri, 15 Dec 2006 01:40:39 +0100 (CET) To: "Tim Bray" , "Bob Wyman" Subject: Re: Atom Entry docs From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Cc: atom-syntax Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <457F30B7.1020100@sun.com> <45be5cd40612132023t76f58abcnf5426a2ef7c1320d@mail.gmail.com> <45818321.5080908@sun.com> Date: Fri, 15 Dec 2006 01:43:08 +0100 Message-ID: In-Reply-To: <45818321.5080908@sun.com> User-Agent: Opera Mail/9.10 (Win32) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id kBF0ee1b001315 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 On Thu, 14 Dec 2006 18:00:17 +0100, Tim Bray wrote: > Bob Wyman wrote: > >> There is, I think, a compromise position here which will avoid breakin= g =20 >> those existing implementations which follow the existing RFC's. > > In case you haven't noticed, the WG is hopelessly split = =20 > between the new-media-type option and the media-type-parameter option. = =20 > If a few people were to put up their hands and say "yeah what Bob said"= =20 > your co-chairs would probably do a hasty consensus grab. *Hands up* =ABWhat Bob said=BB --=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 Thu Dec 14 20:06:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gv1Wu-0000yJ-J2 for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 20:06:28 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gv1Wr-0002iF-QH for atompub-archive@lists.ietf.org; Thu, 14 Dec 2006 20:06:28 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBF0kKA7001682; Thu, 14 Dec 2006 17:46:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBF0kKtP001681; Thu, 14 Dec 2006 17:46:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from csmtp1.b-one.net (csmtp.b-one.net [195.47.247.21]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBF0kJ85001675 for ; Thu, 14 Dec 2006 17:46:20 -0700 (MST) (envelope-from asbjorn@tigerstaden.no) Received: from quark (72.84-48-117.nextgentel.com [84.48.117.72]) by csmtp1.b-one.net (Postfix) with ESMTP id 23B4A19115570; Fri, 15 Dec 2006 01:46:19 +0100 (CET) Date: Fri, 15 Dec 2006 01:48:48 +0100 To: "James M Snell" Subject: Re: Atom Entry Documents From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Cc: "Mark Nottingham" , "Mark Baker" , atom-syntax Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <457C5DD9.9070309@gmail.com> <457E22E9.3010805@gmail.com> <457E5CAD.8010605@gmail.com> <4581EEE1.8050209@gmail.com> Message-ID: In-Reply-To: <4581EEE1.8050209@gmail.com> User-Agent: Opera Mail/9.10 (Win32) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id kBF0kKA7001682 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 On Fri, 15 Dec 2006 01:40:01 +0100, James M Snell =20 wrote: > Quite a few folks seemed to have a preference to a separate doc. What does "quite a few folks" mean wrt consensus? What reasons are there = =20 not to include this in the APP specification? --=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 Fri Dec 15 00:16:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gv5RK-0004c0-JU for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 00:16:58 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gv5RG-0002oZ-6r for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 00:16:58 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBF4uN39030480; Thu, 14 Dec 2006 21:56:23 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBF4uNAN030479; Thu, 14 Dec 2006 21:56:23 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBF4uLua030471 for ; Thu, 14 Dec 2006 21:56:22 -0700 (MST) (envelope-from joe.gregorio@gmail.com) Received: by ug-out-1314.google.com with SMTP id j3so862531ugf for ; Thu, 14 Dec 2006 20:56:20 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=lHAcie/boggod5TNgfxUW2N0mYyau07zmfCxJ41ZxK3J1hcvlzDXbYTRnenQViUViQ2YJvNSlNMYYCHvyLJ/rQbtVuiVbkZFEallXVIMJJ9W22L1eDrA5EVu0dHbEhfnG9yIraelFQM5JazX1Kzi6Oye7/SwWBVte32+Hp+5cEo= Received: by 10.78.201.2 with SMTP id y2mr206194huf.1166158580422; Thu, 14 Dec 2006 20:56:20 -0800 (PST) Received: by 10.78.191.4 with HTTP; Thu, 14 Dec 2006 20:56:20 -0800 (PST) Message-ID: <3f1451f50612142056n6615343bwd117de5973a1698a@mail.gmail.com> Date: Thu, 14 Dec 2006 23:56:20 -0500 From: "Joe Gregorio" To: "Sam Ruby" Subject: Re: AD Evaluation of draft-ietf-atompub-protocol-11 Cc: "Lisa Dusseault" , Atom , "atom-protocol Protocol" In-Reply-To: <4581C432.3010208@intertwingly.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8BD53B7C-5B43-4F2D-8DC5-0281CCB84B84@commerce.net> <3f1451f50612070836h45091080k851cece2198c464a@mail.gmail.com> <4581C432.3010208@intertwingly.net> X-Google-Sender-Auth: ccaa331f48a7709e Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.1 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 On 12/14/06, Sam Ruby wrote: > I believe I first saw this in a response made by Roy Fielding to an > assertion that servers must treat HTTP PUT as a bit-for-bit copy, but I > can't immediately find the reference. http://www.imc.org/atom-protocol/mail-archive/msg05425.html > In any case: clients must always > consider the possibility that the server processes other requests (even > internally generated ones) between the time the one the client issued > and the next request the server choses to process. Such requests could > partially or completely change the representation of the resource. > > - Sam Ruby > -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Fri Dec 15 00:39:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gv5n4-00031s-Qb for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 00:39:26 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gv5n2-0005FF-Ui for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 00:39:26 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBF5Nr1P034145; Thu, 14 Dec 2006 22:23:53 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBF5Nr8i034144; Thu, 14 Dec 2006 22:23:53 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBF5NnKq034136 for ; Thu, 14 Dec 2006 22:23:52 -0700 (MST) (envelope-from joe.gregorio@gmail.com) Received: by ug-out-1314.google.com with SMTP id j3so868442ugf for ; Thu, 14 Dec 2006 21:23:48 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=JOaNkKEnV+exr7kBKLwteOtTIW9pNt0IP4uUCihEasDwPhEwQ9UX6Hfh+7pm0C2VEsPp3aSeHgTbfiu4gmLzFsNBW0v45Hi8CqHdVBlMTvukhEocgqI5nVDgAwIMlnLe4PW7+9md+Tg9Yg1Dmmc3gBtN6EQ3rgEVpS6yjiTm+Nk= Received: by 10.78.204.20 with SMTP id b20mr222241hug.1166160228432; Thu, 14 Dec 2006 21:23:48 -0800 (PST) Received: by 10.78.191.4 with HTTP; Thu, 14 Dec 2006 21:23:48 -0800 (PST) Message-ID: <3f1451f50612142123x1a054a0docfe2ea543c52af6d@mail.gmail.com> Date: Fri, 15 Dec 2006 00:23:48 -0500 From: "Joe Gregorio" To: "Lisa Dusseault" Subject: Re: AD Evaluation of draft-ietf-atompub-protocol-11 Cc: Atom , "atom-protocol Protocol" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8BD53B7C-5B43-4F2D-8DC5-0281CCB84B84@commerce.net> <3f1451f50612070836h45091080k851cece2198c464a@mail.gmail.com> X-Google-Sender-Auth: d22fe420d4af2e07 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.1 (+) X-Scan-Signature: 25620135586de10c627e3628c432b04a On 12/14/06, Lisa Dusseault wrote: > This requirement has to be stated explicitly, at least as a SHOULD. This is > the kind of thing that clients come to completely rely on, and then you find > some special-purpose server that decides this doesn't fit in its model. > "Well, the spec doesn't require me to accept link relations which point to > other servers." Finger-pointing rather than interoperability. Older versions of the spec had this wording: http://bitworking.org/projects/atom/draft-gregorio-09.html#rfc.section.4.3 "This RFC does not specify the form of the URIs that are used. The URI space of each server is controlled, as defined by HTTP, by the server alone. What this RFC does specify are the formats of the files that are exchanged and the actions that can be performed on the URIs embedded in those files." Something along those lines could be added back in. >>> Can a server ever ignore part of an edit and successfully process the rest? > >> Yes. Think of a client that throws in a slew of random link elements with >> relations my server implementation doesn't understand. Same with foreign >> markup. The server is in charge. > I completely disagree with this. > It is way too unpredictable for clients to > deal with. Clients are left with the illusion of flexibility -- it *seems* > you can use Atom syntax extensions and do creative things that other > extended clients can understand -- but in fact the server can alter this at > will leaving the client without any control over what it's really > publishing. This happens *all the time* in the real world. Many blog comment systems have 'Preview' buttons. Why? Because you never know how the server is going to handle your text. Yes, it might be nice, in the future, to add a way for a server to advertise its capabilities, but we do not have the real world experience with the protocol to know what that should look like. > In many cases, the client won't even want the server to store > some stripped version of what it POSTed, because it can really change the > meaning of some entry to have the server strip some of the content and > markup. Imagine removing the start time and location when I'm trying to > publish an event entry to what I believe ought to be a calendar feed. > > Some server changes to submitted documents is of course going to be > allowable (edit dates, server-provided IDs, changes which are effectively > XML canonicalization) but I believe these need to be limited. The general > case, which is how servers deal with unrecognized elements, needs to be > severely limited so that the server can either reject the whole request or > store as provided. I'm sorry but we've already argued this to death on the list and there is nothing in HTTP which supports that view [1]. We've even reviewed the scenario you are talking about and came to the opposite conclusion: http://www.imc.org/atom-protocol/mail-archive/msg05415.html This is the documented consensus of the WG. The next draft will have verbage that makes this position clearer. If some implementations find that too loose and want octet-for-octet storage they can use always WebDAV. [1] http://www.imc.org/atom-protocol/mail-archive/msg05415.html Thanks, -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Fri Dec 15 02:45:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gv7lQ-0002UM-EK for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 02:45:52 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gv7lN-0006LA-W4 for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 02:45:52 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBF7Q2k7045152; Fri, 15 Dec 2006 00:26:02 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBF7Q2UE045151; Fri, 15 Dec 2006 00:26:02 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.webfaction.com (mail1.webfaction.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBF7Q0oQ045145 for ; Fri, 15 Dec 2006 00:26:01 -0700 (MST) (envelope-from sh@defuze.org) Received: from [192.168.136.165] ([194.221.10.165]) (authenticated bits=0) by mail1.webfaction.com (8.12.11.20060308/8.13.3) with ESMTP id kBF7PsRK022765; Fri, 15 Dec 2006 01:25:58 -0600 Message-ID: <45824DFC.8050507@defuze.org> Date: Fri, 15 Dec 2006 07:25:48 +0000 From: Sylvain Hellegouarch User-Agent: Thunderbird 1.5.0.5 (X11/20060728) MIME-Version: 1.0 To: Eric Scheid CC: Atom Syntax Subject: Re: AD Evaluation of draft-ietf-atompub-protocol-11 References: In-Reply-To: X-Enigmail-Version: 0.94.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: List-Unsubscribe: List-ID: X-Spam-Score: 1.1 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Eric Scheid wrote: > On 15/12/06 7:29 AM, "Sylvain Hellegouarch" wrote: > >> Besides, if you want to do fancy thing with a member, simply post a >> media resource which is an atom entry. This won't be modified by the >> server and will solely be treated a media resource. > > promise? does the spec support this assertion? or is this another case of > "the server is in charge and can accept or change whatever it wants"? > > e. No you are right, this is a gratuitous assertion here. However APP currently describes what a server is allowed to do on a member resource and not on the media resource. It could be interesting to see how extensions to APP could allow the server and the UA to agree on what level of modification each party is entitled to expect. - Sylvain From owner-atom-syntax@mail.imc.org Fri Dec 15 04:16:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gv9B6-0002fM-0t for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 04:16:28 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gv9B4-0001EP-LE for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 04:16:28 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBF8gFWD052870; Fri, 15 Dec 2006 01:42:15 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBF8gFmp052869; Fri, 15 Dec 2006 01:42:15 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id kBF8gDxM052856 for ; Fri, 15 Dec 2006 01:42:13 -0700 (MST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 15 Dec 2006 08:42:12 -0000 Received: from p508F8EF2.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.142.242] by mail.gmx.net (mp048) with SMTP; 15 Dec 2006 09:42:12 +0100 X-Authenticated: #1915285 Message-ID: <45825FDC.3020501@gmx.de> Date: Fri, 15 Dec 2006 09:42:04 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Joe Gregorio CC: Lisa Dusseault , Atom , atom-protocol Protocol Subject: Re: AD Evaluation of draft-ietf-atompub-protocol-11 References: <8BD53B7C-5B43-4F2D-8DC5-0281CCB84B84@commerce.net> <3f1451f50612070836h45091080k851cece2198c464a@mail.gmail.com> <3f1451f50612142123x1a054a0docfe2ea543c52af6d@mail.gmail.com> In-Reply-To: <3f1451f50612142123x1a054a0docfe2ea543c52af6d@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.1 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Joe Gregorio schrieb: > ... > This is the documented consensus of the WG. The next draft will have > verbage that makes this position clearer. If some implementations > find that too loose and want octet-for-octet storage they can use > always WebDAV. > > [1] http://www.imc.org/atom-protocol/mail-archive/msg05415.html WebDAV doesn't make any promises about what servers do upon PUT. It just relies on RFC2616. Best regards, Julian From owner-atom-syntax@mail.imc.org Fri Dec 15 06:37:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvBNB-0006rv-6e for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 06:37:05 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvBN8-0004zF-Ov for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 06:37:05 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBFB6Lpm067348; Fri, 15 Dec 2006 04:06:21 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBFB6LeI067347; Fri, 15 Dec 2006 04:06:21 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-01.southeast.rr.com (ms-smtp-01.southeast.rr.com [24.25.9.100]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBFB6JSd067336; Fri, 15 Dec 2006 04:06:20 -0700 (MST) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.105] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) by ms-smtp-01.southeast.rr.com (8.13.6/8.13.6) with ESMTP id kBFB6GdR019835; Fri, 15 Dec 2006 06:06:16 -0500 (EST) Message-ID: <458281A7.5030502@intertwingly.net> Date: Fri, 15 Dec 2006 06:06:15 -0500 From: Sam Ruby User-Agent: Thunderbird 1.5.0.8 (X11/20061115) MIME-Version: 1.0 To: Joe Gregorio CC: Lisa Dusseault , Atom , atom-protocol Protocol Subject: Re: AD Evaluation of draft-ietf-atompub-protocol-11 References: <8BD53B7C-5B43-4F2D-8DC5-0281CCB84B84@commerce.net> <3f1451f50612070836h45091080k851cece2198c464a@mail.gmail.com> <4581C432.3010208@intertwingly.net> <3f1451f50612142056n6615343bwd117de5973a1698a@mail.gmail.com> In-Reply-To: <3f1451f50612142056n6615343bwd117de5973a1698a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.1 (+) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Joe Gregorio wrote: > On 12/14/06, Sam Ruby wrote: >> I believe I first saw this in a response made by Roy Fielding to an >> assertion that servers must treat HTTP PUT as a bit-for-bit copy, but I >> can't immediately find the reference. > > http://www.imc.org/atom-protocol/mail-archive/msg05425.html That's the one! - Sam Ruby From owner-atom-syntax@mail.imc.org Fri Dec 15 08:01:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvCgb-0004mz-5M for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 08:01:13 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvCgV-000864-Ea for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 08:01:13 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBFCi1KY080009; Fri, 15 Dec 2006 05:44:01 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBFCi12l080008; Fri, 15 Dec 2006 05:44:01 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id kBFChxuF079988 for ; Fri, 15 Dec 2006 05:44:00 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 15 Dec 2006 12:43:58 -0000 Received: from xdsl-87-79-236-202.netcologne.de (EHLO klangraum) [87.79.236.202] by mail.gmx.net (mp031) with SMTP; 15 Dec 2006 13:43:58 +0100 X-Authenticated: #163624 Date: Fri, 15 Dec 2006 13:43:58 +0100 From: "A. Pagaltzis" To: atom-syntax Subject: Re: Atom Entry docs Message-ID: <20061215124358.GF13961@klangraum> Mail-Followup-To: atom-syntax References: <457F30B7.1020100@sun.com> <45be5cd40612132023t76f58abcnf5426a2ef7c1320d@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45be5cd40612132023t76f58abcnf5426a2ef7c1320d@mail.gmail.com> User-Agent: Mutt/1.4.2.1i Organization: haphazard X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 * Bob Wyman [2006-12-14 05:45]: > 1) Define ;type=feed and ;type=entry as optional parameters. > (i.e. get them defined, registered, and "ready to use.") > 2) Leave RFC4287 unchanged. i.e. do NOT re-define > "application/atom-xml" > 3) New specifications MAY require that ;type=entry be used. > (Note: Just because ;type=entry is used DOES NOT imply that > ;type=feed must also be used....) +1 Regards, -- Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Fri Dec 15 08:01:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvChD-00059E-9K for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 08:01:52 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvChA-0008CS-M3 for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 08:01:51 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBFCl8Jw080341; Fri, 15 Dec 2006 05:47:08 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBFCl8X3080340; Fri, 15 Dec 2006 05:47:08 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mtaout01-winn.ispmail.ntl.com (mtaout01-winn.ispmail.ntl.com [81.103.221.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBFCl6rK080331 for ; Fri, 15 Dec 2006 05:47:07 -0700 (MST) (envelope-from djpowell@djpowell.net) Received: from aamtaout03-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com with ESMTP id <20061215124705.KCLZ15018.mtaout01-winn.ispmail.ntl.com@aamtaout03-winn.ispmail.ntl.com>; Fri, 15 Dec 2006 12:47:05 +0000 Received: from cpc1-stok1-0-0-cust704.bagu.cable.ntl.com ([86.4.230.193]) by aamtaout03-winn.ispmail.ntl.com with ESMTP id <20061215124704.GVIX26699.aamtaout03-winn.ispmail.ntl.com@cpc1-stok1-0-0-cust704.bagu.cable.ntl.com>; Fri, 15 Dec 2006 12:47:04 +0000 Date: Fri, 15 Dec 2006 12:47:05 +0000 From: David Powell X-Mailer: The Bat! (v3.85.03) Professional X-Priority: 3 (Normal) Message-ID: <282688936.20061215124705@djpowell.net> To: Henri Sivonen CC: atom-syntax Subject: Re: Atom Entry docs In-Reply-To: <38ADFD5F-2C0F-49FE-87D0-C218EDF59075@iki.fi> References: <457F30B7.1020100@sun.com> <457FB015.8000706@defuze.org> <38ADFD5F-2C0F-49FE-87D0-C218EDF59075@iki.fi> 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: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Thursday, December 14, 2006, 9:04:00 AM, Henri Sivonen wrote: > On Dec 13, 2006, at 17:51, Mark Baker wrote: >> But >> given that an alternative exists which shouldn't break those servers, >> why not use it when there's no apparent downside? > The downside is that implementations that (quite reasonably) assume > that application/atom+xml == feed are also reasonable when they > ignore unknown media type parameters. An example would be an HTML page with rel="alternative" links pointing to a feed and an Atom Entry document. This seems quite a reasonable use-case, yet if we don't create a new MIME type, then I'd expect that all current feed reader implementations would incorrectly detect the entry document to be a feed, which would be very confusing for the user if they select the entry document, and their feed reader attempts to subscribe to the entry document. Which would either work, and they would get subscribed to a feed that doesn't update, or they'd get an error. > Given the options of a new type or a new parameter, I am +1 on the > new type. (Although in general, I don't like the proliferation of > application/*+xml types, because apps need to do root sniffing for > application/xml anyway.) Another issue with MIME parameters is that the old MIME RFCs are inconsistent about the definition of the term "media type", which can mean top-level type, top-level/sub-type, or top-level/sub-type with parameters. When Atom was being developed I asked (several times) whether Atom documents are allowed to contain parameters in places that they specify media types, and I got conflicting answers. My perception is that MIME parameters just don't work very well. Another case for a new type is browser dispatch. Operating systems tend not to use MIME types for deciding which application to use. Whilst a feed reader is a sensible application to open a feed in; an entry document should probably be opened in an editing/publishing application. This is not really possible if we use a MIME parameter to distinguish the two document types. -- Dave From owner-atom-syntax@mail.imc.org Fri Dec 15 08:21:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvD09-0005qu-Ep for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 08:21:25 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvD05-0002pk-1y for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 08:21:25 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBFD8nDS082482; Fri, 15 Dec 2006 06:08:49 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBFD8nrB082481; Fri, 15 Dec 2006 06:08:49 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sam.opera.com (sam.opera.com [193.69.113.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBFD8kOe082474 for ; Fri, 15 Dec 2006 06:08:48 -0700 (MST) (envelope-from annevk@opera.com) Received: from id-c0020 (c529db1cc.cable.wanadoo.nl [82.157.177.204]) (authenticated bits=0) by sam.opera.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id kBFD8gsI018734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 15 Dec 2006 13:08:43 GMT Date: Fri, 15 Dec 2006 14:08:42 +0100 To: "A. Pagaltzis" Subject: Re: Atom Entry docs From: "Anne van Kesteren" Organization: Opera Software Cc: "Atom Syntax" Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <457F30B7.1020100@sun.com> <45be5cd40612132023t76f58abcnf5426a2ef7c1320d@mail.gmail.com> <20061215124358.GF13961@klangraum> Message-ID: In-Reply-To: <20061215124358.GF13961@klangraum> User-Agent: Opera Mail/9.02 (Win32) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by balder-227.proper.com id kBFD8nOe082476 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 On Fri, 15 Dec 2006 13:43:58 +0100, A. Pagaltzis wrote: >> 1) Define ;type=feed and ;type=entry as optional parameters. >> (i.e. get them defined, registered, and "ready to use.") >> 2) Leave RFC4287 unchanged. i.e. do NOT re-define >> "application/atom-xml" >> 3) New specifications MAY require that ;type=entry be used. >> (Note: Just because ;type=entry is used DOES NOT imply that >> ;type=feed must also be used....) > > +1 Did anyone check how widely deployed the entry documents actually are? And how much support there is for them? -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Fri Dec 15 08:26:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvD55-0007Ab-V1 for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 08:26:31 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvD54-0003cF-I4 for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 08:26:31 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBFD9Q8U082543; Fri, 15 Dec 2006 06:09:26 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBFD9Qnl082542; Fri, 15 Dec 2006 06:09:26 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mtaout01-winn.ispmail.ntl.com (mtaout01-winn.ispmail.ntl.com [81.103.221.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBFD9PKa082535 for ; Fri, 15 Dec 2006 06:09:25 -0700 (MST) (envelope-from djpowell@djpowell.net) Received: from aamtaout04-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com with ESMTP id <20061215130924.KWJR15018.mtaout01-winn.ispmail.ntl.com@aamtaout04-winn.ispmail.ntl.com> for ; Fri, 15 Dec 2006 13:09:24 +0000 Received: from cpc1-stok1-0-0-cust704.bagu.cable.ntl.com ([86.4.230.193]) by aamtaout04-winn.ispmail.ntl.com with ESMTP id <20061215130924.QOJA29112.aamtaout04-winn.ispmail.ntl.com@cpc1-stok1-0-0-cust704.bagu.cable.ntl.com> for ; Fri, 15 Dec 2006 13:09:24 +0000 Date: Fri, 15 Dec 2006 13:09:24 +0000 From: David Powell X-Mailer: The Bat! (v3.85.03) Professional X-Priority: 3 (Normal) Message-ID: <1725437059.20061215130924@djpowell.net> To: atom-syntax Subject: Re: Atom Entry docs In-Reply-To: <457F30B7.1020100@sun.com> References: <457F30B7.1020100@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: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 I've always interpreted a kind of inheritance relationship between MIME types. It's never wrong to label an Excel file, an XML document, or an Atom Feed as application/octet-stream, because all of those types ARE octet-streams. It is just not as helpful as it could be. Likewise, it is never wrong to label an Atom Feed, as application/xml. It just isn't being optimally helpful. I think that you have to interpret MIME types this way, otherwise a generic XML processing application which labelled content as application/xml would be standards compliant until the day that the Atom RFC was published when it would become un-compliant overnight without anyone touching the code. I don't think that that is the way that standards are supposed to work. So likewise, I see no harm in inventing application/atomentry+xml. Sure, applications can still use application/atom+xml for entries, they just aren't being as helpful as ones that use the more explicit MIME type. -- Dave From owner-atom-syntax@mail.imc.org Fri Dec 15 09:50:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvEOG-0006I9-10 for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 09:50:24 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvEOB-0006A4-Kw for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 09:50:24 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBFEUx1s091466; Fri, 15 Dec 2006 07:30:59 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBFEUxkv091465; Fri, 15 Dec 2006 07:30:59 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBFEUvDB091459 for ; Fri, 15 Dec 2006 07:30:58 -0700 (MST) (envelope-from joe.gregorio@gmail.com) Received: by nf-out-0910.google.com with SMTP id m18so1080691nfc for ; Fri, 15 Dec 2006 06:30:56 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=ofV9N9EYjSh9T6Ks+6wMudMcHsvMRhYtBb95t4stnL9MNxXxuhgkF9gkZntZ0cxVsiYbW5bcoO1/xcdyQG2MgEX04iMjx8EPqXNtEOmifSmb3+B8itL5wsdFwXTwGZxIcXt8Ju6zOjLiZEJh9S3JeQWsCZwLuh9xfJuftvBcqvA= Received: by 10.49.28.3 with SMTP id f3mr2594133nfj.1166193056252; Fri, 15 Dec 2006 06:30:56 -0800 (PST) Received: by 10.78.191.4 with HTTP; Fri, 15 Dec 2006 06:30:56 -0800 (PST) Message-ID: <3f1451f50612150630g14edf4f0rfe2952df07c908e8@mail.gmail.com> Date: Fri, 15 Dec 2006 09:30:56 -0500 From: "Joe Gregorio" To: "Tim Bray" Subject: Re: Atom Entry docs Cc: "Bob Wyman" , atom-syntax In-Reply-To: <45818321.5080908@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <457F30B7.1020100@sun.com> <45be5cd40612132023t76f58abcnf5426a2ef7c1320d@mail.gmail.com> <45818321.5080908@sun.com> X-Google-Sender-Auth: 522ab4b65e81d3fd Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 On 12/14/06, Tim Bray wrote: > > Bob Wyman wrote: > > There is, I think, a compromise position here which will avoid breaking > > those existing implementations which follow the existing RFC's. > > In case you haven't noticed, the WG is hopelessly split > between the new-media-type option and the media-type-parameter option. > If a few people were to put up their hands and say "yeah what Bob said" > your co-chairs would probably do a hasty consensus grab. +1 to what Bob said. -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Fri Dec 15 11:35:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvG1p-0006Ae-SV for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 11:35:21 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvG1l-0004tC-Av for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 11:35:21 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBFGDE4B003425; Fri, 15 Dec 2006 09:13:14 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBFGDE1i003424; Fri, 15 Dec 2006 09:13:14 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBFGDCSp003414; Fri, 15 Dec 2006 09:13:12 -0700 (MST) (envelope-from Tim.Bray@Sun.COM) Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kBFGDBLu026612; Fri, 15 Dec 2006 09:13:11 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JAB00501OQWAX00@mail-amer.sun.com> (original mail from Tim.Bray@Sun.COM) ; Fri, 15 Dec 2006 09:13:11 -0700 (MST) Received: from [192.168.1.100] (fatwire-204-250.uniserve.ca [216.113.204.251]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JAB0007GP1YH530@mail-amer.sun.com>; Fri, 15 Dec 2006 09:13:11 -0700 (MST) Date: Fri, 15 Dec 2006 08:13:48 -0800 From: Tim Bray Subject: Re: AD Evaluation of draft-ietf-atompub-protocol-11 In-reply-to: To: Lisa Dusseault Cc: Joe Gregorio , Atom , atom-protocol Protocol Message-id: <4582C9BC.8010704@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <8BD53B7C-5B43-4F2D-8DC5-0281CCB84B84@commerce.net> <3f1451f50612070836h45091080k851cece2198c464a@mail.gmail.com> User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.1 (+) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Lisa Dusseault wrote: >>> Can a client modify an entry to contain a link relation element in the >>> following cases: >>> >>> - To point to a resource on a different server entirely? >> >> There is no reason to believe that any of these resource are on >> the same machine to begin with. I could POST to media to machine A >> and have the MLE could be created on machine B and the editable media >> resource itself created on machine C. > > This requirement has to be stated explicitly, at least as a SHOULD. Hmm. One particular operation in the APP is defined as creating two resources; we specify how this is requested and the mechanism by which the server communicates the URIs that identify the newly-created resources. It would feel really weird to me to specify anything about what servers the resources might be on. That's not how URIs work or how the Web works. You can't tell by looking at a URI what server the resource is on, anyhow. The URI might not be an HTTP URI. Two URIs that look very much the same might reference data on different continents. That's the whole point of how URIs work. Having said that, Lisa has already pointed out shortcomings in the number and placement of examples concerning this particular case. I think it'd be a good idea to have the example showing the Media resource showing up at http://media.example.com and the MLE showing up at http://app.example.com. But I'd be very much against side-tripping the protocol definition into any discussion of "servers". >>> Can a server ever ignore part of an edit and successfully process the rest? >>> >> >> Yes. Think of a client that throws in a slew of random link elements with >> relations my server implementation doesn't understand. Same with foreign >> markup. The server is in charge. > > I completely disagree with this. It is way too unpredictable for clients to deal with. Well, except there are several examples of APP clients that seem to do just fine. Example: After extensive discussion, the WG achieved consensus that APP servers are *not* required to retain foreign markup. Example: It is perfectly possible to imagine a server that morphs or prunes incoming entries for reasons of political censorship, security policies, markup standards, spelling-correction, automatic translation, or lots of other things we can't possibly imagine. Example: my Ape protocol exerciser posts entries with a separate and fields. At least one of the servers I've tested against accepts posts but discards my summary and generates its own, algorithmically. The range of things a server can usefully choose to do currently exceeds our ability to specify or constrain. Fortunately, in HTTP, we have a protocol the semantics of whose state-changing verbs PUT and POST are remarkably well-matched for these interactions whereby a client says "please take this and publish it and tell me what you did" and the server says "OK, here's what I made of it." The current WG consensus, way better than "rough", is that this level of interoperation is useful. That consensus seems to be supported by implementation experience. Lisa, perhaps the problem is that I'm reacting to a fairly general statement of concern. Do you have some specific suggestions as to how server behavior could be limited or formally described? -Tim From owner-atom-syntax@mail.imc.org Fri Dec 15 12:29:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvGrw-0003vp-CS for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 12:29:12 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvGru-0005X6-Fr for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 12:29:11 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBFHCp1b010527; Fri, 15 Dec 2006 10:12:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBFHCp2n010526; Fri, 15 Dec 2006 10:12:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBFHCnS2010520 for ; Fri, 15 Dec 2006 10:12:50 -0700 (MST) (envelope-from hwinkler@gmail.com) Received: by nf-out-0910.google.com with SMTP id m18so1112292nfc for ; Fri, 15 Dec 2006 09:12:49 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=FXMglMOGq5+r2s+J2wOla2xtzfhFWS7rDYJrccyt5yhTHuHr3KVBRpzys3ubs3rtfpl7SNrQUBLfPCpe9U4YcEh1SqV3aBV5E+TkptwWHFDohn32TKvj6LLQ62MMLEXrClEQ8iTU9FxCOORkLleoTjnqvocDwIuLnqJgR2qveAE= Received: by 10.49.41.18 with SMTP id t18mr314708nfj.1166202768915; Fri, 15 Dec 2006 09:12:48 -0800 (PST) Received: by 10.82.116.19 with HTTP; Fri, 15 Dec 2006 09:12:48 -0800 (PST) Message-ID: <927441b30612150912t4c74f031g68bbf02e00273e58@mail.gmail.com> Date: Fri, 15 Dec 2006 11:12:48 -0600 From: "Hugh Winkler" To: "David Powell" Subject: Re: Atom Entry docs Cc: atom-syntax In-Reply-To: <1725437059.20061215130924@djpowell.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <457F30B7.1020100@sun.com> <1725437059.20061215130924@djpowell.net> X-Google-Sender-Auth: 72a72514f04c59ca Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 On 12/15/06, David Powell wrote: > > > I've always interpreted a kind of inheritance relationship between > MIME types. > It's telling that James felt it natural to choose the name "type" for the parameter. Because it really is naming a new type of document. In programming, whenever I find myself sticking a member named "type" into some class definition, I usually have to admit that I'm hacking in a new subclass definition and subverting the type system. That's what defining the "type" parameter is doing. Hugh From owner-atom-syntax@mail.imc.org Fri Dec 15 14:36:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvIqq-0004U3-Hs for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 14:36:12 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvIqm-0005lN-00 for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 14:36:12 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBFJGIsH024513; Fri, 15 Dec 2006 12:16:18 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBFJGHuF024511; Fri, 15 Dec 2006 12:16:18 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBFJGExv024503 for ; Fri, 15 Dec 2006 12:16:15 -0700 (MST) (envelope-from bobwyman@gmail.com) Received: by py-out-1112.google.com with SMTP id f31so465740pyh for ; Fri, 15 Dec 2006 11:16:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=oaixk+2nFcD0hkPc6jrh3O3Q1I5HDOWV2isFLL3s3c0Os2QyZnXbaWYIf0YQ0UlFHuOaxltjS5R2sPLfrorOAhj2ODtAI3g9rLrHdjyY903ho5X265k7OgP4CNR2KkXijKjPehknylgiR0+JA9i2eatVc8ue8R6DB/HXUeP84rw= Received: by 10.35.112.4 with SMTP id p4mr382657pym.1166210174303; Fri, 15 Dec 2006 11:16:14 -0800 (PST) Received: by 10.35.15.12 with HTTP; Fri, 15 Dec 2006 11:16:14 -0800 (PST) Message-ID: <45be5cd40612151116k3c915332ge35dada186c0ea3b@mail.gmail.com> Date: Fri, 15 Dec 2006 14:16:14 -0500 From: "Bob Wyman" To: "Hugh Winkler" Subject: Re: Atom Entry docs Cc: "David Powell" , atom-syntax In-Reply-To: <927441b30612150912t4c74f031g68bbf02e00273e58@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_128659_20178849.1166210174219" References: <457F30B7.1020100@sun.com> <1725437059.20061215130924@djpowell.net> <927441b30612150912t4c74f031g68bbf02e00273e58@mail.gmail.com> X-Google-Sender-Auth: a2aee3718ab73d29 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.5 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b ------=_Part_128659_20178849.1166210174219 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 12/15/06, Hugh Winkler wrote: > > It's telling that James felt it natural to choose the name "type" for > the parameter. Because it really is naming a new type of document. What would be better than "type?" Might "root" work better? It seems to me that "application/atom+xm;type=entry" describes "an Atom document whose root element is `'." The type of the document is "atom" but it is a "kind" or "type" of atom document that has an element as it's root. Unfortunately, "type" is being used to mean two completely different things in this context. Would you be happier if the proposal was for the following? application/atom+xml;root=entry application/atom+xml;root=feed One argument for using "root" is that it might be a usage that would be useful with other mediatypes which have more than one possible root element. Also, using "root" as the parameter name would ensure that folk don't get confused into thinking that there is any kind of subtyping going on here -- specifying ";type=root" is simply providing meta-data which describes a constrained use of the general atom type -- it is no different from doing something like saying: "I won't except any feeds that don't have elements." or, "This feed contains no more than 256 entry elements." If one is being exceptionally formal or overly pedantic, I can see how you might argue that a feed constrained to fewer than 257 entries is somehow a sub-type of sub-class of the more general atom type. But, since every distinct instance of the atom type can be described in similar manners, it would mean that every atom instance is a "subtype." In some contexts, this observation might be useful. I don't think, however, that such precision is useful in the realm for which we normally are designing Atom... bob wyman ------=_Part_128659_20178849.1166210174219 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 12/15/06, Hugh Winkler <hughw@wellstorm.com> wrote:
It's telling that James felt it natural to choose the name "type"= for
the parameter. Because it really is naming a new type of document.<= /blockquote>

What would be better than "type?" Might &quo= t;root" work better?

It seems to me that "application/atom+xm;type=3Dentry" de= scribes "an Atom document whose root element is `<entry/>'."= ; The type of the document is "atom" but it is a "kind"= or "type" of atom document that has an <entry/> element as= it's root. Unfortunately, "type" is being used to mean two compl= etely different things in this context.

Would you be happier if the proposal was for the following?

=     application/atom+xml;root=3Dentry
   = application/atom+xml;root=3Dfeed

One argument for using "root&= quot; is that it might be a usage that would be useful with other mediatype= s which have more than one possible root element. Also, using "root&qu= ot; as the parameter name would ensure that folk don't get confused into th= inking that there is any kind of subtyping going on here -- specifying &quo= t;;type=3Droot" is simply providing meta-data which describes a constr= ained use of the general atom type -- it is no different from doing somethi= ng like saying: "I won't except any feeds that don't have <icon/>= ; elements." or, "This feed contains no more than 256 entry eleme= nts." If one is being exceptionally formal or overly pedantic, I can s= ee how you might argue that a feed constrained to fewer than 257 entries is= somehow a sub-type of sub-class of the more general atom type. But, since = every distinct instance of the atom type can be described in similar manner= s, it would mean that every atom instance is a "subtype." In some= contexts, this observation might be useful. I don't think, however, that s= uch precision is useful in the realm for which we normally are designing At= om...

bob wyman


------=_Part_128659_20178849.1166210174219-- From owner-atom-syntax@mail.imc.org Fri Dec 15 14:55:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvJ99-0003zV-FO for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 14:55:07 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvJ97-0008Do-BN for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 14:55:06 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBFJcp9h027554; Fri, 15 Dec 2006 12:38:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBFJcplQ027553; Fri, 15 Dec 2006 12:38:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBFJcoN8027546 for ; Fri, 15 Dec 2006 12:38:51 -0700 (MST) (envelope-from hwinkler@gmail.com) Received: by nf-out-0910.google.com with SMTP id m18so1138265nfc for ; Fri, 15 Dec 2006 11:38:49 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=jW42rTP1DX+d9NPcoSGuXgtQ9ZXfoAiJ8IRVk1qiynT7tzk4G6fusIuZCJg7JW2jk0DZh3IiByK3aDq2XX3f9Vy0/PUEMduDY5iQpMfAkdo2IdE9yCpS6b3o9XJPazvp4xLSXHoWmbik5sIa570oFVYBzl/v3wPIAj8IO7Mau2o= Received: by 10.82.179.9 with SMTP id b9mr72066buf.1166211523005; Fri, 15 Dec 2006 11:38:43 -0800 (PST) Received: by 10.82.116.19 with HTTP; Fri, 15 Dec 2006 11:38:42 -0800 (PST) Message-ID: <927441b30612151138l6d806e8bye2b78740b8bfaa52@mail.gmail.com> Date: Fri, 15 Dec 2006 13:38:42 -0600 From: "Hugh Winkler" To: "Bob Wyman" Subject: Re: Atom Entry docs Cc: "David Powell" , atom-syntax In-Reply-To: <45be5cd40612151116k3c915332ge35dada186c0ea3b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline References: <457F30B7.1020100@sun.com> <1725437059.20061215130924@djpowell.net> <927441b30612150912t4c74f031g68bbf02e00273e58@mail.gmail.com> <45be5cd40612151116k3c915332ge35dada186c0ea3b@mail.gmail.com> X-Google-Sender-Auth: 354deb77d101d811 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kBFJcpN8027548 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 On 12/15/06, Bob Wyman wrote: > On 12/15/06, Hugh Winkler wrote: > > > It's telling that James felt it natural to choose the name "type" for > > the parameter. Because it really is naming a new type of document. > > > What would be better than "type?" Might "root" work better? No, my point was that "type" is right on the money; it correctly describes what you're doing... defining a new mime type, but overloading the parameter mechanism to do so. > > > It seems to me that "application/atom+xm;type=entry" describes "an Atom document whose root element is `'." The type of the document is "atom" but it is a "kind" or "type" of atom document that has an element as it's root. Unfortunately, "type" is being used to mean two completely different things in this context. > > Would you be happier if the proposal was for the following? > > application/atom+xml;root=entry > application/atom+xml;root=feed > No. > One argument for using "root" is that it might be a usage that would be useful with other mediatypes which have more than one possible root element. Also, using "root" as the parameter name would ensure that folk don't get confused into thinking that there is any kind of subtyping going on here -- specifying ";type=root" is simply providing meta-data which describes a constrained use of the general atom type -- it is no different from doing something like saying: "I won't except any feeds that don't have elements." or, "This feed contains no more than 256 entry elements." If one is being exceptionally formal or overly pedantic, I can see how you might argue that a feed constrained to fewer than 257 entries is somehow a sub-type of sub-class of the more general atom type. But, since every distinct instance of the atom type can be described in similar manners, it would mean that every atom instance is a "subtype." In some contexts, this observation might be useful. I! don't think, however, that such precision is useful in the realm for which we normally are designing Atom... Straw man: I didn't even remotely imply that all uses of mime parameters is the same as subclassing. In this case, yes, as betrayed by the natural choice of language. When James's proposal came up, I happened to have just constructed some server code (not Atom-specific) to dispatch PUT and POST based on the mime type of the request entity. You just do a simple string match on the bit in front of the semicolon, and dispatch based on that. It's very easy to parameterize that mechanism: any plugin can declare it handles "application/atom+xml". It's not such a big deal if the handler for "application/atom+xml" has to further dispatch based on the parameters, but you can see it's duplicative. The reason for the duplication is a little imperfection in the modelling. If the WG decides other considerations outweigh this one, programmers will handle it. No biggie. But lots of mime type dispatch code lives in browsers, and in servers, and most of the mime.types-ish files you see never have a semicolon in them. (James is correct that you can put the parameter in mime.types for Apache, but of course that is a case of dispatching based on file extension, not on mime type). Hugh From owner-atom-syntax@mail.imc.org Fri Dec 15 15:53:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvK3M-0008Hx-EE for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 15:53:12 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvK3L-0007fz-0y for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 15:53:12 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBFKZKiE033502; Fri, 15 Dec 2006 13:35:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBFKZKTN033501; Fri, 15 Dec 2006 13:35:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBFKZJHn033495 for ; Fri, 15 Dec 2006 13:35:19 -0700 (MST) (envelope-from lisa@osafoundation.org) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id F1D9E142262; Fri, 15 Dec 2006 12:35:18 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02834-03; Fri, 15 Dec 2006 12:35:16 -0800 (PST) Received: from [10.1.1.214] (ip10.commerce.net [157.22.41.10]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 7036F142260; Fri, 15 Dec 2006 12:35:16 -0800 (PST) In-Reply-To: <457E5CAD.8010605@gmail.com> References: <457C5DD9.9070309@gmail.com> <457E22E9.3010805@gmail.com> <457E5CAD.8010605@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <04B1F571-F2DA-4E55-B9ED-B87A7272634F@osafoundation.org> Cc: Mark Nottingham , Mark Baker , atom-syntax Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: Atom Entry Documents Date: Fri, 15 Dec 2006 12:35:10 -0800 To: James M Snell X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 I don't feel that changing parts of RFC4287 is appropriate for an individual draft, particularly when the WG that did RFC4287 exists. Certainly in order to update RFC4287 it would *have* to be Proposed Standard. What constitutes an update or change (rather than an optional extension) might be open to some debate. Echoing Tim, I agree there's no problem with James doing an individual draft for now so that everybody can evaluate a specific proposal and suggest what should be done with it. Lisa On Dec 11, 2006, at 11:39 PM, James M Snell wrote: > > *If* the document proceeds to Proposed Standard, the new RFC would > update RFC4287 either by adding a new type param or by deprecating the > use of application/atom+xml for atom entry documents in favor of a new > media type. No other part of RFC4287 would be affected. > > Ideally, I would much rather this be a WG draft. I pinged Tim > about it > the other day and he suggested that I go ahead with a I-D for now and > that we can explore whether or not to move forward with it as a WG > draft > later. > > - James > > Mark Nottingham wrote: >> What would the relationship of that document be to RFC4287? >> >> Cheers, >> >> >> On 2006/12/11, at 7:32 PM, James M Snell wrote: >> >>> The I-D would be an individual draft, not a WG draft. >> >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> > From owner-atom-syntax@mail.imc.org Fri Dec 15 16:07:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvKHB-0001Bh-1H for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 16:07:29 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvKGY-0001Ul-Vp for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 16:06:54 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBFKpeDt035112; Fri, 15 Dec 2006 13:51:40 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBFKpela035111; Fri, 15 Dec 2006 13:51:40 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.249]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBFKpdxh035098 for ; Fri, 15 Dec 2006 13:51:40 -0700 (MST) (envelope-from joe.gregorio@gmail.com) Received: by an-out-0708.google.com with SMTP id d33so303162and for ; Fri, 15 Dec 2006 12:51:37 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=kXVOo8GnikHKqc/1PBHdtI+lRI92+ordS0hxi0NyeanB9wnh9fWwQszlJUJKGOzM7v+mvx3HlNrqaYUhke6A2u36SeWwzXtWhXMWl/RlIOf6JI6GpLDM0iTHT8wadMiX0egm5GQunUJB/VzN1TpqDSnTGQ4nmvVodmKqs1VF+hE= Received: by 10.78.160.2 with SMTP id i2mr354457hue.1166215895226; Fri, 15 Dec 2006 12:51:35 -0800 (PST) Received: by 10.78.191.4 with HTTP; Fri, 15 Dec 2006 12:51:35 -0800 (PST) Message-ID: <3f1451f50612151251t7537dac2x36476d0e0184738a@mail.gmail.com> Date: Fri, 15 Dec 2006 15:51:35 -0500 From: "Joe Gregorio" To: "James M Snell" Subject: Re: Atom Entry Documents Cc: atom-syntax In-Reply-To: <457C5DD9.9070309@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <457C5DD9.9070309@gmail.com> X-Google-Sender-Auth: 713e5e7570e1f01e Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab On 12/10/06, James M Snell wrote: > > Ok, the recent discussion seems to point towards a consensus towards > distinctly flagging Entry Documents in the media type. The only > question is whether or not to use a new media type or an optional type > param. I'm going to write up an I-D this week. > > Please let me know which of the two approaches below y'all prefer... > > Option A) Optional Type Param > > application/atom+xml; type=entry > application/atom+xml; type=feed +1 -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Fri Dec 15 16:12:15 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvKLn-0004uI-FZ for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 16:12:15 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GvKLl-0004Gd-UN for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 16:12:15 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBFKvbig035673; Fri, 15 Dec 2006 13:57:37 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBFKvb95035672; Fri, 15 Dec 2006 13:57:37 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBFKvah0035664 for ; Fri, 15 Dec 2006 13:57:37 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i20so503660wra for ; Fri, 15 Dec 2006 12:57:36 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=XO4pIEwYcNPVCraE2iG5C23a+7zKIr45w8GA3IMo+lMnbOAuHDQMhLs5ZSazAsIWoeTSADEME2iGsLhD8O8NNyKu21jt2djoymAziFUWnsmQdn6RKupRC0lDfN3NhHvk1GGuTqf0rkzUtBx2Jq9OMnt1ulrsm8j4LWuHn9izb8g= Received: by 10.90.25.3 with SMTP id 3mr1489220agy.1166216256080; Fri, 15 Dec 2006 12:57:36 -0800 (PST) Received: from ?192.168.1.109? ( [67.181.218.96]) by mx.google.com with ESMTP id 29sm6249114wrl.2006.12.15.12.57.33; Fri, 15 Dec 2006 12:57:35 -0800 (PST) Message-ID: <45830C3A.9000409@gmail.com> Date: Fri, 15 Dec 2006 12:57:30 -0800 From: James M Snell User-Agent: Thunderbird 1.5.0.8 (X11/20061115) MIME-Version: 1.0 To: Lisa Dusseault CC: Mark Nottingham , Mark Baker , atom-syntax Subject: Re: Atom Entry Documents References: <457C5DD9.9070309@gmail.com> <457E22E9.3010805@gmail.com> <457E5CAD.8010605@gmail.com> <04B1F571-F2DA-4E55-B9ED-B87A7272634F@osafoundation.org> In-Reply-To: <04B1F571-F2DA-4E55-B9ED-B87A7272634F@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 +1 many times over. Lisa Dusseault wrote: > I don't feel that changing parts of RFC4287 is appropriate for an > individual draft, particularly when the WG that did RFC4287 exists. > Certainly in order to update RFC4287 it would *have* to be Proposed > Standard. What constitutes an update or change (rather than an optional > extension) might be open to some debate. > [snip] From owner-atom-syntax@mail.imc.org Fri Dec 15 18:07:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvM90-0002gw-DZ for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 18:07:10 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvM8y-0001iA-UE for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 18:07:10 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBFMppR8046947; Fri, 15 Dec 2006 15:51:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBFMppfu046946; Fri, 15 Dec 2006 15:51:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBFMpnrN046936 for ; Fri, 15 Dec 2006 15:51:51 -0700 (MST) (envelope-from foolistbar@googlemail.com) Received: by an-out-0708.google.com with SMTP id d33so310782and for ; Fri, 15 Dec 2006 14:51:48 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:in-reply-to:references:mime-version:x-priority:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=oB+awbICr7gGNFOflpzp9EKGa1xg3sAXM+mQCNdxWQ2g3gOmtKYEaw5oy0PA3qgWelj0vxhUCE+6pzrlgbjrvHTuvHWh8goGiEuLb7wZD3AgaSMutKSQFhDArQkyGcC+u8rGmd7z60Yz7bDFmDNVFUM8T8809qc1G2sIRe5Jp0I= Received: by 10.100.132.16 with SMTP id f16mr1050815and.1166223108777; Fri, 15 Dec 2006 14:51:48 -0800 (PST) Received: from ?192.168.0.7? ( [86.139.123.225]) by mx.google.com with ESMTP id c14sm6314597ana.2006.12.15.14.51.47; Fri, 15 Dec 2006 14:51:48 -0800 (PST) In-Reply-To: <282688936.20061215124705@djpowell.net> References: <457F30B7.1020100@sun.com> <457FB015.8000706@defuze.org> <38ADFD5F-2C0F-49FE-87D0-C218EDF59075@iki.fi> <282688936.20061215124705@djpowell.net> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1F43E0FD-AA18-4649-87B1-0CF9DE877FF1@googlemail.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Geoffrey Sneddon Subject: Re: Atom Entry docs Date: Fri, 15 Dec 2006 22:51:45 +0000 To: David Powell X-Mailer: Apple Mail (2.752.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 On 15 Dec 2006, at 12:47, David Powell wrote: > An example would be an HTML page with rel="alternative" links > pointing to a feed and an Atom Entry document. This seems quite a > reasonable use-case, yet if we don't create a new MIME type, then I'd > expect that all current feed reader implementations would incorrectly > detect the entry document to be a feed, which would be very confusing > for the user if they select the entry document, and their feed reader > attempts to subscribe to the entry document. Which would either work, > and they would get subscribed to a feed that doesn't update, or they'd > get an error. This is my real issue with just using a MIME type parameter - feed readers normally just ignore an unknown MIME type parameter, so we'd have the same issue (entry documents showing up with feed documents). Creating a MIME type would get around this issue - I think this is really just a time when we have to step back and look at where we are, and choose what to do in this situation, regardless of what is technically correct. - Geoffrey Sneddon From owner-atom-syntax@mail.imc.org Fri Dec 15 19:17:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvNEm-0003NO-35 for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 19:17:12 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvNEk-0001XE-Im for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 19:17:12 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBFNxK6I053295; Fri, 15 Dec 2006 16:59:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBFNxK1r053294; Fri, 15 Dec 2006 16:59:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from csmtp1.b-one.net (csmtp.b-one.net [195.47.247.21]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBFNxJSm053285 for ; Fri, 15 Dec 2006 16:59:20 -0700 (MST) (envelope-from asbjorn@tigerstaden.no) Received: from quark (72.84-48-117.nextgentel.com [84.48.117.72]) by csmtp1.b-one.net (Postfix) with ESMTP id 9F58C19116732; Sat, 16 Dec 2006 00:59:18 +0100 (CET) Date: Sat, 16 Dec 2006 01:01:09 +0100 To: "David Powell" , "Henri Sivonen" Subject: Re: Atom Entry docs From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Cc: atom-syntax Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <457F30B7.1020100@sun.com> <457FB015.8000706@defuze.org> <38ADFD5F-2C0F-49FE-87D0-C218EDF59075@iki.fi> <282688936.20061215124705@djpowell.net> Message-ID: In-Reply-To: <282688936.20061215124705@djpowell.net> User-Agent: Opera Mail/9.10 (Win32) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id kBFNxK6I053295 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a On Fri, 15 Dec 2006 13:47:05 +0100, David Powell = =20 wrote: > An example would be an HTML page with rel=3D"alternative" links > pointing to a feed and an Atom Entry document. My thought on this is that that's actually broken. If not according to RF= C =20 4287 or anything else, it's most likely wrong semantics involved. Ether =20 the current HTML document is an alternate representation of the Atom =20 Entry, or it is an alternate representation of the Feed. In any case, the relation type 'feed' would be better suited for the feed= =20 reference and 'alternate' would suit the Entry reference if the Entry =20 indeed was an alternate representation of the HTML document. Alternate representation of web site front pages are typically Feeds, =20 alternate representations of article pages are typically Entries. There's= =20 very few cases where a Feed and an Entry can be alternate representations= =20 of the same resource. --=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 Fri Dec 15 19:45:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvNfn-0000AX-Jo for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 19:45:07 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvNfi-0004KL-To for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 19:45:07 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBG0WLYw055400; Fri, 15 Dec 2006 17:32:21 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBG0WLJd055399; Fri, 15 Dec 2006 17:32:21 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mcom.com (r2d2.aoltw.net [64.236.137.26]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBG0WKaM055392 for ; Fri, 15 Dec 2006 17:32:20 -0700 (MST) (envelope-from jpanzer@aol.net) Received: from areophany.nscp.aoltw.net (areophany.nscp.aoltw.net [10.169.155.201]) by mcom.com (8.10.0/8.10.0) with ESMTP id kBG0VVd05479; Fri, 15 Dec 2006 16:31:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by areophany.nscp.aoltw.net (Postfix) with ESMTP id 039E1CCC11; Fri, 15 Dec 2006 16:31:31 -0800 (PST) Received: from areophany.nscp.aoltw.net ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20321-03; Fri, 15 Dec 2006 16:31:29 -0800 (PST) Received: from [10.169.155.201] (areophany.nscp.aoltw.net [10.169.155.201]) by areophany.nscp.aoltw.net (Postfix) with ESMTP id 466ACCCBFC; Fri, 15 Dec 2006 16:31:29 -0800 (PST) Message-ID: <45833E61.6090907@aol.net> Date: Fri, 15 Dec 2006 16:31:29 -0800 From: John Panzer User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= Cc: David Powell , Henri Sivonen , atom-syntax Subject: Re: Atom Entry docs References: <457F30B7.1020100@sun.com> <457FB015.8000706@defuze.org> <38ADFD5F-2C0F-49FE-87D0-C218EDF59075@iki.fi> <282688936.20061215124705@djpowell.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040501040401010802010707" X-Spam-Status: No, hits=-0.847 tagged_above=-999 required=5 tests=ALL_TRUSTED, AWL, HTML_40_50, HTML_IMAGE_ONLY_20, HTML_MESSAGE X-Spam-Level: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.0 (+) X-Scan-Signature: ed68cc91cc637fea89623888898579ba This is a multi-part message in MIME format. --------------040501040401010802010707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id kBG0WLYw055400 Asbj=F8rn Ulsberg wrote: > > On Fri, 15 Dec 2006 13:47:05 +0100, David Powell=20 > wrote: > >> An example would be an HTML page with rel=3D"alternative" links >> pointing to a feed and an Atom Entry document. > > My thought on this is that that's actually broken. If not according to=20 > RFC 4287 or anything else, it's most likely wrong semantics involved.=20 > Ether the current HTML document is an alternate representation of the=20 > Atom Entry, or it is an alternate representation of the Feed. Or both. Millions of blog entry pages have both an entry and a set of=20 comments on that entry. Yes, it's stretching the concept of 'alternate'=20 a long, long way. > > In any case, the relation type 'feed' would be better suited for the=20 > feed reference and 'alternate' would suit the Entry reference if the=20 > Entry indeed was an alternate representation of the HTML document. Agreed, in an ideal world. --=20 Abstractioneer John Panzer System Architect http://abstractioneer.org --------------040501040401010802010707 Content-Type: multipart/related; boundary="------------070503080000090207040107" --------------070503080000090207040107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Asbjørn Ulsberg wrote:

On Fri, 15 Dec 2006 13:47:05 +0100, David Powell <djpowell@djpowell.net> wrote:

An example would be an HTML page with rel="alternative" links
pointing to a feed and an Atom Entry document.

My thought on this is that that's actually broken. If not according to RFC 4287 or anything else, it's most likely wrong semantics involved. Ether the current HTML document is an alternate representation of the Atom Entry, or it is an alternate representation of the Feed.
Or both.  Millions of blog entry pages have both an entry and a set of comments on that entry.  Yes, it's stretching the concept of 'alternate' a long, long way.

In any case, the relation type 'feed' would be better suited for the feed reference and 'alternate' would suit the Entry reference if the Entry indeed was an alternate representation of the HTML document.
Agreed, in an ideal world.

--
AbstractioneerJohn Panzer
System Architect
http://abstractioneer.org
--------------070503080000090207040107 Content-Type: image/gif; name="SzHO.gif" Content-ID: Content-Disposition: inline; filename="SzHO.gif" Content-Transfer-Encoding: base64 R0lGODlhLAFDAPcAAP///5mZmTMzM2ZmZuathN57MeZ7MeaEMe+MMe+MOuaMOuZ7OuZzMe+E MfeUOvecOvecQuaMSve9nO+lY/+cOu+cY//37/fFnO+USvfWtf/v5v+1cwAzmfeta//v3v/F hPela//mzvfFjP/etfe1c+97Mf+tWv/Wte+MQvelUve9hPetWvelSu+UQvetc+ZrMd5zMf/e vfe1hOaMUt5rMfe1a/e9jPfWve+tjN5jKf+tUvfOpf/m1u+1lO+UY+Z7SuaMY95zQt5aKd5z OqWlpQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH/C05FVFNDQVBFMi4wAwEAAAAh+QQA9AEAACwA AAAALAFDAAAI/gABAAhAsKDBgwgTEhTIsKHDhxAjSpxIsaLFixgzatzIsaPHjxsVihxZEKTJ kyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtCnEgyEDCIT6dOFU qwOxlnTKtWtOq1gtbg37UGrWswvTSiXrta1bl2DNbs1qtmFctg7Vol3LF+/bv4A5xt17tmre umXl8iWsN7DjxxgHQ/VLlnJdvZgXQ97MOfHVwp8ND/wctvTizKA7q4ZMla5ixK6vKrZrUDbD uXNX694NEjbv38CDCx9OvLjx48iTK1/OvPlEAQKKQv843WF158mra48O4LpG6NwZ/oK/7v3h ePHhOZbvnh49+Izj21N/z54+dpDbBeZX75089/XoiaeffPDJt15/F/mXkoLs3YfffxAOaN9+ 1kXHYIMYQnTgee6Ft59/9gWoYYgiYhhfQxzW15+HLDo4X4MMfkjgdBdSaF6KMg6oo4kRZlgi ij0CKWKOPO6Y4YUubhTfhEGmWOGRLfp4I31EVtnjhhLuiKWWV55YpJFIJlkghFGCOOOSYAb5 XJdctvnllm8aWCabT0JZIoBiWmTjngTa6See3Q1Jp5VuCukmnITqV2iMfeZZEZ9GSnkni0w6 KeGcHQJJJaUAonlpRF6qmB6OXW5HoqMwAZqnqqguxWqS/q+2KuustNZq66245qrrrrwNMMBK vvIqLEi/muRrsQAEK5GyGSnL7LAuIvvRsQw9+5C1FmELrYPU/loss91KK1CwzlI7LrnHdpss uOim+2257CJrLrnbQvbuuPgmm6+46J677r/VvittvwH72+/B3ib8r7n1OvZttftG3JC7Bidc rr/nEowxwgtb3K7GDQf2sMQjDyyvwuxufC/IF3PMsskhPzYyxvrWDHPF8E6cbsA5Z9wzwTuv C3LMRBdt9NFIJ6300kw37fTTUEctda0EFGDA1QYcoPUBCCSgAAFTO03AAgxc3UADCCDgwNoP PAAB2GEvXQADEUggwQRpr+1A/tsUPHBA3EtfXQFDFlwAwd4P9O3A34AnfTUGF2SggUAWbJD4 Aw4gwPhFHHDgUeeNI2fA2Xl34IFAH2COQAMGONS55xCBrhHosode3OggWBCCCBA8MIJAJKxe QusMyQ6768dvVLvtw3HdAeEmUHACABagMDzxAi1Pu+evH/969tsD8H33xS8v/vfgwx6++cwP xbUDKagwuQUrODC5BAYwwADy6nPv//kABF/5/re+/5UPgAVEYPLa5z69PYAFv9NAC1xAPQa8 AAaxI6AGzxc+ASpQgegTYAITyMCiHGBtMQjBByAwORmUwAIAmAENMFg8EW6wdh0M4AgXaMMP 6pCHfiUEitpqIJAQOMAGALiBAW4AABzkgIYDHKD/jIfDDm6vitozYAipGMSiJOABOoDhDhAA AgDwgAE9AEAPckCDLjZMAYlLQQeEVwEfvOAHQAiCEKDoxmERoHeZa8DwLEiDHORACEOAWx+h RYCtYY0BMIjkDBW5yEpa8pKYfEtAAAAh+QQAGQAAACwCAAYAswAYAAAI/gABCBxIsKDBgwgT KlzIsKHDhxAjSkRIpGJFiRcBWMxo0OJAjwJBauQ4saTJkygVZiTJECTLgkRCxrxIc6bNlDhz 6sQYc6TMniOBfuy5cWFNn0eL7lzKlOnKm0cPsnw5VCZSqDebat1a8mnQqB2F+pQKNCnWsVzT qlVJNKtVsiGtkpx71uzau3iHilQq8mfbtgQ3/tVLOK/hwzrFIl7MuLHjx5AjS55MubLly5gz a35LmerDl543UwQ8NrTRqUrRkuVouqViqoIhxs7JN/Vbr6pl062aO3BZzhNBvxaqeDRvnKxJ 3yY9u3RxsMmBwxzeNzXu5H2l631e9i9d7Ls5ju+Gzly5b7TRe2/vvry9c/fnw2pPf728ePbA Be9Vbvt8+vcJzVafewP29pR90/FWX233HffdTwp2B5t+DaonH4AFZjhchPPhV2B8//0HH4Da VUhfcXERiKCGHXJooIcIagTfiReGF96F6FnX3HYufuWbSxJOqKNnze2o43IHtvYZiqI5pqST TDbJ2JMpBQQAIfkEABkAAAAsAgAGALMAGAAACGsAAQgcSLCgwYMIEypcyLChw4cQI0qcSLGi xYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pcybKly5cwY8qcSbOmzZs4c+rcybOnz59AgwodSrSo 0aNIkypdyrSp06dQo0qdSrWq1atYs2rdylViQAAh+QQAGQAAACwCAAYArQAWAAAI/gABCBxI sKDBgwgTKlzIsKHDhxAjShRIpGJFiRcpZjxocWBHjUQ8bpxIsqTJkwQzjmT4MSSAlRQ1vgx5 sSZNlyhz6typUKXLjzNxiiwIM+XNmUhtFuXJtCnGn0dtIhy5VGbSqFidat360GdQqRxxVkUq U6pZoVzTqrUK1qpBr0Pjls3adq3drRY35gVJtGPeoyJb6h2M9q7hwyQLI17MuLHjx5AjS55M ubLly5gza0YMdHPTsXzl6uz8N3Bh0CxXlnb7trNa1KQVm4zttijqhbTZyhb9evdckD4JK50K mOzg1oKPw2x7nGxC4XG9KqUKFPrQ5sah6g7rHK5zo9Ghcbq+Ktc78e3ZgQNerv37dbHw0Zt/ b1qo7fjpz2Of31p+e+q17ZUddas1Bxd/f/HnXoDoISeggb7ld2B7/jUoYHcUTthgeRSC11+F 3FnYYYga5gfifPvBJx5+CLJ42ngE4vchhtWtBpxRMXboXYErDhQQACH5BAD0AQAALAIABgCt ABYAAAj+AAEIHEiwoMGDCBMqXMiwocOHECNKFBigYkWJFylmPGhxYEeNATxunEiypMmTBDOO ZPgxJICVFDW+DHmxJk2XKHPq3KlQpcuPM3GKLAgz5c2ZSG0W5cm0KcafR20iHLlUZtKoWJ1q 3frQZ1CpHHFWRSpTqlmhXNOqtQrWqkGvQ+OWzdp2rd2tFjfmBUm0Y96jIlvqHYz2ruHDJAsj Xsy4sePHkCNLnky5suXLmDNrRiyg8+atnhd2FkAw9M7RpUeTFqjaoGmSqFPHBvC6YOu7tQ/O pr369OvQpnPzPrk7+GrhqQ0jH+gZ+O3bvFHvTm6cde/cqo/Pbt6bOenq1sOYKzQO3vnw7LKv q//9Xb138eaHu27/Xr795PC1Tz/vPr9o7f7Jh158+BFIXX8CApigbvRZV1x39S14n20N2mcg gwHGx5540Wn4IHoWKujhfCAKZ2J/F3pXIooQzpehiN2NKGGHERIoY4rltTghhzK6GOCMCN0I Y4FDTgheiPqxyGGNCqbno4MIUsjkdiBC6aSKBtr4XJIDBQQAIfkEABkAAAAsAgAGAK0AFgAA CP4AAQgcSLCgwYMIEypcyLChw4cQI0oUSKRiRYkXKWY8aHFgR41EPG6cSLKkyZMEM45k+DEk gJUUNb4MebEmTZcoc+rcqVCly48zcYosCDPlzZlIbRblybQpxp9HbSIcuVRm0qhYnWrd+tBn UKkccVZFKlOqWaFc06q1CtaqQa9D45bN2nat3a0WN+YFSbRj3qMiW+odjPau4cMkCyNezLix 48eQI0ueTLmy5cuYM2tGDHRz07F85ers/DdwYdAsV5Z2+7azWtSkFZuM7bYo6oW02coW/Xr3 XJA+CSudCpjs4NaCj8Nse5xsQuFxvSqlChT60ObGoeoO6xyuc6PRoXG6virXO/Ht2YEDXq79 +3Wx8NGbf29aqO346c9jn99afnvqte2VHXWrNQcXf3/x516A6CEnoIG+5Xdge/41KGB3FE7Y YHkUgtdfhdxZ2GGIGuYH4nz7wScefgiyeNp4BOL3IYbVrQacUTF26F2BKw4UEAAh+QQAGQAA ACwCAAYArQAWAAAIZQABCBxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJ sqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1K tarVoAEBACH5BAAZAAAALAIABgBTABYAAAj1AAEIHEiwoMGDCBMqXMiwIJGHDxsOhBjxIMSJ FQFcFLhRIsOKGT8SUThS48iIKE+q9OgRZMmOHU2GtLgypUmZJVmSfFlzJcKZBF3etGlTZ0Kh FH3S/JmTaM+bRplyVAo16NSqWJ0OpRo1KEWMLnNO5el1I8yMMbuqJbm2rdu3cOPKnUu3rt27 ePPqjQsUrFeaYclCRRvzK1ixMjEeDdk3a1PBQgdDFoy1suLAiB0rlmwwsmfKhxEXtXx189XR pj+XTrqZsdLGrsuy/tt68mrbYw3DFuuaJ2/RuFVzLj2882+HoIEKX06ZsF/ZuWn3Pjsdeu6c AQEAIfkEAPQBAAAsAgAGAFMAFgAACP4AAQgcSLCgwYMIEypcyLBggIcPGw6EGPEgxIkVAVwU uFEiw4oZPwZQOFLjyIgoT6r06BFkyY4dTYa0uDKlSZklWZJ8WXMlwpkEXd60aVNnQqEUfdL8 mZNoz5tGmXJUCjXo1KpYnQ6lGjUoRYwuc07l6XUjzIwxu6olubat27dw48qdS7eu3bt48+qN K0BAwr5+B/Y9CDhwYYGDASROrBgwwcOCHT9mzNigZMSBLWduHBmzZ86gFxse3XkywsGiL5f+ HJp0QdGfYYOerJoz5c2mV9v2W5m17N+QW5u+fXpz5cLBWQtfDtw3cteac2MebRx3c+auicfG rbu3bOXbwxBjd766NuTk3xsHR696ffCAACH5BAAZAAAALAIABgBTABYAAAj1AAEIHEiwoMGD CBMqXMiwIJGHDxsOhBjxIMSJFQFcFLhRIsOKGT8SUThS48iIKE+q9OgRZMmOHU2GtLgypUmZ JVmSfFlzJcKZBF3etGlTZ0KhFH3S/JmTaM+bRplyVAo16NSqWJ0OpRo1KEWMLnNO5el1I8yM MbuqJbm2rdu3cOPKnUu3rt27ePPqjQsUrFeaYclCRRvzK1ixMjEeDdk3a1PBQgdDFoy1suLA iB0rlmwwsmfKhxEXtXx189XRpj+XTrqZsdLGrsuy/tt68mrbYw3DFuuaJ2/RuFVzLj2882+H oIEKX06ZsF/ZuWn3Pjsdeu6cAQEAIfkEABkAAAAsAgAGAFMAFgAACEYAAQgcSLCgwYMIEypc yLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pcybKly5cwY8qcSbOmzZs4c+rc iTMgACH5BAAZAAAALAIABgCiABgAAAj+AAEIHEiwoMGDCBMqXMiwocOHECMmJEKQIkQiGAdi tHhwo8aMAj2GBCmxpMmTJklybGgxo8uVGkcCeDmTIk2UOHPq7AiyZU+bMGXeREizKFCSO5Mq vVhzZlOjBn82JerzKVCrS7NqnTjyKtSKHIcWVOm17NStaLeGNVsTJtKvMj9ihZu2btKVPte6 3Zg3btefej8GtUu4cMTBhhMrXsy4sePHkCNLnky5suXLkZHe1YxZLeK/EjlzvvjZoUjBZCee Jjzab2meWVs/XJ36LNXEskfzBQu4Nl+8u3n3liv6quuqCsn6rvqS9mnlyG/bniqVOvLicq2v Fro2u+y41cNs764OFvxeniI1izfPfmx366rPLl+4Hr5t8r/N1y5v3/v1/35lZ19rv+EXnXT1 kTcggKDJ1556DCYY1HzTCWhggLAt2N6DDFro3HPpRRhdfu4JJ2CJx4EYXIMstqWggSG2+Nh3 ndWY1oo2VhYQACH5BAD0AQAALAIABgCiABgAAAj+AAEIHEiwoMGDCBMqXMiwocOHECMmDECQ IsQAGAditHhwo8aMAj2GBCmxpMmTJklybGgxo8uVGkcCeDmTIk2UOHPq7AiyZU+bMGXeREiz KFCSO5MqvVhzZlOjBn82JerzKVCrS7NqnTjyKtSKHIcWVOm17NStaLeGNVsTJtKvMj9ihZu2 btKVPte63Zg3btefej8GtUu4cMTBhhMrXsy4sePHkCNLnky5suXLkQUI0Kp5M2a7mhV29gwx dEHTJlGnVg1gNGnWBEcnhj0QNWmHtHHmftg59mvPuwUGz7qbtuzavVsfVy58ufLkyJMvDw2b +m/kzRfahm66+2br0J+LX2/uXTTw28zTl1d/3uD27OLRM38Pf/j6++d7r/ddH73x46zh19+A p423n3vfjceedu0t6CCB8fVHH38PEihghfA5mJtr+x140IUXWtjgdh2KWKCJGspHn4fYQcji iSlCGCOGJN7mWnQj5pjhjTCSp2CPNf7m3JDh8ahahwDmJ19jw33mJFrOPUlZQAAh+QQAGQAA ACwCAAYAogAYAAAI/gABCBxIsKDBgwgTKlzIsKHDhxAjJiRCkCJEIhgHYrR4cKPGjAI9hgQp saTJkyZJcmxoMaPLlRpHAng5kyJNlDhz6uwIsmVPmzBl3kRIsyhQkjuTKr1Yc2ZTowZ/NiXq 8ylQq0uzap048irUihyHFlTptezUrWi3hjVbEybSrzI/YoWbtm7SlT7Xut2YN27Xn3o/BrVL uHDEwYYTK17MuLHjx5AjS55MubLly5GR3tWMWS3ivxI5c7742aFIwWQnniY82m9pnllbP1yd +izVxLJH8wULuDZfvLt595Yr+qrrqgrJ+q76kvZp5chv254qlTry4nKtrxa6NrvsuNXDbO+u Dhb8Xp4iNYs3z35sd+uqzy5fuB6+bfK/zdcub9/79f9+ZWdfa7/hF5109ZE3IICgydeeegwm GNR80wloYICwLdjegwxa6Nxz6UUYXX7uCSdgiceBGFyDLLaloIEhtvjYd53VmNaKNlYWEAAh +QQAGQAAACwCAAYAogAYAAAIZgABCBxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPH jyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKnT p1CjSp1KtarVqzwDAgAh+QQAGQAAACwCAAYAlwAWAAAI/gABCBxIsKDBgwgTKlzIsKHDhxAf EiE4MSKRigAuYjSocWBHgR8zXoxIsqRJiRg3Nvw4ciRHkBNbxpwp8qTNmzhFVtzpUiZHnjUT +hw602XOo0iF1qRJ9KdHowd7Mp0aNKlVqzyp+iwotSrXlFqpXh17FOzSrFGBboVJMexZsnBv bkQLU6VOulA1SgXLN67fvyTtAh5MuLDhw4gTK17MuLHjx5AjD4b6t6tkh3rLms1JGWhQyiX1 Zq4r+qlovqXban6qebNqrybtpnwJknZG22xJm87LMnNq3aQF+7Zs+S7rtR5ty07OlTnFr7mJ y/b8eXr05R2lX7+efXnz2t9vW4f3zrr69uC5zaNX/1y89uqjQeMGL759fefkz79/r35//v6e gSZfePgpZyCBAOoX4Gb+peecgue5N9d/9ZFnIW2jAcfeb92ll1pxDyZYVYa8/XTabiSehtpo AQEAIfkEAPQBAAAsAgAGAJcAFgAACP4AAQgcSLCgwYMIEypcyLChw4cQHwYgODFigIoALmI0 qHFgR4EfM16MSLKkSYkYNzb8OHIkR5ATW8acKfKkzZs4RVbc6VImR541E/ocOtNlzqNIhdak SfSnR6MHezKdGjSpVas8qfosKLUq15RaqV4dexTs0qxRgW6FSTHsWbJwb25EC1OlTrpQNUoF yzeu378k7QIeTLiw4cOIEytezLix48eQIw8WIKAwZYGXJTuknBln5843QQOoPJp0ZtElOasm XXo1a9efYRdEbTL2Uc4DUZ9mfZI35twGXwcHPnv2a9yYVRNU3vry6uXIm/tO7nx38uvUj5fe Xrz76OG/vX5P922de3no2M2PN81+OO7y8NtL574c/Hfx9scbxx4/N3Pb9D2nHnjy9SedfArp F159CxJ3H4P+8VfghOkZaCCEEmZIX4QLKfiggx56qKGFFI5Yom77DajifaChiN+LECrIXHYc xhbdewgKeJ6DJlZ4I2+6yZbdjLAd55pAAQEAIfkEABkAAAAsAgAGAJcAFgAACP4AAQgcSLCg wYMIEypcyLChw4cQHxIhODEikYoALmI0qHFgR4EfM16MSLKkSYkYNzb8OHIkR5ATW8acKfKk zZs4RVbc6VImR541E/ocOtNlzqNIhdakSfSnR6MHezKdGjSpVas8qfosKLUq15RaqV4dexTs 0qxRgW6FSTHsWbJwb25EC1OlTrpQNUoFyzeu378k7QIeTLiw4cOIEytezLix48eQIw+G+rer ZId6y5rNSRloUMol9WauK/qpaL6l22p+qnmzaq8m7aZ8CZJ2RttsSZvOyzJzat2kBfu2bPku 67UebctOzpU5xa+5icv2/Hl69OUdpV+/nn1589rfb1uH9866+vbguc2jV/9cvPbqo0HjBi++ fX3n5M+/f69+f/7+noEmX3j4KWcggQDqF+Bm/qXnnILnuTfXf/WRZyFtowHH3m/dpZdacQ8m WFWGvP102m4knobaaAEBACH5BAD6AAAALAIABgCXABYAAAhfAAEIHEiwoMGDCBMqXMiwocOH ECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2bOHPq3Mmzp8+f QIMKHUq0qNGjSJMqXcq0qdOnUKMCCAgAOw== --------------070503080000090207040107-- --------------040501040401010802010707-- From owner-atom-syntax@mail.imc.org Fri Dec 15 20:17:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvOAl-0003zY-Ln for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 20:17:07 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvOAi-0007bT-NA for atompub-archive@lists.ietf.org; Fri, 15 Dec 2006 20:17:07 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBG10Po4058060; Fri, 15 Dec 2006 18:00:25 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBG10PQM058058; Fri, 15 Dec 2006 18:00:25 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBG10O99058047; Fri, 15 Dec 2006 18:00:24 -0700 (MST) (envelope-from ldusseault@commerce.net) Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by gateout02.mbox.net (Postfix) with ESMTP id 4BAB32101; Sat, 16 Dec 2006 01:00:23 +0000 (GMT) Received: from GW2.EXCHPROD.USA.NET [165.212.116.254] by gateout02.mbox.net via smtad (C8.MAIN.3.32M); Sat, 16 Dec 2006 01:00:23 GMT X-USANET-Source: 165.212.116.254 IN ldusseault@commerce.net GW2.EXCHPROD.USA.NET X-USANET-MsgId: XID279kLPBaX2099Xo2 Received: from [10.1.1.214] ([157.22.41.10]) by GW2.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Dec 2006 18:00:22 -0700 In-Reply-To: <4582C9BC.8010704@sun.com> References: <8BD53B7C-5B43-4F2D-8DC5-0281CCB84B84@commerce.net> <3f1451f50612070836h45091080k851cece2198c464a@mail.gmail.com> <4582C9BC.8010704@sun.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/alternative; boundary=Apple-Mail-6--1054944523 Message-Id: <057641F2-0976-45BD-A8B3-497475F50951@commerce.net> Cc: Joe Gregorio , Atom , atom-protocol Protocol From: Lisa Dusseault Subject: Re: AD Evaluation of draft-ietf-atompub-protocol-11 Date: Fri, 15 Dec 2006 17:00:16 -0800 To: Tim Bray X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 16 Dec 2006 01:00:22.0395 (UTC) FILETIME=[90319CB0:01C720AD] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.6 (+) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 --Apple-Mail-6--1054944523 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I guess I'm assuming that one would want clients to be able to extend Atom unilaterally. The choices that I highlighted as problematic make it harder for clients to reliably add extensions to Atom documents. (It remains easy for servers to add extensions to Atom feeds and entries using prescribed mechanisms like adding new elements in custom namespaces. ) Since clients post Atom entries and other clients retrieve them, it seemed reasonable to want to extend Atom client-to-client. If I used "AtomFu" client that was able to annotate my entries automatically with what music I was listening to (track name, album and artist in XML elements) while I wrote a blog posting, I thought AtomFu should just store that as XML markup in the entry. Other users running "AtomFu" will see that information and nobody else needs to upgrade -- not servers, not other clients. Eventually if other clients see this as a useful feature they'll make the additional markup visible. Servers probably would never need to upgrade to use or touch that markup. A model where servers aren't required to keep such information won't, in practice, allow that kind of extension. If clients can't rely on their markup getting stored, then clients can't extend Atom unilaterally using XML markup. But implementors of client software are innovative, too. You can't stop them from putting cool information in entries -- they'll just put it in a place where the server decides it's just natural-language or some other component that it does allow the client to create unmodified. So maybe instead of seeing track name, album and artist in XML elements, we'll see them in square brackets or some other format in the blog entry "text". This will hurt interoperability to a certain extent, as there is no standard way of extending the machine-parsable information within the *text* of an entry. We won't see this today -- with new protocols, servers typically lead adoption, implementing the protocol before many clients emerge. But in the long run, server deployments get old and yet as long as they're still running, admins avoid changing software or even upgrading. Yet people who've gotten used to the new functionality start expecting more from it and seek out clients that do cool new things and still interoperate with their servers. Bare bones clients are the first generation of a new technology, and innovative (whatever the barriers) clients come much later. It may be that I'm just having trouble accepting that the WG fully understands this and has still come to consensus that this is a great way to proceed. Is that the case? thx, Lisa On Dec 15, 2006, at 8:13 AM, Tim Bray wrote: > > The current WG consensus, way better than "rough", is that this > level of interoperation is useful. That consensus seems to be > supported by implementation experience. > > Lisa, perhaps the problem is that I'm reacting to a fairly general > statement of concern. Do you have some specific suggestions as to > how server behavior could be limited or formally described? --Apple-Mail-6--1054944523 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

I guess I'm assuming that = one would want clients to be able to extend Atom unilaterally.=A0 The = choices that I highlighted as problematic make it harder for clients to = reliably add extensions to Atom documents.=A0 (It remains easy for = servers to add extensions to Atom feeds and entries using prescribed = mechanisms like adding new elements in custom namespaces.=A0 = )

Since = clients post Atom entries and other clients retrieve them, it seemed = reasonable to want to extend Atom client-to-client.=A0 If I used = "AtomFu" client that was able to annotate my entries automatically with = what music I was listening to (track name, album and artist in XML = elements) while I wrote a blog posting, I thought AtomFu should just = store that as XML markup in the entry.=A0 Other users running "AtomFu" = will see that information and nobody else needs to upgrade -- not = servers, not other clients.=A0 Eventually if other clients see this as a = useful feature they'll make the additional markup visible.=A0 Servers = probably would never need to upgrade to use or touch that = markup.

A = model where servers aren't required to keep such information won't, in = practice, allow that kind of extension. If clients can't rely on their = markup getting stored, then clients can't extend Atom unilaterally using = XML markup.

But= implementors of client software are innovative, too.=A0 You can't stop = them from putting cool information in entries -- they'll just put it in = a place where the server decides it's just natural-language or some = other component that it does allow the client to create unmodified.=A0 = So maybe instead of seeing track name, album and artist in XML elements, = we'll see them in square brackets or some other format in the blog entry = "text".=A0=A0This will hurt interoperability to a certain extent, as = there is no standard way of extending the machine-parsable information = within the *text* of an entry.

We won't see this today -- = with new protocols, servers typically lead adoption, implementing the = protocol before many clients emerge.=A0 But in the long run, server = deployments get old and yet as long as they're still running, admins = avoid changing software or even upgrading.=A0 Yet people who've gotten = used to the new functionality start expecting more from it and seek out = clients that do cool new things and still interoperate with their = servers.=A0 Bare bones clients are the first generation of a new = technology, and innovative (whatever the barriers) clients come much = later.

It may = be that I'm just having trouble accepting that the WG fully understands = this and has still come to consensus that this is a great way to = proceed.=A0 Is that the case?

thx,
Lisa

=
On Dec 15, 2006, at 8:13 AM, Tim Bray wrote:

The current WG consensus, way better than "rough", = is that this level of interoperation is useful.=A0 That consensus seems = to be supported by implementation = experience.


Lisa, perhaps the problem is that I'm reacting to a fairly = general statement of concern.=A0 = Do you have some specific suggestions as to how server behavior = could be limited or formally described?

=

= --Apple-Mail-6--1054944523-- From owner-atom-syntax@mail.imc.org Sat Dec 16 09:44:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gvalr-0002Jj-St for atompub-archive@lists.ietf.org; Sat, 16 Dec 2006 09:44:15 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gvaln-0002pp-EB for atompub-archive@lists.ietf.org; Sat, 16 Dec 2006 09:44:15 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBGESLKX027660; Sat, 16 Dec 2006 07:28:21 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBGESLeF027658; Sat, 16 Dec 2006 07:28:21 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from csmtp1.b-one.net (csmtp.b-one.net [195.47.247.21]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBGESJUW027650 for ; Sat, 16 Dec 2006 07:28:20 -0700 (MST) (envelope-from asbjorn@tigerstaden.no) Received: from quark (72.84-48-117.nextgentel.com [84.48.117.72]) by csmtp1.b-one.net (Postfix) with ESMTP id 509B419114EF2; Sat, 16 Dec 2006 15:28:17 +0100 (CET) Date: Sat, 16 Dec 2006 15:30:02 +0100 To: "John Panzer" Subject: Re: Atom Entry docs From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Cc: "David Powell" , "Henri Sivonen" , atom-syntax Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <457F30B7.1020100@sun.com> <457FB015.8000706@defuze.org> <38ADFD5F-2C0F-49FE-87D0-C218EDF59075@iki.fi> <282688936.20061215124705@djpowell.net> <45833E61.6090907@aol.net> Message-ID: In-Reply-To: <45833E61.6090907@aol.net> User-Agent: Opera Mail/9.10 (Win32) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id kBGESLKX027660 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 On Sat, 16 Dec 2006 01:31:29 +0100, John Panzer wrote: > Or both. Millions of blog entry pages have both an entry and a set of > comments on that entry. Yes, it's stretching the concept of 'alternate= ' > a long, long way. Yes, it's a long stretch. RFC 4685 specifies how to build that =20 relationship; rel=3D"alternate" is not the appropriate solution. >> In any case, the relation type 'feed' would be better suited for the >> feed reference and 'alternate' would suit the Entry reference if the >> Entry indeed was an alternate representation of the HTML document. > > Agreed, in an ideal world. Considering that the 'feed' relationship is being baked in WHATWG, I don'= t =20 think that ideal world is such a utopia. --=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 Sat Dec 16 10:35:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvbZa-0003qg-9C for atompub-archive@lists.ietf.org; Sat, 16 Dec 2006 10:35:38 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvbZX-00033Z-RI for atompub-archive@lists.ietf.org; Sat, 16 Dec 2006 10:35:38 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBGFJU2K032550; Sat, 16 Dec 2006 08:19:30 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBGFJTp3032549; Sat, 16 Dec 2006 08:19:29 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBGFJP9W032527; Sat, 16 Dec 2006 08:19:25 -0700 (MST) (envelope-from Tim.Bray@Sun.COM) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kBGFJNs2011012; Sat, 16 Dec 2006 08:19:25 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JAD00E01H71JG00@mail-amer.sun.com> (original mail from Tim.Bray@Sun.COM) ; Sat, 16 Dec 2006 08:19:23 -0700 (MST) Received: from [192.168.1.45] (fatwire-204-250.uniserve.ca [216.113.204.251]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JAD00393H8AJ710@mail-amer.sun.com>; Sat, 16 Dec 2006 08:19:23 -0700 (MST) Date: Sat, 16 Dec 2006 07:20:01 -0800 From: Tim Bray Subject: Re: AD Evaluation of draft-ietf-atompub-protocol-11 In-reply-to: <057641F2-0976-45BD-A8B3-497475F50951@commerce.net> To: Lisa Dusseault Cc: Joe Gregorio , Atom , atom-protocol Protocol Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.752.2) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: <8BD53B7C-5B43-4F2D-8DC5-0281CCB84B84@commerce.net> <3f1451f50612070836h45091080k851cece2198c464a@mail.gmail.com> <4582C9BC.8010704@sun.com> <057641F2-0976-45BD-A8B3-497475F50951@commerce.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.1 (+) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 On Dec 15, 2006, at 5:00 PM, Lisa Dusseault wrote: > I guess I'm assuming that one would want clients to be able to > extend Atom unilaterally. That doesn't seem to have been a design goal for the WG. To the extent that the issue never came up in the discussion. > The choices that I highlighted as problematic make it harder for > clients to reliably add extensions to Atom documents. You're being tactful with "harder". I'd say "impossible". Here's my take on the WG thinking: The set of software implementations which could reasonably act as APP servers is incredibly large and heterogeneous. A lot of them already exist. The requirement that they reliably round-trip arbitrary XML from clients is actually pretty onerous, since many (all?) of them will have internal data-storage models which will look very little like the Atom XML representation. We think that APP as specified allows very good interoperability for basic Web-centric publish/edit operations with low overhead, and low demands for complexity in the client and sever implementations. Adding the requirement for client-side extensibility would reduce the number of server implementations that would be able to advertise conformance with APP, even though they are perfectly capable of the highly-useful function possible under APP as of the current draft. > (It remains easy for servers to add extensions to Atom feeds and > entries using prescribed mechanisms like adding new elements in > custom namespaces. ) Right. Phrased another way, the APP is highly extensible; but the current version requires co-operation from both client and server. This seems reasonable to me. > It may be that I'm just having trouble accepting that the WG fully > understands this and has still come to consensus that this is a > great way to proceed. Is that the case? Sort of. Frankly, there seems to have been very little hunger for unilateral client-side extension, and a very strong aversion from the server-side people to accepting the round-trip-any-XML requirement. -Tim From owner-atom-syntax@mail.imc.org Sat Dec 16 12:56:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gvdlm-00058f-ET for atompub-archive@lists.ietf.org; Sat, 16 Dec 2006 12:56:22 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gvdlj-0001vE-TP for atompub-archive@lists.ietf.org; Sat, 16 Dec 2006 12:56:22 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBGHcPdl045899; Sat, 16 Dec 2006 10:38:25 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBGHcPfB045898; Sat, 16 Dec 2006 10:38:25 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.232]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBGHcOmZ045884 for ; Sat, 16 Dec 2006 10:38:24 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i20so547396wra for ; Sat, 16 Dec 2006 09:38:23 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=iTZ08JCaMOvKtoksdcuxWjIUCd6wzJS+mSGhp56AASBemfAj3SSFQZHcGfyDGxOhEEtn+na8HIvCsCj3mKp3F0EMKPs5u82c/+y9u+054EfcLe9zTDWTYU91MwHIqqsUi6/m+t1tjQO6gD47jhjYK3kHqHlBe80w5kgG/1Aaj48= Received: by 10.90.118.12 with SMTP id q12mr2228063agc.1166290703256; Sat, 16 Dec 2006 09:38:23 -0800 (PST) Received: from ?192.168.1.109? ( [67.181.218.96]) by mx.google.com with ESMTP id 12sm11145817wrl.2006.12.16.09.38.20; Sat, 16 Dec 2006 09:38:22 -0800 (PST) Message-ID: <45842F04.5040805@gmail.com> Date: Sat, 16 Dec 2006 09:38:12 -0800 From: James M Snell User-Agent: Thunderbird 1.5.0.8 (X11/20061115) MIME-Version: 1.0 To: Tim Bray CC: Lisa Dusseault , Joe Gregorio , Atom , atom-protocol Protocol Subject: Re: AD Evaluation of draft-ietf-atompub-protocol-11 References: <8BD53B7C-5B43-4F2D-8DC5-0281CCB84B84@commerce.net> <3f1451f50612070836h45091080k851cece2198c464a@mail.gmail.com> <4582C9BC.8010704@sun.com> <057641F2-0976-45BD-A8B3-497475F50951@commerce.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.1 (+) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Tim Bray wrote: > [snip] > We think that APP as specified allows very good interoperability for > basic Web-centric publish/edit operations with low overhead, and low > demands for complexity in the client and sever implementations. Adding > the requirement for client-side extensibility would reduce the number of > server implementations that would be able to advertise conformance with > APP, even though they are perfectly capable of the highly-useful > function possible under APP as of the current draft. > +1 >> (It remains easy for servers to add extensions to Atom feeds and >> entries using prescribed mechanisms like adding new elements in custom >> namespaces. ) > > Right. Phrased another way, the APP is highly extensible; but the > current version requires co-operation from both client and server. This > seems reasonable to me. > +1 >> It may be that I'm just having trouble accepting that the WG fully >> understands this and has still come to consensus that this is a great >> way to proceed. Is that the case? > > Sort of. Frankly, there seems to have been very little hunger for > unilateral client-side extension, and a very strong aversion from the > server-side people to accepting the round-trip-any-XML requirement. > From this implementors point of view client-side extension simply is not a requirement. - James From owner-atom-syntax@mail.imc.org Sat Dec 16 15:41:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvgL9-0000Om-Ci for atompub-archive@lists.ietf.org; Sat, 16 Dec 2006 15:41:03 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvgL4-0002KG-Ue for atompub-archive@lists.ietf.org; Sat, 16 Dec 2006 15:41:03 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBGKPSAs062236; Sat, 16 Dec 2006 13:25:28 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBGKPS3k062235; Sat, 16 Dec 2006 13:25:28 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBGKPP9j062212 for ; Sat, 16 Dec 2006 13:25:28 -0700 (MST) (envelope-from joe.gregorio@gmail.com) Received: by ug-out-1314.google.com with SMTP id j3so1394387ugf for ; Sat, 16 Dec 2006 12:25:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=GpX5NbwmXSTi50dOpLKFjf1+2jsAeqqAa7eq0OhbKXQ4vajYT19M8eypbSYcJqCoyd0lKzF/nFdqtYUfSs7WaWMecPFg87kbDEwh7WRSMAPxsXGZq9LartduTeRWpA0eLycDGZ17rnebNm7umY/3VbI0TYALMfIkYNS+j3kVqX4= Received: by 10.78.47.15 with SMTP id u15mr1418565huu.1166300724086; Sat, 16 Dec 2006 12:25:24 -0800 (PST) Received: by 10.78.191.4 with HTTP; Sat, 16 Dec 2006 12:25:18 -0800 (PST) Message-ID: <3f1451f50612161225g22a1763nd0b400a36c8594ed@mail.gmail.com> Date: Sat, 16 Dec 2006 15:25:18 -0500 From: "Joe Gregorio" To: "Lisa Dusseault" Subject: Re: AD Evaluation of draft-ietf-atompub-protocol-11 Cc: "Tim Bray" , Atom , "atom-protocol Protocol" In-Reply-To: <057641F2-0976-45BD-A8B3-497475F50951@commerce.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8BD53B7C-5B43-4F2D-8DC5-0281CCB84B84@commerce.net> <3f1451f50612070836h45091080k851cece2198c464a@mail.gmail.com> <4582C9BC.8010704@sun.com> <057641F2-0976-45BD-A8B3-497475F50951@commerce.net> X-Google-Sender-Auth: 6ec56af840e4db0b Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.1 (+) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 On 12/15/06, Lisa Dusseault wrote: > > I guess I'm assuming that one would want clients to be able to extend Atom > unilaterally. The choices that I highlighted as problematic make it harder > for clients to reliably add extensions to Atom documents. (It remains easy > for servers to add extensions to Atom feeds and entries using prescribed > mechanisms like adding new elements in custom namespaces. ) > > Since clients post Atom entries and other clients retrieve them, it seemed > reasonable to want to extend Atom client-to-client. If I used "AtomFu" > client that was able to annotate my entries automatically with what music I > was listening to (track name, album and artist in XML elements) while I > wrote a blog posting, I thought AtomFu should just store that as XML markup > in the entry. Other users running "AtomFu" will see that information and > nobody else needs to upgrade -- not servers, not other clients. Eventually > if other clients see this as a useful feature they'll make the additional > markup visible. Servers probably would never need to upgrade to use or > touch that markup. > > A model where servers aren't required to keep such information won't, in > practice, allow that kind of extension. If clients can't rely on their > markup getting stored, then clients can't extend Atom unilaterally using XML > markup. I do not see the ability of clients to unilaterally extend the APP using XML as a requirement. > But implementors of client software are innovative, too. You can't stop > them from putting cool information in entries -- they'll just put it in a > place where the server decides it's just natural-language or some other > component that it does allow the client to create unmodified. So maybe > instead of seeing track name, album and artist in XML elements, we'll see > them in square brackets or some other format in the blog entry "text". You say that as if it's a bad thing. Personally I like microformats. And besides, just because *your* client stuffs a track name, album and artist into some XML does not automatically make it interoperable; every client can, and will, choose to encode that data differently. > This will hurt interoperability to a certain extent, as there is no standard way > of extending the machine-parsable information within the *text* of an entry. See microformats. > It may be that I'm just having trouble accepting that the WG fully > understands this and has still come to consensus that this is a great way to > proceed. Like I stated previously, this has been discussed ad infinitum on the list and the consensus supports it. -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Sat Dec 16 16:54:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvhUV-0002GP-IL for atompub-archive@lists.ietf.org; Sat, 16 Dec 2006 16:54:47 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvhUU-0005v2-3Y for atompub-archive@lists.ietf.org; Sat, 16 Dec 2006 16:54:47 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBGLfTqo069065; Sat, 16 Dec 2006 14:41:29 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBGLfTIh069064; Sat, 16 Dec 2006 14:41:29 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from fepv02.charter.net (rems01.cluster1.charter.net [209.225.8.201]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBGLfSY8069058 for ; Sat, 16 Dec 2006 14:41:29 -0700 (MST) (envelope-from antone@geckotribe.com) Received: from aa10.charter.net ([10.20.200.162]) by fepv02.charter.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20061216214127.SPZH2856.fepv02.charter.net@aa10.charter.net> for ; Sat, 16 Dec 2006 16:41:27 -0500 Received: from [192.168.2.3] (really [68.118.146.150]) by aa10.charter.net with ESMTP id <20061216214127.SLNL9092.aa10.charter.net@[192.168.2.3]> for ; Sat, 16 Dec 2006 16:41:27 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <3f1451f50612161225g22a1763nd0b400a36c8594ed@mail.gmail.com> References: <8BD53B7C-5B43-4F2D-8DC5-0281CCB84B84@commerce.net> <3f1451f50612070836h45091080k851cece2198c464a@mail.gmail.com> <4582C9BC.8010704@sun.com> <057641F2-0976-45BD-A8B3-497475F50951@commerce.net> <3f1451f50612161225g22a1763nd0b400a36c8594ed@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6183011A-7A00-45FD-A5B1-102D6010BAC1@geckotribe.com> Content-Transfer-Encoding: 7bit From: Antone Roundy Subject: Re: AD Evaluation of draft-ietf-atompub-protocol-11 Date: Sat, 16 Dec 2006 15:41:26 -0600 To: atom-syntax@imc.org X-Mailer: Apple Mail (2.752.2) X-Chzlrs: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.1 (+) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 I'm not subscribed to the APP mailing list, so hopefully this isn't all redundant: On 12/15/06, Lisa Dusseault wrote: > A model where servers aren't required to keep such information > won't, in > practice, allow that kind of extension. If clients can't rely on their > markup getting stored, then clients can't extend Atom unilaterally > using XML > markup. There are two different issues here, which I think has been mentioned, but which might bear being clearly stated: 1) Do servers have to keep all extension data? 2) Can a server accept an entry while discarding some or all extension data, or do they have to reject the entry and return an error code? I think the answer to the first question is clearly no--servers shouldn't be required to store all arbitrary data that is sent to them. So the questions are: 1) Which hurts more--data loss or rejected entries? 2) Is there any way to reduce that pain? The pain of data loss is obvious--the data is lost. The pain of rejected entries is having to fix and repost them or decide not to try again. In either case, it might be useful to be able to query the server somehow to find out what it will and won't preserve. If data is discarded, you can figure that out after the fact by loading the resulting entry and checking whether the data is all there, but one might prefer to know ahead of time if something is going to be lost in order to be able to decide whether to post it or not. If the entry is just going to be rejected, unless there's a way for the server to communicate exactly which data it had issues with, fixing the data to make it acceptable could be extremely difficult ("Hmm, I'll leave this data out and try again...nope, still rejected. I'll put that back in and leave this out...nope. I'll take both out...nope. I'll put both back in and take yet another piece of data out..."). So, how might a client query a server to see what it will preserve? A few possibilities: 1) Have some way to request some sort of description of what will and won't be preserved and what might be altered. I don't know how one would go about responding to such an inquiry except to basically send back a list of what will be preserved, including some way to say "I'll preserve unknown attributes here", "I'll preserve unknown child elements (and their children) here", "I'll store up to 32767 bytes here", etc. If there is any known extension markup that a server wants to explicitly state that it won't preserve, there may need to be a way to do that too. 2) Have a way to do a "test post", where one posts the data one is considering posting (or something structurally identical), but says "don't store this--just tell me what you WOULD store". The response could include what would be returned if one were to load the data after it being stored, or it could be some sort of list of anything that would be discarded or altered. 3) (I get the impression this could be done without requiring changes--is this the sort of process that has already been selected?) Post the data as a draft, reload it to see if it's all still there. If so, or if what has been preserved is acceptable, change it's status to "published" or whatever it's called. If not delete it and give up or take whatever other action is appropriate. My impression is that data loss would be less painful and more easily dealt with than rejection of entries that won't be completely preserved. ...but I haven't followed the discussion, so what do I know. From owner-atom-syntax@mail.imc.org Sat Dec 16 19:48:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvkCB-0000D1-7G for atompub-archive@lists.ietf.org; Sat, 16 Dec 2006 19:48:03 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvkC9-0003sv-OQ for atompub-archive@lists.ietf.org; Sat, 16 Dec 2006 19:48:03 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBH0VW2m085257; Sat, 16 Dec 2006 17:31:32 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBH0VW1g085256; Sat, 16 Dec 2006 17:31:32 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.224]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBH0VVXH085249 for ; Sat, 16 Dec 2006 17:31:32 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id i30so981069wxd for ; Sat, 16 Dec 2006 16:31:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=mjQCkVj4LP0VfjBN9eUG6VVkaKcheo1Oam7N78VLxE0UVqoFD1Eu1C5ronucsJBwGuIlOhEpz0sJoigCQQq+2UrFlkpMiD3ozO8YuIHdu2XV4odnD3t8+jMwEaudTp/K/gAYk1aAI1NkGgQVGxuDviW/KuVfppRPUEXNWmeLcZ0= Received: by 10.70.61.1 with SMTP id j1mr4278118wxa.1166315491086; Sat, 16 Dec 2006 16:31:31 -0800 (PST) Received: from ?192.168.1.109? ( [67.181.218.96]) by mx.google.com with ESMTP id 12sm12006410wrl.2006.12.16.16.31.29; Sat, 16 Dec 2006 16:31:30 -0800 (PST) Message-ID: <45848FDE.80700@gmail.com> Date: Sat, 16 Dec 2006 16:31:26 -0800 From: James M Snell User-Agent: Thunderbird 1.5.0.8 (X11/20061115) MIME-Version: 1.0 To: Antone Roundy CC: atom-syntax@imc.org Subject: Re: AD Evaluation of draft-ietf-atompub-protocol-11 References: <8BD53B7C-5B43-4F2D-8DC5-0281CCB84B84@commerce.net> <3f1451f50612070836h45091080k851cece2198c464a@mail.gmail.com> <4582C9BC.8010704@sun.com> <057641F2-0976-45BD-A8B3-497475F50951@commerce.net> <3f1451f50612161225g22a1763nd0b400a36c8594ed@mail.gmail.com> <6183011A-7A00-45FD-A5B1-102D6010BAC1@geckotribe.com> In-Reply-To: <6183011A-7A00-45FD-A5B1-102D6010BAC1@geckotribe.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.1 (+) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 The moral of the story is simple: clients need to know what they're getting into. 1. Servers can accept or reject whatever they want. 2. it's really nice if servers let client's know up front what they intend to accept or reject 3. at this point there's no need for any kind of handshake protocol to determine what a server will accept or reject. What's most likely to happen (and most likely to actually be used and work effectively) is that server's will put up websites [1] that document exactly how their endpoints work and what clients should expect. - James [1] http://code.google.com/apis/gdata/ Antone Roundy wrote: > > I'm not subscribed to the APP mailing list, so hopefully this isn't all > redundant: > > On 12/15/06, Lisa Dusseault wrote: >> A model where servers aren't required to keep such information won't, in >> practice, allow that kind of extension. If clients can't rely on their >> markup getting stored, then clients can't extend Atom unilaterally >> using XML >> markup. > > There are two different issues here, which I think has been mentioned, > but which might bear being clearly stated: > > 1) Do servers have to keep all extension data? > > 2) Can a server accept an entry while discarding some or all extension > data, or do they have to reject the entry and return an error code? > > I think the answer to the first question is clearly no--servers > shouldn't be required to store all arbitrary data that is sent to them. > So the questions are: > > 1) Which hurts more--data loss or rejected entries? > > 2) Is there any way to reduce that pain? > > The pain of data loss is obvious--the data is lost. The pain of > rejected entries is having to fix and repost them or decide not to try > again. > > In either case, it might be useful to be able to query the server > somehow to find out what it will and won't preserve. If data is > discarded, you can figure that out after the fact by loading the > resulting entry and checking whether the data is all there, but one > might prefer to know ahead of time if something is going to be lost in > order to be able to decide whether to post it or not. If the entry is > just going to be rejected, unless there's a way for the server to > communicate exactly which data it had issues with, fixing the data to > make it acceptable could be extremely difficult ("Hmm, I'll leave this > data out and try again...nope, still rejected. I'll put that back in and > leave this out...nope. I'll take both out...nope. I'll put both back in > and take yet another piece of data out..."). > > So, how might a client query a server to see what it will preserve? A > few possibilities: > > 1) Have some way to request some sort of description of what will and > won't be preserved and what might be altered. I don't know how one > would go about responding to such an inquiry except to basically send > back a list of what will be preserved, including some way to say "I'll > preserve unknown attributes here", "I'll preserve unknown child elements > (and their children) here", "I'll store up to 32767 bytes here", etc. > If there is any known extension markup that a server wants to explicitly > state that it won't preserve, there may need to be a way to do that too. > > 2) Have a way to do a "test post", where one posts the data one is > considering posting (or something structurally identical), but says > "don't store this--just tell me what you WOULD store". The response > could include what would be returned if one were to load the data after > it being stored, or it could be some sort of list of anything that would > be discarded or altered. > > 3) (I get the impression this could be done without requiring > changes--is this the sort of process that has already been selected?) > Post the data as a draft, reload it to see if it's all still there. If > so, or if what has been preserved is acceptable, change it's status to > "published" or whatever it's called. If not delete it and give up or > take whatever other action is appropriate. > > > My impression is that data loss would be less painful and more easily > dealt with than rejection of entries that won't be completely preserved. > > ...but I haven't followed the discussion, so what do I know. > > From owner-atom-syntax@mail.imc.org Sat Dec 16 20:36:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvkxC-0000I5-6r for atompub-archive@lists.ietf.org; Sat, 16 Dec 2006 20:36:38 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvkxA-0001mu-JJ for atompub-archive@lists.ietf.org; Sat, 16 Dec 2006 20:36:38 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBH1OoRF089348; Sat, 16 Dec 2006 18:24:50 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBH1OotB089346; Sat, 16 Dec 2006 18:24:50 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironclad.net.au ([203.30.247.11]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id kBH1OmuF089339 for ; Sat, 16 Dec 2006 18:24:49 -0700 (MST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.118] (HELO [192.168.1.2]) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.0007461111 for ; Sun, 17 Dec 2006 12:24:35 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 17 Dec 2006 12:24:48 +1100 Subject: Re: AD Evaluation of draft-ietf-atompub-protocol-11 From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: 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: List-Unsubscribe: List-ID: X-Spam-Score: 1.1 (+) X-Scan-Signature: d6b246023072368de71562c0ab503126 On 17/12/06 2:20 AM, "Tim Bray" wrote: >> I guess I'm assuming that one would want clients to be able to >> extend Atom unilaterally. > > That doesn't seem to have been a design goal for the WG. To the > extent that the issue never came up in the discussion. Not sure exactly, but I did raise the possibility of a client passing in XML whose only purpose is for the benefit of other clients. Things like editorial comments and such. These would have been shepherded in the app:control element, and there was a great deal of discussion about the contents of app:control not being "published" (whatever that meant). It got hairy, and there wasn't much support for the idea. e. From owner-atom-syntax@mail.imc.org Sat Dec 16 21:08:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvlSJ-0003qI-F7 for atompub-archive@lists.ietf.org; Sat, 16 Dec 2006 21:08:47 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvlSG-0004fA-MC for atompub-archive@lists.ietf.org; Sat, 16 Dec 2006 21:08:47 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBH1tfMt091996; Sat, 16 Dec 2006 18:55:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBH1tfcM091995; Sat, 16 Dec 2006 18:55:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBH1teA4091988 for ; Sat, 16 Dec 2006 18:55:40 -0700 (MST) (envelope-from bobwyman@gmail.com) Received: by py-out-1112.google.com with SMTP id f31so646178pyh for ; Sat, 16 Dec 2006 17:55:40 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:x-google-sender-auth; b=imxN9XN6wJwqcodlbSd++10jNOAFBAtaovpVWqHre4PkzmvwXsBxRbL5iEJ6NClvW2rh9ULn0UTnSZkS9WKkFaSJQ/JQH8ln26h3Ssh/fCR9iUPRGZ3AiWsfCkZcUAc71d9WrCvO1kungxVFKwJ955gXNQuNWiowiZDTEweyZFE= Received: by 10.35.110.13 with SMTP id n13mr4499615pym.1166320539671; Sat, 16 Dec 2006 17:55:39 -0800 (PST) Received: by 10.35.15.12 with HTTP; Sat, 16 Dec 2006 17:55:39 -0800 (PST) Message-ID: <45be5cd40612161755j997553cv8a728be443b54cbe@mail.gmail.com> Date: Sat, 16 Dec 2006 20:55:39 -0500 From: "Bob Wyman" To: "Lisa Dusseault" , atom-syntax@imc.org Subject: Inheritance of license grants by entries in a feed Cc: "Bjoern Hoehrmann" , "Karl Dubost" , "Mike Linksvayer" , "Andreas Sewe" , "Thomas Roessler" , "Wendy Seltzer" , "A. Pagaltzis" , "John Panzer" , "Antone Roundy" , "David Powell" , "Robert Sparks" , "James M Snell" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_136614_31719015.1166320539457" X-Google-Sender-Auth: 10780532310e4ede Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.5 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 ------=_Part_136614_31719015.1166320539457 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline In general, I think the latest version of James Snell's license ID [1] is much better than earlier versions. I am particularly pleased that this draft only speaks of license "grants." I remain, as always, opposed to anything that would encourage people to attempt to restrict the implied license to syndicate. I do, however, have a few small issues. The text on "inheritance" is, I think, almost correct in this draft however, as written it seems to create a risk of the incorrect granting of rights as well as unfortunate loss or decay of grants when entries are copied between feeds. The current draft states: (focus on the underlined bits. The first underlined sentence is too restrictive, the second too inclusive.) 2.3. Inherited Licenses > The license on a feed MAY be inherited by entries. Generally, a more > specific license overrides the less specific license. More specifically, > if an entry has any license link relations at all, including the > "undefined" license, it does not inherit the license of > the feed. If an entry has no license link relations, it does inherit the > license of its parent feed(s). Since an entry may appear in multiple > feeds, it may inherit multiple licenses. This is equivalent to stating > multiple licenses on the entry itself. > I am concerned that some readers who are not intimately familiar with RFC4287 may not understand that entries which contain atom:source elements do NOT inherit feed metadata from the feeds in which they are found. The text of the current draft seems to override this constraint on inheritance. Thus, I propose the following new wording for the third and fourth sentences in the first paragraph of section 2.3 (the one's quoted and underlined above): More specifically, if an entry has any license link relations at all, > including the "undefined" license, [or, if the entry contains an > atom:source element,] it does not inherit the license of the feed. If an > entry has no license link relations[, and contains no atom:source > element,] it does inherit the license of its parent feed(s). > Additionally, I believe that this draft should align with the handling of atom:rights defined in section 4.2.11 of RFC4287 by adding the following text at some appropriate location: If an atom:entry which does not contain an atom:source is copied from one > feed into another feed then if the feed into which it is copied contains a > license, an atom:source element SHOULD be added to the copied entry. If a > source feed contains a license, that license SHOULD be preserved in an > atom:source element added to any entries copied from the source feed which > do not already contain atom:source elements. > The first constraint is necessary to ensure that the act of copying entries does not result in rights being granted by the copyist even though those rights were were not granted by the entry's author. The second constraint helps to prevent the "loss" or "decay" of rights as things are copied from feeds with licenses that grant rights into feeds that contain no or lesser grants. I realize that clarifying these constraints on inheritance allows for at least one "odd" result. That is, I might have a feed which contains entries whose atom:source elements declare license grants that differ greatly from what is seen in the feed's metadata even though all those entries claim the enclosing feed as their "source." This actually makes a good bit more sense than it might seem to at first glance. The reason for this is that the rights granted for entries added to a feed can change over time even though changes to the feed's default rights may not impact previously created entries. Thus, a feed might have granted liberal rights when an entry was first created but might not offer the same grants when the entry was updated. The author should be able to maintain with the entry the rights that were originally granted (or not granted) rather than being forced to update the rights in order to do something as simple as a spelling correction. (Yes, I realize that the author could, in some cases, simply attach the old rights to the updated entry rather than using an atom:source which contains the same information. However, this can get messy in some situations and causes us to lose some information about the source of the license grants -- it may be useful in some cases to distinguish between licenses granted in feed metadata and those granted in entry metadata. Forcing attachment of licenses to entries would also require using the "undefined" license in more cases than is desirable.) I've got a few other comments -- destined for other messages. Nonetheless, this draft is looking much better than earlier drafts. bob wyman [1] http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-license-10.txt ------=_Part_136614_31719015.1166320539457 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline In general, I think the latest version of James Snell's license ID [1] is m= uch better than earlier versions. I am particularly pleased that this draft= only speaks of license "grants." I remain, as always, opposed to= anything that would encourage people to attempt to restrict the implied li= cense to syndicate. I do, however, have a few small issues. The text on &qu= ot;inheritance" is, I think, almost correct in this draft however, as = written it seems to create a risk of the incorrect granting of rights as we= ll as unfortunate loss or decay of grants when entries are copied between f= eeds.

The current draft states: (focus on the underlined bits. The first = underlined sentence is too restrictive, the second too inclusive.)

2.3. Inherited Licenses
= The license on a feed MAY be= inherited by entries. Generally, a more specific license overrides the le= ss specific license. =20 More specifically, if an entry has any license link rel= ations at all,=20 = including the "unde= fined" license, it does not inherit the license of
the feed. If an entry has no license link relatio= ns, it does inherit=20 = the license of its paren= t feed(s). Since an entry may appear in multiple feeds, it may inherit multiple licenses. This is equivalen= t to stating multiple licens= es on the entry itself.

I am concerned that some read= ers who are not intimately familiar with RFC4287 may not understand that en= tries which contain atom:source elements do NOT inherit feed metadata from = the feeds in which they are found. The text of the current draft seems to o= verride this constraint on inheritance. Thus, I propose the following new w= ording for the third and fourth sentences in the first paragraph of section= =20 2.3 (the one's quoted and underlined above):

More specifically, if an entry has any l= icense link relations at all, including the "undefined" license,= =20 [or, if the entry contains an atom:sourc= e element,] it does not inherit the license of the feed. If an entry= has no license link relations[, and con= tains no atom:source element,] it does inherit the license of its parent feed(s).
=
Additionally, I believe that this draft should align with the handling = of atom:rights defined in section 4.2.11 of RFC4287 by adding the following= text at some appropriate location:

If an ato= m:entry which does not contain an atom:source is copied from one feed into = another feed then if the feed into which it is copied contains a license, a= n atom:source element SHOULD be added to the copied entry. If a source feed= contains a license, that license SHOULD be preserved in an atom:source ele= ment added to any entries copied from the source feed which do not already = contain atom:source elements.

The first constraint is necessary to ensure that the a= ct of copying entries does not result in rights being granted by the copyis= t even though those rights were were not granted by the entry's author. The= second constraint helps to prevent the "loss" or "decay&quo= t; of rights as things are copied from feeds with licenses that grant right= s into feeds that contain no or lesser grants.

I realize that clarifying these constraints on inheritance allows f= or at least one "odd" result. That is, I might have a feed which = contains entries whose atom:source elements declare license grants that dif= fer greatly from what is seen in the feed's metadata even though all those = entries claim the enclosing feed as their "source." This actually= makes a good bit more sense than it might seem to at first glance. The rea= son for this is that the rights granted for entries added to a feed can cha= nge over time even though changes to the feed's default rights may not impa= ct previously created entries. Thus, a feed might have granted liberal righ= ts when an entry was first created but might not offer the same grants when= the entry was updated. The author should be able to maintain with the entr= y the rights that were originally granted (or not granted) rather than bein= g forced to update the rights in order to do something as simple as a spell= ing correction. (Yes, I realize that the author could, in some cases, simpl= y attach the old rights to the updated entry rather than using an atom:sour= ce which contains the same information. However, this can get messy in some= situations and causes us to lose some information about the source of the = license grants -- it may be useful in some cases to distinguish between lic= enses granted in feed metadata and those granted in entry metadata. Forcing= attachment of licenses to entries would also require using the "undef= ined" license in more cases than is desirable.)

I've got a few other comments -- destined for other messages. Nonet= heless, this draft is looking much better than earlier drafts.

bob w= yman

[1] http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-license-10.txt=

------=_Part_136614_31719015.1166320539457-- From owner-atom-syntax@mail.imc.org Sat Dec 16 21:24:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gvlhd-0001Sf-O6 for atompub-archive@lists.ietf.org; Sat, 16 Dec 2006 21:24:37 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gvlhc-0006tZ-4f for atompub-archive@lists.ietf.org; Sat, 16 Dec 2006 21:24:37 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBH2B9KU093380; Sat, 16 Dec 2006 19:11:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBH2B9bI093379; Sat, 16 Dec 2006 19:11:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBH2B8CN093373 for ; Sat, 16 Dec 2006 19:11:08 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id i30so992810wxd for ; Sat, 16 Dec 2006 18:11:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Lt36iCnNVoccQsPIaRdu3eTZkqHCN53BnRonTPV2kXSUc+P4PURdgeCZZmUeN32VrhPigGHt/VEPIh7IO1AoasTH4FEex7uazxjiGRUhXF8SquMkh1K+OOxa/G3okzl6eO3GolKu1qoM2IvpapiGqNTQWjLsd389TTUfuLWmV4I= Received: by 10.70.99.9 with SMTP id w9mr4371780wxb.1166321467718; Sat, 16 Dec 2006 18:11:07 -0800 (PST) Received: from ?192.168.1.109? ( [67.181.218.96]) by mx.google.com with ESMTP id 6sm8438258wrh.2006.12.16.18.11.00; Sat, 16 Dec 2006 18:11:03 -0800 (PST) Message-ID: <4584A732.3090509@gmail.com> Date: Sat, 16 Dec 2006 18:10:58 -0800 From: James M Snell User-Agent: Thunderbird 1.5.0.8 (X11/20061115) MIME-Version: 1.0 To: Bob Wyman CC: Lisa Dusseault , atom-syntax@imc.org, Bjoern Hoehrmann , Karl Dubost , Mike Linksvayer , Andreas Sewe , Thomas Roessler , Wendy Seltzer , "A. Pagaltzis" , John Panzer , Antone Roundy , David Powell , Robert Sparks Subject: Re: Inheritance of license grants by entries in a feed References: <45be5cd40612161755j997553cv8a728be443b54cbe@mail.gmail.com> In-Reply-To: <45be5cd40612161755j997553cv8a728be443b54cbe@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Bob, As always, thanks for the feedback. These are excellent suggestions. I'll work them into the next draft. - James Bob Wyman wrote: > In general, I think the latest version of James Snell's license ID [1] > is much better than earlier versions. I am particularly pleased that > this draft only speaks of license "grants." I remain, as always, opposed > to anything that would encourage people to attempt to restrict the > implied license to syndicate. I do, however, have a few small issues. > The text on "inheritance" is, I think, almost correct in this draft > however, as written it seems to create a risk of the incorrect granting > of rights as well as unfortunate loss or decay of grants when entries > are copied between feeds. > > The current draft states: (focus on the underlined bits. The first > underlined sentence is too restrictive, the second too inclusive.) > > 2.3. Inherited Licenses > The license on a feed MAY be inherited by entries. Generally, a more > specific license overrides the less specific license. More > specifically, if an entry has any license link relations at all, > including the "undefined" license, it does not inherit the license of > the feed. If an entry has no license link relations, it does inherit > the license of its parent feed(s). Since an entry may appear in > multiple feeds, it may inherit multiple licenses. This is equivalent > to stating multiple licenses on the entry itself. > > > I am concerned that some readers who are not intimately familiar with > RFC4287 may not understand that entries which contain atom:source > elements do NOT inherit feed metadata from the feeds in which they are > found. The text of the current draft seems to override this constraint > on inheritance. Thus, I propose the following new wording for the third > and fourth sentences in the first paragraph of section 2.3 (the one's > quoted and underlined above): > > More specifically, if an entry has any license link relations at > all, including the "undefined" license, [or, if the entry contains > an atom:source element,] it does not inherit the license of the > feed. If an entry has no license link relations[, and contains no > atom:source element,] it does inherit the license of its parent feed(s). > > > Additionally, I believe that this draft should align with the handling > of atom:rights defined in section 4.2.11 of RFC4287 by adding the > following text at some appropriate location: > > If an atom:entry which does not contain an atom:source is copied > from one feed into another feed then if the feed into which it is > copied contains a license, an atom:source element SHOULD be added to > the copied entry. If a source feed contains a license, that license > SHOULD be preserved in an atom:source element added to any entries > copied from the source feed which do not already contain atom:source > elements. > > > The first constraint is necessary to ensure that the act of copying > entries does not result in rights being granted by the copyist even > though those rights were were not granted by the entry's author. The > second constraint helps to prevent the "loss" or "decay" of rights as > things are copied from feeds with licenses that grant rights into feeds > that contain no or lesser grants. > > I realize that clarifying these constraints on inheritance allows for at > least one "odd" result. That is, I might have a feed which contains > entries whose atom:source elements declare license grants that differ > greatly from what is seen in the feed's metadata even though all those > entries claim the enclosing feed as their "source." This actually makes > a good bit more sense than it might seem to at first glance. The reason > for this is that the rights granted for entries added to a feed can > change over time even though changes to the feed's default rights may > not impact previously created entries. Thus, a feed might have granted > liberal rights when an entry was first created but might not offer the > same grants when the entry was updated. The author should be able to > maintain with the entry the rights that were originally granted (or not > granted) rather than being forced to update the rights in order to do > something as simple as a spelling correction. (Yes, I realize that the > author could, in some cases, simply attach the old rights to the updated > entry rather than using an atom:source which contains the same > information. However, this can get messy in some situations and causes > us to lose some information about the source of the license grants -- it > may be useful in some cases to distinguish between licenses granted in > feed metadata and those granted in entry metadata. Forcing attachment of > licenses to entries would also require using the "undefined" license in > more cases than is desirable.) > > I've got a few other comments -- destined for other messages. > Nonetheless, this draft is looking much better than earlier drafts. > > bob wyman > > [1] > http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-license-10.txt > From owner-atom-syntax@mail.imc.org Sat Dec 16 21:25:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvliG-0001oA-Ej for atompub-archive@lists.ietf.org; Sat, 16 Dec 2006 21:25:16 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gvli9-0006wc-Pr for atompub-archive@lists.ietf.org; Sat, 16 Dec 2006 21:25:16 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBH2DAbh093531; Sat, 16 Dec 2006 19:13:10 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBH2DAHo093530; Sat, 16 Dec 2006 19:13:10 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id kBH2D7KM093505 for ; Sat, 16 Dec 2006 19:13:08 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 17 Dec 2006 02:13:06 -0000 Received: from xdsl-87-79-236-202.netcologne.de (EHLO klangraum) [87.79.236.202] by mail.gmx.net (mp004) with SMTP; 17 Dec 2006 03:13:06 +0100 X-Authenticated: #163624 Date: Sun, 17 Dec 2006 03:13:05 +0100 From: "A. Pagaltzis" To: Atom , atom-protocol Protocol Subject: Re: AD Evaluation of draft-ietf-atompub-protocol-11 Message-ID: <20061217021305.GN13961@klangraum> Mail-Followup-To: Atom , atom-protocol Protocol References: <8BD53B7C-5B43-4F2D-8DC5-0281CCB84B84@commerce.net> <3f1451f50612070836h45091080k851cece2198c464a@mail.gmail.com> <4582C9BC.8010704@sun.com> <057641F2-0976-45BD-A8B3-497475F50951@commerce.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <057641F2-0976-45BD-A8B3-497475F50951@commerce.net> User-Agent: Mutt/1.4.2.1i Organization: haphazard X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id kBH2DAbh093531 X-Spam-Score: 1.1 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab * Lisa Dusseault [2006-12-16 02:15]: > Since clients post Atom entries and other clients retrieve > them, it seemed reasonable to want to extend Atom > client-to-client. If I used "AtomFu" client that was able to > annotate my entries automatically with what music I was > listening to (track name, album and artist in XML elements) > while I wrote a blog posting, I thought AtomFu should just > store that as XML markup in the entry. That is, IMO, a misconception about Atom =E2=80=93 one that is frequently seen. We just had a similar discussion tonight in #atom on the Freenode IRC network. The track name, album and artist are data; they should be part of the payload of an entry, not part of its envelope. In practice, that means you use either microformats or a more structured format than HTML. Extending the Atom envelope is a strategy of last resort. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Sat Dec 16 21:43:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gvlza-0007ve-ID for atompub-archive@lists.ietf.org; Sat, 16 Dec 2006 21:43:10 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvlzZ-0000HG-20 for atompub-archive@lists.ietf.org; Sat, 16 Dec 2006 21:43:10 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBH2OxZ6094500; Sat, 16 Dec 2006 19:24:59 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBH2OxHO094499; Sat, 16 Dec 2006 19:24:59 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBH2Ow6A094493 for ; Sat, 16 Dec 2006 19:24:59 -0700 (MST) (envelope-from bobwyman@gmail.com) Received: by py-out-1112.google.com with SMTP id f31so649068pyh for ; Sat, 16 Dec 2006 18:24:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:x-google-sender-auth; b=Eb4izhE14f/glMMnafmxDkO6EBFT9v03R9wnHQio9RuSadRAxU30o5PYy/x+3p7nevQ2DZPDT93ADhdCCaTrzOaVNptOI5SRuEM0H7ffZUD3eQvNgWOpuR4/Wx3zVR9umRF2zUI8E7WX1yeMXIJLrmkyqvylbgXMXfJeg0RtoQ0= Received: by 10.35.125.16 with SMTP id c16mr4779571pyn.1166322298353; Sat, 16 Dec 2006 18:24:58 -0800 (PST) Received: by 10.35.15.12 with HTTP; Sat, 16 Dec 2006 18:24:58 -0800 (PST) Message-ID: <45be5cd40612161824u6a6b2f20s70e5abae78dd7070@mail.gmail.com> Date: Sat, 16 Dec 2006 21:24:58 -0500 From: "Bob Wyman" To: "Lisa Dusseault" , atom-syntax@imc.org Subject: License Draft: Tortured text re obligations... Cc: "Bjoern Hoehrmann" , "Karl Dubost" , "Mike Linksvayer" , "Andreas Sewe" , "Thomas Roessler" , "Wendy Seltzer" , "A. Pagaltzis" , "John Panzer" , "Antone Roundy" , "David Powell" , "Robert Sparks" , "James M Snell" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_136742_20642703.1166322298298" X-Google-Sender-Auth: ffa236241a5bb219 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.5 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 ------=_Part_136742_20642703.1166322298298 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline There is, I think a bit of tortured text in James Snell's otherwise useful License ID[1]. 1.3. Terminology ... The term "license" refers to a potentially machine-readable description of explicit rights, and associated obligations, that have been granted to consumers of an Atom feed or entry. The problem is the underlined clause... One can't "grant" an obligation. (When you have a conjunction, you should be able to scan the sentence with only one element of the conjunction without losing meaning...) As written, the sentence can be read by nitpicking lawyers as: "The term 'license' refers to obligations that have been granted..." Clearly, this isn't the intent. Thus, I propose the following rewording: The term "license" refers to a potentially machine-readable description of explicit rights that have been granted to consumers of an Atom feed or entry. Rights granted by a license may be associated with obligations which must be assumed by those exercising those rights. I realize that this is a bit more wordy than the existing text, however, I think it better perserves the author's intent. Also, it has the nice attribute of limiting the discussion of "obligations" to the scope of rights granted by the licenses -- not rights that might exist in the absence of the license. Nothing we do should encourage people to use in-feed or in-entry data to restrict rights which exist independent of an explicit license grant. Such rights may include fair-use rights, the right to create backups, the implied right to syndicate, etc. As with Creative Commons licenses, I believe our goal here should be to provide mechanisms to expand the rights granted -- not to restrict them. bob wyman [1] http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-license-10.txt ------=_Part_136742_20642703.1166322298298 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
There is, I think a bit of tortured text in James Snell's otherwise useful License ID[1].
1.3. Terminology
...
The term "license" refers to a potentially machine-readable description of explicit rights, and associated obligations, that have been granted to consumers of an Atom feed or entry.
The problem is the underlined clause... One can't "grant" an obligation. (When you have a conjunction, you should be able to scan the sentence with only one element of the conjunction without losing meaning...) As written, the sentence can be read by nitpicking lawyers as: "The term 'license' refers to obligations that have been granted..." Clearly, this isn't the intent. Thus, I propose the following rewording:
The term "license" refers to a potentially machine-readable description of explicit rights that have been granted to consumers of an Atom feed or entry. Rights granted by a license may be associated with obligations which must be assumed by those exercising those rights.
I realize that this is a bit more wordy than the existing text, however, I think it better perserves the author's intent. Also, it has the nice attribute of limiting the discussion of "obligations" to the scope of rights granted by the licenses -- not rights that might exist in the absence of the license. Nothing we do should encourage people to use in-feed or in-entry data to restrict rights which exist independent of an explicit license grant. Such rights may include fair-use rights, the right to create backups, the implied right to syndicate, etc. As with Creative Commons licenses, I believe our goal here should be to provide mechanisms to expand the rights granted -- not to restrict them.


------=_Part_136742_20642703.1166322298298-- From owner-atom-syntax@mail.imc.org Sat Dec 16 22:48:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gvn10-0006fA-LF for atompub-archive@lists.ietf.org; Sat, 16 Dec 2006 22:48:42 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gvn0v-00081B-Kc for atompub-archive@lists.ietf.org; Sat, 16 Dec 2006 22:48:42 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBH3Zo6x001494; Sat, 16 Dec 2006 20:35:50 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBH3ZoZL001493; Sat, 16 Dec 2006 20:35:50 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from darwin.ctyme.com (smtp8.junkemailfilter.com [69.50.231.8]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBH3ZntT001486 for ; Sat, 16 Dec 2006 20:35:49 -0700 (MST) (envelope-from ml@creativecommons.org) Received: from adsl-71-146-162-180.dsl.pltn13.sbcglobal.net ([71.146.162.180] helo=[192.168.1.102]) by darwin.ctyme.com with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.63) id 1GvmoN-0000jD-TV; Sat, 16 Dec 2006 19:35:39 -0800 Subject: Re: License Draft: Tortured text re obligations... From: Mike Linksvayer To: Bob Wyman Cc: Lisa Dusseault , atom-syntax@imc.org, Bjoern Hoehrmann , Karl Dubost , Andreas Sewe , Thomas Roessler , Wendy Seltzer , "A. Pagaltzis" , John Panzer , Antone Roundy , David Powell , Robert Sparks , James M Snell In-Reply-To: <45be5cd40612161824u6a6b2f20s70e5abae78dd7070@mail.gmail.com> References: <45be5cd40612161824u6a6b2f20s70e5abae78dd7070@mail.gmail.com> Content-Type: text/plain Date: Sat, 16 Dec 2006 19:35:39 -0800 Message-Id: <1166326539.5422.3.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Spamfilter-host: darwin.ctyme.com - http://www.junkemailfilter.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab On Sat, 2006-12-16 at 21:24 -0500, Bob Wyman wrote: > I realize that this is a bit more wordy than the existing text, > however, I think it better perserves the author's intent. Also, it has > the nice attribute of limiting the discussion of "obligations" to the > scope of rights granted by the licenses -- not rights that might exist > in the absence of the license. Nothing we do should encourage people > to use in-feed or in-entry data to restrict rights which exist > independent of an explicit license grant. Such rights may include > fair-use rights, the right to create backups, the implied right to > syndicate, etc. As with Creative Commons licenses, I believe our goal > here should be to provide mechanisms to expand the rights granted -- > not to restrict them. > I agree with Bob's suggested change. Draft 10 is looking very good from my perspective. > -- http://wiki.creativecommons.org/User:Mike_Linksvayer From owner-atom-syntax@mail.imc.org Sun Dec 17 00:37:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvoiP-00047X-7e for atompub-archive@lists.ietf.org; Sun, 17 Dec 2006 00:37:37 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvoiN-0004xd-Pi for atompub-archive@lists.ietf.org; Sun, 17 Dec 2006 00:37:37 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBH5Lwvw009572; Sat, 16 Dec 2006 22:21:58 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBH5Lw2x009571; Sat, 16 Dec 2006 22:21:58 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.225]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBH5LuCR009565 for ; Sat, 16 Dec 2006 22:21:57 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id i30so1013225wxd for ; Sat, 16 Dec 2006 21:21:56 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=a7QXnh01yTFS8j8uOfdhelKYOsEYJ/a0WksXdZ+mtLSx5R5Z6XbYxkiuYhb8cz7/AOPAF8FPgWZh1zvsUkHOjSQasaMikLZzVnCkdiIDGCR4NtQVlP2pNeOKFpz7Jo8TrYvBvapcuqoLsmkhqCr95pw4HhQeq5cZQSW3soVSsrA= Received: by 10.70.132.2 with SMTP id f2mr4635308wxd.1166332916480; Sat, 16 Dec 2006 21:21:56 -0800 (PST) Received: from ?192.168.1.109? ( [67.181.218.96]) by mx.google.com with ESMTP id 29sm10248990wrl.2006.12.16.21.21.52; Sat, 16 Dec 2006 21:21:55 -0800 (PST) Message-ID: <4584D3ED.5030908@gmail.com> Date: Sat, 16 Dec 2006 21:21:49 -0800 From: James M Snell User-Agent: Thunderbird 1.5.0.8 (X11/20061115) MIME-Version: 1.0 To: Bob Wyman CC: Lisa Dusseault , atom-syntax@imc.org, Bjoern Hoehrmann , Karl Dubost , Mike Linksvayer , Andreas Sewe , Thomas Roessler , Wendy Seltzer , "A. Pagaltzis" , John Panzer , Antone Roundy , David Powell , Robert Sparks Subject: Re: License Draft: Tortured text re obligations... References: <45be5cd40612161824u6a6b2f20s70e5abae78dd7070@mail.gmail.com> In-Reply-To: <45be5cd40612161824u6a6b2f20s70e5abae78dd7070@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 +1. Another good edit. I've started working on draft 11 with these edits. - James Bob Wyman wrote: > There is, I think a bit of tortured text in James Snell's otherwise > useful License ID[1]. > > 1.3. Terminology > ... > The term "license" refers to a potentially machine-readable > description of explicit rights, and associated obligations, that > have been granted to consumers of an Atom feed or entry. > > The problem is the underlined clause... One can't "grant" an obligation. > (When you have a conjunction, you should be able to scan the sentence > with only one element of the conjunction without losing meaning...) As > written, the sentence can be read by nitpicking lawyers as: "The term > 'license' refers to obligations that have been granted..." Clearly, this > isn't the intent. Thus, I propose the following rewording: > > The term "license" refers to a potentially machine-readable > description of explicit rights that have been granted to consumers > of an Atom feed or entry. Rights granted by a license may be > associated with obligations which must be assumed by those > exercising those rights. > > I realize that this is a bit more wordy than the existing text, however, > I think it better perserves the author's intent. Also, it has the nice > attribute of limiting the discussion of "obligations" to the scope of > rights granted by the licenses -- not rights that might exist in the > absence of the license. Nothing we do should encourage people to use > in-feed or in-entry data to restrict rights which exist independent of > an explicit license grant. Such rights may include fair-use rights, the > right to create backups, the implied right to syndicate, etc. As with > Creative Commons licenses, I believe our goal here should be to provide > mechanisms to expand the rights granted -- not to restrict them. > > bob wyman > > [1] > http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-license-10.txt > From owner-atom-syntax@mail.imc.org Sun Dec 17 04:11:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gvs3n-0002zt-MQ for atompub-archive@lists.ietf.org; Sun, 17 Dec 2006 04:11:55 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gvs3m-0002sk-9T for atompub-archive@lists.ietf.org; Sun, 17 Dec 2006 04:11:55 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBH8ucFU028949; Sun, 17 Dec 2006 01:56:38 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBH8ucnf028948; Sun, 17 Dec 2006 01:56:38 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironclad.net.au ([203.30.247.11]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id kBH8uZme028923 for ; Sun, 17 Dec 2006 01:56:36 -0700 (MST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.118] (HELO [192.168.1.2]) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.0007462694 for ; Sun, 17 Dec 2006 19:56:19 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 17 Dec 2006 19:56:33 +1100 Subject: Re: AD Evaluation of draft-ietf-atompub-protocol-11 From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <20061217021305.GN13961@klangraum> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kBH8ubme028937 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id kBH8ucFU028949 X-Spam-Score: 1.1 (+) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 On 17/12/06 1:13 PM, "A. Pagaltzis" wrote: > * Lisa Dusseault [2006-12-16 02:15]: >> Since clients post Atom entries and other clients retrieve >> them, it seemed reasonable to want to extend Atom >> client-to-client. If I used "AtomFu" client that was able to >> annotate my entries automatically with what music I was >> listening to (track name, album and artist in XML elements) >> while I wrote a blog posting, I thought AtomFu should just >> store that as XML markup in the entry. >=20 > That is, IMO, a misconception about Atom =AD one that is frequently > seen. We just had a similar discussion tonight in #atom on the > Freenode IRC network. The track name, album and artist are data; > they should be part of the payload of an entry, not part of its > envelope. In practice, that means you use either microformats or > a more structured format than HTML. Extending the Atom envelope > is a strategy of last resort. wha? What music Lisa is listening to when she wrote a blog posting is meta dat= a, not content, unless of course she's writing a blog posting *about* that particular bit of music. The music is contextual meta data, along the sam= e vein as geo location of circumstance, the atom:generator involved, and ev= en the atom:published date/time. Since when are we calling atom entries "envelopes"? e. From owner-atom-syntax@mail.imc.org Sun Dec 17 04:29:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvsKf-0006Mj-4Q for atompub-archive@lists.ietf.org; Sun, 17 Dec 2006 04:29:21 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvsKd-0003NN-Nl for atompub-archive@lists.ietf.org; Sun, 17 Dec 2006 04:29:21 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBH9E2lv029975; Sun, 17 Dec 2006 02:14:02 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBH9E24w029974; Sun, 17 Dec 2006 02:14:02 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBH9E1sG029966 for ; Sun, 17 Dec 2006 02:14:02 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id i30so1036796wxd for ; Sun, 17 Dec 2006 01:14:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=A+f7zLAKeQynWphwqki+7M7RLHFMAAUiEmMsyXTRFR3QWyJhTqgN/wgsQ85Z7adq49d3ptlozy1eoUQ6JSe3eVHJnGIZvI+MkB00lHUpKdnFkrntlXhirNTw3dAWlZ0b57bY0fdKPhVwuJz+QBARfA+UTotBje/rNtYxK+ZxpzA= Received: by 10.70.61.1 with SMTP id j1mr4920873wxa.1166346841035; Sun, 17 Dec 2006 01:14:01 -0800 (PST) Received: from ?192.168.1.109? ( [67.181.218.96]) by mx.google.com with ESMTP id 25sm2440916wra.2006.12.17.01.13.59; Sun, 17 Dec 2006 01:14:00 -0800 (PST) Message-ID: <45850A55.5090907@gmail.com> Date: Sun, 17 Dec 2006 01:13:57 -0800 From: James M Snell User-Agent: Thunderbird 1.5.0.8 (X11/20061115) MIME-Version: 1.0 To: Eric Scheid CC: Atom Syntax Subject: Re: AD Evaluation of draft-ietf-atompub-protocol-11 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id kBH9E2lv029975 X-Spam-Score: 1.1 (+) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Quite frankly it doesn't matter what we call anything right now. The server gets to determine what pieces of data it's willing to handle. Period. If you want anything more than that, use webdav. - James Eric Scheid wrote: > On 17/12/06 1:13 PM, "A. Pagaltzis" wrote: >=20 >> * Lisa Dusseault [2006-12-16 02:15]: >>> Since clients post Atom entries and other clients retrieve >>> them, it seemed reasonable to want to extend Atom >>> client-to-client. If I used "AtomFu" client that was able to >>> annotate my entries automatically with what music I was >>> listening to (track name, album and artist in XML elements) >>> while I wrote a blog posting, I thought AtomFu should just >>> store that as XML markup in the entry. >> That is, IMO, a misconception about Atom =AD one that is frequently >> seen. We just had a similar discussion tonight in #atom on the >> Freenode IRC network. The track name, album and artist are data; >> they should be part of the payload of an entry, not part of its >> envelope. In practice, that means you use either microformats or >> a more structured format than HTML. Extending the Atom envelope >> is a strategy of last resort. >=20 > wha? >=20 > What music Lisa is listening to when she wrote a blog posting is meta d= ata, > not content, unless of course she's writing a blog posting *about* that > particular bit of music. The music is contextual meta data, along the s= ame > vein as geo location of circumstance, the atom:generator involved, and = even > the atom:published date/time. >=20 > Since when are we calling atom entries "envelopes"? >=20 > e. >=20 >=20 >=20 From owner-atom-syntax@mail.imc.org Sun Dec 17 05:01:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gvspn-0000De-Hy for atompub-archive@lists.ietf.org; Sun, 17 Dec 2006 05:01:31 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gvspm-0000Vc-6x for atompub-archive@lists.ietf.org; Sun, 17 Dec 2006 05:01:31 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBH9mQu1032459; Sun, 17 Dec 2006 02:48:26 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBH9mQiP032458; Sun, 17 Dec 2006 02:48:26 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id kBH9mOKg032452 for ; Sun, 17 Dec 2006 02:48:25 -0700 (MST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 17 Dec 2006 09:48:24 -0000 Received: from p508FAE12.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.174.18] by mail.gmx.net (mp035) with SMTP; 17 Dec 2006 10:48:24 +0100 X-Authenticated: #1915285 Message-ID: <4585125C.2040102@gmx.de> Date: Sun, 17 Dec 2006 10:48:12 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: James M Snell CC: Eric Scheid , Atom Syntax Subject: Re: AD Evaluation of draft-ietf-atompub-protocol-11 References: <45850A55.5090907@gmail.com> In-Reply-To: <45850A55.5090907@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.1 (+) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 James M Snell schrieb: > Quite frankly it doesn't matter what we call anything right now. The > server gets to determine what pieces of data it's willing to handle. > Period. If you want anything more than that, use webdav. > ... Again: WebDAV doesn't redefine PUT, so the situation is exactly the same. (Unless you were referring to PROPFIND/PROPPATCH). Best regards, Julian From owner-atom-syntax@mail.imc.org Sun Dec 17 05:50:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gvtbf-0008Gq-Lo for atompub-archive@lists.ietf.org; Sun, 17 Dec 2006 05:50:59 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gvtbe-0002FA-8a for atompub-archive@lists.ietf.org; Sun, 17 Dec 2006 05:50:59 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBHAYCvF038054; Sun, 17 Dec 2006 03:34:12 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBHAYCQC038051; Sun, 17 Dec 2006 03:34:12 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.174]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBHAYCiM038044 for ; Sun, 17 Dec 2006 03:34:12 -0700 (MST) (envelope-from algermissen1971@mac.com) Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/8.12.11/smtpout04/MantshX 4.0) with ESMTP id kBHAY97T006183; Sun, 17 Dec 2006 02:34:09 -0800 (PST) Received: from [10.0.1.2] (d114233.adsl.hansenet.de [80.171.114.233]) (authenticated bits=0) by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id kBHAY5GU029843; Sun, 17 Dec 2006 02:34:07 -0800 (PST) In-Reply-To: <45850A55.5090907@gmail.com> References: <45850A55.5090907@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9C589749-1B64-4988-BB3E-5398B42D8243@mac.com> Cc: Eric Scheid , Atom Syntax Content-Transfer-Encoding: 7bit From: Jan Algermissen Subject: Re: AD Evaluation of draft-ietf-atompub-protocol-11 Date: Sun, 17 Dec 2006 11:34:27 +0100 To: James M Snell X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.6 (+) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 On Dec 17, 2006, at 10:13 AM, James M Snell wrote: > > Quite frankly it doesn't matter what we call anything right now. The > server gets to determine what pieces of data it's willing to handle. > Period. If you want anything more than that, use webdav. > (Sorry if this has already been said or not on the point, but I cannot read through the thread right now). - The server is free to 'mess' with the PUTed data at will before doing the update; so it can strip out whatever it wants. - Clients should do a GET before doing a PUT so they get some chance to see what the sever actually handles Jan > - James > > Eric Scheid wrote: >> On 17/12/06 1:13 PM, "A. Pagaltzis" wrote: >> >>> * Lisa Dusseault [2006-12-16 02:15]: >>>> Since clients post Atom entries and other clients retrieve >>>> them, it seemed reasonable to want to extend Atom >>>> client-to-client. If I used "AtomFu" client that was able to >>>> annotate my entries automatically with what music I was >>>> listening to (track name, album and artist in XML elements) >>>> while I wrote a blog posting, I thought AtomFu should just >>>> store that as XML markup in the entry. >>> That is, IMO, a misconception about Atom one that is frequently >>> seen. We just had a similar discussion tonight in #atom on the >>> Freenode IRC network. The track name, album and artist are data; >>> they should be part of the payload of an entry, not part of its >>> envelope. In practice, that means you use either microformats or >>> a more structured format than HTML. Extending the Atom envelope >>> is a strategy of last resort. >> >> wha? >> >> What music Lisa is listening to when she wrote a blog posting is >> meta data, >> not content, unless of course she's writing a blog posting *about* >> that >> particular bit of music. The music is contextual meta data, along >> the same >> vein as geo location of circumstance, the atom:generator involved, >> and even >> the atom:published date/time. >> >> Since when are we calling atom entries "envelopes"? >> >> e. >> >> >> > From owner-atom-syntax@mail.imc.org Sun Dec 17 16:51:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gw3uo-0002zi-QZ for atompub-archive@lists.ietf.org; Sun, 17 Dec 2006 16:51:26 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gw3un-0006tL-7o for atompub-archive@lists.ietf.org; Sun, 17 Dec 2006 16:51:26 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBHLb5AP006786; Sun, 17 Dec 2006 14:37:05 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBHLb5Fq006785; Sun, 17 Dec 2006 14:37:05 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBHLb2QY006770 for ; Sun, 17 Dec 2006 14:37:05 -0700 (MST) (envelope-from bobwyman@gmail.com) Received: by py-out-1112.google.com with SMTP id f31so744244pyh for ; Sun, 17 Dec 2006 13:37:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=JOIEiEye+/ZR+sGSGDANDg3m+uXlFs9YXSBsVZ2pxY+Ucil0E2im4OSmNbl+l83IcX4hzERAS2HExTJWM8+ku99MJZk09m6BV+YuvKSzri3TEWfFWY+NcLJwqv61gRH0eql8sbQM8k45qrgODQxVYzuxeP70BtjuOjUuYXBfCWs= Received: by 10.35.93.1 with SMTP id v1mr6388759pyl.1166391422379; Sun, 17 Dec 2006 13:37:02 -0800 (PST) Received: by 10.35.15.12 with HTTP; Sun, 17 Dec 2006 13:37:02 -0800 (PST) Message-ID: <45be5cd40612171337i175ed046rd26ab0687477a8db@mail.gmail.com> Date: Sun, 17 Dec 2006 16:37:02 -0500 From: "Bob Wyman" To: Atom , "atom-protocol Protocol" Subject: Re: AD Evaluation of draft-ietf-atompub-protocol-11 In-Reply-To: <20061217021305.GN13961@klangraum> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2792_582241.1166391422299" References: <8BD53B7C-5B43-4F2D-8DC5-0281CCB84B84@commerce.net> <3f1451f50612070836h45091080k851cece2198c464a@mail.gmail.com> <4582C9BC.8010704@sun.com> <057641F2-0976-45BD-A8B3-497475F50951@commerce.net> <20061217021305.GN13961@klangraum> X-Google-Sender-Auth: 51253ebefefda229 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.4 (+) X-Scan-Signature: 386e0819b1192672467565a524848168 ------=_Part_2792_582241.1166391422299 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 12/16/06, A. Pagaltzis wrote: > > Extending the Atom envelope is a strategy of last resort. > +1 It is important to remember that not all processors of Atom data will know what to do with unexpected metadata in the envelope. Thus, unexpected envelope fields will often simply be stripped off and thrown to the bit bucket. If you want data to stay with your "content," it is best to put it in the ... Sometimes, it may be appropriate to extend the envelope, however, one should not do so without a really compelling case. Envelope extensions typically require "fetching time" or database structure modifications in consuming applications if those extensions are to be supported. This is because many feed consumers have distinct fields in their databases or internal structures for each of the envelope elements and then just have a single field for content. Also, the code for manipulating envelope fields is usually distinctly different from the code used to manipulate and process . So, if you create a new envelope field, you require a great deal of code to be modified for that field to be supported. On the other hand, if something can be slipped into you'll see it being stored immediately and have the opportunity for downstream consumers (display routines, etc.) to provide support for the additional data. (For instance, you might write a GreaseMonkey script to do interesting things with stuff encoded in even though the "backend" of the application knows nothing about it.) My personal feeling is that many of the proposals (but not all) for envelope extensions are derived from what I consider to be unfortunate precedent set in the RSS world where all sorts of random stuff has been pushed into the envelope since in RSS the field is so under-specified that it isn't really possible to think of it as something which can be structured. Fortunately, the field has moved forward since legacy RSS was defined and we've got better methods that can be used with Atom. There are undoubtedly still things that might go in the envelope, but not as many as some folk might think. bob wyman ------=_Part_2792_582241.1166391422299 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 12/16/06, A. Pagaltzis <pagaltzis@gmx.de> wrote:
Extending the Atom envelope is a strategy of last resort.
<= /div>
+1

It is important to remember that not all processors of A= tom data will know what to do with unexpected metadata in the envelope. Thu= s, unexpected envelope fields will often simply be stripped off and thrown = to the bit bucket. If you want data to stay with your "content," = it is best to put it in the <content/>...  Sometimes, it may be = appropriate to extend the envelope, however, one should not do so without a= really compelling case.

Envelope extensions typically require "fetching time" or = database structure modifications in consuming applications if those extensi= ons are to be supported. This is because many feed consumers have distinct = fields in their databases or internal structures for each of the envelope e= lements and then just have a single field for content. Also, the code for m= anipulating envelope fields is usually distinctly different from the code u= sed to manipulate and process <content/>. So, if you create a new env= elope field, you require a great deal of code to be modified for that field= to be supported. On the other hand, if something can be slipped into <c= ontent/> you'll see it being stored immediately and have the opportunity= for downstream consumers (display routines, etc.) to provide support for t= he additional data. (For instance, you might write a GreaseMonkey script to= do interesting things with stuff encoded in <content/> even though t= he "backend" of the application knows nothing about it.)

My personal feeling is that many of the proposals (but not all) for= envelope extensions are derived from what I consider to be unfortunate pre= cedent set in the RSS world where all sorts of random stuff has been pushed= into the envelope since in RSS the <description/> field is so under-= specified that it isn't really possible to think of it as something which c= an be structured. Fortunately, the field has moved forward since legacy RSS= was defined and we've got better methods that can be used with Atom. There= are undoubtedly still things that might go in the envelope, but not as man= y as some folk might think.

bob wyman

------=_Part_2792_582241.1166391422299-- From owner-atom-syntax@mail.imc.org Sun Dec 17 17:50:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gw4qC-0005nw-V2 for atompub-archive@lists.ietf.org; Sun, 17 Dec 2006 17:50:44 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gw4qA-0006cz-VK for atompub-archive@lists.ietf.org; Sun, 17 Dec 2006 17:50:44 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBHMXQOa012623; Sun, 17 Dec 2006 15:33:26 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBHMXQJq012622; Sun, 17 Dec 2006 15:33:26 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mtaout01-winn.ispmail.ntl.com (mtaout01-winn.ispmail.ntl.com [81.103.221.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBHMXKsn012608 for ; Sun, 17 Dec 2006 15:33:25 -0700 (MST) (envelope-from djpowell@djpowell.net) Received: from aamtaout02-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com with ESMTP id <20061217223318.CCAY15018.mtaout01-winn.ispmail.ntl.com@aamtaout02-winn.ispmail.ntl.com>; Sun, 17 Dec 2006 22:33:18 +0000 Received: from cpc1-stok1-0-0-cust704.bagu.cable.ntl.com ([86.4.230.193]) by aamtaout02-winn.ispmail.ntl.com with ESMTP id <20061217223318.KZBS17393.aamtaout02-winn.ispmail.ntl.com@cpc1-stok1-0-0-cust704.bagu.cable.ntl.com>; Sun, 17 Dec 2006 22:33:18 +0000 Date: Sun, 17 Dec 2006 22:33:22 +0000 From: David Powell X-Mailer: The Bat! (v3.85.03) Professional X-Priority: 3 (Normal) Message-ID: <146868075.20061217223322@djpowell.net> To: "Bob Wyman" CC: "Lisa Dusseault" , atom-syntax@imc.org, "Bjoern Hoehrmann" , "Karl Dubost" , "Mike Linksvayer" , "Andreas Sewe" , "Thomas Roessler" , "Wendy Seltzer" , "A. Pagaltzis" , "John Panzer" , "Antone Roundy" , "David Powell" , "Robert Sparks" , "James M Snell" Subject: Re: Inheritance of license grants by entries in a feed In-Reply-To: <45be5cd40612161755j997553cv8a728be443b54cbe@mail.gmail.com> References: <45be5cd40612161755j997553cv8a728be443b54cbe@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: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Sunday, December 17, 2006, 1:55:39 AM, Bob Wyman wrote: > 2.3. Inherited Licenses > The license on a feed MAY be inherited by entries. James, I'm not sure exactly what you are trying to achieve with the inheritance rule for licenses, but I think that it could do with the term "feed" being more accurately specified. Whilst it would be very useful for extensions to be able to support inheritance rules like the ones that Atom specifies for atom:author and atom:rights, which cause properties applied to a "feed document" to inherit to the entries declared within the "feed document"; there is nothing in Atom's specification of extensions elements that supports this short-hand notation, and attempting to emulate this behaviour in an extension will cause real-world implementations of feed stores to incorrectly assign, or not assign, licenses to the wrong entries. Simply because Atom implementations tend to give entries and feeds seperate life-cycles, and implementations that maintain a feed-state over multiple pollings of a feed are unlikely to associate each entry with the set of feed document metadata from each of the documents that it occurred in. Eg, if you store a feed in an implementation such as Microsoft's Feed Engine, only a single set of feed extensions will be associated with the feed. This will mean that if you change the license in the feed document when a feed is subsequently polled, intending it only to apply to the entries within that new feed document, you will effectively retroactively apply the license to the old entries too. Atom, unfortunately, doesn't have a way of indicating that an extension applies at "feed document"-level and MUST be processed at the feed document parsing stage. What you can do however, is to specify that feed licenses apply to the "feed", and inherit to the entries in the feed. This behaviour doesn't require implementations to be psychic and guess that an unknown extension needs to be processed at the document parsing stage. It means that the license applies to all entries in that feed, not just ones in that specific feed document. This is probably reasonable behaviour for licenses anyway. This might be your intention, but I'm not clear from the draft. -- Dave From owner-atom-syntax@mail.imc.org Mon Dec 18 01:40:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwCB2-00087l-Po for atompub-archive@lists.ietf.org; Mon, 18 Dec 2006 01:40:44 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwCB1-0004dn-Bu for atompub-archive@lists.ietf.org; Mon, 18 Dec 2006 01:40:44 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBI6N2f5052949; Sun, 17 Dec 2006 23:23:02 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBI6N29J052948; Sun, 17 Dec 2006 23:23:02 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBI6N0FY052937 for ; Sun, 17 Dec 2006 23:23:00 -0700 (MST) (envelope-from karl@w3.org) Received: from [127.0.0.1] (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 3AC8F4F11F; Mon, 18 Dec 2006 01:22:40 -0500 (EST) In-Reply-To: <45be5cd40612161824u6a6b2f20s70e5abae78dd7070@mail.gmail.com> References: <45be5cd40612161824u6a6b2f20s70e5abae78dd7070@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <6AE6663E-A217-4604-B1D0-34B5297D9C43@w3.org> Cc: "Lisa Dusseault" , atom-syntax@imc.org, "Bjoern Hoehrmann" , "Mike Linksvayer" , "Andreas Sewe" , "Thomas Roessler" , "Wendy Seltzer" , "A. Pagaltzis" , "John Panzer" , "Antone Roundy" , "David Powell" , "Robert Sparks" , "James M Snell" From: Karl Dubost Subject: Re: License Draft: Tortured text re obligations... Date: Mon, 18 Dec 2006 15:22:29 +0900 To: Bob Wyman X-Mailer: Apple Mail (2.752.3) X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kBI6N0FY052942 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id kBI6N2f5052949 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Le 17 d=E9c. 2006 =E0 11:24, Bob Wyman a =E9crit : > There is, I think a bit of tortured text in James Snell's otherwise =20 > useful License ID[1]. > 1.3. Terminology bob wyman > > [1] http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-=20 > license-10.txt > +1 --=20 Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager, QA Activity Lead QA Weblog - http://www.w3.org/QA/ *** Be Strict To Be Cool *** From owner-atom-syntax@mail.imc.org Mon Dec 18 04:42:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwF1P-0000x2-LR for atompub-archive@lists.ietf.org; Mon, 18 Dec 2006 04:42:59 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwF1O-0008Tz-7P for atompub-archive@lists.ietf.org; Mon, 18 Dec 2006 04:42:59 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBI9SCXM072975; Mon, 18 Dec 2006 02:28:12 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBI9SCC7072974; Mon, 18 Dec 2006 02:28:12 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBI9SB4n072963; Mon, 18 Dec 2006 02:28:11 -0700 (MST) (envelope-from algermissen1971@mac.com) Received: from mac.com (webmail045-S [10.13.128.45]) by smtpout.mac.com (Xserve/8.12.11/smtpout09/MantshX 4.0) with ESMTP id kBI9S6oH018967; Mon, 18 Dec 2006 01:28:09 -0800 (PST) Received: from webmail045 (localhost [127.0.0.1]) by mac.com (8.13.8/webmail045/MantshX 4.0) with ESMTP id kBI9S5l6025774; Mon, 18 Dec 2006 01:28:05 -0800 (PST) Date: Mon, 18 Dec 2006 01:28:04 -0800 From: Jan Algermissen To: Bob Wyman Cc: Atom , atom-protocol Protocol Message-ID: in-reply-to: <45be5cd40612171337i175ed046rd26ab0687477a8db@mail.gmail.com> references: <8BD53B7C-5B43-4F2D-8DC5-0281CCB84B84@commerce.net> <3f1451f50612070836h45091080k851cece2198c464a@mail.gmail.com> <4582C9BC.8010704@sun.com> <057641F2-0976-45BD-A8B3-497475F50951@commerce.net> <20061217021305.GN13961@klangraum> <45be5cd40612171337i175ed046rd26ab0687477a8db@mail.gmail.com> Subject: Re: AD Evaluation of draft-ietf-atompub-protocol-11 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 193.7.250.35 Received: from [193.7.250.35] from webmail.mac.com with HTTP; Mon, 18 Dec 2006 01:28:04 -0800 X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.6 (+) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 On Sunday, December 17, 2006, at 11:02PM, "Bob Wyman" wrote: >It is important to remember that not all processors of Atom data will know >what to do with unexpected metadata in the envelope. Thus, unexpected >envelope fields will often simply be stripped off and thrown to the bit >bucket. If you want data to stay with your "content," it is best to put it >in the ... Sometimes, it may be appropriate to extend the >envelope, however, one should not do so without a really compelling case. I think the distinction to make is whether the information in question is necessary for whatever process the entries participate in. Processes should be able to work with the entries without having to dig into the actual content. Jan > >Envelope extensions typically require "fetching time" or database structure >modifications in consuming applications if those extensions are to be >supported. This is because many feed consumers have distinct fields in their >databases or internal structures for each of the envelope elements and then >just have a single field for content. Also, the code for manipulating >envelope fields is usually distinctly different from the code used to >manipulate and process . So, if you create a new envelope field, >you require a great deal of code to be modified for that field to be >supported. On the other hand, if something can be slipped into >you'll see it being stored immediately and have the opportunity for >downstream consumers (display routines, etc.) to provide support for the >additional data. (For instance, you might write a GreaseMonkey script to do >interesting things with stuff encoded in even though the >"backend" of the application knows nothing about it.) > >My personal feeling is that many of the proposals (but not all) for envelope >extensions are derived from what I consider to be unfortunate precedent set >in the RSS world where all sorts of random stuff has been pushed into the >envelope since in RSS the field is so under-specified that it >isn't really possible to think of it as something which can be structured. >Fortunately, the field has moved forward since legacy RSS was defined and >we've got better methods that can be used with Atom. There are undoubtedly >still things that might go in the envelope, but not as many as some folk >might think. > >bob wyman > From owner-atom-syntax@mail.imc.org Mon Dec 18 17:49:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwRIs-0002j6-UO for atompub-archive@lists.ietf.org; Mon, 18 Dec 2006 17:49:50 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwRIs-0002pT-1w for atompub-archive@lists.ietf.org; Mon, 18 Dec 2006 17:49:50 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBIMMMou068925; Mon, 18 Dec 2006 15:22:22 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBIMMMGS068924; Mon, 18 Dec 2006 15:22:22 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.239]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBIMMIkE068907 for ; Mon, 18 Dec 2006 15:22:18 -0700 (MST) (envelope-from bobwyman@gmail.com) Received: by wx-out-0506.google.com with SMTP id i30so1395819wxd for ; Mon, 18 Dec 2006 14:22:17 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=YWtjxgErw03oj4hyUfgNn1i6BXl1O4ZonXGNuRN4vRiMD9s4AamAABYUfQD0vZKi9hhkFoZHz1sQXbuny8mki/WmdPx0nQ6oiRwzhgMVfndMoJjzRJY9hE9Jo0zqhUsgvW8trWWULLF4Xo2NHXaHrCJk+AAUyakqeDw5+XqU+KA= Received: by 10.90.69.8 with SMTP id r8mr4467385aga.1166480537677; Mon, 18 Dec 2006 14:22:17 -0800 (PST) Received: by 10.90.90.12 with HTTP; Mon, 18 Dec 2006 14:22:17 -0800 (PST) Message-ID: <45be5cd40612181422r134f6d70k648f30db3cbafee2@mail.gmail.com> Date: Mon, 18 Dec 2006 17:22:17 -0500 From: "Bob Wyman" To: "David Powell" Subject: Re: Inheritance of license grants by entries in a feed Cc: "Lisa Dusseault" , atom-syntax@imc.org, "Bjoern Hoehrmann" , "Karl Dubost" , "Mike Linksvayer" , "Andreas Sewe" , "Thomas Roessler" , "Wendy Seltzer" , "A. Pagaltzis" , "John Panzer" , "Antone Roundy" , "Robert Sparks" , "James M Snell" In-Reply-To: <146868075.20061217223322@djpowell.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_19909_24547758.1166480537639" References: <45be5cd40612161755j997553cv8a728be443b54cbe@mail.gmail.com> <146868075.20061217223322@djpowell.net> X-Google-Sender-Auth: cb3dc68b54afb304 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.3 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f ------=_Part_19909_24547758.1166480537639 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 12/17/06, David Powell wrote: > > What you can do however, is to specify that feed licenses apply to the > "feed", and inherit to the entries in the feed. ... It > means that the license applies to all entries in that feed, not just > ones in that specific feed document. This is probably reasonable > behaviour for licenses anyway. > Particularly in the case of licenses, it is very important to distinguish between the "feed" or stream of all entries (past, present and future) associated with a feed id and the actual feed documents that encapsulate subsets of that stream. Atom provides no mechanism for associating meta-data with "feeds." Atom only supports associating meta-data with Feed Documents. Data in one feed document does not apply to entries found in another feed document -- or to entries that stand-alone. Feed meta-data found in one feed document does not override, compliment or invalidate feed meta-data found in other feed documents. This is one of the many reasons we have atom:source -- so that we can bind specific feed meta-data to an entry no matter what context in which that entry might appear or when it might be read. If we had a case where data in one feed document overrides data in other feed documents, we'd have a mess. Some of the questions that we'd have to answer are: - Elements like atom:author, atom:contributor and atom:rights can and do change over time -- sometimes frequently. If such a change occurs, does it mean that we've implied a change to all previous entries published in all previously published feed documents? This rule would tend to force us to create new feeds (i.e. new feed ids) whenever authors, contributors, or rights change. This would make a mess for aggregators and feed readers who have enough trouble keeping up with changes in the syndisphere... - If data is present in one feed doc but not another later document, does the absence of the data in the later document override the previous document or do we combine what we know from both documents? (i.e. if the earlier Feed document had an atom:contributor field but a later Feed Document does not, does this mean that we wipe out knowledge of the contributor who might have been essential to creating some of the earlier entries? (That's kind of heartless -- it would be a high tech version of "What have you done for me lately?...") Or, do we improperly maintain the old contributor as a contributor of new entries --potentially long after the contributor has died?) - How do we handle mistakes? For instance, if after publishing several thousand feed documents in sequence, I might publish one that accidentally grants "all rights to everyone" when I really meant to grant only "non-commercial" rights. Does the new badly coded feed document force all of the thousands of entries I've been working on over time into the public domain even if that wasn't what I intended? - How do I "repair" the mistake discussed immediately above? If I publish a new feed document with a license grant for "non-commercial use," does that then apply to all previously published entries -- including those that were accidentally published with over-generous rights? Does this mean that I can use a license in one feed document to *restrict* or rescind rights granted by another feed document? (This would be a very bad thing...) - If I have an aggregator that picks up some content which is licensed for general use today, how can I be sure that I can still use the content tomorrow? If the content of a Feed Document applies retroactively, it would seem that I have to re-fetch the feed every time I use content from the feed so that I can check the metadata. This doesn't seem to make sense. If I were sued by someone, could I use the argument: "But, I didn't read the new, more restrictive Feed Documents!" Is ignorance an excuse? I could go on...But, I hope the case is made. Feed Documents only describe themselves and the entries they contain. They do not "describe" the feed. > if you store a feed in an implementation such as > Microsoft's Feed Engine, only a single set of feed > extensions will be associated with the feed. While it is important to be aware of the inadequacies (as well as the strengths) of implementations by companies with significant market power, I don't think that we can simply delegate the standards writing process to such companies or modify standards to cover up their bugs. The fact that Microsoft or any other company has done the wrong thing should not, in itself, be sufficient to dictate the development of standards. Hopefully, they will eventually see the error in their ways and correct them. bob wyman ------=_Part_19909_24547758.1166480537639 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 12/17/06, David Powell <djpowell@djpowell.net> wrote:
What you can do however, is to specify that feed licenses apply to the
&= quot;feed", and inherit to the entries in the feed. ... It
means th= at the license applies to all entries in that feed, not just
ones in that specific feed document. This is probably reason= able
behaviour for licenses anyway.

Particular= ly in the case of licenses, it is very important to distinguish between the= "feed" or stream of all entries (past, present and future) assoc= iated with a feed id and the actual feed documents that encapsulate subsets= of that stream. Atom provides no mechanism for associating meta-data with = "feeds." Atom only supports associating meta-data with Feed Docum= ents. Data in one feed document does not apply to entries found in another = feed document -- or to entries that stand-alone. Feed meta-data found in on= e feed document does not override, compliment or invalidate feed meta-data = found in other feed documents. This is one of the many reasons we have atom= :source -- so that we can bind specific feed meta-data to an entry no matte= r what context in which that entry might appear or when it might be read.

If we had a case where data in one feed document overrides data in = other feed documents, we'd have a mess. Some of the questions that we&#= 39;d have to answer are:
  • Elements like atom:author, atom:contrib= utor and atom:rights can and do change over time -- sometimes frequently. I= f such a change occurs, does it mean that we've implied a change to all= previous entries published in all previously published feed documents? Thi= s rule would tend to force us to create new feeds ( i.e. new feed ids) whenever authors, contributors, or rights change. This w= ould make a mess for aggregators and feed readers who have enough trouble k= eeping up with changes in the syndisphere...
  • If data is present in one feed doc but not another later document, does the absence of the data in the later document override the previous document or do we combine what we know from both documents? (i.e. = if the earlier Feed document had an atom:contributor field but a later Feed= Document does not, does this mean that we wipe out knowledge of the contri= butor who might have been essential to creating some of the earlier entries= ? (That's kind of heartless -- it would be a high tech version of "= ;What have you done for me lately?...") Or, do we improperly maintain = the old contributor as a contributor of new entries --potentially long afte= r the contributor has died?)
  • How do we handle mistakes? For instance, if after publishing sever= al thousand feed documents in sequence, I might publish one that accidental= ly grants "all rights to everyone" when I really meant to grant o= nly "non-commercial" rights. Does the new badly coded feed docume= nt force all of the thousands of entries I've been working on over time= into the public domain even if that wasn't what I intended?
  • How do I "repair" the mistake discussed immediately abov= e? If I publish a new feed document with a license grant for "non-comm= ercial use," does that then apply to all previously published entries = -- including those that were accidentally published with over-generous righ= ts? Does this mean that I can use a license in one feed document to *restri= ct* or rescind rights granted by another feed document? (This would be a=20 very bad thing...)
  • If I have an aggregator that picks up some content which is licens= ed for general use today, how can I be sure that I can still use the conten= t tomorrow? If the content of a Feed Document applies retroactively, it wou= ld seem that I have to re-fetch the feed every time I use content from the = feed so that I can check the metadata. This doesn't seem to make sense.= If I were sued by someone, could I use the argument: "But, I didn'= ;t read the new, more restrictive Feed Documents!" Is ignorance an exc= use?=20
I could go on...But, I hope the case is made. Feed Documents only= describe themselves and the entries they contain. They do not "descri= be" the feed.

> if you store a feed in an implementation suc= h as
> Microsoft's Feed Engine, only a single set of feed
> ext= ensions will be associated with the feed.

While it is important to b= e aware of the inadequacies (as well as the strengths) of implementations b= y companies with significant market power, I don't think that we can si= mply delegate the standards writing process to such companies or modify sta= ndards to cover up their bugs. The fact that Microsoft or any other company= has done the wrong thing should not, in itself, be sufficient to dictate t= he development of standards. Hopefully, they will eventually see the error = in their ways and correct them.=20

bob wyman

------=_Part_19909_24547758.1166480537639-- From owner-atom-syntax@mail.imc.org Tue Dec 19 15:47:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwlrn-0002XL-Ed for atompub-archive@lists.ietf.org; Tue, 19 Dec 2006 15:47:15 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gwlrk-00078s-UK for atompub-archive@lists.ietf.org; Tue, 19 Dec 2006 15:47:15 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBJKRF5p021195; Tue, 19 Dec 2006 13:27:15 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBJKRFS1021194; Tue, 19 Dec 2006 13:27:15 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBJKRCFe021184 for ; Tue, 19 Dec 2006 13:27:15 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by an-out-0708.google.com with SMTP id d33so562282and for ; Tue, 19 Dec 2006 12:27:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=dmr0iS2KiYB8Zn493xRtrLM6KjMwq/ViDYSDKHCBkouOe/zfrEqOWTkEwmJqugMkvt9beZQKvyjrKiF+lqCzJ/kkVtkUqGmvijWuGEBtffUGmv5zadSOadVGMcEq+svUEXNW9WMjrhlXjpvDv/Kov7ZsqaXBRZIhs6EjgPenYN8= Received: by 10.100.140.6 with SMTP id n6mr4771000and.1166560032346; Tue, 19 Dec 2006 12:27:12 -0800 (PST) Received: from ?192.168.1.109? ( [67.181.218.96]) by mx.google.com with ESMTP id 38sm22249537wrl.2006.12.19.12.27.10; Tue, 19 Dec 2006 12:27:11 -0800 (PST) Message-ID: <45884B1B.9060209@gmail.com> Date: Tue, 19 Dec 2006 12:27:07 -0800 From: James M Snell User-Agent: Thunderbird 1.5.0.8 (X11/20061115) MIME-Version: 1.0 To: atom-syntax Subject: Re: Atom Entry docs References: <457F30B7.1020100@sun.com> <45be5cd40612132023t76f58abcnf5426a2ef7c1320d@mail.gmail.com> <45818321.5080908@sun.com> In-Reply-To: <45818321.5080908@sun.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Ok, so we've had more than just a few people put up their hands and say "what Bob said". This week I'll go ahead write up an initial draft of this using the type param option while we wait for the co-chairs to do their hasty consensus grab :-) - James Tim Bray wrote: > [snip] > In case you haven't noticed, the WG is hopelessly split > between the new-media-type option and the media-type-parameter option. > If a few people were to put up their hands and say "yeah what Bob said" > your co-chairs would probably do a hasty consensus grab. > [snip] From owner-atom-syntax@mail.imc.org Tue Dec 19 16:47:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwmoK-0002Kl-9f for atompub-archive@lists.ietf.org; Tue, 19 Dec 2006 16:47:44 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwmoF-0002ye-Rt for atompub-archive@lists.ietf.org; Tue, 19 Dec 2006 16:47:44 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBJLSOjH029488; Tue, 19 Dec 2006 14:28:24 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBJLSOPM029487; Tue, 19 Dec 2006 14:28:24 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from csmtp1.b-one.net (csmtp.b-one.net [195.47.247.21]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBJLSNOX029479 for ; Tue, 19 Dec 2006 14:28:24 -0700 (MST) (envelope-from asbjorn@tigerstaden.no) Received: from quark (72.84-48-117.nextgentel.com [84.48.117.72]) by csmtp1.b-one.net (Postfix) with ESMTP id 527D91911514C; Tue, 19 Dec 2006 22:28:22 +0100 (CET) To: "James M Snell" , atom-syntax Subject: Re: Atom Entry docs From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <457F30B7.1020100@sun.com> <45be5cd40612132023t76f58abcnf5426a2ef7c1320d@mail.gmail.com> <45818321.5080908@sun.com> <45884B1B.9060209@gmail.com> Date: Tue, 19 Dec 2006 22:31:00 +0100 Message-ID: In-Reply-To: <45884B1B.9060209@gmail.com> User-Agent: Opera Mail/9.10 (Win32) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id kBJLSOjH029488 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c On Tue, 19 Dec 2006 21:27:07 +0100, James M Snell =20 wrote: > Ok, so we've had more than just a few people put up their hands and say > "what Bob said". This week I'll go ahead write up an initial draft of > this using the type param option while we wait for the co-chairs to do > their hasty consensus grab :-) =ABWhat James said.=BB ;) --=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 Fri Dec 22 12:57:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxoeD-0001ED-LR for atompub-archive@lists.ietf.org; Fri, 22 Dec 2006 12:57:33 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxoeC-0001LS-2E for atompub-archive@lists.ietf.org; Fri, 22 Dec 2006 12:57:33 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBMHcefX086251; Fri, 22 Dec 2006 10:38:40 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBMHceC6086250; Fri, 22 Dec 2006 10:38:40 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBMHcdNb086242 for ; Fri, 22 Dec 2006 10:38:39 -0700 (MST) (envelope-from foolistbar@googlemail.com) Received: by an-out-0708.google.com with SMTP id d33so844308and for ; Fri, 22 Dec 2006 09:38:38 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:mime-version:content-transfer-encoding:message-id:content-type:to:from:subject:date:x-mailer; b=AbZd5cgYdbkK3Gonh+KL7AS5ekGNDQbkYOLl4CMs4um9IW+wkRIwk/AyzcTgxV4rk1ubz8rpUDt9OFgKKh9Iogw6QGEkKWT58nRGG/ZqRsM4DQuY1zjTxpDDBVXjw/VkNuz8U90Yp2i1SLx2yvI1PlWNplCe10aPHsQhS8EcL6k= Received: by 10.100.9.19 with SMTP id 19mr7699121ani.1166809118356; Fri, 22 Dec 2006 09:38:38 -0800 (PST) Received: from ?192.168.0.7? ( [86.139.123.225]) by mx.google.com with ESMTP id c39sm13533250anc.2006.12.22.09.38.37; Fri, 22 Dec 2006 09:38:37 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: atom-syntax From: Geoffrey Sneddon Subject: within HTML content Date: Fri, 22 Dec 2006 17:38:33 +0000 X-Mailer: Apple Mail (2.752.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 If we come across something like: "Test Link]] >", I assume the link should point to , due to the element? I assume, likewise, that would take precedence over xml:base, as it is directly within the content. - Geoffrey Sneddon From owner-atom-syntax@mail.imc.org Fri Dec 22 14:44:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxqJR-0001Eq-Uf for atompub-archive@lists.ietf.org; Fri, 22 Dec 2006 14:44:13 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxqJP-0002Sv-9s for atompub-archive@lists.ietf.org; Fri, 22 Dec 2006 14:44:13 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBMJR0XA015194; Fri, 22 Dec 2006 12:27:00 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBMJR01g015193; Fri, 22 Dec 2006 12:27:00 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bay0-omc3-s18.bay0.hotmail.com (bay0-omc3-s18.bay0.hotmail.com [65.54.246.218]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBMJQw5W015184 for ; Fri, 22 Dec 2006 12:26:59 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from hotmail.com ([207.46.9.147]) by bay0-omc3-s18.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Fri, 22 Dec 2006 11:26:58 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 22 Dec 2006 11:26:57 -0800 Message-ID: Received: from 81.179.129.31 by BAY120-DAV9.phx.gbl with DAV; Fri, 22 Dec 2006 19:26:54 +0000 X-Originating-IP: [81.179.129.31] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: "atom-syntax" References: Subject: Re: within HTML content Date: Fri, 22 Dec 2006 19:28:54 -0000 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.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-OriginalArrivalTime: 22 Dec 2006 19:26:57.0982 (UTC) FILETIME=[2586ADE0:01C725FF] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 3.0 (+++) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Geoffrey Sneddon wrote: > If we come across something like: " [Test Link]] > >", I assume the link should point to example.com/test.html>, due to the element? Not necessarily. The base element should only appear in the head section of an HTML document, so it's not actually valid in an HTML fragment like this. I suppose you could support it if you wanted to, but I don't think you'd be wrong to ignore it. Regards James From owner-atom-syntax@mail.imc.org Wed Dec 27 16:14:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gzg65-0008F6-Vg for atompub-archive@lists.ietf.org; Wed, 27 Dec 2006 16:14:01 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gzg64-0004zs-FX for atompub-archive@lists.ietf.org; Wed, 27 Dec 2006 16:14:01 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBRKo7Q7031842; Wed, 27 Dec 2006 13:50:07 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBRKo7BQ031841; Wed, 27 Dec 2006 13:50:07 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ns3.neustar.com (ns3.neustar.com [156.154.24.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBRKo5vP031824 for ; Wed, 27 Dec 2006 13:50:07 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 8F02C175F7; Wed, 27 Dec 2006 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gzfis-0004UO-4C; Wed, 27 Dec 2006 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: atom-syntax@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-atompub-protocol-12.txt Message-Id: Date: Wed, 27 Dec 2006 15:50:02 -0500 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.3 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 --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 Publishing Protocol Author(s) : B. de Hora, J. Gregorio Filename : draft-ietf-atompub-protocol-12.txt Pages : 57 Date : 2006-12-27 The Atom Publishing Protocol (APP) is an application-level protocol for publishing and editing Web resources. The protocol is based on HTTP transport of Atom-formatted representations. The Atom format is documented in the Atom Syndication Format [RFC4287]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-12.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-protocol-12.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-protocol-12.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: <2006-12-27123059.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-atompub-protocol-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-atompub-protocol-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-12-27123059.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-atom-syntax@mail.imc.org Sat Dec 30 03:15:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0ZN0-00057z-Cj for atompub-archive@lists.ietf.org; Sat, 30 Dec 2006 03:15:10 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0ZMw-0007Ax-Lr for atompub-archive@lists.ietf.org; Sat, 30 Dec 2006 03:15:10 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBU7qpbj012667; Sat, 30 Dec 2006 00:52:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBU7qp9x012666; Sat, 30 Dec 2006 00:52:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bay0-omc3-s1.bay0.hotmail.com (bay0-omc3-s1.bay0.hotmail.com [65.54.246.201]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBU7qplx012660 for ; Sat, 30 Dec 2006 00:52:51 -0700 (MST) (envelope-from peaceable_whale@hotmail.com) Received: from hotmail.com ([207.46.8.26]) by bay0-omc3-s1.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Fri, 29 Dec 2006 23:52:50 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 29 Dec 2006 23:52:50 -0800 Message-ID: Received: from 61.238.43.155 by BAY117-DAV16.phx.gbl with DAV; Sat, 30 Dec 2006 07:52:45 +0000 X-Originating-IP: [61.238.43.155] X-Originating-Email: [peaceable_whale@hotmail.com] X-Sender: peaceable_whale@hotmail.com From: "Franklin Tse" To: "'atom-syntax'" Subject: Text-type contents and White Space Date: Sat, 30 Dec 2006 15:52:40 +0800 Message-ID: <000201c72be7$7b1ebc00$715c3400$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Accr5bivL5zTiS0GTsWfRKQVSMoj3w== Content-Language: zh-hk x-cr-hashedpuzzle: AwRa A0sh BwOQ CgKS DdjC E+Ra FQ6Z Feq8 F6sm GCGM GNo6 GQ09 HpI1 JQr5 KhNZ K8P/;1;YQB0AG8AbQAtAHMAeQBuAHQAYQB4AEAAaQBtAGMALgBvAHIAZwA=;Sosha1_v1;7;{E9FF2E95-4C7B-4FAB-88FB-21DF47478ACE};cABlAGEAYwBlAGEAYgBsAGUAXwB3AGgAYQBsAGUAQABoAG8AdABtAGEAaQBsAC4AYwBvAG0A;Sat, 30 Dec 2006 07:40:05 GMT;VABlAHgAdAAtAHQAeQBwAGUAIABjAG8AbgB0AGUAbgB0AHMAIABhAG4AZAAgAFcAaABpAHQAZQAgAFMAcABhAGMAZQA= x-cr-puzzleid: {E9FF2E95-4C7B-4FAB-88FB-21DF47478ACE} X-OriginalArrivalTime: 30 Dec 2006 07:52:50.0274 (UTC) FILETIME=[80DCC420:01C72BE7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kBU7qplx012661 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 In Section 3.1.1.1. of RFC 4287, If the value is "text", the content of the Text construct MUST NOT contain child elements. Such text is intended to be presented to humans in a readable fashion. Thus, Atom Processors MAY collapse white space (including line breaks) and display the text using typographic techniques such as justification and proportional fonts. However, white space in some text contents cannot be collapsed. Otherwise, the contents will be broken. Since xml:space is not defined in RFC 4287 (although it has been defined in the XML 1.0 Specification), it seems not valid to use it in an Atom feed (Am I correct?). The current method to stop the white space being collapsed is to use the 
 of HTML/XHTML.


123
  White space here should be preserved
    456
]]> My question is, can xml:space="preserve" be used? If yes, can it be added into RFC 4287 as if xml:base and xml:lang? 123 White space here should be preserved 456 Thanks, Franklin Tse From owner-atom-syntax@mail.imc.org Sat Dec 30 04:57:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0axd-0003l5-Rn for atompub-archive@lists.ietf.org; Sat, 30 Dec 2006 04:57:06 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0au3-00042V-9p for atompub-archive@lists.ietf.org; Sat, 30 Dec 2006 04:53:28 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBU9XtPv021949; Sat, 30 Dec 2006 02:33:55 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBU9XtIx021948; Sat, 30 Dec 2006 02:33:55 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id kBU9Xr0w021940 for ; Sat, 30 Dec 2006 02:33:54 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 30 Dec 2006 09:33:52 -0000 Received: from xdsl-87-79-236-202.netcologne.de (EHLO klangraum) [87.79.236.202] by mail.gmx.net (mp047) with SMTP; 30 Dec 2006 10:33:52 +0100 X-Authenticated: #163624 Date: Sat, 30 Dec 2006 10:33:52 +0100 From: "A. Pagaltzis" To: "'atom-syntax'" Subject: Re: Text-type contents and White Space Message-ID: <20061230093352.GW10523@klangraum> Mail-Followup-To: 'atom-syntax' References: <000201c72be7$7b1ebc00$715c3400$@com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000201c72be7$7b1ebc00$715c3400$@com> User-Agent: Mutt/1.4.2.1i Organization: haphazard X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab * Franklin Tse [2006-12-30 09:10]: > In Section 3.1.1.1. of RFC 4287, > > If the value is "text", the content of the Text construct > MUST NOT contain child elements. Such text is intended to be > presented to humans in a readable fashion. Thus, Atom > Processors MAY collapse white space (including line breaks) > and display the text using typographic techniques such as > justification and proportional fonts. > > However, white space in some text contents cannot be collapsed. > Otherwise, the contents will be broken. Use `type="text/plain"`. The `text` type is intended for limited amounts of inline content that can be rendered in menus, lists and the like, not for substantive amounts of content. Regards, -- Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Sat Dec 30 05:19:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0bJO-0001ut-9a for atompub-archive@lists.ietf.org; Sat, 30 Dec 2006 05:19:34 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0bJJ-0001fX-OO for atompub-archive@lists.ietf.org; Sat, 30 Dec 2006 05:19:34 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBUA3xFO024669; Sat, 30 Dec 2006 03:04:00 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBUA3xC8024668; Sat, 30 Dec 2006 03:03:59 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bay0-omc1-s39.bay0.hotmail.com (bay0-omc1-s39.bay0.hotmail.com [65.54.246.111]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBUA3w8V024661 for ; Sat, 30 Dec 2006 03:03:59 -0700 (MST) (envelope-from peaceable_whale@hotmail.com) Received: from hotmail.com ([207.46.8.87]) by bay0-omc1-s39.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sat, 30 Dec 2006 02:03:58 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 30 Dec 2006 02:03:58 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Sat, 30 Dec 2006 10:03:56 GMT X-Originating-IP: [61.238.43.155] X-Originating-Email: [peaceable_whale@hotmail.com] X-Sender: peaceable_whale@hotmail.com In-Reply-To: <20061230093352.GW10523@klangraum> From: "Franklin Tse" To: pagaltzis@gmx.de Cc: atom-syntax@imc.org Subject: Re: Text-type contents and White Space Date: Sat, 30 Dec 2006 18:03:56 +0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 30 Dec 2006 10:03:58.0117 (UTC) FILETIME=[D2765550:01C72BF9] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 IE and Firefox both failed to display text/plain contents. Opera can but all white space was collasped Franklin >From: "A. Pagaltzis" >To: "'atom-syntax'" >Subject: Re: Text-type contents and White Space >Date: Sat, 30 Dec 2006 10:33:52 +0100 >MIME-Version: 1.0 >Received: from balder-227.proper.com ([192.245.12.227]) by >bay0-mc10-f16.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2444); Sat, >30 Dec 2006 01:43:48 -0800 >Received: from balder-227.proper.com (localhost [127.0.0.1])by >balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBU9XtPv021949;Sat, 30 >Dec 2006 02:33:55 -0700 (MST)(envelope-from owner-atom-syntax@mail.imc.org) >Received: (from majordom@localhost)by balder-227.proper.com >(8.13.5/8.13.5/Submit) id kBU9XtIx021948;Sat, 30 Dec 2006 02:33:55 -0700 >(MST)(envelope-from owner-atom-syntax@mail.imc.org) >Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])by >balder-227.proper.com (8.13.5/8.13.5) with SMTP id kBU9Xr0w021940for >; Sat, 30 Dec 2006 02:33:54 -0700 (MST)(envelope-from >pagaltzis@gmx.de) >Received: (qmail invoked by alias); 30 Dec 2006 09:33:52 -0000 >Received: from xdsl-87-79-236-202.netcologne.de (EHLO klangraum) >[87.79.236.202] by mail.gmx.net (mp047) with SMTP; 30 Dec 2006 10:33:52 >+0100 >X-Message-Info: LsUYwwHHNt0EcBwwqClCjv7fVvdFoPaZ6Bo4rp+I6+M= >X-Authentication-Warning: balder-227.proper.com: majordom set sender to >owner-atom-syntax@mail.imc.org using -f >X-Authenticated: #163624 >Mail-Followup-To: 'atom-syntax' >References: <000201c72be7$7b1ebc00$715c3400$@com> >User-Agent: Mutt/1.4.2.1i >Organization: haphazard >X-Y-GMX-Trusted: 0 >Precedence: bulk >List-Archive: >List-Unsubscribe: >List-ID: >Return-Path: owner-atom-syntax@mail.imc.org >X-OriginalArrivalTime: 30 Dec 2006 09:43:48.0743 (UTC) >FILETIME=[019E8170:01C72BF7] > > >* Franklin Tse [2006-12-30 09:10]: > > In Section 3.1.1.1. of RFC 4287, > > > > If the value is "text", the content of the Text construct > > MUST NOT contain child elements. Such text is intended to be > > presented to humans in a readable fashion. Thus, Atom > > Processors MAY collapse white space (including line breaks) > > and display the text using typographic techniques such as > > justification and proportional fonts. > > > > However, white space in some text contents cannot be collapsed. > > Otherwise, the contents will be broken. > >Use `type="text/plain"`. The `text` type is intended for limited >amounts of inline content that can be rendered in menus, lists >and the like, not for substantive amounts of content. > >Regards, >-- >Aristotle Pagaltzis // > _________________________________________________________________ Learn English via Shopping Game, FREE! http://www.linguaphonenet.com/BannerTrack.asp?EMSCode=MSN06-03ETFJ-0211E From owner-atom-syntax@mail.imc.org Sat Dec 30 05:47:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0bkg-0002MI-N1 for atompub-archive@lists.ietf.org; Sat, 30 Dec 2006 05:47:46 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0bkc-0000ty-AD for atompub-archive@lists.ietf.org; Sat, 30 Dec 2006 05:47:46 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBUATDiH026661; Sat, 30 Dec 2006 03:29:13 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBUATD91026660; Sat, 30 Dec 2006 03:29:13 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sam.opera.com (sam.opera.com [193.69.113.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBUATBEe026654 for ; Sat, 30 Dec 2006 03:29:12 -0700 (MST) (envelope-from annevk@opera.com) Received: from id-c0020 (ip565a461c.direct-adsl.nl [86.90.70.28] (may be forged)) (authenticated bits=0) by sam.opera.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id kBUAT2E6000578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 30 Dec 2006 10:29:03 GMT To: "Franklin Tse" , pagaltzis@gmx.de Subject: Re: Text-type contents and White Space From: "Anne van Kesteren" Organization: Opera Software Cc: atom-syntax@imc.org Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: Content-Transfer-Encoding: 7bit Date: Sat, 30 Dec 2006 11:29:01 +0100 Message-ID: In-Reply-To: User-Agent: Opera Mail/9.02 (Win32) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 On Sat, 30 Dec 2006 11:03:56 +0100, Franklin Tse wrote: > IE and Firefox both failed to display text/plain contents. Opera can but > all white space was collasped I suppose that's something we should fix then. * files a bug report. -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Sat Dec 30 05:47:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0bkg-0002MR-O4 for atompub-archive@lists.ietf.org; Sat, 30 Dec 2006 05:47:46 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0bkf-0000uo-8Y for atompub-archive@lists.ietf.org; Sat, 30 Dec 2006 05:47:46 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBUAXZrA026899; Sat, 30 Dec 2006 03:33:35 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBUAXZpW026898; Sat, 30 Dec 2006 03:33:35 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bay0-omc1-s3.bay0.hotmail.com (bay0-omc1-s3.bay0.hotmail.com [65.54.246.75]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBUAXXLG026892 for ; Sat, 30 Dec 2006 03:33:34 -0700 (MST) (envelope-from peaceable_whale@hotmail.com) Received: from hotmail.com ([207.46.8.98]) by bay0-omc1-s3.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sat, 30 Dec 2006 02:33:33 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 30 Dec 2006 02:33:33 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Sat, 30 Dec 2006 10:33:32 GMT X-Originating-IP: [61.238.43.155] X-Originating-Email: [peaceable_whale@hotmail.com] X-Sender: peaceable_whale@hotmail.com In-Reply-To: From: "Franklin Tse" To: annevk@opera.com, pagaltzis@gmx.de Cc: atom-syntax@imc.org Subject: Re: Text-type contents and White Space Date: Sat, 30 Dec 2006 18:33:32 +0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 30 Dec 2006 10:33:33.0453 (UTC) FILETIME=[F4A51BD0:01C72BFD] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 I have tested with both and . Both of them are the same. Franklin >From: "Anne van Kesteren" >To: "Franklin Tse" , pagaltzis@gmx.de >CC: atom-syntax@imc.org >Subject: Re: Text-type contents and White Space >Date: Sat, 30 Dec 2006 11:29:01 +0100 >MIME-Version: 1.0 >Received: from sam.opera.com ([193.69.113.81]) by >bay0-mc9-f14.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2444); Sat, >30 Dec 2006 02:29:07 -0800 >Received: from id-c0020 (ip565a461c.direct-adsl.nl [86.90.70.28] (may be >forged))(authenticated bits=0)by sam.opera.com >(8.13.4/8.13.4/Debian-3sarge3) with ESMTP id >kBUAT2E6000578(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 >verify=NOT);Sat, 30 Dec 2006 10:29:03 GMT >X-Message-Info: LsUYwwHHNt3660MmjhEvYg2f34OAemlK3oXsmRrh6gU= >Organization: Opera Software >References: >User-Agent: Opera Mail/9.02 (Win32) >Return-Path: annevk@opera.com >X-OriginalArrivalTime: 30 Dec 2006 10:29:07.0721 (UTC) >FILETIME=[56419F90:01C72BFD] > >On Sat, 30 Dec 2006 11:03:56 +0100, Franklin Tse > wrote: >>IE and Firefox both failed to display text/plain contents. Opera can but >>all white space was collasped > >I suppose that's something we should fix then. > >* files a bug report. > > >-- >Anne van Kesteren > > _________________________________________________________________ Learn English via Shopping Game, FREE! http://www.linguaphonenet.com/BannerTrack.asp?EMSCode=MSN06-03ETFJ-0211E From owner-atom-syntax@mail.imc.org Sat Dec 30 05:49:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0bmb-0002qj-9I for atompub-archive@lists.ietf.org; Sat, 30 Dec 2006 05:49:45 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0bmZ-0001Qb-Rb for atompub-archive@lists.ietf.org; Sat, 30 Dec 2006 05:49:45 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBUAajsj027091; Sat, 30 Dec 2006 03:36:45 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBUAajP3027090; Sat, 30 Dec 2006 03:36:45 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id kBUAafYY027081 for ; Sat, 30 Dec 2006 03:36:43 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 30 Dec 2006 10:36:40 -0000 Received: from xdsl-87-79-236-202.netcologne.de (EHLO klangraum) [87.79.236.202] by mail.gmx.net (mp053) with SMTP; 30 Dec 2006 11:36:40 +0100 X-Authenticated: #163624 Date: Sat, 30 Dec 2006 11:36:40 +0100 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: Text-type contents and White Space Message-ID: <20061230103640.GY10523@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <20061230093352.GW10523@klangraum> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Organization: haphazard X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id kBUAajsj027091 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 * Franklin Tse [2006-12-30 11:05]: > IE and Firefox both failed to display text/plain contents. > Opera can but all white space was collasped Yeah, I suspected that. Of course, none of the support xml:space either, but the semantics of using text/plain are already obvious without having to amend the spec and supporting it should take minimal effort, so I would file bugs. Almost no consumer at this point is prepared to process anything but HTML and inline text since almost everyone just treats Atom as a dialect of RSS 2.0. If you need the interoperability right now, you will have to keep doing what you=E2=80=99re already doing with `type=3D"html"` containing `
` tags.

Regards,
--=20
Aristotle Pagaltzis // 




From owner-atom-syntax@mail.imc.org Sat Dec 30 05:53:30 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H0bqE-0003ku-2y
	for atompub-archive@lists.ietf.org; Sat, 30 Dec 2006 05:53:30 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1H0bqB-0003AA-MA
	for atompub-archive@lists.ietf.org; Sat, 30 Dec 2006 05:53:30 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBUAfjYw027872;
	Sat, 30 Dec 2006 03:41:45 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBUAfj3Z027871;
	Sat, 30 Dec 2006 03:41:45 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from sam.opera.com (sam.opera.com [193.69.113.81])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBUAfih8027865
	for ; Sat, 30 Dec 2006 03:41:44 -0700 (MST)
	(envelope-from annevk@opera.com)
Received: from id-c0020 (ip565a461c.direct-adsl.nl [86.90.70.28] (may be forged))
	(authenticated bits=0)
	by sam.opera.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id kBUAfd0c001107
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Sat, 30 Dec 2006 10:41:40 GMT
To: "Franklin Tse" , pagaltzis@gmx.de
Subject: Re: Text-type contents and White Space
From: "Anne van Kesteren" 
Organization: Opera Software
Cc: atom-syntax@imc.org
Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8
MIME-Version: 1.0
References: 
Date: Sat, 30 Dec 2006 11:41:39 +0100
Message-ID: 
In-Reply-To: 
User-Agent: Opera Mail/9.02 (Win32)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from Quoted-Printable to 8bit by balder-227.proper.com id kBUAfjh8027866
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c


On Sat, 30 Dec 2006 11:33:32 +0100, Franklin Tse  
 wrote:
> I have tested with both  and
> .

I don't think we do anything with xml:space. The definition it has makes  
it kind of pointless I think.


-- 
Anne van Kesteren