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

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 4 Jul 2003 13:07:43 -0500

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

Well, that's why I asked if it's an AoR - if it looks like
sip:[email-masked], then there's at least a strong hint that
this is not Bob's own address. If it's sip:[email-masked], or some other
contact address (even a GRUU), it might not be so obvious. So it isn't clear
to me that baseline PIDF implementations will be able to trivially determine

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

There are alternatives that might also work, such as having separate
<presence> documents for the two presentities whose presence is represented.
In that instance, it is a surprise to neither the baseline PIDF nor RPIDS
watcher that 'related' presence information represents someone else.

[snip]
> 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).

Agreed, which is why receiving two presence for separate entities might be
preferable.

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

The point being that 'fill-ins' have their own devices, which do not belong
to or describe the person being filled-in for.

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

That's one way things could turn out. Or, we could provide an alternative to
that in which things are more explicit and compatible - implementers and
users could of course disregard the standard, but at least we did our best. 

Anyway, I don't think that this is the intended use of multiple tuples for a
presentity - I think that originally, multiple tuples were intended to
indicate multiple means of contact (URI schemes) for the same presentity,
whether that entailed multiple devices, interfaces, or what have you.

[snip]
> 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.
> 

Right. I think it is useful to view this as a general SIP problem: that
there can be an AoR that has one or more support AoRs (as opposed to
devices) registered behind it, and that consequently it might be useful to
supply a parameter that says how the parties behind such support AoRs are
related to the primary AoR.

It might be useful for a normal user agent to be able to look at a
redirection when such callee caps appear and for the user to decide "well,
no, I don't want to talk to any of Bob's family members".

> > 
> > 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.
> 
> I still don't see how this breaks compatibility with baseline PIDF.
> 

Because you have an entity tag saying 'this is presence for Bob' when some
tuples underneath provide presence for someone else. There is no requirement
that we organize presence documents in such a way that someone else's
presence can appear in Bob's <presence> document - it is this notion that I
think breaks compatibility with baseline PIDF (in which it's a safe
assumption that tuples describe the presentity named in the 'entity' tag).
If there were such a requirement, it might motivate <relationship> as it
stands, agreed. But I think the real, underlying requirement is just that
you can subscribe to someone's presence and receive presence for related
parties. That underlying requirement can probably be satisfied for SIP in
other ways, including redirecting SUBSCRIBEs to multiple targets.

Jon Peterson
NeuStar, Inc. 

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

---

From: [email-masked]
Date: Mon, 14 Jul 2003 11:46:20 +0300

> -----Original Message-----
> From: ext Henning Schulzrinne [mailto:[email-masked]]
> Sent: Sunday, July 13, 2003 5:21 PM
> To: Jonathan Rosenberg
> Cc: Peterson, Jon; Simpletons (E-mail)
> Subject: Re: [Simple] comments on rpids-01 - <relationship>
> 
> 
> Jonathan Rosenberg wrote:
> 
> 
> > I'm not sure that works for presence, though. That is, I 
> don't think you 
> > could generate a SUBSCRIBE with appropriate caller preferences 
> > parameters to just get the presence of the executive and not their 
> > support staff.
> 
> Also, the authentication issues can get rather messy. It's 
> one thing to 
> find the secretary, it's another to convey "this random 
> person who you 
> have never met isn't a stalker but somebody where your boss has asked 
> you allow subscription (but only for as long as the boss is 
> willing to 
> be watched and no longer)". It's a lot easier if a single 
> trusted entity 
> subscribes to the <relationship> party.

Can't this be done by sharing an authorisation list between the secretary and her boss?

/Hisham

> 
> In my model, the boss (or her composer) subscribes to the 
> secretary, who 
> might limit that subscription to working hours. If the 
> secretary stays 
> late, he might then allow the boss later access. This all 
> works pretty 
> naturally, without the elaborate machinery that you'd need otherwise. 
> (You don't want the boss to be able to override all subscription 
> decisions, for example, so you can't just give her access to the 
> authorization database.)
> 
> 
> > 
> > I'm in agreement with Jon that we don't want to populate 
> Joe's presence 
> > document with tuples that really describe Bob, just because 
> Bob is Joe's 
> > assistant. But, Bob does represent a point of contact for 
> Joe, and I 
> > think that information itself is useful presence.
> 
> I think this is somewhere in-between. We have other entities, such as 
> voicemail systems, that are valid contacts and tuples. What is the 
> principal difference between my voicemail box and the 
> executive version, 
> with a live human being answering it?
> 
> 
> > 
> > So, how about this. We could mandate that when a contact 
> contains the 
> > <relationship> element, the tuple has no other information 
> except for 
> > open/closed. The <relationship> element can have an 
> attribute which says 
> > where to go to get the acutal presence for that user:
> > 
> >  <tuple id="7c8dqui">
> >           <status>
> >             <basic>open</basic>
> >             <contact>sip:[email-masked]</contact>
> >             <ep:relationship
> >          
> pres="pres:[email-masked]">assistant</ep:relationship>
> >           </status>
> >           <note>My secretary</note>
> >         </tuple>
> > 
> > This way, there is never actual presence information for 
> the secretary - 
> > only a reference to obtain it. But, the secretary is listed 
> as a contact 
> > point.
> 
> This seems useful in some circumstances, but I'm afraid it 
> doesn't solve 
> the authorization problem I mentioned above.
> 
> 
> 
>