From gonzalo.camarillo@ericsson.com Wed Jul 4 03:00:03 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C4921F8810 for ; Wed, 4 Jul 2012 03:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.214 X-Spam-Level: X-Spam-Status: No, score=-106.214 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id saxjOdku-LaI for ; Wed, 4 Jul 2012 03:00:03 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id A7A5C21F8807 for ; Wed, 4 Jul 2012 03:00:02 -0700 (PDT) X-AuditID: c1b4fb30-b7fb46d0000064f2-0a-4ff4142b004e Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id F5.FC.25842.B2414FF4; Wed, 4 Jul 2012 12:00:12 +0200 (CEST) Received: from [131.160.36.52] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.264.0; Wed, 4 Jul 2012 11:59:57 +0200 Message-ID: <4FF4141D.6010302@ericsson.com> Date: Wed, 4 Jul 2012 12:59:57 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "dispatch@ietf.org" References: <20111202210806.7950.76133.idtracker@ietfa.amsl.com> <4EDA6648.2040109@alum.mit.edu> <155970D1DA8E174F9E46039E10E2AA3512B06B@XMB104ADS.rim.net> <155970D1DA8E174F9E46039E10E2AA35132AE9@XMB104ADS.rim.net> <155970D1DA8E174F9E46039E10E2AA351429AC@XMB104ADS.rim.net> <4F8EA090.1010400@ericsson.com> <155970D1DA8E174F9E46039E10E2AA3516DCCA@XMB104ADS.rim.net> <18372A69-0835-4E41-882E-B8D1F229F316@iii.ca> <8D9E58E6-3098-48DF-B752-B6D12146EB82@iii.ca> In-Reply-To: <8D9E58E6-3098-48DF-B752-B6D12146EB82@iii.ca> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphluLIzCtJLcpLzFFi42KZGfG3VldH5Iu/wZ25XBZLJy1gdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxv5z1gW7mCoObetla2D8zdjFyMkhIWAisaL3FCuELSZx4d56 ti5GLg4hgVOMEpd+X4dyVjFKrHiwkb2LkYODV0BbYvvjHJAGFgEVidePt7OD2GwCFhJbbt1n AbFFBYIl5nXfBLN5BQQlTs58AmaLALUeXdXFDGILC3hJvL3bzgZiCwk0s0g0z3AAGc8pYCXR /kQC4h5JiXvtq8FKmAX0JKZcbWGEsOUltr+dwwzRqi2x/FkLywRGwVlIts1C0jILScsCRuZV jMK5iZk56eXmeqlFmcnFxfl5esWpmxiBIXlwy2+DHYyb7osdYpTmYFES59VT3e8vJJCeWJKa nZpakFoUX1Sak1p8iJGJg1OqgfH0oZhEvhvtE/k3510/e6SObbeS1v2zle3+KxTfxF/ccmuq ydSHz5Z6hZ2/Y/Vc7OxBPj+WcObwBNanOl865278vILHNM+i4Xt3a9WZb9POtL1a0KVps9aD 8f21tWZl797fKKhjrFW+kt6TV5BUeKPv4cXjK31LxK8/fnZWRqH87z6LfhtuzwtKLMUZiYZa zEXFiQDIETpLFwIAAA== Subject: Re: [dispatch] draft-bakker-sipping-3gpp-ims-xml-body-handling-07 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 10:00:03 -0000 Folks, this thread has died without a clear conclusion. Interestingly, one of the comments was about the unresponsiveness of the editors of the draft when addressing comments. If there is not enough energy around this piece of work, it will be impossible to make any type of progress. Cheers, Gonzalo From gonzalo.camarillo@ericsson.com Thu Jul 5 01:06:50 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5AD321F85C7 for ; Thu, 5 Jul 2012 01:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.919 X-Spam-Level: X-Spam-Status: No, score=-105.919 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_102=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 T2oqLik7icGf for ; Thu, 5 Jul 2012 01:06:49 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0E82821F85C4 for ; Thu, 5 Jul 2012 01:06:48 -0700 (PDT) X-AuditID: c1b4fb25-b7fc16d000005db2-10-4ff54b24f16a Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 49.2F.23986.42B45FF4; Thu, 5 Jul 2012 10:07:00 +0200 (CEST) Received: from [131.160.126.161] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.264.0; Thu, 5 Jul 2012 10:07:00 +0200 Message-ID: <4FF54B23.4040601@ericsson.com> Date: Thu, 5 Jul 2012 11:06:59 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "dispatch@ietf.org" References: <20120626162244.16515.97970.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDLMWRmVeSWpSXmKPExsUyM+Jvra6K91d/gycTdS2WTlrAavFndwej A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJWxvP0da8Ey3YrT53YzNTAeUOli5OCQEDCR 2HOovIuRE8gUk7hwbz1bFyMXh5DAKUaJX/MXM0M4axgljk9YxQrSwCugLfFmnhFIA4uAisSH lWvZQWw2AQuJLbfus4DYogLBEvO6b4LZvAKCEidnPgGzRYBaj67qYgaxmQUsJS4cvgcWFxbI kXgw+yw7xK42RolFB7aBDeUUCJT49vgqI8R1khL32lezQTRrSrRu/80OYctLbH87B2yoENCC 5c9aWCYwCs1CsnsWkpZZSFoWMDKvYhTOTczMSS830kstykwuLs7P0ytO3cQIDOGDW36r7mC8 c07kEKM0B4uSOK/11j3+QgLpiSWp2ampBalF8UWlOanFhxiZODilGhgtkm6G332hULc7Xr0j f8nav+/Wxe28uHrW3vKdghxp2zs4dhU73GmeObXGdCvLi5rsZJ+VL17ePBTXW8wk3P3u3znR iKBj1UFnPZhSHNZ2/F240ujbtXPbpgXn/X+prnux4c/7/0djFiUdfnJ0o2ScwsWgE50ulwIe CP9z2H/okPPhyuhV/zXElViKMxINtZiLihMBfHkmQi8CAAA= Subject: Re: [dispatch] Fwd: [new-work] WG Review: Sip Traversal Required for Applications to Work (straw) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 08:06:50 -0000 Folks, the IESG will discuss the chartering of this new WG this evening. In the mean time, you may want to subscribe to the newly created mailing list for the WG. https://www.ietf.org/mailman/listinfo/straw Cheers, Gonzalo On 26/06/2012 8:06 PM, Victor Pascual Avila wrote: > FYI > > ---------- Forwarded message ---------- > From: IESG Secretary > Date: Tue, Jun 26, 2012 at 6:22 PM > Subject: [new-work] WG Review: Sip Traversal Required for Applications > to Work (straw) > To: new-work@ietf.org > > > A new IETF working group has been proposed in the Real-time Applications > and Infrastructure Area. The IESG has not made any determination yet. The > following draft charter was submitted, and is provided for informational > purposes only. Please send your comments to the IESG mailing list (iesg > at ietf.org) by 2012-07-03. > > Sip Traversal Required for Applications to Work (straw) > ------------------------------------------------ > Current Status: Proposed Working Group > > Assigned Area Director: > Gonzalo Camarillo > > > Charter of Working Group: > > Problem Statement: > > Within the context of the SIP protocol and architecture, a > Back-to-Back User Agent (B2BUA) is any SIP device in the logical path > between two User Agents performing a role beyond that of a Proxy as > defined in RFC 3261. The B2BUA may be as simple as a session-stateful > Proxy becoming a B2BUA in order to terminate dead sessions by > generating BYEs; or it may be a 3PCC-style agent only modifying SDP; > or it may be a Session Border Controller performing such functions as > in RFC 5853; or it may be an Enterprise PBX terminating REFERs and > such; or it may be a complete UAS and UAC implementation with a PRI > (Primary Rate Interface) loopback in-between. > > In its most extreme form, the scope of the SIP protocol ends at the > UAS of the B2BUA, and a new SIP protocol scope begins on its UAC side. > In practice, however, users expect some SIP protocol aspects to go > beyond the scope of the B2BUA's UAS side, and be traversed onto its > UAC side, as if the B2BUA was not an end unto itself; this is similar > to the expectation that emails work when they cross from POP and IMAP > to/from SMTP. > > It is impossible to normatively define all the behaviors of B2BUAs in > general, or even subsets of them such as SBCs (Session Border > Controlers)or PBXs (Private Branch Exchanges). Unlike consumer NATs, > B2BUAs perform widely varying functions for purposes which may be > unique to their environment, unique to their architecture, or unique > to the wishes of their administrator. Instead of defining all things > a given type of B2BUA must do, a more practical objective would be to > define what very few things any B2BUA must do to make a specific SIP > mechanism work, and let the market decide whether to do those things. > > The name of this working group reflects that practical objective: if > there were a thin straw between the SIP UAS and UAC of a B2BUA, what > must be passed through that straw and used on each side. Or viewed > another way, if a B2BUA were in fact a UAS and UAC connected with a > PRI loopback circuit, and if we could extend ISDN, what information > would we carry in ISDN across the PRI for a specific SIP mechanism to > work end-to-end. > > For example, the WG could produce a document which specifies that the > Max-Forwards header field value should be copied and decremented > across the B2BUA, if the B2BUA wishes to prevent infinite > loops. Administrators could then tell their B2BUA vendors to comply > with the document, if the administrator so wishes. > > > Objectives: > > The objectives of the STRAW Working Group are to publish normative > documents which define which SIP header fields, parameters, MIME > bodies, body content fields/information, or media-plane > characteristics are required to traverse between the User Agent > "sides" of a B2BUA for specific functions to work. > > The specific functions covered are expected to relate to > already-published RFCs or existing RAI area work, as opposed to all > future IETF work. In other words, the Working Group is not meant to > be a never-ending source for B2BUA requirements in the RAI area. > > Deliverables would indicate which types of B2BUAs would apply or not. > For example, a document defining the requirements for end-to-end > DTLS-SRTP would not apply to B2BUAs which terminate media, such as > transcoders or recorders. > > Milestones: > Dec 2012 - A taxonomy document defining role-types of B2BUAs, as a > reference for other deliverables submitted to the IESG as Informational > Apr 2013 - A document defining the requirements for B2BUAs with respect > to loop detection/prevention submitted to the IESG as PS > Aug 2013 - A document defining the requirements for B2BUAs to support > end-to-end and hop-by-hop media-loopback test calls submitted to the IESG > as PS > Dec 2013 - A document defining the requirements for B2BUAs to support > DTLS-SRTP (RFC 5764) end-to-end submitted to the IESG as PS > Dec 2013 - A document defining the requirements for B2BUAs to support > STUN message transactions end-to-end submitted to the IESG as PS > Dec 2013 - A document defining the requirements for B2BUAs to support > RTCP end-to-end submitted to the IESG as PS > > > _______________________________________________ > new-work mailing list > new-work@ietf.org > https://www.ietf.org/mailman/listinfo/new-work > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From prvs=5533fbc1e4=jbakker@rim.com Thu Jul 5 07:21:28 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF6421F86B5 for ; Thu, 5 Jul 2012 07:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 78fRmpkvZx1d for ; Thu, 5 Jul 2012 07:21:27 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1AE21F86B3 for ; Thu, 5 Jul 2012 07:21:26 -0700 (PDT) X-AuditID: 0a41282f-b7f0e6d000001e78-3f-4ff5a2f36e5b Received: from XCT102CNC.rim.net (xct102cnc.rim.net [10.65.161.202]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs060cnc.rim.net (SBG) with SMTP id 08.C9.07800.3F2A5FF4; Thu, 5 Jul 2012 14:21:39 +0000 (GMT) Received: from XCT103ADS.rim.net (10.67.111.44) by XCT102CNC.rim.net (10.65.161.202) with Microsoft SMTP Server (TLS) id 14.2.298.4; Thu, 5 Jul 2012 10:21:38 -0400 Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT103ADS.rim.net ([fe80::c8f6:ae2e:c42b:3614%21]) with mapi id 14.02.0298.004; Thu, 5 Jul 2012 09:21:37 -0500 From: John-Luc Bakker To: Gonzalo Camarillo , "dispatch@ietf.org" Thread-Topic: [dispatch] draft-bakker-sipping-3gpp-ims-xml-body-handling-07 Thread-Index: AQHNHVOLGaoZosgWp06CrMLzAfa1kZbLjn1AgBjrSQCAACmKgIALMfOAgCnbcICAAYcccA== Date: Thu, 5 Jul 2012 14:21:36 +0000 Message-ID: <155970D1DA8E174F9E46039E10E2AA351A28B4@XMB104ADS.rim.net> References: <20111202210806.7950.76133.idtracker@ietfa.amsl.com> <4EDA6648.2040109@alum.mit.edu> <155970D1DA8E174F9E46039E10E2AA3512B06B@XMB104ADS.rim.net> <155970D1DA8E174F9E46039E10E2AA35132AE9@XMB104ADS.rim.net> <155970D1DA8E174F9E46039E10E2AA351429AC@XMB104ADS.rim.net> <4F8EA090.1010400@ericsson.com> <155970D1DA8E174F9E46039E10E2AA3516DCCA@XMB104ADS.rim.net> <18372A69-0835-4E41-882E-B8D1F229F316@iii.ca> <8D9E58E6-3098-48DF-B752-B6D12146EB82@iii.ca> <4FF4141D.6010302@ericsson.com> In-Reply-To: <4FF4141D.6010302@ericsson.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.253] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMKsWRmVeSWpSXmKPExsXC5bjwlO7nRV/9DZ4tlrBYOmkBq8Wm5SuZ HJg8fn29yuaxZMlPpgCmqAZGm6TEkrLgzPQ8fTubxLy8/JLEklSFlNTiZFsln9T0xByFgKLM ssTkSgWXzOLknMTM3NQiJYXMFFslEyWFgpzE5NTc1LwSW6XEgoLUvBQlOy4FDGADVJaZp5Ca l5yfkpmXbqvkGeyva2FhaqlrqGSnm9DJk/H57BTWgkdsFSfe7mJvYLzA2sXIySEhYCLx7NhC dghbTOLCvfVsXYxcHEICfUwST09vYYRwljNK7J3fyQ7hbGKUeHx5MVg7m4C6xNYV25lBbBGB RIldH98ygdjCAl4Sq7+1MELEvSVO7JwNZYdJHJg6GayeRUBFYub1lSwgNq+Am8S+x4tZIBZs ZZHY3/YBLMEpoCPR+bED7D5GAVmJ3Wevgy1gFhCXuPVkPhPE3QISS/acZ4awRSVePv4H9Zui xN+931kh6nUkFuz+xAZha0ssW/iaGWKxoMTJmU/AdgkJyEi0tu1im8AoPgvJillI2mchaZ+F pH0BI8sqRsHcjGIDM4PkvGS9osxcvbzUkk2M4CSiob+DsW+v1iFGAQ5GJR7ek9O++guxJpYV V+YeYpTgYFYS4e3NAArxpiRWVqUW5ccXleakFh9itAAG0URmKe7kfGCCyyuJNzYwQOEoifMe Yv/sLySQDkxM2ampBalFMK1MHJwgo7mkRIqB6SW1KLG0JCMelATji4FpUKqB8RDDxUCbqHUT 4+v1Mn6wx5b28ojM5J7Q+vLrhEX9av+uTd1ot/a0Y9YNzQBVYZFzpa99u7ynpDbYSDP+smB3 OHY/qzI88tCtoOIJkxLe8f5L3773wZLzJ/kWTdt8JJTn3t9ZYWlHTzxfGB39+ZPh7r1PrjTM 6N6zxyJkr4Mip4J6SaVUW+qOq0osxRmJhlrMRcWJAC0oSwNWAwAA Subject: Re: [dispatch] draft-bakker-sipping-3gpp-ims-xml-body-handling-07 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 14:21:28 -0000 Hi, I will be vacationing the next 2 weeks. I am planning to collect all open issues and report back. Ki d regards, JL -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf= Of Gonzalo Camarillo Sent: Wednesday, July 04, 2012 5:00 AM To: dispatch@ietf.org Subject: Re: [dispatch] draft-bakker-sipping-3gpp-ims-xml-body-handling-07 Folks, this thread has died without a clear conclusion. Interestingly, one of the c= omments was about the unresponsiveness of the editors of the draft when addr= essing comments. If there is not enough energy around this piece of work, it= will be impossible to make any type of progress. Cheers, Gonzalo _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From mary.ietf.barnes@gmail.com Fri Jul 6 14:19:10 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7939911E80F5 for ; Fri, 6 Jul 2012 14:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.538 X-Spam-Level: X-Spam-Status: No, score=-103.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 1MnPo6xcyvGr for ; Fri, 6 Jul 2012 14:19:09 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 48E5D11E80F3 for ; Fri, 6 Jul 2012 14:19:09 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so17461207obb.31 for ; Fri, 06 Jul 2012 14:19:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=PKkX/1o0GzGpVEQXfc1K8fJAaNpRm2wZAsHp+d64hH8=; b=c3e9OTsXDSha5UKZ7au2jOX6RzNKWy0m2u1OWzS+DYgCXLW9oUl1AIYTrX3Sr8gihy plRqEG8su0MmbbWMZQza5pLa/GOjzkUmgXqb/xNqOSSt9IBI5EhsC6jRG1GpUB5x89TI cS7Ow3Q4gMwMRiFOQY0gmY74R/SgXwQfjEwwjQswP/pP3ksBm2qgvqliC9YdeuK+iT36 2nXYRq6K91rVelUqM/Dg79TyCTW7y9kd2oa7MPz9TKaSWFWIKuLqewlHaO0lcDFDoCOB 1D+3J9oeDIYnOuPsOctqKQEdhSfyYxxc2D7rqHRzPGiV1hZg2rk70wVM/AfPZxYuXV8D AvUA== MIME-Version: 1.0 Received: by 10.182.14.101 with SMTP id o5mr27598796obc.1.1341609566364; Fri, 06 Jul 2012 14:19:26 -0700 (PDT) Received: by 10.182.147.1 with HTTP; Fri, 6 Jul 2012 14:19:26 -0700 (PDT) In-Reply-To: <20120706211533.3449.10225.idtracker@ietfa.amsl.com> References: <20120706211533.3449.10225.idtracker@ietfa.amsl.com> Date: Fri, 6 Jul 2012 16:19:26 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=14dae9399bada1631004c42fd13a Subject: [dispatch] Fwd: NomCom 2012-13 Call for Volunteers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 21:19:10 -0000 --14dae9399bada1631004c42fd13a Content-Type: text/plain; charset=ISO-8859-1 FYI... ---------- Forwarded message ---------- From: NomCom Chair Date: Fri, Jul 6, 2012 at 4:15 PM Subject: NomCom 2012-13 Call for Volunteers To: IETF Announcement List The IETF nominating committee process for 2012-13 has begun. The IETF nominating committee appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. The 10 nominating committee members are selected randomly from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. The details of the operation of the nomcom can be found in RFC 3777. To be eligible, volunteers for the nomcom need to have attended 3 of the past 5 IETF meetings as of the time this announcement goes out. That is, 3 meetings from IETF 79 (Beijing) - IETF 83 (Paris). If you qualify, and if you will not be seeking appointment to any of the open positions that this nomcom will be filling, please consider volunteering. The list of people whose terms end with the March 2013 IETF meeting, and thus the positions for which the nominating committee is responsible for filling, are as follows: IAOC: -------- Dave Crocker IAB: -------- Alissa Cooper Joel Halpern David Kessens Danny McPherson Jon Peterson Dave Thaler IESG: -------- Russ Housley (General Area) Pete Resnick (Applications Area) Ralph Droms (Internet Area) Ronald Bonica (Operations and Management Area) Robert Sparks (Real-Time Applications and Infrastructure Area) Adrian Farrel (Routing Area) Stephen Farrell (Security Area) Wesley Eddy (Transport Area) The primary activity for this nomcom will begin in August 2012 and should be completed in January 2013. The nomcom will be collecting requirements from the community, as well as talking to candidates and obtaining feedback from community members about candidates. There will be regularly scheduled conference calls to ensure progress. Thus, being a nomcom member does require some time commitment. Please volunteer by sending an email before 11:59 pm EDT (UTC - 4 hours) August 5, 2012 as follows: To: mlepinski.ietf@gmail.com Subject: Nomcom 2012-13 Volunteer Please include the following information in the body: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name // typically what goes in the Company field // in the IETF Registration Form [] // // For confirmation if selected Please expect an email response from me within 3 business days stating whether or not you are qualified. If you don't receive a response, please re-send your email with the tag "RESEND:" added to the subject line. If you are not yet sure you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the nomcom is a good way of contributing toward that goal. I will be publishing a more detailed timetable for nomcom activities, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within the next couple weeks. Thank you, Matthew Lepinski mlepinski.ietf@gmail.com nomcom-chair@ietf.org --14dae9399bada1631004c42fd13a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable FYI...

