[Standards-JIG] PEP and Pubsub Questions

Peter Saint-Andre stpeter at jabber.org
Wed Apr 5 18:49:34 UTC 2006


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

Matt Tucker wrote:

> PEP questions: 

I'm skipping these for now. I have a bunch of PEP stuff to incorporate
but I'm waiting until JEP-0060 is settled.

> Pubsub questions:
> 
> 1) Should at least one item element be present in the retract element?

When attempting to retract an item, yes. I've added an error case about
that (bad-request + item-required).

Also I changed the error condition in example 90 to be forbidden, since
not-authorized is not consistent with the other examples.

> And if no item is included then return an "item-required" error? The
> schema currently allows 0-unbound items elements. 

The schema is correct so that we can handle notification of item
deletion, see the very last example at
http://www.jabber.org/jeps/tmp/jep-0060-1.8.html#publisher-delete

> As an aside, what
> about adding a comment to the "7.2 Delete an Item from a Node" saying
> that it's possible to include many items and in that case the
> notification of deletion should include many retract elements.

Hrm. Is it advisable for us to support batch deletion? I think not.

> 2) If a retract element includes many items, but one or more items are
> invalid, should the retract operation be ignored and not delete any of
> the requested items? 

See above, I'm not a big fan of batch deletion. I'd prefer to make that
operation atomic. We don't allow batch publishing, why allow batch
deletion? I've provisionally changed the scheme to reflect that.

> 3) Since nodes that don't persist their items may have one cached item
> and that item may have an ID, why is it that "7.2 Delete an Item from a
> Node" defines the following failure reason "The node does not support
> persistent items"? I would expect to return a failure error if the node
> is transient and payloads are not being included in event notifications,
> since nodeIDs are not being used in that case.

See below.

> 4) Should we add the failure reason "Request did not specify a node" to
> "7.2 Delete an Item from a Node" and return a "nodeid-required" error?
> Same comment applies to "7.1. Publish an Item to a Node".

Done.

> 5) What error should the pubsub service return when a retart element
> contains an item element with no id attribute? Should we create the
> pubsub error "itemid-required" and return that error? It's an edge case,
> but id is an optional item attribute so this case may potentially
> happen. :)

That's another form of "did not specify an item" but I will make that
clear in the error case.

> 6) What error should the pubsub service return when a retract operation
> is attempted on a collection node? Does this case fall into the "The
> node does not support persistent items" or should we use a specific
> error?

Yes, that was the idea behind "does not support persistent items".

> 7) Example 94 is including a retract element inside the items element.
> The schema does not define this case. 

The namespace is 'http://jabber.org/protocol/pubsub#event' for those
notifications and the schema for that namespace includes the following:

  <xs:element name='item'>
    <xs:complexType>
      <xs:choice minOccurs='0'>
        <xs:element name='retract' type='empty'/>
        <xs:any namespace='##other'/>
      </xs:choice>
      <xs:attribute name='id' type='xs:string' use='optional'/>
    </xs:complexType>
  </xs:element>

> 8) When a subscriber is subscribed to a collection node using
> pubsub#subscription_type of type "items", should the subscriber be
> notified of items being deleted? Currently the JEP only mentions
> notifications of new published items.

That's determined by the nature of the originating node. If the
originating node sends notifications, the collection node should pass
them on through. I've modified the text about collection nodes
accordingly (pass through notifications, whether generated by publishing
an item or deleting an item).

> 9) Should SHIMs (Stanza Headers and Internet Metadata) be included in
> "Example 94. Subscribers are notified of deletion" if the node supports
> multiple subscriptions?

Ah, I think so. We still need to specify when SHIMs are to be included.
I'll look at your previous mail about that and post a separate message.

The CVS diff resulting from the changes described above is:

http://www.jabberstudio.org/cgi-bin/viewcvs.cgi/cvs/jeps/0060/jep-0060.xml?r1=1.106&r2=1.107

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

iD8DBQFENBE+NF1RSzyt3NURAgiHAKCpI04xbtZr/Ulc9xxMv0KYuWQUvACgmGE/
RV+mivY2YcEw6OluOLUyUss=
=/aQC
-----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/20060405/951f57ef/attachment.bin>


More information about the Standards mailing list