Subject: AtomPubIssuesList for 2005/05/05

From: Sam Ruby <[email-masked]>
Date: Thu, 05 May 2005 07:17:00 -0400

*************************** REMINDER ******************************
** Use more specific subject lines when responding to this note! **
*************************** REMINDER ******************************

First the meat... here's the new atom pub issues list, conveniently 
sorted into categories:

   EntryId:
     http://intertwingly.net/wiki/pie/PaceAllowDuplicateIDs
     http://intertwingly.net/wiki/pie/PaceDuplicateIDWithSource2
     http://intertwingly.net/wiki/pie/PaceDuplicateIDWithSource
     http://intertwingly.net/wiki/pie/PaceExplainDuplicateIds

   FeedId:
     http://intertwingly.net/wiki/pie/PaceFeedIdOrAlternate
     http://intertwingly.net/wiki/pie/PaceFeedIdOrSelf
     http://intertwingly.net/wiki/pie/PaceOptionalFeedLink

   Provenance:
     http://intertwingly.net/wiki/pie/PaceOriginalAttribute
     http://intertwingly.net/wiki/pie/PaceSourceRecs

   Status:
     http://intertwingly.net/wiki/pie/PaceEntryState
     http://intertwingly.net/wiki/pie/PacePubControl
     http://intertwingly.net/wiki/pie/PacePubStatusResource

   Text:
     http://intertwingly.net/wiki/pie/PaceBriefExample
     http://intertwingly.net/wiki/pie/PaceCoConstraintsAreBad
     http://intertwingly.net/wiki/pie/PaceOptionalSummary
     http://intertwingly.net/wiki/pie/PaceRecommendPlainTextContent
     http://intertwingly.net/wiki/pie/PaceTextShouldBeProvided

   Recommended for Closure:
     http://intertwingly.net/wiki/pie/PaceXhtmlDivSuggestedOnly
     http://intertwingly.net/wiki/pie/PaceXmlContentWrapper

Now for some administrivia.  No progress was made on the last published 
issued list[1], so I've gone ahead and marked those issues that were 
recommended for closure, closed; and those currently under discussion 
were moved back to Needing to Revisit.

Next, I'd like to remind everybody that last call for the Atom Format 
went out.  Operationally, what this means is that the secretary and 
co-chairs are going to be increasingly reluctant to revisit things 
simply because somebody wants to bring them up again.  What that means 
is that in order to successfully bring up an issue, you need to do a 
little homework.  Demonstrate that you have revisited the previous 
discussion, and that you either have something new to add, or can point 
out some evidence that the previous consensus call was made in error.

Tim has taken the opportunity to lead by example on this one with 
PaceAllowDuplicateIDs.  The secretary and co-chairs all are in agreement 
that the XhtmlDiv related paces don't meet this criteria.  If anyone 
disagrees, what we would like to ask is that you follow Tim's lead.

Because we are in last call, I've scheduled everything related to the 
Format document.  As one of the status paces touches on the format, I've 
scheduled all three.  All we need to resolve now is the extent to which 
this is going to affect the format document.

I believe that PaceBriefExample is truly editorial, meaning that the 
editors can act on this at their discretion.

- Sam Ruby

[1] http://www.imc.org/atom-syntax/mail-archive/msg13691.html

---

From: Walter Underwood <[email-masked]>
Date: Thu, 05 May 2005 07:02:15 -0700

--On May 5, 2005 7:17:00 AM -0400 Sam Ruby <[email-masked]> wrote:
>
> Demonstrate that you have revisited the previous discussion, and that you either
> have something new to add, or can point out some evidence that the previous
> consensus call was made in error.

PaceCaching was not discussed and rejected based on false information.
It was rejected because it was HTTP-specific (it is not), and because
it was non-core (similar features are common in other RSS specs).

It does not interact with other features, so it should be a fairly
clean, quick discussion.

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: Mark Pilgrim <[email-masked]>
Date: Thu, 5 May 2005 09:15:44 -0500

> It does not interact with other features, so it should be a fairly

You must be new here.

/ducks

-- 
Cheers,
-Mark

---

From: Graham <[email-masked]>
Date: Thu, 5 May 2005 15:21:02 +0100

> It does not interact with other features, so it should be a fairly

