Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists

2005-06-18 Thread Antone Roundy
On Saturday, June 18, 2005, at 06:28 PM, David Powell wrote: Atom 0.3 multiparts forced a dubious and complex processing model on everyone wanting to process Atom documents. This problem was solved by their removal in the 03 to 07 drafts. The prohibition of composite types in the 08 draft (mad

Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists

2005-06-18 Thread Robert Sayre
On 6/18/05, David Powell <[EMAIL PROTECTED]> wrote: > > > Saturday, June 18, 2005, 7:16:50 PM, Tim Bray wrote: > > >>> My feeling was that we ruled out composite types in *local* content > >>> [...] > >>> > >> > >> I'm still looking, but my suspicion is that we never did rule them > >> out, and

Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists

2005-06-18 Thread David Powell
Saturday, June 18, 2005, 4:40:54 PM, Robert Sayre wrote: > Incorrect. Multipart content presents an accessibility issue because > the entry metadata is no longer sufficiently granular. There would > have to be Atom metadata for each part.[0] A message/rfc822 email or an MHTML document with embe

Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists

2005-06-18 Thread David Powell
Saturday, June 18, 2005, 7:16:50 PM, Tim Bray wrote: >>> My feeling was that we ruled out composite types in *local* content >>> [...] >>> >> >> I'm still looking, but my suspicion is that we never did rule them >> out, and that this restriction crept in during some editorial >> rephrasing. > I

Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists

2005-06-18 Thread Antone Roundy
On Saturday, June 18, 2005, at 01:36 PM, Graham wrote: On 17 Jun 2005, at 6:14 pm, Tim Bray wrote: Uh, has Mark spotted a dumb bug here that we should fix? Do we care if *remote* content is of a composite MIME type? My feeling was that we ruled out composite types in *local* content, for fa

Re: question about future

2005-06-18 Thread Tim Bray
On Jun 18, 2005, at 1:15 PM, Domel wrote: How many drafts will you planing to publish to Atom 1.0? That depends on what the IESG says at their meeting of June 23rd. If they say "OK" there will be a last draft to fix some typos and bugs that people have turned up in -09 and include the

question about future

2005-06-18 Thread Domel
How many drafts will you planing to publish to Atom 1.0?

Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists

2005-06-18 Thread Graham
On 17 Jun 2005, at 6:14 pm, Tim Bray wrote: Uh, has Mark spotted a dumb bug here that we should fix? Do we care if *remote* content is of a composite MIME type? My feeling was that we ruled out composite types in *local* content, for fairly obvious reasons. The fix is obvious, in 4.1.3.

Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists

2005-06-18 Thread Tim Bray
On Jun 18, 2005, at 8:00 AM, David Powell wrote: Friday, June 17, 2005, 6:14:38 PM, Tim Bray wrote: My feeling was that we ruled out composite types in *local* content [...] I'm still looking, but my suspicion is that we never did rule them out, and that this restriction crept in during

Re: Polling Sucks! (was RE: Atom feed synchronization)

2005-06-18 Thread Paul Hoffman
At 10:06 PM -0400 6/17/05, Sam Ruby wrote: P.S. Why is this on atom-sytax? Is there a concrete proposal we are talking about here? Is there likely to be? Wearing my co-chair hat: IETF WG mailing lists are normally used for creating specs that are listed in the charter. They are also used

Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists

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

Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists

2005-06-18 Thread Robert Sayre
On 6/18/05, David Powell <[EMAIL PROTECTED]> wrote: > > > Friday, June 17, 2005, 6:14:38 PM, Tim Bray wrote: > > > My feeling was that we ruled out composite types in *local* content > > [...] > > I'm still looking, but my suspicion is that we never did rule them > out, and that this restricti

Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists

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

Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists

2005-06-18 Thread David Powell
Saturday, June 18, 2005, 1:40:52 PM, Sam Ruby wrote: >> Can somebody give me a link to where we discussed the requirement that >> atom:content MUST NOT contain a composite type? I've tried searching my >> archive but I couldn't find anything at all. The change was introduced >> in draft-08. >>

Re: Polling Sucks! (was RE: Atom feed synchronization)

2005-06-18 Thread Sam Ruby
Joe Gregorio wrote: On 6/17/05, Sam Ruby <[EMAIL PROTECTED]> wrote: P.S. Why is this on atom-sytax? Is there a concrete proposal we are talking about here? Is there likely to be? Were you expecting [atom-syntax] to vanish in a puff of smoke once we have a couple RFCs under our belt? Given

Re: Polling Sucks! (was RE: Atom feed synchronization)

2005-06-18 Thread Robert Sayre
On 6/18/05, Joe Gregorio <[EMAIL PROTECTED]> wrote: > > On 6/17/05, Sam Ruby <[EMAIL PROTECTED]> wrote: > > P.S. Why is this on atom-sytax? Is there a concrete proposal we are > > talking about here? Is there likely to be? > > Were you expecting [atom-syntax] to vanish in a puff of smoke > on

Re: Polling Sucks! (was RE: Atom feed synchronization)

2005-06-18 Thread Joe Gregorio
On 6/17/05, Sam Ruby <[EMAIL PROTECTED]> wrote: > P.S. Why is this on atom-sytax? Is there a concrete proposal we are > talking about here? Is there likely to be? Were you expecting [atom-syntax] to vanish in a puff of smoke once we have a couple RFCs under our belt? Given the technology, and

Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists

2005-06-18 Thread Sam Ruby
David Powell wrote: Friday, June 17, 2005, 6:14:38 PM, you wrote: Uh, has Mark spotted a dumb bug here that we should fix? Do we care if *remote* content is of a composite MIME type? My feeling was that we ruled out composite types in *local* content, for fairly obvious reasons. The fix is

Re: first request for an atom extension: Re: Polling Sucks! (was RE: Atom feed synchronization)

2005-06-18 Thread Bill de hÓra
Henry Story wrote: [...] Something like: http://.../next"; href="http://bblfish.net/blog/archive/ 2005-05-10.atom"> would be really useful. Henry, Mark Nottingham did something on this a while back; try digging through the archives. cheers Bill

Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists

2005-06-18 Thread David Powell
Friday, June 17, 2005, 6:14:38 PM, you wrote: > Uh, has Mark spotted a dumb bug here that we should fix? Do we care > if *remote* content is of a composite MIME type? My feeling was that > we ruled out composite types in *local* content, for fairly obvious > reasons. The fix is obvious, in 4.

Re: Polling Sucks! (was RE: Atom feed synchronization)

2005-06-18 Thread Bill de hÓra
Eric Scheid wrote: how does Atom over XMPP help in this scenario: 1) wake up 2) scratch myself, stagger around in morning fog 3) turn on computer, launch feed reader 4) wonder what changes happened during the night This is not the thread you're looking for - go back to bed! cheers Bill

