Subject: RE: [Sip] Proposed change to callerprefs

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 21 Nov 2001 11:01:20 -0500

response inline.

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Friday, October 05, 2001 10:48 AM
> To: [email-masked]
> Subject: [Sip] Proposed change to callerprefs
> 
> 
> I posted the question attached to the end of this to 
> sip-implementors a
> week or so age.
> Since then I have considered the question further and have come to the
> conclusion that while the interpretation I reached was probably valid
> and functional, it is a confusing interpretation. I now 
> believe it would
> be better to revise the callerprefs proposal so that the issues may be
> handled in a more consistent, less confusing way. 
> 
> In my earlier posting, I posed the problem of specifying a preference
> for a contact supporting both english and spanish language. 
> According to
> draft-ietf-sip-callerprefs-04 language="en,es" means english 
> OR spanish,
> while language="en",language="es" means english AND spanish.
> 
> The trouble with this is it violates the principle of least
> astonishment. I believe most people will expect language="en,es" and
> language="en",language="es" to mean the same thing.

I also posted a note on sip-implementors that explained that this is also
problematic from a grammar perspective; I think most parsers will assume a
single instance of each parameter, as most use hash tables to index
parameters by name.

> For precedent we
> need look no further than the normal header processing logic in sip,
> which says that:
> 
>    Accept-Contact:*;language="en", *;language="es"
> 
> is equivalent to:
> 
>    Accept-Contact:*;language="en"
>    Accept-Contact:*;language="es"
> 
> So, I propose that: 
> 
>   language="en,es"
> 
> should be equivalent to:
> 
>   language="en",language="es"

Well, it was my proposal that this simply be disallowed. 

> 
> and that this should require a match on both english AND spanish.
> The reason this means AND rather than OR is consistency with the
> combination of cp-params of different types:
> 
>   language="en",media="audio"     means english AND audio, so
>   language="en",language="es"     should mean english AND spanish
> 
> Unfortunately this interpretation is a change from the current draft. 
> 
> In addition to the consistency argument, practicality also 
> supports this
> change. For one thing, there is more need to express an AND condition
> than an OR condition, and so it ought to be more concise.

Can you provide specific use cases? This rule matching can get arbitrarily
complex, and I want to make sure we don't add things because their important
in theory only, especially this late in the game.

> Also, there is
> already another way to express the OR condition. If I want english or
> spanish, I can write:
> 
>    Accept-Contact:*;language="en", *;language="es"

Assuming there is a need for AND, another way which is more consistent with
the grammar would be:

;language="en,es"     -> English or Spanish
;language="en&es"     -> Engish and Spanish

Effectively, the list now becomes an OR or ANDs, so that:

;language="en&es,de"

is also OK. 

> 
> There is one more issue to deal with if this change is to be made.
> Consider
> 
>    Accept-Contact:*;media="voice";media="video";q=1.0,
>                   *;media="voice";media="!video";q=.5
> 
> This ought to be equivalent to
> 
>    Accept-Contact:*;media="voice,video";q=1.0,
>                   *;media="voice,!video";q=.5
> 
> but this would be wrong because "!" is only valid at the beginning of
> the parameter value, and applies the value as a whole rather than to a
> particular item in the comma separated list of items in the value.
> 
> For consistency, I propose that this also be changed. Negation through
> use of "!" should apply to an individual element in a comma separated
> list of values.

This is not needed. Remember, the set processing is done to ultimately
affect the prioritization of the contacts. Let us assume that the & rule
above exists. Instead, you could use:

   Accept-Contact: *;media="voice&video",q=1.0,
                   *;media="voice",q=0.5

Now, if the contact list has:

sip:[email-masked];media="voice,video"
sip:[email-masked];media="voice"

The videophone matches both rules above, but the cellphone only matches the
voice rule. If simple averaging is used over the q values from matching
rules, the videophone ends up with a higher q value than the cell phone,
which is ultimately what you are after anyway.

> 
> For example (yes, I know this is nonsense), suppose I want to accept
> contacts supporting english but neither spanish nor french. 

