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

From: [email-masked]
Date: Thu, 27 Feb 2003 18:11:48 +0200

Hi,

If we think that there is some value (as at least I do) in having some kind of 'hard state' in the absense of any published information (which needs to be garbage collected), and we think that SIP PUBLISH is not the right way to manage it, should we consider it being in the scope of Data Manipulation (we have such a mechanism on our charter)? The user could set the data whenever, and overwrite it using SIP PUBLISH. Uploading a PIDF document should be good enough. Assignment of tuple ids and labels would of course need to be consistent with SIP PUBLISH.

I guess Jon's idea is to have some default response for all AoRs/users served by a particular PA, whereas I think it should be a per user thing. I would like to have a tuple describing my e-mail status (basically always open, but the note might indicate that messages won't be read until Monday). It has been argued that this might not be part of presence, but what else would be as nice a way of letting people know this type of information.

Markus

> -----Original Message-----
> From: ext Peterson, Jon [mailto:[email-masked]]
> Sent: 26 February, 2003 21:55
> To: Niemi Aki (NMP/Helsinki); Isomaki Markus (NRC/Helsinki); Kiss
> Krisztian (NRC/Tampere); [email-masked]
> Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00
> 
> 
> 
> The argument that there is some 'hard state' that exists in 
> the absence of
> any publications (namely, the state or document expressing 
> that the user is
> away) is in some ways attractive, yes. You are correct that a 
> registrar
> doesn't supply null contact addresses or something when the 
> user in question
> has no registration, but rather provides a specific failure 
> response. Of
> course, the events framework has a different semantics - 
> subscriptions are
> accepted when there is currently no published presence 
> information for a
> user. Sending a failure response wouldn't be workable.
> 
> There are, however, a couple of NOTIFY syntaxes that might 
> communicate that
> there is no available presence information. One is that a 
> NOTIFY might not
> contain any body. Another is that the presence agent or 
> compositor invents a
> simple tuple that contains a status of CLOSED. The latter 
> option may sound a
> lot like hard state, whereas the former does not. Whether or 
> not the latter
> option is really 'state' though is debatable - almost an 
> implementation
> question. Having a default response to queries in the absence 
> of state does
> not, in and of itself, constitute state in my opinion. It 
> does not require,
> for example, per-user tables in memory that have some 
> specific values, as
> far as I can imagine how it would be implemented.
> 
> Jon Peterson
> NeuStar, Inc.
> 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple