From rjsparks@nostrum.com Thu Dec 1 14:47:56 2011 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 9124B1F0C7C for ; Thu, 1 Dec 2011 14:47:56 -0800 (PST) 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, 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 R8R0GHRaR09I for ; Thu, 1 Dec 2011 14:47:55 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB8D1F0C74 for ; Thu, 1 Dec 2011 14:47:55 -0800 (PST) Received: from [192.168.2.105] (pool-71-170-49-200.dllstx.fios.verizon.net [71.170.49.200]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id pB1MloQc028578 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 1 Dec 2011 16:47:51 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1-875086661 From: Robert Sparks In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3A87DFF5@ESESSCMS0356.eemea.ericsson.se> Date: Thu, 1 Dec 2011 16:47:50 -0600 Message-Id: <91230E95-75EE-4F6B-96A4-D30595D28634@nostrum.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C3A87DFF5@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 71.170.49.200 is authenticated by a trusted mechanism) Cc: "sipcore@ietf.org Core\) WG" Subject: Re: [sipcore] Proxy-Feature: Requirement changes based on Robert's comments (IETF#81) 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, 01 Dec 2011 22:47:56 -0000 --Apple-Mail-1-875086661 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 26, 2011, at 8:52 AM, Christer Holmberg wrote: > =20 > Hi, > =20 > Based on Robert's comments on the proxy feature requirements in = Taipei, this e-mail describes suggested modifications. > =20 > If people are ok with the suggested modifications I will submit a new = version of the requirements draft. > =20 > Regards, > =20 > Christer > =20 > ------------ > =20 > - Comment that REQ-10 should talk about having access to the = information, rather than talking specifically about making routing = decisions: > =20 > I suggest a modification of REQ-10: > =20 > =20 > OLD: > =20 > REQ-10: Other SIP entities MUST be able to make routing > decisions based on received feature/capability support > indications. > =20 > NEW: > =20 > REQ-10: Other SIP entities MUST be able to retrieve the > feature/capability support indications received in a SIP > message. How about: SIP entities on the path of the SIP message MUST be able to inspect the feature/capability support indicators introduced by other entities. > =20 > =20 > ------------ > =20 > =20 > - Comment regarding the fact that requirements REQ-8 and REQ-9 seem to = be identical: > =20 > Actually, they are not identical. REQ-8 talks about the case when an = entity receives an indication that it doesn't support, while REQ-9 talks = about the case where an entity that doesn't even support the mechanism = receives an indication. > =20 > So, my suggestion is that we keep both requirements. > =20 > But, If you think it helps, I could modify REQ-8 in the following way: > =20 > "REQ-8: If a SIP entity that supports the proxy = feature/ > capability indication mechanism receives a feature = support > indication that it does not understand, it MUST act as if it = hadn't > received the indication." Better. > =20 > =20 > ------------ > =20 > =20 > - Comment regarding the fact that we don't have a requirement saying = that a proxy indicating support of a feature/capability associated with = a dialog must be part of the signaling path of that dialog. > =20 > I suggest the following new requirement: > =20 > REQ-XX: A SIP proxy that indicates support of a feature/capability = associated with a dialog MUST take the necessary steps to ensure it is > part of the signaling path of the remainder > that dialog. > =20 Maybe that should be further refined to make it obvious that, as a = consequence, a proxy can only indicate such support as part of a dialog forming transaction. > =20 > ------------ > =20 > =20 I also suggested that Req-13 be stated as a requirement (the solution = must provide a way to avoid collision of indicators). It would also be good to get some list discussion continuing the = discussion we had in the meeting about the potential semantics of an indications are. We talked about whether these would be allowed or would make sense: * An indication that was basically the brand of the element. * An indication that an element was made from trendy parts or met some = certification criteria (such as around energy use) * An indication that the element is capable of dropping logs in SIPCLF = format I suspect there are others that folks here could brainstorm... --Apple-Mail-1-875086661 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Nov 26, 2011, at 8:52 AM, Christer = Holmberg wrote:

 
Hi,
 
Based on Robert's = comments on the proxy feature requirements in Taipei, this e-mail = describes suggested modifications.
 
If people are ok = with the suggested modifications I will submit a new version of the = requirements draft.
 
Regards,
 
Christer
 
------------
 
- Comment that = REQ-10 should talk about having access to the information, rather than = talking specifically about making routing = decisions:
 
I suggest a modification of REQ-10:
 
 
OLD:
 
        REQ-10: Other SIP = entities MUST be able to make routing
        decisions based on = received feature/capability support
         = indications.
 
NEW:
 
         REQ-10: = Other SIP entities MUST be able to retrieve the
        feature/capability = support indications received in a SIP
        = message.

=
How about:

SIP entities on the path of = the SIP message MUST be
able to inspect the feature/capability = support indicators
introduced by other = entities.

 
 
------------
 
 
- Comment regarding = the fact that requirements REQ-8 and REQ-9 seem to be = identical:
 
Actually, they are not identical. REQ-8 talks about the case = when an entity receives an indication that it doesn't support, while = REQ-9 talks about the case where an entity that doesn't even support the = mechanism receives an indication.
 
So, my suggestion is = that we keep both requirements.
 
But, If you think it = helps, I could modify REQ-8 in the following way:
 
         "REQ-8: If a = SIP entity <new> that supports the proxy = feature/
         capability = indication mechanism </new> receives a feature = support
        indication that it = does not understand, it MUST act as if it hadn't
        received the = indication."
Bette= r.
 
 
------------
 
 
- Comment regarding = the fact that we don't have a requirement saying that a proxy indicating = support of a feature/capability associated with a dialog must be part of = the signaling path of that dialog.
 
I suggest the = following new requirement:
 
REQ-XX: A SIP proxy = that indicates support of a feature/capability associated with a dialog = MUST
take the necessary = steps to ensure it is
part of the = signaling path of
the = remainder
that = dialog.
 

Maybe that should be further refined to make it obvious that, = as a consequence, a proxy can only indicate such
support as = part of a dialog forming = transaction.


 
------------
 
 
=

I also suggested that Req-13 be stated as a = requirement (the solution must provide a way to avoid collision of = indicators).

It would also be good to get some list = discussion continuing the discussion we had in the meeting about the = potential
semantics of an indications = are.

We talked about whether these would be = allowed or would make sense:

* An indication = that was basically the brand of the element.
* An indication = that an element was made from trendy parts or met some certification = criteria (such as around energy use)
* An indication that the = element is capable of dropping logs in SIPCLF = format

I suspect there are others that folks = here could = brainstorm...


