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

From: [email-masked]
Date: Sat, 16 Nov 2002 18:46:43 +0200

Hi,

Thanks for comments. Mine are inline,

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: 16 November, 2002 07:35
> To: Lonnfors Mikko (NRC/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Simple] FW: I-D
> ACTION:draft-lonnfors-simple-prescaps-ext-00.txt
> 
> 
> 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?

This is one of the issues which is currently completely unspecified in the draft. I have a bit mixed feeling how we should proceed which this one. As the decision  is based on presence info watchers have quite a lot freedom how they can initiate communication with the presentity. I am not sure if it makes much sense to mandate any strict behavior from UAs but I think we could give recommendations. This topic definitely deserves more discussion.  

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

Yes, this is probably the case.

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

Yes, this has been my assumption.

> 
> 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, I definitely agree. The question seems to be if it is sufficient to give current functionality with ability to extend it using XML namespaces or is there need to define addition functionality to support more complex features.

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

I am not very familiar with work done in w3c in this area but I will take a look.

- Mikko

> -Jonathan R.
> 
> [email-masked] wrote:
> > 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
> >>
> > 
> > _______________________________________________
> > simple mailing list
> > [email-masked]
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > 
> 
> -- 
> 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
> 
>