Subject: [Iptel] Implementing "language-switch" tag in CPL

From: Administratör <[email-masked]>
Date: Fri, 14 Jan 2005 18:50:35 +0100

I find the documentation of the language-switch tag (RFC3880 chapter 
4.3) unclear. Lets take this example script (modified version of 
example in RFC 3880 chapter 12.5):
   	.....
          <language-switch>
              <not-present>
		.....
              </not-present>
              <language matches="es">
                <location url="sip:[email-masked]">
                  <proxy/>
                </location>
              </language>
              <language matches="en">
              <otherwise>
                <location url="sip:[email-masked]">
                  <proxy/>
                </location>
              </language>
              <otherwise>
		.....
              </otherwise>
            </language-switch>
	.....

There are several possible cases here:

* the SIP request supplied no accept-language
- execute the content of not-present.

* the SIP request supplied accept-language that didn't match any of the 
languages, in this case spanish (es) and english (en)
-  execute the content of otherwise.

* the SIP request supplied accept-language that matches e.g.:
"Accept-Language: en, es;q=0.8 da;q=0.0"

+ if matching is done in regular switch order (as language-switch is 
documented to be a switch in the RFC - it's part of chapter 4 - 
"Switches") the first <language matches="es"> condition, would be 
matched so the caller would end up at a spanish operator, even though 
he/she has a higher q-value for "en" (= "en;q=1").

+ This seams odd, as this would mean that the callers q-values are 
completely ignored, this interpretation also appears to be in 
contradiction with the statement "Languages with a 'q' value of 0 are 
also ignored." - RFC 3880 chapter 4.3. (why are q-value = 0 treated 
specially ?).

+ The HTTP 1.1 specification (in regards to accept-language) appears to 
imply that each <language matches="..."> condition is assigned a 
q-value - same as the matching language-range in the request or 0 if 
not supplied in the request. The condition with the largest q-value is 
then selected and executed - is this how it is supposed to work ?

_______________________________________________
Iptel mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/iptel

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 14 Jan 2005 17:05:27 -0500

I agree that this is somewhat unfortunate.

The problem is, fundamentally, that the "first-match" semantics of CPL
switches don't mesh very well with the "best-match" semantics of HTTP/SIP
Accept-Language.

To resolve this, I decided to just impose CPL's semantics, to keep CPL
engines from having to scan an entire language-switch before deciding which
output to take.

Conceivably this was the wrong choice; a CPL extension called something like
best-match-language-switch (in an appropriate namespace) might be in order.

-- 
Jonathan Lennox
[email-masked]

---

From: Administratör <[email-masked]>
Date: Mon, 17 Jan 2005 14:14:23 +0100

I don't have any real experience working in the RFC process, in regards
to how and to what extent a RFC can be modified - but here are my
thoughts and opinions about language-switches:

* Replace it with "language-select", described below (or similar CPL
   Node).
* Add "language-select" as some kind of extension.
* is language-switch needed and truly useful or could it be made
   optional / removed from the RFC (3880) ?:

- We, in this case Stockholm University how work on
   http://www.stacken.kth.se/projekt/yxa/ don't see any immediate need
   for this functionality, this may of course apply to other parties.
- Are regular users actually going supply reasonable.
   "accepted-language" values, or will 90% of all phones send some kind
   of useless default or supply no values at all ? - For language-switch
   to be truly useful, almost all phone must supply correct values for
   "accepted-language", for CPL scripts to be able to rely on this
   information.

-----------------------------------------------------------------------
Notes on proposed language-select below:

* I tried to model it after "proxy" - with matching conditions
   "language" and "default" a no matching condition.

-----------------------------------------------------------------------

Language Selects

    Language selects allow a CPL script to make decisions based on the
    languages in which the originator of the call wishes to communicate.
    They are summarized in Figure X. This a modified version of
    "language-switch" acting in a manner more compatible with other
    related RFCs like RFC 2616 (see chapter 14.4).

             Node:  "language-select"
          Outputs:  "language"         Specific string to match
       Parameters:  None

           Output:  "language"
       Parameters:  "matches"          Match if the given language
                                       matches a language-range of the
                                       call.
           Output:  "default"
       Parameters:  none

       Figure X: Syntax of the "language-select" node

    Language selects take no parameters.

    The "language" output takes one parameter, "matches".  The value of
    the parameter is a language-tag, as defined in RFC 3066.  The
    caller may have specified a set of language-ranges, also as defined
    in RFC 3066. The match is done as follows:

    * Each language-tag (i.e. each "matches") is matched against the
      language-ranges supplied by the request, each language-tag value is
      paired with the best "q" value found, "q" = 0 if no value was
      supplied.
      The "language" output with the best fit is then executed, best fit:
      - select all "language"-"q" pairs, that have the maximum "q" value.
      - select all the "language" outputs that have the highest number of
        segements = number of "-" separators + 1.
      - if there are still identical matches the "language" output will
        be selected in the order they are declared in "language-select".

    * If no "language" output matches, the "default" output is selected.
      This happens if the request supplied no language information or if
      all the "language"-"q" pairs got "q" = 0.

    See RFC 3066 for the details of how language-ranges match language-
    tags.  Briefly, a language-range matches a language-tag if it exactly
    equals the tag, or if it exactly equals a prefix of the tag such that
    the first character following the prefix is "-".

    If the caller specified the special language-range "*", it is ignored
    for the purpose of matching.  Languages with a "q" value of 0 are
    also ignored ().

Usage of "language-select" with SIP

    The language-ranges for the "language-select" select are obtained
    from the SIP "Accept-Language" header field.  The select is not-
    present if the initial SIP request did not contain this header field.
-----------------------------------------------------------------------

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 17 Jan 2005 15:35:26 -0500

> thoughts and opinions about language-switches:

The best approach would be to define language-select (or whatever you want
to call it) as an extension to CPL.  See section 11 of RFC 3880 for details
on how CPL extensions work.  Since CPL extensions are defined using XML
namespaces, they don't necessarily have to go through the IETF
standardization process (though if they're generally useful, I'd encourage
them to be).

>    "accepted-language", for CPL scripts to be able to rely on this

This I don't know.  If your implementation targets SIP, I'd suggest asking
on the SIP-Implementors mailing list.  See
<http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors>.

-- 
Jonathan Lennox
lennox at cs dot columbia dot edu