= --Apple-Mail-1-875086661-- From christer.holmberg@ericsson.com Fri Dec 2 00:01:40 2011 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 7768321F9279 for ; Fri, 2 Dec 2011 00:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 t97Y0p5CQNj7 for ; Fri, 2 Dec 2011 00:01:39 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5586621F91CA for ; Fri, 2 Dec 2011 00:01:39 -0800 (PST) X-AuditID: c1b4fb3d-b7cfeae000005b81-8c-4ed885e1d3b9 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id F3.62.23425.1E588DE4; Fri, 2 Dec 2011 09:01:37 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.20]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Fri, 2 Dec 2011 09:01:37 +0100 From: Christer Holmberg To: Robert Sparks Date: Fri, 2 Dec 2011 09:01:35 +0100 Thread-Topic: Proxy-Feature: Requirement changes based on Robert's comments (IETF#81) Thread-Index: Acywe0OaVIB/E7j/TbCrd1lSdXfAzQASkjDA Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3A97B62B@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3A87DFF5@ESESSCMS0356.eemea.ericsson.se> <91230E95-75EE-4F6B-96A4-D30595D28634@nostrum.com> In-Reply-To: <91230E95-75EE-4F6B-96A4-D30595D28634@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org Core\) WG" Subject: Re: [sipcore] Proxy-Feature: Requirement changes based on Robert's comments (IETF#81) 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, 02 Dec 2011 08:01:40 -0000 Hi Robert,=20 ------------ =20 > - Comment that REQ-10 should talk about having access to the information,= =20 > rather than talking specifically about making routing decisions: > =20 > I suggest a modification of REQ-10: > =20 > =20 > OLD: > =20 > REQ-10: Other SIP entities MUST be able to make routing > decisions based on received feature/capability support > indications. > =20 > NEW: > =20 > REQ-10: Other SIP entities MUST be able to retrieve the > feature/capability support indications received in a SIP > message. > =09 > > How about: > > SIP entities on the path of the SIP message MUST be > able to inspect the feature/capability support indicators > introduced by other entities. Sounds good. =09 =20 ------------ =20 =20 > - Comment regarding the fact that requirements REQ-8 and REQ-9 seem to be= identical: > =20 > Actually, they are not identical. REQ-8 talks about the case when an enti= ty receives=20 > an indication that it doesn't support, while REQ-9 talks about the case w= here an entity=20 > that doesn't even support the mechanism receives an indication. > =20 > So, my suggestion is that we keep both requirements. > =20 > But, If you think it helps, I could modify REQ-8 in the following way: > =20 > "REQ-8: If a SIP entity that supports the proxy feature/ > capability indication mechanism receives a feature support > indication that it does not understand, it MUST act as if it hadn'= t > received the indication." > =09 > Better. Good. =09 ------------ =20 =20 =20 > - Comment regarding the fact that we don't have a requirement saying that= a proxy indicating=20 > support of a feature/capability associated with a dialog must be part of = the signaling path=20 > of that dialog. > =20 > I suggest the following new requirement: > =20 > REQ-XX: A SIP proxy that indicates support of a feature/capability assoc= iated with a dialog MUST=20 > take the necessary steps to ensure it is part of the signaling path of t= he remainder that dialog. > =20 > =09 > Maybe that should be further refined to make it obvious that, as a conseq= uence, a=20 > proxy can only indicate such support as part of a dialog forming transact= ion. Yes. But, as we have discussed on the list, a proxy would also have to re-i= ndicate support as part of a target refresh dialog, so indicate that it sti= ll supports the feature. So, I suggest: REQ-XX: A SIP proxy that indicates support of a feature/capability associ= ated with a dialog MUST=20 take the necessary steps to ensure it is part of the signaling path of th= e remainder that dialog,=20 by indicating the support of the feature/capability as part of a dialog f= orming transaction, or=20 as part of a target refresh request within a dialog. =20 ------------ =20 =20 > I also suggested that Req-13 be stated as a requirement (the solution mus= t provide a way to avoid collision of indicators).=20 I suggest to modify the requirement (Req-13 will become Req-14, btw) in the= following way: REQ-14: A procedure for registering feature/capability indication values,= which prevents name collisions of indicators, with IANA MUST be defined. ------------ > It would also be good to get some list discussion continuing the discussi= on we had in the meeting about the potential > semantics of an indications are. > > We talked about whether these would be allowed or would make sense: > > * An indication that was basically the brand of the element. > * An indication that an element was made from trendy parts or met some ce= rtification criteria (such as around energy use) > * An indication that the element is capable of dropping logs in SIPCLF fo= rmat > > I suspect there are others that folks here could brainstorm... I have been working on some text, similar to what we have for Info Packages= , about indication specifications, and what information they need to contai= n, and one part is of course a description/reference of the semantics. You = will see it in the next version of draft-holmberg-sipcore-proxy-feature, su= ggesting a mechanism (using the Feature-Caps header field). So, if a brand has some defined feature semantics associated with it, I thi= nk it should be allowed. I also think that indicating that an element is capable of dropping logs is= a good use-case. I don't think the mechanism is to be used for pure information purpose, if = there is no defined and registered semantics associated with it. We can have that discussion when we start looking at the text I mentioned a= bove, but I hope that it won't stop us from beginning the work on the actua= l protocol mechanism. Thanks! Regards, Christer From victor.pascual.avila@gmail.com Fri Dec 2 07:33:30 2011 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 3426521F8B7B for ; Fri, 2 Dec 2011 07:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 OpJPvyqoonEc for ; Fri, 2 Dec 2011 07:33:29 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id AF34F21F8B56 for ; Fri, 2 Dec 2011 07:33:29 -0800 (PST) Received: by iaek3 with SMTP id k3so2075294iae.31 for ; Fri, 02 Dec 2011 07:33:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=hnY+XCTeIclfhGt79TGZ5muUw3Xc7w9pqM3Wu3ukyxw=; b=NJatYM/dOuOwyTUwtkppIx4jKHkkmUwAfuIBOjATa2njIezR1KG4mb525Yla1xKiKv ZdRv256xeOlYzWfqsUymkDrgd3VEgD4wKjnDhsmuCq3MQyN4Ww4Q/zD0xVxdTQjXwYXa 8On1gl3MCtOb7MGDgsMzkEpQfkkuQgAOEHJbI= MIME-Version: 1.0 Received: by 10.43.43.130 with SMTP id uc2mr14027802icb.35.1322840009340; Fri, 02 Dec 2011 07:33:29 -0800 (PST) Received: by 10.231.12.5 with HTTP; Fri, 2 Dec 2011 07:33:29 -0800 (PST) In-Reply-To: References: Date: Fri, 2 Dec 2011 16:33:29 +0100 Message-ID: From: Victor Pascual Avila To: "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [sipcore] New Version Notification for draft-ibc-sipcore-sip-websocket-00 (previously draft-ibc-rtcweb-sip-websocket-00) 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, 02 Dec 2011 15:33:30 -0000 The authors would appreciate any comments and suggestions on this new versi= on. Many thanks in advance, -Victor On Sun, Nov 27, 2011 at 2:07 PM, I=C3=B1aki Baz Castillo wr= ote: > A new version of I-D, draft-ibc-sipcore-sip-websocket-00.txt has been > successfully submitted by I=C3=B1aki Baz Castillo and posted to the IETF > repository. > > Filename: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ibc-sipcore-sip-websocket > Revision: =C2=A0 =C2=A0 =C2=A0 =C2=A000 > Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The WebSocket Protocol as a Tra= nsport for the Session > Initiation Protocol (SIP) > Creation date: =C2=A0 2011-11-24 > WG ID: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission > Number of pages: 27 > > Abstract: > =C2=A0This document specifies a WebSocket Sub-Protocol for a new transpor= t > =C2=A0in SIP (Session Initiation Protocol). =C2=A0The WebSocket protocol = enables > =C2=A0two-way realtime communication between clients and servers. > > > http://www.ietf.org/id/draft-ibc-sipcore-sip-websocket-00.txt > http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-00 > > > This draft is a new revision of the previously named > draft-ibc-rtcweb-sip-websocket-00. > > Summary of main changes in this revision: > > - WebSocket background provided. > - Scope not limited to web-browsers. > - Outbound and GRUU usage described. > - DNS NAPTR/SRV considerations included. > - Added some clarifications and bug fixing. > > > As usual, your comments are most appreciated. > > > -- > I=C3=B1aki Baz Castillo > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --=20 Victor Pascual =C3=81vila From gilad@voxisoft.com Fri Dec 2 08:16:40 2011 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 CF08821F8C11 for ; Fri, 2 Dec 2011 08:16:40 -0800 (PST) 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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, STOX_REPLY_TYPE=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 gWooLYPpyMXZ for ; Fri, 2 Dec 2011 08:16:40 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id C789421F8C0F for ; Fri, 2 Dec 2011 08:16:39 -0800 (PST) Received: by faap14 with SMTP id p14so2550963faa.31 for ; Fri, 02 Dec 2011 08:16:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voxisoft.com; s=google; h=message-id:from:to:references:in-reply-to:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :importance:x-mailer:x-mimeole; bh=EDPhTvDsrOw2lkKjOZrVcyTd7Ea/C0RMV1grEXUkgR4=; b=YcHZ6GwjeBaf6z8+wDvzOaaZuNy7v9Wy+zhX8qTxL2IOVosDw4DEDnnENz/iR4d5Qz BQry72TTMAXMXGZ270qOaXQ0aOMi/UH1OxWUePOSGokpg2VX8TS182DJH0sS8iJEZJmv F5bTDwm0mCqT/wHleY/DKGmKX3korv811xtuw= Received: by 10.180.14.129 with SMTP id p1mr10888399wic.8.1322842597260; Fri, 02 Dec 2011 08:16:37 -0800 (PST) Received: from gsmlaptop ([109.64.26.1]) by mx.google.com with ESMTPS id cc11sm9118wib.3.2011.12.02.08.16.33 (version=SSLv3 cipher=OTHER); Fri, 02 Dec 2011 08:16:34 -0800 (PST) Message-ID: <5470070492D34F4EAC60E4ED91CB3841@gsmlaptop> From: "Gilad Shaham" To: "Victor Pascual Avila" , "SIPCORE \(Session Initiation Protocol Core\) WG" References: In-Reply-To: Date: Fri, 2 Dec 2011 18:15:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3538.513 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3538.513 Subject: Re: [sipcore] New Version Notification for draft-ibc-sipcore-sip-websocket-00 (previously draft-ibc-rtcweb-sip-websocket-00) 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, 02 Dec 2011 16:16:40 -0000 Hi Victor, I followed the previous draft and read this one. I know that from the last draft you would like to refrain from sips issues, but I would expect it to be mentioned at the very least in the security section (13.1). If I'm reading the examples correctly they mean - use TLS for WebSocket, but from there forward use any transport, even unencrypted. I'm not sure everyone would realize that and personally, I don't see a problem sending sips to indicate it should be secure end-to-end as defined by RFC 5630. I'm also not so sure why the 'anonymous.invalid' strings are shown in this RFC for the Via and Contact headers. This usage is neither defined nor referenced anywhere other than the examples. If this specification doesn't mandate/recommend it I don't think it should be there, and if it does, it should be clearly defined (or reference another RFC that does). Hope it helps, Gilad -----Original Message----- From: Victor Pascual Avila Sent: Friday, December 02, 2011 5:33 PM To: SIPCORE (Session Initiation Protocol Core) WG Subject: Re: [sipcore] New Version Notification for draft-ibc-sipcore-sip-websocket-00 (previously draft-ibc-rtcweb-sip-websocket-00) The authors would appreciate any comments and suggestions on this new version. Many thanks in advance, -Victor On Sun, Nov 27, 2011 at 2:07 PM, Iñaki Baz Castillo wrote: > A new version of I-D, draft-ibc-sipcore-sip-websocket-00.txt has been > successfully submitted by Iñaki Baz Castillo and posted to the IETF > repository. > > Filename: draft-ibc-sipcore-sip-websocket > Revision: 00 > Title: The WebSocket Protocol as a Transport for the Session > Initiation Protocol (SIP) > Creation date: 2011-11-24 > WG ID: Individual Submission > Number of pages: 27 > > Abstract: > This document specifies a WebSocket Sub-Protocol for a new transport > in SIP (Session Initiation Protocol). The WebSocket protocol enables > two-way realtime communication between clients and servers. > > > http://www.ietf.org/id/draft-ibc-sipcore-sip-websocket-00.txt > http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-00 > > > This draft is a new revision of the previously named > draft-ibc-rtcweb-sip-websocket-00. > > Summary of main changes in this revision: > > - WebSocket background provided. > - Scope not limited to web-browsers. > - Outbound and GRUU usage described. > - DNS NAPTR/SRV considerations included. > - Added some clarifications and bug fixing. > > > As usual, your comments are most appreciated. > > > -- > Iñaki Baz Castillo > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore -- Victor Pascual Ávila _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From ibc@aliax.net Fri Dec 2 08:40:35 2011 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 66A6D21F8B5B for ; Fri, 2 Dec 2011 08:40:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.077 X-Spam-Level: X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_24=0.6, MIME_8BIT_HEADER=0.3, 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 dzqG+DYPaeWm for ; Fri, 2 Dec 2011 08:40:35 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B942521F8B51 for ; Fri, 2 Dec 2011 08:40:34 -0800 (PST) Received: by vcbfy13 with SMTP id fy13so2779488vcb.31 for ; Fri, 02 Dec 2011 08:40:34 -0800 (PST) Received: by 10.220.108.10 with SMTP id d10mr1063661vcp.138.1322844034169; Fri, 02 Dec 2011 08:40:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.1.82 with HTTP; Fri, 2 Dec 2011 08:40:13 -0800 (PST) In-Reply-To: <5470070492D34F4EAC60E4ED91CB3841@gsmlaptop> References: <5470070492D34F4EAC60E4ED91CB3841@gsmlaptop> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 2 Dec 2011 17:40:13 +0100 Message-ID: To: Gilad Shaham Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: =?UTF-8?B?Sm9zw6kgTHVpcyBNaWxsw6Fu?= , "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] New Version Notification for draft-ibc-sipcore-sip-websocket-00 (previously draft-ibc-rtcweb-sip-websocket-00) 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, 02 Dec 2011 16:40:35 -0000 2011/12/2 Gilad Shaham : > I followed the previous draft and read this one. I know that from the las= t > draft you would like to refrain from sips issues, but I would expect it t= o > be mentioned at the very least in the security section (13.1). If I'm > reading the examples correctly they mean - use TLS for WebSocket, but fro= m > there forward use any transport, even unencrypted. I'm not sure everyone > would realize that and personally, I don't see a problem sending sips to > indicate it should be secure end-to-end as defined by RFC 5630. Hi Gilad. Indeed we have avoided mentioning sips stuff in the draft. We consider that adding it won't help understanding the sips theory, nor it will help understanding the SIP WebSocket transport proposed in the draft. Personally I consider that the sips stuff should be reworked. Said that, what do you exactly miss (related to sips) in the draft? maybe an example flow? or perhaps a consideration that "in presence of a sips URI the WebSocket transport must be secure which means "wss" URI in the WebSocket connection"? > I'm also not so sure why the 'anonymous.invalid' strings are shown in thi= s > RFC for the Via and Contact headers. This usage is neither defined nor > referenced anywhere other than the examples. If this specification doesn'= t > mandate/recommend it I don't think it should be there, and if it does, it > should be clearly defined (or reference another RFC that does). As explained in the draft, the JavaScript stack in WebSocket capable web browsers has no way to determine the source IP:port from which a WebSocket connection has been established, this is, the SIP UA running within a JavaScript application in a web does not know its local address. Therefore we've chosen 'anonymous.invalid' for Via sentby-host value and for Contact in the initial REGISTER (once the registration is done, the SIP UA would know its GRUU addresses). Regardless GRUU is implemented in the registrar, the usage of Outbound (RFC 5626) makes unnecessary for the SIP UA to know its local address. Of course, in case there is a hostname more appropriate than 'anonymous.invalid' then we could propose it. Is there? Thanks a lot for your comments. --=20 I=C3=B1aki Baz Castillo From gilad@voxisoft.com Fri Dec 2 10:48:26 2011 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 C53CF11E80E7 for ; Fri, 2 Dec 2011 10:48:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.837 X-Spam-Level: X-Spam-Status: No, score=-2.837 tagged_above=-999 required=5 tests=[AWL=-0.761, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, MIME_8BIT_HEADER=0.3, 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 oa1uLxvrXFAc for ; Fri, 2 Dec 2011 10:48:25 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id AA78211E80B5 for ; Fri, 2 Dec 2011 10:48:25 -0800 (PST) Received: by qcsf15 with SMTP id f15so506927qcs.31 for ; Fri, 02 Dec 2011 10:48:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voxisoft.com; s=google; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=SRg8UfMZaPwG6ymPjEVChEt77++SlL2qtC69cHNPzEw=; b=lUmE17OCRP8Lbre3O7tdVdFh6toNp4uRteMR7ZcI0NlNSdqwFm0mUL/PJ8ZwSpKwgY E43/UnWj89nogqjSkKk6dkPVO59wC+/5zskVJIrvMh73FBsA1FTriL8VhTUgFlthQleZ jZQ/PwukFw32hctYmTCFCCHXVIFFvNrA+Y/YQ= Received: by 10.229.68.234 with SMTP id w42mr2661053qci.251.1322851705127; Fri, 02 Dec 2011 10:48:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.159.198 with HTTP; Fri, 2 Dec 2011 10:48:03 -0800 (PST) X-Originating-IP: [109.64.26.1] In-Reply-To: References: <5470070492D34F4EAC60E4ED91CB3841@gsmlaptop> From: Gilad Shaham Date: Fri, 2 Dec 2011 20:48:03 +0200 Message-ID: To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=0016e651f6e8f982a904b3206964 Cc: =?ISO-8859-1?Q?Jos=E9_Luis_Mill=E1n?= , "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] New Version Notification for draft-ibc-sipcore-sip-websocket-00 (previously draft-ibc-rtcweb-sip-websocket-00) 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, 02 Dec 2011 18:48:26 -0000 --0016e651f6e8f982a904b3206964 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Dec 2, 2011 at 6:40 PM, I=F1aki Baz Castillo wrote: > 2011/12/2 Gilad Shaham : > > I followed the previous draft and read this one. I know that from the > last > > draft you would like to refrain from sips issues, but I would expect it > to > > be mentioned at the very least in the security section (13.1). If I'm > > reading the examples correctly they mean - use TLS for WebSocket, but > from > > there forward use any transport, even unencrypted. I'm not sure everyon= e > > would realize that and personally, I don't see a problem sending sips t= o > > indicate it should be secure end-to-end as defined by RFC 5630. > > Hi Gilad. Indeed we have avoided mentioning sips stuff in the draft. > We consider that adding it won't help understanding the sips theory, > nor it will help understanding the SIP WebSocket transport proposed in > the draft. Personally I consider that the sips stuff should be > reworked. > > Said that, what do you exactly miss (related to sips) in the draft? > maybe an example flow? or perhaps a consideration that "in presence of > a sips URI the WebSocket transport must be secure which means "wss" > URI in the WebSocket connection"? > > If using sips in the examples has a negative effect on clarity I understand, but it is a bcp and a recommendation, is it not? It should be clear that implementors would not rely solely on 'wss' for end-to-end-encryption, but rather use sips URI for that purpose, especially since the draft does recommend securing the traffic. In other words, I believe there should be at the very least text explaining that in the security considerations section. > > > I'm also not so sure why the 'anonymous.invalid' strings are shown in > this > > RFC for the Via and Contact headers. This usage is neither defined nor > > referenced anywhere other than the examples. If this specification > doesn't > > mandate/recommend it I don't think it should be there, and if it does, = it > > should be clearly defined (or reference another RFC that does). > > As explained in the draft, the JavaScript stack in WebSocket capable > web browsers has no way to determine the source IP:port from which a > WebSocket connection has been established, this is, the SIP UA running > within a JavaScript application in a web does not know its local > address. Therefore we've chosen 'anonymous.invalid' for Via > sentby-host value and for Contact in the initial REGISTER (once the > registration is done, the SIP UA would know its GRUU addresses). > Regardless GRUU is implemented in the registrar, the usage of Outbound > (RFC 5626) makes unnecessary for the SIP UA to know its local address. > > Of course, in case there is a hostname more appropriate than > 'anonymous.invalid' then we could propose it. Is there? > The string did reminded me of the privacy extensions, since it's used in the From header, but I was more concerned there is something unspecified. Outbound still mandates a URI since the authoritative proxy will store that value to form the target set and therefore it seems as if the UA should be prepared to receive anonymous.invalid as target URI. Should that be the case or should the UA generate some kind of URI? It's just an example and it's possible it's easy to explain how it works, but my point is that this seems undefined. I agree that the URI should not be mandatory since it is due to javascript security limitations and it's certainly possible this transport would be used outside the browser. If you are looking for alternative hostnames, 'localhost' comes to mind, but I didn't really consider whether it's better, worse or equivalent. Thanks, Gilad --0016e651f6e8f982a904b3206964 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Fri, Dec 2, 2011 at = 6:40 PM, I=F1aki Baz Castillo <ibc@aliax.net> wrote:
2011/12/2 Gilad Shaham <gilad@voxi= soft.com>:
> I followed the previous draft and read this one. I k= now that from the last
> draft you would like to refrain from sips issues, but I would expect i= t to
> be mentioned at the very least in the security section (13.1). If I= 9;m
> reading the examples correctly they mean - use TLS for WebSocket, but = from
> there forward use any transport, even unencrypted. I'm not sure ev= eryone
> would realize that and personally, I don't see a problem sending s= ips to
> indicate it should be secure end-to-end as defined by RFC 5630.

Hi Gilad. Indeed we have avoided mentioning sips stuff in the draft.<= br> We consider that adding it won't help understanding the sips theory, nor it will help understanding the SIP WebSocket transport proposed in
the draft. Personally I consider that the sips stuff should be
reworked.

Said that, what do you exactly miss (related to sips) in the draft?
maybe an example flow? or perhaps a consideration that "in presence of=
a sips URI the WebSocket transport must be secure which means "wss&quo= t;
URI in the WebSocket connection"?

If using sips in the examples= has a negative effect on clarity I understand, but it is a bcp and a recom= mendation, is it not? It should be clear that implementors would not rely s= olely on 'wss' for end-to-end-encryption, but rather use sips URI f= or that purpose, especially since the draft does recommend securing the tra= ffic. In other words, I believe there should be at the very least text expl= aining that in the security considerations section.

> I'm also not so sure why the 'anonymous.invalid' strings a= re shown in this
> RFC for the Via and Contact headers. This usage is neither defined nor=
> referenced anywhere other than the examples. If this specification doe= sn't
> mandate/recommend it I don't think it should be there, and if it d= oes, it
> should be clearly defined (or reference another RFC that does).

As explained in the draft, the JavaScript stack in WebSocket capable<= br> web browsers has no way to determine the source IP:port from which a
WebSocket connection has been established, this is, the SIP UA running
within a JavaScript application in a web does not know its local
address. Therefore we've chosen 'anonymous.invalid' for Via
sentby-host value and for Contact in the initial REGISTER (once the
registration is done, the SIP UA would know its GRUU addresses).
Regardless GRUU is implemented in the registrar, the usage of Outbound
(RFC 5626) makes unnecessary for the SIP UA to know its local address.

Of course, in case there is a hostname more appropriate than
'anonymous.invalid' then we could propose it. Is there?
The string did reminded me of the privacy extensions, since it= 9;s used in the From header, but I was more concerned there is something un= specified. Outbound still mandates a URI since the authoritative proxy will= store that value to form the target set and therefore it seems as if the U= A should be prepared to receive anonymous.invalid as target URI. Should tha= t be the case or should the UA generate some kind of URI? It's just an = example and it's possible it's easy to explain how it works, but my= point is that this seems undefined.

I agree that the URI should not be mandatory since it is due to javascr= ipt security limitations and it's certainly possible this transport wou= ld be used outside the browser. If you are looking for alternative hostname= s, 'localhost' comes to mind, but I didn't really consider whet= her it's better, worse or equivalent.

Thanks,
Gilad
--0016e651f6e8f982a904b3206964-- From Ranjit.Avasarala@Polycom.com Fri Dec 2 10:58:09 2011 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 4376621F8C56 for ; Fri, 2 Dec 2011 10:58:09 -0800 (PST) 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 SYHZfe-ta7u8 for ; Fri, 2 Dec 2011 10:58:08 -0800 (PST) Received: from Hkgehubprd01.polycom.com (hkgehubprd01.polycom.com [140.242.6.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4024921F8C57 for ; Fri, 2 Dec 2011 10:58:07 -0800 (PST) Received: from hkgmboxprd22.polycom.com ([fe80::c4c3:4566:8b3b:ec85]) by Hkgehubprd01.polycom.com ([fe80::5efe:172.21.6.201%12]) with mapi; Sat, 3 Dec 2011 02:58:06 +0800 From: "Avasarala, Ranjit" To: Gilad Shaham , Victor Pascual Avila , "SIPCORE (Session Initiation Protocol Core) WG" Date: Sat, 3 Dec 2011 02:57:20 +0800 Thread-Topic: [sipcore] New Version Notification for draft-ibc-sipcore-sip-websocket-00 (previously draft-ibc-rtcweb-sip-websocket-00) Thread-Index: AcyxDcsATy0S4csSQ7O4FT18Ci6YRgAFkmKQ Message-ID: <1F2A2C70609D9E41844A2126145FC0982D86143C@HKGMBOXPRD22.polycom.com> References: <5470070492D34F4EAC60E4ED91CB3841@gsmlaptop> In-Reply-To: <5470070492D34F4EAC60E4ED91CB3841@gsmlaptop> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [sipcore] New Version Notification for draft-ibc-sipcore-sip-websocket-00 (previously draft-ibc-rtcweb-sip-websocket-00) 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, 02 Dec 2011 18:58:09 -0000 SGkgR2lsYWQNCg0KQWN0dWFsbHkgd2Vic29ja2V0cyBoYXZlIHNlY3VyaXR5IG9wdGlvbiBpbiB3 c3M6Ly8gb3B0aW9uLiBDb3VsZCB0aGF0IGJlIHVzZWQgZm9yIGVuc3VyaW5nIHNlY3VyaXR5PyAN Cg0KUmVnYXJkcw0KUmFuaml0DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBz aXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBHaWxhZCBTaGFoYW0NClNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMDIsIDIw MTEgOTo0NiBQTQ0KVG86IFZpY3RvciBQYXNjdWFsIEF2aWxhOyBTSVBDT1JFIChTZXNzaW9uIElu aXRpYXRpb24gUHJvdG9jb2wgQ29yZSkgV0cNClN1YmplY3Q6IFJlOiBbc2lwY29yZV0gTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pYmMtc2lwY29yZS1zaXAtd2Vic29ja2V0LTAw IChwcmV2aW91c2x5IGRyYWZ0LWliYy1ydGN3ZWItc2lwLXdlYnNvY2tldC0wMCkNCg0KSGkgVmlj dG9yLA0KDQpJIGZvbGxvd2VkIHRoZSBwcmV2aW91cyBkcmFmdCBhbmQgcmVhZCB0aGlzIG9uZS4g SSBrbm93IHRoYXQgZnJvbSB0aGUgbGFzdCBkcmFmdCB5b3Ugd291bGQgbGlrZSB0byByZWZyYWlu IGZyb20gc2lwcyBpc3N1ZXMsIGJ1dCBJIHdvdWxkIGV4cGVjdCBpdCB0byBiZSBtZW50aW9uZWQg YXQgdGhlIHZlcnkgbGVhc3QgaW4gdGhlIHNlY3VyaXR5IHNlY3Rpb24gKDEzLjEpLiBJZiBJJ20g cmVhZGluZyB0aGUgZXhhbXBsZXMgY29ycmVjdGx5IHRoZXkgbWVhbiAtIHVzZSBUTFMgZm9yIFdl YlNvY2tldCwgYnV0IGZyb20gdGhlcmUgZm9yd2FyZCB1c2UgYW55IHRyYW5zcG9ydCwgZXZlbiB1 bmVuY3J5cHRlZC4gSSdtIG5vdCBzdXJlIGV2ZXJ5b25lIHdvdWxkIHJlYWxpemUgdGhhdCBhbmQg cGVyc29uYWxseSwgSSBkb24ndCBzZWUgYSBwcm9ibGVtIHNlbmRpbmcgc2lwcyB0byBpbmRpY2F0 ZSBpdCBzaG91bGQgYmUgc2VjdXJlIGVuZC10by1lbmQgYXMgZGVmaW5lZCBieSBSRkMgNTYzMC4N Cg0KSSdtIGFsc28gbm90IHNvIHN1cmUgd2h5IHRoZSAnYW5vbnltb3VzLmludmFsaWQnIHN0cmlu Z3MgYXJlIHNob3duIGluIHRoaXMgUkZDIGZvciB0aGUgVmlhIGFuZCBDb250YWN0IGhlYWRlcnMu IFRoaXMgdXNhZ2UgaXMgbmVpdGhlciBkZWZpbmVkIG5vciByZWZlcmVuY2VkIGFueXdoZXJlIG90 aGVyIHRoYW4gdGhlIGV4YW1wbGVzLiBJZiB0aGlzIHNwZWNpZmljYXRpb24gZG9lc24ndCBtYW5k YXRlL3JlY29tbWVuZCBpdCBJIGRvbid0IHRoaW5rIGl0IHNob3VsZCBiZSB0aGVyZSwgYW5kIGlm IGl0IGRvZXMsIGl0IHNob3VsZCBiZSBjbGVhcmx5IGRlZmluZWQgKG9yIHJlZmVyZW5jZSBhbm90 aGVyIFJGQyB0aGF0IGRvZXMpLg0KDQpIb3BlIGl0IGhlbHBzLA0KR2lsYWQNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFZpY3RvciBQYXNjdWFsIEF2aWxhDQpTZW50OiBGcmlk YXksIERlY2VtYmVyIDAyLCAyMDExIDU6MzMgUE0NClRvOiBTSVBDT1JFIChTZXNzaW9uIEluaXRp YXRpb24gUHJvdG9jb2wgQ29yZSkgV0cNClN1YmplY3Q6IFJlOiBbc2lwY29yZV0gTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvcg0KZHJhZnQtaWJjLXNpcGNvcmUtc2lwLXdlYnNvY2tldC0wMCAo cHJldmlvdXNseQ0KZHJhZnQtaWJjLXJ0Y3dlYi1zaXAtd2Vic29ja2V0LTAwKQ0KDQpUaGUgYXV0 aG9ycyB3b3VsZCBhcHByZWNpYXRlIGFueSBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgb24gdGhp cyBuZXcgdmVyc2lvbi4NCg0KTWFueSB0aGFua3MgaW4gYWR2YW5jZSwNCi1WaWN0b3INCg0KT24g U3VuLCBOb3YgMjcsIDIwMTEgYXQgMjowNyBQTSwgScOxYWtpIEJheiBDYXN0aWxsbyA8aWJjQGFs aWF4Lm5ldD4gd3JvdGU6DQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pYmMtc2lwY29y ZS1zaXAtd2Vic29ja2V0LTAwLnR4dCBoYXMgYmVlbiANCj4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRl ZCBieSBJw7Fha2kgQmF6IENhc3RpbGxvIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgDQo+IHJlcG9z aXRvcnkuDQo+DQo+IEZpbGVuYW1lOiAgICAgICAgZHJhZnQtaWJjLXNpcGNvcmUtc2lwLXdlYnNv Y2tldA0KPiBSZXZpc2lvbjogICAgICAgIDAwDQo+IFRpdGxlOiAgICAgICAgICAgVGhlIFdlYlNv Y2tldCBQcm90b2NvbCBhcyBhIFRyYW5zcG9ydCBmb3IgdGhlIFNlc3Npb24NCj4gSW5pdGlhdGlv biBQcm90b2NvbCAoU0lQKQ0KPiBDcmVhdGlvbiBkYXRlOiAgIDIwMTEtMTEtMjQNCj4gV0cgSUQ6 ICAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4gTnVtYmVyIG9mIHBhZ2VzOiAyNw0K Pg0KPiBBYnN0cmFjdDoNCj4gIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGEgV2ViU29ja2V0IFN1 Yi1Qcm90b2NvbCBmb3IgYSBuZXcgdHJhbnNwb3J0ICANCj4gaW4gU0lQIChTZXNzaW9uIEluaXRp YXRpb24gUHJvdG9jb2wpLiAgVGhlIFdlYlNvY2tldCBwcm90b2NvbCBlbmFibGVzICANCj4gdHdv LXdheSByZWFsdGltZSBjb21tdW5pY2F0aW9uIGJldHdlZW4gY2xpZW50cyBhbmQgc2VydmVycy4N Cj4NCj4NCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pYmMtc2lwY29yZS1zaXAtd2Vi c29ja2V0LTAwLnR4dA0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pYmMtc2lw Y29yZS1zaXAtd2Vic29ja2V0LTAwDQo+DQo+DQo+IFRoaXMgZHJhZnQgaXMgYSBuZXcgcmV2aXNp b24gb2YgdGhlIHByZXZpb3VzbHkgbmFtZWQgDQo+IGRyYWZ0LWliYy1ydGN3ZWItc2lwLXdlYnNv Y2tldC0wMC4NCj4NCj4gU3VtbWFyeSBvZiBtYWluIGNoYW5nZXMgaW4gdGhpcyByZXZpc2lvbjoN Cj4NCj4gLSBXZWJTb2NrZXQgYmFja2dyb3VuZCBwcm92aWRlZC4NCj4gLSBTY29wZSBub3QgbGlt aXRlZCB0byB3ZWItYnJvd3NlcnMuDQo+IC0gT3V0Ym91bmQgYW5kIEdSVVUgdXNhZ2UgZGVzY3Jp YmVkLg0KPiAtIEROUyBOQVBUUi9TUlYgY29uc2lkZXJhdGlvbnMgaW5jbHVkZWQuDQo+IC0gQWRk ZWQgc29tZSBjbGFyaWZpY2F0aW9ucyBhbmQgYnVnIGZpeGluZy4NCj4NCj4NCj4gQXMgdXN1YWws IHlvdXIgY29tbWVudHMgYXJlIG1vc3QgYXBwcmVjaWF0ZWQuDQo+DQo+DQo+IC0tDQo+IEnDsWFr aSBCYXogQ2FzdGlsbG8NCj4gPGliY0BhbGlheC5uZXQ+DQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNpcGNvcmUgbWFpbGluZyBsaXN0DQo+IHNp cGNvcmVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z aXBjb3JlDQoNCg0KDQotLQ0KVmljdG9yIFBhc2N1YWwgw4F2aWxhDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2lwY29yZSBtYWlsaW5nIGxpc3QNCnNp cGNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lw Y29yZSANCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CnNpcGNvcmUgbWFpbGluZyBsaXN0DQpzaXBjb3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg== From gilad@voxisoft.com Fri Dec 2 11:12:00 2011 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 4756B11E809D for ; Fri, 2 Dec 2011 11:12:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.907 X-Spam-Level: X-Spam-Status: No, score=-2.907 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 jQ6NGcX60tS9 for ; Fri, 2 Dec 2011 11:11:59 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1517211E8083 for ; Fri, 2 Dec 2011 11:11:59 -0800 (PST) Received: by qadb15 with SMTP id b15so685183qad.10 for ; Fri, 02 Dec 2011 11:11:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voxisoft.com; s=google; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=NXGZmAT9b7xSAGWlYNTIZDBQdg76PQeagwnUSU+FFMg=; b=DCMAdCXnuNojDF1M3K0mRp8QvVE9tHJ0z+bpHDxzxk36UyiHvAGzXJQLyo/ocr0T/g W6S+tRLVIMB/APeG0p/h0hgUR5Wt5SsahDhPPF4OhSw+cY4naYQrTEudgQb8ztazSsxk cynKGkvz6POGMR0wmW7odF1fW+gKbd1LWlG3w= Received: by 10.224.185.199 with SMTP id cp7mr4185205qab.68.1322853115234; Fri, 02 Dec 2011 11:11:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.159.198 with HTTP; Fri, 2 Dec 2011 11:11:34 -0800 (PST) X-Originating-IP: [109.64.26.1] In-Reply-To: <1F2A2C70609D9E41844A2126145FC0982D86143C@HKGMBOXPRD22.polycom.com> References: <5470070492D34F4EAC60E4ED91CB3841@gsmlaptop> <1F2A2C70609D9E41844A2126145FC0982D86143C@HKGMBOXPRD22.polycom.com> From: Gilad Shaham Date: Fri, 2 Dec 2011 21:11:34 +0200 Message-ID: To: "Avasarala, Ranjit" Content-Type: multipart/alternative; boundary=485b397dd547060ab604b320be1d Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] New Version Notification for draft-ibc-sipcore-sip-websocket-00 (previously draft-ibc-rtcweb-sip-websocket-00) 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, 02 Dec 2011 19:12:00 -0000 --485b397dd547060ab604b320be1d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable wss is used to secure a single hop, it does not ensure, at least based on existing sip routing rules, that it will remain secure for the next hops. My point is exactly this, it should be clear wss is not enough. On Fri, Dec 2, 2011 at 8:57 PM, Avasarala, Ranjit < Ranjit.Avasarala@polycom.com> wrote: > Hi Gilad > > Actually websockets have security option in wss:// option. Could that be > used for ensuring security? > > Regards > Ranjit > > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Gilad Shaham > Sent: Friday, December 02, 2011 9:46 PM > To: Victor Pascual Avila; SIPCORE (Session Initiation Protocol Core) WG > Subject: Re: [sipcore] New Version Notification for > draft-ibc-sipcore-sip-websocket-00 (previously > draft-ibc-rtcweb-sip-websocket-00) > > Hi Victor, > > I followed the previous draft and read this one. I know that from the las= t > draft you would like to refrain from sips issues, but I would expect it t= o > be mentioned at the very least in the security section (13.1). If I'm > reading the examples correctly they mean - use TLS for WebSocket, but fro= m > there forward use any transport, even unencrypted. I'm not sure everyone > would realize that and personally, I don't see a problem sending sips to > indicate it should be secure end-to-end as defined by RFC 5630. > > I'm also not so sure why the 'anonymous.invalid' strings are shown in thi= s > RFC for the Via and Contact headers. This usage is neither defined nor > referenced anywhere other than the examples. If this specification doesn'= t > mandate/recommend it I don't think it should be there, and if it does, it > should be clearly defined (or reference another RFC that does). > > Hope it helps, > Gilad > > -----Original Message----- > From: Victor Pascual Avila > Sent: Friday, December 02, 2011 5:33 PM > To: SIPCORE (Session Initiation Protocol Core) WG > Subject: Re: [sipcore] New Version Notification for > draft-ibc-sipcore-sip-websocket-00 (previously > draft-ibc-rtcweb-sip-websocket-00) > > The authors would appreciate any comments and suggestions on this new > version. > > Many thanks in advance, > -Victor > > On Sun, Nov 27, 2011 at 2:07 PM, I=F1aki Baz Castillo wro= te: > > A new version of I-D, draft-ibc-sipcore-sip-websocket-00.txt has been > > successfully submitted by I=F1aki Baz Castillo and posted to the IETF > > repository. > > > > Filename: draft-ibc-sipcore-sip-websocket > > Revision: 00 > > Title: The WebSocket Protocol as a Transport for the Session > > Initiation Protocol (SIP) > > Creation date: 2011-11-24 > > WG ID: Individual Submission > > Number of pages: 27 > > > > Abstract: > > This document specifies a WebSocket Sub-Protocol for a new transport > > in SIP (Session Initiation Protocol). The WebSocket protocol enables > > two-way realtime communication between clients and servers. > > > > > > http://www.ietf.org/id/draft-ibc-sipcore-sip-websocket-00.txt > > http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-00 > > > > > > This draft is a new revision of the previously named > > draft-ibc-rtcweb-sip-websocket-00. > > > > Summary of main changes in this revision: > > > > - WebSocket background provided. > > - Scope not limited to web-browsers. > > - Outbound and GRUU usage described. > > - DNS NAPTR/SRV considerations included. > > - Added some clarifications and bug fixing. > > > > > > As usual, your comments are most appreciated. > > > > > > -- > > I=F1aki Baz Castillo > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > > -- > Victor Pascual =C1vila > _______________________________________________ > 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 > --485b397dd547060ab604b320be1d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
wss is used to secure a single hop, it does not ensure, at= least based on existing sip routing rules, that it will remain secure for = the next hops.
My point is exactly this, it should be clear wss is not e= nough.

On Fri, Dec 2, 2011 at 8:57 PM, Avasarala, R= anjit <Ranjit.Avasarala@polycom.com> wrote:
Hi Gilad

Actually websockets have security option in wss:// option. Could that be us= ed for ensuring security?

Regards
Ranjit

-----Original Message-----
From: sipcore-bounces@ietf.org<= /a> [mailto:sipcore-bounces@iet= f.org] On Behalf Of Gilad Shaham
Sent: Friday, December 02, 2011 9:46 PM
To: Victor Pascual Avila; SIPCORE (Session Initiation Protocol Core) WG
Subject: Re: [sipcore] New Version Notification for draft-ibc-sipcore-sip-w= ebsocket-00 (previously draft-ibc-rtcweb-sip-websocket-00)

Hi Victor,

I followed the previous draft and read this one. I know that from the last = draft you would like to refrain from sips issues, but I would expect it to = be mentioned at the very least in the security section (13.1). If I'm r= eading the examples correctly they mean - use TLS for WebSocket, but from t= here forward use any transport, even unencrypted. I'm not sure everyone= would realize that and personally, I don't see a problem sending sips = to indicate it should be secure end-to-end as defined by RFC 5630.

I'm also not so sure why the 'anonymous.invalid' strings are sh= own in this RFC for the Via and Contact headers. This usage is neither defi= ned nor referenced anywhere other than the examples. If this specification = doesn't mandate/recommend it I don't think it should be there, and = if it does, it should be clearly defined (or reference another RFC that doe= s).

Hope it helps,
Gilad

-----Original Message-----
From: Victor Pascual Avila
Sent: Friday, December 02, 2011 5:33 PM
To: SIPCORE (Session Initiation Protocol Core) WG
Subject: Re: [sipcore] New Version Notification for
draft-ibc-sipcore-sip-websocket-00 (previously
draft-ibc-rtcweb-sip-websocket-00)

The authors would appreciate any comments and suggestions on this new versi= on.

Many thanks in advance,
-Victor

On Sun, Nov 27, 2011 at 2:07 PM, I=F1aki Baz Castillo <ibc@aliax.net> wrote:
> A new version of I-D, draft-ibc-sipcore-sip-websocket-00.txt has been<= br> > successfully submitted by I=F1aki Baz Castillo and posted to the IETF<= br> > repository.
>
> Filename: =A0 =A0 =A0 =A0draft-ibc-sipcore-sip-websocket
> Revision: =A0 =A0 =A0 =A000
> Title: =A0 =A0 =A0 =A0 =A0 The WebSocket Protocol as a Transport for t= he Session
> Initiation Protocol (SIP)
> Creation date: =A0 2011-11-24
> WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
> Number of pages: 27
>
> Abstract:
> =A0This document specifies a WebSocket Sub-Protocol for a new transpor= t
> in SIP (Session Initiation Protocol). =A0The WebSocket protocol enable= s
> two-way realtime communication between clients and servers.
>
>
> http://www.ietf.org/id/draft-ibc-sipcore-sip-websocke= t-00.txt
> http://tools.ietf.org/html/draft-ibc-sipcore-sip-webs= ocket-00
>
>
> This draft is a new revision of the previously named
> draft-ibc-rtcweb-sip-websocket-00.
>
> Summary of main changes in this revision:
>
> - WebSocket background provided.
> - Scope not limited to web-browsers.
> - Outbound and GRUU usage described.
> - DNS NAPTR/SRV considerations included.
> - Added some clarifications and bug fixing.
>
>
> As usual, your comments are most appreciated.
>
>
> --
> I=F1aki Baz Castillo
> <ibc@aliax.net>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore



--
Victor Pascual =C1vila
_______________________________________________
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

--485b397dd547060ab604b320be1d-- From wwwrun@rfc-editor.org Fri Dec 2 16:21:43 2011 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 854E921F8C4E; Fri, 2 Dec 2011 16:21:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.6 X-Spam-Level: X-Spam-Status: No, score=-101.6 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, 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 0akFoN-q9lLz; Fri, 2 Dec 2011 16:21:43 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 2F41F21F8C4D; Fri, 2 Dec 2011 16:21:43 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 3905C72E00C; Fri, 2 Dec 2011 16:21:26 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20111203002126.3905C72E00C@rfc-editor.org> Date: Fri, 2 Dec 2011 16:21:26 -0800 (PST) Cc: sipcore@ietf.org, rfc-editor@rfc-editor.org Subject: [sipcore] RFC 6442 on Location Conveyance for the Session Initiation Protocol 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: Sat, 03 Dec 2011 00:21:43 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6442 Title: Location Conveyance for the Session Initiation Protocol Author: J. Polk, B. Rosen, J. Peterson Status: Standards Track Stream: IETF Date: December 2011 Mailbox: jmpolk@cisco.com, br@brianrosen.net, jon.peterson@neustar.biz Pages: 35 Characters: 80795 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sipcore-location-conveyance-09.txt URL: http://www.rfc-editor.org/rfc/rfc6442.txt This document defines an extension to the Session Initiation Protocol (SIP) to convey geographic location information from one SIP entity to another SIP entity. The SIP extension covers end-to-end conveyance as well as location-based routing, where SIP intermediaries make routing decisions based upon the location of the Location Target. [STANDARDS-TRACK] This document is a product of the Session Initiation Protocol Core Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From jmpolk@cisco.com Fri Dec 2 17:28:24 2011 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 1A9931F0C45 for ; Fri, 2 Dec 2011 17:28:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, 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 Hs0Y+-2UXo7m for ; Fri, 2 Dec 2011 17:28:23 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 71B7C1F0C38 for ; Fri, 2 Dec 2011 17:28:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=2752; q=dns/txt; s=iport; t=1322875703; x=1324085303; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=xIXYkbpyRO9wEOFJFRSSZxmts/Sefais19h0IsXdrF0=; b=NZyK7H95D9hVrP9UFJ3qorxJ9yMun5ze+T/MbgpAVTqARIHoPtP7SQMm zVcmEmw/Pbl3LSHCt7I97IArjXreBt4dwkJK1XTAY2N0H5bcEKMzk4y3J x72/J+wrAJnr28W1xr7IqjBUpQGtKDS34oHVn+rT6kyA7qHc18dh+S8qA 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANF52U6rRDoJ/2dsb2JhbABDqi6BBYFyAQEBBAEBAQ8BJQIUIAsQBwQUEBIQGQ4KJhkJCwcCBAGHbZgvAZ4riAyDFQSIK55i X-IronPort-AV: E=Sophos;i="4.71,286,1320624000"; d="scan'208";a="17471716" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 03 Dec 2011 01:28:23 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pB31SM2V014463; Sat, 3 Dec 2011 01:28:22 GMT Message-Id: <201112030128.pB31SM2V014463@mtv-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 02 Dec 2011 19:28:19 -0600 To: sipcore@ietf.org From: "James M. Polk" In-Reply-To: <20111203002126.3905C72E00C@rfc-editor.org> References: <20111203002126.3905C72E00C@rfc-editor.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [sipcore] RFC 6442 on Location Conveyance for the Session Initiation Protocol 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: Sat, 03 Dec 2011 01:28:24 -0000 yyyeeeeeeee..... aaaaahhhhhhhhh clank... ..... creeeeek ....... <<>> (dust settles) wow... so that's been the weight dragging on me all this time.... I feel better ;-) James At 06:21 PM 12/2/2011, rfc-editor@rfc-editor.org wrote: >A new Request for Comments is now available in online RFC libraries. > > > RFC 6442 > > Title: Location Conveyance for the Session > Initiation Protocol > Author: J. Polk, B. Rosen, > J. Peterson > Status: Standards Track > Stream: IETF > Date: December 2011 > Mailbox: jmpolk@cisco.com, > br@brianrosen.net, > jon.peterson@neustar.biz > Pages: 35 > Characters: 80795 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-sipcore-location-conveyance-09.txt > > URL: http://www.rfc-editor.org/rfc/rfc6442.txt > >This document defines an extension to the Session Initiation >Protocol (SIP) to convey geographic location information from one >SIP entity to another SIP entity. The SIP extension covers >end-to-end conveyance as well as location-based routing, where SIP >intermediaries make routing decisions based upon the location of the >Location Target. [STANDARDS-TRACK] > >This document is a product of the Session Initiation Protocol Core >Working Group of the IETF. > >This is now a Proposed Standard Protocol. > >STANDARDS TRACK: This document specifies an Internet standards track >protocol for the Internet community,and requests discussion and suggestions >for improvements. Please refer to the current edition of the Internet >Official Protocol Standards (STD 1) for the standardization state and >status of this protocol. Distribution of this memo is unlimited. > >This announcement is sent to the IETF-Announce and rfc-dist lists. >To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > >For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. >For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > >Requests for special distribution should be addressed to either the >author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless >specifically noted otherwise on the RFC itself, all RFCs are for >unlimited distribution. > > >The RFC Editor Team >Association Management Solutions, LLC > > >_______________________________________________ >IETF-Announce mailing list >IETF-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/ietf-announce From martin.thomson@gmail.com Fri Dec 2 18:02:17 2011 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 88A9D1F0C55 for ; Fri, 2 Dec 2011 18:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_93=0.6, 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 vC348fxOyl7J for ; Fri, 2 Dec 2011 18:02:17 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id B23811F0C45 for ; Fri, 2 Dec 2011 18:02:16 -0800 (PST) Received: by bkar19 with SMTP id r19so2406bka.31 for ; Fri, 02 Dec 2011 18:02:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=XHOs8gABAMn/EJpWUix7+/8jzxdU9CgS9sww88cc3RQ=; b=h0DCyoBI+0JN7YT2PXET8WpvEWMSmEtK11Dx5zLNAH1dDkkNbDziOvc9PuLkM7xm9t bEHUrFx5Q8DrkisFBTM9KNx/mPW+ygVcjjKA+7e+OYGFKNO1CRdDczA6Czqy7xiDabP/ AfaUo7JP36lTs6L8oXAOUXzaxnxA7bX072z3w= MIME-Version: 1.0 Received: by 10.205.137.135 with SMTP id io7mr318788bkc.88.1322877735360; Fri, 02 Dec 2011 18:02:15 -0800 (PST) Received: by 10.204.79.74 with HTTP; Fri, 2 Dec 2011 18:02:15 -0800 (PST) In-Reply-To: <201112030128.pB31SM2V014463@mtv-core-4.cisco.com> References: <20111203002126.3905C72E00C@rfc-editor.org> <201112030128.pB31SM2V014463@mtv-core-4.cisco.com> Date: Sat, 3 Dec 2011 13:02:15 +1100 Message-ID: From: Martin Thomson To: "James M. Polk" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: sipcore@ietf.org Subject: Re: [sipcore] RFC 6442 on Location Conveyance for the Session Initiation Protocol 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: Sat, 03 Dec 2011 02:02:17 -0000 Congratulations. On 3 December 2011 12:28, James M. Polk wrote: > yyyeeeeeeee..... aaaaahhhhhhhhh > > clank... > > ..... =C2=A0 creeeeek =C2=A0....... > > <<>> > > (dust settles) > > wow... so that's been the weight dragging on me all this time.... > > I feel better > > ;-) > > James > > > At 06:21 PM 12/2/2011, rfc-editor@rfc-editor.org wrote: > >> A new Request for Comments is now available in online RFC libraries. >> >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 6442 >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0Title: =C2=A0 =C2=A0 =C2=A0Location Conveyanc= e for the Session >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ini= tiation Protocol >> =C2=A0 =C2=A0 =C2=A0 =C2=A0Author: =C2=A0 =C2=A0 J. Polk, B. Rosen, >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0J. = Peterson >> =C2=A0 =C2=A0 =C2=A0 =C2=A0Status: =C2=A0 =C2=A0 Standards Track >> =C2=A0 =C2=A0 =C2=A0 =C2=A0Stream: =C2=A0 =C2=A0 IETF >> =C2=A0 =C2=A0 =C2=A0 =C2=A0Date: =C2=A0 =C2=A0 =C2=A0 December 2011 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0Mailbox: =C2=A0 =C2=A0jmpolk@cisco.com, >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0br@= brianrosen.net, >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0jon= .peterson@neustar.biz >> =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages: =C2=A0 =C2=A0 =C2=A035 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0Characters: 80795 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0Updates/Obsoletes/SeeAlso: =C2=A0 None >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0I-D Tag: =C2=A0 =C2=A0draft-ietf-sipcore-loca= tion-conveyance-09.txt >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.rf= c-editor.org/rfc/rfc6442.txt >> >> This document defines an extension to the Session Initiation >> Protocol (SIP) to convey geographic location information from one >> SIP entity to another SIP entity. =C2=A0The SIP extension covers >> end-to-end conveyance as well as location-based routing, where SIP >> intermediaries make routing decisions based upon the location of the >> Location Target. =C2=A0[STANDARDS-TRACK] >> >> This document is a product of the Session Initiation Protocol Core Worki= ng >> Group of the IETF. >> >> This is now a Proposed Standard Protocol. >> >> STANDARDS TRACK: This document specifies an Internet standards track >> protocol for the Internet community,and requests discussion and >> suggestions >> for improvements. =C2=A0Please refer to the current edition of the Inter= net >> Official Protocol Standards (STD 1) for the standardization state and >> status of this protocol. =C2=A0Distribution of this memo is unlimited. >> >> This announcement is sent to the IETF-Announce and rfc-dist lists. >> To subscribe or unsubscribe, see >> =C2=A0http://www.ietf.org/mailman/listinfo/ietf-announce >> =C2=A0http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >> >> For searching the RFC series, see >> http://www.rfc-editor.org/rfcsearch.html. >> For downloading RFCs, see http://www.rfc-editor.org/rfc.html. >> >> Requests for special distribution should be addressed to either the >> author of the RFC in question, or to rfc-editor@rfc-editor.org. =C2=A0Un= less >> specifically noted otherwise on the RFC itself, all RFCs are for >> unlimited distribution. >> >> >> The RFC Editor Team >> Association Management Solutions, LLC >> >> >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From James.Winterbottom@commscope.com Fri Dec 2 21:07:26 2011 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 D020511E8081 for ; Fri, 2 Dec 2011 21:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_93=0.6] 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 CDosnE1PAqoW for ; Fri, 2 Dec 2011 21:07:26 -0800 (PST) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8A011E8073 for ; Fri, 2 Dec 2011 21:07:25 -0800 (PST) X-AuditID: 0a0404e9-b7c8cae00000799e-0f-4ed9ae8bed59 Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id 7A.44.31134.B8EA9DE4; Fri, 2 Dec 2011 23:07:23 -0600 (CST) Received: from CDCE10HC1.commscope.com (10.86.28.21) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 2 Dec 2011 23:05:29 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by CDCE10HC1.commscope.com (10.86.28.21) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 2 Dec 2011 23:05:28 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Sat, 3 Dec 2011 13:05:25 +0800 From: "Winterbottom, James" To: "'martin.thomson@gmail.com'" , "'jmpolk@cisco.com'" Date: Sat, 3 Dec 2011 13:05:24 +0800 Thread-Topic: [sipcore] RFC 6442 on Location Conveyance for the Session Initiation Protocol Thread-Index: AcyxX5ln9mMgMQXqTKqK3GqxnY9A/wAGZDe5 Message-ID: <5A55A45AE77F5941B18E5457ECAC8188012119F93EAE@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "'sipcore@ietf.org'" Subject: Re: [sipcore] RFC 6442 on Location Conveyance for the Session Initiation Protocol 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: Sat, 03 Dec 2011 05:07:26 -0000 KzENCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogc2lwY29yZS1ib3VuY2Vz QGlldGYub3JnIDxzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmc+DQpUbzogSmFtZXMgTS4gUG9sayA8 am1wb2xrQGNpc2NvLmNvbT4NCkNjOiBzaXBjb3JlQGlldGYub3JnIDxzaXBjb3JlQGlldGYub3Jn Pg0KU2VudDogU2F0IERlYyAwMyAxMDowMjoxNSAyMDExClN1YmplY3Q6IFJlOiBbc2lwY29yZV0g UkZDIDY0NDIgb24gTG9jYXRpb24gQ29udmV5YW5jZSBmb3IgdGhlIFNlc3Npb24gSW5pdGlhdGlv biBQcm90b2NvbA0KDQpDb25ncmF0dWxhdGlvbnMuCgpPbiAzIERlY2VtYmVyIDIwMTEgMTI6Mjgs IEphbWVzIE0uIFBvbGsgPGptcG9sa0BjaXNjby5jb20+IHdyb3RlOgo+IHl5eWVlZWVlZWVlLi4u Li4gYWFhYWFoaGhoaGhoaGgKPgo+IGNsYW5rLi4uCj4KPiAuLi4uLiDCoCBjcmVlZWVlayDCoC4u Li4uLi4KPgo+IDw8PHRodWQ+Pj4KPgo+IChkdXN0IHNldHRsZXMpCj4KPiB3b3cuLi4gc28gdGhh dCdzIGJlZW4gdGhlIHdlaWdodCBkcmFnZ2luZyBvbiBtZSBhbGwgdGhpcyB0aW1lLi4uLgo+Cj4g SSBmZWVsIGJldHRlcgo+Cj4gOy0pCj4KPiBKYW1lcwo+Cj4KPiBBdCAwNjoyMSBQTSAxMi8yLzIw MTEsIHJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmcgd3JvdGU6Cj4KPj4gQSBuZXcgUmVxdWVzdCBm b3IgQ29tbWVudHMgaXMgbm93IGF2YWlsYWJsZSBpbiBvbmxpbmUgUkZDIGxpYnJhcmllcy4KPj4K Pj4KPj4gwqAgwqAgwqAgwqBSRkMgNjQ0Mgo+Pgo+PiDCoCDCoCDCoCDCoFRpdGxlOiDCoCDCoCDC oExvY2F0aW9uIENvbnZleWFuY2UgZm9yIHRoZSBTZXNzaW9uCj4+IMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgSW5pdGlhdGlvbiBQcm90b2NvbAo+PiDCoCDCoCDCoCDCoEF1dGhvcjogwqAg wqAgSi4gUG9saywgQi4gUm9zZW4sCj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgSi4g UGV0ZXJzb24KPj4gwqAgwqAgwqAgwqBTdGF0dXM6IMKgIMKgIFN0YW5kYXJkcyBUcmFjawo+PiDC oCDCoCDCoCDCoFN0cmVhbTogwqAgwqAgSUVURgo+PiDCoCDCoCDCoCDCoERhdGU6IMKgIMKgIMKg IERlY2VtYmVyIDIwMTEKPj4gwqAgwqAgwqAgwqBNYWlsYm94OiDCoCDCoGptcG9sa0BjaXNjby5j b20sCj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYnJAYnJpYW5yb3Nlbi5uZXQsCj4+ IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgam9uLnBldGVyc29uQG5ldXN0YXIuYml6Cj4+ IMKgIMKgIMKgIMKgUGFnZXM6IMKgIMKgIMKgMzUKPj4gwqAgwqAgwqAgwqBDaGFyYWN0ZXJzOiA4 MDc5NQo+PiDCoCDCoCDCoCDCoFVwZGF0ZXMvT2Jzb2xldGVzL1NlZUFsc286IMKgIE5vbmUKPj4K Pj4gwqAgwqAgwqAgwqBJLUQgVGFnOiDCoCDCoGRyYWZ0LWlldGYtc2lwY29yZS1sb2NhdGlvbi1j b252ZXlhbmNlLTA5LnR4dAo+Pgo+PiDCoCDCoCDCoCDCoFVSTDogwqAgwqAgwqAgwqBodHRwOi8v d3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM2NDQyLnR4dAo+Pgo+PiBUaGlzIGRvY3VtZW50IGRl ZmluZXMgYW4gZXh0ZW5zaW9uIHRvIHRoZSBTZXNzaW9uIEluaXRpYXRpb24KPj4gUHJvdG9jb2wg KFNJUCkgdG8gY29udmV5IGdlb2dyYXBoaWMgbG9jYXRpb24gaW5mb3JtYXRpb24gZnJvbSBvbmUK Pj4gU0lQIGVudGl0eSB0byBhbm90aGVyIFNJUCBlbnRpdHkuIMKgVGhlIFNJUCBleHRlbnNpb24g Y292ZXJzCj4+IGVuZC10by1lbmQgY29udmV5YW5jZSBhcyB3ZWxsIGFzIGxvY2F0aW9uLWJhc2Vk IHJvdXRpbmcsIHdoZXJlIFNJUAo+PiBpbnRlcm1lZGlhcmllcyBtYWtlIHJvdXRpbmcgZGVjaXNp b25zIGJhc2VkIHVwb24gdGhlIGxvY2F0aW9uIG9mIHRoZQo+PiBMb2NhdGlvbiBUYXJnZXQuIMKg W1NUQU5EQVJEUy1UUkFDS10KPj4KPj4gVGhpcyBkb2N1bWVudCBpcyBhIHByb2R1Y3Qgb2YgdGhl IFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbCBDb3JlIFdvcmtpbmcKPj4gR3JvdXAgb2YgdGhl IElFVEYuCj4+Cj4+IFRoaXMgaXMgbm93IGEgUHJvcG9zZWQgU3RhbmRhcmQgUHJvdG9jb2wuCj4+ Cj4+IFNUQU5EQVJEUyBUUkFDSzogVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYW4gSW50ZXJuZXQg c3RhbmRhcmRzIHRyYWNrCj4+IHByb3RvY29sIGZvciB0aGUgSW50ZXJuZXQgY29tbXVuaXR5LGFu ZCByZXF1ZXN0cyBkaXNjdXNzaW9uIGFuZAo+PiBzdWdnZXN0aW9ucwo+PiBmb3IgaW1wcm92ZW1l bnRzLiDCoFBsZWFzZSByZWZlciB0byB0aGUgY3VycmVudCBlZGl0aW9uIG9mIHRoZSBJbnRlcm5l dAo+PiBPZmZpY2lhbCBQcm90b2NvbCBTdGFuZGFyZHMgKFNURCAxKSBmb3IgdGhlIHN0YW5kYXJk aXphdGlvbiBzdGF0ZSBhbmQKPj4gc3RhdHVzIG9mIHRoaXMgcHJvdG9jb2wuIMKgRGlzdHJpYnV0 aW9uIG9mIHRoaXMgbWVtbyBpcyB1bmxpbWl0ZWQuCj4+Cj4+IFRoaXMgYW5ub3VuY2VtZW50IGlz IHNlbnQgdG8gdGhlIElFVEYtQW5ub3VuY2UgYW5kIHJmYy1kaXN0IGxpc3RzLgo+PiBUbyBzdWJz Y3JpYmUgb3IgdW5zdWJzY3JpYmUsIHNlZQo+PiDCoGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pZXRmLWFubm91bmNlCj4+IMKgaHR0cDovL21haWxtYW4ucmZjLWVkaXRvci5v cmcvbWFpbG1hbi9saXN0aW5mby9yZmMtZGlzdAo+Pgo+PiBGb3Igc2VhcmNoaW5nIHRoZSBSRkMg c2VyaWVzLCBzZWUKPj4gaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZmNzZWFyY2guaHRtbC4K Pj4gRm9yIGRvd25sb2FkaW5nIFJGQ3MsIHNlZSBodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3Jm Yy5odG1sLgo+Pgo+PiBSZXF1ZXN0cyBmb3Igc3BlY2lhbCBkaXN0cmlidXRpb24gc2hvdWxkIGJl IGFkZHJlc3NlZCB0byBlaXRoZXIgdGhlCj4+IGF1dGhvciBvZiB0aGUgUkZDIGluIHF1ZXN0aW9u LCBvciB0byByZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnLiDCoFVubGVzcwo+PiBzcGVjaWZpY2Fs bHkgbm90ZWQgb3RoZXJ3aXNlIG9uIHRoZSBSRkMgaXRzZWxmLCBhbGwgUkZDcyBhcmUgZm9yCj4+ IHVubGltaXRlZCBkaXN0cmlidXRpb24uCj4+Cj4+Cj4+IFRoZSBSRkMgRWRpdG9yIFRlYW0KPj4g QXNzb2NpYXRpb24gTWFuYWdlbWVudCBTb2x1dGlvbnMsIExMQwo+Pgo+Pgo+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+PiBJRVRGLUFubm91bmNlIG1h aWxpbmcgbGlzdAo+PiBJRVRGLUFubm91bmNlQGlldGYub3JnCj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaWV0Zi1hbm5vdW5jZQo+Cj4KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IHNpcGNvcmUgbWFpbGluZyBsaXN0Cj4g c2lwY29yZUBpZXRmLm9yZwo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2lwY29yZQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpz aXBjb3JlIG1haWxpbmcgbGlzdApzaXBjb3JlQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2lwY29yZQo= From pkyzivat@alum.mit.edu Sat Dec 3 09:00:27 2011 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 850BA21F8D88 for ; Sat, 3 Dec 2011 09:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_93=0.6] 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 i67kAdW9vUfh for ; Sat, 3 Dec 2011 09:00:27 -0800 (PST) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id CEB0521F8C94 for ; Sat, 3 Dec 2011 09:00:26 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta10.westchester.pa.mail.comcast.net with comcast id 4gvg1i00A27AodY5Ah0TxZ; Sat, 03 Dec 2011 17:00:27 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta19.westchester.pa.mail.comcast.net with comcast id 4h0T1i00707duvL3fh0Tqa; Sat, 03 Dec 2011 17:00:27 +0000 Message-ID: <4EDA55AC.2040505@alum.mit.edu> Date: Sun, 04 Dec 2011 01:00:28 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: SIPCORE References: <20111203002126.3905C72E00C@rfc-editor.org> In-Reply-To: <20111203002126.3905C72E00C@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] RFC 6442 on Location Conveyance for the Session Initiation Protocol 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: Sat, 03 Dec 2011 17:00:27 -0000 Congratulations to the authors. It has been a long slog! Thanks, Paul On 12/3/11 8:21 AM, rfc-editor@rfc-editor.org wrote: > > A new Request for Comments is now available in online RFC libraries. > > > RFC 6442 > > Title: Location Conveyance for the Session > Initiation Protocol > Author: J. Polk, B. Rosen, > J. Peterson > Status: Standards Track > Stream: IETF > Date: December 2011 > Mailbox: jmpolk@cisco.com, > br@brianrosen.net, > jon.peterson@neustar.biz > Pages: 35 > Characters: 80795 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-sipcore-location-conveyance-09.txt > > URL: http://www.rfc-editor.org/rfc/rfc6442.txt > > This document defines an extension to the Session Initiation > Protocol (SIP) to convey geographic location information from one > SIP entity to another SIP entity. The SIP extension covers > end-to-end conveyance as well as location-based routing, where SIP > intermediaries make routing decisions based upon the location of the > Location Target. [STANDARDS-TRACK] > > This document is a product of the Session Initiation Protocol Core Working Group of the IETF. > > This is now a Proposed Standard Protocol. > > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > From pkyzivat@alum.mit.edu Sat Dec 3 11:52:01 2011 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 905F621F8ECE for ; Sat, 3 Dec 2011 11:52:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] 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 JnFfdNSWdFLw for ; Sat, 3 Dec 2011 11:52:01 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by ietfa.amsl.com (Postfix) with ESMTP id E794721F9295 for ; Sat, 3 Dec 2011 11:52:00 -0800 (PST) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta12.westchester.pa.mail.comcast.net with comcast id 4jmu1i00B1ap0As5Cjs1Dx; Sat, 03 Dec 2011 19:52:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta22.westchester.pa.mail.comcast.net with comcast id 4js01i00q07duvL3ijs0XA; Sat, 03 Dec 2011 19:52:01 +0000 Message-ID: <4EDA7DDE.1030005@alum.mit.edu> Date: Sun, 04 Dec 2011 03:51:58 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: sipcore@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [sipcore] New Version Notification for draft-ibc-sipcore-sip-websocket-00 (previously draft-ibc-rtcweb-sip-websocket-00) 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: Sat, 03 Dec 2011 19:52:01 -0000 Section 7: Since you are mostly trying to avoid interactions with sips, why is it that you use SIPS+D2W to resolve wss URIs? That seems to imply some relationship to sips that is not intended. Thanks, Paul On 11/27/11 9:07 PM, Iñaki Baz Castillo wrote: > A new version of I-D, draft-ibc-sipcore-sip-websocket-00.txt has been > successfully submitted by Iñaki Baz Castillo and posted to the IETF > repository. > > Filename: draft-ibc-sipcore-sip-websocket > Revision: 00 > Title: The WebSocket Protocol as a Transport for the Session > Initiation Protocol (SIP) > Creation date: 2011-11-24 > WG ID: Individual Submission > Number of pages: 27 > > Abstract: > This document specifies a WebSocket Sub-Protocol for a new transport > in SIP (Session Initiation Protocol). The WebSocket protocol enables > two-way realtime communication between clients and servers. > > > http://www.ietf.org/id/draft-ibc-sipcore-sip-websocket-00.txt > http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-00 > > > This draft is a new revision of the previously named > draft-ibc-rtcweb-sip-websocket-00. > > Summary of main changes in this revision: > > - WebSocket background provided. > - Scope not limited to web-browsers. > - Outbound and GRUU usage described. > - DNS NAPTR/SRV considerations included. > - Added some clarifications and bug fixing. > > > As usual, your comments are most appreciated. > > From hannes.tschofenig@nsn.com Sun Dec 4 10:50:11 2011 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 7882B21F86F6 for ; Sun, 4 Dec 2011 10:50:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, 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 AFpgxeCVKv-Y for ; Sun, 4 Dec 2011 10:50:10 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 4D13821F86D0 for ; Sun, 4 Dec 2011 10:50:09 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pB4Io4E5010518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 4 Dec 2011 19:50:04 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pB4Io2TC003564; Sun, 4 Dec 2011 19:50:04 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 4 Dec 2011 19:50:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Sun, 4 Dec 2011 20:49:58 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718DD7C885@FIESEXC035.nsn-intra.net> In-Reply-To: <5A55A45AE77F5941B18E5457ECAC8188012119F93EAE@SISPE7MB1.commscope.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] RFC 6442 on Location Conveyance for the Session Initiation Protocol Thread-Index: AcyxX5ln9mMgMQXqTKqK3GqxnY9A/wAGZDe5ABhtFkA= References: <5A55A45AE77F5941B18E5457ECAC8188012119F93EAE@SISPE7MB1.commscope.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Winterbottom, James" , , X-OriginalArrivalTime: 04 Dec 2011 18:50:00.0242 (UTC) FILETIME=[86826920:01CCB2B5] Cc: sipcore@ietf.org Subject: Re: [sipcore] RFC 6442 on Location Conveyance for the Session Initiation Protocol 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: Sun, 04 Dec 2011 18:50:11 -0000 SSB0aG91Z2h0IEkgd291bGQgbmV2ZXIgc2VlIHRoaXMgZGF5LiANCg0KQ29uZ3JhdHVsYXRpb25z IQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHNpcGNvcmUtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4gQmVoYWxm IE9mIGV4dCBXaW50ZXJib3R0b20sIEphbWVzDQo+IFNlbnQ6IFNhdHVyZGF5LCBEZWNlbWJlciAw MywgMjAxMSA3OjA1IEFNDQo+IFRvOiAnbWFydGluLnRob21zb25AZ21haWwuY29tJzsgJ2ptcG9s a0BjaXNjby5jb20nDQo+IENjOiAnc2lwY29yZUBpZXRmLm9yZycNCj4gU3ViamVjdDogUmU6IFtz aXBjb3JlXSBSRkMgNjQ0MiBvbiBMb2NhdGlvbiBDb252ZXlhbmNlIGZvciB0aGUgU2Vzc2lvbg0K PiBJbml0aWF0aW9uIFByb3RvY29sDQo+IA0KPiArMQ0KPiANCj4gLS0tLS0gT3JpZ2luYWwgTWVz c2FnZSAtLS0tLQ0KPiBGcm9tOiBzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgPHNpcGNvcmUtYm91 bmNlc0BpZXRmLm9yZz4NCj4gVG86IEphbWVzIE0uIFBvbGsgPGptcG9sa0BjaXNjby5jb20+DQo+ IENjOiBzaXBjb3JlQGlldGYub3JnIDxzaXBjb3JlQGlldGYub3JnPg0KPiBTZW50OiBTYXQgRGVj IDAzIDEwOjAyOjE1IDIwMTENCj4gU3ViamVjdDogUmU6IFtzaXBjb3JlXSBSRkMgNjQ0MiBvbiBM b2NhdGlvbiBDb252ZXlhbmNlIGZvciB0aGUgU2Vzc2lvbg0KPiBJbml0aWF0aW9uIFByb3RvY29s DQo+IA0KPiBDb25ncmF0dWxhdGlvbnMuDQo+IA0KPiBPbiAzIERlY2VtYmVyIDIwMTEgMTI6Mjgs IEphbWVzIE0uIFBvbGsgPGptcG9sa0BjaXNjby5jb20+IHdyb3RlOg0KPiA+IHl5eWVlZWVlZWVl Li4uLi4gYWFhYWFoaGhoaGhoaGgNCj4gPg0KPiA+IGNsYW5rLi4uDQo+ID4NCj4gPiAuLi4uLiDC oCBjcmVlZWVlayDCoC4uLi4uLi4NCj4gPg0KPiA+IDw8PHRodWQ+Pj4NCj4gPg0KPiA+IChkdXN0 IHNldHRsZXMpDQo+ID4NCj4gPiB3b3cuLi4gc28gdGhhdCdzIGJlZW4gdGhlIHdlaWdodCBkcmFn Z2luZyBvbiBtZSBhbGwgdGhpcyB0aW1lLi4uLg0KPiA+DQo+ID4gSSBmZWVsIGJldHRlcg0KPiA+ DQo+ID4gOy0pDQo+ID4NCj4gPiBKYW1lcw0KPiA+DQo+ID4NCj4gPiBBdCAwNjoyMSBQTSAxMi8y LzIwMTEsIHJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmcgd3JvdGU6DQo+ID4NCj4gPj4gQSBuZXcg UmVxdWVzdCBmb3IgQ29tbWVudHMgaXMgbm93IGF2YWlsYWJsZSBpbiBvbmxpbmUgUkZDIGxpYnJh cmllcy4NCj4gPj4NCj4gPj4NCj4gPj4gwqAgwqAgwqAgwqBSRkMgNjQ0Mg0KPiA+Pg0KPiA+PiDC oCDCoCDCoCDCoFRpdGxlOiDCoCDCoCDCoExvY2F0aW9uIENvbnZleWFuY2UgZm9yIHRoZSBTZXNz aW9uDQo+ID4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgSW5pdGlhdGlvbiBQcm90b2Nv bA0KPiA+PiDCoCDCoCDCoCDCoEF1dGhvcjogwqAgwqAgSi4gUG9saywgQi4gUm9zZW4sDQo+ID4+ IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgSi4gUGV0ZXJzb24NCj4gPj4gwqAgwqAgwqAg wqBTdGF0dXM6IMKgIMKgIFN0YW5kYXJkcyBUcmFjaw0KPiA+PiDCoCDCoCDCoCDCoFN0cmVhbTog wqAgwqAgSUVURg0KPiA+PiDCoCDCoCDCoCDCoERhdGU6IMKgIMKgIMKgIERlY2VtYmVyIDIwMTEN Cj4gPj4gwqAgwqAgwqAgwqBNYWlsYm94OiDCoCDCoGptcG9sa0BjaXNjby5jb20sDQo+ID4+IMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYnJAYnJpYW5yb3Nlbi5uZXQsDQo+ID4+IMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgam9uLnBldGVyc29uQG5ldXN0YXIuYml6DQo+ID4+IMKg IMKgIMKgIMKgUGFnZXM6IMKgIMKgIMKgMzUNCj4gPj4gwqAgwqAgwqAgwqBDaGFyYWN0ZXJzOiA4 MDc5NQ0KPiA+PiDCoCDCoCDCoCDCoFVwZGF0ZXMvT2Jzb2xldGVzL1NlZUFsc286IMKgIE5vbmUN Cj4gPj4NCj4gPj4gwqAgwqAgwqAgwqBJLUQgVGFnOiDCoCDCoGRyYWZ0LWlldGYtc2lwY29yZS1s b2NhdGlvbi1jb252ZXlhbmNlLTA5LnR4dA0KPiA+Pg0KPiA+PiDCoCDCoCDCoCDCoFVSTDogwqAg wqAgwqAgwqBodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM2NDQyLnR4dA0KPiA+Pg0K PiA+PiBUaGlzIGRvY3VtZW50IGRlZmluZXMgYW4gZXh0ZW5zaW9uIHRvIHRoZSBTZXNzaW9uIElu aXRpYXRpb24NCj4gPj4gUHJvdG9jb2wgKFNJUCkgdG8gY29udmV5IGdlb2dyYXBoaWMgbG9jYXRp b24gaW5mb3JtYXRpb24gZnJvbSBvbmUNCj4gPj4gU0lQIGVudGl0eSB0byBhbm90aGVyIFNJUCBl bnRpdHkuIMKgVGhlIFNJUCBleHRlbnNpb24gY292ZXJzDQo+ID4+IGVuZC10by1lbmQgY29udmV5 YW5jZSBhcyB3ZWxsIGFzIGxvY2F0aW9uLWJhc2VkIHJvdXRpbmcsIHdoZXJlIFNJUA0KPiA+PiBp bnRlcm1lZGlhcmllcyBtYWtlIHJvdXRpbmcgZGVjaXNpb25zIGJhc2VkIHVwb24gdGhlIGxvY2F0 aW9uIG9mIHRoZQ0KPiA+PiBMb2NhdGlvbiBUYXJnZXQuIMKgW1NUQU5EQVJEUy1UUkFDS10NCj4g Pj4NCj4gPj4gVGhpcyBkb2N1bWVudCBpcyBhIHByb2R1Y3Qgb2YgdGhlIFNlc3Npb24gSW5pdGlh dGlvbiBQcm90b2NvbCBDb3JlDQo+IFdvcmtpbmcNCj4gPj4gR3JvdXAgb2YgdGhlIElFVEYuDQo+ ID4+DQo+ID4+IFRoaXMgaXMgbm93IGEgUHJvcG9zZWQgU3RhbmRhcmQgUHJvdG9jb2wuDQo+ID4+ DQo+ID4+IFNUQU5EQVJEUyBUUkFDSzogVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYW4gSW50ZXJu ZXQgc3RhbmRhcmRzIHRyYWNrDQo+ID4+IHByb3RvY29sIGZvciB0aGUgSW50ZXJuZXQgY29tbXVu aXR5LGFuZCByZXF1ZXN0cyBkaXNjdXNzaW9uIGFuZA0KPiA+PiBzdWdnZXN0aW9ucw0KPiA+PiBm b3IgaW1wcm92ZW1lbnRzLiDCoFBsZWFzZSByZWZlciB0byB0aGUgY3VycmVudCBlZGl0aW9uIG9m IHRoZQ0KPiBJbnRlcm5ldA0KPiA+PiBPZmZpY2lhbCBQcm90b2NvbCBTdGFuZGFyZHMgKFNURCAx KSBmb3IgdGhlIHN0YW5kYXJkaXphdGlvbiBzdGF0ZQ0KPiBhbmQNCj4gPj4gc3RhdHVzIG9mIHRo aXMgcHJvdG9jb2wuIMKgRGlzdHJpYnV0aW9uIG9mIHRoaXMgbWVtbyBpcyB1bmxpbWl0ZWQuDQo+ ID4+DQo+ID4+IFRoaXMgYW5ub3VuY2VtZW50IGlzIHNlbnQgdG8gdGhlIElFVEYtQW5ub3VuY2Ug YW5kIHJmYy1kaXN0IGxpc3RzLg0KPiA+PiBUbyBzdWJzY3JpYmUgb3IgdW5zdWJzY3JpYmUsIHNl ZQ0KPiA+PiDCoGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZXRmLWFubm91 bmNlDQo+ID4+IMKgaHR0cDovL21haWxtYW4ucmZjLWVkaXRvci5vcmcvbWFpbG1hbi9saXN0aW5m by9yZmMtZGlzdA0KPiA+Pg0KPiA+PiBGb3Igc2VhcmNoaW5nIHRoZSBSRkMgc2VyaWVzLCBzZWUN Cj4gPj4gaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZmNzZWFyY2guaHRtbC4NCj4gPj4gRm9y IGRvd25sb2FkaW5nIFJGQ3MsIHNlZSBodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy5odG1s Lg0KPiA+Pg0KPiA+PiBSZXF1ZXN0cyBmb3Igc3BlY2lhbCBkaXN0cmlidXRpb24gc2hvdWxkIGJl IGFkZHJlc3NlZCB0byBlaXRoZXIgdGhlDQo+ID4+IGF1dGhvciBvZiB0aGUgUkZDIGluIHF1ZXN0 aW9uLCBvciB0byByZmMtZWRpdG9yQHJmYy0NCj4gZWRpdG9yLm9yZy4gwqBVbmxlc3MNCj4gPj4g c3BlY2lmaWNhbGx5IG5vdGVkIG90aGVyd2lzZSBvbiB0aGUgUkZDIGl0c2VsZiwgYWxsIFJGQ3Mg YXJlIGZvcg0KPiA+PiB1bmxpbWl0ZWQgZGlzdHJpYnV0aW9uLg0KPiA+Pg0KPiA+Pg0KPiA+PiBU aGUgUkZDIEVkaXRvciBUZWFtDQo+ID4+IEFzc29jaWF0aW9uIE1hbmFnZW1lbnQgU29sdXRpb25z LCBMTEMNCj4gPj4NCj4gPj4NCj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPj4gSUVURi1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCj4gPj4gSUVU Ri1Bbm5vdW5jZUBpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2lldGYtYW5ub3VuY2UNCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPiA+ IHNpcGNvcmVAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NpcGNvcmUNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4gc2lwY29yZUBpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2lwY29yZSBtYWlsaW5nIGxp c3QNCj4gc2lwY29yZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NpcGNvcmUNCg== From ibc@aliax.net Mon Dec 5 00:32:15 2011 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 C7E5121F8A71 for ; Mon, 5 Dec 2011 00:32:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.077 X-Spam-Level: X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_24=0.6, MIME_8BIT_HEADER=0.3, 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 hr3rYkf0rKEn for ; Mon, 5 Dec 2011 00:32:15 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA7021F8A6F for ; Mon, 5 Dec 2011 00:32:14 -0800 (PST) Received: by vbbez10 with SMTP id ez10so1242128vbb.31 for ; Mon, 05 Dec 2011 00:32:14 -0800 (PST) Received: by 10.52.33.239 with SMTP id u15mr4031891vdi.49.1323073934215; Mon, 05 Dec 2011 00:32:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.203.8 with HTTP; Mon, 5 Dec 2011 00:31:52 -0800 (PST) In-Reply-To: References: <5470070492D34F4EAC60E4ED91CB3841@gsmlaptop> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 5 Dec 2011 09:31:52 +0100 Message-ID: To: Gilad Shaham Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: =?UTF-8?B?Sm9zw6kgTHVpcyBNaWxsw6Fu?= , "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] New Version Notification for draft-ibc-sipcore-sip-websocket-00 (previously draft-ibc-rtcweb-sip-websocket-00) 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, 05 Dec 2011 08:32:15 -0000 2011/12/2 Gilad Shaham : >> Said that, what do you exactly miss (related to sips) in the draft? >> maybe an example flow? or perhaps a consideration that "in presence of >> a sips URI the WebSocket transport must be secure which means "wss" >> URI in the WebSocket connection"? >> > If using sips in the examples has a negative effect on clarity I understa= nd, > but it is a bcp and a recommendation, is it not? It should be clear that > implementors would not rely solely on 'wss' for end-to-end-encryption, bu= t > rather use sips URI for that purpose, especially since the draft does > recommend securing the traffic. In other words, I believe there should be= at > the very least text explaining that in the security considerations sectio= n. Ok, it makes sense. We will add a text under the Security section about the relationship between SIPS usage and WSS transport requirement. >> As explained in the draft, the JavaScript stack in WebSocket capable >> web browsers has no way to determine the source IP:port from which a >> WebSocket connection has been established, this is, the SIP UA running >> within a JavaScript application in a web does not know its local >> address. Therefore we've chosen 'anonymous.invalid' for Via >> sentby-host value and for Contact in the initial REGISTER (once the >> registration is done, the SIP UA would know its GRUU addresses). >> Regardless GRUU is implemented in the registrar, the usage of Outbound >> (RFC 5626) makes unnecessary for the SIP UA to know its local address. >> >> Of course, in case there is a hostname more appropriate than >> 'anonymous.invalid' then we could propose it. Is there? > > The string did reminded me of the privacy extensions, since it's used in = the > From header, but I was more concerned there is something unspecified. > Outbound still mandates a URI since the authoritative proxy will store th= at > value to form the target set and therefore it seems as if the UA should b= e > prepared to receive anonymous.invalid as target URI. Should that be the c= ase > or should the UA generate some kind of URI? It's just an example and it's > possible it's easy to explain how it works, but my point is that this see= ms > undefined. > > I agree that the URI should not be mandatory since it is due to javascrip= t > security limitations and it's certainly possible this transport would be > used outside the browser. If you are looking for alternative hostnames, > 'localhost' comes to mind, but I didn't really consider whether it's bett= er, > worse or equivalent. Yes, using localhost would be another option, but it has a drawback in case the WebSocket SIP UA does not use GRUU: in that case a remote peer would see "localhost" as the target of of WS UA. If it sends a REFER to a third participant containing "Refer-To: " then the third participant would try to open a WS connection to itself. Well, as the draft states, GRUU is required for SIP UA's using WebSocket transport, at least in web browsers. So I'm not sure wheter using "localhost" is better than using "anonymous.invalid". Maybe it is better to use "invalid.domain"? Thanks a lot. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Dec 5 00:37:57 2011 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 6738D21F8A91 for ; Mon, 5 Dec 2011 00:37:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 ZsJnKK27Qf3I for ; Mon, 5 Dec 2011 00:37:57 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id CB5D921F8A71 for ; Mon, 5 Dec 2011 00:37:56 -0800 (PST) Received: by vbbez10 with SMTP id ez10so1245285vbb.31 for ; Mon, 05 Dec 2011 00:37:56 -0800 (PST) Received: by 10.52.117.65 with SMTP id kc1mr4026868vdb.66.1323074276334; Mon, 05 Dec 2011 00:37:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.203.8 with HTTP; Mon, 5 Dec 2011 00:37:36 -0800 (PST) In-Reply-To: <4EDA7DDE.1030005@alum.mit.edu> References: <4EDA7DDE.1030005@alum.mit.edu> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 5 Dec 2011 09:37:36 +0100 Message-ID: To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: sipcore@ietf.org Subject: Re: [sipcore] New Version Notification for draft-ibc-sipcore-sip-websocket-00 (previously draft-ibc-rtcweb-sip-websocket-00) 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, 05 Dec 2011 08:37:57 -0000 2011/12/3 Paul Kyzivat : > Section 7: > > Since you are mostly trying to avoid interactions with sips, why is it th= at > you use SIPS+D2W to resolve wss URIs? That seems to imply some relationsh= ip > to sips that is not intended. Well, we didn't try to discourage the interaction with SIPS, we just tryed to avoid too much text about SIPS since, IMHO, it adds some complexity which is not very clear currently. But as said in other mail, we will add a text under the "Security" section describing the requirement of using secure WebSocket transport ("wss" schema in the WS URI) when SIPS is used. Regards. --=20 I=C3=B1aki Baz Castillo From gilad@voxisoft.com Mon Dec 5 01:36:18 2011 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 41A8321F8AE9 for ; Mon, 5 Dec 2011 01:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=-0.404, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, MIME_8BIT_HEADER=0.3, 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 NTZ9XysoNKWE for ; Mon, 5 Dec 2011 01:36:17 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 20F5421F8A67 for ; Mon, 5 Dec 2011 01:36:16 -0800 (PST) Received: by qcsf15 with SMTP id f15so1582908qcs.31 for ; Mon, 05 Dec 2011 01:36:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voxisoft.com; s=google; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=6WzV60SD4eC3hGMuaeWm0Fy/kD6IYCAXaZv2hwzrAWM=; b=WbRH9m5nPDEQAgCXvWpeurbCWJmgloUr+qL7M6xWnpT13hvl8N5mUlYPR5qjFiy4Jf ocG0GQ/uFTAEpQLRaiB9RyK7lW89rJzeyRAvRy7hMQohC9C+kBCtS5RaRgg7xFgC3AWI Bsyr0YJWyfeU3nKSXHFJOF4dxmqoK+aFv0n5U= Received: by 10.229.24.139 with SMTP id v11mr1773052qcb.175.1323077775215; Mon, 05 Dec 2011 01:36:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.159.198 with HTTP; Mon, 5 Dec 2011 01:35:54 -0800 (PST) X-Originating-IP: [109.64.26.1] In-Reply-To: References: <5470070492D34F4EAC60E4ED91CB3841@gsmlaptop> From: Gilad Shaham Date: Mon, 5 Dec 2011 11:35:54 +0200 Message-ID: To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=001636426537cd4e8004b3550cef Cc: =?ISO-8859-1?Q?Jos=E9_Luis_Mill=E1n?= , "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] New Version Notification for draft-ibc-sipcore-sip-websocket-00 (previously draft-ibc-rtcweb-sip-websocket-00) 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, 05 Dec 2011 09:36:18 -0000 --001636426537cd4e8004b3550cef Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Dec 5, 2011 at 10:31 AM, I=F1aki Baz Castillo wrote= : > 2011/12/2 Gilad Shaham : > >> Said that, what do you exactly miss (related to sips) in the draft? > >> maybe an example flow? or perhaps a consideration that "in presence of > >> a sips URI the WebSocket transport must be secure which means "wss" > >> URI in the WebSocket connection"? > >> > > If using sips in the examples has a negative effect on clarity I > understand, > > but it is a bcp and a recommendation, is it not? It should be clear tha= t > > implementors would not rely solely on 'wss' for end-to-end-encryption, > but > > rather use sips URI for that purpose, especially since the draft does > > recommend securing the traffic. In other words, I believe there should > be at > > the very least text explaining that in the security considerations > section. > > Ok, it makes sense. We will add a text under the Security section > about the relationship between SIPS usage and WSS transport > requirement. > > Great, then I'll look for it in the next draft. > > > > >> As explained in the draft, the JavaScript stack in WebSocket capable > >> web browsers has no way to determine the source IP:port from which a > >> WebSocket connection has been established, this is, the SIP UA running > >> within a JavaScript application in a web does not know its local > >> address. Therefore we've chosen 'anonymous.invalid' for Via > >> sentby-host value and for Contact in the initial REGISTER (once the > >> registration is done, the SIP UA would know its GRUU addresses). > >> Regardless GRUU is implemented in the registrar, the usage of Outbound > >> (RFC 5626) makes unnecessary for the SIP UA to know its local address. > >> > >> Of course, in case there is a hostname more appropriate than > >> 'anonymous.invalid' then we could propose it. Is there? > > > > The string did reminded me of the privacy extensions, since it's used i= n > the > > From header, but I was more concerned there is something unspecified. > > Outbound still mandates a URI since the authoritative proxy will store > that > > value to form the target set and therefore it seems as if the UA should > be > > prepared to receive anonymous.invalid as target URI. Should that be the > case > > or should the UA generate some kind of URI? It's just an example and it= 's > > possible it's easy to explain how it works, but my point is that this > seems > > undefined. > > > > I agree that the URI should not be mandatory since it is due to > javascript > > security limitations and it's certainly possible this transport would b= e > > used outside the browser. If you are looking for alternative hostnames, > > 'localhost' comes to mind, but I didn't really consider whether it's > better, > > worse or equivalent. > > Yes, using localhost would be another option, but it has a drawback in > case the WebSocket SIP UA does not use GRUU: in that case a remote > peer would see "localhost" as the target of of WS UA. If it sends a > REFER to a third participant containing "Refer-To: > " then the third participant would > try to open a WS connection to itself. Well, as the draft states, GRUU > is required for SIP UA's using WebSocket transport, at least in web > browsers. > > So I'm not sure wheter using "localhost" is better than using > "anonymous.invalid". Maybe it is better to use "invalid.domain"? > > So, if we were to have normative text that defines this, it would probabl= y explain why localhost or any routable domain name is a bad choice as opposed to a non-routable domain. Should a UA be free to choose based on a set of rules or are we defining one host part for all? Should it generate parts or all of this domain dynamically to assist with matching incoming requests? Is one free to use an invalid IP (such as the infamous 0.0.0.0)? And most importantly, do others believe this requires normative text or not= ? Thanks, Gilad --001636426537cd4e8004b3550cef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon, Dec 5, 2011 at = 10:31 AM, I=F1aki Baz Castillo <ibc@aliax.net> wrote:
2011/12/2 Gilad Shaham <gilad@voxi= soft.com>:
>> Said that, what do you exactly miss (related to = sips) in the draft?
>> maybe an example flow? or perhaps a consideration that "in pr= esence of
>> a sips URI the WebSocket transport must be secure which means &quo= t;wss"
>> URI in the WebSocket connection"?
>>
> If using sips in the examples has a negative effect on clarity I under= stand,
> but it is a bcp and a recommendation, is it not? It should be clear th= at
> implementors would not rely solely on 'wss' for end-to-end-enc= ryption, but
> rather use sips URI for that purpose, especially since the draft does<= br> > recommend securing the traffic. In other words, I believe there should= be at
> the very least text explaining that in the security considerations sec= tion.

Ok, it makes sense. We will add a text under the Security section
about the relationship between SIPS usage and WSS transport
requirement.

Great, then I'll look for= it in the next draft.



>> As explained in the draft, the JavaScript stack in WebSocket capab= le
>> web browsers has no way to determine the source IP:port from which= a
>> WebSocket connection has been established, this is, the SIP UA run= ning
>> within a JavaScript application in a web does not know its local >> address. Therefore we've chosen 'anonymous.invalid' fo= r Via
>> sentby-host value and for Contact in the initial REGISTER (once th= e
>> registration is done, the SIP UA would know its GRUU addresses). >> Regardless GRUU is implemented in the registrar, the usage of Outb= ound
>> (RFC 5626) makes unnecessary for the SIP UA to know its local addr= ess.
>>
>> Of course, in case there is a hostname more appropriate than
>> 'anonymous.invalid' then we could propose it. Is there? >
> The string did reminded me of the privacy extensions, since it's u= sed in the
> From header, but I was more concerned there is something unspecified.<= br> > Outbound still mandates a URI since the authoritative proxy will store= that
> value to form the target set and therefore it seems as if the UA shoul= d be
> prepared to receive anonymous.invalid as target URI. Should that be th= e case
> or should the UA generate some kind of URI? It's just an example a= nd it's
> possible it's easy to explain how it works, but my point is that t= his seems
> undefined.
>
> I agree that the URI should not be mandatory since it is due to javasc= ript
> security limitations and it's certainly possible this transport wo= uld be
> used outside the browser. If you are looking for alternative hostnames= ,
> 'localhost' comes to mind, but I didn't really consider wh= ether it's better,
> worse or equivalent.

Yes, using localhost would be another option, but it has a drawback i= n
case the WebSocket SIP UA does not use GRUU: in that case a remote
peer would see "localhost" as the target of of WS UA. If it sends= a
REFER to a third participant containing "Refer-To:
<sip:alice@localhost;transport=3Dws>" then the third participant= would
try to open a WS connection to itself. Well, as the draft states, GRUU
is required for SIP UA's using WebSocket transport, at least in web
browsers.

So I'm not sure wheter using "localhost" is better than using=
"anonymous.invalid". Maybe it is better to use "invalid.doma= in"?

So, if we were to have normative text that defines th= is, it would probably explain why localhost or any routable domain name is = a bad choice as opposed to a non-routable domain. Should a UA be free to ch= oose based on a set of rules or are we defining one host part for all? Shou= ld it generate parts or all of this domain dynamically to assist with match= ing incoming requests? Is one free to use an invalid IP (such as the infamo= us 0.0.0.0)?

And most importantly, do others believe this requires normative text or= not?

Thanks,
Gilad
--001636426537cd4e8004b3550cef-- From ibc@aliax.net Mon Dec 5 01:51:42 2011 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 684F221F8B1F for ; Mon, 5 Dec 2011 01:51:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 DdwzuOaOWEjH for ; Mon, 5 Dec 2011 01:51:41 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B33A421F8B1D for ; Mon, 5 Dec 2011 01:51:41 -0800 (PST) Received: by vbbez10 with SMTP id ez10so1291126vbb.31 for ; Mon, 05 Dec 2011 01:51:41 -0800 (PST) Received: by 10.52.33.239 with SMTP id u15mr4136385vdi.49.1323078701196; Mon, 05 Dec 2011 01:51:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.203.8 with HTTP; Mon, 5 Dec 2011 01:51:19 -0800 (PST) In-Reply-To: References: <5470070492D34F4EAC60E4ED91CB3841@gsmlaptop> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 5 Dec 2011 10:51:19 +0100 Message-ID: To: Gilad Shaham Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: =?UTF-8?B?Sm9zw6kgTHVpcyBNaWxsw6Fu?= , "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] New Version Notification for draft-ibc-sipcore-sip-websocket-00 (previously draft-ibc-rtcweb-sip-websocket-00) 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, 05 Dec 2011 09:51:42 -0000 2011/12/5 Gilad Shaham : >> Yes, using localhost would be another option, but it has a drawback in >> case the WebSocket SIP UA does not use GRUU: in that case a remote >> peer would see "localhost" as the target of of WS UA. If it sends a >> REFER to a third participant containing "Refer-To: >> " then the third participant would >> try to open a WS connection to itself. Well, as the draft states, GRUU >> is required for SIP UA's using WebSocket transport, at least in web >> browsers. >> >> So I'm not sure wheter using "localhost" is better than using >> "anonymous.invalid". Maybe it is better to use "invalid.domain"? >> > So, if we were to have normative text that defines this, it would probabl= y > explain why localhost or any routable domain name is a bad choice as oppo= sed > to a non-routable domain. Should a UA be free to choose based on a set of > rules or are we defining one host part for all? Should it generate parts = or > all of this domain dynamically to assist with matching incoming requests?= Is > one free to use an invalid IP (such as the infamous 0.0.0.0)? Take into account that when a JavaScript code (running in a web browser) open a WebSocket connection given a WS URI with domain, the JavaScript code is not aware of the resulting IP nor the IP family (IPv4 or IPv6). So IMHO using a IP address in Via/Contact is a bad idea. Assuming that a domain is used, I think that which one to set should not be normative, for the following reasons: 1) If Outbound is being used (and it's a MUST for these kind of SIP endpoints) the host in Via and Contact does not matter (for registration or dialogs). 2) If GRUU is used, the host in Contact would be a globally routable URI. If GRUU is not used, then there is no way at all for SIP REFER mechanism to work (since a SIP WebSocket client can only be contacted via the WS connection it has opened with the WS server). So the domain in Contact does not matter (with GRUU it will always work, without GRUU it will never work). > And most importantly, do others believe this requires normative text or n= ot? I consider that this should be an informative text, maybe by suggesting the usage of "invalid.domain" or "any non routable domain". Regards. --=20 I=C3=B1aki Baz Castillo From kpfleming@digium.com Mon Dec 5 05:34:21 2011 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 21D1021F8BA8 for ; Mon, 5 Dec 2011 05:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 tgwSbzHaZINB for ; Mon, 5 Dec 2011 05:34:20 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6363A21F8B94 for ; Mon, 5 Dec 2011 05:34:20 -0800 (PST) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1RXYgU-0006U3-QT for sipcore@ietf.org; Mon, 05 Dec 2011 07:34:18 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id C5073D8005 for ; Mon, 5 Dec 2011 07:34:18 -0600 (CST) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6egpwWOrwlqS for ; Mon, 5 Dec 2011 07:34:18 -0600 (CST) Received: from [192.168.1.5] (173-18-150-64.client.mchsi.com [173.18.150.64]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 1924AD8002 for ; Mon, 5 Dec 2011 07:34:18 -0600 (CST) Message-ID: <4EDCC858.8000607@digium.com> Date: Mon, 05 Dec 2011 07:34:16 -0600 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <5470070492D34F4EAC60E4ED91CB3841@gsmlaptop> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [sipcore] New Version Notification for draft-ibc-sipcore-sip-websocket-00 (previously draft-ibc-rtcweb-sip-websocket-00) 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, 05 Dec 2011 13:34:21 -0000 On 12/05/2011 03:51 AM, I=F1aki Baz Castillo wrote: > 2011/12/5 Gilad Shaham: >>> Yes, using localhost would be another option, but it has a drawback i= n >>> case the WebSocket SIP UA does not use GRUU: in that case a remote >>> peer would see "localhost" as the target of of WS UA. If it sends a >>> REFER to a third participant containing "Refer-To: >>> " then the third participant woul= d >>> try to open a WS connection to itself. Well, as the draft states, GRU= U >>> is required for SIP UA's using WebSocket transport, at least in web >>> browsers. >>> >>> So I'm not sure wheter using "localhost" is better than using >>> "anonymous.invalid". Maybe it is better to use "invalid.domain"? >>> >> So, if we were to have normative text that defines this, it would prob= ably >> explain why localhost or any routable domain name is a bad choice as o= pposed >> to a non-routable domain. Should a UA be free to choose based on a set= of >> rules or are we defining one host part for all? Should it generate par= ts or >> all of this domain dynamically to assist with matching incoming reques= ts? Is >> one free to use an invalid IP (such as the infamous 0.0.0.0)? > > Take into account that when a JavaScript code (running in a web > browser) open a WebSocket connection given a WS URI with domain, the > JavaScript code is not aware of the resulting IP nor the IP family > (IPv4 or IPv6). So IMHO using a IP address in Via/Contact is a bad > idea. > > Assuming that a domain is used, I think that which one to set should > not be normative, for the following reasons: > > 1) If Outbound is being used (and it's a MUST for these kind of SIP > endpoints) the host in Via and Contact does not matter (for > registration or dialogs). > > 2) If GRUU is used, the host in Contact would be a globally routable > URI. If GRUU is not used, then there is no way at all for SIP REFER > mechanism to work (since a SIP WebSocket client can only be contacted > via the WS connection it has opened with the WS server). So the domain > in Contact does not matter (with GRUU it will always work, without > GRUU it will never work). > > >> And most importantly, do others believe this requires normative text o= r not? > > I consider that this should be an informative text, maybe by > suggesting the usage of "invalid.domain" or "any non routable domain". "invalid.domain" is not a guaranteed-to-be-unassigned domain;=20 "domain.invalid" is. There is an RFC defining such 'invalid' and=20 'example' domain names: RFC2606/BCP32. It would probably be best if your draft included the logic you've=20 written above as the rationale for the use of a purposefully-invalid=20 domain name, and then included a reference to RFC2606 so that readers=20 will know why "domain.invalid" is in fact invalid. --=20 Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpflemin= g 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From ibc@aliax.net Mon Dec 5 05:37:52 2011 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 5C43221F8BAA for ; Mon, 5 Dec 2011 05:37:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 jCBLrSRT7-jk for ; Mon, 5 Dec 2011 05:37:52 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D98E921F8B94 for ; Mon, 5 Dec 2011 05:37:51 -0800 (PST) Received: by vbbez10 with SMTP id ez10so1467471vbb.31 for ; Mon, 05 Dec 2011 05:37:51 -0800 (PST) Received: by 10.52.117.65 with SMTP id kc1mr4579933vdb.66.1323092271239; Mon, 05 Dec 2011 05:37:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.203.8 with HTTP; Mon, 5 Dec 2011 05:37:30 -0800 (PST) In-Reply-To: <4EDCC858.8000607@digium.com> References: <5470070492D34F4EAC60E4ED91CB3841@gsmlaptop> <4EDCC858.8000607@digium.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 5 Dec 2011 14:37:30 +0100 Message-ID: To: "Kevin P. Fleming" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: sipcore@ietf.org Subject: Re: [sipcore] New Version Notification for draft-ibc-sipcore-sip-websocket-00 (previously draft-ibc-rtcweb-sip-websocket-00) 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, 05 Dec 2011 13:37:52 -0000 2011/12/5 Kevin P. Fleming : > "invalid.domain" is not a guaranteed-to-be-unassigned domain; > "domain.invalid" is. There is an RFC defining such 'invalid' and 'example= ' > domain names: RFC2606/BCP32. > > It would probably be best if your draft included the logic you've written > above as the rationale for the use of a purposefully-invalid domain name, > and then included a reference to RFC2606 so that readers will know why > "domain.invalid" is in fact invalid. Great, it will be added in a new revision. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From gilad@voxisoft.com Mon Dec 5 06:17:12 2011 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 1D97621F8B6B for ; Mon, 5 Dec 2011 06:17:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.679 X-Spam-Level: X-Spam-Status: No, score=-2.679 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 uiO-WqAZmjlf for ; Mon, 5 Dec 2011 06:17:11 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id C6F6621F8BD8 for ; Mon, 5 Dec 2011 06:17:10 -0800 (PST) Received: by qcsf15 with SMTP id f15so1754122qcs.31 for ; Mon, 05 Dec 2011 06:17:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voxisoft.com; s=google; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=exkWIJL3mSnR+naCf70uScV61VEn91AvzN9XLSZvS90=; b=YRAp3QhBEDK5aYDil8crWKUzn/7LfVHomHARWvPrTJ+mzCqmaVBwfm02X8/v2aTq90 NNvwGjNbRvsqyHuEStRvCSQXXLVldk+32sa35rYiU5+SDcchWiB/7jwcQbOF3EDeIQ3V cdQXA5yhDDE+q10EkPDU1v/Ca9tHnMZeGnRpg= Received: by 10.229.65.150 with SMTP id j22mr1979197qci.289.1323094630262; Mon, 05 Dec 2011 06:17:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.159.198 with HTTP; Mon, 5 Dec 2011 06:16:49 -0800 (PST) X-Originating-IP: [109.64.26.1] In-Reply-To: References: <5470070492D34F4EAC60E4ED91CB3841@gsmlaptop> From: Gilad Shaham Date: Mon, 5 Dec 2011 16:16:49 +0200 Message-ID: To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=0016e65dabb470e89204b358f9ce Cc: =?ISO-8859-1?Q?Jos=E9_Luis_Mill=E1n?= , "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] New Version Notification for draft-ibc-sipcore-sip-websocket-00 (previously draft-ibc-rtcweb-sip-websocket-00) 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, 05 Dec 2011 14:17:12 -0000 --0016e65dabb470e89204b358f9ce Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Dec 5, 2011 at 11:51 AM, I=F1aki Baz Castillo wrote= : > 2011/12/5 Gilad Shaham : > >> Yes, using localhost would be another option, but it has a drawback in > >> case the WebSocket SIP UA does not use GRUU: in that case a remote > >> peer would see "localhost" as the target of of WS UA. If it sends a > >> REFER to a third participant containing "Refer-To: > >> " then the third participant would > >> try to open a WS connection to itself. Well, as the draft states, GRUU > >> is required for SIP UA's using WebSocket transport, at least in web > >> browsers. > >> > >> So I'm not sure wheter using "localhost" is better than using > >> "anonymous.invalid". Maybe it is better to use "invalid.domain"? > >> > > So, if we were to have normative text that defines this, it would > probably > > explain why localhost or any routable domain name is a bad choice as > opposed > > to a non-routable domain. Should a UA be free to choose based on a set = of > > rules or are we defining one host part for all? Should it generate part= s > or > > all of this domain dynamically to assist with matching incoming > requests? Is > > one free to use an invalid IP (such as the infamous 0.0.0.0)? > > Take into account that when a JavaScript code (running in a web > browser) open a WebSocket connection given a WS URI with domain, the > JavaScript code is not aware of the resulting IP nor the IP family > (IPv4 or IPv6). So IMHO using a IP address in Via/Contact is a bad > idea. > I agree the later messages should not try to resolve an IP address, but I still don't see why it's that much different to have an invalid IP rather than an invalid domain. The advantage of an IP is that you are sure no one would try to resolve it, although it's true you would have no idea whether to place IPv4 or IPv6 in there and you'd just have to choose one of them. So it's not that I think one is better than the other, but some may ask for this option from compatibility point of view - I assume some implementations were never built with domain name in Contact header or in Via header in mind, although this is perfectly legitimate to do so. Anyway, if you strongly object to IP, domain is good too. > > Assuming that a domain is used, I think that which one to set should > not be normative, for the following reasons: > > 1) If Outbound is being used (and it's a MUST for these kind of SIP > endpoints) the host in Via and Contact does not matter (for > registration or dialogs). > > 2) If GRUU is used, the host in Contact would be a globally routable > URI. If GRUU is not used, then there is no way at all for SIP REFER > mechanism to work (since a SIP WebSocket client can only be contacted > via the WS connection it has opened with the WS server). So the domain > in Contact does not matter (with GRUU it will always work, without > GRUU it will never work). > > > Seems right. So we are saying a UA MAY include an invalid host part in th= e registration Contact header and any request top Via header. The UA MUST support Outbound and SHOULD (or MUST) support GRUU. Actually, there is good reason to consider mandating GRUU for this scenario. The reason is that suppose 2 different users named Alice register to 2 different AORs. Both Alice users go through the same proxy (named P1) that supports websockets and it forwards the requests to the different registrars. When an incoming request to one of the Alices comes in, a proxy will forward the request to alice@ through P1, but P1 cannot distinguish the two and they are in fact different users. I also believe UAs should be encouraged to compare the instance id of incoming requests. --0016e65dabb470e89204b358f9ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon, Dec 5, 2011 at = 11:51 AM, I=F1aki Baz Castillo <ibc@aliax.net> wrote:
2011/12/5 Gilad Shaham <gilad@voxi= soft.com>:
>> Yes, using localhost would be another option, bu= t it has a drawback in
>> case the WebSocket SIP UA does not use GRUU: in that case a remote=
>> peer would see "localhost" as the target of of WS UA. If= it sends a
>> REFER to a third participant containing "Refer-To:
>> <sip:alice@localhost;transport=3Dws>" then the third pa= rticipant would
>> try to open a WS connection to itself. Well, as the draft states, = GRUU
>> is required for SIP UA's using WebSocket transport, at least i= n web
>> browsers.
>>
>> So I'm not sure wheter using "localhost" is better t= han using
>> "anonymous.invalid". Maybe it is better to use "inv= alid.domain"?
>>
> So, if we were to have normative text that defines this, it would prob= ably
> explain why localhost or any routable domain name is a bad choice as o= pposed
> to a non-routable domain. Should a UA be free to choose based on a set= of
> rules or are we defining one host part for all? Should it generate par= ts or
> all of this domain dynamically to assist with matching incoming reques= ts? Is
> one free to use an invalid IP (such as the infamous 0.0.0.0)?

