Consensus call: PacePubControl

[Tim Bray <Tim.Bray@xxxxxxx>]

<co-chair-mode>
PubControl: http://www.intertwingly.net/wiki/pie/PacePubControl

In the interests of transparency, I've summarized my reading of the  
discussion below, with pointers.

Here's how I see it:

1. PacePubControl does not have consensus support and should be  
marked for closure.

2. Rob Sayre has outlined an extreme position that, in general, this  
stuff is too blog-specific and not worthy of standardization in the  
core.  However, my reading of the group is that there's a good chance  
for rough-consensus backing for some of these capabilities.  Of the  
capabilities outlined in PubControl, trackback-out seems to have  
qualitatively weaker support than the others.

3. There is consensus that if we put something about publishing  
status in the core, it should not be acceptable, just "draft? Yes/No".

4. There is real interest in being able to signal markup formats in  
the protocol somehow (e.g. MarkDown, WikiWords), I believe a well- 
thought-out proposal here has a real chance of support.

5. I think that if we do this kind of thing, there is probably  
consensus support for doing it with a MustUnderstand facility of some  
sort.

6. Now I'm going to go and look at the other Paces in play, but my  
initial suspicion is that none have consensus support.

7. There is a big opportunity here for someone to read this  
correspondence and come back with another proposal in the  
PacePubControl space.

Summary of debate:

Gregorio +1 http://www.imc.org/atom-protocol/mail-archive/msg00894.html
Johnson +1 with concerns about data formats http://www.imc.org/atom- 
protocol/mail-archive/msg00899.html
de hOra likewise http://www.imc.org/atom-protocol/mail-archive/ 
msg00900.html

Sayre: MIME for types? http://www.imc.org/atom-protocol/mail-archive/ 
msg00901.html

Cooper: launched big thread on extensibility of published-status:  
http://www.imc.org/atom-protocol/mail-archive/msg00902.html

Broyer: +1, but doesn't like trackback-out: http://www.imc.org/atom- 
protocol/mail-archive/msg00911.html
        doesn't like container: http://www.imc.org/atom-protocol/ 
mail-archive/msg00913.html

Gregorio: more on markup types: http://www.imc.org/atom-protocol/mail- 
archive/msg00913.html
          plus wants to limit draft status
Johnson: +1 to previous: http://www.imc.org/atom-protocol/mail- 
archive/msg00931.html
Powell: Also +1, don't want extensible status: http://www.imc.org/ 
atom-protocol/mail-archive/msg00931.html

Powell: disagrees with Broyer on container: http://www.imc.org/atom- 
protocol/mail-archive/msg00941.html

Powell: make sure PubControl plays by 6.4 extensibility rules: http:// 
www.imc.org/atom-protocol/mail-archive/msg00942.html

Broyer: seems to withdraw hostility to container: http://www.imc.org/ 
atom-protocol/mail-archive/msg00942.html

Tauber: smart remarks on markup types: http://www.imc.org/atom- 
protocol/mail-archive/msg00945.html
Ringnalda: follows on from Tauber: http://www.imc.org/atom-protocol/ 
mail-archive/msg00946.html

Broyer: doesn't want markup types in the core: http://www.imc.org/ 
atom-protocol/mail-archive/msg00947.html

Snell: Wants to generalize with <param/> elements:  http:// 
www.imc.org/atom-protocol/mail-archive/msg01005.html

de hOra: Pushes back on Snell: http://www.imc.org/atom-protocol/mail- 
archive/msg01009.html
  ... discussion follows

Broyer: Concerned about locking a small blog-specific ops into APP  
core: http://www.imc.org/atom-protocol/mail-archive/msg01015.html
Scheid: -1 on generalized <param/>: http://www.imc.org/atom-protocol/ 
mail-archive/msg01016.html
Obasanjo: Ditto: http://www.imc.org/atom-protocol/mail-archive/ 
msg01017.html
Gregorio: Ditto: http://www.imc.org/atom-protocol/mail-archive/ 
msg01018.html
          Plus, assumes no MustUnderstand

Sayre: Maybe MustUnderstand is OK for protocol even if not for  
format.  As for PubControl, worries about distribution of control  
info between HTTP & Atom, maybe HTTP/SOAP/Atom: http://www.imc.org/ 
atom-protocol/mail-archive/msg01019.html

Obasanjo: +1 on MustUnderstand: http://www.imc.org/atom-protocol/mail- 
archive/msg01021.html

Snell: Drops <param/> idea: http://www.imc.org/atom-protocol/mail- 
archive/msg01020.html

Ruby: Also in favor of revisiting MustUnderstand: http://www.imc.org/ 
atom-protocol/mail-archive/msg01024.html

Snell: Good stuff on layering: http://www.imc.org/atom-protocol/mail- 
archive/msg01023.html

Powell: Properties view of PacePubControl: http://www.imc.org/atom- 
protocol/mail-archive/msg01031.html

Broyer: Pushes back: http://www.imc.org/atom-protocol/mail-archive/ 
msg01034.html

Rignalda: Feels that things like trackback *are* generic enough to  
standardize: http://www.imc.org/atom-protocol/mail-archive/msg01035.html

Sayre: Disagrees, thinks many not appropriate for standardization:  
http://www.imc.org/atom-protocol/mail-archive/msg01162.html

Bray: Highlights the Simmons post at http://inessential.com/ 
2004/11/18.php which called for standardization: http://www.imc.org/ 
atom-protocol/mail-archive/msg01163.html

Obasanjo: Questions Simmons' standing as a client developer: http:// 
www.imc.org/atom-protocol/mail-archive/msg01164.html

Sayre: Uses trackback as an example of something that's too shaky/ 
specific to standardize: http://www.imc.org/atom-protocol/mail- 
archive/msg01166.html

Broyer: good question "Could we please divide up the debate between  
*how* to apply "control
properties" and *which* ones should be in the protocol core?": http:// 
www.imc.org/atom-protocol/mail-archive/msg01177.html

Gregorio: proposes pure HTTP approach: http://www.imc.org/atom- 
protocol/mail-archive/msg01178.html