Subject: RE: [Simple] RPIDS: Capabilities in tuples and Caller Prefs

From: Ben Campbell <[email-masked]>
Date: 13 Mar 2003 13:08:52 -0600

I also apologize for coming in late to this converation, but here goes.
(I am responding the thread in general, rather than sending a bunch of
responses to individual emails.)

In general, I like Jonathan's approach. If for no other reason than it
is more philosophically aligned with a controversial informational RFC I
happen to like a lot. (3087). Actually, though, it allows a more general
approach than caller-prefs, in that I could provide a tuple contact that
acted as an entry point into a CPL script, or an application server of
some type. Maybe even a direct call to a voice mail box, as per the
examples in 3087.

But I do have a couple of concerns:

1) Why do we assume the PS is constructing the tuple contacts? Certainly
an implementation could do this, but they could also be published by a
device, couldn't they?

2) What about callers that are not using presence clients at all? Are
they left entirely out in the cold by this approach? Would we have to
maintain a caller-prefs based mechanism in parallel?

It almost seems to me that Jonathan's approach, allong with some markup
to indicate if the contact URI should be used "raw", or should have
caller-prefs parameters applied to it, could give the best of both
worlds.

On Thu, 2003-02-20 at 10:44, Rosen, Brian wrote:
> I'm glad we got back to this, as I really want to get closure.
> .... snip....
> > I think the actual problem, if any, is with the client. It is 
> > the server 
> > that gets to decide which of these models it wishes to use. 
> > The client 
> > must accomodate.
> > 
> > For us it is not a problem - you only publish one tuple, so 
> > to us it is 
> > just a single virtual device.
> Well, your client has to use caller preferences to influence
> what happens to the call, if he wants to do that.  If we don't
> make that work well, and clients won't implement it,
> we won't have good interoperability.
> 
> > 
> > I don't know if this is a problem to you or not. Clients need to be 
> > prepared to present information about multiple tuples to their users, 
> > and preferably provide the user with suitable courses of action on a 
> > per-tuple basis. This is more work than if there is but a 
> > single tuple. 
> > But I can think of some concise and convenient GUI interfaces 
> > for this
> It would be interesting to do some useability studies on this.
> 
> > 
> > > I'm not objecting to having a way to provide a device
> > > address if the principal wishes to.  I'm trying to
> > > figure out a way so that if the principal does NOT
> > > wish to provide device addresses, or even enumerate
> > > the devices he has, all watcher/UA implementations will 
> > > work pretty well. 
> > 
> > Where is the problem?
> Making the syntax of the (RPIDS) presence document and
> the syntax of caller preferences match enough to make
> influencing outcome obvious.  
> 
> Making the representation of data in one tuple rich enough
> to express the state of a presentity instead of the state
> of a device.
> 
> Brian
>  
> _______________________________________________
> 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: "Rosen, Brian" <[email-masked]>
Date: Thu, 13 Mar 2003 16:00:46 -0500

Boy, I'd really like to get closure on this.

The fundamental difference between this problem and the one
3087 deals with is that the target of the 3087 URI is very
explicit, and very precise, and it doesn't depend on any
called party preferences.  You deposit a message in
a voicemail.

Here, we have something quite different.  My presence
service offers some (possibly fascinating) information
about me, and you want to contact me.  The discussion is
how you influence how you contact me.  The point I keep
trying to maintain is that, unlike in 3087, I get to
choose if I let you get to my cellphone or not.  You can
ask for it, but I may not give it to you.

I cannot prevent anyone, nor would I want to, from giving
out the sip address (or E.164) of their cellphone.  However,
I would prefer to give out only my one-true AoR.  I would
prefer that (ideally) no one has the actual URI of my
cellphone except my home proxy (when I register it).  

Now, you could well know that I have a cellphone.  And when
you call me, you can ask to ring my cellphone.  I might
have rules in my proxy that allows you to get to my cellphone
from my AoR.  So, the subject at hand is how you influence
what device I answer on.  Isn't that pretty much what 
caller prefs is for?

Now, I'll admit that its entirely possible to come up with
some kind of naming convention that lets my presence system
and my home proxy have a set of made-up URIs that correspond
to a set of what I would call "caller preferences".  
That would match 3087.
Since it's not necessarily true that my home proxy is my presence
service, if they aren't the same then whatever presence hands out 
better be understandable to my home proxy.
  
So, we would need specs to say how one home proxy implementation
interworks with someone else's presence implementation.
That means we have to specify the URI construction convention;
it's not a URI constructed by the presence service, 
and it's not constructed by the home proxy unless we invent 
some kind of way the

It's either that or the things that are in these URIs 
really are device addresses and not AoRs.
Doing it all with caller prefs solves that.
Doing it with Jonathan's proposal means we have to do some
sip work to make the language the PS uses in the URIs match
some kind of standard.

Of course, as you point out, that would also make the
UA that doesn't have a watcher be able to influence a call.
In theory, that could work with both approaches; the UA
would either know what the caller prefs language was like,
or it would know what the URI naming convention was.

Brian

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: Thursday, March 13, 2003 2:09 PM
> To: Rosen, Brian
> Cc: 'Paul Kyzivat'; [email-masked]; Jonathan Rosenberg;
> Simple WG
> Subject: RE: [Simple] RPIDS: Capabilities in tuples and Caller Prefs
> 
>