Take into account that when a JavaScript code (running in a web
browser) open a WebSocket connection given a WS URI with domain, the
JavaScript code is not aware of the resulting IP nor the IP family
(IPv4 or IPv6). So IMHO using a IP address in Via/Contact is a bad
idea.
I agree the later messages should not try to res= olve an IP address, but I still don't see why it's that much differ= ent to have an invalid IP rather than an invalid domain. The advantage of a= n IP is that you are sure no one would try to resolve it, although it's= true you would have no idea whether to place IPv4 or IPv6 in there and you= 'd just have to choose one of them. So it's not that I think one is= better than the other, but some may ask for this option from compatibility= point of view - I assume some implementations were never built with domain= name in Contact header or in Via header in mind, although this is perfectl= y legitimate to do so. Anyway, if you strongly object to IP, domain is good= too.

Assuming that a domain is used, I think that which one to set should
not be normative, for the following reasons:

1) If Outbound is being used (and it's a MUST for these kind of SIP
endpoints) the host in Via and Contact does not matter (for
registration or dialogs).

2) If GRUU is used, the host in Contact would be a globally routable
URI. If GRUU is not used, then there is no way =A0at all for SIP REFER
mechanism to work (since a SIP WebSocket client can only be contacted
via the WS connection it has opened with the WS server). So the domain
in Contact does not matter (with GRUU it will always work, without
GRUU it will never work).


