Subject: RE: Pseudo-Last Call on draft-nottingham-atompub-feed-history-07

From: "David Hall" <[email-masked]>
Date: Thu, 5 Oct 2006 12:55:31 -0700

Hey Mark -

Things are looking good to me.

Couple questions, comments:

1. I think your document might need to address what's supposed to happen
if duplicate items are discovered when trolling through the paged info.
Newer replaces older? (That makes the most sense to me) Although I guess
the argument might be, "what's an 'item'?". 

2. We're currently recommending 'feed history' as a best practice for
Media RSS. http://search.yahoo.com/mrss

(I'll need to update that link in the documentation)

Thanks-
David

> From: Mark Nottingham <[email-masked]>
> Date: 4 October 2006 11:13:06 AM
> To: Atom-Syntax Syntax <[email-masked]>
> Subject: Pseudo-Last Call on draft-nottingham-atompub-feed-history-07
>
>
> I've only had positive comments about -07 so far, so I've
> recommended it for publication as a Proposed Standard to the IESG.
>
> As part of that process, I'm issuing an informal, pseudo-WG Last
> Call on the document to capture any remaining feedback. In particular,
>
> * What do people think about putting this document on the Standards
> Track?
>
> * Do you have an implementation available, in progress, planned, etc.?
>
> http://ietfreport.isoc.org/idref/draft-nottingham-atompub-feed-
> history/
>
> Please provide feedback by October 18th.
>
> Cheers,
>
> --
> Mark Nottingham     http://www.mnot.net/

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 11 Oct 2006 22:06:28 -0700

> the argument might be, "what's an 'item'?".

I started going down that road in early drafts, but backed away from  
it when it started looking like a rat hole. :)

To allow FH to normatively specify what to do with duplicates, you  
have to figure out the ordering of entries, so you can determine  
their relative precedence. Since Atom doesn't have any explicit  
ordering, FH would need to either assume ordering semantics  
implicitly, or doing something explicit in an extension.

In the paged case, this seems like a tall order, because it's totally  
context-dependent; e.g., if you have OpenSearch or GData results, or  
orders for launching the missiles that are paged, and you happen to  
get a duplicate, the right thing to do may be very different.

In the archived case, it's a little easier, because we're already  
inferring that the pages closes to current do have precedence, so we  
just need to figure out what to do about duplicates in the same feed  
document.

I could see making the implied page-by-page precedence for Archived  
feeds in section 4 explicit. It would also be easy to add text saying  
that relative precedence in the same feed document can be determined  
by any extension that defines ordering, defaulting to the update time  
of the entries (or document order, topmost first? I think this is  
what most people do, but it seems contrary to the spirit of the Atom  
spec). I'm not crazy about actually defining an ordering extension  
(is one in progress? James?) in FH.

Does that work for you?

> (I'll need to update that link in the documentation)

Thanks!