Re: Polling Sucks! (was RE: Atom feed synchronization)

2005-06-18 Thread Bill de hÓra
Bob Wyman wrote: Joe Gregorio wrote: The one thing missing from the analysis is the overhead, and practicality, of switching protocols (HTTP to XMPP). I'm not aware of anything that might be called "overhead." What our clients do is, upon startup, connect to XMPP and request the list

Re: Polling Sucks! (was RE: Atom feed synchronization)

2005-06-18 Thread Bob Wyman
Sam Ruby wrote: P.S. Why is this on atom-sytax? Is there a concrete proposal we are talking about here? Is there likely to be? Because James Snell asked a question?.. But, more seriously: I intend to write an Internet draft for RFC3229+feed and hope that I'll be able to get the workin

Re: Polling Sucks! (was RE: Atom feed synchronization)

2005-06-18 Thread Bob Wyman
James M Snell wrote: If I understand Bob's solution correctly, it goes something like: 1) wake up 2) scratch whatever you need to scratch 3) turn on computer, launch feed reader 4) feed reader does some RFC3229+feed magic to catch up on what happened during the night 5) feed reader opens a XMPP

first request for an atom extension: Re: Polling Sucks! (was RE: Atom feed synchronization)

2005-06-18 Thread Henry Story
This is a good venue. I think XMPP and polling can be explored. But for the needs of BlogEd [1] on which I am working, and for my personal needs, I would really like us to introduce an extension to the link concept, to provide a pointer to the next page in a historically ordered sequence of