Seems right. So we are saying a UA MAY include = an invalid host part in the registration Contact header and any request top= Via header. The UA MUST support Outbound and SHOULD (or MUST) support GRUU= .
Actually, there is good reason to consider mandating GRUU for this scenario= . The reason is that suppose 2 different users named Alice register to 2 di= fferent AORs. Both Alice users go through the same proxy (named P1) that su= pports websockets and it forwards the requests to the different registrars.= When an incoming request to one of the Alices comes in, a proxy will forwa= rd the request to alice@<invalid host> through P1, but P1 cannot dist= inguish the two and they are in fact different users. I also believe UAs sh= ould be encouraged to compare the instance id of incoming requests.

--0016e65dabb470e89204b358f9ce-- From ibc@aliax.net Mon Dec 5 06:27:52 2011 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 D216521F8BD8 for ; Mon, 5 Dec 2011 06:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 6Bo303w+9RoW for ; Mon, 5 Dec 2011 06:27:52 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2A62421F8BBA for ; Mon, 5 Dec 2011 06:27:51 -0800 (PST) Received: by vbbez10 with SMTP id ez10so1515808vbb.31 for ; Mon, 05 Dec 2011 06:27:51 -0800 (PST) Received: by 10.52.88.5 with SMTP id bc5mr4771140vdb.15.1323095271269; Mon, 05 Dec 2011 06:27:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.203.8 with HTTP; Mon, 5 Dec 2011 06:27:30 -0800 (PST) In-Reply-To: References: <5470070492D34F4EAC60E4ED91CB3841@gsmlaptop> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 5 Dec 2011 15:27:30 +0100 Message-ID: To: Gilad Shaham Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: =?UTF-8?B?Sm9zw6kgTHVpcyBNaWxsw6Fu?= , "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] New Version Notification for draft-ibc-sipcore-sip-websocket-00 (previously draft-ibc-rtcweb-sip-websocket-00) 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, 05 Dec 2011 14:27:52 -0000 2011/12/5 Gilad Shaham : >> Take into account that when a JavaScript code (running in a web >> browser) open a WebSocket connection given a WS URI with domain, the >> JavaScript code is not aware of the resulting IP nor the IP family >> (IPv4 or IPv6). So IMHO using a IP address in Via/Contact is a bad >> idea. > > I agree the later messages should not try to resolve an IP address, but I > still don't see why it's that much different to have an invalid IP rather > than an invalid domain. The advantage of an IP is that you are sure no on= e > would try to resolve it, although it's true you would have no idea whethe= r > to place IPv4 or IPv6 in there and you'd just have to choose one of them.= So > it's not that I think one is better than the other, but some may ask for > this option from compatibility point of view - I assume some implementati= ons > were never built with domain name in Contact header or in Via header in > mind, although this is perfectly legitimate to do so. Anyway, if you > strongly object to IP, domain is good too. Hi, I strongly expect that any SIP implementation must accept a hostname in the Via sentby-host, if not the problem is not here :) And about a hostname in the Contact URI, GRUU already does it so if we enforce GRUU we do require that remote peers must allow a Contact URI with hostname. If not, the problem is not here again :) IMHO "domain.invalid" is the best choice, as it is an "standard" unresolvable domain according to RFC 2606 section 2: ".invalid" is intended for use in online construction of domain names that are sure to be invalid and which it is obvious at a glance are invalid. >> Assuming that a domain is used, I think that which one to set should >> not be normative, for the following reasons: >> >> 1) If Outbound is being used (and it's a MUST for these kind of SIP >> endpoints) the host in Via and Contact does not matter (for >> registration or dialogs). >> >> 2) If GRUU is used, the host in Contact would be a globally routable >> URI. If GRUU is not used, then there is no way =C2=A0at all for SIP REFE= R >> mechanism to work (since a SIP WebSocket client can only be contacted >> via the WS connection it has opened with the WS server). So the domain >> in Contact does not matter (with GRUU it will always work, without >> GRUU it will never work). >> >> > Seems right. So we are saying a UA MAY include an invalid host part in th= e > registration Contact header and any request top Via header. The UA MUST > support Outbound and SHOULD (or MUST) support GRUU. > Actually, there is good reason to consider mandating GRUU for this scenar= io. > The reason is that suppose 2 different users named Alice register to 2 > different AORs. Both Alice users go through the same proxy (named P1) tha= t > supports websockets and it forwards the requests to the different > registrars. When an incoming request to one of the Alices comes in, a pro= xy > will forward the request to alice@ through P1, but P1 canno= t > distinguish the two and they are in fact different users. I also believe = UAs > should be encouraged to compare the instance id of incoming requests. In the scenario you describe Outbound must take place (the registrar can only send incoming requests to the users via their outbound SIP EDGE proxy implementing WebSocket transport). So the Path header the EDGE proxy adds to the REGISTER includes a flow token (RFC 5626), probably in the URI username part. When the registrar routes an incoming request to a registration binding of one of those WS clients, such request will contain a Route header with same value as the Path header during registration, and the EDGE proxy will associate the flow token in such Route URI to the corresponding WebSocket connection. This is, the Outbound EDGE proxy does not inspect the request URI for incoming requets, but just the Route URI and the Outbound flow token in it. --=20 I=C3=B1aki Baz Castillo From gilad@voxisoft.com Mon Dec 5 06:38:32 2011 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 175C621F8ADC for ; Mon, 5 Dec 2011 06:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.678 X-Spam-Level: X-Spam-Status: No, score=-2.678 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 1Hr66ghqVoLP for ; Mon, 5 Dec 2011 06:38:31 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0310A21F8AD3 for ; Mon, 5 Dec 2011 06:38:30 -0800 (PST) Received: by qadb15 with SMTP id b15so1859973qad.10 for ; Mon, 05 Dec 2011 06:38:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voxisoft.com; s=google; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Ume7mqmPaIfKWeXkgkOOj01hz5a7lZTldbMUqESasJ4=; b=J0l+DSwmVpddd3bgAnMK2tubYTcoy2yYL7oLpLYfH4uLkCl47ieQxpA5c83V4nByfE Id8JMpZ0G1NqK8YT81nom9xXvrBFvNvRo1u9yfiNDNgKpipW0IrDD1fT3goxRB/pzS1l NbLm38o7gq9lORW+sOq2KW4hpHyWAqXuzBQTA= Received: by 10.224.185.199 with SMTP id cp7mr7970088qab.68.1323095909132; Mon, 05 Dec 2011 06:38:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.159.198 with HTTP; Mon, 5 Dec 2011 06:38:08 -0800 (PST) X-Originating-IP: [109.64.26.1] In-Reply-To: References: <5470070492D34F4EAC60E4ED91CB3841@gsmlaptop> From: Gilad Shaham Date: Mon, 5 Dec 2011 16:38:08 +0200 Message-ID: To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=485b397dd547aaea2904b3594531 Cc: =?ISO-8859-1?Q?Jos=E9_Luis_Mill=E1n?= , "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] New Version Notification for draft-ibc-sipcore-sip-websocket-00 (previously draft-ibc-rtcweb-sip-websocket-00) 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, 05 Dec 2011 14:38:32 -0000 --485b397dd547aaea2904b3594531 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Dec 5, 2011 at 4:27 PM, I=F1aki Baz Castillo wrote: > 2011/12/5 Gilad Shaham : > >> Assuming that a domain is used, I think that which one to set should > >> not be normative, for the following reasons: > >> > >> 1) If Outbound is being used (and it's a MUST for these kind of SIP > >> endpoints) the host in Via and Contact does not matter (for > >> registration or dialogs). > >> > >> 2) If GRUU is used, the host in Contact would be a globally routable > >> URI. If GRUU is not used, then there is no way at all for SIP REFER > >> mechanism to work (since a SIP WebSocket client can only be contacted > >> via the WS connection it has opened with the WS server). So the domain > >> in Contact does not matter (with GRUU it will always work, without > >> GRUU it will never work). > >> > >> > > Seems right. So we are saying a UA MAY include an invalid host part in > the > > registration Contact header and any request top Via header. The UA MUST > > support Outbound and SHOULD (or MUST) support GRUU. > > Actually, there is good reason to consider mandating GRUU for this > scenario. > > The reason is that suppose 2 different users named Alice register to 2 > > different AORs. Both Alice users go through the same proxy (named P1) > that > > supports websockets and it forwards the requests to the different > > registrars. When an incoming request to one of the Alices comes in, a > proxy > > will forward the request to alice@ through P1, but P1 > cannot > > distinguish the two and they are in fact different users. I also believ= e > UAs > > should be encouraged to compare the instance id of incoming requests. > > In the scenario you describe Outbound must take place (the registrar > can only send incoming requests to the users via their outbound SIP > EDGE proxy implementing WebSocket transport). So the Path header the > EDGE proxy adds to the REGISTER includes a flow token (RFC 5626), > probably in the URI username part. > > When the registrar routes an incoming request to a registration > binding of one of those WS clients, such request will contain a Route > header with same value as the Path header during registration, and the > EDGE proxy will associate the flow token in such Route URI to the > corresponding WebSocket connection. This is, the Outbound EDGE proxy > does not inspect the request URI for incoming requets, but just the > Route URI and the Outbound flow token in it. > > Right, I ignored that path is there, so it also seems correct that GRUU i= s a SHOULD --485b397dd547aaea2904b3594531 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon, Dec 5, 2011 at = 4:27 PM, I=F1aki Baz Castillo <ibc@aliax.net> wrote:
2011/12/5 Gilad Shaham <gilad@voxi= soft.com>:
>> Assuming that a domain is used, I think that which one to set shou= ld
>> not be normative, for the following reasons:
>>
>> 1) If Outbound is being used (and it's a MUST for these kind o= f SIP
>> endpoints) the host in Via and Contact does not matter (for
>> registration or dialogs).
>>
>> 2) If GRUU is used, the host in Contact would be a globally routab= le
>> URI. If GRUU is not used, then there is no way =A0at all for SIP R= EFER
>> mechanism to work (since a SIP WebSocket client can only be contac= ted
>> via the WS connection it has opened with the WS server). So the do= main
>> in Contact does not matter (with GRUU it will always work, without=
>> GRUU it will never work).
>>
>>
> Seems right. So we are saying a UA MAY include an invalid host part in= the
> registration Contact header and any request top Via header. The UA MUS= T
> support Outbound and SHOULD (or MUST) support GRUU.
> Actually, there is good reason to consider mandating GRUU for this sce= nario.
> The reason is that suppose 2 different users named Alice register to 2=
> different AORs. Both Alice users go through the same proxy (named P1) = that
> supports websockets and it forwards the requests to the different
> registrars. When an incoming request to one of the Alices comes in, a = proxy
> will forward the request to alice@<invalid host> through P1, but= P1 cannot
> distinguish the two and they are in fact different users. I also belie= ve UAs
> should be encouraged to compare the instance id of incoming requests.<= br>
In the scenario you describe Outbound must take place (the registrar<= br> can only send incoming requests to the users via their outbound SIP
EDGE proxy implementing WebSocket transport). So the Path header the
EDGE proxy adds to the REGISTER includes a flow token (RFC 5626),
probably in the URI username part.