Unless we can make providing incorrect or misleading information in  
either of these elements lead to the immediate purging of first born,  
they're not at all useful to anyone. The "expires date" can't apply  
to 99% of feeds since they don't work on a fixed or predictable  
schedule. Meanwhile "max-age" doesn't provide any actionable  
information to caches, beyond "I chose this random number off the top  
of my head when I wrote my Atom script 3 years ago. Deal." Do you  
seriously expect it to be interpreted as a promise that the feed  
won't change for the next x minutes?

Graham

---

From: Mark Pilgrim <[email-masked]>
Date: Thu, 5 May 2005 09:26:46 -0500

> won't change for the next x minutes?

No, but I do seriously expect it to be interpreted that the feed
publisher does not wish clients to check it for the next x minutes.

-- 
Cheers,
-Mark

---

From: Sam Ruby <[email-masked]>
Date: Thu, 05 May 2005 10:44:24 -0400

> it was non-core (similar features are common in other RSS specs).

Actually, it never has been rejected.  I had miscategorized it as 
protocol.  I've fixing that now, and scheduled it for this cycle.

Sorry for the confusion.

- Sam Ruby

---

From: James Aylett <[email-masked]>
Date: Thu, 5 May 2005 15:49:47 +0100

> publisher does not wish clients to check it for the next x minutes.

Indeed - Expires doesn't say it won't change, it says that you
shouldn't care whether it's changed.

James

-- 
/--------------------------------------------------------------------------\
  James Aylett                                                  xapian.org
  [email-masked]                               uncertaintydivision.org

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 6 May 2005 16:28:44 -0700

-1. Having two mechanisms in two different layers is a recipe for 
disaster. If HTTP headers are good enough for everything else on the 
web, they're good enough for Atom.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Walter Underwood <[email-masked]>
Date: Sat, 07 May 2005 20:19:43 -0700

--On May 6, 2005 4:28:44 PM -0700 Paul Hoffman <[email-masked]> wrote:
>
> -1. Having two mechanisms in two different layers is a recipe for disaster. 
> If HTTP headers are good enough for everything else on the web, they're good 
> enough for Atom.

That would be a problem. But this is one mechanism with two ways to
specify it. One is out-of-band in a server-specific way, the other
is in the document in a standard way. Either way, it is HTTP rules for
caching at all intermediate caches and at the client.

Architecturally, this is exactly the same as HTTP-EQUIV meta tags for
HTTP headers, and very similar to the ROBOTS meta tag for /robots.txt.
In both cases, they provide a way for the document author to specify
something without having permissions on the server software config.

Further, these should be implemented exactly like HTTP-EQUIV, where
the server software reads them and sets the header.

The HTTP-EQUIV meta tag is proof "put it in the header" is not good
enough for everything else. If that wasn't needed, it would be deprecated
by now.

There is a problem here, though. We need to specify the priority of the
in-document specs vs. the HTTP header specs. I propose following the HTTP
standard, in saying that the HTTP headers trump anything in the body.
I'll even assume that following the HTTP spec is non-controversial, and
go update the PACE.

wunder

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 7 May 2005 22:20:01 -0700

Walter,

> the server software reads them and sets the header.

Servers don't do this with HTTP-EQUIV because it's too much of a 
performance hit; HTTP-EQUIV was a nice idea that never took off.

> enough for everything else. If that wasn't needed, it would be 

I'm sympathetic to this problem, but I think the right answer is to fix 
the server configuration mechanisms, not to mix transport issues into 
formats.

> go update the PACE

This was the approach taken in determining the character encoding for 
XML, and it cause a lot of confusion and problems.

Also, realise that HTTP's caching mechanism is very much reliant on the 
constraints of HTTP; Expires brings clock sync issues, and max-age 
places requirements on the behaviour of intermediaries. It's not very 
easy to abstract these away into a generic mechanism.

So, I'm -1 to PaceCaching.

Cheers,

--
Mark Nottingham     http://www.mnot.net/

---

From: Bill de hÓra <[email-masked]>
Date: Sun, 08 May 2005 15:46:16 +0100

> So, I'm -1 to PaceCaching.

I agree with Paul and Mark, this is mixing layers. -1 to PaceCaching.

cheers
Bill