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
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
For related work, you could look at the email spam filtering stuff
from SIEVE: http://www.ietf.org/internet-drafts/draft-ietf-sieve-
spamtestbis-02.txt
The similar problem is that many spam libraries already produce some
kind of linear or similar scale of severity/likelihood rating for
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 -
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
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 and got an instant stamp of approval
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
versa.
There is interest
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
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
, 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 very brief. I discussed explicitly with the IESG during the
IESG tele
FYIBegin forwarded message:From: The IESG [EMAIL PROTECTED]Date: August 14, 2006 6:35:53 PM PDTTo: IETF-Announce ietf-announce@ietf.orgSubject: Last Call: 'Atom License Extension' to Experimental RFC (draft-snell-atompub-feed-license) Reply-To: iesg@ietf.org The IESG has received a request from
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
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 server
store those
unrecognized extension elements
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
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
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
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)
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
FYI
--Lisa
Begin forwarded message:
From: The IESG [EMAIL PROTECTED]
Date: January 19, 2007 1:07:21 PM PST
To: IETF-Announce ietf-announce@ietf.org
Subject: Last Call: draft-nottingham-atompub-feed-history (Feed
Paging and Archiving) to Proposed Standard
Reply-To: ietf@ietf.org
The IESG
19 matches
Mail list logo
