In which you predict somebody will *complain* that Atom is broken - you
never claim that Atom will actually break. I think Robert's complaint is
merely a kind attempt to help you fulfil your prophecy.
Joe Gregorio wrote:
I think Robert is referring to this:
http://tinyurl.com/l2uop
On 5/
I think Robert is referring to this:
http://tinyurl.com/l2uop
-joe
On 5/18/06, Paul Hoffman <[EMAIL PROTECTED]> wrote:
At 1:58 AM +0200 5/19/06, Robert Sayre wrote:
>On 5/19/06, Lisa Dusseault <[EMAIL PROTECTED]> wrote:
>>
>>This announcement is for a document that will obsolete RFC3548,
At 1:58 AM +0200 5/19/06, Robert Sayre wrote:
On 5/19/06, Lisa Dusseault <[EMAIL PROTECTED]> wrote:
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).
Yep, this definitely breaks RFC4287 i
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 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 5/19/06, Lisa Dusseault <[EMAIL PROTECTED]> wrote:
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).
Yep, this definitely breaks RFC4287 in the way Joe predicted. Time for
a revision.
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
>From: Nicolas Krebs <[EMAIL PROTECTED]>
>To: atom-syntax@imc.org
>Subject: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard
>(draft-snell-atompub-feed-thread)
>Date: Wed, 17 May 2006 23:55:47 +0200
>> - 'Atom Threading Extensions '
>>as a Proposed Standard
>In section 3, t
The requestor sends a request for all entries and comments on those entiries since a certain date. If the date request is considered reasonable, a compact atom syntax that contains,
a) a determination as to whether they support providing diffs a:ds="0" false, a:ds="1", trueb) the relavent pieces
* Antone Roundy <[EMAIL PROTECTED]> [2006-05-18 21:40]:
> The point of the whole exercise is to create a lightweight
> document for volatile metadata. If it's an atom:feed, you have
> to include a lot of stuff that's not needed here--atom:title,
> atom:updated, atom:author, and atom:summary or ato
On May 18, 2006, at 12:31 PM, A. Pagaltzis wrote:
Actually, you don’t really need another format. There’s no reason
why you couldn’t use atom:feed in place of your hypothetical
ct:comment-tracking. :-) Your ct:entry elements could almost be
atom:entry ones instead, too, except that assigning the
* Antone Roundy <[EMAIL PROTECTED]> [2006-05-18 20:05]:
> and in another document:
>
>
>
>
> hreflang="..." ct:count="5" ct:when="..." />
> hreflang="..." ct:count="3" ct:when="..." />
>
>
>
On May 18, 2006, at 8:10 AM, Brendan Taylor wrote:
Do you have any suggestions about how this metadata could be included
without changing the content of the feed? AFAICT the only solution
is to
not use the attributes (which aren't required, of course).
If it's in the feed document and it ge
* Robert Sayre <[EMAIL PROTECTED]> [2006-05-18 18:05]:
> There's no technical reason for the placement of the
> attributes,
Do you have better ideas on how to provide this information on a
per-link basis? It would help if you actually tried to suggest an
approach instead of bashing what’s there.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
As you may have noticed, the "Atom Over XMPP" I-D expired on February 20
of this year:
http://www.xmpp.org/drafts/draft-saintandre-atompub-notify-04.html
However, by no means is this I-D abandoned.
Since January, the underlying publish-subscribe spe
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."
Hope that helps!
On 5/18/06, James M Snell <[EMAIL PROTECTED]>
* James M Snell <[EMAIL PROTECTED]> [2006-05-18 17:40]:
> My interpretation of the text and the RELAX NG definition is
> that while the specification does not assign any meaning to
> extensions of the link element, it is nonetheless explicitly
> allowed.
Noone ever debated that.
> It may have be
David,
David Powell wrote:
> Tuesday, May 16, 2006, 4:50:03 AM, James M Snell wrote:
>
>> A few of the individuals on the WG had a problem with the placement of
>> the attributes due to various limitations of a few existing Atom 1.0
>> implementations.
>
> That doesn't accurately state my probl
And I am sorry for the numerous mistakes I make in my written English. *sigh*
>
> It's a valid concern, but as James has been saying the "problem" is with
> the syndication model. This isn't something that Atom (or any extension)
> can solve.
I agree with you and James. This is much larger issue and this spec is not
the right place to try solving it.
> Do you have any su
On Thu, May 18, 2006 at 09:26:18AM +0100, Sylvain Hellegouarch wrote:
> By acting as you do, we may end up in a huge amount of feeds being sent on
> the wire to clients which believe the feed has actually changed in its
> content when it has changed only in one meta-data value (that they will
> not
> Well this is debatable because you effectively change the resource itself
> and ought to update its meta-data as well (ie Last-Modified and Etag
> values).
>
> Besides, by not doing so can be even worse because an aggregator would
> requests the feed, the server would respond with a 304 and the
>>
>> By acting as you do, we may end up in a huge amount of feeds being sent
>> on
>> the wire to clients which believe the feed has actually changed in its
>> content when it has changed only in one meta-data value (that they will
>> not handle anyway).
>
>
>
> Servers don't *have* to change the
By acting as you do, we may end up in a huge amount of feeds being sent onthe wire to clients which believe the feed has actually changed in its
content when it has changed only in one meta-data value (that they willnot handle anyway).
Servers don't *have* to change the feed's Last-Modified and ETa
Tuesday, May 16, 2006, 4:50:03 AM, James M Snell wrote:
> A few of the individuals on the WG had a problem with the placement of
> the attributes due to various limitations of a few existing Atom 1.0
> implementations.
That doesn't accurately state my problem with FTE. My concern is more
genera
>
> When Friendster approached Six Apart and asked for a way to keep abreast
> as to the comment activity within the Friendster Blogging network
> (powered by TypePad), I turned immediately to FTE.
>
> In this implementation, there was actually no desire for Friendster to
> gain access to the com
> The latter is, of course, not specific to FTE, but apparently is enough
> of a problem to at least warrant a mention.
>
Thank you. This is fully appreciated.
- Sylvain
27 matches
Mail list logo
