Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 5 Mar 2003 17:48:05 -0500

A couple notes below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, March 05, 2003 3:02 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00
> 
> 
[snip]
> 
> Yes, I'm assuming that the composer supports the default 
> state, or fallback status concept. I'm also stating a 
> requirement, that the PUBLISH mechanism should support 
> setting the default status - I'm not saying all composers 
> must support this concept, or support setting the default 
> status with PUBLISH. My point is that the default status is 
> not that different from "live" status, so that we would need 
> to defer the problem to another interface or work item.
> 

I think it is reasonable for there to be a requirement for compositors to
have some default behavior for notifications in the absence of current
presence information about a user. We should include that; in fact, an
earlier version circulated to the pub design team had text along those
lines, but we couldn't arrive at the right wording for it. I think we're in
a better position to do so now, after some discussion.

The issue of how different it is from "live" status though is a bit more
difficult. A PIDF document can contain 0 tuples. A compositor might consider
this to be the 'base' document it holds for every user. Sending a tuple-less
PIDF document to watchers definitely, in my mind, communicates that no
presence information is currently available for the presentity. I'm not sure
why this default document would need to be modified by users.

> I would even argue, that what you say above also makes 
> assumptions about the system. It assumes that watchers 
> understand something about expiration of presence statuses, 
> which they don't by default. Expires of a PUBLISH can't be 
> mapped to the subscriptions of watchers, and a timestamp in a 
> presence document says nothing about expiration.
> 

Agreed that it is probably not advisable to reuse Expires to relay
publication durations to end users. Henning's RPIDS model has its own way of
expressing the duration of an individual tuple, which is ultimately a better
approach, I think.

[snip]
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple