Fwd: Last Call: draft-nottingham-atompub-feed-history (Feed Paging and Archiving) to Proposed Standard

FYI --Lisa Begin forwarded message: From: The IESG <[EMAIL PROTECTED]> Date: January 19, 2007 1:07:21 PM PST To: IETF-Announce Subject: Last Call: draft-nottingham-atompub-feed-history (Feed Paging and Archiving) to Proposed Standard Reply-To: ietf@ietf.org The IESG has received a request

Re: AD Evaluation of draft-ietf-atompub-protocol-11

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

Re: Atom Entry Documents

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) mi

Re: AD Evaluation of draft-ietf-atompub-protocol-11

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

Re: PaceEntryMediatype

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 t

Re: In San Francisco/Bay Area

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 th

Re: AD Evaluation of draft-ietf-atompub-protocol-11

On Oct 18, 2006, at 1:04 AM, Sylvain Hellegouarch wrote: My assumption: a client cannot create a media resource without also creating a media link entry.  When I POST a media resource to a collection, a media link entry is *always* created. Same here. Lisa what do you mean by creating a media reso

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

On Oct 26, 2006, at 1:02 PM, Jan Algermissen wrote:If you aim to provide a REST interface, do not mimick a query interface (at least not a complex one). Think of your 'asset space' in terms of pre-defined, useful collections that you expose as resources (feeds) and provide light weight query interf

Re: AD Evaluation -- extensions

the expectation is and perhaps even offer safe ways of violating the expectation. Lisa On Oct 17, 2006, at 4:31 PM, Eric Scheid wrote: On 18/10/06 8:07 AM, "Lisa Dusseault" <[EMAIL PROTECTED]> wrote: Extensions When the client puts extension elements in a MER, MUST the se

Re: Atom Syndication Format To Draft Standard?

The Draft Standard requirement for demonstrated interoperability for all features is documented in RFC2026.  It's that requirement which leads to the popular conclusion that in many cases, adding a new feature is incompatible with moving to Draft Standard at the same time -- that popular conclusion

Re: versioning extension?

On Sep 11, 2006, at 5:20 PM, Tim Bray wrote:Versioning is an issue in almost *every* application. What is so bad about it? In my experience, the semantics of "versioning" are so tightly bound to particular applications that it's really hard to find common threads.  You saw that happen here when w

Fwd: Last Call: 'Atom License Extension' to Experimental RFC (draft-snell-atompub-feed-license)

FYIBegin forwarded message:From: The IESG <[EMAIL PROTECTED]>Date: August 14, 2006 6:35:53 PM PDTTo: IETF-Announce Subject: Last Call: 'Atom License Extension' to Experimental RFC  (draft-snell-atompub-feed-license) Reply-To: iesg@ietf.org The IESG has received a request fro

Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard

concern, one way or another, as well. Lisa On Jul 9, 2006, at 9:43 PM, Robert Sayre wrote: On 7/4/06, Lisa Dusseault <[EMAIL PROTECTED]> wrote: I wrote the synopsis, in which I was careful not to state that it was a WG document. I believe it was accurate for what it said although it's

Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard

I wrote the synopsis, in which I was careful not to state that it was a WG document. I believe it was accurate for what it said although it's very brief. I discussed explicitly with the IESG during the IESG tele-conference calls that there was some lengthy debate and disagreement over c

Re: Feed Thread in Last Call

On May 23, 2006, at 12:16 PM, Tim Bray wrote: On May 18, 2006, at 6:15 AM, David Powell wrote: What I see as a problem is that reasonable implementations will not preserve Atom documents bit-for-bit, so they will need to explicitly support this draft if they don't want to corrupt data by dro

Re: Atompub WG meeting at the Montreal IETF

e making good progress on the publishing protocol. However, there are reasons other than "moving documents forwards" for WGs to meet. Lisa Dusseault, our Area Director, asked us to have a meeting so that people active in the Atompub WG can have more interaction with the IETF, and vice

Re: Informational vs. standards-track for Atom Threading Extensions

On May 17, 2006, at 7:41 PM, Robert Sayre wrote: On 5/18/06, Lisa Dusseault <[EMAIL PROTECTED]> wrote: On May 17, 2006, at 10:02 AM, Robert Sayre wrote: > > Well, you clearly don't think they're important. But then you felt > compelled to change them back an

Re: Feed Thread in Last Call

On May 18, 2006, at 8:56 AM, Robert Sayre wrote: Look at that giant email. Seems to me that it's a debate taking place for no discernable reason. There's no technical reason for the placement of the attributes, and management has made it clear that any objections are "irrelevant." I realize

Fwd: Protocol Action: 'The Base16, Base32, and Base64 Data Encodings' to Proposed Standard

This announcement is for a document that will obsolete RFC3548, which is referenced by a couple APPS area RFCs:  XMPP (RFC3920) and Atom Syntax (RFC4287).There are also a few drafts that reference RFC3548 that caught my eye: - draft-ietf-nntpext-base, which is in RFC ED queue -  draft-josefsson-sas

Re: Atom Rank Extensions: Feedback on r:value and r:range elements wanted (long)

For related work, you could look at the email spam filtering stuff from SIEVE: The similar problem is that many spam libraries already produce some kind of linear or similar scale of severity/likelihood rating for

Re: Informational vs. standards-track for Atom Threading Extensions

On May 17, 2006, at 10:02 AM, Robert Sayre wrote: Well, you clearly don't think they're important. But then you felt compelled to change them back and got an instant stamp of approval from our AD. What happened there? I read this as implying causality between two events. Those two events

Re: Feed Thread in Last Call

On May 16, 2006, at 4:38 PM, Robert Sayre wrote: You're including attributes in that document that you know won't be visible to a large number of implementations. Is there some way that one could write an Atom extension that would have new feed/post information that *would* be visible to

Re: [Fwd: draft-reschke-http-addmember-00]

On Feb 17, 2005, at 4:58 AM, Stefan Eissing wrote: I think What Would Make The World A Better Place is a mechanism that generic clients can discover POST service points where they can persist new entities. There is nothing wrong with POST, it is just that a client cannot discover if and where a