---------- Forwarded message -----= -----
From: NomCom Chair <nomcom-chair@ietf.org= >
Date: Fri, Jul 6, 2012 at 4:15 PM
Subject: NomCom 2012-13 Call for Volun= teers
To: IETF Announcement List <ietf-announce@ietf.org>


The IETF nominating commit= tee process for 2012-13 has begun. The IETF
nominating committee appoints folks to fill the open slots on the
IAOC, the IAB, and the IESG. The 10 nominating committee members are
selected randomly from a pool of volunteers. The more volunteers, the
better chance we have of choosing a random yet representative cross
section of the IETF population. =A0The details of the operation of the
nomcom can be found in RFC 3777.

To be eligible, volunteers for the nomcom need to have attended 3 of
the past 5 IETF meetings as of the time this announcement goes out.
That is, 3 meetings from IETF 79 (Beijing) - IETF 83 (Paris). If you
qualify, and if you will not be seeking appointment to any of the open
positions that this nomcom will be filling, please consider
volunteering.

The list of people whose terms end with the March 2013 IETF meeting,
and thus the positions for which the nominating committee is
responsible for filling, are as follows:

IAOC:
--------
Dave Crocker

IAB:
--------
Alissa Cooper
Joel Halpern
David Kessens
Danny McPherson
Jon Peterson
Dave Thaler

