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

From: [email-masked]
Date: Fri, 27 Jun 2003 17:25:08 +0300

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?

Regards,
Hisham

> -----Original Message-----
> From: ext Henning Schulzrinne [mailto:[email-masked]]
> Sent: Friday, June 27, 2003 6:10 AM
> To: Peterson, Jon
> Cc: Simpletons (E-mail)
> Subject: Re: [Simple] comments on rpids-01 - <relationship>
> 
> 
> Peterson, Jon wrote:
> 
> > I'm unsure about <relationship> because it encourages 
> presentities to
> > publish their presence under another entity's AoR (and for 
> compositors to
> > accept such publications) - given that this would include 
> family members,
> > associates, and the like, it seems to give rise to fairly 
> complicated
> > authorization logic in compositors. I wonder, though, if 
> there aren't other
> > solutions to this problem - like, giving out a group alias 
> as your AoR, or
> > something, that includes any other persons whose presence 
> is 'equivalent' to
> > yours as necessary. It seems weird to include presence 
> information in a
> > <presence> document that doesn't below to the resource 
> identified by the
> > 'entity' attribute of the <presence> document. Most 
> importantly, I'm not
> > sure that this is very backwards-compatible with baseline 
> PIDF - if you
> > don't understand the <relationship> element, you might be 
> unpleasantly
> > surprised when you IM one of the contact addresses in the associated
> > <tuple>. I agree that something that provides this 
> capability (associating
> > presence from one party with that of another) would be 
> useful, but I'm not
> > sure that it should be done as a PIDF extension.
> 
> 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. 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.
> 
> 
> 
> 
> _______________________________________________
> 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: Fri, 27 Jun 2003 11:45:33 -0400

[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