Well, to be honest, coming up with real scenarios is important in order to
justify the late change, but as I point out above, even if you did, its not
clear to me that it matters.
> 
> If there isn't agreement with this proposal, then I at least 
> hope to get
> agreement that the interpretation I posed in the message below is
> correct. It is essential that there be some way to express the AND
> condition for two values of the same cp-param type.

I'd still like to see real uses, but I can imagine there are some (voice and
video, for example, is a reasonable thing to ask for). So, I will go ahead
and add my & proposal to the draft, since its easy to do within the
framework. We can discuss further, but this way, if there is agreement on
that, then the draft is ready for iesg immediately rather than requiring a
rev.

-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

> 
> -------- Original Message --------
> Subject: [Sip-implementors] Need clarification on callerprefs
> Date: Thu, 27 Sep 2001 10:26:57 -0400
> From: Paul Kyzivat <[email-masked]>
> To: [email-masked]
> References: <[email-masked]>
> 
> I have a question on the matching algorithm in callerprefs.
> 
> Suppose I need a rule that requires multiple distinct values for the
> same kind of param - for instance I need a contact that supports both
> English and Spanish.
> 
> If I match:
> 
>    Accept-Contact *;language="en,es"
> 
> against:
> 
>    Contact: sip:[email-masked];language="en"
>    Contact: sip:[email-masked];language="de,en"
>    Contact: sip:[email-masked];language="en,es,fi"
> 
> it will match both joe and alice, which is not what I want.
> 
> I believe that the following should do the right thing:
> 
>    Accept-Contact *;language="en";language="es"
> 
> I find nothing in the draft that forbids this, but neither do I find
> anything that convinces me that this is intended behavior either. 
> 
> Can someone confirm that this is valid usage, and that a server which
> failed to support it would be non-conforming?
> 
> 	Paul Kyzivat
> _______________________________________________
> Sip-implementors mailing list
> [email-masked]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> 
> _______________________________________________
> Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
> 

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Nov 2001 14:26:16 -0500

Jonathan,

I am off on personal business this week, and so am only quickly scanning
mail. But I did want to respond to this. I have more to say, but I think
that can wait until later.

Comments below.

	Paul

> single instance of each parameter, as most use hash tables to index

I agree that repeating the parameter is a poor way to represent AND, and
that a better way is preferred.

> Well, it was my proposal that this simply be disallowed.

OK, as long as we get both AND and OR.

One concern I have about this is that then there is a difference in
meaning of "," between the Contact header and the
Accept-Contact/Reject-Contact headers. In Contact, the "," means AND:

  Contact: foo@bar;language="en,es"

means foo@bar can do english AND spanish, while

  Accept-Contact: *;language="en,es"

means to accept anyone speaking english OR spanish.

It would be more reasonable to make "," mean AND, and use "|" to mean
OR. Another possibility is the one I suggested earlier to have "," mean
AND and then use multiple headers to express OR, since they already do
that.

> in theory only, especially this late in the game.

The obvious use cases are:
- OR for languages (english OR spanish)
- AND for media (audio AND video)

> Effectively, the list now becomes an OR or ANDs, so that:

Then the ugly head of precedence enters the picture. 
Does this mean "en & (es | de)" or "(en & es) | de"?

I imagine we can find something workable though perhaps not intuitive
definition.

>    Accept-Contact: *;media="voice&video",q=1.0,

We can easily get into the world of the obscure and useless here. I have
quite a bit of difficulty coming up with good uses for NOT at all,
especially in Accept-Contact. I suppose it has more use in
Reject-Contact.

> that, then the draft is ready for iesg immediately rather than requiring a

I defer to your judgement about strategy. There is work required in the
matching algorithm section that isn't so straightforward, as well as in
the code example if it is to be retained. (I think code samples are
dangerous in standards.)

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 26 Nov 2001 13:57:35 -0500

Jonathan,

I sent this last wednesday, but I haven't seen it come back, so maybe it
got lost. Here it is again.

Comments below.

	Paul