From binod.pg@oracle.com Tue May 7 04:37:49 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C5F21F8E6E for ; Tue, 7 May 2013 04:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMMsh+hBiFNS for ; Tue, 7 May 2013 04:37:42 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7A97921F8675 for ; Tue, 7 May 2013 04:37:42 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r47Bbexx025916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 7 May 2013 11:37:41 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r47Bbe6r010752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 7 May 2013 11:37:40 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r47BbdGh006185 for ; Tue, 7 May 2013 11:37:40 GMT Received: from [192.168.0.9] (/59.92.140.200) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 07 May 2013 04:37:39 -0700 Message-ID: <5188E77B.3040603@oracle.com> Date: Tue, 07 May 2013 17:07:31 +0530 From: Binod User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: sipcore@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet22.oracle.com [141.146.126.238] Subject: [sipcore] Questions on SIP over websockets. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 11:37:49 -0000 HI, As part of JSR 359 (SIP Servlet 2.0) standardization, we are working on supporting SIP over websocket ID in SIP servlets. I have a few questions on this I-D and will be great, if you can answer the following questions. - How do you envision the sip/websocket to be used? Do you expect webservers that use webrtc to also support sip/websocket or do you expect, the sip/websocket to be supported by the sip servers independent of webservers and thus web application and sip application run as independent entities? Or both? - When a call come from a SIP UA to web browser (reverse of what is shown in 8.2), one option the draft is suggesting is the use of RFC 5626 as the way to identify the flow to send the request. But the draft does not stop a proxy/b2b from using some other mechanism either. Is that intentional? Do the spec allow a webserver to use a websocket connection based on its logic to send the requests to the client? - JSEP in webrtc (section A.1.5) has a model that simply does offer/answer using INVITE dialog. So, if I understand correctly, REGISTER is not really required for a web application. Is that model allowed? The examples in the rfc draft and reference to 5626 suggest the use of REGISTER. Is that the intention? thanks, Binod. From ibc@aliax.net Tue May 7 04:50:27 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12C121F8F17 for ; Tue, 7 May 2013 04:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldboZ8wQWbem for ; Tue, 7 May 2013 04:50:27 -0700 (PDT) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id EDC1721F8EE8 for ; Tue, 7 May 2013 04:50:26 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id f11so1514832qae.8 for ; Tue, 07 May 2013 04:50:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=IHKDIW9zamlTAUie/t1HoBbkHBHmTF15CfqzsER6lKI=; b=cVwyNwyTJPCY0Kk84IBS3aBnhxq+g3JIt85pSbnzyl/GFSSsC+8PCWDGL0iuPaWXz/ eTUeJRJtHIbYdQNyQU0MS9BgnGDW+gvYpw5iXkqB23TwNawf+XjRWCIQC3914DLKHOdk MoxsTHwiCUWPHWuaDaPsgmtwaqL84zDSv7IIu8XkDbqMTcEocid0su5YMz4G6XEI0pTk 5BKk+oosxChDLLJjZE9HzAT+IuzlibFLb+3nhrQcKYN5ZAMw+GKlCQP2/MMZNBV+DPxO zIz7gf2NPh+nLWdGh+nX+6ogUqTqEwcS56QERF/njtsOvwvdhwv3UWYQ69b666SJ4ZHY HV4w== X-Received: by 10.49.39.68 with SMTP id n4mr1252903qek.44.1367927426254; Tue, 07 May 2013 04:50:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.81.175 with HTTP; Tue, 7 May 2013 04:50:05 -0700 (PDT) In-Reply-To: <5188E77B.3040603@oracle.com> References: <5188E77B.3040603@oracle.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 7 May 2013 13:50:05 +0200 Message-ID: To: Binod Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlc88FqC8isUId5mbjYmf8dfzwnm6zcZdp+WYht8WIycQuUrP9IwrVSTiiDXQ/RtdC4SS+D Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] Questions on SIP over websockets. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 11:50:27 -0000 2013/5/7 Binod : > As part of JSR 359 (SIP Servlet 2.0) standardization, we are working on > supporting SIP > over websocket ID in SIP servlets. I have a few questions on this I-D and > will be great, > if you can answer the following questions. > > - How do you envision the sip/websocket to be used? Do you expect webserv= ers > that use webrtc to also support sip/websocket or do you expect, the > sip/websocket > to be supported by the sip servers independent of webservers and thus w= eb > application and sip application run as independent entities? Or both? I expect both, but for now all the server implementations I know are pure SIP servers with recent WebSocket support. > - When a call come from a SIP UA to web browser (reverse of what is shown= in > 8.2), > one option the draft is suggesting is the use of RFC 5626 as the way to > identify the > flow to send the request. But the draft does not stop a proxy/b2b from > using some other > mechanism either. Is that intentional? Do the spec allow a webserver to > use a > websocket connection based on its logic to send the requests to the > client? SIP rules define that a request is routed based on its Route headers and Request-URI value. If a SIP-WebSocket proxy/server/entity routes the requests to a WS client based on other criterion then it is not playing SIP rules so such a behavior is out of the scope of SIP protocol and the draft. Anyhow some SIP servers/PBXs/B2BUAs already implement their own routing logic, regardless they don't implement RFC 5626. This is not something new in SIP over WebSocket, some occurs in SIP over TCP. > - JSEP in webrtc (section A.1.5) has a model that simply does offer/answe= r > using INVITE dialog. > So, if I understand correctly, REGISTER is not really required for a we= b > application. > Is that model allowed? The examples in the rfc draft and reference to > 5626 suggest the > use of REGISTER. Is that the intention? draft-sipcore-sip-websocket just defines a new transport for SIP, and not a new SIP protocol. If the SIP WebSocket Client does not perform SIP registration then it's hard to understand how a server/proxy could route requests to it. Of course it can be done in tons of proprietary ways, but the draft plays to SIP rules and thus registration + RFC 5626 seems a proper way for a SIP WebSocket Client to be able to receive incoming initial requests. Let us not consider SIP over WebSocket as something else than what it is: a new transport for SIP protocol, no more. This is still SIP. Best regards. -- I=C3=B1aki Baz Castillo From binod.pg@oracle.com Tue May 7 05:19:36 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 868D821F8F4D for ; Tue, 7 May 2013 05:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwUannaBkaj5 for ; Tue, 7 May 2013 05:19:31 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id B292B21F8611 for ; Tue, 7 May 2013 05:19:31 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r47CJU8R013058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 7 May 2013 12:19:31 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r47CJTP4021074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 7 May 2013 12:19:30 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r47CJTOL004166 for ; Tue, 7 May 2013 12:19:29 GMT Received: from [192.168.0.9] (/59.92.140.200) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 07 May 2013 05:19:29 -0700 Message-ID: <5188F14D.6040405@oracle.com> Date: Tue, 07 May 2013 17:49:25 +0530 From: Binod User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: sipcore@ietf.org References: <5188E77B.3040603@oracle.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Source-IP: acsinet22.oracle.com [141.146.126.238] Subject: Re: [sipcore] Questions on SIP over websockets. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 12:19:36 -0000 Thanks Inaki. On the JSEP and REGISTER, you are saying that, the server MUST use REGISTER + 5626. Did I get it right? In that case, why it is not mandated in the I-D? Given WS connections are always initiated from the client, Is there any way other than using 5626 to send a request from the server to the websocket client? thanks, Binod. On Tuesday 07 May 2013 05:20 PM, Iñaki Baz Castillo wrote: > 2013/5/7 Binod : >> As part of JSR 359 (SIP Servlet 2.0) standardization, we are working on >> supporting SIP >> over websocket ID in SIP servlets. I have a few questions on this I-D and >> will be great, >> if you can answer the following questions. >> >> - How do you envision the sip/websocket to be used? Do you expect webservers >> that use webrtc to also support sip/websocket or do you expect, the >> sip/websocket >> to be supported by the sip servers independent of webservers and thus web >> application and sip application run as independent entities? Or both? > I expect both, but for now all the server implementations I know are > pure SIP servers with recent WebSocket support. > > > >> - When a call come from a SIP UA to web browser (reverse of what is shown in >> 8.2), >> one option the draft is suggesting is the use of RFC 5626 as the way to >> identify the >> flow to send the request. But the draft does not stop a proxy/b2b from >> using some other >> mechanism either. Is that intentional? Do the spec allow a webserver to >> use a >> websocket connection based on its logic to send the requests to the >> client? > SIP rules define that a request is routed based on its Route headers > and Request-URI value. If a SIP-WebSocket proxy/server/entity routes > the requests to a WS client based on other criterion then it is not > playing SIP rules so such a behavior is out of the scope of SIP > protocol and the draft. > > Anyhow some SIP servers/PBXs/B2BUAs already implement their own > routing logic, regardless they don't implement RFC 5626. This is not > something new in SIP over WebSocket, some occurs in SIP over TCP. > > > > >> - JSEP in webrtc (section A.1.5) has a model that simply does offer/answer >> using INVITE dialog. >> So, if I understand correctly, REGISTER is not really required for a web >> application. >> Is that model allowed? The examples in the rfc draft and reference to >> 5626 suggest the >> use of REGISTER. Is that the intention? > draft-sipcore-sip-websocket just defines a new transport for SIP, and > not a new SIP protocol. If the SIP WebSocket Client does not perform > SIP registration then it's hard to understand how a server/proxy could > route requests to it. Of course it can be done in tons of proprietary > ways, but the draft plays to SIP rules and thus registration + RFC > 5626 seems a proper way for a SIP WebSocket Client to be able to > receive incoming initial requests. > > > Let us not consider SIP over WebSocket as something else than what it > is: a new transport for SIP protocol, no more. This is still SIP. > > > Best regards. > > > -- > Iñaki Baz Castillo > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From ibc@aliax.net Tue May 7 05:35:25 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5517F21F86DE for ; Tue, 7 May 2013 05:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAHesb2s0xsy for ; Tue, 7 May 2013 05:35:24 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id A348121F8FE3 for ; Tue, 7 May 2013 05:35:24 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id z10so239428qcx.14 for ; Tue, 07 May 2013 05:35:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=4jlhnx9PceRqugJuhtJARwWuJwnkFPBB5a3EOxK6FvU=; b=SnVaSrZp5HWwlwwQ15UK6Xd+4mlzQ4R6T6ZccB7Ux80lO5rqVaulSr5i2mroK5N5Fz s2z4f0yp3le3kI9ri7N7SSqFKc/9O5EqbUotoPEB58OTbxppxN09D+PeZnlgdzwv/dXW zJes0Us/3Bs48358o7wNq4Da4/Bpioc1Xxov7BC/EVqtcriyknTnHCmtbeL5A01mk7M/ xxjJdwRT9Yst6yr1Al6WGBVnzA10yPKbBTb14UKqyuGK3Le9PUaNiOZMzjwruZEn+zjs uXuq9Q0auMIwcEKnhlqk847pz7Qbd7a6XecK46BKKeWCUZwmzKW7z5DLW0n/mz5nRdHK 82Cw== X-Received: by 10.229.150.199 with SMTP id z7mr544496qcv.25.1367930123973; Tue, 07 May 2013 05:35:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.81.175 with HTTP; Tue, 7 May 2013 05:35:03 -0700 (PDT) In-Reply-To: <5188F14D.6040405@oracle.com> References: <5188E77B.3040603@oracle.com> <5188F14D.6040405@oracle.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 7 May 2013 14:35:03 +0200 Message-ID: To: Binod Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk3h8jpTlck5t58LCzxG74UH51C2tnVxwwyUJTt21mjoNshXa9fNILNSDL84kYVr8+QAJJh Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] Questions on SIP over websockets. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 12:35:25 -0000 2013/5/7 Binod : > Thanks Inaki. > > On the JSEP and REGISTER, you are saying that, the server MUST use > REGISTER + 5626. Did I get it right? No, I never said "MUST" :) > In that case, why it is not mandated in the I-D? The SIPCORE WG already decided in a previous IETF meeting that the draft should not mandate Outbound, and I agree, since the draft just defines a new transport for SIP. > Given WS connections are always initiated from the client, Is there any w= ay > other than using 5626 to send a request from the server to the > websocket client? Yes, proprietary solutions like those implemented in MOST of the SIP servers when a SIP TCP client connects to it and the server reuses such a TCP connection for routing *everything* to the UA regardless RFC 5626 is not used, announced or supported by the UA and/or the server. Examples: Asterisk, SER/Kamailio/OpenSIPS, 99% of comercial SIP servers I've tested, etc. Regards. -- I=C3=B1aki Baz Castillo From binod.pg@oracle.com Tue May 7 08:34:04 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6758721F8E96 for ; Tue, 7 May 2013 08:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wM2F1TjwVtX4 for ; Tue, 7 May 2013 08:33:59 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id F0EB821F8F0D for ; Tue, 7 May 2013 08:33:57 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r47FXueO012988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 7 May 2013 15:33:57 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r47FXur7008452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 7 May 2013 15:33:56 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r47FXuSP008447 for ; Tue, 7 May 2013 15:33:56 GMT Received: from [192.168.0.9] (/59.92.140.200) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 07 May 2013 08:33:55 -0700 Message-ID: <51891EE1.2030402@oracle.com> Date: Tue, 07 May 2013 21:03:53 +0530 From: Binod User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: sipcore@ietf.org References: <5188E77B.3040603@oracle.com> <5188F14D.6040405@oracle.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Source-IP: acsinet21.oracle.com [141.146.126.237] Subject: Re: [sipcore] Questions on SIP over websockets. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 15:34:04 -0000 On Tuesday 07 May 2013 06:05 PM, Iñaki Baz Castillo wrote: > 2013/5/7 Binod : >> Thanks Inaki. >> >> On the JSEP and REGISTER, you are saying that, the server MUST use >> REGISTER + 5626. Did I get it right? > No, I never said "MUST" :) > > >> In that case, why it is not mandated in the I-D? > The SIPCORE WG already decided in a previous IETF meeting that the > draft should not mandate Outbound, and I agree, since the draft just > defines a new transport for SIP. > > > >> Given WS connections are always initiated from the client, Is there any way >> other than using 5626 to send a request from the server to the >> websocket client? > Yes, proprietary solutions like those implemented in MOST of the SIP > servers when a SIP TCP client connects to it and the server reuses > such a TCP connection for routing *everything* to the UA regardless > RFC 5626 is not used, announced or supported by the UA and/or the > server. Examples: Asterisk, SER/Kamailio/OpenSIPS, 99% of comercial > SIP servers I've tested, etc. > > > Regards. It matches with my understanding. As it stands today, the I-D allows, though it doesn't encourage, webservers to use their own mechanism to route the SIP messages instead of using REGISTER+5626. I don't necessarily disagree with either approach. Just wanted to make sure that the standard we are working on allows what the I-D intends to allow. Thanks. Binod. > > > > > > > > > -- > Iñaki Baz Castillo > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@alum.mit.edu Tue May 7 10:58:12 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9755A21F940B for ; Tue, 7 May 2013 10:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.302 X-Spam-Level: X-Spam-Status: No, score=0.302 tagged_above=-999 required=5 tests=[AWL=0.739, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzdkiNrviCP5 for ; Tue, 7 May 2013 10:58:08 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id DA28F21F9408 for ; Tue, 7 May 2013 10:58:07 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta01.westchester.pa.mail.comcast.net with comcast id YzaM1l0071ei1Bg515y7vm; Tue, 07 May 2013 17:58:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id Z5y71l0043ZTu2S3k5y7XW; Tue, 07 May 2013 17:58:07 +0000 Message-ID: <518940AE.508@alum.mit.edu> Date: Tue, 07 May 2013 13:58:06 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: sipcore@ietf.org References: <5188E77B.3040603@oracle.com> <5188F14D.6040405@oracle.com> <51891EE1.2030402@oracle.com> In-Reply-To: <51891EE1.2030402@oracle.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367949487; bh=SJ8UfYls8dxwNCVycvIPuxoDDRU9GBKuHgRSYjlFk/s=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=cjHE8/Vz8DDBNxGzuEYJYhAyNifFu91gpd4IrZpcn06rYQHYDhhcY1awzpPT9ow1D uKKLfkDAiyz1jHlkwiwo3U0oKYSML0e4eoa6xMs9XU7HlaUYGmuzPyV+KOQq857WAB af93y2ipDx0n9ulobRGrrGrqw0RHI45RwHvgrma034As3/USOiVO96WOalDGAWS0yS ZFmOuOEFKnbbt3L3igih1eAhhSIObG9TUKNq/3nWAfRlBDUseMqHqh+m0CB7XusPpI rhff35mhOGupJFBR0w0XzNso204LSmUGzIoK+5dmohrDdjqbdpCtZkeDjxvbcPwRTe TF6j1OMumsI1g== Subject: Re: [sipcore] Questions on SIP over websockets. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 17:58:12 -0000 On 5/7/13 11:33 AM, Binod wrote: > On Tuesday 07 May 2013 06:05 PM, Iñaki Baz Castillo wrote: >> 2013/5/7 Binod : >>> Thanks Inaki. >>> >>> On the JSEP and REGISTER, you are saying that, the server MUST use >>> REGISTER + 5626. Did I get it right? >> No, I never said "MUST" :) >> >> >>> In that case, why it is not mandated in the I-D? >> The SIPCORE WG already decided in a previous IETF meeting that the >> draft should not mandate Outbound, and I agree, since the draft just >> defines a new transport for SIP. Not mandating it allows flexibility and support of future extensions. If you are building strictly standards compliant products, then *for now* outbound is the only way you will be able to receive outbound calls. But of course you could still *initiate* calls without this. >>> Given WS connections are always initiated from the client, Is there >>> any way >>> other than using 5626 to send a request from the server to the >>> websocket client? >> Yes, proprietary solutions like those implemented in MOST of the SIP >> servers when a SIP TCP client connects to it and the server reuses >> such a TCP connection for routing *everything* to the UA regardless >> RFC 5626 is not used, announced or supported by the UA and/or the >> server. Examples: Asterisk, SER/Kamailio/OpenSIPS, 99% of comercial >> SIP servers I've tested, etc. >> >> >> Regards. > > It matches with my understanding. As it stands today, the I-D allows, > though it doesn't encourage, webservers to use their own mechanism > to route the SIP messages instead of using REGISTER+5626. > > I don't necessarily disagree with either approach. Just wanted to > make sure that the standard we are working on allows what the > I-D intends to allow. There is nothing inherently *wrong* with this. SIP gives proxies great leeway to employ their own routing policies. It just means that the portions of the system that do this are *proprietary*. Thanks, Paul From worley@shell01.TheWorld.com Tue May 7 13:30:16 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4973221F92BC for ; Tue, 7 May 2013 13:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.825 X-Spam-Level: X-Spam-Status: No, score=-0.825 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619, SARE_OBFU_PART_CIA=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YfoulpFfnFM for ; Tue, 7 May 2013 13:30:10 -0700 (PDT) Received: from TheWorld.com (pcls4.std.com [192.74.137.144]) by ietfa.amsl.com (Postfix) with ESMTP id 81C4821F912C for ; Tue, 7 May 2013 13:30:06 -0700 (PDT) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r47KTcH0011239; Tue, 7 May 2013 16:29:40 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r47KTcCf4278487; Tue, 7 May 2013 16:29:38 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r47KTb754337901; Tue, 7 May 2013 16:29:37 -0400 (EDT) Date: Tue, 7 May 2013 16:29:37 -0400 (EDT) Message-Id: <201305072029.r47KTb754337901@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Inaki Baz Castillo In-reply-to: (ibc@aliax.net) References: <339625C1-F16E-429F-BA62-066F6F6B3B51@edvina.net> <6360A039-E87A-4872-A480-587FC9F84D2F@edvina.net> <201305021842.r42Ig2DO3979809@shell01.TheWorld.com> <201305030115.r431FRoS4006275@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36B55D@ESESSMB209.ericsson.se> <201305031801.r43I1cSY4050203@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36B7BA@ESESSMB209.ericsson.se> <201305062200.r46M0wjP4269356@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36C7C8@ESESSMB209.ericsson.se> Cc: sipcore@ietf.org Subject: Re: [sipcore] [dispatch] SIP outbound and in-dialog requests X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 20:30:16 -0000 [Moving this discussion to Sipcore.] [Sorry about losing the diacritic on the "n".] > From: IC1aki Baz Castillo > > Anyhow, it seems that nobody wants to reply to the problem I describe. > Is it not clear? Let me re-explain it: It is not at all clear to me. There may be important details that I don't recall at this point, but even so, it would be very useful if you could provide additional explanation at a number of points. > - Bob registers with GRUU and Outbound. EDGE adds Path: > > Path: > > > - Alice calls Bob. Once the call is established, the route set from > Alice is as follows: > > Route: > Route: OK, you need to explain why the registrar record-routes itself. > - So an in-dialog INFO from Alice looks as follows: > > INFO sip:bob@biloxi.com;gr=GRUU_1 > Route: > Route: > > - When the INFO arrives to the REGISTRAR, the REGISTRAR MUST perform > GRUU lookup, RIGHT?? No, because the registrar only needs to forward the request to , the next address in the route set after the registrar's address, and that doesn't contain a GRUU. In general, a SIP element shouldn't be looking at addresses beyone the next address in the route set. Dale From pkyzivat@alum.mit.edu Tue May 7 14:23:54 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADC221F905F for ; Tue, 7 May 2013 14:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.96 X-Spam-Level: X-Spam-Status: No, score=0.96 tagged_above=-999 required=5 tests=[AWL=-0.869, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_23=0.6, RDNS_NONE=0.1, SARE_OBFU_PART_CIA=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hts7HdJ238ti for ; Tue, 7 May 2013 14:23:48 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 100F221F8E75 for ; Tue, 7 May 2013 14:23:47 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta03.westchester.pa.mail.comcast.net with comcast id YzZ51l00B27AodY539Pnex; Tue, 07 May 2013 21:23:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id Z9Pm1l00k3ZTu2S3f9Pma7; Tue, 07 May 2013 21:23:46 +0000 Message-ID: <518970E2.9020400@alum.mit.edu> Date: Tue, 07 May 2013 17:23:46 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: sipcore@ietf.org References: <6360A039-E87A-4872-A480-587FC9F84D2F@edvina.net> <201305021842.r42Ig2DO3979809@shell01.TheWorld.com> <201305030115.r431FRoS4006275@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36B55D@ESESSMB209.ericsson.se> <201305031801.r43I1cSY4050203@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36B7BA@ESESSMB209.ericsson.se> <201305062200.r46M0wjP4269356@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36C7C8@ESESSMB209.ericsson.se> <201305072029.r47KTb754337901@shell01.TheWorld.com> In-Reply-To: <201305072029.r47KTb754337901@shell01.TheWorld.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367961827; bh=x4wEfNu4v6E/rmdcUz0r1ZWmplvsXt14FfTPo9rdhEM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=PX5/KWbxZtYjR5w2bs9nncfB55ddB76zgAnXGPSHkBgyvc1AhQVYqbNr8Oorczqb3 vi11+7Lde2JSaMV/1j2GltSqvLkGjeBY+3UKzGyqMHRwnnspDBHG1Cl2SdRZxmM4Dc lBm/xfOcSiPnCmuphOHkaaseZ7GFl8pgcqBU2tHOd4IENEg+hl6LOrfjlbuZnZeiO3 xC87ukLxVU5xDIEFbjFuik7uTI0MXCIBI4xnapf4OjzLIFu6vzLcnb+Y0Sf1JVYFDq jQgqJGVa+UFBaDq0VlodBjn7M/i3HY3lehzlL1UOjwbqY54BKaTcHlXuo+V7XhI30f Zqr0W5niM6g1Q== Subject: Re: [sipcore] [dispatch] SIP outbound and in-dialog requests X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 21:23:54 -0000 At end... On 5/7/13 4:29 PM, Dale R. Worley wrote: > [Moving this discussion to Sipcore.] > > [Sorry about losing the diacritic on the "n".] > >> From: IC1aki Baz Castillo >> >> Anyhow, it seems that nobody wants to reply to the problem I describe. >> Is it not clear? Let me re-explain it: > > It is not at all clear to me. There may be important details that I > don't recall at this point, but even so, it would be very useful if > you could provide additional explanation at a number of points. > >> - Bob registers with GRUU and Outbound. EDGE adds Path: >> >> Path: >> >> >> - Alice calls Bob. Once the call is established, the route set from >> Alice is as follows: >> >> Route: >> Route: > > OK, you need to explain why the registrar record-routes itself. > >> - So an in-dialog INFO from Alice looks as follows: >> >> INFO sip:bob@biloxi.com;gr=GRUU_1 >> Route: >> Route: >> >> - When the INFO arrives to the REGISTRAR, the REGISTRAR MUST perform >> GRUU lookup, RIGHT?? > > No, because the registrar only needs to forward the request to > , the next address in the route set after > the registrar's address, and that doesn't contain a GRUU. In general, > a SIP element shouldn't be looking at addresses beyone the next > address in the route set. I always thought that, (and I still do, BUT) if you read 3261 carefully, you will discover that the instructions are to first look at the R-URI, and if you are responsible for it, then translate it. Once you have done that, then you still use the Route to decide on next place to go. I think it is the wrong thing to do, but it is what it says. IMO you should not pay any attention to the R-URI if there is a Route header. But that's just me. The other thing is: if the contact is a GRUU, you really *want* it to translate it for each request in the dialog. And you want there to be no pending Route headers at that time, so that the Path corresponding to the GRUU can be followed. Thanks, Paul From jonathan@hansfords.net Fri May 10 04:08:53 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB0FB21F8FE9 for ; Fri, 10 May 2013 04:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZeOql9NsH6q for ; Fri, 10 May 2013 04:08:47 -0700 (PDT) Received: from avasout03.plus.net (avasout03.plus.net [84.93.230.244]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB1621F8FED for ; Fri, 10 May 2013 04:08:46 -0700 (PDT) Received: from webmail.plus.net ([84.93.228.147]) by avasout03 with smtp id aB8k1l0033BT6uC01B8kMN; Fri, 10 May 2013 12:08:44 +0100 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=Wq0Sb7vv c=1 sm=1 tr=0 a=jSQgp9IWXRf89EXR5FPwJg==:117 a=zvOXFpZrtIe2DiqMBxawyA==:17 a=0Bzu9jTXAAAA:8 a=jkFKeVsF5M4A:10 a=dYCPD3cKDi0A:10 a=0B8HqoTn75oA:10 a=6bkCdLdQAAAA:8 a=f0uUZFObAAAA:8 a=ffJw79X0-78A:10 a=y44CGAe1oIjpokyu1nMA:9 a=amxVXBjOgUjlLSVC:21 a=xAoeUfa2sB8MCRK3:21 a=QEXdDO2ut3YA:10 a=Y6f2u3JI4I1zbB773vYA:9 a=_W_S_7VecoQA:10 X-AUTH: hansfords+us:2500 Received: from host-212-159-131-154.static.as13285.net ([212.159.131.154]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Fri, 10 May 2013 12:08:44 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_758f6a6545c06600eeeda4d840b6cad6" Date: Fri, 10 May 2013 12:08:44 +0100 From: Jonathan Hansford To: Message-ID: <984edebb3d71943ddd13940a3ea1b148@imap.plus.net> X-Sender: Jonathan@hansfords.net User-Agent: Roundcube Webmail/0.7.4 X-Originating-IP: [212.159.131.154] Subject: [sipcore] SIP and Internationalisation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 11:08:54 -0000 --=_758f6a6545c06600eeeda4d840b6cad6 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 Hi, I am currently looking at a number of Internet protocols for international use and am looking to see how much commonality there is between them. A number are, or are in the process of becoming, IDNA2008 aware (e.g. DNS - RFC 5890, SMTP - RFC 6530/1, XMPP - draft-ietf-xmpp-6122bis-07). I have been trying to identify what support for internationalization there is within SIP and can find no reference to it. Can you advise what level of support (if any) SIP currently provides for countries whose native language is not (adequately) supported by US ASCII and/or whether there are any plans to address this in the future? Thanks, Jonathan Hansford --=_758f6a6545c06600eeeda4d840b6cad6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi,

I am currently looking at a number of Internet protocols for internation= al use and am looking to see how much commonality there is between them. A = number are, or are in the process of becoming, IDNA2008 aware (e.g. DNS - R= FC 5890, SMTP - RFC 6530/1, XMPP - draft-ietf-xmpp-6122bis-07).

I have been trying to identify what support for internationalization the= re is within SIP and can find no reference to it. Can you advise what level= of support (if any) SIP currently provides for countries whose native lang= uage is not (adequately) supported by US ASCII and/or whether there are any= plans to address this in the future?

Thanks,

Jonathan Hansford

--=_758f6a6545c06600eeeda4d840b6cad6-- From gunnar.hellstrom@omnitor.se Fri May 10 08:08:52 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6BBC21F8B64 for ; Fri, 10 May 2013 08:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YjxUSVBoJCS for ; Fri, 10 May 2013 08:08:47 -0700 (PDT) Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 4AB3521F85F7 for ; Fri, 10 May 2013 08:08:46 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP; Fri, 10 May 2013 17:08:39 +0200 (CEST) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-02-01.atm.binero.net (Postfix) with ESMTPA id 0E2AF3A125; Fri, 10 May 2013 17:08:39 +0200 (CEST) Message-ID: <518D0D78.60408@omnitor.se> Date: Fri, 10 May 2013 17:08:40 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: sipcore@ietf.org, Peter Saint-Andre References: <984edebb3d71943ddd13940a3ea1b148@imap.plus.net> In-Reply-To: <984edebb3d71943ddd13940a3ea1b148@imap.plus.net> Content-Type: multipart/alternative; boundary="------------080004030102040607070307" Subject: Re: [sipcore] SIP and Internationalisation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 15:08:52 -0000 This is a multi-part message in MIME format. --------------080004030102040607070307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Jonathan, Most items in SIP are UTF-8 coded, so I think there is good preparedness for internationlaization. I think you should coordinate your activities with this draft, that is going in the other direction - trying to find out the minimal common set to be used in addressing in multiple services. It might need your results as a separate section and its current information may be answer on your current question. https://datatracker.ietf.org/doc/draft-saintandre-username-interop Regards Gunnar Hellström On 2013-05-10 13:08, Jonathan Hansford wrote: > > Hi, > > I am currently looking at a number of Internet protocols for > international use and am looking to see how much commonality there is > between them. A number are, or are in the process of becoming, > IDNA2008 aware (e.g. DNS - RFC 5890, SMTP - RFC 6530/1, XMPP - > draft-ietf-xmpp-6122bis-07). > > I have been trying to identify what support for internationalization > there is within SIP and can find no reference to it. Can you advise > what level of support (if any) SIP currently provides for countries > whose native language is not (adequately) supported by US ASCII and/or > whether there are any plans to address this in the future? > > Thanks, > > Jonathan Hansford > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --------------080004030102040607070307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Jonathan,
Most items in SIP are UTF-8 coded, so I think there is good preparedness for internationlaization.
I think you should coordinate your activities with this draft, that is going in the other direction - trying to find out the minimal common set to be used in addressing in multiple services. It might need your results as a separate section and its current information may be answer on your current question.
https://datatracker.ietf.org/doc/draft-saintandre-username-interop 
Regards

Gunnar Hellström
On 2013-05-10 13:08, Jonathan Hansford wrote:

Hi,

I am currently looking at a number of Internet protocols for international use and am looking to see how much commonality there is between them. A number are, or are in the process of becoming, IDNA2008 aware (e.g. DNS - RFC 5890, SMTP - RFC 6530/1, XMPP - draft-ietf-xmpp-6122bis-07).

I have been trying to identify what support for internationalization there is within SIP and can find no reference to it. Can you advise what level of support (if any) SIP currently provides for countries whose native language is not (adequately) supported by US ASCII and/or whether there are any plans to address this in the future?

Thanks,

Jonathan Hansford



_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

--------------080004030102040607070307-- From stpeter@stpeter.im Fri May 10 08:22:34 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F7521F898B for ; Fri, 10 May 2013 08:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-r8a2qLwXac for ; Fri, 10 May 2013 08:22:23 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B94A121F8AE2 for ; Fri, 10 May 2013 08:22:23 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E37B34111A; Fri, 10 May 2013 09:34:08 -0600 (MDT) Message-ID: <518D10AD.4030201@stpeter.im> Date: Fri, 10 May 2013 09:22:21 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Gunnar Hellstrom References: <984edebb3d71943ddd13940a3ea1b148@imap.plus.net> <518D0D78.60408@omnitor.se> In-Reply-To: <518D0D78.60408@omnitor.se> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] SIP and Internationalisation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 15:22:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 5/10/13 9:08 AM, Gunnar Hellstrom wrote: > Jonathan, Most items in SIP are UTF-8 coded, so I think there is > good preparedness for internationlaization. In my experience, no one is ever fully prepared for internationalization. :-) > I think you should coordinate your activities with this draft, that > is going in the other direction - trying to find out the minimal > common set to be used in addressing in multiple services. It might > need your results as a separate section and its current information > may be answer on your current question. > https://datatracker.ietf.org/doc/draft-saintandre-username-interop That is a very early effort, and I deliberately punted on the i18n aspects. If the work is compelling, I can address i18n in a future version. > On 2013-05-10 13:08, Jonathan Hansford wrote: >> >> Hi, >> >> I am currently looking at a number of Internet protocols for >> international use and am looking to see how much commonality >> there is between them. A number are, or are in the process of >> becoming, IDNA2008 aware (e.g. DNS - RFC 5890, SMTP - RFC 6530/1, >> XMPP - draft-ietf-xmpp-6122bis-07). In addition to the IDNA2008 work, I strongly recommend that you look at the output of the PRECIS WG (which generalizes the IDNA2008 approach to identifiers other than domain names, such as the localpart of a SIP URI): http://datatracker.ietf.org/wg/precis/ >> I have been trying to identify what support for >> internationalization there is within SIP and can find no >> reference to it. Can you advise what level of support (if any) >> SIP currently provides for countries whose native language is not >> (adequately) supported by US ASCII and/or whether there are any >> plans to address this in the future? I can't speak to that directly, but I'm happy to help. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRjRCtAAoJEOoGpJErxa2pW64QAIg2k363Ket7ccxxVu5NrENU weELLT/SwhyGZTDr/zWDE+MjU8mbkjYaSQoIfqbXYQxkyibv4dGx07u1CwDWxtp6 3mfbNVUHhwIvEws9L37JhTCOn0Vh3ppsklLxrPkJ+KYQ0ct/LwFpxINLeEDQAzKy Z0gZJc/mwsEzcFs5Wfn4h4beuiz2k7Q1UuPzfuaqsNjNuk4NFaYQWJKs1r06wQsO K2Z8QMeozsUFRvTLKaHob8cpoJm1qRZkzqBrCG3kv0a9SlLOvtbEHp8wX5Iw9GNG O+BF5k2hFzZEr2P1veLhCZqnAfq2fL5yavDgw07ag+ZelOXvwMDvSFIp36T1VhqO 2oDFbvKhY3SW7BItKckPRuC447aAnhP7ndSRcWgbSbruMgiTUkmfeXeSV6IFlYuU 1dBkD365oc2f2WxLu2BpfvDNp+3P1zSA7T8hEWRvkD4s9wgKBbKK/KJ5eMKr/m9f aqAEFFfubzkiiaZjRXaAksLU4zvF82rFCrSKb2E6XzgfiKq1qiRjXzLPPiWYcEut KKLrw62LS1yN+Yy0dqLfZB+LOjhxIBWnJqq+Py9s1YopRs9sByEDWskB/ZBYgXVD owPQEeVFwaTxAsM1Mf6o/SHVfRHUqTMSQcKR7PD+n6ijXps4Dr6QT3jZl8jekCKs XZzvH1XNamXWutjQL7Fr =Daua -----END PGP SIGNATURE----- From stpeter@stpeter.im Fri May 10 08:51:35 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE4AE21F84B0 for ; Fri, 10 May 2013 08:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HeKxVlwmQZPd for ; Fri, 10 May 2013 08:51:27 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B3BAA21F8AA8 for ; Fri, 10 May 2013 08:51:24 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7EAF34111A; Fri, 10 May 2013 10:03:08 -0600 (MDT) Message-ID: <518D1778.7020307@stpeter.im> Date: Fri, 10 May 2013 09:51:20 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Gunnar Hellstrom References: <984edebb3d71943ddd13940a3ea1b148@imap.plus.net> <518D0D78.60408@omnitor.se> <518D10AD.4030201@stpeter.im> In-Reply-To: <518D10AD.4030201@stpeter.im> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] SIP and Internationalisation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 15:51:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 5/10/13 9:22 AM, Peter Saint-Andre wrote: > On 5/10/13 9:08 AM, Gunnar Hellstrom wrote: >> Jonathan, Most items in SIP are UTF-8 coded, so I think there is >> good preparedness for internationlaization. > > In my experience, no one is ever fully prepared for > internationalization. :-) Someone asked me this off-list, but it's useful to discuss it in public... Thinking that UTF-8 solves your internationalization problems is like thinking that TLS solves your security problems. I hate to break it to you, but it's not that simple. Yes, using UTF-8 encoding is better than being stuck with ASCII, but there are many many challenging issues with internationalization. The following slides might help orient folks who are new to i18n: https://stpeter.im/files/i18n-intro.pdf Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRjRd4AAoJEOoGpJErxa2pJMoP/iRdz9bqSgsO8kH6GRFlijU6 q9F7ozFBWFK0ZUCAE9XPFmb7A1+7aKtaz0WZSVaFCi3n8/aoIf+Nt0cKue5ngInc 0wQe5jjEaQXb13QXqMUbJLguu1QSlWyF8+/+kfDnHggS8TjgtnQ8ya9D/+7BBxlX Aq39ish5EILybUI2Mi2ovXa6QGRQN+EX5Y0nyge+9LM2qGgrl3x5Nx1jwiW5twMz qGLwEMSSMOU/j9kLzWXjLd4yTSHZB88kN+gBz4lwSWLr5JQzflZZ4w/fTY+Zg99Y +oLsy+Rer+Elq1s8uhixCdxJoYV2lDSoqlZgcY7nx97d3biogvtDPwYtqJeS1qe/ 1hL//HGDQDhF77Zu08NZ0KC8geqbzZBG5c5MZW2ZpErJvQWzkA/wp7jRXVoTawn6 acjKwFNz2viO5yxZNDjaphtHZda8EjPqSLWT7ZSi7/SBoGrKBchZ1SBwSUd0fqMq +QQhZafQDke36HnFzdHTSGtNz2/e14LeIXY2xFHsE7dPRcS/hu/TleH5F5tA4uDW xrOqZOXL6OX6w+Ofs/2o68jjANHAFMTfhmrTlEX7rSuKE7NZJLtWZlJP+80m2GZ+ xGdoVf7Ndp2tX8//sXE/Fhxhv4T9zPc6jJJxPzSihqhmJlhynaHoCZ7lrzeEhneK RCGW8JQ2vEpP7WNm1nLa =n8b3 -----END PGP SIGNATURE----- From adam@nostrum.com Fri May 10 09:17:02 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0543121F8F69 for ; Fri, 10 May 2013 09:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQMC9no7ATOO for ; Fri, 10 May 2013 09:17:01 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5E621F8F53 for ; Fri, 10 May 2013 09:16:59 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r4AGGsaK086529 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 10 May 2013 11:16:56 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <518D1D76.800@nostrum.com> Date: Fri, 10 May 2013 11:16:54 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Jonathan Hansford References: <984edebb3d71943ddd13940a3ea1b148@imap.plus.net> In-Reply-To: <984edebb3d71943ddd13940a3ea1b148@imap.plus.net> Content-Type: multipart/alternative; boundary="------------050201090501000109070906" Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: sipcore@ietf.org Subject: Re: [sipcore] SIP and Internationalisation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 16:17:02 -0000 This is a multi-part message in MIME format. --------------050201090501000109070906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jonathan: As far as I know, there has been no serious work on SIP's i18n story so far. The closest we come is the use of UTF-8 everywhere. While an international character encoding is a necessary part of the story, it's far from sufficient. I've known for quite some time that SIP's IDN story is conspicuous by its absence. I've never really had the time to poke at existing, deployed implementations to see what they do when you feed unicode characters into domain names. Given the lack of specification, I doubt most of them do anything useful. Some might accidentally kind of work, depending on what punycode support their underlying DNS libraries provide, but the chances of this being done in a way that yields success seems extremely slim. The other area we need to worry about, as Gunnar and Peter hinted at, is usernames. The big issue here (as I understand it) is the application of stringprep for the purpose of measuring username equality. I'd been keeping my eyes, very loosely, on the IRI work in hope that we could leverage its output in a future SIP internationalization effort, since it would hopefully provide guidance on both the IDN and stringprep issues. Sadly, that work seems to have been terminated before producing useful output, so we'll have to make our own way through this morass. There are probably some similar issues for password normalization, although I'm not sure that's as much of an issue, since passwords, by their nature, are generated in a more repeatable way than usernames are. I would expect that people who have spent far more time than I have thinking about the problem have some ideas here. Aside from URIs and Digest credentials, there is mercifully little in the way of protocol fields intended to be user-visible for SIP. A handful, like Organization and Subject, were specified in a way that implied that they should be user-renderable; however, in practice, no one ever uses these fields (and, in any case, I don't think they pose any particular i18n challenges, as these fields are not machine-interpretable, and do allow UTF-8 characters). In practice, most implementations them do a lousy job of l10n (e.g. for response Reason-Phrases) , but I don't think we're missing anything protocol-wise; this seems to be a failing of the implementations themselves. I think that's the vast majority of what you need to worry about in terms of the core SIP protocol. Now, there are some protocols we use (e.g., BFCP, TLS, CCMP, S/MIME) that we would rely on having sufficient internationalization support, but I would be inclined to consider those a separable effort. In any case, if you can find enough critical mass of people with the energy and time to move this work forward, I would welcome it wholeheartedly. I believe that, the way the charter is currently written, this work is likely to fall under the purview of the SIPCORE working group. /a On 5/10/13 06:08, Jonathan Hansford wrote: > > Hi, > > I am currently looking at a number of Internet protocols for > international use and am looking to see how much commonality there is > between them. A number are, or are in the process of becoming, > IDNA2008 aware (e.g. DNS - RFC 5890, SMTP - RFC 6530/1, XMPP - > draft-ietf-xmpp-6122bis-07). > > I have been trying to identify what support for internationalization > there is within SIP and can find no reference to it. Can you advise > what level of support (if any) SIP currently provides for countries > whose native language is not (adequately) supported by US ASCII and/or > whether there are any plans to address this in the future? > > Thanks, > > Jonathan Hansford > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --------------050201090501000109070906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Jonathan:

