Subject: RE: [Simple] comments on rpids-01 - <relationship>

From: [email-masked]
Date: Mon, 30 Jun 2003 10:43:39 +0300

If I publish my secretary's (not that I have one :) phone presence as a tuple in my presence doc, then that tuple's information is out of date and stale as soon as that phone is idle, the secretary is on the phone, or any other scenario that changes the state of that device. I have no means of automating an publish update of that tuple.

The tuple I publish about my secretary's phone should only carry the mandatory PIDF elements, namely <contact> without any RPIDS extensions other that <relationship>. If a watcher wants a more accurate state of that phone, then they better subscribe to the secretary's presence.

/Hisham

> -----Original Message-----
> From: ext Henning Schulzrinne [mailto:[email-masked]]
> Sent: Friday, June 27, 2003 6:46 PM
> To: Khartabil Hisham (NMP/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Simple] comments on rpids-01 - <relationship>
> 
> 
> [email-masked] wrote:
> 
> > Let me get things clear here: when the <relationship> element is
> > present, its only referring to the information in the <contact>. The
> > rest of the tuple presence information still belongs to the
> > presentity. What I'm trying to say here is that the 
> presentity is not
> > publishing presence info about another presentity. Is my
> > interpretation right?
> 
> Let me try to answer this indirectly. One view of "what is a 
> tuple" is 
> that it is effectively an extended advertisement of my 
> reachability. I 
> can choose to publish a single Contact and have that contact 
> figure out 
> what is the best person/device/service to reach or I can 
> publish a wider 
> range of devices, services and interfaces and leave more of 
> the decision 
> to the watcher. I think there's value in both approaches; a single 
> presentity may even choose to publish different views to 
> different watchers.
> 
> Thus, just like my assistant can register under my AOR and receive my 
> phone calls in my absence (subject to authorization, policy, etc.), I 
> should be able to export this information to the watcher if I 
> prefer to 
> give the watcher more information and control.
> 
> Thus, consider my assistant as an 'extension' of my 
> presentity. This is 
> not fundamentally different than me including my secretary's phone 
> number in my vCard or listing it as a device tuple. The 
> <relationship> 
> element simply makes a property of that tuple explicit and 
> thus allows 
> better choices.
> 
> I would imagine that this tuple would have a low q value, 
> unless this is 
> really the first Contact that I want a watcher to communicate with.
> 
> It is up to the composer and the rules it has to limit the 
> publication 
> of this information; this is no different than limiting the 
> exposure of 
> my cellphone (or somebody else's cellphone...).
> 
> Henning
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 30 Jun 2003 21:47:34 -0400

[email-masked] wrote:

> If I publish my secretary's (not that I have one :) phone presence as
> a tuple in my presence doc, then that tuple's information is out of
> date and stale as soon as that phone is idle, the secretary is on the
> phone, or any other scenario that changes the state of that device. I
> have no means of automating an publish update of that tuple.

There are two cases of interest:

(1) The presentity knows about the existence of a secretary, but doesn't 
keep track of his or her status. In that case, I agree that only the 
minimal information should be published. This is not all that different 
from publishing information about my home phone, say - I generally don't 
know if somebody is using it or if somebody is at home who might take a 
call.

(2) There is a composer that is instructed to include my assistant's 
status in my reachability information and thus this information is as 
accurate as if somebody had subscribed directly to the assistant. This 
requires policy alignment, i.e., an agreement with the person that I'm 
allowed to tell anybody I choose to about this person's status. 
(Probably realistic for assistants; probably a bad idea for colleagues 
that 'cover' for me.)

In general, my feeling is that it's good policy to only publish minimal 
information and require watchers to subscribe directly to that entity if 
they want more details. I don't think it is necessary to make this part 
of a protocol definition.

Side note: Compared to the alternatives, these policies are relatively 
easy to implement. Once you start relying on forking, things get rather 
messy. For example, for the assistant case, a reasonable policy is that 
the status of the assistant is only available if you subscribe to the 
principal or that subscriptions that are approved by the principal 
include a subscription permission to the assistant (more likely). This 
is trivially done in this manner, but rather hairy, with lots of 
undefined protocol operations, otherwise.

> 
> The tuple I publish about my secretary's phone should only carry the
> mandatory PIDF elements, namely <contact> without any RPIDS
> extensions other that <relationship>. If a watcher wants a more
> accurate state of that phone, then they better subscribe to the
> secretary's presence.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 30 Jun 2003 21:47:34 -0400