When the registrar routes an incoming request to a registration
binding of one of those WS clients, such request will contain a Route
header with same value as the Path header during registration, and the
EDGE proxy will associate the flow token in such Route URI to the
corresponding WebSocket connection. This is, the Outbound EDGE proxy
does not inspect the request URI for incoming requets, but just the
Route URI and the Outbound flow token in it.

Right, = I ignored that path is there, so it also seems correct that GRUU is a SHOUL= D

--485b397dd547aaea2904b3594531-- From internet-drafts@ietf.org Mon Dec 5 09:02:21 2011 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 5712821F8C8C; Mon, 5 Dec 2011 09:02:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.459 X-Spam-Level: X-Spam-Status: No, score=-102.459 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, 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 WVHiCZkaZe+o; Mon, 5 Dec 2011 09:02:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F2A21F8C86; Mon, 5 Dec 2011 09:02:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64 Message-ID: <20111205170220.7887.61492.idtracker@ietfa.amsl.com> Date: Mon, 05 Dec 2011 09:02:20 -0800 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-proxy-feature-reqs-03.txt 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, 05 Dec 2011 17:02:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core Work= ing Group of the IETF. Title : Requirements for indication of features supported by a S= IP proxy Author(s) : Christer Holmberg Ivo Sedlacek Filename : draft-ietf-sipcore-proxy-feature-reqs-03.txt Pages : 9 Date : 2011-12-05 The Session Initiation Protocol (SIP) "Caller Preferences" extension defined in RFC 3840 provides a mechanism that allows a SIP message to convey information relating to the originator's supported features/ capabilities. This document defines requirements for a mechanism that would allow SIP proxies to convey information relating to the proxy's supported features/capabilities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-proxy-feature-reqs-0= 3.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sipcore-proxy-feature-reqs-03= .txt From christer.holmberg@ericsson.com Mon Dec 5 09:05:13 2011 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 DB28211E8094 for ; Mon, 5 Dec 2011 09:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.404 X-Spam-Level: X-Spam-Status: No, score=-6.404 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] 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 LrFXXBsSReyS for ; Mon, 5 Dec 2011 09:05:13 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 13B2621F8C0D for ; Mon, 5 Dec 2011 09:05:12 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-6d-4edcf9c798dd Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 3F.F9.09514.7C9FCDE4; Mon, 5 Dec 2011 18:05:11 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.67]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Mon, 5 Dec 2011 18:05:11 +0100 From: Christer Holmberg To: "sipcore@ietf.org" Date: Mon, 5 Dec 2011 18:02:46 +0100 Thread-Topic: Draft new version: draft-ietf-sipcore-proxy-feature-reqs-03 Thread-Index: AQHMs2/3gasW8Wsc9EaHgiof2zydzQ== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3BA75DB7@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "pkyzivat@cisco.com" Subject: [sipcore] Draft new version: draft-ietf-sipcore-proxy-feature-reqs-03 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, 05 Dec 2011 17:05:14 -0000 Hi, Based on Robert's comments, I've updated and submitted a new version (-03) = of the proxy feature requirements document. As no other comments were given, I hope that we are now able to finish the = requirement work, and focus on the mechanism :) Thanks to everyone who provided guidance and input! Regards, Christer= From xavier.marjou@gmail.com Thu Dec 8 04:53:50 2011 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 80BAB21F86D0 for ; Thu, 8 Dec 2011 04:53:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_38=0.6, 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 uqJK6uVVHNu0 for ; Thu, 8 Dec 2011 04:53:49 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id A5FAA21F86C3 for ; Thu, 8 Dec 2011 04:53:49 -0800 (PST) Received: by yenm7 with SMTP id m7so1638385yen.31 for ; Thu, 08 Dec 2011 04:53:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=Cp1+e8s+7jrxY5Pu89wJkNV/R4vPKs6C3xI5toKPUfc=; b=Jqg3Mi+HHt+Qm+tR7eDrKD5eQtgjTl57+CWTpBhBT98mYqerVuuv+N4aInyMYvWZ5R j2hXsiTUyrTp4iNDPfxL2nBAb9AeCUyaGmUTt+ggjoRsYoT5BQ5MFEuDUMk9Dl/nRmri K/uTMUAupePL6o28Zm6LcYZJr/uhwj4AbKJqA= MIME-Version: 1.0 Received: by 10.236.173.170 with SMTP id v30mr4090306yhl.24.1323348828195; Thu, 08 Dec 2011 04:53:48 -0800 (PST) Sender: xavier.marjou@gmail.com Received: by 10.236.180.230 with HTTP; Thu, 8 Dec 2011 04:53:48 -0800 (PST) Date: Thu, 8 Dec 2011 13:53:48 +0100 X-Google-Sender-Auth: QSX9AzbR8sA83mtdY3wRxlq5ro4 Message-ID: From: Xavier Marjou To: SIPCORE Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [sipcore] Modification proposal to RFC3841 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, 08 Dec 2011 12:53:50 -0000 Hi, Together with some colleagues, we would like to propose a modification to RFC3841 (Caller Preferences for the SIP). The motivation comes from the fact that the proxy behavior specified in RFC3841 gives an exaggerated preferential treatment to reach =93old=94 UAs (i.e. UAs implementing RFC3261 only) to the detriment of =93new=94 UAs (i.e. UA implementing RFC3261 and RFC3840). As a consequence, when RFC3841 is used on our SIP proxies, most of the SIP calls (SIP INVITEs) terminate at an =93old=94 device rather than at a =93new=94 device= . This is unfair for =93new=94 UAs: they make efforts to implement RFC3840 (and generally other new features/rfcs as well) but they will never be reached. The thing that happens is the following: - An =93old=94 UA sends REGISTER with an =93old=94 Contact (e.g. Contact:sip:c1@192.100.1.2) - A =93new=94 UA sends a REGISTER with a =93new=94 Contact having a sip.instance feature parameter (e.g. Contact:sip:c2@192.100.1.3;+sip.instance=3D"" - A SIP INVITE always arrives at the =93old=94 UA, as its Contact is =93immune=94 and thus benefits from a greater priority than a Contact having feature parameters according to RFC3841 rules. There is thus a need to somehow decrease the priority of =93old=94 UA (ie: UAs that have no feature parameters), otherwise RFC3841 is useless. We would there like to propose the following modification to Section 7.2.3 of RFC3841: 4. If the Contact URI has no "methods" feature parameter, the feature ta= g methods=3D"INVITE,OPTIONS,BYE,CANCEL,ACK" SHOULD be appended to the list. What do you think ? Cheers, Xavier PS: here is a more detailed example of a typical problem encountered when a proxy in the network supports RFC3841. RFC3841 creates a side-effect. The presence of the +sip.instance feature tag modifies the proxy behavior although no preference has been expressed by the caller. Case I. 1) Bob registers two contact addresses for his AoR: Contact:sip:c1@192.100.1.1 and Contact:sip:c2@193.100.1.1 2) Alice calls Bob=92s AoR. The INVITE request does not include any Feature Preference or Request Handling Preference. 3) Bob=92s proxy applies RFC3841 procedures. As it does not find any explicit preference it extracts implicit preferences from the request as specified in RFC3841 Clause 7.2.2. It then behaves as if it had received the INVITE request with Accept-Contact: *;method=3D =ABINVITE=BB;require 4) Bob=92s proxy retrieves the two contact addresses. As c1 and c2 have no feature parameters, they are said to be immune to caller preference processing and are removed from the target set temporarily. 5) At the end both contacts are back in the target set with the same Qa score of 1. 6) Bob=92s proxy forks the request in parallel towards both targets. Case II. 1) Bob registers two contact addresses for his AoR: Contact:sip:c1@192.100.1.1;+sip.instance=3D"" and Contact:sip:c2@193.100.1.1 2) Alice calls Bob=92s AoR. The INVITE request does not include any Feature Preference or Request Handling Preference. 3) Bob=92s proxy applies RFC3841 procedures. As it does not find any explicit preference it extracts implicit preferences from the request as specified in RFC3841 Clause 7.2.2. It then behaves as if it had received the INVITE request with Accept-Contact: *;method=3D =ABINVITE=BB;require 4) Bob=92s proxy retrieves the two contact addresses. As c2 has no feature parameters, it is said to be immune to caller preference processing and is removed from the target set temporarily. The +sip.instance feature parameter is used to create a contact predicate for c1. 5) At the end the The Qa score for c1 is 0 and c2 is put back in the target set with a Qa score of 1. 6) Bob=92s proxy forwards the request to contact c2 first. And then sequentially to contact c1. From brett@broadsoft.com Thu Dec 8 07:43:52 2011 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 01DEB21F85A4 for ; Thu, 8 Dec 2011 07:43:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 7Opk4YCGtGcw for ; Thu, 8 Dec 2011 07:43:51 -0800 (PST) Received: from smtpout01.partnerhosted.com (smtpedge02.chinookhosting.com [173.225.22.202]) by ietfa.amsl.com (Postfix) with ESMTP id 3EACE21F8591 for ; Thu, 8 Dec 2011 07:43:51 -0800 (PST) Received: from CASUMHUB02.citservers.local (172.16.98.58) by FW02.citservers.local (172.16.98.4) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 8 Dec 2011 07:44:03 -0800 Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Thu, 8 Dec 2011 07:44:03 -0800 From: Brett Tate To: "sipcore@ietf.org" Date: Thu, 8 Dec 2011 07:43:49 -0800 Thread-Topic: RFC 3261: Authorization UTF8-NONASCII and escaping Thread-Index: Acy1wC3TW7tfeHkLR8i8SyZPR9prSg== Message-ID: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C128C8EBC@EXMBXCLUS01.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] RFC 3261: Authorization UTF8-NONASCII and escaping 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, 08 Dec 2011 15:43:52 -0000 Howdy, Since unable to obtain much response on sip-implementors... The following are some questions concerning SIP Digest MD5 Authorization. 1) Are UTF8-NONASCII allowed within username and realm? Based upon the ABN= F, it appears to be yes. However since SIP authentication is based upon th= e HTTP specs (such as rfc2617 and rfc2616), I'm not sure if the SIP ABNF ch= anges to include UTF8-NONASCII was intentional concerning the topic. More = specifically, I'm not sure if the rfc2616 TEXT snippet (or something else) = somehow prevents UTF8-NONASCII. 2) Can the password used within Digest MD5 authentication calculation inclu= de UTF8-NONASCII? 3) If quoted-string username contains useless and required escaping of char= acters, is the escaped or un-escaped username supposed to be used within th= e calculation? I assume the un-escaped username; however I thought I'd ask= anyway.=20 In case it helps, the following link mentions that RFC 2831 (similarly base= d upon RFC 2617) attempted to address/resolve these types of questions (int= roduced charset); however RFC 6331 cited these type of issues as part of th= e justification for deprecating RFC 2831. https://lists.cs.columbia.edu/pipermail/sip-implementors/2011-December/0280= 14.html=20 Thanks, Brett ----------- RFC 2617: username =3D "username" "=3D" username-value username-value =3D quoted-string realm =3D "realm" "=3D" realm-value realm-value =3D quoted-string ---- RFC 2616: quoted-string =3D ( <"> *(qdtext | quoted-pair ) <"> ) qdtext =3D > The backslash character ("\") MAY be used as a single-character quoting mechanism only within quoted-string and comment constructs. quoted-pair =3D "\" CHAR Words of *TEXT MAY contain characters from character sets other=20 than ISO-8859-1 [22] only when encoded according to the rules=20 of RFC 2047 [14]. TEXT =3D ---- RFC 3261: Authorization =3D "Authorization" HCOLON credentials credentials =3D ("Digest" LWS digest-response) / other-response digest-response =3D dig-resp *(COMMA dig-resp) dig-resp =3D username / realm / nonce / digest-uri / dresponse / algorithm / cnonce / opaque / message-qop / nonce-count / auth-param username =3D "username" EQUAL username-value username-value =3D quoted-string realm =3D "realm" EQUAL realm-value realm-value =3D quoted-string A string of text is parsed as a single word if it is quoted using double-quote marks. In quoted strings, quotation marks (") and backslashes (\) need to be escaped. quoted-string =3D SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE qdtext =3D LWS / %x21 / %x23-5B / %x5D-7E / UTF8-NONASCII The backslash character ("\") MAY be used as a single-character quoting mechanism only within quoted-string and comment constructs. Unlike HTTP/1.1, the characters CR and LF cannot be escaped by this mechanism to avoid conflict with line folding and header separation. quoted-pair =3D "\" (%x00-09 / %x0B-0C / %x0E-7F) From pkyzivat@alum.mit.edu Thu Dec 8 07:59:40 2011 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 536A021F8AD1 for ; Thu, 8 Dec 2011 07:59:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, J_CHICKENPOX_38=0.6] 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 wqocz3wgffwO for ; Thu, 8 Dec 2011 07:59:39 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 88FF921F8AE1 for ; Thu, 8 Dec 2011 07:59:39 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta05.westchester.pa.mail.comcast.net with comcast id 6e0U1i00Q1wpRvQ55fzfoo; Thu, 08 Dec 2011 15:59:39 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta18.westchester.pa.mail.comcast.net with comcast id 6fzf1i01e07duvL3efzfFW; Thu, 08 Dec 2011 15:59:39 +0000 Message-ID: <4EE0DEEA.5010604@alum.mit.edu> Date: Thu, 08 Dec 2011 23:59:38 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: sipcore@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [sipcore] Modification proposal to RFC3841 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, 08 Dec 2011 15:59:40 -0000 As co-chair, but also as one of the authors of 3841: The issue raised here is subtle. The entire contact selection and prioritization scheme was already nearly incomprehensible. (I'm not proud of that, but I was a newbie at the time.) I don't have information about existing implementations, and typical usage of those implementations. I would like to see several (ideally three or more) who have worked on, or used, callerpref implementations, be involved in discussions. If you fall into that category, please speak up. Others, who haven't delved into this subject are also welcome, but engaging meaningfully in the discussion will involve careful study of 3840/3841. Thanks, Paul On 12/8/11 8:53 PM, Xavier Marjou wrote: > Hi, > > Together with some colleagues, we would like to propose a modification > to RFC3841 (Caller Preferences for the SIP). > > The motivation comes from the fact that the proxy behavior specified > in RFC3841 gives an exaggerated preferential treatment to reach old > UAs (i.e. UAs implementing RFC3261 only) to the detriment of new UAs > (i.e. UA implementing RFC3261 and RFC3840). As a consequence, when > RFC3841 is used on our SIP proxies, most of the SIP calls (SIP > INVITEs) terminate at an old device rather than at a new device. > This is unfair for new UAs: they make efforts to implement RFC3840 > (and generally other new features/rfcs as well) but they will never be > reached. > > The thing that happens is the following: > - An old UA sends REGISTER with an old Contact (e.g. > Contact:sip:c1@192.100.1.2) > - A new UA sends a REGISTER with a new Contact having a > sip.instance feature parameter (e.g. > Contact:sip:c2@192.100.1.3;+sip.instance="" > - A SIP INVITE always arrives at the old UA, as its Contact is > immune and thus benefits from a greater priority than a Contact > having feature parameters according to RFC3841 rules. > > There is thus a need to somehow decrease the priority of old UA (ie: > UAs that have no feature parameters), otherwise RFC3841 is useless. > > We would there like to propose the following modification to Section > 7.2.3 of RFC3841: > 4. If the Contact URI has no "methods" feature parameter, the feature tag > methods="INVITE,OPTIONS,BYE,CANCEL,ACK" SHOULD be appended to > the list. > > What do you think ? > > Cheers, > Xavier > > > PS: here is a more detailed example of a typical problem encountered > when a proxy in the network supports RFC3841. > RFC3841 creates a side-effect. The presence of the +sip.instance > feature tag modifies the proxy behavior although no preference has > been expressed by the caller. > > Case I. > > 1) Bob registers two contact addresses for his AoR: > Contact:sip:c1@192.100.1.1 and Contact:sip:c2@193.100.1.1 > 2) Alice calls Bobs AoR. The INVITE request does not include any > Feature Preference or Request Handling Preference. > 3) Bobs proxy applies RFC3841 procedures. As it does not find any > explicit preference it extracts implicit preferences from the request > as specified in RFC3841 Clause 7.2.2. It then behaves as if it had > received the INVITE request with Accept-Contact: *;method= > INVITE;require > 4) Bobs proxy retrieves the two contact addresses. As c1 and c2 have > no feature parameters, they are said to be immune to caller preference > processing and are removed from the target set temporarily. > 5) At the end both contacts are back in the target set with the same > Qa score of 1. > 6) Bobs proxy forks the request in parallel towards both targets. > > > > Case II. > > 1) Bob registers two contact addresses for his AoR: > Contact:sip:c1@192.100.1.1;+sip.instance="" > and Contact:sip:c2@193.100.1.1 > 2) Alice calls Bobs AoR. The INVITE request does not include any > Feature Preference or Request Handling Preference. > 3) Bobs proxy applies RFC3841 procedures. As it does not find any > explicit preference it extracts implicit preferences from the request > as specified in RFC3841 Clause 7.2.2. It then behaves as if it had > received the INVITE request with Accept-Contact: *;method= > INVITE;require > 4) Bobs proxy retrieves the two contact addresses. As c2 has no > feature parameters, it is said to be immune to caller preference > processing and is removed from the target set temporarily. The > +sip.instance feature parameter is used to create a contact predicate > for c1. > 5) At the end the The Qa score for c1 is 0 and c2 is put back in the > target set with a Qa score of 1. > 6) Bobs proxy forwards the request to contact c2 first. And then > sequentially to contact c1. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From dworley@avaya.com Thu Dec 8 09:28:05 2011 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 6CF3021F8B83 for ; Thu, 8 Dec 2011 09:28:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 vuCzAx0ThB9Z for ; Thu, 8 Dec 2011 09:28:05 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA9F21F8B5C for ; Thu, 8 Dec 2011 09:28:04 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAAXz4E7GmAcF/2dsb2JhbABDqmiBBYFyAQEBAQIBEihECwIBCA0IDxIQMiUBAQQBEggah2WcI5sfilhjBIgukiiMWQ X-IronPort-AV: E=Sophos;i="4.71,320,1320642000"; d="scan'208";a="281064163" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 08 Dec 2011 12:27:46 -0500 Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by co300216-co-erhwest-out.avaya.com with ESMTP; 08 Dec 2011 12:25:18 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.3]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Thu, 8 Dec 2011 12:27:45 -0500 From: "Worley, Dale R (Dale)" To: Xavier Marjou , SIPCORE Date: Thu, 8 Dec 2011 12:27:44 -0500 Thread-Topic: [sipcore] Modification proposal to RFC3841 Thread-Index: Acy1qHNXWQsM3RmVQdiTXSSPmXbbwwAIySET Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Modification proposal to RFC3841 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, 08 Dec 2011 17:28:05 -0000 > From: Xavier Marjou [xavier.marjou@orange.com] >=20 > We would there like to propose the following modification to Section > 7.2.3 of RFC3841: > 4. If the Contact URI has no "methods" feature parameter, the feature = tag > methods=3D"INVITE,OPTIONS,BYE,CANCEL,ACK" SHOULD be appended to > the list. That doesn't solve the problem well, unfortunately. Consider your Case II, but with the incoming request being SUBSCRIBE (or MESSAGE). Since the second contact has an implicit 'methods=3D"INVITE,OPTIONS,BYE,CANCEL,ACK"' and the request has an implicit '(sip.methods=3DSUBSCRIBE)' *with the reqire flag*, the SUBSCRIBE could never be delivered to the second contact even if the first contact was nonresponsibe. Part of the problem is that the logic of RFC 3841 assumes that if a UA registers a contact with any feature parameters, the UA understands and is implementing RFC 3841, and specifically, will include feature parameters that describe all of its features. In particular, that it will include a 'methods' feature parameter. But the reality is that most UAs that include a +sip.instance parameter are doing so to implement GRUU and/or SIP Outbound, and logic should not assume that they support *no* methods. The logic of RFC 3841 holds that if an (implicit or explicit) Accept-Contacts demands a particular value for a particular feature, a UA will be downgraded if it does not declare a value for that feature. The exemption is that if the UA provided *no* feature parameters, than it will not be downgraded. Rather the logic should (IMHO) not downgrade the contact unless it provides an incompatible value for the feature (unless there was an explicit 'require' flag). Dale From pkyzivat@alum.mit.edu Thu Dec 8 10:41:05 2011 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 89F1B21F8AB9 for ; Thu, 8 Dec 2011 10:41:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] 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 GOp61bG9fFSS for ; Thu, 8 Dec 2011 10:41:05 -0800 (PST) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id CD66921F8AF1 for ; Thu, 8 Dec 2011 10:41:04 -0800 (PST) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta06.westchester.pa.mail.comcast.net with comcast id 6igt1i0010QuhwU56ih51V; Thu, 08 Dec 2011 18:41:05 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta02.westchester.pa.mail.comcast.net with comcast id 6ih41i01v07duvL3Nih5UU; Thu, 08 Dec 2011 18:41:05 +0000 Message-ID: <4EE104BF.7010702@alum.mit.edu> Date: Thu, 08 Dec 2011 13:41:03 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: sipcore@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] Modification proposal to RFC3841 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, 08 Dec 2011 18:41:05 -0000 On 12/8/11 12:27 PM, Worley, Dale R (Dale) wrote: >> From: Xavier Marjou [xavier.marjou@orange.com] >> >> We would there like to propose the following modification to Section >> 7.2.3 of RFC3841: >> 4. If the Contact URI has no "methods" feature parameter, the feature tag >> methods="INVITE,OPTIONS,BYE,CANCEL,ACK" SHOULD be appended to >> the list. > > That doesn't solve the problem well, unfortunately. Consider your > Case II, but with the incoming request being SUBSCRIBE (or MESSAGE). > Since the second contact has an implicit > 'methods="INVITE,OPTIONS,BYE,CANCEL,ACK"' and the request has an > implicit '(sip.methods=SUBSCRIBE)' *with the reqire flag*, the > SUBSCRIBE could never be delivered to the second contact even if the > first contact was nonresponsibe. > > Part of the problem is that the logic of RFC 3841 assumes that if a UA > registers a contact with any feature parameters, the UA understands > and is implementing RFC 3841, and specifically, will include feature > parameters that describe all of its features. In particular, that it > will include a 'methods' feature parameter. But the reality is that > most UAs that include a +sip.instance parameter are doing so to > implement GRUU and/or SIP Outbound, and logic should not assume that > they support *no* methods. An interesting observation. Of course those other uses for feature tags didn't exist when 3841 was written. In retrospect, we should perhaps have called out in outbound and gruu that use of those made it mandatory to implement 3841. > The logic of RFC 3841 holds that if an (implicit or explicit) > Accept-Contacts demands a particular value for a particular feature, a > UA will be downgraded if it does not declare a value for that feature. > The exemption is that if the UA provided *no* feature parameters, than > it will not be downgraded. Rather the logic should (IMHO) not > downgrade the contact unless it provides an incompatible value for the > feature (unless there was an explicit 'require' flag). I'll defer commenting on this. I always have to go back and study the complete algorithm again before drawing any conclusions, and that gives me a headache. My feeling is that the most straightforward way to deal with this is for those that are having trouble to get each UA to register with all of its callerprefs, rather than introducing new defaulting. Thanks, Paul From adam@nostrum.com Thu Dec 8 19:57:23 2011 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 372CB1F0C50 for ; Thu, 8 Dec 2011 19:57:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.204 X-Spam-Level: X-Spam-Status: No, score=-101.204 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 gmvZjNBNbSCF for ; Thu, 8 Dec 2011 19:57:22 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3F48B1F0C4E for ; Thu, 8 Dec 2011 19:57:21 -0800 (PST) Received: from [192.168.0.159] (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id pB93v71g072266 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 8 Dec 2011 21:57:14 -0600 (CST) (envelope-from adam@nostrum.com) References: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C128C8EBC@EXMBXCLUS01.citservers.local> From: Adam Roach Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In-Reply-To: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C128C8EBC@EXMBXCLUS01.citservers.local> Message-Id: <32372A9E-B596-4EA9-8C02-9276BFC888BD@nostrum.com> Date: Thu, 8 Dec 2011 21:55:20 -0600 To: Brett Tate Mime-Version: 1.0 (1.0) X-Mailer: iPad Mail (9A334) Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: "sipcore@ietf.org" Subject: Re: [sipcore] RFC 3261: Authorization UTF8-NONASCII and escaping 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, 09 Dec 2011 03:57:23 -0000 [as an individual] These are really good questions, and ones that don't really have an answer y= et. There have been some hallway conversations around SIP and internationali= zation at recent IETF meetings. Most of what I've heard has centered on URIs= (and domains in particular), and authentication is an important topic that I= haven't heard come up yet. I suspect that this is the next big thing SIPCORE will take on (unless we de= cide to spin up a new SIP internationalization WG). Stay tuned -- and if you= 're interested in doing work in this area, speak up. I expect that we'll be l= ooking for draft authors in the coming months.=20 /a On Dec 8, 2011, at 9:43, Brett Tate wrote: > Howdy, >=20 > Since unable to obtain much response on sip-implementors... >=20 > The following are some questions concerning SIP Digest MD5 Authorization. >=20 > 1) Are UTF8-NONASCII allowed within username and realm? Based upon the AB= NF, it appears to be yes. However since SIP authentication is based upon th= e HTTP specs (such as rfc2617 and rfc2616), I'm not sure if the SIP ABNF cha= nges to include UTF8-NONASCII was intentional concerning the topic. More sp= ecifically, I'm not sure if the rfc2616 TEXT snippet (or something else) som= ehow prevents UTF8-NONASCII. >=20 > 2) Can the password used within Digest MD5 authentication calculation incl= ude UTF8-NONASCII? >=20 > 3) If quoted-string username contains useless and required escaping of cha= racters, is the escaped or un-escaped username supposed to be used within th= e calculation? I assume the un-escaped username; however I thought I'd ask a= nyway.=20 >=20 > In case it helps, the following link mentions that RFC 2831 (similarly bas= ed upon RFC 2617) attempted to address/resolve these types of questions (int= roduced charset); however RFC 6331 cited these type of issues as part of the= justification for deprecating RFC 2831. >=20 > https://lists.cs.columbia.edu/pipermail/sip-implementors/2011-December/028= 014.html=20 >=20 > Thanks, > Brett >=20 >=20 > ----------- >=20 > RFC 2617: >=20 > username =3D "username" "=3D" username-value > username-value =3D quoted-string > realm =3D "realm" "=3D" realm-value > realm-value =3D quoted-string >=20 > ---- >=20 > RFC 2616: >=20 > quoted-string =3D ( <"> *(qdtext | quoted-pair ) <"> ) > qdtext =3D > >=20 > The backslash character ("\") MAY be used as a single-character > quoting mechanism only within quoted-string and comment constructs. >=20 > quoted-pair =3D "\" CHAR >=20 > Words of *TEXT MAY contain characters from character sets other=20 > than ISO-8859-1 [22] only when encoded according to the rules=20 > of RFC 2047 [14]. >=20 > TEXT =3D >=20 > ---- >=20 > RFC 3261: > Authorization =3D "Authorization" HCOLON credentials > credentials =3D ("Digest" LWS digest-response) > / other-response > digest-response =3D dig-resp *(COMMA dig-resp) > dig-resp =3D username / realm / nonce / digest-uri > / dresponse / algorithm / cnonce > / opaque / message-qop > / nonce-count / auth-param > username =3D "username" EQUAL username-value > username-value =3D quoted-string > realm =3D "realm" EQUAL realm-value > realm-value =3D quoted-string >=20 > A string of text is parsed as a single word if it is quoted using > double-quote marks. In quoted strings, quotation marks (") and > backslashes (\) need to be escaped. >=20 > quoted-string =3D SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE > qdtext =3D LWS / %x21 / %x23-5B / %x5D-7E / UTF8-NONASCII >=20 > The backslash character ("\") MAY be used as a single-character > quoting mechanism only within quoted-string and comment constructs. > Unlike HTTP/1.1, the characters CR and LF cannot be escaped by this > mechanism to avoid conflict with line folding and header separation. >=20 > quoted-pair =3D "\" (%x00-09 / %x0B-0C / %x0E-7F) >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From ibc@aliax.net Fri Dec 9 05:25:43 2011 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 033F821F8531 for ; Fri, 9 Dec 2011 05:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 tfFYrVKl0oA6 for ; Fri, 9 Dec 2011 05:25:42 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 688BF21F8514 for ; Fri, 9 Dec 2011 05:25:42 -0800 (PST) Received: by vcbfy13 with SMTP id fy13so2454608vcb.31 for ; Fri, 09 Dec 2011 05:25:41 -0800 (PST) Received: by 10.52.94.18 with SMTP id cy18mr4337517vdb.24.1323437141577; Fri, 09 Dec 2011 05:25:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.177.134 with HTTP; Fri, 9 Dec 2011 05:25:20 -0800 (PST) In-Reply-To: <32372A9E-B596-4EA9-8C02-9276BFC888BD@nostrum.com> References: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C128C8EBC@EXMBXCLUS01.citservers.local> <32372A9E-B596-4EA9-8C02-9276BFC888BD@nostrum.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 9 Dec 2011 14:25:20 +0100 Message-ID: To: Adam Roach Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "sipcore@ietf.org" Subject: Re: [sipcore] RFC 3261: Authorization UTF8-NONASCII and escaping 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, 09 Dec 2011 13:25:43 -0000 2011/12/9 Adam Roach : > These are really good questions, and ones that don't really have an answe= r yet. There have been some hallway conversations around SIP and internatio= nalization at recent IETF meetings. Most of what I've heard has centered on= URIs (and domains in particular), and authentication is an important topic= that I haven't heard come up yet. > > I suspect that this is the next big thing SIPCORE will take on (unless we= decide to spin up a new SIP internationalization WG). Stay tuned -- and if= you're interested in doing work in this area, speak up. I expect that we'l= l be looking for draft authors in the coming months. It would be needed that some specification defines how to read a "username" and "realm" from an (WWW-)Authorization header. Should the parser perform hexadecimal unescaping on those fields? or should those fields contain UTF8-NONASCII symbols (since their BNF grammar allow it)? This must be defined. Regards. --=20 I=C3=B1aki Baz Castillo From brett@broadsoft.com Fri Dec 9 06:39:35 2011 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 5272721F84F8 for ; Fri, 9 Dec 2011 06:39:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] 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 dbgPDcw-mD4d for ; Fri, 9 Dec 2011 06:39:34 -0800 (PST) Received: from smtpout01.partnerhosted.com (smtpedge02.chinookhosting.com [173.225.22.202]) by ietfa.amsl.com (Postfix) with ESMTP id A4B8721F849C for ; Fri, 9 Dec 2011 06:39:34 -0800 (PST) Received: from casumhub01.citservers.local (172.16.98.57) by FW02.citservers.local (172.16.98.4) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 9 Dec 2011 06:39:49 -0800 Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Fri, 9 Dec 2011 06:39:46 -0800 From: Brett Tate To: Adam Roach , "sipcore@ietf.org" Date: Fri, 9 Dec 2011 06:39:31 -0800 Thread-Topic: [sipcore] RFC 3261: Authorization UTF8-NONASCII and escaping Thread-Index: Acy2Jse5wDqoweAfSaKwqqtOtng29gAUbLgg Message-ID: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C128C905E@EXMBXCLUS01.citservers.local> References: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C128C8EBC@EXMBXCLUS01.citservers.local> <32372A9E-B596-4EA9-8C02-9276BFC888BD@nostrum.com> In-Reply-To: <32372A9E-B596-4EA9-8C02-9276BFC888BD@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] RFC 3261: Authorization UTF8-NONASCII and escaping 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, 09 Dec 2011 14:39:35 -0000 Thanks for the response. In case not captured yet... One of the international limitations is the inability to compliantly embed = headers containing UTF8-NONASCII within a sip-uri. RFC 3986 provides an es= caping mechanism for newer URIs. Concerning domains, RFC 3986 mention the use of RFC 3490; however RFC 3490 = was made obsolete by RFC 5890 and RFC 5891. > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Thursday, December 08, 2011 10:55 PM > To: Brett Tate > Cc: sipcore@ietf.org > Subject: Re: [sipcore] RFC 3261: Authorization UTF8-NONASCII and > escaping >=20 > [as an individual] >=20 > These are really good questions, and ones that don't really have an > answer yet. There have been some hallway conversations around SIP and > internationalization at recent IETF meetings. Most of what I've heard > has centered on URIs (and domains in particular), and authentication is > an important topic that I haven't heard come up yet. >=20 > I suspect that this is the next big thing SIPCORE will take on (unless > we decide to spin up a new SIP internationalization WG). Stay tuned -- > and if you're interested in doing work in this area, speak up. I expect > that we'll be looking for draft authors in the coming months. >=20 > /a >=20 > On Dec 8, 2011, at 9:43, Brett Tate wrote: >=20 > > Howdy, > > > > Since unable to obtain much response on sip-implementors... > > > > The following are some questions concerning SIP Digest MD5 > Authorization. > > > > 1) Are UTF8-NONASCII allowed within username and realm? Based upon > the ABNF, it appears to be yes. However since SIP authentication is > based upon the HTTP specs (such as rfc2617 and rfc2616), I'm not sure > if the SIP ABNF changes to include UTF8-NONASCII was intentional > concerning the topic. More specifically, I'm not sure if the rfc2616 > TEXT snippet (or something else) somehow prevents UTF8-NONASCII. > > > > 2) Can the password used within Digest MD5 authentication calculation > include UTF8-NONASCII? > > > > 3) If quoted-string username contains useless and required escaping > of characters, is the escaped or un-escaped username supposed to be > used within the calculation? I assume the un-escaped username; however > I thought I'd ask anyway. > > > > In case it helps, the following link mentions that RFC 2831 > (similarly based upon RFC 2617) attempted to address/resolve these > types of questions (introduced charset); however RFC 6331 cited these > type of issues as part of the justification for deprecating RFC 2831. > > > > https://lists.cs.columbia.edu/pipermail/sip-implementors/2011- > December/028014.html > > > > Thanks, > > Brett From xavier.marjou@gmail.com Fri Dec 9 07:16:10 2011 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 44AEF21F84FC for ; Fri, 9 Dec 2011 07:16:10 -0800 (PST) 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=[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 HFzHXKbhsXuR for ; Fri, 9 Dec 2011 07:16:09 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC8C21F84E5 for ; Fri, 9 Dec 2011 07:16:09 -0800 (PST) Received: by ghrr18 with SMTP id r18so2848521ghr.31 for ; Fri, 09 Dec 2011 07:16:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5azOBqBShgQnqGAmP4CZskDOdNRdvYUdT/xRqTuX6vg=; b=OCrvOMtDkr9k1c4ag4SMwf67VqWLK0z2jDBwo9dklu7WBDMUE03HAgzpSTK6luOTw4 gAoffd40XdhLDGgM79KNSRLUg89vRvL8f1ZfUp3SQpASiI5dOrA6wmI6cdx/b0cuO/3T Kh5rD3+Cl/nlAfgVhrYkbUgVfNWrFWmh5OeTI= MIME-Version: 1.0 Received: by 10.236.128.242 with SMTP id f78mr13056531yhi.7.1323443768849; Fri, 09 Dec 2011 07:16:08 -0800 (PST) Received: by 10.236.180.230 with HTTP; Fri, 9 Dec 2011 07:16:08 -0800 (PST) In-Reply-To: References: Date: Fri, 9 Dec 2011 16:16:08 +0100 Message-ID: From: Xavier Marjou To: "Worley, Dale R (Dale)" Content-Type: multipart/alternative; boundary=20cf30050b64b8f60804b3aa4322 Cc: SIPCORE Subject: Re: [sipcore] Modification proposal to RFC3841 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, 09 Dec 2011 15:16:10 -0000 --20cf30050b64b8f60804b3aa4322 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Dec 8, 2011 at 6:27 PM, Worley, Dale R (Dale) wrote: > > From: Xavier Marjou [xavier.marjou@orange.com] > > > > We would there like to propose the following modification to Section > > 7.2.3 of RFC3841: > > 4. If the Contact URI has no "methods" feature parameter, the feature > tag > > methods="INVITE,OPTIONS,BYE,CANCEL,ACK" SHOULD be appended to > > the list. > > That doesn't solve the problem well, unfortunately. Consider your > Case II, but with the incoming request being SUBSCRIBE (or MESSAGE). > Since the second contact has an implicit > 'methods="INVITE,OPTIONS,BYE,CANCEL,ACK"' and the request has an > implicit '(sip.methods=SUBSCRIBE)' *with the reqire flag*, the > SUBSCRIBE could never be delivered to the second contact even if the > first contact was nonresponsibe. > Hi Dale, The proposal is not to add methods="INVITE,OPTIONS,BYE,CANCEL,ACK" to the list of Contact URI having no parameters at all. The proposal is to add methods="INVITE,OPTIONS,BYE,CANCEL,ACK" to the list of Contact URI having no "methods" parameters. So in the example with the SUBSCRIBE message, the proposal does work : both Contact URIs have no "methods" param when being processed by the proposed treatment 7.2.3.#4 , thus each one will have methods="INVITE,OPTIONS,BYE,CANCEL,ACK" added into its related list, and they will thus end-up with the same priority. Cheers, Xavier --20cf30050b64b8f60804b3aa4322 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Dec 8, 2011 at 6:27 PM, Worley, = Dale R (Dale) <dw= orley@avaya.com> wrote:
> From: Xavier Marjou [xavie= r.marjou@orange.com]
>
> We would there like to propose the following modification to Section > 7.2.3 of RFC3841:
> =A0 =A04. If the Contact URI has no "methods" feature parame= ter, the feature tag
> =A0 =A0methods=3D"INVITE,OPTIONS,BYE,CANCEL,ACK" SHOULD be a= ppended to
> =A0 =A0the list.

That doesn't solve the problem well, unfortunately. =A0Consider y= our
Case II, but with the incoming request being SUBSCRIBE (or MESSAGE).
Since the second contact has an implicit
'methods=3D"INVITE,OPTIONS,BYE,CANCEL,ACK"' and the reque= st has an
implicit '(sip.methods=3DSUBSCRIBE)' *with the reqire flag*, the SUBSCRIBE could never be delivered to the second contact even if the
first contact was nonresponsibe.

Hi Dale,

= The proposal is not to add methods=3D"INVITE,OPTIONS,BYE,CANCEL,ACK&qu= ot; to the list of Contact URI having no parameters at all.
The proposa= l is to add methods=3D"INVITE,OPTIONS,BYE,CANCEL,ACK" to the list= of Contact URI having no "methods" parameters.
So in the example with the SUBSCRIBE message, the proposal does work : both= Contact URIs have no "methods" param when being processed by the= proposed treatment 7.2.3.#4 , thus each one will have methods=3D"INVI= TE,OPTIONS,BYE,CANCEL,ACK" added into its related list, and they will = thus end-up with the same priority.

Cheers,
Xavier
--20cf30050b64b8f60804b3aa4322-- From keith.drage@alcatel-lucent.com Fri Dec 9 07:31:31 2011 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 838B921F8586 for ; Fri, 9 Dec 2011 07:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.047 X-Spam-Level: X-Spam-Status: No, score=-106.047 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, 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 j2VP8vdnZv9W for ; Fri, 9 Dec 2011 07:31:29 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 96B1121F853E for ; Fri, 9 Dec 2011 07:31:29 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id pB9FV8xh007707 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 9 Dec 2011 16:31:23 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 9 Dec 2011 16:31:10 +0100 From: "DRAGE, Keith (Keith)" To: Xavier Marjou , "Worley, Dale R (Dale)" Date: Fri, 9 Dec 2011 16:31:08 +0100 Thread-Topic: [sipcore] Modification proposal to RFC3841 Thread-Index: Acy2hYBOZcMI9WWSQpax2RiK7ZxsTAAAXN8A Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE2221EB085FRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: SIPCORE Subject: Re: [sipcore] Modification proposal to RFC3841 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, 09 Dec 2011 15:31:31 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE2221EB085FRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable One point I'd offer is that the proposal is making the assumption that all = existing UAs not implementing RFC 3841 essentially implement the INVITE met= hod, and are prepared to receive and process such INVITE requests. As far as I am aware, it is perfectly possible that an implementation only = provide the REGISTER method, and for example SUBSCRIBE and PUBLISH. The pro= posal above would require all such devices used in a multi-terminal situati= on to implement RFC 3841 in order to avoid receiving INVITE requests not in= tended for them. Regards Keith ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Xavier Marjou Sent: 09 December 2011 15:16 To: Worley, Dale R (Dale) Cc: SIPCORE Subject: Re: [sipcore] Modification proposal to RFC3841 On Thu, Dec 8, 2011 at 6:27 PM, Worley, Dale R (Dale) > wrote: > From: Xavier Marjou [xavier.marjou@orange.com] > > We would there like to propose the following modification to Section > 7.2.3 of RFC3841: > 4. If the Contact URI has no "methods" feature parameter, the feature = tag > methods=3D"INVITE,OPTIONS,BYE,CANCEL,ACK" SHOULD be appended to > the list. That doesn't solve the problem well, unfortunately. Consider your Case II, but with the incoming request being SUBSCRIBE (or MESSAGE). Since the second contact has an implicit 'methods=3D"INVITE,OPTIONS,BYE,CANCEL,ACK"' and the request has an implicit '(sip.methods=3DSUBSCRIBE)' *with the reqire flag*, the SUBSCRIBE could never be delivered to the second contact even if the first contact was nonresponsibe. Hi Dale, The proposal is not to add methods=3D"INVITE,OPTIONS,BYE,CANCEL,ACK" to the= list of Contact URI having no parameters at all. The proposal is to add methods=3D"INVITE,OPTIONS,BYE,CANCEL,ACK" to the lis= t of Contact URI having no "methods" parameters. So in the example with the SUBSCRIBE message, the proposal does work : both= Contact URIs have no "methods" param when being processed by the proposed = treatment 7.2.3.#4 , thus each one will have methods=3D"INVITE,OPTIONS,BYE,= CANCEL,ACK" added into its related list, and they will thus end-up with the= same priority. Cheers, Xavier --_000_EDC0A1AE77C57744B664A310A0B23AE2221EB085FRMRSSXCHMBSC3d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

One point I’d offer is that the proposal is making the assumption that all existing UAs not implementing RF= C 3841 essentially implement the INVITE method, and are prepared to receive a= nd process such INVITE requests.

 

As far as I am aware, it is perfectly possible that an implementation only provide the REGISTER method, and for example SUBSCRIBE and PUBLISH. The proposal above would require all such devices used in a multi-terminal situation to implement RFC 3841 in order t= o avoid receiving INVITE requests not intended for them.

 

Regards

 

Keith

 

From:= sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Xavier Marjou
Sent: 09 December 2011 15:16=
To: Worley, Dale R (Dale) Cc: SIPCORE
Subject: Re: [sipcore] Modification proposal to RFC3841

 

 =

On Thu, Dec 8, 2011 at 6:27 PM, Worley, Dale R (Dale) <dworley@avaya.com> wrote:

> From: Xavier Marjou [xavier.marjou@orange.com]

>
> We would there like to propose the following modification to Section > 7.2.3 of RFC3841:
>    4. If the Contact URI has no "methods" feature parameter, the feature tag
>    methods=3D"INVITE,OPTIONS,BYE,CANCEL,ACK" SHOUL= D be appended to
>    the list.

That doesn't solve the problem well, unfortunately.  Consider = your
Case II, but with the incoming request being SUBSCRIBE (or MESSAGE).
Since the second contact has an implicit
'methods=3D"INVITE,OPTIONS,BYE,CANCEL,ACK"' and the request has a= n
implicit '(sip.methods=3DSUBSCRIBE)' *with the reqire flag*, the
SUBSCRIBE could never be delivered to the second contact even if the
first contact was nonresponsibe.


Hi Dale,

The proposal is not to add methods=3D"INVITE,OPTIONS,BYE,CANCEL,ACK&qu= ot; to the list of Contact URI having no parameters at all.
The proposal is to add methods=3D"INVITE,OPTIONS,BYE,CANCEL,ACK" = to the list of Contact URI having no "methods" parameters.
So in the example with the SUBSCRIBE message, the proposal does work : both Contact URIs have no "methods" param when being processed by the proposed treatment 7.2.3.#4 , thus each one will have methods=3D"INVITE,OPTIONS,BYE,CANCEL,ACK" added into its related = list, and they will thus end-up with the same priority.

Cheers,
Xavier

--_000_EDC0A1AE77C57744B664A310A0B23AE2221EB085FRMRSSXCHMBSC3d_-- From HKaplan@acmepacket.com Fri Dec 9 17:02:16 2011 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 7A6621F0C59 for ; Fri, 9 Dec 2011 17:02:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] 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 D-rkAzsfdTsK for ; Fri, 9 Dec 2011 17:02:16 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id BB1EA1F0C40 for ; Fri, 9 Dec 2011 17:02:03 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 9 Dec 2011 20:01:59 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.245]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Fri, 9 Dec 2011 20:01:59 -0500 From: Hadriel Kaplan To: Xavier Marjou Thread-Topic: [sipcore] Modification proposal to RFC3841 Thread-Index: AQHMttdQau970nOtZESEDMj+WUYqaA== Date: Sat, 10 Dec 2011 01:01:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <41D6EAEE9BA3D24B8AA0401B95DB15DB@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "Worley, Dale R \(Dale\)" , SIPCORE Subject: Re: [sipcore] Modification proposal to RFC3841 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: Sat, 10 Dec 2011 01:02:16 -0000 On Dec 9, 2011, at 10:16 AM, Xavier Marjou wrote: > On Thu, Dec 8, 2011 at 6:27 PM, Worley, Dale R (Dale) = wrote: >> > From: Xavier Marjou [xavier.marjou@orange.com] >> > >> > We would there like to propose the following modification to Section >> > 7.2.3 of RFC3841: >> > 4. If the Contact URI has no "methods" feature parameter, the featu= re tag >> > methods=3D"INVITE,OPTIONS,BYE,CANCEL,ACK" SHOULD be appended to >> > the list. >>=20 >> That doesn't solve the problem well, unfortunately. Consider your >> Case II, but with the incoming request being SUBSCRIBE (or MESSAGE). >> Since the second contact has an implicit >> 'methods=3D"INVITE,OPTIONS,BYE,CANCEL,ACK"' and the request has an >> implicit '(sip.methods=3DSUBSCRIBE)' *with the reqire flag*, the >> SUBSCRIBE could never be delivered to the second contact even if the >> first contact was nonresponsibe. >=20 > Hi Dale,=20 >=20 > The proposal is not to add methods=3D"INVITE,OPTIONS,BYE,CANCEL,ACK" to t= he list of Contact URI having no parameters at all.=20 > The proposal is to add methods=3D"INVITE,OPTIONS,BYE,CANCEL,ACK" to the l= ist of Contact URI having no "methods" parameters.=20 > So in the example with the SUBSCRIBE message, the proposal does work : bo= th Contact URIs have no "methods" param when being processed by the propose= d treatment 7.2.3.#4 , thus each one will have methods=3D"INVITE,OPTIONS,BY= E,CANCEL,ACK" added into its related list, and they will thus end-up with t= he same priority. That won't solve the problem. Ultimately you're guessing that UA-2 only su= pports those methods, so if you guess wrong, it will break. For example, h= ow do you know neither UAs support the MESSAGE method? It would be better to use an implicit 'methods=3D"*"' concept. -hadriel From HKaplan@acmepacket.com Fri Dec 9 17:19:21 2011 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 AF57511E8094 for ; Fri, 9 Dec 2011 17:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] 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 XfFlJ5PcMfF4 for ; Fri, 9 Dec 2011 17:19:21 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1320911E8082 for ; Fri, 9 Dec 2011 17:19:20 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 9 Dec 2011 20:19:19 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.245]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Fri, 9 Dec 2011 20:19:19 -0500 From: Hadriel Kaplan To: Paul Kyzivat Thread-Topic: [sipcore] Modification proposal to RFC3841 Thread-Index: AQHMttm9hrbH8QKg20eJpa1ACbJZ9A== Date: Sat, 10 Dec 2011 01:19:19 +0000 Message-ID: <54DE53E2-E6FE-4480-A500-32F0D453C84C@acmepacket.com> References: <4EE104BF.7010702@alum.mit.edu> In-Reply-To: <4EE104BF.7010702@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [sipcore] Modification proposal to RFC3841 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: Sat, 10 Dec 2011 01:19:21 -0000 On Dec 8, 2011, at 1:41 PM, Paul Kyzivat wrote: > In retrospect, we should perhaps have called out in outbound and gruu tha= t use of those made it mandatory to implement 3841. That would have made it a lot harder to deploy outbound. We've successfull= y convinced some providers to deploy outbound's instance param and get thei= r Registrar and UAs to do it, but I doubt we could have convinced them to d= o full 3841. I wonder if we should not have had the instance id be a feature tag to begi= n with. It's not a feature preference. >> The logic of RFC 3841 holds that if an (implicit or explicit) >> Accept-Contacts demands a particular value for a particular feature, a >> UA will be downgraded if it does not declare a value for that feature. >> The exemption is that if the UA provided *no* feature parameters, than >> it will not be downgraded. Rather the logic should (IMHO) not >> downgrade the contact unless it provides an incompatible value for the >> feature (unless there was an explicit 'require' flag). >=20 > I'll defer commenting on this. I always have to go back and study the com= plete algorithm again before drawing any conclusions, and that gives me a h= eadache. >=20 > My feeling is that the most straightforward way to deal with this is for = those that are having trouble to get each UA to register with all of its ca= llerprefs, rather than introducing new defaulting. Changing existing UAs is really really hard, in many ways. Changing the ru= les of RFC 3841 with an update/extension and changing the deployed proxies = is easier, afaict. ISTM that Dale has it right: the logic should be if you don't explicitly in= dicate a given feature-tag, it's essentially unknown whether you do/don't s= upport it, and requests should be routed to you as if you did. Or if we re= ally want to preserve the property of implicitly unsupported, then we'll ha= ve to update 3841 to exempt "sip.instance", "sip.message" and "sip.ice". -hadriel From ibc@aliax.net Mon Dec 12 14:12:22 2011 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 654D321F87D6 for ; Mon, 12 Dec 2011 14:12:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[AWL=-0.659, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 lY90opjrwkrX for ; Mon, 12 Dec 2011 14:12:22 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C93A621F85EF for ; Mon, 12 Dec 2011 14:12:21 -0800 (PST) Received: by vbbez10 with SMTP id ez10so4619852vbb.31 for ; Mon, 12 Dec 2011 14:12:21 -0800 (PST) Received: by 10.52.94.18 with SMTP id cy18mr44252vdb.24.1323727941245; Mon, 12 Dec 2011 14:12:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.177.134 with HTTP; Mon, 12 Dec 2011 14:12:00 -0800 (PST) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 12 Dec 2011 23:12:00 +0100 Message-ID: To: "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [sipcore] New Version Notification for draft-ibc-sipcore-sip-websocket-00 (previously draft-ibc-rtcweb-sip-websocket-00) 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, 12 Dec 2011 22:12:22 -0000 Hi, the WebSocket protocol is now approved as the RFC 6455: http://tools.ietf.org/html/rfc6455 This is interesting since it makes the WebSocket Transport for SIP no longer to depend on a non finished draft. Best regards. --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Mon Dec 12 23:48:29 2011 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 B48C611E808B for ; Mon, 12 Dec 2011 23:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 bH9o3nxon18A for ; Mon, 12 Dec 2011 23:48:29 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id F013D21F846C for ; Mon, 12 Dec 2011 23:48:28 -0800 (PST) X-AuditID: c1b4fb3d-b7cfeae000005b81-fd-4ee7034b6c7a Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 00.D3.23425.B4307EE4; Tue, 13 Dec 2011 08:48:27 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.67]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 13 Dec 2011 08:48:11 +0100 From: Christer Holmberg To: "sipcore@ietf.org" Date: Tue, 13 Dec 2011 08:48:10 +0100 Thread-Topic: Draft new version: draft-holmberg-sipcore-proxy-feature-04 Thread-Index: AQHMuPsS1mpPYFZ0PEuNdfMsDm7xhQ== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3BCD862A@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A05852C3BCD862AESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-04 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, 13 Dec 2011 07:48:29 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A05852C3BCD862AESESSCMS0356e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a new version (-04) of draft-holmberg-sipcore-proxy-feature,= which defines a new header field, Feature-Caps, for indicating support of = features. As requested in Taipei, I've added a chapter on information that needs to b= e provided when a feature-tag is registered with IANA. It's based on the te= xt we have for Info Packages. Also note that Hadriel has been added as co-author :) There were some discussions whether we will able to use the existing IANA r= egistry, which we need to further discuss, but I hope that will not stop us= from adopting the draft and moving forward with the solution work. Thanks! Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A05852C3BCD862AESESSCMS0356e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I've submitted a new version (-04) o= f draft-holmberg-sipcore-proxy-feature, which defines a new header field, F= eature-Caps, for indicating support of features.
 
