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

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 27 Jun 2003 22:30:20 -0500

> The surprise can occur even with the AOR, if you suddenly reach the 
> secretary. This is quite common in any system that has any form of 
> redirection of where phones are sometimes picked up by people other than 
> the party which advertised that number. 

Agreed, no question.

> Thus, this doesn't seem to add 
> any more confusion for 'naive' watchers than hiding the secretary behind 
> the same AOR. If anything, the second AOR, with a different name, may 
> provide a better clue to the non-RPIDS watcher that this is a different 
> person, more so than just having the proxy route the MESSAGE to another 
> person automatically.

What second AoR? You mean, one in the <contact> URI? Is that URI necessarily
an AoR? If not, then there's no guarantee it will be distinguishable by a
human from a plausible contact address for the 'primary' presentity. If it
is necessarily an AoR, that creates some requirements for publishing using
<contact>s in tuples containing a <relationship> than diverge from ordinary
behavior. 

I guess I have a hard time seeing why, if you're receiving presence
information from two presentities, you shouldn't receive two different
chunks of <presence>. The point is that I may not have any interest in the
admin's presence - I asked for the executive's presence. I should have the
option of not receiving the admin's presence when I ask for the executive's
- and I don't think I should have to anticipate this with SUBSCRIBE filters
on <relationship>, or something (though I suppose such filters could be
applied reactively, and that's better than nothing). I certainly can't do
filtering on <relationship> if I don't understand <relationship> anyway.

Not that I've thought this through in great detail, but I think this would
be less confusing if watchers received different <presence> documents (with
different AoRs in the 'entity' attr) for 'related' persons, possibly by
having servers redirect the presence SUBSCRIBE to multiple targets.
Applications might then choose some sensible way of displaying that the
SUBSCRIBE was redirected to multiple targets, or pop-up to the user to ask
if it's worth subscribing to each given party. This may be a SIP specific
solution (I don't know how many other presence protocols support the concept
of redirection), but then again, we have set out to solve these problems for
SIP applications - I see no problem with relying on baseline capability.

I would be more comfortable with the use of something like <relationship> in
that context, perhaps as a <presence>-level subelement, to explain how one
presentity is related to another presentity if you end up doing multiple
SUBSCRIBEs because of a redirection. It would be better still if there were
a 'relationship' callee capabilities tag that could be received in a SIP
redirection - given the general case with an admin registering under an AoR
for non-IM&P applications like telephony that you raise above, it would seem
warranted as a general SIP function, if perhaps one that would be especially
useful here.

The bottom line, from my perspective, is that <relationship> is essentially
a selective override of the 'entity' attribute of <presence> - not something
that's likely to be compatible with baseline PIDF.

Jon Peterson
NeuStar, Inc.

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

---

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
> 
>