IESG:
--------
Russ Housley (General Area)
Pete Resnick (Applications Area)
Ralph Droms (Internet Area)
Ronald Bonica (Operations and Management Area)
Robert Sparks (Real-Time Applications and Infrastructure Area)
Adrian Farrel (Routing Area)
Stephen Farrell (Security Area)
Wesley Eddy (Transport Area)

The primary activity for this nomcom will begin in August 2012 and
should be completed in January 2013. The nomcom will be collecting
requirements from the community, as well as talking to candidates and
obtaining feedback from community members about candidates. There will
be regularly scheduled conference calls to ensure progress. Thus,
being a nomcom member does require some time commitment.

Please volunteer by sending an email before 11:59 pm EDT (UTC - 4
hours) August 5, 2012 as follows:

To: mlepinski.ietf@gmail.com
Subject: Nomcom 2012-13 Volunteer

Please include the following information in the body:

<Your Full Name> =A0// As you enter in the IETF Registration Form, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 // First/Given name followed by Las= t/Family Name
<Current Primary Affiliation>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 // typically what goes in the Company field=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 // =A0in the IETF Registration Form
[<all email addresses used to Register for the past 5 IETF meetings>]=
<Preferred email address> =A0//
<Telephone number> =A0 =A0 =A0 =A0 // For confirmation if selected
Please expect an email response from me within 3 business days stating
whether or not you are qualified. =A0If you don't receive a response, please re-send your email with the tag "RESEND:" added to the sub= ject
line.