As requested in Taipei, I've ad= ded a chapter on information that needs to be provided when a feature-tag i= s registered with IANA. It's based on the text we have for Info Packages.
 
Also note that Hadriel has been adde= d as co-author :)
 
There were some discussions whether = we will able to use the existing IANA registry, which we need to furth= er discuss, but I hope that will not stop us from adopting the dr= aft and moving forward with the solution work.
 
Thanks!
 
Regards,
 
Christer
--_000_7F2072F1E0DE894DA4B517B93C6A05852C3BCD862AESESSCMS0356e_-- From ivo.sedlacek@ericsson.com Thu Dec 15 05:55:16 2011 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 D0A1921F863E for ; Thu, 15 Dec 2011 05:55:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 8Wz+F6jwpEwp for ; Thu, 15 Dec 2011 05:55:16 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 9240F21F84D6 for ; Thu, 15 Dec 2011 05:55:15 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-31-4ee9fc404149 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 6C.00.09514.04CF9EE4; Thu, 15 Dec 2011 14:55:12 +0100 (CET) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.1.39]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 15 Dec 2011 14:55:12 +0100 From: Ivo Sedlacek To: Christer Holmberg , "sipcore@ietf.org" Date: Thu, 15 Dec 2011 14:55:11 +0100 Thread-Topic: Draft new version: draft-holmberg-sipcore-proxy-feature-04 Thread-Index: AQHMuPsS1mpPYFZ0PEuNdfMsDm7xhZXbeh+A Message-ID: <3A324A65CCACC64289667DFAC0B88E12197548EBFA@ESESSCMS0360.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3BCD862A@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3BCD862A@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_3A324A65CCACC64289667DFAC0B88E12197548EBFAESESSCMS0360e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-04 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, 15 Dec 2011 13:55:17 -0000 --_000_3A324A65CCACC64289667DFAC0B88E12197548EBFAESESSCMS0360e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, As co-author of the draft-holmberg-sipcore-proxy-feature, I support the wor= k and will continue contributing to its progress. I hope we can move the draft-holmberg-sipcore-proxy-feature forward - 3GPP = needs a solution for the use cases identified in the draft-ietf-sipcore-pro= xy-feature-reqs. Kind regards Ivo Sedlacek Ericsson Technology and Portfolio Management, Terminal Standardization Sweden Office: +46 10 711 9382 Fax: +46 10 713 5929 ivo.sedlacek@ericsson.com www.ericsson.com [http://www.ericsson.com/shared/images/Email.gif] This communication is confidential. We only send and receive email on the b= asis of the term set out at www.ericsson.com/email_disclaimer ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Christer Holmberg Sent: 13. prosince 2011 8:48 To: sipcore@ietf.org Subject: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-= 04 Hi, I've submitted a new version (-04) of draft-holmberg-sipcore-proxy-feature,= which defines a new header field, Feature-Caps, for indicating support of = features. As requested in Taipei, I've added a chapter on information that needs to b= e provided when a feature-tag is registered with IANA. It's based on the te= xt we have for Info Packages. Also note that Hadriel has been added as co-author :) There were some discussions whether we will able to use the existing IANA r= egistry, which we need to further discuss, but I hope that will not stop us= from adopting the draft and moving forward with the solution work. Thanks! Regards, Christer --_000_3A324A65CCACC64289667DFAC0B88E12197548EBFAESESSCMS0360e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello,
 
As co-author of the=20 draft-holmberg-sipcore-proxy-feature, I support the work and will continue= =20 contributing to its progress.
 
I hope we can move the=20 draft-holmberg-sipcore-proxy-feature forward - 3GPP needs a solution for th= e use=20 cases identified in the draft-ietf-sipcore-proxy-feature-reqs.
 
Kind regards
 

Ivo Sedlacek= =20


Ericsson
T= echnology=20 and Portfolio Management, Terminal Standardization
Sweden
Office: +4= 6 10=20 711 9382
Fax: +46 10 713=20 5929
ivo.sedlacek@ericsson.com
www.ericsson.com


3D"Ericsson



This=20 communication is confidential. We only send and receive email on the basis = of=20 the term set out at www.ericsson.com/email_di= sclaimer=20

 

From: sipcore-bounces@ietf.org=20 [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer=20 Holmberg
Sent: 13. prosince 2011 8:48
To:=20 sipcore@ietf.org
Subject: [sipcore] Draft new version:=20 draft-holmberg-sipcore-proxy-feature-04

Hi,
 
I've submitted a new version (-04) of=20 draft-holmberg-sipcore-proxy-feature, which defines a new header field,=20 Feature-Caps, for indicating support of features.
 
As requested in Taipei, I've added = a chapter=20 on information that needs to be provided when a feature-tag is registered w= ith=20 IANA. It's based on the text we have for Info Packages.
 
Also note that Hadriel has been added as= =20 co-author :)
 
There were some discussions whether we&n= bsp;will=20 able to use the existing IANA registry, which we need to further discuss, b= ut I=20 hope that will not stop us from adopting the draft and moving for= ward=20 with the solution work.
 
Thanks!
 
Regards,
 
Christer
--_000_3A324A65CCACC64289667DFAC0B88E12197548EBFAESESSCMS0360e_-- From md3135@att.com Thu Dec 15 18:39:02 2011 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 9791321F8B3D for ; Thu, 15 Dec 2011 18:39:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 okvgdz4tLB-s for ; Thu, 15 Dec 2011 18:39:01 -0800 (PST) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id B692E21F867F for ; Thu, 15 Dec 2011 18:39:01 -0800 (PST) X-Env-Sender: md3135@att.com X-Msg-Ref: server-5.tower-120.messagelabs.com!1324003139!53892468!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.4.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17461 invoked from network); 16 Dec 2011 02:38:59 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-5.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Dec 2011 02:38:59 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id pBG2dRtZ027943; Thu, 15 Dec 2011 21:39:27 -0500 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id pBG2dLW6027866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Dec 2011 21:39:23 -0500 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by sflint01.pst.cso.att.com (RSA Interceptor); Thu, 15 Dec 2011 21:38:41 -0500 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([169.254.1.231]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.01.0339.001; Thu, 15 Dec 2011 21:38:41 -0500 From: "DOLLY, MARTIN C" To: Ivo Sedlacek , Christer Holmberg , "sipcore@ietf.org" Thread-Topic: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-04 Thread-Index: AQHMuPsS1mpPYFZ0PEuNdfMsDm7xhZXbeh+AgAJLMEA= Date: Fri, 16 Dec 2011 02:38:40 +0000 Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A05852C3BCD862A@ESESSCMS0356.eemea.ericsson.se> <3A324A65CCACC64289667DFAC0B88E12197548EBFA@ESESSCMS0360.eemea.ericsson.se> In-Reply-To: <3A324A65CCACC64289667DFAC0B88E12197548EBFA@ESESSCMS0360.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.89.36] Content-Type: multipart/alternative; boundary="_000_E42CCDDA6722744CB241677169E83656AD094EMISOUT7MSGUSR9IIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-04 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, 16 Dec 2011 02:39:02 -0000 --_000_E42CCDDA6722744CB241677169E83656AD094EMISOUT7MSGUSR9IIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable AT&T supports this draft moving forward. Thank you Martin Dolly Lead Member Technical Staff Core & Government/Regulatory Standards AT&T Services, Inc. md3135@att.com +1-609-903-3360 From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Ivo Sedlacek Sent: Thursday, December 15, 2011 8:55 AM To: Christer Holmberg; sipcore@ietf.org Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feat= ure-04 Hello, As co-author of the draft-holmberg-sipcore-proxy-feature, I support the wor= k and will continue contributing to its progress. I hope we can move the draft-holmberg-sipcore-proxy-feature forward - 3GPP = needs a solution for the use cases identified in the draft-ietf-sipcore-pro= xy-feature-reqs. Kind regards Ivo Sedlacek Ericsson Technology and Portfolio Management, Terminal Standardization Sweden Office: +46 10 711 9382 Fax: +46 10 713 5929 ivo.sedlacek@ericsson.com www.ericsson.com [Ericsson logo] This communication is confidential. We only send and receive email on the b= asis of the term set out at www.ericsson.com/email_disclaimer ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Christer Holmberg Sent: 13. prosince 2011 8:48 To: sipcore@ietf.org Subject: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-= 04 Hi, I've submitted a new version (-04) of draft-holmberg-sipcore-proxy-feature,= which defines a new header field, Feature-Caps, for indicating support of = features. As requested in Taipei, I've added a chapter on information that needs to b= e provided when a feature-tag is registered with IANA. It's based on the te= xt we have for Info Packages. Also note that Hadriel has been added as co-author :) There were some discussions whether we will able to use the existing IANA r= egistry, which we need to further discuss, but I hope that will not stop us= from adopting the draft and moving forward with the solution work. Thanks! Regards, Christer --_000_E42CCDDA6722744CB241677169E83656AD094EMISOUT7MSGUSR9IIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

