Subject: RE: [Simple] FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt

From: [email-masked]
Date: Sat, 2 Nov 2002 15:08:20 +0200

Hi,

inline

> -----Original Message-----
> From: ext Paul Kyzivat [mailto:[email-masked]]
> Sent: 29 October, 2002 17:06
> To: [email-masked]
> Subject: Re: [Simple] FW: I-D
> ACTION:draft-lonnfors-simple-prescaps-ext-00.txt
> 
> 
> [email-masked] wrote:
> > 
> > Hi,
> > 
> > New draft is now available. Basically draft presents a 
> solution for the requirements presented in 
> draft-kyzivat-simple-prescaps-reqts-00.txt.
> > All comments are welcome.
> 
> Obviously Mikko and I have been cooperating on this. We were 
> both interested in the subject. I thought it would be helpful 
> to be clear about the requirements rather than jumping 
> directly to a proposed solution, so I posted a requirements 
> draft last week. Since then I have been waiting for Mikko to 
> submit this in order to have more fodder for discussion.
> 
> There is already a work item to produce a SIP-specific 
> profile for PIDF. I consider these drafts to be a *partial* 
> response to that work item. I realize there is a desire for 
> some addition generalized status values beyond open/closed, 
> such as busy. That is a minefield, and we have chosen not to 
> address it. Instead, we are focusing on some attributes that 
> should be less controversial because they are drawn from the 
> callerprefs draft, whose basic concepts have been accepted 
> for a long time. (I am open to discussion about whether these 
> specific drafts should be expanded to cover the more general 
> requirement, or whether that should be left separate.)
> The assertion of these drafts is that capabilities a UAS can 
> specify when registering are information that is equally 
> important in a presence document. I believe Mikko is most 
> concerned with supported media. I also consider that to be of 
> major importance, but I also believe all the others are of 
> potential value in a presence document.

This topic was first discussed in IMPP mailing list related to PIDF communication means. After some discussion it was concluded that this work might fit better to SIMPLE WG agenda. 
I would also like to see some comments to the requirements draft. A small problem in writing that was that there were no requirements for callerpreferences and because of that we have tried to put quite a lot motivational and explanative text into requirements. It would be very helpful to hear also other people comments to this. If the overall idea is acceptable then the exact requirements should be quite clear. At least requirements 1, 2, and 3 should be quite self-evident (I hope). Requirement 4 is now marked with SHOULD level and I would like to hear if it would be good idea to move it to MUST level. Also I am not sure we have been able to collect all relevant requirements so if something seems to be missing please let us know.  

> The callerprefs draft is still itself in a state of flux. The 
> work here should remain dependent on the outcome of that 
> work. But I believe it would be helpful to begin progressing 
> these documents now.

We have tried to keep this draft as independent of callerprefs as possible but there is of course quite heavy dependency between these two. 

