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

Peter Saint-Andre stpeter at jabber.org
Wed May 31 20:18:42 UTC 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ralph Meijer wrote:
> On Tue, May 30, 2006 at 01:54:43PM -0600, Peter Saint-Andre wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> 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. ;-)

>>> 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).

Peter

- --
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

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

iD8DBQFEffoiNF1RSzyt3NURAq3BAJsF0EMNQFkKepJ9Hiz6gFKn689a7gCgmHhu
XqzlsOgq1vRQzD2z5sWNNJ0=
=UBQX
-----END PGP SIGNATURE-----
-------------- 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/20060531/4d521708/attachment.bin>


More information about the Standards mailing list