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: Henning Schulzrinne <[email-masked]>
Date: Sat, 28 Jun 2003 12:18:14 -0400

> <contact>s in tuples containing a <relationship> than diverge from ordinary

Doesn't matter if it is an AOR. Clearly, if it's a tel URI, it will be 
hard to tell if its your personal line, your secretary or the front 
desk. I was thinking of SIP URIs, as in sip:[email-masked]

Again, the crucial part is that listing this additional contact 
explicitly rather than 'hiding' it behind the presentity's Contact 
address is never any worse in terms of surprise for the non-RPIDS 
watcher and with the <relationship> label is always better for the RPIDS 
capable watcher.

> filtering on <relationship> if I don't understand <relationship> anyway.

The problem is that there is no easy and intuitive way to let you know 
that part of my presence is my assistant (whom the watcher does not know 
and has not met). In real life, we do treat other people as temporary 
'fill-ins' for ourselves, making an 'is this expected to be useful' 
calculus. When I subscribe, I don't get to explicitly ask to "don't send 
me all your devices, I only want the ones I care about". Given how 
things work today, what will happen is that people will simply add their 
assistant to their presence document with or without the <relationship> 
label since that's probably one of the more useful applications of 
having multiple tuples for one presentity.

> warranted as a general SIP function, if perhaps one that would be especially

I agree that a callee attribute in draft-ietf-sip-callee-caps might well 
be useful. We have the notion of 'attendant', but this simply says that 
the call will be answered by some other party, not that this Contact URI 
*is* an attendant.

> that's likely to be compatible with baseline PIDF.

I still don't see how this breaks compatibility with baseline PIDF.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 28 Jun 2003 12:18:14 -0400