Re: [Sipping] session-info <token> value

Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Fri, 20 May 2011 12:21 UTC

Return-Path: <gonzalo.camarillo@ericsson.com>
X-Original-To: sipping@ietfa.amsl.com
Delivered-To: sipping@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC20DE0695 for <sipping@ietfa.amsl.com>; Fri, 20 May 2011 05:21:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ez0Aw6PD6T-t for <sipping@ietfa.amsl.com>; Fri, 20 May 2011 05:21:35 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id ED150E065D for <sipping@ietf.org>; Fri, 20 May 2011 05:21:34 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-77-4dd65ccd3774
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 22.39.20773.DCC56DD4; Fri, 20 May 2011 14:21:33 +0200 (CEST)
Received: from [131.160.37.44] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Fri, 20 May 2011 14:21:32 +0200
Message-ID: <4DD65CCC.5000008@ericsson.com>
Date: Fri, 20 May 2011 15:21:32 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: "Worley, Dale R (Dale)" <dworley@avaya.com>
References: <CD5674C3CD99574EBA7432465FC13C1B22246BD4AE@DC-US1MBEX4.global.avaya.com>
In-Reply-To: <CD5674C3CD99574EBA7432465FC13C1B22246BD4AE@DC-US1MBEX4.global.avaya.com>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
Cc: "sipping@ietf.org" <sipping@ietf.org>
Subject: Re: [Sipping] session-info <token> value
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipping>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 May 2011 12:21:35 -0000

Hi,

yes, I think limiting the valid characters to something simpler (UTF8 or
ASCII) makes sense.

Cheers,

Gonzalo

On 18/05/2011 7:33 PM, Worley, Dale R (Dale) wrote:
> 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:foo@example.com;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