If you are not yet sure you would like to volunteer, please consider
that nomcom members play a very important role in shaping the
leadership of the IETF. =A0Ensuring the leadership of the IETF is fair
and balanced and comprised of those who can lead the IETF in the right
direction is an important responsibility that rests on the IETF
participants at large. Volunteering for the nomcom is a good way of
contributing toward that goal.

I will be publishing a more detailed timetable for nomcom activities,
as well as details of the randomness seeds to be used for the RFC 3797
selection process, within the next couple weeks.

Thank you,
Matthew Lepinski
mlepinski.ietf@gmail.com nomcom-chair@ietf.org

--14dae9399bada1631004c42fd13a-- From richard@shockey.us Fri Jul 6 16:44:48 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F30911E80C0 for ; Fri, 6 Jul 2012 16:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.635 X-Spam-Level: X-Spam-Status: No, score=-98.635 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.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 e4+LAAzTu10x for ; Fri, 6 Jul 2012 16:44:47 -0700 (PDT) Received: from oproxy5-pub.bluehost.com (oproxy5.bluehost.com [IPv6:2605:dc00:100:2::a5]) by ietfa.amsl.com (Postfix) with SMTP id 9022211E80AA for ; Fri, 6 Jul 2012 16:44:47 -0700 (PDT) Received: (qmail 3997 invoked by uid 0); 6 Jul 2012 23:45:05 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by cpoproxy2.bluehost.com with SMTP; 6 Jul 2012 23:45:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:Cc:To:From; bh=8dWfaBL1H9ltWXNxQaLlEAUWL23h1vzDglT9OAyDfmI=; b=ApVv8Sydd+p+p49FBgd5PEUT5Cp9mMv4EHl6gdkk2PAHtyWjQRGuS1ItyxqEulHxFaa8Xj4/98MHTX0+9+kRGhoTt7ZjKPM1u/T/ZqT9U4P1kj5VqVCE+q3FuxrobIOh; Received: from [71.191.243.130] (port=64977 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1SnICu-0002JG-2P; Fri, 06 Jul 2012 17:45:04 -0600 From: "Richard Shockey" To: "'IETF-Discussion list'" Date: Fri, 6 Jul 2012 19:45:02 -0400 Message-ID: <00ec01cd5bd1$5d94fcb0$18bef610$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00ED_01CD5BAF.D6835CB0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1b0VxYtKZbVnbWTyq8slFdajhb+w== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.191.243.130 authed with richard@shockey.us} Cc: dispatch@ietf.org, sipcore@ietf.org Subject: [dispatch] The US Federal Communications Commission Technical Advisory Committee is discussing the end of POTS. X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 23:44:48 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00ED_01CD5BAF.D6835CB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Aka the PSTN transition . http://www.fcc.gov/encyclopedia/technological-advisory-council http://transition.fcc.gov/bureaus/oet/tac/tacdocs/TAC-WG-Ques-5-9-12.pdf Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 < mailto:richard(at)shockey.us> skype-linkedin-facebook: rshockey101 http//www.sipforum.org ------=_NextPart_000_00ED_01CD5BAF.D6835CB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Aka the PSTN = transition …

 

h= ttp://www.fcc.gov/encyclopedia/technological-advisory-council

 

http://transition.fcc.gov/bureaus/oet/tac/tacdocs/TAC-WG-Ques-5-= 9-12.pdf

 

Richard = Shockey
Shockey Consulting
Chairman of the Board of Directors SIP = Forum
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us>
skype= -linkedin-facebook: rshockey101
http//www.sipforum.org

 

