Subject: WG Last Call for draft-ietf-atompub-protocol

From: Paul Hoffman <[email-masked]>
Date: Thu, 14 Sep 2006 10:13:13 -0700

With the publication of draft-ietf-atompub-protocol-10.txt, we are 
ready for WG Last Call. This is a two-week period where people look 
intently at the document and comment on it.  New Paces are still 
allowed, and are encouraged if you are proposing anything more than a 
few sentences worth of change.  

At the end of the Last Call, we grind out one last revision, and the 
WG passes it on to our fearless AD to take it to the IETF as a whole.

The WG Last Call will close September 26.

Please remember to make your subject lines meaningful when you start 
threads, and when you change the topic. Thanks!

---

From: James M Snell <[email-masked]>
Date: Thu, 14 Sep 2006 10:24:44 -0700

What are we going to do with the Security Considerations?  We had two
paces on the table. Robert withdrew his. I made some edits to mine.  At
this point, my Pace is the only one still on the table.

- James

Paul Hoffman wrote:
> 
> With the publication of draft-ietf-atompub-protocol-10.txt, we are ready
> for WG Last Call. This is a two-week period where people look intently
> at the document and comment on it.  New Paces are still allowed, and are
> encouraged if you are proposing anything more than a few sentences worth
> of change. 
> At the end of the Last Call, we grind out one last revision, and the WG
> passes it on to our fearless AD to take it to the IETF as a whole.
>

---

From: Martin Duerst <[email-masked]>
Date: Fri, 15 Sep 2006 11:54:30 +0900

Just a procedural nit:

>The WG Last Call will close September 26.

Your email is dated as follows: Date: Thu, 14 Sep 2006 10:13:13 -0700.

When last counting, two weeks were fourteen days. That would make
the closure date of WG Last Call September 28th. Or did I get anything wrong?

Regards,    Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 14 Sep 2006 21:40:38 -0700

>the closure date of WG Last Call September 28th. Or did I get anything wrong?

You got wrong the fact that the WG started discussing the draft two 
days ago. WG Last Call is as long as is needed, and we thought that 
about two weeks was needed.

---

From: Sam Ruby <[email-masked]>
Date: Tue, 26 Sep 2006 15:34:43 -0400

> The WG Last Call will close September 26.

Here's a list of Paces that weren't disposed of with the last consensus 
call:

PaceAppEdited
PaceAppEdited2
PaceAppModified3
PaceAppVersion
PaceCollectionLinkType
PaceFixModel
PaceLocationPointsToEntry
PaceOrderCollectionsByAppModified2
PaceRemoveConnegSuggestionOnServiceDoc
PaceRemoveOutOfLineCategoriesFromCategoryDocument
PaceRevertTitle
PaceSecurityConsiderationsRevised
PaceServiceLinkType
UseElementsForAppCollectionTitles2
UseElementsForAppCollectionTitles3

- Sam Ruby

---

From: Tim Bray <[email-masked]>
Date: Tue, 26 Sep 2006 15:15:11 -0700

On Sep 26, 2006, at 12:34 PM, Sam Ruby wrote:

> Here's a list of Paces that weren't disposed of with the last  
> consensus call:

First of all, did Sam get them all?  Please speak up soonest about  
anything that was missed and might have a realistic chance.

<co-chair-mode>

PaceAppEdited: Lots of discussion.  There seems universal support for  
the utility of an app:edited element, and an assertion that entry  
members SHOULD contain one.  On the other hand, every discussion of  
sort order has spiraled instantly into a rat-hole.

Conclusion.  PaceAppEdited is accepted, in part. The second part of  
the proposal, defining the app:edited element, is ACCEPTED.  The  
first part, imposing a requirement on the sort order of collections,  
clearly does not have consensus support.

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

PaceAppEdited2: Not enough support, some opposition, big and  
complicated.  REJECTED.

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

PaceAppModified3: Lots of discussion, no real consensus, eventually  
replaced by PaceAppEdited.  REJECTED.

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

PaceAppVersion: Got no +1s, some opposition: REJECTED.

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

PaceCollectionLinkType: zero discussion: REJECTED.

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

PaceFixModel: 2 supporters, not enough: REJECTED.
But note that this is inconsistent with some of the language in  
section 9, so editorial work is required.

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

PaceLocationPointsToEntry: zero discussion: REJECTED.

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

PaceOrderCollectionsByAppModified2: zero discussion: REJECTED.

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

PaceRemoveConnegSuggestionOnServiceDoc: almost no discussion: REJECTED.

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

PaceRemoveOutOfLineCategoriesFromCategoryDocument: 2 supporters,  
little discussion, not enough.  REJECTED.

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

PaceRevertTitle: Lots of -1's: REJECTED.

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

PaceSecurityConsiderationsRevised: We need something in the Security  
Considerations section of the document, and there was at least some  
support for the ideas in this section in the past. The other proposal  
for words for this section was withdrawn. Therefore, this Pace is  
ACCEPTED with the understanding that the issue of what our security  
considerations are is not closed and may be modified after the IETF  
last call.

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

PaceServiceLinkType: Not enough discussion/support: REJECTED.

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

UseElementsForAppCollectionTitles3: Seems to have been incorporated  
in the draft.

</co-chair-mode>

---

From: Eric Scheid <[email-masked]>
Date: Wed, 27 Sep 2006 09:59:48 +1000

> clearly does not have consensus support.

There also seems to be universal support for the notion that collection
feeds could be sorted by something other than what's currently in the spec.
The spec currently not only says collections are to be sorted by
atom:updated, but because of the MUST it also says it MUST NOT be sorted by
anything *else*, which is a problem.

Section 10.0 ¶ 2 says this:

    The entries in the returned Atom Feed MUST be ordered by their
   "atom:updated" property, with the most recently updated entries
    coming first in the document order. Clients SHOULD be constructed
    in consideration of the fact that changes which do not alter the
    atom:updated value of an entry will not affect the position of
    the entry in a Collection.

We need to either strike that entire paragraph, or at the very least make
that MUST into a SHOULD.

I say +1 to s/MUST/SHOULD/

e.

---

From: Tim Bray <[email-masked]>
Date: Wed, 27 Sep 2006 13:14:20 -0700

<co-chair-mode>
Please see the dialogue below.
</co-chair-mode>

(Eric's point seems plausible to me; personally I'd be inclined to a  
+1.)

<co-chair-mode>
Can we have some feedback from the WG ASAP?  We want to take  
protocol-11 to the IETF.
</co-chair-mode>

   -Tim

---

From: John Panzer <[email-masked]>
Date: Wed, 27 Sep 2006 21:11:22 -0700

+1 to removing the MUST.
+0 to changing it to SHOULD.

---

From: Henry Story <[email-masked]>
Date: Thu, 28 Sep 2006 18:45:26 +0200

+1 to make the MUST a SHOULD
+1 on app:edited

But I think it would be really useful if we could have something that  
allowed the user to specify how the feed should be sorted.

Henry

On 27 Sep 2006, at 22:14, Tim Bray wrote:

> (Eric's point seems plausible to me; personally I'd be inclined to  
> a +1.)
>
> <co-chair-mode>