[Standards-JIG] JEP-0060: 1.8pre13

Peter Saint-Andre stpeter at jabber.org
Wed Apr 12 15:41:20 UTC 2006


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

Ralph Meijer wrote:
> On Fri, Apr 07, 2006 at 11:08:13AM -0600, Peter Saint-Andre wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Based on the list messages I sent yesterday (barejid attribute, etc.)
>> and IM discussions with Gaston Dombiak before he released Wildfire 2.6
>> (now with pubsub support), I have upped the rev on JEP-0060 to 1.8pre13:
>>
>> http://www.jabber.org/jeps/tmp/jep-0060-1.8.html
>>
>> The CVS diff is here:
>>
>> http://www.jabberstudio.org/cgi-bin/viewcvs.cgi/cvs/jeps/0060/jep-0060.xml?r1=1.110&r2=1.115
> 
> I think the change to line 5586, where minOccurs='1' for {..#event}items
> is wrong. Using table 5, the case left-bottom (transient/notification)
> requires an items element in the notification to carry the node id,
> obviously without any items inside.

Fixed.

> The text in table 5 for this case is wrong because it refers to the
> wrapper in the event, not in the publish action (there is no 'items' in
> there).

Yes, there are two aspects: what the publish includes and what the
notification includes. I'll clarify that.

> The change to 'retract' seems ok, though. I don't think retracting using
> the same case (transient/notification, so without any items) is useful.
> It seems to me that someone using a node configured this way will want
> to convey some property changed and send out a notification. I don't
> think you can conceptually undo that. But I could be wrong here.

That seems right.

> Going on with the same use-case, the 'SHOULD' for including items in publishes
> seems wrong. It depends on the node's configuration. It might be useful
> to have examples for the 4 different 'modes'.

Agreed, I'll add those.

> A note for batch publish and deletion should be added that the action
> MUST either succeed for all items /or/ fail for all items.

Right, will add.

> The note about example 85, concerning multiple namespaces is vague. If I
> publish a atom entry, it most probably will contain XHTML inside. So,
> the item will have more than one namespaces used. So, I suppose you
> wanted to convey that there MUST NOT be more than one child element
> of <item/> and leave it at that.

Yes, I *think* that's right. IIRC we had some issue with including SHIM
headers, but I'll look into that again.

> Regarding 'barejid', I think the result of the chat between stpeter and
> me [1] is that this will be removed again.

Yes. Unless Gaston replies with a knock-down argument against our
conclusion. :-)

> I would have loved to have no such restriction at all, to avoid a new
> container element for grouping related data. This has been discussed in
> the past, but I couldn't find the discussion in the archives.

Yes, that was a long time ago. It may have happened at the IRL meeting
in Munich in 2002. (Speaking of which, we need more -- i.e., some -- IRL
meetings. I'm going to work on that for 2007...)

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

iD8DBQFEPR+gNF1RSzyt3NURAqKqAKDfP4FAUG2/Y0myNHqNhUaoWBlI1QCfQpOw
7uoA/ff0SJvFvWhFtmEAwZM=
=kVSX
-----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/20060412/98b7128a/attachment.bin>


More information about the Standards mailing list