Subject: RE: [Sip] Proposed change to callerprefs

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 27 Nov 2001 15:25:22 -0500

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Wednesday, November 21, 2001 2:26 PM
> To: Jonathan Rosenberg
> Cc: [email-masked]
> Subject: Re: [Sip] Proposed change to callerprefs
> 
> > > 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.
> 
> 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.

While the syntax is the same, the spec is clearer now that the contact
header and accept-contact are not saying the same thing:

   The
   parameter values in the rule are interpreted as an OR-of-ANDs logic
   statement, with the conjunctions separated by commas, and the
   components in the conjunction separated by ampersands. The logic
   statement can be preceded by the negation operator (!). The parameter
   values in the contact entry are interpreted as a set of elements. A
   component in the logic statement is true if its value appears in the
   set of elements (based on a case sensitive string comparison), false
   otherwise. The rule matches the contact entry if the rule would
   evaluate to true, given that the value of the components of the rule
   are true or false depending on their presence in the set defined by
   the contact entry.

Hopefully this makes it clear that the contact header has a set, and the
accept-contact has a rule.

There is no technical reason not to use different syntaxes; its merely an
issue of backwards compatibility, since this draft has been around FOREVER. 
> > 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.
> 
> The obvious use cases are:
> - OR for languages (english OR spanish)
> - AND for media (audio AND video)

Other examples would be nice, but as I said, I am convinced that AND would
be useful and its now in the draft.
> > 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.
> 
> Then the ugly head of precedence enters the picture. 
> Does this mean "en & (es | de)" or "(en & es) | de"?

Standard precedence rules used in logic. AND takes presence, so en&es,de is
(en&es) | de. I will add text to clarify that (hopefully in the version that
also includes IESG comments, since I really want to send this version to
iesg).
> > 
> > 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
> 
> 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.

OK, so if there are no uses let us keep with what is written now.
> > 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.
> 
> 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.)
> 

OK, what is the problem specifically? I did verify the code...

-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

_______________________________________________
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