Subject: Work Queue Rotation #16

From: Tim Bray <[email-masked]>
Date: Mon, 31 Jan 2005 11:45:25 -0800

Atom Public Issues List:  
http://www.intertwingly.net/wiki/pie/AtomPubIssuesList

First off, a huge THANK-YOU to the group for taking this list of hard  
issues on and engaging in some really high-quality discussion and  
(mostly) being polite about it.

Second, our "last call" attempt, as last calls often do, shook new  
issues out of the woodwork, so we're going to have to have another work  
queue rotation: stand by for more from Sam and Paul on that.

As always, these consensus calls are open to challenge, in this case  
there are 15 issues and over a thousand emails that we had to plow  
through, so it wouldn't be surprising if we had mis-read the WG on one  
of them.

Unlike previous rotations, all but two of these had received a lot of  
prior discussion, and there were postings from me to the group  
outlining what the probable finding would for each absent any further  
discussion.  These are reproduced below for each Pace, marked "If no  
further discussion:"

The Pro/Contra numbers below are not "votes", just part of the evidence  
we used in making the call as to whether or not consensus exists.

====================================================================

PaceAttributesNamespace

If no further discussion: Not yet taken up by the WG, depends on the  
discussion that comes with this call. Same rules as all the others:  
there has to be a positive WG consensus that each adds to the base  
specification.

Pro: 2
Contra: 7

Conclusion: No consensus, close it.

==================================================

PaceDateOfSubject:

If no further discussion: This topic was beaten to death a few times in  
the WG. Unless there is a wave of enthusiasm unaccompanied by -1s, the  
dates in the current Internet Draft will be all that ships with the  
final document.

Pro: 0
Contra: 1

Conclusion: No consensus, close it.

===================================================

PaceDateUpdated2

If no further discussion: This topic was beaten to death a few times in  
the WG. Unless there is a wave of enthusiasm unaccompanied by -1s, the  
dates in the current Internet Draft will be all that ships with the  
final document.

Pro: 0
Contra: 3

Conclusion: No consensus, close it.

========================================================

PaceEnclosuresAndPix

If no further discussion: Got no -1's, seems useful, needed for feature  
parity with RSS2, will likely go in absent some objections.

Note considerable argument whether these should have their own  
elements, not be crammed into <atom:link>, also a huge amount of  
discussion about favicon:

Pro: 6
Contra: 0

Conclusion: There is consensus that Atom should provide declarations  
for Enclosure and Image.  There is some feeling that putting them in  
<atom:link> is abuse of markup.  However, my best guess is that the  
people who don't want to use <atom:link> would rather put up with that  
than give up these tags.  So: adopt the Pace as written, and take a  
serious look at the proposals (already in the inbasket) for doing this  
without using <atom:link>.  Also, if people really want favicon, let's  
have a Pace or an extension for that.

================================================================

PaceEntryDeletion

If no further discussion: The earlier discussion for this was  
inconclusive. The demand doesn't seem high enough to get it over the  
goal line, but if there is a wave of enthusiasm, there didn't seem to  
be that much opposition.

Pro: 0
Contra: 3

Conclusion: No consensus, close it.

===================================================================

PaceEntriesAllTheWayDown:

If no further discussion: This is a radical change to the document and,  
so far, hasn't gathered widespread enough support to make it over the  
line.

Pro: 2
Contra: 1

Conclusion: We have a strong -1 and, in the form of PaceFeedRecursive,  
another proposal.  Not nearly enough support to say there is WG  
consensus for a change this large at this late date.

=====================================================================

PaceExtendingAtom:

If no further discussion:  This is the result of a lot of discussion  
around "Must Ignore" and has in various drafts received lots of  
friendly remarks and suggestions for improvement, which have been  
incorporated. Absent some convincing -1s, it probably goes in.

Pro: 2
Contra: 0

Conclusion: Accepted.

=======================================================================

PaceExtensionConstruct:

If no further discussion: This has received no -1s, but also not a lot  
of wild enthusiasm. Support at the moment is a bit marginal, but some  
+1s from implementors would probably make it a slam-dunk.

Pro: 2
Neutral: 1
Contra: 0

Conclusion: The Pace isn't really stable, there have been revisions and  
even the +1's were asking for changes.  We can give the supporters a  
chance to give some UNQUALIFIED +1s; it probably does enjoy rough  
consensus, we just need a bit more clarity.

======================================================================== 
=

PaceFeedState:

If no further discussion: Like PaceSupersede, this model of publishing  
does not (so far) enjoy consensus support.

Partially pro: 2
Contra: 0

Conclusion: Not enough interest.  Close it.

======================================================================== 
==

PaceFeedLink:

If no further discussion: Not yet taken up by the WG, depends on the  
discussion that comes with this call. Same rules as all the others:  
there has to be a positive WG consensus that each adds to the base  
specification.

