[Standards] adding body as RECOMMENDED field for PEP-protocols?

Ralph Meijer jabber.org at ralphm.ik.nu
Fri Jun 22 19:29:27 UTC 2007

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

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



More information about the Standards mailing list