Peter Saint-Andre wrote:
Whenever a client publishes the first item to a node that ends in
"+[accessmodel]", the pubsub service MUST create the node with a default
access model equal to the specified model (that is "open" or "presence"
or "roster" or "authorize" or "whitelist"). [1] For such a node, the
access model MUST remain fixed and a pubsub service MUST return an error
if the node owner tries to change it.
[1] In fact "roster" doesn't make sense here since you need to specify
the roster group. And BTW the list for "whitelist" must start out empty,
i.e., only the node owner can publish or subscribe.
I think I agree with everything above except the proposed syntax. *If*
we agree on the functionality, then IMHO it *should* be trivial to come
up with a more appropriate syntax.
I strongly disagree with overloading the node attribute with the access
model. IMHO, mixing an identifier and a configuration parameter into the
same attribute would be a horrible (and unnecessary) hack.
Instead of:
<publish node='http://jabber.org/protocol/activity+whitelist'>
I could live with this syntax:
<publish node='http://jabber.org/protocol/activity'
access_model='whitelist'>
However, IMHO, the following example stanza would "fit" better with the
rest of the protocol. That would make it easier for developers, since
they could simply reuse their existing <configure/> element processing code:
<iq from='[EMAIL PROTECTED]/balcony' type='set' id='create-presence'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='http://jabber.org/protocol/activity'>
<item>
<activity xmlns='http://jabber.org/protocol/activity'>
<relaxing>
<partying/>
</relaxing>
<text xml:lang='en'>My nurse's birthday!</text>
</activity>
</item>
</publish>
<configure>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/pubsub#node_config</value>
</field>
<field var='pubsub#access_model'>
<option><value>whitelist</value></option>
</field>
</x>
</configure>
</pubsub>
</iq>
I stress that the functionality associated with the above example would
be absolutely identical to that which Peter described above.
- Ian
P.S. I put Ralph on copy because, although he has been very busy
recently, we're not going to move forward on this without his input and
eventual acceptance (he's both a principle author of the PubSub protocol
and a council member).