Pro: 5
Contra: 0

Conclusion: Rough consensus, adopt it.  The discussions about  
relative/absolute URI were inconclusive; if someone wants to change  
what's there now, we need a quick Pace to focus it.  There is also  
consensus that  language be added saying that there is no obligation on  
clients to actually use this thing, there were proposals for draft  
wording from Bray  
(http://www.imc.org/atom-syntax/mail-archive/msg12477.html) and Parks  
(http://www.imc.org/atom-syntax/mail-archive/msg12475.html), both  
proposals got +1's, the editors can cherry-pick.

==================================================================

PaceIRI

If no further discussion: It's hard to see how to avoid adopting this  
now that IRIs are standards-track RFC.

Pro: 2
Expressed neutral: 1
Contra: 0
Concerns about cost: 3

Conclusion: This is tough.  There was nothing like a -1, but there were  
real concerns about cost.  As a judgement call, it looks like the  
concerns were fairly addressed, and there is a general feeling that  
this is The Right Thing To Do.  Accepted.

=======================================================================

PaceMustBeWellFormed:

If no further discussion:  The WG completely failed to converge to  
consensus on these issues last time around. Consensus can still be  
found here.

Contra: 2
Pro: 5
Friendly, but wanted it in another doc: 2

Conclusion: We have consensus that there are real issues here, but not  
on the language nor even the desired behavior.  Next step: we will ask  
our AD Scott Hollenbeck, who as co-author of RFC3470 is one of the lead  
experts in this space, for guidance on (a) whether it's OK for us to be  
throwing MUSTs and SHOULDs around in this space, and (b) to what extent  
we should cover ground (and in effect profile) space that is covered by  
the existing RFC3023.  Action Tim: draft a note to Scott with a pointer  
to some of the best discussion from the mail archive.

=======================================================================

PaceSimpleLanguageTagging:

If no further discussion: Not yet taken up by the WG, depends on the  
discussion that comes with this call. Same rules as all the others:  
there has to be a positive WG consensus that each adds to the base  
specification.

Pro: 2
Contra: 3

Conclusion: No consensus, close it.

======================================================================== 
==

PacePersonLinks

If no further discussion: Has failed to get anywhere near enough  
support to call rough consensus in previous go-arounds.

Pro: 1
Contra: 1

Conclusion: No consensus, close it.

======================================================================== 
==

PaceSyntaxGuidelines

If no further discussion: Hasn't got enough support so far, but also  
has had no opposition we can find.

Pro: 2
Contra: 3

Conclusion: No consensus, close it.

---

From: Robert Sayre <[email-masked]>
Date: Mon, 31 Jan 2005 16:09:32 -0500

Tim Bray wrote:

>  Pro: 2 Expressed neutral: 1 Contra: 0 Concerns about cost: 3
>
>  Conclusion: This is tough. There was nothing like a -1, but there
>  were real concerns about cost. As a judgement call, it looks like
>  the concerns were fairly addressed, and there is a general feeling
>  that this is The Right Thing To Do. Accepted.
>

Mark Nottingham wrote:

>  As I understand it, if I implement an Atom processor that doesn't
>  support IRIs, It's not conformant, and will have problems with some
>  valid feeds, when dereferencing IRIs.

This is tough because it's pointless to use MAY or SHOULD here. The 
result Mark outlined would still happen, only it would happen *forever*. 
So, the only two choices are MUST NOT support IRIs or MUST support IRIs. 
It seems myopic to ban them in exchange for short-term interop. Also, it 
borders on ridiculous for a group of North Americans, Australians, and 
Western Europeans conducting contentious, snarky, slang-ridden 
proceedings in English to declare consensus against them. So, I concur 
with the chairs, even though the cost concerns me and IRIs are certain 
to cause problems in the short-term.

Robert Sayre

---

From: Antone Roundy <[email-masked]>
Date: Mon, 31 Jan 2005 14:11:50 -0700

On Monday, January 31, 2005, at 12:45  PM, Tim Bray wrote:
> If no further discussion: This is a radical change to the document 
> and, so far, hasn't gathered widespread enough support to make it over 
> the line.
>
> Pro: 2
> Contra: 1
>
I'll add another -1 to this one, and will be posting another proposal 
similar to PaceFeedRecursive shortly.

---

From: Graham <[email-masked]>
Date: Mon, 31 Jan 2005 21:25:45 +0000

I don't know much about IRIs. Is it possible to express them as URIs?

Graham

---

From: Robert Sayre <[email-masked]>
Date: Mon, 31 Jan 2005 17:15:57 -0500

> I don't know much about IRIs. Is it possible to express them as URIs?

My read-the-draft-once understanding is that it is always possible to 
convert an IRI to a URI, but it may not be possible to convert a URI 
back to the same IRI it was generated from. For example, it is always 
possible to convert an IRI to ASCII for use in HTTP's Request-URI, but 
it would be better to leave it in Unicode for editing. There's also a 
large section of the draft that deals with right-to-left IRIs, but I 
don't understand it.

Oh, there was also this nugget: "Applications using IRIs as identity 
tokens with no relationship to a protocol MUST use the Simple String 
Comparison (see section 5.3.1)." (5.1.  Equivalence)

Robert Sayre

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 31 Jan 2005 15:46:46 -0800

> Conclusion: Not enough interest.  Close it.

If this is the direction we go in on this, that's fine with me, but I 
think that the spec needs to say *something* about managing feed state, 
even if it's just this:

[[[
x. Managing Feed State

Atom Processors MAY keep state (e.g., metadata in atom:head, entries) 
sourced from Atom Feed Documents and combine them with other Atom Feed 
Documents, in order to facilitate a contiguous view of the contents of 
the feed. The manner in which Atom Feed Documents are combined in order 
to reconstruct a feed (including methods of identifying duplicate 
entries, updating metadata, and dealing with missing entries) is out of 
the scope of this specification, but may be defined by an extension to 
Atom.
]]]

So, if we drop PaceFeedState, I propose the text above.

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

---

From: DJWS <[email-masked]>
Date: Tue, 01 Feb 2005 00:25:41 +0100

>I don't know much about IRIs. Is it possible to express them as URIs?

As far as I understand, and this is my problem : I cannot have a formal 
response on the following.
- there are various way to support a non ASCII IRI (the majority of the 
world needs them - inclunding French language).
- one way is to use Unicode
- another way is to use ToASCII and punycode process (used in IDNs)

the punycode process :
- is reversible (if it was not, the Domain Name could not be valid).
- is used in IDNs in transcoding the Unicode into ascii for 2LD and above 
level and in adding the prefix "xn--".
- can obvsiously be used to transcode the TLD of a domain name, but there 
is no specification in RFCs about TLDs being punycoded. Yet there are 
"ML.ML" domain names already in use (both by Govs agencies and in private 
spaces).

I asked the author of the IRI RFC. He reponded to most of my questions. But 
the situation of the TLD is not clear as it is not supported by IE, but is 
supported by plug-in. The case of ATOM is different as not dependent from 
browsers. Also it is likely that in the ATOM definition timeframe the 
"ML.ML" (multilingual.multilingual) will most probably broadly in use in 
some areas of the world.

jfc

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 31 Jan 2005 18:27:20 -0800

At 3:46 PM -0800 1/31/05, Mark Nottingham wrote:
>If this is the direction we go in on this, that's fine with me, but 
>I think that the spec needs to say *something* about managing feed 
>state,

Why?

>  even if it's just this:
>
>[[[
>x. Managing Feed State
>
>Atom Processors MAY keep state (e.g., metadata in atom:head, 
>entries) sourced from Atom Feed Documents and combine them with 
>other Atom Feed Documents, in order to facilitate a contiguous view 
>of the contents of the feed. The manner in which Atom Feed Documents 
>are combined in order to reconstruct a feed (including methods of 
>identifying duplicate entries, updating metadata, and dealing with 
>missing entries) is out of the scope of this specification, but may 
>be defined by an extension to Atom.
>]]]
>

What does that add to the document? A MAY with a hint of an extension 
doesn't seem to add much.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Robert Sayre <[email-masked]>
Date: Mon, 31 Jan 2005 21:42:37 -0500

> doesn't seem to add much.

I agree with Paul. The proposal doesn't really make sense unless there's 
a way to distinguish "this feed represents the current weather in 
Oaxaca" from "the latest entry represents the current weather in 
Oaxaca". Also, should such a convention arise, it would be easy to add 
to the registry.

Robert Sayre

---

From: Martin Duerst <[email-masked]>
Date: Tue, 01 Feb 2005 09:10:21 +0900

sourced from Atom Feed Documents and combine them with other Atom Feed 
Documents, in order to facilitate a contiguous view of the contents of the 
feed. The manner in which Atom Feed Documents are combined in order to 
reconstruct a feed (including methods of identifying duplicate entries, 
updating metadata, and dealing with missing entries) is out of the scope of 
this specification, but may be defined by an extension to Atom.
 >So, if we drop PaceFeedState, I propose the text above.

Fine with me, except that I'd change the second parenthesis from:

"(including methods of identifying duplicate entries, updating metadata,
and dealing with missing entries)"

to:

"(including methods of updating metadata and dealing with missing entries)"

How to identify duplicate entries is clear from the description of the
id attribute, so I don't think it belongs here.

Regards,    Martin.