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: Jonathan Rosenberg <[email-masked]>
Date: Sun, 13 Jul 2003 09:59:25 -0400

> no, I don't want to talk to any of Bob's family members".

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.

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.

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.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 13 Jul 2003 09:59:25 -0400

<tuple id="7c8dqui">
           <status>
             <basic>open</basic>

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 13 Jul 2003 10:21:03 -0400

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 

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.

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?

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 13 Jul 2003 10:21:03 -0400

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 14 Jul 2003 08:58:54 -0500

[...]
> parameters to just get the presence of the executive and not their 

Right; when we first came up with the notion of the <relationship>
element, our thoughts were along the lines of the primary presentity
being busy (present, but busy and not-interruptible), and having a
different person act as a temporary surrogate.  The canonical
example Dr. Schulzrinne provided was a professor being in an oral,
and thus not interruptable for the duration of the exam except
by the holder of the <relationship> element.  No mention was made
about the presence status of the AoR in the <relationship>
element.  And I believe this suffices, and even mirrors the real-
world (boss away, secretary takes phone calls, but may be out to
lunch).

> think that information itself is useful presence.

Agree.

> where to go to get the acutal presence for that user:
[...]
> only a reference to obtain it. But, the secretary is listed as a contact 

Concur.

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 14 Jul 2003 08:58:54 -0500

Agree.

[...]

Concur.

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 14 Jul 2003 09:14:48 -0500

Henning Schulzrinne wrote:
[...]
> with a live human being answering it?

The latter can actually assess a situation and decide if it is
worth interrupting the presentity.  My wife calling my secretary
in a harried tone is apt more to get a favorable response from
my secretary then she is from a voicemail box which will impassively
ask it to press "2" for an emergency.  Likewise, anyone calling
my voice mailbox is given the opportunity to interrupt me under
the guise of an emergency; folks calling my secretary won't be
so fradulent in their purpose (one hopes).

Regards,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 14 Jul 2003 09:14:48 -0500

Regards,

- vijay

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 14 Jul 2003 10:30:00 -0400

Vijay K. Gurbani wrote:

You nicely describe the properties of a good secretary and how it 
improves upon the inanimate version, but how does this relate to the 
"can't be part of another presence document" question?

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 14 Jul 2003 10:30:00 -0400

Vijay K. Gurbani wrote:

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 14 Jul 2003 10:08:25 -0500

> "can't be part of another presence document" question?

Unless I got my threads mixed, I believe we were discussing if
we should put presence status of secondary AoRs in a presentity's
document.

Jonathan proposed a means of including a reference to obtain
the secretary's presence so we don't populate the presentity's
document with presence status of alternative contacts
(http://www1.ietf.org/mail-archive/working-groups/simple/current/msg01151.html),
which I think is reasonable (modulo the security aspects).

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 14 Jul 2003 10:08:25 -0500

- vijay

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 14 Jul 2003 13:50:08 -0400

> which I think is reasonable (modulo the security aspects).

Are you agreeing or disagreeing with my authorization concerns? I don't 
think they are just 'modulo' concern.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 14 Jul 2003 13:50:08 -0400

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 14 Jul 2003 13:01:51 -0500

> think they are just 'modulo' concern.

No, they are not.  And yes, I do agree with your authorization
concerns.

In a separate email thread, I propose using URI leasing to address
some of the authorization concerns.  I think we will need more
discussion on that aspect to see if it is feasible or not.

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 14 Jul 2003 13:01:51 -0500

- vijay