[Standards-JIG] JEP-60 Item id for node configuration change notifications

Peter Saint-Andre stpeter at jabber.org
Tue May 30 19:54:43 UTC 2006

Hash: SHA1

Ralph Meijer wrote:
> On Wed, May 10, 2006 at 01:14:34PM -0600, Peter Saint-Andre wrote:
>> [..]
>> I'm not sure why Peter did it that way, since that's the only reserved
>> ItemID as far as I can see. However, I don't immediately see a better
>> approach, so I think a service would in fact need to reject publication
>> requests that specify an ItemID of "configuration" (i.e., reserve that
>> ItemID for generation only by the service). I'll clarify that in the text.
> I dislike reserved ItemIDs. 

I don't like them, either.

> Can't we add a <configure/> to <event/> in
> the #event namespace?

Like this?

<message from='pubsub.shakespeare.lit' to='francisco at denmark.lit' id='foo'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='blogs/princely_musings'>

> Also, I'm still not sure about the access attribute to the <configure/>
> element in the other namespaces. I know it would be easier for PEP, but
> I don't know if avoiding forms there is needed/a good idea.

I don't see any great harm in the 'access' attribute, just as I don't
see any great harm in the 'type' attribute in an example like this:

<iq type='set'
    from='bard at shakespeare.lit/globe'
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <create node='announcements' type='collection'/>

That is, we could do that with a data form that includes the correct
value of the "pubsub#type" field. But do we gain anything by removing
the 'access' and 'type' attributes here and using data forms instead?


- --
Peter Saint-Andre
Jabber Software Foundation

Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

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

More information about the Standards mailing list