------=_NextPart_000_00ED_01CD5BAF.D6835CB0-- From gonzalo.camarillo@ericsson.com Tue Jul 10 13:09:49 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA6B911E80A6 for ; Tue, 10 Jul 2012 13:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.916 X-Spam-Level: X-Spam-Status: No, score=-105.916 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_102=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 GpfNEdMc5Ssq for ; Tue, 10 Jul 2012 13:09:48 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3CAE421F86BE for ; Tue, 10 Jul 2012 13:09:48 -0700 (PDT) X-AuditID: c1b4fb30-b7f916d000000bfb-3a-4ffc8c277289 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 65.5C.03067.72C8CFF4; Tue, 10 Jul 2012 22:10:15 +0200 (CEST) Received: from [131.160.126.248] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.264.0; Tue, 10 Jul 2012 22:10:15 +0200 Message-ID: <4FFC8C27.3000502@ericsson.com> Date: Tue, 10 Jul 2012 23:10:15 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "dispatch@ietf.org" References: <20120626162244.16515.97970.idtracker@ietfa.amsl.com> <4FF54B23.4040601@ericsson.com> In-Reply-To: <4FF54B23.4040601@ericsson.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgluLIzCtJLcpLzFFi42KZGfG3Vle954+/wZc5OhZLJy1gdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxuG3G5kKnhlUnFp+nr2B8bx6FyMnh4SAicTevj8sELaYxIV7 69m6GLk4hAROMUq8OfqNEcJZyygx4/dsJpAqXgFtid3Lp7KD2CwCqhJ3jnxmBLHZBCwktty6 DzZJVCBYYl73TRaIekGJkzOfgNkiQL1HV3Uxg9jCAjkSD2afZYdYsIxRYt66b2AJTgEdiafn TrFCnCQpca99NRuIzSygJzHlagsjhC0vsf3tHLB6IaChy5+1sExgFJyFZN8sJC2zkLQsYGRe xSicm5iZk15urpdalJlcXJyfp1ecuokRGJoHt/w22MG46b7YIUZpDhYlcV491f3+QgLpiSWp 2ampBalF8UWlOanFhxiZODilGhiZnq3fbDJdc9LVez7qO24aFua8mWTMaNHUmu6Xvk1vm3NM XHSOznzZl9M1X6p03/qjLVrXukUztWMHa9imbXM1j2kn/BGpjb+w2VexOPvxmSu2TP9mdGTL r57yffo7nzURb3sTV+XHbr54WfjA9Au1EwosecK4y/afmvVZcZfsf4ea3Fj2jQpKLMUZiYZa zEXFiQDQk3gjGwIAAA== Subject: Re: [dispatch] Fwd: [new-work] WG Review: Sip Traversal Required for Applications to Work (straw) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 20:09:50 -0000 Hi, the STRAW WG has just been chartered: https://datatracker.ietf.org/wg/straw/charter/ Cheers, Gonzalo On 05/07/2012 11:06 AM, Gonzalo Camarillo wrote: > Folks, > > the IESG will discuss the chartering of this new WG this evening. In the > mean time, you may want to subscribe to the newly created mailing list > for the WG. > > https://www.ietf.org/mailman/listinfo/straw > > Cheers, > > Gonzalo > > On 26/06/2012 8:06 PM, Victor Pascual Avila wrote: >> FYI >> >> ---------- Forwarded message ---------- >> From: IESG Secretary >> Date: Tue, Jun 26, 2012 at 6:22 PM >> Subject: [new-work] WG Review: Sip Traversal Required for Applications >> to Work (straw) >> To: new-work@ietf.org >> >> >> A new IETF working group has been proposed in the Real-time Applications >> and Infrastructure Area. The IESG has not made any determination yet. The >> following draft charter was submitted, and is provided for informational >> purposes only. Please send your comments to the IESG mailing list (iesg >> at ietf.org) by 2012-07-03. >> >> Sip Traversal Required for Applications to Work (straw) >> ------------------------------------------------ >> Current Status: Proposed Working Group >> >> Assigned Area Director: >> Gonzalo Camarillo >> >> >> Charter of Working Group: >> >> Problem Statement: >> >> Within the context of the SIP protocol and architecture, a >> Back-to-Back User Agent (B2BUA) is any SIP device in the logical path >> between two User Agents performing a role beyond that of a Proxy as >> defined in RFC 3261. The B2BUA may be as simple as a session-stateful >> Proxy becoming a B2BUA in order to terminate dead sessions by >> generating BYEs; or it may be a 3PCC-style agent only modifying SDP; >> or it may be a Session Border Controller performing such functions as >> in RFC 5853; or it may be an Enterprise PBX terminating REFERs and >> such; or it may be a complete UAS and UAC implementation with a PRI >> (Primary Rate Interface) loopback in-between. >> >> In its most extreme form, the scope of the SIP protocol ends at the >> UAS of the B2BUA, and a new SIP protocol scope begins on its UAC side. >> In practice, however, users expect some SIP protocol aspects to go >> beyond the scope of the B2BUA's UAS side, and be traversed onto its >> UAC side, as if the B2BUA was not an end unto itself; this is similar >> to the expectation that emails work when they cross from POP and IMAP >> to/from SMTP. >> >> It is impossible to normatively define all the behaviors of B2BUAs in >> general, or even subsets of them such as SBCs (Session Border >> Controlers)or PBXs (Private Branch Exchanges). Unlike consumer NATs, >> B2BUAs perform widely varying functions for purposes which may be >> unique to their environment, unique to their architecture, or unique >> to the wishes of their administrator. Instead of defining all things >> a given type of B2BUA must do, a more practical objective would be to >> define what very few things any B2BUA must do to make a specific SIP >> mechanism work, and let the market decide whether to do those things. >> >> The name of this working group reflects that practical objective: if >> there were a thin straw between the SIP UAS and UAC of a B2BUA, what >> must be passed through that straw and used on each side. Or viewed >> another way, if a B2BUA were in fact a UAS and UAC connected with a >> PRI loopback circuit, and if we could extend ISDN, what information >> would we carry in ISDN across the PRI for a specific SIP mechanism to >> work end-to-end. >> >> For example, the WG could produce a document which specifies that the >> Max-Forwards header field value should be copied and decremented >> across the B2BUA, if the B2BUA wishes to prevent infinite >> loops. Administrators could then tell their B2BUA vendors to comply >> with the document, if the administrator so wishes. >> >> >> Objectives: >> >> The objectives of the STRAW Working Group are to publish normative >> documents which define which SIP header fields, parameters, MIME >> bodies, body content fields/information, or media-plane >> characteristics are required to traverse between the User Agent >> "sides" of a B2BUA for specific functions to work. >> >> The specific functions covered are expected to relate to >> already-published RFCs or existing RAI area work, as opposed to all >> future IETF work. In other words, the Working Group is not meant to >> be a never-ending source for B2BUA requirements in the RAI area. >> >> Deliverables would indicate which types of B2BUAs would apply or not. >> For example, a document defining the requirements for end-to-end >> DTLS-SRTP would not apply to B2BUAs which terminate media, such as >> transcoders or recorders. >> >> Milestones: >> Dec 2012 - A taxonomy document defining role-types of B2BUAs, as a >> reference for other deliverables submitted to the IESG as Informational >> Apr 2013 - A document defining the requirements for B2BUAs with respect >> to loop detection/prevention submitted to the IESG as PS >> Aug 2013 - A document defining the requirements for B2BUAs to support >> end-to-end and hop-by-hop media-loopback test calls submitted to the IESG >> as PS >> Dec 2013 - A document defining the requirements for B2BUAs to support >> DTLS-SRTP (RFC 5764) end-to-end submitted to the IESG as PS >> Dec 2013 - A document defining the requirements for B2BUAs to support >> STUN message transactions end-to-end submitted to the IESG as PS >> Dec 2013 - A document defining the requirements for B2BUAs to support >> RTCP end-to-end submitted to the IESG as PS >> >> >> _______________________________________________ >> new-work mailing list >> new-work@ietf.org >> https://www.ietf.org/mailman/listinfo/new-work >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > From gonzalo.camarillo@ericsson.com Wed Jul 11 04:23:24 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 153EC21F847E for ; Wed, 11 Jul 2012 04:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.211 X-Spam-Level: X-Spam-Status: No, score=-106.211 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyU4RNQJhDP1 for ; Wed, 11 Jul 2012 04:23:19 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6632621F847C for ; Wed, 11 Jul 2012 04:23:18 -0700 (PDT) X-AuditID: c1b4fb2d-b7f6c6d000001cc5-01-4ffd6243dfc6 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 36.59.07365.3426DFF4; Wed, 11 Jul 2012 13:23:48 +0200 (CEST) Received: from [131.160.126.248] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.264.0; Wed, 11 Jul 2012 13:23:47 +0200 Message-ID: <4FFD6243.70104@ericsson.com> Date: Wed, 11 Jul 2012 14:23:47 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: DISPATCH X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHJMWRmVeSWpSXmKPExsUyM+Jvra5L0l9/g1mPOCyWTlrA6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujOOXF7MWrGSraDqxhrGBcRJrFyMnh4SAicSsp+/ZIGwxiQv3 1oPZQgKnGCXud4d3MXIB2WsZJU7s+wHWwCugKdG74SILiM0ioCrR0foZLM4mYCGx5dZ9sLio QLDEvO6bLBD1ghInZz4Bs0UEFCT2XjoAVi8sYCixcOMedojFkhL32leDLWYW0JOYcrWFEcKW l9j+dg4zxEHaEsuftbBMYOSfhWTsLCQts5C0LGBkXsUonJuYmZNebqiXWpSZXFycn6dXnLqJ ERhmB7f81t3BeOqcyCFGaQ4WJXFerqT9/kIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY/edt uXE741DxnNDi3/wsKQKKugXC7SU3Zkcz/1S6reTyZe6tWw1O77g93s1ImvJlUuDXi9lNli+S fuzqm2wn9k964ufMjUbi2y9FsQS7lPs+inx/Qa5Sctep06JSC1zOStmvfeq1XCGreybL06j4 xE8lu+XmTF+xLmPTI8nts3bUvXvxZe0MfyWW4oxEQy3mouJEAErXz/wBAgAA Subject: [dispatch] Status of draft-montemurro-gsma-imei-urn X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 11:23:24 -0000 Folks, I have noticed that the authors of the following draft have just submitted a new revision: http://tools.ietf.org/html/draft-montemurro-gsma-imei-urn-10 We had a conference call among a few interested people (including the authors) back in January (2012), right after version 09 of the draft was submitted. The conclusion of that conference call was that the authors were going to submit a new revision of the draft clarifying the use of the mechanism and explaining how the 3GPP architecture addresses the privacy issues that were discussed. The draft has only been revised now, and the new revision is almost identical to the previous one. If the authors could clarify what the status of this draft is according to their understanding, that would be great. Cheers, Gonzalo From dworley@avaya.com Wed Jul 11 10:58:00 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51AEB11E813F for ; Wed, 11 Jul 2012 10:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.156 X-Spam-Level: X-Spam-Status: No, score=-103.156 tagged_above=-999 required=5 tests=[AWL=0.443, 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 sGZw0a2WSdRQ for ; Wed, 11 Jul 2012 10:57:59 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 4BDF611E8139 for ; Wed, 11 Jul 2012 10:57:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJ+9/U/GmAcF/2dsb2JhbABFhWewZIEhgQeCJxIREVcBFQ0CJgIEMBURAQQbGodrnBWEI4oekwaBII58MmADmzKKDoJ7 X-IronPort-AV: E=Sophos;i="4.77,569,1336363200"; d="scan'208";a="356961244" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 11 Jul 2012 13:55:08 -0400 Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by co300216-co-erhwest-out.avaya.com with ESMTP; 11 Jul 2012 13:55:13 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Wed, 11 Jul 2012 13:58:29 -0400 From: "Worley, Dale R (Dale)" To: "dispatch@ietf.org" Date: Wed, 11 Jul 2012 13:58:28 -0400 Thread-Topic: draft-montemurro-gsma-imei-urn-10 Thread-Index: Ac1fjsaIbKFcT5zTSV6bzIS/dQ2A3w== Message-ID: 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: [dispatch] draft-montemurro-gsma-imei-urn-10 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 17:58:00 -0000 VGhpcyBpcyByYXRoZXIgYSBuaXQsIGJ1dCBpbiAtMTAgSSBzZWU6CgogICAgICAgZ3NtYS1zcGVj aWZpZXItZGVmaW5lZC1wYXJhbS1uYW1lICA9IGdzbWEtYXBwcm92ZWQtbm9uZW1wdHktc3RyaW5n CiAgICAgICBnc21hLXNwZWNpZmllci1kZWZpbmVkLXBhcmFtLXZhbCA9IGdzbWEtYXBwcm92ZWQt c3RyaW5nCiAgICAgICBnc21hLXNwZWNpZmllci1wYXJhbSA9CiAgICAgICAgICAgICAgICAgICAg ICAgInN2biIgIj0iIHNvZnR3YXJlLXZlcnNpb24tc3RyaW5nIC8KICAgICAgICAgICAgICAgICAg ICAgICAidmVycyIgIj0iIGdzbWEtZm9ybWF0LXZlcnNpb24tc3RyaW5nIC8KICAgICAgICAgICAg ICAgICAgICAgICBnc21hLXNwZWNpZmllci1kZWZpbmVkLXBhcmFtLW5hbWUgIj0iCiAgICAgICAg ICAgICAgICAgICAgICAgMSooZ3NtYS1zcGVjaWZpZXItZGVmaW5lZC1wYXJhbS12YWwpCiAgICAg ICBzb2Z0d2FyZS12ZXJzaW9uLXN0cmluZyA9IDJESUdJVAogICAgICAgZ3NtYS1mb3JtYXQtdmVy c2lvbi1zdHJpbmcgPSBESUdJVAogICAgICAgZ3NtYS1hcHByb3ZlZC1zdHJpbmcgPSAqdW5yZXNl cnZlZAoKVGhlIHByb2R1Y3Rpb24gZm9yIGdzbWEtc3BlY2lmaWVyLXBhcmFtIGhhcyBiZWVuIG1v ZGlmaWVkIHNpbmNlIHRoZSAtMDkKdmVyc2lvbi4KCkxvb2tpbmcgYXQgdGhlIGZpbmFsIGFsdGVy bmF0aXZlIGZvciBnc21hLXNwZWNpZmllci1wYXJhbSBJIHNlZToKCiAgICAgZ3NtYS1zcGVjaWZp ZXItZGVmaW5lZC1wYXJhbS1uYW1lICI9IiAxKihnc21hLXNwZWNpZmllci1kZWZpbmVkLXBhcmFt LXZhbCkKCmJ1dCBnaXZlbiB0aGVzZSBkZWZpbml0aW9uczoKCiAgICAgICBnc21hLXNwZWNpZmll ci1kZWZpbmVkLXBhcmFtLXZhbCA9IGdzbWEtYXBwcm92ZWQtc3RyaW5nCiAgICAgICBnc21hLWFw cHJvdmVkLXN0cmluZyA9ICp1bnJlc2VydmVkCgp0aGlzIGhhcyB0aGUgZWZmZWN0OgoKICAgICBn c21hLXNwZWNpZmllci1kZWZpbmVkLXBhcmFtLW5hbWUgIj0iIDEqKCp1bnJlc2VydmVkKQoKd2hp Y2ggaGFzIHRoZSBzYW1lIGVmZmVjdCBhczoKCiAgICAgZ3NtYS1zcGVjaWZpZXItZGVmaW5lZC1w YXJhbS1uYW1lICI9IiAqdW5yZXNlcnZlZAoKSW4gdGhpcyBjb250ZXh0LCBJIHRoaW5rIHRoZSBu YXR1cmFsIHdheSB0byBleHByZXNzIGl0IGlzOgoKICAgICBnc21hLXNwZWNpZmllci1kZWZpbmVk LXBhcmFtLW5hbWUgIj0iIGdzbWEtc3BlY2lmaWVyLWRlZmluZWQtcGFyYW0tdmFsCgpEYWxlCgo= From pkyzivat@alum.mit.edu Wed Jul 11 11:28:43 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B44D421F84C2 for ; Wed, 11 Jul 2012 11:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.316 X-Spam-Level: X-Spam-Status: No, score=-2.316 tagged_above=-999 required=5 tests=[AWL=0.283, 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 UxXyeLPYb58D for ; Wed, 11 Jul 2012 11:28:43 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 207FA21F8476 for ; Wed, 11 Jul 2012 11:28:42 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta13.westchester.pa.mail.comcast.net with comcast id Z59S1j0031vXlb85D6VGJa; Wed, 11 Jul 2012 18:29:16 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id Z6VJ1j00T3ZTu2S3d6VJmL; Wed, 11 Jul 2012 18:29:18 +0000 Message-ID: <4FFDC5F9.1080904@alum.mit.edu> Date: Wed, 11 Jul 2012 14:29:13 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: dispatch@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn-10 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 18:28:43 -0000 Dale, I don't really know, but conjecture that they want to allow multiple values. If so, what is missing from the ABNF is a separator between values. Thanks, Paul On 7/11/12 1:58 PM, Worley, Dale R (Dale) wrote: > This is rather a nit, but in -10 I see: > > gsma-specifier-defined-param-name = gsma-approved-nonempty-string > gsma-specifier-defined-param-val = gsma-approved-string > gsma-specifier-param = > "svn" "=" software-version-string / > "vers" "=" gsma-format-version-string / > gsma-specifier-defined-param-name "=" > 1*(gsma-specifier-defined-param-val) > software-version-string = 2DIGIT > gsma-format-version-string = DIGIT > gsma-approved-string = *unreserved > > The production for gsma-specifier-param has been modified since the -09 > version. > > Looking at the final alternative for gsma-specifier-param I see: > > gsma-specifier-defined-param-name "=" 1*(gsma-specifier-defined-param-val) > > but given these definitions: > > gsma-specifier-defined-param-val = gsma-approved-string > gsma-approved-string = *unreserved > > this has the effect: > > gsma-specifier-defined-param-name "=" 1*(*unreserved) > > which has the same effect as: > > gsma-specifier-defined-param-name "=" *unreserved > > In this context, I think the natural way to express it is: > > gsma-specifier-defined-param-name "=" gsma-specifier-defined-param-val > > Dale > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From prvs=4554478367=jbakker@rim.com Thu Jul 26 14:35:36 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5624711E80AE for ; Thu, 26 Jul 2012 14:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 7bTQbmLxbIZn for ; Thu, 26 Jul 2012 14:35:35 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 11CBF11E80A4 for ; Thu, 26 Jul 2012 14:35:34 -0700 (PDT) X-AuditID: 0a41282f-b7fbe6d0000051f1-fe-5011b8268b88 Received: from XCT102ADS.rim.net (xct102ads.rim.net [10.67.111.43]) by mhs060cnc.rim.net (SBG) with SMTP id 5B.F5.20977.628B1105; Thu, 26 Jul 2012 16:35:34 -0500 (CDT) Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT102ADS.rim.net ([fe80::4806:2e1d:2b7c:cfdf%22]) with mapi id 14.02.0298.004; Thu, 26 Jul 2012 16:35:33 -0500 From: John-Luc Bakker To: "dispatch@ietf.org" Thread-Topic: [dispatch] draft-bakker-sipping-3gpp-ims-xml-body-handling-07 Thread-Index: AQHNHVOLGaoZosgWp06CrMLzAfa1kZbLjn1AgBjrSQCAACmKgIALMfOAgCnbcICAAYcccIAhUyhw Date: Thu, 26 Jul 2012 21:35:32 +0000 Message-ID: <155970D1DA8E174F9E46039E10E2AA351C07B7@XMB104ADS.rim.net> References: <20111202210806.7950.76133.idtracker@ietfa.amsl.com> <4EDA6648.2040109@alum.mit.edu> <155970D1DA8E174F9E46039E10E2AA3512B06B@XMB104ADS.rim.net> <155970D1DA8E174F9E46039E10E2AA35132AE9@XMB104ADS.rim.net> <155970D1DA8E174F9E46039E10E2AA351429AC@XMB104ADS.rim.net> <4F8EA090.1010400@ericsson.com> <155970D1DA8E174F9E46039E10E2AA3516DCCA@XMB104ADS.rim.net> <18372A69-0835-4E41-882E-B8D1F229F316@iii.ca> <8D9E58E6-3098-48DF-B752-B6D12146EB82@iii.ca> <4FF4141D.6010302@ericsson.com> <155970D1DA8E174F9E46039E10E2AA351A28B4@XMB104ADS.rim.net> In-Reply-To: <155970D1DA8E174F9E46039E10E2AA351A28B4@XMB104ADS.rim.net> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.252] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPKsWRmVeSWpSXmKPExsXC5Zyvrau2QzDAYP9xfoulkxawOjB6LFny kymAMaqB0SYpsaQsODM9T9/OJjEvL78ksSRVISW1ONlWySc1PTFHIaAosywxuVLBJbM4OScx Mze1SEkhM8VWyURJoSAnMTk1NzWvxFYpsaAgNS9FyY5LAQPYAJVl5imk5iXnp2TmpdsqeQb7 61pYmFrqGirZ6SZ08mTMPvKSpaDNqOLujkUsDYy71bsYOTkkBEwkzl5tZYewxSQu3FvP1sXI xSEksJJR4tW9V6wgCSGBzYwS65dpgNhsAuoSW1dsZwaxRQS0JY6u6gKzhQW8JFZ/a2GEiHtL nNg5G8qOknjRdIsNxGYRUJU4eeIbmM0r4Cbxd+F3VohlX1gk+k7eAEtwCrhLTPu4CKyZUUBW YvfZ60wgNrOAuMStJ/OZIC4VkFiy5zwzhC0q8fLxP1YIW1HicUs3C0S9jsSC3Z/YIGxtiWUL XzNDLBaUODnzCcsERtFZSMbOQtIyC0nLLCQtCxhZVjEK5mYUG5gZJOcl6xVl5urlpZZsYgRF v6OG/g7Gt+8tDjEKcDAq8fCu3ioYIMSaWFZcmXuIUYKDWUmE13s5UIg3JbGyKrUoP76oNCe1 +BCjBTBYJjJLcSfnAxNTXkm8sYEBCkdJnDfjG1+AkEA6MMlkp6YWpBbBtDJxcIKM5pISKQam itSixNKSjHhQQosvBqY0qQZGv5ZbNYpeF95tdlD3Ldrkerb5UJuhcNjn3hcilzMeRBy+YK54 685phf23jycYmJkWO/2qmnFsSfds9Y1nt8bOK89dk9PjLZ2qYOp90ufD+UrBjzfKVk3xEt2Q l37pTx3np3cB+zlm8SmFpEtest8383Rbt9cMtSeRPuWsPWozbqnxB638fvugEktxRqKhFnNR cSIAiB5ULTIDAAA= Subject: Re: [dispatch] draft-bakker-sipping-3gpp-ims-xml-body-handling-07 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 21:35:36 -0000 Hi all, First of all, some editorial improvements have been identified. However, I c= onsider the editorials not the issue that are holding up progress. I start with a summary of the problem the draft attempts to address. A content-disposition value is used to select a content handler. A UA is not expected to inspect the content when deciding on invoking a cont= ent handler. 3GPP have specified handling of the MIME media type tag 3gpp-ims+xml body at= the Application Server (AS) (a network element in the role of UAS) and at t= he User Equipment (UE) (in the role of UAC). This handling at the AS (let's= say that the handling is performed by a content handler, and let's call thi= s content handler "content handler A") is very different from the handling a= t the UE (by content handler B). Note also the following: http://www.iana.org/assignments/media-types/applica= tion/3gpp-ims+xml, i.e. the tag itself had been registered with IANA. The re= gistration information explicitly includes: Applications which use this media: Applications that use the 3GPP IM CN Subsystem as defined by 3GPP. The problem is: how to select between the different content handlers when th= is media is received at the UE or at the AS. This is how I understand the options: A) choosing between content handler A and content handler B can be done in a= n implementation specific way: for example, content handler A is selected wh= en a body part with MIME media type tag 3gpp-ims+xml body is received by an= AS in the role of UAS. Content handler B is selected when a body part with= MIME media type tag 3gpp-ims+xml body is received by a UE in the role of UA= C. B) choosing between a content handler for the MIME media type tag is done ba= sed on the Content-Disposition header field value. The advantage is that les= s customization is needed and software that is more "off-the-shelf" can be o= btained. An option that is not available to 3GPP is to have unique MIME media type t= ags, each associated with a content handler. Having unique MIME media type= tags at this stage would raise backwards compatibility concerns. 3GPP have chosen not to preclude option B) above. 3GPP has chosen two conten= t disposition values, one applicable at the AS and one applicable at the UE.= Here is an excerpt of the draft: 6. IANA Considerations This document registers new disposition-types for the Content- Disposition header field that apply to the "application/3gpp-ims+xml" body (part) used by 3GPP and are to be registered in the IANA registry for Mail Content Disposition Values and Parameters: o 3gpp-alternative-service: the body (part) contains 3GPP IM CN subsystem XML with the 'alternative-service' XML element as described in Section 4.2; and o 3gpp-service-info: the body (part) contains 3GPP IM CN subsystem XML with the 'service-info' XML element as described in Section 4.3. It shows that each disposition-type is associated with a unique content hand= ler. Open issues New disposition-types for the Content-Disposition header field can only be r= egistered via drafts on the Experimental track or on the Standards track. We= chose to use the Experimental track for registering the two values. People= have questioned the use of the Experimental track for this. However, it sho= uld be noted that an experimental RFC may be promoted to standards track if= it becomes popular. Another issue is the following: Using this common content-type with the two different dispositions means that you have new error cases: - the C-T is 3gpp-alternative-service and the body contains: ... - the C-T is 3gpp-service-info and the body contains: ... It is correct that these error conditions can occur. But this would only occ= ur if the network is misconfigured. Such a misconfiguration is unlikely. I d= o not consider this an issue but including a note in the draft may be pruden= t. Conclusion In this e-mail, I have not gone into the details of what content handler A o= r content handler B are actually doing when receiving one of these body part= s. Since this media is intended to be used by 3GPP. I believe it is sufficie= nt to understand that the content handler A and the content handler B are ve= ry different. Multiple MIME types have been considered but 3GPP participants could not agr= ee that approach. Therefore, alternative solutions have been considered by t= he stake holders, but were not found applicable. It may be useful to documen= t the alternative solution in the draft for information. People have expressed concern that the draft is on experimental track. If si= pping also wishes not to preclude option B) above, then apart from agreeing= and adding notes as suggested above, fixing the editorials, I believe the s= election of the track to be the main issue. Kind regards, John-Luc -----Original Message----- From: John-Luc Bakker Sent: Thursday, July 05, 2012 9:22 AM To: 'Gonzalo Camarillo'; dispatch@ietf.org Subject: RE: [dispatch] draft-bakker-sipping-3gpp-ims-xml-body-handling-07 Hi, I will be vacationing the next 2 weeks. I am planning to collect all open issues and report back. Ki d regards, JL -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf= Of Gonzalo Camarillo Sent: Wednesday, July 04, 2012 5:00 AM To: dispatch@ietf.org Subject: Re: [dispatch] draft-bakker-sipping-3gpp-ims-xml-body-handling-07 Folks, this thread has died without a clear conclusion. Interestingly, one of the c= omments was about the unresponsiveness of the editors of the draft when addr= essing comments. If there is not enough energy around this piece of work, it= will be impossible to make any type of progress. Cheers, Gonzalo _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful.