Subject: Re: Next step on atom:id

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 23 Aug 2004 08:32:54 -0700

We have been discussing atom:id and have, I think, a good 
understanding of the alternatives.  While there isn't currently 
strong consensus on which is better, it does seem likely that the 
differences in cost and effectiveness are minor.  The survey at 
http://www.intertwingly.net/wiki/pie/IDSurvey is far from conclusive. 
Some folks on the list seem to hold tight to their views in 
particular directions even though there is near-universal agreement 
that atom:id is handy but not terribly important for most Atom users.

Given this stickiness, it is probably not worthwhile for us to try to 
make another stab at this right now. Given that there are no other 
parts of the spec that are significantly affected by the syntax of 
atom:id, we can safely pick any of the current minorly-different 
proposals for the next draft.

Thus, we will ask the format document authors to use 
http://www.intertwingly.net/wiki/pie/PaceIdConstruct (minus the 
requirement that atom:feed MUST contain an atom:id) as the text for 
atom:id and ask Sam to also put that pace on the "revisit" list. We 
will revisit the topic after everyone sees it in context; maybe that 
will help soften some of the firm views.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Graham Parks <[email-masked]>
Date: Mon, 23 Aug 2004 13:36:47 -0400

>that atom:id is handy but not terribly important for most Atom users.

Where the hell did you get that idea? atom:id is the most important thing in the fricking world as far as doing anything reliable or consistent with syndicated content is concerned. Many people on the list have said the same thing on several occasions.

>atom:id and ask Sam to also put that pace on the "revisit" list.

That Pace is remarkably clunky and ineloquent. Why not go with the current wording plus something about it being absolute?

Graham

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 23 Aug 2004 11:47:41 -0700

At 1:36 PM -0400 8/23/04, Graham Parks wrote:
>Where the hell did you get that idea? atom:id is the most important 
>thing in the fricking world as far as doing anything reliable or 
>consistent with syndicated content is concerned. Many people on the 
>list have said the same thing on several occasions.

My apologies for poor wording. I should have said the specific syntax 
rules about whether or not atom:id is canonicalized is not terribly 
important for most Atom users.

>That Pace is remarkably clunky and ineloquent. Why not go with the 
>current wording plus something about it being absolute?

Are you proposing that because you saw consensus about that on the 
mailing list, or because it is your preference and you believe that 
more discussion now would be best for the WG?

--Paul Hoffman, Director

---

From: Graham Parks <[email-masked]>
Date: Mon, 23 Aug 2004 21:26:06 -0400

>important for most Atom users.

Yes. Good. I'm glad that's what you meant.

>more discussion now would be best for the WG?

PaceIDConstruct has lots of stuff that has never really been discussed - eg "If the identified resource is served dynamically, the content of an Identification construct MUST be created only once and then stored along with the resource". Also, (I've noticed) it's much easier to add things than it is to remove it later. We shouldn't be adding a big bunch of stuff there isn't consensus around, which is why I think it would be better to stick with the terse current version because

Graham

---

From: Tim Bray <[email-masked]>
Date: Mon, 23 Aug 2004 19:25:54 -0700

On Aug 23, 2004, at 6:26 PM, Graham Parks wrote:

> PaceIDConstruct has lots of stuff that has never really been discussed 
> - eg "If the identified resource is served dynamically, the content of 
> an Identification construct MUST be created only once and then stored 
> along with the resource".

Hmm, I thought that one got lots of discussion, there was endless 
ranting about how atom:id was going to be broken because people would 
generate it dynamically, we must explain not to do that, etc... I 
thought there was a pretty clear mandate to go overboard in lecturing 
about the importance of persistence & immutability.

Having said that, if you think you can improve the language making a 
suggestion for a delta is always OK. -Tim

---

From: Graham <[email-masked]>
Date: Mon, 23 Aug 2004 22:57:03 -0700

> about the importance of persistence & immutability.

I think people agree on the principle, it's just that the wording 
mandates how it MUST be implemented, and that's crossing a boundary - 
all we can dictate is how it must interoperate. The lecture needs to be 
non-normative, or at least not use capital letter words.

> suggestion for a delta is always OK.

I'll draft something when I have time.

Graham

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 24 Aug 2004 00:13:01 -0700

+1 - this is the gist of the problem I had with the text as well.

On Aug 23, 2004, at 10:57 PM, Graham wrote:

> all we can dictate is how it must interoperate. The lecture needs to 
> be non-normative, or at least not use capital letter words.

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

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 24 Aug 2004 11:24:23 -0400

Graham wrote:
> mandates how it MUST be implemented, and that's crossing a boundary
>  - all we can dictate is how it must interoperate.

	+1

	IETF is about interoperation -- not implementation. You can require
that something "appear to have been implemented" in some way, but you can't
require that it *actually* be implemented in that way. What we define in
IETF specifications is the form, interface, or externally visible behavior
of systems -- not the methods by which the required behavior is implemented.
An IETF spec says only: "Make it look like this!" How you meet that
challenge is up to you.
 
		bob wyman