Subject: [sipcore] Bug in RFC4235 (dialog event package)?

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Jul 2011 14:30:30 -0400

(as individual)

I've come across what appears to me to be a bug 4235. But before filing 
it I'd like to get some other opinions on it.

This has to do with the <target> element used to represent the Contact 
address and its parameters. The parameters of a Contact can be 
'feature-param's as defined in 3840, or various other things defined in 
3261 and other extensions.

The problem is that 4235 re-encodes contact parameters in a way that 
loses information, so that two semantically different parameters can be 
reported identically.

An example given is:

       <target uri="sip:[email-masked]">
         <param pname="isfocus" pval="true"/>
         <param pname="class" pval="business"/>
         <param pname="description" pval="Alice's desk &amp; office"/>
         <param pname="sip.rendering" pval="no"/>
       </target>

The corresponding Contact isn't given, but presumably is:

Contact: sip:[email-masked];isfocus="true";class="business";
    description="<Alice's desk & office>";+sip.rendering="no"

Note the change from
   description="<Alice's desk & office>"
to
   <param pname="description" pval="Alice's desk &amp; office"/>

This arises based on the following from 4.1.6.2:

    It can contain a list of Contact header parameters in param sub-
    elements (such as those defined in [10]).  The param element contains
    two required attributes, pname and pval.  Boolean parameters are
    represented by the explicit pval values, "true" and "false" (for
    example, when a feature parameter is explicitly negated).  Parameters
    that have no value at all are represented by the explicit pval value
    "true".   The param element itself has no contents.  To avoid
    repeating Contact information in each request, the subscriber can
    assume that the target URI and parameters are the same as in previous
    notifications if no target element is present in the corresponding
    local or remote element.  If a target element is present in the local
    or remote part of a notification, the new target tag and list of
    parameter tags completely supersedes the old target and parameter
    list in the corresponding part.  Note that any quoting (including
    extra angle-bracket quoting used to quote string values in [10]) or
    backslash escaping MUST be removed before being placed in a pval
    attribute.  Any remaining single quotes, double quotes, and
    ampersands MUST be properly XML escaped.

Specifically, the second to last sentence calls for stripping the 
bracketing < and >. That bracketing is specified in 3840 for feature params:

    feature-param    =  enc-feature-tag [EQUAL LDQUOT (tag-value-list
                        / string-value ) RDQUOT]
    enc-feature-tag  =  base-tags / other-tags
    base-tags        =  "audio" / "automata" /
                        "class" / "duplex" / "data" /
                        "control" / "mobility" / "description" /
                        "events" / "priority" / "methods" /
                        "schemes" / "application" / "video" /
                        "language" / "type" / "isfocus" /
                        "actor" / "text" / "extensions"
    other-tags      =  "+" ftag-name
    ftag-name       =  ALPHA *( ALPHA / DIGIT / "!" / "'" /
                       "." / "-" / "%" )
    tag-value-list  =  tag-value *("," tag-value)
    tag-value       =  ["!"] (token-nobang / boolean / numeric)
    token-nobang    =  1*(alphanum / "-" / "." / "%" / "*"
                       / "_" / "+" / "`" / "'" / "~" )
    boolean         =  "TRUE" / "FALSE"
    numeric         =  "#" numeric-relation number
    numeric-relation  =  ">=" / "<=" / "=" / (number ":")
    number          =  [ "+" / "-" ] 1*DIGIT ["." 0*DIGIT]
    string-value    =  "<" *(qdtext-no-abkt / quoted-pair ) ">"
    qdtext-no-abkt  =  LWS / %x21 / %x23-3B / %x3D
                            / %x3F-5B / %x5D-7E / UTF8-NONASCII

The bracketing < and > serve to syntactically distinguish a 
string-value, which might look like a tag-value-list, from a tag-value-list.
For instance:

	description="red,green,blue"
	has a tag value list with three tags, while

	description="<red,green,blue>"
	has a single string-value.

These are handled quite differently by the matching rules of 3841.

There is another "bug" in the 4235 example quoted above:

It seems clear that sip.render was intended to represent a 
feature-param. If so, according to 3840, that would be represented in 
the Contact as +sip.render. If so, nothing in 4235 says to remove that 
"+" when encoding it in xml. If the + is removed, then the distinction 
between feature-params and other params is lost.

I'd appreciate any thoughts others might have on this - whether its 
really a bug (I think that is clear), how significant it might be, and 
how it might be fixed. (I have some ideas for fixes, but nothing is pretty.)

	Thanks,
	Paul

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 28 Jul 2011 11:13:52 -0400

> From: Paul Kyzivat [[email-masked]]
> 

I believe that this behavior was intended, though (IMHO) it is not a
good design -- instead, I would prefer that the <param> elements carry
the parameter name/value pairs in a way that is isomorphic to what can
be given in a Contact header.  (Including properly distinguishing ';p'
from ';p=""'.)

But if the reader of <param> knows the semantics of the particular
parameter (whether the value part is a tag-value-list or a
string-value), it can properly reconstruct the parameter's value as
represented in the SIP message.

The problem is if the reader of <param> does not know a priori the
type of the parameter, or if parameters are introduced that are not
feature parameters.

> how it might be fixed. (I have some ideas for fixes, but nothing is pretty.)

We might change 4235 to specify that parameters that are not feature
parameters are handled in the way I preferred above.  (Distinguishing
feature parameters from others can be done absolutely by the rules in
RFC 3840.

> between feature-params and other params is lost.

I suspect that the text is what is intended and the example is wrong
and should be:

          <param pname="+sip.rendering" pval="no"/>

What is the current implementation practice?

Dale