On Fri, 2007-06-22 at 02:03 +0530, Mridul Muralidharan wrote: > Joe Hildebrand wrote: > > > > On Jun 14, 2007, at 8:45 PM, Mridul Muralidharan wrote: > > > >> You are right, application payloads getting sent (as messages) should, > >> imo, not contain <body /> unless it expects to communicate that to the > >> user. > >> In a lot of cases for pep typically, it would be consumed by the > >> client to appropriately add meta-data for the contact - it just would > >> not make sense to show the plain text info to user. > >> > >> That being said, we should not preclude addition of body, it might > >> make sense for usecases (maybe where pep is more used like pubsub with > >> infrequent updates ?) > > > > A body inside the namespace for the particular PEP node is perfectly > > fine, if it makes sense for that namespace. If a client doesn't know > > about that namespace, it's not going to add the +notify capability, nor > > subscribe to the node directly, so the notification should never come to > > a client that doesn't know how to process it; "process" here may mean > > just pull out the body element in the appropriate namespace and display > > it in some interesting way. > > > > --Joe Hildebrand > > > > > > user subscribes to a pep node, and later on a different resource comes > along on a different client which does not understand pep. > So you can have pep data getting pushed to resources which do not > understand pep.
What you say does not apply to the case that Joe lays out. Subscriptions in the case of sending caps that represent a set of features that includes a namespace with a "+notify" suffix, are not persistent. As soon as the caps change, the resource is 'unsubscribed' again. XEP-0115 doesn't explicitly define what happens on unavailability presence, but I assume it should mean the feature not being offered any longer, resulting in a unsubscribe. So in this very case, sending along body would be quite useless. I assume here that a client sending caps to the effect of wanting to receive notifications for a particular namespace, does actually support it. As for sending bodies along with other namespaced data should result in the following behaviour by clients: if the known subelements of the element yield a richer presentation (like XHTML, but also various PEP/pubsub events) that is known by the client, it should do show that. If there is no such element (known to the client), it should show the body. -- Groetjes, ralphm
