Subject: [RAI] FW: session-info <token> value

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 31 May 2011 15:34:24 -0400

From: [email-masked] [[email-masked]] On Behalf Of Worley, Dale R (Dale) [[email-masked]]
Sent: Wednesday, May 18, 2011 12:33 PM
To: Gonzalo Camarillo; [email-masked]
Subject: [Sipping] session-info <token> value

There is a "token" value which is passed from a policy server to a UA.  The token value is the content of a <token> element in the session-info document, so in general it is a sequence of Unicode characters.  The UA uses it when it makes certain requests by adding a Policy-Info header of the form:

Policy-Info: sip:[email-masked];token=xyzzy

where the value of the "token" parameter is the content of the <token> element in the session-info that it was given.

The question is what characters are permitted in the token value?

The only limitation on the session-info document is that it consist of Unicode characters.  But in order to put it in a parameter value, it must be representable there.  Parameter values use %-escaping, so characters from U+0020 (space) to U+007E (~) can easily be accommodated.  If we use %80 to %FF to represent the characters from U+0080 to U+00FF, we can add the Latin-1 set.  Or we could assume that %-escaping is used to encode *bytes* used in the *UTF-8* representation of characters, in which case the entire Unicode set is representable.  (Since the semantics of %-escaping is not described anywhere in RFC 3261, either of these is possible.)

It seems to me that limiting the characters to U+0020 through U+007E, the ordinary ASCII set, is enough flexibility and avoids all sorts of complications.

Dale

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 1 Jun 2011 07:46:07 +0800

On 2011-06-01 at 05:34:24, Worley, Dale R (Dale) wrote:
> It seems to me that limiting the characters to U+0020 through U+007E, 
> the ordinary ASCII set, is enough flexibility and avoids all sorts of 
> complications.

That would permit invalid URIs.  How about 'unreserved' from RFC3986?

http://tools.ietf.org/html/rfc3986#section-2.3