Subject: [Sipping] Question on RFC3840 and multiple string-value encoded tags

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 10 Sep 2007 20:37:33 +0200

Hi,

I have a question on the usage of multiple values for a single feature tag.

If a feature tag value contains ":" characters, my understanding is that the tag value must be encoded as string-value (tag-value does not allow ":" to be used).

According to the ABNF in RFC3840 there is no concept of string-value lists (similar to tag-value-list). There is only a single string-value per feature tag.

So, if I want to list multiple feature tag values, for a single feature tag, the question is:

Should the values be coded as a single string value, but with the different values comma separated within the string-value itself?

(Example: ;+my.feature.tag="<urn:urn-xxx-blah.blah.blah,urn:urn-xxx:sip.is.good>")

OR:

Should multiple instances of the feature tag be used, each with a string value containing only a single value?

(Example: ;+my.feature.tag="<urn:urn-xxx-blah.blah.blah>"
          ;+my.feature.tag="<urn:urn-xxx:sip.is.good>")

Regards,

Christer

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Sep 2007 15:06:05 -0400

Hmm. I've recently gotten other questions about callerprefs for IMS 
related sources. It seems like maybe IMS is starting to use callerprefs 
for something. Can we have an explanation for how they are being used? 
That would help in answering questions.

Inline.

	Paul

> If a feature tag value contains ":" characters, my understanding is that the tag value must be encoded as string-value (tag-value does not allow ":" to be used).

The feature tag values were set up to encode the various data types 
supported by 2533. The "tag-value" is used for tokens, booleans, and 
numbers, none of which include ":".

> According to the ABNF in RFC3840 there is no concept of string-value lists (similar to tag-value-list). There is only a single string-value per feature tag.

Yeah. It was a compromise, trying to fit general strings into the syntax 
alongside the other types within the limitations of the sip header syntax.

> (Example: ;+my.feature.tag="<urn:urn-xxx-blah.blah.blah,urn:urn-xxx:sip.is.good>")

That won't work. Look at the mapping to the predicate syntax and you 
will see that commas don't result in multiple terms for this.

>           ;+my.feature.tag="<urn:urn-xxx:sip.is.good>")

That won't work either. SIP doesn't allow multiple instances of the same 
parameter in the same header.

There just isn't any way to do what you are trying to do. Sorry.

	Paul

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 11 Sep 2007 09:05:42 +0200

Hi, 

>>If a feature tag value contains ":" characters, my understanding is
that the tag value must be encoded as 
>>string-value (tag-value does not allow ":" to be used).
> 
>The feature tag values were set up to encode the various data 
>types supported by 2533. The "tag-value" is used for tokens, 
>booleans, and numbers, none of which include ":".
> 
>>According to the ABNF in RFC3840 there is no concept of 
>>tring-value lists (similar to tag-value-list). There is only 
>>a single string-value per feature tag.
> 
>Yeah. It was a compromise, trying to fit general strings into 
>the syntax alongside the other types within the limitations 
>of the sip header syntax.
> 
>>Should the values be coded as a single string value, but with the
different values comma separated within the 
>>string-value itself?
>>(Example:
;+my.feature.tag="<urn:urn-xxx-blah.blah.blah,urn:urn-xxx:sip.is.good>")
> 
>That won't work. Look at the mapping to the predicate syntax 
>and you will see that commas don't result in multiple terms for this.

I think the receiver can process the string content in any way it wants
- including splitting it up into different parts/values.

A receiver that does not understand the feature tag will of course only
see it as a single string.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 Sep 2007 07:58:20 -0400

> see it as a single string.

The feature tags were defined to support the callerprefs matching 
algorithm. When doing callerprefs matching the tags must be interpreted 
as specified in 3840/3841. A node that does callerprefs matching using a 
different parsing of the tags will be very non-compliant.

Of course callerprefs doesn't care what the tags *mean*, but users of 
them do care. So the sender and the recipient also need to agree on how 
to associate meaning with the tags. Perhaps you are suggesting that a 
recipient could associate meaning with a particular tag value as a list. 
I suppose there might be some case where that makes sense even though it 
is not a list for matching purposes, but that seems very far fetched - I 
can't think of such a case. The case you are describing, with a list of 
URNs, doesn't make any sense to me.

	Paul

---

From: [email-masked]
Date: Tue, 11 Sep 2007 15:19:16 -0400

From: "Christer Holmberg (JO/LMF)" <[email-masked]>

True, but I know of no defined "receiver" other than a proxy that is
implementing callerprefs.  The feature tag values are only used when
making registrations.

Dale

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 11 Sep 2007 22:22:41 +0200

Hi,

