Re: Query re: support of Media RSS extensions inside Atom feeds

2007-02-12 Thread Ernest Prabhakar
On Feb 9, 2007, at 9:23 PM, John Panzer wrote: Does anyone know of any issues with placing Yahoo! Media RSS extensions (which seem to fit the requirments for Atom extensions to me) inside an Atom feed? Secondarily A year or two ago there was discussion of doing an IETF working group to

Re: Atom Entry docs what Bob said

2006-12-14 Thread Ernest Prabhakar
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 [EMAIL PROTECTED] wrote: 1) Define ;type=feed and ;type=entry as optional parameters. (i.e. get them defined,

Re: Atom Entry Documents

2006-12-11 Thread Ernest Prabhakar
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,

Re: PaceEntryMediatype - rel-type instead

2006-12-01 Thread Ernest Prabhakar
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

Re: PaceEntryMediatype

2006-12-01 Thread Ernest Prabhakar
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

Re: PaceEntryMediatype - Options

2006-11-30 Thread Ernest Prabhakar
Hi Antoine, On Nov 30, 2006, at 10:21 AM, Antone Roundy wrote: Summary of thoughts and questions: Thanks -- this is incredibly helpful. However, might I suggest a couple more options? 6) Change expectations, not the spec. Consumers must poll the feed to inspect the metadata, and

Re: How to do RESTful SEARCH (was Re: Adding POST capability to atom:link)

2006-11-02 Thread Ernest Prabhakar
A server that instead provides light-weight query interfaces as you describe, or guides the client into the content, does not work with a client that doesn't do HTML (a CalDAV, WebDAV or possibly Atom authoring client); correct?My understanding (for what it is worth) is that REST *requires*

OT Re: [OFF-LIST] Re: Fwd: Link rel test cases [OFF-LIST]

2006-05-31 Thread Ernest Prabhakar
Hi Robert, While I'm not entirely thrilled with James, and I believe you provide some useful perspective, if you think it is appropriate and ethical to respond by posting private email to the list, I must reluctantly conclude that this list is better off without you. Sincerely, Ernest

Re: Feed Thread in Last Call

2006-05-23 Thread Ernest Prabhakar
I've had a hard time following this thread, but for what its worth I buy Tim's reasoning. +1 On May 23, 2006, at 12:26 PM, James M Snell wrote: +1. What Tim said. - James Tim Bray wrote: On May 18, 2006, at 6:15 AM, David Powell wrote: What I see as a problem is that reasonable

Re: Atom, files and directories: what it's all about

2005-11-28 Thread Ernest Prabhakar
Hi Henry, On Nov 23, 2005, at 3:22 AM, Henry Story wrote: A few improvements of atom over directories is that our feed can contain not just the current version of an entry, but all previous versions as well, which I think I remember was a feature supported by the vms file system.