AT&T supports this dr= aft moving forward.

 <= /p>

Thank you

 <= /p>

Martin Dolly
Lead Member Technical Staff

Core & Government/Reg= ulatory Standards
AT&T Services, Inc.
md3135@att.com

+1-609-903-3360<= /o:p>

 <= /p>

 <= /p>

 <= /p>

From: sipcore-= bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Ivo Sedlacek
Sent: Thursday, December 15, 2011 8:55 AM
To: Christer Holmberg; sipcore@ietf.org
Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-pro= xy-feature-04

 

Hello,

 

As co-author of the draft-ho= lmberg-sipcore-proxy-feature, I support the work and will continue contribu= ting to its progress.

 

I hope we can move the draft= -holmberg-sipcore-proxy-feature forward - 3GPP needs a solution for the use= cases identified in the draft-ietf-sipcore-proxy-feature-reqs.=

 

Kind regards

 

Ivo Sedlacek


Ericsson
Technology and Portfolio Management, Terminal Standardization
Sweden
Office: +46 10 711 9382
Fax: +46 10 713 5929
ivo.sedlacek@ericsson.com
www.ericsson.com


3D"Ericsson



This communication is confidential. We only send and receive email on the b= asis of the term set out at www.ericsson.com/email= _disclaimer

 

 