>>I think the receiver can process the string content in any way it wants - including splitting it up into different parts/values.
>>
>>A receiver that does not understand the feature tag will of course only see it as a single string.
>
>The feature tags were defined to support the callerprefs matching algorithm.
>
>When doing callerprefs matching the tags must be interpreted as specified in 3840/3841. A node that
>does callerprefs matching using a different parsing of the tags will be very non-compliant.
>
>Of course callerprefs doesn't care what the tags *mean*, but users of them do care. So the sender and the recipient also
>need to agree on how to associate meaning with the tags.

Yes. So, everyone implementing this specific feature tag will know how to process it.

Regards,

Christer

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 11 Sep 2007 22:48:07 +0200

Hi,
 
I think it's perfectly ok to use feature tag values also in non-registration requests. RFC3841 shows many such examples.
 
Regards,
 
Christer

________________________________

From: [email-masked] [mailto:[email-masked]]
Sent: Tue 11/09/2007 21:19
To: [email-masked]
Subject: Re: [Sipping] Question on RFC3840 and multiple string-valueencodedtags

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 Sep 2007 17:36:06 -0400

Yes, feature tags may be used in non-registration requests. They are 
supposed to be used on Contacts in dialogs to indicate the capabilities 
of the endpoints. This has been used widely now for isfocus for conferences.

But the definitions of capabilities in 3840 still apply to these usages.

If you want to have a capability that is string valued, encoded as 
sometag="<abc...xyz>" and you wish to have the endpoints further parse 
the string value, then I guess that is ok. But remember that for 
callerprefs matching purposes it is a *single* value.

	Paul

---

From: "Dawes, Peter, VF-Group" <[email-masked]>
Date: Thu, 13 Sep 2007 11:24:21 +0200

Hello All,
 
RFC 3841 gives a helpful example of caller preferences processing in
7.2.5, quoted below. But, I am not sure about the significance of the
q-value in the Accept-Contact: header, e.g. 
 
Accept-Contact: *;methods="BYE";class="business";q=1.0
 
In the example from 7.2.5 quoted below, Contact:
sip:[email-masked];audio;video;methods="INVITE,BYE";q=0.2 is said to
match the preferences in the Accept-Contact: header above with a score
of 0.5, but this seems to ignore the mismatching q-values. Should the
score not be 0.33 (one match out of 3, not one match out of 2)?
 
Can someone please explain how the calculation is done, I have read
through RFC 4596 as well, but I can't find any other example of a
q-value in an Accept-Contact: header. Thanks.
 
Regards,
Peter
 
>From RFC 3841:
 
7.2.5.  Example
 
   Consider the following example, which is contrived but illustrative
   of the various components of the matching process.  There are five
   registered Contacts for sip:[email-masked].  They are:
 
   Contact: sip:[email-masked];audio;video;methods="INVITE,BYE";q=0.2
   Contact: sip:[email-masked];audio="FALSE";
     methods="INVITE";actor="msg-taker";q=0.2
   Contact: sip:[email-masked];audio;actor="msg-taker";
     methods="INVITE";video;q=0.3
   Contact: sip:[email-masked];audio;methods="INVITE,OPTIONS";q=0.2
   Contact: sip:[email-masked];q=0.5
 
   An INVITE sent to sip:[email-masked] contained the following caller
   preferences header fields:
 
   Reject-Contact: *;actor="msg-taker";video
   Accept-Contact: *;audio;require
   Accept-Contact: *;video;explicit
   Accept-Contact: *;methods="BYE";class="business";q=1.0
 
   There are no implicit preferences in this example, because explicit
   preferences are provided.
 
   The proxy first removes u5 from the target set, since it is immune
   from caller preferences processing.
 
   Next, the proxy processes the Reject-Contact header field.  It is a
   match for all four remaining contacts, but only an explicit match for
   u3.  That is because u3 is the only one that explicitly indicated
   support for video, and explicitly indicated it is a message taker.
   So, u3 gets discarded, and the others remain.
 
   Next, each of the remaining three contacts is compared against each
   of the three Accept-Contact predicates.  u1 is a match to all three,
   earning a score of 1.0 for the first two predicates, and 0.5 for the
   third (the methods feature tag was present in the contact predicate,
   but the class tag was not).  u2 doesn't match the first predicate.
   Because that predicate has a require tag, u2 is discarded.  u4
   matches the first predicate, earning a score of 1.0.  u4 matches the

Rosenberg, et al.           Standards Track                    [Page 16]

RFC 3841               Caller Preferences for SIP            August 2004

   second predicate, but since the match is not explicit (the score is
   0.0, in fact), the score is set to zero (it was already zero, so
   nothing changes).  u4 does not match the third predicate.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Sep 2007 09:16:45 -0400

> q-value in an Accept-Contact: header. Thanks.

This is an error in the RFC.

In the early drafts of this rfc there was a q-value parameter defined 
for the Accept-Contact header. But in later drafts it was removed. 
Apparently the usage in the example was overlooked when that change was 
made.

	Paul