Here are some open items for solution draft:
- At a moment draft allows use of extension in two places inside PIDF document (inside <tuple> and <status>. Should we specify the exact location where this extension can be used within PIDF document.
- We went through 2 or 3 different XML schemas before ending up with current one. Obviously there is lot of different options and if someone thinks there exists better alternatives then this can be discussed.
- We ended up using negated attribute inside <value> elements to indicate whether value is supporter or not supported. There are also other alternatives to represent this. One alternative would be to replace <value> with either <require> or <forbid> element.

- Mikko

> 	Paul
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 16 Nov 2002 00:34:37 -0500

I think the basic idea behind these drafts is a good one. There is clear 
value in knowing, at a watcher, more details on each of the contact 
addresses in the presence document.

There are a bunch of issues here which require further discussion:

1. Assuming the watcher "picks" one of the contact addresses, and 
decides to communicate with it by sending it an INVITE, how should that 
INVITE look? If the URI in the contact element is the AOR of the user, 
does the watcher need to add caller preferences (Require-Contact) in 
order to reach that specific UA instance?

More generally, what is the meaning of these capabilities attributes? 
Does it mean that there exists some UA behind that URI with those 
capabilities? Does it mean that any UA reached with that URI is 
guaranteed to have those capabilities? I think what you want is the 
former. I also think that you are not going to be able to put the actual 
Contact URI into the PIDF doc; it will need to be some kind of AOR, but 
one that routes to a specific UA instance.

2. One of the things I am not particularly fond of in the current caller 
prefs spec is the limitation on the capabilities predicate (conjunctive 
normal form only). That restriction exists because of the syntactic 
limitations of using contact parameters, and of the need for a simple 
matching algorithm in proxies to support routing. I would like to leave 
the door open for much more complex capabilities documents, which can be 
uploaded by a UA and used for other things, NOT call routing 
necessarily. Here is a good example of a use case that does not need to 
suffer the limitations of caller prefs. It would be nice if we can be 
more general.

w3c has done a lot of work in describing capabilities (CC/PP, RDF), all 
of which is XML-based. I wonder if there is a better fit here to use 
that kind of syntax?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 16 Nov 2002 11:05:16 -0500

> There are a bunch of issues here which require further discussion:

Yup. We were expecting discussion.

> order to reach that specific UA instance?

My assumption has been that if the watcher picks one of the contact addresses, he then just sends the invite to it. It is up to the publisher of presence to arrange things so that does the right thing. The publisher can identify separate tuples each with a particular set of capabilities, and yet provide a single AOR for all of them. In that case it is in effect promising to provide a smart proxy at the AOR that can do the right thing.

Or the publisher can provide an actual individual contact address for each tuple. In that case it is promising that the contact addresses are usable by presence subscribers.

In the end, the publisher is in the driver's seat, and publishing what it willing to expose and what it thinks will be useful to subscribers. There clearly is a tradeoff  between those two things, and the publisher is the one that ought to decide.

Whether the subscriber should put callerprefs on the invite is a good question. If the algorithm the subscriber uses to choose between the contacts can be represented by callerprefs then it probably wouldn't hurt and might help. This needs further discussion.

> former.

I agree.

> I also think that you are not going to be able to put the actual

As I mention above, this is really the responsibility of the publisher. It would be stupid of the publisher to insert URIs that cannot be used by subscribers. But I don't see any reason to otherwise restrict this.

> suffer the limitations of caller prefs. It would be nice if we can be

Yes!!! Thanks for mentioning this. I was waiting for this to get out for general discussion before bringing it up. I would welcome suggestions for enhancements to the requirements.

> of which is XML-based. I wonder if there is a better fit here to use

Could be.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 18 Nov 2002 01:08:44 -0500

Paul Kyzivat wrote:
 >> decides to communicate with it by sending it an INVITE, how should
 >> that INVITE look? If the URI in the contact element is the AOR of
 >> the user, does the watcher need to add caller preferences
 >> (Require-Contact) in order to reach that specific UA instance?
 >
 >
 > My assumption has been that if the watcher picks one of the contact
 > addresses, he then just sends the invite to it. It is up to the
 > publisher of presence to arrange things so that does the right thing.

Agreed.

 > The publisher can identify separate tuples each with a particular set
 > of capabilities, and yet provide a single AOR for all of them. In
 > that case it is in effect promising to provide a smart proxy at the
 > AOR that can do the right thing.

Well, that won't work. How would the proxy know which tuple was 
intended? The only way it can know is if the caller had placed caller 
preferences in the request. That was my point - how would the caller 
know it needs to do that?

I suppose the right answer is to construct the tuple URI like this:

sip:aor@domain?Require-Contact=<escaped version of *;media="video">

that is, you don't rely on the subscriber to insert the caller prefs. 
The PA does that itself by embedding them in the URI.

 >
 > Or the publisher can provide an actual individual contact address for
 > each tuple. In that case it is promising that the contact addresses
 > are usable by presence subscribers.

This is another instance of what I've been calling the "globally 
routable UA instance problem" - how to construct a SIP URI that routes 
to a specific UA instance when used outside of any existing dialog.

 >
 > In the end, the publisher is in the driver's seat, and publishing
 > what it willing to expose and what it thinks will be useful to
 > subscribers. There clearly is a tradeoff  between those two things,
 > and the publisher is the one that ought to decide.
 >
 > Whether the subscriber should put callerprefs on the invite is a good
 > question. If the algorithm the subscriber uses to choose between the
 > contacts can be represented by callerprefs then it probably wouldn't
 > hurt and might help. This needs further discussion.

I think the semantic needs to be simple. The caller invokes the URI in 
the presence document, period. The server guarnatees that that results 
in a request being routed to a UA described by the information in the 
presence document. Thats the contact.

 >
 >> 2. One of the things I am not particularly fond of in the current
 >> caller prefs spec is the limitation on the capabilities predicate
 >> (conjunctive normal form only). That restriction exists because of
 >> the syntactic limitations of using contact parameters, and of the
 >> need for a simple matching algorithm in proxies to support routing.
 >> I would like to leave the door open for much more complex
 >> capabilities documents, which can be uploaded by a UA and used for
 >> other things, NOT call routing necessarily. Here is a good example
 >> of a use case that does not need to suffer the limitations of
 >> caller prefs. It would be nice if we can be more general.
 >
 >
 > Yes!!! Thanks for mentioning this. I was waiting for this to get out
 > for general discussion before bringing it up. I would welcome
 > suggestions for enhancements to the requirements.
 >
 >
 >> w3c has done a lot of work in describing capabilities (CC/PP, RDF),
 >> all of which is XML-based. I wonder if there is a better fit here
 >> to use that kind of syntax?
 >
 >
 > Could be.

That seems to be the common answer here... someone needs to do a 
detailed study and see how it fits.

-Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Nov 2002 12:37:05 -0500

> The PA does that itself by embedding them in the URI.

I think this is a matter of semantics. If I, as publisher, say there are two tuples with different attributes, but associate them both with the same AOR, it might mean that I have two devices registered at the same AOR with differing attributes but don't choose to identify their addresses; or it might mean that I have a single device with two different and interesting sets of attributes I choose to advertise.

The subscriber doesn't know and shouldn't care, as long as it reaches a device with the proper capabilities.

Having a proxy for the AOR simply fork the request may be sufficient if there are two devices and the characteristics that differentiate them can always be discerned from the initial request. This isn't going to be the case very often, but since the publisher is in the driver seat it should be his problem to decide this.

Nevertheless, I agree that in general it would be best for the presence publisher to do as you suggest and embed the callerprefs headers in the contact address. Toward that end, I think we had better specify somewhere that contact addresses in presence may indeed contain embedded headers, since they aren't universally accepted.

> presence document. Thats the contact.

Yes, this seems to be the best answer.

> detailed study and see how it fits.

I already spoke with Mikko about this. Neither of us are familiar with the W3C work. Will need to figure out who has the time / contacts to do the digging.

	Paul