From:<= /span> sipcore-bounces@ietf.org [mailto:sipcore-bounces@iet= f.org] On Behalf Of Christer Holmberg
Sent: 13. prosince 2011 8:48
To: sipcore@ietf.org
Subject: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-f= eature-04

Hi,

 

I've submitted a new version= (-04) of draft-holmberg-sipcore-proxy-feature, which defines a new header = field, Feature-Caps, for indicating support of features.<= /p>

 

As requested in Taipei,= I've added a chapter on information that needs to be provided when a featu= re-tag is registered with IANA. It's based on the text we have for Info Packages.

 

Also note that Hadriel has b= een added as co-author :)

 

There were some discussions = whether we will able to use the existing IANA registry, which we need = to further discuss, but I hope that will not stop us from adoptin= g the draft and moving forward with the solution work.

 

Thanks!

 

Regards,

 

Christer

--_000_E42CCDDA6722744CB241677169E83656AD094EMISOUT7MSGUSR9IIT_-- From R.Jesske@telekom.de Thu Dec 15 23:10:45 2011 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 9274121F86DD for ; Thu, 15 Dec 2011 23:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 E-bN8lk0unn1 for ; Thu, 15 Dec 2011 23:10:44 -0800 (PST) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0144621F85A7 for ; Thu, 15 Dec 2011 23:10:43 -0800 (PST) Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 16 Dec 2011 08:10:29 +0100 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.93]) by HE110889.emea1.cds.t-internal.com ([fe80::841f:f92c:15ca:8526%16]) with mapi; Fri, 16 Dec 2011 08:10:29 +0100 From: To: , , , Date: Fri, 16 Dec 2011 08:10:27 +0100 Thread-Topic: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-04 Thread-Index: AQHMuPsS1mpPYFZ0PEuNdfMsDm7xhZXbeh+AgAJLMECAAExCEA== Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D0A6261FB9A@HE111648.emea1.cds.t-internal.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C3BCD862A@ESESSCMS0356.eemea.ericsson.se> <3A324A65CCACC64289667DFAC0B88E12197548EBFA@ESESSCMS0360.eemea.ericsson.se> In-Reply-To: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_580BEA5E3B99744AB1F5BFF5E9A3C67D0A6261FB9AHE111648emea1_" MIME-Version: 1.0 Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-04 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, 16 Dec 2011 07:10:45 -0000 --_000_580BEA5E3B99744AB1F5BFF5E9A3C67D0A6261FB9AHE111648emea1_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Roland ________________________________ Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im Auftrag = von DOLLY, MARTIN C Gesendet: Freitag, 16. Dezember 2011 03:39 An: Ivo Sedlacek; Christer Holmberg; sipcore@ietf.org Betreff: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feat= ure-04 AT&T supports this draft moving forward. Thank you Martin Dolly Lead Member Technical Staff Core & Government/Regulatory Standards AT&T Services, Inc. md3135@att.com +1-609-903-3360 From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Ivo Sedlacek Sent: Thursday, December 15, 2011 8:55 AM To: Christer Holmberg; sipcore@ietf.org Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feat= ure-04 Hello, As co-author of the draft-holmberg-sipcore-proxy-feature, I support the wor= k and will continue contributing to its progress. I hope we can move the draft-holmberg-sipcore-proxy-feature forward - 3GPP = needs a solution for the use cases identified in the draft-ietf-sipcore-pro= xy-feature-reqs. Kind regards Ivo Sedlacek Ericsson Technology and Portfolio Management, Terminal Standardization Sweden Office: +46 10 711 9382 Fax: +46 10 713 5929 ivo.sedlacek@ericsson.com www.ericsson.com [http://www.ericsson.com/shared/images/Email.gif] This communication is confidential. We only send and receive email on the b= asis of the term set out at www.ericsson.com/email_disclaimer ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Christer Holmberg Sent: 13. prosince 2011 8:48 To: sipcore@ietf.org Subject: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-= 04 Hi, I've submitted a new version (-04) of draft-holmberg-sipcore-proxy-feature,= which defines a new header field, Feature-Caps, for indicating support of = features. As requested in Taipei, I've added a chapter on information that needs to b= e provided when a feature-tag is registered with IANA. It's based on the te= xt we have for Info Packages. Also note that Hadriel has been added as co-author :) There were some discussions whether we will able to use the existing IANA r= egistry, which we need to further discuss, but I hope that will not stop us= from adopting the draft and moving forward with the solution work. Thanks! Regards, Christer --_000_580BEA5E3B99744AB1F5BFF5E9A3C67D0A6261FB9AHE111648emea1_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
+1
 
Roland

Von: sipcore-bounces@ietf.org=20 [mailto:sipcore-bounces@ietf.org] Im Auftrag von DOLLY, MARTIN=20 C
Gesendet: Freitag, 16. Dezember 2011 03:39
An: Ivo=20 Sedlacek; Christer Holmberg; sipcore@ietf.org
Betreff: Re: [sipco= re]=20 Draft new version: draft-holmberg-sipcore-proxy-feature-04

AT&T=20 supports this draft moving forward.

 

Thank=20 you

 

Martin=20 Dolly
Lead Member Technical Staff

Core=20 & Government/Regulatory Standards

md3135@att.com<= o:p>

+1-609-903-3360

 

 

 

From:<= /B>=20 sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of= =20 Ivo Sedlacek
Sent: Thursday, December 15, 2011 8:55=20 AM
To: Christer Holmberg; sipcore@ietf.org
Subject: Re:= =20 [sipcore] Draft new version:=20 draft-holmberg-sipcore-proxy-feature-04

 

Hello,

 

As=20 co-author of the draft-holmberg-sipcore-proxy-feature, I support the work a= nd=20 will continue contributing to its progress.

 

I hope=20 we can move the draft-holmberg-sipcore-proxy-feature forward - 3GPP needs a= =20 solution for the use cases identified in the=20 draft-ietf-sipcore-proxy-feature-reqs.

 

Kind=20 regards

 





This=20 communication is confidential. We only send and receive email on the basis = of=20 the term set out at www.ericsson.com/email_di= sclaimer=20

 

 

From:<= /B>=20 sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of= =20 Christer Holmberg
Sent: 13. prosince 2011 8:48
To:= =20 sipcore@ietf.org
Subject: [sipcore] Draft new version:=20 draft-holmberg-sipcore-proxy-feature-04

Hi,

 

I've=20 submitted a new version (-04) of draft-holmberg-sipcore-proxy-feature, whic= h=20 defines a new header field, Feature-Caps, for indicating support of=20 features.

 

As=20 requested in Taipei, I've added a chapter on information that needs to= be=20 provided when a feature-tag is registered with IANA. It's based on the text= we=20 have for Info Packages.

 

Also=20 note that Hadriel has been added as co-author :)

 

There=20 were some discussions whether we will able to use the existing IANA=20 registry, which we need to further discuss, but I hope that will not s= top=20 us from adopting the draft and moving forward with the solution=20 work.

 

Thanks!

 

Regards,

 

Christer

--_000_580BEA5E3B99744AB1F5BFF5E9A3C67D0A6261FB9AHE111648emea1_-- From peter.leis@nsn.com Fri Dec 16 02:35:30 2011 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 4DCEB21F8B1D for ; Fri, 16 Dec 2011 02:35:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 DpoerTZkoT68 for ; Fri, 16 Dec 2011 02:35:29 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 855FE21F8B0F for ; Fri, 16 Dec 2011 02:35:28 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pBGAZMpL032298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Dec 2011 11:35:22 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pBGAZMnf002321; Fri, 16 Dec 2011 11:35:22 +0100 Received: from DEMUEXC035.nsn-intra.net ([10.150.128.26]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Dec 2011 11:35:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCBBDE.68F438DA" Date: Fri, 16 Dec 2011 11:35:19 +0100 Message-ID: <79C4240C13B4C84B910850B96B1B431203895017@DEMUEXC035.nsn-intra.net> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D0A6261FB9A@HE111648.emea1.cds.t-internal.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Draftnew version: draft-holmberg-sipcore-proxy-feature-04 Thread-Index: AQHMuPsS1mpPYFZ0PEuNdfMsDm7xhZXbeh+AgAJLMECAAExCEIAAOSUA References: <7F2072F1E0DE894DA4B517B93C6A05852C3BCD862A@ESESSCMS0356.eemea.ericsson.se><3A324A65CCACC64289667DFAC0B88E12197548EBFA@ESESSCMS0360.eemea.ericsson.se> <580BEA5E3B99744AB1F5BFF5E9A3C67D0A6261FB9A@HE111648.emea1.cds.t-internal.com> From: "Leis, Peter (NSN - DE/Munich)" To: , , , , X-OriginalArrivalTime: 16 Dec 2011 10:35:22.0214 (UTC) FILETIME=[69FBB860:01CCBBDE] Subject: Re: [sipcore] Draftnew version: draft-holmberg-sipcore-proxy-feature-04 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, 16 Dec 2011 10:35:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCBBDE.68F438DA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 =20 Peter =20 From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of ext R.Jesske@telekom.de Sent: Friday, December 16, 2011 8:10 AM To: md3135@att.com; ivo.sedlacek@ericsson.com; christer.holmberg@ericsson.com; sipcore@ietf.org Subject: Re: [sipcore] Draftnew version: draft-holmberg-sipcore-proxy-feature-04 =20 +1 =20 Roland =20 ________________________________ Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im Auftrag von DOLLY, MARTIN C Gesendet: Freitag, 16. Dezember 2011 03:39 An: Ivo Sedlacek; Christer Holmberg; sipcore@ietf.org Betreff: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-04 AT&T supports this draft moving forward. =20 Thank you =20 Martin Dolly Lead Member Technical Staff Core & Government/Regulatory Standards AT&T Services, Inc. md3135@att.com =20 +1-609-903-3360 =20 =20 =20 From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Ivo Sedlacek Sent: Thursday, December 15, 2011 8:55 AM To: Christer Holmberg; sipcore@ietf.org Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-04 =20 Hello, =20 As co-author of the draft-holmberg-sipcore-proxy-feature, I support the work and will continue contributing to its progress.=20 =20 I hope we can move the draft-holmberg-sipcore-proxy-feature forward - 3GPP needs a solution for the use cases identified in the draft-ietf-sipcore-proxy-feature-reqs. =20 Kind regards =20 Ivo Sedlacek=20 Ericsson Technology and Portfolio Management, Terminal Standardization=20 Sweden Office: +46 10 711 9382 Fax: +46 10 713 5929 ivo.sedlacek@ericsson.com www.ericsson.com Ericsson logo=20 This communication is confidential. We only send and receive email on the basis of the term set out at www.ericsson.com/email_disclaimer=20 =20 =20 ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 13. prosince 2011 8:48 To: sipcore@ietf.org Subject: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-04 Hi, =20 I've submitted a new version (-04) of draft-holmberg-sipcore-proxy-feature, which defines a new header field, Feature-Caps, for indicating support of features. =20 As requested in Taipei, I've added a chapter on information that needs to be provided when a feature-tag is registered with IANA. It's based on the text we have for Info Packages. =20 Also note that Hadriel has been added as co-author :) =20 There were some discussions whether we will able to use the existing IANA registry, which we need to further discuss, but I hope that will not stop us from adopting the draft and moving forward with the solution work. =20 Thanks! =20 Regards, =20 Christer ------_=_NextPart_001_01CCBBDE.68F438DA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1

 

Peter

 

From:= = sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of ext R.Jesske@telekom.de
Sent: Friday, December 16, 2011 = 8:10 AM
To: md3135@att.com; ivo.sedlacek@ericsson.com; = christer.holmberg@ericsson.com; sipcore@ietf.org
Subject: Re: = [sipcore] Draftnew version: = draft-holmberg-sipcore-proxy-feature-04

=

 

+1=

 

Ro= land

 

Von:<= /b> = sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im Auftrag = von DOLLY, MARTIN C
Gesendet: Freitag, 16. Dezember 2011 = 03:39
An: Ivo Sedlacek; Christer Holmberg; = sipcore@ietf.org
Betreff: Re: [sipcore] Draft new version: = draft-holmberg-sipcore-proxy-feature-04

AT&T supports this draft moving forward.

 

Thank you

 

Martin Dolly
Lead Member Technical Staff

Core & Government/Regulatory Standards
AT&T Services, Inc.
md3135@att.com

+1-609-903-3360

 

 

 

From:= = sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Ivo Sedlacek
Sent: Thursday, December 15, 2011 8:55 = AM
To: Christer Holmberg; sipcore@ietf.org
Subject: = Re: [sipcore] Draft new version: = draft-holmberg-sipcore-proxy-feature-04

=

 

= Hello,

 

= As co-author of the draft-holmberg-sipcore-proxy-feature, I support the = work and will continue contributing to its progress. =

 

= I hope we can move the draft-holmberg-sipcore-proxy-feature forward - = 3GPP needs a solution for the use cases identified in the = draft-ietf-sipcore-proxy-feature-reqs.

 

= Kind regards

 

Ivo Sedlacek


Ericsson
Technology and Portfolio Management, Terminal = Standardization
Sweden
Office: +46 10 711 9382
Fax: +46 10 713 = 5929
ivo.sedlacek@ericsson.com
www.ericsson.com


3D"Ericsson

=

This communication is confidential. We only send and receive = email on the basis of the term set out at www.ericsson.com/email_= disclaimer

 

 

From:= = sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Christer Holmberg
Sent: 13. prosince 2011 = 8:48
To: sipcore@ietf.org
Subject: [sipcore] Draft = new version: = draft-holmberg-sipcore-proxy-feature-04

= Hi,

=  

= I've submitted a new version (-04) of = draft-holmberg-sipcore-proxy-feature, which defines a new header field, = Feature-Caps, for indicating support of = features.

=  

= As requested in Taipei, I've added a chapter on information that = needs to be provided when a feature-tag is registered with IANA. It's = based on the text we have for Info = Packages.

=  

= Also note that Hadriel has been added as co-author = :)

=  

= There were some discussions whether we will able to use the = existing IANA registry, which we need to further discuss, but I hope = that will not stop us from adopting the draft and moving = forward with the solution work.

=  

= Thanks!

=  

= Regards,

=  

= Christer

------_=_NextPart_001_01CCBBDE.68F438DA-- From laura.liess.dt@googlemail.com Fri Dec 16 07:18:09 2011 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 36CF521F8B3F for ; Fri, 16 Dec 2011 07:18:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 7wgFR2GTdDJu for ; Fri, 16 Dec 2011 07:18:08 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id B281A21F8B44 for ; Fri, 16 Dec 2011 07:18:07 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so4942939wgb.13 for ; Fri, 16 Dec 2011 07:18:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=kWA5ib3b0KhArA7NhbnYvl53NtGghNLnbArxThnpC+w=; b=vwaTJOz47kpoHKkijJJuMU0KL3GRfU2i74GFw7cd45u5yyPfyPKYaQLhNo6dgbu6o2 /hsczmmuHcKkeXY58l/eOsZw4JiL1dxPh9KGdrdC5mO3XOnrhtqsu/NKa8x5Ujs7fR1z SMbW3aQ35FKLJuKzq3p/zlLIfpXLC0JiB/UUU= MIME-Version: 1.0 Received: by 10.216.135.19 with SMTP id t19mr3083222wei.16.1324048686749; Fri, 16 Dec 2011 07:18:06 -0800 (PST) Received: by 10.227.202.141 with HTTP; Fri, 16 Dec 2011 07:18:06 -0800 (PST) In-Reply-To: <79C4240C13B4C84B910850B96B1B431203895017@DEMUEXC035.nsn-intra.net> References: <7F2072F1E0DE894DA4B517B93C6A05852C3BCD862A@ESESSCMS0356.eemea.ericsson.se> <3A324A65CCACC64289667DFAC0B88E12197548EBFA@ESESSCMS0360.eemea.ericsson.se> <580BEA5E3B99744AB1F5BFF5E9A3C67D0A6261FB9A@HE111648.emea1.cds.t-internal.com> <79C4240C13B4C84B910850B96B1B431203895017@DEMUEXC035.nsn-intra.net> Date: Fri, 16 Dec 2011 16:18:06 +0100 Message-ID: From: Laura Liess To: ivo.sedlacek@ericsson.com, christer.holmberg@ericsson.com, sipcore@ietf.org Content-Type: multipart/alternative; boundary=0016e6d62330a39b0104b4371b18 Subject: Re: [sipcore] Draftnew version: draft-holmberg-sipcore-proxy-feature-04 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, 16 Dec 2011 15:18:09 -0000 --0016e6d62330a39b0104b4371b18 Content-Type: text/plain; charset=ISO-8859-1 I support moving forward with the draft. Laura 2011/12/16 Leis, Peter (NSN - DE/Munich) > +1**** > > ** ** > > Peter**** > > ** ** > > *From:* sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] *On > Behalf Of *ext R.Jesske@telekom.de > *Sent:* Friday, December 16, 2011 8:10 AM > *To:* md3135@att.com; ivo.sedlacek@ericsson.com; > christer.holmberg@ericsson.com; sipcore@ietf.org > *Subject:* Re: [sipcore] Draftnew version: > draft-holmberg-sipcore-proxy-feature-04**** > > ** ** > > +1**** > > **** > > Roland**** > > ** ** > ------------------------------ > > *Von:* sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] *Im > Auftrag von *DOLLY, MARTIN C > *Gesendet:* Freitag, 16. Dezember 2011 03:39 > *An:* Ivo Sedlacek; Christer Holmberg; sipcore@ietf.org > *Betreff:* Re: [sipcore] Draft new version: > draft-holmberg-sipcore-proxy-feature-04**** > > AT&T supports this draft moving forward.**** > > ** ** > > Thank you**** > > ** ** > > Martin Dolly > Lead Member Technical Staff**** > > Core & Government/Regulatory Standards > AT&T Services, Inc. > md3135@att.com**** > > +1-609-903-3360**** > > ** ** > > ** ** > > ** ** > > *From:* sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] *On > Behalf Of *Ivo Sedlacek > *Sent:* Thursday, December 15, 2011 8:55 AM > *To:* Christer Holmberg; sipcore@ietf.org > *Subject:* Re: [sipcore] Draft new version: > draft-holmberg-sipcore-proxy-feature-04**** > > ** ** > > Hello,**** > > **** > > As co-author of the draft-holmberg-sipcore-proxy-feature, I support the > work and will continue contributing to its progress. **** > > **** > > I hope we can move the draft-holmberg-sipcore-proxy-feature forward - 3GPP > needs a solution for the use cases identified in the > draft-ietf-sipcore-proxy-feature-reqs.**** > > **** > > Kind regards**** > > **** > > *Ivo Sedlacek ***** > > > Ericsson > Technology and Portfolio Management, Terminal Standardization > Sweden > Office: +46 10 711 9382 > Fax: +46 10 713 5929 > ivo.sedlacek@ericsson.com > www.ericsson.com**** > > > [image: Ericsson logo]**** > > > > This communication is confidential. We only send and receive email on the > basis of the term set out at www.ericsson.com/email_disclaimer **** > > **** > > ** ** > ------------------------------ > > *From:* sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] *On > Behalf Of *Christer Holmberg > *Sent:* 13. prosince 2011 8:48 > *To:* sipcore@ietf.org > *Subject:* [sipcore] Draft new version: > draft-holmberg-sipcore-proxy-feature-04**** > > Hi,**** > > **** > > I've submitted a new version (-04) of > draft-holmberg-sipcore-proxy-feature, which defines a new header field, > Feature-Caps, for indicating support of features.**** > > **** > > As requested in Taipei, I've added a chapter on information that needs to > be provided when a feature-tag is registered with IANA. It's based on the > text we have for Info Packages.**** > > **** > > Also note that Hadriel has been added as co-author :)**** > > **** > > There were some discussions whether we will able to use the existing IANA > registry, which we need to further discuss, but I hope that will not stop > us from adopting the draft and moving forward with the solution work.**** > > **** > > Thanks!**** > > **** > > Regards,**** > > **** > > Christer**** > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > --0016e6d62330a39b0104b4371b18 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I support moving forward with the draft.

Laura

2011/12/16 Leis, Peter (NSN - DE/Munich) &l= t;peter.leis@nsn.com>

+1

=A0

Peter

=A0

=A0

+1

=A0

Roland

= =A0

Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf= .org] Im Auftrag von DOLLY, MARTIN C
Gesendet: Freitag, 16. Dezember 2011 03:39
An: Ivo Sedlace= k; Christer Holmberg; sipcore@ietf.org
Betreff: Re: [sipcore] Draft new version: d= raft-holmberg-sipcore-proxy-feature-04

AT&T supports this dr= aft moving forward.

=A0

Thank you

=A0

Martin Dolly
Lead Memb= er Technical Staff

Core & Government/Regulatory Standards
AT&T Services, Inc.
md3135@att.com

+1-609-903-3360

=A0<= /p>

=A0

=A0<= /p>

From: sipcore-bounces@ietf= .org [mailto:sipcore-bounces@ietf.org] On Behalf Of Ivo Sedlacek
Sent: Thursday, December 15, 2011 8:55 AM
To: Christer Hol= mberg; sipcore@ietf.o= rg
Subject: Re: [sipcore] Draft new version: draft-holmberg-s= ipcore-proxy-feature-04

=A0

Hello,

=

=A0

As co-author of the draft-holmberg-sipcore-proxy-feature, I support the= work and will continue contributing to its progress. =

=A0

I hope we can move the draft-holmber= g-sipcore-proxy-feature forward - 3GPP needs a solution for the use cases i= dentified in the draft-ietf-sipcore-proxy-feature-reqs.

=A0

Kind regards

=A0

Ivo Sedlacek


Ericsson
Technology and Portfolio Management, Terminal Sta= ndardization
Sweden
Office: +46 10 711 9382
Fax: +46 10 713 5929
ivo.se= dlacek@ericsson.com
www.ericsson.com<= /span>


3D"Ericsson

<= p class=3D"MsoNormal">

This communication is= confidential. We only send and receive email on the basis of the term set = out at www.ericsson.com/email_disclaimer

=A0

=A0

From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf= .org] On Behalf Of Christer Holmberg
Sent: 13. prosince 2011 8:48
To: sipcore@ietf.org
Subject: [sipco= re] Draft new version: draft-holmberg-sipcore-proxy-feature-04

Hi,<= /span>

=A0<= /u>

I've submitte= d a new version (-04) of draft-holmberg-sipcore-proxy-feature, which define= s a new header field, Feature-Caps, for indicating support of features.<= /u>

=A0=

As req= uested=A0in Taipei, I've added a chapter on information that needs to b= e provided when a feature-tag is registered with IANA. It's based on th= e text we have for Info Packages.

=A0=

Also n= ote that Hadriel has been added as co-author :)

=A0=

There = were some discussions whether we=A0will able to use the existing IANA regis= try, which we need to further discuss, but I hope that will not=A0stop us f= rom=A0adopting the draft and moving forward with the solution work.<= u>

=A0=

Thanks= !

=A0=

Regard= s,

=A0=

Christ= er


___________________________________= ____________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore


--0016e6d62330a39b0104b4371b18--