[Council] some comments about end of meeting

[Ian Paterson]

Hi all,

Today it might look like a separate iq:private with hardcoded empty 
whilelist will fix the contentious p+c issues. But perhaps people only 
see it that way because the existance of the old iq:private makes the 
many use cases obvious, while the fact that personal publishing is not 
deployed means we have very few examples of protocols that use it (only 
XEP-0189?). However, IMHO, as soon as PEP for publishing is deployed, we 
will have an explosion of standard and proprietary uses cases that will 
probably exceed those for iq:private+. These cases will expose the exact 
same p+c issues (except there will be no need for drop-in replacements 
for legacy code).

My other concern with a separate iq:private+ spec is that it won't be 
implemented so quickly as if it were included in the PEP document.


Ideally I'd like to see an updated PEP. But *if* that were not an 
option, I'd adopt the 060 on a JID approach, and *retract* PEP - since 
if PEP exists that will distract developers from 060 on a JID (some 
servers would offer 060 and others only PEP - which doesn't help client 
developers).

If we were to throw away PEP then I'd like to see all of PEP's "client 
simplification magic" incorporated into 060 (auto node creation etc).

That said, I'm conscious that implementations of PEP already exist, and 
there are none for "060 on a JID". Although Chris and Ralph might be 
ready to implement "060 on a JID" right now, would the developers of the 
popular open source and commercial servers complete that work anytime 
soon? The close integration with presence means that, AFAICT, 
implementing "060 on a JID" will be much more difficult than simply 
importing existing 060 code into the core servers. (Has 060 ever been 
implemented in Erlang?) So "060 on a JID" is probably best left as a 
recommended future upgrade path for PEP. In which case IMHO we need an 
appropriately-featured PEP...


I'm very strongly against leaving PEP as it is because it doesn't offer 
sufficient *publishing* functionality to be as useful as the *personal* 
subset of 060 should be. For example, how can we redesign XEP-0189 with 
PEP as is? (Please stop and think about that now.)

While I'm in violent agreement that PEP is a stepping stone to 060 on a 
JID, IMHO without "multiple persistent items" PEP does not hit the sweet 
spot of providing the most useful functionality while eliminating a 
significant part of the work required to implement the full 060 spec. 
(And In order to provide the iq:private replacement functionality (POP), 
developers are going to have to implement "multiple persistent items" 
anyway.)

- Ian