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

Peter Saint-Andre stpeter at jabber.org
Fri Jun 2 21:03:35 UTC 2006

Peter Saint-Andre wrote:
> Hash: SHA1
> Ralph Meijer wrote:
>> On Tue, May 30, 2006 at 01:54:43PM -0600, Peter Saint-Andre wrote:
>>> 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'>
>>>       <configure/>
>>>     </items>
>>>   </event>
>>> </message>
>> No, the idea is to include the configuration in the event, because that
>> is what the reserved item id was intended for. So more like this:
>>   <message>
>>     <event>
>>       <configure node='blogs/princely_musings'>
>>         ... JEP-0004 form in here ...
>>       </configure>
>>     </event>
>>   </message>
> Oh, I see. Yeah, that makes sense. Formerly we included the x:data form
> as a regular payload but you're right that the format you propose would
> be easier for a client to digest. Plus it doesn't require reservation of
> any ItemIDs. Good work, Mr. Co-Author. ;-)

I've added this to my working copy, using a <configuration/> element.

>>>> 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'
>>>     to='pubsub.shakespeare.lit'
>>>     id='create3'>
>>>   <pubsub xmlns='http://jabber.org/protocol/pubsub'>
>>>     <create node='announcements' type='collection'/>
>>>   </pubsub>
>>> </iq>
>>> 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?
>> Heh, yeah. I think we added those attributes to simplify the protocol
>> for PEP. For now I think we should only use forms, really. The 'problem'
>> is that we now have configuration data spread over attributes of
>> <create/> and the contents of <configure/> (whether as JEP-0004 form or
>> some other namespaced XML for custom implementations).
> In 1.7 we have things like this (current Example 100):
> <iq type="set"
>     from="pgm at jabber.org"
>     to="pubsub.jabber.org"
>     id="create3">
>     <pubsub xmlns="http://jabber.org/protocol/pubsub">
>         <create node="test"
> 	        type="collection"/>
>     </pubsub>
> </iq>
> So the 'type' attribute is already in use (we're not currently using a
> data form for that when creating a collection node).

Ralph, what do you think about this?


Peter Saint-Andre
Jabber Software Foundation

-------------- 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/20060602/7d6c1717/attachment.bin>

More information about the Standards mailing list