As far as I know, there has been no serious work on SIP's i18n story so far. The closest we come is the use of UTF-8 everywhere. While an international character encoding is a necessary part of the story, it's far from sufficient.

I've known for quite some time that SIP's IDN story is conspicuous by its absence. I've never really had the time to poke at existing, deployed implementations to see what they do when you feed unicode characters into domain names. Given the lack of specification, I doubt most of them do anything useful. Some might accidentally kind of work, depending on what punycode support their underlying DNS libraries provide, but the chances of this being done in a way that yields success seems extremely slim.

The other area we need to worry about, as Gunnar and Peter hinted at, is usernames. The big issue here (as I understand it) is the application of stringprep for the purpose of measuring username equality.

I'd been keeping my eyes, very loosely, on the IRI work in hope that we could leverage its output in a future SIP internationalization effort, since it would hopefully provide guidance on both the IDN and stringprep issues. Sadly, that work seems to have been terminated before producing useful output, so we'll have to make our own way through this morass.

There are probably some similar issues for password normalization, although I'm not sure that's as much of an issue, since passwords, by their nature, are generated in a more repeatable way than usernames are. I would expect that people who have spent far more time than I have thinking about the problem have some ideas here.

Aside from URIs and Digest credentials, there is mercifully little in the way of protocol fields intended to be user-visible for SIP. A handful, like Organization and Subject, were specified in a way that implied that they should be user-renderable; however, in practice, no one ever uses these fields (and, in any case, I don't think they pose any particular i18n challenges, as these fields are not machine-interpretable, and do allow UTF-8 characters).

In practice, most implementations them do a lousy job of l10n (e.g. for response Reason-Phrases) , but I don't think we're missing anything protocol-wise; this seems to be a failing of the implementations themselves.

I think that's the vast majority of what you need to worry about in terms of the core SIP protocol. Now, there are some protocols we use (e.g., BFCP, TLS, CCMP, S/MIME) that we would rely on having sufficient internationalization support, but I would be inclined to consider those a separable effort.

In any case, if you can find enough critical mass of people with the energy and time to move this work forward, I would welcome it wholeheartedly. I believe that, the way the charter is currently written, this work is likely to fall under the purview of the SIPCORE working group.

/a


On 5/10/13 06:08, Jonathan Hansford wrote:

Hi,

I am currently looking at a number of Internet protocols for international use and am looking to see how much commonality there is between them. A number are, or are in the process of becoming, IDNA2008 aware (e.g. DNS - RFC 5890, SMTP - RFC 6530/1, XMPP - draft-ietf-xmpp-6122bis-07).

I have been trying to identify what support for internationalization there is within SIP and can find no reference to it. Can you advise what level of support (if any) SIP currently provides for countries whose native language is not (adequately) supported by US ASCII and/or whether there are any plans to address this in the future?

Thanks,

Jonathan Hansford



_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

--------------050201090501000109070906-- From stpeter@stpeter.im Fri May 10 10:08:09 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32EAB21F898A for ; Fri, 10 May 2013 10:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIuczT2YCQIJ for ; Fri, 10 May 2013 10:08:04 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B696421F8972 for ; Fri, 10 May 2013 10:08:04 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.235]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7F7F34111A; Fri, 10 May 2013 11:19:50 -0600 (MDT) Message-ID: <518D2972.60809@stpeter.im> Date: Fri, 10 May 2013 11:08:02 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Adam Roach References: <984edebb3d71943ddd13940a3ea1b148@imap.plus.net> <518D1D76.800@nostrum.com> In-Reply-To: <518D1D76.800@nostrum.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org, Jonathan Hansford Subject: Re: [sipcore] SIP and Internationalisation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 17:08:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Adam, a few corrections and amplifications inline. On 5/10/13 10:16 AM, Adam Roach wrote: > Jonathan: > > As far as I know, there has been no serious work on SIP's i18n > story so far. The closest we come is the use of UTF-8 everywhere. > While an international character encoding is a necessary part of > the story, it's far from sufficient. > > I've known for quite some time that SIP's IDN story is conspicuous > by its absence. I've never really had the time to poke at > existing, deployed implementations to see what they do when you > feed unicode characters into domain names. Given the lack of > specification, I doubt most of them do anything useful. Some might > accidentally kind of work, depending on what punycode support their > underlying DNS libraries provide, but the chances of this being > done in a way that yields success seems extremely slim. It's not just punycode (RFC 3492) but the framework that re-uses punycode. The original framework was IDNA2003 (RFC 3490), which has been superseded by RFCs 5890-5894. However, the world is migrating to IDNA2008 in a rather slow fashion, so many applications still use IDNA2003. > The other area we need to worry about, as Gunnar and Peter hinted > at, is usernames. The big issue here (as I understand it) is the > application of stringprep for the purpose of measuring username > equality. IDNA2003 used stringprep, which was tied to Unicode 3.2 (the current version is 6.2). IDNA2008 ditched stringprep so that it could be agile with respect to Unicode versions. The PRECIS WG is doing the same for non-DNS identifiers. > I'd been keeping my eyes, very loosely, on the IRI work in hope > that we could leverage its output in a future SIP > internationalization effort, since it would hopefully provide > guidance on both the IDN and stringprep issues. Sadly, that work > seems to have been terminated before producing useful output, so > we'll have to make our own way through this morass. The IRI WG was trying to update RFC 3987, but that effort ran out of steam. However, RFC 3987 still exists and is usable. > There are probably some similar issues for password normalization, > although I'm not sure that's as much of an issue, since passwords, > by their nature, are generated in a more repeatable way than > usernames are. I would expect that people who have spent far more > time than I have thinking about the problem have some ideas here. See RFC 4103 (SASLprep) and draft-ietf-precis-saslprepbis. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRjSlyAAoJEOoGpJErxa2poVsQAJvMnZzXiqXe6OeL5NXekqBT LV+WLH41m2kcfdPMz8PsKCVlcLOslVrV0PBjCLJYsQHSEjQYpMU7AMOQZ5LNto0D tgYD2LUCoyDBvhZer/ghMWTPTARnNHV62+zMBhES09pm2eIcp3a4fsRiatmdm0Xt 0MWJwEqxTztxqkFdTVYgC2ujAEU5IJqVXNlxkl7PA42XcuQzs+8LKKx/CKuh6rNO DlqYKsJQ2YjUiXdoh3dXSHKWnoFraYs8U4BQT6xFXfew6iB47D0qdu2px0+quuHH DSPNdwpC3DZBinzUyxrSJ0uNb9EBRveMHINSMOHB9VjLFncORv0CqPHqfHeRhwCm RBhk49fp2LS0XZOfkzoDXZPfoTWlM3SiMRG1B7ul7sWsX2d9hP40W/SLgGz9kWcu iQ3bo1FBtlV4xmgs6+2RdMvf272a1WFj8jaTashha8W5DY4ZtmOma0l19mW9IfA+ JiS24pKu9fpM0n41TbEBz9TZZ+SOuZIiQSszxENuwXM4boNFh+SnBHGqWPTU56iw x6EzyTesqQ+igSmTKu6FXb7BmLncii9BgaH2VllfJee8sV3OA6eT38hdPNWTZ1Wh JF5OiMCv3qnlaswLsJ7gjkbdLQEyHKwJoWg+WaqWH1kshyzEfUolxfWT8WboutqK 35iv7dt+JfO0DEJRTA8X =inv4 -----END PGP SIGNATURE----- From stpeter@stpeter.im Fri May 10 10:10:53 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9187E21F84A1 for ; Fri, 10 May 2013 10:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2kPmMLa5Lwt for ; Fri, 10 May 2013 10:10:49 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 05F7A21F8488 for ; Fri, 10 May 2013 10:10:49 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F044141123; Fri, 10 May 2013 11:22:34 -0600 (MDT) Message-ID: <518D2A16.8030908@stpeter.im> Date: Fri, 10 May 2013 11:10:46 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Adam Roach References: <984edebb3d71943ddd13940a3ea1b148@imap.plus.net> <518D1D76.800@nostrum.com> <518D2972.60809@stpeter.im> In-Reply-To: <518D2972.60809@stpeter.im> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org, Jonathan Hansford Subject: Re: [sipcore] SIP and Internationalisation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 17:10:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 5/10/13 11:08 AM, Peter Saint-Andre wrote: > See RFC 4103 (SASLprep) and draft-ietf-precis-saslprepbis. Er, RFC 4013. /psa -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRjSoWAAoJEOoGpJErxa2pOc8P/ij7kmtZzXL2MyGjd5ht+7aF JTd00juEpV+/uO2600k9Bf8tU5kDU2wKTGeqP77TH2l1ZxeaRGQj+StgAj0GClyX 7iGx2tGM3YvJKV+JKSIZ29SvfC91evnC2rpoFBgU8UqoSvKBwpOI0QsaZylR1Ts5 seEhvR9iWWN3DO6pnxqju3N/VWTalAQxnaPBgHirAyu/oS7bwjUuUJANutH0wWuQ /hSx/2RHObdqjOoNZmVGp1AnmqKRVfEZcBUCuLrwEMFDwnD3w6LXaQrXr/uyPUNn lG2eIxgCRxiFXuf3tg8XwrMaSFqdvJXdj/WK7z2FG8AXOUdouP6rvjG1Y117S+br K7AEA37F/+GvOJZrznoraP2/084KCsj5XI1iCU8QTUtijOn+FqxbgFyBMqECfbLc bp6yr4IAW+LnmvQvECB0Y+qizvyoUc+O5x6N/vS3FrUUVXRPvT7vSBmxi39mzVpC wr5gs2BOejBA5+EJ0w5TWDepKnjCN2aAnjxruMewvk7rfTtX1USi7i1YGZzdvGX/ PV6Q23SGww8MU7FbIqYrBhlTgZvouW0ZoahhbLwoCz59lVnJ6spiiMwGhLLMW39a Z5EdwlUayTcZOOUdN6f17P7xwS/mXgCcmvqdCNZToN6D8I9BXqA92BuGdMuhTCqM l1r351Nk+ckgowDTEPEB =fgXM -----END PGP SIGNATURE----- From worley@shell01.TheWorld.com Fri May 10 11:14:56 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A6A21F8F2C for ; Fri, 10 May 2013 11:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.674 X-Spam-Level: X-Spam-Status: No, score=-2.674 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nu-prUkysQdw for ; Fri, 10 May 2013 11:14:51 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id EF87C21F8F41 for ; Fri, 10 May 2013 11:14:50 -0700 (PDT) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r4AIEQfA018763; Fri, 10 May 2013 14:14:30 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r4AIEQu04493958; Fri, 10 May 2013 14:14:26 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r4AIEPYY4515177; Fri, 10 May 2013 14:14:25 -0400 (EDT) Date: Fri, 10 May 2013 14:14:25 -0400 (EDT) Message-Id: <201305101814.r4AIEPYY4515177@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Jonathan Hansford In-reply-to: <984edebb3d71943ddd13940a3ea1b148@imap.plus.net> (Jonathan@hansfords.net) References: <984edebb3d71943ddd13940a3ea1b148@imap.plus.net> Cc: sipcore@ietf.org Subject: Re: [sipcore] SIP and Internationalisation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 18:14:56 -0000 > From: Jonathan Hansford > > I have been trying to identify what > support for internationalization there is within SIP and can find no > reference to it. Can you advise what level of support (if any) SIP > currently provides for countries whose native language is not > (adequately) supported by US ASCII and/or whether there are any plans to > address this in the future? Here's the state of SIP practice that I see: There isn't much of SIP that is visible to the user, so little of it has internationalization concerns. As far as I know, the most significant area is the "name-addr" construction, which is the enhanced URI that is used to address phone calls. That is often used at the receiving phone to display the caller's name a phone number. Typical use is something like: INVITE sip:bob@biloxi.com SIP/2.0 From: Alice ;tag=1928301774 To: Bob The display-name part, "Alice" and "Bob" is defined to be a series of UTF-8-encoded Unicode characters (with certain restrictions), so it is already fully internationalized. It also has the virtue that while the protocol carries it, the protocol doesn't *interpret* it. The protocol treats URIs (e.g., sip:bob@biloxi.com) as sequences of Unicode characters with very limited variation allowed before one URI becomes "different" from another. Generally, we do not expect users to enter URIs or interpret them, but rather select entries from address books. The domain name part (atlanta.com) is part of the URI, and so is restricted to Ascii characters. But we have a system for encoding non-Ascii domain names into Ascii characters. I'm not familiar with the details, but it's the same problem as encoding non-Ascii domain names into HTTP URLs. The part that is least well worked out (IMO) is the user-part of the SIP URI; in these examples, "bob" and "alice". As part of a URI, user-parts have to be composed of Ascii characters, but there is an escaping system, where instead of an ordinary character you write "%xx", where "xx" is two hex digits. It turns out that what the escape *means* is not well specified, other than that if you replace a syntactically acceptable Ascii character with its hex escape, the resulting URI must compare equal to the original URI. But it seems that there is an intention that a non-Ascii character can be represented by writing a series of escapes representing the bytes in the character's UTF-8 representation. But it's likely that at least some systems use the escapes %80 to %FF to represent the characters U+0080 to U+00FF. Dale From pkyzivat@alum.mit.edu Fri May 10 12:14:39 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6084521F9423 for ; Fri, 10 May 2013 12:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.059 X-Spam-Level: X-Spam-Status: No, score=-0.059 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwal7+H-NH8w for ; Fri, 10 May 2013 12:14:34 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0C221F93EC for ; Fri, 10 May 2013 12:14:33 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta03.westchester.pa.mail.comcast.net with comcast id aAxN1l00B0mv7h053KEYu0; Fri, 10 May 2013 19:14:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id aKEY1l0103ZTu2S3XKEYP7; Fri, 10 May 2013 19:14:32 +0000 Message-ID: <518D4718.9010304@alum.mit.edu> Date: Fri, 10 May 2013 15:14:32 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: sipcore@ietf.org References: <984edebb3d71943ddd13940a3ea1b148@imap.plus.net> <518D1D76.800@nostrum.com> In-Reply-To: <518D1D76.800@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368213272; bh=n/w4SfOJn7dEJNPmU+WNtHjNFhhlO85ScyeSmVYztiQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=f1SEjq6fXjSfzv4JCWYvISOpEfnSQxCujSl5GSIproKy8MbrdVwRlDO1wSZF0dEL/ yYjHdr9u/SNEu0txZ1DcnK/eKLCqJLUKPaewrM2+Fe1tlhnE0xJvfNvsAY3DgFlNmR 7Wr4SPlyNS1AqrfZZYxcy8to42EEv3Crx1r/9m0ZtDjDd3el5DJ2YEOrRYf+EgevJ/ tAXTXI5YvxYcIvlJp+txPm24f1k+APdWqBTGOgtyISOtRwwKKKiywxz3lTXWhrbYYg SeYm8KbfUu7VREqFC6cxwrtXlchTbtaKst0OaPl9SkaydVbY/rvIVxRLfGIyZVP5vN 7cOYAMkG16oSw== Subject: Re: [sipcore] SIP and Internationalisation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 19:14:39 -0000 I'll echo Adam, but admit that I know very little about internationalization - clearly less than Adam, much less Peter. I do know enough to recognize that there is something lacking. If we have a volunteer with the knowledge and motivation to work on it, then we should be be able to support the work within sipcore. I expect this hasn't surfaced as much of a problem because most of the use of sip is with phone numbers. Thanks, Paul On 5/10/13 12:16 PM, Adam Roach wrote: > Jonathan: > > As far as I know, there has been no serious work on SIP's i18n story so > far. The closest we come is the use of UTF-8 everywhere. While an > international character encoding is a necessary part of the story, it's > far from sufficient. > > I've known for quite some time that SIP's IDN story is conspicuous by > its absence. I've never really had the time to poke at existing, > deployed implementations to see what they do when you feed unicode > characters into domain names. Given the lack of specification, I doubt > most of them do anything useful. Some might accidentally kind of work, > depending on what punycode support their underlying DNS libraries > provide, but the chances of this being done in a way that yields success > seems extremely slim. > > The other area we need to worry about, as Gunnar and Peter hinted at, is > usernames. The big issue here (as I understand it) is the application of > stringprep for the purpose of measuring username equality. > > I'd been keeping my eyes, very loosely, on the IRI work in hope that we > could leverage its output in a future SIP internationalization effort, > since it would hopefully provide guidance on both the IDN and stringprep > issues. Sadly, that work seems to have been terminated before producing > useful output, so we'll have to make our own way through this morass. > > There are probably some similar issues for password normalization, > although I'm not sure that's as much of an issue, since passwords, by > their nature, are generated in a more repeatable way than usernames are. > I would expect that people who have spent far more time than I have > thinking about the problem have some ideas here. > > Aside from URIs and Digest credentials, there is mercifully little in > the way of protocol fields intended to be user-visible for SIP. A > handful, like Organization and Subject, were specified in a way that > implied that they should be user-renderable; however, in practice, no > one ever uses these fields (and, in any case, I don't think they pose > any particular i18n challenges, as these fields are not > machine-interpretable, and do allow UTF-8 characters). > > In practice, most implementations them do a lousy job of l10n (e.g. for > response Reason-Phrases) , but I don't think we're missing anything > protocol-wise; this seems to be a failing of the implementations themselves. > > I think that's the vast majority of what you need to worry about in > terms of the core SIP protocol. Now, there are some protocols we use > (e.g., BFCP, TLS, CCMP, S/MIME) that we would rely on having sufficient > internationalization support, but I would be inclined to consider those > a separable effort. > > In any case, if you can find enough critical mass of people with the > energy and time to move this work forward, I would welcome it > wholeheartedly. I believe that, the way the charter is currently > written, this work is likely to fall under the purview of the SIPCORE > working group. > > /a > > > On 5/10/13 06:08, Jonathan Hansford wrote: >> >> Hi, >> >> I am currently looking at a number of Internet protocols for >> international use and am looking to see how much commonality there is >> between them. A number are, or are in the process of becoming, >> IDNA2008 aware (e.g. DNS - RFC 5890, SMTP - RFC 6530/1, XMPP - >> draft-ietf-xmpp-6122bis-07). >> >> I have been trying to identify what support for internationalization >> there is within SIP and can find no reference to it. Can you advise >> what level of support (if any) SIP currently provides for countries >> whose native language is not (adequately) supported by US ASCII and/or >> whether there are any plans to address this in the future? >> >> Thanks, >> >> Jonathan Hansford >> >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From stpeter@stpeter.im Fri May 10 14:40:45 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBC821F9354 for ; Fri, 10 May 2013 14:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XR+DUbsmzqde for ; Fri, 10 May 2013 14:40:40 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4255C21F9343 for ; Fri, 10 May 2013 14:40:39 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9AB434111A for ; Fri, 10 May 2013 15:52:26 -0600 (MDT) Message-ID: <518D6956.9060708@stpeter.im> Date: Fri, 10 May 2013 15:40:38 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: sipcore@ietf.org References: <984edebb3d71943ddd13940a3ea1b148@imap.plus.net> <518D1D76.800@nostrum.com> <518D4718.9010304@alum.mit.edu> In-Reply-To: <518D4718.9010304@alum.mit.edu> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] SIP and Internationalisation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 21:40:45 -0000 On 5/10/13 1:14 PM, Paul Kyzivat wrote: > I'll echo Adam, but admit that I know very little about > internationalization - clearly less than Adam, much less Peter. > > I do know enough to recognize that there is something lacking. > If we have a volunteer with the knowledge and motivation to work on it, > then we should be be able to support the work within sipcore. I doubt that we'll find a volunteer with both the motivation and the knowledge. Instead, I expect that we'll need to find someone with the motivation and then train that person to have the knowledge. In the XMPP community, Joe Hildebrand and I had to train ourselves (with much help from more knowledgeable people like Pete Resnick). There is a lot to learn in this space (personally I feel like I'm still scratching the surface), and the motivation will need to be accompanied by the willingness to do a great deal of self-learning. > I expect this hasn't surfaced as much of a problem because most of the > use of sip is with phone numbers. Probably so. Peter -- Peter Saint-Andre https://stpeter.im/ From tsearle@sipstacks.com Mon May 13 00:34:56 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A713E21F9223 for ; Mon, 13 May 2013 00:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.822 X-Spam-Level: * X-Spam-Status: No, score=1.822 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, J_CHICKENPOX_39=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfMQEi7TTBtU for ; Mon, 13 May 2013 00:34:56 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 07C4221F91D8 for ; Mon, 13 May 2013 00:34:55 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id e11so11793627iej.30 for ; Mon, 13 May 2013 00:34:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:x-gm-message-state; bh=6rs+1k+sN3lbWcpVw1RKqwTrLqesqm9wBRCZuWAQiv0=; b=IcB3PuLTu/4ZV4jMrW/Vr74hRheBjncSmVSClyb2f6N9ku/x2tzKgt536Thln77eWO au6SqdAEpJbCuY5CxeZgt0vMIJCWFhah16AJpfQ0Zoe/wRg+Q8nq3ZVxAfrkGPQQRAhu IB43QQlr/hJEoFfkFJpXimcIFtVANPlWvT6GG5v31EJd+jD4fQA1V/oy8wj3pxqe+EVP IGdlDlyLgVKAOFH9e36E1jndb1NYcA03KEnbSjKFQrace6izN+RE7NKEVzuPsGDt9Rx/ JCyKByF401b9utE2SrkvWGfboCYugrkwnvzXNmpnUC+gEYAGmVy680XqArDJayih9axR KjuQ== MIME-Version: 1.0 X-Received: by 10.50.79.233 with SMTP id m9mr9195912igx.53.1368430495308; Mon, 13 May 2013 00:34:55 -0700 (PDT) Received: by 10.64.96.136 with HTTP; Mon, 13 May 2013 00:34:55 -0700 (PDT) In-Reply-To: <518D6956.9060708@stpeter.im> References: <984edebb3d71943ddd13940a3ea1b148@imap.plus.net> <518D1D76.800@nostrum.com> <518D4718.9010304@alum.mit.edu> <518D6956.9060708@stpeter.im> Date: Mon, 13 May 2013 09:34:55 +0200 Message-ID: From: Torrey Searle To: sipcore@ietf.org Content-Type: multipart/alternative; boundary=089e0139fffc92b09e04dc948da5 X-Gm-Message-State: ALoCoQkjjlXbsPiGaulQDPVunBZtISWsk3/7GF05VTEwVdEjpE/sFL+tkKmT/YLMuOCV8WZJUTWc Subject: Re: [sipcore] SIP and Internationalisation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 07:34:56 -0000 --089e0139fffc92b09e04dc948da5 Content-Type: text/plain; charset=ISO-8859-1 If I understand correctly, the domain name part does have a significant problem as it's defined as follows: ALPHA = %x41-5A / %x61-7A ; A-Z / a-z hostport = host [ ":" port ] host = hostname / IPv4address / IPv6reference hostname = *( domainlabel "." ) toplabel [ "." ] domainlabel = alphanum / alphanum *( alphanum / "-" ) alphanum Which would prevent the newer domain names in non-latin alphabets from being legally used in SIP. Or would SIP require the use of the "ToAscii" format defined rfc3490? On Fri, May 10, 2013 at 11:40 PM, Peter Saint-Andre wrote: > On 5/10/13 1:14 PM, Paul Kyzivat wrote: > > I'll echo Adam, but admit that I know very little about > > internationalization - clearly less than Adam, much less Peter. > > > > I do know enough to recognize that there is something lacking. > > If we have a volunteer with the knowledge and motivation to work on it, > > then we should be be able to support the work within sipcore. > > I doubt that we'll find a volunteer with both the motivation and the > knowledge. Instead, I expect that we'll need to find someone with the > motivation and then train that person to have the knowledge. In the XMPP > community, Joe Hildebrand and I had to train ourselves (with much help > from more knowledgeable people like Pete Resnick). There is a lot to > learn in this space (personally I feel like I'm still scratching the > surface), and the motivation will need to be accompanied by the > willingness to do a great deal of self-learning. > > > I expect this hasn't surfaced as much of a problem because most of the > > use of sip is with phone numbers. > > Probably so. > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --089e0139fffc92b09e04dc948da5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
If I understand correctly, the domain name part does have = a significant problem as it's defined as follows:

=A0ALPHA = =A0 =A0 =A0 =A0 =A0=3D =A0%x41-5A / %x61-7A =A0 ; A-Z / a-z
<= br>
hostport =A0 =A0 =A0 =A0 =3D =A0host [ ":" port ]
host = =A0 =A0 =A0 =A0 =A0 =A0 =3D =A0hostname / IPv4address / IPv6reference
=
hostname =A0 =A0 =A0 =A0 =3D =A0*( domainlabel "." ) toplabe= l [ "." ]
domainlabel =A0 =A0 =A0=3D =A0alphanum
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / alphanum *( alphanum / "= ;-" ) alphanum


Whi= ch would prevent the newer domain names in non-latin alphabets from being l= egally used in SIP. =A0Or would SIP require the use of the "ToAscii&qu= ot; format defined rfc3490?



On Fri, May 10, 2013 at 11:40 PM, Peter Saint-Andre <stpeter@stpe= ter.im> wrote:
On 5/10/13 1:14 PM, Paul K= yzivat wrote:
> I'll echo Adam, but admit that I know very little about
> internationalization - clearly less than Adam, much less Peter.
>
> I do know enough to recognize that there is something lacking.
> If we have a volunteer with the knowledge and motivation to work on it= ,
> then we should be be able to support the work within sipcore.

I doubt that we'll find a volunteer with both the motivation and = the
knowledge. Instead, I expect that we'll need to find someone with the motivation and then train that person to have the knowledge. In the XMPP community, Joe Hildebrand and I had to train ourselves (with much help
from more knowledgeable people like Pete Resnick). There is a lot to
learn in this space (personally I feel like I'm still scratching the surface), and the motivation will need to be accompanied by the
willingness to do a great deal of self-learning.

> I expect this hasn't surfaced as much of a problem because most of= the
> use of sip is with phone numbers.

Probably so.

Peter

--
Peter Saint-Andre
https://stpeter.im/

_____________________________= __________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

--089e0139fffc92b09e04dc948da5-- From stpeter@stpeter.im Mon May 13 05:24:31 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C2E21F86DD for ; Mon, 13 May 2013 05:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.399 X-Spam-Level: X-Spam-Status: No, score=-101.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_37=0.6, J_CHICKENPOX_39=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48uKAnrWe9d5 for ; Mon, 13 May 2013 05:24:26 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 18A6921F8607 for ; Mon, 13 May 2013 05:24:25 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 32B164112A; Mon, 13 May 2013 06:36:21 -0600 (MDT) Message-ID: <5190DB79.5@stpeter.im> Date: Mon, 13 May 2013 06:24:25 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Torrey Searle References: <984edebb3d71943ddd13940a3ea1b148@imap.plus.net> <518D1D76.800@nostrum.com> <518D4718.9010304@alum.mit.edu> <518D6956.9060708@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] SIP and Internationalisation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 12:24:31 -0000 On 5/13/13 1:34 AM, Torrey Searle wrote: > If I understand correctly, the domain name part does have a significant > problem as it's defined as follows: > > ALPHA = %x41-5A / %x61-7A ; A-Z / a-z > > hostport = host [ ":" port ] > host = hostname / IPv4address / IPv6reference > hostname = *( domainlabel "." ) toplabel [ "." ] > domainlabel = alphanum > / alphanum *( alphanum / "-" ) alphanum > > > Which would prevent the newer domain names in non-latin alphabets from > being legally used in SIP. Or would SIP require the use of the > "ToAscii" format defined rfc3490? Yes, it would require the punycoded form (an A-label in RFC 5890). Peter -- Peter Saint-Andre https://stpeter.im/ From wwwrun@rfc-editor.org Fri May 17 12:33:15 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59A9E21F96FC for ; Fri, 17 May 2013 12:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MO4jgL0GTXKZ for ; Fri, 17 May 2013 12:33:14 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 949FA21F9730 for ; Fri, 17 May 2013 12:33:14 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A93CE62102; Fri, 17 May 2013 12:32:58 -0700 (PDT) To: adam@nostrum.com, rlb@ipv.sx, gonzalo.camarillo@ericsson.com, adam@nostrum.com, pkyzivat@alum.mit.edu From: RFC Errata System Message-Id: <20130517193258.A93CE62102@rfc-editor.org> Date: Fri, 17 May 2013 12:32:58 -0700 (PDT) Cc: lawrence.jovellanos@gmail.com, sipcore@ietf.org, rfc-editor@rfc-editor.org Subject: [sipcore] [Editorial Errata Reported] RFC6878 (3628) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 19:33:15 -0000 The following errata report has been submitted for RFC6878, "IANA Registry for the Session Initiation Protocol (SIP) "Priority" Header Field". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6878&eid=3628 -------------------------------------- Type: Editorial Reported by: Lawrence Jovellanos Section: 2 Original Text ------------- This policy was chosen over lighter-weight policies due the potential architectural impact of the semantics associated with new values. Corrected Text -------------- This policy was chosen over lighter-weight policies due to the potential architectural impact of the semantics associated with new values. Notes ----- Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6878 (draft-ietf-sipcore-priority-00) -------------------------------------- Title : IANA Registry for the Session Initiation Protocol (SIP) "Priority" Header Field Publication Date : March 2013 Author(s) : A.B. Roach Category : PROPOSED STANDARD Source : Session Initiation Protocol Core Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From gonzalo.camarillo@ericsson.com Wed May 22 22:39:38 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A33B11E8164 for ; Wed, 22 May 2013 22:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.045 X-Spam-Level: X-Spam-Status: No, score=-106.045 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymEra+9OgK2N for ; Wed, 22 May 2013 22:39:33 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A113A21F9671 for ; Wed, 22 May 2013 22:39:32 -0700 (PDT) X-AuditID: c1b4fb2d-b7fe36d000007102-b9-519dab939428 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 4B.C6.28930.39BAD915; Thu, 23 May 2013 07:39:31 +0200 (CEST) Received: from [131.160.36.24] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Thu, 23 May 2013 07:39:30 +0200 Message-ID: <519DAB92.3070605@ericsson.com> Date: Thu, 23 May 2013 08:39:30 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: sipcore@ietf.org References: <20130517193258.A93CE62102@rfc-editor.org> In-Reply-To: <20130517193258.A93CE62102@rfc-editor.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJLMWRmVeSWpSXmKPExsUyM+Jvre7k1XMDDV69ELTY83cRu8WKbc0s Fis2HGC1mNpna/H1xyY2B1aPv+8/MHnsnHWX3WPJkp9MHpM3zmLxmLXzCUsAaxSXTUpqTmZZ apG+XQJXxsE+roIHfBV3P9xgbmA8wt3FyMEhIWAi8fxwaBcjJ5ApJnHh3no2EFtI4BSjxLY3 OV2MXED2akaJrsOPWUDqeQW0JTa8FQGpYRFQlZhx/CA7iM0mYCGx5dZ9FhBbVCBKYs66B2Bz eAUEJU7OfAIWFxEQkXg2/R8byBhmgUiJWyd5QMLCAuYSzz8eZIJYaybxctFMsJGcQPFHf0+z QpwmKbHlRTtYnFlAT2LK1RZGCFteYvvbOcwQvdoSy5+1sExgFJqFZPMsJC2zkLQsYGRexcie m5iZk15uuIkRGNwHt/zW3cF46pzIIUZpDhYlcd5e7amBQgLpiSWp2ampBalF8UWlOanFhxiZ ODilGhhtU7iXZC/3XKqwobRXUnvToZhbLut1hZdqB8xZqPZL8/n8PWGuSxmOLTTZ+nFK3pHK PL5/N6ynvND538347C7z1ruZ5bOzjX4FO7CyvbjhKbRNbOnUn2k7pFbun9epUVu38Flz7oGt W7vmLDe3S3m1PW9/RKVwsPKirglHN300/hT94lXj7/pPSizFGYmGWsxFxYkAoGQBejwCAAA= Cc: rlb@ipv.sx, lawrence.jovellanos@gmail.com Subject: Re: [sipcore] [Editorial Errata Reported] RFC6878 (3628) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 05:39:38 -0000 Hi, I have just moved this erratum to the "held for document update" state, per the errata handling guidelines. Cheers, Gonzalo On 17/05/2013 10:32 PM, RFC Errata System wrote: > The following errata report has been submitted for RFC6878, > "IANA Registry for the Session Initiation Protocol (SIP) "Priority" Header Field". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6878&eid=3628 > > -------------------------------------- > Type: Editorial > Reported by: Lawrence Jovellanos > > Section: 2 > > Original Text > ------------- > This policy was chosen over lighter-weight policies due the potential architectural impact of the semantics associated with new values. > > Corrected Text > -------------- > This policy was chosen over lighter-weight policies due to the potential architectural impact of the semantics associated with new values. > > Notes > ----- > > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6878 (draft-ietf-sipcore-priority-00) > -------------------------------------- > Title : IANA Registry for the Session Initiation Protocol (SIP) "Priority" Header Field > Publication Date : March 2013 > Author(s) : A.B. Roach > Category : PROPOSED STANDARD > Source : Session Initiation Protocol Core > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG > >