[Standards] private storage revisited

Peter Saint-Andre stpeter at jabber.org
Fri Jul 6 20:19:02 UTC 2007


Ian Paterson wrote:
> 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.

One nice thing about the NodeID hack is that the client knows
immediately what the access model (e.g., if the node already exists and
it receives data published to that node by another resource).

> 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'>

Haven't we been down this road before? See for instance Example 5 here:

http://www.xmpp.org/extensions/attic/jep-0163-0.2.html

Yet we moved away from that. See here (Ralph objecting to the 'access'
attribute):

http://mail.jabber.org/pipermail/standards/2006-May/011315.html

And further discussion:

http://mail.jabber.org/pipermail/standards/2006-May/011383.html
http://mail.jabber.org/pipermail/standards/2006-May/011414.html
http://mail.jabber.org/pipermail/standards/2006-May/011417.html
http://mail.jabber.org/pipermail/standards/2006-June/011496.html
http://mail.jabber.org/pipermail/standards/2006-June/011572.html

This is essentially publish+configure all over again, but limited to the
access model.

> 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='juliet at capulet.com/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.

Right.

It's publish+configure. Again. Do you think we'll make more progress
this time?

Peter

-- 
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7354 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070706/e9a641e1/attachment.bin>


More information about the Standards mailing list