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

Fri Jun 22 14:29:27 CDT 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
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