From nobody Fri Aug 5 04:41:33 2016 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 73B8512D7B3; Fri, 5 Aug 2016 04:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhCYEq1Z372N; Fri, 5 Aug 2016 04:41:27 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C43212D782; Fri, 5 Aug 2016 04:41:26 -0700 (PDT) X-AuditID: c1b4fb3a-c7bff700000009bd-07-57a47b62ac09 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id 3E.56.02493.26B74A75; Fri, 5 Aug 2016 13:41:24 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.187]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0301.000; Fri, 5 Aug 2016 13:41:21 +0200 From: Ivo Sedlacek To: "ecrit@ietf.org" Thread-Topic: draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 Thread-Index: AdHvCr3UqMZD6yUmRXGJoLQMM15tQQ== Date: Fri, 5 Aug 2016 11:41:22 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101164BDFB2@ESESSMB301.ericsson.se> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM2J7oG5K9ZJwg+e/LSwaFz1ltfj6YxOb A5PHkiU/mQIYo7hsUlJzMstSi/TtErgybi7bxVJwSLDi/N8uxgbG5XxdjJwcEgImEodvzmTv YuTiEBJYzyix78I9KGcxo0TH399MIFVsAnoSE7ccYQWxRQRUJTacWckIYjMLaEo82rkXrEZY IEji9LopzBA1wRKn+w5B1etJHNi+mQ3EZhFQkfg6swfM5hXwlZh+9zc7iM0oICtx9U8v1Exx iVtP5jNBXCcgsWTPeWYIW1Ti5eN/rBC2ksSPDZdYIOp1JBbs/sQGYWtLLFv4mhlivqDEyZlP WCYwCs9CMnYWkpZZSFpmIWlZwMiyilG0OLW4ODfdyEgvtSgzubg4P08vL7VkEyMw3A9u+W21 g/Hgc8dDjAIcjEo8vAuaFocLsSaWFVfmHmKU4GBWEuFVqFoSLsSbklhZlVqUH19UmpNafIhR moNFSZzX/6ViuJBAemJJanZqakFqEUyWiYNTqoHR5Pr3xq+v5mi7rXYvNohZ8z5TxXZv5WS2 QpvZt/+8a2V6kbbCQ2hjxdK0Dqt+79LSN5rW33tYTn3/LFW6W8Exj2vVi7D46PxQ44Obb/35 1HL02x6r5Q8fn53P67WgI9DzwNIc13jVd2Xal1Y/mM1+pKPOcX9+86Vtipcf1lQY/VwyjddX 7Xm1EktxRqKhFnNRcSIAQS6ZCXMCAAA= Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 11:41:28 -0000 Hello, COMMENT 2: \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\ Usage of Call-Info: - in a response to an initial INVITE request; and - in a SIP INFO request sent from PSAP to the UE; is not aligned with semantic of call-info as defined in RFC3261: ----------------- The Call-Info header field provides additional information about the caller or callee, depending on whether it is found in a request or response. ----------------- In those cases, the Call-Info identifies a MIME body of application/Emergen= cyCallData.eCall.control+xml MIME type (draft-ietf-ecrit-ecall-11 section 6= , 4th paragraph and 9 and in Figure 9 and Figure 10), which carries: -------- A PSAP or IVS transmits >>a metadata/control object<< (see Section 9) by encoding it per the description in this document and attaching it to a SIP message as a MIME body part per [RFC7852]. The body part is identified by its MIME content-type ('application/ emergencyCallData.eCall.control+xml') in the Content-Type header field of the body part. The body part is assigned a unique identifier which is listed in a Content-ID header field in the body part. >>The SIP message is marked as containing the metadata/control object by adding (or appending to) a Call-Info header field at the top level of the SIP message.<< -------- and -------- ... When the IVS includes an unsolicited MSD in a SIP request (e.g., the initial INVITE), the PSAP sends a metadata/control block indicating successful/unsuccessful receipt of the MSD in the SIP response to the request. =20 ... -------- In those cases, the MIME body indicates an delivery report (Figure 9) or re= quests an action to be performed at UAS (Figure 10). ///////////////////////////////////////////////////////////////////////////= /// PROPOSED SOLUTION to COMMENT 2 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\ Align the semantic of the Call-Info header field with RFC3261, remove usage= of Call-Info header field, or update RFC3261. ///////////////////////////////////////////////////////////////////////////= /// Kind regards Ivo Sedlacek From nobody Thu Aug 11 10:11:12 2016 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 D821B12D795 for ; Thu, 11 Aug 2016 10:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzQni6n-ZYRc for ; Thu, 11 Aug 2016 10:11:09 -0700 (PDT) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D79212D817 for ; Thu, 11 Aug 2016 10:11:09 -0700 (PDT) Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-03v.sys.comcast.net with SMTP id XtVDbQiXl8GkCXtVSb7RBZ; Thu, 11 Aug 2016 17:10:58 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by comcast with SMTP id XtVRb6kjO9pGIXtVSbu8Ug; Thu, 11 Aug 2016 17:10:58 +0000 References: <3b670133-e961-9554-c857-5861733947fd@alum.mit.edu> To: SIPCORE From: Paul Kyzivat X-Forwarded-Message-Id: <3b670133-e961-9554-c857-5861733947fd@alum.mit.edu> Message-ID: Date: Thu, 11 Aug 2016 13:10:57 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <3b670133-e961-9554-c857-5861733947fd@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfCGj0yrTNlIagEjtE7WUmf+hPymUPo8UDoR5kDHU2lvF+BcKiC5Xz8SRyU72JdG4O1Cy/LoOX0/n3nKGXDku2P1hXR/klEYhDZtOvBVONNfqBAZPZuuJ 22tZge8LxXYtGt5OPkJIxQRURidBVb2DBtJPrkegxfbAKL86QD6lj+QlkdI92X1BPmIPDpdzIg1NHQ== Archived-At: Subject: [sipcore] Content-ID cannot be included when SIP message has solely one body (i.e. no multipart/...) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 17:11:11 -0000 Bringing this to sipcore. It just came up in ecrit, but is a general issue. IMO Content-ID should be permitted as a SIP header field. Necessary in any case where some other header field wants to include a cid: uri and there is only one body part. Frankly, IMO SIP should be considered to be an extension to MIME, and so all the basic MIME header fields ought to be allowed. Thanks, Paul -------- Forwarded Message -------- Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Content-ID cannot be included when SIP message has solely one body (i.e. no multipart/...) Date: Thu, 11 Aug 2016 10:50:30 -0400 From: Paul Kyzivat To: ecrit@ietf.org Hmm. Interesting issue. ISTM the proper solution to that is to define Content-ID as a SIP header field. Of course a work-around is to add a multipart wrapper to the single body part. But that shouldn't be necessary. Thanks, Paul On 8/11/16 10:04 AM, Ivo Sedlacek wrote: > Hello, > > I found another potential issue. > > If a SIP message contains solely one body (i.e. not multipart/mixed body), then the SIP message cannot contain a Content-ID header field. > > Content-ID header field is NOT a SIP header field - Content-ID cannot be found in in RFC3261 and Content-ID cannot be found in http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-2 > Content-ID header field is a MIME multipart/mixed header field. > > Also, rfc5621 states: > ------------ > Content-ID URLs allow creating references to body *parts*. > ------------ > > Thus, Figure 10, and Figure 11 (and related procedures) of draft-ietf-ecrit-ecall-11 use a header field (Content-ID header field) not defined in SIP. > > Kind regards > > Ivo > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From nobody Thu Aug 11 10:59:42 2016 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 9C7B812D8F2 for ; Thu, 11 Aug 2016 10:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvmAV9KiiQGv for ; Thu, 11 Aug 2016 10:59:38 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E94D612D0DB for ; Thu, 11 Aug 2016 10:59:37 -0700 (PDT) X-AuditID: c1b4fb2d-917ff700000019a3-f3-57acbd078ff8 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id 70.73.06563.70DBCA75; Thu, 11 Aug 2016 19:59:36 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.187]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0301.000; Thu, 11 Aug 2016 19:59:35 +0200 From: Ivo Sedlacek To: "sipcore@ietf.org" Thread-Topic: Content-ID header field not defined in SIP Thread-Index: AdHz7HbNjd2T8u7kRR29JnCw0ka2hQ== Date: Thu, 11 Aug 2016 17:59:34 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101164C5617@ESESSMB301.ericsson.se> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHLMWRmVeSWpSXmKPExsUyM2K7pS7H3jXhBt0zOSy+/tjE5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujP61d1kKDnJWNOw4wNrAeIO9i5GDQ0LAROLzPtMuRi4OIYH1 jBI7f3UwQThLGCXO9Exj7mLk5GAT0JOYuOUIK4gtIqApsfzbVnYQW1jAWGLy8Q1sEHELiYsT PrBA2HoS9xuPMYLYLAKqEr9mTger4RXwlWg7dhmshlFAVuLqn16wGmYBcYlbT+YzgdgSAgIS S/acZ4awRSVePv7HCmErSazYfgmqXkdiwe5PbBC2tsSyha+ZIeYLSpyc+YRlAqPQLCRjZyFp mYWkZRaSlgWMLKsYRYtTi4tz042M9VKLMpOLi/Pz9PJSSzYxAkP54JbfujsYV792PMQowMGo xMO7IHt1uBBrYllxZe4hRgkOZiUR3r871oQL8aYkVlalFuXHF5XmpBYfYpTmYFES5/V/qRgu JJCeWJKanZpakFoEk2Xi4JRqYNQv3Jk/w3q2pcmMytqQxs8XH+ZMe7OE73TYtuecsivnHIqY Pn3x0beyiiG2C/WfxB15u5NxYe91TQebf9VXD3d2J13aly7cdvGglkpEi+V5yXlztl15Iqq/ w+CH5Z9E7pP/RJomzA88qmdQ/ovrUEO0/tlawYjScIsD4Q/WVV4WFIpd9tB4JaMSS3FGoqEW c1FxIgBELotHYQIAAA== Archived-At: Subject: [sipcore] Content-ID header field not defined in SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 17:59:39 -0000 Hello, The Content-ID header field does not seem to be defined as a *SIP* header f= ield - Content-ID cannot be found in in RFC3261 and Content-ID also cannot = be found in http://www.iana.org/assignments/sip-parameters/sip-parameters.x= html#sip-parameters-2=20 NOTE: Content-ID header field is defined to be a *MIME multipart/mixed* hea= der field. However, rfc5368 section 7 and Figure 3 describe REFER request: - with a single body (of application/resource-lists+xml MIME type) with a C= ontent-ID *SIP* header field; and - with Refer-To header field referring to the body. Also, it is possible to send an INVITE request *without SDP offer* and with= location information according to rfc6442. In such case, the INVITE reques= t: - has a single body (of application/pidf+xml MIME type) with a Content-ID *= SIP* header field; and - has Geolocation header field referring to the body. One can of course put a single body inside a multipart/mixed, but that is r= ather messy. I assume the proper solution is to define the Content-ID heade= r field as *SIP* header field. Is there any support for such definition? If so, I would prepare a draft. Kind regards Ivo Sedlacek From nobody Thu Aug 11 11:07:40 2016 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 6FD2A12D8EB for ; Thu, 11 Aug 2016 11:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AR72kwsS80Hd for ; Thu, 11 Aug 2016 11:07:36 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CD2512D0DB for ; Thu, 11 Aug 2016 11:07:36 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 87258A3CEC570; Thu, 11 Aug 2016 18:07:30 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u7BI7XUY030784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Aug 2016 18:07:33 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u7BI6DMh027523 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Aug 2016 20:07:33 +0200 Received: from FR711WXCHMBA04.zeu.alcatel-lucent.com ([169.254.4.46]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Thu, 11 Aug 2016 20:07:22 +0200 From: "Drage, Keith (Nokia - GB)" To: Ivo Sedlacek , "sipcore@ietf.org" Thread-Topic: Content-ID header field not defined in SIP Thread-Index: AdHz7HbNjd2T8u7kRR29JnCw0ka2hQADkf0g Date: Thu, 11 Aug 2016 18:07:21 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF49B95@FR711WXCHMBA04.zeu.alcatel-lucent.com> References: <39B5E4D390E9BD4890E2B31079006101164C5617@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B31079006101164C5617@ESESSMB301.ericsson.se> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] Content-ID header field not defined in SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 18:07:38 -0000 Can we first establish the use case as to why we need one. We need it in MIME because we may need to distinguish between multiple part= bodies of identical type. We don't need it for SDP because we known the SDP contained in a SIP transa= ction relates to the dialog. We don't need it in an INFO request because we known the body relates to th= e Info-package. We don't need it with PIDF-LO because the Geolocation header field points t= o it. Essentially we mostly deal with this by knowing the body is specific to oth= er header fields in the SIP message. Do you have any specific existing use cases (ignoring the ecrit discussion)= . Keith -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Ivo Sedlacek Sent: 11 August 2016 19:00 To: sipcore@ietf.org Subject: [sipcore] Content-ID header field not defined in SIP Hello, The Content-ID header field does not seem to be defined as a *SIP* header f= ield - Content-ID cannot be found in in RFC3261 and Content-ID also cannot = be found in http://www.iana.org/assignments/sip-parameters/sip-parameters.x= html#sip-parameters-2=20 NOTE: Content-ID header field is defined to be a *MIME multipart/mixed* hea= der field. However, rfc5368 section 7 and Figure 3 describe REFER request: - with a single body (of application/resource-lists+xml MIME type) with a C= ontent-ID *SIP* header field; and - with Refer-To header field referring to the body. Also, it is possible to send an INVITE request *without SDP offer* and with= location information according to rfc6442. In such case, the INVITE reques= t: - has a single body (of application/pidf+xml MIME type) with a Content-ID *= SIP* header field; and - has Geolocation header field referring to the body. One can of course put a single body inside a multipart/mixed, but that is r= ather messy. I assume the proper solution is to define the Content-ID heade= r field as *SIP* header field. Is there any support for such definition? If so, I would prepare a draft. Kind regards Ivo Sedlacek _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Aug 11 12:03:25 2016 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 A915212D90B for ; Thu, 11 Aug 2016 12:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NGMpPnHD1ht for ; Thu, 11 Aug 2016 12:03:16 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A302C12D1BC for ; Thu, 11 Aug 2016 12:03:16 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-05v.sys.comcast.net with SMTP id XvD8bXMGt2FGMXvG7bDSSc; Thu, 11 Aug 2016 19:03:15 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by comcast with SMTP id XvG7b7W4VHaWLXvG7bjtBd; Thu, 11 Aug 2016 19:03:15 +0000 To: sipcore@ietf.org References: <39B5E4D390E9BD4890E2B31079006101164C5617@ESESSMB301.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF49B95@FR711WXCHMBA04.zeu.alcatel-lucent.com> From: Paul Kyzivat Message-ID: <3ea5d8d6-9d2e-27c9-812c-00df4c5972de@alum.mit.edu> Date: Thu, 11 Aug 2016 15:03:13 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF49B95@FR711WXCHMBA04.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfDPp790uD0oRYlVCHJpkFh8E7zmQe7/wkNHt7j5ObQCt42pyv1hVxcoPts16z2llMpzZVD2MoPNjFsG8D0O6I/J83943apOApcBagRSA34UN3RK64+J+ 1wQh1aXOjRhCLlVWM7NyXGf8mAlp0Oq1oMcPs7Ki674pO5JjO3Lj78KxrjeyQrwry3R0qHNJPEsvtQ== Archived-At: Subject: Re: [sipcore] Content-ID header field not defined in SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 19:03:22 -0000 On 8/11/16 2:07 PM, Drage, Keith (Nokia - GB) wrote: > Can we first establish the use case as to why we need one. > > We need it in MIME because we may need to distinguish between multiple part bodies of identical type. > > We don't need it for SDP because we known the SDP contained in a SIP transaction relates to the dialog. > > We don't need it in an INFO request because we known the body relates to the Info-package. > > We don't need it with PIDF-LO because the Geolocation header field points to it. We *do* need it with PIDF-LO precisely because the Geolocation header field points to it. It points to it *via* the Content-ID. It currently works in INVITE as long as there is also an offer. If there is no offer, then the only body part is the PIDF-LO, and it needs a Content-ID so that there is something for the cid URL in the Call-Info to reference. Thanks, Paul > Essentially we mostly deal with this by knowing the body is specific to other header fields in the SIP message. > > Do you have any specific existing use cases (ignoring the ecrit discussion). > > Keith > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Ivo Sedlacek > Sent: 11 August 2016 19:00 > To: sipcore@ietf.org > Subject: [sipcore] Content-ID header field not defined in SIP > > Hello, > > The Content-ID header field does not seem to be defined as a *SIP* header field - Content-ID cannot be found in in RFC3261 and Content-ID also cannot be found in http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-2 > > NOTE: Content-ID header field is defined to be a *MIME multipart/mixed* header field. > > However, rfc5368 section 7 and Figure 3 describe REFER request: > - with a single body (of application/resource-lists+xml MIME type) with a Content-ID *SIP* header field; and > - with Refer-To header field referring to the body. > > Also, it is possible to send an INVITE request *without SDP offer* and with location information according to rfc6442. In such case, the INVITE request: > - has a single body (of application/pidf+xml MIME type) with a Content-ID *SIP* header field; and > - has Geolocation header field referring to the body. > > One can of course put a single body inside a multipart/mixed, but that is rather messy. I assume the proper solution is to define the Content-ID header field as *SIP* header field. > > Is there any support for such definition? If so, I would prepare a draft. > > Kind regards > > Ivo Sedlacek > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Thu Aug 11 12:30:48 2016 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 C569F12B020 for ; Thu, 11 Aug 2016 12:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7386YCaRi87 for ; Thu, 11 Aug 2016 12:30:45 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 322C112B005 for ; Thu, 11 Aug 2016 12:30:45 -0700 (PDT) X-AuditID: c1b4fb2d-917ff700000019a3-a3-57acd2612b3b Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id F5.6B.06563.162DCA75; Thu, 11 Aug 2016 21:30:43 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.187]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0301.000; Thu, 11 Aug 2016 21:30:40 +0200 From: Ivo Sedlacek To: "Drage, Keith (Nokia - GB)" , "sipcore@ietf.org" Thread-Topic: Content-ID header field not defined in SIP Thread-Index: AdHz7HbNjd2T8u7kRR29JnCw0ka2hQADkf0gAALSxOA= Date: Thu, 11 Aug 2016 19:30:40 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101164C5672@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164C5617@ESESSMB301.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF49B95@FR711WXCHMBA04.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF49B95@FR711WXCHMBA04.zeu.alcatel-lucent.com> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM2K7lm7ypTXhBrd8LTZsOc5i8fXHJjYH Jo8lS34yedy9dYkpgCmKyyYlNSezLLVI3y6BK+N59xf2go2sFev+nmJvYFzC0sXIySEhYCLx a8s+xi5GLg4hgfWMEovbNrBDOEsYJd7/n8cGUsUmoCcxccsRVhBbRCBB4sGZTWC2sIC5xNnJ E9kh4hYSFyd8YIGwrSTaO1+A2SwCqhL7fz8Dq+cV8JVY97sFatsCRomJb2cwgSQ4BWIlbs+f BjaIUUBW4uqfXkYQm1lAXOLWk/lMEKcKSCzZc54ZwhaVePn4HyuErSSx6PZnJoh6HYkFuz+x QdjaEssWvmaGWCwocXLmE5YJjCKzkIydhaRlFpKWWUhaFjCyrGIULU4tLs5NNzLWSy3KTC4u zs/Ty0st2cQIjIiDW37r7mBc/drxEKMAB6MSD6/C3jXhQqyJZcWVuYcYJTiYlUR4T14ACvGm JFZWpRblxxeV5qQWH2KU5mBREuf1f6kYLiSQnliSmp2aWpBaBJNl4uCUamDsDvg/Q6apqPpJ 0tkLlxqPPZfp6xMybtCdkfjedUaevgz7j1t/+93WunPbHn4kF7IrZ6v3y/nr3iTOfSpUsfTT pgY/4y+KVq92qG33WNryb6HSwVzFYA+z2t3sssVnl/NmM6Y8aeI0v1xmdMsxoOuLrtWsqA/s sn9Pleetdj8Z+lKc5ZHDmd9KLMUZiYZazEXFiQDBL5XChAIAAA== Archived-At: Subject: Re: [sipcore] Content-ID header field not defined in SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 19:30:47 -0000 > Can we first establish the use case as to why we need one. I gave two cases below: > However, rfc5368 section 7 and Figure 3 describe REFER request: > - with a single body (of application/resource-lists+xml MIME type) with a= Content-ID *SIP* header field; and > - with Refer-To header field >>>referring to the body.<<< > > Also, it is possible to send an INVITE request *without SDP offer* and wi= th location information according to rfc6442. In such case, the INVITE requ= est: > - has a single body (of application/pidf+xml MIME type) with a Content-ID= *SIP* header field; and > - has Geolocation header field >>>referring to the body.<<< Kind regards Ivo From nobody Thu Aug 11 16:54:21 2016 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 08CA712D647 for ; Thu, 11 Aug 2016 16:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfYvmN4lUNh8 for ; Thu, 11 Aug 2016 16:54:18 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7621312B05E for ; Thu, 11 Aug 2016 16:54:18 -0700 (PDT) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-01v.sys.comcast.net with SMTP id Xzn0b7rHrTaLwXznlbOy5n; Thu, 11 Aug 2016 23:54:17 +0000 Received: from hobgoblin.ariadne.com ([73.100.16.189]) by comcast with SMTP id XznkbkwAATXV7XznlbFAHR; Thu, 11 Aug 2016 23:54:17 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u7BNsFS8011225; Thu, 11 Aug 2016 19:54:15 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u7BNsEE1011222; Thu, 11 Aug 2016 19:54:14 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Ivo Sedlacek In-Reply-To: <39B5E4D390E9BD4890E2B31079006101164C5617@ESESSMB301.ericsson.se> (ivo.sedlacek@ericsson.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 11 Aug 2016 19:54:14 -0400 Message-ID: <87d1le50bd.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfCpWhFZK7LUfAAIt1ca4EtwfSYuvlMfu3E22DnY4yPk9vMJqFUykFSOu4GwoFg3duwXfm+A1QQftXdOcTnyouxJdTjzYenP0lGc30talfnEW42Tpq0+j 8WeI8QOeszPhz3IdcdS76kZFzP2egI2zHCOUxybjl8wHLRy48j+pLLdrXaj47nkamNvykZ2743vK1s0d3CsZqQpwgMzXTZiEby8= Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Content-ID header field not defined in SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 23:54:20 -0000 Ivo Sedlacek writes: > The Content-ID header field does not seem to be defined as a *SIP* > header field - Content-ID cannot be found in in RFC3261 and Content-ID > also cannot be found in > http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-2 > Is there any support for such definition? If so, I would prepare a draft. It seems to me that, effectively, Content-ID is already defined as a SIP header. It seems to be just an accident that the published grammars include Content-ID headers for parts of multipart bodies in SIP messages but don't include Content-ID headers for the bodies of SIP messages. Thus, yes, I support a draft to correct the situation. Dale From nobody Thu Aug 11 21:17:58 2016 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 3340512D911 for ; Thu, 11 Aug 2016 21:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5Xj-ji4IRlA for ; Thu, 11 Aug 2016 21:17:53 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E60E712D8E7 for ; Thu, 11 Aug 2016 21:17:52 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id o80so7583011wme.1 for ; Thu, 11 Aug 2016 21:17:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/OnuHpLfQzqzbjPI3Z8y/9W9p9Uj1xPbkq36Ysa6Zm4=; b=KiE3DSLUKVNgnw+psdi1GlcPHmS16cl1/2LCsS29888UyNy//L0HZKisch9iGtiJ80 j9AM9buacFhuCeJuk0Vsy0CJC/cKurIE+/H5gwmKopl8vtG3HmIUNgZn5Pyx57hUrtYB IFbbK4PUp+1p3NUWblaJBQM+UU3lYn8YdFBBNOJpCqmPLbdT51Q6M5Pj0OJsCy8/K9Qr 59352s/8gtwT5P6LgQQ03NfhZvvwGnWXZapMSBLWsczPcDO1b9Z8JG1DoNL30gGwCcVE OesgSGiSwEbhrsNjDvyY4xAxm57CGlFm1Wo0wSSk1FDSnjndyQMOLrwb1JAgiiB5ifDb urRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/OnuHpLfQzqzbjPI3Z8y/9W9p9Uj1xPbkq36Ysa6Zm4=; b=HDsEsoOOyQ80wBRyR22BasFUpkalOTDqHev6GrvKGRPrD05W+KhvmC7nBCdIlrfKqG wk9QS/3blfZn+nKDfgQQEQNC2XzyWXr8wSY2YI3vnZKsfKsiz6NfP6Sb6Ab374nKsDEM fBoPUyS5AHqVJgsJ+hUSXlRxMYdUlNSvF2JYmzNLDHAYxJqS71jn7V+bD74OOBvfGQnJ y5Dq3Rb+HQIIb4dfJvTDRi6eUZA/chfmP+7gsQiLqe68q1N11KT+qsFKUpRP8nlQk3Xy +nLXlLs57QqjFFNWF4TFf65IR9g3OE1s2H+frY+shv6Fw9nR9Yqr1dYl/pv8YZhA4oJs hqww== X-Gm-Message-State: AEkoouvK6DkO75JlNdVhmAc9YkpgOw+W7sYPP1muoszTdyD22/QRoV420MHBUbOBG11o3Hw/4Liq585iOYanWA== X-Received: by 10.194.11.72 with SMTP id o8mr14914343wjb.10.1470975458616; Thu, 11 Aug 2016 21:17:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.96.139 with HTTP; Thu, 11 Aug 2016 21:17:38 -0700 (PDT) In-Reply-To: <39B5E4D390E9BD4890E2B31079006101164C5617@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164C5617@ESESSMB301.ericsson.se> From: Ranjit Avasarala Date: Thu, 11 Aug 2016 23:17:38 -0500 Message-ID: To: Ivo Sedlacek Content-Type: multipart/alternative; boundary=e89a8f234d49af29d60539d82929 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Content-ID header field not defined in SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2016 04:17:55 -0000 --e89a8f234d49af29d60539d82929 Content-Type: text/plain; charset=UTF-8 Hi I agree Content-ID is a useful header in SIP when there is no body and it could point to any URL. I can contribute to the draft if possible. Regards Ranjit On Thu, Aug 11, 2016 at 12:59 PM, Ivo Sedlacek wrote: > Hello, > > The Content-ID header field does not seem to be defined as a *SIP* header > field - Content-ID cannot be found in in RFC3261 and Content-ID also cannot > be found in http://www.iana.org/assignments/sip-parameters/ > sip-parameters.xhtml#sip-parameters-2 > > NOTE: Content-ID header field is defined to be a *MIME multipart/mixed* > header field. > > However, rfc5368 section 7 and Figure 3 describe REFER request: > - with a single body (of application/resource-lists+xml MIME type) with a > Content-ID *SIP* header field; and > - with Refer-To header field referring to the body. > > Also, it is possible to send an INVITE request *without SDP offer* and > with location information according to rfc6442. In such case, the INVITE > request: > - has a single body (of application/pidf+xml MIME type) with a Content-ID > *SIP* header field; and > - has Geolocation header field referring to the body. > > One can of course put a single body inside a multipart/mixed, but that is > rather messy. I assume the proper solution is to define the Content-ID > header field as *SIP* header field. > > Is there any support for such definition? If so, I would prepare a draft. > > Kind regards > > Ivo Sedlacek > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --e89a8f234d49af29d60539d82929 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi
I agree Content-ID is a useful = header in SIP when there is no body and it could point to any URL.=C2=A0 I = can contribute to the draft if possible.

Regards
Ran= jit=C2=A0

On Thu, Aug 11, 2016 at 12:59 PM, Ivo Sedlacek <ivo.sedlacek@er= icsson.com> wrote:
Hello,
The Content-ID header field does not seem to be defined as a *SIP* header f= ield - Content-ID cannot be found in in RFC3261 and Content-ID also cannot = be found in http= ://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#s= ip-parameters-2

NOTE: Content-ID header field is defined to be a *MIME multipart/mixed* hea= der field.

However, rfc5368 section 7 and Figure 3 describe REFER request:
- with a single body (of application/resource-lists+xml MIME type) with a C= ontent-ID *SIP* header field; and
- with Refer-To header field referring to the body.

Also, it is possible to send an INVITE request *without SDP offer* and with= location information according to rfc6442. In such case, the INVITE reques= t:
- has a single body (of application/pidf+xml MIME type) with a Content-ID *= SIP* header field; and
- has Geolocation header field referring to the body.

One can of course put a single body inside a multipart/mixed, but that is r= ather messy. I assume the proper solution is to define the Content-ID heade= r field as *SIP* header field.

Is there any support for such definition? If so, I would prepare a draft.
Kind regards

Ivo Sedlacek


_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore<= br>

--e89a8f234d49af29d60539d82929-- From nobody Mon Aug 15 06:16:34 2016 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D91A12D8C9; Mon, 15 Aug 2016 06:16:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147126699230.31678.9613693360268273574.idtracker@ietfa.amsl.com> Date: Mon, 15 Aug 2016 06:16:32 -0700 Archived-At: Cc: sipcore@ietf.org, draft-ietf-sipcore-dns-dual-stack@ietf.org, sipcore-chairs@ietf.org Subject: [sipcore] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Yes_on_draft-ietf-si?= =?utf-8?q?pcore-dns-dual-stack-07=3A_=28with_COMMENT=29?= X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 13:16:32 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-sipcore-dns-dual-stack-07: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sipcore-dns-dual-stack/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks! This seems very useful in the preparation for Happy-Eyeballs. One question: Why does a client need to look up ALL addresses if it already knows that it itself only support one specific address familiy? And related to this question: Shouldn't it be named "multi-stack client" instead of "dual-stack client"? From nobody Tue Aug 16 00:23:00 2016 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 A0D5912D094 for ; Tue, 16 Aug 2016 00:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHR0uH7lDK-3 for ; Tue, 16 Aug 2016 00:22:56 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56703127078 for ; Tue, 16 Aug 2016 00:22:53 -0700 (PDT) Received: from [192.168.40.20] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 6897D426A; Tue, 16 Aug 2016 09:22:49 +0200 (CEST) From: "Olle E. Johansson" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Aug 2016 09:22:53 +0200 Message-Id: To: sipcore@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Olle E Johansson Subject: [sipcore] New SIP Forum Document: TWG-9 on IPv6 impact on IPv4 SIP implementations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 07:22:59 -0000 Hi! A while ago the SIP Forum IPv6 working group produced a document on the = impact of IPv6 on IPv4-only SIP implementations, in order to inform = developers about issues found at the SIP Forum SIPit events and in real = life tests in other places. We contributed this document to the IETF but = as it did not really match the IETF documentation flow, we decided to = finally publish it as a SIP Forum document. You can find it here: = http://www.sipforum.org/component/option,com_docman/task,cat_view/gid,129/= Itemid,261/ This document captures potential impacts to IPv4 SIP implementations = when interworking with IPv6 SIP implementations. Although some amount of = interworking translation will occur at the network and application = layers, an IPv4 SIP application may still encounter a SIP message with = some IPv6 values in it, resulting in unforeseen error conditions. Such = potential scenarios will be identified in this document so that SIP = application developers can define solutions to handle these cases. Note, = this document is not intended to be an exhaustive list, rather to = provide an overview of some of the more commonly encountered potential = scenarios. A big thank you to everyone involved in the process and especially to my = co-authors Carl Klatsky and Gonzalo Salgueiro! We will continue testing at the SIPit event in New Hampshire in = September. If you haven=E2=80=99t registred yet, it=E2=80=99s high time. = Go to http://www.sipit.net and read more.=20 Best regards, /Olle From nobody Tue Aug 16 06:50:58 2016 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 5BFC612D843 for ; Tue, 16 Aug 2016 06:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YT70jVp95Bpr for ; Tue, 16 Aug 2016 06:50:55 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01DC612D841 for ; Tue, 16 Aug 2016 06:50:54 -0700 (PDT) X-AuditID: c1b4fb2d-917ff700000019a3-7f-57b31a3c5ad4 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by (Symantec Mail Security) with SMTP id 37.A4.06563.C3A13B75; Tue, 16 Aug 2016 15:50:53 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.179]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0301.000; Tue, 16 Aug 2016 15:50:51 +0200 From: Christer Holmberg To: "sipcore@ietf.org" Thread-Topic: Draft new: draft-holmberg-sipcore-content-id-00 Thread-Index: AQHR98S6mkJf3bvA+kChF4NYCmV/nKBLrLyA Date: Tue, 16 Aug 2016 13:50:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_D3D8F5C4CB5Cchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGIsWRmVeSWpSXmKPExsUyM2K7n66t1OZwg4s/xSy+/tjE5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujG9LtrMUnJSq2Dj7A1sD4xqxLkZODgkBE4m+5Y+Yuxi5OIQE 1jNK7HjSzg7hLGGU+PT1BVsXIwcHm4CFRPc/bZAGEQFNieXftrKD2MIClhITD75hgojbSTQv PMkOYRtJPHg2kQ3EZhFQlZj16TYziM0rYCUxY+c9FhBbCMh++64dLM4pYC0xe8pbsDijgJjE 91NrwGYyC4hL3HoynwniUAGJJXvOM0PYohIvH/9jBbFFBfQkvn+dDRVXlGh/2sAI0Rsvcf71 ZhaIvYISJ2c+YZnAKDILydhZSMpmISmDiBtIvD83nxnC1pZYtvA1lK0vsfHLWUYI21rizLXd jMhqFjByrGIULU4tLs5NNzLWSy3KTC4uzs/Ty0st2cQIjK2DW37r7mBc/drxEKMAB6MSD68C 86ZwIdbEsuLK3EOMEhzMSiK8h0U3hwvxpiRWVqUW5ccXleakFh9ilOZgURLn9X+pGC4kkJ5Y kpqdmlqQWgSTZeLglGpgDGgXWac3l3XfCV/HyoN21VMXfPruW/gta/30T4zTt0nOvLBApObG N79l7DeuJmUam++O8ZN6HvnEn0EkSfrz/qV/3wkxqAu2T+lqv39X/zfXUa1LrClb1d+v/mH+ v6TmB0NNR/vSFYf1X/WKXOPK7JNikV7f86bifuys5VMVF3T8SF+RemvJfCWW4oxEQy3mouJE AOoUCqGpAgAA Archived-At: Subject: [sipcore] Draft new: draft-holmberg-sipcore-content-id-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 13:50:57 -0000 --_000_D3D8F5C4CB5Cchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, When a SIP message contains a multipart/mixed body, individual body parts c= an be associated with a Content-ID header field and header fields of the SI= P message can refer to those body parts. Note that the Content-ID is not a = SIP header field in such cases, but a MIME header field related to the indi= vidual body part. However, in ECRIT it was identified that there are cases where a request wi= th a single message body also needs a Content-ID header field as header fie= lds of SIP message needs to refer to the body =96 in which Content-ID it ne= eds to become a SIP header field. Later, it was also realised that there exist non-ECRIT cases where it is al= so needed. Please see the draft for examples. We have submitted a draft, which gives description of the problem and defin= es the Content-ID header field for SIP. For the GitHub fans: https://github.com/cdh4u/draft-content-id (NOTE: Indiv= idual repo) Regards, Christer & Ivo --_000_D3D8F5C4CB5Cchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi,

When a SIP message contains a multipart/mixed body, individual body pa= rts can be associated with a Content-ID header field and header fields of t= he SIP message can refer to those body parts. Note that the Content-ID is n= ot a SIP header field in such cases, but a MIME header field related to the individual body part.

However, in ECRIT it was identified that there are cases where a reque= st with a single message body also needs a Content-ID header field as heade= r fields of SIP message needs to refer to the body =96 in which Content-ID = it needs to become a SIP header field.

Later, it was also realised that there exist non-ECRIT cases where it = is also needed.

Please see the draft for examples.

We have submitted a draft, which gives description of the problem and = defines the Content-ID header field for SIP.

For the GitHub fans: https://github.com/cdh4u/draft-content-id (NOTE: Individ= ual repo)

Regards,

Christer & Ivo
 --_000_D3D8F5C4CB5Cchristerholmbergericssoncom_-- From nobody Tue Aug 16 08:39:50 2016 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 9038112D882 for ; Tue, 16 Aug 2016 08:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4uX3wKr5F_N for ; Tue, 16 Aug 2016 08:39:47 -0700 (PDT) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 432D312D864 for ; Tue, 16 Aug 2016 08:39:47 -0700 (PDT) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-11v.sys.comcast.net with SMTP id ZgScbo6JHlSxsZgSwbx2cE; Tue, 16 Aug 2016 15:39:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-20v.sys.comcast.net with SMTP id ZgSwbzNUeFTmAZgSwbnYjL; Tue, 16 Aug 2016 15:39:46 +0000 To: sipcore@ietf.org References: From: Paul Kyzivat Message-ID: Date: Tue, 16 Aug 2016 11:39:45 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfG4F2PfscKKQ+SpmmspYK66vpFKapSXHLlH3XG2EohL3/8UBlSlD4V5ddsssyFIsbYjwchFCBaByNcvSKKjDdOr0/kQKb/cx4dIqZs5DH8fH1WWrT7WN q268Bo6B4JqJoLCKcsCvoBGWd9UBC2rWb+EIe3MevfQdT/CKIwN/mQqBQjBTAtN2tLhkJT1rpgX0ww== Archived-At: Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-content-id-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 15:39:48 -0000 Quick turnaround! It seems to do the job, and I especially like the conciseness of the abstract. I'm just wondering if there are any other things like this that ought to be included. ISTM that RFC2042 can be considered a "base class" for a family of message syntaxes that share a common style. Viewed that way, SIP ought to support all of the header fields defined in RFC2042. Those include: - mime-version - content-type - content-transfer-encoding - content-id - content-description It also generically adopts . Unfortunately none of this seems to be defined in a way that is intended to support this sort of subclassing model. So it isn't straightforward to simply declare SIP to be a subclass of MIME and leave it at that. But we could define the others one by one, by reference. Thanks, Paul On 8/16/16 9:50 AM, Christer Holmberg wrote: > > Hi, > > When a SIP message contains a multipart/mixed body, individual body > parts can be associated with a Content-ID header field and header fields > of the SIP message can refer to those body parts. Note that the > Content-ID is not a SIP header field in such cases, but a MIME header > field related to the individual body part. > > However, in ECRIT it was identified that there are cases where a request > with a single message body also needs a Content-ID header field as > header fields of SIP message needs to refer to the body in which > Content-ID it needs to become a SIP header field. > > Later, it was also realised that there exist non-ECRIT cases where it is > also needed. > > Please see the draft for examples. > > We have submitted a draft, which gives description of the problem and > defines the Content-ID header field for SIP. > > For the GitHub fans: https://github.com/cdh4u/draft-content-id (NOTE: > Individual repo) > > > Regards, > > Christer & Ivo > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Tue Aug 16 20:31:32 2016 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 67AFB12B005; Tue, 16 Aug 2016 20:31:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147140468741.19939.3811368106001545602.idtracker@ietfa.amsl.com> Date: Tue, 16 Aug 2016 20:31:27 -0700 Archived-At: Cc: sipcore@ietf.org, draft-ietf-sipcore-dns-dual-stack@ietf.org, sipcore-chairs@ietf.org Subject: [sipcore] Spencer Dawkins' Yes on draft-ietf-sipcore-dns-dual-stack-07: (with COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 03:31:27 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-sipcore-dns-dual-stack-07: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sipcore-dns-dual-stack/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I appreciate this work. I do have one comment. Could you provide some explanation for the reader as to why SIP is "different", following this statement? Even an example would be useful. Unfortunately, in common SIP situations, it is not possible to "race" simultaneous request attempts using two address families. From nobody Wed Aug 17 04:44:12 2016 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 30E6812D66C for ; Wed, 17 Aug 2016 04:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwbE1pyMjsD1 for ; Wed, 17 Aug 2016 04:44:09 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6BCB12D74A for ; Wed, 17 Aug 2016 04:37:17 -0700 (PDT) X-AuditID: c1b4fb2d-cf87d980000019a3-c3-57b44c6b0fc5 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id 2C.A1.06563.B6C44B75; Wed, 17 Aug 2016 13:37:15 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.224]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0301.000; Wed, 17 Aug 2016 13:37:14 +0200 From: Ivo Sedlacek To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Draft new: draft-holmberg-sipcore-content-id-00 Thread-Index: AQHR98S6mkJf3bvA+kChF4NYCmV/nKBLrLyA///rB4CAAW/xEA== Date: Wed, 17 Aug 2016 11:37:14 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101164EB950@ESESSMB301.ericsson.se> References: In-Reply-To: Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM2K7q262z5Zwg7/brCxWbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj5urvLAW/RCvmf/3M0sD4TrCLkZNDQsBE 4v/OmcxdjFwcQgLrGSXmzTjJCuEsYZRoezedBaSKTUBPYuKWI6wgtohAoMTVJROYQWxhATeJ C+umMHYxcgDF3SUeL6iCKHGS2HhjJztImEVAVeLspTiQMK+Ar8TkH1+hxi9klPixaAMbSIJT wEGipX8W2HhGAVmJq396GUFsZgFxiVtP5jNBHCogsWTPeWYIW1Ti5eN/rBC2okT70waoeh2J Bbs/sUHY2hLLFr5mhlgsKHFy5hOWCYwis5CMnYWkZRaSlllIWhYwsqxiFC1OLS7OTTcy1kst ykwuLs7P08tLLdnECIyHg1t+6+5gXP3a8RCjAAejEg/vgpDN4UKsiWXFlbmHGCU4mJVEeFs8 toQL8aYkVlalFuXHF5XmpBYfYpTmYFES5/V/qRguJJCeWJKanZpakFoEk2Xi4JRqYEw6ayXS tjQir8Rc6kdjfql+vYne+oWf+mL7IiTvvZkh+m/zxTnp3bMvLzYNcTf40/DQte7OkiunLERf rjjTtrKrdrPC/c8K7lktb8MOeLPO+BHte3N5V1RI15dziufPPtVfmatdIZv3lsGyWeS36gd3 Vd4Vt1iKZ/YHR6TfYJO+fr3r47a+9UosxRmJhlrMRcWJAHeKEMCDAgAA Archived-At: Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-content-id-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 11:44:11 -0000 Hello, thank you for the comments. > ISTM that RFC2042 can be considered a "base class" for a family of=20 > message syntaxes that share a common style. Viewed that way, SIP ought=20 > to support all of the header fields defined in RFC2042. Those include: >=20 > - mime-version Would the MIME-Version header field be included in header fields of a SIP m= essage solely when the SIP message contains one body, or would it be includ= ed in case when SIP message contains several bodies?=20 BTW, HTTP MIME-Version header field is specified - see http://www.iana.org/= assignments/message-headers/message-headers.xhtml=20 > - content-type MIME Content-Type header field defined in RFC2045 matches the SIP Content-T= ype header field defined in RFC3261. Please note that ABNF for SIP Content-= Type header field is based on ABNF in RFC2616 while ABNF for MIME Content-T= ype header field is in RFC2045. So, IMO, everything is in place for Content-Type. > - content-transfer-encoding Is this really needed? SIP provides binary transport. HTTP Content-Transfer-Encoding header field is NOT specified either - see h= ttp://www.iana.org/assignments/message-headers/message-headers.xhtml > - content-id This is proposed to be specified the draft. > - content-description HTTP Content-Description header field is NOT specified either - see http://= www.iana.org/assignments/message-headers/message-headers.xhtml > It also generically adopts the string "Content-">. On top of the above, http://www.iana.org/assignments/message-headers/messag= e-headers.xhtml additionally gives the following MIME or HTTP headers: - Content-Alternative - in MIME, not in HTTP (and not available in SIP) - Content-Base - in MIME, in HTTP (and not available in SIP). Marked as "ob= soleted" - Content-Disposition - in MIME, in HTTP (and available in SIP) - Content-Duration - in MIME, not in HTTP (and not available in SIP) - Content-Encoding - not in MIME, in HTTP (and available in SIP) - Content-features - in MIME, not in HTTP (and not available in SIP) - Content-Language - in MIME, in HTTP (and available in SIP) - Content-Length - not in MIME, in HTTP (and available in SIP) - Content-Location - in MIME, in HTTP (and not available in SIP) - Content-MD5 - in MIME, in HTTP (and not available in SIP) - Content-Range - not in MIME, in HTTP (and not available in SIP) - Content-Script-Type - not in MIME, in HTTP (and not available in SIP) - Content-Style-Type - not in MIME, in HTTP (and not available in SIP) - Content-Version - not in MIME, in HTTP (and not available in SIP) Not sure whether any header fields of the above (which are not in SIP alrea= dy) are useful for SIP. Kind regards Ivo From nobody Wed Aug 17 05:02:13 2016 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 58A4812D563 for ; Wed, 17 Aug 2016 05:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-iqGkkkZAep for ; Wed, 17 Aug 2016 05:02:07 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E11C812D0B4 for ; Wed, 17 Aug 2016 05:02:06 -0700 (PDT) X-AuditID: c1b4fb3a-0618b980000009bd-d7-57b4523d5f59 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id B4.F4.02493.D3254B75; Wed, 17 Aug 2016 14:02:05 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.179]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0301.000; Wed, 17 Aug 2016 14:02:02 +0200 From: Christer Holmberg To: Ivo Sedlacek , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Draft new: draft-holmberg-sipcore-content-id-00 Thread-Index: AQHR99Rv7KHCso5O+UushCbQ3/zT+aBM5jYAgAA6WIA= Date: Wed, 17 Aug 2016 12:02:02 +0000 Message-ID: References: <39B5E4D390E9BD4890E2B31079006101164EB950@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B31079006101164EB950@ESESSMB301.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="us-ascii" Content-ID: <0A965BD43785274CB13909FB13ACFD44@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2K7lq5t0JZwg+9PBC1WbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStj/8HHLAUvWStWLE5oYLzJ0sXIySEhYCIx oaeBuYuRi0NIYD2jxLX9LVDOEkaJS2d3snYxcnCwCVhIdP/TBmkQEaiWmHx0OxuILSzgJtHU BDKIAyjuLvF4QRVEiZXEnO13mUBsFgFViXkdixhBbF6g+OovC9kgxj9llPgz8yjYEZwCfhI7 F+9kBrEZBcQkvp9aA9bMLCAucevJfCaIQwUkluw5zwxhi0q8fPyPFcQWFdCT+P51NjPIDRIC ShLTtqZBtOpILNj9iQ3CtpZo6HwPNVJbYtnC18wQ9whKnJz5hGUCo9gsJNtmIWmfhaR9FpL2 WUjaFzCyrmIULU4tLs5NNzLSSy3KTC4uzs/Ty0st2cQIjKmDW35b7WA8+NzxEKMAB6MSD++C kM3hQqyJZcWVuYcYJTiYlUR49wVsCRfiTUmsrEotyo8vKs1JLT7EKM3BoiTO6/9SMVxIID2x JDU7NbUgtQgmy8TBKdXAmP9U/HoT+/djn7WdXoffVlJ12H3h7eRPSjkCWXkPkq6+CmIRuD9x zltB2/PLVL7fvtL0IttqXn2608Os1mL9w07qfifrjZ4b7p1e9iRnW8jUHTMYymOup7yXjFDp Lr7+1vsfc76D9UZ/442eMyVn7xD45LjQ/MH6zjsdXytyGVqLC9LcJy35rMRSnJFoqMVcVJwI APemfK2lAgAA Archived-At: Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-content-id-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 12:02:11 -0000 Hi, >>ISTM that RFC2042 can be considered a "base class" for a family of >> message syntaxes that share a common style. Viewed that way, SIP ought >> to support all of the header fields defined in RFC2042. Those include: >>=20 >> - mime-version > >Would the MIME-Version header field be included in header fields of a SIP >message solely when the SIP message contains one body, or would it be >included in case when SIP message contains several bodies? > >BTW, HTTP MIME-Version header field is specified - see >http://www.iana.org/assignments/message-headers/message-headers.xhtml MIME-Version is already defined as a SIP header field in RFC 3261, and you can see usage examples e.g. in RFC 3204. Regards, Christer From nobody Wed Aug 17 12:39:17 2016 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 8BF7712D104 for ; Wed, 17 Aug 2016 12:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.448 X-Spam-Level: X-Spam-Status: No, score=-5.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYZEP_r0u_Bt for ; Wed, 17 Aug 2016 12:39:11 -0700 (PDT) Received: from alum-mailsec-scanner-7.mit.edu (alum-mailsec-scanner-7.mit.edu [18.7.68.19]) by ietfa.amsl.com (Postfix) with ESMTP id 1143612B039 for ; Wed, 17 Aug 2016 12:39:10 -0700 (PDT) X-AuditID: 12074413-aa3ff70000000955-ae-57b4bd5d4722 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by (Symantec Messaging Gateway) with SMTP id D8.86.02389.D5DB4B75; Wed, 17 Aug 2016 15:39:09 -0400 (EDT) Received: from Paul-Kyzivats-MacBook-Pro.local (c-73-218-51-154.hsd1.ma.comcast.net [73.218.51.154]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id u7HJd8Mi016756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 17 Aug 2016 15:39:09 -0400 From: Paul Kyzivat To: Ivo Sedlacek References: <39B5E4D390E9BD4890E2B31079006101164EB945@ESESSMB301.ericsson.se> Message-ID: <8f0c6119-869c-e4d5-dabe-7a0c6542f590@alum.mit.edu> Date: Wed, 17 Aug 2016 15:39:07 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <39B5E4D390E9BD4890E2B31079006101164EB945@ESESSMB301.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPIsWRmVeSWpSXmKPExsUixO6iqBu7d0u4wZF3mha9K+exWnz9sYnN gcnj19erbB5LlvxkCmCK4rJJSc3JLEst0rdL4Mr4uMu0oFe54vayv4wNjFNluhg5OSQETCRu tz9h7WLk4hAS2Moo8ftvKzuE85RJon/GL2aQKjYBLYk5h/6zgNjCAm4STU03wWwRAR2J/msL GKEaGCV+XL7HBpJgFpCTWLt8FzuIzStgL7FowUamLkYODhYBVYn9u9VBwqICaRLTD/czQpQI Spyc+YQFpIRTwE9iztdgiCm2Enfm7maGsOUltr+dwzyBkX8Wko5ZSMpmISlbwMi8ilEuMac0 Vzc3MTOnODVZtzg5MS8vtUjXXC83s0QvNaV0EyMkHIV3MO46KXeIUYCDUYmHV2DGlnAh1sSy 4srcQ4ySHExKorxRc4FCfEn5KZUZicUZ8UWlOanFhxglOJiVRHjDdwDleFMSK6tSi/JhUtIc LErivGpL1P2EBNITS1KzU1MLUotgsjIcHEoSvAzAuBMSLEpNT61Iy8wpQUgzcXCCDOcBGn5n D8jw4oLE3OLMdIj8KUZFKXFeIZCEAEgiozQPrheWLl4xigO9IswbDFLFA0w1cN2vgAYzAQ3m 5QcbXJKIkJJqYOw0LVzf33ZkjuGe3/rTt2ofEvjbdfymSVlrG48w40zLJfd4F74JuTI7vrpU zbTttfeuaeqzojbl9zPsdJirZflaoOtgSf6Orc1vZ7DWas2yDmDTX/E+1SRpX45siEWH6Ts/ KfVlXydolnNuaYmfv333p9WrGf5JB2xtYsluXHXi2/4njIuUK5VYijMSDbWYi4oTAZzKgnLy AgAA Archived-At: Cc: SIPCORE Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-content-id-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 19:39:15 -0000 Ivo, On 8/17/16 7:36 AM, Ivo Sedlacek wrote: > Hello, > > thank you for the comments. > >> ISTM that RFC2042 can be considered a "base class" for a family of >> message syntaxes that share a common style. Viewed that way, SIP ought >> to support all of the header fields defined in RFC2042. Those include: Just to be clear - I am not well schooled on all the intricacies of MIME. So I'm not sure which of these header fields might be (or not be) relevant for SIP. I brought it up to encourage a broader discussion. >> - mime-version > > Would the MIME-Version header field be included in header fields of a SIP message solely when the SIP message contains one body, or would it be included in case when SIP message contains several bodies? > > BTW, HTTP MIME-Version header field is specified - see http://www.iana.org/assignments/message-headers/message-headers.xhtml I think this is not clear. The 3261 definition is simply a reference to HTTP (RFC2616), without any explanation. And RFC2616 isn't very clear about it either - but does say its use is optional. So this may deserve some clarification. >> - content-type > > MIME Content-Type header field defined in RFC2045 matches the SIP Content-Type header field defined in RFC3261. Please note that ABNF for SIP Content-Type header field is based on ABNF in RFC2616 while ABNF for MIME Content-Type header field is in RFC2045. > > So, IMO, everything is in place for Content-Type. Yep. >> - content-transfer-encoding > > Is this really needed? SIP provides binary transport. > > HTTP Content-Transfer-Encoding header field is NOT specified either - see http://www.iana.org/assignments/message-headers/message-headers.xhtml Since sip provides for binary transfer it does seem *unnecessary*. For some uses it might still be convenient if somebody has an already encoded body they want to include. The downside is that it would not be backward compatible. I guess it is currently still possible as long as used in one part of a multipart body. >> - content-id > > This is proposed to be specified the draft. > >> - content-description > > HTTP Content-Description header field is NOT specified either - see http://www.iana.org/assignments/message-headers/message-headers.xhtml Since it seems to be intended solely for human consumption it doesn't seem very important. >> It also generically adopts > the string "Content-">. > > On top of the above, http://www.iana.org/assignments/message-headers/message-headers.xhtml additionally gives the following MIME or HTTP headers: I was looking for a registry and didn't find it. > - Content-Alternative - in MIME, not in HTTP (and not available in SIP) > - Content-Base - in MIME, in HTTP (and not available in SIP). Marked as "obsoleted" > - Content-Disposition - in MIME, in HTTP (and available in SIP) > - Content-Duration - in MIME, not in HTTP (and not available in SIP) > - Content-Encoding - not in MIME, in HTTP (and available in SIP) > - Content-features - in MIME, not in HTTP (and not available in SIP) > - Content-Language - in MIME, in HTTP (and available in SIP) > - Content-Length - not in MIME, in HTTP (and available in SIP) > - Content-Location - in MIME, in HTTP (and not available in SIP) > - Content-MD5 - in MIME, in HTTP (and not available in SIP) > - Content-Range - not in MIME, in HTTP (and not available in SIP) > - Content-Script-Type - not in MIME, in HTTP (and not available in SIP) > - Content-Style-Type - not in MIME, in HTTP (and not available in SIP) > - Content-Version - not in MIME, in HTTP (and not available in SIP) > > Not sure whether any header fields of the above (which are not in SIP already) are useful for SIP. Unfortunately ISTM that MIME hasn't been managed in a way that clearly separates those parts that are generic from those that are only meaningful for mail. (But I haven't studied all the docs, so maybe I'm wrong about this.) Clearly http has done its own picking and choosing, as has sip. But the criteria for doing so aren't so obvious. The current experience with content-id shows that potentially any mime body might make sense in a sip message. ISTM the question we need to ask is where to draw the line between those that can be included directly, vs. those that can only be included by wrapping them in another layer of mime wrapper. Thanks, Paul From nobody Wed Aug 17 14:58:30 2016 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7214812D0FB; Wed, 17 Aug 2016 14:58:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Suresh Krishnan" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147147110646.23797.16205066964281684411.idtracker@ietfa.amsl.com> Date: Wed, 17 Aug 2016 14:58:26 -0700 Archived-At: Cc: sipcore@ietf.org, draft-ietf-sipcore-dns-dual-stack@ietf.org, sipcore-chairs@ietf.org Subject: [sipcore] Suresh Krishnan's Discuss on draft-ietf-sipcore-dns-dual-stack-07: (with DISCUSS) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 21:58:26 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-sipcore-dns-dual-stack-07: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sipcore-dns-dual-stack/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- * Section 3.1 It is not clear to me what exactly the normative addendum is requiring the client to do as regards to the DNS query while implementing "The dual-stack client SHOULD look up all address records". Does this mean that the client should do a AAAA (28) query followed by (or in parallel or preceded ) for a A (1) query? I think it would be good to clarify the types and ordering/concurrency of the queries. * Section 4 I am a bit puzzled by the merging of the address lists from two separate DNS queries in relation to RFC6724. This is how I see the destination address selection in RFC6724. The application ends up calling some kind of name resolution API (something like getaddrinfo()) with a hostname/FQDN (say sip-1.example.com) and this results in a set of addresses being returned. The destination address selection algorithm specified in Section 6 of RFC6724 then orders these addresses and picks one. I am not seeing how the second FQDN and its associated set of addresses become involved in the RFC6724 process. Is this something that you are adding on top of RFC6724? Please clarify. From nobody Thu Aug 18 05:28:13 2016 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 5299312DBF5 for ; Thu, 18 Aug 2016 05:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QuZzkjaHUVwO for ; Thu, 18 Aug 2016 05:28:10 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75D4C12DC44 for ; Thu, 18 Aug 2016 05:26:00 -0700 (PDT) X-AuditID: c1b4fb30-ad3ff700000009f9-41-57b5a955d430 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id B5.14.02553.559A5B75; Thu, 18 Aug 2016 14:25:58 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.179]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0301.000; Thu, 18 Aug 2016 14:25:56 +0200 From: Christer Holmberg To: Paul Kyzivat , Ivo Sedlacek Thread-Topic: [sipcore] Draft new: draft-holmberg-sipcore-content-id-00 Thread-Index: AQHR99Rv7KHCso5O+UushCbQ3/zT+aBNjnBUgAErIwA= Date: Thu, 18 Aug 2016 12:25:56 +0000 Message-ID: References: <39B5E4D390E9BD4890E2B31079006101164EB945@ESESSMB301.ericsson.se> <8f0c6119-869c-e4d5-dabe-7a0c6542f590@alum.mit.edu> In-Reply-To: <8f0c6119-869c-e4d5-dabe-7a0c6542f590@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <38E4E4A4FDDF444E9E604AA231730704@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPIsWRmVeSWpSXmKPExsUyM2K7vW7Yyq3hBndm6Fus2HCA1eLrj01s Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGiRm/2Quea1VsfrKBrYHxnFIXIyeHhICJ xNtdn9m7GLk4hATWM0q0/DvKDOEsYZT4sGIqaxcjBwebgIVE9z9tkAYRgRCJ7v//2EBsZgE5 iesfNoLZwgJuEk1NN1lAykUE3CUeL6iCMK0kZq60B6lgEVCVeHp3EjuIzQsUnnbvENSm2UwS 5x78YgJJcAo4SJyfNQOsiFFATOL7qTVMEKvEJW49mc8EcbOAxJI955khbFGJl4//sYLYogJ6 Et+/zoaKK0pcnb4cqldP4sbUKVAnW0ucbXsJZWtLLFv4mhniIEGJkzOfsExgFJ+FZN0sJO2z kLTPQtI+C0n7AkbWVYyixanFSbnpRkZ6qUWZycXF+Xl6eaklmxiB0XZwy2+DHYwvnzseYhTg YFTi4VVYtiVciDWxrLgy9xCjBAezkghv2Iqt4UK8KYmVValF+fFFpTmpxYcYpTlYlMR5/V8q hgsJpCeWpGanphakFsFkmTg4pRoY/U5W+fx6K7DjjIQYi6Bjftij9jrJTWccp52ax6WqxBDw xcLs629RubRFxzsLFQ8blp1OvJShreS861GMpdSnBerb74ZmPL6xt/aUVrzWDN7e5/qbA5kd Fm46Fck/2/b7rDSRnE2Zi6fMrtvacurlnyltGy5ea1BRPZNT0ppt+b4l7o/U+5aHSizFGYmG WsxFxYkAM65CLbICAAA= Archived-At: Cc: SIPCORE Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-content-id-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 12:28:12 -0000 Hi, I don=B9t think we shall try to =B3fix everything=B2. We know that such wor= k may take forever. The draft identifies the problem with Content-ID. If someone else know about similar problems with other header fields, please bring it to the WG. Obviously, if we think that the definition of some header field that IS already defined for SIP (e.g. MIME-Version) is unclear, we can discuss whether we should fix that. But, let=B9s work to fix the stuff that people need. If people need something else in future, they can write a draft... Regards, Christer On 17/08/16 22:39, "sipcore on behalf of Paul Kyzivat" wrote: >Ivo, > >On 8/17/16 7:36 AM, Ivo Sedlacek wrote: >> Hello, >> >> thank you for the comments. >> >>> ISTM that RFC2042 can be considered a "base class" for a family of >>> message syntaxes that share a common style. Viewed that way, SIP ought >>> to support all of the header fields defined in RFC2042. Those include: > >Just to be clear - I am not well schooled on all the intricacies of >MIME. So I'm not sure which of these header fields might be (or not be) >relevant for SIP. I brought it up to encourage a broader discussion. > >>> - mime-version >> >> Would the MIME-Version header field be included in header fields of a >>SIP message solely when the SIP message contains one body, or would it >>be included in case when SIP message contains several bodies? >> >> BTW, HTTP MIME-Version header field is specified - see >>http://www.iana.org/assignments/message-headers/message-headers.xhtml > >I think this is not clear. The 3261 definition is simply a reference to >HTTP (RFC2616), without any explanation. And RFC2616 isn't very clear >about it either - but does say its use is optional. > >So this may deserve some clarification. > >>> - content-type >> >> MIME Content-Type header field defined in RFC2045 matches the SIP >>Content-Type header field defined in RFC3261. Please note that ABNF for >>SIP Content-Type header field is based on ABNF in RFC2616 while ABNF for >>MIME Content-Type header field is in RFC2045. >> >> So, IMO, everything is in place for Content-Type. > >Yep. > >>> - content-transfer-encoding >> >> Is this really needed? SIP provides binary transport. >> >> HTTP Content-Transfer-Encoding header field is NOT specified either - >>see http://www.iana.org/assignments/message-headers/message-headers.xhtml > >Since sip provides for binary transfer it does seem *unnecessary*. For >some uses it might still be convenient if somebody has an already >encoded body they want to include. The downside is that it would not be >backward compatible. > >I guess it is currently still possible as long as used in one part of a >multipart body. > >>> - content-id >> >> This is proposed to be specified the draft. >> >>> - content-description >> >> HTTP Content-Description header field is NOT specified either - see >>http://www.iana.org/assignments/message-headers/message-headers.xhtml > >Since it seems to be intended solely for human consumption it doesn't >seem very important. > >>> It also generically adopts >> the string "Content-">. >> >> On top of the above, >>http://www.iana.org/assignments/message-headers/message-headers.xhtml >>additionally gives the following MIME or HTTP headers: > >I was looking for a registry and didn't find it. > >> - Content-Alternative - in MIME, not in HTTP (and not available in SIP) >> - Content-Base - in MIME, in HTTP (and not available in SIP). Marked as >>"obsoleted" >> - Content-Disposition - in MIME, in HTTP (and available in SIP) >> - Content-Duration - in MIME, not in HTTP (and not available in SIP) >> - Content-Encoding - not in MIME, in HTTP (and available in SIP) >> - Content-features - in MIME, not in HTTP (and not available in SIP) >> - Content-Language - in MIME, in HTTP (and available in SIP) >> - Content-Length - not in MIME, in HTTP (and available in SIP) >> - Content-Location - in MIME, in HTTP (and not available in SIP) >> - Content-MD5 - in MIME, in HTTP (and not available in SIP) >> - Content-Range - not in MIME, in HTTP (and not available in SIP) >> - Content-Script-Type - not in MIME, in HTTP (and not available in SIP) >> - Content-Style-Type - not in MIME, in HTTP (and not available in SIP) >> - Content-Version - not in MIME, in HTTP (and not available in SIP) >> >> Not sure whether any header fields of the above (which are not in SIP >>already) are useful for SIP. > >Unfortunately ISTM that MIME hasn't been managed in a way that clearly >separates those parts that are generic from those that are only >meaningful for mail. (But I haven't studied all the docs, so maybe I'm >wrong about this.) > >Clearly http has done its own picking and choosing, as has sip. But the >criteria for doing so aren't so obvious. > >The current experience with content-id shows that potentially any mime >body might make sense in a sip message. ISTM the question we need to ask >is where to draw the line between those that can be included directly, >vs. those that can only be included by wrapping them in another layer of >mime wrapper. > > Thanks, > Paul > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Aug 18 06:03:19 2016 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 107B212DDC0 for ; Thu, 18 Aug 2016 06:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_MIME_MALF=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bcB-ZO2bFBu for ; Thu, 18 Aug 2016 06:03:08 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68CEB12DDA8 for ; Thu, 18 Aug 2016 06:02:58 -0700 (PDT) X-AuditID: c1b4fb25-ca31e98000001071-55-57b5b2004ea4 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by (Symantec Mail Security) with SMTP id 4E.53.04209.002B5B75; Thu, 18 Aug 2016 15:02:56 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.224]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0301.000; Thu, 18 Aug 2016 15:02:55 +0200 From: Ivo Sedlacek To: Christer Holmberg , Paul Kyzivat Thread-Topic: [sipcore] Draft new: draft-holmberg-sipcore-content-id-00 Thread-Index: AQHR98S6mkJf3bvA+kChF4NYCmV/nKBLrLyA///rB4CAAW9TEIAAZeKAgAEZTQCAACY9EA== Date: Thu, 18 Aug 2016 13:02:55 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101164F0BC4@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164EB945@ESESSMB301.ericsson.se> <8f0c6119-869c-e4d5-dabe-7a0c6542f590@alum.mit.edu> In-Reply-To: Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B31079006101164F0BC4ESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyM2K7hy7Dpq3hBkcOG1is2HCA1eLrj01s Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGrTmtTAVnnzFWPHub1MB4/jhjFyMnh4SA icSWHeuYuxi5OIQE1jNKfP5/GcpZwihx4eJHNpAqNgE9iYlbjrCC2CICcRLTTj4Hs5kF5CSu f9gIViMs4CZxYd0UoKkcQDXuEo8XVEGUh0msm7qAGcRmEVCV6O9bywRi8wr4Smz8uBXMFhI4 wyTx8xbYGE4Ba4nOm5fBjmMUkJW4+qeXEWKVuMStJ/OZII4WkFiy5zwzhC0q8fLxP1YIW0mi cckTqNPyJfb9+8oGsUtQ4uTMJywTGEVmIRk1C0nZLCRlEHE9iRtTp7BB2NoSyxa+ZoawdSVm /DvEgiy+gJF9FaNocWpxUm66kbFealFmcnFxfp5eXmrJJkZgZB3c8lt1B+PlN46HGAU4GJV4 eBWWbQkXYk0sK67MPcQowcGsJMLLs3ZruBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFe/5eK4UIC 6YklqdmpqQWpRTBZJg5OqQZG3UV/+bPEddfLXUmdtLTgY+Y8y0+SRx+2v16/+C3LTVHVtne3 vi/ft+VwiZW8e+i6JH6vne/TJYLP/X/h/6rup56P3dPJS+ffqw19vWzxvNOnow6E6Pk3L++Q uOd0wNXpsLzlcibTf23Wk+5e49d7KZk3Rf4jl9G0zds+/N97/vp2tjU6UzVe7FBiKc5INNRi LipOBABTvkEcqAIAAA== Archived-At: Cc: SIPCORE Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-content-id-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 13:03:17 -0000 --_000_39B5E4D390E9BD4890E2B31079006101164F0BC4ESESSMB301erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Content-ID header field definition for SIP is definitely needed. RFC5368 already contains an example of its usage in Figure 3: ------------ REFER sip:conf-123@example.com;gruu;opaque=3Dhha9s8d-999a SIP/2.0 Via: SIP/2.0/TCP client.chicago.example.com ;branch=3Dz9hG4bKhjhs8ass83 Max-Forwards: 70 To: "Conference 123" From: Carol ;tag=3D32331 Call-ID: d432fa84b4c76e66710 CSeq: 2 REFER Contact: Refer-To: Refer-Sub: false Require: multiple-refer, norefersub Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Allow-Events: dialog Accept: application/sdp, message/sipfrag Content-Type: application/resource-lists+xml Content-Disposition: recipient-list Content-Length: 362 Content-ID: Figure 3: REFER request with multiple REFER-Targets ------------ and RFC5368 is referenced by specifications of other standardization organi= zations (e.g. in OMA Push-To-Talk-over-Cellular OMA-TS-PoC_ControlPlane-V1_= 0_3-20090922-A), so Content-ID can be used as shown above in real networks. So, it would be nice to close the gap rather soon. I have no view on whether other Content-* header fields missing in SIP are = needed in SIP or not. Kind regards Ivo Sedlacek -----Original Message----- From: Christer Holmberg Sent: Thursday, August 18, 2016 2:26 PM To: Paul Kyzivat; Ivo Sedlacek Cc: SIPCORE Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-content-id-00 Hi, I don=B9t think we shall try to =B3fix everything=B2. We know that such wor= k may take forever. The draft identifies the problem with Content-ID. If someone else know abou= t similar problems with other header fields, please bring it to the WG. Obviously, if we think that the definition of some header field that IS alr= eady defined for SIP (e.g. MIME-Version) is unclear, we can discuss whether= we should fix that. But, let=B9s work to fix the stuff that people need. If people need somethi= ng else in future, they can write a draft... Regards, Christer On 17/08/16 22:39, "sipcore on behalf of Paul Kyzivat" > wrote: >Ivo, > >On 8/17/16 7:36 AM, Ivo Sedlacek wrote: >> Hello, >> >> thank you for the comments. >> >>> ISTM that RFC2042 can be considered a "base class" for a family of >>> message syntaxes that share a common style. Viewed that way, SIP >>> ought to support all of the header fields defined in RFC2042. Those inc= lude: > >Just to be clear - I am not well schooled on all the intricacies of >MIME. So I'm not sure which of these header fields might be (or not be) >relevant for SIP. I brought it up to encourage a broader discussion. > >>> - mime-version >> >> Would the MIME-Version header field be included in header fields of a >>SIP message solely when the SIP message contains one body, or would it >>be included in case when SIP message contains several bodies? >> >> BTW, HTTP MIME-Version header field is specified - see >>http://www.iana.org/assignments/message-headers/message-headers.xhtml > >I think this is not clear. The 3261 definition is simply a reference to >HTTP (RFC2616), without any explanation. And RFC2616 isn't very clear >about it either - but does say its use is optional. > >So this may deserve some clarification. > >>> - content-type >> >> MIME Content-Type header field defined in RFC2045 matches the SIP >>Content-Type header field defined in RFC3261. Please note that ABNF >>for SIP Content-Type header field is based on ABNF in RFC2616 while >>ABNF for MIME Content-Type header field is in RFC2045. >> >> So, IMO, everything is in place for Content-Type. > >Yep. > >>> - content-transfer-encoding >> >> Is this really needed? SIP provides binary transport. >> >> HTTP Content-Transfer-Encoding header field is NOT specified either - >>see >>http://www.iana.org/assignments/message-headers/message-headers.xhtml > >Since sip provides for binary transfer it does seem *unnecessary*. For >some uses it might still be convenient if somebody has an already >encoded body they want to include. The downside is that it would not be >backward compatible. > >I guess it is currently still possible as long as used in one part of a >multipart body. > >>> - content-id >> >> This is proposed to be specified the draft. >> >>> - content-description >> >> HTTP Content-Description header field is NOT specified either - see >>http://www.iana.org/assignments/message-headers/message-headers.xhtml > >Since it seems to be intended solely for human consumption it doesn't >seem very important. > >>> It also generically adopts >> with the string "Content-">. >> >> On top of the above, >>http://www.iana.org/assignments/message-headers/message-headers.xhtml >>additionally gives the following MIME or HTTP headers: > >I was looking for a registry and didn't find it. > >> - Content-Alternative - in MIME, not in HTTP (and not available in >>SIP) >> - Content-Base - in MIME, in HTTP (and not available in SIP). Marked >>as "obsoleted" >> - Content-Disposition - in MIME, in HTTP (and available in SIP) >> - Content-Duration - in MIME, not in HTTP (and not available in SIP) >> - Content-Encoding - not in MIME, in HTTP (and available in SIP) >> - Content-features - in MIME, not in HTTP (and not available in SIP) >> - Content-Language - in MIME, in HTTP (and available in SIP) >> - Content-Length - not in MIME, in HTTP (and available in SIP) >> - Content-Location - in MIME, in HTTP (and not available in SIP) >> - Content-MD5 - in MIME, in HTTP (and not available in SIP) >> - Content-Range - not in MIME, in HTTP (and not available in SIP) >> - Content-Script-Type - not in MIME, in HTTP (and not available in >>SIP) >> - Content-Style-Type - not in MIME, in HTTP (and not available in >>SIP) >> - Content-Version - not in MIME, in HTTP (and not available in SIP) >> >> Not sure whether any header fields of the above (which are not in SIP >>already) are useful for SIP. > >Unfortunately ISTM that MIME hasn't been managed in a way that clearly >separates those parts that are generic from those that are only >meaningful for mail. (But I haven't studied all the docs, so maybe I'm >wrong about this.) > >Clearly http has done its own picking and choosing, as has sip. But the >criteria for doing so aren't so obvious. > >The current experience with content-id shows that potentially any mime >body might make sense in a sip message. ISTM the question we need to >ask is where to draw the line between those that can be included >directly, vs. those that can only be included by wrapping them in >another layer of mime wrapper. > > Thanks, > Paul > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore --_000_39B5E4D390E9BD4890E2B31079006101164F0BC4ESESSMB301erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

 

Content-ID header field definition for SIP is def= initely needed.

 

RFC5368 already contains an example of its usage = in Figure 3:

------------

   REFER sip:conf-123= @example.com;gruu;opaque=3Dhha9s8d-999a  SIP/2.0

   Via: SIP/2.= 0/TCP client.chicago.example.com

        &= nbsp;  ;branch=3Dz9hG4bKhjhs8ass83

   Max-Forwards: 70

   To: "Conference 123" <s= ip:conf-123@example.com>

   From: Carol <sip:carol@chicago.ex= ample.com>;tag=3D32331

   Call-ID: d432fa84b4c76e66710

   CSeq: 2 REFER

   Contact: <sip:carol@client.chicag= o.example.com>

   Refer-To: <cid:cn35t8jf02@example= .com>

   Refer-Sub: false

   Require: multiple-refer, norefersub<= o:p>

   Allow: INVITE, ACK, CANCEL, OPTIONS,= BYE, REFER, SUBSCRIBE, NOTIFY

   Allow-Events: dialog

   Accept: application/sdp, message/sip= frag

   Content-Type: application/resource-l= ists+xml

   Content-Disposition: recipient-list<= o:p>

   Content-Length: 362

   Content-ID: <cn35t8jf02@example.com>

 

   <?xml version=3D"1.0" e= ncoding=3D"UTF-8"?>

   <resource-lists xmlns=3D"urn= :ietf:params:xml:ns:resource-lists"

        &= nbsp;  xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance&quo= t;>

     <list><= /p>

       <entry ur= i=3D"sip:bill@example.com?method=3DBYE" />

       <entry ur= i=3D"sip:joe@example.org?method=3DBYE" />

       <entry ur= i=3D"sip:ted@example.net?method=3DBYE" />

     </list>=

   </resource-lists>

 

        &= nbsp;   Figure 3: REFER request with multiple REFER-Targets<= /o:p>

------------

 

and RFC5368 is referenced by specifications of ot= her standardization organizations (e.g. in OMA Push-To-Talk-over-Cellular O= MA-TS-PoC_ControlPlane-V1_0_3-20090922-A), so Content-ID can be used as sho= wn above in real networks.

 

So, it would be nice to close the gap rather soon= .

 

I have no view on whether other Content-* header = fields missing in SIP are needed in SIP or not.

 

Kind regards

 

Ivo Sedlacek

        &= nbsp;           &nbs= p;            &= nbsp;

-----Original Message-----
From: Christer Holmberg
Sent: Thursday, August 18, 2016 2:26 PM
To: Paul Kyzivat; Ivo Sedlacek
Cc: SIPCORE
Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-content-id-00

 

 

Hi,

 

I don=B9t think we shall try to =B3fix everything= =B2. We know that such work may take forever.

 

The draft identifies the problem with Content-ID.= If someone else know about similar problems with other header fields, plea= se bring it to the WG.

 

Obviously, if we think that the definition of som= e header field that IS already defined for SIP (e.g. MIME-Version) is uncle= ar, we can discuss whether we should fix that.

 

But, let=B9s work to fix the stuff that people ne= ed. If people need something else in future, they can write a draft...=

 

Regards,

 

Christer

 

 

 

 

 

 

 

On 17/08/16 22:39, "sipcore on behalf of Pau= l Kyzivat"

<sipcore-bounces@ietf.org on behalf of pkyzivat@alum.mi= t.edu> wrote:

 

>Ivo,

> 

>On 8/17/16 7:36 AM, Ivo Sedlacek wrote:<= /o:p>

>> Hello,

>> 

>> thank you for the comments.

>> 

>>> ISTM that RFC2042 can be considered = a "base class" for a family of

>>> message syntaxes that share a common= style. Viewed that way, SIP

>>> ought to support all of the header f= ields defined in RFC2042. Those include:

> 

>Just to be clear - I am not well schooled on = all the intricacies of

>MIME. So I'm not sure which of these header f= ields might be (or not be)

>relevant for SIP. I brought it up to encourag= e a broader discussion.

> 

>>> - mime-version

>> 

>> Would the MIME-Version header field be i= ncluded in header fields of a

>>SIP message solely when the SIP message c= ontains one body, or would it

>>be included in case when SIP message cont= ains several bodies?

>> 

>> BTW, HTTP MIME-Version header field is s= pecified - see

>>http://www.iana.org/assignments/message-headers/message= -headers.xhtml

> 

>I think this is not clear. The 3261 definitio= n is simply a reference to

>HTTP (RFC2616), without any explanation. And = RFC2616 isn't very clear

>about it either - but does say its use is opt= ional.

> 

>So this may deserve some clarification.<= /o:p>

> 

>>> - content-type

>> 

>> MIME Content-Type header field defined i= n RFC2045 matches the SIP

>>Content-Type header field defined in RFC3= 261. Please note that ABNF

>>for SIP Content-Type header field is base= d on ABNF in RFC2616 while

>>ABNF for MIME Content-Type header field i= s in RFC2045.

>> 

>> So, IMO, everything is in place for Cont= ent-Type.

> 

>Yep.

> 

>>> - content-transfer-encoding

>> 

>> Is this really needed? SIP provides bina= ry transport.

>> 

>> HTTP Content-Transfer-Encoding header fi= eld is NOT specified either -

>>see

>>http://www.iana.org/assignments/message-headers/message= -headers.xhtml

> 

>Since sip provides for binary transfer it doe= s seem *unnecessary*. For

>some uses it might still be convenient if som= ebody has an already

>encoded body they want to include. The downsi= de is that it would not be

>backward compatible.

> 

>I guess it is currently still possible as lon= g as used in one part of a

>multipart body.

> 

>>> - content-id

>> 

>> This is proposed to be specified the dra= ft.

>> 

>>> - content-description

>> 

>> HTTP Content-Description header field is= NOT specified either - see

>>http://www.iana.org/assignments/message-headers/message= -headers.xhtml

> 

>Since it seems to be intended solely for huma= n consumption it doesn't

>seem very important.

> 

>>> It also generically adopts <Any R= FC 822 header field which begins

>>> with the string "Content-"= >.

>> 

>> On top of the above,

>>http://www.iana.org/assignments/message-headers/message= -headers.xhtml

>>additionally gives the following MIME or = HTTP headers:

> 

>I was looking for a registry and didn't find = it.

> 

>> - Content-Alternative - in MIME, not in = HTTP (and not available in

>>SIP)

>> - Content-Base - in MIME, in HTTP (and n= ot available in SIP). Marked

>>as "obsoleted"

>> - Content-Disposition - in MIME, in HTTP= (and available in SIP)

>> - Content-Duration - in MIME, not in HTT= P (and not available in SIP)

>> - Content-Encoding - not in MIME, in HTT= P (and available in SIP)

>> - Content-features - in MIME, not in HTT= P (and not available in SIP)

>> - Content-Language - in MIME, in HTTP (a= nd available in SIP)

>> - Content-Length - not in MIME, in HTTP = (and available in SIP)

>> - Content-Location - in MIME, in HTTP (a= nd not available in SIP)

>> - Content-MD5 - in MIME, in HTTP (and no= t available in SIP)

>> - Content-Range - not in MIME, in HTTP (= and not available in SIP)

>> - Content-Script-Type - not in MIME, in = HTTP (and not available in

>>SIP)

>> - Content-Style-Type - not in MIME, in H= TTP (and not available in

>>SIP)

>> - Content-Version - not in MIME, in HTTP= (and not available in SIP)

>> 

>> Not sure whether any header fields of th= e above (which are not in SIP

>>already) are useful for SIP.

> 

>Unfortunately ISTM that MIME hasn't been mana= ged in a way that clearly

>separates those parts that are generic from t= hose that are only

>meaningful for mail. (But I haven't studied a= ll the docs, so maybe I'm

>wrong about this.)

> 

>Clearly http has done its own picking and cho= osing, as has sip. But the

>criteria for doing so aren't so obvious.=

> 

>The current experience with content-id shows = that potentially any mime

>body might make sense in a sip message. ISTM = the question we need to

>ask is where to draw the line between those t= hat can be included

>directly, vs. those that can only be included= by wrapping them in

>another layer of mime wrapper.

> 

>       &nb= sp;     Thanks,

>       &nb= sp;     Paul

> 

>_____________________________________________= __

>sipcore mailing list

>sipcore@ietf.org

>https://= www.ietf.org/mailman/listinfo/sipcore

 

--_000_39B5E4D390E9BD4890E2B31079006101164F0BC4ESESSMB301erics_-- From nobody Thu Aug 18 07:13:55 2016 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 91E3E12DF1E for ; Thu, 18 Aug 2016 07:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdVa-UkOmNAQ for ; Thu, 18 Aug 2016 07:13:52 -0700 (PDT) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2D1B12DF00 for ; Thu, 18 Aug 2016 07:13:52 -0700 (PDT) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-09v.sys.comcast.net with SMTP id aO4eb6fZz1XXBaO4ubzTUA; Thu, 18 Aug 2016 14:13:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-16v.sys.comcast.net with SMTP id aO4sburagpwEGaO4tbould; Thu, 18 Aug 2016 14:13:52 +0000 To: Christer Holmberg , Ivo Sedlacek References: <39B5E4D390E9BD4890E2B31079006101164EB945@ESESSMB301.ericsson.se> <8f0c6119-869c-e4d5-dabe-7a0c6542f590@alum.mit.edu> From: Paul Kyzivat Message-ID: <4da8754f-c41d-05fd-2eaf-245611be02df@alum.mit.edu> Date: Thu, 18 Aug 2016 10:13:49 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfKOT0M4mjjFxE+le0TNIbaqYCbjHvMqXMKbBK1T0tY0LiAWh9eTm+kA0rcF4FnHF33qBm2gZiQ6Noy/L6IBdGxlR5NuIiYbhHOMNUt/xVKNValEDFrS7 8NbLuDtdO/I26g8xsMJAMOpKoQsZ4pVLUQ0kg62iigZcZrlZBDAVGYVgbE7QXYkY3LwIhmAB2RXvTV3khQJYn3mONf7nnuWRpLS0PL8RymvUWJgpMIuMI+Ou 2p3cZTonmGKTL5pBE2PasvLfcxyZan3kBG519BqK190= Archived-At: Cc: SIPCORE Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-content-id-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 14:13:53 -0000 On 8/18/16 8:25 AM, Christer Holmberg wrote: > > Hi, > > I dont think we shall try to fix everything. We know that such work may > take forever. > > The draft identifies the problem with Content-ID. If someone else know > about similar problems with other header fields, please bring it to the WG. > > Obviously, if we think that the definition of some header field that IS > already defined for SIP (e.g. MIME-Version) is unclear, we can discuss > whether we should fix that. > > But, lets work to fix the stuff that people need. If people need > something else in future, they can write a draft... OK. In spite of my desire for completeness I can accept sticking with just the immediate need. Thanks, Paul From nobody Fri Aug 19 11:37:56 2016 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 3CC1612D88F for ; Fri, 19 Aug 2016 11:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uipB2geMgp8z for ; Fri, 19 Aug 2016 11:37:49 -0700 (PDT) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 229BE12D5AA for ; Fri, 19 Aug 2016 11:37:48 -0700 (PDT) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-12v.sys.comcast.net with SMTP id aoegbcK3NxBKTaofrb5xrn; Fri, 19 Aug 2016 18:37:47 +0000 Received: from hobgoblin.ariadne.com ([73.100.16.189]) by resomta-ch2-20v.sys.comcast.net with SMTP id aofpbh8eU6coJaofqbH4Hs; Fri, 19 Aug 2016 18:37:47 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u7JIbjJR009174; Fri, 19 Aug 2016 14:37:45 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u7JIbik6009170; Fri, 19 Aug 2016 14:37:44 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Mirja Kuehlewind" In-Reply-To: <147126699230.31678.9613693360268273574.idtracker@ietfa.amsl.com> Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 19 Aug 2016 14:37:44 -0400 Message-ID: <87pop47gg7.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfNLjKydKWoQRkwFzGXDnLlJxssWgb1t7/3Ig9ApQpYIgDjqvDZ2dZvNT36sgcD078nRbd37E2S8i95OqDo8jKMYBdU1Pf/Yn/y52Jg3fqqbedg5bMGXy iYNRaSrSaJf93rtieakQcUDuh9TMEglQdU5hsLnAziybiy6Fj8rz/p9ZOA83dQZy24qnzlSkPOstEhKbqsu+ZdTYb2Gpzbz1xZ1S+JmVUdDRD6FsMYLtCY7O knpj24IiA6UY8YE+heSdb8s16CgIddlszwGRfW7AZnevzrYi+UjpGZyV5Jto/jBvJ3BZPcHBxL6JNNxZNaM1nlgmEceSkhhekUp1sMis4Qk= Archived-At: Cc: sipcore@ietf.org, draft-ietf-sipcore-dns-dual-stack@ietf.org, iesg@ietf.org, sipcore-chairs@ietf.org Subject: Re: [sipcore] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Yes_on_draft-ietf-si?= =?utf-8?q?pcore-dns-dual-stack-07=3A_=28with_COMMENT=29?= X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 18:37:50 -0000 "Mirja Kuehlewind" writes: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks! This seems very useful in the preparation for Happy-Eyeballs. Thanks! > One question: Why does a client need to look up ALL addresses if it > already knows that it itself only support one specific address familiy? The draft refers to "all address" families in this part of section 3.1: The dual-stack client SHOULD look up all address records (i.e., for all address family(ies) that it supports) for the domain name and add the resulting addresses to the list of IP addresses to be contacted. In this context, we clarify that "all address records" means "[address records] for all address family(ies) that [the device] supports". There is also this usage in section 3.2: Such special-purpose hostnames SHOULD be used only as described in this section, as targets of SRV records for an aggregate host name, where the aggregate host name ultimately resolves to addresses in all families supported by the client. Here the primary text qualifies "all families" with "supported by the client". > And related to this question: Shouldn't it be named "multi-stack client" > instead of "dual-stack client"? Strictly speaking, "multi-stack client" is more robust against the possibility that a third address family is introduced. However, the term "dual-stack" is what has been used in all of the discussions regarding the transition to using IPv6, so we have continued its use in this draft in the narrative portions. OTOH, all of the normative text is written to operate correctly even if further address families are introduced. Dale From nobody Fri Aug 19 11:58:08 2016 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 0165012D1B2 for ; Fri, 19 Aug 2016 11:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GsBs5oQj89B3 for ; Fri, 19 Aug 2016 11:58:02 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21D2B12D1C0 for ; Fri, 19 Aug 2016 11:58:00 -0700 (PDT) Received: (qmail 19535 invoked from network); 19 Aug 2016 20:51:17 +0200 Received: from p5dec255c.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.37.92) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 19 Aug 2016 20:51:17 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <87pop47gg7.fsf@hobgoblin.ariadne.com> Date: Fri, 19 Aug 2016 20:51:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87pop47gg7.fsf@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: sipcore@ietf.org, draft-ietf-sipcore-dns-dual-stack@ietf.org, iesg@ietf.org, sipcore-chairs@ietf.org Subject: Re: [sipcore] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Yes_on_draft-ietf-si?= =?utf-8?q?pcore-dns-dual-stack-07=3A_=28with_COMMENT=29?= X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 18:58:04 -0000 Hi, thanks for your reply! See below. > Am 19.08.2016 um 20:37 schrieb Dale R. Worley : >=20 > "Mirja Kuehlewind" writes: >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Thanks! This seems very useful in the preparation for Happy-Eyeballs. >=20 > Thanks! >=20 >> One question: Why does a client need to look up ALL addresses if it >> already knows that it itself only support one specific address = familiy? >=20 > The draft refers to "all address" families in this part of section = 3.1: >=20 > The dual-stack client SHOULD look up all address records (i.e., > for all address family(ies) that it supports) for the domain name > and add the resulting addresses to the list of IP addresses to be > contacted. >=20 > In this context, we clarify that "all address records" means "[address > records] for all address family(ies) that [the device] supports". >=20 > There is also this usage in section 3.2: >=20 > Such special-purpose hostnames SHOULD be used only as described in > this section, as targets of SRV records for an aggregate host name, > where the aggregate host name ultimately resolves to addresses in = all > families supported by the client. >=20 > Here the primary text qualifies "all families" with "supported by the > client=E2=80=9C. Okay. I think I was confused by the =E2=80=9Ai.e.=E2=80=98 together with = the second sentence here: The dual-stack client SHOULD look up all address records (i.e., for all address family(ies) that it supports) for the domain name and add the resulting addresses to the list of IP addresses to be contacted. A client MUST be prepared for the existence of DNS resource records containing addresses in families that it does not support; if such records may be returned by the client's DNS queries, such records MUST be ignored as unusable and the supported addresses used as specified herein. Reading it again with your clarification I not sure why I misunderstood = in the first place. So probably no clarification needed; or maybe just = remove the =E2=80=9Ai.e.=E2=80=98 and the brackets..? One more question: getting an record returned for an address family that = was not requested is an error case, right? Or can this actual happen in = =E2=80=9Anormal=E2=80=98 operation? >=20 >> And related to this question: Shouldn't it be named "multi-stack = client" >> instead of "dual-stack client"? >=20 > Strictly speaking, "multi-stack client" is more robust against the > possibility that a third address family is introduced. However, the > term "dual-stack" is what has been used in all of the discussions > regarding the transition to using IPv6, so we have continued its use = in > this draft in the narrative portions. OTOH, all of the normative text > is written to operate correctly even if further address families are > introduced. I noticed that the whole doc is written in a way that would correctly = operate with new address families. That's we I suggested this change. I = think that this term would be as easily understandable as the current = dual-stack term. But I don=E2=80=99t have a strong opinion, so please = just use what you think is better. Mirja >=20 > Dale >=20 From nobody Fri Aug 19 12:13:46 2016 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 BC10C12DB14 for ; Fri, 19 Aug 2016 12:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0Nm62cRiNmc for ; Fri, 19 Aug 2016 12:13:37 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4528312DB31 for ; Fri, 19 Aug 2016 12:13:35 -0700 (PDT) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-05v.sys.comcast.net with SMTP id apEKbkBxH2FGMapEUbcyw1; Fri, 19 Aug 2016 19:13:34 +0000 Received: from hobgoblin.ariadne.com ([73.100.16.189]) by resomta-ch2-20v.sys.comcast.net with SMTP id apESbhHA36coJapETbH8g2; Fri, 19 Aug 2016 19:13:34 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u7JJDW6q013002; Fri, 19 Aug 2016 15:13:32 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u7JJDVfo012996; Fri, 19 Aug 2016 15:13:31 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Spencer Dawkins" In-Reply-To: <147140468741.19939.3811368106001545602.idtracker@ietfa.amsl.com> (spencerdawkins.ietf@gmail.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 19 Aug 2016 15:13:31 -0400 Message-ID: <87mvk87esk.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfCo09Kb/Jkwv/u1JcQchMpE+uoN9Khh+ab4OWblojmlbHVUMrd6HHcID9kJK//YpMRCasrlQM0RIZtQsqKAUJetwmWOMG5/MlXGpk0BUxgLD+Nig93LJ n9ToIQ7NC/X1L67+gJvEA2KiI9HrpmKvtggT9+ZOSqi91pDzci7H4O28xrjLPrtYkD3mmQ/4z+X/891bfOieDFx5zxccFJx5ylW/cawDCe31qdBeCgY0GMc8 Zvb2Dj7a/p5vSYQLRyN1K67I8d/hxa/4QhWeRvwnr5POjlAw+dtSJV9GRj8xSqBW4sIOMnpfYMOp8urEhf7849sjdQEFhv+PlRwOfM4uCDrYAhh9H+AN621U SD4ODZGPDes9/80odd4WUyE7zxR2+A== Archived-At: Cc: sipcore@ietf.org, draft-ietf-sipcore-dns-dual-stack@ietf.org, iesg@ietf.org, sipcore-chairs@ietf.org Subject: Re: [sipcore] Spencer Dawkins' Yes on draft-ietf-sipcore-dns-dual-stack-07: (with COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 19:13:39 -0000 "Spencer Dawkins" writes: > Could you provide some explanation for the reader as to why SIP is > "different", following this statement? Even an example would be useful. > > Unfortunately, in common SIP situations, it is not possible to "race" > simultaneous request attempts using two address families. That's a good point, because the reason is non-obvious to a reader who hasn't hassled with SIP in unreliable network environments. Racing in HTTP is the sending of simultaneous TCP SYNs to two different addresses. The client then continues the handshake and sends the request to the address that responds first. The crucial fact is that opening a TCP connection to an HTTP server alone does not change the server's state. SIP requests are usually transmitted as single UDP packets, so sending two copies of the request to two different addresses risks having two copies of the request propagating through the SIP network at the same time -- the difference from HTTP is that the SIP element cannot test the route in a non-state-changing way. If two copies of the same request arrive at one client, the client must reject the second of them with a 482 response. But this rule is not sufficient to prevent user-visible differences in behavior because a proxy that is upstream of the second request to arrive at the client may (almost immediately!) serially fork the second request to further destinations. A version of this scenario that I saw in the wild is diagrammed in https://www.ietf.org/mail-archive/web/sipcore/current/msg06853.html. I've added this explanation to section 3.2. You can see the change in https://www.ietf.org/rfcdiff?url1=draft-ietf-sipcore-dns-dual-stack-07&url2=http://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore-dns-dual-stack-08.txt Dale From nobody Fri Aug 19 13:15:10 2016 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 819A612D9AB; Fri, 19 Aug 2016 13:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dt0zUW1JLTEY; Fri, 19 Aug 2016 13:15:06 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33A2E12D66C; Fri, 19 Aug 2016 13:10:47 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id z8so19496256ywa.1; Fri, 19 Aug 2016 13:10:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pKZ16yCdG/4nWHUVWAocO+gbF57I/ADYuUga96PDui4=; b=VX4L6hKH/eRpnL1PfYv+H4DEOQuPxS6jT+uHoADu0ziTqApxdJqQUxlfS/ucyRwB/B BLYoM89Yjt8Tv1E+wRlAceUSW7LENgXdoE+MJwuVHlq1A5dYVL1W2/dEXEBBJnNPW9q2 m+/tbbyIV0tNmhkC+pl6SSK7QmBiJsDKIdA/ej7gyWIR/vsSjjCUR/wjemRonwMXWsmZ e8SLd/vBvVgHd8qQ7xs7Hclc6GP3zT2C47FXu/JnVUxBhYy9Zwg2bf9TtGT0TRsnenHd TleoPtg/8hSscQNyY74K2B7cyeI4o/sU2WoXI89ynjLGi0SWQpQmZQGPjt4VHx/va/Cm AvIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pKZ16yCdG/4nWHUVWAocO+gbF57I/ADYuUga96PDui4=; b=BB2ozu3V5B/MzDCOoz+K3izGAZlrdLmE/S/PTM1IV+9rfMz49RQHiGvelQQAeLHYGx ZpsWhXZUaOUPhXgTuQUC8CUhK5Txc6USdhbrMeUYmz1E2AyvNLtA97zDM9j6L+HLJTdq F3YozEscVGgi7qjMkp5E4BzLgG5jzwKBPrl/wFSmiRXUUxdqVdTQ5QZnO4UU8drmWrdg Gn48UOimk3DqOB5V3e9JQ6/y0Kikep4Xx22hToxPrXWY9moDeBrfbBAhHJwtyWBdKvD5 avGul4JF9ibpqTfSOcYCZHa541iaH4zlg0I79pfs1Z44mBnNF/2tjscCCUV1OIzXEmoF rtbw== X-Gm-Message-State: AEkooutqfS3W/wYDRu5bKyYkGdvcyjeHcHAZm3M4Xlkf0E+F8Pf33qqVXr79p1Cqs6VpdJdhqJTcCDyhXmIRkA== X-Received: by 10.129.93.86 with SMTP id r83mr7947077ywb.211.1471637446473; Fri, 19 Aug 2016 13:10:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.210.195 with HTTP; Fri, 19 Aug 2016 13:10:46 -0700 (PDT) In-Reply-To: <87mvk87esk.fsf@hobgoblin.ariadne.com> References: <147140468741.19939.3811368106001545602.idtracker@ietfa.amsl.com> <87mvk87esk.fsf@hobgoblin.ariadne.com> From: Spencer Dawkins at IETF Date: Fri, 19 Aug 2016 15:10:46 -0500 Message-ID: To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=001a114d805c3c3c97053a724bdf Archived-At: Cc: SIPCORE , draft-ietf-sipcore-dns-dual-stack@ietf.org, "iesg@ietf.org" , sipcore-chairs@ietf.org Subject: Re: [sipcore] Spencer Dawkins' Yes on draft-ietf-sipcore-dns-dual-stack-07: (with COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 20:15:08 -0000 --001a114d805c3c3c97053a724bdf Content-Type: text/plain; charset=UTF-8 Hi, Dale, On Fri, Aug 19, 2016 at 2:13 PM, Dale R. Worley wrote: > "Spencer Dawkins" writes: > > Could you provide some explanation for the reader as to why SIP is > > "different", following this statement? Even an example would be useful. > > > > Unfortunately, in common SIP situations, it is not possible to "race" > > simultaneous request attempts using two address families. > > That's a good point, because the reason is non-obvious to a reader who > hasn't hassled with SIP in unreliable network environments. > > Racing in HTTP is the sending of simultaneous TCP SYNs to two different > addresses. The client then continues the handshake and sends the > request to the address that responds first. The crucial fact is that > opening a TCP connection to an HTTP server alone does not change the > server's state. > > SIP requests are usually transmitted as single UDP packets, so sending > two copies of the request to two different addresses risks having two > copies of the request propagating through the SIP network at the same > time -- the difference from HTTP is that the SIP element cannot test the > route in a non-state-changing way. > > If two copies of the same request arrive at one client, the client must > reject the second of them with a 482 response. But this rule is not > sufficient to prevent user-visible differences in behavior because a > proxy that is upstream of the second request to arrive at the client may > (almost immediately!) serially fork the second request to further > destinations. A version of this scenario that I saw in the wild is > diagrammed in > https://www.ietf.org/mail-archive/web/sipcore/current/msg06853.html. > > I've added this explanation to section 3.2. You can see the change in > > https://www.ietf.org/rfcdiff?url1=draft-ietf-sipcore-dns- > dual-stack-07&url2=http://svn.resiprocate.org/rep/ietf- > drafts/worley/draft-ietf-sipcore-dns-dual-stack-08.txt > > Dale > That's a terrific response to my comment. Thank you for including your response in the document! Spencer --001a114d805c3c3c97053a724bdf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Dale,

On Fri, Aug 19, 2016 at 2:13 PM, Dale R. Worley = <worley@ariadne.= com> wrote:
"Spencer Dawkins" <spencerdawkins.ietf@gmail.com> writes:
> Could you provide some explanation for the reader as to why SIP is
> "different", following this statement? Even an example would= be useful.
>
>=C2=A0 =C2=A0 Unfortunately, in common SIP situations, it is not possib= le to "race"
>=C2=A0 =C2=A0 simultaneous request attempts using two address families.=

That's a good point, because the reason is non-obvious to a read= er who
hasn't hassled with SIP in unreliable network environments.

Racing in HTTP is the sending of simultaneous TCP SYNs to two different
addresses.=C2=A0 The client then continues the handshake and sends the
request to the address that responds first.=C2=A0 The crucial fact is that<= br> opening a TCP connection to an HTTP server alone does not change the
server's state.

SIP requests are usually transmitted as single UDP packets, so sending
two copies of the request to two different addresses risks having two
copies of the request propagating through the SIP network at the same
time -- the difference from HTTP is that the SIP element cannot test the route in a non-state-changing way.

If two copies of the same request arrive at one client, the client must
reject the second of them with a 482 response.=C2=A0 But this rule is not sufficient to prevent user-visible differences in behavior because a
proxy that is upstream of the second request to arrive at the client may (almost immediately!) serially fork the second request to further
destinations.=C2=A0 A version of this scenario that I saw in the wild is diagrammed in
https://www.ietf.org/mail-ar= chive/web/sipcore/current/msg06853.html.

I've added this explanation to section 3.2.=C2=A0 You can see the chang= e in

h= ttps://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-sipcore-dns-dual-st= ack-07&url2=3Dhttp://svn.resiprocate.org/rep/ietf-drafts/worl= ey/draft-ietf-sipcore-dns-dual-stack-08.txt

Dale

That&= #39;s a terrific response to my comment. Thank you for including your respo= nse in the document!

Spencer
--001a114d805c3c3c97053a724bdf-- From nobody Fri Aug 19 13:30:31 2016 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 382CC12D82F for ; Fri, 19 Aug 2016 13:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RGNz7xX7sbr for ; Fri, 19 Aug 2016 13:30:28 -0700 (PDT) Received: from resqmta-po-10v.sys.comcast.net (resqmta-po-10v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F5F312D7DB for ; Fri, 19 Aug 2016 13:30:28 -0700 (PDT) Received: from resomta-po-11v.sys.comcast.net ([96.114.154.235]) by resqmta-po-10v.sys.comcast.net with SMTP id aqQVbrNj4HqolaqQtbRF8G; Fri, 19 Aug 2016 20:30:27 +0000 Received: from hobgoblin.ariadne.com ([73.100.16.189]) by resomta-po-11v.sys.comcast.net with SMTP id aqQrbluHQctRBaqQsbgzPa; Fri, 19 Aug 2016 20:30:27 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u7JKUOd8022173; Fri, 19 Aug 2016 16:30:24 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u7JKUO57022169; Fri, 19 Aug 2016 16:30:24 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Suresh Krishnan" In-Reply-To: <147147110646.23797.16205066964281684411.idtracker@ietfa.amsl.com> (suresh.krishnan@ericsson.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 19 Aug 2016 16:30:24 -0400 Message-ID: <87k2fc7b8f.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfP0f/Pqp4gkuN6O3jw9PZ/8hKJkfZS6/tOrJw5KxgZs62+axVbEPjxSY5razV8xU8eIVYcqZjctpdwjAR2zBElrNlzHkF8tSwhOswO/cnNyc6rhvLebj SUlKji/m5+AWh7736QB+JJMjEQHeiY3GZtGa4XQ1j3OitKF2YnhxTnRMhpyCgsnmELyHcTbI7KSXOhGN87pJ4fQpDDhc+3XKBSQCxR65jxGXqp13UhBhhlMo U7A61rXjNqPFz5I0bkXgG6ifESy0tFZveweY52Mx4u37rLI78l0YaDE97hUewhlrsE6dzngvcPLnP1yNOvD7g5Gyja1pOdzvDdrBs6f5ZEnUFZWQduUruIqN 9NNux5/I Archived-At: Cc: sipcore@ietf.org, draft-ietf-sipcore-dns-dual-stack@ietf.org, iesg@ietf.org, sipcore-chairs@ietf.org Subject: Re: [sipcore] Suresh Krishnan's Discuss on draft-ietf-sipcore-dns-dual-stack-07: (with DISCUSS) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 20:30:30 -0000 "Suresh Krishnan" writes: > * Section 3.1 > > It is not clear to me what exactly the normative addendum is requiring > the client to do as regards to the DNS query while implementing "The > dual-stack client SHOULD look up all address records". Does this mean > that the client should do a AAAA (28) query followed by (or in parallel > or preceded ) for a A (1) query? I think it would be good to clarify the > types and ordering/concurrency of the queries. Given that the responses to DNS queries do not depend on the order in which they are done, it seems to me that the only necessity is to specify that the client must do both A and AAAA queries. In regard to the specific record types, one of our goals was that the wording should be robust to the possibility of additional address families being created. Thus we used the wording The dual-stack client SHOULD look up all address records [...] for all address family(ies) that it supports [...] for the domain name and add the resulting addresses to the list of IP addresses to be contacted. Assuming that the client supports exactly IPv4 and IPv6, the queries to obtain address records for those families are A and AAAA. I don't see that the text can be interpreted in a different way. > * Section 4 > > I am a bit puzzled by the merging of the address lists from two separate > DNS queries in relation to RFC6724. This is how I see the destination > address selection in RFC6724. The application ends up calling some kind > of name resolution API (something like getaddrinfo()) with a > hostname/FQDN (say sip-1.example.com) and this results in a set of > addresses being returned. The destination address selection algorithm > specified in Section 6 of RFC6724 then orders these addresses and picks > one. I am not seeing how the second FQDN and its associated set of > addresses become involved in the RFC6724 process. Is this something that > you are adding on top of RFC6724? Please clarify. One way of looking at it is that the full process of resolving the server's address is the process for SRV records (RFC 2782) on top of the destination address selection process (RFC 6724). You've identified that correctly. The full process is fairly complicated, and the full documentation involves the interaction of RFC 3263, RFC 2782, and RFC 6724. But restricting our attention to the case in question: - The SRV records for domain name in the destination SIP URL are looked up. (RFC 3263) - Depending on the priority and weight fields (and the randomization implied by them!), the "target" domain names of the SRV records are listed in a particular order. (RFC 2782) The case in question is when there are more than one SRV records for the destination domain name, and hence more than one target domain name. - Each of those target domain names is expanded into a group of IPv4 and IPv6 addresses by looking up the A and AAAA records for the name. Each group is sorted by the destination selection algorithm. (This can be accomplished by calling getaddrinfo() on the target domain name.) (RFC 6724) - The sorted groups of addresses for the target domain names are concatenated in the order of the target domain names. The crucial point here is that the destination selection reordering is only within the groups that result from the target domain names of the SRVs -- The whole algorithm is a two-field sort with the "major" sort being done by the SRV algorithm and the "minor" sort being done by destination selection. The original RFC 3263 specification describes the first two steps, but presumes that the third step does not explicitly sort the addresses that are obtained for the target domain name. As a general rule, people who have digested the rules of RFC 3263 agree that the "naturally correct" way to incorporate destination selection (now that it exists for IPv6) is to expand the third step to include that sortation -- and, critically, that destination selection cannot reorder two addresses between groups that derive from different target domain names. The purpose of section 4 is to make that understanding normative. Now, comparing what I have written here with the text in section 4, I see that section 4 does not make explicit the ordered list of target domain names from the SRV records. And I can see that if the reader is not thoroughly familiar with RFC 3263, that makes the overall process significantly less clear, because it doesn't make step 2 above explicit. I've updated the draft -08 to show the list of target domain names. You can see the difference in https://www.ietf.org/rfcdiff?url1=draft-ietf-sipcore-dns-dual-stack-07&url2=http://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore-dns-dual-stack-08.txt and the entire current draft in http://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore-dns-dual-stack-08.{txt,html} Dale From nobody Fri Aug 19 23:26:27 2016 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 C2B6412D147; Fri, 19 Aug 2016 23:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuPwON-kBAoL; Fri, 19 Aug 2016 23:26:18 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A071B12D100; Fri, 19 Aug 2016 23:26:16 -0700 (PDT) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id A46F54281; Sat, 20 Aug 2016 08:26:11 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: <87k2fc7b8f.fsf@hobgoblin.ariadne.com> Date: Sat, 20 Aug 2016 08:26:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87k2fc7b8f.fsf@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: sipcore-chairs@ietf.org, sipcore@ietf.org, Olle E Johansson , Suresh Krishnan , draft-ietf-sipcore-dns-dual-stack@ietf.org, iesg@ietf.org Subject: Re: [sipcore] Suresh Krishnan's Discuss on draft-ietf-sipcore-dns-dual-stack-07: (with DISCUSS) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2016 06:26:21 -0000 > On 19 Aug 2016, at 22:30, Dale R. Worley wrote: >=20 > "Suresh Krishnan" writes: >> * Section 3.1 >>=20 >> It is not clear to me what exactly the normative addendum is = requiring >> the client to do as regards to the DNS query while implementing "The >> dual-stack client SHOULD look up all address records". Does this mean >> that the client should do a AAAA (28) query followed by (or in = parallel >> or preceded ) for a A (1) query? I think it would be good to clarify = the >> types and ordering/concurrency of the queries. >=20 > Given that the responses to DNS queries do not depend on the order in > which they are done, it seems to me that the only necessity is to > specify that the client must do both A and AAAA queries. >=20 > In regard to the specific record types, one of our goals was that the > wording should be robust to the possibility of additional address > families being created. Thus we used the wording >=20 > The dual-stack client SHOULD look up all address records [...] = for > all address family(ies) that it supports [...] for the domain = name > and add the resulting addresses to the list of IP addresses to be > contacted. >=20 > Assuming that the client supports exactly IPv4 and IPv6, the queries = to > obtain address records for those families are A and AAAA. I don't see > that the text can be interpreted in a different way. Note that RFC 2782 (DNS SRV records) use a similar approach: "Note that where this document refers to "address records", it means A RR's, AAAA RR's, or their most modern equivalent.=E2=80=9D /O >=20 >> * Section 4 >>=20 >> I am a bit puzzled by the merging of the address lists from two = separate >> DNS queries in relation to RFC6724. This is how I see the destination >> address selection in RFC6724. The application ends up calling some = kind >> of name resolution API (something like getaddrinfo()) with a >> hostname/FQDN (say sip-1.example.com) and this results in a set of >> addresses being returned. The destination address selection algorithm >> specified in Section 6 of RFC6724 then orders these addresses and = picks >> one. I am not seeing how the second FQDN and its associated set of >> addresses become involved in the RFC6724 process. Is this something = that >> you are adding on top of RFC6724? Please clarify. >=20 > One way of looking at it is that the full process of resolving the > server's address is the process for SRV records (RFC 2782) on top of = the > destination address selection process (RFC 6724). You've identified > that correctly. >=20 > The full process is fairly complicated, and the full documentation > involves the interaction of RFC 3263, RFC 2782, and RFC 6724. But > restricting our attention to the case in question: >=20 > - The SRV records for domain name in the destination SIP URL are = looked > up. (RFC 3263) >=20 > - Depending on the priority and weight fields (and the randomization > implied by them!), the "target" domain names of the SRV records are > listed in a particular order. (RFC 2782) >=20 > The case in question is when there are more than one SRV records for = the > destination domain name, and hence more than one target domain name. >=20 > - Each of those target domain names is expanded into a group of IPv4 = and > IPv6 addresses by looking up the A and AAAA records for the name. = Each > group is sorted by the destination selection algorithm. (This can be > accomplished by calling getaddrinfo() on the target domain name.) > (RFC 6724) >=20 > - The sorted groups of addresses for the target domain names are > concatenated in the order of the target domain names. >=20 > The crucial point here is that the destination selection reordering is > only within the groups that result from the target domain names of the > SRVs -- The whole algorithm is a two-field sort with the "major" sort > being done by the SRV algorithm and the "minor" sort being done by > destination selection. >=20 > The original RFC 3263 specification describes the first two steps, but > presumes that the third step does not explicitly sort the addresses = that > are obtained for the target domain name. As a general rule, people = who > have digested the rules of RFC 3263 agree that the "naturally correct" > way to incorporate destination selection (now that it exists for IPv6) > is to expand the third step to include that sortation -- and, > critically, that destination selection cannot reorder two addresses > between groups that derive from different target domain names. >=20 > The purpose of section 4 is to make that understanding normative. >=20 > Now, comparing what I have written here with the text in section 4, I > see that section 4 does not make explicit the ordered list of target > domain names from the SRV records. And I can see that if the reader = is > not thoroughly familiar with RFC 3263, that makes the overall process > significantly less clear, because it doesn't make step 2 above = explicit. >=20 > I've updated the draft -08 to show the list of target domain names. > You can see the difference in > = https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-sipcore-dns-dual-stack-07&u= rl2=3Dhttp://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore= -dns-dual-stack-08.txt > and the entire current draft in > = http://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore-dns-d= ual-stack-08.{txt,html} >=20 > Dale From nobody Mon Aug 22 08:40:37 2016 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 3FB7D12D093 for ; Mon, 22 Aug 2016 08:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJ8agHG529F1 for ; Mon, 22 Aug 2016 08:40:30 -0700 (PDT) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C64112D60F for ; Mon, 22 Aug 2016 08:40:22 -0700 (PDT) Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-06v.sys.comcast.net with SMTP id brI5bX3nx2NhqbrKnb1fvJ; Mon, 22 Aug 2016 15:40:21 +0000 Received: from hobgoblin.ariadne.com ([73.100.16.189]) by resomta-ch2-02v.sys.comcast.net with SMTP id brKlbcAoKu1gJbrKmbXrpr; Mon, 22 Aug 2016 15:40:21 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u7MFeIFL028596; Mon, 22 Aug 2016 11:40:18 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u7MFeIAO028592; Mon, 22 Aug 2016 11:40:18 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Olle E. Johansson" In-Reply-To: (oej@edvina.net) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 22 Aug 2016 11:40:17 -0400 Message-ID: <87lgzo4xsu.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfHt8tWQg8sED2UzLmSLwuZuIvskPgjIQLcULMS3yKlFCjv7nIBY6r66TnJ3zmfWhRo+S5TXBGYkSVCAcgSdmalH6UTIOgqBBijMAF2mpifgUi+2R+skh QoU+z9/YrFHSGvZ91mYy0a8qWawHsdkqJVdnOhRMYqk2uqc1UFU4FhtYonMR/LZJsFoEHYq6n4ACIKzgtuljL9XMTIr5YC1JM/XsDBqJKdD4exWPmJ83iCg8 D/bWaHq6lyJMQOO6k7nYnW/RzJUNFZulEyMa4+lWHwa9s7jBDY39Ds8CkbcjHBaqXJb0nFIS2o/UtwlBW/DJHdicHSLgRp0QM7a/zIAlpq2IzWHg4oQ8KEKO kprqLlw9 Archived-At: Cc: sipcore-chairs@ietf.org, sipcore@ietf.org, oej@edvina.net, suresh.krishnan@ericsson.com, draft-ietf-sipcore-dns-dual-stack@ietf.org, iesg@ietf.org Subject: Re: [sipcore] Suresh Krishnan's Discuss on draft-ietf-sipcore-dns-dual-stack-07: (with DISCUSS) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 15:40:31 -0000 "Olle E. Johansson" writes: > Note that RFC 2782 (DNS SRV records) use a similar approach: > > "Note that where this document refers to "address records", it means A > RR's, AAAA RR's, or their most modern equivalent." Indeed, the definition of "address records" at the end of section 2 of draft-ietf-sipcore-dns-dual-stack-07 was derived from that definition in RFC 2782. Dale From nobody Mon Aug 22 12:32:44 2016 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 7851A12D1E4 for ; Mon, 22 Aug 2016 12:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbSDhUY-w0eC for ; Mon, 22 Aug 2016 12:32:36 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB80112D756 for ; Mon, 22 Aug 2016 12:32:34 -0700 (PDT) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-08v.sys.comcast.net with SMTP id bux7bXu5y84vjbuxWbf09H; Mon, 22 Aug 2016 19:32:34 +0000 Received: from hobgoblin.ariadne.com ([73.100.16.189]) by resomta-ch2-17v.sys.comcast.net with SMTP id buxUb5BBSrG54buxVb5msn; Mon, 22 Aug 2016 19:32:34 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u7MJWWjl020946; Mon, 22 Aug 2016 15:32:32 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u7MJWVwd020943; Mon, 22 Aug 2016 15:32:31 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Mirja Kuehlewind \(IETF\)" In-Reply-To: (ietf@kuehlewind.net) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 22 Aug 2016 15:32:31 -0400 Message-ID: <87inus38hc.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-CMAE-Envelope: MS4wfOsN9mguk4ijXilGcmncHoK+w2WHI/lxFMYCXjciYLNN3b/WBA/TSYniGw+UyuWxLdS5cSogWNNM7LvBtrlYM0PdS7+DUOKU9dsraafiHLMZcHhV1dQ9 9K0/bp9TdFrOhX0Xpgh2MLj2Ut9zWzcZOgCNA92+CCjise3nfProDAGWQ2Ts4R97iBdztdLVMeCZkmuPURx5zJPM4IO5kpemPCHE64wYtuMBZv5J4Cs8gUzW sYHIyYeZotuMSGZhSl75dCY+z2s8VHTkE5Q3J1BGNuu54GB/lrGBKrRrhFz4ISYKgNn154jYtkZT1BGqDmt+xu0Z2SOOlNbjTBtSojP15HU= Archived-At: Cc: sipcore@ietf.org, draft-ietf-sipcore-dns-dual-stack@ietf.org, iesg@ietf.org, sipcore-chairs@ietf.org Subject: Re: [sipcore] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Yes_on_draft-ietf-si?= =?utf-8?q?pcore-dns-dual-stack-07=3A_=28with_COMMENT=29?= X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 19:32:37 -0000 "Mirja Kuehlewind (IETF)" writes: > Okay. I think I was confused by the =E2=80=9Ai.e.=E2=80=98 together with = the second > sentence here: > > The dual-stack client SHOULD look up all address records (i.e., > for all address family(ies) that it supports) for the domain name > and add the resulting addresses to the list of IP addresses to be > contacted. A client MUST be prepared for the existence of DNS > resource records containing addresses in families that it does not > support; if such records may be returned by the client's DNS > queries, such records MUST be ignored as unusable and the > supported addresses used as specified herein. > > Reading it again with your clarification I not sure why I > misunderstood in the first place. So probably no clarification needed; > or maybe just remove the =E2=80=9Ai.e.=E2=80=98 and the brackets..? Reading it again, the text can be simplified by replacing "all address records (i.e., for all address family(ies) that it supports)" with "address records for all address families that it supports". So I've made that change. > One more question: getting an record returned for an address family > that was not requested is an error case, right? Or can this actual > happen in =E2=80=9Anormal=E2=80=98 operation? It depends on what DNS requests are used. E.g., if the client does an ANY request, then it will get both A and AAAA records for the domain name. But if there is a new address family, it might receive other records, and the client must be prepared to ignore them. >>> And related to this question: Shouldn't it be named "multi-stack client" >>> instead of "dual-stack client"? > > I noticed that the whole doc is written in a way that would correctly > operate with new address families. That's we I suggested this > change. I think that this term would be as easily understandable as > the current dual-stack term. But I don=E2=80=99t have a strong opinion, so > please just use what you think is better. I'll ask my coauthors what they think. They've been working on this text longer than I have and know its background better. I've updated the draft -08. You can see the differences in https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-sipcore-dns-dual-stack-07&ur= l2=3Dhttp://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore-d= ns-dual-stack-08.txt and the entire current draft in http://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore-dns-du= al-stack-08.{txt,html} Dale From nobody Wed Aug 24 11:33:50 2016 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 514BB12D658 for ; Wed, 24 Aug 2016 11:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmrAEwZXPp3X for ; Wed, 24 Aug 2016 11:33:42 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 752D012D645 for ; Wed, 24 Aug 2016 11:33:40 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-01v.sys.comcast.net with SMTP id ccyibRD5xTaLwcczbb1WJ6; Wed, 24 Aug 2016 18:33:39 +0000 Received: from hobgoblin.ariadne.com ([73.100.16.189]) by resomta-ch2-18v.sys.comcast.net with SMTP id cczabhhdwxqA0cczbbLJcI; Wed, 24 Aug 2016 18:33:39 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u7OIXcjP029140; Wed, 24 Aug 2016 14:33:38 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u7OIXbJf029137; Wed, 24 Aug 2016 14:33:37 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Mirja Kuehlewind \(IETF\)" In-Reply-To: (ietf@kuehlewind.net) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 24 Aug 2016 14:33:36 -0400 Message-ID: <87mvk2xbi7.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-CMAE-Envelope: MS4wfHHfmxk6YavI5tgpOsE7AEe7f/oRZq9UEHlsL+ameoZqdViE6YqwaS7LEQkaFA1gfBgYOw5K+qiCx0diJHFk0LcTb1KHw8OyAi/2WNFlwa1jiiAINdGm 0vABAqjyaxLOKPXYmYNemxEgceixVhRmX/eudTyVpOVu1aSdjaTVxOrl1YEdDZrkSSKT4tLArfz/5s4+93aCs5GWGS3K+juLkrU5m2qIog/kl7dFsZd0fSRx NZg1e4FiciR8Q41FPsXPDxOejAdqQ9/w0RO0bIWPNYfGkNm2FNJv1zG83ihFzopsoY3MdY0z5NNrqB2oioGAdAWMq5L9z5lJ/GA/oG0T8no= Archived-At: Cc: sipcore@ietf.org, draft-ietf-sipcore-dns-dual-stack@ietf.org, iesg@ietf.org, sipcore-chairs@ietf.org Subject: Re: [sipcore] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Yes_on_draft-ietf-si?= =?utf-8?q?pcore-dns-dual-stack-07=3A_=28with_COMMENT=29?= X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 18:33:43 -0000 "Mirja Kuehlewind (IETF)" writes: >>> And related to this question: Shouldn't it be named "multi-stack client" >>> instead of "dual-stack client"? >>=20 >> Strictly speaking, "multi-stack client" is more robust against the >> possibility that a third address family is introduced. However, the >> term "dual-stack" is what has been used in all of the discussions >> regarding the transition to using IPv6, so we have continued its use in >> this draft in the narrative portions. OTOH, all of the normative text >> is written to operate correctly even if further address families are >> introduced. > > I noticed that the whole doc is written in a way that would correctly > operate with new address families. That's we I suggested this > change. I think that this term would be as easily understandable as > the current dual-stack term. But I don=E2=80=99t have a strong opinion, so > please just use what you think is better. We've kept the term "dual-stack" because that's what's been used in all the Happy Eyeballs-related discussions, but we've revised the Terminology section to make it clear that "dual-stack" includes any situation "where the client has access to multiple communication methods that have distinct addressing characteristics". I've updated the draft -08. You can see the differences in https://www.ietf.org/rfcdiff?url1=3D3Ddraft-ietf-sipcore-dns-dual-stack-07&= ur=3D l2=3D3Dhttp://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore= -d=3D ns-dual-stack-08.txt and the entire current draft in http://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore-dns-du= =3D al-stack-08.{txt,html} Dale From nobody Wed Aug 24 17:22:40 2016 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 CE07712D58E for ; Wed, 24 Aug 2016 17:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1iyk31puXX1 for ; Wed, 24 Aug 2016 17:22:37 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9C0D12D0F7 for ; Wed, 24 Aug 2016 17:22:29 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id z190so31848155qkc.0 for ; Wed, 24 Aug 2016 17:22:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:subject:date:references:to :message-id:mime-version; bh=VbhpvaioZnrtoDz19TZAbH8R414z3ye/+Eup510BY24=; b=wOrOIfyuiQT0yoGnWfDgLJ6d7kXwBRY3opjXJe9kL37grnwyCVnXSejjg66DpunacL 8J3s1YfqSPOzhwAbCvIiQ34HB9eesiX13HQzfZH5g0pDBRZRs/WTbgrBgLnD0fRy9uDm jBqQlUYAWg5e/AWsxdkkS8Q9YqloFNBA6g8TKZmAOar78sWdKjn3kUQ1n5ZlUSPjvawC EhbxQKQEPwCFbJM5JJpUFiqtVSxMqge97S1wlxMaRdpUZcBTD3Sh0dKQIaR+5tXNm8tJ syK0DdtyuVlM6pT/dFAzDUdbAmlPjRUkq4A8eLkEJwrv2jHcB0zF7/Elt9g6GoN7ZZ+m cbKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject:date :references:to:message-id:mime-version; bh=VbhpvaioZnrtoDz19TZAbH8R414z3ye/+Eup510BY24=; b=eyHyf66wBUostick1RrlRe75+T16REOsKm0eOevWazFxNmMqmO6ys6/lReDbC/E85N x2yC9abVeKZdei8d6F2Y3EBccT87maQdVQFtVn8QARRkbwWXYdQK6Oo5FcE6GOcV/bjg R+n6KpiYzfwWqJ6SCr+vF2f3mbVaYFvUXttgppfyZ5U+RalxGdLLnwW2X9yi5tDoF4vd XHhD6WerE9whaOwDsVjhKKYqByNbrQIaWPvXvYn+o0fLyn1BWOe5tQCOq/GEkrMvk7r7 Z9PZ6/c1macBjyqXyWHLh5bZtKLGxKONJUbsMNAVFNf0cFgDF1ZYpOzhUEvP4xe3vmbM kbvg== X-Gm-Message-State: AE9vXwPfTvJDiXRDTKLX1n1DcB1FBmWb9r+YZQqZVgrrqm0ME8TQuCnOeGbGLy36CdQHUw== X-Received: by 10.55.49.144 with SMTP id x138mr7091274qkx.227.1472084548846; Wed, 24 Aug 2016 17:22:28 -0700 (PDT) Received: from [10.33.192.33] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id c26sm6183555qte.1.2016.08.24.17.22.28 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 24 Aug 2016 17:22:28 -0700 (PDT) From: Brian Rosen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Aug 2016 20:22:25 -0400 References: To: sipcore@ietf.org Message-Id: <76CCBFA5-8D53-4B1E-A495-4A18AB081384@brianrosen.net> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 00:22:39 -0000 Over in ecrit we have a disagreement that relates to interpreting = RFC6086. Background: RFC7852 defines something called "Additional Data", which is carried in = emergency call signaling. It's data related to the call, e.g., the = identity and contact data of the service provider handling the call. = Additional Data is signaled with a Call-Info header field, which = contains either a URI pointing to a data block fetched with HTTPS, or a = Content Indirect referencing a body part of the SIP message. It's = usually used on the INVITE of the emergency call, so it can be displayed = to the PSAP (emergency call center) call-taker when the call is = assigned. Sometimes, this data can change during a call. The example in = discussion is telematics data in a vehicle. The vehicle can report = things like the number of occupants and its orientation. The PSAP can = request an update mid call (e.g., if the call taker thinks things might = have changed). INFO is the chosen mechanism to send the request for update. The device = will send a response to the request (an ACK), which is also sent in = INFO. This constitutes a well defined INFO package, and will be = registered in the usual way. The Issue at hand: So, the dispute is how the updated data is sent mid call. RFC6086 says NOTE: An INFO request can also contain other body parts that are meaningful within the context of an invite dialog usage but are not specifically associated with the INFO method and the application concerned. The authors of the draft (of which I am one) desire to use the = Additional Data mechanism to carry the updated data. The data could be = sent in any convenient message, although since the vehicle is sending an = ACK, it's likely going to go on that. We'd like to always carry the = data in the same way. In an INFO message it would be carried the same = as it is in the INVITE, as Additional Data. Since the INFO carries an = ACK, it would specify the appropriate INFO package, and would contain a = body part with the ACK. There would be another body part for the = updated data, pointed to by the Call-Info. Some ecrit participants say that the above language of 6086 would = prohibit the INFO from containing a Call-Info header with a CID pointing = to a MIME body part, because the data was requested by an INFO, and = hence is related to the INFO package. They say that the data MUST be = carried with a body part and Content Disposition that is part of the = INFO package definition. The draft authors claim this 6086 language isn't a straightjacket, and = it's perfectly fine to carry the data referenced by a Call-Info with a = Content Indirect body part using the same MIME type and Content = Disposition as it would in an INVITE. When the updated data is sent in = INFO, it's because the INFO is a convenient message (since it's being = sent to carry the ACK). Mechanically, both mechanisms can be made to work. The body parts would = be labeled appropriately and there would be no confusion about what they = mean or how they would be interpreted. It's really only whether the = Call-Info header is present and what the MIME type and Content = Disposition the body part containing the data would be. In the author's = preferred way, it would be the MIME type and Content Disposition of the = Call-Info and in the other point of view it would be the MIME type and = Content Disposition of the INFO package. Please ignore your personal preference for whether you think it ought to = go in the INFO or not, and please help us interpret 6086: does the data = HAVE to go in an INFO body part or can it be sent in a Call-Info body = part? From nobody Wed Aug 24 20:50:16 2016 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 D45F212D10C; Wed, 24 Aug 2016 20:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.079 X-Spam-Level: X-Spam-Status: No, score=-13.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gnz9ucT_SEvn; Wed, 24 Aug 2016 20:50:07 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B355512B04F; Wed, 24 Aug 2016 20:50:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15386; q=dns/txt; s=iport; t=1472097006; x=1473306606; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=D+/eF7XUUmoGddipJXyyaww51RHYXKiaAy6XWwf/bb4=; b=mIR+5e/le065wVmiVs5H5+klxV+dr3DvyBnIovI7fmoKEZOzQnsYAURV /2xxYLH/e1JQEM3UE8lG54iVjW+bnS0x0FVLLxuhYTh55l/W+STcN9/Kj 0tCGYBMe/cOOMi693xF+h99j6fPGW8l3f6gOtZumMpMaVl5EHCqexs9Zz 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DcAgAJar5X/5JdJa1cgykBAQEBAR5Wf?= =?us-ascii?q?AezBYJ5gg+Bfh+EI4FbAoFROBQCAQEBAQEBAV4nhGIBBXIHEAIBCD8HMhQRAgQ?= =?us-ascii?q?OBYgyDsAxAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIYugXgIgk2EKlSCb4IvBYYQi?= =?us-ascii?q?A+LKQGGH4J/gniDDIFthFyJB4xAg3gBDw82gkiBNXABAQGHVX8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,573,1464652800"; d="scan'208,217";a="313586053" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Aug 2016 03:50:05 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u7P3o5S9014813 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 25 Aug 2016 03:50:05 GMT Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 24 Aug 2016 22:50:04 -0500 Received: from xch-aln-009.cisco.com ([173.36.7.19]) by XCH-ALN-009.cisco.com ([173.36.7.19]) with mapi id 15.00.1210.000; Wed, 24 Aug 2016 22:50:05 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: Suresh Krishnan Thread-Topic: Suresh Krishnan's Discuss on draft-ietf-sipcore-dns-dual-stack-07: (with DISCUSS) Thread-Index: AQHR/oPDG5fffFhK70W0JbKQU/W66A== Date: Thu, 25 Aug 2016 03:50:05 +0000 Message-ID: <39AEA207-8847-4178-8079-F31D1B50653F@cisco.com> References: <87k2fc7b8f.fsf@hobgoblin.ariadne.com> In-Reply-To: <87k2fc7b8f.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.230.249] Content-Type: multipart/alternative; boundary="_000_39AEA207884741788079F31D1B50653Fciscocom_" MIME-Version: 1.0 Archived-At: Cc: SIPCORE , "draft-ietf-sipcore-dns-dual-stack@ietf.org" , The IESG , "sipcore-chairs@ietf.org" Subject: Re: [sipcore] Suresh Krishnan's Discuss on draft-ietf-sipcore-dns-dual-stack-07: (with DISCUSS) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 03:50:09 -0000 --_000_39AEA207884741788079F31D1B50653Fciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Suresh - Just following up on this. The updated draft (-08) attempts to address you= r DISCUSS. You can see the diffs here: https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-sipcore-dns-dual-stack-07&ur= l2=3Dhttp://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore-d= ns-dual-stack-08.txt and the entire current draft can be found here: http://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore-dns-du= =3D al-stack-08.txt Once you confirm your points are addressed we will publish the -08 version. Thanks, Gonzalo On Aug 19, 2016, at 4:30 PM, Dale R. Worley > wrote: "Suresh Krishnan" > writes: * Section 3.1 It is not clear to me what exactly the normative addendum is requiring the client to do as regards to the DNS query while implementing "The dual-stack client SHOULD look up all address records". Does this mean that the client should do a AAAA (28) query followed by (or in parallel or preceded ) for a A (1) query? I think it would be good to clarify the types and ordering/concurrency of the queries. Given that the responses to DNS queries do not depend on the order in which they are done, it seems to me that the only necessity is to specify that the client must do both A and AAAA queries. In regard to the specific record types, one of our goals was that the wording should be robust to the possibility of additional address families being created. Thus we used the wording The dual-stack client SHOULD look up all address records [...] for all address family(ies) that it supports [...] for the domain name and add the resulting addresses to the list of IP addresses to be contacted. Assuming that the client supports exactly IPv4 and IPv6, the queries to obtain address records for those families are A and AAAA. I don't see that the text can be interpreted in a different way. * Section 4 I am a bit puzzled by the merging of the address lists from two separate DNS queries in relation to RFC6724. This is how I see the destination address selection in RFC6724. The application ends up calling some kind of name resolution API (something like getaddrinfo()) with a hostname/FQDN (say sip-1.example.com) and this re= sults in a set of addresses being returned. The destination address selection algorithm specified in Section 6 of RFC6724 then orders these addresses and picks one. I am not seeing how the second FQDN and its associated set of addresses become involved in the RFC6724 process. Is this something that you are adding on top of RFC6724? Please clarify. One way of looking at it is that the full process of resolving the server's address is the process for SRV records (RFC 2782) on top of the destination address selection process (RFC 6724). You've identified that correctly. The full process is fairly complicated, and the full documentation involves the interaction of RFC 3263, RFC 2782, and RFC 6724. But restricting our attention to the case in question: - The SRV records for domain name in the destination SIP URL are looked up. (RFC 3263) - Depending on the priority and weight fields (and the randomization implied by them!), the "target" domain names of the SRV records are listed in a particular order. (RFC 2782) The case in question is when there are more than one SRV records for the destination domain name, and hence more than one target domain name. - Each of those target domain names is expanded into a group of IPv4 and IPv6 addresses by looking up the A and AAAA records for the name. Each group is sorted by the destination selection algorithm. (This can be accomplished by calling getaddrinfo() on the target domain name.) (RFC 6724) - The sorted groups of addresses for the target domain names are concatenated in the order of the target domain names. The crucial point here is that the destination selection reordering is only within the groups that result from the target domain names of the SRVs -- The whole algorithm is a two-field sort with the "major" sort being done by the SRV algorithm and the "minor" sort being done by destination selection. The original RFC 3263 specification describes the first two steps, but presumes that the third step does not explicitly sort the addresses that are obtained for the target domain name. As a general rule, people who have digested the rules of RFC 3263 agree that the "naturally correct" way to incorporate destination selection (now that it exists for IPv6) is to expand the third step to include that sortation -- and, critically, that destination selection cannot reorder two addresses between groups that derive from different target domain names. The purpose of section 4 is to make that understanding normative. Now, comparing what I have written here with the text in section 4, I see that section 4 does not make explicit the ordered list of target domain names from the SRV records. And I can see that if the reader is not thoroughly familiar with RFC 3263, that makes the overall process significantly less clear, because it doesn't make step 2 above explicit. I've updated the draft -08 to show the list of target domain names. You can see the difference in https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-sipcore-dns-dual-stack-07&ur= l2=3Dhttp://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore-d= ns-dual-stack-08.txt and the entire current draft in http://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore-dns-du= al-stack-08.{txt,html} Dale --_000_39AEA207884741788079F31D1B50653Fciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <0317D3BEED0A19449B47F0F1C00BE2B7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Hi Suresh - 


Just following up on this.  The updated draft (-08) at= tempts to address your DISCUSS.  You can see the diffs here:

https://www= .ietf.org/rfcdiff?url1=3Ddraft-ietf-sipcore-dns-dual-stack-07&url2=3Dht= tp://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore-dns-dual= -stack-08.txt

and the entire current draft can be found here:

http://svn.resiprocate.org/rep/ietf-= drafts/worley/draft-ietf-sipcore-dns-du=3D
al-stack-08.txt

Once you confirm your points are addressed we will publish = the -08 version.

Thanks,

Gonzalo


On Aug 19, 2016, at 4:30 PM, Dale R. W= orley <worley@ariadne.c= om> wrote:

"Suresh Krishnan" <suresh.krishnan@ericsson.com> writes:
* Section 3.1

It is not clear to me what exactly the normative addendum is requiring
the client to do as regards to the DNS query while implementing "The dual-stack client SHOULD look up all address records". Does this mean<= br class=3D""> that the client should do a AAAA (28) query followed by (or in parallel
or preceded ) for a A (1) query? I think it would be good to clarify the types and ordering/concurrency of the queries.

Given that the responses to DNS queries do not depend on the order in
which they are done, it seems to me that the only necessity is to
specify that the client must do both A and AAAA queries.

In regard to the specific record types, one of our goals was that the
wording should be robust to the possibility of additional address
families being created.  Thus we used the wording

     The dual-stack client SHOULD look up all address record= s [...] for
     all address family(ies) that it supports [...] for the = domain name
     and add the resulting addresses to the list of IP addre= sses to be
     contacted.

Assuming that the client supports exactly IPv4 and IPv6, the queries to
obtain address records for those families are A and AAAA.  I don't see=
that the text can be interpreted in a different way.

* Section 4

I am a bit puzzled by the merging of the address lists from two separate DNS queries in relation to RFC6724. This is how I see the destination
address selection in RFC6724. The application ends up calling some kind
of name resolution API (something like getaddrinfo()) with a
hostname/FQDN (say sip-1.ex= ample.com) and this results in a set of
addresses being returned. The destination address selection algorithm
specified in Section 6 of RFC6724 then orders these addresses and picks
one. I am not seeing how the second FQDN and its associated set of
addresses become involved in the RFC6724 process. Is this something that you are adding on top of RFC6724? Please clarify.

One way of looking at it is that the full process of resolving the
server's address is the process for SRV records (RFC 2782) on top of the destination address selection process (RFC 6724).  You've identified that correctly.

The full process is fairly complicated, and the full documentation
involves the interaction of RFC 3263, RFC 2782, and RFC 6724.  But
restricting our attention to the case in question:

- The SRV records for domain name in the destination SIP URL are looked
 up.  (RFC 3263)

- Depending on the priority and weight fields (and the randomization
 implied by them!), the "target" domain names of the SRV rec= ords are
 listed in a particular order.  (RFC 2782)

The case in question is when there are more than one SRV records for the destination domain name, and hence more than one target domain name.

- Each of those target domain names is expanded into a group of IPv4 and  IPv6 addresses by looking up the A and AAAA records for the name. &nb= sp;Each
 group is sorted by the destination selection algorithm.  (This c= an be
 accomplished by calling getaddrinfo() on the target domain name.)
 (RFC 6724)

- The sorted groups of addresses for the target domain names are
 concatenated in the order of the target domain names.

The crucial point here is that the destination selection reordering is
only within the groups that result from the target domain names of the
SRVs -- The whole algorithm is a two-field sort with the "major" = sort
being done by the SRV algorithm and the "minor" sort being done b= y
destination selection.

The original RFC 3263 specification describes the first two steps, but
presumes that the third step does not explicitly sort the addresses that are obtained for the target domain name.  As a general rule, people wh= o
have digested the rules of RFC 3263 agree that the "naturally correct&= quot;
way to incorporate destination selection (now that it exists for IPv6)
is to expand the third step to include that sortation -- and,
critically, that destination selection cannot reorder two addresses
between groups that derive from different target domain names.

The purpose of section 4 is to make that understanding normative.

Now, comparing what I have written here with the text in section 4, I
see that section 4 does not make explicit the ordered list of target
domain names from the SRV records.  And I can see that if the reader i= s
not thoroughly familiar with RFC 3263, that makes the overall process
significantly less clear, because it doesn't make step 2 above explicit.
I've updated the draft -08 to show the list of target domain names.
You can see the difference in
https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-sipcore-d= ns-dual-stack-07&url2=3Dhttp://svn.resiprocate.org/rep/ietf-drafts/= worley/draft-ietf-sipcore-dns-dual-stack-08.txt
and the entire current draft in
http://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore-dns-du= al-stack-08.{txt,html}

Dale

--_000_39AEA207884741788079F31D1B50653Fciscocom_-- From nobody Wed Aug 24 23:00:22 2016 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 6CCC312D587 for ; Wed, 24 Aug 2016 23:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-HZpxmrKB3U for ; Wed, 24 Aug 2016 23:00:17 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1788312D0C1 for ; Wed, 24 Aug 2016 23:00:16 -0700 (PDT) X-AuditID: c1b4fb3a-c91fe700000009bd-02-57be896e771a Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by (Symantec Mail Security) with SMTP id CA.A0.02493.E698EB75; Thu, 25 Aug 2016 08:00:15 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0301.000; Thu, 25 Aug 2016 08:00:14 +0200 From: Christer Holmberg To: Brian Rosen , "sipcore@ietf.org" Thread-Topic: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? Thread-Index: AQHR/mbNNlz1LzaAzEOKupLA3hyI6qBZQRIA Date: Thu, 25 Aug 2016 06:00:13 +0000 Message-ID: References: <76CCBFA5-8D53-4B1E-A495-4A18AB081384@brianrosen.net> In-Reply-To: <76CCBFA5-8D53-4B1E-A495-4A18AB081384@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2K7h25+575wgz0FFk/vT2Oz+PpjE5sD k8f9b3/ZPZYs+ckUwBTFZZOSmpNZllqkb5fAlbF54we2gkXaFe8ObWFvYPyk1MXIySEhYCLx 4tx/xi5GLg4hgfWMEk+un2IESQgJLGGUWH9TpYuRg4NNwEKi+582SFhEwEvi7s3jbCC2sECS xOb5a1kh4skSj/7fZYKwjSQad8wBG8MioCrxdOMydhCbV8BKYtuybywQ47Mltr5tB6vnFHCS +N+5GmwOo4CYxPdTa8DizALiEreezGeCuFNAYsme88wQtqjEy8f/wOpFBfQkvn+dDRVXlNh5 tp0ZoldP4sbUKWwQtrXE3euXWCFsbYllC18zQ9wjKHFy5hOWCYxis5Csm4WkfRaS9llI2mch aV/AyLqKUbQ4tbg4N93ISC+1KDO5uDg/Ty8vtWQTIzCmDm75bbWD8eBzx0OMAhyMSjy8Cx7s DRdiTSwrrsw9xCjBwawkwruwdV+4EG9KYmVValF+fFFpTmrxIUZpDhYlcV7/l4rhQgLpiSWp 2ampBalFMFkmDk6pBsaUQ9OnyzV/tY/+wO/xWOXrjoffg979kd2hGK98983zcwGezioXbizM WZf1ql7GhzvGvtFGyJeXc9WWab7JM3i/8UecmMpo9PHlxUXatfo3hdPc1Yqj363xLrv75tfD H4sKs1aH9d3WOcAeduOS+0G2/HOPZyx552637/nJeFvn6bZKG6sZ6xiUWIozEg21mIuKEwHX K0+0pQIAAA== Archived-At: Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 06:00:19 -0000 Hi, I=B9m glad this is brought to SIPCORE. As one of the info package proponents, please let me clarify my arguments. The 6086 text that Brian copied says =B3but are not specifically associated with the INFO method and the application concerned=B2. I claim that the updated data IS associated with the application concerned (ecall). The updated data is requested by the ecall application, and the delivered updated data is consumed by the ecall application. The updated data is NOT some non-ecall-application-related information that is piggybacked in a "convenient INFO message" that happens to be sent by the ecall application for some other purpose. (In addition, the updated data is NOT associated with a legacy (pre-6086) INFO usage, which could justify not using an Info Package. I do want to point out that nobody has claimed that the updated data would be associated with legacy INFO, but just for completeness) RFC 7852 does define a mechanism for transporting data, using Call-Info etc. But, 7852 does not update 6086, nor can 7852 override rules and procedures associated with individual SIP methods (INFO in this case). I also pointed this out before 7852 was published, but was told that it=B9s too late to change it (granted, the draft was in the RFC editor=B9s queue). Finally, again for completeness, I want to point out that 6086 does not prevent including Call-Info in INFO as such. The issue is how some want to use Call-Info instead of an Info Package. Regards, Christer On 25/08/16 03:22, "sipcore on behalf of Brian Rosen" wrote: >Over in ecrit we have a disagreement that relates to interpreting RFC6086. > >Background: >RFC7852 defines something called "Additional Data", which is carried in >emergency call signaling. It's data related to the call, e.g., the >identity and contact data of the service provider handling the call. >Additional Data is signaled with a Call-Info header field, which contains >either a URI pointing to a data block fetched with HTTPS, or a Content >Indirect referencing a body part of the SIP message. It's usually used >on the INVITE of the emergency call, so it can be displayed to the PSAP >(emergency call center) call-taker when the call is assigned. > >Sometimes, this data can change during a call. The example in discussion >is telematics data in a vehicle. The vehicle can report things like the >number of occupants and its orientation. The PSAP can request an update >mid call (e.g., if the call taker thinks things might have changed). > >INFO is the chosen mechanism to send the request for update. The device >will send a response to the request (an ACK), which is also sent in INFO. > This constitutes a well defined INFO package, and will be registered in >the usual way. > >The Issue at hand: >So, the dispute is how the updated data is sent mid call. > >RFC6086 says > > NOTE: An INFO request can also contain other body parts that are > meaningful within the context of an invite dialog usage but are > not specifically associated with the INFO method and the > application concerned. > >The authors of the draft (of which I am one) desire to use the Additional >Data mechanism to carry the updated data. The data could be sent in any >convenient message, although since the vehicle is sending an ACK, it's >likely going to go on that. We'd like to always carry the data in the >same way. In an INFO message it would be carried the same as it is in >the INVITE, as Additional Data. Since the INFO carries an ACK, it would >specify the appropriate INFO package, and would contain a body part with >the ACK. There would be another body part for the updated data, pointed >to by the Call-Info. > >Some ecrit participants say that the above language of 6086 would >prohibit the INFO from containing a Call-Info header with a CID pointing >to a MIME body part, because the data was requested by an INFO, and hence >is related to the INFO package. They say that the data MUST be carried >with a body part and Content Disposition that is part of the INFO package >definition. > >The draft authors claim this 6086 language isn't a straightjacket, and >it's perfectly fine to carry the data referenced by a Call-Info with a >Content Indirect body part using the same MIME type and Content >Disposition as it would in an INVITE. When the updated data is sent in >INFO, it's because the INFO is a convenient message (since it's being >sent to carry the ACK). > >Mechanically, both mechanisms can be made to work. The body parts would >be labeled appropriately and there would be no confusion about what they >mean or how they would be interpreted. It's really only whether the >Call-Info header is present and what the MIME type and Content >Disposition the body part containing the data would be. In the author's >preferred way, it would be the MIME type and Content Disposition of the >Call-Info and in the other point of view it would be the MIME type and >Content Disposition of the INFO package. > >Please ignore your personal preference for whether you think it ought to >go in the INFO or not, and please help us interpret 6086: does the data >HAVE to go in an INFO body part or can it be sent in a Call-Info body >part? > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Aug 25 05:56:10 2016 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 6311D12B04E for ; Thu, 25 Aug 2016 05:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9erWCPy-OSl6 for ; Thu, 25 Aug 2016 05:56:06 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E69B12B011 for ; Thu, 25 Aug 2016 05:56:06 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id 93so21999344qtg.2 for ; Thu, 25 Aug 2016 05:56:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lPQxOnq/SF9JEFvhDPRLTbIn5t9azeKfSLQ0/FVMu08=; b=qg9rHtM3fzcEMrue3BJ9JO9e628ZldDG0obC4IN0oMWpehA9X2Pi8Cqr8LeGThCAcF OpraL4Kmc63YjqGX7hEFcY6mH1zOA659uXvuwgLXuQ2BqRn1/53+fpmuRpu/FOb/lObl tV45LHFquKaXCse3FNbGTwFx3VP/KlE/MMyGt5XZo+W8ibCePukdWWDRfiSgubyiI7eT 40AIsrSurZbNYyyTWwjqBLX9cAuBvyfbXBPicuF4hPXo7vHJ8823AtnTuANX/CBXmZNI e/j3uEOPHLvjYPHOOMYLwa4PJYIvru1+WTMMhaQRkg3nIoRvbQfCvJv2ejrg4lJcGvjf QViA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lPQxOnq/SF9JEFvhDPRLTbIn5t9azeKfSLQ0/FVMu08=; b=RcpJunUGNnV0MNYrpLgXzt4U7P0BZ4xuALTYLYomFnL7pVl3OF850/PRHey+ff2YzQ Vwc/7yBLcdj6+xk68snmZnnmCqI1ZXQrbS9OQHpl2A5yJa0lPhPfgC4iUJPA2Unm2gXF a8L/FHZHnYy0XXlsdh6d0ULuIgIOY0IM481Tqv239rYVLitZSu/5uSGB3GiPwIP13vO2 5CZwvp2lB3yRNDtWf8F6yfhLVbPyKRnm78syQ+rLuEntBK88pUlmQCQGY6KwzdZrX48+ RNnINZmDjiL2Hf85GuBSUJcSVFIWQGasnRAqYvZrVibmW3ewdiQEWi3WNk+A2hKVE9xR LbAg== X-Gm-Message-State: AE9vXwNm/JTxUNvwr6EU8viDkXWToDDXEYLb9I5JCtUpCH617qPbZVg5HRW4DWguIatlaA== X-Received: by 10.200.54.107 with SMTP id n40mr9936132qtb.44.1472129765014; Thu, 25 Aug 2016 05:56:05 -0700 (PDT) Received: from [10.33.192.33] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id j67sm7462662qkf.41.2016.08.25.05.56.04 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 25 Aug 2016 05:56:04 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: Date: Thu, 25 Aug 2016 08:56:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <05240A95-8319-4555-8B46-FA18B6C27883@brianrosen.net> References: <76CCBFA5-8D53-4B1E-A495-4A18AB081384@brianrosen.net> To: Christer Holmberg X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 12:56:08 -0000 We=E2=80=99re agreeing that there is a relationship between the command = and the data. We=E2=80=99re suggesting that we don=E2=80=99t have to be anal about the = language and as long as there is an INFO package, and a body part that = has the ACK which is an INFO body part, that the cited language = doesn=E2=80=99t compel us to use the INFO body part to transport the = data, the Call-Info mechanism is acceptable. No one is suggesting that we update 6086, and we agree that 7852 did not = update 6086. =20 It=E2=80=99s just whether that language prohibits use of the Call-Info = to carry the data when it was prompted by the INFO package request, and = accompanies the INFO package ACK. Brian > On Aug 25, 2016, at 2:00 AM, Christer Holmberg = wrote: >=20 > Hi, >=20 > I=C2=B9m glad this is brought to SIPCORE. As one of the info package > proponents, please let me clarify my arguments. >=20 > The 6086 text that Brian copied says =C2=B3but are not specifically = associated > with the INFO method and the application concerned=C2=B2. >=20 > I claim that the updated data IS associated with the application = concerned > (ecall). The updated data is requested by the ecall application, and = the > delivered updated data is consumed by the ecall application. The = updated > data is NOT some non-ecall-application-related information that is > piggybacked in a "convenient INFO message" that happens to be sent by = the > ecall application for some other purpose. >=20 > (In addition, the updated data is NOT associated with a legacy = (pre-6086) > INFO usage, which could justify not using an Info Package. I do want = to > point out that nobody has claimed that the updated data would be > associated with legacy INFO, but just for completeness) >=20 > RFC 7852 does define a mechanism for transporting data, using = Call-Info > etc. But, 7852 does not update 6086, nor can 7852 override rules and > procedures associated with individual SIP methods (INFO in this case). = I > also pointed this out before 7852 was published, but was told that = it=C2=B9s > too late to change it (granted, the draft was in the RFC editor=C2=B9s = queue). >=20 > Finally, again for completeness, I want to point out that 6086 does = not > prevent including Call-Info in INFO as such. The issue is how some = want to > use Call-Info instead of an Info Package. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > On 25/08/16 03:22, "sipcore on behalf of Brian Rosen" > wrote: >=20 >> Over in ecrit we have a disagreement that relates to interpreting = RFC6086. >>=20 >> Background: >> RFC7852 defines something called "Additional Data", which is carried = in >> emergency call signaling. It's data related to the call, e.g., the >> identity and contact data of the service provider handling the call. >> Additional Data is signaled with a Call-Info header field, which = contains >> either a URI pointing to a data block fetched with HTTPS, or a = Content >> Indirect referencing a body part of the SIP message. It's usually = used >> on the INVITE of the emergency call, so it can be displayed to the = PSAP >> (emergency call center) call-taker when the call is assigned. >>=20 >> Sometimes, this data can change during a call. The example in = discussion >> is telematics data in a vehicle. The vehicle can report things like = the >> number of occupants and its orientation. The PSAP can request an = update >> mid call (e.g., if the call taker thinks things might have changed). >>=20 >> INFO is the chosen mechanism to send the request for update. The = device >> will send a response to the request (an ACK), which is also sent in = INFO. >> This constitutes a well defined INFO package, and will be registered = in >> the usual way. >>=20 >> The Issue at hand: >> So, the dispute is how the updated data is sent mid call. >>=20 >> RFC6086 says >>=20 >> NOTE: An INFO request can also contain other body parts that are >> meaningful within the context of an invite dialog usage but are >> not specifically associated with the INFO method and the >> application concerned. >>=20 >> The authors of the draft (of which I am one) desire to use the = Additional >> Data mechanism to carry the updated data. The data could be sent in = any >> convenient message, although since the vehicle is sending an ACK, = it's >> likely going to go on that. We'd like to always carry the data in = the >> same way. In an INFO message it would be carried the same as it is = in >> the INVITE, as Additional Data. Since the INFO carries an ACK, it = would >> specify the appropriate INFO package, and would contain a body part = with >> the ACK. There would be another body part for the updated data, = pointed >> to by the Call-Info. >>=20 >> Some ecrit participants say that the above language of 6086 would >> prohibit the INFO from containing a Call-Info header with a CID = pointing >> to a MIME body part, because the data was requested by an INFO, and = hence >> is related to the INFO package. They say that the data MUST be = carried >> with a body part and Content Disposition that is part of the INFO = package >> definition. >>=20 >> The draft authors claim this 6086 language isn't a straightjacket, = and >> it's perfectly fine to carry the data referenced by a Call-Info with = a >> Content Indirect body part using the same MIME type and Content >> Disposition as it would in an INVITE. When the updated data is sent = in >> INFO, it's because the INFO is a convenient message (since it's being >> sent to carry the ACK). >>=20 >> Mechanically, both mechanisms can be made to work. The body parts = would >> be labeled appropriately and there would be no confusion about what = they >> mean or how they would be interpreted. It's really only whether the >> Call-Info header is present and what the MIME type and Content >> Disposition the body part containing the data would be. In the = author's >> preferred way, it would be the MIME type and Content Disposition of = the >> Call-Info and in the other point of view it would be the MIME type = and >> Content Disposition of the INFO package. >>=20 >> Please ignore your personal preference for whether you think it ought = to >> go in the INFO or not, and please help us interpret 6086: does the = data >> HAVE to go in an INFO body part or can it be sent in a Call-Info body >> part? >>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >=20 From nobody Thu Aug 25 06:14:12 2016 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 C140F12B04E for ; Thu, 25 Aug 2016 06:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TvdELIyZSWY for ; Thu, 25 Aug 2016 06:14:09 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3717512B05D for ; Thu, 25 Aug 2016 06:14:09 -0700 (PDT) X-AuditID: c1b4fb3a-c91fe700000009bd-2d-57beef1ebeb9 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by (Symantec Mail Security) with SMTP id 3F.A9.02493.E1FEEB75; Thu, 25 Aug 2016 15:14:07 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0301.000; Thu, 25 Aug 2016 15:14:06 +0200 From: Christer Holmberg To: Brian Rosen Thread-Topic: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? Thread-Index: AQHR/mbNNlz1LzaAzEOKupLA3hyI6qBZQRIAgABAqYCAADiRgA== Date: Thu, 25 Aug 2016 13:14:06 +0000 Message-ID: References: <76CCBFA5-8D53-4B1E-A495-4A18AB081384@brianrosen.net> <05240A95-8319-4555-8B46-FA18B6C27883@brianrosen.net> In-Reply-To: <05240A95-8319-4555-8B46-FA18B6C27883@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPIsWRmVeSWpSXmKPExsUyM2K7k678+33hBj3HZSye3p/GZvH1xyY2 ByaP+9/+snssWfKTKYApissmJTUnsyy1SN8ugSuj5YRewSK/ii0n7jM1MC7w6WLk5JAQMJGY 9P0SUxcjF4eQwHpGidXHXkI5SxglJp74zNLFyMHBJmAh0f1PG6RBREBZYuetTnYQm1lAU+LR zr1MILawQJLE5vlrWSFqkiUe/b/LBGE7SVw/tYEVZAyLgKrE49l1IGFeASuJ9xtWs0GsusIo 8frlTrCZnED18yfOB7MZBcQkvp9awwSxS1zi1pP5TBBHC0gs2XOeGcIWlXj5+B/YXlEBPYnv X2dDxZUkfmy4xALRqyXx5cc+NgjbWqJ30ltmCFtRYkr3Q3aIgwQlTs58wjKBUXwWknWzkLTP QtI+C0n7LCTtCxhZVzGKFqcWF+emGxnppRZlJhcX5+fp5aWWbGIERtvBLb+tdjAefO54iFGA g1GJh3fBg73hQqyJZcWVuYcYJTiYlUR4X7/dFy7Em5JYWZValB9fVJqTWnyIUZqDRUmc1/+l YriQQHpiSWp2ampBahFMlomDU6qBUcxuBddO7kQOCf+C4lb3ou9OGnVPNwuqSq1f2Va6atPJ rp+NplbPXnxaIfT8ASvTjkmRHaW8iV9/fK24JNYSprZE9FngomX505gu6nRk72Drrn7zzMTi 53OLubcd3mvfYvzBsamoOb06Vqmj7t61AiMLzdY+KbavCbIlB2qX/zs/ofjHCeEHSizFGYmG WsxFxYkAwzPtB7ICAAA= Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 13:14:12 -0000 SGksDQoNCj5XZaGvcmUgYWdyZWVpbmcgdGhhdCB0aGVyZSBpcyBhIHJlbGF0aW9uc2hpcCBiZXR3 ZWVuIHRoZSBjb21tYW5kIGFuZCB0aGUNCj5kYXRhLg0KPg0KPldloa9yZSBzdWdnZXN0aW5nIHRo YXQgd2UgZG9uoa90IGhhdmUgdG8gYmUgYW5hbCBhYm91dCB0aGUgbGFuZ3VhZ2UgYW5kIGFzDQo+ bG9uZyBhcyB0aGVyZSBpcyBhbiBJTkZPIHBhY2thZ2UsIGFuZCBhIGJvZHkgcGFydCB0aGF0IGhh cyB0aGUgQUNLIHdoaWNoDQo+aXMgYW4gSU5GTyBib2R5IHBhcnQsIHRoYXQgdGhlIGNpdGVkIGxh bmd1YWdlIGRvZXNuoa90IGNvbXBlbCB1cyB0byB1c2UNCj50aGUgSU5GTyBib2R5IHBhcnQgdG8g dHJhbnNwb3J0IHRoZSBkYXRhLCB0aGUgQ2FsbC1JbmZvIG1lY2hhbmlzbSBpcw0KPmFjY2VwdGFi bGUuDQo+DQo+Tm8gb25lIGlzIHN1Z2dlc3RpbmcgdGhhdCB3ZSB1cGRhdGUgNjA4NiwgYW5kIHdl IGFncmVlIHRoYXQgNzg1MiBkaWQgbm90DQo+dXBkYXRlIDYwODYuICANCj4NCj5JdKGvcyBqdXN0 IHdoZXRoZXIgdGhhdCBsYW5ndWFnZSBwcm9oaWJpdHMgdXNlIG9mIHRoZSBDYWxsLUluZm8gdG8g Y2FycnkNCj50aGUgZGF0YSB3aGVuIGl0IHdhcyBwcm9tcHRlZCBieSB0aGUgSU5GTyBwYWNrYWdl IHJlcXVlc3QsIGFuZA0KPmFjY29tcGFuaWVzIHRoZSBJTkZPIHBhY2thZ2UgQUNLLg0KDQpZb3Ug c2VlbSB0byBzdWdnZXN0IHRoYXQsIGp1c3QgYmVjYXVzZSB5b3UgdXNlIGFuIEluZm8gUGFja2Fn ZSBmb3Igc2VuZGluZw0KU09NRSBvZiB0aGUgZWNhbGwgcmVsYXRlZCBpbmZvcm1hdGlvbiAodGhl IHJlcXVlc3QgYW5kIEFDSyksIHRoYXQgYWxsb3dzDQp5b3UgdG8gc2VuZCB0aGUgcmVzdCBvZiB0 aGUgZWNhbGwgcmVsYXRlZCBpbmZvcm1hdGlvbiAodGhlIGRhdGEgY29udGVudCkNCndpdGhvdXQg dXNpbmcgYW4gSW5mbyBQYWNrYWdlLiBJIHJlYWxseSBkb26hr3Qgc2VlIGhvdyB5b3UgY2FuIHBh cnNlIHRoZQ0KY2l0ZWQgdGV4dCBpbiB0aGF0IHdheS4gVGhlIGNpdGVkIHRleHQgc2F5cyB0aGF0 IGluZm9ybWF0aW9uIGFzc29jaWF0ZWQNCndpdGggdGhlIGFwcGxpY2F0aW9uIHNoYWxsIGJlIHNl bnQgdXNpbmcgYW4gSW5mbyBQYWNrYWdlLiBBbmQsIGJvdGggdGhlDQpBQ0sgYW5kIHRoZSByZXF1 ZXN0ZWQgZGF0YSBjb250ZW50IGFyZSBhc3NvY2lhdGVkIHdpdGggdGhlIGVjYWxsDQphcHBsaWNh dGlvbi4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCg0KDQo+DQo+QnJpYW4NCj4NCj4+ IE9uIEF1ZyAyNSwgMjAxNiwgYXQgMjowMCBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcNCj4+PGNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+PiANCj4+IEhpLA0KPj4gDQo+PiBJ qfZtIGdsYWQgdGhpcyBpcyBicm91Z2h0IHRvIFNJUENPUkUuIEFzIG9uZSBvZiB0aGUgaW5mbyBw YWNrYWdlDQo+PiBwcm9wb25lbnRzLCBwbGVhc2UgbGV0IG1lIGNsYXJpZnkgbXkgYXJndW1lbnRz Lg0KPj4gDQo+PiBUaGUgNjA4NiB0ZXh0IHRoYXQgQnJpYW4gY29waWVkIHNheXMgqfhidXQgYXJl IG5vdCBzcGVjaWZpY2FsbHkNCj4+YXNzb2NpYXRlZA0KPj4gd2l0aCB0aGUgSU5GTyBtZXRob2Qg YW5kIHRoZSBhcHBsaWNhdGlvbiBjb25jZXJuZWSp9y4NCj4+IA0KPj4gSSBjbGFpbSB0aGF0IHRo ZSB1cGRhdGVkIGRhdGEgSVMgYXNzb2NpYXRlZCB3aXRoIHRoZSBhcHBsaWNhdGlvbg0KPj5jb25j ZXJuZWQNCj4+IChlY2FsbCkuIFRoZSB1cGRhdGVkIGRhdGEgaXMgcmVxdWVzdGVkIGJ5IHRoZSBl Y2FsbCBhcHBsaWNhdGlvbiwgYW5kIHRoZQ0KPj4gZGVsaXZlcmVkIHVwZGF0ZWQgZGF0YSBpcyBj b25zdW1lZCBieSB0aGUgZWNhbGwgYXBwbGljYXRpb24uIFRoZSB1cGRhdGVkDQo+PiBkYXRhIGlz IE5PVCBzb21lIG5vbi1lY2FsbC1hcHBsaWNhdGlvbi1yZWxhdGVkIGluZm9ybWF0aW9uIHRoYXQg aXMNCj4+IHBpZ2d5YmFja2VkIGluIGEgImNvbnZlbmllbnQgSU5GTyBtZXNzYWdlIiB0aGF0IGhh cHBlbnMgdG8gYmUgc2VudCBieQ0KPj50aGUNCj4+IGVjYWxsIGFwcGxpY2F0aW9uIGZvciBzb21l IG90aGVyIHB1cnBvc2UuDQo+PiANCj4+IChJbiBhZGRpdGlvbiwgdGhlIHVwZGF0ZWQgZGF0YSBp cyBOT1QgYXNzb2NpYXRlZCB3aXRoIGEgbGVnYWN5DQo+PihwcmUtNjA4NikNCj4+IElORk8gdXNh Z2UsIHdoaWNoIGNvdWxkIGp1c3RpZnkgbm90IHVzaW5nIGFuIEluZm8gUGFja2FnZS4gSSBkbyB3 YW50IHRvDQo+PiBwb2ludCBvdXQgdGhhdCBub2JvZHkgaGFzIGNsYWltZWQgdGhhdCB0aGUgdXBk YXRlZCBkYXRhIHdvdWxkIGJlDQo+PiBhc3NvY2lhdGVkIHdpdGggbGVnYWN5IElORk8sIGJ1dCBq dXN0IGZvciBjb21wbGV0ZW5lc3MpDQo+PiANCj4+IFJGQyA3ODUyIGRvZXMgZGVmaW5lIGEgbWVj aGFuaXNtIGZvciB0cmFuc3BvcnRpbmcgZGF0YSwgdXNpbmcgQ2FsbC1JbmZvDQo+PiBldGMuIEJ1 dCwgNzg1MiBkb2VzIG5vdCB1cGRhdGUgNjA4Niwgbm9yIGNhbiA3ODUyIG92ZXJyaWRlIHJ1bGVz IGFuZA0KPj4gcHJvY2VkdXJlcyBhc3NvY2lhdGVkIHdpdGggaW5kaXZpZHVhbCBTSVAgbWV0aG9k cyAoSU5GTyBpbiB0aGlzIGNhc2UpLiBJDQo+PiBhbHNvIHBvaW50ZWQgdGhpcyBvdXQgYmVmb3Jl IDc4NTIgd2FzIHB1Ymxpc2hlZCwgYnV0IHdhcyB0b2xkIHRoYXQgaXSp9nMNCj4+IHRvbyBsYXRl IHRvIGNoYW5nZSBpdCAoZ3JhbnRlZCwgdGhlIGRyYWZ0IHdhcyBpbiB0aGUgUkZDIGVkaXRvcqn2 cw0KPj5xdWV1ZSkuDQo+PiANCj4+IEZpbmFsbHksIGFnYWluIGZvciBjb21wbGV0ZW5lc3MsIEkg d2FudCB0byBwb2ludCBvdXQgdGhhdCA2MDg2IGRvZXMgbm90DQo+PiBwcmV2ZW50IGluY2x1ZGlu ZyBDYWxsLUluZm8gaW4gSU5GTyBhcyBzdWNoLiBUaGUgaXNzdWUgaXMgaG93IHNvbWUgd2FudA0K Pj50bw0KPj4gdXNlIENhbGwtSW5mbyBpbnN0ZWFkIG9mIGFuIEluZm8gUGFja2FnZS4NCj4+IA0K Pj4gUmVnYXJkcywNCj4+IA0KPj4gQ2hyaXN0ZXINCj4+IA0KPj4gDQo+PiANCj4+IE9uIDI1LzA4 LzE2IDAzOjIyLCAic2lwY29yZSBvbiBiZWhhbGYgb2YgQnJpYW4gUm9zZW4iDQo+PiA8c2lwY29y ZS1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBickBicmlhbnJvc2VuLm5ldD4gd3JvdGU6 DQo+PiANCj4+PiBPdmVyIGluIGVjcml0IHdlIGhhdmUgYSBkaXNhZ3JlZW1lbnQgdGhhdCByZWxh dGVzIHRvIGludGVycHJldGluZw0KPj4+UkZDNjA4Ni4NCj4+PiANCj4+PiBCYWNrZ3JvdW5kOg0K Pj4+IFJGQzc4NTIgZGVmaW5lcyBzb21ldGhpbmcgY2FsbGVkICJBZGRpdGlvbmFsIERhdGEiLCB3 aGljaCBpcyBjYXJyaWVkIGluDQo+Pj4gZW1lcmdlbmN5IGNhbGwgc2lnbmFsaW5nLiAgSXQncyBk YXRhIHJlbGF0ZWQgdG8gdGhlIGNhbGwsIGUuZy4sIHRoZQ0KPj4+IGlkZW50aXR5IGFuZCBjb250 YWN0IGRhdGEgb2YgdGhlIHNlcnZpY2UgcHJvdmlkZXIgaGFuZGxpbmcgdGhlIGNhbGwuDQo+Pj4g QWRkaXRpb25hbCBEYXRhIGlzIHNpZ25hbGVkIHdpdGggYSBDYWxsLUluZm8gaGVhZGVyIGZpZWxk LCB3aGljaA0KPj4+Y29udGFpbnMNCj4+PiBlaXRoZXIgYSBVUkkgcG9pbnRpbmcgdG8gYSBkYXRh IGJsb2NrIGZldGNoZWQgd2l0aCBIVFRQUywgb3IgYSBDb250ZW50DQo+Pj4gSW5kaXJlY3QgcmVm ZXJlbmNpbmcgYSBib2R5IHBhcnQgb2YgdGhlIFNJUCBtZXNzYWdlLiAgSXQncyB1c3VhbGx5IHVz ZWQNCj4+PiBvbiB0aGUgSU5WSVRFIG9mIHRoZSBlbWVyZ2VuY3kgY2FsbCwgc28gaXQgY2FuIGJl IGRpc3BsYXllZCB0byB0aGUgUFNBUA0KPj4+IChlbWVyZ2VuY3kgY2FsbCBjZW50ZXIpIGNhbGwt dGFrZXIgd2hlbiB0aGUgY2FsbCBpcyBhc3NpZ25lZC4NCj4+PiANCj4+PiBTb21ldGltZXMsIHRo aXMgZGF0YSBjYW4gY2hhbmdlIGR1cmluZyBhIGNhbGwuICBUaGUgZXhhbXBsZSBpbg0KPj4+ZGlz Y3Vzc2lvbg0KPj4+IGlzIHRlbGVtYXRpY3MgZGF0YSBpbiBhIHZlaGljbGUuICAgVGhlIHZlaGlj bGUgY2FuIHJlcG9ydCB0aGluZ3MgbGlrZQ0KPj4+dGhlDQo+Pj4gbnVtYmVyIG9mIG9jY3VwYW50 cyBhbmQgaXRzIG9yaWVudGF0aW9uLiAgVGhlIFBTQVAgY2FuIHJlcXVlc3QgYW4NCj4+PnVwZGF0 ZQ0KPj4+IG1pZCBjYWxsIChlLmcuLCBpZiB0aGUgY2FsbCB0YWtlciB0aGlua3MgdGhpbmdzIG1p Z2h0IGhhdmUgY2hhbmdlZCkuDQo+Pj4gDQo+Pj4gSU5GTyBpcyB0aGUgY2hvc2VuIG1lY2hhbmlz bSB0byBzZW5kIHRoZSByZXF1ZXN0IGZvciB1cGRhdGUuICBUaGUNCj4+PmRldmljZQ0KPj4+IHdp bGwgc2VuZCBhIHJlc3BvbnNlIHRvIHRoZSByZXF1ZXN0IChhbiBBQ0spLCB3aGljaCBpcyBhbHNv IHNlbnQgaW4NCj4+PklORk8uDQo+Pj4gVGhpcyBjb25zdGl0dXRlcyBhIHdlbGwgZGVmaW5lZCBJ TkZPIHBhY2thZ2UsIGFuZCB3aWxsIGJlIHJlZ2lzdGVyZWQgaW4NCj4+PiB0aGUgdXN1YWwgd2F5 Lg0KPj4+IA0KPj4+IFRoZSBJc3N1ZSBhdCBoYW5kOg0KPj4+IFNvLCB0aGUgZGlzcHV0ZSBpcyBo b3cgdGhlIHVwZGF0ZWQgZGF0YSBpcyBzZW50IG1pZCBjYWxsLg0KPj4+IA0KPj4+IFJGQzYwODYg c2F5cw0KPj4+IA0KPj4+ICBOT1RFOiBBbiBJTkZPIHJlcXVlc3QgY2FuIGFsc28gY29udGFpbiBv dGhlciBib2R5IHBhcnRzIHRoYXQgYXJlDQo+Pj4gIG1lYW5pbmdmdWwgd2l0aGluIHRoZSBjb250 ZXh0IG9mIGFuIGludml0ZSBkaWFsb2cgdXNhZ2UgYnV0IGFyZQ0KPj4+ICBub3Qgc3BlY2lmaWNh bGx5IGFzc29jaWF0ZWQgd2l0aCB0aGUgSU5GTyBtZXRob2QgYW5kIHRoZQ0KPj4+ICBhcHBsaWNh dGlvbiBjb25jZXJuZWQuDQo+Pj4gDQo+Pj4gVGhlIGF1dGhvcnMgb2YgdGhlIGRyYWZ0IChvZiB3 aGljaCBJIGFtIG9uZSkgZGVzaXJlIHRvIHVzZSB0aGUNCj4+PkFkZGl0aW9uYWwNCj4+PiBEYXRh IG1lY2hhbmlzbSB0byBjYXJyeSB0aGUgdXBkYXRlZCBkYXRhLiAgVGhlIGRhdGEgY291bGQgYmUg c2VudCBpbg0KPj4+YW55DQo+Pj4gY29udmVuaWVudCBtZXNzYWdlLCBhbHRob3VnaCBzaW5jZSB0 aGUgdmVoaWNsZSBpcyBzZW5kaW5nIGFuIEFDSywgaXQncw0KPj4+IGxpa2VseSBnb2luZyB0byBn byBvbiB0aGF0LiAgV2UnZCBsaWtlIHRvIGFsd2F5cyBjYXJyeSB0aGUgZGF0YSBpbiB0aGUNCj4+ PiBzYW1lIHdheS4gIEluIGFuIElORk8gbWVzc2FnZSBpdCB3b3VsZCBiZSBjYXJyaWVkIHRoZSBz YW1lIGFzIGl0IGlzIGluDQo+Pj4gdGhlIElOVklURSwgYXMgQWRkaXRpb25hbCBEYXRhLiAgU2lu Y2UgdGhlIElORk8gY2FycmllcyBhbiBBQ0ssIGl0DQo+Pj53b3VsZA0KPj4+IHNwZWNpZnkgdGhl IGFwcHJvcHJpYXRlIElORk8gcGFja2FnZSwgYW5kIHdvdWxkIGNvbnRhaW4gYSBib2R5IHBhcnQN Cj4+PndpdGgNCj4+PiB0aGUgQUNLLiAgVGhlcmUgd291bGQgYmUgYW5vdGhlciBib2R5IHBhcnQg Zm9yIHRoZSB1cGRhdGVkIGRhdGEsDQo+Pj5wb2ludGVkDQo+Pj4gdG8gYnkgdGhlIENhbGwtSW5m by4NCj4+PiANCj4+PiBTb21lIGVjcml0IHBhcnRpY2lwYW50cyBzYXkgdGhhdCB0aGUgYWJvdmUg bGFuZ3VhZ2Ugb2YgNjA4NiB3b3VsZA0KPj4+IHByb2hpYml0IHRoZSBJTkZPIGZyb20gY29udGFp bmluZyBhIENhbGwtSW5mbyBoZWFkZXIgd2l0aCBhIENJRA0KPj4+cG9pbnRpbmcNCj4+PiB0byBh IE1JTUUgYm9keSBwYXJ0LCBiZWNhdXNlIHRoZSBkYXRhIHdhcyByZXF1ZXN0ZWQgYnkgYW4gSU5G TywgYW5kDQo+Pj5oZW5jZQ0KPj4+IGlzIHJlbGF0ZWQgdG8gdGhlIElORk8gcGFja2FnZS4gIFRo ZXkgc2F5IHRoYXQgdGhlIGRhdGEgTVVTVCBiZSBjYXJyaWVkDQo+Pj4gd2l0aCBhIGJvZHkgcGFy dCBhbmQgQ29udGVudCBEaXNwb3NpdGlvbiB0aGF0IGlzIHBhcnQgb2YgdGhlIElORk8NCj4+PnBh Y2thZ2UNCj4+PiBkZWZpbml0aW9uLg0KPj4+IA0KPj4+IFRoZSBkcmFmdCBhdXRob3JzIGNsYWlt IHRoaXMgNjA4NiBsYW5ndWFnZSBpc24ndCBhIHN0cmFpZ2h0amFja2V0LCBhbmQNCj4+PiBpdCdz IHBlcmZlY3RseSBmaW5lIHRvIGNhcnJ5IHRoZSBkYXRhIHJlZmVyZW5jZWQgYnkgYSBDYWxsLUlu Zm8gd2l0aCBhDQo+Pj4gQ29udGVudCBJbmRpcmVjdCBib2R5IHBhcnQgdXNpbmcgdGhlIHNhbWUg TUlNRSB0eXBlIGFuZCBDb250ZW50DQo+Pj4gRGlzcG9zaXRpb24gYXMgaXQgd291bGQgaW4gYW4g SU5WSVRFLiAgIFdoZW4gdGhlIHVwZGF0ZWQgZGF0YSBpcyBzZW50DQo+Pj5pbg0KPj4+IElORk8s IGl0J3MgYmVjYXVzZSB0aGUgSU5GTyBpcyBhIGNvbnZlbmllbnQgbWVzc2FnZSAoc2luY2UgaXQn cyBiZWluZw0KPj4+IHNlbnQgdG8gY2FycnkgdGhlIEFDSykuDQo+Pj4gDQo+Pj4gTWVjaGFuaWNh bGx5LCBib3RoIG1lY2hhbmlzbXMgY2FuIGJlIG1hZGUgdG8gd29yay4gIFRoZSBib2R5IHBhcnRz DQo+Pj53b3VsZA0KPj4+IGJlIGxhYmVsZWQgYXBwcm9wcmlhdGVseSBhbmQgdGhlcmUgd291bGQg YmUgbm8gY29uZnVzaW9uIGFib3V0IHdoYXQNCj4+PnRoZXkNCj4+PiBtZWFuIG9yIGhvdyB0aGV5 IHdvdWxkIGJlIGludGVycHJldGVkLiAgSXQncyByZWFsbHkgb25seSB3aGV0aGVyIHRoZQ0KPj4+ IENhbGwtSW5mbyBoZWFkZXIgaXMgcHJlc2VudCBhbmQgd2hhdCB0aGUgTUlNRSB0eXBlIGFuZCBD b250ZW50DQo+Pj4gRGlzcG9zaXRpb24gdGhlIGJvZHkgcGFydCBjb250YWluaW5nIHRoZSBkYXRh IHdvdWxkIGJlLiAgSW4gdGhlDQo+Pj5hdXRob3Incw0KPj4+IHByZWZlcnJlZCB3YXksIGl0IHdv dWxkIGJlIHRoZSBNSU1FIHR5cGUgYW5kIENvbnRlbnQgRGlzcG9zaXRpb24gb2YgdGhlDQo+Pj4g Q2FsbC1JbmZvIGFuZCBpbiB0aGUgb3RoZXIgcG9pbnQgb2YgdmlldyBpdCB3b3VsZCBiZSB0aGUg TUlNRSB0eXBlIGFuZA0KPj4+IENvbnRlbnQgRGlzcG9zaXRpb24gb2YgdGhlIElORk8gcGFja2Fn ZS4NCj4+PiANCj4+PiBQbGVhc2UgaWdub3JlIHlvdXIgcGVyc29uYWwgcHJlZmVyZW5jZSBmb3Ig d2hldGhlciB5b3UgdGhpbmsgaXQgb3VnaHQNCj4+PnRvDQo+Pj4gZ28gaW4gdGhlIElORk8gb3Ig bm90LCBhbmQgcGxlYXNlIGhlbHAgdXMgaW50ZXJwcmV0IDYwODY6IGRvZXMgdGhlIGRhdGENCj4+ PiBIQVZFIHRvIGdvIGluIGFuIElORk8gYm9keSBwYXJ0IG9yIGNhbiBpdCBiZSBzZW50IGluIGEg Q2FsbC1JbmZvIGJvZHkNCj4+PiBwYXJ0Pw0KPj4+IA0KPj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4+ PiBzaXBjb3JlQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zaXBjb3JlDQo+PiANCj4NCg0K From nobody Thu Aug 25 06:26:44 2016 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 9061E12B076 for ; Thu, 25 Aug 2016 06:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5yC2SbkM66L for ; Thu, 25 Aug 2016 06:26:41 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D53E12B03D for ; Thu, 25 Aug 2016 06:26:41 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id l2so45251680qkf.3 for ; Thu, 25 Aug 2016 06:26:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fji0MZsDj4Hyjcmq/wA5XShIbPhrU9RPk9v1pSDQiP8=; b=FEMFDMstcgNLQEtfALP6my5GaP5dpZX/YUZJNupGCQbAPv0oIPD2N1+d+LGw5wEiDt HCKUJskD187RCgECikpag7wuvcMZESYnHhyAIIQ6AGFb2gbgpg2FGMGjB849A4WMXyOQ RrhUnMpOFQVesm9Wh+eqeAeIN8gb+Fh/QVKFhX4x9HTvLVV+CpfVqMFZ60OKR1+e8msB jxcMcYSRDmw/iBNYKgjtg+jUGo8z7CAfw8/89CjpeqT3tY1r1mkS/HSgahFzEc+uaMWq baoH57DOSktrU/ic02YSRvGgUezQV41Ba7OvG8zTN3VeyIQUDDpvPsOyml8rAVbizzZX +LDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fji0MZsDj4Hyjcmq/wA5XShIbPhrU9RPk9v1pSDQiP8=; b=YN+wdybiP2v8A9njVduTWR0TyxYvzsa4HG4KvUC1fNFxiEiBldOBPqkfNWesUtbjh/ 817LrWHlzDve+sIVkCkhT9NQXnW1+7ZJmDUcBT7WdIbuxRdsUmXGIV1EKpVXZUF9uNMX AoFUBQw2P5bFOnnuyILjI0zUUEz2Wa7hWDtWZ7jmPITrq9Kz6FYkbwRJwyZt9u5KY8/O i9qbk5dSeMAvc1VQ/omiT41T/t2JQREEyoLcFPIPVOrJ2IMVVkik+hHwe6UybTPJvGTp yxOd5sxyCmgAvwMgCoKUriGA2UJ9EhulHhQjDGHhP6lV4g3xb1MoEolSBdS1X75eQZse 0SDA== X-Gm-Message-State: AE9vXwPSvM0u2eQHgtfznACp5EoC/DY3tHHEeGT7KREf4LvhfR65/OILth4qTVZXTGq7TA== X-Received: by 10.55.126.194 with SMTP id z185mr9903783qkc.140.1472131595303; Thu, 25 Aug 2016 06:26:35 -0700 (PDT) Received: from [10.33.192.33] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id 6sm7604204qke.5.2016.08.25.06.26.34 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 25 Aug 2016 06:26:34 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: Date: Thu, 25 Aug 2016 09:26:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <76CCBFA5-8D53-4B1E-A495-4A18AB081384@brianrosen.net> <05240A95-8319-4555-8B46-FA18B6C27883@brianrosen.net> To: Christer Holmberg X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 13:26:43 -0000 Yes, I=E2=80=99m saying that the ACK satisfies the 6086 use of INFO, and = that it=E2=80=99s okay to send the data with Call-Info. Yes, I=E2=80=99m agreeing that there is a relationship between the INFO = package and the data. Yes, I=E2=80=99m disagreeing with your interpretation of the language. So, now, what say you sipcore? Brian > On Aug 25, 2016, at 9:14 AM, Christer Holmberg = wrote: >=20 > Hi, >=20 >> We=E2=80=99re agreeing that there is a relationship between the = command and the >> data. >>=20 >> We=E2=80=99re suggesting that we don=E2=80=99t have to be anal about = the language and as >> long as there is an INFO package, and a body part that has the ACK = which >> is an INFO body part, that the cited language doesn=E2=80=99t compel = us to use >> the INFO body part to transport the data, the Call-Info mechanism is >> acceptable. >>=20 >> No one is suggesting that we update 6086, and we agree that 7852 did = not >> update 6086. =20 >>=20 >> It=E2=80=99s just whether that language prohibits use of the = Call-Info to carry >> the data when it was prompted by the INFO package request, and >> accompanies the INFO package ACK. >=20 > You seem to suggest that, just because you use an Info Package for = sending > SOME of the ecall related information (the request and ACK), that = allows > you to send the rest of the ecall related information (the data = content) > without using an Info Package. I really don=E2=80=99t see how you can = parse the > cited text in that way. The cited text says that information = associated > with the application shall be sent using an Info Package. And, both = the > ACK and the requested data content are associated with the ecall > application. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >>=20 >> Brian >>=20 >>> On Aug 25, 2016, at 2:00 AM, Christer Holmberg >>> wrote: >>>=20 >>> Hi, >>>=20 >>> I=C2=B9m glad this is brought to SIPCORE. As one of the info package >>> proponents, please let me clarify my arguments. >>>=20 >>> The 6086 text that Brian copied says =C2=B3but are not specifically >>> associated >>> with the INFO method and the application concerned=C2=B2. >>>=20 >>> I claim that the updated data IS associated with the application >>> concerned >>> (ecall). The updated data is requested by the ecall application, and = the >>> delivered updated data is consumed by the ecall application. The = updated >>> data is NOT some non-ecall-application-related information that is >>> piggybacked in a "convenient INFO message" that happens to be sent = by >>> the >>> ecall application for some other purpose. >>>=20 >>> (In addition, the updated data is NOT associated with a legacy >>> (pre-6086) >>> INFO usage, which could justify not using an Info Package. I do want = to >>> point out that nobody has claimed that the updated data would be >>> associated with legacy INFO, but just for completeness) >>>=20 >>> RFC 7852 does define a mechanism for transporting data, using = Call-Info >>> etc. But, 7852 does not update 6086, nor can 7852 override rules and >>> procedures associated with individual SIP methods (INFO in this = case). I >>> also pointed this out before 7852 was published, but was told that = it=C2=B9s >>> too late to change it (granted, the draft was in the RFC editor=C2=B9s= >>> queue). >>>=20 >>> Finally, again for completeness, I want to point out that 6086 does = not >>> prevent including Call-Info in INFO as such. The issue is how some = want >>> to >>> use Call-Info instead of an Info Package. >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>>=20 >>>=20 >>> On 25/08/16 03:22, "sipcore on behalf of Brian Rosen" >>> wrote: >>>=20 >>>> Over in ecrit we have a disagreement that relates to interpreting >>>> RFC6086. >>>>=20 >>>> Background: >>>> RFC7852 defines something called "Additional Data", which is = carried in >>>> emergency call signaling. It's data related to the call, e.g., the >>>> identity and contact data of the service provider handling the = call. >>>> Additional Data is signaled with a Call-Info header field, which >>>> contains >>>> either a URI pointing to a data block fetched with HTTPS, or a = Content >>>> Indirect referencing a body part of the SIP message. It's usually = used >>>> on the INVITE of the emergency call, so it can be displayed to the = PSAP >>>> (emergency call center) call-taker when the call is assigned. >>>>=20 >>>> Sometimes, this data can change during a call. The example in >>>> discussion >>>> is telematics data in a vehicle. The vehicle can report things = like >>>> the >>>> number of occupants and its orientation. The PSAP can request an >>>> update >>>> mid call (e.g., if the call taker thinks things might have = changed). >>>>=20 >>>> INFO is the chosen mechanism to send the request for update. The >>>> device >>>> will send a response to the request (an ACK), which is also sent in >>>> INFO. >>>> This constitutes a well defined INFO package, and will be = registered in >>>> the usual way. >>>>=20 >>>> The Issue at hand: >>>> So, the dispute is how the updated data is sent mid call. >>>>=20 >>>> RFC6086 says >>>>=20 >>>> NOTE: An INFO request can also contain other body parts that are >>>> meaningful within the context of an invite dialog usage but are >>>> not specifically associated with the INFO method and the >>>> application concerned. >>>>=20 >>>> The authors of the draft (of which I am one) desire to use the >>>> Additional >>>> Data mechanism to carry the updated data. The data could be sent = in >>>> any >>>> convenient message, although since the vehicle is sending an ACK, = it's >>>> likely going to go on that. We'd like to always carry the data in = the >>>> same way. In an INFO message it would be carried the same as it is = in >>>> the INVITE, as Additional Data. Since the INFO carries an ACK, it >>>> would >>>> specify the appropriate INFO package, and would contain a body part >>>> with >>>> the ACK. There would be another body part for the updated data, >>>> pointed >>>> to by the Call-Info. >>>>=20 >>>> Some ecrit participants say that the above language of 6086 would >>>> prohibit the INFO from containing a Call-Info header with a CID >>>> pointing >>>> to a MIME body part, because the data was requested by an INFO, and >>>> hence >>>> is related to the INFO package. They say that the data MUST be = carried >>>> with a body part and Content Disposition that is part of the INFO >>>> package >>>> definition. >>>>=20 >>>> The draft authors claim this 6086 language isn't a straightjacket, = and >>>> it's perfectly fine to carry the data referenced by a Call-Info = with a >>>> Content Indirect body part using the same MIME type and Content >>>> Disposition as it would in an INVITE. When the updated data is = sent >>>> in >>>> INFO, it's because the INFO is a convenient message (since it's = being >>>> sent to carry the ACK). >>>>=20 >>>> Mechanically, both mechanisms can be made to work. The body parts >>>> would >>>> be labeled appropriately and there would be no confusion about what >>>> they >>>> mean or how they would be interpreted. It's really only whether = the >>>> Call-Info header is present and what the MIME type and Content >>>> Disposition the body part containing the data would be. In the >>>> author's >>>> preferred way, it would be the MIME type and Content Disposition of = the >>>> Call-Info and in the other point of view it would be the MIME type = and >>>> Content Disposition of the INFO package. >>>>=20 >>>> Please ignore your personal preference for whether you think it = ought >>>> to >>>> go in the INFO or not, and please help us interpret 6086: does the = data >>>> HAVE to go in an INFO body part or can it be sent in a Call-Info = body >>>> part? >>>>=20 >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>=20 >>=20 >=20 From nobody Thu Aug 25 06:47:28 2016 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 741AB12D0BB for ; Thu, 25 Aug 2016 06:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHaoT6Qj-plW for ; Thu, 25 Aug 2016 06:47:26 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B27412B068 for ; Thu, 25 Aug 2016 06:47:26 -0700 (PDT) Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-01v.sys.comcast.net with SMTP id cuzMbSTaMTaLwcv09b3h85; Thu, 25 Aug 2016 13:47:25 +0000 Received: from hobgoblin.ariadne.com ([73.100.16.189]) by resomta-ch2-11v.sys.comcast.net with SMTP id cv08bxcfOuiLEcv09bcDhm; Thu, 25 Aug 2016 13:47:25 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u7PDlObr022756; Thu, 25 Aug 2016 09:47:24 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u7PDlOX4022753; Thu, 25 Aug 2016 09:47:24 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Brian Rosen In-Reply-To: <76CCBFA5-8D53-4B1E-A495-4A18AB081384@brianrosen.net> Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 25 Aug 2016 09:47:23 -0400 Message-ID: <8737ltvu38.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfDasyp50myQ3jua68bQojayBRHbjgimwugLrK1G3OjSsgFMlr+rur/3ZaSR//8wNCPblXn7xhp0gC8tjba7LOmN12dJBDbtM505nlq327ISG42Ya6+1E SOmJGHs4IplfxyzjAB9Y6ZCSjExw3aqJylZs+edNrXAbtxZOL9E2sWR10/X/OIVLzI9Aw/so+N3f23VsxfyGooRYZ6gdXlckWLg= Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 13:47:27 -0000 Brian Rosen writes: > INFO is the chosen mechanism to send the request for update. The > device will send a response to the request (an ACK), which is also > sent in INFO. This constitutes a well defined INFO package, and will > be registered in the usual way. Interesting. I would have expected the update (and effectively the ACK) to be in the response to the INFO request. Presumably there's a reason that doesn't work. Dale From nobody Thu Aug 25 06:56:38 2016 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 D7B6512D13A for ; Thu, 25 Aug 2016 06:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDW52uGCM06P for ; Thu, 25 Aug 2016 06:56:34 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77D6312D0C7 for ; Thu, 25 Aug 2016 06:56:34 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id z190so46139881qkc.0 for ; Thu, 25 Aug 2016 06:56:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aB9yBWwAJdB58QfZspQ8I8oPbiGdXA3YpoYMV6yA32U=; b=T2KQxGsdLULgavR7Qot/6iN4SPsKSO+589ecVLnbCmk/FQB34Lh8nE8kKoGIfd0/W/ wn6xqRAgn/IwLOD/5ZSxteDtvTp234RxBVf3ndxTQE72Bu3W/0m4s6+e6u0uxOaOpXGI QELWhMjYq0YZQWTUniUZFSvYXvmvnlfvSSyVgTmXvQGjIsvHhkeBLhYGIKHZQJAcl+as lMkUKpWU9mjRUi0LOynH+rukgFyBCgSWoQdwOL034sLU/TETER2VHSkf9GWOJ8PBrStl yJOSgjOUUhuw+6V00TYKxMQWsJlz2+GCeTIRQLPYR43FUHF7fX9Jzc5qMIZbKEZUXHeL Ib3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aB9yBWwAJdB58QfZspQ8I8oPbiGdXA3YpoYMV6yA32U=; b=TYX1K3f5UyY9RNVJFd0pRcYvQhDt792RJis9Qo+GFkW/5RAtoJB/d0Yx3jSxryAzOY uPPtNCN/UXtKYiA9Y/ivHuR2UHlAWkH8IwCiOO0Kt6DvVC8LSkB+GkRhUGVI5ePbaj6U XFBW/sUMas1fSmpcBmulVvO1rdL2LHR+y2DYgVKZ+uF0XqWWSk55eHYf5juU0rGAqz27 tJXnZ2tCEyHp9kVvwOEoUCpafmmAAmHNU4gdtQVBw43SYmV9ckUEEbmq+A9t/TAycYoo 5reem0psYX40pRLiZ4gSIY7RyDeTS2ao7dLGWaGz2m2nTelC0QQMswlcLR/P6KIer3RJ FtoQ== X-Gm-Message-State: AE9vXwOh4Exq43gShERo27kt8Rai7uev7cJ6ibtLsDCPp5SjtKm1LoQGGWqT9J9w+o1Vog== X-Received: by 10.55.120.2 with SMTP id t2mr9822717qkc.62.1472133393654; Thu, 25 Aug 2016 06:56:33 -0700 (PDT) Received: from [10.33.192.33] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id t15sm7635075qtc.26.2016.08.25.06.56.32 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 25 Aug 2016 06:56:33 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: <8737ltvu38.fsf@hobgoblin.ariadne.com> Date: Thu, 25 Aug 2016 09:56:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8737ltvu38.fsf@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 13:56:36 -0000 I believe there can be a time delay between asking for it and getting = the data. For the moment, that=E2=80=99s not germane, although the data = could come in the response to the INFO. The same issues would apply. Do you think the language in 6086 prohibits the data to come in a = Call-Info body part, whether in an INFO or a response to an INFO? Brian > On Aug 25, 2016, at 9:47 AM, Dale R. Worley = wrote: >=20 > Brian Rosen writes: >> INFO is the chosen mechanism to send the request for update. The >> device will send a response to the request (an ACK), which is also >> sent in INFO. This constitutes a well defined INFO package, and will >> be registered in the usual way. >=20 > Interesting. I would have expected the update (and effectively the = ACK) > to be in the response to the INFO request. Presumably there's a = reason > that doesn't work. >=20 > Dale From nobody Thu Aug 25 07:32:40 2016 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 17DA012D850 for ; Thu, 25 Aug 2016 07:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blNdud2nWg88 for ; Thu, 25 Aug 2016 07:32:36 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 465BA12D85A for ; Thu, 25 Aug 2016 07:32:22 -0700 (PDT) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-08v.sys.comcast.net with SMTP id cvhDbcPm984vjcvhdbnpz2; Thu, 25 Aug 2016 14:32:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-13v.sys.comcast.net with SMTP id cvhcbQc22dRgOcvhdbb5ll; Thu, 25 Aug 2016 14:32:21 +0000 To: sipcore@ietf.org References: <76CCBFA5-8D53-4B1E-A495-4A18AB081384@brianrosen.net> <05240A95-8319-4555-8B46-FA18B6C27883@brianrosen.net> From: Paul Kyzivat Message-ID: <5d462933-e3c0-b3a3-958d-5c9d1e86d854@alum.mit.edu> Date: Thu, 25 Aug 2016 10:32:20 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfFxwm0cTiP61NfqWDsPBr6mCy4MrXnRl/sfQvrrgf5slB0huB2xeU3NsT/EGdvt1fmEfWN03THx9yjEje0hSnoey44BTGiqV7/QM64r9CvVGQuc2yJmp FymJeSVQDOlSLV1knbwFrvqgntbCdqWEuDYyEQV1W/8WBZehYB09X8YK5yzKKrSwoYt0XP0TltykjA== Archived-At: Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 14:32:38 -0000 On 8/25/16 9:26 AM, Brian Rosen wrote: > Yes, I’m saying that the ACK satisfies the 6086 use of INFO, and that it’s okay to send the data with Call-Info. > > Yes, I’m agreeing that there is a relationship between the INFO package and the data. > > Yes, I’m disagreeing with your interpretation of the language. > > So, now, what say you sipcore? I think the main point of bringing this to sipcore is to get some fresh input into this discussion. Since I have been party to the discussion over in ecrit I don't bring anything fresh here. But for completeness I will register my opinion here too. IMO this is not a question about whether the proposed usage is valid according to 6086 and other rfcs. (I think it is quite clear that it *is* valid.) Rather this is simply a question of what is the best design for the desired functionality. As such I don't think it really needs to be settled in sipcore. But I am happy to check if anybody has a different perspective on this. Thanks, Paul > Brian > > >> On Aug 25, 2016, at 9:14 AM, Christer Holmberg wrote: >> >> Hi, >> >>> We’re agreeing that there is a relationship between the command and the >>> data. >>> >>> We’re suggesting that we don’t have to be anal about the language and as >>> long as there is an INFO package, and a body part that has the ACK which >>> is an INFO body part, that the cited language doesn’t compel us to use >>> the INFO body part to transport the data, the Call-Info mechanism is >>> acceptable. >>> >>> No one is suggesting that we update 6086, and we agree that 7852 did not >>> update 6086. >>> >>> It’s just whether that language prohibits use of the Call-Info to carry >>> the data when it was prompted by the INFO package request, and >>> accompanies the INFO package ACK. >> >> You seem to suggest that, just because you use an Info Package for sending >> SOME of the ecall related information (the request and ACK), that allows >> you to send the rest of the ecall related information (the data content) >> without using an Info Package. I really don’t see how you can parse the >> cited text in that way. The cited text says that information associated >> with the application shall be sent using an Info Package. And, both the >> ACK and the requested data content are associated with the ecall >> application. >> >> Regards, >> >> Christer >> >> >> >> >> >>> >>> Brian >>> >>>> On Aug 25, 2016, at 2:00 AM, Christer Holmberg >>>> wrote: >>>> >>>> Hi, >>>> >>>> I¹m glad this is brought to SIPCORE. As one of the info package >>>> proponents, please let me clarify my arguments. >>>> >>>> The 6086 text that Brian copied says ³but are not specifically >>>> associated >>>> with the INFO method and the application concerned². >>>> >>>> I claim that the updated data IS associated with the application >>>> concerned >>>> (ecall). The updated data is requested by the ecall application, and the >>>> delivered updated data is consumed by the ecall application. The updated >>>> data is NOT some non-ecall-application-related information that is >>>> piggybacked in a "convenient INFO message" that happens to be sent by >>>> the >>>> ecall application for some other purpose. >>>> >>>> (In addition, the updated data is NOT associated with a legacy >>>> (pre-6086) >>>> INFO usage, which could justify not using an Info Package. I do want to >>>> point out that nobody has claimed that the updated data would be >>>> associated with legacy INFO, but just for completeness) >>>> >>>> RFC 7852 does define a mechanism for transporting data, using Call-Info >>>> etc. But, 7852 does not update 6086, nor can 7852 override rules and >>>> procedures associated with individual SIP methods (INFO in this case). I >>>> also pointed this out before 7852 was published, but was told that it¹s >>>> too late to change it (granted, the draft was in the RFC editor¹s >>>> queue). >>>> >>>> Finally, again for completeness, I want to point out that 6086 does not >>>> prevent including Call-Info in INFO as such. The issue is how some want >>>> to >>>> use Call-Info instead of an Info Package. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> On 25/08/16 03:22, "sipcore on behalf of Brian Rosen" >>>> wrote: >>>> >>>>> Over in ecrit we have a disagreement that relates to interpreting >>>>> RFC6086. >>>>> >>>>> Background: >>>>> RFC7852 defines something called "Additional Data", which is carried in >>>>> emergency call signaling. It's data related to the call, e.g., the >>>>> identity and contact data of the service provider handling the call. >>>>> Additional Data is signaled with a Call-Info header field, which >>>>> contains >>>>> either a URI pointing to a data block fetched with HTTPS, or a Content >>>>> Indirect referencing a body part of the SIP message. It's usually used >>>>> on the INVITE of the emergency call, so it can be displayed to the PSAP >>>>> (emergency call center) call-taker when the call is assigned. >>>>> >>>>> Sometimes, this data can change during a call. The example in >>>>> discussion >>>>> is telematics data in a vehicle. The vehicle can report things like >>>>> the >>>>> number of occupants and its orientation. The PSAP can request an >>>>> update >>>>> mid call (e.g., if the call taker thinks things might have changed). >>>>> >>>>> INFO is the chosen mechanism to send the request for update. The >>>>> device >>>>> will send a response to the request (an ACK), which is also sent in >>>>> INFO. >>>>> This constitutes a well defined INFO package, and will be registered in >>>>> the usual way. >>>>> >>>>> The Issue at hand: >>>>> So, the dispute is how the updated data is sent mid call. >>>>> >>>>> RFC6086 says >>>>> >>>>> NOTE: An INFO request can also contain other body parts that are >>>>> meaningful within the context of an invite dialog usage but are >>>>> not specifically associated with the INFO method and the >>>>> application concerned. >>>>> >>>>> The authors of the draft (of which I am one) desire to use the >>>>> Additional >>>>> Data mechanism to carry the updated data. The data could be sent in >>>>> any >>>>> convenient message, although since the vehicle is sending an ACK, it's >>>>> likely going to go on that. We'd like to always carry the data in the >>>>> same way. In an INFO message it would be carried the same as it is in >>>>> the INVITE, as Additional Data. Since the INFO carries an ACK, it >>>>> would >>>>> specify the appropriate INFO package, and would contain a body part >>>>> with >>>>> the ACK. There would be another body part for the updated data, >>>>> pointed >>>>> to by the Call-Info. >>>>> >>>>> Some ecrit participants say that the above language of 6086 would >>>>> prohibit the INFO from containing a Call-Info header with a CID >>>>> pointing >>>>> to a MIME body part, because the data was requested by an INFO, and >>>>> hence >>>>> is related to the INFO package. They say that the data MUST be carried >>>>> with a body part and Content Disposition that is part of the INFO >>>>> package >>>>> definition. >>>>> >>>>> The draft authors claim this 6086 language isn't a straightjacket, and >>>>> it's perfectly fine to carry the data referenced by a Call-Info with a >>>>> Content Indirect body part using the same MIME type and Content >>>>> Disposition as it would in an INVITE. When the updated data is sent >>>>> in >>>>> INFO, it's because the INFO is a convenient message (since it's being >>>>> sent to carry the ACK). >>>>> >>>>> Mechanically, both mechanisms can be made to work. The body parts >>>>> would >>>>> be labeled appropriately and there would be no confusion about what >>>>> they >>>>> mean or how they would be interpreted. It's really only whether the >>>>> Call-Info header is present and what the MIME type and Content >>>>> Disposition the body part containing the data would be. In the >>>>> author's >>>>> preferred way, it would be the MIME type and Content Disposition of the >>>>> Call-Info and in the other point of view it would be the MIME type and >>>>> Content Disposition of the INFO package. >>>>> >>>>> Please ignore your personal preference for whether you think it ought >>>>> to >>>>> go in the INFO or not, and please help us interpret 6086: does the data >>>>> HAVE to go in an INFO body part or can it be sent in a Call-Info body >>>>> part? >>>>> >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>> >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Thu Aug 25 07:58:11 2016 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 D359712D142 for ; Thu, 25 Aug 2016 07:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLSs5t-gRGhb for ; Thu, 25 Aug 2016 07:58:08 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB81E12D0F9 for ; Thu, 25 Aug 2016 07:58:07 -0700 (PDT) X-AuditID: c1b4fb2d-917ff700000019a3-96-57bf077da5d1 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by (Symantec Mail Security) with SMTP id 7D.99.06563.D770FB75; Thu, 25 Aug 2016 16:58:06 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0301.000; Thu, 25 Aug 2016 16:58:05 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? Thread-Index: AQHR/t2KCnVeSlQa/k+Sxwkc4yebnqBZxASQ Date: Thu, 25 Aug 2016 14:58:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC60A10@ESESSMB209.ericsson.se> References: <76CCBFA5-8D53-4B1E-A495-4A18AB081384@brianrosen.net> <05240A95-8319-4555-8B46-FA18B6C27883@brianrosen.net> <5d462933-e3c0-b3a3-958d-5c9d1e86d854@alum.mit.edu> In-Reply-To: <5d462933-e3c0-b3a3-958d-5c9d1e86d854@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM2J7lG4d+/5wg65J/BYrNhxgtfj6YxOb A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJWx6OI+poKGtIrtna8ZGxg3JHcxcnJICJhI 3JvWyQhiCwmsZ5RY87Gmi5ELyF7CKNH8+glzFyMHB5uAhUT3P22QGhGBQImrSyYwg9jCAokS E/rmMkPEkyTmbNoDZRtJPNi/mB3EZhFQleiZ9wVsPq+Ar8SNRzeZIOZ/ZpI4uRkiwSngIHH5 wgUwm1FATOL7qTVMIDazgLjErSfzmSAOFZBYsuc8M4QtKvHy8T9WCFtJYsX2S4wgdzILaEqs 36UP0aooMaX7ITvEXkGJkzOfsExgFJmFZOoshI5ZSDpmIelYwMiyilG0OLW4ODfdyFgvtSgz ubg4P08vL7VkEyMwFg5u+a27g3H1a8dDjAIcjEo8vAse7A0XYk0sK67MPcQowcGsJMK7n2V/ uBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFe/5eK4UIC6YklqdmpqQWpRTBZJg5OqQZGNxZJBeGE QP2X+/Vmf2gW7pnGc6nr1CVvOaZ2t1elNWzljx65+bjN/rPo4vIExwq3/Eszs+V87KsVHjU2 fDUyjWqs8amQFMxVjemcFaixTeS/z6WsO4+OvAqv9bpzKNb+skOX+MdrBT+m/jDVYt9xg41L au80Fd6D7HevTt91zaS6SqAnJlKJpTgj0VCLuag4EQCmNqA8gQIAAA== Archived-At: Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 14:58:10 -0000 UGF1bCwgYSBnZW5lcmljIHF1ZXN0aW9uLCB3aGljaCBtaWdodCBoZWxwIG1lIHVuZGVyc3RhbmQg eW91ciB2aWV3IG9uIGVjYWxsOiBpbiB5b3VyIG9waW5pb24sIHdoZW4gKGlmIGV2ZXIpIGlzIHVz YWdlIG9mIGFuIEluZm8gUGFja2FnZSByZXF1aXJlZD8NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXIN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHNpcGNvcmUgW21haWx0bzpzaXBj b3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQYXVsIEt5eml2YXQNClNlbnQ6IDI1 IEF1Z3VzdCAyMDE2IDE3OjMyDQpUbzogc2lwY29yZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtz aXBjb3JlXSBDYW4gYW4gSU5GTyBjb250YWluIGEgYm9keSByZWxhdGVkIHRvLCBidXQgbm90IHBh cnQgb2YgdGhlIElORk8gcGFja2FnZT8NCg0KT24gOC8yNS8xNiA5OjI2IEFNLCBCcmlhbiBSb3Nl biB3cm90ZToNCj4gWWVzLCBJ4oCZbSBzYXlpbmcgdGhhdCB0aGUgQUNLIHNhdGlzZmllcyB0aGUg NjA4NiB1c2Ugb2YgSU5GTywgYW5kIHRoYXQgaXTigJlzIG9rYXkgdG8gc2VuZCB0aGUgZGF0YSB3 aXRoIENhbGwtSW5mby4NCj4NCj4gWWVzLCBJ4oCZbSBhZ3JlZWluZyB0aGF0IHRoZXJlIGlzIGEg cmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIElORk8gcGFja2FnZSBhbmQgdGhlIGRhdGEuDQo+DQo+ IFllcywgSeKAmW0gZGlzYWdyZWVpbmcgd2l0aCB5b3VyIGludGVycHJldGF0aW9uIG9mIHRoZSBs YW5ndWFnZS4NCj4NCj4gU28sIG5vdywgd2hhdCBzYXkgeW91IHNpcGNvcmU/DQoNCkkgdGhpbmsg dGhlIG1haW4gcG9pbnQgb2YgYnJpbmdpbmcgdGhpcyB0byBzaXBjb3JlIGlzIHRvIGdldCBzb21l IGZyZXNoIGlucHV0IGludG8gdGhpcyBkaXNjdXNzaW9uLiBTaW5jZSBJIGhhdmUgYmVlbiBwYXJ0 eSB0byB0aGUgZGlzY3Vzc2lvbiBvdmVyIGluIGVjcml0IEkgZG9uJ3QgYnJpbmcgYW55dGhpbmcg ZnJlc2ggaGVyZS4gQnV0IGZvciBjb21wbGV0ZW5lc3MgSSB3aWxsIHJlZ2lzdGVyIG15IG9waW5p b24gaGVyZSB0b28uDQoNCklNTyB0aGlzIGlzIG5vdCBhIHF1ZXN0aW9uIGFib3V0IHdoZXRoZXIg dGhlIHByb3Bvc2VkIHVzYWdlIGlzIHZhbGlkIGFjY29yZGluZyB0byA2MDg2IGFuZCBvdGhlciBy ZmNzLiAoSSB0aGluayBpdCBpcyBxdWl0ZSBjbGVhciB0aGF0IGl0DQoqaXMqIHZhbGlkLikgUmF0 aGVyIHRoaXMgaXMgc2ltcGx5IGEgcXVlc3Rpb24gb2Ygd2hhdCBpcyB0aGUgYmVzdCBkZXNpZ24g Zm9yIHRoZSBkZXNpcmVkIGZ1bmN0aW9uYWxpdHkuIEFzIHN1Y2ggSSBkb24ndCB0aGluayBpdCBy ZWFsbHkgbmVlZHMgdG8gYmUgc2V0dGxlZCBpbiBzaXBjb3JlLg0KDQpCdXQgSSBhbSBoYXBweSB0 byBjaGVjayBpZiBhbnlib2R5IGhhcyBhIGRpZmZlcmVudCBwZXJzcGVjdGl2ZSBvbiB0aGlzLg0K DQoJVGhhbmtzLA0KCVBhdWwNCg0KPiBCcmlhbg0KPg0KPg0KPj4gT24gQXVnIDI1LCAyMDE2LCBh dCA5OjE0IEFNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u Y29tPiB3cm90ZToNCj4+DQo+PiBIaSwNCj4+DQo+Pj4gV2XigJlyZSBhZ3JlZWluZyB0aGF0IHRo ZXJlIGlzIGEgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIGNvbW1hbmQgYW5kIA0KPj4+IHRoZSBk YXRhLg0KPj4+DQo+Pj4gV2XigJlyZSBzdWdnZXN0aW5nIHRoYXQgd2UgZG9u4oCZdCBoYXZlIHRv IGJlIGFuYWwgYWJvdXQgdGhlIGxhbmd1YWdlIA0KPj4+IGFuZCBhcyBsb25nIGFzIHRoZXJlIGlz IGFuIElORk8gcGFja2FnZSwgYW5kIGEgYm9keSBwYXJ0IHRoYXQgaGFzIA0KPj4+IHRoZSBBQ0sg d2hpY2ggaXMgYW4gSU5GTyBib2R5IHBhcnQsIHRoYXQgdGhlIGNpdGVkIGxhbmd1YWdlIGRvZXNu 4oCZdCANCj4+PiBjb21wZWwgdXMgdG8gdXNlIHRoZSBJTkZPIGJvZHkgcGFydCB0byB0cmFuc3Bv cnQgdGhlIGRhdGEsIHRoZSANCj4+PiBDYWxsLUluZm8gbWVjaGFuaXNtIGlzIGFjY2VwdGFibGUu DQo+Pj4NCj4+PiBObyBvbmUgaXMgc3VnZ2VzdGluZyB0aGF0IHdlIHVwZGF0ZSA2MDg2LCBhbmQg d2UgYWdyZWUgdGhhdCA3ODUyIGRpZCANCj4+PiBub3QgdXBkYXRlIDYwODYuDQo+Pj4NCj4+PiBJ dOKAmXMganVzdCB3aGV0aGVyIHRoYXQgbGFuZ3VhZ2UgcHJvaGliaXRzIHVzZSBvZiB0aGUgQ2Fs bC1JbmZvIHRvIA0KPj4+IGNhcnJ5IHRoZSBkYXRhIHdoZW4gaXQgd2FzIHByb21wdGVkIGJ5IHRo ZSBJTkZPIHBhY2thZ2UgcmVxdWVzdCwgYW5kIA0KPj4+IGFjY29tcGFuaWVzIHRoZSBJTkZPIHBh Y2thZ2UgQUNLLg0KPj4NCj4+IFlvdSBzZWVtIHRvIHN1Z2dlc3QgdGhhdCwganVzdCBiZWNhdXNl IHlvdSB1c2UgYW4gSW5mbyBQYWNrYWdlIGZvciANCj4+IHNlbmRpbmcgU09NRSBvZiB0aGUgZWNh bGwgcmVsYXRlZCBpbmZvcm1hdGlvbiAodGhlIHJlcXVlc3QgYW5kIEFDSyksIA0KPj4gdGhhdCBh bGxvd3MgeW91IHRvIHNlbmQgdGhlIHJlc3Qgb2YgdGhlIGVjYWxsIHJlbGF0ZWQgaW5mb3JtYXRp b24gDQo+PiAodGhlIGRhdGEgY29udGVudCkgd2l0aG91dCB1c2luZyBhbiBJbmZvIFBhY2thZ2Uu IEkgcmVhbGx5IGRvbuKAmXQgc2VlIA0KPj4gaG93IHlvdSBjYW4gcGFyc2UgdGhlIGNpdGVkIHRl eHQgaW4gdGhhdCB3YXkuIFRoZSBjaXRlZCB0ZXh0IHNheXMgDQo+PiB0aGF0IGluZm9ybWF0aW9u IGFzc29jaWF0ZWQgd2l0aCB0aGUgYXBwbGljYXRpb24gc2hhbGwgYmUgc2VudCB1c2luZyANCj4+ IGFuIEluZm8gUGFja2FnZS4gQW5kLCBib3RoIHRoZSBBQ0sgYW5kIHRoZSByZXF1ZXN0ZWQgZGF0 YSBjb250ZW50IGFyZSANCj4+IGFzc29jaWF0ZWQgd2l0aCB0aGUgZWNhbGwgYXBwbGljYXRpb24u DQo+Pg0KPj4gUmVnYXJkcywNCj4+DQo+PiBDaHJpc3Rlcg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+ Pj4NCj4+PiBCcmlhbg0KPj4+DQo+Pj4+IE9uIEF1ZyAyNSwgMjAxNiwgYXQgMjowMCBBTSwgQ2hy aXN0ZXIgSG9sbWJlcmcgDQo+Pj4+IDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IHdy b3RlOg0KPj4+Pg0KPj4+PiBIaSwNCj4+Pj4NCj4+Pj4gScK5bSBnbGFkIHRoaXMgaXMgYnJvdWdo dCB0byBTSVBDT1JFLiBBcyBvbmUgb2YgdGhlIGluZm8gcGFja2FnZSANCj4+Pj4gcHJvcG9uZW50 cywgcGxlYXNlIGxldCBtZSBjbGFyaWZ5IG15IGFyZ3VtZW50cy4NCj4+Pj4NCj4+Pj4gVGhlIDYw ODYgdGV4dCB0aGF0IEJyaWFuIGNvcGllZCBzYXlzIMKzYnV0IGFyZSBub3Qgc3BlY2lmaWNhbGx5 IA0KPj4+PiBhc3NvY2lhdGVkIHdpdGggdGhlIElORk8gbWV0aG9kIGFuZCB0aGUgYXBwbGljYXRp b24gY29uY2VybmVkwrIuDQo+Pj4+DQo+Pj4+IEkgY2xhaW0gdGhhdCB0aGUgdXBkYXRlZCBkYXRh IElTIGFzc29jaWF0ZWQgd2l0aCB0aGUgYXBwbGljYXRpb24gDQo+Pj4+IGNvbmNlcm5lZCAoZWNh bGwpLiBUaGUgdXBkYXRlZCBkYXRhIGlzIHJlcXVlc3RlZCBieSB0aGUgZWNhbGwgDQo+Pj4+IGFw cGxpY2F0aW9uLCBhbmQgdGhlIGRlbGl2ZXJlZCB1cGRhdGVkIGRhdGEgaXMgY29uc3VtZWQgYnkg dGhlIA0KPj4+PiBlY2FsbCBhcHBsaWNhdGlvbi4gVGhlIHVwZGF0ZWQgZGF0YSBpcyBOT1Qgc29t ZSANCj4+Pj4gbm9uLWVjYWxsLWFwcGxpY2F0aW9uLXJlbGF0ZWQgaW5mb3JtYXRpb24gdGhhdCBp cyBwaWdneWJhY2tlZCBpbiBhIA0KPj4+PiAiY29udmVuaWVudCBJTkZPIG1lc3NhZ2UiIHRoYXQg aGFwcGVucyB0byBiZSBzZW50IGJ5IHRoZSBlY2FsbCANCj4+Pj4gYXBwbGljYXRpb24gZm9yIHNv bWUgb3RoZXIgcHVycG9zZS4NCj4+Pj4NCj4+Pj4gKEluIGFkZGl0aW9uLCB0aGUgdXBkYXRlZCBk YXRhIGlzIE5PVCBhc3NvY2lhdGVkIHdpdGggYSBsZWdhY3kNCj4+Pj4gKHByZS02MDg2KQ0KPj4+ PiBJTkZPIHVzYWdlLCB3aGljaCBjb3VsZCBqdXN0aWZ5IG5vdCB1c2luZyBhbiBJbmZvIFBhY2th Z2UuIEkgZG8gDQo+Pj4+IHdhbnQgdG8gcG9pbnQgb3V0IHRoYXQgbm9ib2R5IGhhcyBjbGFpbWVk IHRoYXQgdGhlIHVwZGF0ZWQgZGF0YSANCj4+Pj4gd291bGQgYmUgYXNzb2NpYXRlZCB3aXRoIGxl Z2FjeSBJTkZPLCBidXQganVzdCBmb3IgY29tcGxldGVuZXNzKQ0KPj4+Pg0KPj4+PiBSRkMgNzg1 MiBkb2VzIGRlZmluZSBhIG1lY2hhbmlzbSBmb3IgdHJhbnNwb3J0aW5nIGRhdGEsIHVzaW5nIA0K Pj4+PiBDYWxsLUluZm8gZXRjLiBCdXQsIDc4NTIgZG9lcyBub3QgdXBkYXRlIDYwODYsIG5vciBj YW4gNzg1MiANCj4+Pj4gb3ZlcnJpZGUgcnVsZXMgYW5kIHByb2NlZHVyZXMgYXNzb2NpYXRlZCB3 aXRoIGluZGl2aWR1YWwgU0lQIA0KPj4+PiBtZXRob2RzIChJTkZPIGluIHRoaXMgY2FzZSkuIEkg YWxzbyBwb2ludGVkIHRoaXMgb3V0IGJlZm9yZSA3ODUyIA0KPj4+PiB3YXMgcHVibGlzaGVkLCBi dXQgd2FzIHRvbGQgdGhhdCBpdMK5cyB0b28gbGF0ZSB0byBjaGFuZ2UgaXQgDQo+Pj4+IChncmFu dGVkLCB0aGUgZHJhZnQgd2FzIGluIHRoZSBSRkMgZWRpdG9ywrlzIHF1ZXVlKS4NCj4+Pj4NCj4+ Pj4gRmluYWxseSwgYWdhaW4gZm9yIGNvbXBsZXRlbmVzcywgSSB3YW50IHRvIHBvaW50IG91dCB0 aGF0IDYwODYgZG9lcyANCj4+Pj4gbm90IHByZXZlbnQgaW5jbHVkaW5nIENhbGwtSW5mbyBpbiBJ TkZPIGFzIHN1Y2guIFRoZSBpc3N1ZSBpcyBob3cgDQo+Pj4+IHNvbWUgd2FudCB0byB1c2UgQ2Fs bC1JbmZvIGluc3RlYWQgb2YgYW4gSW5mbyBQYWNrYWdlLg0KPj4+Pg0KPj4+PiBSZWdhcmRzLA0K Pj4+Pg0KPj4+PiBDaHJpc3Rlcg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBPbiAyNS8wOC8xNiAw MzoyMiwgInNpcGNvcmUgb24gYmVoYWxmIG9mIEJyaWFuIFJvc2VuIg0KPj4+PiA8c2lwY29yZS1i b3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBickBicmlhbnJvc2VuLm5ldD4gd3JvdGU6DQo+ Pj4+DQo+Pj4+PiBPdmVyIGluIGVjcml0IHdlIGhhdmUgYSBkaXNhZ3JlZW1lbnQgdGhhdCByZWxh dGVzIHRvIGludGVycHJldGluZyANCj4+Pj4+IFJGQzYwODYuDQo+Pj4+Pg0KPj4+Pj4gQmFja2dy b3VuZDoNCj4+Pj4+IFJGQzc4NTIgZGVmaW5lcyBzb21ldGhpbmcgY2FsbGVkICJBZGRpdGlvbmFs IERhdGEiLCB3aGljaCBpcyANCj4+Pj4+IGNhcnJpZWQgaW4gZW1lcmdlbmN5IGNhbGwgc2lnbmFs aW5nLiAgSXQncyBkYXRhIHJlbGF0ZWQgdG8gdGhlIA0KPj4+Pj4gY2FsbCwgZS5nLiwgdGhlIGlk ZW50aXR5IGFuZCBjb250YWN0IGRhdGEgb2YgdGhlIHNlcnZpY2UgcHJvdmlkZXIgaGFuZGxpbmcg dGhlIGNhbGwuDQo+Pj4+PiBBZGRpdGlvbmFsIERhdGEgaXMgc2lnbmFsZWQgd2l0aCBhIENhbGwt SW5mbyBoZWFkZXIgZmllbGQsIHdoaWNoIA0KPj4+Pj4gY29udGFpbnMgZWl0aGVyIGEgVVJJIHBv aW50aW5nIHRvIGEgZGF0YSBibG9jayBmZXRjaGVkIHdpdGggSFRUUFMsIA0KPj4+Pj4gb3IgYSBD b250ZW50IEluZGlyZWN0IHJlZmVyZW5jaW5nIGEgYm9keSBwYXJ0IG9mIHRoZSBTSVAgbWVzc2Fn ZS4gIA0KPj4+Pj4gSXQncyB1c3VhbGx5IHVzZWQgb24gdGhlIElOVklURSBvZiB0aGUgZW1lcmdl bmN5IGNhbGwsIHNvIGl0IGNhbiANCj4+Pj4+IGJlIGRpc3BsYXllZCB0byB0aGUgUFNBUCAoZW1l cmdlbmN5IGNhbGwgY2VudGVyKSBjYWxsLXRha2VyIHdoZW4gDQo+Pj4+PiB0aGUgY2FsbCBpcyBh c3NpZ25lZC4NCj4+Pj4+DQo+Pj4+PiBTb21ldGltZXMsIHRoaXMgZGF0YSBjYW4gY2hhbmdlIGR1 cmluZyBhIGNhbGwuICBUaGUgZXhhbXBsZSBpbiANCj4+Pj4+IGRpc2N1c3Npb24NCj4+Pj4+IGlz IHRlbGVtYXRpY3MgZGF0YSBpbiBhIHZlaGljbGUuICAgVGhlIHZlaGljbGUgY2FuIHJlcG9ydCB0 aGluZ3MgbGlrZQ0KPj4+Pj4gdGhlDQo+Pj4+PiBudW1iZXIgb2Ygb2NjdXBhbnRzIGFuZCBpdHMg b3JpZW50YXRpb24uICBUaGUgUFNBUCBjYW4gcmVxdWVzdCBhbiANCj4+Pj4+IHVwZGF0ZSBtaWQg Y2FsbCAoZS5nLiwgaWYgdGhlIGNhbGwgdGFrZXIgdGhpbmtzIHRoaW5ncyBtaWdodCBoYXZlIA0K Pj4+Pj4gY2hhbmdlZCkuDQo+Pj4+Pg0KPj4+Pj4gSU5GTyBpcyB0aGUgY2hvc2VuIG1lY2hhbmlz bSB0byBzZW5kIHRoZSByZXF1ZXN0IGZvciB1cGRhdGUuICBUaGUgDQo+Pj4+PiBkZXZpY2Ugd2ls bCBzZW5kIGEgcmVzcG9uc2UgdG8gdGhlIHJlcXVlc3QgKGFuIEFDSyksIHdoaWNoIGlzIGFsc28g DQo+Pj4+PiBzZW50IGluIElORk8uDQo+Pj4+PiBUaGlzIGNvbnN0aXR1dGVzIGEgd2VsbCBkZWZp bmVkIElORk8gcGFja2FnZSwgYW5kIHdpbGwgYmUgDQo+Pj4+PiByZWdpc3RlcmVkIGluIHRoZSB1 c3VhbCB3YXkuDQo+Pj4+Pg0KPj4+Pj4gVGhlIElzc3VlIGF0IGhhbmQ6DQo+Pj4+PiBTbywgdGhl IGRpc3B1dGUgaXMgaG93IHRoZSB1cGRhdGVkIGRhdGEgaXMgc2VudCBtaWQgY2FsbC4NCj4+Pj4+ DQo+Pj4+PiBSRkM2MDg2IHNheXMNCj4+Pj4+DQo+Pj4+PiBOT1RFOiBBbiBJTkZPIHJlcXVlc3Qg Y2FuIGFsc28gY29udGFpbiBvdGhlciBib2R5IHBhcnRzIHRoYXQgYXJlIA0KPj4+Pj4gbWVhbmlu Z2Z1bCB3aXRoaW4gdGhlIGNvbnRleHQgb2YgYW4gaW52aXRlIGRpYWxvZyB1c2FnZSBidXQgYXJl IA0KPj4+Pj4gbm90IHNwZWNpZmljYWxseSBhc3NvY2lhdGVkIHdpdGggdGhlIElORk8gbWV0aG9k IGFuZCB0aGUgDQo+Pj4+PiBhcHBsaWNhdGlvbiBjb25jZXJuZWQuDQo+Pj4+Pg0KPj4+Pj4gVGhl IGF1dGhvcnMgb2YgdGhlIGRyYWZ0IChvZiB3aGljaCBJIGFtIG9uZSkgZGVzaXJlIHRvIHVzZSB0 aGUgDQo+Pj4+PiBBZGRpdGlvbmFsIERhdGEgbWVjaGFuaXNtIHRvIGNhcnJ5IHRoZSB1cGRhdGVk IGRhdGEuICBUaGUgZGF0YSANCj4+Pj4+IGNvdWxkIGJlIHNlbnQgaW4gYW55IGNvbnZlbmllbnQg bWVzc2FnZSwgYWx0aG91Z2ggc2luY2UgdGhlIA0KPj4+Pj4gdmVoaWNsZSBpcyBzZW5kaW5nIGFu IEFDSywgaXQncyBsaWtlbHkgZ29pbmcgdG8gZ28gb24gdGhhdC4gIFdlJ2QgDQo+Pj4+PiBsaWtl IHRvIGFsd2F5cyBjYXJyeSB0aGUgZGF0YSBpbiB0aGUgc2FtZSB3YXkuICBJbiBhbiBJTkZPIG1l c3NhZ2UgDQo+Pj4+PiBpdCB3b3VsZCBiZSBjYXJyaWVkIHRoZSBzYW1lIGFzIGl0IGlzIGluIHRo ZSBJTlZJVEUsIGFzIEFkZGl0aW9uYWwgDQo+Pj4+PiBEYXRhLiAgU2luY2UgdGhlIElORk8gY2Fy cmllcyBhbiBBQ0ssIGl0IHdvdWxkIHNwZWNpZnkgdGhlIA0KPj4+Pj4gYXBwcm9wcmlhdGUgSU5G TyBwYWNrYWdlLCBhbmQgd291bGQgY29udGFpbiBhIGJvZHkgcGFydCB3aXRoIHRoZSANCj4+Pj4+ IEFDSy4gIFRoZXJlIHdvdWxkIGJlIGFub3RoZXIgYm9keSBwYXJ0IGZvciB0aGUgdXBkYXRlZCBk YXRhLCANCj4+Pj4+IHBvaW50ZWQgdG8gYnkgdGhlIENhbGwtSW5mby4NCj4+Pj4+DQo+Pj4+PiBT b21lIGVjcml0IHBhcnRpY2lwYW50cyBzYXkgdGhhdCB0aGUgYWJvdmUgbGFuZ3VhZ2Ugb2YgNjA4 NiB3b3VsZCANCj4+Pj4+IHByb2hpYml0IHRoZSBJTkZPIGZyb20gY29udGFpbmluZyBhIENhbGwt SW5mbyBoZWFkZXIgd2l0aCBhIENJRCANCj4+Pj4+IHBvaW50aW5nIHRvIGEgTUlNRSBib2R5IHBh cnQsIGJlY2F1c2UgdGhlIGRhdGEgd2FzIHJlcXVlc3RlZCBieSBhbiANCj4+Pj4+IElORk8sIGFu ZCBoZW5jZSBpcyByZWxhdGVkIHRvIHRoZSBJTkZPIHBhY2thZ2UuICBUaGV5IHNheSB0aGF0IHRo ZSANCj4+Pj4+IGRhdGEgTVVTVCBiZSBjYXJyaWVkIHdpdGggYSBib2R5IHBhcnQgYW5kIENvbnRl bnQgRGlzcG9zaXRpb24gdGhhdCANCj4+Pj4+IGlzIHBhcnQgb2YgdGhlIElORk8gcGFja2FnZSBk ZWZpbml0aW9uLg0KPj4+Pj4NCj4+Pj4+IFRoZSBkcmFmdCBhdXRob3JzIGNsYWltIHRoaXMgNjA4 NiBsYW5ndWFnZSBpc24ndCBhIHN0cmFpZ2h0amFja2V0LCANCj4+Pj4+IGFuZCBpdCdzIHBlcmZl Y3RseSBmaW5lIHRvIGNhcnJ5IHRoZSBkYXRhIHJlZmVyZW5jZWQgYnkgYSANCj4+Pj4+IENhbGwt SW5mbyB3aXRoIGEgQ29udGVudCBJbmRpcmVjdCBib2R5IHBhcnQgdXNpbmcgdGhlIHNhbWUgTUlN RSB0eXBlIGFuZCBDb250ZW50DQo+Pj4+PiBEaXNwb3NpdGlvbiBhcyBpdCB3b3VsZCBpbiBhbiBJ TlZJVEUuICAgV2hlbiB0aGUgdXBkYXRlZCBkYXRhIGlzIHNlbnQNCj4+Pj4+IGluDQo+Pj4+PiBJ TkZPLCBpdCdzIGJlY2F1c2UgdGhlIElORk8gaXMgYSBjb252ZW5pZW50IG1lc3NhZ2UgKHNpbmNl IGl0J3MgDQo+Pj4+PiBiZWluZyBzZW50IHRvIGNhcnJ5IHRoZSBBQ0spLg0KPj4+Pj4NCj4+Pj4+ IE1lY2hhbmljYWxseSwgYm90aCBtZWNoYW5pc21zIGNhbiBiZSBtYWRlIHRvIHdvcmsuICBUaGUg Ym9keSBwYXJ0cyANCj4+Pj4+IHdvdWxkIGJlIGxhYmVsZWQgYXBwcm9wcmlhdGVseSBhbmQgdGhl cmUgd291bGQgYmUgbm8gY29uZnVzaW9uIA0KPj4+Pj4gYWJvdXQgd2hhdCB0aGV5IG1lYW4gb3Ig aG93IHRoZXkgd291bGQgYmUgaW50ZXJwcmV0ZWQuICBJdCdzIA0KPj4+Pj4gcmVhbGx5IG9ubHkg d2hldGhlciB0aGUgQ2FsbC1JbmZvIGhlYWRlciBpcyBwcmVzZW50IGFuZCB3aGF0IHRoZSANCj4+ Pj4+IE1JTUUgdHlwZSBhbmQgQ29udGVudCBEaXNwb3NpdGlvbiB0aGUgYm9keSBwYXJ0IGNvbnRh aW5pbmcgdGhlIA0KPj4+Pj4gZGF0YSB3b3VsZCBiZS4gIEluIHRoZSBhdXRob3IncyBwcmVmZXJy ZWQgd2F5LCBpdCB3b3VsZCBiZSB0aGUgDQo+Pj4+PiBNSU1FIHR5cGUgYW5kIENvbnRlbnQgRGlz cG9zaXRpb24gb2YgdGhlIENhbGwtSW5mbyBhbmQgaW4gdGhlIA0KPj4+Pj4gb3RoZXIgcG9pbnQg b2YgdmlldyBpdCB3b3VsZCBiZSB0aGUgTUlNRSB0eXBlIGFuZCBDb250ZW50IA0KPj4+Pj4gRGlz cG9zaXRpb24gb2YgdGhlIElORk8gcGFja2FnZS4NCj4+Pj4+DQo+Pj4+PiBQbGVhc2UgaWdub3Jl IHlvdXIgcGVyc29uYWwgcHJlZmVyZW5jZSBmb3Igd2hldGhlciB5b3UgdGhpbmsgaXQgDQo+Pj4+ PiBvdWdodCB0byBnbyBpbiB0aGUgSU5GTyBvciBub3QsIGFuZCBwbGVhc2UgaGVscCB1cyBpbnRl cnByZXQgNjA4NjogDQo+Pj4+PiBkb2VzIHRoZSBkYXRhIEhBVkUgdG8gZ28gaW4gYW4gSU5GTyBi b2R5IHBhcnQgb3IgY2FuIGl0IGJlIHNlbnQgaW4gDQo+Pj4+PiBhIENhbGwtSW5mbyBib2R5IHBh cnQ/DQo+Pj4+Pg0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+Pj4+IHNpcGNvcmUgbWFpbGluZyBsaXN0DQo+Pj4+PiBzaXBjb3JlQGlldGYu b3JnDQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUN Cj4+Pj4NCj4+Pg0KPj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4gc2lwY29yZUBpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCj4NCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNpcGNvcmUgbWFp bGluZyBsaXN0DQpzaXBjb3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NpcGNvcmUNCg== From nobody Thu Aug 25 08:17:39 2016 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 2758212D0E2 for ; Thu, 25 Aug 2016 08:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XkkYnYqZVAI for ; Thu, 25 Aug 2016 08:17:35 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE2F712D0DC for ; Thu, 25 Aug 2016 08:17:34 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 4DB414A0CB6B5; Thu, 25 Aug 2016 15:17:27 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u7PFHUj0008982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 25 Aug 2016 15:17:30 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u7PFHUq1028947 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Aug 2016 17:17:30 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.50]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Thu, 25 Aug 2016 17:17:30 +0200 From: "Drage, Keith (Nokia - GB)" To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? Thread-Index: AQHR/t2d3LN8JlqI6kKCkuU4GVEabKBZxlAw Date: Thu, 25 Aug 2016 15:17:29 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF5AAE0@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <76CCBFA5-8D53-4B1E-A495-4A18AB081384@brianrosen.net> <05240A95-8319-4555-8B46-FA18B6C27883@brianrosen.net> <5d462933-e3c0-b3a3-958d-5c9d1e86d854@alum.mit.edu> In-Reply-To: <5d462933-e3c0-b3a3-958d-5c9d1e86d854@alum.mit.edu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 15:17:38 -0000 VGltZSB0byBleHByZXNzIG15IG9waW5pb24uDQoNCkluIHNvbWUgY2lyY3VtYW5jZXMsIGVjYWxs IG5lZWRzIHRvIHRyYW5zZmVyIGRhdGEgb3V0c2lkZSBvZiBhIG5vcm1hbCBjYWxsIGNvbnRyb2wg bWVzc2FnZS4NCg0KVGhlIHZpZXdwb2ludCBpcyB0aGF0IGFuIElORk8gbWVzc2FnZSBtaWdodCBk byB0aGF0LiBUbyB1c2UgSU5GTyBtZXRob2RzLCBvbmUgTVVTVCBkZWZpbmUgYW4gSW5mbyBwYWNr YWdlLiBUaGVyZSBpcyBub3Qgb3RoZXIgcmVxdWlyZW1lbnQgaW4gZWNhbGwgZm9yIGFuIEluZm8g cGFja2FnZSB0byBleGlzdCwgc28gdGhlIEluZm8gcGFja2FnZSBNVVNUIGJlIG9uZSBzcGVjaWZp YyB0byB0cmFuc2ZlcnJpbmcgdGhlIGVjYWxsIGRhdGEsIG5vdCBhbiBJbmZvIHBhY2thZ2UgZm9y IHNvbWV0aGluZyBlbHNlIHRoYXQganVzdCBoYXBwZW5zIHRvIGJlIHN1cHBvcnRpbmcgZWNhbGwg ZGF0YSB0cmFuc2ZlciBiZWNhdXNlIGl0IGlzIGFscmVhZHkgdGhlcmUuDQoNClRyYW5zZmVycmlu ZyBkYXRhIGluIEluZm8gcGFja2FnZXMgaXMgd2VsbCBrbm93bi4gSXQgZG9lcyBub3QgcmVxdWly ZSB0aGUgdXNlIG9mIGEgQ2FsbC1JbmZvIGhlYWRlciBmaWVsZCB0byBkZXNjcmliZSB0aGUgdXNh Z2UuIFRoZSB1c2FnZSBpcyBkZWZpbmVkIGJ5IHRoZSBJbmZvLXBhY2thZ2UgaGVhZGVyIGZpZWxk LiBVc2luZyB0aGUgQ2FsbC1JbmZvIGhlYWRlciBmaWVsZCB3b3VsZCBwcm92aWRlIHR3byBtZWFu cyBvZiBkZXNjcmliaW5nIHRoZSBwdXJwb3NlIG9mIHRoZSBzYW1lIG1lc3NhZ2UgYm9keSBhbmQg bGVhZCB0byBhbGwgc29ydHMgb2YgZXJyb3IgaGFuZGxpbmcgaXNzdWVzIHdoZW4gdGhleSBiZWNv bWUgaW4gY29uZmxpY3QgKGJlY2F1c2Ugc29tZW9uZSBmYWlsZWQgdG8gcmVhZCB0aGUgc3BlY2lm aWNhdGlvbiBvciBzb21lIG90aGVyIHJlYXNvbikuIFRoaXMgbXkgdmlldyBpcyBjbGVhcmx5IHRo YXQgd2Ugc2hvdWxkIGZvbGxvdyB0aGUgcnVsZXMgb2YgY2xlYW4gZGVzaWduIGFuZCBub3QgZG8g dGhpcywgcGFydGljdWxhcmx5IGFzIGluIG15IHZpZXcgaXQgaXMgdG90YWxseSB1bm5lY2Nlc3Nh cnkuDQoNClRoZSByZW1haW5kZXIgZ29lcyBtb3JlIGludG8gZWNhbGwgcmVxdWlyZW1lbnRzLCBh bmQgdGhlcmVmb3JlIGZhbGxzIG1vcmUgdG8gdGhlIHNjb3BlIG9mIGVjcml0IGFuZCAzR1BQLCBi dXQgaW5kaWNhdGVzIHdoeSBJIHRoaW5rIGl0IGlzIHVubmVjZXNzYXJ5Lg0KDQpFY2FsbCBjb25z aXN0cyBvZiB0d28gcGFydHMgLSBkYXRhIHRyYW5zZmVycmVkIGluIHRoZSBpbml0aWFsIElOVklU RSBtZXNzYWdlLiBObyBvbmUgaGFzIG9iamVjdGVkIHRvIGFkZGl0aW9uYWwgZGF0YSB0byBwZXJm b3JtIHRoaXMgZnVuY3Rpb24uIEZ1cnRoZXIgaW4gc29tZSBjaXJjdW1zdGFuY2VzLCB0aGUgUFNB UCBjYW4gcmVxdWVzdCBtb3JlIGRhdGEgdG8gYmUgc2VudCBvdXRzaWRlIHRoYXQgaW5pdGlhbCBy ZXF1ZXN0IGFuZCBvdXRzaWRlIGZ1cnRoZXIgY2FsbCBjb250cm9sIG1lc3NhZ2VzLiBJdCBpcyBo ZXJlIHdoZXJlIHRoZSBJbmZvIHBhY2thZ2UgZGlzY3Vzc2lvbiBjb21lcyBpbi4gTXkgdmlldyBz dHJvbmdseSBleHByZXNzZWQgaXMgdGhhdCB0aGVzZSBjYW4gYmUgdHJlYXRlZCBmcm9tIHRoZSBT SVAgdmlld3BvaW50IGFzIHR3byBlbnRpcmVseSBzZXBhcmF0ZSB0cmFuc3BvcnQgbWVjaGFuaXNt cywgY29tcGxldGVseSBvcGVyYXRpbmcgaW5kZXBlbmRlbnRseSBhdCB0aGUgU0lQIGxhdGVyLiBB dCBzb21lIHBvaW50IHRoZXkgYm90aCB0cmFuc2ZlciBhbiBNU0QsIGJ1dCB0aGF0IGlzIHNlcGFy YXRlbHkgaWRlbnRpZmllZCBieSBvdGhlciBoZWFkZXIgZmllbGRzLiBJdCBpcyB0aGVuIHVwIHRv IHRoZSBhcHBsaWNhdGlvbiBpbiBib3RoIHRoZSBQU0FQIGFuZCB0aGUgY2FsbGluZyB1c2VyIGFn ZW50IHRvIGNvbnRyb2wgaG93IHRoZXNlIHR3byBpbmRlcGVuZGVudCBkYXRhIHRyYW5zZmVyIG1l Y2hhbmlzbXMgYXJlIHVzZWQuIEFzIHN1Y2ggdGhlcmUgaXMgbm8gbmVlZCB0byBzdGFydCBkZWZp bmluZyBpbnRlcmFjdGlvbnMgYmV0d2VlbiBJbmZvIHBhY2thZ2VzIGFuZCBhZGRpdGlvbmFsIGRh dGEsIGFuZCBubyBuZWVkIGZvciBvbmUgdG8gdXBkYXRlIHRoZSBvdGhlci4NCg0KUmVnYXJkcw0K DQpLZWl0aA0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHNpcGNvcmUg W21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQYXVsIEt5eml2 YXQNClNlbnQ6IDI1IEF1Z3VzdCAyMDE2IDE1OjMyDQpUbzogc2lwY29yZUBpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFtzaXBjb3JlXSBDYW4gYW4gSU5GTyBjb250YWluIGEgYm9keSByZWxhdGVkIHRv LCBidXQgbm90IHBhcnQgb2YgdGhlIElORk8gcGFja2FnZT8NCg0KT24gOC8yNS8xNiA5OjI2IEFN LCBCcmlhbiBSb3NlbiB3cm90ZToNCj4gWWVzLCBJ4oCZbSBzYXlpbmcgdGhhdCB0aGUgQUNLIHNh dGlzZmllcyB0aGUgNjA4NiB1c2Ugb2YgSU5GTywgYW5kIHRoYXQgaXTigJlzIG9rYXkgdG8gc2Vu ZCB0aGUgZGF0YSB3aXRoIENhbGwtSW5mby4NCj4NCj4gWWVzLCBJ4oCZbSBhZ3JlZWluZyB0aGF0 IHRoZXJlIGlzIGEgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIElORk8gcGFja2FnZSBhbmQgdGhl IGRhdGEuDQo+DQo+IFllcywgSeKAmW0gZGlzYWdyZWVpbmcgd2l0aCB5b3VyIGludGVycHJldGF0 aW9uIG9mIHRoZSBsYW5ndWFnZS4NCj4NCj4gU28sIG5vdywgd2hhdCBzYXkgeW91IHNpcGNvcmU/ DQoNCkkgdGhpbmsgdGhlIG1haW4gcG9pbnQgb2YgYnJpbmdpbmcgdGhpcyB0byBzaXBjb3JlIGlz IHRvIGdldCBzb21lIGZyZXNoIGlucHV0IGludG8gdGhpcyBkaXNjdXNzaW9uLiBTaW5jZSBJIGhh dmUgYmVlbiBwYXJ0eSB0byB0aGUgZGlzY3Vzc2lvbiBvdmVyIGluIGVjcml0IEkgZG9uJ3QgYnJp bmcgYW55dGhpbmcgZnJlc2ggaGVyZS4gQnV0IGZvciBjb21wbGV0ZW5lc3MgSSB3aWxsIHJlZ2lz dGVyIG15IG9waW5pb24gaGVyZSB0b28uDQoNCklNTyB0aGlzIGlzIG5vdCBhIHF1ZXN0aW9uIGFi b3V0IHdoZXRoZXIgdGhlIHByb3Bvc2VkIHVzYWdlIGlzIHZhbGlkIGFjY29yZGluZyB0byA2MDg2 IGFuZCBvdGhlciByZmNzLiAoSSB0aGluayBpdCBpcyBxdWl0ZSBjbGVhciB0aGF0IGl0DQoqaXMq IHZhbGlkLikgUmF0aGVyIHRoaXMgaXMgc2ltcGx5IGEgcXVlc3Rpb24gb2Ygd2hhdCBpcyB0aGUg YmVzdCBkZXNpZ24gZm9yIHRoZSBkZXNpcmVkIGZ1bmN0aW9uYWxpdHkuIEFzIHN1Y2ggSSBkb24n dCB0aGluayBpdCByZWFsbHkgbmVlZHMgdG8gYmUgc2V0dGxlZCBpbiBzaXBjb3JlLg0KDQpCdXQg SSBhbSBoYXBweSB0byBjaGVjayBpZiBhbnlib2R5IGhhcyBhIGRpZmZlcmVudCBwZXJzcGVjdGl2 ZSBvbiB0aGlzLg0KDQoJVGhhbmtzLA0KCVBhdWwNCg0KPiBCcmlhbg0KPg0KPg0KPj4gT24gQXVn IDI1LCAyMDE2LCBhdCA5OjE0IEFNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4+DQo+PiBIaSwNCj4+DQo+Pj4gV2XigJlyZSBhZ3Jl ZWluZyB0aGF0IHRoZXJlIGlzIGEgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIGNvbW1hbmQgYW5k IA0KPj4+IHRoZSBkYXRhLg0KPj4+DQo+Pj4gV2XigJlyZSBzdWdnZXN0aW5nIHRoYXQgd2UgZG9u 4oCZdCBoYXZlIHRvIGJlIGFuYWwgYWJvdXQgdGhlIGxhbmd1YWdlIA0KPj4+IGFuZCBhcyBsb25n IGFzIHRoZXJlIGlzIGFuIElORk8gcGFja2FnZSwgYW5kIGEgYm9keSBwYXJ0IHRoYXQgaGFzIA0K Pj4+IHRoZSBBQ0sgd2hpY2ggaXMgYW4gSU5GTyBib2R5IHBhcnQsIHRoYXQgdGhlIGNpdGVkIGxh bmd1YWdlIGRvZXNu4oCZdCANCj4+PiBjb21wZWwgdXMgdG8gdXNlIHRoZSBJTkZPIGJvZHkgcGFy dCB0byB0cmFuc3BvcnQgdGhlIGRhdGEsIHRoZSANCj4+PiBDYWxsLUluZm8gbWVjaGFuaXNtIGlz IGFjY2VwdGFibGUuDQo+Pj4NCj4+PiBObyBvbmUgaXMgc3VnZ2VzdGluZyB0aGF0IHdlIHVwZGF0 ZSA2MDg2LCBhbmQgd2UgYWdyZWUgdGhhdCA3ODUyIGRpZCANCj4+PiBub3QgdXBkYXRlIDYwODYu DQo+Pj4NCj4+PiBJdOKAmXMganVzdCB3aGV0aGVyIHRoYXQgbGFuZ3VhZ2UgcHJvaGliaXRzIHVz ZSBvZiB0aGUgQ2FsbC1JbmZvIHRvIA0KPj4+IGNhcnJ5IHRoZSBkYXRhIHdoZW4gaXQgd2FzIHBy b21wdGVkIGJ5IHRoZSBJTkZPIHBhY2thZ2UgcmVxdWVzdCwgYW5kIA0KPj4+IGFjY29tcGFuaWVz IHRoZSBJTkZPIHBhY2thZ2UgQUNLLg0KPj4NCj4+IFlvdSBzZWVtIHRvIHN1Z2dlc3QgdGhhdCwg anVzdCBiZWNhdXNlIHlvdSB1c2UgYW4gSW5mbyBQYWNrYWdlIGZvciANCj4+IHNlbmRpbmcgU09N RSBvZiB0aGUgZWNhbGwgcmVsYXRlZCBpbmZvcm1hdGlvbiAodGhlIHJlcXVlc3QgYW5kIEFDSyks IA0KPj4gdGhhdCBhbGxvd3MgeW91IHRvIHNlbmQgdGhlIHJlc3Qgb2YgdGhlIGVjYWxsIHJlbGF0 ZWQgaW5mb3JtYXRpb24gDQo+PiAodGhlIGRhdGEgY29udGVudCkgd2l0aG91dCB1c2luZyBhbiBJ bmZvIFBhY2thZ2UuIEkgcmVhbGx5IGRvbuKAmXQgc2VlIA0KPj4gaG93IHlvdSBjYW4gcGFyc2Ug dGhlIGNpdGVkIHRleHQgaW4gdGhhdCB3YXkuIFRoZSBjaXRlZCB0ZXh0IHNheXMgDQo+PiB0aGF0 IGluZm9ybWF0aW9uIGFzc29jaWF0ZWQgd2l0aCB0aGUgYXBwbGljYXRpb24gc2hhbGwgYmUgc2Vu dCB1c2luZyANCj4+IGFuIEluZm8gUGFja2FnZS4gQW5kLCBib3RoIHRoZSBBQ0sgYW5kIHRoZSBy ZXF1ZXN0ZWQgZGF0YSBjb250ZW50IGFyZSANCj4+IGFzc29jaWF0ZWQgd2l0aCB0aGUgZWNhbGwg YXBwbGljYXRpb24uDQo+Pg0KPj4gUmVnYXJkcywNCj4+DQo+PiBDaHJpc3Rlcg0KPj4NCj4+DQo+ Pg0KPj4NCj4+DQo+Pj4NCj4+PiBCcmlhbg0KPj4+DQo+Pj4+IE9uIEF1ZyAyNSwgMjAxNiwgYXQg MjowMCBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgDQo+Pj4+IDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmlj c3Nvbi5jb20+IHdyb3RlOg0KPj4+Pg0KPj4+PiBIaSwNCj4+Pj4NCj4+Pj4gScK5bSBnbGFkIHRo aXMgaXMgYnJvdWdodCB0byBTSVBDT1JFLiBBcyBvbmUgb2YgdGhlIGluZm8gcGFja2FnZSANCj4+ Pj4gcHJvcG9uZW50cywgcGxlYXNlIGxldCBtZSBjbGFyaWZ5IG15IGFyZ3VtZW50cy4NCj4+Pj4N Cj4+Pj4gVGhlIDYwODYgdGV4dCB0aGF0IEJyaWFuIGNvcGllZCBzYXlzIMKzYnV0IGFyZSBub3Qg c3BlY2lmaWNhbGx5IA0KPj4+PiBhc3NvY2lhdGVkIHdpdGggdGhlIElORk8gbWV0aG9kIGFuZCB0 aGUgYXBwbGljYXRpb24gY29uY2VybmVkwrIuDQo+Pj4+DQo+Pj4+IEkgY2xhaW0gdGhhdCB0aGUg dXBkYXRlZCBkYXRhIElTIGFzc29jaWF0ZWQgd2l0aCB0aGUgYXBwbGljYXRpb24gDQo+Pj4+IGNv bmNlcm5lZCAoZWNhbGwpLiBUaGUgdXBkYXRlZCBkYXRhIGlzIHJlcXVlc3RlZCBieSB0aGUgZWNh bGwgDQo+Pj4+IGFwcGxpY2F0aW9uLCBhbmQgdGhlIGRlbGl2ZXJlZCB1cGRhdGVkIGRhdGEgaXMg Y29uc3VtZWQgYnkgdGhlIA0KPj4+PiBlY2FsbCBhcHBsaWNhdGlvbi4gVGhlIHVwZGF0ZWQgZGF0 YSBpcyBOT1Qgc29tZSANCj4+Pj4gbm9uLWVjYWxsLWFwcGxpY2F0aW9uLXJlbGF0ZWQgaW5mb3Jt YXRpb24gdGhhdCBpcyBwaWdneWJhY2tlZCBpbiBhIA0KPj4+PiAiY29udmVuaWVudCBJTkZPIG1l c3NhZ2UiIHRoYXQgaGFwcGVucyB0byBiZSBzZW50IGJ5IHRoZSBlY2FsbCANCj4+Pj4gYXBwbGlj YXRpb24gZm9yIHNvbWUgb3RoZXIgcHVycG9zZS4NCj4+Pj4NCj4+Pj4gKEluIGFkZGl0aW9uLCB0 aGUgdXBkYXRlZCBkYXRhIGlzIE5PVCBhc3NvY2lhdGVkIHdpdGggYSBsZWdhY3kNCj4+Pj4gKHBy ZS02MDg2KQ0KPj4+PiBJTkZPIHVzYWdlLCB3aGljaCBjb3VsZCBqdXN0aWZ5IG5vdCB1c2luZyBh biBJbmZvIFBhY2thZ2UuIEkgZG8gDQo+Pj4+IHdhbnQgdG8gcG9pbnQgb3V0IHRoYXQgbm9ib2R5 IGhhcyBjbGFpbWVkIHRoYXQgdGhlIHVwZGF0ZWQgZGF0YSANCj4+Pj4gd291bGQgYmUgYXNzb2Np YXRlZCB3aXRoIGxlZ2FjeSBJTkZPLCBidXQganVzdCBmb3IgY29tcGxldGVuZXNzKQ0KPj4+Pg0K Pj4+PiBSRkMgNzg1MiBkb2VzIGRlZmluZSBhIG1lY2hhbmlzbSBmb3IgdHJhbnNwb3J0aW5nIGRh dGEsIHVzaW5nIA0KPj4+PiBDYWxsLUluZm8gZXRjLiBCdXQsIDc4NTIgZG9lcyBub3QgdXBkYXRl IDYwODYsIG5vciBjYW4gNzg1MiANCj4+Pj4gb3ZlcnJpZGUgcnVsZXMgYW5kIHByb2NlZHVyZXMg YXNzb2NpYXRlZCB3aXRoIGluZGl2aWR1YWwgU0lQIA0KPj4+PiBtZXRob2RzIChJTkZPIGluIHRo aXMgY2FzZSkuIEkgYWxzbyBwb2ludGVkIHRoaXMgb3V0IGJlZm9yZSA3ODUyIA0KPj4+PiB3YXMg cHVibGlzaGVkLCBidXQgd2FzIHRvbGQgdGhhdCBpdMK5cyB0b28gbGF0ZSB0byBjaGFuZ2UgaXQg DQo+Pj4+IChncmFudGVkLCB0aGUgZHJhZnQgd2FzIGluIHRoZSBSRkMgZWRpdG9ywrlzIHF1ZXVl KS4NCj4+Pj4NCj4+Pj4gRmluYWxseSwgYWdhaW4gZm9yIGNvbXBsZXRlbmVzcywgSSB3YW50IHRv IHBvaW50IG91dCB0aGF0IDYwODYgZG9lcyANCj4+Pj4gbm90IHByZXZlbnQgaW5jbHVkaW5nIENh bGwtSW5mbyBpbiBJTkZPIGFzIHN1Y2guIFRoZSBpc3N1ZSBpcyBob3cgDQo+Pj4+IHNvbWUgd2Fu dCB0byB1c2UgQ2FsbC1JbmZvIGluc3RlYWQgb2YgYW4gSW5mbyBQYWNrYWdlLg0KPj4+Pg0KPj4+ PiBSZWdhcmRzLA0KPj4+Pg0KPj4+PiBDaHJpc3Rlcg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBP biAyNS8wOC8xNiAwMzoyMiwgInNpcGNvcmUgb24gYmVoYWxmIG9mIEJyaWFuIFJvc2VuIg0KPj4+ PiA8c2lwY29yZS1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBickBicmlhbnJvc2VuLm5l dD4gd3JvdGU6DQo+Pj4+DQo+Pj4+PiBPdmVyIGluIGVjcml0IHdlIGhhdmUgYSBkaXNhZ3JlZW1l bnQgdGhhdCByZWxhdGVzIHRvIGludGVycHJldGluZyANCj4+Pj4+IFJGQzYwODYuDQo+Pj4+Pg0K Pj4+Pj4gQmFja2dyb3VuZDoNCj4+Pj4+IFJGQzc4NTIgZGVmaW5lcyBzb21ldGhpbmcgY2FsbGVk ICJBZGRpdGlvbmFsIERhdGEiLCB3aGljaCBpcyANCj4+Pj4+IGNhcnJpZWQgaW4gZW1lcmdlbmN5 IGNhbGwgc2lnbmFsaW5nLiAgSXQncyBkYXRhIHJlbGF0ZWQgdG8gdGhlIA0KPj4+Pj4gY2FsbCwg ZS5nLiwgdGhlIGlkZW50aXR5IGFuZCBjb250YWN0IGRhdGEgb2YgdGhlIHNlcnZpY2UgcHJvdmlk ZXIgaGFuZGxpbmcgdGhlIGNhbGwuDQo+Pj4+PiBBZGRpdGlvbmFsIERhdGEgaXMgc2lnbmFsZWQg d2l0aCBhIENhbGwtSW5mbyBoZWFkZXIgZmllbGQsIHdoaWNoIA0KPj4+Pj4gY29udGFpbnMgZWl0 aGVyIGEgVVJJIHBvaW50aW5nIHRvIGEgZGF0YSBibG9jayBmZXRjaGVkIHdpdGggSFRUUFMsIA0K Pj4+Pj4gb3IgYSBDb250ZW50IEluZGlyZWN0IHJlZmVyZW5jaW5nIGEgYm9keSBwYXJ0IG9mIHRo ZSBTSVAgbWVzc2FnZS4gIA0KPj4+Pj4gSXQncyB1c3VhbGx5IHVzZWQgb24gdGhlIElOVklURSBv ZiB0aGUgZW1lcmdlbmN5IGNhbGwsIHNvIGl0IGNhbiANCj4+Pj4+IGJlIGRpc3BsYXllZCB0byB0 aGUgUFNBUCAoZW1lcmdlbmN5IGNhbGwgY2VudGVyKSBjYWxsLXRha2VyIHdoZW4gDQo+Pj4+PiB0 aGUgY2FsbCBpcyBhc3NpZ25lZC4NCj4+Pj4+DQo+Pj4+PiBTb21ldGltZXMsIHRoaXMgZGF0YSBj YW4gY2hhbmdlIGR1cmluZyBhIGNhbGwuICBUaGUgZXhhbXBsZSBpbiANCj4+Pj4+IGRpc2N1c3Np b24NCj4+Pj4+IGlzIHRlbGVtYXRpY3MgZGF0YSBpbiBhIHZlaGljbGUuICAgVGhlIHZlaGljbGUg Y2FuIHJlcG9ydCB0aGluZ3MgbGlrZQ0KPj4+Pj4gdGhlDQo+Pj4+PiBudW1iZXIgb2Ygb2NjdXBh bnRzIGFuZCBpdHMgb3JpZW50YXRpb24uICBUaGUgUFNBUCBjYW4gcmVxdWVzdCBhbiANCj4+Pj4+ IHVwZGF0ZSBtaWQgY2FsbCAoZS5nLiwgaWYgdGhlIGNhbGwgdGFrZXIgdGhpbmtzIHRoaW5ncyBt aWdodCBoYXZlIA0KPj4+Pj4gY2hhbmdlZCkuDQo+Pj4+Pg0KPj4+Pj4gSU5GTyBpcyB0aGUgY2hv c2VuIG1lY2hhbmlzbSB0byBzZW5kIHRoZSByZXF1ZXN0IGZvciB1cGRhdGUuICBUaGUgDQo+Pj4+ PiBkZXZpY2Ugd2lsbCBzZW5kIGEgcmVzcG9uc2UgdG8gdGhlIHJlcXVlc3QgKGFuIEFDSyksIHdo aWNoIGlzIGFsc28gDQo+Pj4+PiBzZW50IGluIElORk8uDQo+Pj4+PiBUaGlzIGNvbnN0aXR1dGVz IGEgd2VsbCBkZWZpbmVkIElORk8gcGFja2FnZSwgYW5kIHdpbGwgYmUgDQo+Pj4+PiByZWdpc3Rl cmVkIGluIHRoZSB1c3VhbCB3YXkuDQo+Pj4+Pg0KPj4+Pj4gVGhlIElzc3VlIGF0IGhhbmQ6DQo+ Pj4+PiBTbywgdGhlIGRpc3B1dGUgaXMgaG93IHRoZSB1cGRhdGVkIGRhdGEgaXMgc2VudCBtaWQg Y2FsbC4NCj4+Pj4+DQo+Pj4+PiBSRkM2MDg2IHNheXMNCj4+Pj4+DQo+Pj4+PiBOT1RFOiBBbiBJ TkZPIHJlcXVlc3QgY2FuIGFsc28gY29udGFpbiBvdGhlciBib2R5IHBhcnRzIHRoYXQgYXJlIA0K Pj4+Pj4gbWVhbmluZ2Z1bCB3aXRoaW4gdGhlIGNvbnRleHQgb2YgYW4gaW52aXRlIGRpYWxvZyB1 c2FnZSBidXQgYXJlIA0KPj4+Pj4gbm90IHNwZWNpZmljYWxseSBhc3NvY2lhdGVkIHdpdGggdGhl IElORk8gbWV0aG9kIGFuZCB0aGUgDQo+Pj4+PiBhcHBsaWNhdGlvbiBjb25jZXJuZWQuDQo+Pj4+ Pg0KPj4+Pj4gVGhlIGF1dGhvcnMgb2YgdGhlIGRyYWZ0IChvZiB3aGljaCBJIGFtIG9uZSkgZGVz aXJlIHRvIHVzZSB0aGUgDQo+Pj4+PiBBZGRpdGlvbmFsIERhdGEgbWVjaGFuaXNtIHRvIGNhcnJ5 IHRoZSB1cGRhdGVkIGRhdGEuICBUaGUgZGF0YSANCj4+Pj4+IGNvdWxkIGJlIHNlbnQgaW4gYW55 IGNvbnZlbmllbnQgbWVzc2FnZSwgYWx0aG91Z2ggc2luY2UgdGhlIA0KPj4+Pj4gdmVoaWNsZSBp cyBzZW5kaW5nIGFuIEFDSywgaXQncyBsaWtlbHkgZ29pbmcgdG8gZ28gb24gdGhhdC4gIFdlJ2Qg DQo+Pj4+PiBsaWtlIHRvIGFsd2F5cyBjYXJyeSB0aGUgZGF0YSBpbiB0aGUgc2FtZSB3YXkuICBJ biBhbiBJTkZPIG1lc3NhZ2UgDQo+Pj4+PiBpdCB3b3VsZCBiZSBjYXJyaWVkIHRoZSBzYW1lIGFz IGl0IGlzIGluIHRoZSBJTlZJVEUsIGFzIEFkZGl0aW9uYWwgDQo+Pj4+PiBEYXRhLiAgU2luY2Ug dGhlIElORk8gY2FycmllcyBhbiBBQ0ssIGl0IHdvdWxkIHNwZWNpZnkgdGhlIA0KPj4+Pj4gYXBw cm9wcmlhdGUgSU5GTyBwYWNrYWdlLCBhbmQgd291bGQgY29udGFpbiBhIGJvZHkgcGFydCB3aXRo IHRoZSANCj4+Pj4+IEFDSy4gIFRoZXJlIHdvdWxkIGJlIGFub3RoZXIgYm9keSBwYXJ0IGZvciB0 aGUgdXBkYXRlZCBkYXRhLCANCj4+Pj4+IHBvaW50ZWQgdG8gYnkgdGhlIENhbGwtSW5mby4NCj4+ Pj4+DQo+Pj4+PiBTb21lIGVjcml0IHBhcnRpY2lwYW50cyBzYXkgdGhhdCB0aGUgYWJvdmUgbGFu Z3VhZ2Ugb2YgNjA4NiB3b3VsZCANCj4+Pj4+IHByb2hpYml0IHRoZSBJTkZPIGZyb20gY29udGFp bmluZyBhIENhbGwtSW5mbyBoZWFkZXIgd2l0aCBhIENJRCANCj4+Pj4+IHBvaW50aW5nIHRvIGEg TUlNRSBib2R5IHBhcnQsIGJlY2F1c2UgdGhlIGRhdGEgd2FzIHJlcXVlc3RlZCBieSBhbiANCj4+ Pj4+IElORk8sIGFuZCBoZW5jZSBpcyByZWxhdGVkIHRvIHRoZSBJTkZPIHBhY2thZ2UuICBUaGV5 IHNheSB0aGF0IHRoZSANCj4+Pj4+IGRhdGEgTVVTVCBiZSBjYXJyaWVkIHdpdGggYSBib2R5IHBh cnQgYW5kIENvbnRlbnQgRGlzcG9zaXRpb24gdGhhdCANCj4+Pj4+IGlzIHBhcnQgb2YgdGhlIElO Rk8gcGFja2FnZSBkZWZpbml0aW9uLg0KPj4+Pj4NCj4+Pj4+IFRoZSBkcmFmdCBhdXRob3JzIGNs YWltIHRoaXMgNjA4NiBsYW5ndWFnZSBpc24ndCBhIHN0cmFpZ2h0amFja2V0LCANCj4+Pj4+IGFu ZCBpdCdzIHBlcmZlY3RseSBmaW5lIHRvIGNhcnJ5IHRoZSBkYXRhIHJlZmVyZW5jZWQgYnkgYSAN Cj4+Pj4+IENhbGwtSW5mbyB3aXRoIGEgQ29udGVudCBJbmRpcmVjdCBib2R5IHBhcnQgdXNpbmcg dGhlIHNhbWUgTUlNRSB0eXBlIGFuZCBDb250ZW50DQo+Pj4+PiBEaXNwb3NpdGlvbiBhcyBpdCB3 b3VsZCBpbiBhbiBJTlZJVEUuICAgV2hlbiB0aGUgdXBkYXRlZCBkYXRhIGlzIHNlbnQNCj4+Pj4+ IGluDQo+Pj4+PiBJTkZPLCBpdCdzIGJlY2F1c2UgdGhlIElORk8gaXMgYSBjb252ZW5pZW50IG1l c3NhZ2UgKHNpbmNlIGl0J3MgDQo+Pj4+PiBiZWluZyBzZW50IHRvIGNhcnJ5IHRoZSBBQ0spLg0K Pj4+Pj4NCj4+Pj4+IE1lY2hhbmljYWxseSwgYm90aCBtZWNoYW5pc21zIGNhbiBiZSBtYWRlIHRv IHdvcmsuICBUaGUgYm9keSBwYXJ0cyANCj4+Pj4+IHdvdWxkIGJlIGxhYmVsZWQgYXBwcm9wcmlh dGVseSBhbmQgdGhlcmUgd291bGQgYmUgbm8gY29uZnVzaW9uIA0KPj4+Pj4gYWJvdXQgd2hhdCB0 aGV5IG1lYW4gb3IgaG93IHRoZXkgd291bGQgYmUgaW50ZXJwcmV0ZWQuICBJdCdzIA0KPj4+Pj4g cmVhbGx5IG9ubHkgd2hldGhlciB0aGUgQ2FsbC1JbmZvIGhlYWRlciBpcyBwcmVzZW50IGFuZCB3 aGF0IHRoZSANCj4+Pj4+IE1JTUUgdHlwZSBhbmQgQ29udGVudCBEaXNwb3NpdGlvbiB0aGUgYm9k eSBwYXJ0IGNvbnRhaW5pbmcgdGhlIA0KPj4+Pj4gZGF0YSB3b3VsZCBiZS4gIEluIHRoZSBhdXRo b3IncyBwcmVmZXJyZWQgd2F5LCBpdCB3b3VsZCBiZSB0aGUgDQo+Pj4+PiBNSU1FIHR5cGUgYW5k IENvbnRlbnQgRGlzcG9zaXRpb24gb2YgdGhlIENhbGwtSW5mbyBhbmQgaW4gdGhlIA0KPj4+Pj4g b3RoZXIgcG9pbnQgb2YgdmlldyBpdCB3b3VsZCBiZSB0aGUgTUlNRSB0eXBlIGFuZCBDb250ZW50 IA0KPj4+Pj4gRGlzcG9zaXRpb24gb2YgdGhlIElORk8gcGFja2FnZS4NCj4+Pj4+DQo+Pj4+PiBQ bGVhc2UgaWdub3JlIHlvdXIgcGVyc29uYWwgcHJlZmVyZW5jZSBmb3Igd2hldGhlciB5b3UgdGhp bmsgaXQgDQo+Pj4+PiBvdWdodCB0byBnbyBpbiB0aGUgSU5GTyBvciBub3QsIGFuZCBwbGVhc2Ug aGVscCB1cyBpbnRlcnByZXQgNjA4NjogDQo+Pj4+PiBkb2VzIHRoZSBkYXRhIEhBVkUgdG8gZ28g aW4gYW4gSU5GTyBib2R5IHBhcnQgb3IgY2FuIGl0IGJlIHNlbnQgaW4gDQo+Pj4+PiBhIENhbGwt SW5mbyBib2R5IHBhcnQ/DQo+Pj4+Pg0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IHNpcGNvcmUgbWFpbGluZyBsaXN0DQo+Pj4+PiBz aXBjb3JlQGlldGYub3JnDQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NpcGNvcmUNCj4+Pj4NCj4+Pg0KPj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4gc2lwY29y ZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNv cmUNCj4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CnNpcGNvcmUgbWFpbGluZyBsaXN0DQpzaXBjb3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg== From nobody Thu Aug 25 08:34:34 2016 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 0CCC412D1BC for ; Thu, 25 Aug 2016 08:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BE45ecvsSip for ; Thu, 25 Aug 2016 08:34:22 -0700 (PDT) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FFD012D1C1 for ; Thu, 25 Aug 2016 08:34:13 -0700 (PDT) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-11v.sys.comcast.net with SMTP id cwfHb1wBZlSxscwfUbP0SA; Thu, 25 Aug 2016 15:34:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-20v.sys.comcast.net with SMTP id cwfTbcHuaZSN2cwfUb8v9Q; Thu, 25 Aug 2016 15:34:12 +0000 To: Christer Holmberg , "sipcore@ietf.org" References: <76CCBFA5-8D53-4B1E-A495-4A18AB081384@brianrosen.net> <05240A95-8319-4555-8B46-FA18B6C27883@brianrosen.net> <5d462933-e3c0-b3a3-958d-5c9d1e86d854@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC60A10@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: Date: Thu, 25 Aug 2016 11:34:11 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC60A10@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfDOpBRz4muslbpcdQrfZaRMsTixDFngx5aU8Rj4hWM0V6kI+9nGi3P+YC145MVIG3V0TApzjAaEJryU4wL5BU8oYi5YuBzENqdWmmEoSgUGamxBNqqSV e1j4b9xrVPqtYJDZAYXQSo5MNvG+shOjqErVeFmJbJS49ih7nFBJgerGMQyQWDG//weTvh9oswoa0P9TI1guRr6/Bn3GN16cALyEVwvGyxhO7opxCTRdjAkq Archived-At: Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 15:34:24 -0000 On 8/25/16 10:58 AM, Christer Holmberg wrote: > Paul, a generic question, which might help me understand your view on ecall: in your opinion, when (if ever) is usage of an Info Package required? I guess I would phrase it this way: If you have a need to transmit some information via a sip session, then you should consider all the available mechanisms sip has, and decide if there is some combination of existing mechanisms that meets your need. The following are some of the available mechanisms: - new event packages - new info packages - new qualifying options with call-info, alert-info, error-info - newly defined header field parameters - new defined header fields Many of these mechanisms have their own rules for what sorts of new usage are appropriate. Others do not, and are probably deficient because of that. For those, the bar is generally the need to get a RFC approved. INFO is notable because the bar is pretty low (Specification Required). So some may choose it for its ease. When choosing among the options, you have to consider what the approval processes will be for each, and that the reviewers will probably ask if you have considered alternative approaches. For instance Geolocation was done with a new header field that sometimes references a separate body part. That raised a higher hurdle to get over than using an info package. But it was deemed worth it since it had needs that couldn't be met by info packages. In general there are likely to be multiple options available for almost anything you want to do. And then it will come down to weighing the pros/cons. Thanks, Paul > Regards, > > Christer > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 25 August 2016 17:32 > To: sipcore@ietf.org > Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? > > On 8/25/16 9:26 AM, Brian Rosen wrote: >> Yes, I’m saying that the ACK satisfies the 6086 use of INFO, and that it’s okay to send the data with Call-Info. >> >> Yes, I’m agreeing that there is a relationship between the INFO package and the data. >> >> Yes, I’m disagreeing with your interpretation of the language. >> >> So, now, what say you sipcore? > > I think the main point of bringing this to sipcore is to get some fresh input into this discussion. Since I have been party to the discussion over in ecrit I don't bring anything fresh here. But for completeness I will register my opinion here too. > > IMO this is not a question about whether the proposed usage is valid according to 6086 and other rfcs. (I think it is quite clear that it > *is* valid.) Rather this is simply a question of what is the best design for the desired functionality. As such I don't think it really needs to be settled in sipcore. > > But I am happy to check if anybody has a different perspective on this. > > Thanks, > Paul > >> Brian >> >> >>> On Aug 25, 2016, at 9:14 AM, Christer Holmberg wrote: >>> >>> Hi, >>> >>>> We’re agreeing that there is a relationship between the command and >>>> the data. >>>> >>>> We’re suggesting that we don’t have to be anal about the language >>>> and as long as there is an INFO package, and a body part that has >>>> the ACK which is an INFO body part, that the cited language doesn’t >>>> compel us to use the INFO body part to transport the data, the >>>> Call-Info mechanism is acceptable. >>>> >>>> No one is suggesting that we update 6086, and we agree that 7852 did >>>> not update 6086. >>>> >>>> It’s just whether that language prohibits use of the Call-Info to >>>> carry the data when it was prompted by the INFO package request, and >>>> accompanies the INFO package ACK. >>> >>> You seem to suggest that, just because you use an Info Package for >>> sending SOME of the ecall related information (the request and ACK), >>> that allows you to send the rest of the ecall related information >>> (the data content) without using an Info Package. I really don’t see >>> how you can parse the cited text in that way. The cited text says >>> that information associated with the application shall be sent using >>> an Info Package. And, both the ACK and the requested data content are >>> associated with the ecall application. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> >>>> >>>> Brian >>>> >>>>> On Aug 25, 2016, at 2:00 AM, Christer Holmberg >>>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I¹m glad this is brought to SIPCORE. As one of the info package >>>>> proponents, please let me clarify my arguments. >>>>> >>>>> The 6086 text that Brian copied says ³but are not specifically >>>>> associated with the INFO method and the application concerned². >>>>> >>>>> I claim that the updated data IS associated with the application >>>>> concerned (ecall). The updated data is requested by the ecall >>>>> application, and the delivered updated data is consumed by the >>>>> ecall application. The updated data is NOT some >>>>> non-ecall-application-related information that is piggybacked in a >>>>> "convenient INFO message" that happens to be sent by the ecall >>>>> application for some other purpose. >>>>> >>>>> (In addition, the updated data is NOT associated with a legacy >>>>> (pre-6086) >>>>> INFO usage, which could justify not using an Info Package. I do >>>>> want to point out that nobody has claimed that the updated data >>>>> would be associated with legacy INFO, but just for completeness) >>>>> >>>>> RFC 7852 does define a mechanism for transporting data, using >>>>> Call-Info etc. But, 7852 does not update 6086, nor can 7852 >>>>> override rules and procedures associated with individual SIP >>>>> methods (INFO in this case). I also pointed this out before 7852 >>>>> was published, but was told that it¹s too late to change it >>>>> (granted, the draft was in the RFC editor¹s queue). >>>>> >>>>> Finally, again for completeness, I want to point out that 6086 does >>>>> not prevent including Call-Info in INFO as such. The issue is how >>>>> some want to use Call-Info instead of an Info Package. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> >>>>> On 25/08/16 03:22, "sipcore on behalf of Brian Rosen" >>>>> wrote: >>>>> >>>>>> Over in ecrit we have a disagreement that relates to interpreting >>>>>> RFC6086. >>>>>> >>>>>> Background: >>>>>> RFC7852 defines something called "Additional Data", which is >>>>>> carried in emergency call signaling. It's data related to the >>>>>> call, e.g., the identity and contact data of the service provider handling the call. >>>>>> Additional Data is signaled with a Call-Info header field, which >>>>>> contains either a URI pointing to a data block fetched with HTTPS, >>>>>> or a Content Indirect referencing a body part of the SIP message. >>>>>> It's usually used on the INVITE of the emergency call, so it can >>>>>> be displayed to the PSAP (emergency call center) call-taker when >>>>>> the call is assigned. >>>>>> >>>>>> Sometimes, this data can change during a call. The example in >>>>>> discussion >>>>>> is telematics data in a vehicle. The vehicle can report things like >>>>>> the >>>>>> number of occupants and its orientation. The PSAP can request an >>>>>> update mid call (e.g., if the call taker thinks things might have >>>>>> changed). >>>>>> >>>>>> INFO is the chosen mechanism to send the request for update. The >>>>>> device will send a response to the request (an ACK), which is also >>>>>> sent in INFO. >>>>>> This constitutes a well defined INFO package, and will be >>>>>> registered in the usual way. >>>>>> >>>>>> The Issue at hand: >>>>>> So, the dispute is how the updated data is sent mid call. >>>>>> >>>>>> RFC6086 says >>>>>> >>>>>> NOTE: An INFO request can also contain other body parts that are >>>>>> meaningful within the context of an invite dialog usage but are >>>>>> not specifically associated with the INFO method and the >>>>>> application concerned. >>>>>> >>>>>> The authors of the draft (of which I am one) desire to use the >>>>>> Additional Data mechanism to carry the updated data. The data >>>>>> could be sent in any convenient message, although since the >>>>>> vehicle is sending an ACK, it's likely going to go on that. We'd >>>>>> like to always carry the data in the same way. In an INFO message >>>>>> it would be carried the same as it is in the INVITE, as Additional >>>>>> Data. Since the INFO carries an ACK, it would specify the >>>>>> appropriate INFO package, and would contain a body part with the >>>>>> ACK. There would be another body part for the updated data, >>>>>> pointed to by the Call-Info. >>>>>> >>>>>> Some ecrit participants say that the above language of 6086 would >>>>>> prohibit the INFO from containing a Call-Info header with a CID >>>>>> pointing to a MIME body part, because the data was requested by an >>>>>> INFO, and hence is related to the INFO package. They say that the >>>>>> data MUST be carried with a body part and Content Disposition that >>>>>> is part of the INFO package definition. >>>>>> >>>>>> The draft authors claim this 6086 language isn't a straightjacket, >>>>>> and it's perfectly fine to carry the data referenced by a >>>>>> Call-Info with a Content Indirect body part using the same MIME type and Content >>>>>> Disposition as it would in an INVITE. When the updated data is sent >>>>>> in >>>>>> INFO, it's because the INFO is a convenient message (since it's >>>>>> being sent to carry the ACK). >>>>>> >>>>>> Mechanically, both mechanisms can be made to work. The body parts >>>>>> would be labeled appropriately and there would be no confusion >>>>>> about what they mean or how they would be interpreted. It's >>>>>> really only whether the Call-Info header is present and what the >>>>>> MIME type and Content Disposition the body part containing the >>>>>> data would be. In the author's preferred way, it would be the >>>>>> MIME type and Content Disposition of the Call-Info and in the >>>>>> other point of view it would be the MIME type and Content >>>>>> Disposition of the INFO package. >>>>>> >>>>>> Please ignore your personal preference for whether you think it >>>>>> ought to go in the INFO or not, and please help us interpret 6086: >>>>>> does the data HAVE to go in an INFO body part or can it be sent in >>>>>> a Call-Info body part? >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Thu Aug 25 08:40:57 2016 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 BDC6812D845 for ; Thu, 25 Aug 2016 08:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQBV0BJVwpVy for ; Thu, 25 Aug 2016 08:40:52 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23CBC12D190 for ; Thu, 25 Aug 2016 08:40:32 -0700 (PDT) X-AuditID: c1b4fb3a-c7bff700000009bd-4e-57bf116ff4be Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by (Symantec Mail Security) with SMTP id BC.51.02493.F611FB75; Thu, 25 Aug 2016 17:40:31 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0301.000; Thu, 25 Aug 2016 17:40:30 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? Thread-Index: AQHR/t2KCnVeSlQa/k+Sxwkc4yebnqBZxASQ///o+oCAACKDMA== Date: Thu, 25 Aug 2016 15:40:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC61D10@ESESSMB209.ericsson.se> References: <76CCBFA5-8D53-4B1E-A495-4A18AB081384@brianrosen.net> <05240A95-8319-4555-8B46-FA18B6C27883@brianrosen.net> <5d462933-e3c0-b3a3-958d-5c9d1e86d854@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC60A10@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM2K7rm6+4P5wg7cfJC1WbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj674m9oKm+or2D/vYGhgfVHcxcnJICJhI NB3/wNbFyMUhJLCeUeL5g3vMEM4SRon5sycDZTg42AQsJLr/aYM0iAgESlxdMoEZxBYWSJSY 0DeXGSKeJDFn0x4o20li+Y8uNhCbRUBVYsb7BjCbV8BX4tCrlYwQ898yS1zffJwVJMEp4CBx fsItdhCbUUBM4vupNUwgNrOAuMStJ/OZIC4VkFiy5zwzhC0q8fLxP1YIW0lixfZLjCB3Mgto SqzfpQ/RqigxpfshO8ReQYmTM5+wTGAUmYVk6iyEjllIOmYh6VjAyLKKUbQ4tbg4N93ISC+1 KDO5uDg/Ty8vtWQTIzAaDm75bbWD8eBzx0OMAhyMSjy8Cx7sDRdiTSwrrsw9xCjBwawkwqvJ tz9ciDclsbIqtSg/vqg0J7X4EKM0B4uSOK//S8VwIYH0xJLU7NTUgtQimCwTB6dUA6NOaMKp WlsPhqXXOpeuTVrnazJnnoRx3ETT2piTuueYP3+Z6N474d3Wbavjomw3nubLW5wX5lVZrVaf xPDXtD77yfom35Lr5rcO6j79n/FyXlpTSYv9VBcmeYejX2P0jtg8UYs+Le/WcvqxrXJ0W/qX 9GVKjb69+Yd0WLQsOQzbzk02XHUrUomlOCPRUIu5qDgRAMmI6TKCAgAA Archived-At: Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 15:40:55 -0000 SGkgUGF1bCwNCg0KSSBhbSBub3QgdGFsa2luZyBhYm91dCB0aGUgY3JpdGVyaWEgZm9yIHNlbGVj dGluZyBJTkZPIGluIHRoZSBmaXJzdCBwbGFjZSAoaW5zdGVhZCBvZiBlLmcuIGV2ZW50IHBhY2th Z2VzKS4NCg0KSSBhbSBhc2tpbmc6IGFzc3VtaW5nIHlvdSBoYXZlIGRldGVybWluZWQgKGJhc2Vk IG9uIHdoYXRldmVyIGNyaXRlcmlhKSB0aGF0IHRoZSBJTkZPIG1lc3NhZ2UgaXMgdGhlIG1vc3Qg YXBwcm9wcmlhdGUgbWVjaGFuaXNtLCB3aGVuIGFyZSB5b3UgcmVxdWlyZWQgdG8gdXNlIEluZm8g UGFja2FnZT8NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IFBhdWwgS3l6aXZhdCBbbWFpbHRvOnBreXppdmF0QGFsdW0ubWl0LmVkdV0g DQpTZW50OiAyNSBBdWd1c3QgMjAxNiAxODozNA0KVG86IENocmlzdGVyIEhvbG1iZXJnIDxjaHJp c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+OyBzaXBjb3JlQGlldGYub3JnDQpTdWJqZWN0OiBS ZTogW3NpcGNvcmVdIENhbiBhbiBJTkZPIGNvbnRhaW4gYSBib2R5IHJlbGF0ZWQgdG8sIGJ1dCBu b3QgcGFydCBvZiB0aGUgSU5GTyBwYWNrYWdlPw0KDQpPbiA4LzI1LzE2IDEwOjU4IEFNLCBDaHJp c3RlciBIb2xtYmVyZyB3cm90ZToNCj4gUGF1bCwgYSBnZW5lcmljIHF1ZXN0aW9uLCB3aGljaCBt aWdodCBoZWxwIG1lIHVuZGVyc3RhbmQgeW91ciB2aWV3IG9uIGVjYWxsOiBpbiB5b3VyIG9waW5p b24sIHdoZW4gKGlmIGV2ZXIpIGlzIHVzYWdlIG9mIGFuIEluZm8gUGFja2FnZSByZXF1aXJlZD8N Cg0KSSBndWVzcyBJIHdvdWxkIHBocmFzZSBpdCB0aGlzIHdheToNCg0KSWYgeW91IGhhdmUgYSBu ZWVkIHRvIHRyYW5zbWl0IHNvbWUgaW5mb3JtYXRpb24gdmlhIGEgc2lwIHNlc3Npb24sIHRoZW4g eW91IHNob3VsZCBjb25zaWRlciBhbGwgdGhlIGF2YWlsYWJsZSBtZWNoYW5pc21zIHNpcCBoYXMs IGFuZCBkZWNpZGUgaWYgdGhlcmUgaXMgc29tZSBjb21iaW5hdGlvbiBvZiBleGlzdGluZyBtZWNo YW5pc21zIHRoYXQgbWVldHMgeW91ciBuZWVkLg0KDQpUaGUgZm9sbG93aW5nIGFyZSBzb21lIG9m IHRoZSBhdmFpbGFibGUgbWVjaGFuaXNtczoNCg0KLSBuZXcgZXZlbnQgcGFja2FnZXMNCi0gbmV3 IGluZm8gcGFja2FnZXMNCi0gbmV3IHF1YWxpZnlpbmcgb3B0aW9ucyB3aXRoIGNhbGwtaW5mbywg YWxlcnQtaW5mbywgZXJyb3ItaW5mbw0KLSBuZXdseSBkZWZpbmVkIGhlYWRlciBmaWVsZCBwYXJh bWV0ZXJzDQotIG5ldyBkZWZpbmVkIGhlYWRlciBmaWVsZHMNCg0KTWFueSBvZiB0aGVzZSBtZWNo YW5pc21zIGhhdmUgdGhlaXIgb3duIHJ1bGVzIGZvciB3aGF0IHNvcnRzIG9mIG5ldyB1c2FnZSBh cmUgYXBwcm9wcmlhdGUuIE90aGVycyBkbyBub3QsIGFuZCBhcmUgcHJvYmFibHkgZGVmaWNpZW50 IGJlY2F1c2Ugb2YgdGhhdC4gRm9yIHRob3NlLCB0aGUgYmFyIGlzIGdlbmVyYWxseSB0aGUgbmVl ZCB0byBnZXQgYSBSRkMgYXBwcm92ZWQuDQoNCklORk8gaXMgbm90YWJsZSBiZWNhdXNlIHRoZSBi YXIgaXMgcHJldHR5IGxvdyAoU3BlY2lmaWNhdGlvbiBSZXF1aXJlZCkuIA0KU28gc29tZSBtYXkg Y2hvb3NlIGl0IGZvciBpdHMgZWFzZS4NCg0KV2hlbiBjaG9vc2luZyBhbW9uZyB0aGUgb3B0aW9u cywgeW91IGhhdmUgdG8gY29uc2lkZXIgd2hhdCB0aGUgYXBwcm92YWwgcHJvY2Vzc2VzIHdpbGwg YmUgZm9yIGVhY2gsIGFuZCB0aGF0IHRoZSByZXZpZXdlcnMgd2lsbCBwcm9iYWJseSBhc2sgaWYg eW91IGhhdmUgY29uc2lkZXJlZCBhbHRlcm5hdGl2ZSBhcHByb2FjaGVzLg0KDQpGb3IgaW5zdGFu Y2UgR2VvbG9jYXRpb24gd2FzIGRvbmUgd2l0aCBhIG5ldyBoZWFkZXIgZmllbGQgdGhhdCBzb21l dGltZXMgcmVmZXJlbmNlcyBhIHNlcGFyYXRlIGJvZHkgcGFydC4gVGhhdCByYWlzZWQgYSBoaWdo ZXIgaHVyZGxlIHRvIGdldCBvdmVyIHRoYW4gdXNpbmcgYW4gaW5mbyBwYWNrYWdlLiBCdXQgaXQg d2FzIGRlZW1lZCB3b3J0aCBpdCBzaW5jZSBpdCBoYWQgbmVlZHMgdGhhdCBjb3VsZG4ndCBiZSBt ZXQgYnkgaW5mbyBwYWNrYWdlcy4NCg0KSW4gZ2VuZXJhbCB0aGVyZSBhcmUgbGlrZWx5IHRvIGJl IG11bHRpcGxlIG9wdGlvbnMgYXZhaWxhYmxlIGZvciBhbG1vc3QgYW55dGhpbmcgeW91IHdhbnQg dG8gZG8uIEFuZCB0aGVuIGl0IHdpbGwgY29tZSBkb3duIHRvIHdlaWdoaW5nIHRoZSBwcm9zL2Nv bnMuDQoNCglUaGFua3MsDQoJUGF1bA0KDQo+IFJlZ2FyZHMsDQo+DQo+IENocmlzdGVyDQo+DQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHNpcGNvcmUgW21haWx0bzpzaXBj b3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQYXVsIA0KPiBLeXppdmF0DQo+IFNl bnQ6IDI1IEF1Z3VzdCAyMDE2IDE3OjMyDQo+IFRvOiBzaXBjb3JlQGlldGYub3JnDQo+IFN1Ympl Y3Q6IFJlOiBbc2lwY29yZV0gQ2FuIGFuIElORk8gY29udGFpbiBhIGJvZHkgcmVsYXRlZCB0bywg YnV0IG5vdCBwYXJ0IG9mIHRoZSBJTkZPIHBhY2thZ2U/DQo+DQo+IE9uIDgvMjUvMTYgOToyNiBB TSwgQnJpYW4gUm9zZW4gd3JvdGU6DQo+PiBZZXMsIEnigJltIHNheWluZyB0aGF0IHRoZSBBQ0sg c2F0aXNmaWVzIHRoZSA2MDg2IHVzZSBvZiBJTkZPLCBhbmQgdGhhdCBpdOKAmXMgb2theSB0byBz ZW5kIHRoZSBkYXRhIHdpdGggQ2FsbC1JbmZvLg0KPj4NCj4+IFllcywgSeKAmW0gYWdyZWVpbmcg dGhhdCB0aGVyZSBpcyBhIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBJTkZPIHBhY2thZ2UgYW5k IHRoZSBkYXRhLg0KPj4NCj4+IFllcywgSeKAmW0gZGlzYWdyZWVpbmcgd2l0aCB5b3VyIGludGVy cHJldGF0aW9uIG9mIHRoZSBsYW5ndWFnZS4NCj4+DQo+PiBTbywgbm93LCB3aGF0IHNheSB5b3Ug c2lwY29yZT8NCj4NCj4gSSB0aGluayB0aGUgbWFpbiBwb2ludCBvZiBicmluZ2luZyB0aGlzIHRv IHNpcGNvcmUgaXMgdG8gZ2V0IHNvbWUgZnJlc2ggaW5wdXQgaW50byB0aGlzIGRpc2N1c3Npb24u IFNpbmNlIEkgaGF2ZSBiZWVuIHBhcnR5IHRvIHRoZSBkaXNjdXNzaW9uIG92ZXIgaW4gZWNyaXQg SSBkb24ndCBicmluZyBhbnl0aGluZyBmcmVzaCBoZXJlLiBCdXQgZm9yIGNvbXBsZXRlbmVzcyBJ IHdpbGwgcmVnaXN0ZXIgbXkgb3BpbmlvbiBoZXJlIHRvby4NCj4NCj4gSU1PIHRoaXMgaXMgbm90 IGEgcXVlc3Rpb24gYWJvdXQgd2hldGhlciB0aGUgcHJvcG9zZWQgdXNhZ2UgaXMgdmFsaWQgDQo+ IGFjY29yZGluZyB0byA2MDg2IGFuZCBvdGhlciByZmNzLiAoSSB0aGluayBpdCBpcyBxdWl0ZSBj bGVhciB0aGF0IGl0DQo+ICppcyogdmFsaWQuKSBSYXRoZXIgdGhpcyBpcyBzaW1wbHkgYSBxdWVz dGlvbiBvZiB3aGF0IGlzIHRoZSBiZXN0IGRlc2lnbiBmb3IgdGhlIGRlc2lyZWQgZnVuY3Rpb25h bGl0eS4gQXMgc3VjaCBJIGRvbid0IHRoaW5rIGl0IHJlYWxseSBuZWVkcyB0byBiZSBzZXR0bGVk IGluIHNpcGNvcmUuDQo+DQo+IEJ1dCBJIGFtIGhhcHB5IHRvIGNoZWNrIGlmIGFueWJvZHkgaGFz IGEgZGlmZmVyZW50IHBlcnNwZWN0aXZlIG9uIHRoaXMuDQo+DQo+IAlUaGFua3MsDQo+IAlQYXVs DQo+DQo+PiBCcmlhbg0KPj4NCj4+DQo+Pj4gT24gQXVnIDI1LCAyMDE2LCBhdCA5OjE0IEFNLCBD aHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPiB3cm90ZToN Cj4+Pg0KPj4+IEhpLA0KPj4+DQo+Pj4+IFdl4oCZcmUgYWdyZWVpbmcgdGhhdCB0aGVyZSBpcyBh IHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBjb21tYW5kIGFuZCANCj4+Pj4gdGhlIGRhdGEuDQo+ Pj4+DQo+Pj4+IFdl4oCZcmUgc3VnZ2VzdGluZyB0aGF0IHdlIGRvbuKAmXQgaGF2ZSB0byBiZSBh bmFsIGFib3V0IHRoZSBsYW5ndWFnZSANCj4+Pj4gYW5kIGFzIGxvbmcgYXMgdGhlcmUgaXMgYW4g SU5GTyBwYWNrYWdlLCBhbmQgYSBib2R5IHBhcnQgdGhhdCBoYXMgDQo+Pj4+IHRoZSBBQ0sgd2hp Y2ggaXMgYW4gSU5GTyBib2R5IHBhcnQsIHRoYXQgdGhlIGNpdGVkIGxhbmd1YWdlIGRvZXNu4oCZ dCANCj4+Pj4gY29tcGVsIHVzIHRvIHVzZSB0aGUgSU5GTyBib2R5IHBhcnQgdG8gdHJhbnNwb3J0 IHRoZSBkYXRhLCB0aGUgDQo+Pj4+IENhbGwtSW5mbyBtZWNoYW5pc20gaXMgYWNjZXB0YWJsZS4N Cj4+Pj4NCj4+Pj4gTm8gb25lIGlzIHN1Z2dlc3RpbmcgdGhhdCB3ZSB1cGRhdGUgNjA4NiwgYW5k IHdlIGFncmVlIHRoYXQgNzg1MiANCj4+Pj4gZGlkIG5vdCB1cGRhdGUgNjA4Ni4NCj4+Pj4NCj4+ Pj4gSXTigJlzIGp1c3Qgd2hldGhlciB0aGF0IGxhbmd1YWdlIHByb2hpYml0cyB1c2Ugb2YgdGhl IENhbGwtSW5mbyB0byANCj4+Pj4gY2FycnkgdGhlIGRhdGEgd2hlbiBpdCB3YXMgcHJvbXB0ZWQg YnkgdGhlIElORk8gcGFja2FnZSByZXF1ZXN0LCANCj4+Pj4gYW5kIGFjY29tcGFuaWVzIHRoZSBJ TkZPIHBhY2thZ2UgQUNLLg0KPj4+DQo+Pj4gWW91IHNlZW0gdG8gc3VnZ2VzdCB0aGF0LCBqdXN0 IGJlY2F1c2UgeW91IHVzZSBhbiBJbmZvIFBhY2thZ2UgZm9yIA0KPj4+IHNlbmRpbmcgU09NRSBv ZiB0aGUgZWNhbGwgcmVsYXRlZCBpbmZvcm1hdGlvbiAodGhlIHJlcXVlc3QgYW5kIEFDSyksIA0K Pj4+IHRoYXQgYWxsb3dzIHlvdSB0byBzZW5kIHRoZSByZXN0IG9mIHRoZSBlY2FsbCByZWxhdGVk IGluZm9ybWF0aW9uIA0KPj4+ICh0aGUgZGF0YSBjb250ZW50KSB3aXRob3V0IHVzaW5nIGFuIElu Zm8gUGFja2FnZS4gSSByZWFsbHkgZG9u4oCZdCBzZWUgDQo+Pj4gaG93IHlvdSBjYW4gcGFyc2Ug dGhlIGNpdGVkIHRleHQgaW4gdGhhdCB3YXkuIFRoZSBjaXRlZCB0ZXh0IHNheXMgDQo+Pj4gdGhh dCBpbmZvcm1hdGlvbiBhc3NvY2lhdGVkIHdpdGggdGhlIGFwcGxpY2F0aW9uIHNoYWxsIGJlIHNl bnQgdXNpbmcgDQo+Pj4gYW4gSW5mbyBQYWNrYWdlLiBBbmQsIGJvdGggdGhlIEFDSyBhbmQgdGhl IHJlcXVlc3RlZCBkYXRhIGNvbnRlbnQgDQo+Pj4gYXJlIGFzc29jaWF0ZWQgd2l0aCB0aGUgZWNh bGwgYXBwbGljYXRpb24uDQo+Pj4NCj4+PiBSZWdhcmRzLA0KPj4+DQo+Pj4gQ2hyaXN0ZXINCj4+ Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4+DQo+Pj4+IEJyaWFuDQo+Pj4+DQo+Pj4+PiBPbiBB dWcgMjUsIDIwMTYsIGF0IDI6MDAgQU0sIENocmlzdGVyIEhvbG1iZXJnIA0KPj4+Pj4gPGNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+Pj4+Pg0KPj4+Pj4gSGksDQo+Pj4+ Pg0KPj4+Pj4gScK5bSBnbGFkIHRoaXMgaXMgYnJvdWdodCB0byBTSVBDT1JFLiBBcyBvbmUgb2Yg dGhlIGluZm8gcGFja2FnZSANCj4+Pj4+IHByb3BvbmVudHMsIHBsZWFzZSBsZXQgbWUgY2xhcmlm eSBteSBhcmd1bWVudHMuDQo+Pj4+Pg0KPj4+Pj4gVGhlIDYwODYgdGV4dCB0aGF0IEJyaWFuIGNv cGllZCBzYXlzIMKzYnV0IGFyZSBub3Qgc3BlY2lmaWNhbGx5IA0KPj4+Pj4gYXNzb2NpYXRlZCB3 aXRoIHRoZSBJTkZPIG1ldGhvZCBhbmQgdGhlIGFwcGxpY2F0aW9uIGNvbmNlcm5lZMKyLg0KPj4+ Pj4NCj4+Pj4+IEkgY2xhaW0gdGhhdCB0aGUgdXBkYXRlZCBkYXRhIElTIGFzc29jaWF0ZWQgd2l0 aCB0aGUgYXBwbGljYXRpb24gDQo+Pj4+PiBjb25jZXJuZWQgKGVjYWxsKS4gVGhlIHVwZGF0ZWQg ZGF0YSBpcyByZXF1ZXN0ZWQgYnkgdGhlIGVjYWxsIA0KPj4+Pj4gYXBwbGljYXRpb24sIGFuZCB0 aGUgZGVsaXZlcmVkIHVwZGF0ZWQgZGF0YSBpcyBjb25zdW1lZCBieSB0aGUgDQo+Pj4+PiBlY2Fs bCBhcHBsaWNhdGlvbi4gVGhlIHVwZGF0ZWQgZGF0YSBpcyBOT1Qgc29tZSANCj4+Pj4+IG5vbi1l Y2FsbC1hcHBsaWNhdGlvbi1yZWxhdGVkIGluZm9ybWF0aW9uIHRoYXQgaXMgcGlnZ3liYWNrZWQg aW4gYSANCj4+Pj4+ICJjb252ZW5pZW50IElORk8gbWVzc2FnZSIgdGhhdCBoYXBwZW5zIHRvIGJl IHNlbnQgYnkgdGhlIGVjYWxsIA0KPj4+Pj4gYXBwbGljYXRpb24gZm9yIHNvbWUgb3RoZXIgcHVy cG9zZS4NCj4+Pj4+DQo+Pj4+PiAoSW4gYWRkaXRpb24sIHRoZSB1cGRhdGVkIGRhdGEgaXMgTk9U IGFzc29jaWF0ZWQgd2l0aCBhIGxlZ2FjeQ0KPj4+Pj4gKHByZS02MDg2KQ0KPj4+Pj4gSU5GTyB1 c2FnZSwgd2hpY2ggY291bGQganVzdGlmeSBub3QgdXNpbmcgYW4gSW5mbyBQYWNrYWdlLiBJIGRv IA0KPj4+Pj4gd2FudCB0byBwb2ludCBvdXQgdGhhdCBub2JvZHkgaGFzIGNsYWltZWQgdGhhdCB0 aGUgdXBkYXRlZCBkYXRhIA0KPj4+Pj4gd291bGQgYmUgYXNzb2NpYXRlZCB3aXRoIGxlZ2FjeSBJ TkZPLCBidXQganVzdCBmb3IgY29tcGxldGVuZXNzKQ0KPj4+Pj4NCj4+Pj4+IFJGQyA3ODUyIGRv ZXMgZGVmaW5lIGEgbWVjaGFuaXNtIGZvciB0cmFuc3BvcnRpbmcgZGF0YSwgdXNpbmcgDQo+Pj4+ PiBDYWxsLUluZm8gZXRjLiBCdXQsIDc4NTIgZG9lcyBub3QgdXBkYXRlIDYwODYsIG5vciBjYW4g Nzg1MiANCj4+Pj4+IG92ZXJyaWRlIHJ1bGVzIGFuZCBwcm9jZWR1cmVzIGFzc29jaWF0ZWQgd2l0 aCBpbmRpdmlkdWFsIFNJUCANCj4+Pj4+IG1ldGhvZHMgKElORk8gaW4gdGhpcyBjYXNlKS4gSSBh bHNvIHBvaW50ZWQgdGhpcyBvdXQgYmVmb3JlIDc4NTIgDQo+Pj4+PiB3YXMgcHVibGlzaGVkLCBi dXQgd2FzIHRvbGQgdGhhdCBpdMK5cyB0b28gbGF0ZSB0byBjaGFuZ2UgaXQgDQo+Pj4+PiAoZ3Jh bnRlZCwgdGhlIGRyYWZ0IHdhcyBpbiB0aGUgUkZDIGVkaXRvcsK5cyBxdWV1ZSkuDQo+Pj4+Pg0K Pj4+Pj4gRmluYWxseSwgYWdhaW4gZm9yIGNvbXBsZXRlbmVzcywgSSB3YW50IHRvIHBvaW50IG91 dCB0aGF0IDYwODYgDQo+Pj4+PiBkb2VzIG5vdCBwcmV2ZW50IGluY2x1ZGluZyBDYWxsLUluZm8g aW4gSU5GTyBhcyBzdWNoLiBUaGUgaXNzdWUgaXMgDQo+Pj4+PiBob3cgc29tZSB3YW50IHRvIHVz ZSBDYWxsLUluZm8gaW5zdGVhZCBvZiBhbiBJbmZvIFBhY2thZ2UuDQo+Pj4+Pg0KPj4+Pj4gUmVn YXJkcywNCj4+Pj4+DQo+Pj4+PiBDaHJpc3Rlcg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4g T24gMjUvMDgvMTYgMDM6MjIsICJzaXBjb3JlIG9uIGJlaGFsZiBvZiBCcmlhbiBSb3NlbiINCj4+ Pj4+IDxzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGJyQGJyaWFucm9zZW4u bmV0PiB3cm90ZToNCj4+Pj4+DQo+Pj4+Pj4gT3ZlciBpbiBlY3JpdCB3ZSBoYXZlIGEgZGlzYWdy ZWVtZW50IHRoYXQgcmVsYXRlcyB0byBpbnRlcnByZXRpbmcgDQo+Pj4+Pj4gUkZDNjA4Ni4NCj4+ Pj4+Pg0KPj4+Pj4+IEJhY2tncm91bmQ6DQo+Pj4+Pj4gUkZDNzg1MiBkZWZpbmVzIHNvbWV0aGlu ZyBjYWxsZWQgIkFkZGl0aW9uYWwgRGF0YSIsIHdoaWNoIGlzIA0KPj4+Pj4+IGNhcnJpZWQgaW4g ZW1lcmdlbmN5IGNhbGwgc2lnbmFsaW5nLiAgSXQncyBkYXRhIHJlbGF0ZWQgdG8gdGhlIA0KPj4+ Pj4+IGNhbGwsIGUuZy4sIHRoZSBpZGVudGl0eSBhbmQgY29udGFjdCBkYXRhIG9mIHRoZSBzZXJ2 aWNlIHByb3ZpZGVyIGhhbmRsaW5nIHRoZSBjYWxsLg0KPj4+Pj4+IEFkZGl0aW9uYWwgRGF0YSBp cyBzaWduYWxlZCB3aXRoIGEgQ2FsbC1JbmZvIGhlYWRlciBmaWVsZCwgd2hpY2ggDQo+Pj4+Pj4g Y29udGFpbnMgZWl0aGVyIGEgVVJJIHBvaW50aW5nIHRvIGEgZGF0YSBibG9jayBmZXRjaGVkIHdp dGggDQo+Pj4+Pj4gSFRUUFMsIG9yIGEgQ29udGVudCBJbmRpcmVjdCByZWZlcmVuY2luZyBhIGJv ZHkgcGFydCBvZiB0aGUgU0lQIG1lc3NhZ2UuDQo+Pj4+Pj4gSXQncyB1c3VhbGx5IHVzZWQgb24g dGhlIElOVklURSBvZiB0aGUgZW1lcmdlbmN5IGNhbGwsIHNvIGl0IGNhbiANCj4+Pj4+PiBiZSBk aXNwbGF5ZWQgdG8gdGhlIFBTQVAgKGVtZXJnZW5jeSBjYWxsIGNlbnRlcikgY2FsbC10YWtlciB3 aGVuIA0KPj4+Pj4+IHRoZSBjYWxsIGlzIGFzc2lnbmVkLg0KPj4+Pj4+DQo+Pj4+Pj4gU29tZXRp bWVzLCB0aGlzIGRhdGEgY2FuIGNoYW5nZSBkdXJpbmcgYSBjYWxsLiAgVGhlIGV4YW1wbGUgaW4g DQo+Pj4+Pj4gZGlzY3Vzc2lvbg0KPj4+Pj4+IGlzIHRlbGVtYXRpY3MgZGF0YSBpbiBhIHZlaGlj bGUuICAgVGhlIHZlaGljbGUgY2FuIHJlcG9ydCB0aGluZ3MgbGlrZQ0KPj4+Pj4+IHRoZQ0KPj4+ Pj4+IG51bWJlciBvZiBvY2N1cGFudHMgYW5kIGl0cyBvcmllbnRhdGlvbi4gIFRoZSBQU0FQIGNh biByZXF1ZXN0IGFuIA0KPj4+Pj4+IHVwZGF0ZSBtaWQgY2FsbCAoZS5nLiwgaWYgdGhlIGNhbGwg dGFrZXIgdGhpbmtzIHRoaW5ncyBtaWdodCBoYXZlIA0KPj4+Pj4+IGNoYW5nZWQpLg0KPj4+Pj4+ DQo+Pj4+Pj4gSU5GTyBpcyB0aGUgY2hvc2VuIG1lY2hhbmlzbSB0byBzZW5kIHRoZSByZXF1ZXN0 IGZvciB1cGRhdGUuICBUaGUgDQo+Pj4+Pj4gZGV2aWNlIHdpbGwgc2VuZCBhIHJlc3BvbnNlIHRv IHRoZSByZXF1ZXN0IChhbiBBQ0spLCB3aGljaCBpcyANCj4+Pj4+PiBhbHNvIHNlbnQgaW4gSU5G Ty4NCj4+Pj4+PiBUaGlzIGNvbnN0aXR1dGVzIGEgd2VsbCBkZWZpbmVkIElORk8gcGFja2FnZSwg YW5kIHdpbGwgYmUgDQo+Pj4+Pj4gcmVnaXN0ZXJlZCBpbiB0aGUgdXN1YWwgd2F5Lg0KPj4+Pj4+ DQo+Pj4+Pj4gVGhlIElzc3VlIGF0IGhhbmQ6DQo+Pj4+Pj4gU28sIHRoZSBkaXNwdXRlIGlzIGhv dyB0aGUgdXBkYXRlZCBkYXRhIGlzIHNlbnQgbWlkIGNhbGwuDQo+Pj4+Pj4NCj4+Pj4+PiBSRkM2 MDg2IHNheXMNCj4+Pj4+Pg0KPj4+Pj4+IE5PVEU6IEFuIElORk8gcmVxdWVzdCBjYW4gYWxzbyBj b250YWluIG90aGVyIGJvZHkgcGFydHMgdGhhdCBhcmUgDQo+Pj4+Pj4gbWVhbmluZ2Z1bCB3aXRo aW4gdGhlIGNvbnRleHQgb2YgYW4gaW52aXRlIGRpYWxvZyB1c2FnZSBidXQgYXJlIA0KPj4+Pj4+ IG5vdCBzcGVjaWZpY2FsbHkgYXNzb2NpYXRlZCB3aXRoIHRoZSBJTkZPIG1ldGhvZCBhbmQgdGhl IA0KPj4+Pj4+IGFwcGxpY2F0aW9uIGNvbmNlcm5lZC4NCj4+Pj4+Pg0KPj4+Pj4+IFRoZSBhdXRo b3JzIG9mIHRoZSBkcmFmdCAob2Ygd2hpY2ggSSBhbSBvbmUpIGRlc2lyZSB0byB1c2UgdGhlIA0K Pj4+Pj4+IEFkZGl0aW9uYWwgRGF0YSBtZWNoYW5pc20gdG8gY2FycnkgdGhlIHVwZGF0ZWQgZGF0 YS4gIFRoZSBkYXRhIA0KPj4+Pj4+IGNvdWxkIGJlIHNlbnQgaW4gYW55IGNvbnZlbmllbnQgbWVz c2FnZSwgYWx0aG91Z2ggc2luY2UgdGhlIA0KPj4+Pj4+IHZlaGljbGUgaXMgc2VuZGluZyBhbiBB Q0ssIGl0J3MgbGlrZWx5IGdvaW5nIHRvIGdvIG9uIHRoYXQuICBXZSdkIA0KPj4+Pj4+IGxpa2Ug dG8gYWx3YXlzIGNhcnJ5IHRoZSBkYXRhIGluIHRoZSBzYW1lIHdheS4gIEluIGFuIElORk8gDQo+ Pj4+Pj4gbWVzc2FnZSBpdCB3b3VsZCBiZSBjYXJyaWVkIHRoZSBzYW1lIGFzIGl0IGlzIGluIHRo ZSBJTlZJVEUsIGFzIA0KPj4+Pj4+IEFkZGl0aW9uYWwgRGF0YS4gIFNpbmNlIHRoZSBJTkZPIGNh cnJpZXMgYW4gQUNLLCBpdCB3b3VsZCBzcGVjaWZ5IA0KPj4+Pj4+IHRoZSBhcHByb3ByaWF0ZSBJ TkZPIHBhY2thZ2UsIGFuZCB3b3VsZCBjb250YWluIGEgYm9keSBwYXJ0IHdpdGggDQo+Pj4+Pj4g dGhlIEFDSy4gIFRoZXJlIHdvdWxkIGJlIGFub3RoZXIgYm9keSBwYXJ0IGZvciB0aGUgdXBkYXRl ZCBkYXRhLCANCj4+Pj4+PiBwb2ludGVkIHRvIGJ5IHRoZSBDYWxsLUluZm8uDQo+Pj4+Pj4NCj4+ Pj4+PiBTb21lIGVjcml0IHBhcnRpY2lwYW50cyBzYXkgdGhhdCB0aGUgYWJvdmUgbGFuZ3VhZ2Ug b2YgNjA4NiB3b3VsZCANCj4+Pj4+PiBwcm9oaWJpdCB0aGUgSU5GTyBmcm9tIGNvbnRhaW5pbmcg YSBDYWxsLUluZm8gaGVhZGVyIHdpdGggYSBDSUQgDQo+Pj4+Pj4gcG9pbnRpbmcgdG8gYSBNSU1F IGJvZHkgcGFydCwgYmVjYXVzZSB0aGUgZGF0YSB3YXMgcmVxdWVzdGVkIGJ5IA0KPj4+Pj4+IGFu IElORk8sIGFuZCBoZW5jZSBpcyByZWxhdGVkIHRvIHRoZSBJTkZPIHBhY2thZ2UuICBUaGV5IHNh eSB0aGF0IA0KPj4+Pj4+IHRoZSBkYXRhIE1VU1QgYmUgY2FycmllZCB3aXRoIGEgYm9keSBwYXJ0 IGFuZCBDb250ZW50IERpc3Bvc2l0aW9uIA0KPj4+Pj4+IHRoYXQgaXMgcGFydCBvZiB0aGUgSU5G TyBwYWNrYWdlIGRlZmluaXRpb24uDQo+Pj4+Pj4NCj4+Pj4+PiBUaGUgZHJhZnQgYXV0aG9ycyBj bGFpbSB0aGlzIDYwODYgbGFuZ3VhZ2UgaXNuJ3QgYSANCj4+Pj4+PiBzdHJhaWdodGphY2tldCwg YW5kIGl0J3MgcGVyZmVjdGx5IGZpbmUgdG8gY2FycnkgdGhlIGRhdGEgDQo+Pj4+Pj4gcmVmZXJl bmNlZCBieSBhIENhbGwtSW5mbyB3aXRoIGEgQ29udGVudCBJbmRpcmVjdCBib2R5IHBhcnQgdXNp bmcgdGhlIHNhbWUgTUlNRSB0eXBlIGFuZCBDb250ZW50DQo+Pj4+Pj4gRGlzcG9zaXRpb24gYXMg aXQgd291bGQgaW4gYW4gSU5WSVRFLiAgIFdoZW4gdGhlIHVwZGF0ZWQgZGF0YSBpcyBzZW50DQo+ Pj4+Pj4gaW4NCj4+Pj4+PiBJTkZPLCBpdCdzIGJlY2F1c2UgdGhlIElORk8gaXMgYSBjb252ZW5p ZW50IG1lc3NhZ2UgKHNpbmNlIGl0J3MgDQo+Pj4+Pj4gYmVpbmcgc2VudCB0byBjYXJyeSB0aGUg QUNLKS4NCj4+Pj4+Pg0KPj4+Pj4+IE1lY2hhbmljYWxseSwgYm90aCBtZWNoYW5pc21zIGNhbiBi ZSBtYWRlIHRvIHdvcmsuICBUaGUgYm9keSANCj4+Pj4+PiBwYXJ0cyB3b3VsZCBiZSBsYWJlbGVk IGFwcHJvcHJpYXRlbHkgYW5kIHRoZXJlIHdvdWxkIGJlIG5vIA0KPj4+Pj4+IGNvbmZ1c2lvbiBh Ym91dCB3aGF0IHRoZXkgbWVhbiBvciBob3cgdGhleSB3b3VsZCBiZSBpbnRlcnByZXRlZC4gIA0K Pj4+Pj4+IEl0J3MgcmVhbGx5IG9ubHkgd2hldGhlciB0aGUgQ2FsbC1JbmZvIGhlYWRlciBpcyBw cmVzZW50IGFuZCB3aGF0IA0KPj4+Pj4+IHRoZSBNSU1FIHR5cGUgYW5kIENvbnRlbnQgRGlzcG9z aXRpb24gdGhlIGJvZHkgcGFydCBjb250YWluaW5nIA0KPj4+Pj4+IHRoZSBkYXRhIHdvdWxkIGJl LiAgSW4gdGhlIGF1dGhvcidzIHByZWZlcnJlZCB3YXksIGl0IHdvdWxkIGJlIA0KPj4+Pj4+IHRo ZSBNSU1FIHR5cGUgYW5kIENvbnRlbnQgRGlzcG9zaXRpb24gb2YgdGhlIENhbGwtSW5mbyBhbmQg aW4gdGhlIA0KPj4+Pj4+IG90aGVyIHBvaW50IG9mIHZpZXcgaXQgd291bGQgYmUgdGhlIE1JTUUg dHlwZSBhbmQgQ29udGVudCANCj4+Pj4+PiBEaXNwb3NpdGlvbiBvZiB0aGUgSU5GTyBwYWNrYWdl Lg0KPj4+Pj4+DQo+Pj4+Pj4gUGxlYXNlIGlnbm9yZSB5b3VyIHBlcnNvbmFsIHByZWZlcmVuY2Ug Zm9yIHdoZXRoZXIgeW91IHRoaW5rIGl0IA0KPj4+Pj4+IG91Z2h0IHRvIGdvIGluIHRoZSBJTkZP IG9yIG5vdCwgYW5kIHBsZWFzZSBoZWxwIHVzIGludGVycHJldCA2MDg2Og0KPj4+Pj4+IGRvZXMg dGhlIGRhdGEgSEFWRSB0byBnbyBpbiBhbiBJTkZPIGJvZHkgcGFydCBvciBjYW4gaXQgYmUgc2Vu dCANCj4+Pj4+PiBpbiBhIENhbGwtSW5mbyBib2R5IHBhcnQ/DQo+Pj4+Pj4NCj4+Pj4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+IHNpcGNv cmUgbWFpbGluZyBsaXN0DQo+Pj4+Pj4gc2lwY29yZUBpZXRmLm9yZw0KPj4+Pj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KPj4+Pj4NCj4+Pj4NCj4+Pg0K Pj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ PiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPj4gc2lwY29yZUBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQo+Pg0KPg0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzaXBjb3JlIG1haWxpbmcg bGlzdA0KPiBzaXBjb3JlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2lwY29yZQ0KPg0KDQo= From nobody Thu Aug 25 08:50:40 2016 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 E2FF512D15A for ; Thu, 25 Aug 2016 08:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3hw4L1i29Bl for ; Thu, 25 Aug 2016 08:50:37 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2368A12D0E2 for ; Thu, 25 Aug 2016 08:50:37 -0700 (PDT) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-05v.sys.comcast.net with SMTP id cwuXbsuZL2FGMcwvMbtvHm; Thu, 25 Aug 2016 15:50:36 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-20v.sys.comcast.net with SMTP id cwvLbcMAbZSN2cwvLb8yNm; Thu, 25 Aug 2016 15:50:36 +0000 To: Christer Holmberg , "sipcore@ietf.org" References: <76CCBFA5-8D53-4B1E-A495-4A18AB081384@brianrosen.net> <05240A95-8319-4555-8B46-FA18B6C27883@brianrosen.net> <5d462933-e3c0-b3a3-958d-5c9d1e86d854@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC60A10@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC61D10@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <1c9b4538-720c-0126-7a82-d63edfc40caf@alum.mit.edu> Date: Thu, 25 Aug 2016 11:50:31 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC61D10@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfAdBn7u0g7wD//hCFr3p1NsRxrVTfapMwvaLeU18RpeHKJsgLjR1JUmDelwnuHW6xUJdDi3EiS4QoEAuJikLLRhmlcLEYybe4owFHvocLcKf+hSvpxP6 uQm+mHkMOOX+HP7aeF2G6QybOs2M46wXyx+g/wyy3NTGn6RSk9ETpn4m2OJ3ssWpcUIbyAa9+vG14Ya2uHxN9LFViRfPJ3nSBMi4bKp3psx3df5itGFx/cOx Archived-At: Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 15:50:39 -0000 On 8/25/16 11:40 AM, Christer Holmberg wrote: > Hi Paul, > > I am not talking about the criteria for selecting INFO in the first place (instead of e.g. event packages). > > I am asking: assuming you have determined (based on whatever criteria) that the INFO message is the most appropriate mechanism, when are you required to use Info Package? That is easy. In a call where you have negotiated use of Info Package X, you should: - use info package X for those things it is designed for; - use other mechanisms for things those are designed for. If you find something where it is ambiguous whether to use X or some other mechanism then I think your definition of package X is inadequate. Thanks, Paul > Regards, > > Christer > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 25 August 2016 18:34 > To: Christer Holmberg ; sipcore@ietf.org > Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? > > On 8/25/16 10:58 AM, Christer Holmberg wrote: >> Paul, a generic question, which might help me understand your view on ecall: in your opinion, when (if ever) is usage of an Info Package required? > > I guess I would phrase it this way: > > If you have a need to transmit some information via a sip session, then you should consider all the available mechanisms sip has, and decide if there is some combination of existing mechanisms that meets your need. > > The following are some of the available mechanisms: > > - new event packages > - new info packages > - new qualifying options with call-info, alert-info, error-info > - newly defined header field parameters > - new defined header fields > > Many of these mechanisms have their own rules for what sorts of new usage are appropriate. Others do not, and are probably deficient because of that. For those, the bar is generally the need to get a RFC approved. > > INFO is notable because the bar is pretty low (Specification Required). > So some may choose it for its ease. > > When choosing among the options, you have to consider what the approval processes will be for each, and that the reviewers will probably ask if you have considered alternative approaches. > > For instance Geolocation was done with a new header field that sometimes references a separate body part. That raised a higher hurdle to get over than using an info package. But it was deemed worth it since it had needs that couldn't be met by info packages. > > In general there are likely to be multiple options available for almost anything you want to do. And then it will come down to weighing the pros/cons. > > Thanks, > Paul > >> Regards, >> >> Christer >> >> -----Original Message----- >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul >> Kyzivat >> Sent: 25 August 2016 17:32 >> To: sipcore@ietf.org >> Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? >> >> On 8/25/16 9:26 AM, Brian Rosen wrote: >>> Yes, I’m saying that the ACK satisfies the 6086 use of INFO, and that it’s okay to send the data with Call-Info. >>> >>> Yes, I’m agreeing that there is a relationship between the INFO package and the data. >>> >>> Yes, I’m disagreeing with your interpretation of the language. >>> >>> So, now, what say you sipcore? >> >> I think the main point of bringing this to sipcore is to get some fresh input into this discussion. Since I have been party to the discussion over in ecrit I don't bring anything fresh here. But for completeness I will register my opinion here too. >> >> IMO this is not a question about whether the proposed usage is valid >> according to 6086 and other rfcs. (I think it is quite clear that it >> *is* valid.) Rather this is simply a question of what is the best design for the desired functionality. As such I don't think it really needs to be settled in sipcore. >> >> But I am happy to check if anybody has a different perspective on this. >> >> Thanks, >> Paul >> >>> Brian >>> >>> >>>> On Aug 25, 2016, at 9:14 AM, Christer Holmberg wrote: >>>> >>>> Hi, >>>> >>>>> We’re agreeing that there is a relationship between the command and >>>>> the data. >>>>> >>>>> We’re suggesting that we don’t have to be anal about the language >>>>> and as long as there is an INFO package, and a body part that has >>>>> the ACK which is an INFO body part, that the cited language doesn’t >>>>> compel us to use the INFO body part to transport the data, the >>>>> Call-Info mechanism is acceptable. >>>>> >>>>> No one is suggesting that we update 6086, and we agree that 7852 >>>>> did not update 6086. >>>>> >>>>> It’s just whether that language prohibits use of the Call-Info to >>>>> carry the data when it was prompted by the INFO package request, >>>>> and accompanies the INFO package ACK. >>>> >>>> You seem to suggest that, just because you use an Info Package for >>>> sending SOME of the ecall related information (the request and ACK), >>>> that allows you to send the rest of the ecall related information >>>> (the data content) without using an Info Package. I really don’t see >>>> how you can parse the cited text in that way. The cited text says >>>> that information associated with the application shall be sent using >>>> an Info Package. And, both the ACK and the requested data content >>>> are associated with the ecall application. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> Brian >>>>> >>>>>> On Aug 25, 2016, at 2:00 AM, Christer Holmberg >>>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I¹m glad this is brought to SIPCORE. As one of the info package >>>>>> proponents, please let me clarify my arguments. >>>>>> >>>>>> The 6086 text that Brian copied says ³but are not specifically >>>>>> associated with the INFO method and the application concerned². >>>>>> >>>>>> I claim that the updated data IS associated with the application >>>>>> concerned (ecall). The updated data is requested by the ecall >>>>>> application, and the delivered updated data is consumed by the >>>>>> ecall application. The updated data is NOT some >>>>>> non-ecall-application-related information that is piggybacked in a >>>>>> "convenient INFO message" that happens to be sent by the ecall >>>>>> application for some other purpose. >>>>>> >>>>>> (In addition, the updated data is NOT associated with a legacy >>>>>> (pre-6086) >>>>>> INFO usage, which could justify not using an Info Package. I do >>>>>> want to point out that nobody has claimed that the updated data >>>>>> would be associated with legacy INFO, but just for completeness) >>>>>> >>>>>> RFC 7852 does define a mechanism for transporting data, using >>>>>> Call-Info etc. But, 7852 does not update 6086, nor can 7852 >>>>>> override rules and procedures associated with individual SIP >>>>>> methods (INFO in this case). I also pointed this out before 7852 >>>>>> was published, but was told that it¹s too late to change it >>>>>> (granted, the draft was in the RFC editor¹s queue). >>>>>> >>>>>> Finally, again for completeness, I want to point out that 6086 >>>>>> does not prevent including Call-Info in INFO as such. The issue is >>>>>> how some want to use Call-Info instead of an Info Package. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Christer >>>>>> >>>>>> >>>>>> >>>>>> On 25/08/16 03:22, "sipcore on behalf of Brian Rosen" >>>>>> wrote: >>>>>> >>>>>>> Over in ecrit we have a disagreement that relates to interpreting >>>>>>> RFC6086. >>>>>>> >>>>>>> Background: >>>>>>> RFC7852 defines something called "Additional Data", which is >>>>>>> carried in emergency call signaling. It's data related to the >>>>>>> call, e.g., the identity and contact data of the service provider handling the call. >>>>>>> Additional Data is signaled with a Call-Info header field, which >>>>>>> contains either a URI pointing to a data block fetched with >>>>>>> HTTPS, or a Content Indirect referencing a body part of the SIP message. >>>>>>> It's usually used on the INVITE of the emergency call, so it can >>>>>>> be displayed to the PSAP (emergency call center) call-taker when >>>>>>> the call is assigned. >>>>>>> >>>>>>> Sometimes, this data can change during a call. The example in >>>>>>> discussion >>>>>>> is telematics data in a vehicle. The vehicle can report things like >>>>>>> the >>>>>>> number of occupants and its orientation. The PSAP can request an >>>>>>> update mid call (e.g., if the call taker thinks things might have >>>>>>> changed). >>>>>>> >>>>>>> INFO is the chosen mechanism to send the request for update. The >>>>>>> device will send a response to the request (an ACK), which is >>>>>>> also sent in INFO. >>>>>>> This constitutes a well defined INFO package, and will be >>>>>>> registered in the usual way. >>>>>>> >>>>>>> The Issue at hand: >>>>>>> So, the dispute is how the updated data is sent mid call. >>>>>>> >>>>>>> RFC6086 says >>>>>>> >>>>>>> NOTE: An INFO request can also contain other body parts that are >>>>>>> meaningful within the context of an invite dialog usage but are >>>>>>> not specifically associated with the INFO method and the >>>>>>> application concerned. >>>>>>> >>>>>>> The authors of the draft (of which I am one) desire to use the >>>>>>> Additional Data mechanism to carry the updated data. The data >>>>>>> could be sent in any convenient message, although since the >>>>>>> vehicle is sending an ACK, it's likely going to go on that. We'd >>>>>>> like to always carry the data in the same way. In an INFO >>>>>>> message it would be carried the same as it is in the INVITE, as >>>>>>> Additional Data. Since the INFO carries an ACK, it would specify >>>>>>> the appropriate INFO package, and would contain a body part with >>>>>>> the ACK. There would be another body part for the updated data, >>>>>>> pointed to by the Call-Info. >>>>>>> >>>>>>> Some ecrit participants say that the above language of 6086 would >>>>>>> prohibit the INFO from containing a Call-Info header with a CID >>>>>>> pointing to a MIME body part, because the data was requested by >>>>>>> an INFO, and hence is related to the INFO package. They say that >>>>>>> the data MUST be carried with a body part and Content Disposition >>>>>>> that is part of the INFO package definition. >>>>>>> >>>>>>> The draft authors claim this 6086 language isn't a >>>>>>> straightjacket, and it's perfectly fine to carry the data >>>>>>> referenced by a Call-Info with a Content Indirect body part using the same MIME type and Content >>>>>>> Disposition as it would in an INVITE. When the updated data is sent >>>>>>> in >>>>>>> INFO, it's because the INFO is a convenient message (since it's >>>>>>> being sent to carry the ACK). >>>>>>> >>>>>>> Mechanically, both mechanisms can be made to work. The body >>>>>>> parts would be labeled appropriately and there would be no >>>>>>> confusion about what they mean or how they would be interpreted. >>>>>>> It's really only whether the Call-Info header is present and what >>>>>>> the MIME type and Content Disposition the body part containing >>>>>>> the data would be. In the author's preferred way, it would be >>>>>>> the MIME type and Content Disposition of the Call-Info and in the >>>>>>> other point of view it would be the MIME type and Content >>>>>>> Disposition of the INFO package. >>>>>>> >>>>>>> Please ignore your personal preference for whether you think it >>>>>>> ought to go in the INFO or not, and please help us interpret 6086: >>>>>>> does the data HAVE to go in an INFO body part or can it be sent >>>>>>> in a Call-Info body part? >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > From nobody Thu Aug 25 08:57:07 2016 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 0EEEC12D15A for ; Thu, 25 Aug 2016 08:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0k6XmsKd_3eT for ; Thu, 25 Aug 2016 08:57:03 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 398F612D135 for ; Thu, 25 Aug 2016 08:57:03 -0700 (PDT) X-AuditID: c1b4fb30-ea88e980000009f9-2d-57bf154dc309 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by (Symantec Mail Security) with SMTP id 2C.BC.02553.D451FB75; Thu, 25 Aug 2016 17:57:01 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0301.000; Thu, 25 Aug 2016 17:56:58 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? Thread-Index: AQHR/t2KCnVeSlQa/k+Sxwkc4yebnqBZxASQ///o+oCAACKDMP//4g2AgAAiZiA= Date: Thu, 25 Aug 2016 15:56:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC61E7C@ESESSMB209.ericsson.se> References: <76CCBFA5-8D53-4B1E-A495-4A18AB081384@brianrosen.net> <05240A95-8319-4555-8B46-FA18B6C27883@brianrosen.net> <5d462933-e3c0-b3a3-958d-5c9d1e86d854@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC60A10@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC61D10@ESESSMB209.ericsson.se> <1c9b4538-720c-0126-7a82-d63edfc40caf@alum.mit.edu> In-Reply-To: <1c9b4538-720c-0126-7a82-d63edfc40caf@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM2K7hK6v6P5wg/PLNSxWbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStjxuGLrAWzuhgrLs9xbWC80sbYxcjJISFg InF70XuWLkYuDiGB9YwSBycdY4RwljBKtD5/DeRwcLAJWEh0/9MGaRARCJS4umQCM4gtLJAo MaFvLjNEPElizqY9ULafxKxv95lAbBYBVYlPa16ALeMV8JVob3zACjH/OYvE8xV3wBo4BRwk npy/ANbAKCAm8f3UGjCbWUBc4taT+UwQlwpILNlznhnCFpV4+fgfK4StJLFi+yWwO5kFNCXW 79KHaFWUmNL9kB1ir6DEyZlPWCYwisxCMnUWQscsJB2zkHQsYGRZxShanFqclJtuZKSXWpSZ XFycn6eXl1qyiREYDwe3/DbYwfjyueMhRgEORiUe3gUP9oYLsSaWFVfmHmKU4GBWEuG9JbQ/ XIg3JbGyKrUoP76oNCe1+BCjNAeLkjiv/0vFcCGB9MSS1OzU1ILUIpgsEwenVAOjsNpF1du2 2h93cJ5kS/K45NzjbHu8lk+7qahnj/SL9UE6usrpnAUMHdGL1KtMZuc9ZTllzCl/+8+uvO60 Jv0ZH6fons+sTu7I8Yjmtd/k6qVooP61VvXVlR49wfxjE27Nllq6YIHIUZU/vom/3NaqX7rY zmXv0K/i6viFw9hky7XQH1WrNyixFGckGmoxFxUnAgARUNhtgwIAAA== Archived-At: Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 15:57:06 -0000 SGksDQoNCj4+IEkgYW0gbm90IHRhbGtpbmcgYWJvdXQgdGhlIGNyaXRlcmlhIGZvciBzZWxlY3Rp bmcgSU5GTyBpbiB0aGUgZmlyc3QgcGxhY2UgKGluc3RlYWQgb2YgZS5nLiBldmVudCBwYWNrYWdl cykuDQo+Pg0KPj4gSSBhbSBhc2tpbmc6IGFzc3VtaW5nIHlvdSBoYXZlIGRldGVybWluZWQgKGJh c2VkIG9uIHdoYXRldmVyIGNyaXRlcmlhKSB0aGF0IHRoZSBJTkZPIG1lc3NhZ2UgaXMgdGhlDQo+ PiBtb3N0IGFwcHJvcHJpYXRlIG1lY2hhbmlzbSwgd2hlbiBhcmUgeW91IHJlcXVpcmVkIHRvIHVz ZSBJbmZvIFBhY2thZ2U/DQo+DQo+IFRoYXQgaXMgZWFzeS4gSW4gYSBjYWxsIHdoZXJlIHlvdSBo YXZlIG5lZ290aWF0ZWQgdXNlIG9mIEluZm8gUGFja2FnZSBYLCB5b3Ugc2hvdWxkOg0KPg0KPiAt IHVzZSBpbmZvIHBhY2thZ2UgWCBmb3IgdGhvc2UgdGhpbmdzIGl0IGlzIGRlc2lnbmVkIGZvcjsN Cj4gLSB1c2Ugb3RoZXIgbWVjaGFuaXNtcyBmb3IgdGhpbmdzIHRob3NlIGFyZSBkZXNpZ25lZCBm b3IuDQo+DQo+IElmIHlvdSBmaW5kIHNvbWV0aGluZyB3aGVyZSBpdCBpcyBhbWJpZ3VvdXMgd2hl dGhlciB0byB1c2UgWCBvciBzb21lIG90aGVyIG1lY2hhbmlzbSB0aGVuIEkgdGhpbmsgeW91ciBk ZWZpbml0aW9uIG9mIHBhY2thZ2UgWCBpcyBpbmFkZXF1YXRlLg0KDQpUaGF0J3Mgc3RpbGwgbm90 IHdoYXQgSSdtIGFza2luZy4gV2hlbiB5b3UgZGVmaW5lIGEgcGFja2FnZSwgeW91IG9idmlvdXNs eSBuZWVkIHRvIGRlZmluZSBpdCBjb3JyZWN0bHksIGJ1dCBteSBxdWVzdGlvbiBpcyB3aGVuIHlv dSBoYXZlIHRvIGRlZmluZSBhIHBhY2thZ2UgdG8gYmVnaW4gd2l0aC4NCg0KT3IsIHRvIHB1dCBp dCBpbiBhbm90aGVyIHdheTogQXNzdW1pbmcgSSB3YW50IHRvIHNlbmQgY29udGVudCBYIHVzaW5n IElORk8uIEhvdyBkbyBJIGRldGVybWluZSB3aGV0aGVyIEkgbmVlZCB0byBkZWZpbmUgYW4gSW5m byBQYWNrYWdlIGZvciB0aGF0LCBvciB3aGV0aGVyIEkgY2FuIHNlbmQgaXQgaW4gSU5GTyB3aXRo b3V0IGRlZmluaW5nIGFuIEluZm8gUGFja2FnZT8NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K DQoNCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUGF1bCBLeXppdmF0 IFttYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1XQ0KPiBTZW50OiAyNSBBdWd1c3QgMjAxNiAx ODozNA0KPiBUbzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u LmNvbT47IA0KPiBzaXBjb3JlQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbc2lwY29yZV0gQ2Fu IGFuIElORk8gY29udGFpbiBhIGJvZHkgcmVsYXRlZCB0bywgYnV0IG5vdCBwYXJ0IG9mIHRoZSBJ TkZPIHBhY2thZ2U/DQo+DQo+IE9uIDgvMjUvMTYgMTA6NTggQU0sIENocmlzdGVyIEhvbG1iZXJn IHdyb3RlOg0KPj4gUGF1bCwgYSBnZW5lcmljIHF1ZXN0aW9uLCB3aGljaCBtaWdodCBoZWxwIG1l IHVuZGVyc3RhbmQgeW91ciB2aWV3IG9uIGVjYWxsOiBpbiB5b3VyIG9waW5pb24sIHdoZW4gKGlm IGV2ZXIpIGlzIHVzYWdlIG9mIGFuIEluZm8gUGFja2FnZSByZXF1aXJlZD8NCj4NCj4gSSBndWVz cyBJIHdvdWxkIHBocmFzZSBpdCB0aGlzIHdheToNCj4NCj4gSWYgeW91IGhhdmUgYSBuZWVkIHRv IHRyYW5zbWl0IHNvbWUgaW5mb3JtYXRpb24gdmlhIGEgc2lwIHNlc3Npb24sIHRoZW4geW91IHNo b3VsZCBjb25zaWRlciBhbGwgdGhlIGF2YWlsYWJsZSBtZWNoYW5pc21zIHNpcCBoYXMsIGFuZCBk ZWNpZGUgaWYgdGhlcmUgaXMgc29tZSBjb21iaW5hdGlvbiBvZiBleGlzdGluZyBtZWNoYW5pc21z IHRoYXQgbWVldHMgeW91ciBuZWVkLg0KPg0KPiBUaGUgZm9sbG93aW5nIGFyZSBzb21lIG9mIHRo ZSBhdmFpbGFibGUgbWVjaGFuaXNtczoNCj4NCj4gLSBuZXcgZXZlbnQgcGFja2FnZXMNCj4gLSBu ZXcgaW5mbyBwYWNrYWdlcw0KPiAtIG5ldyBxdWFsaWZ5aW5nIG9wdGlvbnMgd2l0aCBjYWxsLWlu Zm8sIGFsZXJ0LWluZm8sIGVycm9yLWluZm8NCj4gLSBuZXdseSBkZWZpbmVkIGhlYWRlciBmaWVs ZCBwYXJhbWV0ZXJzDQo+IC0gbmV3IGRlZmluZWQgaGVhZGVyIGZpZWxkcw0KPg0KPiBNYW55IG9m IHRoZXNlIG1lY2hhbmlzbXMgaGF2ZSB0aGVpciBvd24gcnVsZXMgZm9yIHdoYXQgc29ydHMgb2Yg bmV3IHVzYWdlIGFyZSBhcHByb3ByaWF0ZS4gT3RoZXJzIGRvIG5vdCwgYW5kIGFyZSBwcm9iYWJs eSBkZWZpY2llbnQgYmVjYXVzZSBvZiB0aGF0LiBGb3IgdGhvc2UsIHRoZSBiYXIgaXMgZ2VuZXJh bGx5IHRoZSBuZWVkIHRvIGdldCBhIFJGQyBhcHByb3ZlZC4NCj4NCj4gSU5GTyBpcyBub3RhYmxl IGJlY2F1c2UgdGhlIGJhciBpcyBwcmV0dHkgbG93IChTcGVjaWZpY2F0aW9uIFJlcXVpcmVkKS4N Cj4gU28gc29tZSBtYXkgY2hvb3NlIGl0IGZvciBpdHMgZWFzZS4NCj4NCj4gV2hlbiBjaG9vc2lu ZyBhbW9uZyB0aGUgb3B0aW9ucywgeW91IGhhdmUgdG8gY29uc2lkZXIgd2hhdCB0aGUgYXBwcm92 YWwgcHJvY2Vzc2VzIHdpbGwgYmUgZm9yIGVhY2gsIGFuZCB0aGF0IHRoZSByZXZpZXdlcnMgd2ls bCBwcm9iYWJseSBhc2sgaWYgeW91IGhhdmUgY29uc2lkZXJlZCBhbHRlcm5hdGl2ZSBhcHByb2Fj aGVzLg0KPg0KPiBGb3IgaW5zdGFuY2UgR2VvbG9jYXRpb24gd2FzIGRvbmUgd2l0aCBhIG5ldyBo ZWFkZXIgZmllbGQgdGhhdCBzb21ldGltZXMgcmVmZXJlbmNlcyBhIHNlcGFyYXRlIGJvZHkgcGFy dC4gVGhhdCByYWlzZWQgYSBoaWdoZXIgaHVyZGxlIHRvIGdldCBvdmVyIHRoYW4gdXNpbmcgYW4g aW5mbyBwYWNrYWdlLiBCdXQgaXQgd2FzIGRlZW1lZCB3b3J0aCBpdCBzaW5jZSBpdCBoYWQgbmVl ZHMgdGhhdCBjb3VsZG4ndCBiZSBtZXQgYnkgaW5mbyBwYWNrYWdlcy4NCj4NCj4gSW4gZ2VuZXJh bCB0aGVyZSBhcmUgbGlrZWx5IHRvIGJlIG11bHRpcGxlIG9wdGlvbnMgYXZhaWxhYmxlIGZvciBh bG1vc3QgYW55dGhpbmcgeW91IHdhbnQgdG8gZG8uIEFuZCB0aGVuIGl0IHdpbGwgY29tZSBkb3du IHRvIHdlaWdoaW5nIHRoZSBwcm9zL2NvbnMuDQo+DQo+IAlUaGFua3MsDQo+IAlQYXVsDQo+DQo+ PiBSZWdhcmRzLA0KPj4NCj4+IENocmlzdGVyDQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4+IEZyb206IHNpcGNvcmUgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBQYXVsIA0KPj4gS3l6aXZhdA0KPj4gU2VudDogMjUgQXVndXN0IDIwMTYg MTc6MzINCj4+IFRvOiBzaXBjb3JlQGlldGYub3JnDQo+PiBTdWJqZWN0OiBSZTogW3NpcGNvcmVd IENhbiBhbiBJTkZPIGNvbnRhaW4gYSBib2R5IHJlbGF0ZWQgdG8sIGJ1dCBub3QgcGFydCBvZiB0 aGUgSU5GTyBwYWNrYWdlPw0KPj4NCj4+IE9uIDgvMjUvMTYgOToyNiBBTSwgQnJpYW4gUm9zZW4g d3JvdGU6DQo+Pj4gWWVzLCBJ4oCZbSBzYXlpbmcgdGhhdCB0aGUgQUNLIHNhdGlzZmllcyB0aGUg NjA4NiB1c2Ugb2YgSU5GTywgYW5kIHRoYXQgaXTigJlzIG9rYXkgdG8gc2VuZCB0aGUgZGF0YSB3 aXRoIENhbGwtSW5mby4NCj4+Pg0KPj4+IFllcywgSeKAmW0gYWdyZWVpbmcgdGhhdCB0aGVyZSBp cyBhIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBJTkZPIHBhY2thZ2UgYW5kIHRoZSBkYXRhLg0K Pj4+DQo+Pj4gWWVzLCBJ4oCZbSBkaXNhZ3JlZWluZyB3aXRoIHlvdXIgaW50ZXJwcmV0YXRpb24g b2YgdGhlIGxhbmd1YWdlLg0KPj4+DQo+Pj4gU28sIG5vdywgd2hhdCBzYXkgeW91IHNpcGNvcmU/ DQo+Pg0KPj4gSSB0aGluayB0aGUgbWFpbiBwb2ludCBvZiBicmluZ2luZyB0aGlzIHRvIHNpcGNv cmUgaXMgdG8gZ2V0IHNvbWUgZnJlc2ggaW5wdXQgaW50byB0aGlzIGRpc2N1c3Npb24uIFNpbmNl IEkgaGF2ZSBiZWVuIHBhcnR5IHRvIHRoZSBkaXNjdXNzaW9uIG92ZXIgaW4gZWNyaXQgSSBkb24n dCBicmluZyBhbnl0aGluZyBmcmVzaCBoZXJlLiBCdXQgZm9yIGNvbXBsZXRlbmVzcyBJIHdpbGwg cmVnaXN0ZXIgbXkgb3BpbmlvbiBoZXJlIHRvby4NCj4+DQo+PiBJTU8gdGhpcyBpcyBub3QgYSBx dWVzdGlvbiBhYm91dCB3aGV0aGVyIHRoZSBwcm9wb3NlZCB1c2FnZSBpcyB2YWxpZCANCj4+IGFj Y29yZGluZyB0byA2MDg2IGFuZCBvdGhlciByZmNzLiAoSSB0aGluayBpdCBpcyBxdWl0ZSBjbGVh ciB0aGF0IGl0DQo+PiAqaXMqIHZhbGlkLikgUmF0aGVyIHRoaXMgaXMgc2ltcGx5IGEgcXVlc3Rp b24gb2Ygd2hhdCBpcyB0aGUgYmVzdCBkZXNpZ24gZm9yIHRoZSBkZXNpcmVkIGZ1bmN0aW9uYWxp dHkuIEFzIHN1Y2ggSSBkb24ndCB0aGluayBpdCByZWFsbHkgbmVlZHMgdG8gYmUgc2V0dGxlZCBp biBzaXBjb3JlLg0KPj4NCj4+IEJ1dCBJIGFtIGhhcHB5IHRvIGNoZWNrIGlmIGFueWJvZHkgaGFz IGEgZGlmZmVyZW50IHBlcnNwZWN0aXZlIG9uIHRoaXMuDQo+Pg0KPj4gCVRoYW5rcywNCj4+IAlQ YXVsDQo+Pg0KPj4+IEJyaWFuDQo+Pj4NCj4+Pg0KPj4+PiBPbiBBdWcgMjUsIDIwMTYsIGF0IDk6 MTQgQU0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+ IHdyb3RlOg0KPj4+Pg0KPj4+PiBIaSwNCj4+Pj4NCj4+Pj4+IFdl4oCZcmUgYWdyZWVpbmcgdGhh dCB0aGVyZSBpcyBhIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBjb21tYW5kIA0KPj4+Pj4gYW5k IHRoZSBkYXRhLg0KPj4+Pj4NCj4+Pj4+IFdl4oCZcmUgc3VnZ2VzdGluZyB0aGF0IHdlIGRvbuKA mXQgaGF2ZSB0byBiZSBhbmFsIGFib3V0IHRoZSBsYW5ndWFnZSANCj4+Pj4+IGFuZCBhcyBsb25n IGFzIHRoZXJlIGlzIGFuIElORk8gcGFja2FnZSwgYW5kIGEgYm9keSBwYXJ0IHRoYXQgaGFzIA0K Pj4+Pj4gdGhlIEFDSyB3aGljaCBpcyBhbiBJTkZPIGJvZHkgcGFydCwgdGhhdCB0aGUgY2l0ZWQg bGFuZ3VhZ2UgDQo+Pj4+PiBkb2VzbuKAmXQgY29tcGVsIHVzIHRvIHVzZSB0aGUgSU5GTyBib2R5 IHBhcnQgdG8gdHJhbnNwb3J0IHRoZSBkYXRhLCANCj4+Pj4+IHRoZSBDYWxsLUluZm8gbWVjaGFu aXNtIGlzIGFjY2VwdGFibGUuDQo+Pj4+Pg0KPj4+Pj4gTm8gb25lIGlzIHN1Z2dlc3RpbmcgdGhh dCB3ZSB1cGRhdGUgNjA4NiwgYW5kIHdlIGFncmVlIHRoYXQgNzg1MiANCj4+Pj4+IGRpZCBub3Qg dXBkYXRlIDYwODYuDQo+Pj4+Pg0KPj4+Pj4gSXTigJlzIGp1c3Qgd2hldGhlciB0aGF0IGxhbmd1 YWdlIHByb2hpYml0cyB1c2Ugb2YgdGhlIENhbGwtSW5mbyB0byANCj4+Pj4+IGNhcnJ5IHRoZSBk YXRhIHdoZW4gaXQgd2FzIHByb21wdGVkIGJ5IHRoZSBJTkZPIHBhY2thZ2UgcmVxdWVzdCwgDQo+ Pj4+PiBhbmQgYWNjb21wYW5pZXMgdGhlIElORk8gcGFja2FnZSBBQ0suDQo+Pj4+DQo+Pj4+IFlv dSBzZWVtIHRvIHN1Z2dlc3QgdGhhdCwganVzdCBiZWNhdXNlIHlvdSB1c2UgYW4gSW5mbyBQYWNr YWdlIGZvciANCj4+Pj4gc2VuZGluZyBTT01FIG9mIHRoZSBlY2FsbCByZWxhdGVkIGluZm9ybWF0 aW9uICh0aGUgcmVxdWVzdCBhbmQgDQo+Pj4+IEFDSyksIHRoYXQgYWxsb3dzIHlvdSB0byBzZW5k IHRoZSByZXN0IG9mIHRoZSBlY2FsbCByZWxhdGVkIA0KPj4+PiBpbmZvcm1hdGlvbiAodGhlIGRh dGEgY29udGVudCkgd2l0aG91dCB1c2luZyBhbiBJbmZvIFBhY2thZ2UuIEkgDQo+Pj4+IHJlYWxs eSBkb27igJl0IHNlZSBob3cgeW91IGNhbiBwYXJzZSB0aGUgY2l0ZWQgdGV4dCBpbiB0aGF0IHdh eS4gVGhlIA0KPj4+PiBjaXRlZCB0ZXh0IHNheXMgdGhhdCBpbmZvcm1hdGlvbiBhc3NvY2lhdGVk IHdpdGggdGhlIGFwcGxpY2F0aW9uIA0KPj4+PiBzaGFsbCBiZSBzZW50IHVzaW5nIGFuIEluZm8g UGFja2FnZS4gQW5kLCBib3RoIHRoZSBBQ0sgYW5kIHRoZSANCj4+Pj4gcmVxdWVzdGVkIGRhdGEg Y29udGVudCBhcmUgYXNzb2NpYXRlZCB3aXRoIHRoZSBlY2FsbCBhcHBsaWNhdGlvbi4NCj4+Pj4N Cj4+Pj4gUmVnYXJkcywNCj4+Pj4NCj4+Pj4gQ2hyaXN0ZXINCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+ Pj4NCj4+Pj4NCj4+Pj4+DQo+Pj4+PiBCcmlhbg0KPj4+Pj4NCj4+Pj4+PiBPbiBBdWcgMjUsIDIw MTYsIGF0IDI6MDAgQU0sIENocmlzdGVyIEhvbG1iZXJnIA0KPj4+Pj4+IDxjaHJpc3Rlci5ob2xt YmVyZ0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KPj4+Pj4+DQo+Pj4+Pj4gSGksDQo+Pj4+Pj4NCj4+ Pj4+PiBJwrltIGdsYWQgdGhpcyBpcyBicm91Z2h0IHRvIFNJUENPUkUuIEFzIG9uZSBvZiB0aGUg aW5mbyBwYWNrYWdlIA0KPj4+Pj4+IHByb3BvbmVudHMsIHBsZWFzZSBsZXQgbWUgY2xhcmlmeSBt eSBhcmd1bWVudHMuDQo+Pj4+Pj4NCj4+Pj4+PiBUaGUgNjA4NiB0ZXh0IHRoYXQgQnJpYW4gY29w aWVkIHNheXMgwrNidXQgYXJlIG5vdCBzcGVjaWZpY2FsbHkgDQo+Pj4+Pj4gYXNzb2NpYXRlZCB3 aXRoIHRoZSBJTkZPIG1ldGhvZCBhbmQgdGhlIGFwcGxpY2F0aW9uIGNvbmNlcm5lZMKyLg0KPj4+ Pj4+DQo+Pj4+Pj4gSSBjbGFpbSB0aGF0IHRoZSB1cGRhdGVkIGRhdGEgSVMgYXNzb2NpYXRlZCB3 aXRoIHRoZSBhcHBsaWNhdGlvbiANCj4+Pj4+PiBjb25jZXJuZWQgKGVjYWxsKS4gVGhlIHVwZGF0 ZWQgZGF0YSBpcyByZXF1ZXN0ZWQgYnkgdGhlIGVjYWxsIA0KPj4+Pj4+IGFwcGxpY2F0aW9uLCBh bmQgdGhlIGRlbGl2ZXJlZCB1cGRhdGVkIGRhdGEgaXMgY29uc3VtZWQgYnkgdGhlIA0KPj4+Pj4+ IGVjYWxsIGFwcGxpY2F0aW9uLiBUaGUgdXBkYXRlZCBkYXRhIGlzIE5PVCBzb21lIA0KPj4+Pj4+ IG5vbi1lY2FsbC1hcHBsaWNhdGlvbi1yZWxhdGVkIGluZm9ybWF0aW9uIHRoYXQgaXMgcGlnZ3li YWNrZWQgaW4gDQo+Pj4+Pj4gYSAiY29udmVuaWVudCBJTkZPIG1lc3NhZ2UiIHRoYXQgaGFwcGVu cyB0byBiZSBzZW50IGJ5IHRoZSBlY2FsbCANCj4+Pj4+PiBhcHBsaWNhdGlvbiBmb3Igc29tZSBv dGhlciBwdXJwb3NlLg0KPj4+Pj4+DQo+Pj4+Pj4gKEluIGFkZGl0aW9uLCB0aGUgdXBkYXRlZCBk YXRhIGlzIE5PVCBhc3NvY2lhdGVkIHdpdGggYSBsZWdhY3kNCj4+Pj4+PiAocHJlLTYwODYpDQo+ Pj4+Pj4gSU5GTyB1c2FnZSwgd2hpY2ggY291bGQganVzdGlmeSBub3QgdXNpbmcgYW4gSW5mbyBQ YWNrYWdlLiBJIGRvIA0KPj4+Pj4+IHdhbnQgdG8gcG9pbnQgb3V0IHRoYXQgbm9ib2R5IGhhcyBj bGFpbWVkIHRoYXQgdGhlIHVwZGF0ZWQgZGF0YSANCj4+Pj4+PiB3b3VsZCBiZSBhc3NvY2lhdGVk IHdpdGggbGVnYWN5IElORk8sIGJ1dCBqdXN0IGZvciBjb21wbGV0ZW5lc3MpDQo+Pj4+Pj4NCj4+ Pj4+PiBSRkMgNzg1MiBkb2VzIGRlZmluZSBhIG1lY2hhbmlzbSBmb3IgdHJhbnNwb3J0aW5nIGRh dGEsIHVzaW5nIA0KPj4+Pj4+IENhbGwtSW5mbyBldGMuIEJ1dCwgNzg1MiBkb2VzIG5vdCB1cGRh dGUgNjA4Niwgbm9yIGNhbiA3ODUyIA0KPj4+Pj4+IG92ZXJyaWRlIHJ1bGVzIGFuZCBwcm9jZWR1 cmVzIGFzc29jaWF0ZWQgd2l0aCBpbmRpdmlkdWFsIFNJUCANCj4+Pj4+PiBtZXRob2RzIChJTkZP IGluIHRoaXMgY2FzZSkuIEkgYWxzbyBwb2ludGVkIHRoaXMgb3V0IGJlZm9yZSA3ODUyIA0KPj4+ Pj4+IHdhcyBwdWJsaXNoZWQsIGJ1dCB3YXMgdG9sZCB0aGF0IGl0wrlzIHRvbyBsYXRlIHRvIGNo YW5nZSBpdCANCj4+Pj4+PiAoZ3JhbnRlZCwgdGhlIGRyYWZ0IHdhcyBpbiB0aGUgUkZDIGVkaXRv csK5cyBxdWV1ZSkuDQo+Pj4+Pj4NCj4+Pj4+PiBGaW5hbGx5LCBhZ2FpbiBmb3IgY29tcGxldGVu ZXNzLCBJIHdhbnQgdG8gcG9pbnQgb3V0IHRoYXQgNjA4NiANCj4+Pj4+PiBkb2VzIG5vdCBwcmV2 ZW50IGluY2x1ZGluZyBDYWxsLUluZm8gaW4gSU5GTyBhcyBzdWNoLiBUaGUgaXNzdWUgDQo+Pj4+ Pj4gaXMgaG93IHNvbWUgd2FudCB0byB1c2UgQ2FsbC1JbmZvIGluc3RlYWQgb2YgYW4gSW5mbyBQ YWNrYWdlLg0KPj4+Pj4+DQo+Pj4+Pj4gUmVnYXJkcywNCj4+Pj4+Pg0KPj4+Pj4+IENocmlzdGVy DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gT24gMjUvMDgvMTYgMDM6MjIsICJzaXBj b3JlIG9uIGJlaGFsZiBvZiBCcmlhbiBSb3NlbiINCj4+Pj4+PiA8c2lwY29yZS1ib3VuY2VzQGll dGYub3JnIG9uIGJlaGFsZiBvZiBickBicmlhbnJvc2VuLm5ldD4gd3JvdGU6DQo+Pj4+Pj4NCj4+ Pj4+Pj4gT3ZlciBpbiBlY3JpdCB3ZSBoYXZlIGEgZGlzYWdyZWVtZW50IHRoYXQgcmVsYXRlcyB0 byANCj4+Pj4+Pj4gaW50ZXJwcmV0aW5nIFJGQzYwODYuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEJhY2tn cm91bmQ6DQo+Pj4+Pj4+IFJGQzc4NTIgZGVmaW5lcyBzb21ldGhpbmcgY2FsbGVkICJBZGRpdGlv bmFsIERhdGEiLCB3aGljaCBpcyANCj4+Pj4+Pj4gY2FycmllZCBpbiBlbWVyZ2VuY3kgY2FsbCBz aWduYWxpbmcuICBJdCdzIGRhdGEgcmVsYXRlZCB0byB0aGUgDQo+Pj4+Pj4+IGNhbGwsIGUuZy4s IHRoZSBpZGVudGl0eSBhbmQgY29udGFjdCBkYXRhIG9mIHRoZSBzZXJ2aWNlIHByb3ZpZGVyIGhh bmRsaW5nIHRoZSBjYWxsLg0KPj4+Pj4+PiBBZGRpdGlvbmFsIERhdGEgaXMgc2lnbmFsZWQgd2l0 aCBhIENhbGwtSW5mbyBoZWFkZXIgZmllbGQsIHdoaWNoIA0KPj4+Pj4+PiBjb250YWlucyBlaXRo ZXIgYSBVUkkgcG9pbnRpbmcgdG8gYSBkYXRhIGJsb2NrIGZldGNoZWQgd2l0aCANCj4+Pj4+Pj4g SFRUUFMsIG9yIGEgQ29udGVudCBJbmRpcmVjdCByZWZlcmVuY2luZyBhIGJvZHkgcGFydCBvZiB0 aGUgU0lQIG1lc3NhZ2UuDQo+Pj4+Pj4+IEl0J3MgdXN1YWxseSB1c2VkIG9uIHRoZSBJTlZJVEUg b2YgdGhlIGVtZXJnZW5jeSBjYWxsLCBzbyBpdCBjYW4gDQo+Pj4+Pj4+IGJlIGRpc3BsYXllZCB0 byB0aGUgUFNBUCAoZW1lcmdlbmN5IGNhbGwgY2VudGVyKSBjYWxsLXRha2VyIHdoZW4gDQo+Pj4+ Pj4+IHRoZSBjYWxsIGlzIGFzc2lnbmVkLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBTb21ldGltZXMsIHRo aXMgZGF0YSBjYW4gY2hhbmdlIGR1cmluZyBhIGNhbGwuICBUaGUgZXhhbXBsZSBpbiANCj4+Pj4+ Pj4gZGlzY3Vzc2lvbg0KPj4+Pj4+PiBpcyB0ZWxlbWF0aWNzIGRhdGEgaW4gYSB2ZWhpY2xlLiAg IFRoZSB2ZWhpY2xlIGNhbiByZXBvcnQgdGhpbmdzIGxpa2UNCj4+Pj4+Pj4gdGhlDQo+Pj4+Pj4+ IG51bWJlciBvZiBvY2N1cGFudHMgYW5kIGl0cyBvcmllbnRhdGlvbi4gIFRoZSBQU0FQIGNhbiBy ZXF1ZXN0IA0KPj4+Pj4+PiBhbiB1cGRhdGUgbWlkIGNhbGwgKGUuZy4sIGlmIHRoZSBjYWxsIHRh a2VyIHRoaW5rcyB0aGluZ3MgbWlnaHQgDQo+Pj4+Pj4+IGhhdmUgY2hhbmdlZCkuDQo+Pj4+Pj4+ DQo+Pj4+Pj4+IElORk8gaXMgdGhlIGNob3NlbiBtZWNoYW5pc20gdG8gc2VuZCB0aGUgcmVxdWVz dCBmb3IgdXBkYXRlLiAgDQo+Pj4+Pj4+IFRoZSBkZXZpY2Ugd2lsbCBzZW5kIGEgcmVzcG9uc2Ug dG8gdGhlIHJlcXVlc3QgKGFuIEFDSyksIHdoaWNoIA0KPj4+Pj4+PiBpcyBhbHNvIHNlbnQgaW4g SU5GTy4NCj4+Pj4+Pj4gVGhpcyBjb25zdGl0dXRlcyBhIHdlbGwgZGVmaW5lZCBJTkZPIHBhY2th Z2UsIGFuZCB3aWxsIGJlIA0KPj4+Pj4+PiByZWdpc3RlcmVkIGluIHRoZSB1c3VhbCB3YXkuDQo+ Pj4+Pj4+DQo+Pj4+Pj4+IFRoZSBJc3N1ZSBhdCBoYW5kOg0KPj4+Pj4+PiBTbywgdGhlIGRpc3B1 dGUgaXMgaG93IHRoZSB1cGRhdGVkIGRhdGEgaXMgc2VudCBtaWQgY2FsbC4NCj4+Pj4+Pj4NCj4+ Pj4+Pj4gUkZDNjA4NiBzYXlzDQo+Pj4+Pj4+DQo+Pj4+Pj4+IE5PVEU6IEFuIElORk8gcmVxdWVz dCBjYW4gYWxzbyBjb250YWluIG90aGVyIGJvZHkgcGFydHMgdGhhdCBhcmUgDQo+Pj4+Pj4+IG1l YW5pbmdmdWwgd2l0aGluIHRoZSBjb250ZXh0IG9mIGFuIGludml0ZSBkaWFsb2cgdXNhZ2UgYnV0 IGFyZSANCj4+Pj4+Pj4gbm90IHNwZWNpZmljYWxseSBhc3NvY2lhdGVkIHdpdGggdGhlIElORk8g bWV0aG9kIGFuZCB0aGUgDQo+Pj4+Pj4+IGFwcGxpY2F0aW9uIGNvbmNlcm5lZC4NCj4+Pj4+Pj4N Cj4+Pj4+Pj4gVGhlIGF1dGhvcnMgb2YgdGhlIGRyYWZ0IChvZiB3aGljaCBJIGFtIG9uZSkgZGVz aXJlIHRvIHVzZSB0aGUgDQo+Pj4+Pj4+IEFkZGl0aW9uYWwgRGF0YSBtZWNoYW5pc20gdG8gY2Fy cnkgdGhlIHVwZGF0ZWQgZGF0YS4gIFRoZSBkYXRhIA0KPj4+Pj4+PiBjb3VsZCBiZSBzZW50IGlu IGFueSBjb252ZW5pZW50IG1lc3NhZ2UsIGFsdGhvdWdoIHNpbmNlIHRoZSANCj4+Pj4+Pj4gdmVo aWNsZSBpcyBzZW5kaW5nIGFuIEFDSywgaXQncyBsaWtlbHkgZ29pbmcgdG8gZ28gb24gdGhhdC4g IA0KPj4+Pj4+PiBXZSdkIGxpa2UgdG8gYWx3YXlzIGNhcnJ5IHRoZSBkYXRhIGluIHRoZSBzYW1l IHdheS4gIEluIGFuIElORk8gDQo+Pj4+Pj4+IG1lc3NhZ2UgaXQgd291bGQgYmUgY2FycmllZCB0 aGUgc2FtZSBhcyBpdCBpcyBpbiB0aGUgSU5WSVRFLCBhcyANCj4+Pj4+Pj4gQWRkaXRpb25hbCBE YXRhLiAgU2luY2UgdGhlIElORk8gY2FycmllcyBhbiBBQ0ssIGl0IHdvdWxkIA0KPj4+Pj4+PiBz cGVjaWZ5IHRoZSBhcHByb3ByaWF0ZSBJTkZPIHBhY2thZ2UsIGFuZCB3b3VsZCBjb250YWluIGEg Ym9keSANCj4+Pj4+Pj4gcGFydCB3aXRoIHRoZSBBQ0suICBUaGVyZSB3b3VsZCBiZSBhbm90aGVy IGJvZHkgcGFydCBmb3IgdGhlIA0KPj4+Pj4+PiB1cGRhdGVkIGRhdGEsIHBvaW50ZWQgdG8gYnkg dGhlIENhbGwtSW5mby4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gU29tZSBlY3JpdCBwYXJ0aWNpcGFudHMg c2F5IHRoYXQgdGhlIGFib3ZlIGxhbmd1YWdlIG9mIDYwODYgDQo+Pj4+Pj4+IHdvdWxkIHByb2hp Yml0IHRoZSBJTkZPIGZyb20gY29udGFpbmluZyBhIENhbGwtSW5mbyBoZWFkZXIgd2l0aCANCj4+ Pj4+Pj4gYSBDSUQgcG9pbnRpbmcgdG8gYSBNSU1FIGJvZHkgcGFydCwgYmVjYXVzZSB0aGUgZGF0 YSB3YXMgDQo+Pj4+Pj4+IHJlcXVlc3RlZCBieSBhbiBJTkZPLCBhbmQgaGVuY2UgaXMgcmVsYXRl ZCB0byB0aGUgSU5GTyBwYWNrYWdlLiAgDQo+Pj4+Pj4+IFRoZXkgc2F5IHRoYXQgdGhlIGRhdGEg TVVTVCBiZSBjYXJyaWVkIHdpdGggYSBib2R5IHBhcnQgYW5kIA0KPj4+Pj4+PiBDb250ZW50IERp c3Bvc2l0aW9uIHRoYXQgaXMgcGFydCBvZiB0aGUgSU5GTyBwYWNrYWdlIGRlZmluaXRpb24uDQo+ Pj4+Pj4+DQo+Pj4+Pj4+IFRoZSBkcmFmdCBhdXRob3JzIGNsYWltIHRoaXMgNjA4NiBsYW5ndWFn ZSBpc24ndCBhIA0KPj4+Pj4+PiBzdHJhaWdodGphY2tldCwgYW5kIGl0J3MgcGVyZmVjdGx5IGZp bmUgdG8gY2FycnkgdGhlIGRhdGEgDQo+Pj4+Pj4+IHJlZmVyZW5jZWQgYnkgYSBDYWxsLUluZm8g d2l0aCBhIENvbnRlbnQgSW5kaXJlY3QgYm9keSBwYXJ0IHVzaW5nIHRoZSBzYW1lIE1JTUUgdHlw ZSBhbmQgQ29udGVudA0KPj4+Pj4+PiBEaXNwb3NpdGlvbiBhcyBpdCB3b3VsZCBpbiBhbiBJTlZJ VEUuICAgV2hlbiB0aGUgdXBkYXRlZCBkYXRhIGlzIHNlbnQNCj4+Pj4+Pj4gaW4NCj4+Pj4+Pj4g SU5GTywgaXQncyBiZWNhdXNlIHRoZSBJTkZPIGlzIGEgY29udmVuaWVudCBtZXNzYWdlIChzaW5j ZSBpdCdzIA0KPj4+Pj4+PiBiZWluZyBzZW50IHRvIGNhcnJ5IHRoZSBBQ0spLg0KPj4+Pj4+Pg0K Pj4+Pj4+PiBNZWNoYW5pY2FsbHksIGJvdGggbWVjaGFuaXNtcyBjYW4gYmUgbWFkZSB0byB3b3Jr LiAgVGhlIGJvZHkgDQo+Pj4+Pj4+IHBhcnRzIHdvdWxkIGJlIGxhYmVsZWQgYXBwcm9wcmlhdGVs eSBhbmQgdGhlcmUgd291bGQgYmUgbm8gDQo+Pj4+Pj4+IGNvbmZ1c2lvbiBhYm91dCB3aGF0IHRo ZXkgbWVhbiBvciBob3cgdGhleSB3b3VsZCBiZSBpbnRlcnByZXRlZC4NCj4+Pj4+Pj4gSXQncyBy ZWFsbHkgb25seSB3aGV0aGVyIHRoZSBDYWxsLUluZm8gaGVhZGVyIGlzIHByZXNlbnQgYW5kIA0K Pj4+Pj4+PiB3aGF0IHRoZSBNSU1FIHR5cGUgYW5kIENvbnRlbnQgRGlzcG9zaXRpb24gdGhlIGJv ZHkgcGFydCANCj4+Pj4+Pj4gY29udGFpbmluZyB0aGUgZGF0YSB3b3VsZCBiZS4gIEluIHRoZSBh dXRob3IncyBwcmVmZXJyZWQgd2F5LCBpdCANCj4+Pj4+Pj4gd291bGQgYmUgdGhlIE1JTUUgdHlw ZSBhbmQgQ29udGVudCBEaXNwb3NpdGlvbiBvZiB0aGUgQ2FsbC1JbmZvIA0KPj4+Pj4+PiBhbmQg aW4gdGhlIG90aGVyIHBvaW50IG9mIHZpZXcgaXQgd291bGQgYmUgdGhlIE1JTUUgdHlwZSBhbmQg DQo+Pj4+Pj4+IENvbnRlbnQgRGlzcG9zaXRpb24gb2YgdGhlIElORk8gcGFja2FnZS4NCj4+Pj4+ Pj4NCj4+Pj4+Pj4gUGxlYXNlIGlnbm9yZSB5b3VyIHBlcnNvbmFsIHByZWZlcmVuY2UgZm9yIHdo ZXRoZXIgeW91IHRoaW5rIGl0IA0KPj4+Pj4+PiBvdWdodCB0byBnbyBpbiB0aGUgSU5GTyBvciBu b3QsIGFuZCBwbGVhc2UgaGVscCB1cyBpbnRlcnByZXQgNjA4NjoNCj4+Pj4+Pj4gZG9lcyB0aGUg ZGF0YSBIQVZFIHRvIGdvIGluIGFuIElORk8gYm9keSBwYXJ0IG9yIGNhbiBpdCBiZSBzZW50IA0K Pj4+Pj4+PiBpbiBhIENhbGwtSW5mbyBib2R5IHBhcnQ/DQo+Pj4+Pj4+DQo+Pj4+Pj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4+IHNpcGNv cmUgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+IHNpcGNvcmVAaWV0Zi5vcmcNCj4+Pj4+Pj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQo+Pj4+Pj4NCj4+Pj4+DQo+ Pj4+DQo+Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4+IHNpcGNvcmUgbWFpbGluZyBsaXN0DQo+Pj4gc2lwY29yZUBpZXRmLm9yZw0KPj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KPj4+DQo+Pg0K Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IHNp cGNvcmUgbWFpbGluZyBsaXN0DQo+PiBzaXBjb3JlQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCj4+DQo+DQoNCg== From nobody Thu Aug 25 10:02:36 2016 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 9259912D501 for ; Thu, 25 Aug 2016 10:02:33 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3r73DgddNWG for ; Thu, 25 Aug 2016 10:02:32 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 8806C12D0E6 for ; Thu, 25 Aug 2016 10:02:32 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 25 Aug 2016 10:02:31 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <76CCBFA5-8D53-4B1E-A495-4A18AB081384@brianrosen.net> X-Mailer: Eudora for Mac OS X Date: Thu, 25 Aug 2016 09:58:42 -0700 To: Christer Holmberg , Brian Rosen , "sipcore@ietf.org" From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 17:02:33 -0000 At 6:00 AM +0000 8/25/16, Christer Holmberg wrote: > I claim that the updated data IS associated with the application concerned > (ecall). Since we have a request/response protocol carried in INFO and using a well-defined INFO package, we can define "the application concerned" as this request/response protocol, which is part of the larger eCall application. (Not just eCall, it will also be a part of other emergency call applications.) -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- If God had really intended men to fly, He'd make it easier to get to the airport. --George Winters From nobody Thu Aug 25 10:03:36 2016 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 58B0D12D853 for ; Thu, 25 Aug 2016 10:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wyKQfJhg6K6 for ; Thu, 25 Aug 2016 10:03:29 -0700 (PDT) Received: from email.salsgiver.com (email.salsgiver.com [206.67.234.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEFD812D18D for ; Thu, 25 Aug 2016 10:03:29 -0700 (PDT) Received: from [10.33.192.33] ([156.154.81.54]) (authenticated bits=0) by email.salsgiver.com (8.15.2/8.14.3) with ESMTPA id u7PH3N95083717; Thu, 25 Aug 2016 13:03:25 -0400 (EDT) (envelope-from br@salsgiver.com) X-Authentication-Warning: email.salsgiver.com: Host [156.154.81.54] claimed to be [10.33.192.33] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF5AAE0@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Thu, 25 Aug 2016 13:03:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <76CCBFA5-8D53-4B1E-A495-4A18AB081384@brianrosen.net> <05240A95-8319-4555-8B46-FA18B6C27883@brianrosen.net> <5d462933-e3c0-b3a3-958d-5c9d1e86d854@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8BADF5AAE0@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: "Drage, Keith (Nokia - GB)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 17:03:33 -0000 I asked that you not base your response (here in sippcore) on how you = PREFER to transport the data. We have a language interpretation that = Christer asked to take to sipcore: does the language in 6086 PROHIBIT = the data from being carried in Call-Info? sipcore should not opine on what ecrit SHOULD do, but only what it COULD = do with respect to 6086. Is it your opinion that 6086 prohibits us from carrying the data in = Call-Info? Brian > On Aug 25, 2016, at 11:17 AM, Drage, Keith (Nokia - GB) = wrote: >=20 > Time to express my opinion. >=20 > In some circumances, ecall needs to transfer data outside of a normal = call control message. >=20 > The viewpoint is that an INFO message might do that. To use INFO = methods, one MUST define an Info package. There is not other requirement = in ecall for an Info package to exist, so the Info package MUST be one = specific to transferring the ecall data, not an Info package for = something else that just happens to be supporting ecall data transfer = because it is already there. >=20 > Transferring data in Info packages is well known. It does not require = the use of a Call-Info header field to describe the usage. The usage is = defined by the Info-package header field. Using the Call-Info header = field would provide two means of describing the purpose of the same = message body and lead to all sorts of error handling issues when they = become in conflict (because someone failed to read the specification or = some other reason). This my view is clearly that we should follow the = rules of clean design and not do this, particularly as in my view it is = totally unneccessary. >=20 > The remainder goes more into ecall requirements, and therefore falls = more to the scope of ecrit and 3GPP, but indicates why I think it is = unnecessary. >=20 > Ecall consists of two parts - data transferred in the initial INVITE = message. No one has objected to additional data to perform this = function. Further in some circumstances, the PSAP can request more data = to be sent outside that initial request and outside further call control = messages. It is here where the Info package discussion comes in. My view = strongly expressed is that these can be treated from the SIP viewpoint = as two entirely separate transport mechanisms, completely operating = independently at the SIP later. At some point they both transfer an MSD, = but that is separately identified by other header fields. It is then up = to the application in both the PSAP and the calling user agent to = control how these two independent data transfer mechanisms are used. As = such there is no need to start defining interactions between Info = packages and additional data, and no need for one to update the other. >=20 > Regards >=20 > Keith >=20 >=20 >=20 > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul = Kyzivat > Sent: 25 August 2016 15:32 > To: sipcore@ietf.org > Subject: Re: [sipcore] Can an INFO contain a body related to, but not = part of the INFO package? >=20 > On 8/25/16 9:26 AM, Brian Rosen wrote: >> Yes, I=E2=80=99m saying that the ACK satisfies the 6086 use of INFO, = and that it=E2=80=99s okay to send the data with Call-Info. >>=20 >> Yes, I=E2=80=99m agreeing that there is a relationship between the = INFO package and the data. >>=20 >> Yes, I=E2=80=99m disagreeing with your interpretation of the = language. >>=20 >> So, now, what say you sipcore? >=20 > I think the main point of bringing this to sipcore is to get some = fresh input into this discussion. Since I have been party to the = discussion over in ecrit I don't bring anything fresh here. But for = completeness I will register my opinion here too. >=20 > IMO this is not a question about whether the proposed usage is valid = according to 6086 and other rfcs. (I think it is quite clear that it > *is* valid.) Rather this is simply a question of what is the best = design for the desired functionality. As such I don't think it really = needs to be settled in sipcore. >=20 > But I am happy to check if anybody has a different perspective on = this. >=20 > Thanks, > Paul >=20 >> Brian >>=20 >>=20 >>> On Aug 25, 2016, at 9:14 AM, Christer Holmberg = wrote: >>>=20 >>> Hi, >>>=20 >>>> We=E2=80=99re agreeing that there is a relationship between the = command and=20 >>>> the data. >>>>=20 >>>> We=E2=80=99re suggesting that we don=E2=80=99t have to be anal = about the language=20 >>>> and as long as there is an INFO package, and a body part that has=20= >>>> the ACK which is an INFO body part, that the cited language = doesn=E2=80=99t=20 >>>> compel us to use the INFO body part to transport the data, the=20 >>>> Call-Info mechanism is acceptable. >>>>=20 >>>> No one is suggesting that we update 6086, and we agree that 7852 = did=20 >>>> not update 6086. >>>>=20 >>>> It=E2=80=99s just whether that language prohibits use of the = Call-Info to=20 >>>> carry the data when it was prompted by the INFO package request, = and=20 >>>> accompanies the INFO package ACK. >>>=20 >>> You seem to suggest that, just because you use an Info Package for=20= >>> sending SOME of the ecall related information (the request and ACK),=20= >>> that allows you to send the rest of the ecall related information=20 >>> (the data content) without using an Info Package. I really don=E2=80=99= t see=20 >>> how you can parse the cited text in that way. The cited text says=20 >>> that information associated with the application shall be sent using=20= >>> an Info Package. And, both the ACK and the requested data content = are=20 >>> associated with the ecall application. >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>>=20 >>>> Brian >>>>=20 >>>>> On Aug 25, 2016, at 2:00 AM, Christer Holmberg=20 >>>>> wrote: >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> I=C2=B9m glad this is brought to SIPCORE. As one of the info = package=20 >>>>> proponents, please let me clarify my arguments. >>>>>=20 >>>>> The 6086 text that Brian copied says =C2=B3but are not = specifically=20 >>>>> associated with the INFO method and the application concerned=C2=B2.= >>>>>=20 >>>>> I claim that the updated data IS associated with the application=20= >>>>> concerned (ecall). The updated data is requested by the ecall=20 >>>>> application, and the delivered updated data is consumed by the=20 >>>>> ecall application. The updated data is NOT some=20 >>>>> non-ecall-application-related information that is piggybacked in a=20= >>>>> "convenient INFO message" that happens to be sent by the ecall=20 >>>>> application for some other purpose. >>>>>=20 >>>>> (In addition, the updated data is NOT associated with a legacy >>>>> (pre-6086) >>>>> INFO usage, which could justify not using an Info Package. I do=20 >>>>> want to point out that nobody has claimed that the updated data=20 >>>>> would be associated with legacy INFO, but just for completeness) >>>>>=20 >>>>> RFC 7852 does define a mechanism for transporting data, using=20 >>>>> Call-Info etc. But, 7852 does not update 6086, nor can 7852=20 >>>>> override rules and procedures associated with individual SIP=20 >>>>> methods (INFO in this case). I also pointed this out before 7852=20= >>>>> was published, but was told that it=C2=B9s too late to change it=20= >>>>> (granted, the draft was in the RFC editor=C2=B9s queue). >>>>>=20 >>>>> Finally, again for completeness, I want to point out that 6086 = does=20 >>>>> not prevent including Call-Info in INFO as such. The issue is how=20= >>>>> some want to use Call-Info instead of an Info Package. >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Christer >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 25/08/16 03:22, "sipcore on behalf of Brian Rosen" >>>>> wrote: >>>>>=20 >>>>>> Over in ecrit we have a disagreement that relates to interpreting=20= >>>>>> RFC6086. >>>>>>=20 >>>>>> Background: >>>>>> RFC7852 defines something called "Additional Data", which is=20 >>>>>> carried in emergency call signaling. It's data related to the=20 >>>>>> call, e.g., the identity and contact data of the service provider = handling the call. >>>>>> Additional Data is signaled with a Call-Info header field, which=20= >>>>>> contains either a URI pointing to a data block fetched with = HTTPS,=20 >>>>>> or a Content Indirect referencing a body part of the SIP message. = =20 >>>>>> It's usually used on the INVITE of the emergency call, so it can=20= >>>>>> be displayed to the PSAP (emergency call center) call-taker when=20= >>>>>> the call is assigned. >>>>>>=20 >>>>>> Sometimes, this data can change during a call. The example in=20 >>>>>> discussion >>>>>> is telematics data in a vehicle. The vehicle can report things = like >>>>>> the >>>>>> number of occupants and its orientation. The PSAP can request an=20= >>>>>> update mid call (e.g., if the call taker thinks things might have=20= >>>>>> changed). >>>>>>=20 >>>>>> INFO is the chosen mechanism to send the request for update. The=20= >>>>>> device will send a response to the request (an ACK), which is = also=20 >>>>>> sent in INFO. >>>>>> This constitutes a well defined INFO package, and will be=20 >>>>>> registered in the usual way. >>>>>>=20 >>>>>> The Issue at hand: >>>>>> So, the dispute is how the updated data is sent mid call. >>>>>>=20 >>>>>> RFC6086 says >>>>>>=20 >>>>>> NOTE: An INFO request can also contain other body parts that are=20= >>>>>> meaningful within the context of an invite dialog usage but are=20= >>>>>> not specifically associated with the INFO method and the=20 >>>>>> application concerned. >>>>>>=20 >>>>>> The authors of the draft (of which I am one) desire to use the=20 >>>>>> Additional Data mechanism to carry the updated data. The data=20 >>>>>> could be sent in any convenient message, although since the=20 >>>>>> vehicle is sending an ACK, it's likely going to go on that. We'd=20= >>>>>> like to always carry the data in the same way. In an INFO = message=20 >>>>>> it would be carried the same as it is in the INVITE, as = Additional=20 >>>>>> Data. Since the INFO carries an ACK, it would specify the=20 >>>>>> appropriate INFO package, and would contain a body part with the=20= >>>>>> ACK. There would be another body part for the updated data,=20 >>>>>> pointed to by the Call-Info. >>>>>>=20 >>>>>> Some ecrit participants say that the above language of 6086 would=20= >>>>>> prohibit the INFO from containing a Call-Info header with a CID=20= >>>>>> pointing to a MIME body part, because the data was requested by = an=20 >>>>>> INFO, and hence is related to the INFO package. They say that = the=20 >>>>>> data MUST be carried with a body part and Content Disposition = that=20 >>>>>> is part of the INFO package definition. >>>>>>=20 >>>>>> The draft authors claim this 6086 language isn't a = straightjacket,=20 >>>>>> and it's perfectly fine to carry the data referenced by a=20 >>>>>> Call-Info with a Content Indirect body part using the same MIME = type and Content >>>>>> Disposition as it would in an INVITE. When the updated data is = sent >>>>>> in >>>>>> INFO, it's because the INFO is a convenient message (since it's=20= >>>>>> being sent to carry the ACK). >>>>>>=20 >>>>>> Mechanically, both mechanisms can be made to work. The body = parts=20 >>>>>> would be labeled appropriately and there would be no confusion=20 >>>>>> about what they mean or how they would be interpreted. It's=20 >>>>>> really only whether the Call-Info header is present and what the=20= >>>>>> MIME type and Content Disposition the body part containing the=20 >>>>>> data would be. In the author's preferred way, it would be the=20 >>>>>> MIME type and Content Disposition of the Call-Info and in the=20 >>>>>> other point of view it would be the MIME type and Content=20 >>>>>> Disposition of the INFO package. >>>>>>=20 >>>>>> Please ignore your personal preference for whether you think it=20= >>>>>> ought to go in the INFO or not, and please help us interpret = 6086:=20 >>>>>> does the data HAVE to go in an INFO body part or can it be sent = in=20 >>>>>> a Call-Info body part? >>>>>>=20 >>>>>> _______________________________________________ >>>>>> sipcore mailing list >>>>>> sipcore@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>=20 >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >>=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Aug 25 10:08:02 2016 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 7869912B03A for ; Thu, 25 Aug 2016 10:08:01 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7StEXUQbagD for ; Thu, 25 Aug 2016 10:07:53 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF3A126FDC for ; Thu, 25 Aug 2016 10:07:53 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 25 Aug 2016 10:07:52 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF5AAE0@FR712WXCHMBA11.zeu.alcatel-l ucent.com> References: <76CCBFA5-8D53-4B1E-A495-4A18AB081384@brianrosen.net> <05240A95-8319-4555-8B46-FA18B6C27883@brianrosen.net> <5d462933-e3c0-b3a3-958d-5c9d1e86d854@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8BADF5AAE0@FR712WXCHMBA11.zeu.alcatel-l ucent.com> X-Mailer: Eudora for Mac OS X Date: Thu, 25 Aug 2016 10:07:50 -0700 To: "Drage, Keith (Nokia - GB)" , Paul Kyzivat , "sipcore@ietf.org" From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 17:08:01 -0000 We're getting into the ECRIT discussion, which as Paul noted is not the intent of bringing this to sipcore. But I did want to respond to two points: At 3:17 PM +0000 8/25/16, Keith (Nokia - GB) Drage wrote: > Transferring data in Info packages is well known. It does not > require the use of a Call-Info header field to describe the usage. > The usage is defined by the Info-package header field. Using the > Call-Info header field would provide two means of describing the > purpose of the same message body and lead to all sorts of error > handling issues when they become in conflict (because someone > failed to read the specification or some other reason). This my > view is clearly that we should follow the rules of clean design and > not do this, particularly as in my view it is totally unneccessary. The authors want to have the vehicle telematics data always sent the same way, so there is only one way of doing so, not two. > Ecall consists of two parts - data transferred in the initial > INVITE message. No one has objected to additional data to perform > this function. Further in some circumstances, the PSAP can request > more data to be sent outside that initial request and outside > further call control messages. It is here where the Info package > discussion comes in. My view strongly expressed is that these can > be treated from the SIP viewpoint as two entirely separate > transport mechanisms, completely operating independently at the SIP > later. At some point they both transfer an MSD, but that is > separately identified by other header fields. It is then up to the > application in both the PSAP and the calling user agent to control > how these two independent data transfer mechanisms are used. As > such there is no need to start defining interactions between Info > packages and additional data, and no need for one to update the > other. The authors of the draft want to have one mechanism for transporting the vehicle data. There is another, separate mechanism, that requests the vehicle to take an action. In eCall, this action is limited to sending updated data. In the car-crash draft, the action is extended to other things (e.g., flash the lights). This mechanism uses a request/response protocol, which is carried in INFO and uses a well-defined INFO package. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- We must abandon the prevalent belief in the superior wisdom of the ignorant. --Daniel J. Boorstin From nobody Thu Aug 25 10:43:53 2016 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 0081712D0ED for ; Thu, 25 Aug 2016 10:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrAHqHtfn1Cl for ; Thu, 25 Aug 2016 10:43:49 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89F4712D51A for ; Thu, 25 Aug 2016 10:43:49 -0700 (PDT) X-AuditID: c1b4fb3a-c7bff700000009bd-9e-57bf2e539aab Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id 08.4F.02493.35E2FB75; Thu, 25 Aug 2016 19:43:47 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0301.000; Thu, 25 Aug 2016 19:43:46 +0200 From: Christer Holmberg To: Brian Rosen , "Drage, Keith (Nokia - GB)" Thread-Topic: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? Thread-Index: AQHR/t2KCnVeSlQa/k+Sxwkc4yebnqBZqFSAgAAdloCAACwDUA== Date: Thu, 25 Aug 2016 17:43:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC6240C@ESESSMB209.ericsson.se> References: <76CCBFA5-8D53-4B1E-A495-4A18AB081384@brianrosen.net> <05240A95-8319-4555-8B46-FA18B6C27883@brianrosen.net> <5d462933-e3c0-b3a3-958d-5c9d1e86d854@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8BADF5AAE0@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGbHdXjdYb3+4wZNvGhbTjm1gt9iw5TiL xdcfm9gcmD2WLPnJ5HH31iUmj0WHfrAGMEdx2aSk5mSWpRbp2yVwZSzrnMFa0MNW8f/OROYG xh+sXYycHBICJhL7Wk+yg9hCAusZJS6fk+hi5AKylzBKXP39na2LkYODTcBCovufNkiNiECk RPPRv2wgNrOApsSjnXuZQGxhgUSJCX1zmSFqkiTmbNoDZTtJHNnSzgIyhkVAVWLlTC+QMK+A r8SjkxuYIFb9ZZY4tWEOWD2ngKPE1plbwW5jFBCT+H5qDRPELnGJW0/mM0HcLCCxZM95Zghb VOLl439QvyhJrNh+iRFkF8ht63fpQ7QqSkzpfsgOsVdQ4uTMJywTGEVnIZk6C6FjFpKOWUg6 FjCyrGIULU4tLs5NNzLSSy3KTC4uzs/Ty0st2cQIjJqDW35b7WA8+NzxEKMAB6MSD++CB3vD hVgTy4orcw8xSnAwK4nwpunuDxfiTUmsrEotyo8vKs1JLT7EKM3BoiTO6/9SMVxIID2xJDU7 NbUgtQgmy8TBKdXAKL5s6ebYtQfXC0q/7fjYJPf/YnPPvDeX7hbq1viF/H+9/t7p8CCNq306 5/is78UHzOr+15O39GHo77jp7/jnfGV+OGu6SX3IiQsBv0+kqGl1mZ0+VcfI37j1R9DX523/ Yg+G1r/LPfJu2d51H39GM5uWRfPO+ODOsKE0eXfIt0NvtjPsOSb/WlmJpTgj0VCLuag4EQA6 vq5llgIAAA== Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 17:43:51 -0000 SGksDQoNCj4gSSBhc2tlZCB0aGF0IHlvdSBub3QgYmFzZSB5b3VyIHJlc3BvbnNlIChoZXJlIGlu IHNpcHBjb3JlKSBvbiBob3cgeW91IFBSRUZFUiB0byB0cmFuc3BvcnQgdGhlIGRhdGEuICANCj4g V2UgaGF2ZSBhIGxhbmd1YWdlIGludGVycHJldGF0aW9uIHRoYXQgQ2hyaXN0ZXIgYXNrZWQgdG8g dGFrZSB0byBzaXBjb3JlOiBkb2VzIHRoZSBsYW5ndWFnZSBpbiA2MDg2IFBST0hJQklUIHRoZSBk YXRhIGZyb20gYmVpbmcgY2FycmllZCBpbiBDYWxsLUluZm8/DQoNCkFzIEkgaW5kaWNhdGVkIGlu IEVDUklULCBJIHRoaW5rIHRoYXQgaXMgdGhlIHdyb25nIHF1ZXN0aW9uIHRvIGFzayBTSVBDT1JF Lg0KDQo2MDg2IGRvZXMgbm90IHJlY29nbml6ZSAiZGF0YSBiZWluZyBjYXJyaWVkIGluIENhbGwt SW5mbyIuIEFzIGZhciBhcyA2MDg2IGlzIGNvbmNlcm5lZCwgeW91IGVpdGhlciB1c2UgYW4gSW5m byBQYWNrYWdlLCBvciB5b3UgZG9uJ3QsIGFuZCB0aGUgcXVlc3Rpb24gaXMgd2hldGhlciB5b3Ug aGF2ZSB0byB1c2UgYW4gSW5mbyBQYWNrYWdlLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQo= From nobody Thu Aug 25 11:10:40 2016 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 0BBBD12D592 for ; Thu, 25 Aug 2016 11:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrIutv_9ZrUz for ; Thu, 25 Aug 2016 11:10:37 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A563212D162 for ; Thu, 25 Aug 2016 11:10:37 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id A4445B4C5E4F5; Thu, 25 Aug 2016 18:10:31 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u7PIAZl6026879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 25 Aug 2016 18:10:35 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u7PIAYBm013084 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Aug 2016 20:10:34 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.50]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Thu, 25 Aug 2016 20:10:34 +0200 From: "Drage, Keith (Nokia - GB)" To: Christer Holmberg , Brian Rosen Thread-Topic: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? Thread-Index: AQHR/t2d3LN8JlqI6kKCkuU4GVEabKBZxlAw////moCAAAtJAIAAKB4g Date: Thu, 25 Aug 2016 18:10:34 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF5AE6D@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <76CCBFA5-8D53-4B1E-A495-4A18AB081384@brianrosen.net> <05240A95-8319-4555-8B46-FA18B6C27883@brianrosen.net> <5d462933-e3c0-b3a3-958d-5c9d1e86d854@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8BADF5AAE0@FR712WXCHMBA11.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B4BC6240C@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC6240C@ESESSMB209.ericsson.se> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 18:10:39 -0000 SSBhZ3JlZSB3aXRoIENocmlzdGVyLiBUaGUgZGV0ZXJtaW5pbmcgZmFjdG9yIGlzIHdoYXQgZmFs bHMgaW4gdGhlIHNjb3BlIG9mIFNJUENPUkUgdG8gcGFzcyBqdWRnZW1lbnQgb24sIGFuZCBub3Qg bmVjZXNzYXJpbHkgdGhlIHF1ZXN0aW9uIHlvdSAoQnJpYW4pIGFza2VkLg0KDQpUbyByZXNwb25k IHRvIHRoYXQgcHJvYmxlbSwgSSBoYWQgdG8gcHJvdmlkZSBtb3JlIGluZm9ybWF0aW9uIHRoYXQg eW91IChCcmlhbikgY2FyZWQgdG8gZG8uIEkgdGhpbmsgdGhlIHF1ZXN0aW9uIGZhaWxlZCB0byBi ZSBhc2tlZCBhZGVxdWF0ZWx5IGluIHlvdXIgbWFpbC4NCg0KS2VpdGgNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IENocmlzdGVyIEhvbG1iZXJnIFttYWlsdG86Y2hyaXN0ZXIu aG9sbWJlcmdAZXJpY3Nzb24uY29tXSANClNlbnQ6IDI1IEF1Z3VzdCAyMDE2IDE4OjQ0DQpUbzog QnJpYW4gUm9zZW47IERyYWdlLCBLZWl0aCAoTm9raWEgLSBHQikNCkNjOiBzaXBjb3JlQGlldGYu b3JnDQpTdWJqZWN0OiBSRTogW3NpcGNvcmVdIENhbiBhbiBJTkZPIGNvbnRhaW4gYSBib2R5IHJl bGF0ZWQgdG8sIGJ1dCBub3QgcGFydCBvZiB0aGUgSU5GTyBwYWNrYWdlPw0KDQpIaSwNCg0KPiBJ IGFza2VkIHRoYXQgeW91IG5vdCBiYXNlIHlvdXIgcmVzcG9uc2UgKGhlcmUgaW4gc2lwcGNvcmUp IG9uIGhvdyB5b3UgUFJFRkVSIHRvIHRyYW5zcG9ydCB0aGUgZGF0YS4gIA0KPiBXZSBoYXZlIGEg bGFuZ3VhZ2UgaW50ZXJwcmV0YXRpb24gdGhhdCBDaHJpc3RlciBhc2tlZCB0byB0YWtlIHRvIHNp cGNvcmU6IGRvZXMgdGhlIGxhbmd1YWdlIGluIDYwODYgUFJPSElCSVQgdGhlIGRhdGEgZnJvbSBi ZWluZyBjYXJyaWVkIGluIENhbGwtSW5mbz8NCg0KQXMgSSBpbmRpY2F0ZWQgaW4gRUNSSVQsIEkg dGhpbmsgdGhhdCBpcyB0aGUgd3JvbmcgcXVlc3Rpb24gdG8gYXNrIFNJUENPUkUuDQoNCjYwODYg ZG9lcyBub3QgcmVjb2duaXplICJkYXRhIGJlaW5nIGNhcnJpZWQgaW4gQ2FsbC1JbmZvIi4gQXMg ZmFyIGFzIDYwODYgaXMgY29uY2VybmVkLCB5b3UgZWl0aGVyIHVzZSBhbiBJbmZvIFBhY2thZ2Us IG9yIHlvdSBkb24ndCwgYW5kIHRoZSBxdWVzdGlvbiBpcyB3aGV0aGVyIHlvdSBoYXZlIHRvIHVz ZSBhbiBJbmZvIFBhY2thZ2UuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg== From nobody Thu Aug 25 11:10:51 2016 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 D336412D5D0 for ; Thu, 25 Aug 2016 11:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEVI9wnLoDDp for ; Thu, 25 Aug 2016 11:10:38 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD75912D563 for ; Thu, 25 Aug 2016 11:10:37 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 9C4E955A68C67; Thu, 25 Aug 2016 18:10:31 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u7PIAY0Z026875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 25 Aug 2016 18:10:35 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u7PIAYWp013063 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Aug 2016 20:10:34 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.50]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Thu, 25 Aug 2016 20:10:33 +0200 From: "Drage, Keith (Nokia - GB)" To: Brian Rosen Thread-Topic: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? Thread-Index: AQHR/t2d3LN8JlqI6kKCkuU4GVEabKBZxlAw////moCAADCT8A== Date: Thu, 25 Aug 2016 18:10:33 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF5AE60@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <76CCBFA5-8D53-4B1E-A495-4A18AB081384@brianrosen.net> <05240A95-8319-4555-8B46-FA18B6C27883@brianrosen.net> <5d462933-e3c0-b3a3-958d-5c9d1e86d854@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8BADF5AAE0@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 18:10:45 -0000 SSB0aGluayBpdCBpcyBub3QgYSBwcm9oaWJpdGlvbiAtIGl0IGhhcyBhIHNlbWFudGljIGFmdGVy IGFsbCwgYnV0IHJhdGhlciBhIGRldmlhdGlvbiBmcm9tIGJlc3QgcHJhY3RpY2Ugb2Yga2VlcGlu ZyB0aGluZ3Mgc2ltcGxlLiBBZGRpbmcgaXQgaW4gcmVzcGVjdCBvZiB0aGUgSW5mby1QYWNrYWdl IGhhcyB0byBoYXZlIHplcm8gaW1wYWN0LiANCg0KSWYgdXNpbmcgSU5GTywgdGhlbiB0aGUgSW5m by1QYWNrYWdlIGRlZmluZXMgd2hhdCBpcyBjYXJyaWVkLCB1c2luZyB0aGUgSW5mby1QYWNrYWdl IGhlYWRlciBmaWVsZC4gQWRkaW5nIENhbGwtSW5mbyBpcyBub3QgYmVsdCBhbmQgYnJhY2VzLCBy YXRoZXIgaXQgaXMgbm90aGluZyB0byBkbyB3aXRoIHRoZSBjb3JyZWN0IG9wZXJhdGlvbiBvZiB0 aGUgSW5mby1QYWNrYWdlIGFuZCB0aGVyZWZvcmUgYSBjb21wbGV4aXR5IHRoYXQgd2lsbCBkZWZp bml0ZWx5IGxlYWQgdG8gZXJyb3IgcHJvbmUgaW1wbGVtZW50YXRpb25zLg0KDQpBcmUgeW91IGdv aW5nIHRvIG5vdyBzdGFydCBwcm9wb3NpbmcgYWRkaW5nIHRoZSBDYWxsLUluZm8gaGVhZGVyIGZp ZWxkIHRvIGFsbCB1c2FnZXMgb2YgdGhlIEdlb2xvY2F0aW9uIGhlYWRlciBmaWVsZCB0aGF0IHBv aW50IHRvIGEgbWVzc2FnZSBib2R5LCBiZWNhdXNlIHRoYXQgaXMgdGhlIGxvZ2ljYWwgcHJvZ3Jl c3Npb24gb2YgdXNpbmcgaXQgaW4gcmVzcGVjdCBvZiB0aGUgSW5mbyBwYWNrYWdlIGRhdGEgY29u dGVudHMuDQoNCktlaXRoDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBCcmlh biBSb3NlbiBbbWFpbHRvOmJyQHNhbHNnaXZlci5jb21dIA0KU2VudDogMjUgQXVndXN0IDIwMTYg MTg6MDMNClRvOiBEcmFnZSwgS2VpdGggKE5va2lhIC0gR0IpDQpDYzogUGF1bCBLeXppdmF0OyBz aXBjb3JlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NpcGNvcmVdIENhbiBhbiBJTkZPIGNvbnRh aW4gYSBib2R5IHJlbGF0ZWQgdG8sIGJ1dCBub3QgcGFydCBvZiB0aGUgSU5GTyBwYWNrYWdlPw0K DQpJIGFza2VkIHRoYXQgeW91IG5vdCBiYXNlIHlvdXIgcmVzcG9uc2UgKGhlcmUgaW4gc2lwcGNv cmUpIG9uIGhvdyB5b3UgUFJFRkVSIHRvIHRyYW5zcG9ydCB0aGUgZGF0YS4gIFdlIGhhdmUgYSBs YW5ndWFnZSBpbnRlcnByZXRhdGlvbiB0aGF0IENocmlzdGVyIGFza2VkIHRvIHRha2UgdG8gc2lw Y29yZTogZG9lcyB0aGUgbGFuZ3VhZ2UgaW4gNjA4NiBQUk9ISUJJVCB0aGUgZGF0YSBmcm9tIGJl aW5nIGNhcnJpZWQgaW4gQ2FsbC1JbmZvPw0KDQpzaXBjb3JlIHNob3VsZCBub3Qgb3BpbmUgb24g d2hhdCBlY3JpdCBTSE9VTEQgZG8sIGJ1dCBvbmx5IHdoYXQgaXQgQ09VTEQgZG8gd2l0aCByZXNw ZWN0IHRvIDYwODYuDQoNCklzIGl0IHlvdXIgb3BpbmlvbiB0aGF0IDYwODYgcHJvaGliaXRzIHVz IGZyb20gY2FycnlpbmcgdGhlIGRhdGEgaW4gQ2FsbC1JbmZvPw0KDQpCcmlhbg0KDQo+IE9uIEF1 ZyAyNSwgMjAxNiwgYXQgMTE6MTcgQU0sIERyYWdlLCBLZWl0aCAoTm9raWEgLSBHQikgPGtlaXRo LmRyYWdlQG5va2lhLmNvbT4gd3JvdGU6DQo+IA0KPiBUaW1lIHRvIGV4cHJlc3MgbXkgb3Bpbmlv bi4NCj4gDQo+IEluIHNvbWUgY2lyY3VtYW5jZXMsIGVjYWxsIG5lZWRzIHRvIHRyYW5zZmVyIGRh dGEgb3V0c2lkZSBvZiBhIG5vcm1hbCBjYWxsIGNvbnRyb2wgbWVzc2FnZS4NCj4gDQo+IFRoZSB2 aWV3cG9pbnQgaXMgdGhhdCBhbiBJTkZPIG1lc3NhZ2UgbWlnaHQgZG8gdGhhdC4gVG8gdXNlIElO Rk8gbWV0aG9kcywgb25lIE1VU1QgZGVmaW5lIGFuIEluZm8gcGFja2FnZS4gVGhlcmUgaXMgbm90 IG90aGVyIHJlcXVpcmVtZW50IGluIGVjYWxsIGZvciBhbiBJbmZvIHBhY2thZ2UgdG8gZXhpc3Qs IHNvIHRoZSBJbmZvIHBhY2thZ2UgTVVTVCBiZSBvbmUgc3BlY2lmaWMgdG8gdHJhbnNmZXJyaW5n IHRoZSBlY2FsbCBkYXRhLCBub3QgYW4gSW5mbyBwYWNrYWdlIGZvciBzb21ldGhpbmcgZWxzZSB0 aGF0IGp1c3QgaGFwcGVucyB0byBiZSBzdXBwb3J0aW5nIGVjYWxsIGRhdGEgdHJhbnNmZXIgYmVj YXVzZSBpdCBpcyBhbHJlYWR5IHRoZXJlLg0KPiANCj4gVHJhbnNmZXJyaW5nIGRhdGEgaW4gSW5m byBwYWNrYWdlcyBpcyB3ZWxsIGtub3duLiBJdCBkb2VzIG5vdCByZXF1aXJlIHRoZSB1c2Ugb2Yg YSBDYWxsLUluZm8gaGVhZGVyIGZpZWxkIHRvIGRlc2NyaWJlIHRoZSB1c2FnZS4gVGhlIHVzYWdl IGlzIGRlZmluZWQgYnkgdGhlIEluZm8tcGFja2FnZSBoZWFkZXIgZmllbGQuIFVzaW5nIHRoZSBD YWxsLUluZm8gaGVhZGVyIGZpZWxkIHdvdWxkIHByb3ZpZGUgdHdvIG1lYW5zIG9mIGRlc2NyaWJp bmcgdGhlIHB1cnBvc2Ugb2YgdGhlIHNhbWUgbWVzc2FnZSBib2R5IGFuZCBsZWFkIHRvIGFsbCBz b3J0cyBvZiBlcnJvciBoYW5kbGluZyBpc3N1ZXMgd2hlbiB0aGV5IGJlY29tZSBpbiBjb25mbGlj dCAoYmVjYXVzZSBzb21lb25lIGZhaWxlZCB0byByZWFkIHRoZSBzcGVjaWZpY2F0aW9uIG9yIHNv bWUgb3RoZXIgcmVhc29uKS4gVGhpcyBteSB2aWV3IGlzIGNsZWFybHkgdGhhdCB3ZSBzaG91bGQg Zm9sbG93IHRoZSBydWxlcyBvZiBjbGVhbiBkZXNpZ24gYW5kIG5vdCBkbyB0aGlzLCBwYXJ0aWN1 bGFybHkgYXMgaW4gbXkgdmlldyBpdCBpcyB0b3RhbGx5IHVubmVjY2Vzc2FyeS4NCj4gDQo+IFRo ZSByZW1haW5kZXIgZ29lcyBtb3JlIGludG8gZWNhbGwgcmVxdWlyZW1lbnRzLCBhbmQgdGhlcmVm b3JlIGZhbGxzIG1vcmUgdG8gdGhlIHNjb3BlIG9mIGVjcml0IGFuZCAzR1BQLCBidXQgaW5kaWNh dGVzIHdoeSBJIHRoaW5rIGl0IGlzIHVubmVjZXNzYXJ5Lg0KPiANCj4gRWNhbGwgY29uc2lzdHMg b2YgdHdvIHBhcnRzIC0gZGF0YSB0cmFuc2ZlcnJlZCBpbiB0aGUgaW5pdGlhbCBJTlZJVEUgbWVz c2FnZS4gTm8gb25lIGhhcyBvYmplY3RlZCB0byBhZGRpdGlvbmFsIGRhdGEgdG8gcGVyZm9ybSB0 aGlzIGZ1bmN0aW9uLiBGdXJ0aGVyIGluIHNvbWUgY2lyY3Vtc3RhbmNlcywgdGhlIFBTQVAgY2Fu IHJlcXVlc3QgbW9yZSBkYXRhIHRvIGJlIHNlbnQgb3V0c2lkZSB0aGF0IGluaXRpYWwgcmVxdWVz dCBhbmQgb3V0c2lkZSBmdXJ0aGVyIGNhbGwgY29udHJvbCBtZXNzYWdlcy4gSXQgaXMgaGVyZSB3 aGVyZSB0aGUgSW5mbyBwYWNrYWdlIGRpc2N1c3Npb24gY29tZXMgaW4uIE15IHZpZXcgc3Ryb25n bHkgZXhwcmVzc2VkIGlzIHRoYXQgdGhlc2UgY2FuIGJlIHRyZWF0ZWQgZnJvbSB0aGUgU0lQIHZp ZXdwb2ludCBhcyB0d28gZW50aXJlbHkgc2VwYXJhdGUgdHJhbnNwb3J0IG1lY2hhbmlzbXMsIGNv bXBsZXRlbHkgb3BlcmF0aW5nIGluZGVwZW5kZW50bHkgYXQgdGhlIFNJUCBsYXRlci4gQXQgc29t ZSBwb2ludCB0aGV5IGJvdGggdHJhbnNmZXIgYW4gTVNELCBidXQgdGhhdCBpcyBzZXBhcmF0ZWx5 IGlkZW50aWZpZWQgYnkgb3RoZXIgaGVhZGVyIGZpZWxkcy4gSXQgaXMgdGhlbiB1cCB0byB0aGUg YXBwbGljYXRpb24gaW4gYm90aCB0aGUgUFNBUCBhbmQgdGhlIGNhbGxpbmcgdXNlciBhZ2VudCB0 byBjb250cm9sIGhvdyB0aGVzZSB0d28gaW5kZXBlbmRlbnQgZGF0YSB0cmFuc2ZlciBtZWNoYW5p c21zIGFyZSB1c2VkLiBBcyBzdWNoIHRoZXJlIGlzIG5vIG5lZWQgdG8gc3RhcnQgZGVmaW5pbmcg aW50ZXJhY3Rpb25zIGJldHdlZW4gSW5mbyBwYWNrYWdlcyBhbmQgYWRkaXRpb25hbCBkYXRhLCBh bmQgbm8gbmVlZCBmb3Igb25lIHRvIHVwZGF0ZSB0aGUgb3RoZXIuDQo+IA0KPiBSZWdhcmRzDQo+ IA0KPiBLZWl0aA0KPiANCj4gDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBzaXBjb3JlIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgUGF1bCANCj4gS3l6aXZhdA0KPiBTZW50OiAyNSBBdWd1c3QgMjAxNiAxNTozMg0KPiBUbzog c2lwY29yZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3NpcGNvcmVdIENhbiBhbiBJTkZPIGNv bnRhaW4gYSBib2R5IHJlbGF0ZWQgdG8sIGJ1dCBub3QgcGFydCBvZiB0aGUgSU5GTyBwYWNrYWdl Pw0KPiANCj4gT24gOC8yNS8xNiA5OjI2IEFNLCBCcmlhbiBSb3NlbiB3cm90ZToNCj4+IFllcywg SeKAmW0gc2F5aW5nIHRoYXQgdGhlIEFDSyBzYXRpc2ZpZXMgdGhlIDYwODYgdXNlIG9mIElORk8s IGFuZCB0aGF0IGl04oCZcyBva2F5IHRvIHNlbmQgdGhlIGRhdGEgd2l0aCBDYWxsLUluZm8uDQo+ PiANCj4+IFllcywgSeKAmW0gYWdyZWVpbmcgdGhhdCB0aGVyZSBpcyBhIHJlbGF0aW9uc2hpcCBi ZXR3ZWVuIHRoZSBJTkZPIHBhY2thZ2UgYW5kIHRoZSBkYXRhLg0KPj4gDQo+PiBZZXMsIEnigJlt IGRpc2FncmVlaW5nIHdpdGggeW91ciBpbnRlcnByZXRhdGlvbiBvZiB0aGUgbGFuZ3VhZ2UuDQo+ PiANCj4+IFNvLCBub3csIHdoYXQgc2F5IHlvdSBzaXBjb3JlPw0KPiANCj4gSSB0aGluayB0aGUg bWFpbiBwb2ludCBvZiBicmluZ2luZyB0aGlzIHRvIHNpcGNvcmUgaXMgdG8gZ2V0IHNvbWUgZnJl c2ggaW5wdXQgaW50byB0aGlzIGRpc2N1c3Npb24uIFNpbmNlIEkgaGF2ZSBiZWVuIHBhcnR5IHRv IHRoZSBkaXNjdXNzaW9uIG92ZXIgaW4gZWNyaXQgSSBkb24ndCBicmluZyBhbnl0aGluZyBmcmVz aCBoZXJlLiBCdXQgZm9yIGNvbXBsZXRlbmVzcyBJIHdpbGwgcmVnaXN0ZXIgbXkgb3BpbmlvbiBo ZXJlIHRvby4NCj4gDQo+IElNTyB0aGlzIGlzIG5vdCBhIHF1ZXN0aW9uIGFib3V0IHdoZXRoZXIg dGhlIHByb3Bvc2VkIHVzYWdlIGlzIHZhbGlkIA0KPiBhY2NvcmRpbmcgdG8gNjA4NiBhbmQgb3Ro ZXIgcmZjcy4gKEkgdGhpbmsgaXQgaXMgcXVpdGUgY2xlYXIgdGhhdCBpdA0KPiAqaXMqIHZhbGlk LikgUmF0aGVyIHRoaXMgaXMgc2ltcGx5IGEgcXVlc3Rpb24gb2Ygd2hhdCBpcyB0aGUgYmVzdCBk ZXNpZ24gZm9yIHRoZSBkZXNpcmVkIGZ1bmN0aW9uYWxpdHkuIEFzIHN1Y2ggSSBkb24ndCB0aGlu ayBpdCByZWFsbHkgbmVlZHMgdG8gYmUgc2V0dGxlZCBpbiBzaXBjb3JlLg0KPiANCj4gQnV0IEkg YW0gaGFwcHkgdG8gY2hlY2sgaWYgYW55Ym9keSBoYXMgYSBkaWZmZXJlbnQgcGVyc3BlY3RpdmUg b24gdGhpcy4NCj4gDQo+IAlUaGFua3MsDQo+IAlQYXVsDQo+IA0KPj4gQnJpYW4NCj4+IA0KPj4g DQo+Pj4gT24gQXVnIDI1LCAyMDE2LCBhdCA5OjE0IEFNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hy aXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4+PiANCj4+PiBIaSwNCj4+PiAN Cj4+Pj4gV2XigJlyZSBhZ3JlZWluZyB0aGF0IHRoZXJlIGlzIGEgcmVsYXRpb25zaGlwIGJldHdl ZW4gdGhlIGNvbW1hbmQgYW5kIA0KPj4+PiB0aGUgZGF0YS4NCj4+Pj4gDQo+Pj4+IFdl4oCZcmUg c3VnZ2VzdGluZyB0aGF0IHdlIGRvbuKAmXQgaGF2ZSB0byBiZSBhbmFsIGFib3V0IHRoZSBsYW5n dWFnZSANCj4+Pj4gYW5kIGFzIGxvbmcgYXMgdGhlcmUgaXMgYW4gSU5GTyBwYWNrYWdlLCBhbmQg YSBib2R5IHBhcnQgdGhhdCBoYXMgDQo+Pj4+IHRoZSBBQ0sgd2hpY2ggaXMgYW4gSU5GTyBib2R5 IHBhcnQsIHRoYXQgdGhlIGNpdGVkIGxhbmd1YWdlIGRvZXNu4oCZdCANCj4+Pj4gY29tcGVsIHVz IHRvIHVzZSB0aGUgSU5GTyBib2R5IHBhcnQgdG8gdHJhbnNwb3J0IHRoZSBkYXRhLCB0aGUgDQo+ Pj4+IENhbGwtSW5mbyBtZWNoYW5pc20gaXMgYWNjZXB0YWJsZS4NCj4+Pj4gDQo+Pj4+IE5vIG9u ZSBpcyBzdWdnZXN0aW5nIHRoYXQgd2UgdXBkYXRlIDYwODYsIGFuZCB3ZSBhZ3JlZSB0aGF0IDc4 NTIgDQo+Pj4+IGRpZCBub3QgdXBkYXRlIDYwODYuDQo+Pj4+IA0KPj4+PiBJdOKAmXMganVzdCB3 aGV0aGVyIHRoYXQgbGFuZ3VhZ2UgcHJvaGliaXRzIHVzZSBvZiB0aGUgQ2FsbC1JbmZvIHRvIA0K Pj4+PiBjYXJyeSB0aGUgZGF0YSB3aGVuIGl0IHdhcyBwcm9tcHRlZCBieSB0aGUgSU5GTyBwYWNr YWdlIHJlcXVlc3QsIA0KPj4+PiBhbmQgYWNjb21wYW5pZXMgdGhlIElORk8gcGFja2FnZSBBQ0su DQo+Pj4gDQo+Pj4gWW91IHNlZW0gdG8gc3VnZ2VzdCB0aGF0LCBqdXN0IGJlY2F1c2UgeW91IHVz ZSBhbiBJbmZvIFBhY2thZ2UgZm9yIA0KPj4+IHNlbmRpbmcgU09NRSBvZiB0aGUgZWNhbGwgcmVs YXRlZCBpbmZvcm1hdGlvbiAodGhlIHJlcXVlc3QgYW5kIEFDSyksIA0KPj4+IHRoYXQgYWxsb3dz IHlvdSB0byBzZW5kIHRoZSByZXN0IG9mIHRoZSBlY2FsbCByZWxhdGVkIGluZm9ybWF0aW9uIA0K Pj4+ICh0aGUgZGF0YSBjb250ZW50KSB3aXRob3V0IHVzaW5nIGFuIEluZm8gUGFja2FnZS4gSSBy ZWFsbHkgZG9u4oCZdCBzZWUgDQo+Pj4gaG93IHlvdSBjYW4gcGFyc2UgdGhlIGNpdGVkIHRleHQg aW4gdGhhdCB3YXkuIFRoZSBjaXRlZCB0ZXh0IHNheXMgDQo+Pj4gdGhhdCBpbmZvcm1hdGlvbiBh c3NvY2lhdGVkIHdpdGggdGhlIGFwcGxpY2F0aW9uIHNoYWxsIGJlIHNlbnQgdXNpbmcgDQo+Pj4g YW4gSW5mbyBQYWNrYWdlLiBBbmQsIGJvdGggdGhlIEFDSyBhbmQgdGhlIHJlcXVlc3RlZCBkYXRh IGNvbnRlbnQgDQo+Pj4gYXJlIGFzc29jaWF0ZWQgd2l0aCB0aGUgZWNhbGwgYXBwbGljYXRpb24u DQo+Pj4gDQo+Pj4gUmVnYXJkcywNCj4+PiANCj4+PiBDaHJpc3Rlcg0KPj4+IA0KPj4+IA0KPj4+ IA0KPj4+IA0KPj4+IA0KPj4+PiANCj4+Pj4gQnJpYW4NCj4+Pj4gDQo+Pj4+PiBPbiBBdWcgMjUs IDIwMTYsIGF0IDI6MDAgQU0sIENocmlzdGVyIEhvbG1iZXJnIA0KPj4+Pj4gPGNocmlzdGVyLmhv bG1iZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+Pj4+PiANCj4+Pj4+IEhpLA0KPj4+Pj4gDQo+ Pj4+PiBJwrltIGdsYWQgdGhpcyBpcyBicm91Z2h0IHRvIFNJUENPUkUuIEFzIG9uZSBvZiB0aGUg aW5mbyBwYWNrYWdlIA0KPj4+Pj4gcHJvcG9uZW50cywgcGxlYXNlIGxldCBtZSBjbGFyaWZ5IG15 IGFyZ3VtZW50cy4NCj4+Pj4+IA0KPj4+Pj4gVGhlIDYwODYgdGV4dCB0aGF0IEJyaWFuIGNvcGll ZCBzYXlzIMKzYnV0IGFyZSBub3Qgc3BlY2lmaWNhbGx5IA0KPj4+Pj4gYXNzb2NpYXRlZCB3aXRo IHRoZSBJTkZPIG1ldGhvZCBhbmQgdGhlIGFwcGxpY2F0aW9uIGNvbmNlcm5lZMKyLg0KPj4+Pj4g DQo+Pj4+PiBJIGNsYWltIHRoYXQgdGhlIHVwZGF0ZWQgZGF0YSBJUyBhc3NvY2lhdGVkIHdpdGgg dGhlIGFwcGxpY2F0aW9uIA0KPj4+Pj4gY29uY2VybmVkIChlY2FsbCkuIFRoZSB1cGRhdGVkIGRh dGEgaXMgcmVxdWVzdGVkIGJ5IHRoZSBlY2FsbCANCj4+Pj4+IGFwcGxpY2F0aW9uLCBhbmQgdGhl IGRlbGl2ZXJlZCB1cGRhdGVkIGRhdGEgaXMgY29uc3VtZWQgYnkgdGhlIA0KPj4+Pj4gZWNhbGwg YXBwbGljYXRpb24uIFRoZSB1cGRhdGVkIGRhdGEgaXMgTk9UIHNvbWUgDQo+Pj4+PiBub24tZWNh bGwtYXBwbGljYXRpb24tcmVsYXRlZCBpbmZvcm1hdGlvbiB0aGF0IGlzIHBpZ2d5YmFja2VkIGlu IGEgDQo+Pj4+PiAiY29udmVuaWVudCBJTkZPIG1lc3NhZ2UiIHRoYXQgaGFwcGVucyB0byBiZSBz ZW50IGJ5IHRoZSBlY2FsbCANCj4+Pj4+IGFwcGxpY2F0aW9uIGZvciBzb21lIG90aGVyIHB1cnBv c2UuDQo+Pj4+PiANCj4+Pj4+IChJbiBhZGRpdGlvbiwgdGhlIHVwZGF0ZWQgZGF0YSBpcyBOT1Qg YXNzb2NpYXRlZCB3aXRoIGEgbGVnYWN5DQo+Pj4+PiAocHJlLTYwODYpDQo+Pj4+PiBJTkZPIHVz YWdlLCB3aGljaCBjb3VsZCBqdXN0aWZ5IG5vdCB1c2luZyBhbiBJbmZvIFBhY2thZ2UuIEkgZG8g DQo+Pj4+PiB3YW50IHRvIHBvaW50IG91dCB0aGF0IG5vYm9keSBoYXMgY2xhaW1lZCB0aGF0IHRo ZSB1cGRhdGVkIGRhdGEgDQo+Pj4+PiB3b3VsZCBiZSBhc3NvY2lhdGVkIHdpdGggbGVnYWN5IElO Rk8sIGJ1dCBqdXN0IGZvciBjb21wbGV0ZW5lc3MpDQo+Pj4+PiANCj4+Pj4+IFJGQyA3ODUyIGRv ZXMgZGVmaW5lIGEgbWVjaGFuaXNtIGZvciB0cmFuc3BvcnRpbmcgZGF0YSwgdXNpbmcgDQo+Pj4+ PiBDYWxsLUluZm8gZXRjLiBCdXQsIDc4NTIgZG9lcyBub3QgdXBkYXRlIDYwODYsIG5vciBjYW4g Nzg1MiANCj4+Pj4+IG92ZXJyaWRlIHJ1bGVzIGFuZCBwcm9jZWR1cmVzIGFzc29jaWF0ZWQgd2l0 aCBpbmRpdmlkdWFsIFNJUCANCj4+Pj4+IG1ldGhvZHMgKElORk8gaW4gdGhpcyBjYXNlKS4gSSBh bHNvIHBvaW50ZWQgdGhpcyBvdXQgYmVmb3JlIDc4NTIgDQo+Pj4+PiB3YXMgcHVibGlzaGVkLCBi dXQgd2FzIHRvbGQgdGhhdCBpdMK5cyB0b28gbGF0ZSB0byBjaGFuZ2UgaXQgDQo+Pj4+PiAoZ3Jh bnRlZCwgdGhlIGRyYWZ0IHdhcyBpbiB0aGUgUkZDIGVkaXRvcsK5cyBxdWV1ZSkuDQo+Pj4+PiAN Cj4+Pj4+IEZpbmFsbHksIGFnYWluIGZvciBjb21wbGV0ZW5lc3MsIEkgd2FudCB0byBwb2ludCBv dXQgdGhhdCA2MDg2IA0KPj4+Pj4gZG9lcyBub3QgcHJldmVudCBpbmNsdWRpbmcgQ2FsbC1JbmZv IGluIElORk8gYXMgc3VjaC4gVGhlIGlzc3VlIGlzIA0KPj4+Pj4gaG93IHNvbWUgd2FudCB0byB1 c2UgQ2FsbC1JbmZvIGluc3RlYWQgb2YgYW4gSW5mbyBQYWNrYWdlLg0KPj4+Pj4gDQo+Pj4+PiBS ZWdhcmRzLA0KPj4+Pj4gDQo+Pj4+PiBDaHJpc3Rlcg0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IA0K Pj4+Pj4gT24gMjUvMDgvMTYgMDM6MjIsICJzaXBjb3JlIG9uIGJlaGFsZiBvZiBCcmlhbiBSb3Nl biINCj4+Pj4+IDxzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGJyQGJyaWFu cm9zZW4ubmV0PiB3cm90ZToNCj4+Pj4+IA0KPj4+Pj4+IE92ZXIgaW4gZWNyaXQgd2UgaGF2ZSBh IGRpc2FncmVlbWVudCB0aGF0IHJlbGF0ZXMgdG8gaW50ZXJwcmV0aW5nIA0KPj4+Pj4+IFJGQzYw ODYuDQo+Pj4+Pj4gDQo+Pj4+Pj4gQmFja2dyb3VuZDoNCj4+Pj4+PiBSRkM3ODUyIGRlZmluZXMg c29tZXRoaW5nIGNhbGxlZCAiQWRkaXRpb25hbCBEYXRhIiwgd2hpY2ggaXMgDQo+Pj4+Pj4gY2Fy cmllZCBpbiBlbWVyZ2VuY3kgY2FsbCBzaWduYWxpbmcuICBJdCdzIGRhdGEgcmVsYXRlZCB0byB0 aGUgDQo+Pj4+Pj4gY2FsbCwgZS5nLiwgdGhlIGlkZW50aXR5IGFuZCBjb250YWN0IGRhdGEgb2Yg dGhlIHNlcnZpY2UgcHJvdmlkZXIgaGFuZGxpbmcgdGhlIGNhbGwuDQo+Pj4+Pj4gQWRkaXRpb25h bCBEYXRhIGlzIHNpZ25hbGVkIHdpdGggYSBDYWxsLUluZm8gaGVhZGVyIGZpZWxkLCB3aGljaCAN Cj4+Pj4+PiBjb250YWlucyBlaXRoZXIgYSBVUkkgcG9pbnRpbmcgdG8gYSBkYXRhIGJsb2NrIGZl dGNoZWQgd2l0aCANCj4+Pj4+PiBIVFRQUywgb3IgYSBDb250ZW50IEluZGlyZWN0IHJlZmVyZW5j aW5nIGEgYm9keSBwYXJ0IG9mIHRoZSBTSVAgbWVzc2FnZS4NCj4+Pj4+PiBJdCdzIHVzdWFsbHkg dXNlZCBvbiB0aGUgSU5WSVRFIG9mIHRoZSBlbWVyZ2VuY3kgY2FsbCwgc28gaXQgY2FuIA0KPj4+ Pj4+IGJlIGRpc3BsYXllZCB0byB0aGUgUFNBUCAoZW1lcmdlbmN5IGNhbGwgY2VudGVyKSBjYWxs LXRha2VyIHdoZW4gDQo+Pj4+Pj4gdGhlIGNhbGwgaXMgYXNzaWduZWQuDQo+Pj4+Pj4gDQo+Pj4+ Pj4gU29tZXRpbWVzLCB0aGlzIGRhdGEgY2FuIGNoYW5nZSBkdXJpbmcgYSBjYWxsLiAgVGhlIGV4 YW1wbGUgaW4gDQo+Pj4+Pj4gZGlzY3Vzc2lvbg0KPj4+Pj4+IGlzIHRlbGVtYXRpY3MgZGF0YSBp biBhIHZlaGljbGUuICAgVGhlIHZlaGljbGUgY2FuIHJlcG9ydCB0aGluZ3MgbGlrZQ0KPj4+Pj4+ IHRoZQ0KPj4+Pj4+IG51bWJlciBvZiBvY2N1cGFudHMgYW5kIGl0cyBvcmllbnRhdGlvbi4gIFRo ZSBQU0FQIGNhbiByZXF1ZXN0IGFuIA0KPj4+Pj4+IHVwZGF0ZSBtaWQgY2FsbCAoZS5nLiwgaWYg dGhlIGNhbGwgdGFrZXIgdGhpbmtzIHRoaW5ncyBtaWdodCBoYXZlIA0KPj4+Pj4+IGNoYW5nZWQp Lg0KPj4+Pj4+IA0KPj4+Pj4+IElORk8gaXMgdGhlIGNob3NlbiBtZWNoYW5pc20gdG8gc2VuZCB0 aGUgcmVxdWVzdCBmb3IgdXBkYXRlLiAgVGhlIA0KPj4+Pj4+IGRldmljZSB3aWxsIHNlbmQgYSBy ZXNwb25zZSB0byB0aGUgcmVxdWVzdCAoYW4gQUNLKSwgd2hpY2ggaXMgDQo+Pj4+Pj4gYWxzbyBz ZW50IGluIElORk8uDQo+Pj4+Pj4gVGhpcyBjb25zdGl0dXRlcyBhIHdlbGwgZGVmaW5lZCBJTkZP IHBhY2thZ2UsIGFuZCB3aWxsIGJlIA0KPj4+Pj4+IHJlZ2lzdGVyZWQgaW4gdGhlIHVzdWFsIHdh eS4NCj4+Pj4+PiANCj4+Pj4+PiBUaGUgSXNzdWUgYXQgaGFuZDoNCj4+Pj4+PiBTbywgdGhlIGRp c3B1dGUgaXMgaG93IHRoZSB1cGRhdGVkIGRhdGEgaXMgc2VudCBtaWQgY2FsbC4NCj4+Pj4+PiAN Cj4+Pj4+PiBSRkM2MDg2IHNheXMNCj4+Pj4+PiANCj4+Pj4+PiBOT1RFOiBBbiBJTkZPIHJlcXVl c3QgY2FuIGFsc28gY29udGFpbiBvdGhlciBib2R5IHBhcnRzIHRoYXQgYXJlIA0KPj4+Pj4+IG1l YW5pbmdmdWwgd2l0aGluIHRoZSBjb250ZXh0IG9mIGFuIGludml0ZSBkaWFsb2cgdXNhZ2UgYnV0 IGFyZSANCj4+Pj4+PiBub3Qgc3BlY2lmaWNhbGx5IGFzc29jaWF0ZWQgd2l0aCB0aGUgSU5GTyBt ZXRob2QgYW5kIHRoZSANCj4+Pj4+PiBhcHBsaWNhdGlvbiBjb25jZXJuZWQuDQo+Pj4+Pj4gDQo+ Pj4+Pj4gVGhlIGF1dGhvcnMgb2YgdGhlIGRyYWZ0IChvZiB3aGljaCBJIGFtIG9uZSkgZGVzaXJl IHRvIHVzZSB0aGUgDQo+Pj4+Pj4gQWRkaXRpb25hbCBEYXRhIG1lY2hhbmlzbSB0byBjYXJyeSB0 aGUgdXBkYXRlZCBkYXRhLiAgVGhlIGRhdGEgDQo+Pj4+Pj4gY291bGQgYmUgc2VudCBpbiBhbnkg Y29udmVuaWVudCBtZXNzYWdlLCBhbHRob3VnaCBzaW5jZSB0aGUgDQo+Pj4+Pj4gdmVoaWNsZSBp cyBzZW5kaW5nIGFuIEFDSywgaXQncyBsaWtlbHkgZ29pbmcgdG8gZ28gb24gdGhhdC4gIFdlJ2Qg DQo+Pj4+Pj4gbGlrZSB0byBhbHdheXMgY2FycnkgdGhlIGRhdGEgaW4gdGhlIHNhbWUgd2F5LiAg SW4gYW4gSU5GTyANCj4+Pj4+PiBtZXNzYWdlIGl0IHdvdWxkIGJlIGNhcnJpZWQgdGhlIHNhbWUg YXMgaXQgaXMgaW4gdGhlIElOVklURSwgYXMgDQo+Pj4+Pj4gQWRkaXRpb25hbCBEYXRhLiAgU2lu Y2UgdGhlIElORk8gY2FycmllcyBhbiBBQ0ssIGl0IHdvdWxkIHNwZWNpZnkgDQo+Pj4+Pj4gdGhl IGFwcHJvcHJpYXRlIElORk8gcGFja2FnZSwgYW5kIHdvdWxkIGNvbnRhaW4gYSBib2R5IHBhcnQg d2l0aCANCj4+Pj4+PiB0aGUgQUNLLiAgVGhlcmUgd291bGQgYmUgYW5vdGhlciBib2R5IHBhcnQg Zm9yIHRoZSB1cGRhdGVkIGRhdGEsIA0KPj4+Pj4+IHBvaW50ZWQgdG8gYnkgdGhlIENhbGwtSW5m by4NCj4+Pj4+PiANCj4+Pj4+PiBTb21lIGVjcml0IHBhcnRpY2lwYW50cyBzYXkgdGhhdCB0aGUg YWJvdmUgbGFuZ3VhZ2Ugb2YgNjA4NiB3b3VsZCANCj4+Pj4+PiBwcm9oaWJpdCB0aGUgSU5GTyBm cm9tIGNvbnRhaW5pbmcgYSBDYWxsLUluZm8gaGVhZGVyIHdpdGggYSBDSUQgDQo+Pj4+Pj4gcG9p bnRpbmcgdG8gYSBNSU1FIGJvZHkgcGFydCwgYmVjYXVzZSB0aGUgZGF0YSB3YXMgcmVxdWVzdGVk IGJ5IA0KPj4+Pj4+IGFuIElORk8sIGFuZCBoZW5jZSBpcyByZWxhdGVkIHRvIHRoZSBJTkZPIHBh Y2thZ2UuICBUaGV5IHNheSB0aGF0IA0KPj4+Pj4+IHRoZSBkYXRhIE1VU1QgYmUgY2FycmllZCB3 aXRoIGEgYm9keSBwYXJ0IGFuZCBDb250ZW50IERpc3Bvc2l0aW9uIA0KPj4+Pj4+IHRoYXQgaXMg cGFydCBvZiB0aGUgSU5GTyBwYWNrYWdlIGRlZmluaXRpb24uDQo+Pj4+Pj4gDQo+Pj4+Pj4gVGhl IGRyYWZ0IGF1dGhvcnMgY2xhaW0gdGhpcyA2MDg2IGxhbmd1YWdlIGlzbid0IGEgDQo+Pj4+Pj4g c3RyYWlnaHRqYWNrZXQsIGFuZCBpdCdzIHBlcmZlY3RseSBmaW5lIHRvIGNhcnJ5IHRoZSBkYXRh IA0KPj4+Pj4+IHJlZmVyZW5jZWQgYnkgYSBDYWxsLUluZm8gd2l0aCBhIENvbnRlbnQgSW5kaXJl Y3QgYm9keSBwYXJ0IHVzaW5nIHRoZSBzYW1lIE1JTUUgdHlwZSBhbmQgQ29udGVudA0KPj4+Pj4+ IERpc3Bvc2l0aW9uIGFzIGl0IHdvdWxkIGluIGFuIElOVklURS4gICBXaGVuIHRoZSB1cGRhdGVk IGRhdGEgaXMgc2VudA0KPj4+Pj4+IGluDQo+Pj4+Pj4gSU5GTywgaXQncyBiZWNhdXNlIHRoZSBJ TkZPIGlzIGEgY29udmVuaWVudCBtZXNzYWdlIChzaW5jZSBpdCdzIA0KPj4+Pj4+IGJlaW5nIHNl bnQgdG8gY2FycnkgdGhlIEFDSykuDQo+Pj4+Pj4gDQo+Pj4+Pj4gTWVjaGFuaWNhbGx5LCBib3Ro IG1lY2hhbmlzbXMgY2FuIGJlIG1hZGUgdG8gd29yay4gIFRoZSBib2R5IA0KPj4+Pj4+IHBhcnRz IHdvdWxkIGJlIGxhYmVsZWQgYXBwcm9wcmlhdGVseSBhbmQgdGhlcmUgd291bGQgYmUgbm8gDQo+ Pj4+Pj4gY29uZnVzaW9uIGFib3V0IHdoYXQgdGhleSBtZWFuIG9yIGhvdyB0aGV5IHdvdWxkIGJl IGludGVycHJldGVkLiAgDQo+Pj4+Pj4gSXQncyByZWFsbHkgb25seSB3aGV0aGVyIHRoZSBDYWxs LUluZm8gaGVhZGVyIGlzIHByZXNlbnQgYW5kIHdoYXQgDQo+Pj4+Pj4gdGhlIE1JTUUgdHlwZSBh bmQgQ29udGVudCBEaXNwb3NpdGlvbiB0aGUgYm9keSBwYXJ0IGNvbnRhaW5pbmcgDQo+Pj4+Pj4g dGhlIGRhdGEgd291bGQgYmUuICBJbiB0aGUgYXV0aG9yJ3MgcHJlZmVycmVkIHdheSwgaXQgd291 bGQgYmUgDQo+Pj4+Pj4gdGhlIE1JTUUgdHlwZSBhbmQgQ29udGVudCBEaXNwb3NpdGlvbiBvZiB0 aGUgQ2FsbC1JbmZvIGFuZCBpbiB0aGUgDQo+Pj4+Pj4gb3RoZXIgcG9pbnQgb2YgdmlldyBpdCB3 b3VsZCBiZSB0aGUgTUlNRSB0eXBlIGFuZCBDb250ZW50IA0KPj4+Pj4+IERpc3Bvc2l0aW9uIG9m IHRoZSBJTkZPIHBhY2thZ2UuDQo+Pj4+Pj4gDQo+Pj4+Pj4gUGxlYXNlIGlnbm9yZSB5b3VyIHBl cnNvbmFsIHByZWZlcmVuY2UgZm9yIHdoZXRoZXIgeW91IHRoaW5rIGl0IA0KPj4+Pj4+IG91Z2h0 IHRvIGdvIGluIHRoZSBJTkZPIG9yIG5vdCwgYW5kIHBsZWFzZSBoZWxwIHVzIGludGVycHJldCA2 MDg2Og0KPj4+Pj4+IGRvZXMgdGhlIGRhdGEgSEFWRSB0byBnbyBpbiBhbiBJTkZPIGJvZHkgcGFy dCBvciBjYW4gaXQgYmUgc2VudCANCj4+Pj4+PiBpbiBhIENhbGwtSW5mbyBib2R5IHBhcnQ/DQo+ Pj4+Pj4gDQo+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+Pj4+PiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPj4+Pj4+IHNpcGNvcmVAaWV0Zi5v cmcNCj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUN Cj4+Pj4+IA0KPj4+PiANCj4+PiANCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+IHNpcGNvcmUgbWFpbGluZyBsaXN0DQo+PiBzaXBjb3Jl QGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNv cmUNCj4+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4gc2lwY29yZUBpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2lwY29yZSBtYWlsaW5nIGxp c3QNCj4gc2lwY29yZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NpcGNvcmUNCg0K From nobody Thu Aug 25 11:21:31 2016 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 28435128B44 for ; Thu, 25 Aug 2016 11:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CWQj6vIL3p7 for ; Thu, 25 Aug 2016 11:21:27 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B059512D162 for ; Thu, 25 Aug 2016 11:21:26 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id C9096ECEDEB46; Thu, 25 Aug 2016 18:10:58 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u7PIB22G032172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 25 Aug 2016 18:11:02 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u7PI9qQV004592 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Aug 2016 20:11:02 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.50]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Thu, 25 Aug 2016 20:10:34 +0200 From: "Drage, Keith (Nokia - GB)" To: Randall Gellens , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? Thread-Index: AQHR/vv4t8U9zxQ/t0S7ZAjE4j7poA== Date: Thu, 25 Aug 2016 18:10:33 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF5AE65@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <76CCBFA5-8D53-4B1E-A495-4A18AB081384@brianrosen.net> <05240A95-8319-4555-8B46-FA18B6C27883@brianrosen.net> <5d462933-e3c0-b3a3-958d-5c9d1e86d854@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8BADF5AAE0@FR712WXCHMBA11.zeu.alcatel-l ucent.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 18:21:29 -0000 > The authors want to have the vehicle telematics data always sent the same= way, so there is only one way of doing so, not two. The you cannot use additional-data because that does not allow messages to = be sent purely on the need of the data, and you cannot use the Info-Package= if you want to send stuff in the INVITE request.=20 Therefore your requirement cannot be met. > The authors of the draft want to have one mechanism for transporting the = vehicle data. There is another, separate mechanism, that requests the vehi= cle to take an action. In eCall, this action is limited to sending updated= data. In the car-crash draft, the action is extended to other things (e.g= ., flash the lights). This mechanism uses a request/response protocol, whi= ch is carried in INFO and uses a well-defined INFO package. Car-crash is nothing to do with ecall. Ecall works to a set of requirements= defined by 3GPP and takes place in a 3GPP emergency call over IMS. Car-cra= sh is apparently defined as something over the top that does not use IMS wi= thin a 3GPP, and IS NOT a 3GPP emergency call. Keith -----Original Message----- From: Randall Gellens [mailto:rg+ietf@randy.pensive.org]=20 Sent: 25 August 2016 18:08 To: Drage, Keith (Nokia - GB); Paul Kyzivat; sipcore@ietf.org Subject: Re: [sipcore] Can an INFO contain a body related to, but not part = of the INFO package? We're getting into the ECRIT discussion, which as Paul noted is not the int= ent of bringing this to sipcore. But I did want to respond to two points: At 3:17 PM +0000 8/25/16, Keith (Nokia - GB) Drage wrote: > Transferring data in Info packages is well known. It does not require=20 > the use of a Call-Info header field to describe the usage. > The usage is defined by the Info-package header field. Using the=20 > Call-Info header field would provide two means of describing the=20 > purpose of the same message body and lead to all sorts of error=20 > handling issues when they become in conflict (because someone failed=20 > to read the specification or some other reason). This my view is=20 > clearly that we should follow the rules of clean design and not do=20 > this, particularly as in my view it is totally unneccessary. > Ecall consists of two parts - data transferred in the initial INVITE=20 > message. No one has objected to additional data to perform this=20 > function. Further in some circumstances, the PSAP can request more=20 > data to be sent outside that initial request and outside further call=20 > control messages. It is here where the Info package discussion comes=20 > in. My view strongly expressed is that these can be treated from the=20 > SIP viewpoint as two entirely separate transport mechanisms,=20 > completely operating independently at the SIP later. At some point=20 > they both transfer an MSD, but that is separately identified by other=20 > header fields. It is then up to the application in both the PSAP and=20 > the calling user agent to control how these two independent data=20 > transfer mechanisms are used. As such there is no need to start=20 > defining interactions between Info packages and additional data, and=20 > no need for one to update the other. The authors of the draft want to have one mechanism for transporting the ve= hicle data. There is another, separate mechanism, that requests the vehicl= e to take an action. In eCall, this action is limited to sending updated d= ata. In the car-crash draft, the action is extended to other things (e.g.,= flash the lights). This mechanism uses a request/response protocol, which= is carried in INFO and uses a well-defined INFO package. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- We must abandon the p= revalent belief in the superior wisdom of the ignorant. --Daniel J. Boorstin From nobody Thu Aug 25 12:05:25 2016 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 5A1A912D592 for ; Thu, 25 Aug 2016 12:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQnwIrf-eQuw for ; Thu, 25 Aug 2016 12:05:20 -0700 (PDT) Received: from email.salsgiver.com (email.salsgiver.com [206.67.234.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C6C812D5B8 for ; Thu, 25 Aug 2016 12:05:20 -0700 (PDT) Received: from [10.33.192.33] ([156.154.81.54]) (authenticated bits=0) by email.salsgiver.com (8.15.2/8.14.3) with ESMTPA id u7PJ5Ef7018842; Thu, 25 Aug 2016 15:05:16 -0400 (EDT) (envelope-from br@salsgiver.com) X-Authentication-Warning: email.salsgiver.com: Host [156.154.81.54] claimed to be [10.33.192.33] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF5AE60@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Thu, 25 Aug 2016 15:05:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <037EFB4D-2C03-4A53-B182-7416A52D8554@salsgiver.com> References: <76CCBFA5-8D53-4B1E-A495-4A18AB081384@brianrosen.net> <05240A95-8319-4555-8B46-FA18B6C27883@brianrosen.net> <5d462933-e3c0-b3a3-958d-5c9d1e86d854@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8BADF5AAE0@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADF5AE60@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: "Drage, Keith (Nokia - GB)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 19:05:22 -0000 Actually, that=E2=80=99s a very good question. Suppose I used a variation on the same INFO package that triggered a new = location-by-value update. Does the location have to come in an INFO package block, or can it come = in a Geolocation header CID bock? Brian > On Aug 25, 2016, at 2:10 PM, Drage, Keith (Nokia - GB) = wrote: >=20 > I think it is not a prohibition - it has a semantic after all, but = rather a deviation from best practice of keeping things simple. Adding = it in respect of the Info-Package has to have zero impact.=20 >=20 > If using INFO, then the Info-Package defines what is carried, using = the Info-Package header field. Adding Call-Info is not belt and braces, = rather it is nothing to do with the correct operation of the = Info-Package and therefore a complexity that will definitely lead to = error prone implementations. >=20 > Are you going to now start proposing adding the Call-Info header field = to all usages of the Geolocation header field that point to a message = body, because that is the logical progression of using it in respect of = the Info package data contents. >=20 > Keith >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@salsgiver.com]=20 > Sent: 25 August 2016 18:03 > To: Drage, Keith (Nokia - GB) > Cc: Paul Kyzivat; sipcore@ietf.org > Subject: Re: [sipcore] Can an INFO contain a body related to, but not = part of the INFO package? >=20 > I asked that you not base your response (here in sippcore) on how you = PREFER to transport the data. We have a language interpretation that = Christer asked to take to sipcore: does the language in 6086 PROHIBIT = the data from being carried in Call-Info? >=20 > sipcore should not opine on what ecrit SHOULD do, but only what it = COULD do with respect to 6086. >=20 > Is it your opinion that 6086 prohibits us from carrying the data in = Call-Info? >=20 > Brian >=20 >> On Aug 25, 2016, at 11:17 AM, Drage, Keith (Nokia - GB) = wrote: >>=20 >> Time to express my opinion. >>=20 >> In some circumances, ecall needs to transfer data outside of a normal = call control message. >>=20 >> The viewpoint is that an INFO message might do that. To use INFO = methods, one MUST define an Info package. There is not other requirement = in ecall for an Info package to exist, so the Info package MUST be one = specific to transferring the ecall data, not an Info package for = something else that just happens to be supporting ecall data transfer = because it is already there. >>=20 >> Transferring data in Info packages is well known. It does not require = the use of a Call-Info header field to describe the usage. The usage is = defined by the Info-package header field. Using the Call-Info header = field would provide two means of describing the purpose of the same = message body and lead to all sorts of error handling issues when they = become in conflict (because someone failed to read the specification or = some other reason). This my view is clearly that we should follow the = rules of clean design and not do this, particularly as in my view it is = totally unneccessary. >>=20 >> The remainder goes more into ecall requirements, and therefore falls = more to the scope of ecrit and 3GPP, but indicates why I think it is = unnecessary. >>=20 >> Ecall consists of two parts - data transferred in the initial INVITE = message. No one has objected to additional data to perform this = function. Further in some circumstances, the PSAP can request more data = to be sent outside that initial request and outside further call control = messages. It is here where the Info package discussion comes in. My view = strongly expressed is that these can be treated from the SIP viewpoint = as two entirely separate transport mechanisms, completely operating = independently at the SIP later. At some point they both transfer an MSD, = but that is separately identified by other header fields. It is then up = to the application in both the PSAP and the calling user agent to = control how these two independent data transfer mechanisms are used. As = such there is no need to start defining interactions between Info = packages and additional data, and no need for one to update the other. >>=20 >> Regards >>=20 >> Keith >>=20 >>=20 >>=20 >> -----Original Message----- >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul=20 >> Kyzivat >> Sent: 25 August 2016 15:32 >> To: sipcore@ietf.org >> Subject: Re: [sipcore] Can an INFO contain a body related to, but not = part of the INFO package? >>=20 >> On 8/25/16 9:26 AM, Brian Rosen wrote: >>> Yes, I=E2=80=99m saying that the ACK satisfies the 6086 use of INFO, = and that it=E2=80=99s okay to send the data with Call-Info. >>>=20 >>> Yes, I=E2=80=99m agreeing that there is a relationship between the = INFO package and the data. >>>=20 >>> Yes, I=E2=80=99m disagreeing with your interpretation of the = language. >>>=20 >>> So, now, what say you sipcore? >>=20 >> I think the main point of bringing this to sipcore is to get some = fresh input into this discussion. Since I have been party to the = discussion over in ecrit I don't bring anything fresh here. But for = completeness I will register my opinion here too. >>=20 >> IMO this is not a question about whether the proposed usage is valid=20= >> according to 6086 and other rfcs. (I think it is quite clear that it >> *is* valid.) Rather this is simply a question of what is the best = design for the desired functionality. As such I don't think it really = needs to be settled in sipcore. >>=20 >> But I am happy to check if anybody has a different perspective on = this. >>=20 >> Thanks, >> Paul >>=20 >>> Brian >>>=20 >>>=20 >>>> On Aug 25, 2016, at 9:14 AM, Christer Holmberg = wrote: >>>>=20 >>>> Hi, >>>>=20 >>>>> We=E2=80=99re agreeing that there is a relationship between the = command and=20 >>>>> the data. >>>>>=20 >>>>> We=E2=80=99re suggesting that we don=E2=80=99t have to be anal = about the language=20 >>>>> and as long as there is an INFO package, and a body part that has=20= >>>>> the ACK which is an INFO body part, that the cited language = doesn=E2=80=99t=20 >>>>> compel us to use the INFO body part to transport the data, the=20 >>>>> Call-Info mechanism is acceptable. >>>>>=20 >>>>> No one is suggesting that we update 6086, and we agree that 7852=20= >>>>> did not update 6086. >>>>>=20 >>>>> It=E2=80=99s just whether that language prohibits use of the = Call-Info to=20 >>>>> carry the data when it was prompted by the INFO package request,=20= >>>>> and accompanies the INFO package ACK. >>>>=20 >>>> You seem to suggest that, just because you use an Info Package for=20= >>>> sending SOME of the ecall related information (the request and = ACK),=20 >>>> that allows you to send the rest of the ecall related information=20= >>>> (the data content) without using an Info Package. I really don=E2=80=99= t see=20 >>>> how you can parse the cited text in that way. The cited text says=20= >>>> that information associated with the application shall be sent = using=20 >>>> an Info Package. And, both the ACK and the requested data content=20= >>>> are associated with the ecall application. >>>>=20 >>>> Regards, >>>>=20 >>>> Christer >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> Brian >>>>>=20 >>>>>> On Aug 25, 2016, at 2:00 AM, Christer Holmberg=20 >>>>>> wrote: >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> I=C2=B9m glad this is brought to SIPCORE. As one of the info = package=20 >>>>>> proponents, please let me clarify my arguments. >>>>>>=20 >>>>>> The 6086 text that Brian copied says =C2=B3but are not = specifically=20 >>>>>> associated with the INFO method and the application concerned=C2=B2= . >>>>>>=20 >>>>>> I claim that the updated data IS associated with the application=20= >>>>>> concerned (ecall). The updated data is requested by the ecall=20 >>>>>> application, and the delivered updated data is consumed by the=20 >>>>>> ecall application. The updated data is NOT some=20 >>>>>> non-ecall-application-related information that is piggybacked in = a=20 >>>>>> "convenient INFO message" that happens to be sent by the ecall=20 >>>>>> application for some other purpose. >>>>>>=20 >>>>>> (In addition, the updated data is NOT associated with a legacy >>>>>> (pre-6086) >>>>>> INFO usage, which could justify not using an Info Package. I do=20= >>>>>> want to point out that nobody has claimed that the updated data=20= >>>>>> would be associated with legacy INFO, but just for completeness) >>>>>>=20 >>>>>> RFC 7852 does define a mechanism for transporting data, using=20 >>>>>> Call-Info etc. But, 7852 does not update 6086, nor can 7852=20 >>>>>> override rules and procedures associated with individual SIP=20 >>>>>> methods (INFO in this case). I also pointed this out before 7852=20= >>>>>> was published, but was told that it=C2=B9s too late to change it=20= >>>>>> (granted, the draft was in the RFC editor=C2=B9s queue). >>>>>>=20 >>>>>> Finally, again for completeness, I want to point out that 6086=20 >>>>>> does not prevent including Call-Info in INFO as such. The issue = is=20 >>>>>> how some want to use Call-Info instead of an Info Package. >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Christer >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 25/08/16 03:22, "sipcore on behalf of Brian Rosen" >>>>>> wrote: >>>>>>=20 >>>>>>> Over in ecrit we have a disagreement that relates to = interpreting=20 >>>>>>> RFC6086. >>>>>>>=20 >>>>>>> Background: >>>>>>> RFC7852 defines something called "Additional Data", which is=20 >>>>>>> carried in emergency call signaling. It's data related to the=20= >>>>>>> call, e.g., the identity and contact data of the service = provider handling the call. >>>>>>> Additional Data is signaled with a Call-Info header field, which=20= >>>>>>> contains either a URI pointing to a data block fetched with=20 >>>>>>> HTTPS, or a Content Indirect referencing a body part of the SIP = message. >>>>>>> It's usually used on the INVITE of the emergency call, so it can=20= >>>>>>> be displayed to the PSAP (emergency call center) call-taker when=20= >>>>>>> the call is assigned. >>>>>>>=20 >>>>>>> Sometimes, this data can change during a call. The example in=20= >>>>>>> discussion >>>>>>> is telematics data in a vehicle. The vehicle can report things = like >>>>>>> the >>>>>>> number of occupants and its orientation. The PSAP can request = an=20 >>>>>>> update mid call (e.g., if the call taker thinks things might = have=20 >>>>>>> changed). >>>>>>>=20 >>>>>>> INFO is the chosen mechanism to send the request for update. = The=20 >>>>>>> device will send a response to the request (an ACK), which is=20 >>>>>>> also sent in INFO. >>>>>>> This constitutes a well defined INFO package, and will be=20 >>>>>>> registered in the usual way. >>>>>>>=20 >>>>>>> The Issue at hand: >>>>>>> So, the dispute is how the updated data is sent mid call. >>>>>>>=20 >>>>>>> RFC6086 says >>>>>>>=20 >>>>>>> NOTE: An INFO request can also contain other body parts that are=20= >>>>>>> meaningful within the context of an invite dialog usage but are=20= >>>>>>> not specifically associated with the INFO method and the=20 >>>>>>> application concerned. >>>>>>>=20 >>>>>>> The authors of the draft (of which I am one) desire to use the=20= >>>>>>> Additional Data mechanism to carry the updated data. The data=20= >>>>>>> could be sent in any convenient message, although since the=20 >>>>>>> vehicle is sending an ACK, it's likely going to go on that. = We'd=20 >>>>>>> like to always carry the data in the same way. In an INFO=20 >>>>>>> message it would be carried the same as it is in the INVITE, as=20= >>>>>>> Additional Data. Since the INFO carries an ACK, it would = specify=20 >>>>>>> the appropriate INFO package, and would contain a body part with=20= >>>>>>> the ACK. There would be another body part for the updated data,=20= >>>>>>> pointed to by the Call-Info. >>>>>>>=20 >>>>>>> Some ecrit participants say that the above language of 6086 = would=20 >>>>>>> prohibit the INFO from containing a Call-Info header with a CID=20= >>>>>>> pointing to a MIME body part, because the data was requested by=20= >>>>>>> an INFO, and hence is related to the INFO package. They say = that=20 >>>>>>> the data MUST be carried with a body part and Content = Disposition=20 >>>>>>> that is part of the INFO package definition. >>>>>>>=20 >>>>>>> The draft authors claim this 6086 language isn't a=20 >>>>>>> straightjacket, and it's perfectly fine to carry the data=20 >>>>>>> referenced by a Call-Info with a Content Indirect body part = using the same MIME type and Content >>>>>>> Disposition as it would in an INVITE. When the updated data is = sent >>>>>>> in >>>>>>> INFO, it's because the INFO is a convenient message (since it's=20= >>>>>>> being sent to carry the ACK). >>>>>>>=20 >>>>>>> Mechanically, both mechanisms can be made to work. The body=20 >>>>>>> parts would be labeled appropriately and there would be no=20 >>>>>>> confusion about what they mean or how they would be interpreted. = =20 >>>>>>> It's really only whether the Call-Info header is present and = what=20 >>>>>>> the MIME type and Content Disposition the body part containing=20= >>>>>>> the data would be. In the author's preferred way, it would be=20= >>>>>>> the MIME type and Content Disposition of the Call-Info and in = the=20 >>>>>>> other point of view it would be the MIME type and Content=20 >>>>>>> Disposition of the INFO package. >>>>>>>=20 >>>>>>> Please ignore your personal preference for whether you think it=20= >>>>>>> ought to go in the INFO or not, and please help us interpret = 6086: >>>>>>> does the data HAVE to go in an INFO body part or can it be sent=20= >>>>>>> in a Call-Info body part? >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> sipcore mailing list >>>>>>> sipcore@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>>=20 >>=20 >> _______________________________________________ >> 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 >=20 From nobody Thu Aug 25 13:37:27 2016 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 9F7AA126D74 for ; Thu, 25 Aug 2016 13:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YTKgXJMi9cN for ; Thu, 25 Aug 2016 13:37:23 -0700 (PDT) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78CF012D0FC for ; Thu, 25 Aug 2016 13:37:23 -0700 (PDT) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-12v.sys.comcast.net with SMTP id d1NRblV4nxBKTd1OsbO3Gv; Thu, 25 Aug 2016 20:37:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-19v.sys.comcast.net with SMTP id d1OrbPzGzg3APd1OsbjhrI; Thu, 25 Aug 2016 20:37:22 +0000 To: Christer Holmberg , "sipcore@ietf.org" References: <76CCBFA5-8D53-4B1E-A495-4A18AB081384@brianrosen.net> <05240A95-8319-4555-8B46-FA18B6C27883@brianrosen.net> <5d462933-e3c0-b3a3-958d-5c9d1e86d854@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC60A10@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC61D10@ESESSMB209.ericsson.se> <1c9b4538-720c-0126-7a82-d63edfc40caf@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC61E7C@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <81e44324-ae48-c2a4-c8e2-5f349da7d4d8@alum.mit.edu> Date: Thu, 25 Aug 2016 16:37:21 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC61E7C@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfHc0mtuHl3O63ovZBAGABevlV3C8cOtVusTrpu6MLGhB/rFIpT72SlkUNHSnSmMzBEouie3yXyxjr4QUbZX+E9QoFtgCJRVW07IcxxUT+xNLTtWXdXYG YPjT76Q7EUwknlZKYXQQguT3YNLQ96J3WtrGmZmtVonZAlB/NepF+G4q15H5/0hAP15fsJ+17leOce4v82NP7KV2qXpyr+yCt92nu0rhB8jv6d7HtdnKNSZX Archived-At: Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 20:37:25 -0000 On 8/25/16 11:56 AM, Christer Holmberg wrote: > Or, to put it in another way: Assuming I want to send content X using INFO. How do I determine whether I need to define an Info Package for that, or whether I can send it in INFO without defining an Info Package? Depends on what you mean by "send it in INFO". I take that to mean: send it in the INFO body/body part. When you are talking about "legacy" INFO (without info package) then the body usage is very ill-defined. You are expected to only be using it for legacy usage - stuff that is "grandfathered in". So I don't think that even applies to this question. But this is dancing around stuff that is defined by some means other than method. If you say "you want to send it using INFO" then I would expect the content to be contained within the info package body. OTOH, if you just want to send X in a lot of circumstances, then you might choose a different method (such as call-info) that isn't method-specific. If you do that, then it can go anywhere a call-info can go, which happens to include INFO. Thanks, Paul > Regards, > > Christer > > > >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: 25 August 2016 18:34 >> To: Christer Holmberg ; >> sipcore@ietf.org >> Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? >> >> On 8/25/16 10:58 AM, Christer Holmberg wrote: >>> Paul, a generic question, which might help me understand your view on ecall: in your opinion, when (if ever) is usage of an Info Package required? >> >> I guess I would phrase it this way: >> >> If you have a need to transmit some information via a sip session, then you should consider all the available mechanisms sip has, and decide if there is some combination of existing mechanisms that meets your need. >> >> The following are some of the available mechanisms: >> >> - new event packages >> - new info packages >> - new qualifying options with call-info, alert-info, error-info >> - newly defined header field parameters >> - new defined header fields >> >> Many of these mechanisms have their own rules for what sorts of new usage are appropriate. Others do not, and are probably deficient because of that. For those, the bar is generally the need to get a RFC approved. >> >> INFO is notable because the bar is pretty low (Specification Required). >> So some may choose it for its ease. >> >> When choosing among the options, you have to consider what the approval processes will be for each, and that the reviewers will probably ask if you have considered alternative approaches. >> >> For instance Geolocation was done with a new header field that sometimes references a separate body part. That raised a higher hurdle to get over than using an info package. But it was deemed worth it since it had needs that couldn't be met by info packages. >> >> In general there are likely to be multiple options available for almost anything you want to do. And then it will come down to weighing the pros/cons. >> >> Thanks, >> Paul >> >>> Regards, >>> >>> Christer >>> >>> -----Original Message----- >>> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul >>> Kyzivat >>> Sent: 25 August 2016 17:32 >>> To: sipcore@ietf.org >>> Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? >>> >>> On 8/25/16 9:26 AM, Brian Rosen wrote: >>>> Yes, I’m saying that the ACK satisfies the 6086 use of INFO, and that it’s okay to send the data with Call-Info. >>>> >>>> Yes, I’m agreeing that there is a relationship between the INFO package and the data. >>>> >>>> Yes, I’m disagreeing with your interpretation of the language. >>>> >>>> So, now, what say you sipcore? >>> >>> I think the main point of bringing this to sipcore is to get some fresh input into this discussion. Since I have been party to the discussion over in ecrit I don't bring anything fresh here. But for completeness I will register my opinion here too. >>> >>> IMO this is not a question about whether the proposed usage is valid >>> according to 6086 and other rfcs. (I think it is quite clear that it >>> *is* valid.) Rather this is simply a question of what is the best design for the desired functionality. As such I don't think it really needs to be settled in sipcore. >>> >>> But I am happy to check if anybody has a different perspective on this. >>> >>> Thanks, >>> Paul >>> >>>> Brian >>>> >>>> >>>>> On Aug 25, 2016, at 9:14 AM, Christer Holmberg wrote: >>>>> >>>>> Hi, >>>>> >>>>>> We’re agreeing that there is a relationship between the command >>>>>> and the data. >>>>>> >>>>>> We’re suggesting that we don’t have to be anal about the language >>>>>> and as long as there is an INFO package, and a body part that has >>>>>> the ACK which is an INFO body part, that the cited language >>>>>> doesn’t compel us to use the INFO body part to transport the data, >>>>>> the Call-Info mechanism is acceptable. >>>>>> >>>>>> No one is suggesting that we update 6086, and we agree that 7852 >>>>>> did not update 6086. >>>>>> >>>>>> It’s just whether that language prohibits use of the Call-Info to >>>>>> carry the data when it was prompted by the INFO package request, >>>>>> and accompanies the INFO package ACK. >>>>> >>>>> You seem to suggest that, just because you use an Info Package for >>>>> sending SOME of the ecall related information (the request and >>>>> ACK), that allows you to send the rest of the ecall related >>>>> information (the data content) without using an Info Package. I >>>>> really don’t see how you can parse the cited text in that way. The >>>>> cited text says that information associated with the application >>>>> shall be sent using an Info Package. And, both the ACK and the >>>>> requested data content are associated with the ecall application. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> Brian >>>>>> >>>>>>> On Aug 25, 2016, at 2:00 AM, Christer Holmberg >>>>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I¹m glad this is brought to SIPCORE. As one of the info package >>>>>>> proponents, please let me clarify my arguments. >>>>>>> >>>>>>> The 6086 text that Brian copied says ³but are not specifically >>>>>>> associated with the INFO method and the application concerned². >>>>>>> >>>>>>> I claim that the updated data IS associated with the application >>>>>>> concerned (ecall). The updated data is requested by the ecall >>>>>>> application, and the delivered updated data is consumed by the >>>>>>> ecall application. The updated data is NOT some >>>>>>> non-ecall-application-related information that is piggybacked in >>>>>>> a "convenient INFO message" that happens to be sent by the ecall >>>>>>> application for some other purpose. >>>>>>> >>>>>>> (In addition, the updated data is NOT associated with a legacy >>>>>>> (pre-6086) >>>>>>> INFO usage, which could justify not using an Info Package. I do >>>>>>> want to point out that nobody has claimed that the updated data >>>>>>> would be associated with legacy INFO, but just for completeness) >>>>>>> >>>>>>> RFC 7852 does define a mechanism for transporting data, using >>>>>>> Call-Info etc. But, 7852 does not update 6086, nor can 7852 >>>>>>> override rules and procedures associated with individual SIP >>>>>>> methods (INFO in this case). I also pointed this out before 7852 >>>>>>> was published, but was told that it¹s too late to change it >>>>>>> (granted, the draft was in the RFC editor¹s queue). >>>>>>> >>>>>>> Finally, again for completeness, I want to point out that 6086 >>>>>>> does not prevent including Call-Info in INFO as such. The issue >>>>>>> is how some want to use Call-Info instead of an Info Package. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Christer >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 25/08/16 03:22, "sipcore on behalf of Brian Rosen" >>>>>>> wrote: >>>>>>> >>>>>>>> Over in ecrit we have a disagreement that relates to >>>>>>>> interpreting RFC6086. >>>>>>>> >>>>>>>> Background: >>>>>>>> RFC7852 defines something called "Additional Data", which is >>>>>>>> carried in emergency call signaling. It's data related to the >>>>>>>> call, e.g., the identity and contact data of the service provider handling the call. >>>>>>>> Additional Data is signaled with a Call-Info header field, which >>>>>>>> contains either a URI pointing to a data block fetched with >>>>>>>> HTTPS, or a Content Indirect referencing a body part of the SIP message. >>>>>>>> It's usually used on the INVITE of the emergency call, so it can >>>>>>>> be displayed to the PSAP (emergency call center) call-taker when >>>>>>>> the call is assigned. >>>>>>>> >>>>>>>> Sometimes, this data can change during a call. The example in >>>>>>>> discussion >>>>>>>> is telematics data in a vehicle. The vehicle can report things like >>>>>>>> the >>>>>>>> number of occupants and its orientation. The PSAP can request >>>>>>>> an update mid call (e.g., if the call taker thinks things might >>>>>>>> have changed). >>>>>>>> >>>>>>>> INFO is the chosen mechanism to send the request for update. >>>>>>>> The device will send a response to the request (an ACK), which >>>>>>>> is also sent in INFO. >>>>>>>> This constitutes a well defined INFO package, and will be >>>>>>>> registered in the usual way. >>>>>>>> >>>>>>>> The Issue at hand: >>>>>>>> So, the dispute is how the updated data is sent mid call. >>>>>>>> >>>>>>>> RFC6086 says >>>>>>>> >>>>>>>> NOTE: An INFO request can also contain other body parts that are >>>>>>>> meaningful within the context of an invite dialog usage but are >>>>>>>> not specifically associated with the INFO method and the >>>>>>>> application concerned. >>>>>>>> >>>>>>>> The authors of the draft (of which I am one) desire to use the >>>>>>>> Additional Data mechanism to carry the updated data. The data >>>>>>>> could be sent in any convenient message, although since the >>>>>>>> vehicle is sending an ACK, it's likely going to go on that. >>>>>>>> We'd like to always carry the data in the same way. In an INFO >>>>>>>> message it would be carried the same as it is in the INVITE, as >>>>>>>> Additional Data. Since the INFO carries an ACK, it would >>>>>>>> specify the appropriate INFO package, and would contain a body >>>>>>>> part with the ACK. There would be another body part for the >>>>>>>> updated data, pointed to by the Call-Info. >>>>>>>> >>>>>>>> Some ecrit participants say that the above language of 6086 >>>>>>>> would prohibit the INFO from containing a Call-Info header with >>>>>>>> a CID pointing to a MIME body part, because the data was >>>>>>>> requested by an INFO, and hence is related to the INFO package. >>>>>>>> They say that the data MUST be carried with a body part and >>>>>>>> Content Disposition that is part of the INFO package definition. >>>>>>>> >>>>>>>> The draft authors claim this 6086 language isn't a >>>>>>>> straightjacket, and it's perfectly fine to carry the data >>>>>>>> referenced by a Call-Info with a Content Indirect body part using the same MIME type and Content >>>>>>>> Disposition as it would in an INVITE. When the updated data is sent >>>>>>>> in >>>>>>>> INFO, it's because the INFO is a convenient message (since it's >>>>>>>> being sent to carry the ACK). >>>>>>>> >>>>>>>> Mechanically, both mechanisms can be made to work. The body >>>>>>>> parts would be labeled appropriately and there would be no >>>>>>>> confusion about what they mean or how they would be interpreted. >>>>>>>> It's really only whether the Call-Info header is present and >>>>>>>> what the MIME type and Content Disposition the body part >>>>>>>> containing the data would be. In the author's preferred way, it >>>>>>>> would be the MIME type and Content Disposition of the Call-Info >>>>>>>> and in the other point of view it would be the MIME type and >>>>>>>> Content Disposition of the INFO package. >>>>>>>> >>>>>>>> Please ignore your personal preference for whether you think it >>>>>>>> ought to go in the INFO or not, and please help us interpret 6086: >>>>>>>> does the data HAVE to go in an INFO body part or can it be sent >>>>>>>> in a Call-Info body part? >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>> >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >> > From nobody Thu Aug 25 14:01:27 2016 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 5CB1B126D74 for ; Thu, 25 Aug 2016 14:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XepwCMCGkrDZ for ; Thu, 25 Aug 2016 14:01:25 -0700 (PDT) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 400BF128874 for ; Thu, 25 Aug 2016 14:01:22 -0700 (PDT) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-04v.sys.comcast.net with SMTP id d1lXbEWfH8Pead1m5bJyqM; Thu, 25 Aug 2016 21:01:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-16v.sys.comcast.net with SMTP id d1m4bTOKyqv8jd1m5bam0a; Thu, 25 Aug 2016 21:01:21 +0000 To: "Drage, Keith (Nokia - GB)" , Randall Gellens , "sipcore@ietf.org" References: <76CCBFA5-8D53-4B1E-A495-4A18AB081384@brianrosen.net> <05240A95-8319-4555-8B46-FA18B6C27883@brianrosen.net> <5d462933-e3c0-b3a3-958d-5c9d1e86d854@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8BADF5AAE0@FR712WXCHMBA11.zeu.alcatel-l ucent.com> <949EF20990823C4C85C18D59AA11AD8BADF5AE65@FR712WXCHMBA11.zeu.alcatel-lucent.com> From: Paul Kyzivat Message-ID: Date: Thu, 25 Aug 2016 17:01:20 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF5AE65@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfAtoWi1tHygHpcSxr5lZgDZ2wDBngWtk2PB7w8j3nUYZRyiATZkYl7BXITIGA3yUGrDOw8Dzk1i/YJW7JmB9WULakv9uWPS0iDUKORxuy6PSx4bb9wG7 YHYfLfqJc6KtB3TS0ejFpK7kExZIxZWUbkltf2S6BYYi4Uxojqvvek+F97PniA2q0AFq4d6V8SvExEXzchEM5GosGBWKbfoYsd+V30FYrUYuzTpef+isKwZg rYtPOUv29xlP7Ekog884xvKVwb/GwZKyltlkshWiGes= Archived-At: Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 21:01:26 -0000 This is mostly getting outside the scope of sipcore. But maybe this one part is in scope... On 8/25/16 2:10 PM, Drage, Keith (Nokia - GB) wrote: > The you cannot use additional-data because that does not allow messages to be sent purely on the need of the data, I disagree. Consider for a moment session timer. In principle all it needs to do is signal *something* from end to end through all the session signaling intermediaries. It doesn't really need the function of any particular message. But to do so it triggers the sending of INVITE or UPDATE. Note in particular that the UPDATE can be effectively a no-op aside from its session-timer updating. (It need not carry an offer, though it MAY.) And the resulting message does its job without any of the recipients knowing if it was sent solely because it was needed for session timer, or if it was going anyway but serves also to refresh the session timer. The same can be true for additional-data (or any usage of call-info). The additional-data transport can be piggybacked on a message that is already being sent for some other purpose, or some benign message can be sent specifically to serve as the vehicle for the additional-data. It could be INVITE or UPDATE. Or it could be INFO if you have some info package that you want to send at that time, or it could be the response to an INFO package if you happen to need to respond to one at the same time that you need to send the additional-data. In the case where you have just received an INFO containing an indication that fresh additional-data would be appreciated, it may be really convenient to piggyback the additional-data on the response to that INFO. I see no problem with that. Note that some other implementation might not find it convenient to piggyback that way. (Maybe it takes awhile to generate the fresh data and it doesn't want to delay the response.) Then that implementation may need to find some other message to carry the additional-data. I do not see how that violates the letter or spirit of SIP. What *would* violate the spirit of sip would be something similar that sends high volume and frequent data over the signaling channel. Thanks, Paul From nobody Thu Aug 25 14:49:50 2016 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 CD84D12D0AF for ; Thu, 25 Aug 2016 14:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.534 X-Spam-Level: X-Spam-Status: No, score=-0.534 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crUP3H_-AOpm for ; Thu, 25 Aug 2016 14:49:47 -0700 (PDT) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C25A612B02C for ; Thu, 25 Aug 2016 14:49:47 -0700 (PDT) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-06v.sys.comcast.net with SMTP id d2WmbcbzV2Nhqd2WxbD6Pg; Thu, 25 Aug 2016 21:49:47 +0000 Received: from hobgoblin.ariadne.com ([73.100.16.189]) by resomta-ch2-16v.sys.comcast.net with SMTP id d2WwbTaGjqv8jd2WwbasIY; Thu, 25 Aug 2016 21:49:47 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u7PLnjc9007899; Thu, 25 Aug 2016 17:49:45 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u7PLniMf007892; Thu, 25 Aug 2016 17:49:44 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Brian Rosen In-Reply-To: Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 25 Aug 2016 17:49:44 -0400 Message-ID: <87bn0g7c3r.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfLHMpykHM8PwguUTwIqrgpi8EonAWDgqekdvz4KlTvtZxF2sbzlqLwdKFJcaRJLRk9iwWNlIvwRCCUQuPlg/yp8VLl2/aUqehg2yhDUPwnB6XpXWIUn5 sM+XdullV1vyW2mz0LLhWZkBmShbYK/bsGzA5j21JL2PNrhwEz/qYRSSKY8T2N55w9BLcu4CoF7qyzmnq/H9wkEcsiLMnL2vaEM= Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 21:49:49 -0000 Brian Rosen writes: >> On Aug 25, 2016, at 9:47 AM, Dale R. Worley wrote: >> Interesting. I would have expected the update (and effectively the ACK) >> to be in the response to the INFO request. Presumably there's a reason >> that doesn't work. > > I believe there can be a time delay between asking for it and getting > the data. For the moment, that's not germane, although the data could > come in the response to the INFO. In addition to the fact that the caller may delay sending the data so long that the INFO transaction should not be delayed for it, RFC 6086 section 4.3.2 forbids message bodies in responses to INFO requests with an Info Package. Dale From nobody Thu Aug 25 15:18:26 2016 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 3427812D1DC for ; Thu, 25 Aug 2016 15:18:25 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjt0NWOxkyuf for ; Thu, 25 Aug 2016 15:18:24 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB3C12B02C for ; Thu, 25 Aug 2016 15:18:24 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 25 Aug 2016 15:18:23 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <39B5E4D390E9BD4890E2B31079006101164EB950@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164EB950@ESESSMB301.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Thu, 25 Aug 2016 15:18:21 -0700 To: Ivo Sedlacek , Paul Kyzivat , "sipcore@ietf.org" From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-content-id-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 22:18:25 -0000 At 11:37 AM +0000 8/17/16, Ivo Sedlacek wrote: > > - content-transfer-encoding > > Is this really needed? SIP provides binary transport. When defining MIME types, it's usual to specify the content transfer encoding that is used. So, it seems useful to permit Content-Transfer-Encoding as a SIP header field. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The trouble with doing anything right the first time is that nobody appreciates how difficult it was. From nobody Thu Aug 25 16:27:58 2016 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 4E8E612D0F5 for ; Thu, 25 Aug 2016 16:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, WEIRD_PORT=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghfK67o3eSZc for ; Thu, 25 Aug 2016 16:27:54 -0700 (PDT) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEF5A12B056 for ; Thu, 25 Aug 2016 16:27:54 -0700 (PDT) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-02v.sys.comcast.net with SMTP id d43PbFJFp0MKRd43ub63FG; Thu, 25 Aug 2016 23:27:54 +0000 Received: from hobgoblin.ariadne.com ([73.100.16.189]) by resomta-ch2-08v.sys.comcast.net with SMTP id d43tbS3W2Zqefd43tbbGfj; Thu, 25 Aug 2016 23:27:54 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u7PNRqRB017995 for ; Thu, 25 Aug 2016 19:27:52 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u7PNRpWV017992; Thu, 25 Aug 2016 19:27:51 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org In-Reply-To: <5d462933-e3c0-b3a3-958d-5c9d1e86d854@alum.mit.edu> (pkyzivat@alum.mit.edu) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 25 Aug 2016 19:27:51 -0400 Message-ID: <878tvk77k8.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfOGk9hLXeiQj2MSg9C4N1XpkbRrDk2Pfi0vVNaTPHQeVOcGOCa65PQhoq/Ib4P7qq3X+Y5ZDxXJxVk+zZCo61zN4Tz2vQb7iwMW9XujhK23/+2Sooazw 9zuL40LuBHqpPV2/mkmTA6DRAOlALo5iwCvxphAQ2R6A4UXUHsb+TkP9gNo/0tUfcdk0OFoIB/SkNQ== Archived-At: Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 23:27:56 -0000 BTW, what is the name of the draft in question? As far as I can tell, it's draft-ietf-ecrit-ecall-11. Why do the example INFO requests in that draft not have Info-Package headers, even though those are central to the interpretation of an info package INFO request? As I understand it: RFC 6086 allows an Info Package INFO request to contain the info package data as either the entire message body, or as one part of a multipart body. Which one applies is determined by the placement of a "Content-Disposition: Info-Package" header, either in the message headers or the headers of one part of the multipart body. The info package part may itself be a multipart type. Any additional body parts of the multipart case SHOULD NOT be data that is intrinsically associated with the data of the info package. The words "not specifically associated with the INFO method and the application concerned" aren't quite what one means, since the data is *always* associated with "the application concerned" in some way. The critical thing is that the data is not specifically associated with the particular info package of this INFO request. In ecrit communications, the callee can send an INFO info package request which requests the caller and the transit networks to resend the RFC 7852 Additional Data. That stimulates the caller to send an INFO request for an info package (seemingly) called "ACK". The ACK info package acknowledges that the caller has processed the Additional Data refresh request. Also, the caller attaches to the INFO request its current Additional Data. And the transit networks attach to the INFO request their current Additional Data. The question is, How is the updated Additional Data to be attached to the INFO request? One choice is that it is attached as described in RFC 7852, in the same way that it is attached to the INVITE request, as additional body parts pointed to by Call-Info headers. The other choice is that it is incorporated into the ACK info package. An additional question: It is clear how the caller detects that it must resend its Additional Data. But how do the transit networks detect that they must resend their Additional Data? Must they scan all transiting INFO requests for use of the ACK info package? I suppose that only requests to urn:service:sos:* URIs need be scanned. The advantage of attaching the Additional Data in the RFC 7852 manner is that the mechanism is already defined, and its implementation is already required. The advantage of attaching the Additional Data as part of the ACK info package is that it conforms to RFC 6086, since the Additional Data is specifically intended to be attached to that INFO request, not just some caller's request chosen at random within the dialog. Note: Suppose we define the ACK info package to *only* acknowledge receiving and processing the request for resend, but allow the caller to attach the Additional Data to any request it chooses. E.g., the caller could send an UPDATE carrying the Additional Data followed by an INFO informing the callee that it had resent the data. Then the Additional Data would not be *part of* the ACK info package data and the RFC 7852 method would not contravene RFC 6086 -- even if the caller *just happened* to always attach the Additional Data to the INFO for the ACK package. Or we could do it *both ways* at the *same time*... Here is an example INFO requesting resending the ecrit data, taken from draft-ietf-ecrit-ecall-11. I've added "Info-Package: emergencyCallData.eCall.MSD". INFO sip:+13145551111@example.com SIP/2.0 To: ;tag=9fxced76sl From: Exemplar PSAP Call-ID: 3848276298220188511@atlanta.example.com Call-Info: cid:3456789012@atlanta.example.com; purpose=emergencyCallData.eCall.control; Accept: application/sdp, application/pidf+xml, application/emergencyCallData.eCall.control+xml, application/emergencyCallData.eCall.MSD+per CSeq: 41862 INFO Info-Package: emergencyCallData.eCall.MSD Recv-Info: emergencyCallData.eCall.MSD Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, SUBSCRIBE, NOTIFY, UPDATE Content-Type: application/EmergencyCallData.eCall.control+xml Content-ID: 3456789012@atlanta.example.com Content-Disposition: info-package Here is the response INFO request that I propose, made by inserting the Additional Data from an example in RFC 7852 to the response INFO request in the draft: INFO urn:service:sos.ecall.automatic SIP/2.0 To: urn:service:sos.ecall.automatic From: ;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com Call-Info: cid:4567890123@atlanta.example.com; purpose=emergencyCallData.eCall.MSD; Call-Info: ;purpose=icon, ;purpose=info, ;purpose=EmergencyCallData.ProviderInfo, ;purpose=EmergencyCallData.DeviceInfo Geolocation: Geolocation-Routing: yes Accept: application/sdp, application/pidf+xml, application/emergencyCallData.eCall.control+xml CSeq: 51862 INFO Info-Package: emergencyCallData.eCall.MSD Recv-Info: emergencyCallData.eCall.MSD Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, SUBSCRIBE, NOTIFY, UPDATE Content-Disposition: info-package Content-Transfer-Encoding: binary Content-Type: multipart/mixed; boundary=boundary1 Content-Length: ... --boundary1 Content-Type: application/emergencyCallData.eCall.MSD+per Content-ID: 4567890123@atlanta.example.com ...MSD in ASN.1 PER encoding goes here... --boundary1 Content-Type: application/EmergencyCallData.DeviceInfo+xml Content-ID: <0123456789@atlanta.example.com> Content-Disposition: by-reference;handling=optional ... --boundary1 Content-Type: application/EmergencyCallData.ProviderInfo+xml Content-ID: <1234567890@atlanta.example.com> Content-Disposition: by-reference;handling=optional ... --boundary1-- The point here is that the emergencyCallData.eCall.MSD info package is defined to allow a multipart body and the body of this request is one such. One part of the body is the application/emergencyCallData.eCall.MSD+per, which presumably carries the ACK semantics, and zero or more parts are application/EmergencyCallData.ProviderInfo+xml, which carry the Additional Data. This structure conforms to RFC 6086. (The Call-Info headers that point to external resources are OK because they do not involve additional body parts.) The application/EmergencyCallData.ProviderInfo+xml parts are pointed to by Call-Info headers, conforming to RFC 7852. Note that the logic that inserts a application/EmergencyCallData.ProviderInfo+xml part into the multipart body which is the emergencyCallData.eCall.MSD info package is the same as the logic which inserts such a part into an ecrit INVITE. Dale From nobody Thu Aug 25 23:56:34 2016 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 70E44128E19 for ; Thu, 25 Aug 2016 23:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNo2X3XoHIB3 for ; Thu, 25 Aug 2016 23:56:29 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EB2F127077 for ; Thu, 25 Aug 2016 23:56:29 -0700 (PDT) X-AuditID: c1b4fb2d-903ff700000019a3-9a-57bfe81a5380 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by (Symantec Mail Security) with SMTP id 42.EC.06563.A18EFB75; Fri, 26 Aug 2016 08:56:27 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0301.000; Fri, 26 Aug 2016 08:56:26 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? Thread-Index: AQHR/t2KCnVeSlQa/k+Sxwkc4yebnqBZxASQ///o+oCAACKDMP//4g2AgAAiZiCAAC2+gIAA4H+A Date: Fri, 26 Aug 2016 06:56:26 +0000 Message-ID: References: <76CCBFA5-8D53-4B1E-A495-4A18AB081384@brianrosen.net> <05240A95-8319-4555-8B46-FA18B6C27883@brianrosen.net> <5d462933-e3c0-b3a3-958d-5c9d1e86d854@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC60A10@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC61D10@ESESSMB209.ericsson.se> <1c9b4538-720c-0126-7a82-d63edfc40caf@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC61E7C@ESESSMB209.ericsson.se> <81e44324-ae48-c2a4-c8e2-5f349da7d4d8@alum.mit.edu> In-Reply-To: <81e44324-ae48-c2a4-c8e2-5f349da7d4d8@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOIsWRmVeSWpSXmKPExsUyM2J7uK70i/3hBluuKlqs2HCA1eLrj01s Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGuWNHGAs2TGWsWPloMVMD45GJjF2MnBwS AiYSnacPsHcxcnEICaxnlOi7vJsNwlnCKHH/4j3WLkYODjYBC4nuf9ogDSICgRJXl0xgBrGF BRIl7rz8yQoRT5KYs2kPM4QdJTFjbQuYzSKgKtG7eSUbiM0rYCVxt2ktC8T8h6wSW6/+AEtw CjhINJ08CtbAKCAm8f3UGiYQm1lAXOLWk/lMEJcKSCzZc54ZwhaVePn4H9hiUQE9ie9fZ0PF FSXanzYwQvRqSXz5sY8NwraWaH02E2qmosSU7ofsEAcJSpyc+YRlAqPYLCTrZiFpn4WkfRaS 9llI2hcwsq5iFC1OLS7OTTcy1kstykwuLs7P08tLLdnECIyug1t+6+5gXP3a8RCjAAejEg+v gtH+cCHWxLLiytxDjBIczEoivKeeAYV4UxIrq1KL8uOLSnNSiw8xSnOwKInz+r9UDBcSSE8s Sc1OTS1ILYLJMnFwSjUwar5ZKOpkfturYHq62xefzjOrZST3HhDdy+qtE/7opZ5d0ncL3eDt Uv7da5+5ZEcEtqm+6SyQXr72mrnZhA917zTTzhyMuPooPG/rQ8sdr/2+JZyP/F/5jNfo8/H6 PAPX+VmWxkcbel6yKKopFu5uikkNPTWppHT5szd3lm4rSW040n7CpO6REktxRqKhFnNRcSIA YeEe9aoCAAA= Archived-At: Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 06:56:32 -0000 SGksDQoNCg0KPj4gT3IsIHRvIHB1dCBpdCBpbiBhbm90aGVyIHdheTogQXNzdW1pbmcgSSB3YW50 IHRvIHNlbmQgY29udGVudCBYIHVzaW5nDQo+PklORk8uIEhvdyBkbyBJIGRldGVybWluZSB3aGV0 aGVyIEkgbmVlZCB0byBkZWZpbmUgYW4gSW5mbyBQYWNrYWdlIGZvcg0KPj50aGF0LCBvciB3aGV0 aGVyIEkgY2FuIHNlbmQgaXQgaW4gSU5GTyB3aXRob3V0IGRlZmluaW5nIGFuIEluZm8gUGFja2Fn ZT8NCj4NCj5EZXBlbmRzIG9uIHdoYXQgeW91IG1lYW4gYnkgInNlbmQgaXQgaW4gSU5GTyIuDQo+ DQo+SSB0YWtlIHRoYXQgdG8gbWVhbjogc2VuZCBpdCBpbiB0aGUgSU5GTyBib2R5L2JvZHkgcGFy dC4NCg0KV2UgY2FuIGFzc3VtZSB0aGF0Lg0KDQo+V2hlbiB5b3UgYXJlIHRhbGtpbmcgYWJvdXQg ImxlZ2FjeSIgSU5GTyAod2l0aG91dCBpbmZvIHBhY2thZ2UpIHRoZW4gdGhlDQo+Ym9keSB1c2Fn ZSBpcyB2ZXJ5IGlsbC1kZWZpbmVkLiBZb3UgYXJlIGV4cGVjdGVkIHRvIG9ubHkgYmUgdXNpbmcg aXQgZm9yDQo+bGVnYWN5IHVzYWdlIC0gc3R1ZmYgdGhhdCBpcyAiZ3JhbmRmYXRoZXJlZCBpbiIu IFNvIEkgZG9uJ3QgdGhpbmsgdGhhdA0KPmV2ZW4gYXBwbGllcyB0byB0aGlzIHF1ZXN0aW9uLg0K DQpHb29kIC0gYXQgbGVhc3Qgd2UgYWdyZWUgb24gdGhhdCA6KQ0KDQo+QnV0IHRoaXMgaXMgZGFu Y2luZyBhcm91bmQgc3R1ZmYgdGhhdCBpcyBkZWZpbmVkIGJ5IHNvbWUgbWVhbnMgb3RoZXINCj50 aGFuIG1ldGhvZC4gSWYgeW91IHNheSAieW91IHdhbnQgdG8gc2VuZCBpdCB1c2luZyBJTkZPIiB0 aGVuIEkgd291bGQNCj5leHBlY3QgdGhlIGNvbnRlbnQgdG8gYmUgY29udGFpbmVkIHdpdGhpbiB0 aGUgaW5mbyBwYWNrYWdlIGJvZHkuIE9UT0gsDQo+aWYgeW91IGp1c3Qgd2FudCB0byBzZW5kIFgg aW4gYSBsb3Qgb2YgY2lyY3Vtc3RhbmNlcywgdGhlbiB5b3UgbWlnaHQNCj5jaG9vc2UgYSBkaWZm ZXJlbnQgbWV0aG9kIChzdWNoIGFzIGNhbGwtaW5mbykgdGhhdCBpc24ndA0KPm1ldGhvZC1zcGVj aWZpYy4gSWYgeW91IGRvIHRoYXQsIHRoZW4gaXQgY2FuIGdvIGFueXdoZXJlIGEgY2FsbC1pbmZv IGNhbg0KPmdvLCB3aGljaCBoYXBwZW5zIHRvIGluY2x1ZGUgSU5GTy4NCg0KWW91IHNlZW0gdG8g Y2xhaW0gdGhhdCwgc2luY2UgeW91IGNhbiBjYXJyeSBjb250ZW50IFggaW4gSU5WSVRFIHVzaW5n DQpDYWxsLUluZm8gKG9yIHdoYXRldmVyIG1lY2hhbmlzbSkgeW91IGNhbiBhbHNvIGNhcnJ5IGNv bnRlbnQgWCBpbiBJTkZPDQp1c2luZyB0aGUgc2FtZSBtZWNoYW5pc20uDQoNCkkgdGhpbmsgdGhh dKGvcyB3aGVyZSB3ZSBoYXZlIGRpZmZlcmVudCBvcGluaW9ucywgYmVjYXVzZSBJIGNsYWltIHRo YXQsDQp3aGVuIHlvdSBjYXJyeSBjb250ZW50IFggaW4gSU5GTywgeW91IGhhdmUgdG8gdXNlIGFu IEluZm8gUGFja2FnZSAtIGV2ZW4NCmlmIHlvdSBjYXJyeSBjb250ZW50IFggaW4gSU5WSVRFIHVz aW5nIENhbGwtSW5mby4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCg0KDQo+Pj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBQYXVsIEt5eml2YXQgW21haWx0bzpw a3l6aXZhdEBhbHVtLm1pdC5lZHVdDQo+Pj4gU2VudDogMjUgQXVndXN0IDIwMTYgMTg6MzQNCj4+ PiBUbzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT47 DQo+Pj4gc2lwY29yZUBpZXRmLm9yZw0KPj4+IFN1YmplY3Q6IFJlOiBbc2lwY29yZV0gQ2FuIGFu IElORk8gY29udGFpbiBhIGJvZHkgcmVsYXRlZCB0bywgYnV0IG5vdA0KPj4+cGFydCBvZiB0aGUg SU5GTyBwYWNrYWdlPw0KPj4+DQo+Pj4gT24gOC8yNS8xNiAxMDo1OCBBTSwgQ2hyaXN0ZXIgSG9s bWJlcmcgd3JvdGU6DQo+Pj4+IFBhdWwsIGEgZ2VuZXJpYyBxdWVzdGlvbiwgd2hpY2ggbWlnaHQg aGVscCBtZSB1bmRlcnN0YW5kIHlvdXIgdmlldyBvbg0KPj4+PmVjYWxsOiBpbiB5b3VyIG9waW5p b24sIHdoZW4gKGlmIGV2ZXIpIGlzIHVzYWdlIG9mIGFuIEluZm8gUGFja2FnZQ0KPj4+PnJlcXVp cmVkPw0KPj4+DQo+Pj4gSSBndWVzcyBJIHdvdWxkIHBocmFzZSBpdCB0aGlzIHdheToNCj4+Pg0K Pj4+IElmIHlvdSBoYXZlIGEgbmVlZCB0byB0cmFuc21pdCBzb21lIGluZm9ybWF0aW9uIHZpYSBh IHNpcCBzZXNzaW9uLA0KPj4+dGhlbiB5b3Ugc2hvdWxkIGNvbnNpZGVyIGFsbCB0aGUgYXZhaWxh YmxlIG1lY2hhbmlzbXMgc2lwIGhhcywgYW5kDQo+Pj5kZWNpZGUgaWYgdGhlcmUgaXMgc29tZSBj b21iaW5hdGlvbiBvZiBleGlzdGluZyBtZWNoYW5pc21zIHRoYXQgbWVldHMNCj4+PnlvdXIgbmVl ZC4NCj4+Pg0KPj4+IFRoZSBmb2xsb3dpbmcgYXJlIHNvbWUgb2YgdGhlIGF2YWlsYWJsZSBtZWNo YW5pc21zOg0KPj4+DQo+Pj4gLSBuZXcgZXZlbnQgcGFja2FnZXMNCj4+PiAtIG5ldyBpbmZvIHBh Y2thZ2VzDQo+Pj4gLSBuZXcgcXVhbGlmeWluZyBvcHRpb25zIHdpdGggY2FsbC1pbmZvLCBhbGVy dC1pbmZvLCBlcnJvci1pbmZvDQo+Pj4gLSBuZXdseSBkZWZpbmVkIGhlYWRlciBmaWVsZCBwYXJh bWV0ZXJzDQo+Pj4gLSBuZXcgZGVmaW5lZCBoZWFkZXIgZmllbGRzDQo+Pj4NCj4+PiBNYW55IG9m IHRoZXNlIG1lY2hhbmlzbXMgaGF2ZSB0aGVpciBvd24gcnVsZXMgZm9yIHdoYXQgc29ydHMgb2Yg bmV3DQo+Pj51c2FnZSBhcmUgYXBwcm9wcmlhdGUuIE90aGVycyBkbyBub3QsIGFuZCBhcmUgcHJv YmFibHkgZGVmaWNpZW50DQo+Pj5iZWNhdXNlIG9mIHRoYXQuIEZvciB0aG9zZSwgdGhlIGJhciBp cyBnZW5lcmFsbHkgdGhlIG5lZWQgdG8gZ2V0IGEgUkZDDQo+Pj5hcHByb3ZlZC4NCj4+Pg0KPj4+ IElORk8gaXMgbm90YWJsZSBiZWNhdXNlIHRoZSBiYXIgaXMgcHJldHR5IGxvdyAoU3BlY2lmaWNh dGlvbiBSZXF1aXJlZCkuDQo+Pj4gU28gc29tZSBtYXkgY2hvb3NlIGl0IGZvciBpdHMgZWFzZS4N Cj4+Pg0KPj4+IFdoZW4gY2hvb3NpbmcgYW1vbmcgdGhlIG9wdGlvbnMsIHlvdSBoYXZlIHRvIGNv bnNpZGVyIHdoYXQgdGhlDQo+Pj5hcHByb3ZhbCBwcm9jZXNzZXMgd2lsbCBiZSBmb3IgZWFjaCwg YW5kIHRoYXQgdGhlIHJldmlld2VycyB3aWxsDQo+Pj5wcm9iYWJseSBhc2sgaWYgeW91IGhhdmUg Y29uc2lkZXJlZCBhbHRlcm5hdGl2ZSBhcHByb2FjaGVzLg0KPj4+DQo+Pj4gRm9yIGluc3RhbmNl IEdlb2xvY2F0aW9uIHdhcyBkb25lIHdpdGggYSBuZXcgaGVhZGVyIGZpZWxkIHRoYXQNCj4+PnNv bWV0aW1lcyByZWZlcmVuY2VzIGEgc2VwYXJhdGUgYm9keSBwYXJ0LiBUaGF0IHJhaXNlZCBhIGhp Z2hlciBodXJkbGUNCj4+PnRvIGdldCBvdmVyIHRoYW4gdXNpbmcgYW4gaW5mbyBwYWNrYWdlLiBC dXQgaXQgd2FzIGRlZW1lZCB3b3J0aCBpdA0KPj4+c2luY2UgaXQgaGFkIG5lZWRzIHRoYXQgY291 bGRuJ3QgYmUgbWV0IGJ5IGluZm8gcGFja2FnZXMuDQo+Pj4NCj4+PiBJbiBnZW5lcmFsIHRoZXJl IGFyZSBsaWtlbHkgdG8gYmUgbXVsdGlwbGUgb3B0aW9ucyBhdmFpbGFibGUgZm9yDQo+Pj5hbG1v c3QgYW55dGhpbmcgeW91IHdhbnQgdG8gZG8uIEFuZCB0aGVuIGl0IHdpbGwgY29tZSBkb3duIHRv IHdlaWdoaW5nDQo+Pj50aGUgcHJvcy9jb25zLg0KPj4+DQo+Pj4gCVRoYW5rcywNCj4+PiAJUGF1 bA0KPj4+DQo+Pj4+IFJlZ2FyZHMsDQo+Pj4+DQo+Pj4+IENocmlzdGVyDQo+Pj4+DQo+Pj4+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+IEZyb206IHNpcGNvcmUgW21haWx0bzpzaXBj b3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQYXVsDQo+Pj4+IEt5eml2YXQNCj4+ Pj4gU2VudDogMjUgQXVndXN0IDIwMTYgMTc6MzINCj4+Pj4gVG86IHNpcGNvcmVAaWV0Zi5vcmcN Cj4+Pj4gU3ViamVjdDogUmU6IFtzaXBjb3JlXSBDYW4gYW4gSU5GTyBjb250YWluIGEgYm9keSBy ZWxhdGVkIHRvLCBidXQgbm90DQo+Pj4+cGFydCBvZiB0aGUgSU5GTyBwYWNrYWdlPw0KPj4+Pg0K Pj4+PiBPbiA4LzI1LzE2IDk6MjYgQU0sIEJyaWFuIFJvc2VuIHdyb3RlOg0KPj4+Pj4gWWVzLCBJ oa9tIHNheWluZyB0aGF0IHRoZSBBQ0sgc2F0aXNmaWVzIHRoZSA2MDg2IHVzZSBvZiBJTkZPLCBh bmQNCj4+Pj4+dGhhdCBpdKGvcyBva2F5IHRvIHNlbmQgdGhlIGRhdGEgd2l0aCBDYWxsLUluZm8u DQo+Pj4+Pg0KPj4+Pj4gWWVzLCBJoa9tIGFncmVlaW5nIHRoYXQgdGhlcmUgaXMgYSByZWxhdGlv bnNoaXAgYmV0d2VlbiB0aGUgSU5GTw0KPj4+Pj5wYWNrYWdlIGFuZCB0aGUgZGF0YS4NCj4+Pj4+ DQo+Pj4+PiBZZXMsIEmhr20gZGlzYWdyZWVpbmcgd2l0aCB5b3VyIGludGVycHJldGF0aW9uIG9m IHRoZSBsYW5ndWFnZS4NCj4+Pj4+DQo+Pj4+PiBTbywgbm93LCB3aGF0IHNheSB5b3Ugc2lwY29y ZT8NCj4+Pj4NCj4+Pj4gSSB0aGluayB0aGUgbWFpbiBwb2ludCBvZiBicmluZ2luZyB0aGlzIHRv IHNpcGNvcmUgaXMgdG8gZ2V0IHNvbWUNCj4+Pj5mcmVzaCBpbnB1dCBpbnRvIHRoaXMgZGlzY3Vz c2lvbi4gU2luY2UgSSBoYXZlIGJlZW4gcGFydHkgdG8gdGhlDQo+Pj4+ZGlzY3Vzc2lvbiBvdmVy IGluIGVjcml0IEkgZG9uJ3QgYnJpbmcgYW55dGhpbmcgZnJlc2ggaGVyZS4gQnV0IGZvcg0KPj4+ PmNvbXBsZXRlbmVzcyBJIHdpbGwgcmVnaXN0ZXIgbXkgb3BpbmlvbiBoZXJlIHRvby4NCj4+Pj4N Cj4+Pj4gSU1PIHRoaXMgaXMgbm90IGEgcXVlc3Rpb24gYWJvdXQgd2hldGhlciB0aGUgcHJvcG9z ZWQgdXNhZ2UgaXMgdmFsaWQNCj4+Pj4gYWNjb3JkaW5nIHRvIDYwODYgYW5kIG90aGVyIHJmY3Mu IChJIHRoaW5rIGl0IGlzIHF1aXRlIGNsZWFyIHRoYXQgaXQNCj4+Pj4gKmlzKiB2YWxpZC4pIFJh dGhlciB0aGlzIGlzIHNpbXBseSBhIHF1ZXN0aW9uIG9mIHdoYXQgaXMgdGhlIGJlc3QNCj4+Pj5k ZXNpZ24gZm9yIHRoZSBkZXNpcmVkIGZ1bmN0aW9uYWxpdHkuIEFzIHN1Y2ggSSBkb24ndCB0aGlu ayBpdCByZWFsbHkNCj4+Pj5uZWVkcyB0byBiZSBzZXR0bGVkIGluIHNpcGNvcmUuDQo+Pj4+DQo+ Pj4+IEJ1dCBJIGFtIGhhcHB5IHRvIGNoZWNrIGlmIGFueWJvZHkgaGFzIGEgZGlmZmVyZW50IHBl cnNwZWN0aXZlIG9uDQo+Pj4+dGhpcy4NCj4+Pj4NCj4+Pj4gCVRoYW5rcywNCj4+Pj4gCVBhdWwN Cj4+Pj4NCj4+Pj4+IEJyaWFuDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+PiBPbiBBdWcgMjUsIDIwMTYs IGF0IDk6MTQgQU0sIENocmlzdGVyIEhvbG1iZXJnDQo+Pj4+Pj48Y2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tPiB3cm90ZToNCj4+Pj4+Pg0KPj4+Pj4+IEhpLA0KPj4+Pj4+DQo+Pj4+Pj4+ IFdloa9yZSBhZ3JlZWluZyB0aGF0IHRoZXJlIGlzIGEgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhl IGNvbW1hbmQNCj4+Pj4+Pj4gYW5kIHRoZSBkYXRhLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBXZaGvcmUg c3VnZ2VzdGluZyB0aGF0IHdlIGRvbqGvdCBoYXZlIHRvIGJlIGFuYWwgYWJvdXQgdGhlIGxhbmd1 YWdlDQo+Pj4+Pj4+IGFuZCBhcyBsb25nIGFzIHRoZXJlIGlzIGFuIElORk8gcGFja2FnZSwgYW5k IGEgYm9keSBwYXJ0IHRoYXQgaGFzDQo+Pj4+Pj4+IHRoZSBBQ0sgd2hpY2ggaXMgYW4gSU5GTyBi b2R5IHBhcnQsIHRoYXQgdGhlIGNpdGVkIGxhbmd1YWdlDQo+Pj4+Pj4+IGRvZXNuoa90IGNvbXBl bCB1cyB0byB1c2UgdGhlIElORk8gYm9keSBwYXJ0IHRvIHRyYW5zcG9ydCB0aGUgZGF0YSwNCj4+ Pj4+Pj4gdGhlIENhbGwtSW5mbyBtZWNoYW5pc20gaXMgYWNjZXB0YWJsZS4NCj4+Pj4+Pj4NCj4+ Pj4+Pj4gTm8gb25lIGlzIHN1Z2dlc3RpbmcgdGhhdCB3ZSB1cGRhdGUgNjA4NiwgYW5kIHdlIGFn cmVlIHRoYXQgNzg1Mg0KPj4+Pj4+PiBkaWQgbm90IHVwZGF0ZSA2MDg2Lg0KPj4+Pj4+Pg0KPj4+ Pj4+PiBJdKGvcyBqdXN0IHdoZXRoZXIgdGhhdCBsYW5ndWFnZSBwcm9oaWJpdHMgdXNlIG9mIHRo ZSBDYWxsLUluZm8gdG8NCj4+Pj4+Pj4gY2FycnkgdGhlIGRhdGEgd2hlbiBpdCB3YXMgcHJvbXB0 ZWQgYnkgdGhlIElORk8gcGFja2FnZSByZXF1ZXN0LA0KPj4+Pj4+PiBhbmQgYWNjb21wYW5pZXMg dGhlIElORk8gcGFja2FnZSBBQ0suDQo+Pj4+Pj4NCj4+Pj4+PiBZb3Ugc2VlbSB0byBzdWdnZXN0 IHRoYXQsIGp1c3QgYmVjYXVzZSB5b3UgdXNlIGFuIEluZm8gUGFja2FnZSBmb3INCj4+Pj4+PiBz ZW5kaW5nIFNPTUUgb2YgdGhlIGVjYWxsIHJlbGF0ZWQgaW5mb3JtYXRpb24gKHRoZSByZXF1ZXN0 IGFuZA0KPj4+Pj4+IEFDSyksIHRoYXQgYWxsb3dzIHlvdSB0byBzZW5kIHRoZSByZXN0IG9mIHRo ZSBlY2FsbCByZWxhdGVkDQo+Pj4+Pj4gaW5mb3JtYXRpb24gKHRoZSBkYXRhIGNvbnRlbnQpIHdp dGhvdXQgdXNpbmcgYW4gSW5mbyBQYWNrYWdlLiBJDQo+Pj4+Pj4gcmVhbGx5IGRvbqGvdCBzZWUg aG93IHlvdSBjYW4gcGFyc2UgdGhlIGNpdGVkIHRleHQgaW4gdGhhdCB3YXkuIFRoZQ0KPj4+Pj4+ IGNpdGVkIHRleHQgc2F5cyB0aGF0IGluZm9ybWF0aW9uIGFzc29jaWF0ZWQgd2l0aCB0aGUgYXBw bGljYXRpb24NCj4+Pj4+PiBzaGFsbCBiZSBzZW50IHVzaW5nIGFuIEluZm8gUGFja2FnZS4gQW5k LCBib3RoIHRoZSBBQ0sgYW5kIHRoZQ0KPj4+Pj4+IHJlcXVlc3RlZCBkYXRhIGNvbnRlbnQgYXJl IGFzc29jaWF0ZWQgd2l0aCB0aGUgZWNhbGwgYXBwbGljYXRpb24uDQo+Pj4+Pj4NCj4+Pj4+PiBS ZWdhcmRzLA0KPj4+Pj4+DQo+Pj4+Pj4gQ2hyaXN0ZXINCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4N Cj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+IEJyaWFuDQo+Pj4+Pj4+DQo+Pj4+Pj4+ PiBPbiBBdWcgMjUsIDIwMTYsIGF0IDI6MDAgQU0sIENocmlzdGVyIEhvbG1iZXJnDQo+Pj4+Pj4+ PiA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4+Pj4+Pj4+DQo+Pj4+ Pj4+PiBIaSwNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBJqfZtIGdsYWQgdGhpcyBpcyBicm91Z2h0IHRv IFNJUENPUkUuIEFzIG9uZSBvZiB0aGUgaW5mbyBwYWNrYWdlDQo+Pj4+Pj4+PiBwcm9wb25lbnRz LCBwbGVhc2UgbGV0IG1lIGNsYXJpZnkgbXkgYXJndW1lbnRzLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ IFRoZSA2MDg2IHRleHQgdGhhdCBCcmlhbiBjb3BpZWQgc2F5cyCp+GJ1dCBhcmUgbm90IHNwZWNp ZmljYWxseQ0KPj4+Pj4+Pj4gYXNzb2NpYXRlZCB3aXRoIHRoZSBJTkZPIG1ldGhvZCBhbmQgdGhl IGFwcGxpY2F0aW9uIGNvbmNlcm5lZKn3Lg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IEkgY2xhaW0gdGhh dCB0aGUgdXBkYXRlZCBkYXRhIElTIGFzc29jaWF0ZWQgd2l0aCB0aGUgYXBwbGljYXRpb24NCj4+ Pj4+Pj4+IGNvbmNlcm5lZCAoZWNhbGwpLiBUaGUgdXBkYXRlZCBkYXRhIGlzIHJlcXVlc3RlZCBi eSB0aGUgZWNhbGwNCj4+Pj4+Pj4+IGFwcGxpY2F0aW9uLCBhbmQgdGhlIGRlbGl2ZXJlZCB1cGRh dGVkIGRhdGEgaXMgY29uc3VtZWQgYnkgdGhlDQo+Pj4+Pj4+PiBlY2FsbCBhcHBsaWNhdGlvbi4g VGhlIHVwZGF0ZWQgZGF0YSBpcyBOT1Qgc29tZQ0KPj4+Pj4+Pj4gbm9uLWVjYWxsLWFwcGxpY2F0 aW9uLXJlbGF0ZWQgaW5mb3JtYXRpb24gdGhhdCBpcyBwaWdneWJhY2tlZCBpbg0KPj4+Pj4+Pj4g YSAiY29udmVuaWVudCBJTkZPIG1lc3NhZ2UiIHRoYXQgaGFwcGVucyB0byBiZSBzZW50IGJ5IHRo ZSBlY2FsbA0KPj4+Pj4+Pj4gYXBwbGljYXRpb24gZm9yIHNvbWUgb3RoZXIgcHVycG9zZS4NCj4+ Pj4+Pj4+DQo+Pj4+Pj4+PiAoSW4gYWRkaXRpb24sIHRoZSB1cGRhdGVkIGRhdGEgaXMgTk9UIGFz c29jaWF0ZWQgd2l0aCBhIGxlZ2FjeQ0KPj4+Pj4+Pj4gKHByZS02MDg2KQ0KPj4+Pj4+Pj4gSU5G TyB1c2FnZSwgd2hpY2ggY291bGQganVzdGlmeSBub3QgdXNpbmcgYW4gSW5mbyBQYWNrYWdlLiBJ IGRvDQo+Pj4+Pj4+PiB3YW50IHRvIHBvaW50IG91dCB0aGF0IG5vYm9keSBoYXMgY2xhaW1lZCB0 aGF0IHRoZSB1cGRhdGVkIGRhdGENCj4+Pj4+Pj4+IHdvdWxkIGJlIGFzc29jaWF0ZWQgd2l0aCBs ZWdhY3kgSU5GTywgYnV0IGp1c3QgZm9yIGNvbXBsZXRlbmVzcykNCj4+Pj4+Pj4+DQo+Pj4+Pj4+ PiBSRkMgNzg1MiBkb2VzIGRlZmluZSBhIG1lY2hhbmlzbSBmb3IgdHJhbnNwb3J0aW5nIGRhdGEs IHVzaW5nDQo+Pj4+Pj4+PiBDYWxsLUluZm8gZXRjLiBCdXQsIDc4NTIgZG9lcyBub3QgdXBkYXRl IDYwODYsIG5vciBjYW4gNzg1Mg0KPj4+Pj4+Pj4gb3ZlcnJpZGUgcnVsZXMgYW5kIHByb2NlZHVy ZXMgYXNzb2NpYXRlZCB3aXRoIGluZGl2aWR1YWwgU0lQDQo+Pj4+Pj4+PiBtZXRob2RzIChJTkZP IGluIHRoaXMgY2FzZSkuIEkgYWxzbyBwb2ludGVkIHRoaXMgb3V0IGJlZm9yZSA3ODUyDQo+Pj4+ Pj4+PiB3YXMgcHVibGlzaGVkLCBidXQgd2FzIHRvbGQgdGhhdCBpdKn2cyB0b28gbGF0ZSB0byBj aGFuZ2UgaXQNCj4+Pj4+Pj4+IChncmFudGVkLCB0aGUgZHJhZnQgd2FzIGluIHRoZSBSRkMgZWRp dG9yqfZzIHF1ZXVlKS4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBGaW5hbGx5LCBhZ2FpbiBmb3IgY29t cGxldGVuZXNzLCBJIHdhbnQgdG8gcG9pbnQgb3V0IHRoYXQgNjA4Ng0KPj4+Pj4+Pj4gZG9lcyBu b3QgcHJldmVudCBpbmNsdWRpbmcgQ2FsbC1JbmZvIGluIElORk8gYXMgc3VjaC4gVGhlIGlzc3Vl DQo+Pj4+Pj4+PiBpcyBob3cgc29tZSB3YW50IHRvIHVzZSBDYWxsLUluZm8gaW5zdGVhZCBvZiBh biBJbmZvIFBhY2thZ2UuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gUmVnYXJkcywNCj4+Pj4+Pj4+DQo+ Pj4+Pj4+PiBDaHJpc3Rlcg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4g T24gMjUvMDgvMTYgMDM6MjIsICJzaXBjb3JlIG9uIGJlaGFsZiBvZiBCcmlhbiBSb3NlbiINCj4+ Pj4+Pj4+IDxzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGJyQGJyaWFucm9z ZW4ubmV0PiB3cm90ZToNCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gT3ZlciBpbiBlY3JpdCB3ZSBoYXZl IGEgZGlzYWdyZWVtZW50IHRoYXQgcmVsYXRlcyB0bw0KPj4+Pj4+Pj4+IGludGVycHJldGluZyBS RkM2MDg2Lg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gQmFja2dyb3VuZDoNCj4+Pj4+Pj4+PiBSRkM3 ODUyIGRlZmluZXMgc29tZXRoaW5nIGNhbGxlZCAiQWRkaXRpb25hbCBEYXRhIiwgd2hpY2ggaXMN Cj4+Pj4+Pj4+PiBjYXJyaWVkIGluIGVtZXJnZW5jeSBjYWxsIHNpZ25hbGluZy4gIEl0J3MgZGF0 YSByZWxhdGVkIHRvIHRoZQ0KPj4+Pj4+Pj4+IGNhbGwsIGUuZy4sIHRoZSBpZGVudGl0eSBhbmQg Y29udGFjdCBkYXRhIG9mIHRoZSBzZXJ2aWNlDQo+Pj4+Pj4+Pj5wcm92aWRlciBoYW5kbGluZyB0 aGUgY2FsbC4NCj4+Pj4+Pj4+PiBBZGRpdGlvbmFsIERhdGEgaXMgc2lnbmFsZWQgd2l0aCBhIENh bGwtSW5mbyBoZWFkZXIgZmllbGQsIHdoaWNoDQo+Pj4+Pj4+Pj4gY29udGFpbnMgZWl0aGVyIGEg VVJJIHBvaW50aW5nIHRvIGEgZGF0YSBibG9jayBmZXRjaGVkIHdpdGgNCj4+Pj4+Pj4+PiBIVFRQ Uywgb3IgYSBDb250ZW50IEluZGlyZWN0IHJlZmVyZW5jaW5nIGEgYm9keSBwYXJ0IG9mIHRoZSBT SVANCj4+Pj4+Pj4+Pm1lc3NhZ2UuDQo+Pj4+Pj4+Pj4gSXQncyB1c3VhbGx5IHVzZWQgb24gdGhl IElOVklURSBvZiB0aGUgZW1lcmdlbmN5IGNhbGwsIHNvIGl0IGNhbg0KPj4+Pj4+Pj4+IGJlIGRp c3BsYXllZCB0byB0aGUgUFNBUCAoZW1lcmdlbmN5IGNhbGwgY2VudGVyKSBjYWxsLXRha2VyIHdo ZW4NCj4+Pj4+Pj4+PiB0aGUgY2FsbCBpcyBhc3NpZ25lZC4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ IFNvbWV0aW1lcywgdGhpcyBkYXRhIGNhbiBjaGFuZ2UgZHVyaW5nIGEgY2FsbC4gIFRoZSBleGFt cGxlIGluDQo+Pj4+Pj4+Pj4gZGlzY3Vzc2lvbg0KPj4+Pj4+Pj4+IGlzIHRlbGVtYXRpY3MgZGF0 YSBpbiBhIHZlaGljbGUuICAgVGhlIHZlaGljbGUgY2FuIHJlcG9ydCB0aGluZ3MNCj4+Pj4+Pj4+ Pmxpa2UNCj4+Pj4+Pj4+PiB0aGUNCj4+Pj4+Pj4+PiBudW1iZXIgb2Ygb2NjdXBhbnRzIGFuZCBp dHMgb3JpZW50YXRpb24uICBUaGUgUFNBUCBjYW4gcmVxdWVzdA0KPj4+Pj4+Pj4+IGFuIHVwZGF0 ZSBtaWQgY2FsbCAoZS5nLiwgaWYgdGhlIGNhbGwgdGFrZXIgdGhpbmtzIHRoaW5ncyBtaWdodA0K Pj4+Pj4+Pj4+IGhhdmUgY2hhbmdlZCkuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBJTkZPIGlzIHRo ZSBjaG9zZW4gbWVjaGFuaXNtIHRvIHNlbmQgdGhlIHJlcXVlc3QgZm9yIHVwZGF0ZS4NCj4+Pj4+ Pj4+PiBUaGUgZGV2aWNlIHdpbGwgc2VuZCBhIHJlc3BvbnNlIHRvIHRoZSByZXF1ZXN0IChhbiBB Q0spLCB3aGljaA0KPj4+Pj4+Pj4+IGlzIGFsc28gc2VudCBpbiBJTkZPLg0KPj4+Pj4+Pj4+IFRo aXMgY29uc3RpdHV0ZXMgYSB3ZWxsIGRlZmluZWQgSU5GTyBwYWNrYWdlLCBhbmQgd2lsbCBiZQ0K Pj4+Pj4+Pj4+IHJlZ2lzdGVyZWQgaW4gdGhlIHVzdWFsIHdheS4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+IFRoZSBJc3N1ZSBhdCBoYW5kOg0KPj4+Pj4+Pj4+IFNvLCB0aGUgZGlzcHV0ZSBpcyBob3cg dGhlIHVwZGF0ZWQgZGF0YSBpcyBzZW50IG1pZCBjYWxsLg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4g UkZDNjA4NiBzYXlzDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBOT1RFOiBBbiBJTkZPIHJlcXVlc3Qg Y2FuIGFsc28gY29udGFpbiBvdGhlciBib2R5IHBhcnRzIHRoYXQgYXJlDQo+Pj4+Pj4+Pj4gbWVh bmluZ2Z1bCB3aXRoaW4gdGhlIGNvbnRleHQgb2YgYW4gaW52aXRlIGRpYWxvZyB1c2FnZSBidXQg YXJlDQo+Pj4+Pj4+Pj4gbm90IHNwZWNpZmljYWxseSBhc3NvY2lhdGVkIHdpdGggdGhlIElORk8g bWV0aG9kIGFuZCB0aGUNCj4+Pj4+Pj4+PiBhcHBsaWNhdGlvbiBjb25jZXJuZWQuDQo+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+PiBUaGUgYXV0aG9ycyBvZiB0aGUgZHJhZnQgKG9mIHdoaWNoIEkgYW0gb25l KSBkZXNpcmUgdG8gdXNlIHRoZQ0KPj4+Pj4+Pj4+IEFkZGl0aW9uYWwgRGF0YSBtZWNoYW5pc20g dG8gY2FycnkgdGhlIHVwZGF0ZWQgZGF0YS4gIFRoZSBkYXRhDQo+Pj4+Pj4+Pj4gY291bGQgYmUg c2VudCBpbiBhbnkgY29udmVuaWVudCBtZXNzYWdlLCBhbHRob3VnaCBzaW5jZSB0aGUNCj4+Pj4+ Pj4+PiB2ZWhpY2xlIGlzIHNlbmRpbmcgYW4gQUNLLCBpdCdzIGxpa2VseSBnb2luZyB0byBnbyBv biB0aGF0Lg0KPj4+Pj4+Pj4+IFdlJ2QgbGlrZSB0byBhbHdheXMgY2FycnkgdGhlIGRhdGEgaW4g dGhlIHNhbWUgd2F5LiAgSW4gYW4gSU5GTw0KPj4+Pj4+Pj4+IG1lc3NhZ2UgaXQgd291bGQgYmUg Y2FycmllZCB0aGUgc2FtZSBhcyBpdCBpcyBpbiB0aGUgSU5WSVRFLCBhcw0KPj4+Pj4+Pj4+IEFk ZGl0aW9uYWwgRGF0YS4gIFNpbmNlIHRoZSBJTkZPIGNhcnJpZXMgYW4gQUNLLCBpdCB3b3VsZA0K Pj4+Pj4+Pj4+IHNwZWNpZnkgdGhlIGFwcHJvcHJpYXRlIElORk8gcGFja2FnZSwgYW5kIHdvdWxk IGNvbnRhaW4gYSBib2R5DQo+Pj4+Pj4+Pj4gcGFydCB3aXRoIHRoZSBBQ0suICBUaGVyZSB3b3Vs ZCBiZSBhbm90aGVyIGJvZHkgcGFydCBmb3IgdGhlDQo+Pj4+Pj4+Pj4gdXBkYXRlZCBkYXRhLCBw b2ludGVkIHRvIGJ5IHRoZSBDYWxsLUluZm8uDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBTb21lIGVj cml0IHBhcnRpY2lwYW50cyBzYXkgdGhhdCB0aGUgYWJvdmUgbGFuZ3VhZ2Ugb2YgNjA4Ng0KPj4+ Pj4+Pj4+IHdvdWxkIHByb2hpYml0IHRoZSBJTkZPIGZyb20gY29udGFpbmluZyBhIENhbGwtSW5m byBoZWFkZXIgd2l0aA0KPj4+Pj4+Pj4+IGEgQ0lEIHBvaW50aW5nIHRvIGEgTUlNRSBib2R5IHBh cnQsIGJlY2F1c2UgdGhlIGRhdGEgd2FzDQo+Pj4+Pj4+Pj4gcmVxdWVzdGVkIGJ5IGFuIElORk8s IGFuZCBoZW5jZSBpcyByZWxhdGVkIHRvIHRoZSBJTkZPIHBhY2thZ2UuDQo+Pj4+Pj4+Pj4gVGhl eSBzYXkgdGhhdCB0aGUgZGF0YSBNVVNUIGJlIGNhcnJpZWQgd2l0aCBhIGJvZHkgcGFydCBhbmQN Cj4+Pj4+Pj4+PiBDb250ZW50IERpc3Bvc2l0aW9uIHRoYXQgaXMgcGFydCBvZiB0aGUgSU5GTyBw YWNrYWdlIGRlZmluaXRpb24uDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBUaGUgZHJhZnQgYXV0aG9y cyBjbGFpbSB0aGlzIDYwODYgbGFuZ3VhZ2UgaXNuJ3QgYQ0KPj4+Pj4+Pj4+IHN0cmFpZ2h0amFj a2V0LCBhbmQgaXQncyBwZXJmZWN0bHkgZmluZSB0byBjYXJyeSB0aGUgZGF0YQ0KPj4+Pj4+Pj4+ IHJlZmVyZW5jZWQgYnkgYSBDYWxsLUluZm8gd2l0aCBhIENvbnRlbnQgSW5kaXJlY3QgYm9keSBw YXJ0DQo+Pj4+Pj4+Pj51c2luZyB0aGUgc2FtZSBNSU1FIHR5cGUgYW5kIENvbnRlbnQNCj4+Pj4+ Pj4+PiBEaXNwb3NpdGlvbiBhcyBpdCB3b3VsZCBpbiBhbiBJTlZJVEUuICAgV2hlbiB0aGUgdXBk YXRlZCBkYXRhIGlzDQo+Pj4+Pj4+Pj5zZW50DQo+Pj4+Pj4+Pj4gaW4NCj4+Pj4+Pj4+PiBJTkZP LCBpdCdzIGJlY2F1c2UgdGhlIElORk8gaXMgYSBjb252ZW5pZW50IG1lc3NhZ2UgKHNpbmNlIGl0 J3MNCj4+Pj4+Pj4+PiBiZWluZyBzZW50IHRvIGNhcnJ5IHRoZSBBQ0spLg0KPj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4gTWVjaGFuaWNhbGx5LCBib3RoIG1lY2hhbmlzbXMgY2FuIGJlIG1hZGUgdG8gd29y ay4gIFRoZSBib2R5DQo+Pj4+Pj4+Pj4gcGFydHMgd291bGQgYmUgbGFiZWxlZCBhcHByb3ByaWF0 ZWx5IGFuZCB0aGVyZSB3b3VsZCBiZSBubw0KPj4+Pj4+Pj4+IGNvbmZ1c2lvbiBhYm91dCB3aGF0 IHRoZXkgbWVhbiBvciBob3cgdGhleSB3b3VsZCBiZSBpbnRlcnByZXRlZC4NCj4+Pj4+Pj4+PiBJ dCdzIHJlYWxseSBvbmx5IHdoZXRoZXIgdGhlIENhbGwtSW5mbyBoZWFkZXIgaXMgcHJlc2VudCBh bmQNCj4+Pj4+Pj4+PiB3aGF0IHRoZSBNSU1FIHR5cGUgYW5kIENvbnRlbnQgRGlzcG9zaXRpb24g dGhlIGJvZHkgcGFydA0KPj4+Pj4+Pj4+IGNvbnRhaW5pbmcgdGhlIGRhdGEgd291bGQgYmUuICBJ biB0aGUgYXV0aG9yJ3MgcHJlZmVycmVkIHdheSwgaXQNCj4+Pj4+Pj4+PiB3b3VsZCBiZSB0aGUg TUlNRSB0eXBlIGFuZCBDb250ZW50IERpc3Bvc2l0aW9uIG9mIHRoZSBDYWxsLUluZm8NCj4+Pj4+ Pj4+PiBhbmQgaW4gdGhlIG90aGVyIHBvaW50IG9mIHZpZXcgaXQgd291bGQgYmUgdGhlIE1JTUUg dHlwZSBhbmQNCj4+Pj4+Pj4+PiBDb250ZW50IERpc3Bvc2l0aW9uIG9mIHRoZSBJTkZPIHBhY2th Z2UuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBQbGVhc2UgaWdub3JlIHlvdXIgcGVyc29uYWwgcHJl ZmVyZW5jZSBmb3Igd2hldGhlciB5b3UgdGhpbmsgaXQNCj4+Pj4+Pj4+PiBvdWdodCB0byBnbyBp biB0aGUgSU5GTyBvciBub3QsIGFuZCBwbGVhc2UgaGVscCB1cyBpbnRlcnByZXQNCj4+Pj4+Pj4+ PjYwODY6DQo+Pj4+Pj4+Pj4gZG9lcyB0aGUgZGF0YSBIQVZFIHRvIGdvIGluIGFuIElORk8gYm9k eSBwYXJ0IG9yIGNhbiBpdCBiZSBzZW50DQo+Pj4+Pj4+Pj4gaW4gYSBDYWxsLUluZm8gYm9keSBw YXJ0Pw0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4+PiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPj4+Pj4+ Pj4+IHNpcGNvcmVAaWV0Zi5vcmcNCj4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NpcGNvcmUNCj4+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+DQo+ Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ Pj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4+Pj4+IHNpcGNvcmVAaWV0Zi5vcmcNCj4+Pj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KPj4+Pj4NCj4+Pj4N Cj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ Pj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4+Pj4gc2lwY29yZUBpZXRmLm9yZw0KPj4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCj4+Pj4NCj4+Pg0KPj4N Cj4NCg0K From nobody Thu Aug 25 23:58:05 2016 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 B5713128E19 for ; Thu, 25 Aug 2016 23:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfwUlN06q0Rb for ; Thu, 25 Aug 2016 23:58:02 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D108127077 for ; Thu, 25 Aug 2016 23:58:02 -0700 (PDT) X-AuditID: c1b4fb30-ea88e980000009f9-cd-57bfe87884e9 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by (Symantec Mail Security) with SMTP id DA.58.02553.878EFB75; Fri, 26 Aug 2016 08:58:00 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.41]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0301.000; Fri, 26 Aug 2016 08:57:56 +0200 From: Ivo Sedlacek To: Randall Gellens , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Draft new: draft-holmberg-sipcore-content-id-00 Thread-Index: AQHR98S6mkJf3bvA+kChF4NYCmV/nKBLrLyA///rB4CAAW/xEIANJGiAgACn8FA= Date: Fri, 26 Aug 2016 06:57:55 +0000 Message-ID: <39B5E4D390E9BD4890E2B3107900610116517CAF@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164EB950@ESESSMB301.ericsson.se> In-Reply-To: Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM2J7lG7Fi/3hBteeKVms2HCA1eL78y5G i68/NrE5MHv8ff+ByWPJkp9MHlvvPGYJYI7isklJzcksSy3St0vgytj+/ihbwRTuiqYtSxgb GFs4uxg5OCQETCTuXPXqYuTiEBJYzyjx/vRhti5GTiBnMaPEn132IDabgJ7ExC1HWEFsEYE6 id1ruhlBbGEBN4kL66YwgswREXCXeLygCsL0k/h8IQmkgkVAVeLkx1nsIDavgK/E8Q8HWCFW 9TNJvH1xgw2knhPohHtrFEFqGAVkJa7+6QWbziwgLnHryXwmEFtCQEBiyZ7zzBC2qMTLx/9Y IWwliR8bLrFA1OtILNj9iQ3C1pZYtvA1M8ReQYmTM5+wTGAUmYVk7CwkLbOQtMxC0rKAkWUV o2hxanFSbrqRkV5qUWZycXF+nl5easkmRmB0HNzy22AH48vnjocYBTgYlXh4FYz2hwuxJpYV V+YeYpTgYFYS4T31DCjEm5JYWZValB9fVJqTWnyIUZqDRUmc1/+lYriQQHpiSWp2ampBahFM lomDU6qBcZKXaZ6i6sMkdqmn63Ybcz4VyC2X1hNU3um66MO5q6d/bktvm/Xw6NLYv1tXqb5o nnf29OP/E6IjPNif3rvfEhIlVtPQsXtKj2mz8s7/MZtOTzVbW1Sq2fOipXjWrY3+4qE33LeH HnY/VPrEXndX3QTmwl/vl4p5qM8X1HpuEbF+aXZiPKvgOiWW4oxEQy3mouJEAISS5EmKAgAA Archived-At: Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-content-id-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 06:58:04 -0000 Hello, > When defining MIME types, it's usual to specify the content transfer enco= ding that is used. So, it seems useful to permit Content-Transfer-Encoding= as a SIP header field. Information in registration template state what sort of data a MIME type ca= n consist of since some transports impose restrictions on the type of data = they can carry. See rfc6838 section 4.8.=20 However, SIP does not impose any such restriction. Can you please give a use case where a SIP Content-Transfer-Encoding header= field would be needed? Thank you. Kind regards Ivo -----Original Message----- From: Randall Gellens [mailto:rg+ietf@randy.pensive.org]=20 Sent: Friday, August 26, 2016 12:18 AM To: Ivo Sedlacek; Paul Kyzivat; sipcore@ietf.org Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-content-id-00 At 11:37 AM +0000 8/17/16, Ivo Sedlacek wrote: > > - content-transfer-encoding > > Is this really needed? SIP provides binary transport. When defining MIME types, it's usual to specify the content transfer encodi= ng that is used. So, it seems useful to permit Content-Transfer-Encoding a= s a SIP header field. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The trouble with doin= g anything right the first time is that nobody appreciates how difficult it= was. From nobody Fri Aug 26 00:38:35 2016 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 8268A12D0A8 for ; Fri, 26 Aug 2016 00:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YF_5Sc3eJJh0 for ; Fri, 26 Aug 2016 00:38:32 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E49D7127077 for ; Fri, 26 Aug 2016 00:38:31 -0700 (PDT) X-AuditID: c1b4fb30-abfff700000009f9-13-57bff1f51c10 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by (Symantec Mail Security) with SMTP id FF.80.02553.5F1FFB75; Fri, 26 Aug 2016 09:38:29 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0301.000; Fri, 26 Aug 2016 09:38:29 +0200 From: Christer Holmberg To: "Dale R. Worley" , "sipcore@ietf.org" Thread-Topic: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? Thread-Index: AQHR/yhMCnVeSlQa/k+Sxwkc4yebnqBa7VsA Date: Fri, 26 Aug 2016 07:38:28 +0000 Message-ID: References: <5d462933-e3c0-b3a3-958d-5c9d1e86d854@alum.mit.edu> <878tvk77k8.fsf@hobgoblin.ariadne.com> In-Reply-To: <878tvk77k8.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2K7iu7Xj/vDDZYfs7D4+mMTm8XLE2UO TB6T939l9liy5CdTAFMUl01Kak5mWWqRvl0CV8aO40/ZClaxVSw4/YC9gbGBtYuRk0NCwERi Xus2li5GLg4hgfWMEqc274FyljBK/N34jKmLkYODTcBCovufNkiDiECQxKbOFcwgtrBAosSd lz9ZIeJJEnM27WGGsI0kvr65zQJiswioSpy7OQ3M5hWwkuh/d5ERxBYSyJD4/u0dO4jNKWAs 8fDLT7A4o4CYxPdTa5hAbGYBcYlbT+YzQRwqILFkz3lmCFtU4uXjf2B7RQX0JL5/nQ0VV5T4 +GofI0SvgcT7c/OZIWxrie47f1ggbG2JZQtfM0PcIyhxcuYTlgmMYrOQrJuFpH0WkvZZSNpn IWlfwMi6ilG0OLU4KTfdyEgvtSgzubg4P08vL7VkEyMwqg5u+W2wg/Hlc8dDjAIcjEo8vApG +8OFWBPLiitzDzFKcDArifCeegYU4k1JrKxKLcqPLyrNSS0+xCjNwaIkzuv/UjFcSCA9sSQ1 OzW1ILUIJsvEwSnVwOh42JUhcO7VjR0BR3Vu1ryMyi3cUxK/X1rglYeK5To9bXFTLeejwgfe ik+x1dy19zTX5tZsoas1Jj323wwOnmQPONghs29t7K0pjl/mS1owH/N6fiPX44xQcoNy7cOf tTuMFfcm73A33GvExf76zUOe4s4DMjI/Xq2/WNeQNVevS2NG0ZLMmUosxRmJhlrMRcWJAI3r QLKmAgAA Archived-At: Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 07:38:33 -0000 Hi, =8A >Note: Suppose we define the ACK info package to *only* acknowledge >receiving and processing the request for resend, but allow the caller to >attach the Additional Data to any request it chooses. E.g., the caller >could send an UPDATE carrying the Additional Data followed by an INFO >informing the callee that it had resent the data. Then the Additional >Data would not be *part of* the ACK info package data and the RFC 7852 >method would not contravene RFC 6086 -- even if the caller *just >happened* to always attach the Additional Data to the INFO for the ACK >package. UPDATE is meant to update information associated with the SIP session, not to transport application data. Nobody in ECRIT has afaik objected to the usage of INFO as such. Regards, Christer From nobody Fri Aug 26 09:02:11 2016 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 5A96E12D126 for ; Fri, 26 Aug 2016 09:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Q6BLXONwjsq for ; Fri, 26 Aug 2016 09:02:08 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2AD412D0F6 for ; Fri, 26 Aug 2016 09:02:08 -0700 (PDT) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-08v.sys.comcast.net with SMTP id dJZgbeDs384vjdJa4brOfa; Fri, 26 Aug 2016 16:02:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-16v.sys.comcast.net with SMTP id dJa3bX5qLqv8jdJa3bcSdg; Fri, 26 Aug 2016 16:02:08 +0000 To: Randall Gellens , Ivo Sedlacek , "sipcore@ietf.org" References: <39B5E4D390E9BD4890E2B31079006101164EB950@ESESSMB301.ericsson.se> From: Paul Kyzivat Message-ID: Date: Fri, 26 Aug 2016 12:02:02 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfPEI9jj8O+LaUPHOOMZTeTeBMv3AijGwVsQwJ7QgOWzA1IgTPKY9/BNwH41dm6iO+9lWTiapxauTrnyfmRQlyYGTMKRmZp1yRdiO4OpIXt2A5i4RtOwG 9gVQOGgACmKlNKjf+O+z6JvSnIPmOUevRZzsZZrXvjKF7jidBILjooxx38JDAUKVQUVjnqkK6Md3FdGII2MIgtyEVnqTCB7yUWUtATbmxL0LECkLNcsPdgdB TRFMDhbMYyBwHOhEYGHEdD0+zLiRFuBkxFoyFtcFvJM= Archived-At: Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-content-id-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 16:02:10 -0000 On 8/25/16 6:18 PM, Randall Gellens wrote: > At 11:37 AM +0000 8/17/16, Ivo Sedlacek wrote: > >> > - content-transfer-encoding >> >> Is this really needed? SIP provides binary transport. > > When defining MIME types, it's usual to specify the content transfer > encoding that is used. So, it seems useful to permit > Content-Transfer-Encoding as a SIP header field. > Adding content-transfer-encoding to sip could cause backward compatibility problems. For instance, if I overrode the content-transfer-encoding for and INVITE with SDP, would the recipient be expected to be capable of decoding it? While it could have value in some cases, if we were to do it we would have to add some rules for backward compatibility. Thanks, Paul From nobody Fri Aug 26 09:09:25 2016 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 02C3612D11B for ; Fri, 26 Aug 2016 09:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9of4sfWnNXz for ; Fri, 26 Aug 2016 09:09:24 -0700 (PDT) Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54A4C12D0F6 for ; Fri, 26 Aug 2016 09:09:24 -0700 (PDT) Received: from resomta-po-12v.sys.comcast.net ([96.114.154.236]) by resqmta-po-04v.sys.comcast.net with SMTP id dJgpbmTgkGkXBdJh5bHMAI; Fri, 26 Aug 2016 16:09:23 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-12v.sys.comcast.net with SMTP id dJh4b7Tx8RVWTdJh5beHeY; Fri, 26 Aug 2016 16:09:23 +0000 To: Christer Holmberg , "sipcore@ietf.org" References: <76CCBFA5-8D53-4B1E-A495-4A18AB081384@brianrosen.net> <05240A95-8319-4555-8B46-FA18B6C27883@brianrosen.net> <5d462933-e3c0-b3a3-958d-5c9d1e86d854@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC60A10@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC61D10@ESESSMB209.ericsson.se> <1c9b4538-720c-0126-7a82-d63edfc40caf@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC61E7C@ESESSMB209.ericsson.se> <81e44324-ae48-c2a4-c8e2-5f349da7d4d8@alum.mit.edu> From: Paul Kyzivat Message-ID: Date: Fri, 26 Aug 2016 12:09:18 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=euc-kr; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfAbjAy54lIQTLl/JGw81RUB63ae727sjSonqg34yQLMEmOppQCSw4S0npBdqIca6LAc0SNi79pm4u0ExOmkoOAwKDlMeD01cK5K9ewMykxysHRRF7vJ3 93ToV47np7L7JamHG0AsFpRcrgqw73+soznUKVRlGKpOnuy//HvieMIFhfg28p1rSegpVqgVZPw4g5OsVfHPcconjOCGTbyNuLXGOz36J/+SWoAL1MwW8Fdv Archived-At: Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 16:09:25 -0000 On 8/26/16 2:56 AM, Christer Holmberg wrote: [snip] >> But this is dancing around stuff that is defined by some means other >> than method. If you say "you want to send it using INFO" then I would >> expect the content to be contained within the info package body. OTOH, >> if you just want to send X in a lot of circumstances, then you might >> choose a different method (such as call-info) that isn't >> method-specific. If you do that, then it can go anywhere a call-info can >> go, which happens to include INFO. > > You seem to claim that, since you can carry content X in INVITE using > Call-Info (or whatever mechanism) you can also carry content X in INFO > using the same mechanism. > > I think thats where we have different opinions, because I claim that, > when you carry content X in INFO, you have to use an Info Package - even > if you carry content X in INVITE using Call-Info. Yes, that is the exact question that we have come to sipcore to ask. And you have stated my position accurately. And lets step back a bit from call-info. I assert the same is true for something else. E.g., if I for some reason had need to send a Geolocation header field with a cid url. IMO it is exactly the same situation as call-info. (This is hypothetical. I don't have a particular case in mind where I might want to send a Geolocation and an INFO at the same time.) Thanks, Paul From nobody Fri Aug 26 13:41:01 2016 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 4750312B047 for ; Fri, 26 Aug 2016 13:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVlbCdJvL-vm for ; Fri, 26 Aug 2016 13:40:58 -0700 (PDT) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87D2A12D5FF for ; Fri, 26 Aug 2016 13:40:48 -0700 (PDT) Received: from resomta-ch2-04v.sys.comcast.net ([69.252.207.100]) by resqmta-ch2-03v.sys.comcast.net with SMTP id dNuVbohN98GkCdNvjbsjUP; Fri, 26 Aug 2016 20:40:47 +0000 Received: from hobgoblin.ariadne.com ([73.100.16.189]) by resomta-ch2-04v.sys.comcast.net with SMTP id dNvibpiczzKuxdNvjbOCpX; Fri, 26 Aug 2016 20:40:47 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u7QKekb8021991; Fri, 26 Aug 2016 16:40:46 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u7QKejX6021987; Fri, 26 Aug 2016 16:40:45 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC61D10@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 26 Aug 2016 16:40:45 -0400 Message-ID: <87shtr5kmq.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfEGs4V8lHHowRvGpqDycDgGVnxEeCojFxL54dr0aBDbFqcebKA9YIsXAANfQbclbI1w7sc0MvAmFB1vRfWjIczZj6xukM1yhkWrwZb+xJF/4+4x+qjwK IgJ2b69jmdWAZs652SmzAhIqHNXcHRqFCmleSAYSvNvkug0Dp+j5RwBDtrQLN3gPJph9zSCvfQjEX4RXcX+TViKcvFJRwFJtOszgM5JzmwYur/kDBEzIcbWC 6ev7WYxl151oLa0uyIF71w== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 20:40:59 -0000 Christer Holmberg writes: > I am asking: assuming you have determined (based on whatever criteria) > that the INFO message is the most appropriate mechanism, when are you > required to use Info Package? If you have decided to use an INFO request, then the INFO request uses an Info Package when (and only when) an Info-Package header is present in the request. That's a basic rule of RFC 6086. There doesn't seem to be any normative prescription of when you are required to use Info Package within INFO, but it seems like a good idea to use an Info Package for any newly designed uses of INFO. Dale From nobody Fri Aug 26 13:44:15 2016 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 855E312D82A for ; Fri, 26 Aug 2016 13:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQSgrftgxsLq for ; Fri, 26 Aug 2016 13:44:13 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCF4E12B047 for ; Fri, 26 Aug 2016 13:44:12 -0700 (PDT) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-05v.sys.comcast.net with SMTP id dNwabuu0d2FGMdNz2by9tN; Fri, 26 Aug 2016 20:44:12 +0000 Received: from hobgoblin.ariadne.com ([73.100.16.189]) by resomta-ch2-12v.sys.comcast.net with SMTP id dNz1bimYg3bNxdNz1bEAxy; Fri, 26 Aug 2016 20:44:12 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u7QKiAsl022322 for ; Fri, 26 Aug 2016 16:44:10 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u7QKiAPn022319; Fri, 26 Aug 2016 16:44:10 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org In-Reply-To: (br@salsgiver.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 26 Aug 2016 16:44:10 -0400 Message-ID: <87poov5kh1.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfOm2VIAw2tjl3SN/Ela9mu3wrcegQG2+UkxF2CamQO4KZqxZlRWq+0E49LyQm6wNBGK+yycl5uK6RLAwnXYMSml6c1DtxQI09HW33FyN6QobN/9sGcKp KkQz7aj7jStXaXekYYXtZlrnvgQ27Dfx4uE2iWz9i5ZG2yQmKl56b7fE6qKLZMpU8P19b+hX3O83dw== Archived-At: Subject: [sipcore] A bug in draft-ietf-ecrit-ecall-11 (was: Re: Can an INFO contain a body related to, but not part of the INFO package?) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 20:44:13 -0000 RFC 6086 section 4.2.1 says: The INFO request MUST NOT contain a Recv-Info header field. A UA can only indicate a set of Info Packages for which it is willing to receive INFO requests by using the SIP methods (and their responses) listed in Section 5. But draft-ietf-ecrit-ecall-11 has two places in section 11 where example INFO requests contain a Recv-Info header: INFO sip:+13145551111@example.com SIP/2.0 To: ;tag=9fxced76sl From: Exemplar PSAP Call-ID: 3848276298220188511@atlanta.example.com Call-Info: cid:3456789012@atlanta.example.com; purpose=emergencyCallData.eCall.control; Accept: application/sdp, application/pidf+xml, application/emergencyCallData.eCall.control+xml, application/emergencyCallData.eCall.MSD+per CSeq: 41862 INFO Recv-Info: emergencyCallData.eCall.MSD ... INFO urn:service:sos.ecall.automatic SIP/2.0 To: urn:service:sos.ecall.automatic From: ;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com Call-Info: cid:4567890123@atlanta.example.com; purpose=emergencyCallData.eCall.MSD; Accept: application/sdp, application/pidf+xml, application/emergencyCallData.eCall.control+xml CSeq: 51862 INFO Recv-Info: emergencyCallData.eCall.MSD ... Dale From nobody Fri Aug 26 13:45:09 2016 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 47A7812D833 for ; Fri, 26 Aug 2016 13:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V_41l3j0EG_A for ; Fri, 26 Aug 2016 13:45:06 -0700 (PDT) Received: from email.salsgiver.com (email.salsgiver.com [206.67.234.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC08012D82A for ; Fri, 26 Aug 2016 13:45:05 -0700 (PDT) Received: from [10.33.192.33] ([156.154.81.54]) (authenticated bits=0) by email.salsgiver.com (8.15.2/8.14.3) with ESMTPA id u7QKib6C034026; Fri, 26 Aug 2016 16:44:38 -0400 (EDT) (envelope-from br@salsgiver.com) X-Authentication-Warning: email.salsgiver.com: Host [156.154.81.54] claimed to be [10.33.192.33] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: <87shtr5kmq.fsf@hobgoblin.ariadne.com> Date: Fri, 26 Aug 2016 16:44:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0AB492FC-F521-40A2-BC74-7098D3427DF8@salsgiver.com> References: <87shtr5kmq.fsf@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 20:45:08 -0000 Christer seems to think that if we send a body part in an INFO message = that isn=E2=80=99t defined in an INFO package, that it constitutes a = pre-6086 INFO use, which is not allowed. Here, we=E2=80=99re using = Call-Info to point to, and label the body part, recognizing that there = is another body part that IS part of the INFO package in the message. The fact that the Call-Info body part is in the INFO message doesn=E2=80=99= t make it a pre-6086 use of INFO. It=E2=80=99s just introduced by = Call-Info rather than INFO. Brian > On Aug 26, 2016, at 4:40 PM, Dale R. Worley = wrote: >=20 > Christer Holmberg writes: >> I am asking: assuming you have determined (based on whatever = criteria) >> that the INFO message is the most appropriate mechanism, when are you >> required to use Info Package? >=20 > If you have decided to use an INFO request, then the INFO request uses > an Info Package when (and only when) an Info-Package header is present > in the request. That's a basic rule of RFC 6086. There doesn't seem = to > be any normative prescription of when you are required to use Info > Package within INFO, but it seems like a good idea to use an Info > Package for any newly designed uses of INFO. >=20 > Dale >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Fri Aug 26 13:56:54 2016 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 0E68E12D816 for ; Fri, 26 Aug 2016 13:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JdJPS4MCwIU for ; Fri, 26 Aug 2016 13:56:51 -0700 (PDT) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3892C12D7B5 for ; Fri, 26 Aug 2016 13:56:51 -0700 (PDT) Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-04v.sys.comcast.net with SMTP id dOBEbG9WW8PeadOBGbN9cX; Fri, 26 Aug 2016 20:56:50 +0000 Received: from hobgoblin.ariadne.com ([73.100.16.189]) by resomta-ch2-05v.sys.comcast.net with SMTP id dOBFba9Vct4EpdOBFbo7Q4; Fri, 26 Aug 2016 20:56:50 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u7QKumB9023629; Fri, 26 Aug 2016 16:56:48 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u7QKum43023626; Fri, 26 Aug 2016 16:56:48 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Paul Kyzivat In-Reply-To: (pkyzivat@alum.mit.edu) Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 26 Aug 2016 16:56:48 -0400 Message-ID: <87lgzj5jvz.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfGH8YE2EXJUb6SaEsChpYFHflsSVBgxaD5c512mDy2wX9fOBwx9FwcrgbsKeiDbjmpleTJTR6v44xmP5ra0P/ICrJc5+PYbAKwoi0vNmUl7zis1++9lc PQDXiyWrpqkGg8CLE0y1SweMEWyrhtC1g90FA0JzRLiT3ssSyBj9pong+Gx1zeFeUbnfacvcTRg/UUg+5gwEVl0uJaNthAgnqZoSB2XwcKI7V7bTtzDL0IbM vb6LbVcagvUS+q55m+Xnwgg+7yIh9tVsiQR10S1IPrCnPpWFMzvnGDouJ/0keTGO Archived-At: Cc: rg+ietf@randy.pensive.org, sipcore@ietf.org, ivo.sedlacek@ericsson.com Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-content-id-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 20:56:52 -0000 Paul Kyzivat writes: > On 8/25/16 6:18 PM, Randall Gellens wrote: >> At 11:37 AM +0000 8/17/16, Ivo Sedlacek wrote: >> >>> > - content-transfer-encoding >>> >>> Is this really needed? SIP provides binary transport. >> >> When defining MIME types, it's usual to specify the content transfer >> encoding that is used. So, it seems useful to permit >> Content-Transfer-Encoding as a SIP header field. > > Adding content-transfer-encoding to sip could cause backward > compatibility problems. For instance, if I overrode the > content-transfer-encoding for and INVITE with SDP, would the recipient > be expected to be capable of decoding it? > > While it could have value in some cases, if we were to do it we would > have to add some rules for backward compatibility. Well, there are three examples of "Content-Transfer-Encoding: base64" in section 23 of RFC 3261. What we're going to have to do is what people do in practice, only use the Content-Transfer-Encoding header in the message if the body is one of those media types that is commonly transported using a content-transfer-encoding. In practice, that is application/pkcs7-signature and application/pkcs7-mime. Dale From nobody Fri Aug 26 14:06:11 2016 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 56C0B12D112 for ; Fri, 26 Aug 2016 14:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cUOCHt9jwPP for ; Fri, 26 Aug 2016 14:06:09 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88A6212D81E for ; Fri, 26 Aug 2016 14:06:07 -0700 (PDT) X-AuditID: c1b4fb3a-c7bff700000009bd-5c-57c0af3ba573 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by (Symantec Mail Security) with SMTP id 72.BB.02493.B3FA0C75; Fri, 26 Aug 2016 23:06:05 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0301.000; Fri, 26 Aug 2016 23:06:03 +0200 From: Christer Holmberg To: Brian Rosen , "Dale R. Worley" Thread-Topic: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? Thread-Index: AQHR/9oeCnVeSlQa/k+Sxwkc4yebnqBblBaAgAAm3OA= Date: Fri, 26 Aug 2016 21:06:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC69809@ESESSMB209.ericsson.se> References: <87shtr5kmq.fsf@hobgoblin.ariadne.com> <0AB492FC-F521-40A2-BC74-7098D3427DF8@salsgiver.com> In-Reply-To: <0AB492FC-F521-40A2-BC74-7098D3427DF8@salsgiver.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGbHdT9d2/YFwgzX/rSymHdvAbvH1xyY2 i5cnyhyYPSbv/8rssWTJTyaPRYd+sAYwR3HZpKTmZJalFunbJXBlfHh4k6ngj2DFxvWtjA2M BwS7GDk5JARMJN7Mv8DWxcjFISSwnlGipfcxC4SzhFHi5btTjF2MHBxsAhYS3f+0QRpEBDwl Nq9uYAexmQU0JR7t3MsEYgsLJEpM6JvLDFGTJDFn0x4o20qiZcJEsBoWAVWJP2+es4DYvAK+ Eqv6/zKC2EICmRJzD38Bi3MKOEo83jYXLM4oICbx/dQaJohd4hK3nsxngjhaQGLJnvPMELao xMvH/1ghbCWJxiVPWEFOBrlt/S59iFZFiSndD9kh1gpKnJz5hGUCo+gsJFNnIXTMQtIxC0nH AkaWVYyixanFxbnpRkZ6qUWZycXF+Xl6eaklmxiBUXNwy2+rHYwHnzseYhTgYFTi4V3QfCBc iDWxrLgy9xCjBAezkgiv1RqgEG9KYmVValF+fFFpTmrxIUZpDhYlcV7/l4rhQgLpiSWp2amp BalFMFkmDk6pBsZm5w2amw5vXnklTi7S7Gs7T9vTK3uKgwsX2Fn+/Cr140GkYLejmt+9p/q/ 3q1du27ajKQJbTJc2Xs3df5RD+f4s/fbvAxn+U8TfBkfvTAt75lw1V5dy1lermjVr/kNtTWO 7S8yj5pmVk2QP2b3obvH8tpM/lCLj6eOr+I5mOlwhn1Zs6FpcpkSS3FGoqEWc1FxIgA6mrvj lgIAAA== Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 21:06:10 -0000 SGksDQoNCj5DaHJpc3RlciBzZWVtcyB0byB0aGluayB0aGF0IGlmIHdlIHNlbmQgYSBib2R5IHBh cnQgaW4gYW4gSU5GTyBtZXNzYWdlIHRoYXQgaXNu4oCZdCBkZWZpbmVkIGluIGFuIElORk8gcGFj a2FnZSwgdGhhdCBpdCBjb25zdGl0dXRlcyBhIHByZS02MDg2IElORk8gdXNlLCB3aGljaCBpcyBu b3QgYWxsb3dlZC4gID5IZXJlLCB3ZeKAmXJlIHVzaW5nIENhbGwtSW5mbyB0byBwb2ludCB0bywg YW5kIGxhYmVsIHRoZSBib2R5IHBhcnQsIHJlY29nbml6aW5nIHRoYXQgdGhlcmUgaXMgYW5vdGhl ciBib2R5IHBhcnQgdGhhdCBJUyBwYXJ0IG9mIHRoZSBJTkZPIHBhY2thZ2UgaW4gdGhlIG1lc3Nh Z2UuDQo+DQo+VGhlIGZhY3QgdGhhdCB0aGUgQ2FsbC1JbmZvIGJvZHkgcGFydCBpcyBpbiB0aGUg SU5GTyBtZXNzYWdlIGRvZXNu4oCZdCBtYWtlIGl0IGEgcHJlLTYwODYgdXNlIG9mIElORk8uICBJ dOKAmXMganVzdCBpbnRyb2R1Y2VkIGJ5IENhbGwtSW5mbyByYXRoZXIgdGhhbiBJTkZPLg0KDQpJ IGFtIHNheWluZyB0aGF0Og0KDQoxKSB0aGUgZGF0YSB5b3Ugc2VuZCBpcyBhc3NvY2lhdGVkIHdp dGggdGhlIGVjYWxsIGFwcGxpY2F0aW9uOyBhbmQNCjIpIHRoYXQgdGhlIGRhdGEgaXMgTk9UIGFz c29jaWF0ZWQgd2l0aCBhIHByZS02MDg2IHVzZSBvZiBJTkZPIC0gaXQgaXMgYSBuZXcgSU5GTyB1 c2FnZQ0KDQouLi5hbmQgdGhlcmVmb3JlIHlvdSBoYXZlIHRvIHVzZSBhbiBJbmZvIFBhY2thZ2Uu DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KPiBPbiBBdWcgMjYsIDIwMTYsIGF0IDQ6NDAg UE0sIERhbGUgUi4gV29ybGV5IDx3b3JsZXlAYXJpYWRuZS5jb20+IHdyb3RlOg0KPiANCj4gQ2hy aXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gd3JpdGVzOg0K Pj4gSSBhbSBhc2tpbmc6IGFzc3VtaW5nIHlvdSBoYXZlIGRldGVybWluZWQgKGJhc2VkIG9uIHdo YXRldmVyIA0KPj4gY3JpdGVyaWEpIHRoYXQgdGhlIElORk8gbWVzc2FnZSBpcyB0aGUgbW9zdCBh cHByb3ByaWF0ZSBtZWNoYW5pc20sIA0KPj4gd2hlbiBhcmUgeW91IHJlcXVpcmVkIHRvIHVzZSBJ bmZvIFBhY2thZ2U/DQo+IA0KPiBJZiB5b3UgaGF2ZSBkZWNpZGVkIHRvIHVzZSBhbiBJTkZPIHJl cXVlc3QsIHRoZW4gdGhlIElORk8gcmVxdWVzdCB1c2VzIA0KPiBhbiBJbmZvIFBhY2thZ2Ugd2hl biAoYW5kIG9ubHkgd2hlbikgYW4gSW5mby1QYWNrYWdlIGhlYWRlciBpcyBwcmVzZW50IA0KPiBp biB0aGUgcmVxdWVzdC4gIFRoYXQncyBhIGJhc2ljIHJ1bGUgb2YgUkZDIDYwODYuICBUaGVyZSBk b2Vzbid0IHNlZW0gDQo+IHRvIGJlIGFueSBub3JtYXRpdmUgcHJlc2NyaXB0aW9uIG9mIHdoZW4g eW91IGFyZSByZXF1aXJlZCB0byB1c2UgSW5mbyANCj4gUGFja2FnZSB3aXRoaW4gSU5GTywgYnV0 IGl0IHNlZW1zIGxpa2UgYSBnb29kIGlkZWEgdG8gdXNlIGFuIEluZm8gDQo+IFBhY2thZ2UgZm9y IGFueSBuZXdseSBkZXNpZ25lZCB1c2VzIG9mIElORk8uDQo+IA0KPiBEYWxlDQo+IA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzaXBjb3JlIG1h aWxpbmcgbGlzdA0KPiBzaXBjb3JlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KDQo= From nobody Fri Aug 26 14:09:53 2016 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 EF32912D837 for ; Fri, 26 Aug 2016 14:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZ2HSBNYk-Rx for ; Fri, 26 Aug 2016 14:09:51 -0700 (PDT) Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55AB112D835 for ; Fri, 26 Aug 2016 14:09:51 -0700 (PDT) Received: from resomta-po-19v.sys.comcast.net ([96.114.154.243]) by resqmta-po-01v.sys.comcast.net with SMTP id dONibAN5IucHZdONqb60He; Fri, 26 Aug 2016 21:09:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-19v.sys.comcast.net with SMTP id dONpboHsFa4NPdONqbPji3; Fri, 26 Aug 2016 21:09:50 +0000 To: "Dale R. Worley" References: <87lgzj5jvz.fsf@hobgoblin.ariadne.com> From: Paul Kyzivat Message-ID: <8892acb9-ae22-b652-fb59-24aa6d91ed52@alum.mit.edu> Date: Fri, 26 Aug 2016 17:09:45 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <87lgzj5jvz.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfIvsdyR70WC4vLoshNuTlmyx5GZ5vvytUabS4tL53/KQ9SpOnL3PSpNIOrjJS4+ga9D1SYFRl+j2pP0f4LE0zKoLChvSN/fRbfuKToIz2H1fI+crLbGw VKWXWIfnSi+PM/2QcwpgVlwTOlbr1s5hMn4y5AH5xtrXemTGK++7U71AMqhUqj34z9gvZDTtfw5LyFfud8zGp6GkD4pA2HN4JqCnGAonuniQoNK7GdC+S/Qt iRIKLsQj/lr2ef10b54MC+ws4q7hYZiicUtknNtdowyFPjsih7FETvdGiGZuvfHj Archived-At: Cc: rg+ietf@randy.pensive.org, sipcore@ietf.org, ivo.sedlacek@ericsson.com Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-content-id-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 21:09:52 -0000 On 8/26/16 4:56 PM, Dale R. Worley wrote: > Paul Kyzivat writes: >> On 8/25/16 6:18 PM, Randall Gellens wrote: >>> At 11:37 AM +0000 8/17/16, Ivo Sedlacek wrote: >>> >>>> > - content-transfer-encoding >>>> >>>> Is this really needed? SIP provides binary transport. >>> >>> When defining MIME types, it's usual to specify the content transfer >>> encoding that is used. So, it seems useful to permit >>> Content-Transfer-Encoding as a SIP header field. >> >> Adding content-transfer-encoding to sip could cause backward >> compatibility problems. For instance, if I overrode the >> content-transfer-encoding for and INVITE with SDP, would the recipient >> be expected to be capable of decoding it? >> >> While it could have value in some cases, if we were to do it we would >> have to add some rules for backward compatibility. > > Well, there are three examples of "Content-Transfer-Encoding: base64" in > section 23 of RFC 3261. Yes, but those are all contained in subordinate body parts of a top level multipart body. We are talking about defining content-transfer-encoding as a valid top-level header field in sip. > What we're going to have to do is what people do in practice, only use > the Content-Transfer-Encoding header in the message if the body is one > of those media types that is commonly transported using a > content-transfer-encoding. In practice, that is > application/pkcs7-signature and application/pkcs7-mime. In practice that would be the sensible thing to do. But I hate to leave it to common sense. I would rather have the valid usage well defined. For the moment this is simply a hypothetical discussion - an extrapolation beyond the proposal to define content-id as a sip header field. Thanks, Paul From nobody Fri Aug 26 14:28:45 2016 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 A15B212D133 for ; Fri, 26 Aug 2016 14:28:42 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8zduECynAtI for ; Fri, 26 Aug 2016 14:28:41 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id AEFA512D112 for ; Fri, 26 Aug 2016 14:28:39 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 26 Aug 2016 14:28:38 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <8892acb9-ae22-b652-fb59-24aa6d91ed52@alum.mit.edu> References: <87lgzj5jvz.fsf@hobgoblin.ariadne.com> <8892acb9-ae22-b652-fb59-24aa6d91ed52@alum.mit.edu> X-Mailer: Eudora for Mac OS X Date: Fri, 26 Aug 2016 14:28:36 -0700 To: Paul Kyzivat , "Dale R. Worley" From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Cc: rg+ietf@randy.pensive.org, sipcore@ietf.org, ivo.sedlacek@ericsson.com Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-content-id-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 21:28:42 -0000 At 5:09 PM -0400 8/26/16, Paul Kyzivat wrote: > For the moment this is simply a hypothetical discussion - an > extrapolation beyond the proposal to define content-id as a sip > header field. I was thinking it might be useful, but in view of the extra complexity, I don't think it should be addressed in the Content-ID draft. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- There is so much to be said in favor of modern journalism. By giving us the opinions of the uneducated, it keeps us in touch with the ignorance of the community. --Oscar Wilde From nobody Fri Aug 26 14:30:44 2016 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 CA48112D112 for ; Fri, 26 Aug 2016 14:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wssG1knl0Ldg for ; Fri, 26 Aug 2016 14:30:42 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CA5512D5BF for ; Fri, 26 Aug 2016 14:30:42 -0700 (PDT) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-01v.sys.comcast.net with SMTP id dOhibUnl9TaLwdOi1b8Zyv; Fri, 26 Aug 2016 21:30:41 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-12v.sys.comcast.net with SMTP id dOi0biyE63bNxdOi1bEHaM; Fri, 26 Aug 2016 21:30:41 +0000 To: sipcore@ietf.org References: <87shtr5kmq.fsf@hobgoblin.ariadne.com> <0AB492FC-F521-40A2-BC74-7098D3427DF8@salsgiver.com> <7594FB04B1934943A5C02806D1A2204B4BC69809@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <5e29dcc7-f8ec-03b0-2ded-dcb8a7b2a388@alum.mit.edu> Date: Fri, 26 Aug 2016 17:30:40 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC69809@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfBauzox4ZKugBemUEYTDa2j4nmPmv5fFtrjruoajBH6e9lIUuWJGiwmFkt/SaAYDu49QjKXQB8p18Ny5vN+VqJLGeplnJ3DyhDVoSXlePixJlSaX8NqJ YtMjCS/5Co7G0ZKABPjMfIrPgamaCh6OyyRaS/kzZMgoQA6wpqUpYwREhESRXMPh34bi4HRSTSuyGw== Archived-At: Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 21:30:44 -0000 On 8/26/16 5:06 PM, Christer Holmberg wrote: > Hi, > >> Christer seems to think that if we send a body part in an INFO message that isn’t defined in an INFO package, that it constitutes a pre-6086 INFO use, which is not allowed. >Here, we’re using Call-Info to point to, and label the body part, recognizing that there is another body part that IS part of the INFO package in the message. >> >> The fact that the Call-Info body part is in the INFO message doesn’t make it a pre-6086 use of INFO. It’s just introduced by Call-Info rather than INFO. > > I am saying that: > > 1) the data you send is associated with the ecall application; and > 2) that the data is NOT associated with a pre-6086 use of INFO - it is a new INFO usage > > ...and therefore you have to use an Info Package. And I"m saying: - if you have an application that can get information using a variety of sip mechanisms (e.g., from call-info in an invite, and from an info package body) - then more than one mechanism is applicable to a single message (e.g. a call-info in an INFO) then you can use whatever combination makes sense. Thanks, Paul > Regards, > > Christer > > >> On Aug 26, 2016, at 4:40 PM, Dale R. Worley wrote: >> >> Christer Holmberg writes: >>> I am asking: assuming you have determined (based on whatever >>> criteria) that the INFO message is the most appropriate mechanism, >>> when are you required to use Info Package? >> >> If you have decided to use an INFO request, then the INFO request uses >> an Info Package when (and only when) an Info-Package header is present >> in the request. That's a basic rule of RFC 6086. There doesn't seem >> to be any normative prescription of when you are required to use Info >> Package within INFO, but it seems like a good idea to use an Info >> Package for any newly designed uses of INFO. >> >> Dale >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Fri Aug 26 14:32:17 2016 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 CAE5A12D840 for ; Fri, 26 Aug 2016 14:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBLlBn7X09R6 for ; Fri, 26 Aug 2016 14:32:15 -0700 (PDT) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1603612D81A for ; Fri, 26 Aug 2016 14:32:14 -0700 (PDT) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-09v.sys.comcast.net with SMTP id dOiCbJSy41XXBdOjWbPHhK; Fri, 26 Aug 2016 21:32:14 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-10v.sys.comcast.net with SMTP id dOjVbOgTiqnakdOjVb0z8Y; Fri, 26 Aug 2016 21:32:14 +0000 To: Randall Gellens , "Dale R. Worley" References: <87lgzj5jvz.fsf@hobgoblin.ariadne.com> <8892acb9-ae22-b652-fb59-24aa6d91ed52@alum.mit.edu> From: Paul Kyzivat Message-ID: <8e26b467-d7f7-29ce-e8c6-e70e136fa650@alum.mit.edu> Date: Fri, 26 Aug 2016 17:32:13 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfNmjGvJNFhkHNuPhGXekdkPZRq5qmeLkVnbHp51nbSGoUQFREeQMTtwEtxAZgvm8Rr2omrHIcpxsP4GfaOs1dBRoPHGKNfkauzMoSYeW4ndU3TEN1z0R N7JYXOJWlKbmLViYRTVHH7yfqHXmZK1A8WnC18lKq21Cl/oQH6PGNoomyDfFa/ZRO9vUwfMIyHg8FqT0G3v55YAmvDMjTHbTDkWdu5CfJfHGpRiMv2oSOQZQ UMcg5RYJNo+QqDseWgYMXLchLElk9crio0dFFAFyewYWeeyLYDxGtq21Je48p7HY Archived-At: Cc: sipcore@ietf.org, ivo.sedlacek@ericsson.com Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-content-id-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 21:32:16 -0000 On 8/26/16 5:28 PM, Randall Gellens wrote: > At 5:09 PM -0400 8/26/16, Paul Kyzivat wrote: > >> For the moment this is simply a hypothetical discussion - an >> extrapolation beyond the proposal to define content-id as a sip header >> field. > > I was thinking it might be useful, but in view of the extra complexity, > I don't think it should be addressed in the Content-ID draft. Yes. In the interest of expediency I am fine with addressing content-id by itself now, and possibly taking up other content-* at some later date. Thanks, Paul From nobody Mon Aug 29 11:43:26 2016 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 BE1E012D78F for ; Mon, 29 Aug 2016 11:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.766 X-Spam-Level: X-Spam-Status: No, score=0.766 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yG7c3qxa2PN for ; Mon, 29 Aug 2016 11:43:25 -0700 (PDT) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3D1B12B049 for ; Mon, 29 Aug 2016 11:43:24 -0700 (PDT) Received: from resomta-po-13v.sys.comcast.net ([96.114.154.237]) by resqmta-po-08v.sys.comcast.net with SMTP id eRWNbBkr42dNjeRWlbli7F; Mon, 29 Aug 2016 18:43:23 +0000 Received: from hobgoblin.ariadne.com ([73.100.16.189]) by resomta-po-13v.sys.comcast.net with SMTP id eRWkbOOVO2CKfeRWlbp53o; Mon, 29 Aug 2016 18:43:23 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u7TIhLGM026595 for ; Mon, 29 Aug 2016 14:43:21 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u7TIhLN3026592; Mon, 29 Aug 2016 14:43:21 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 29 Aug 2016 14:43:21 -0400 Message-ID: <87fupn2z7a.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfFrjgul3skCRFFhvJ3Rf7Qr7wF9y30VMrXC5joithQdjVV/LeIrYuuAPIthqA6PhSRX6kG3mBcW7Aas+PWWqzuafKNRrMm7BEGiuqf+bfmlxCdQM8gZM 9yeXEcssvJ7DmRHg5esOIpWa2ymIf8Vxqy+FMsLy1ATXJVFJ9yF/xQpTb3crTadUn3Y7d1awEkgpBg== Archived-At: Subject: [sipcore] Use of Call-Info in draft-ietf-ecrit-ecall-11 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2016 18:43:26 -0000 Note that the <...> around the URL in the value of a Call-Info header is mandatory (RFC 3261 section 25.1): Call-Info = "Call-Info" HCOLON info *(COMMA info) info = LAQUOT absoluteURI RAQUOT *( SEMI info-param) info-param = ( "purpose" EQUAL ( "icon" / "info" / "card" / token ) ) / generic-param All four example Call-Info headers in draft-ietf-ecrit-ecall-11 omit the <...>: Call-Info: cid:1234567890@atlanta.example.com; purpose=emergencyCallData.eCall.MSD; Call-Info: cid:2345678901@atlanta.example.com; purpose=emergencyCallData.eCall.control; Call-Info: cid:3456789012@atlanta.example.com; purpose=emergencyCallData.eCall.control; Call-Info: cid:4567890123@atlanta.example.com; purpose=emergencyCallData.eCall.MSD; In addition, all of these headers end with an incorrect semicolon. Dale From nobody Mon Aug 29 11:49:14 2016 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 EFCEF12B018 for ; Mon, 29 Aug 2016 11:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, WEIRD_PORT=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9uj_Mi20NIx for ; Mon, 29 Aug 2016 11:49:11 -0700 (PDT) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B514A12D7AA for ; Mon, 29 Aug 2016 11:49:11 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-10v.sys.comcast.net with SMTP id eRY6bvLbCRingeRcNbd4fx; Mon, 29 Aug 2016 18:49:11 +0000 Received: from hobgoblin.ariadne.com ([73.100.16.189]) by resomta-ch2-18v.sys.comcast.net with SMTP id eRcLbWnTK67iteRcMbrYbM; Mon, 29 Aug 2016 18:49:11 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u7TIn9JU027181 for ; Mon, 29 Aug 2016 14:49:09 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u7TIn95X027178; Mon, 29 Aug 2016 14:49:09 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 29 Aug 2016 14:49:08 -0400 Message-ID: <87eg572yxn.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfD7JEhcUciYlys0pQLBnIF31ZW1qHRw2RCXGUq8gPcQCOfHfOohVEabHpK/sh4wKnezSGXD/I7g2cEXxxWR6Je9EYyYLGo80qHRts2e0M4r75YGJAeiU nN/Q8J9ONWt0v52atsxJEzKLUU+wAAwPbmVJRZD0y009R7pJzwU7y4NJa3VPVd16tNG3EX74x1DnZQ== Archived-At: Subject: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2016 18:49:13 -0000 TL;DR: If the body for an emergencyCallData.eCall.MSD info package is defined correctly, we can organize the data in an INFO request the same way that we do in an INVITE request and still follow the info package rules strictly. After asking around, I have learned that my previous message on this subject severely buried the lead: The useful point followed a long message example, which itself followed several pages of recap of the points in question. As far as I can tell, nobody had the stamina to read that far, and in retrospect, I don't blame them. So this time, I'm going recap my proposal and put the important points *first*: It it possible to define an info package for use by draft-ietf-ecrit-ecall-11 that includes all of the Additional Data (RFC 7852) in a way that strictly follows the rules for info packages (RFC 6086), but also uses the same data format used by initial Additional Data reporting. This solves the dilemma that we have been discussing. The key is to define the info package properly. The info package definition is: The body for an emergencyCallData.eCall.MSD info package is: - either an application/emergencyCallData.eCall.MSD+per (containing the MSD), or - a multipart body containing exactly: - exactly one application/emergencyCallData.eCall.MSD+per part (containing the MSD), - zero or more application/EmergencyCallData.DeviceInfo+xml parts (containing Additional Data), and - zero or one application/pidf+xml part (containing geolocation data). This allows all of the information items that we want to carry in the INFO message to be part of one info package, which is the body of the INFO message. In draft-ietf-ecrit-ecall-11 usage, all body parts will typically be pointed to by a Geolocation or Call-Info header. A typical example is this INFO request. I've assembled the example by inserting the Additional Data from an example in RFC 7852 into the response INFO request in draft-ietf-ecrit-ecall-11: INFO urn:service:sos.ecall.automatic SIP/2.0 To: urn:service:sos.ecall.automatic From: ;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com Call-Info: ; purpose=emergencyCallData.eCall.MSD Call-Info: ;purpose=icon, ;purpose=info, ;purpose=EmergencyCallData.ProviderInfo, ;purpose=EmergencyCallData.DeviceInfo Geolocation: Geolocation-Routing: yes Accept: application/sdp, application/pidf+xml, application/emergencyCallData.eCall.control+xml CSeq: 51862 INFO Info-Package: emergencyCallData.eCall.MSD Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, SUBSCRIBE, NOTIFY, UPDATE Content-Disposition: info-package Content-Transfer-Encoding: binary Content-Type: multipart/mixed; boundary=boundary1 Content-Length: ... --boundary1 Content-Type: application/emergencyCallData.eCall.MSD+per Content-ID: 4567890123@atlanta.example.com ...MSD in ASN.1 PER encoding goes here... --boundary1 Content-Type: application/EmergencyCallData.DeviceInfo+xml Content-ID: <0123456789@atlanta.example.com> Content-Disposition: by-reference;handling=optional ... --boundary1 Content-Type: application/EmergencyCallData.ProviderInfo+xml Content-ID: <1234567890@atlanta.example.com> Content-Disposition: by-reference;handling=optional ... --boundary1-- Note the absence of a Recv-Info header (which is forbidden in INFO requests (RFC 6086 section 4.2.1). Note the positioning of the Info-Package header as applying to the entire body. As indicated by the Info-Package header, the entire multipart body is the body of the info package. The info package body includes all of the information contained in the body, including the MSD and the Additional Data, thus strictly following RFC 6086. Three of the Call-Info header values, cid:4567890123@atlanta.example.com; purpose=emergencyCallData.eCall.MSD ;purpose=EmergencyCallData.ProviderInfo ;purpose=EmergencyCallData.DeviceInfo point to body parts within the info package that provide Additional Data. The Geolocation header points to an external application/pidf+xml resource. But it could contain a cid: URL pointing to an additional application/pidf+xml body part. Note that the layout of the body parts is the same as is used in an INFO request containing Additional Data. (Compare with the example in RFC 7852 section 7.) This implies that the logic for inserting an additional Additional Data part into an INFO request is essentially the same as the logic for inserting it into an INVITE request. Dale From nobody Mon Aug 29 14:02:18 2016 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 A7F2B12B032 for ; Mon, 29 Aug 2016 14:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpUjkE3Hyl9k for ; Mon, 29 Aug 2016 14:02:14 -0700 (PDT) Received: from email.salsgiver.com (email.salsgiver.com [206.67.234.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CD8612B044 for ; Mon, 29 Aug 2016 14:02:13 -0700 (PDT) Received: from [10.96.10.115] ([156.154.81.54]) (authenticated bits=0) by email.salsgiver.com (8.15.2/8.14.3) with ESMTPA id u7TL25ea024551; Mon, 29 Aug 2016 17:02:08 -0400 (EDT) (envelope-from br@salsgiver.com) X-Authentication-Warning: email.salsgiver.com: Host [156.154.81.54] claimed to be [10.96.10.115] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: <87eg572yxn.fsf@hobgoblin.ariadne.com> Date: Mon, 29 Aug 2016 14:02:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <76D1BB4B-CE62-42BD-A694-E5140341DD7E@salsgiver.com> References: <87eg572yxn.fsf@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2016 21:02:17 -0000 Verrrry interesting. About the only part I don=E2=80=99t get is the Content Disposition of = Info-Package on the whole body, no Content Disposition on the MSD, and = then a different Content Disposition on the DeviceInfo block. But I think it would be fairly easy to deal with if you were expecting = it, which is what an implementation that handled eCall (and thus the = emergencyCallData.eCall.MSD part) would do. It=E2=80=99s clever, I will say that. Brian > On Aug 29, 2016, at 11:49 AM, Dale R. Worley = wrote: >=20 > TL;DR: If the body for an emergencyCallData.eCall.MSD info package is > defined correctly, we can organize the data in an INFO request the = same > way that we do in an INVITE request and still follow the info package > rules strictly. >=20 >=20 > After asking around, I have learned that my previous message on this > subject severely buried the lead: The useful point followed a long > message example, which itself followed several pages of recap of the > points in question. As far as I can tell, nobody had the stamina to > read that far, and in retrospect, I don't blame them. >=20 > So this time, I'm going recap my proposal and put the important points > *first*: >=20 > It it possible to define an info package for use by > draft-ietf-ecrit-ecall-11 that includes all of the Additional Data = (RFC > 7852) in a way that strictly follows the rules for info packages (RFC > 6086), but also uses the same data format used by initial Additional > Data reporting. This solves the dilemma that we have been discussing. >=20 > The key is to define the info package properly. The info package > definition is: >=20 > The body for an emergencyCallData.eCall.MSD info package is: >=20 > - either an application/emergencyCallData.eCall.MSD+per (containing > the MSD), or >=20 > - a multipart body containing exactly: >=20 > - exactly one application/emergencyCallData.eCall.MSD+per part > (containing the MSD), >=20 > - zero or more application/EmergencyCallData.DeviceInfo+xml > parts (containing Additional Data), and >=20 > - zero or one application/pidf+xml part (containing geolocation > data). >=20 > This allows all of the information items that we want to carry in the > INFO message to be part of one info package, which is the body of the > INFO message. >=20 > In draft-ietf-ecrit-ecall-11 usage, all body parts will typically be > pointed to by a Geolocation or Call-Info header. >=20 > A typical example is this INFO request. I've assembled the example by > inserting the Additional Data from an example in RFC 7852 into the > response INFO request in draft-ietf-ecrit-ecall-11: >=20 > INFO urn:service:sos.ecall.automatic SIP/2.0 > To: urn:service:sos.ecall.automatic > From: ;tag=3D9fxced76sl > Call-ID: 3848276298220188511@atlanta.example.com > Call-Info: ; > purpose=3DemergencyCallData.eCall.MSD > Call-Info: > ;purpose=3Dicon, > ;purpose=3Dinfo, > > ;purpose=3DEmergencyCallData.ProviderInfo, > > ;purpose=3DEmergencyCallData.DeviceInfo > Geolocation: > Geolocation-Routing: yes > Accept: application/sdp, application/pidf+xml, > application/emergencyCallData.eCall.control+xml > CSeq: 51862 INFO > Info-Package: emergencyCallData.eCall.MSD > Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, > SUBSCRIBE, NOTIFY, UPDATE > Content-Disposition: info-package > Content-Transfer-Encoding: binary > Content-Type: multipart/mixed; boundary=3Dboundary1 > Content-Length: ... >=20 > --boundary1 > Content-Type: application/emergencyCallData.eCall.MSD+per > Content-ID: 4567890123@atlanta.example.com >=20 > ...MSD in ASN.1 PER encoding goes here... >=20 > --boundary1 > Content-Type: application/EmergencyCallData.DeviceInfo+xml > Content-ID: <0123456789@atlanta.example.com> > Content-Disposition: by-reference;handling=3Doptional >=20 > > xmlns:dev=3D > "urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo"> > ... > >=20 > --boundary1 > Content-Type: application/EmergencyCallData.ProviderInfo+xml > Content-ID: <1234567890@atlanta.example.com> > Content-Disposition: by-reference;handling=3Doptional >=20 > > xmlns:pi=3D > "urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo"> > ... > > --boundary1-- >=20 > Note the absence of a Recv-Info header (which is forbidden in INFO > requests (RFC 6086 section 4.2.1). >=20 > Note the positioning of the Info-Package header as applying to the > entire body. >=20 > As indicated by the Info-Package header, the entire multipart body is > the body of the info package. The info package body includes all of = the > information contained in the body, including the MSD and the = Additional > Data, thus strictly following RFC 6086. >=20 > Three of the Call-Info header values, > cid:4567890123@atlanta.example.com; > purpose=3DemergencyCallData.eCall.MSD > > ;purpose=3DEmergencyCallData.ProviderInfo > > ;purpose=3DEmergencyCallData.DeviceInfo > point to body parts within the info package that provide Additional > Data. >=20 > The Geolocation header points to an external application/pidf+xml > resource. But it could contain a cid: URL pointing to an additional > application/pidf+xml body part. >=20 > Note that the layout of the body parts is the same as is used in an = INFO > request containing Additional Data. (Compare with the example in RFC > 7852 section 7.) >=20 > This implies that the logic for inserting an additional Additional = Data > part into an INFO request is essentially the same as the logic for > inserting it into an INVITE request. >=20 > Dale >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Aug 29 14:55:58 2016 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 522C512D8AB for ; Mon, 29 Aug 2016 14:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4QWp9qun4ar for ; Mon, 29 Aug 2016 14:55:54 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACC2512D8A6 for ; Mon, 29 Aug 2016 14:55:54 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u7TLtrI6038507 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 29 Aug 2016 16:55:54 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local References: <147250302871.19142.11825877398134368393.idtracker@ietfa.amsl.com> To: "'SIPCORE'" From: Adam Roach X-Forwarded-Message-Id: <147250302871.19142.11825877398134368393.idtracker@ietfa.amsl.com> Message-ID: <2c58937b-763b-1f6d-9740-d728bc824267@nostrum.com> Date: Mon, 29 Aug 2016 16:55:52 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <147250302871.19142.11825877398134368393.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [sipcore] NomCom 2016-2017: Call for Nominations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2016 21:55:56 -0000 The 2016-17 Nominating Committee (Nomcom) is seeking nominations from now until October 8, 2016. The open positions being considered by this year's Nomcom can be found at the end of this email and also on this year's Nomcom website: https://datatracker.ietf.org/nomcom/2016/ Nominations may be made by selecting the Nominate link at the top of the Nomcom 2016 home page, or by visiting the following URL: https://datatracker.ietf.org/nomcom/2016/nominate/ {Note that nominations made using the web tool require an ietf.org datatracker account. You can create a datatracker ietf.org account if you don't have one already by visiting the following URL: https://datatracker.ietf.org/accounts/create/ } If you are unable to use the web form, nominations may instead be made by email to nomcom-16@ietf.org. If using email, please include the word "Nominate" in the Subject and indicate in the email who is being nominated, their email address (to confirm acceptance of the nomination), and the position for which you are making the nomination. If you are nominating someone other than yourself, please tell us if we may tell the nominee that you were the one who made the nomination. If you wish to nominate someone via email for more than one position, please use separate emails to do so. Self-nomination is welcome! Willing nominees will be asked to fill out a questionnaire specific to the position for which they are nominated. The questionnaires will be available on September 2, 2016 and have a submission deadline of October 13, 2016. NomCom 2016-17 will follow the policy for "Open Disclosure of Willing Nominees" described in BCP 10/RFC 7437. As stated in RFC 7437: "The list of nominees willing to be considered for positions under review in the current Nomcom cycle is not confidential". Willing nominees for each position will be listed in a publicly accessible way - anyone with a datatracker account may access the lists. Additionally, the nomination form asks if we may share your own name with the nominee. In all other ways, the confidentiality requirements of BCP10 remain in effect. All feedback and all Nomcom deliberations will remain confidential and will not be disclosed. There is a field on the form you can mark in order to allow the Nomcom to tell the nominee that you were the one who made the nomination. This defaults to “no” - so if you don't mark the field we won’t tell. In order to ensure time to collect sufficient community feedback about each of the willing nominees, nominations must be received by the NomCom on or before October 8, 2016. Please submit your nominations as early as possible for the sake of your nominees. Note that nominations should not wait for management permission, as it is easier to decline the nomination than put one in late. The Nomcom appoints individuals to fill the open slots on the IAOC, the IAB, and the IESG. The list of people and posts whose terms end with the March 2017 IETF meeting, and thus the positions for which this Nomcom is responsible, follows: IAOC Lou Berger IAB Ralph Droms* Russ Housley* Robert Sparks Andrew Sullivan Dave Thaler* Suzanne Woolf IESG Jari Arkko (GEN)* Deborah Brungard (RTG) Ben Campbell (ART) Spencer Dawkins (TSV) Stephen Farrell (SEC)* Joel Jaeggli (OPS)* Terry Manderson (INT) Alvaro Retana (RTG) *- have indicated that they do not intend to accept a renomination. This information is always up to date on https://datatracker.ietf.org/nomcom/2016/ Please be resourceful in identifying possible candidates for these positions, as developing our talent is a very crucial requirement for the IETF, and also, please consider accepting a nomination. You'll find extensive information about specific positions, developed by the IAB, IESG, and IAOC, under individual tabs at: https://datatracker.ietf.org/nomcom/2016/requirements/ In addition to nominations, the Nomcom seeks community input on the positions themselves. We need and welcome the community's views and input on the jobs within each organization. If you have ideas on the positions' responsibilities (more, less, different), please let us know. Please send suggestions and feedback about this to nomcom-16@ietf.org. Thank you for your help in identifying qualified nominees! Lucy Lynch Nomcom Chair 2016-17 nomcom-chair-2016@ietf.org llynch@civil-tongue.net From nobody Mon Aug 29 15:11:10 2016 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 AB4CD12D8A6 for ; Mon, 29 Aug 2016 15:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndyjaDxHVRBE for ; Mon, 29 Aug 2016 15:11:06 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D24812B03A for ; Mon, 29 Aug 2016 15:11:06 -0700 (PDT) X-AuditID: c1b4fb3a-0618b980000009bd-72-57c4b2f8f3a7 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id 54.A8.02493.8F2B4C75; Tue, 30 Aug 2016 00:11:04 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0301.000; Tue, 30 Aug 2016 00:10:59 +0200 From: Christer Holmberg To: Brian Rosen , "Dale R. Worley" Thread-Topic: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 Thread-Index: AQHSAiYM+pjwWhmVIEetajd/MHhvMaBgS2qAgAAv+uA= Date: Mon, 29 Aug 2016 22:10:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC72486@ESESSMB209.ericsson.se> References: <87eg572yxn.fsf@hobgoblin.ariadne.com> <76D1BB4B-CE62-42BD-A694-E5140341DD7E@salsgiver.com> In-Reply-To: <76D1BB4B-CE62-42BD-A694-E5140341DD7E@salsgiver.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGbHdUvfHpiPhBpuuS1hMO7aB3eLrj01s Fi9PlDkwe0ze/5XZY8mSn0weiw79YA1gjuKySUnNySxLLdK3S+DKOPzyK3vBiqCKlX2zmBoY ZwR0MXJySAiYSPy+/J+9i5GLQ0hgPaPEvvlfmSGcJYwSHzYeYuti5OBgE7CQ6P6nDdIgIuAp sXl1AzuIzSygKfFo514mkBJhoPiLlQUQJV4St188ZIewrSTO7DsLZrMIqEo8PdbJAmLzCvhK zD+wggnEFhLIlLh24BsziM0p4Cixd/d3sDijgJjE91NrmCBWiUvcejKfCeJmAYkle84zQ9ii Ei8f/2OFsJUk1h7ezgJyDshp63fpQ7QqSkzphjiHV0BQ4uTMJywTGEVnIZk6C6FjFpKOWUg6 FjCyrGIULU4tLs5NNzLSSy3KTC4uzs/Ty0st2cQIjJmDW35b7WA8+NzxEKMAB6MSD69CxZFw IdbEsuLK3EOMEhzMSiK8/sCIE+JNSaysSi3Kjy8qzUktPsQozcGiJM7r/1IxXEggPbEkNTs1 tSC1CCbLxMEp1cDozn62IN7q8vM3s3hiygWETAK8J/1l21Q/N+DHqQ0W1yZblF06aWG7N0bo BM+04H/tK3O/r3y2tbKA068xLYaJ4fzFE0eWeL7cbz+B89qt49NncP84yD1zUaXh/6u2irsW p283KXHgOCWSdW2OQsWxo967rs/f0Dy5JzfjwCNjq6l/3YTmaK47pcRSnJFoqMVcVJwIADfV 3x2VAgAA Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2016 22:11:08 -0000 SSBtYXkgaGF2ZSBtaXNzZWQgc29tZXRoaW5nLCBidXQgdG8gbWUgdGhpcyBzZWVtcyBtb3JlIG9y IGxlc3MgbGlrZSB3aGF0IGhhcyBhbHJlYWR5IGJlZW4gZGlzY3Vzc2VkIGluIEVDUklUOiBhc3Nv Y2lhdGUgdGhlIE1TRCBpbnNpZGUgYW4gaW5mbyBwYWNrYWdlLCBidXQgc3RpbGwgdXNlIENhbGwt SW5mbyB0byBwb2ludCB0byBpdC4NCg0KQXMgYSBzaWRlIG5vdGUsIGl0J3MgaW1wb3J0YW50IHRv IHNlcGFyYXRlIHRoZSAqdHJhbnNwb3J0IG1lY2hhbmlzbSogZGVmaW5lZCBpbiBBZGRpdGlvbmFs IERhdGEgKGNoYXB0ZXIgNiBvZiBSRkMgNzg1MiksIGFuZCB0aGUgKmRhdGEgc3RydWN0dXJlcyog KERldmljZSBJbmZvcm1hdGlvbikgZGVmaW5lZCBpbiBBZGRpdGlvbmFsIERhdGEuIFRoZXJlIGlz IGN1cnJlbnRseSBubyByZXF1aXJlbWVudCBmb3IgZWNhbGwgdG8gc3VwcG9ydCB0aGUgZGF0YSBz dHJ1Y3R1cmVzLCBhbmQgdGhleSBhcmUgbm90IG1lbnRpb25lZC9yZWZlcmVuY2VkIGluIGRyYWZ0 LWVjYWxsLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogc2lwY29yZSBbbWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEJyaWFuIFJvc2VuDQpTZW50OiAzMCBBdWd1c3QgMjAxNiAwMDowMg0KVG86IERh bGUgUi4gV29ybGV5IDx3b3JsZXlAYXJpYWRuZS5jb20+DQpDYzogc2lwY29yZUBpZXRmLm9yZw0K U3ViamVjdDogUmU6IFtzaXBjb3JlXSBVc2luZyBhbiBJTkZPIHBhY2thZ2UgaW4gZHJhZnQtaWV0 Zi1lY3JpdC1lY2FsbC0xMQ0KDQpWZXJycnJ5IGludGVyZXN0aW5nLg0KDQpBYm91dCB0aGUgb25s eSBwYXJ0IEkgZG9u4oCZdCBnZXQgaXMgdGhlIENvbnRlbnQgRGlzcG9zaXRpb24gb2YgSW5mby1Q YWNrYWdlIG9uIHRoZSB3aG9sZSBib2R5LCBubyBDb250ZW50IERpc3Bvc2l0aW9uIG9uIHRoZSBN U0QsIGFuZCB0aGVuIGEgZGlmZmVyZW50IENvbnRlbnQgRGlzcG9zaXRpb24gb24gdGhlIERldmlj ZUluZm8gYmxvY2suDQoNCkJ1dCBJIHRoaW5rIGl0IHdvdWxkIGJlIGZhaXJseSBlYXN5IHRvIGRl YWwgd2l0aCBpZiB5b3Ugd2VyZSBleHBlY3RpbmcgaXQsIHdoaWNoIGlzIHdoYXQgYW4gaW1wbGVt ZW50YXRpb24gdGhhdCBoYW5kbGVkIGVDYWxsIChhbmQgdGh1cyB0aGUgZW1lcmdlbmN5Q2FsbERh dGEuZUNhbGwuTVNEIHBhcnQpIHdvdWxkIGRvLg0KDQpJdOKAmXMgY2xldmVyLCBJIHdpbGwgc2F5 IHRoYXQuDQoNCkJyaWFuDQoNCj4gT24gQXVnIDI5LCAyMDE2LCBhdCAxMTo0OSBBTSwgRGFsZSBS LiBXb3JsZXkgPHdvcmxleUBhcmlhZG5lLmNvbT4gd3JvdGU6DQo+IA0KPiBUTDtEUjogIElmIHRo ZSBib2R5IGZvciBhbiBlbWVyZ2VuY3lDYWxsRGF0YS5lQ2FsbC5NU0QgaW5mbyBwYWNrYWdlIGlz IA0KPiBkZWZpbmVkIGNvcnJlY3RseSwgd2UgY2FuIG9yZ2FuaXplIHRoZSBkYXRhIGluIGFuIElO Rk8gcmVxdWVzdCB0aGUgDQo+IHNhbWUgd2F5IHRoYXQgd2UgZG8gaW4gYW4gSU5WSVRFIHJlcXVl c3QgYW5kIHN0aWxsIGZvbGxvdyB0aGUgaW5mbyANCj4gcGFja2FnZSBydWxlcyBzdHJpY3RseS4N Cj4gDQo+IA0KPiBBZnRlciBhc2tpbmcgYXJvdW5kLCBJIGhhdmUgbGVhcm5lZCB0aGF0IG15IHBy ZXZpb3VzIG1lc3NhZ2Ugb24gdGhpcyANCj4gc3ViamVjdCBzZXZlcmVseSBidXJpZWQgdGhlIGxl YWQ6ICBUaGUgdXNlZnVsIHBvaW50IGZvbGxvd2VkIGEgbG9uZyANCj4gbWVzc2FnZSBleGFtcGxl LCB3aGljaCBpdHNlbGYgZm9sbG93ZWQgc2V2ZXJhbCBwYWdlcyBvZiByZWNhcCBvZiB0aGUgDQo+ IHBvaW50cyBpbiBxdWVzdGlvbi4gIEFzIGZhciBhcyBJIGNhbiB0ZWxsLCBub2JvZHkgaGFkIHRo ZSBzdGFtaW5hIHRvIA0KPiByZWFkIHRoYXQgZmFyLCBhbmQgaW4gcmV0cm9zcGVjdCwgSSBkb24n dCBibGFtZSB0aGVtLg0KPiANCj4gU28gdGhpcyB0aW1lLCBJJ20gZ29pbmcgcmVjYXAgbXkgcHJv cG9zYWwgYW5kIHB1dCB0aGUgaW1wb3J0YW50IHBvaW50cw0KPiAqZmlyc3QqOg0KPiANCj4gSXQg aXQgcG9zc2libGUgdG8gZGVmaW5lIGFuIGluZm8gcGFja2FnZSBmb3IgdXNlIGJ5DQo+IGRyYWZ0 LWlldGYtZWNyaXQtZWNhbGwtMTEgdGhhdCBpbmNsdWRlcyBhbGwgb2YgdGhlIEFkZGl0aW9uYWwg RGF0YSANCj4gKFJGQw0KPiA3ODUyKSBpbiBhIHdheSB0aGF0IHN0cmljdGx5IGZvbGxvd3MgdGhl IHJ1bGVzIGZvciBpbmZvIHBhY2thZ2VzIChSRkMgDQo+IDYwODYpLCBidXQgYWxzbyB1c2VzIHRo ZSBzYW1lIGRhdGEgZm9ybWF0IHVzZWQgYnkgaW5pdGlhbCBBZGRpdGlvbmFsIA0KPiBEYXRhIHJl cG9ydGluZy4gIFRoaXMgc29sdmVzIHRoZSBkaWxlbW1hIHRoYXQgd2UgaGF2ZSBiZWVuIGRpc2N1 c3NpbmcuDQo+IA0KPiBUaGUga2V5IGlzIHRvIGRlZmluZSB0aGUgaW5mbyBwYWNrYWdlIHByb3Bl cmx5LiAgVGhlIGluZm8gcGFja2FnZSANCj4gZGVmaW5pdGlvbiBpczoNCj4gDQo+ICAgIFRoZSBi b2R5IGZvciBhbiBlbWVyZ2VuY3lDYWxsRGF0YS5lQ2FsbC5NU0QgaW5mbyBwYWNrYWdlIGlzOg0K PiANCj4gICAgLSBlaXRoZXIgYW4gYXBwbGljYXRpb24vZW1lcmdlbmN5Q2FsbERhdGEuZUNhbGwu TVNEK3BlciAoY29udGFpbmluZw0KPiAgICAgIHRoZSBNU0QpLCBvcg0KPiANCj4gICAgLSBhIG11 bHRpcGFydCBib2R5IGNvbnRhaW5pbmcgZXhhY3RseToNCj4gDQo+ICAgICAgICAtIGV4YWN0bHkg b25lIGFwcGxpY2F0aW9uL2VtZXJnZW5jeUNhbGxEYXRhLmVDYWxsLk1TRCtwZXIgcGFydA0KPiAg ICAgICAgICAoY29udGFpbmluZyB0aGUgTVNEKSwNCj4gDQo+ICAgICAgICAtIHplcm8gb3IgbW9y ZSBhcHBsaWNhdGlvbi9FbWVyZ2VuY3lDYWxsRGF0YS5EZXZpY2VJbmZvK3htbA0KPiAgICAgICAg ICBwYXJ0cyAoY29udGFpbmluZyBBZGRpdGlvbmFsIERhdGEpLCBhbmQNCj4gDQo+ICAgICAgICAt IHplcm8gb3Igb25lIGFwcGxpY2F0aW9uL3BpZGYreG1sIHBhcnQgKGNvbnRhaW5pbmcgZ2VvbG9j YXRpb24NCj4gICAgICAgICAgZGF0YSkuDQo+IA0KPiBUaGlzIGFsbG93cyBhbGwgb2YgdGhlIGlu Zm9ybWF0aW9uIGl0ZW1zIHRoYXQgd2Ugd2FudCB0byBjYXJyeSBpbiB0aGUgDQo+IElORk8gbWVz c2FnZSB0byBiZSBwYXJ0IG9mIG9uZSBpbmZvIHBhY2thZ2UsIHdoaWNoIGlzIHRoZSBib2R5IG9m IHRoZSANCj4gSU5GTyBtZXNzYWdlLg0KPiANCj4gSW4gZHJhZnQtaWV0Zi1lY3JpdC1lY2FsbC0x MSB1c2FnZSwgYWxsIGJvZHkgcGFydHMgd2lsbCB0eXBpY2FsbHkgYmUgDQo+IHBvaW50ZWQgdG8g YnkgYSBHZW9sb2NhdGlvbiBvciBDYWxsLUluZm8gaGVhZGVyLg0KPiANCj4gQSB0eXBpY2FsIGV4 YW1wbGUgaXMgdGhpcyBJTkZPIHJlcXVlc3QuICBJJ3ZlIGFzc2VtYmxlZCB0aGUgZXhhbXBsZSBi eSANCj4gaW5zZXJ0aW5nIHRoZSBBZGRpdGlvbmFsIERhdGEgZnJvbSBhbiBleGFtcGxlIGluIFJG QyA3ODUyIGludG8gdGhlIA0KPiByZXNwb25zZSBJTkZPIHJlcXVlc3QgaW4gZHJhZnQtaWV0Zi1l Y3JpdC1lY2FsbC0xMToNCj4gDQo+ICAgICAgSU5GTyB1cm46c2VydmljZTpzb3MuZWNhbGwuYXV0 b21hdGljIFNJUC8yLjANCj4gICAgICBUbzogdXJuOnNlcnZpY2U6c29zLmVjYWxsLmF1dG9tYXRp Yw0KPiAgICAgIEZyb206IDxzaXA6KzEzMTQ1NTUxMTExQGV4YW1wbGUuY29tPjt0YWc9OWZ4Y2Vk NzZzbA0KPiAgICAgIENhbGwtSUQ6IDM4NDgyNzYyOTgyMjAxODg1MTFAYXRsYW50YS5leGFtcGxl LmNvbQ0KPiAgICAgIENhbGwtSW5mbzogPGNpZDo0NTY3ODkwMTIzQGF0bGFudGEuZXhhbXBsZS5j b20+Ow0KPiAgICAgICAgICAgICAgICAgcHVycG9zZT1lbWVyZ2VuY3lDYWxsRGF0YS5lQ2FsbC5N U0QNCj4gICAgICBDYWxsLUluZm86IDxodHRwOi8vd3d3dy5leGFtcGxlLmNvbS9oYW5uZXMvcGhv dG8uanBnPg0KPiAgICAgICAgICAgICAgICAgICAgIDtwdXJwb3NlPWljb24sDQo+ICAgICAgICA8 aHR0cDovL3d3dy5leGFtcGxlLmNvbS9oYW5uZXMvPiA7cHVycG9zZT1pbmZvLA0KPiAgICAgICAg PGNpZDoxMjM0NTY3ODkwQGF0bGFudGEuZXhhbXBsZS5jb20+DQo+ICAgICAgICAgICAgO3B1cnBv c2U9RW1lcmdlbmN5Q2FsbERhdGEuUHJvdmlkZXJJbmZvLA0KPiAgICAgICAgPGNpZDowMTIzNDU2 Nzg5QGF0bGFudGEuZXhhbXBsZS5jb20+DQo+ICAgICAgICAgICAgO3B1cnBvc2U9RW1lcmdlbmN5 Q2FsbERhdGEuRGV2aWNlSW5mbw0KPiAgICAgIEdlb2xvY2F0aW9uOiA8aHR0cHM6Ly9scy5leGFt cGxlLm5ldDo5NzY4LzM1N3ljNnM2NGNleW9pdXk1YXgzbz4NCj4gICAgICBHZW9sb2NhdGlvbi1S b3V0aW5nOiB5ZXMNCj4gICAgICBBY2NlcHQ6IGFwcGxpY2F0aW9uL3NkcCwgYXBwbGljYXRpb24v cGlkZit4bWwsDQo+ICAgICAgICAgICAgICBhcHBsaWNhdGlvbi9lbWVyZ2VuY3lDYWxsRGF0YS5l Q2FsbC5jb250cm9sK3htbA0KPiAgICAgIENTZXE6IDUxODYyIElORk8NCj4gICAgICBJbmZvLVBh Y2thZ2U6IGVtZXJnZW5jeUNhbGxEYXRhLmVDYWxsLk1TRA0KPiAgICAgIEFsbG93OiBJTlZJVEUs IEFDSywgUFJBQ0ssIElORk8sIE9QVElPTlMsIENBTkNFTCwgUkVGRVIsIEJZRSwNCj4gICAgICAg ICAgICAgU1VCU0NSSUJFLCBOT1RJRlksIFVQREFURQ0KPiAgICAgIENvbnRlbnQtRGlzcG9zaXRp b246IGluZm8tcGFja2FnZQ0KPiAgICAgIENvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IGJpbmFy eQ0KPiAgICAgIENvbnRlbnQtVHlwZTogbXVsdGlwYXJ0L21peGVkOyBib3VuZGFyeT1ib3VuZGFy eTENCj4gICAgICBDb250ZW50LUxlbmd0aDogLi4uDQo+IA0KPiAgICAgIC0tYm91bmRhcnkxDQo+ ICAgICAgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi9lbWVyZ2VuY3lDYWxsRGF0YS5lQ2FsbC5N U0QrcGVyDQo+ICAgICAgQ29udGVudC1JRDogNDU2Nzg5MDEyM0BhdGxhbnRhLmV4YW1wbGUuY29t DQo+IA0KPiAgICAgICAgICAgLi4uTVNEIGluIEFTTi4xIFBFUiBlbmNvZGluZyBnb2VzIGhlcmUu Li4NCj4gDQo+ICAgICAgLS1ib3VuZGFyeTENCj4gICAgICBDb250ZW50LVR5cGU6IGFwcGxpY2F0 aW9uL0VtZXJnZW5jeUNhbGxEYXRhLkRldmljZUluZm8reG1sDQo+ICAgICAgQ29udGVudC1JRDog PDAxMjM0NTY3ODlAYXRsYW50YS5leGFtcGxlLmNvbT4NCj4gICAgICBDb250ZW50LURpc3Bvc2l0 aW9uOiBieS1yZWZlcmVuY2U7aGFuZGxpbmc9b3B0aW9uYWwNCj4gDQo+ICAgICAgPD94bWwgdmVy c2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCj4gICAgICA8ZGV2OkVtZXJnZW5jeUNhbGxE YXRhLkRldmljZUluZm8NCj4gICAgICAgICAgIHhtbG5zOmRldj0NCj4gICAgICAgICAgICJ1cm46 aWV0ZjpwYXJhbXM6eG1sOm5zOkVtZXJnZW5jeUNhbGxEYXRhOkRldmljZUluZm8iPg0KPiAgICAg ICAgICAuLi4NCj4gICAgICA8L2RldjpFbWVyZ2VuY3lDYWxsRGF0YS5EZXZpY2VJbmZvPg0KPiAN Cj4gICAgICAtLWJvdW5kYXJ5MQ0KPiAgICAgIENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24vRW1l cmdlbmN5Q2FsbERhdGEuUHJvdmlkZXJJbmZvK3htbA0KPiAgICAgIENvbnRlbnQtSUQ6IDwxMjM0 NTY3ODkwQGF0bGFudGEuZXhhbXBsZS5jb20+DQo+ICAgICAgQ29udGVudC1EaXNwb3NpdGlvbjog YnktcmVmZXJlbmNlO2hhbmRsaW5nPW9wdGlvbmFsDQo+IA0KPiAgICAgIDw/eG1sIHZlcnNpb249 IjEuMCIgZW5jb2Rpbmc9IlVURi04Ij8+DQo+ICAgICAgPHBpOkVtZXJnZW5jeUNhbGxEYXRhLlBy b3ZpZGVySW5mbw0KPiAgICAgICAgIHhtbG5zOnBpPQ0KPiAgICAgICAgICAgICJ1cm46aWV0Zjpw YXJhbXM6eG1sOm5zOkVtZXJnZW5jeUNhbGxEYXRhOlByb3ZpZGVySW5mbyI+DQo+ICAgICAgICAg IC4uLg0KPiAgICAgIDwvcGk6RW1lcmdlbmN5Q2FsbERhdGEuUHJvdmlkZXJJbmZvPg0KPiAgICAg IC0tYm91bmRhcnkxLS0NCj4gDQo+IE5vdGUgdGhlIGFic2VuY2Ugb2YgYSBSZWN2LUluZm8gaGVh ZGVyICh3aGljaCBpcyBmb3JiaWRkZW4gaW4gSU5GTyANCj4gcmVxdWVzdHMgKFJGQyA2MDg2IHNl Y3Rpb24gNC4yLjEpLg0KPiANCj4gTm90ZSB0aGUgcG9zaXRpb25pbmcgb2YgdGhlIEluZm8tUGFj a2FnZSBoZWFkZXIgYXMgYXBwbHlpbmcgdG8gdGhlIA0KPiBlbnRpcmUgYm9keS4NCj4gDQo+IEFz IGluZGljYXRlZCBieSB0aGUgSW5mby1QYWNrYWdlIGhlYWRlciwgdGhlIGVudGlyZSBtdWx0aXBh cnQgYm9keSBpcyANCj4gdGhlIGJvZHkgb2YgdGhlIGluZm8gcGFja2FnZS4gIFRoZSBpbmZvIHBh Y2thZ2UgYm9keSBpbmNsdWRlcyBhbGwgb2YgDQo+IHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQg aW4gdGhlIGJvZHksIGluY2x1ZGluZyB0aGUgTVNEIGFuZCB0aGUgDQo+IEFkZGl0aW9uYWwgRGF0 YSwgdGh1cyBzdHJpY3RseSBmb2xsb3dpbmcgUkZDIDYwODYuDQo+IA0KPiBUaHJlZSBvZiB0aGUg Q2FsbC1JbmZvIGhlYWRlciB2YWx1ZXMsDQo+ICAgICAgICBjaWQ6NDU2Nzg5MDEyM0BhdGxhbnRh LmV4YW1wbGUuY29tOw0KPiAgICAgICAgICAgICAgICAgcHVycG9zZT1lbWVyZ2VuY3lDYWxsRGF0 YS5lQ2FsbC5NU0QNCj4gICAgICAgIDxjaWQ6MTIzNDU2Nzg5MEBhdGxhbnRhLmV4YW1wbGUuY29t Pg0KPiAgICAgICAgICAgIDtwdXJwb3NlPUVtZXJnZW5jeUNhbGxEYXRhLlByb3ZpZGVySW5mbw0K PiAgICAgICAgPGNpZDowMTIzNDU2Nzg5QGF0bGFudGEuZXhhbXBsZS5jb20+DQo+ICAgICAgICAg ICAgO3B1cnBvc2U9RW1lcmdlbmN5Q2FsbERhdGEuRGV2aWNlSW5mbw0KPiBwb2ludCB0byBib2R5 IHBhcnRzIHdpdGhpbiB0aGUgaW5mbyBwYWNrYWdlIHRoYXQgcHJvdmlkZSBBZGRpdGlvbmFsIA0K PiBEYXRhLg0KPiANCj4gVGhlIEdlb2xvY2F0aW9uIGhlYWRlciBwb2ludHMgdG8gYW4gZXh0ZXJu YWwgYXBwbGljYXRpb24vcGlkZit4bWwgDQo+IHJlc291cmNlLiAgQnV0IGl0IGNvdWxkIGNvbnRh aW4gYSBjaWQ6IFVSTCBwb2ludGluZyB0byBhbiBhZGRpdGlvbmFsIA0KPiBhcHBsaWNhdGlvbi9w aWRmK3htbCBib2R5IHBhcnQuDQo+IA0KPiBOb3RlIHRoYXQgdGhlIGxheW91dCBvZiB0aGUgYm9k eSBwYXJ0cyBpcyB0aGUgc2FtZSBhcyBpcyB1c2VkIGluIGFuIA0KPiBJTkZPIHJlcXVlc3QgY29u dGFpbmluZyBBZGRpdGlvbmFsIERhdGEuICAoQ29tcGFyZSB3aXRoIHRoZSBleGFtcGxlIGluIA0K PiBSRkMNCj4gNzg1MiBzZWN0aW9uIDcuKQ0KPiANCj4gVGhpcyBpbXBsaWVzIHRoYXQgdGhlIGxv Z2ljIGZvciBpbnNlcnRpbmcgYW4gYWRkaXRpb25hbCBBZGRpdGlvbmFsIA0KPiBEYXRhIHBhcnQg aW50byBhbiBJTkZPIHJlcXVlc3QgaXMgZXNzZW50aWFsbHkgdGhlIHNhbWUgYXMgdGhlIGxvZ2lj IA0KPiBmb3IgaW5zZXJ0aW5nIGl0IGludG8gYW4gSU5WSVRFIHJlcXVlc3QuDQo+IA0KPiBEYWxl DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPiBzaXBjb3JlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2lwY29yZSBtYWlsaW5nIGxpc3QNCnNpcGNv cmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29y ZQ0K From nobody Mon Aug 29 15:55:12 2016 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 07F9512D8A9 for ; Mon, 29 Aug 2016 15:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXnJbnb0YEa6 for ; Mon, 29 Aug 2016 15:55:08 -0700 (PDT) Received: from email.salsgiver.com (email.salsgiver.com [206.67.234.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61A4F12D7A4 for ; Mon, 29 Aug 2016 15:55:08 -0700 (PDT) Received: from [10.96.10.115] ([156.154.81.54]) (authenticated bits=0) by email.salsgiver.com (8.15.2/8.14.3) with ESMTPA id u7TMsClh026998; Mon, 29 Aug 2016 18:54:58 -0400 (EDT) (envelope-from br@salsgiver.com) X-Authentication-Warning: email.salsgiver.com: Host [156.154.81.54] claimed to be [10.96.10.115] Content-Type: multipart/alternative; boundary="Apple-Mail=_967CBF69-9AEF-45F7-B34A-C53D31E1D0AB" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC72486@ESESSMB209.ericsson.se> Date: Mon, 29 Aug 2016 15:54:59 -0700 Message-Id: References: <87eg572yxn.fsf@hobgoblin.ariadne.com> <76D1BB4B-CE62-42BD-A694-E5140341DD7E@salsgiver.com> <7594FB04B1934943A5C02806D1A2204B4BC72486@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "Dale R. Worley" , "sipcore@ietf.org" Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2016 22:55:11 -0000 --Apple-Mail=_967CBF69-9AEF-45F7-B34A-C53D31E1D0AB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 No, this really does return the MSD in an info block, but it also has = the Additional Data header pointing to the body part that contains the = MSD. eCall itself doesn=E2=80=99t use the other structures, but we would like = to see them in any emergency call, so showing how they would be carried = is useful. Brian > On Aug 29, 2016, at 3:10 PM, Christer Holmberg = wrote: >=20 > I may have missed something, but to me this seems more or less like = what has already been discussed in ECRIT: associate the MSD inside an = info package, but still use Call-Info to point to it. >=20 > As a side note, it's important to separate the *transport mechanism* = defined in Additional Data (chapter 6 of RFC 7852), and the *data = structures* (Device Information) defined in Additional Data. There is = currently no requirement for ecall to support the data structures, and = they are not mentioned/referenced in draft-ecall. >=20 > Regards, >=20 > Christer >=20 > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Brian = Rosen > Sent: 30 August 2016 00:02 > To: Dale R. Worley > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Using an INFO package in = draft-ietf-ecrit-ecall-11 >=20 > Verrrry interesting. >=20 > About the only part I don=E2=80=99t get is the Content Disposition of = Info-Package on the whole body, no Content Disposition on the MSD, and = then a different Content Disposition on the DeviceInfo block. >=20 > But I think it would be fairly easy to deal with if you were expecting = it, which is what an implementation that handled eCall (and thus the = emergencyCallData.eCall.MSD part) would do. >=20 > It=E2=80=99s clever, I will say that. >=20 > Brian >=20 >> On Aug 29, 2016, at 11:49 AM, Dale R. Worley = wrote: >>=20 >> TL;DR: If the body for an emergencyCallData.eCall.MSD info package = is=20 >> defined correctly, we can organize the data in an INFO request the=20 >> same way that we do in an INVITE request and still follow the info=20 >> package rules strictly. >>=20 >>=20 >> After asking around, I have learned that my previous message on this=20= >> subject severely buried the lead: The useful point followed a long=20= >> message example, which itself followed several pages of recap of the=20= >> points in question. As far as I can tell, nobody had the stamina to=20= >> read that far, and in retrospect, I don't blame them. >>=20 >> So this time, I'm going recap my proposal and put the important = points >> *first*: >>=20 >> It it possible to define an info package for use by >> draft-ietf-ecrit-ecall-11 that includes all of the Additional Data=20 >> (RFC >> 7852) in a way that strictly follows the rules for info packages (RFC=20= >> 6086), but also uses the same data format used by initial Additional=20= >> Data reporting. This solves the dilemma that we have been = discussing. >>=20 >> The key is to define the info package properly. The info package=20 >> definition is: >>=20 >> The body for an emergencyCallData.eCall.MSD info package is: >>=20 >> - either an application/emergencyCallData.eCall.MSD+per (containing >> the MSD), or >>=20 >> - a multipart body containing exactly: >>=20 >> - exactly one application/emergencyCallData.eCall.MSD+per part >> (containing the MSD), >>=20 >> - zero or more application/EmergencyCallData.DeviceInfo+xml >> parts (containing Additional Data), and >>=20 >> - zero or one application/pidf+xml part (containing geolocation >> data). >>=20 >> This allows all of the information items that we want to carry in the=20= >> INFO message to be part of one info package, which is the body of the=20= >> INFO message. >>=20 >> In draft-ietf-ecrit-ecall-11 usage, all body parts will typically be=20= >> pointed to by a Geolocation or Call-Info header. >>=20 >> A typical example is this INFO request. I've assembled the example = by=20 >> inserting the Additional Data from an example in RFC 7852 into the=20 >> response INFO request in draft-ietf-ecrit-ecall-11: >>=20 >> INFO urn:service:sos.ecall.automatic SIP/2.0 >> To: urn:service:sos.ecall.automatic >> From: ;tag=3D9fxced76sl >> Call-ID: 3848276298220188511@atlanta.example.com >> Call-Info: ; >> purpose=3DemergencyCallData.eCall.MSD >> Call-Info: >> ;purpose=3Dicon, >> ;purpose=3Dinfo, >> >> ;purpose=3DEmergencyCallData.ProviderInfo, >> >> ;purpose=3DEmergencyCallData.DeviceInfo >> Geolocation: >> Geolocation-Routing: yes >> Accept: application/sdp, application/pidf+xml, >> application/emergencyCallData.eCall.control+xml >> CSeq: 51862 INFO >> Info-Package: emergencyCallData.eCall.MSD >> Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, >> SUBSCRIBE, NOTIFY, UPDATE >> Content-Disposition: info-package >> Content-Transfer-Encoding: binary >> Content-Type: multipart/mixed; boundary=3Dboundary1 >> Content-Length: ... >>=20 >> --boundary1 >> Content-Type: application/emergencyCallData.eCall.MSD+per >> Content-ID: 4567890123@atlanta.example.com >>=20 >> ...MSD in ASN.1 PER encoding goes here... >>=20 >> --boundary1 >> Content-Type: application/EmergencyCallData.DeviceInfo+xml >> Content-ID: <0123456789@atlanta.example.com> >> Content-Disposition: by-reference;handling=3Doptional >>=20 >> >> > xmlns:dev=3D >> "urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo"> >> ... >> >>=20 >> --boundary1 >> Content-Type: application/EmergencyCallData.ProviderInfo+xml >> Content-ID: <1234567890@atlanta.example.com> >> Content-Disposition: by-reference;handling=3Doptional >>=20 >> >> > xmlns:pi=3D >> "urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo"> >> ... >> >> --boundary1-- >>=20 >> Note the absence of a Recv-Info header (which is forbidden in INFO=20 >> requests (RFC 6086 section 4.2.1). >>=20 >> Note the positioning of the Info-Package header as applying to the=20 >> entire body. >>=20 >> As indicated by the Info-Package header, the entire multipart body is=20= >> the body of the info package. The info package body includes all of=20= >> the information contained in the body, including the MSD and the=20 >> Additional Data, thus strictly following RFC 6086. >>=20 >> Three of the Call-Info header values, >> cid:4567890123@atlanta.example.com; >> purpose=3DemergencyCallData.eCall.MSD >> >> ;purpose=3DEmergencyCallData.ProviderInfo >> >> ;purpose=3DEmergencyCallData.DeviceInfo >> point to body parts within the info package that provide Additional=20= >> Data. >>=20 >> The Geolocation header points to an external application/pidf+xml=20 >> resource. But it could contain a cid: URL pointing to an additional=20= >> application/pidf+xml body part. >>=20 >> Note that the layout of the body parts is the same as is used in an=20= >> INFO request containing Additional Data. (Compare with the example = in=20 >> RFC >> 7852 section 7.) >>=20 >> This implies that the logic for inserting an additional Additional=20 >> Data part into an INFO request is essentially the same as the logic=20= >> for inserting it into an INVITE request. >>=20 >> Dale >>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail=_967CBF69-9AEF-45F7-B34A-C53D31E1D0AB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
No, this = really does return the MSD in an info block, but it also has the = Additional Data header pointing to the body part that contains the = MSD.

eCall itself doesn=E2=80=99t use = the other structures, but we would like to see them in any emergency = call, so showing how they would be carried is useful.

Brian

On Aug 29, 2016, at 3:10 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

I = may have missed something, but to me this seems more or less like what = has already been discussed in ECRIT: associate the MSD inside an info = package, but still use Call-Info to point to it.

As a side note, it's important to separate the *transport = mechanism* defined in Additional Data (chapter 6 of RFC 7852), and the = *data structures* (Device Information) defined in Additional Data. There = is currently no requirement for ecall to support the data structures, = and they are not mentioned/referenced in draft-ecall.

Regards,

Christer

-----Original Message-----
From: = sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Brian = Rosen
Sent: 30 August 2016 00:02
To: Dale R. = Worley <worley@ariadne.com>
Cc: sipcore@ietf.org
Subject: Re: [sipcore] Using an INFO package in = draft-ietf-ecrit-ecall-11

Verrrry = interesting.

About the only part I don=E2=80=99= t get is the Content Disposition of Info-Package on the whole body, no = Content Disposition on the MSD, and then a different Content Disposition = on the DeviceInfo block.

But I think it = would be fairly easy to deal with if you were expecting it, which is = what an implementation that handled eCall (and thus the = emergencyCallData.eCall.MSD part) would do.

It=E2=80=99s clever, I will say that.

Brian

On Aug 29, 2016, at 11:49 AM, Dale R. Worley <worley@ariadne.com> = wrote:

TL;DR:  If the body for an = emergencyCallData.eCall.MSD info package is
defined = correctly, we can organize the data in an INFO request the
same way that we do in an INVITE request and still follow the = info
package rules strictly.


After asking around, I have learned that my = previous message on this
subject severely buried the = lead:  The useful point followed a long
message = example, which itself followed several pages of recap of the
points in question.  As far as I can tell, nobody had = the stamina to
read that far, and in retrospect, I don't = blame them.

So this time, I'm going recap = my proposal and put the important points
*first*:

It it possible to define an info package for = use by
draft-ietf-ecrit-ecall-11 that includes all of the = Additional Data
(RFC
7852) in a way that = strictly follows the rules for info packages (RFC
6086), = but also uses the same data format used by initial Additional
Data reporting.  This solves the dilemma that we have = been discussing.

The key is to define the = info package properly.  The info package
definition = is:

  The body for an = emergencyCallData.eCall.MSD info package is:

=   - either an application/emergencyCallData.eCall.MSD+per = (containing
    the MSD), or

  - a multipart body containing = exactly:

=       - exactly one = application/emergencyCallData.eCall.MSD+per part
=         (containing the MSD),

      - zero or = more application/EmergencyCallData.DeviceInfo+xml
=         parts (containing = Additional Data), and

=       - zero or one application/pidf+xml = part (containing geolocation
=         data).

This allows all of the information items that we want to = carry in the
INFO message to be part of one info package, = which is the body of the
INFO message.

In draft-ietf-ecrit-ecall-11 usage, all body parts will = typically be
pointed to by a Geolocation or Call-Info = header.

A typical example is this INFO = request.  I've assembled the example by
inserting = the Additional Data from an example in RFC 7852 into the
response INFO request in draft-ietf-ecrit-ecall-11:

    INFO = urn:service:sos.ecall.automatic SIP/2.0
=     To: urn:service:sos.ecall.automatic
=     From: <sip:+13145551111@example.com>;tag=3D9fxced76sl
    Call-ID: 3848276298220188511@atlanta.example.com
=     Call-Info: <cid:4567890123@atlanta.example.com>;
=             &n= bsp;  purpose=3DemergencyCallData.eCall.MSD
=     Call-Info: <http://wwww.example.com/hannes/photo.jpg>
= =             &n= bsp;      ;purpose=3Dicon,
=       <http://www.example.com/hannes/> ;purpose=3Dinfo,
      <cid:1234567890@atlanta.example.com>
=           ;purpose=3DEme= rgencyCallData.ProviderInfo,
=       <cid:0123456789@atlanta.example.com>
=           ;purpose=3DEme= rgencyCallData.DeviceInfo
=     Geolocation: <https://ls.example.net:9768/357yc6s64ceyoiuy5ax3o>
    Geolocation-Routing: yes
    Accept: application/sdp, = application/pidf+xml,
=             ap= plication/emergencyCallData.eCall.control+xml
=     CSeq: 51862 INFO
=     Info-Package: emergencyCallData.eCall.MSD
    Allow: INVITE, ACK, PRACK, INFO, = OPTIONS, CANCEL, REFER, BYE,
=            SUBSCRIB= E, NOTIFY, UPDATE
=     Content-Disposition: info-package
=     Content-Transfer-Encoding: binary
=     Content-Type: multipart/mixed; = boundary=3Dboundary1
=     Content-Length: ...

=     --boundary1
=     Content-Type: = application/emergencyCallData.eCall.MSD+per
=     Content-ID: 4567890123@atlanta.example.com

         ...MSD = in ASN.1 PER encoding goes here...

=     --boundary1
=     Content-Type: = application/EmergencyCallData.DeviceInfo+xml
=     Content-ID: <0123456789@atlanta.example.com>
=     Content-Disposition: = by-reference;handling=3Doptional

=     <?xml version=3D"1.0" = encoding=3D"UTF-8"?>
=     <dev:EmergencyCallData.DeviceInfo
=          xmlns:dev=3D
=          "urn:ietf:params:xml= :ns:EmergencyCallData:DeviceInfo">
=         ...
=     </dev:EmergencyCallData.DeviceInfo>

    --boundary1
    Content-Type: = application/EmergencyCallData.ProviderInfo+xml
=     Content-ID: <1234567890@atlanta.example.com>
=     Content-Disposition: = by-reference;handling=3Doptional

=     <?xml version=3D"1.0" = encoding=3D"UTF-8"?>
=     <pi:EmergencyCallData.ProviderInfo
       xmlns:pi=3D
=           "urn:ietf:para= ms:xml:ns:EmergencyCallData:ProviderInfo">
=         ...
=     </pi:EmergencyCallData.ProviderInfo>
    --boundary1--

Note the absence of a Recv-Info header (which is forbidden in = INFO
requests (RFC 6086 section 4.2.1).

Note the positioning of the Info-Package header as applying = to the
entire body.

As = indicated by the Info-Package header, the entire multipart body is
the body of the info package.  The info package body = includes all of
the information contained in the body, = including the MSD and the
Additional Data, thus strictly = following RFC 6086.

Three of the Call-Info = header values,
      cid:4567890123@atlanta.example.com;
=             &n= bsp;  purpose=3DemergencyCallData.eCall.MSD
=       <cid:1234567890@atlanta.example.com>
=           ;purpose=3DEme= rgencyCallData.ProviderInfo
=       <cid:0123456789@atlanta.example.com>
=           ;purpose=3DEme= rgencyCallData.DeviceInfo
point to body parts within the = info package that provide Additional
Data.

The Geolocation header points to an external = application/pidf+xml
resource.  But it could contain = a cid: URL pointing to an additional
application/pidf+xml = body part.

Note that the layout of the body = parts is the same as is used in an
INFO request = containing Additional Data.  (Compare with the example in
RFC
7852 section 7.)

This implies that the logic for inserting an additional = Additional
Data part into an INFO request is essentially = the same as the logic
for inserting it into an INVITE = request.

Dale

_______________________________________________
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

= --Apple-Mail=_967CBF69-9AEF-45F7-B34A-C53D31E1D0AB-- From nobody Mon Aug 29 22:28:05 2016 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 D6B1B12D11A for ; Mon, 29 Aug 2016 22:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ploOZ7ZqHxOc for ; Mon, 29 Aug 2016 22:28:02 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BE7212D0FF for ; Mon, 29 Aug 2016 22:28:02 -0700 (PDT) X-AuditID: c1b4fb30-ad3ff700000009f9-50-57c5195f83ab Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by (Symantec Mail Security) with SMTP id E5.2B.02553.F5915C75; Tue, 30 Aug 2016 07:28:00 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0301.000; Tue, 30 Aug 2016 07:27:59 +0200 From: Christer Holmberg To: Brian Rosen Thread-Topic: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 Thread-Index: AQHSAiYM+pjwWhmVIEetajd/MHhvMaBgS2qAgAAv+uD//++FgIAAjvfg Date: Tue, 30 Aug 2016 05:27:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC72B1C@ESESSMB209.ericsson.se> References: <87eg572yxn.fsf@hobgoblin.ariadne.com> <76D1BB4B-CE62-42BD-A694-E5140341DD7E@salsgiver.com> <7594FB04B1934943A5C02806D1A2204B4BC72486@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BC72B1CESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsUyM2K7t26C5NFwg4cbxSymHdvAbvH1xyY2 i5cnyhyYPSbv/8rssWTJTyaPRYd+sAYwR3HZpKTmZJalFunbJXBlLHupXrDoF2PFrJlSDYw3 PjN2MXJySAiYSGxY1MjWxcjFISSwnlFixcWdzBDOEkaJj61LWbsYOTjYBCwkuv9pgzSICChJ rJ24gQ3EZhYIkmj+vIIRpERYwFPixcoCiBIvidsvHrKDhEUE3CSW/uQECbMIqErcmfiWBcTm FfCVmHOtkRVi0xOgTdeugt3DKeAocenqY1YQm1FATOL7qTVMEKvEJW49mc8EcbOAxJI955kh bFGJl4//sULYShKNS56wQtTnSzw6uokNYpmgxMmZT1gmMIrMQjJqFpKyWUjKZgGdzSygKbF+ lz5EiaLElO6H7BC2hkTrnLnsyOILGNlXMYoWpxYn5aYbGemlFmUmFxfn5+nlpZZsYgRG2cEt vw12ML587niIUYCDUYmHV6HiSLgQa2JZcWXuIUYJDmYlEV450aPhQrwpiZVVqUX58UWlOanF hxilOViUxHn9XyqGCwmkJ5akZqemFqQWwWSZODiBsRg92SZKfVfNn7frqmbtWPLEY+VuyZ7O qq5wvay0sxUC/KnvL1/4Mm/avTr2lXa7PsQ5pDwrz91q6rXN2OTSvhi7N4t+CtstevNM59Xb idxd2a+s7PakP0rg/3I6kL/7oZ+B1+/IUxFatxw0i1j3/yv3e6nw7eOxYLkD76ZfVxYIPjTv kNlu14dKLMUZiYZazEXFiQD1wT7UrgIAAA== Archived-At: Cc: "Dale R. Worley" , "sipcore@ietf.org" Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 05:28:05 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BC72B1CESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQo+Tm8sIHRoaXMgcmVhbGx5IGRvZXMgcmV0dXJuIHRoZSBNU0QgaW4gYW4gaW5mbyBibG9jaywg YnV0IGl0IGFsc28gaGFzIHRoZSA+QWRkaXRpb25hbCBEYXRhIGhlYWRlciBwb2ludGluZyB0byB0 aGUgYm9keSBwYXJ0IHRoYXQgY29udGFpbnMgdGhlIE1TRC4NCg0KVGhhdOKAmXMgd2hhdCBJIHNh aWQgOikNCg0KQW5kLCBob3cgaXMgdGhhdCBkaWZmZXJlbnQgZnJvbSB3aGF0IGlzIGN1cnJlbnRs eSBzcGVjaWZpZWQgaW4gZHJhZnQtZWNhbGwtMTE/DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoN Cg0KDQpPbiBBdWcgMjksIDIwMTYsIGF0IDM6MTAgUE0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJp c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNz c29uLmNvbT4+IHdyb3RlOg0KDQpJIG1heSBoYXZlIG1pc3NlZCBzb21ldGhpbmcsIGJ1dCB0byBt ZSB0aGlzIHNlZW1zIG1vcmUgb3IgbGVzcyBsaWtlIHdoYXQgaGFzIGFscmVhZHkgYmVlbiBkaXNj dXNzZWQgaW4gRUNSSVQ6IGFzc29jaWF0ZSB0aGUgTVNEIGluc2lkZSBhbiBpbmZvIHBhY2thZ2Us IGJ1dCBzdGlsbCB1c2UgQ2FsbC1JbmZvIHRvIHBvaW50IHRvIGl0Lg0KDQpBcyBhIHNpZGUgbm90 ZSwgaXQncyBpbXBvcnRhbnQgdG8gc2VwYXJhdGUgdGhlICp0cmFuc3BvcnQgbWVjaGFuaXNtKiBk ZWZpbmVkIGluIEFkZGl0aW9uYWwgRGF0YSAoY2hhcHRlciA2IG9mIFJGQyA3ODUyKSwgYW5kIHRo ZSAqZGF0YSBzdHJ1Y3R1cmVzKiAoRGV2aWNlIEluZm9ybWF0aW9uKSBkZWZpbmVkIGluIEFkZGl0 aW9uYWwgRGF0YS4gVGhlcmUgaXMgY3VycmVudGx5IG5vIHJlcXVpcmVtZW50IGZvciBlY2FsbCB0 byBzdXBwb3J0IHRoZSBkYXRhIHN0cnVjdHVyZXMsIGFuZCB0aGV5IGFyZSBub3QgbWVudGlvbmVk L3JlZmVyZW5jZWQgaW4gZHJhZnQtZWNhbGwuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzaXBjb3JlIFttYWlsdG86c2lwY29yZS1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQnJpYW4gUm9zZW4NClNlbnQ6IDMwIEF1Z3Vz dCAyMDE2IDAwOjAyDQpUbzogRGFsZSBSLiBXb3JsZXkgPHdvcmxleUBhcmlhZG5lLmNvbTxtYWls dG86d29ybGV5QGFyaWFkbmUuY29tPj4NCkNjOiBzaXBjb3JlQGlldGYub3JnPG1haWx0bzpzaXBj b3JlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBVc2luZyBhbiBJTkZPIHBhY2th Z2UgaW4gZHJhZnQtaWV0Zi1lY3JpdC1lY2FsbC0xMQ0KDQpWZXJycnJ5IGludGVyZXN0aW5nLg0K DQpBYm91dCB0aGUgb25seSBwYXJ0IEkgZG9u4oCZdCBnZXQgaXMgdGhlIENvbnRlbnQgRGlzcG9z aXRpb24gb2YgSW5mby1QYWNrYWdlIG9uIHRoZSB3aG9sZSBib2R5LCBubyBDb250ZW50IERpc3Bv c2l0aW9uIG9uIHRoZSBNU0QsIGFuZCB0aGVuIGEgZGlmZmVyZW50IENvbnRlbnQgRGlzcG9zaXRp b24gb24gdGhlIERldmljZUluZm8gYmxvY2suDQoNCkJ1dCBJIHRoaW5rIGl0IHdvdWxkIGJlIGZh aXJseSBlYXN5IHRvIGRlYWwgd2l0aCBpZiB5b3Ugd2VyZSBleHBlY3RpbmcgaXQsIHdoaWNoIGlz IHdoYXQgYW4gaW1wbGVtZW50YXRpb24gdGhhdCBoYW5kbGVkIGVDYWxsIChhbmQgdGh1cyB0aGUg ZW1lcmdlbmN5Q2FsbERhdGEuZUNhbGwuTVNEIHBhcnQpIHdvdWxkIGRvLg0KDQpJdOKAmXMgY2xl dmVyLCBJIHdpbGwgc2F5IHRoYXQuDQoNCkJyaWFuDQoNCg0KT24gQXVnIDI5LCAyMDE2LCBhdCAx MTo0OSBBTSwgRGFsZSBSLiBXb3JsZXkgPHdvcmxleUBhcmlhZG5lLmNvbTxtYWlsdG86d29ybGV5 QGFyaWFkbmUuY29tPj4gd3JvdGU6DQoNClRMO0RSOiAgSWYgdGhlIGJvZHkgZm9yIGFuIGVtZXJn ZW5jeUNhbGxEYXRhLmVDYWxsLk1TRCBpbmZvIHBhY2thZ2UgaXMNCmRlZmluZWQgY29ycmVjdGx5 LCB3ZSBjYW4gb3JnYW5pemUgdGhlIGRhdGEgaW4gYW4gSU5GTyByZXF1ZXN0IHRoZQ0Kc2FtZSB3 YXkgdGhhdCB3ZSBkbyBpbiBhbiBJTlZJVEUgcmVxdWVzdCBhbmQgc3RpbGwgZm9sbG93IHRoZSBp bmZvDQpwYWNrYWdlIHJ1bGVzIHN0cmljdGx5Lg0KDQoNCkFmdGVyIGFza2luZyBhcm91bmQsIEkg aGF2ZSBsZWFybmVkIHRoYXQgbXkgcHJldmlvdXMgbWVzc2FnZSBvbiB0aGlzDQpzdWJqZWN0IHNl dmVyZWx5IGJ1cmllZCB0aGUgbGVhZDogIFRoZSB1c2VmdWwgcG9pbnQgZm9sbG93ZWQgYSBsb25n DQptZXNzYWdlIGV4YW1wbGUsIHdoaWNoIGl0c2VsZiBmb2xsb3dlZCBzZXZlcmFsIHBhZ2VzIG9m IHJlY2FwIG9mIHRoZQ0KcG9pbnRzIGluIHF1ZXN0aW9uLiAgQXMgZmFyIGFzIEkgY2FuIHRlbGws IG5vYm9keSBoYWQgdGhlIHN0YW1pbmEgdG8NCnJlYWQgdGhhdCBmYXIsIGFuZCBpbiByZXRyb3Nw ZWN0LCBJIGRvbid0IGJsYW1lIHRoZW0uDQoNClNvIHRoaXMgdGltZSwgSSdtIGdvaW5nIHJlY2Fw IG15IHByb3Bvc2FsIGFuZCBwdXQgdGhlIGltcG9ydGFudCBwb2ludHMNCipmaXJzdCo6DQoNCkl0 IGl0IHBvc3NpYmxlIHRvIGRlZmluZSBhbiBpbmZvIHBhY2thZ2UgZm9yIHVzZSBieQ0KZHJhZnQt aWV0Zi1lY3JpdC1lY2FsbC0xMSB0aGF0IGluY2x1ZGVzIGFsbCBvZiB0aGUgQWRkaXRpb25hbCBE YXRhDQooUkZDDQo3ODUyKSBpbiBhIHdheSB0aGF0IHN0cmljdGx5IGZvbGxvd3MgdGhlIHJ1bGVz IGZvciBpbmZvIHBhY2thZ2VzIChSRkMNCjYwODYpLCBidXQgYWxzbyB1c2VzIHRoZSBzYW1lIGRh dGEgZm9ybWF0IHVzZWQgYnkgaW5pdGlhbCBBZGRpdGlvbmFsDQpEYXRhIHJlcG9ydGluZy4gIFRo aXMgc29sdmVzIHRoZSBkaWxlbW1hIHRoYXQgd2UgaGF2ZSBiZWVuIGRpc2N1c3NpbmcuDQoNClRo ZSBrZXkgaXMgdG8gZGVmaW5lIHRoZSBpbmZvIHBhY2thZ2UgcHJvcGVybHkuICBUaGUgaW5mbyBw YWNrYWdlDQpkZWZpbml0aW9uIGlzOg0KDQogIFRoZSBib2R5IGZvciBhbiBlbWVyZ2VuY3lDYWxs RGF0YS5lQ2FsbC5NU0QgaW5mbyBwYWNrYWdlIGlzOg0KDQogIC0gZWl0aGVyIGFuIGFwcGxpY2F0 aW9uL2VtZXJnZW5jeUNhbGxEYXRhLmVDYWxsLk1TRCtwZXIgKGNvbnRhaW5pbmcNCiAgICB0aGUg TVNEKSwgb3INCg0KICAtIGEgbXVsdGlwYXJ0IGJvZHkgY29udGFpbmluZyBleGFjdGx5Og0KDQog ICAgICAtIGV4YWN0bHkgb25lIGFwcGxpY2F0aW9uL2VtZXJnZW5jeUNhbGxEYXRhLmVDYWxsLk1T RCtwZXIgcGFydA0KICAgICAgICAoY29udGFpbmluZyB0aGUgTVNEKSwNCg0KICAgICAgLSB6ZXJv IG9yIG1vcmUgYXBwbGljYXRpb24vRW1lcmdlbmN5Q2FsbERhdGEuRGV2aWNlSW5mbyt4bWwNCiAg ICAgICAgcGFydHMgKGNvbnRhaW5pbmcgQWRkaXRpb25hbCBEYXRhKSwgYW5kDQoNCiAgICAgIC0g emVybyBvciBvbmUgYXBwbGljYXRpb24vcGlkZit4bWwgcGFydCAoY29udGFpbmluZyBnZW9sb2Nh dGlvbg0KICAgICAgICBkYXRhKS4NCg0KVGhpcyBhbGxvd3MgYWxsIG9mIHRoZSBpbmZvcm1hdGlv biBpdGVtcyB0aGF0IHdlIHdhbnQgdG8gY2FycnkgaW4gdGhlDQpJTkZPIG1lc3NhZ2UgdG8gYmUg cGFydCBvZiBvbmUgaW5mbyBwYWNrYWdlLCB3aGljaCBpcyB0aGUgYm9keSBvZiB0aGUNCklORk8g bWVzc2FnZS4NCg0KSW4gZHJhZnQtaWV0Zi1lY3JpdC1lY2FsbC0xMSB1c2FnZSwgYWxsIGJvZHkg cGFydHMgd2lsbCB0eXBpY2FsbHkgYmUNCnBvaW50ZWQgdG8gYnkgYSBHZW9sb2NhdGlvbiBvciBD YWxsLUluZm8gaGVhZGVyLg0KDQpBIHR5cGljYWwgZXhhbXBsZSBpcyB0aGlzIElORk8gcmVxdWVz dC4gIEkndmUgYXNzZW1ibGVkIHRoZSBleGFtcGxlIGJ5DQppbnNlcnRpbmcgdGhlIEFkZGl0aW9u YWwgRGF0YSBmcm9tIGFuIGV4YW1wbGUgaW4gUkZDIDc4NTIgaW50byB0aGUNCnJlc3BvbnNlIElO Rk8gcmVxdWVzdCBpbiBkcmFmdC1pZXRmLWVjcml0LWVjYWxsLTExOg0KDQogICAgSU5GTyB1cm46 c2VydmljZTpzb3MuZWNhbGwuYXV0b21hdGljIFNJUC8yLjANCiAgICBUbzogdXJuOnNlcnZpY2U6 c29zLmVjYWxsLmF1dG9tYXRpYw0KICAgIEZyb206IDxzaXA6KzEzMTQ1NTUxMTExQGV4YW1wbGUu Y29tPjt0YWc9OWZ4Y2VkNzZzbA0KICAgIENhbGwtSUQ6IDM4NDgyNzYyOTgyMjAxODg1MTFAYXRs YW50YS5leGFtcGxlLmNvbTxtYWlsdG86Mzg0ODI3NjI5ODIyMDE4ODUxMUBhdGxhbnRhLmV4YW1w bGUuY29tPg0KICAgIENhbGwtSW5mbzogPGNpZDo0NTY3ODkwMTIzQGF0bGFudGEuZXhhbXBsZS5j b20+Ow0KICAgICAgICAgICAgICAgcHVycG9zZT1lbWVyZ2VuY3lDYWxsRGF0YS5lQ2FsbC5NU0QN CiAgICBDYWxsLUluZm86IDxodHRwOi8vd3d3dy5leGFtcGxlLmNvbS9oYW5uZXMvcGhvdG8uanBn Pg0KICAgICAgICAgICAgICAgICAgIDtwdXJwb3NlPWljb24sDQogICAgICA8aHR0cDovL3d3dy5l eGFtcGxlLmNvbS9oYW5uZXMvPiA7cHVycG9zZT1pbmZvLA0KICAgICAgPGNpZDoxMjM0NTY3ODkw QGF0bGFudGEuZXhhbXBsZS5jb20+DQogICAgICAgICAgO3B1cnBvc2U9RW1lcmdlbmN5Q2FsbERh dGEuUHJvdmlkZXJJbmZvLA0KICAgICAgPGNpZDowMTIzNDU2Nzg5QGF0bGFudGEuZXhhbXBsZS5j b20+DQogICAgICAgICAgO3B1cnBvc2U9RW1lcmdlbmN5Q2FsbERhdGEuRGV2aWNlSW5mbw0KICAg IEdlb2xvY2F0aW9uOiA8aHR0cHM6Ly9scy5leGFtcGxlLm5ldDo5NzY4LzM1N3ljNnM2NGNleW9p dXk1YXgzbz4NCiAgICBHZW9sb2NhdGlvbi1Sb3V0aW5nOiB5ZXMNCiAgICBBY2NlcHQ6IGFwcGxp Y2F0aW9uL3NkcCwgYXBwbGljYXRpb24vcGlkZit4bWwsDQogICAgICAgICAgICBhcHBsaWNhdGlv bi9lbWVyZ2VuY3lDYWxsRGF0YS5lQ2FsbC5jb250cm9sK3htbA0KICAgIENTZXE6IDUxODYyIElO Rk8NCiAgICBJbmZvLVBhY2thZ2U6IGVtZXJnZW5jeUNhbGxEYXRhLmVDYWxsLk1TRA0KICAgIEFs bG93OiBJTlZJVEUsIEFDSywgUFJBQ0ssIElORk8sIE9QVElPTlMsIENBTkNFTCwgUkVGRVIsIEJZ RSwNCiAgICAgICAgICAgU1VCU0NSSUJFLCBOT1RJRlksIFVQREFURQ0KICAgIENvbnRlbnQtRGlz cG9zaXRpb246IGluZm8tcGFja2FnZQ0KICAgIENvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IGJp bmFyeQ0KICAgIENvbnRlbnQtVHlwZTogbXVsdGlwYXJ0L21peGVkOyBib3VuZGFyeT1ib3VuZGFy eTENCiAgICBDb250ZW50LUxlbmd0aDogLi4uDQoNCiAgICAtLWJvdW5kYXJ5MQ0KICAgIENvbnRl bnQtVHlwZTogYXBwbGljYXRpb24vZW1lcmdlbmN5Q2FsbERhdGEuZUNhbGwuTVNEK3Blcg0KICAg IENvbnRlbnQtSUQ6IDQ1Njc4OTAxMjNAYXRsYW50YS5leGFtcGxlLmNvbTxtYWlsdG86NDU2Nzg5 MDEyM0BhdGxhbnRhLmV4YW1wbGUuY29tPg0KDQogICAgICAgICAuLi5NU0QgaW4gQVNOLjEgUEVS IGVuY29kaW5nIGdvZXMgaGVyZS4uLg0KDQogICAgLS1ib3VuZGFyeTENCiAgICBDb250ZW50LVR5 cGU6IGFwcGxpY2F0aW9uL0VtZXJnZW5jeUNhbGxEYXRhLkRldmljZUluZm8reG1sDQogICAgQ29u dGVudC1JRDogPDAxMjM0NTY3ODlAYXRsYW50YS5leGFtcGxlLmNvbTxtYWlsdG86MDEyMzQ1Njc4 OUBhdGxhbnRhLmV4YW1wbGUuY29tPj4NCiAgICBDb250ZW50LURpc3Bvc2l0aW9uOiBieS1yZWZl cmVuY2U7aGFuZGxpbmc9b3B0aW9uYWwNCg0KICAgIDw/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rp bmc9IlVURi04Ij8+DQogICAgPGRldjpFbWVyZ2VuY3lDYWxsRGF0YS5EZXZpY2VJbmZvDQogICAg ICAgICB4bWxuczpkZXY9DQogICAgICAgICAidXJuOmlldGY6cGFyYW1zOnhtbDpuczpFbWVyZ2Vu Y3lDYWxsRGF0YTpEZXZpY2VJbmZvIj4NCiAgICAgICAgLi4uDQogICAgPC9kZXY6RW1lcmdlbmN5 Q2FsbERhdGEuRGV2aWNlSW5mbz4NCg0KICAgIC0tYm91bmRhcnkxDQogICAgQ29udGVudC1UeXBl OiBhcHBsaWNhdGlvbi9FbWVyZ2VuY3lDYWxsRGF0YS5Qcm92aWRlckluZm8reG1sDQogICAgQ29u dGVudC1JRDogPDEyMzQ1Njc4OTBAYXRsYW50YS5leGFtcGxlLmNvbTxtYWlsdG86MTIzNDU2Nzg5 MEBhdGxhbnRhLmV4YW1wbGUuY29tPj4NCiAgICBDb250ZW50LURpc3Bvc2l0aW9uOiBieS1yZWZl cmVuY2U7aGFuZGxpbmc9b3B0aW9uYWwNCg0KICAgIDw/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rp bmc9IlVURi04Ij8+DQogICAgPHBpOkVtZXJnZW5jeUNhbGxEYXRhLlByb3ZpZGVySW5mbw0KICAg ICAgIHhtbG5zOnBpPQ0KICAgICAgICAgICJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOkVtZXJnZW5j eUNhbGxEYXRhOlByb3ZpZGVySW5mbyI+DQogICAgICAgIC4uLg0KICAgIDwvcGk6RW1lcmdlbmN5 Q2FsbERhdGEuUHJvdmlkZXJJbmZvPg0KICAgIC0tYm91bmRhcnkxLS0NCg0KTm90ZSB0aGUgYWJz ZW5jZSBvZiBhIFJlY3YtSW5mbyBoZWFkZXIgKHdoaWNoIGlzIGZvcmJpZGRlbiBpbiBJTkZPDQpy ZXF1ZXN0cyAoUkZDIDYwODYgc2VjdGlvbiA0LjIuMSkuDQoNCk5vdGUgdGhlIHBvc2l0aW9uaW5n IG9mIHRoZSBJbmZvLVBhY2thZ2UgaGVhZGVyIGFzIGFwcGx5aW5nIHRvIHRoZQ0KZW50aXJlIGJv ZHkuDQoNCkFzIGluZGljYXRlZCBieSB0aGUgSW5mby1QYWNrYWdlIGhlYWRlciwgdGhlIGVudGly ZSBtdWx0aXBhcnQgYm9keSBpcw0KdGhlIGJvZHkgb2YgdGhlIGluZm8gcGFja2FnZS4gIFRoZSBp bmZvIHBhY2thZ2UgYm9keSBpbmNsdWRlcyBhbGwgb2YNCnRoZSBpbmZvcm1hdGlvbiBjb250YWlu ZWQgaW4gdGhlIGJvZHksIGluY2x1ZGluZyB0aGUgTVNEIGFuZCB0aGUNCkFkZGl0aW9uYWwgRGF0 YSwgdGh1cyBzdHJpY3RseSBmb2xsb3dpbmcgUkZDIDYwODYuDQoNClRocmVlIG9mIHRoZSBDYWxs LUluZm8gaGVhZGVyIHZhbHVlcywNCiAgICAgIGNpZDo0NTY3ODkwMTIzQGF0bGFudGEuZXhhbXBs ZS5jb207DQogICAgICAgICAgICAgICBwdXJwb3NlPWVtZXJnZW5jeUNhbGxEYXRhLmVDYWxsLk1T RA0KICAgICAgPGNpZDoxMjM0NTY3ODkwQGF0bGFudGEuZXhhbXBsZS5jb20+DQogICAgICAgICAg O3B1cnBvc2U9RW1lcmdlbmN5Q2FsbERhdGEuUHJvdmlkZXJJbmZvDQogICAgICA8Y2lkOjAxMjM0 NTY3ODlAYXRsYW50YS5leGFtcGxlLmNvbT4NCiAgICAgICAgICA7cHVycG9zZT1FbWVyZ2VuY3lD YWxsRGF0YS5EZXZpY2VJbmZvDQpwb2ludCB0byBib2R5IHBhcnRzIHdpdGhpbiB0aGUgaW5mbyBw YWNrYWdlIHRoYXQgcHJvdmlkZSBBZGRpdGlvbmFsDQpEYXRhLg0KDQpUaGUgR2VvbG9jYXRpb24g aGVhZGVyIHBvaW50cyB0byBhbiBleHRlcm5hbCBhcHBsaWNhdGlvbi9waWRmK3htbA0KcmVzb3Vy Y2UuICBCdXQgaXQgY291bGQgY29udGFpbiBhIGNpZDogVVJMIHBvaW50aW5nIHRvIGFuIGFkZGl0 aW9uYWwNCmFwcGxpY2F0aW9uL3BpZGYreG1sIGJvZHkgcGFydC4NCg0KTm90ZSB0aGF0IHRoZSBs YXlvdXQgb2YgdGhlIGJvZHkgcGFydHMgaXMgdGhlIHNhbWUgYXMgaXMgdXNlZCBpbiBhbg0KSU5G TyByZXF1ZXN0IGNvbnRhaW5pbmcgQWRkaXRpb25hbCBEYXRhLiAgKENvbXBhcmUgd2l0aCB0aGUg ZXhhbXBsZSBpbg0KUkZDDQo3ODUyIHNlY3Rpb24gNy4pDQoNClRoaXMgaW1wbGllcyB0aGF0IHRo ZSBsb2dpYyBmb3IgaW5zZXJ0aW5nIGFuIGFkZGl0aW9uYWwgQWRkaXRpb25hbA0KRGF0YSBwYXJ0 IGludG8gYW4gSU5GTyByZXF1ZXN0IGlzIGVzc2VudGlhbGx5IHRoZSBzYW1lIGFzIHRoZSBsb2dp Yw0KZm9yIGluc2VydGluZyBpdCBpbnRvIGFuIElOVklURSByZXF1ZXN0Lg0KDQpEYWxlDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzaXBjb3JlIG1h aWxpbmcgbGlzdA0Kc2lwY29yZUBpZXRmLm9yZzxtYWlsdG86c2lwY29yZUBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2lwY29yZSBtYWlsaW5nIGxp c3QNCnNpcGNvcmVAaWV0Zi5vcmc8bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg0K --_000_7594FB04B1934943A5C02806D1A2204B4BC72B1CESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBw dCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+Jmd0Ozwvc3Bhbj5ObywgdGhpcyByZWFsbHkgZG9lcyByZXR1cm4gdGhlIE1TRCBpbiBh biBpbmZvIGJsb2NrLCBidXQgaXQgYWxzbyBoYXMgdGhlDQo8c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+Jmd0Ozwvc3Bhbj5BZGRpdGlvbmFsIERhdGEgaGVhZGVyIHBvaW50aW5nIHRvIHRoZSBi b2R5IHBhcnQgdGhhdCBjb250YWlucyB0aGUgTVNELjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhdOKAmXMgd2hhdCBJIHNhaWQgOik8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFuZCwgaG93IGlzIHRo YXQgZGlmZmVyZW50IGZyb20gd2hhdCBpcyBjdXJyZW50bHkgc3BlY2lmaWVkIGluIGRyYWZ0LWVj YWxsLTExPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UmVnYXJk cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNocmlzdGVyPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiM1ODU2RDYiPjxicj4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBBdWcgMjksIDIwMTYsIGF0IDM6MTAgUE0sIENocmlz dGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgbWF5IGhhdmUgbWlz c2VkIHNvbWV0aGluZywgYnV0IHRvIG1lIHRoaXMgc2VlbXMgbW9yZSBvciBsZXNzIGxpa2Ugd2hh dCBoYXMgYWxyZWFkeSBiZWVuIGRpc2N1c3NlZCBpbiBFQ1JJVDogYXNzb2NpYXRlIHRoZSBNU0Qg aW5zaWRlIGFuIGluZm8gcGFja2FnZSwgYnV0IHN0aWxsIHVzZSBDYWxsLUluZm8gdG8gcG9pbnQg dG8gaXQuPGJyPg0KPGJyPg0KQXMgYSBzaWRlIG5vdGUsIGl0J3MgaW1wb3J0YW50IHRvIHNlcGFy YXRlIHRoZSAqdHJhbnNwb3J0IG1lY2hhbmlzbSogZGVmaW5lZCBpbiBBZGRpdGlvbmFsIERhdGEg KGNoYXB0ZXIgNiBvZiBSRkMgNzg1MiksIGFuZCB0aGUgKmRhdGEgc3RydWN0dXJlcyogKERldmlj ZSBJbmZvcm1hdGlvbikgZGVmaW5lZCBpbiBBZGRpdGlvbmFsIERhdGEuIFRoZXJlIGlzIGN1cnJl bnRseSBubyByZXF1aXJlbWVudCBmb3IgZWNhbGwgdG8gc3VwcG9ydCB0aGUgZGF0YQ0KIHN0cnVj dHVyZXMsIGFuZCB0aGV5IGFyZSBub3QgbWVudGlvbmVkL3JlZmVyZW5jZWQgaW4gZHJhZnQtZWNh bGwuPGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQo8YnI+DQpDaHJpc3Rlcjxicj4NCjxicj4NCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogc2lwY29yZSBbPGEgaHJlZj0ibWFp bHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRm Lm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBCcmlhbiBSb3Nlbjxicj4NClNlbnQ6IDMwIEF1Z3VzdCAy MDE2IDAwOjAyPGJyPg0KVG86IERhbGUgUi4gV29ybGV5ICZsdDs8YSBocmVmPSJtYWlsdG86d29y bGV5QGFyaWFkbmUuY29tIj53b3JsZXlAYXJpYWRuZS5jb208L2E+Jmd0Ozxicj4NCkNjOiA8YSBo cmVmPSJtYWlsdG86c2lwY29yZUBpZXRmLm9yZyI+c2lwY29yZUBpZXRmLm9yZzwvYT48YnI+DQpT dWJqZWN0OiBSZTogW3NpcGNvcmVdIFVzaW5nIGFuIElORk8gcGFja2FnZSBpbiBkcmFmdC1pZXRm LWVjcml0LWVjYWxsLTExPGJyPg0KPGJyPg0KVmVycnJyeSBpbnRlcmVzdGluZy48YnI+DQo8YnI+ DQpBYm91dCB0aGUgb25seSBwYXJ0IEkgZG9u4oCZdCBnZXQgaXMgdGhlIENvbnRlbnQgRGlzcG9z aXRpb24gb2YgSW5mby1QYWNrYWdlIG9uIHRoZSB3aG9sZSBib2R5LCBubyBDb250ZW50IERpc3Bv c2l0aW9uIG9uIHRoZSBNU0QsIGFuZCB0aGVuIGEgZGlmZmVyZW50IENvbnRlbnQgRGlzcG9zaXRp b24gb24gdGhlIERldmljZUluZm8gYmxvY2suPGJyPg0KPGJyPg0KQnV0IEkgdGhpbmsgaXQgd291 bGQgYmUgZmFpcmx5IGVhc3kgdG8gZGVhbCB3aXRoIGlmIHlvdSB3ZXJlIGV4cGVjdGluZyBpdCwg d2hpY2ggaXMgd2hhdCBhbiBpbXBsZW1lbnRhdGlvbiB0aGF0IGhhbmRsZWQgZUNhbGwgKGFuZCB0 aHVzIHRoZSBlbWVyZ2VuY3lDYWxsRGF0YS5lQ2FsbC5NU0QgcGFydCkgd291bGQgZG8uPGJyPg0K PGJyPg0KSXTigJlzIGNsZXZlciwgSSB3aWxsIHNheSB0aGF0Ljxicj4NCjxicj4NCkJyaWFuPGJy Pg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IEF1ZyAyOSwgMjAxNiwgYXQgMTE6NDkgQU0sIERhbGUgUi4gV29ybGV5ICZsdDs8YSBocmVmPSJt YWlsdG86d29ybGV5QGFyaWFkbmUuY29tIj53b3JsZXlAYXJpYWRuZS5jb208L2E+Jmd0OyB3cm90 ZTo8YnI+DQo8YnI+DQpUTDtEUjogJm5ic3A7SWYgdGhlIGJvZHkgZm9yIGFuIGVtZXJnZW5jeUNh bGxEYXRhLmVDYWxsLk1TRCBpbmZvIHBhY2thZ2UgaXMgPGJyPg0KZGVmaW5lZCBjb3JyZWN0bHks IHdlIGNhbiBvcmdhbml6ZSB0aGUgZGF0YSBpbiBhbiBJTkZPIHJlcXVlc3QgdGhlIDxicj4NCnNh bWUgd2F5IHRoYXQgd2UgZG8gaW4gYW4gSU5WSVRFIHJlcXVlc3QgYW5kIHN0aWxsIGZvbGxvdyB0 aGUgaW5mbyA8YnI+DQpwYWNrYWdlIHJ1bGVzIHN0cmljdGx5Ljxicj4NCjxicj4NCjxicj4NCkFm dGVyIGFza2luZyBhcm91bmQsIEkgaGF2ZSBsZWFybmVkIHRoYXQgbXkgcHJldmlvdXMgbWVzc2Fn ZSBvbiB0aGlzIDxicj4NCnN1YmplY3Qgc2V2ZXJlbHkgYnVyaWVkIHRoZSBsZWFkOiAmbmJzcDtU aGUgdXNlZnVsIHBvaW50IGZvbGxvd2VkIGEgbG9uZyA8YnI+DQptZXNzYWdlIGV4YW1wbGUsIHdo aWNoIGl0c2VsZiBmb2xsb3dlZCBzZXZlcmFsIHBhZ2VzIG9mIHJlY2FwIG9mIHRoZSA8YnI+DQpw b2ludHMgaW4gcXVlc3Rpb24uICZuYnNwO0FzIGZhciBhcyBJIGNhbiB0ZWxsLCBub2JvZHkgaGFk IHRoZSBzdGFtaW5hIHRvIDxicj4NCnJlYWQgdGhhdCBmYXIsIGFuZCBpbiByZXRyb3NwZWN0LCBJ IGRvbid0IGJsYW1lIHRoZW0uPGJyPg0KPGJyPg0KU28gdGhpcyB0aW1lLCBJJ20gZ29pbmcgcmVj YXAgbXkgcHJvcG9zYWwgYW5kIHB1dCB0aGUgaW1wb3J0YW50IHBvaW50czxicj4NCipmaXJzdCo6 PGJyPg0KPGJyPg0KSXQgaXQgcG9zc2libGUgdG8gZGVmaW5lIGFuIGluZm8gcGFja2FnZSBmb3Ig dXNlIGJ5PGJyPg0KZHJhZnQtaWV0Zi1lY3JpdC1lY2FsbC0xMSB0aGF0IGluY2x1ZGVzIGFsbCBv ZiB0aGUgQWRkaXRpb25hbCBEYXRhIDxicj4NCihSRkM8YnI+DQo3ODUyKSBpbiBhIHdheSB0aGF0 IHN0cmljdGx5IGZvbGxvd3MgdGhlIHJ1bGVzIGZvciBpbmZvIHBhY2thZ2VzIChSRkMgPGJyPg0K NjA4NiksIGJ1dCBhbHNvIHVzZXMgdGhlIHNhbWUgZGF0YSBmb3JtYXQgdXNlZCBieSBpbml0aWFs IEFkZGl0aW9uYWwgPGJyPg0KRGF0YSByZXBvcnRpbmcuICZuYnNwO1RoaXMgc29sdmVzIHRoZSBk aWxlbW1hIHRoYXQgd2UgaGF2ZSBiZWVuIGRpc2N1c3NpbmcuPGJyPg0KPGJyPg0KVGhlIGtleSBp cyB0byBkZWZpbmUgdGhlIGluZm8gcGFja2FnZSBwcm9wZXJseS4gJm5ic3A7VGhlIGluZm8gcGFj a2FnZSA8YnI+DQpkZWZpbml0aW9uIGlzOjxicj4NCjxicj4NCiZuYnNwOyZuYnNwO1RoZSBib2R5 IGZvciBhbiBlbWVyZ2VuY3lDYWxsRGF0YS5lQ2FsbC5NU0QgaW5mbyBwYWNrYWdlIGlzOjxicj4N Cjxicj4NCiZuYnNwOyZuYnNwOy0gZWl0aGVyIGFuIGFwcGxpY2F0aW9uL2VtZXJnZW5jeUNhbGxE YXRhLmVDYWxsLk1TRCYjNDM7cGVyIChjb250YWluaW5nPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7dGhlIE1TRCksIG9yPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7LSBhIG11bHRpcGFydCBi b2R5IGNvbnRhaW5pbmcgZXhhY3RseTo8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDstIGV4YWN0bHkgb25lIGFwcGxpY2F0aW9uL2VtZXJnZW5jeUNhbGxEYXRh LmVDYWxsLk1TRCYjNDM7cGVyIHBhcnQ8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsoY29udGFpbmluZyB0aGUgTVNEKSw8YnI+DQo8YnI+DQombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDstIHplcm8gb3IgbW9yZSBhcHBsaWNhdGlv bi9FbWVyZ2VuY3lDYWxsRGF0YS5EZXZpY2VJbmZvJiM0Mzt4bWw8YnI+DQombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtwYXJ0cyAoY29udGFpbmluZyBBZGRp dGlvbmFsIERhdGEpLCBhbmQ8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDstIHplcm8gb3Igb25lIGFwcGxpY2F0aW9uL3BpZGYmIzQzO3htbCBwYXJ0IChjb250 YWluaW5nIGdlb2xvY2F0aW9uPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ZGF0YSkuPGJyPg0KPGJyPg0KVGhpcyBhbGxvd3MgYWxsIG9mIHRoZSBp bmZvcm1hdGlvbiBpdGVtcyB0aGF0IHdlIHdhbnQgdG8gY2FycnkgaW4gdGhlIDxicj4NCklORk8g bWVzc2FnZSB0byBiZSBwYXJ0IG9mIG9uZSBpbmZvIHBhY2thZ2UsIHdoaWNoIGlzIHRoZSBib2R5 IG9mIHRoZSA8YnI+DQpJTkZPIG1lc3NhZ2UuPGJyPg0KPGJyPg0KSW4gZHJhZnQtaWV0Zi1lY3Jp dC1lY2FsbC0xMSB1c2FnZSwgYWxsIGJvZHkgcGFydHMgd2lsbCB0eXBpY2FsbHkgYmUgPGJyPg0K cG9pbnRlZCB0byBieSBhIEdlb2xvY2F0aW9uIG9yIENhbGwtSW5mbyBoZWFkZXIuPGJyPg0KPGJy Pg0KQSB0eXBpY2FsIGV4YW1wbGUgaXMgdGhpcyBJTkZPIHJlcXVlc3QuICZuYnNwO0kndmUgYXNz ZW1ibGVkIHRoZSBleGFtcGxlIGJ5IDxicj4NCmluc2VydGluZyB0aGUgQWRkaXRpb25hbCBEYXRh IGZyb20gYW4gZXhhbXBsZSBpbiBSRkMgNzg1MiBpbnRvIHRoZSA8YnI+DQpyZXNwb25zZSBJTkZP IHJlcXVlc3QgaW4gZHJhZnQtaWV0Zi1lY3JpdC1lY2FsbC0xMTo8YnI+DQo8YnI+DQombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDtJTkZPIHVybjpzZXJ2aWNlOnNvcy5lY2FsbC5hdXRvbWF0aWMgU0lQ LzIuMDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RvOiB1cm46c2VydmljZTpzb3MuZWNh bGwuYXV0b21hdGljPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7RnJvbTogJmx0OzxhIGhy ZWY9InNpcDomIzQzOzEzMTQ1NTUxMTExQGV4YW1wbGUuY29tIj5zaXA6JiM0MzsxMzE0NTU1MTEx MUBleGFtcGxlLmNvbTwvYT4mZ3Q7O3RhZz05ZnhjZWQ3NnNsPGJyPg0KJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Q2FsbC1JRDogPGEgaHJlZj0ibWFpbHRvOjM4NDgyNzYyOTgyMjAxODg1MTFAYXRs YW50YS5leGFtcGxlLmNvbSI+Mzg0ODI3NjI5ODIyMDE4ODUxMUBhdGxhbnRhLmV4YW1wbGUuY29t PC9hPjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0NhbGwtSW5mbzogJmx0OzxhIGhyZWY9 ImNpZDo0NTY3ODkwMTIzQGF0bGFudGEuZXhhbXBsZS5jb20iPmNpZDo0NTY3ODkwMTIzQGF0bGFu dGEuZXhhbXBsZS5jb208L2E+Jmd0Ozs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDtwdXJwb3NlPWVtZXJnZW5jeUNhbGxEYXRhLmVDYWxsLk1TRDxicj4NCiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwO0NhbGwtSW5mbzogJmx0OzxhIGhyZWY9Imh0dHA6Ly93d3d3LmV4YW1wbGUu Y29tL2hhbm5lcy9waG90by5qcGciPmh0dHA6Ly93d3d3LmV4YW1wbGUuY29tL2hhbm5lcy9waG90 by5qcGc8L2E+Jmd0Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOztwdXJwb3NlPWljb24sPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0OzxhIGhyZWY9Imh0dHA6Ly93d3cuZXhhbXBsZS5jb20vaGFu bmVzLyI+aHR0cDovL3d3dy5leGFtcGxlLmNvbS9oYW5uZXMvPC9hPiZndDsgO3B1cnBvc2U9aW5m byw8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7PGEgaHJlZj0i Y2lkOjEyMzQ1Njc4OTBAYXRsYW50YS5leGFtcGxlLmNvbSI+Y2lkOjEyMzQ1Njc4OTBAYXRsYW50 YS5leGFtcGxlLmNvbTwvYT4mZ3Q7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7O3B1cnBvc2U9RW1lcmdlbmN5Q2FsbERhdGEu UHJvdmlkZXJJbmZvLDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZs dDs8YSBocmVmPSJjaWQ6MDEyMzQ1Njc4OUBhdGxhbnRhLmV4YW1wbGUuY29tIj5jaWQ6MDEyMzQ1 Njc4OUBhdGxhbnRhLmV4YW1wbGUuY29tPC9hPiZndDs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs7cHVycG9zZT1FbWVyZ2Vu Y3lDYWxsRGF0YS5EZXZpY2VJbmZvPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7R2VvbG9j YXRpb246ICZsdDs8YSBocmVmPSJodHRwczovL2xzLmV4YW1wbGUubmV0Ojk3NjgvMzU3eWM2czY0 Y2V5b2l1eTVheDNvIj5odHRwczovL2xzLmV4YW1wbGUubmV0Ojk3NjgvMzU3eWM2czY0Y2V5b2l1 eTVheDNvPC9hPiZndDs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtHZW9sb2NhdGlvbi1S b3V0aW5nOiB5ZXM8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtBY2NlcHQ6IGFwcGxpY2F0 aW9uL3NkcCwgYXBwbGljYXRpb24vcGlkZiYjNDM7eG1sLDxicj4NCiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2Fw cGxpY2F0aW9uL2VtZXJnZW5jeUNhbGxEYXRhLmVDYWxsLmNvbnRyb2wmIzQzO3htbDxicj4NCiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO0NTZXE6IDUxODYyIElORk88YnI+DQombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDtJbmZvLVBhY2thZ2U6IGVtZXJnZW5jeUNhbGxEYXRhLmVDYWxsLk1TRDxicj4N CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0FsbG93OiBJTlZJVEUsIEFDSywgUFJBQ0ssIElORk8s IE9QVElPTlMsIENBTkNFTCwgUkVGRVIsIEJZRSw8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtTVUJTQ1JJQkUsIE5P VElGWSwgVVBEQVRFPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Q29udGVudC1EaXNwb3Np dGlvbjogaW5mby1wYWNrYWdlPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Q29udGVudC1U cmFuc2Zlci1FbmNvZGluZzogYmluYXJ5PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Q29u dGVudC1UeXBlOiBtdWx0aXBhcnQvbWl4ZWQ7IGJvdW5kYXJ5PWJvdW5kYXJ5MTxicj4NCiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO0NvbnRlbnQtTGVuZ3RoOiAuLi48YnI+DQo8YnI+DQombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDstLWJvdW5kYXJ5MTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O0NvbnRlbnQtVHlwZTogYXBwbGljYXRpb24vZW1lcmdlbmN5Q2FsbERhdGEuZUNhbGwuTVNEJiM0 MztwZXI8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtDb250ZW50LUlEOiA8YSBocmVmPSJt YWlsdG86NDU2Nzg5MDEyM0BhdGxhbnRhLmV4YW1wbGUuY29tIj40NTY3ODkwMTIzQGF0bGFudGEu ZXhhbXBsZS5jb208L2E+PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Li4uTVNEIGluIEFTTi4xIFBFUiBlbmNvZGluZyBnb2Vz IGhlcmUuLi48YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDstLWJvdW5kYXJ5MTxi cj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0NvbnRlbnQtVHlwZTogYXBwbGljYXRpb24vRW1l cmdlbmN5Q2FsbERhdGEuRGV2aWNlSW5mbyYjNDM7eG1sPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Q29udGVudC1JRDogJmx0OzxhIGhyZWY9Im1haWx0bzowMTIzNDU2Nzg5QGF0bGFudGEu ZXhhbXBsZS5jb20iPjAxMjM0NTY3ODlAYXRsYW50YS5leGFtcGxlLmNvbTwvYT4mZ3Q7PGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Q29udGVudC1EaXNwb3NpdGlvbjogYnktcmVmZXJlbmNl O2hhbmRsaW5nPW9wdGlvbmFsPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0 Oz94bWwgdmVyc2lvbj0mcXVvdDsxLjAmcXVvdDsgZW5jb2Rpbmc9JnF1b3Q7VVRGLTgmcXVvdDs/ Jmd0Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZsdDtkZXY6RW1lcmdlbmN5Q2FsbERh dGEuRGV2aWNlSW5mbzxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO3htbG5zOmRldj08YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmcXVvdDt1cm46aWV0ZjpwYXJhbXM6eG1sOm5z OkVtZXJnZW5jeUNhbGxEYXRhOkRldmljZUluZm8mcXVvdDsmZ3Q7PGJyPg0KJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Li4uPGJyPg0KJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jmx0Oy9kZXY6RW1lcmdlbmN5Q2FsbERhdGEuRGV2aWNlSW5mbyZndDs8YnI+ DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDstLWJvdW5kYXJ5MTxicj4NCiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO0NvbnRlbnQtVHlwZTogYXBwbGljYXRpb24vRW1lcmdlbmN5Q2FsbERh dGEuUHJvdmlkZXJJbmZvJiM0Mzt4bWw8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtDb250 ZW50LUlEOiAmbHQ7PGEgaHJlZj0ibWFpbHRvOjEyMzQ1Njc4OTBAYXRsYW50YS5leGFtcGxlLmNv bSI+MTIzNDU2Nzg5MEBhdGxhbnRhLmV4YW1wbGUuY29tPC9hPiZndDs8YnI+DQombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDtDb250ZW50LURpc3Bvc2l0aW9uOiBieS1yZWZlcmVuY2U7aGFuZGxpbmc9 b3B0aW9uYWw8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7P3htbCB2ZXJz aW9uPSZxdW90OzEuMCZxdW90OyBlbmNvZGluZz0mcXVvdDtVVEYtOCZxdW90Oz8mZ3Q7PGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0O3BpOkVtZXJnZW5jeUNhbGxEYXRhLlByb3ZpZGVy SW5mbzxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3htbG5z OnBpPTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZxdW90O3VybjppZXRmOnBhcmFtczp4bWw6bnM6RW1lcmdlbmN5Q2FsbERh dGE6UHJvdmlkZXJJbmZvJnF1b3Q7Jmd0Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOy4uLjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZs dDsvcGk6RW1lcmdlbmN5Q2FsbERhdGEuUHJvdmlkZXJJbmZvJmd0Ozxicj4NCiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOy0tYm91bmRhcnkxLS08YnI+DQo8YnI+DQpOb3RlIHRoZSBhYnNlbmNlIG9m IGEgUmVjdi1JbmZvIGhlYWRlciAod2hpY2ggaXMgZm9yYmlkZGVuIGluIElORk8gPGJyPg0KcmVx dWVzdHMgKFJGQyA2MDg2IHNlY3Rpb24gNC4yLjEpLjxicj4NCjxicj4NCk5vdGUgdGhlIHBvc2l0 aW9uaW5nIG9mIHRoZSBJbmZvLVBhY2thZ2UgaGVhZGVyIGFzIGFwcGx5aW5nIHRvIHRoZSA8YnI+ DQplbnRpcmUgYm9keS48YnI+DQo8YnI+DQpBcyBpbmRpY2F0ZWQgYnkgdGhlIEluZm8tUGFja2Fn ZSBoZWFkZXIsIHRoZSBlbnRpcmUgbXVsdGlwYXJ0IGJvZHkgaXMgPGJyPg0KdGhlIGJvZHkgb2Yg dGhlIGluZm8gcGFja2FnZS4gJm5ic3A7VGhlIGluZm8gcGFja2FnZSBib2R5IGluY2x1ZGVzIGFs bCBvZiA8YnI+DQp0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoZSBib2R5LCBpbmNsdWRp bmcgdGhlIE1TRCBhbmQgdGhlIDxicj4NCkFkZGl0aW9uYWwgRGF0YSwgdGh1cyBzdHJpY3RseSBm b2xsb3dpbmcgUkZDIDYwODYuPGJyPg0KPGJyPg0KVGhyZWUgb2YgdGhlIENhbGwtSW5mbyBoZWFk ZXIgdmFsdWVzLDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhy ZWY9ImNpZDo0NTY3ODkwMTIzQGF0bGFudGEuZXhhbXBsZS5jb20iPmNpZDo0NTY3ODkwMTIzQGF0 bGFudGEuZXhhbXBsZS5jb208L2E+Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO3B1cnBvc2U9ZW1lcmdlbmN5Q2FsbERhdGEuZUNhbGwuTVNEPGJyPg0KJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0OzxhIGhyZWY9ImNpZDoxMjM0NTY3ODkwQGF0bGFu dGEuZXhhbXBsZS5jb20iPmNpZDoxMjM0NTY3ODkwQGF0bGFudGEuZXhhbXBsZS5jb208L2E+Jmd0 Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOztwdXJwb3NlPUVtZXJnZW5jeUNhbGxEYXRhLlByb3ZpZGVySW5mbzxicj4NCiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZsdDs8YSBocmVmPSJjaWQ6MDEyMzQ1 Njc4OUBhdGxhbnRhLmV4YW1wbGUuY29tIj5jaWQ6MDEyMzQ1Njc4OUBhdGxhbnRhLmV4YW1wbGUu Y29tPC9hPiZndDs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs7cHVycG9zZT1FbWVyZ2VuY3lDYWxsRGF0YS5EZXZpY2VJbmZv PGJyPg0KcG9pbnQgdG8gYm9keSBwYXJ0cyB3aXRoaW4gdGhlIGluZm8gcGFja2FnZSB0aGF0IHBy b3ZpZGUgQWRkaXRpb25hbCA8YnI+DQpEYXRhLjxicj4NCjxicj4NClRoZSBHZW9sb2NhdGlvbiBo ZWFkZXIgcG9pbnRzIHRvIGFuIGV4dGVybmFsIGFwcGxpY2F0aW9uL3BpZGYmIzQzO3htbCA8YnI+ DQpyZXNvdXJjZS4gJm5ic3A7QnV0IGl0IGNvdWxkIGNvbnRhaW4gYSBjaWQ6IFVSTCBwb2ludGlu ZyB0byBhbiBhZGRpdGlvbmFsIDxicj4NCmFwcGxpY2F0aW9uL3BpZGYmIzQzO3htbCBib2R5IHBh cnQuPGJyPg0KPGJyPg0KTm90ZSB0aGF0IHRoZSBsYXlvdXQgb2YgdGhlIGJvZHkgcGFydHMgaXMg dGhlIHNhbWUgYXMgaXMgdXNlZCBpbiBhbiA8YnI+DQpJTkZPIHJlcXVlc3QgY29udGFpbmluZyBB ZGRpdGlvbmFsIERhdGEuICZuYnNwOyhDb21wYXJlIHdpdGggdGhlIGV4YW1wbGUgaW4gPGJyPg0K UkZDPGJyPg0KNzg1MiBzZWN0aW9uIDcuKTxicj4NCjxicj4NClRoaXMgaW1wbGllcyB0aGF0IHRo ZSBsb2dpYyBmb3IgaW5zZXJ0aW5nIGFuIGFkZGl0aW9uYWwgQWRkaXRpb25hbCA8YnI+DQpEYXRh IHBhcnQgaW50byBhbiBJTkZPIHJlcXVlc3QgaXMgZXNzZW50aWFsbHkgdGhlIHNhbWUgYXMgdGhl IGxvZ2ljIDxicj4NCmZvciBpbnNlcnRpbmcgaXQgaW50byBhbiBJTlZJVEUgcmVxdWVzdC48YnI+ DQo8YnI+DQpEYWxlPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpzaXBjb3JlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzpzaXBjb3JlQGlldGYub3JnIj5zaXBjb3JlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZSI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlPC9hPjxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzaXBjb3JlIG1haWxpbmcgbGlz dDxicj4NCjxhIGhyZWY9Im1haWx0bzpzaXBjb3JlQGlldGYub3JnIj5zaXBjb3JlQGlldGYub3Jn PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2lwY29yZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlPC9h PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B4BC72B1CESESSMB209erics_-- From nobody Mon Aug 29 23:28:23 2016 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 CC75A12D111 for ; Mon, 29 Aug 2016 23:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xeNk4EXHmnM4 for ; Mon, 29 Aug 2016 23:28:20 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40E2B12D0AC for ; Mon, 29 Aug 2016 23:28:19 -0700 (PDT) X-AuditID: c1b4fb30-ea88e980000009f9-f6-57c527829f5c Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by (Symantec Mail Security) with SMTP id 1B.06.02553.28725C75; Tue, 30 Aug 2016 08:28:18 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0301.000; Tue, 30 Aug 2016 08:28:17 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? Thread-Index: AQHR/9oeCnVeSlQa/k+Sxwkc4yebnqBblBaAgAAm3OD//+YCAIAFgMeA Date: Tue, 30 Aug 2016 06:28:16 +0000 Message-ID: References: <87shtr5kmq.fsf@hobgoblin.ariadne.com> <0AB492FC-F521-40A2-BC74-7098D3427DF8@salsgiver.com> <7594FB04B1934943A5C02806D1A2204B4BC69809@ESESSMB209.ericsson.se> <5e29dcc7-f8ec-03b0-2ded-dcb8a7b2a388@alum.mit.edu> In-Reply-To: <5e29dcc7-f8ec-03b0-2ded-dcb8a7b2a388@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="Windows-1252" Content-ID: <82E683F63C42144A9EEAC1FCB064A893@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyM2K7qG6T+tFwg8kXxCxWbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStj0uQt7AW/eCq+duxgbmCcydXFyMkhIWAi caPpNlsXIxeHkMB6RonPk/+xQzhLGCVWrFrA3MXIwcEmYCHR/U8bpEFEIFDi6pIJzCC2sECi xJ2XP1kh4kkSczbtYYaw3SS+7FzICGKzCKhK3DhxDyzOK2Alsbu7mQli/mNGiZnP5rGDJDgF HCS+fJgLZjMKiEl8P7WGCcRmFhCXuPVkPhPEpQISS/acZ4awRSVePv4HtlhUQE/i+9fZYHdK CChJTNuaBtFqIPH+3HxmCNtaYu22iywQtrbEsoWvoe4RlDg58wnLBEaxWUi2zULSPgtJ+ywk 7bOQtC9gZF3FKFqcWpyUm25kpJdalJlcXJyfp5eXWrKJERhXB7f8NtjB+PK54yFGAQ5GJR5e hYoj4UKsiWXFlbmHGCU4mJVEePVUj4YL8aYkVlalFuXHF5XmpBYfYpTmYFES5/V/qRguJJCe WJKanZpakFoEk2Xi4JRqYOzqrChzvyBneN/fcZ/a3ZpJltN32poazKxwDH3bIvnVstrQdsrj qT9k5YUXfCzJL3pwLW6y6fN9+1u/vS368i5J51fy2+mMh5a/u3R97+Oeb1OfKfFe8Rbd3CjT /bdI5l+W7d+O8xybT/YfEAnp7lrbntZ07ovZ6z4vrmAJp82b515x9JJMlVZiKc5INNRiLipO BADWDz9OpwIAAA== Archived-At: Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 06:28:22 -0000 Hi, >>>Christer seems to think that if we send a body part in an INFO message >>>that isn=B9t defined in an INFO package, that it constitutes a pre-6086 >>>INFO use, which is not allowed. >Here, we=B9re using Call-Info to point >>>to, and label the body part, recognizing that there is another body >>>part that IS part of the INFO package in the message. >>> >>> The fact that the Call-Info body part is in the INFO message doesn=B9t >>>make it a pre-6086 use of INFO. It=B9s just introduced by Call-Info >>>rather than INFO. >> >> I am saying that: >> >> 1) the data you send is associated with the ecall application; and >> 2) that the data is NOT associated with a pre-6086 use of INFO - it is >>a new INFO usage >> >> ...and therefore you have to use an Info Package. > >And I"m saying: > >- if you have an application that can get information using a variety > of sip mechanisms (e.g., from call-info in an invite, and from an > info package body) >- then more than one mechanism is applicable to a single message > (e.g. a call-info in an INFO) then you can use whatever combination > makes sense. So, by claiming that content X can also be sent in a non-INFO request you don=B9t have to define an Info Package? Which also means that the usage will not be registered in the info package registry (and probably not in any other registry either), which means that others can define a slightly different usage of INFO for delivering exactly the same content, with the same semantics - again, one of the things we wanted to prevent with RFC 6086 and the info package registry=8A Regards, Christer From nobody Tue Aug 30 06:27:32 2016 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 6E58712D5CE for ; Tue, 30 Aug 2016 06:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id md1dNgrV1Vor for ; Tue, 30 Aug 2016 06:27:27 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 179DF12D1CA for ; Tue, 30 Aug 2016 06:27:27 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 727DF1EAEF264; Tue, 30 Aug 2016 13:27:22 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u7UDROsm010456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 30 Aug 2016 13:27:24 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u7UDRL3s002353 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Aug 2016 15:27:21 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.50]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Tue, 30 Aug 2016 15:27:21 +0200 From: "Drage, Keith (Nokia - GB)" To: Paul Kyzivat , Randall Gellens , "sipcore@ietf.org" Thread-Topic: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? Thread-Index: AQHSAsI8SYP+RFbAJkaQIBG8mrhc6A== Date: Tue, 30 Aug 2016 13:27:20 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF5CB77@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <76CCBFA5-8D53-4B1E-A495-4A18AB081384@brianrosen.net> <05240A95-8319-4555-8B46-FA18B6C27883@brianrosen.net> <5d462933-e3c0-b3a3-958d-5c9d1e86d854@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8BADF5AAE0@FR712WXCHMBA11.zeu.alcatel-l ucent.com> <949EF20990823C4C85C18D59AA11AD8BADF5AE65@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 13:27:31 -0000 I think we have had this discussion in the past. The impact of doing this is that one will perform all the other functions a= ssociated with the reINVITE or the UPDATE, including a full SDP renegotiati= on. That is unnecessary and not the optimum use of resources when one is tr= ying to perform an emergency call. Further, if the SDP renegotiation fails,= the reINVITE or UPDATE has to be rejected with a 4xx. In that case, what i= s the status of the data transfer? Regards Keith -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Sent: 25 August 2016 22:01 To: Drage, Keith (Nokia - GB); Randall Gellens; sipcore@ietf.org Subject: Re: [sipcore] Can an INFO contain a body related to, but not part = of the INFO package? This is mostly getting outside the scope of sipcore. But maybe this one par= t is in scope... On 8/25/16 2:10 PM, Drage, Keith (Nokia - GB) wrote: > The you cannot use additional-data because that does not allow=20 > messages to be sent purely on the need of the data, I disagree. Consider for a moment session timer. In principle all it needs to do is sig= nal *something* from end to end through all the session signaling intermedi= aries. It doesn't really need the function of any particular message. But t= o do so it triggers the sending of INVITE or UPDATE. Note in particular tha= t the UPDATE can be effectively a no-op aside from its session-timer updati= ng. (It need not carry an offer, though it MAY.) And the resulting message = does its job without any of the recipients knowing if it was sent solely be= cause it was needed for session timer, or if it was going anyway but serves= also to refresh the session timer. The same can be true for additional-data (or any usage of call-info).=20 The additional-data transport can be piggybacked on a message that is alrea= dy being sent for some other purpose, or some benign message can be sent sp= ecifically to serve as the vehicle for the additional-data. It could be INV= ITE or UPDATE. Or it could be INFO if you have some info package that you w= ant to send at that time, or it could be the response to an INFO package if= you happen to need to respond to one at the same time that you need to sen= d the additional-data. In the case where you have just received an INFO containing an indication t= hat fresh additional-data would be appreciated, it may be really convenient= to piggyback the additional-data on the response to that INFO. I see no pr= oblem with that. Note that some other implementation might not find it convenient to piggyba= ck that way. (Maybe it takes awhile to generate the fresh data and it doesn= 't want to delay the response.) Then that implementation may need to find s= ome other message to carry the additional-data. I do not see how that violates the letter or spirit of SIP. What *would* violate the spirit of sip would be something similar that send= s high volume and frequent data over the signaling channel. Thanks, Paul From nobody Tue Aug 30 06:27:38 2016 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 C152412D5CE for ; Tue, 30 Aug 2016 06:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 827umYJHZVDm for ; Tue, 30 Aug 2016 06:27:27 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1798912D14F for ; Tue, 30 Aug 2016 06:27:27 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 881767FBB69E6; Tue, 30 Aug 2016 13:27:22 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u7UDRO2R010457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 30 Aug 2016 13:27:24 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u7UDRL2I002357 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Aug 2016 15:27:22 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.50]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Tue, 30 Aug 2016 15:27:21 +0200 From: "Drage, Keith (Nokia - GB)" To: Brian Rosen Thread-Topic: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? Thread-Index: AQHR/t2d3LN8JlqI6kKCkuU4GVEabKBZxlAw////moCAADCT8P//8XgAgAdqnBA= Date: Tue, 30 Aug 2016 13:27:21 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF5CB80@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <76CCBFA5-8D53-4B1E-A495-4A18AB081384@brianrosen.net> <05240A95-8319-4555-8B46-FA18B6C27883@brianrosen.net> <5d462933-e3c0-b3a3-958d-5c9d1e86d854@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8BADF5AAE0@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADF5AE60@FR712WXCHMBA11.zeu.alcatel-lucent.com> <037EFB4D-2C03-4A53-B182-7416A52D8554@salsgiver.com> In-Reply-To: <037EFB4D-2C03-4A53-B182-7416A52D8554@salsgiver.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 13:27:33 -0000 SSB0aGluayB5b3UgYXJlIGxvb2tpbmcgYXQgdGhlIHdyb25nIHdheSByb3VuZC4NCg0KWW91IG5l ZWQgdG8gbG9vayBhdCB0aGUgcmVxdWlyZW1lbnRzIG9mIHRoZSBhcHBsaWNhdGlvbi4NCg0KSWYg aXQgbmVlZHMgdG8gY29tZSBpbiBhIGNhbGwgY29udHJvbCBtZXNzYWdlLCB0aGVuIGl0IHVzZXMg dGhlIGV4aXN0aW5nIGxvY2F0aW9uLWNvbnZleWFuY2UgUkZDLg0KDQpJZiB5b3UgbmVlZCBpdCBv dXRzaWRlLCBhbmQgeW91IG5lZWQgaXQgaW4gc29tZXRoaW5nIG91dHNpZGUgYSBjYWxsIGNvbnRy b2wgbWVzc2FnZSwgdGhlbiB5b3UgbmVlZCB0byBmb2xsb3cgdGhlIHJ1bGVzIGZvciB0aGUgc2Vs ZWN0ZWQgZGF0YSB0cmFuc2ZlciBtZWNoYW5pc21zIHlvdSBoYXZlIGNob3Nlbi4gSWYgeW91IGhh dmUgY2hvc2VuIElORk8sIGFuZCBhbiBJbmZvIHBhY2thZ2Ugc3BlY2lmaWNhbGx5IGZvciB0aGlz IHB1cnBvc2UsIHRoZW4gdGhlIEdlb2xvY2F0aW9uIGhlYWRlciBmaWVsZCBiZWNvbWVzIGlycmVs ZXZhbnQuIElmIEkgaXMgYW5vdGhlciBJbmZvIHBhY2thZ2UgZm9yIGFub3RoZXIgcHVycG9zZSwg dGhlbiB5b3UgYXJlIGVmZmVjdGl2ZWx5IHBpZ2d5YmFja2luZyBHZW9sb2NhdGlvbiBvbiB0b3Ag b2YgaXQuIEluIG15IHZpZXcgeW91IGNhbm5vdCB0cnkgYW5kIGNvbWJpbmUgcHJvY2VkdXJlcyBm cm9tIHR3byBkaWZmZXJlbnQgZGF0YSB0cmFuc2ZlciBtZWNoYW5pc21zIGFuZCBlbmQgdXAgd2l0 aCBhIHNlbnNpYmxlIHJlc3VsdC4NCg0KS2VpdGgNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IEJyaWFuIFJvc2VuIFttYWlsdG86YnJAc2Fsc2dpdmVyLmNvbV0gDQpTZW50OiAy NSBBdWd1c3QgMjAxNiAyMDowNQ0KVG86IERyYWdlLCBLZWl0aCAoTm9raWEgLSBHQikNCkNjOiBQ YXVsIEt5eml2YXQ7IHNpcGNvcmVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2lwY29yZV0gQ2Fu IGFuIElORk8gY29udGFpbiBhIGJvZHkgcmVsYXRlZCB0bywgYnV0IG5vdCBwYXJ0IG9mIHRoZSBJ TkZPIHBhY2thZ2U/DQoNCkFjdHVhbGx5LCB0aGF04oCZcyBhIHZlcnkgZ29vZCBxdWVzdGlvbi4N Cg0KU3VwcG9zZSBJIHVzZWQgYSB2YXJpYXRpb24gb24gdGhlIHNhbWUgSU5GTyBwYWNrYWdlIHRo YXQgdHJpZ2dlcmVkIGEgbmV3IGxvY2F0aW9uLWJ5LXZhbHVlIHVwZGF0ZS4NCg0KRG9lcyB0aGUg bG9jYXRpb24gaGF2ZSB0byBjb21lIGluIGFuIElORk8gcGFja2FnZSBibG9jaywgb3IgY2FuIGl0 IGNvbWUgaW4gYSBHZW9sb2NhdGlvbiBoZWFkZXIgQ0lEIGJvY2s/DQoNCkJyaWFuDQoNCj4gT24g QXVnIDI1LCAyMDE2LCBhdCAyOjEwIFBNLCBEcmFnZSwgS2VpdGggKE5va2lhIC0gR0IpIDxrZWl0 aC5kcmFnZUBub2tpYS5jb20+IHdyb3RlOg0KPiANCj4gSSB0aGluayBpdCBpcyBub3QgYSBwcm9o aWJpdGlvbiAtIGl0IGhhcyBhIHNlbWFudGljIGFmdGVyIGFsbCwgYnV0IHJhdGhlciBhIGRldmlh dGlvbiBmcm9tIGJlc3QgcHJhY3RpY2Ugb2Yga2VlcGluZyB0aGluZ3Mgc2ltcGxlLiBBZGRpbmcg aXQgaW4gcmVzcGVjdCBvZiB0aGUgSW5mby1QYWNrYWdlIGhhcyB0byBoYXZlIHplcm8gaW1wYWN0 LiANCj4gDQo+IElmIHVzaW5nIElORk8sIHRoZW4gdGhlIEluZm8tUGFja2FnZSBkZWZpbmVzIHdo YXQgaXMgY2FycmllZCwgdXNpbmcgdGhlIEluZm8tUGFja2FnZSBoZWFkZXIgZmllbGQuIEFkZGlu ZyBDYWxsLUluZm8gaXMgbm90IGJlbHQgYW5kIGJyYWNlcywgcmF0aGVyIGl0IGlzIG5vdGhpbmcg dG8gZG8gd2l0aCB0aGUgY29ycmVjdCBvcGVyYXRpb24gb2YgdGhlIEluZm8tUGFja2FnZSBhbmQg dGhlcmVmb3JlIGEgY29tcGxleGl0eSB0aGF0IHdpbGwgZGVmaW5pdGVseSBsZWFkIHRvIGVycm9y IHByb25lIGltcGxlbWVudGF0aW9ucy4NCj4gDQo+IEFyZSB5b3UgZ29pbmcgdG8gbm93IHN0YXJ0 IHByb3Bvc2luZyBhZGRpbmcgdGhlIENhbGwtSW5mbyBoZWFkZXIgZmllbGQgdG8gYWxsIHVzYWdl cyBvZiB0aGUgR2VvbG9jYXRpb24gaGVhZGVyIGZpZWxkIHRoYXQgcG9pbnQgdG8gYSBtZXNzYWdl IGJvZHksIGJlY2F1c2UgdGhhdCBpcyB0aGUgbG9naWNhbCBwcm9ncmVzc2lvbiBvZiB1c2luZyBp dCBpbiByZXNwZWN0IG9mIHRoZSBJbmZvIHBhY2thZ2UgZGF0YSBjb250ZW50cy4NCj4gDQo+IEtl aXRoDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcmlhbiBSb3Nl biBbbWFpbHRvOmJyQHNhbHNnaXZlci5jb21dDQo+IFNlbnQ6IDI1IEF1Z3VzdCAyMDE2IDE4OjAz DQo+IFRvOiBEcmFnZSwgS2VpdGggKE5va2lhIC0gR0IpDQo+IENjOiBQYXVsIEt5eml2YXQ7IHNp cGNvcmVAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtzaXBjb3JlXSBDYW4gYW4gSU5GTyBjb250 YWluIGEgYm9keSByZWxhdGVkIHRvLCBidXQgbm90IHBhcnQgb2YgdGhlIElORk8gcGFja2FnZT8N Cj4gDQo+IEkgYXNrZWQgdGhhdCB5b3Ugbm90IGJhc2UgeW91ciByZXNwb25zZSAoaGVyZSBpbiBz aXBwY29yZSkgb24gaG93IHlvdSBQUkVGRVIgdG8gdHJhbnNwb3J0IHRoZSBkYXRhLiAgV2UgaGF2 ZSBhIGxhbmd1YWdlIGludGVycHJldGF0aW9uIHRoYXQgQ2hyaXN0ZXIgYXNrZWQgdG8gdGFrZSB0 byBzaXBjb3JlOiBkb2VzIHRoZSBsYW5ndWFnZSBpbiA2MDg2IFBST0hJQklUIHRoZSBkYXRhIGZy b20gYmVpbmcgY2FycmllZCBpbiBDYWxsLUluZm8/DQo+IA0KPiBzaXBjb3JlIHNob3VsZCBub3Qg b3BpbmUgb24gd2hhdCBlY3JpdCBTSE9VTEQgZG8sIGJ1dCBvbmx5IHdoYXQgaXQgQ09VTEQgZG8g d2l0aCByZXNwZWN0IHRvIDYwODYuDQo+IA0KPiBJcyBpdCB5b3VyIG9waW5pb24gdGhhdCA2MDg2 IHByb2hpYml0cyB1cyBmcm9tIGNhcnJ5aW5nIHRoZSBkYXRhIGluIENhbGwtSW5mbz8NCj4gDQo+ IEJyaWFuDQo+IA0KPj4gT24gQXVnIDI1LCAyMDE2LCBhdCAxMToxNyBBTSwgRHJhZ2UsIEtlaXRo IChOb2tpYSAtIEdCKSA8a2VpdGguZHJhZ2VAbm9raWEuY29tPiB3cm90ZToNCj4+IA0KPj4gVGlt ZSB0byBleHByZXNzIG15IG9waW5pb24uDQo+PiANCj4+IEluIHNvbWUgY2lyY3VtYW5jZXMsIGVj YWxsIG5lZWRzIHRvIHRyYW5zZmVyIGRhdGEgb3V0c2lkZSBvZiBhIG5vcm1hbCBjYWxsIGNvbnRy b2wgbWVzc2FnZS4NCj4+IA0KPj4gVGhlIHZpZXdwb2ludCBpcyB0aGF0IGFuIElORk8gbWVzc2Fn ZSBtaWdodCBkbyB0aGF0LiBUbyB1c2UgSU5GTyBtZXRob2RzLCBvbmUgTVVTVCBkZWZpbmUgYW4g SW5mbyBwYWNrYWdlLiBUaGVyZSBpcyBub3Qgb3RoZXIgcmVxdWlyZW1lbnQgaW4gZWNhbGwgZm9y IGFuIEluZm8gcGFja2FnZSB0byBleGlzdCwgc28gdGhlIEluZm8gcGFja2FnZSBNVVNUIGJlIG9u ZSBzcGVjaWZpYyB0byB0cmFuc2ZlcnJpbmcgdGhlIGVjYWxsIGRhdGEsIG5vdCBhbiBJbmZvIHBh Y2thZ2UgZm9yIHNvbWV0aGluZyBlbHNlIHRoYXQganVzdCBoYXBwZW5zIHRvIGJlIHN1cHBvcnRp bmcgZWNhbGwgZGF0YSB0cmFuc2ZlciBiZWNhdXNlIGl0IGlzIGFscmVhZHkgdGhlcmUuDQo+PiAN Cj4+IFRyYW5zZmVycmluZyBkYXRhIGluIEluZm8gcGFja2FnZXMgaXMgd2VsbCBrbm93bi4gSXQg ZG9lcyBub3QgcmVxdWlyZSB0aGUgdXNlIG9mIGEgQ2FsbC1JbmZvIGhlYWRlciBmaWVsZCB0byBk ZXNjcmliZSB0aGUgdXNhZ2UuIFRoZSB1c2FnZSBpcyBkZWZpbmVkIGJ5IHRoZSBJbmZvLXBhY2th Z2UgaGVhZGVyIGZpZWxkLiBVc2luZyB0aGUgQ2FsbC1JbmZvIGhlYWRlciBmaWVsZCB3b3VsZCBw cm92aWRlIHR3byBtZWFucyBvZiBkZXNjcmliaW5nIHRoZSBwdXJwb3NlIG9mIHRoZSBzYW1lIG1l c3NhZ2UgYm9keSBhbmQgbGVhZCB0byBhbGwgc29ydHMgb2YgZXJyb3IgaGFuZGxpbmcgaXNzdWVz IHdoZW4gdGhleSBiZWNvbWUgaW4gY29uZmxpY3QgKGJlY2F1c2Ugc29tZW9uZSBmYWlsZWQgdG8g cmVhZCB0aGUgc3BlY2lmaWNhdGlvbiBvciBzb21lIG90aGVyIHJlYXNvbikuIFRoaXMgbXkgdmll dyBpcyBjbGVhcmx5IHRoYXQgd2Ugc2hvdWxkIGZvbGxvdyB0aGUgcnVsZXMgb2YgY2xlYW4gZGVz aWduIGFuZCBub3QgZG8gdGhpcywgcGFydGljdWxhcmx5IGFzIGluIG15IHZpZXcgaXQgaXMgdG90 YWxseSB1bm5lY2Nlc3NhcnkuDQo+PiANCj4+IFRoZSByZW1haW5kZXIgZ29lcyBtb3JlIGludG8g ZWNhbGwgcmVxdWlyZW1lbnRzLCBhbmQgdGhlcmVmb3JlIGZhbGxzIG1vcmUgdG8gdGhlIHNjb3Bl IG9mIGVjcml0IGFuZCAzR1BQLCBidXQgaW5kaWNhdGVzIHdoeSBJIHRoaW5rIGl0IGlzIHVubmVj ZXNzYXJ5Lg0KPj4gDQo+PiBFY2FsbCBjb25zaXN0cyBvZiB0d28gcGFydHMgLSBkYXRhIHRyYW5z ZmVycmVkIGluIHRoZSBpbml0aWFsIElOVklURSBtZXNzYWdlLiBObyBvbmUgaGFzIG9iamVjdGVk IHRvIGFkZGl0aW9uYWwgZGF0YSB0byBwZXJmb3JtIHRoaXMgZnVuY3Rpb24uIEZ1cnRoZXIgaW4g c29tZSBjaXJjdW1zdGFuY2VzLCB0aGUgUFNBUCBjYW4gcmVxdWVzdCBtb3JlIGRhdGEgdG8gYmUg c2VudCBvdXRzaWRlIHRoYXQgaW5pdGlhbCByZXF1ZXN0IGFuZCBvdXRzaWRlIGZ1cnRoZXIgY2Fs bCBjb250cm9sIG1lc3NhZ2VzLiBJdCBpcyBoZXJlIHdoZXJlIHRoZSBJbmZvIHBhY2thZ2UgZGlz Y3Vzc2lvbiBjb21lcyBpbi4gTXkgdmlldyBzdHJvbmdseSBleHByZXNzZWQgaXMgdGhhdCB0aGVz ZSBjYW4gYmUgdHJlYXRlZCBmcm9tIHRoZSBTSVAgdmlld3BvaW50IGFzIHR3byBlbnRpcmVseSBz ZXBhcmF0ZSB0cmFuc3BvcnQgbWVjaGFuaXNtcywgY29tcGxldGVseSBvcGVyYXRpbmcgaW5kZXBl bmRlbnRseSBhdCB0aGUgU0lQIGxhdGVyLiBBdCBzb21lIHBvaW50IHRoZXkgYm90aCB0cmFuc2Zl ciBhbiBNU0QsIGJ1dCB0aGF0IGlzIHNlcGFyYXRlbHkgaWRlbnRpZmllZCBieSBvdGhlciBoZWFk ZXIgZmllbGRzLiBJdCBpcyB0aGVuIHVwIHRvIHRoZSBhcHBsaWNhdGlvbiBpbiBib3RoIHRoZSBQ U0FQIGFuZCB0aGUgY2FsbGluZyB1c2VyIGFnZW50IHRvIGNvbnRyb2wgaG93IHRoZXNlIHR3byBp bmRlcGVuZGVudCBkYXRhIHRyYW5zZmVyIG1lY2hhbmlzbXMgYXJlIHVzZWQuIEFzIHN1Y2ggdGhl cmUgaXMgbm8gbmVlZCB0byBzdGFydCBkZWZpbmluZyBpbnRlcmFjdGlvbnMgYmV0d2VlbiBJbmZv IHBhY2thZ2VzIGFuZCBhZGRpdGlvbmFsIGRhdGEsIGFuZCBubyBuZWVkIGZvciBvbmUgdG8gdXBk YXRlIHRoZSBvdGhlci4NCj4+IA0KPj4gUmVnYXJkcw0KPj4gDQo+PiBLZWl0aA0KPj4gDQo+PiAN Cj4+IA0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IHNpcGNvcmUgW21h aWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQYXVsIA0KPj4gS3l6 aXZhdA0KPj4gU2VudDogMjUgQXVndXN0IDIwMTYgMTU6MzINCj4+IFRvOiBzaXBjb3JlQGlldGYu b3JnDQo+PiBTdWJqZWN0OiBSZTogW3NpcGNvcmVdIENhbiBhbiBJTkZPIGNvbnRhaW4gYSBib2R5 IHJlbGF0ZWQgdG8sIGJ1dCBub3QgcGFydCBvZiB0aGUgSU5GTyBwYWNrYWdlPw0KPj4gDQo+PiBP biA4LzI1LzE2IDk6MjYgQU0sIEJyaWFuIFJvc2VuIHdyb3RlOg0KPj4+IFllcywgSeKAmW0gc2F5 aW5nIHRoYXQgdGhlIEFDSyBzYXRpc2ZpZXMgdGhlIDYwODYgdXNlIG9mIElORk8sIGFuZCB0aGF0 IGl04oCZcyBva2F5IHRvIHNlbmQgdGhlIGRhdGEgd2l0aCBDYWxsLUluZm8uDQo+Pj4gDQo+Pj4g WWVzLCBJ4oCZbSBhZ3JlZWluZyB0aGF0IHRoZXJlIGlzIGEgcmVsYXRpb25zaGlwIGJldHdlZW4g dGhlIElORk8gcGFja2FnZSBhbmQgdGhlIGRhdGEuDQo+Pj4gDQo+Pj4gWWVzLCBJ4oCZbSBkaXNh Z3JlZWluZyB3aXRoIHlvdXIgaW50ZXJwcmV0YXRpb24gb2YgdGhlIGxhbmd1YWdlLg0KPj4+IA0K Pj4+IFNvLCBub3csIHdoYXQgc2F5IHlvdSBzaXBjb3JlPw0KPj4gDQo+PiBJIHRoaW5rIHRoZSBt YWluIHBvaW50IG9mIGJyaW5naW5nIHRoaXMgdG8gc2lwY29yZSBpcyB0byBnZXQgc29tZSBmcmVz aCBpbnB1dCBpbnRvIHRoaXMgZGlzY3Vzc2lvbi4gU2luY2UgSSBoYXZlIGJlZW4gcGFydHkgdG8g dGhlIGRpc2N1c3Npb24gb3ZlciBpbiBlY3JpdCBJIGRvbid0IGJyaW5nIGFueXRoaW5nIGZyZXNo IGhlcmUuIEJ1dCBmb3IgY29tcGxldGVuZXNzIEkgd2lsbCByZWdpc3RlciBteSBvcGluaW9uIGhl cmUgdG9vLg0KPj4gDQo+PiBJTU8gdGhpcyBpcyBub3QgYSBxdWVzdGlvbiBhYm91dCB3aGV0aGVy IHRoZSBwcm9wb3NlZCB1c2FnZSBpcyB2YWxpZCANCj4+IGFjY29yZGluZyB0byA2MDg2IGFuZCBv dGhlciByZmNzLiAoSSB0aGluayBpdCBpcyBxdWl0ZSBjbGVhciB0aGF0IGl0DQo+PiAqaXMqIHZh bGlkLikgUmF0aGVyIHRoaXMgaXMgc2ltcGx5IGEgcXVlc3Rpb24gb2Ygd2hhdCBpcyB0aGUgYmVz dCBkZXNpZ24gZm9yIHRoZSBkZXNpcmVkIGZ1bmN0aW9uYWxpdHkuIEFzIHN1Y2ggSSBkb24ndCB0 aGluayBpdCByZWFsbHkgbmVlZHMgdG8gYmUgc2V0dGxlZCBpbiBzaXBjb3JlLg0KPj4gDQo+PiBC dXQgSSBhbSBoYXBweSB0byBjaGVjayBpZiBhbnlib2R5IGhhcyBhIGRpZmZlcmVudCBwZXJzcGVj dGl2ZSBvbiB0aGlzLg0KPj4gDQo+PiAJVGhhbmtzLA0KPj4gCVBhdWwNCj4+IA0KPj4+IEJyaWFu DQo+Pj4gDQo+Pj4gDQo+Pj4+IE9uIEF1ZyAyNSwgMjAxNiwgYXQgOToxNCBBTSwgQ2hyaXN0ZXIg SG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+Pj4+IA0K Pj4+PiBIaSwNCj4+Pj4gDQo+Pj4+PiBXZeKAmXJlIGFncmVlaW5nIHRoYXQgdGhlcmUgaXMgYSBy ZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgY29tbWFuZCANCj4+Pj4+IGFuZCB0aGUgZGF0YS4NCj4+ Pj4+IA0KPj4+Pj4gV2XigJlyZSBzdWdnZXN0aW5nIHRoYXQgd2UgZG9u4oCZdCBoYXZlIHRvIGJl IGFuYWwgYWJvdXQgdGhlIGxhbmd1YWdlIA0KPj4+Pj4gYW5kIGFzIGxvbmcgYXMgdGhlcmUgaXMg YW4gSU5GTyBwYWNrYWdlLCBhbmQgYSBib2R5IHBhcnQgdGhhdCBoYXMgDQo+Pj4+PiB0aGUgQUNL IHdoaWNoIGlzIGFuIElORk8gYm9keSBwYXJ0LCB0aGF0IHRoZSBjaXRlZCBsYW5ndWFnZSANCj4+ Pj4+IGRvZXNu4oCZdCBjb21wZWwgdXMgdG8gdXNlIHRoZSBJTkZPIGJvZHkgcGFydCB0byB0cmFu c3BvcnQgdGhlIGRhdGEsIA0KPj4+Pj4gdGhlIENhbGwtSW5mbyBtZWNoYW5pc20gaXMgYWNjZXB0 YWJsZS4NCj4+Pj4+IA0KPj4+Pj4gTm8gb25lIGlzIHN1Z2dlc3RpbmcgdGhhdCB3ZSB1cGRhdGUg NjA4NiwgYW5kIHdlIGFncmVlIHRoYXQgNzg1MiANCj4+Pj4+IGRpZCBub3QgdXBkYXRlIDYwODYu DQo+Pj4+PiANCj4+Pj4+IEl04oCZcyBqdXN0IHdoZXRoZXIgdGhhdCBsYW5ndWFnZSBwcm9oaWJp dHMgdXNlIG9mIHRoZSBDYWxsLUluZm8gdG8gDQo+Pj4+PiBjYXJyeSB0aGUgZGF0YSB3aGVuIGl0 IHdhcyBwcm9tcHRlZCBieSB0aGUgSU5GTyBwYWNrYWdlIHJlcXVlc3QsIA0KPj4+Pj4gYW5kIGFj Y29tcGFuaWVzIHRoZSBJTkZPIHBhY2thZ2UgQUNLLg0KPj4+PiANCj4+Pj4gWW91IHNlZW0gdG8g c3VnZ2VzdCB0aGF0LCBqdXN0IGJlY2F1c2UgeW91IHVzZSBhbiBJbmZvIFBhY2thZ2UgZm9yIA0K Pj4+PiBzZW5kaW5nIFNPTUUgb2YgdGhlIGVjYWxsIHJlbGF0ZWQgaW5mb3JtYXRpb24gKHRoZSBy ZXF1ZXN0IGFuZCANCj4+Pj4gQUNLKSwgdGhhdCBhbGxvd3MgeW91IHRvIHNlbmQgdGhlIHJlc3Qg b2YgdGhlIGVjYWxsIHJlbGF0ZWQgDQo+Pj4+IGluZm9ybWF0aW9uICh0aGUgZGF0YSBjb250ZW50 KSB3aXRob3V0IHVzaW5nIGFuIEluZm8gUGFja2FnZS4gSSANCj4+Pj4gcmVhbGx5IGRvbuKAmXQg c2VlIGhvdyB5b3UgY2FuIHBhcnNlIHRoZSBjaXRlZCB0ZXh0IGluIHRoYXQgd2F5LiBUaGUgDQo+ Pj4+IGNpdGVkIHRleHQgc2F5cyB0aGF0IGluZm9ybWF0aW9uIGFzc29jaWF0ZWQgd2l0aCB0aGUg YXBwbGljYXRpb24gDQo+Pj4+IHNoYWxsIGJlIHNlbnQgdXNpbmcgYW4gSW5mbyBQYWNrYWdlLiBB bmQsIGJvdGggdGhlIEFDSyBhbmQgdGhlIA0KPj4+PiByZXF1ZXN0ZWQgZGF0YSBjb250ZW50IGFy ZSBhc3NvY2lhdGVkIHdpdGggdGhlIGVjYWxsIGFwcGxpY2F0aW9uLg0KPj4+PiANCj4+Pj4gUmVn YXJkcywNCj4+Pj4gDQo+Pj4+IENocmlzdGVyDQo+Pj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4+IA0K Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gQnJpYW4NCj4+Pj4+IA0KPj4+Pj4+IE9uIEF1ZyAyNSwgMjAx NiwgYXQgMjowMCBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgDQo+Pj4+Pj4gPGNocmlzdGVyLmhvbG1i ZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+Pj4+Pj4gDQo+Pj4+Pj4gSGksDQo+Pj4+Pj4gDQo+ Pj4+Pj4gScK5bSBnbGFkIHRoaXMgaXMgYnJvdWdodCB0byBTSVBDT1JFLiBBcyBvbmUgb2YgdGhl IGluZm8gcGFja2FnZSANCj4+Pj4+PiBwcm9wb25lbnRzLCBwbGVhc2UgbGV0IG1lIGNsYXJpZnkg bXkgYXJndW1lbnRzLg0KPj4+Pj4+IA0KPj4+Pj4+IFRoZSA2MDg2IHRleHQgdGhhdCBCcmlhbiBj b3BpZWQgc2F5cyDCs2J1dCBhcmUgbm90IHNwZWNpZmljYWxseSANCj4+Pj4+PiBhc3NvY2lhdGVk IHdpdGggdGhlIElORk8gbWV0aG9kIGFuZCB0aGUgYXBwbGljYXRpb24gY29uY2VybmVkwrIuDQo+ Pj4+Pj4gDQo+Pj4+Pj4gSSBjbGFpbSB0aGF0IHRoZSB1cGRhdGVkIGRhdGEgSVMgYXNzb2NpYXRl ZCB3aXRoIHRoZSBhcHBsaWNhdGlvbiANCj4+Pj4+PiBjb25jZXJuZWQgKGVjYWxsKS4gVGhlIHVw ZGF0ZWQgZGF0YSBpcyByZXF1ZXN0ZWQgYnkgdGhlIGVjYWxsIA0KPj4+Pj4+IGFwcGxpY2F0aW9u LCBhbmQgdGhlIGRlbGl2ZXJlZCB1cGRhdGVkIGRhdGEgaXMgY29uc3VtZWQgYnkgdGhlIA0KPj4+ Pj4+IGVjYWxsIGFwcGxpY2F0aW9uLiBUaGUgdXBkYXRlZCBkYXRhIGlzIE5PVCBzb21lIA0KPj4+ Pj4+IG5vbi1lY2FsbC1hcHBsaWNhdGlvbi1yZWxhdGVkIGluZm9ybWF0aW9uIHRoYXQgaXMgcGln Z3liYWNrZWQgaW4gDQo+Pj4+Pj4gYSAiY29udmVuaWVudCBJTkZPIG1lc3NhZ2UiIHRoYXQgaGFw cGVucyB0byBiZSBzZW50IGJ5IHRoZSBlY2FsbCANCj4+Pj4+PiBhcHBsaWNhdGlvbiBmb3Igc29t ZSBvdGhlciBwdXJwb3NlLg0KPj4+Pj4+IA0KPj4+Pj4+IChJbiBhZGRpdGlvbiwgdGhlIHVwZGF0 ZWQgZGF0YSBpcyBOT1QgYXNzb2NpYXRlZCB3aXRoIGEgbGVnYWN5DQo+Pj4+Pj4gKHByZS02MDg2 KQ0KPj4+Pj4+IElORk8gdXNhZ2UsIHdoaWNoIGNvdWxkIGp1c3RpZnkgbm90IHVzaW5nIGFuIElu Zm8gUGFja2FnZS4gSSBkbyANCj4+Pj4+PiB3YW50IHRvIHBvaW50IG91dCB0aGF0IG5vYm9keSBo YXMgY2xhaW1lZCB0aGF0IHRoZSB1cGRhdGVkIGRhdGEgDQo+Pj4+Pj4gd291bGQgYmUgYXNzb2Np YXRlZCB3aXRoIGxlZ2FjeSBJTkZPLCBidXQganVzdCBmb3IgY29tcGxldGVuZXNzKQ0KPj4+Pj4+ IA0KPj4+Pj4+IFJGQyA3ODUyIGRvZXMgZGVmaW5lIGEgbWVjaGFuaXNtIGZvciB0cmFuc3BvcnRp bmcgZGF0YSwgdXNpbmcgDQo+Pj4+Pj4gQ2FsbC1JbmZvIGV0Yy4gQnV0LCA3ODUyIGRvZXMgbm90 IHVwZGF0ZSA2MDg2LCBub3IgY2FuIDc4NTIgDQo+Pj4+Pj4gb3ZlcnJpZGUgcnVsZXMgYW5kIHBy b2NlZHVyZXMgYXNzb2NpYXRlZCB3aXRoIGluZGl2aWR1YWwgU0lQIA0KPj4+Pj4+IG1ldGhvZHMg KElORk8gaW4gdGhpcyBjYXNlKS4gSSBhbHNvIHBvaW50ZWQgdGhpcyBvdXQgYmVmb3JlIDc4NTIg DQo+Pj4+Pj4gd2FzIHB1Ymxpc2hlZCwgYnV0IHdhcyB0b2xkIHRoYXQgaXTCuXMgdG9vIGxhdGUg dG8gY2hhbmdlIGl0IA0KPj4+Pj4+IChncmFudGVkLCB0aGUgZHJhZnQgd2FzIGluIHRoZSBSRkMg ZWRpdG9ywrlzIHF1ZXVlKS4NCj4+Pj4+PiANCj4+Pj4+PiBGaW5hbGx5LCBhZ2FpbiBmb3IgY29t cGxldGVuZXNzLCBJIHdhbnQgdG8gcG9pbnQgb3V0IHRoYXQgNjA4NiANCj4+Pj4+PiBkb2VzIG5v dCBwcmV2ZW50IGluY2x1ZGluZyBDYWxsLUluZm8gaW4gSU5GTyBhcyBzdWNoLiBUaGUgaXNzdWUg DQo+Pj4+Pj4gaXMgaG93IHNvbWUgd2FudCB0byB1c2UgQ2FsbC1JbmZvIGluc3RlYWQgb2YgYW4g SW5mbyBQYWNrYWdlLg0KPj4+Pj4+IA0KPj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+Pj4gDQo+Pj4+Pj4g Q2hyaXN0ZXINCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiBPbiAyNS8wOC8xNiAw MzoyMiwgInNpcGNvcmUgb24gYmVoYWxmIG9mIEJyaWFuIFJvc2VuIg0KPj4+Pj4+IDxzaXBjb3Jl LWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGJyQGJyaWFucm9zZW4ubmV0PiB3cm90ZToN Cj4+Pj4+PiANCj4+Pj4+Pj4gT3ZlciBpbiBlY3JpdCB3ZSBoYXZlIGEgZGlzYWdyZWVtZW50IHRo YXQgcmVsYXRlcyB0byANCj4+Pj4+Pj4gaW50ZXJwcmV0aW5nIFJGQzYwODYuDQo+Pj4+Pj4+IA0K Pj4+Pj4+PiBCYWNrZ3JvdW5kOg0KPj4+Pj4+PiBSRkM3ODUyIGRlZmluZXMgc29tZXRoaW5nIGNh bGxlZCAiQWRkaXRpb25hbCBEYXRhIiwgd2hpY2ggaXMgDQo+Pj4+Pj4+IGNhcnJpZWQgaW4gZW1l cmdlbmN5IGNhbGwgc2lnbmFsaW5nLiAgSXQncyBkYXRhIHJlbGF0ZWQgdG8gdGhlIA0KPj4+Pj4+ PiBjYWxsLCBlLmcuLCB0aGUgaWRlbnRpdHkgYW5kIGNvbnRhY3QgZGF0YSBvZiB0aGUgc2Vydmlj ZSBwcm92aWRlciBoYW5kbGluZyB0aGUgY2FsbC4NCj4+Pj4+Pj4gQWRkaXRpb25hbCBEYXRhIGlz IHNpZ25hbGVkIHdpdGggYSBDYWxsLUluZm8gaGVhZGVyIGZpZWxkLCB3aGljaCANCj4+Pj4+Pj4g Y29udGFpbnMgZWl0aGVyIGEgVVJJIHBvaW50aW5nIHRvIGEgZGF0YSBibG9jayBmZXRjaGVkIHdp dGggDQo+Pj4+Pj4+IEhUVFBTLCBvciBhIENvbnRlbnQgSW5kaXJlY3QgcmVmZXJlbmNpbmcgYSBi b2R5IHBhcnQgb2YgdGhlIFNJUCBtZXNzYWdlLg0KPj4+Pj4+PiBJdCdzIHVzdWFsbHkgdXNlZCBv biB0aGUgSU5WSVRFIG9mIHRoZSBlbWVyZ2VuY3kgY2FsbCwgc28gaXQgY2FuIA0KPj4+Pj4+PiBi ZSBkaXNwbGF5ZWQgdG8gdGhlIFBTQVAgKGVtZXJnZW5jeSBjYWxsIGNlbnRlcikgY2FsbC10YWtl ciB3aGVuIA0KPj4+Pj4+PiB0aGUgY2FsbCBpcyBhc3NpZ25lZC4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+ IFNvbWV0aW1lcywgdGhpcyBkYXRhIGNhbiBjaGFuZ2UgZHVyaW5nIGEgY2FsbC4gIFRoZSBleGFt cGxlIGluIA0KPj4+Pj4+PiBkaXNjdXNzaW9uDQo+Pj4+Pj4+IGlzIHRlbGVtYXRpY3MgZGF0YSBp biBhIHZlaGljbGUuICAgVGhlIHZlaGljbGUgY2FuIHJlcG9ydCB0aGluZ3MgbGlrZQ0KPj4+Pj4+ PiB0aGUNCj4+Pj4+Pj4gbnVtYmVyIG9mIG9jY3VwYW50cyBhbmQgaXRzIG9yaWVudGF0aW9uLiAg VGhlIFBTQVAgY2FuIHJlcXVlc3QgDQo+Pj4+Pj4+IGFuIHVwZGF0ZSBtaWQgY2FsbCAoZS5nLiwg aWYgdGhlIGNhbGwgdGFrZXIgdGhpbmtzIHRoaW5ncyBtaWdodCANCj4+Pj4+Pj4gaGF2ZSBjaGFu Z2VkKS4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IElORk8gaXMgdGhlIGNob3NlbiBtZWNoYW5pc20gdG8g c2VuZCB0aGUgcmVxdWVzdCBmb3IgdXBkYXRlLiAgDQo+Pj4+Pj4+IFRoZSBkZXZpY2Ugd2lsbCBz ZW5kIGEgcmVzcG9uc2UgdG8gdGhlIHJlcXVlc3QgKGFuIEFDSyksIHdoaWNoIA0KPj4+Pj4+PiBp cyBhbHNvIHNlbnQgaW4gSU5GTy4NCj4+Pj4+Pj4gVGhpcyBjb25zdGl0dXRlcyBhIHdlbGwgZGVm aW5lZCBJTkZPIHBhY2thZ2UsIGFuZCB3aWxsIGJlIA0KPj4+Pj4+PiByZWdpc3RlcmVkIGluIHRo ZSB1c3VhbCB3YXkuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBUaGUgSXNzdWUgYXQgaGFuZDoNCj4+Pj4+ Pj4gU28sIHRoZSBkaXNwdXRlIGlzIGhvdyB0aGUgdXBkYXRlZCBkYXRhIGlzIHNlbnQgbWlkIGNh bGwuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBSRkM2MDg2IHNheXMNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IE5P VEU6IEFuIElORk8gcmVxdWVzdCBjYW4gYWxzbyBjb250YWluIG90aGVyIGJvZHkgcGFydHMgdGhh dCBhcmUgDQo+Pj4+Pj4+IG1lYW5pbmdmdWwgd2l0aGluIHRoZSBjb250ZXh0IG9mIGFuIGludml0 ZSBkaWFsb2cgdXNhZ2UgYnV0IGFyZSANCj4+Pj4+Pj4gbm90IHNwZWNpZmljYWxseSBhc3NvY2lh dGVkIHdpdGggdGhlIElORk8gbWV0aG9kIGFuZCB0aGUgDQo+Pj4+Pj4+IGFwcGxpY2F0aW9uIGNv bmNlcm5lZC4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IFRoZSBhdXRob3JzIG9mIHRoZSBkcmFmdCAob2Yg d2hpY2ggSSBhbSBvbmUpIGRlc2lyZSB0byB1c2UgdGhlIA0KPj4+Pj4+PiBBZGRpdGlvbmFsIERh dGEgbWVjaGFuaXNtIHRvIGNhcnJ5IHRoZSB1cGRhdGVkIGRhdGEuICBUaGUgZGF0YSANCj4+Pj4+ Pj4gY291bGQgYmUgc2VudCBpbiBhbnkgY29udmVuaWVudCBtZXNzYWdlLCBhbHRob3VnaCBzaW5j ZSB0aGUgDQo+Pj4+Pj4+IHZlaGljbGUgaXMgc2VuZGluZyBhbiBBQ0ssIGl0J3MgbGlrZWx5IGdv aW5nIHRvIGdvIG9uIHRoYXQuICANCj4+Pj4+Pj4gV2UnZCBsaWtlIHRvIGFsd2F5cyBjYXJyeSB0 aGUgZGF0YSBpbiB0aGUgc2FtZSB3YXkuICBJbiBhbiBJTkZPIA0KPj4+Pj4+PiBtZXNzYWdlIGl0 IHdvdWxkIGJlIGNhcnJpZWQgdGhlIHNhbWUgYXMgaXQgaXMgaW4gdGhlIElOVklURSwgYXMgDQo+ Pj4+Pj4+IEFkZGl0aW9uYWwgRGF0YS4gIFNpbmNlIHRoZSBJTkZPIGNhcnJpZXMgYW4gQUNLLCBp dCB3b3VsZCANCj4+Pj4+Pj4gc3BlY2lmeSB0aGUgYXBwcm9wcmlhdGUgSU5GTyBwYWNrYWdlLCBh bmQgd291bGQgY29udGFpbiBhIGJvZHkgDQo+Pj4+Pj4+IHBhcnQgd2l0aCB0aGUgQUNLLiAgVGhl cmUgd291bGQgYmUgYW5vdGhlciBib2R5IHBhcnQgZm9yIHRoZSANCj4+Pj4+Pj4gdXBkYXRlZCBk YXRhLCBwb2ludGVkIHRvIGJ5IHRoZSBDYWxsLUluZm8uDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBTb21l IGVjcml0IHBhcnRpY2lwYW50cyBzYXkgdGhhdCB0aGUgYWJvdmUgbGFuZ3VhZ2Ugb2YgNjA4NiAN Cj4+Pj4+Pj4gd291bGQgcHJvaGliaXQgdGhlIElORk8gZnJvbSBjb250YWluaW5nIGEgQ2FsbC1J bmZvIGhlYWRlciB3aXRoIA0KPj4+Pj4+PiBhIENJRCBwb2ludGluZyB0byBhIE1JTUUgYm9keSBw YXJ0LCBiZWNhdXNlIHRoZSBkYXRhIHdhcyANCj4+Pj4+Pj4gcmVxdWVzdGVkIGJ5IGFuIElORk8s IGFuZCBoZW5jZSBpcyByZWxhdGVkIHRvIHRoZSBJTkZPIHBhY2thZ2UuICANCj4+Pj4+Pj4gVGhl eSBzYXkgdGhhdCB0aGUgZGF0YSBNVVNUIGJlIGNhcnJpZWQgd2l0aCBhIGJvZHkgcGFydCBhbmQg DQo+Pj4+Pj4+IENvbnRlbnQgRGlzcG9zaXRpb24gdGhhdCBpcyBwYXJ0IG9mIHRoZSBJTkZPIHBh Y2thZ2UgZGVmaW5pdGlvbi4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IFRoZSBkcmFmdCBhdXRob3JzIGNs YWltIHRoaXMgNjA4NiBsYW5ndWFnZSBpc24ndCBhIA0KPj4+Pj4+PiBzdHJhaWdodGphY2tldCwg YW5kIGl0J3MgcGVyZmVjdGx5IGZpbmUgdG8gY2FycnkgdGhlIGRhdGEgDQo+Pj4+Pj4+IHJlZmVy ZW5jZWQgYnkgYSBDYWxsLUluZm8gd2l0aCBhIENvbnRlbnQgSW5kaXJlY3QgYm9keSBwYXJ0IHVz aW5nIHRoZSBzYW1lIE1JTUUgdHlwZSBhbmQgQ29udGVudA0KPj4+Pj4+PiBEaXNwb3NpdGlvbiBh cyBpdCB3b3VsZCBpbiBhbiBJTlZJVEUuICAgV2hlbiB0aGUgdXBkYXRlZCBkYXRhIGlzIHNlbnQN Cj4+Pj4+Pj4gaW4NCj4+Pj4+Pj4gSU5GTywgaXQncyBiZWNhdXNlIHRoZSBJTkZPIGlzIGEgY29u dmVuaWVudCBtZXNzYWdlIChzaW5jZSBpdCdzIA0KPj4+Pj4+PiBiZWluZyBzZW50IHRvIGNhcnJ5 IHRoZSBBQ0spLg0KPj4+Pj4+PiANCj4+Pj4+Pj4gTWVjaGFuaWNhbGx5LCBib3RoIG1lY2hhbmlz bXMgY2FuIGJlIG1hZGUgdG8gd29yay4gIFRoZSBib2R5IA0KPj4+Pj4+PiBwYXJ0cyB3b3VsZCBi ZSBsYWJlbGVkIGFwcHJvcHJpYXRlbHkgYW5kIHRoZXJlIHdvdWxkIGJlIG5vIA0KPj4+Pj4+PiBj b25mdXNpb24gYWJvdXQgd2hhdCB0aGV5IG1lYW4gb3IgaG93IHRoZXkgd291bGQgYmUgaW50ZXJw cmV0ZWQuDQo+Pj4+Pj4+IEl0J3MgcmVhbGx5IG9ubHkgd2hldGhlciB0aGUgQ2FsbC1JbmZvIGhl YWRlciBpcyBwcmVzZW50IGFuZCANCj4+Pj4+Pj4gd2hhdCB0aGUgTUlNRSB0eXBlIGFuZCBDb250 ZW50IERpc3Bvc2l0aW9uIHRoZSBib2R5IHBhcnQgDQo+Pj4+Pj4+IGNvbnRhaW5pbmcgdGhlIGRh dGEgd291bGQgYmUuICBJbiB0aGUgYXV0aG9yJ3MgcHJlZmVycmVkIHdheSwgaXQgDQo+Pj4+Pj4+ IHdvdWxkIGJlIHRoZSBNSU1FIHR5cGUgYW5kIENvbnRlbnQgRGlzcG9zaXRpb24gb2YgdGhlIENh bGwtSW5mbyANCj4+Pj4+Pj4gYW5kIGluIHRoZSBvdGhlciBwb2ludCBvZiB2aWV3IGl0IHdvdWxk IGJlIHRoZSBNSU1FIHR5cGUgYW5kIA0KPj4+Pj4+PiBDb250ZW50IERpc3Bvc2l0aW9uIG9mIHRo ZSBJTkZPIHBhY2thZ2UuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBQbGVhc2UgaWdub3JlIHlvdXIgcGVy c29uYWwgcHJlZmVyZW5jZSBmb3Igd2hldGhlciB5b3UgdGhpbmsgaXQgDQo+Pj4+Pj4+IG91Z2h0 IHRvIGdvIGluIHRoZSBJTkZPIG9yIG5vdCwgYW5kIHBsZWFzZSBoZWxwIHVzIGludGVycHJldCA2 MDg2Og0KPj4+Pj4+PiBkb2VzIHRoZSBkYXRhIEhBVkUgdG8gZ28gaW4gYW4gSU5GTyBib2R5IHBh cnQgb3IgY2FuIGl0IGJlIHNlbnQgDQo+Pj4+Pj4+IGluIGEgQ2FsbC1JbmZvIGJvZHkgcGFydD8N Cj4+Pj4+Pj4gDQo+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+Pj4+Pj4+IHNpcGNvcmUgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+IHNpcGNvcmVA aWV0Zi5vcmcNCj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z aXBjb3JlDQo+Pj4+Pj4gDQo+Pj4+PiANCj4+Pj4gDQo+Pj4gDQo+Pj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBzaXBjb3JlIG1haWxpbmcgbGlz dA0KPj4+IHNpcGNvcmVAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NpcGNvcmUNCj4+PiANCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+IHNpcGNvcmUgbWFpbGluZyBsaXN0DQo+PiBzaXBj b3JlQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Np cGNvcmUNCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+PiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPj4gc2lwY29yZUBpZXRmLm9yZw0KPj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQo+IA0KDQo= From nobody Tue Aug 30 06:37:59 2016 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 7D59A12D1D7 for ; Tue, 30 Aug 2016 06:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMtRj7R4JvnV for ; Tue, 30 Aug 2016 06:37:54 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5545512D578 for ; Tue, 30 Aug 2016 06:37:42 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 3D1E3FE58900C; Tue, 30 Aug 2016 13:27:23 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u7UDRPXW010465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 30 Aug 2016 13:27:25 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u7UDRO8Z002375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Aug 2016 15:27:24 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.50]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Tue, 30 Aug 2016 15:27:24 +0200 From: "Drage, Keith (Nokia - GB)" To: Brian Rosen , "Dale R. Worley" Thread-Topic: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? Thread-Index: AQHR/9oevigk8q19hUaBisx2vMmvZKBblBaAgAXAo7A= Date: Tue, 30 Aug 2016 13:27:24 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF5CBB9@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <87shtr5kmq.fsf@hobgoblin.ariadne.com> <0AB492FC-F521-40A2-BC74-7098D3427DF8@salsgiver.com> In-Reply-To: <0AB492FC-F521-40A2-BC74-7098D3427DF8@salsgiver.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 13:37:58 -0000 QW5kIGFzIEkgaGF2ZSBhc3NlcnRlZCwgYXMgdGhlIGNvbnRlbnRzIG9mIHRoZSBJbmZvIHBhY2th Z2UgZGF0YSBpcyBkZWZpbmVkIGJ5IHRoZSBJbmZvLVBhY2thZ2UgaGVhZGVyLCB0aGUgdXNhZ2Ug b2YgdGhlIENhbGwtSW5mbyBoZWFkZXIgZmllbGQgaXMgaXJyZWxldmFudCwgYW5kIHBvdGVudGlh bGx5IG1pc2xlYWRpbmcuDQoNCktlaXRoDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBzaXBjb3JlIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgQnJpYW4gUm9zZW4NClNlbnQ6IDI2IEF1Z3VzdCAyMDE2IDIxOjQ1DQpUbzogRGFsZSBSLiBX b3JsZXkNCkNjOiBzaXBjb3JlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NpcGNvcmVdIENhbiBh biBJTkZPIGNvbnRhaW4gYSBib2R5IHJlbGF0ZWQgdG8sIGJ1dCBub3QgcGFydCBvZiB0aGUgSU5G TyBwYWNrYWdlPw0KDQpDaHJpc3RlciBzZWVtcyB0byB0aGluayB0aGF0IGlmIHdlIHNlbmQgYSBi b2R5IHBhcnQgaW4gYW4gSU5GTyBtZXNzYWdlIHRoYXQgaXNu4oCZdCBkZWZpbmVkIGluIGFuIElO Rk8gcGFja2FnZSwgdGhhdCBpdCBjb25zdGl0dXRlcyBhIHByZS02MDg2IElORk8gdXNlLCB3aGlj aCBpcyBub3QgYWxsb3dlZC4gIEhlcmUsIHdl4oCZcmUgdXNpbmcgQ2FsbC1JbmZvIHRvIHBvaW50 IHRvLCBhbmQgbGFiZWwgdGhlIGJvZHkgcGFydCwgcmVjb2duaXppbmcgdGhhdCB0aGVyZSBpcyBh bm90aGVyIGJvZHkgcGFydCB0aGF0IElTIHBhcnQgb2YgdGhlIElORk8gcGFja2FnZSBpbiB0aGUg bWVzc2FnZS4NCg0KVGhlIGZhY3QgdGhhdCB0aGUgQ2FsbC1JbmZvIGJvZHkgcGFydCBpcyBpbiB0 aGUgSU5GTyBtZXNzYWdlIGRvZXNu4oCZdCBtYWtlIGl0IGEgcHJlLTYwODYgdXNlIG9mIElORk8u ICBJdOKAmXMganVzdCBpbnRyb2R1Y2VkIGJ5IENhbGwtSW5mbyByYXRoZXIgdGhhbiBJTkZPLg0K DQpCcmlhbg0KDQo+IE9uIEF1ZyAyNiwgMjAxNiwgYXQgNDo0MCBQTSwgRGFsZSBSLiBXb3JsZXkg PHdvcmxleUBhcmlhZG5lLmNvbT4gd3JvdGU6DQo+IA0KPiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hy aXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPiB3cml0ZXM6DQo+PiBJIGFtIGFza2luZzogYXNz dW1pbmcgeW91IGhhdmUgZGV0ZXJtaW5lZCAoYmFzZWQgb24gd2hhdGV2ZXIgDQo+PiBjcml0ZXJp YSkgdGhhdCB0aGUgSU5GTyBtZXNzYWdlIGlzIHRoZSBtb3N0IGFwcHJvcHJpYXRlIG1lY2hhbmlz bSwgDQo+PiB3aGVuIGFyZSB5b3UgcmVxdWlyZWQgdG8gdXNlIEluZm8gUGFja2FnZT8NCj4gDQo+ IElmIHlvdSBoYXZlIGRlY2lkZWQgdG8gdXNlIGFuIElORk8gcmVxdWVzdCwgdGhlbiB0aGUgSU5G TyByZXF1ZXN0IHVzZXMgDQo+IGFuIEluZm8gUGFja2FnZSB3aGVuIChhbmQgb25seSB3aGVuKSBh biBJbmZvLVBhY2thZ2UgaGVhZGVyIGlzIHByZXNlbnQgDQo+IGluIHRoZSByZXF1ZXN0LiAgVGhh dCdzIGEgYmFzaWMgcnVsZSBvZiBSRkMgNjA4Ni4gIFRoZXJlIGRvZXNuJ3Qgc2VlbSANCj4gdG8g YmUgYW55IG5vcm1hdGl2ZSBwcmVzY3JpcHRpb24gb2Ygd2hlbiB5b3UgYXJlIHJlcXVpcmVkIHRv IHVzZSBJbmZvIA0KPiBQYWNrYWdlIHdpdGhpbiBJTkZPLCBidXQgaXQgc2VlbXMgbGlrZSBhIGdv b2QgaWRlYSB0byB1c2UgYW4gSW5mbyANCj4gUGFja2FnZSBmb3IgYW55IG5ld2x5IGRlc2lnbmVk IHVzZXMgb2YgSU5GTy4NCj4gDQo+IERhbGUNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNpcGNvcmUgbWFpbGluZyBsaXN0DQo+IHNpcGNv cmVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBj b3JlDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpz aXBjb3JlIG1haWxpbmcgbGlzdA0Kc2lwY29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQo= From nobody Tue Aug 30 06:51:32 2016 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 4818C12D10D for ; Tue, 30 Aug 2016 06:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, WEIRD_PORT=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWMpMe8n4-mm for ; Tue, 30 Aug 2016 06:51:25 -0700 (PDT) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC17712D177 for ; Tue, 30 Aug 2016 06:51:17 -0700 (PDT) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-03v.sys.comcast.net with SMTP id ejQWbtufH8GkCejRcb2lp9; Tue, 30 Aug 2016 13:51:16 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-01v.sys.comcast.net with SMTP id ejRbbyWeHL4G2ejRcbqRhl; Tue, 30 Aug 2016 13:51:16 +0000 To: sipcore@ietf.org References: <87eg572yxn.fsf@hobgoblin.ariadne.com> <76D1BB4B-CE62-42BD-A694-E5140341DD7E@salsgiver.com> <7594FB04B1934943A5C02806D1A2204B4BC72486@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC72B1C@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <0a72071a-d1ea-d203-f47b-5eb260f6cdb5@alum.mit.edu> Date: Tue, 30 Aug 2016 09:51:14 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC72B1C@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfDemviTPiFWell0rg0BfzcYiAGU3DX21cX8mjU9sw/n2hC2xrk0OtmtQh1eTBFaLrZp3BF+HS4/LKHpW7iNWuG/q0LO3PGWgu4RL53Oq+Bvg0VV7eQez 6Wt0g4RrzDVungPkxqb+5kK7Tr9WbHXUrpNDG//wbOoUeTG0kaGn5jfRy2v2oNrgNCJ9zOJ4fYaX9g== Archived-At: Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 13:51:29 -0000 On 8/30/16 1:27 AM, Christer Holmberg wrote: > >>No, this really does return the MSD in an info block, but it also has > the >Additional Data header pointing to the body part that contains the MSD. > > Thats what I said :) > > And, how is that different from what is currently specified in > draft-ecall-11? Its different because of the nesting structure of the body parts, and their respective content-disposition values. In this form the MSD has a c-d of by-reference, as it should. And yet it meets your objections because it is *part* of the info package body that has a c-d of info-package, as it should. Thanks, Paul > Regards, > > > > Christer > > > > > > On Aug 29, 2016, at 3:10 PM, Christer Holmberg > > wrote: > > > > I may have missed something, but to me this seems more or less like > what has already been discussed in ECRIT: associate the MSD inside > an info package, but still use Call-Info to point to it. > > As a side note, it's important to separate the *transport mechanism* > defined in Additional Data (chapter 6 of RFC 7852), and the *data > structures* (Device Information) defined in Additional Data. There > is currently no requirement for ecall to support the data > structures, and they are not mentioned/referenced in draft-ecall. > > Regards, > > Christer > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Brian Rosen > Sent: 30 August 2016 00:02 > To: Dale R. Worley > > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Using an INFO package in > draft-ietf-ecrit-ecall-11 > > Verrrry interesting. > > About the only part I dont get is the Content Disposition of > Info-Package on the whole body, no Content Disposition on the MSD, > and then a different Content Disposition on the DeviceInfo block. > > But I think it would be fairly easy to deal with if you were > expecting it, which is what an implementation that handled eCall > (and thus the emergencyCallData.eCall.MSD part) would do. > > Its clever, I will say that. > > Brian > > > On Aug 29, 2016, at 11:49 AM, Dale R. Worley > wrote: > > TL;DR: If the body for an emergencyCallData.eCall.MSD info > package is > defined correctly, we can organize the data in an INFO request the > same way that we do in an INVITE request and still follow the info > package rules strictly. > > > After asking around, I have learned that my previous message on > this > subject severely buried the lead: The useful point followed a long > message example, which itself followed several pages of recap of > the > points in question. As far as I can tell, nobody had the > stamina to > read that far, and in retrospect, I don't blame them. > > So this time, I'm going recap my proposal and put the important > points > *first*: > > It it possible to define an info package for use by > draft-ietf-ecrit-ecall-11 that includes all of the Additional Data > (RFC > 7852) in a way that strictly follows the rules for info packages > (RFC > 6086), but also uses the same data format used by initial > Additional > Data reporting. This solves the dilemma that we have been > discussing. > > The key is to define the info package properly. The info package > definition is: > > The body for an emergencyCallData.eCall.MSD info package is: > > - either an application/emergencyCallData.eCall.MSD+per > (containing > the MSD), or > > - a multipart body containing exactly: > > - exactly one application/emergencyCallData.eCall.MSD+per part > (containing the MSD), > > - zero or more application/EmergencyCallData.DeviceInfo+xml > parts (containing Additional Data), and > > - zero or one application/pidf+xml part (containing > geolocation > data). > > This allows all of the information items that we want to carry > in the > INFO message to be part of one info package, which is the body > of the > INFO message. > > In draft-ietf-ecrit-ecall-11 usage, all body parts will > typically be > pointed to by a Geolocation or Call-Info header. > > A typical example is this INFO request. I've assembled the > example by > inserting the Additional Data from an example in RFC 7852 into the > response INFO request in draft-ietf-ecrit-ecall-11: > > INFO urn:service:sos.ecall.automatic SIP/2.0 > To: urn:service:sos.ecall.automatic > From: ;tag=9fxced76sl > Call-ID: 3848276298220188511@atlanta.example.com > > Call-Info: ; > purpose=emergencyCallData.eCall.MSD > Call-Info: > ;purpose=icon, > ;purpose=info, > > ;purpose=EmergencyCallData.ProviderInfo, > > ;purpose=EmergencyCallData.DeviceInfo > Geolocation: > Geolocation-Routing: yes > Accept: application/sdp, application/pidf+xml, > application/emergencyCallData.eCall.control+xml > CSeq: 51862 INFO > Info-Package: emergencyCallData.eCall.MSD > Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, > SUBSCRIBE, NOTIFY, UPDATE > Content-Disposition: info-package > Content-Transfer-Encoding: binary > Content-Type: multipart/mixed; boundary=boundary1 > Content-Length: ... > > --boundary1 > Content-Type: application/emergencyCallData.eCall.MSD+per > Content-ID: 4567890123@atlanta.example.com > > > ...MSD in ASN.1 PER encoding goes here... > > --boundary1 > Content-Type: application/EmergencyCallData.DeviceInfo+xml > Content-ID: <0123456789@atlanta.example.com > > > Content-Disposition: by-reference;handling=optional > > > xmlns:dev= > "urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo"> > ... > > > --boundary1 > Content-Type: application/EmergencyCallData.ProviderInfo+xml > Content-ID: <1234567890@atlanta.example.com > > > Content-Disposition: by-reference;handling=optional > > > xmlns:pi= > "urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo"> > ... > > --boundary1-- > > Note the absence of a Recv-Info header (which is forbidden in INFO > requests (RFC 6086 section 4.2.1). > > Note the positioning of the Info-Package header as applying to the > entire body. > > As indicated by the Info-Package header, the entire multipart > body is > the body of the info package. The info package body includes > all of > the information contained in the body, including the MSD and the > Additional Data, thus strictly following RFC 6086. > > Three of the Call-Info header values, > cid:4567890123@atlanta.example.com; > purpose=emergencyCallData.eCall.MSD > > ;purpose=EmergencyCallData.ProviderInfo > > ;purpose=EmergencyCallData.DeviceInfo > point to body parts within the info package that provide Additional > Data. > > The Geolocation header points to an external application/pidf+xml > resource. But it could contain a cid: URL pointing to an > additional > application/pidf+xml body part. > > Note that the layout of the body parts is the same as is used in an > INFO request containing Additional Data. (Compare with the > example in > RFC > 7852 section 7.) > > This implies that the logic for inserting an additional Additional > Data part into an INFO request is essentially the same as the logic > for inserting it into an INVITE request. > > Dale > > _______________________________________________ > 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 > > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Tue Aug 30 06:58:14 2016 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 3069C12D5F9 for ; Tue, 30 Aug 2016 06:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7tjUZLrNFVv for ; Tue, 30 Aug 2016 06:58:08 -0700 (PDT) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9CA612D1B9 for ; Tue, 30 Aug 2016 06:58:08 -0700 (PDT) Received: from resomta-po-09v.sys.comcast.net ([96.114.154.233]) by resqmta-po-12v.sys.comcast.net with SMTP id ejXebBJGjlHMYejYFbipeg; Tue, 30 Aug 2016 13:58:07 +0000 Received: from hobgoblin.ariadne.com ([73.100.16.189]) by resomta-po-09v.sys.comcast.net with SMTP id ejYDb9TeH6AHrejYEb4dd1; Tue, 30 Aug 2016 13:58:07 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u7UDw4Gj003100; Tue, 30 Aug 2016 09:58:04 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u7UDw4VA003097; Tue, 30 Aug 2016 09:58:04 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Drage\, Keith \(Nokia - GB\)" In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF5CB77@FR712WXCHMBA11.zeu.alcatel-lucent.com> (keith.drage@nokia.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 30 Aug 2016 09:58:04 -0400 Message-ID: <8760qi2wb7.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfOrMp2CRyak6a9xEFeTMXxioL/w+bEhfTVmCdax/suAIMFX05OKoUv9u98MnNtYK5z/sAgfs2Ui48ri4gfEf6vWxqixVhsswZZqzEZppIoOtQyaRDuYW V4vWaR3TWvGIjywxfmH3BPIU/t1qBwDPLaR4v/zUqswpb8IGqyvZLL0Iw6MNbxjDySnd5f3b7CXufY3CGchJdtxDXZgtyoCkZWbbx/IiQk62RlsZZcCDDdsF iAzzALfMEgGbGDvhNUx3Bn0QztpmPO9UnYeGiuHzNxOlD9gT230JRe2i4ZIT5RvP Archived-At: Cc: rg+ietf@randy.pensive.org, sipcore@ietf.org Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 13:58:13 -0000 "Drage, Keith (Nokia - GB)" writes: > The impact of doing this is that one will perform all the other > functions associated with the reINVITE or the UPDATE, including a full > SDP renegotiation. That is unnecessary and not the optimum use of > resources when one is trying to perform an emergency call. [...] You can do an UPDATE without an offer, and in that case, it's nearly a no-op, it doesn't do an SDP renegotiation. As Paul said, "Note in particular that the UPDATE can be effectively a no-op aside from its session-timer updating. (It need not carry an offer, though it MAY.)" Dale From nobody Tue Aug 30 07:06:47 2016 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 3D7FE12D60B for ; Tue, 30 Aug 2016 07:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqjGiKEH_GFd for ; Tue, 30 Aug 2016 07:06:41 -0700 (PDT) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8F1012D5F7 for ; Tue, 30 Aug 2016 07:06:40 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-03v.sys.comcast.net with SMTP id ejg5btw8P8GkCejgWb2pQN; Tue, 30 Aug 2016 14:06:40 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-09v.sys.comcast.net with SMTP id ejgVbUCUYm47VejgVbMhws; Tue, 30 Aug 2016 14:06:40 +0000 To: "Dale R. Worley" , "Drage, Keith (Nokia - GB)" References: <8760qi2wb7.fsf@hobgoblin.ariadne.com> From: Paul Kyzivat Message-ID: <0a3d9c8a-c73f-130f-dfc5-32a4e0bffa99@alum.mit.edu> Date: Tue, 30 Aug 2016 10:06:37 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <8760qi2wb7.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfE4CUnjbks0FD6LPgg7G6LBZSz7QXHDb89YnXLkXq94BRG7Ma4BJp0s6rj2JS8xBITb4AhJ8wZSehQDlF1h+XD5ybpq6ht/Sxy102Hu/rpIf/ncmXq7E 5jCVcFsp486SErHekRiWnAFPDuIZUvvX8wPg9ZdEDtkgibKO2G6Pbm74l1OjXTSJ5CNZtlbCW0cqgqClRUphNBw13neCMwsJVifjLcJ1O7+BGauKsL6mU9bR 5bHW8571ApbdYMArrsQNwjrt1FzxIm/+eXi3tSX98B9OAkmtU03vxkEJQoG0bv8u Archived-At: Cc: rg+ietf@randy.pensive.org, sipcore@ietf.org Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 14:06:45 -0000 On 8/30/16 9:58 AM, Dale R. Worley wrote: > "Drage, Keith (Nokia - GB)" writes: >> The impact of doing this is that one will perform all the other >> functions associated with the reINVITE or the UPDATE, including a full >> SDP renegotiation. That is unnecessary and not the optimum use of >> resources when one is trying to perform an emergency call. [...] > > You can do an UPDATE without an offer, and in that case, it's nearly a > no-op, it doesn't do an SDP renegotiation. As Paul said, "Note in > particular that the UPDATE can be effectively a no-op aside from its > session-timer updating. (It need not carry an offer, though it MAY.)" Also, we are here only discussing the *validity* of doing these things. Weighing the *merits* of one mechanism vs. another is a separate issue, but I prefer to have that debate only consider alternatives that are valid. And that debate can happen in ecrit rather than sipcore. Thanks, Paul From nobody Tue Aug 30 07:59:09 2016 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 DCE1412D5FB; Tue, 30 Aug 2016 07:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWhwuUeAGfGP; Tue, 30 Aug 2016 07:59:06 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FC6612D907; Tue, 30 Aug 2016 07:52:54 -0700 (PDT) X-AuditID: c618062d-980fb98000000a08-15-57c59f2b289e Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by (Symantec Mail Security) with SMTP id B5.0D.02568.B2F95C75; Tue, 30 Aug 2016 16:58:51 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0301.000; Tue, 30 Aug 2016 10:48:19 -0400 From: Suresh Krishnan To: "Gonzalo Salgueiro (gsalguei)" Thread-Topic: Suresh Krishnan's Discuss on draft-ietf-sipcore-dns-dual-stack-07: (with DISCUSS) Thread-Index: AQHR+liDPs9b1GwnaEqwCt9fLb9v3w== Date: Tue, 30 Aug 2016 14:48:18 +0000 Message-ID: References: <87k2fc7b8f.fsf@hobgoblin.ariadne.com> <39AEA207-8847-4178-8079-F31D1B50653F@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyuXRPiK72/KPhBm1HNC32/F3EbvH1nKLF 3Cl+FjP+TGS26P28kNni649NbA5sHlN+b2T1WLLkJ5PHrJ1PWAKYo7hsUlJzMstSi/TtErgy vm28zV6w0qzifeM9xgbGnTpdjBwcEgImEi19ZV2MXBxCAhsYJZ4s2ccG4SxnlJjxZj9TFyMn BxtQ0Yadn8FsEQFziT2/W8CKmAXeMkqsvH+IGSQhLJAgcfv7CzaQqSICiRJL+2Uh6vUkTl/u BSthEVCV+P6miw3E5hXwlej538ECYgsJpErcOXkcrIZRQEzi+6k1YLuYBcQlbj2ZD2ZLCAhI LNlznhnCFpV4+fgfK4StJDHn9TVmiHodiQW7P7FB2NoSyxa+ZobYJShxcuYTlgmMIrOQjJ2F pGUWkpZZSFoWMLKsYuQoLS7IyU03MtjECIyRYxJsujsY70/3PMQowMGoxMOrUHEkXIg1say4 MvcQowQHs5II77c5R8OFeFMSK6tSi/Lji0pzUosPMUpzsCiJ84o9UgwXEkhPLEnNTk0tSC2C yTJxcEo1MHabZfroKadP3bJK2ka4ufnSodi+ha9Lbd6cKFJ1O+rZ577h4/c5n6XTHD17pE86 r4iQ+5y6tGSqO8ualE9fOWT0n8b9kQwMjG0o090ltOR+VumaeRV2fDuz7fmaXgTvLt5fN7Ha pHSXtvn/WwlXly4utZ/3P5rxk+BLjuxt308UxCx5fmiDmRJLcUaioRZzUXEiABZr3taNAgAA Archived-At: Cc: SIPCORE , "draft-ietf-sipcore-dns-dual-stack@ietf.org" , The IESG , "sipcore-chairs@ietf.org" Subject: Re: [sipcore] Suresh Krishnan's Discuss on draft-ietf-sipcore-dns-dual-stack-07: (with DISCUSS) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 14:59:08 -0000 Hi Gonzalo,=0A= Looks good to me. I will clear once the new rev hits.=0A= =0A= Thanks=0A= Suresh=0A= =0A= Gonzalo Salgueiro (gsalguei) wrote:=0A= > Hi Suresh -=0A= >=0A= >=0A= > Just following up on this. The updated draft (-08) attempts to address y= our=0A= > DISCUSS. You can see the diffs here:=0A= >=0A= > https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-sipcore-dns-dual-stack-07&= url2=3Dhttp://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore= -dns-dual-stack-08.txt=0A= >=0A= > and the entire current draft can be found here:=0A= >=0A= > http://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore-dns-= du=3D=0A= > al-stack-08.txt=0A= > =0A= >=0A= > Once you confirm your points are addressed we will publish the -08 versio= n.=0A= >=0A= > Thanks,=0A= >=0A= > Gonzalo=0A= >=0A= >=0A= >> On Aug 19, 2016, at 4:30 PM, Dale R. Worley > > wrote:=0A= >>=0A= >> "Suresh Krishnan" > > writes:=0A= >>> * Section 3.1=0A= >>>=0A= >>> It is not clear to me what exactly the normative addendum is requiring= =0A= >>> the client to do as regards to the DNS query while implementing "The=0A= >>> dual-stack client SHOULD look up all address records". Does this mean= =0A= >>> that the client should do a AAAA (28) query followed by (or in parallel= =0A= >>> or preceded ) for a A (1) query? I think it would be good to clarify th= e=0A= >>> types and ordering/concurrency of the queries.=0A= >>=0A= >> Given that the responses to DNS queries do not depend on the order in=0A= >> which they are done, it seems to me that the only necessity is to=0A= >> specify that the client must do both A and AAAA queries.=0A= >>=0A= >> In regard to the specific record types, one of our goals was that the=0A= >> wording should be robust to the possibility of additional address=0A= >> families being created. Thus we used the wording=0A= >>=0A= >> The dual-stack client SHOULD look up all address records [...] for= =0A= >> all address family(ies) that it supports [...] for the domain name= =0A= >> and add the resulting addresses to the list of IP addresses to be= =0A= >> contacted.=0A= >>=0A= >> Assuming that the client supports exactly IPv4 and IPv6, the queries to= =0A= >> obtain address records for those families are A and AAAA. I don't see= =0A= >> that the text can be interpreted in a different way.=0A= >>=0A= >>> * Section 4=0A= >>>=0A= >>> I am a bit puzzled by the merging of the address lists from two separat= e=0A= >>> DNS queries in relation to RFC6724. This is how I see the destination= =0A= >>> address selection in RFC6724. The application ends up calling some kind= =0A= >>> of name resolution API (something like getaddrinfo()) with a=0A= >>> hostname/FQDN (say sip-1.example.com ) and th= is=0A= >>> results in a set of=0A= >>> addresses being returned. The destination address selection algorithm= =0A= >>> specified in Section 6 of RFC6724 then orders these addresses and picks= =0A= >>> one. I am not seeing how the second FQDN and its associated set of=0A= >>> addresses become involved in the RFC6724 process. Is this something tha= t=0A= >>> you are adding on top of RFC6724? Please clarify.=0A= >>=0A= >> One way of looking at it is that the full process of resolving the=0A= >> server's address is the process for SRV records (RFC 2782) on top of the= =0A= >> destination address selection process (RFC 6724). You've identified=0A= >> that correctly.=0A= >>=0A= >> The full process is fairly complicated, and the full documentation=0A= >> involves the interaction of RFC 3263, RFC 2782, and RFC 6724. But=0A= >> restricting our attention to the case in question:=0A= >>=0A= >> - The SRV records for domain name in the destination SIP URL are looked= =0A= >> up. (RFC 3263)=0A= >>=0A= >> - Depending on the priority and weight fields (and the randomization=0A= >> implied by them!), the "target" domain names of the SRV records are=0A= >> listed in a particular order. (RFC 2782)=0A= >>=0A= >> The case in question is when there are more than one SRV records for the= =0A= >> destination domain name, and hence more than one target domain name.=0A= >>=0A= >> - Each of those target domain names is expanded into a group of IPv4 and= =0A= >> IPv6 addresses by looking up the A and AAAA records for the name. Each= =0A= >> group is sorted by the destination selection algorithm. (This can be= =0A= >> accomplished by calling getaddrinfo() on the target domain name.)=0A= >> (RFC 6724)=0A= >>=0A= >> - The sorted groups of addresses for the target domain names are=0A= >> concatenated in the order of the target domain names.=0A= >>=0A= >> The crucial point here is that the destination selection reordering is= =0A= >> only within the groups that result from the target domain names of the= =0A= >> SRVs -- The whole algorithm is a two-field sort with the "major" sort=0A= >> being done by the SRV algorithm and the "minor" sort being done by=0A= >> destination selection.=0A= >>=0A= >> The original RFC 3263 specification describes the first two steps, but= =0A= >> presumes that the third step does not explicitly sort the addresses that= =0A= >> are obtained for the target domain name. As a general rule, people who= =0A= >> have digested the rules of RFC 3263 agree that the "naturally correct"= =0A= >> way to incorporate destination selection (now that it exists for IPv6)= =0A= >> is to expand the third step to include that sortation -- and,=0A= >> critically, that destination selection cannot reorder two addresses=0A= >> between groups that derive from different target domain names.=0A= >>=0A= >> The purpose of section 4 is to make that understanding normative.=0A= >>=0A= >> Now, comparing what I have written here with the text in section 4, I=0A= >> see that section 4 does not make explicit the ordered list of target=0A= >> domain names from the SRV records. And I can see that if the reader is= =0A= >> not thoroughly familiar with RFC 3263, that makes the overall process=0A= >> significantly less clear, because it doesn't make step 2 above explicit.= =0A= >>=0A= >> I've updated the draft -08 to show the list of target domain names.=0A= >> You can see the difference in=0A= >> https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-sipcore-dns-dual-stack-07= &url2=3Dhttp://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcor= e-dns-dual-stack-08.txt=0A= >> and the entire current draft in=0A= >> http://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore-dns= -dual-stack-08.{txt,html}=0A= >>=0A= >> Dale=0A= >=0A= =0A= From nobody Tue Aug 30 08:37:30 2016 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 3182B12D901 for ; Tue, 30 Aug 2016 08:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOGsjmybbkya for ; Tue, 30 Aug 2016 08:37:23 -0700 (PDT) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 305E012D942 for ; Tue, 30 Aug 2016 08:14:53 -0700 (PDT) Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-09v.sys.comcast.net with SMTP id ekjObOkTs1XXBekkWbZUeH; Tue, 30 Aug 2016 15:14:52 +0000 Received: from hobgoblin.ariadne.com ([73.100.16.189]) by resomta-ch2-15v.sys.comcast.net with SMTP id ekkVbKtOmkiRvekkWb6jXc; Tue, 30 Aug 2016 15:14:52 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u7UFEpRg011252 for ; Tue, 30 Aug 2016 11:14:51 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u7UFEpdJ011249; Tue, 30 Aug 2016 11:14:51 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org In-Reply-To: <87eg572yxn.fsf@hobgoblin.ariadne.com> (worley@ariadne.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 30 Aug 2016 11:14:50 -0400 Message-ID: <87oa4a1e6t.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfDP5+9Upf3ODYl3oEP5zyQamR3DBG2noGItB3zsqVm4yo2l0u1wwZxps5zuBu2lnSzcau47hrkHfY4uVqMLosSiSZ/eupdjuhOS21zLCSXtyNl/esmWO liRRMEsDsSCK7NDLV7M9qIjH6D5AKElk+8350NkOJGN1PV2rVM35aPEBER6oh43zt0X2wXUXIX789A== Archived-At: Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 15:37:28 -0000 Whoops, a mistake on my part in the previous discussion. It turns out that per RFC 6086, in an info package INFO request, the Info-Package header is attached to the message (not to the body part that is the info package contents), and the body part that is the info package contents is identified by the header "Content-Disposition: info-package". It turns out that my example is correct, because it didn't use those headers as I thought it did! Brian Rosen writes: > About the only part I don't get is the Content Disposition of > Info-Package on the whole body, no Content Disposition on the MSD, and > then a different Content Disposition on the DeviceInfo block. Thanks for mentioning that. I was wrong in my understanding of how Info-Package and Content-Disposition are to be used in info package INFO requests. (See above.) In re the Content-Disposition of the whole body, it is required to be "info-package", because of RFC 6086 and that we're constructing the info package so that the entire body is the contents thereof. In re the Content-Disposition of the Additional Data parts, I've used "by-reference", because that's what's shown in draft-ietf-ecrit-ecall-11. The draft seems to copy that from RFC 7852, which is about how Additional Data is carried in INVITE. That references back to RFC 5621, which says that by-reference informs the UAS that the body part can only be processed correctly in the context of the reference to the body part, and warns the UAS not to process the body part if the UAS can't find the reference. In this case, the reference is in the corresponding Call-Info header value. In re the Content-Disposition of the MSD part, that's messier. In a non-multipart body, the MSD part is the whole body, and by RFC 6086, the Content-Disposition must be "info-package". But once the MSD part is turned into a body part of a multipart, the "Content-Disposition: info-package" must be removed from it. We could just omit it, as in this situation, the UAC knows that the UAS processes MSDs. > It's clever, I will say that. That's the goal, construct an implementation that satisfies all the conflicting requirements. Dale From nobody Tue Aug 30 08:54:20 2016 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 864CC12D19E for ; Tue, 30 Aug 2016 08:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iciUx-pQ5R99 for ; Tue, 30 Aug 2016 08:54:14 -0700 (PDT) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4CCB12D938 for ; Tue, 30 Aug 2016 08:29:41 -0700 (PDT) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-06v.sys.comcast.net with SMTP id ekxobjTe42NhqekyrbQVyL; Tue, 30 Aug 2016 15:29:41 +0000 Received: from hobgoblin.ariadne.com ([73.100.16.189]) by resomta-ch2-17v.sys.comcast.net with SMTP id ekypbaBXprtSbekyqbBx7F; Tue, 30 Aug 2016 15:29:40 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u7UFTdN4012735; Tue, 30 Aug 2016 11:29:39 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u7UFTcAF012732; Tue, 30 Aug 2016 11:29:38 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC72486@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 30 Aug 2016 11:29:38 -0400 Message-ID: <87fupm1di5.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfPmZ3ez+8C2obFNnaApbf5wfFYtm+eN3+EDKYqKTVhYEXbZJGNFt/owc0ZcrDyDEgcz49HhBGuQDXnsExtAEMHJFAHoWPh4HiFmrmooYqhU11E/F4rPn d+8+PnB48Hm1aqTfUOlKas4AjRzmRoHjFUlLv0F81eMb2E3cmszYbAEdpFzrimcbmMnjak4rJ66slVo6BMx5HYRhP/ijelnGo7a2o2mJQUmIjT4qVdrU1ypE P3bGs3f1lqqSrYgSyfHR2A== Archived-At: Cc: sipcore@ietf.org, br@salsgiver.com Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 15:54:18 -0000 Christer Holmberg writes: > I may have missed something, but to me this seems more or less like > what has already been discussed in ECRIT: associate the MSD inside an > info package, but still use Call-Info to point to it. > And, how is that different from what is currently specified in > draft-ecall-11? It *is* "more or less" like draft-ietf-ecrit-ecall-11, but it has differences, and those differences are critical to not violating RFC 6086. (Which I gather is the entire point of this conversation.) In particular what is allowed as a body for the emergencyCallData.eCall.MSD info package is changed to also allow multipart bodies, some of which parts can be Additional Data types. Thus, we can move the Additional Data blocks *into* the info package body. BTW, the name of the package would better be "emergencyCallData.eCall" than "emergencyCallData.eCall.MSD". > As a side note, it's important to separate the *transport mechanism* > defined in Additional Data (chapter 6 of RFC 7852), and the *data > structures* (Device Information) defined in Additional Data. There is > currently no requirement for ecall to support the data structures, and > they are not mentioned/referenced in draft-ecall. That's true, but seems to be well-understood. That fact does have a technical consequence, though: The Additional Data components need to have "Content-Disposition: ...;handling=optional" headers so that the callees know that if they don't know how to process (a particular type of) Additional Data, the request should be accepted. But that's discussed in RRC 7852. Dale From nobody Tue Aug 30 09:41:18 2016 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 F21A812D611 for ; Tue, 30 Aug 2016 09:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Ru0mKzahia1 for ; Tue, 30 Aug 2016 09:41:02 -0700 (PDT) Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE3CF12D5EC for ; Tue, 30 Aug 2016 09:41:02 -0700 (PDT) Received: from resomta-po-03v.sys.comcast.net ([96.114.154.227]) by resqmta-po-04v.sys.comcast.net with SMTP id em5nbsUkAGkXBem5tbQpRl; Tue, 30 Aug 2016 16:41:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-03v.sys.comcast.net with SMTP id em5sbfZxj6ohdem5tbBc3o; Tue, 30 Aug 2016 16:41:01 +0000 To: Christer Holmberg , "sipcore@ietf.org" References: <87shtr5kmq.fsf@hobgoblin.ariadne.com> <0AB492FC-F521-40A2-BC74-7098D3427DF8@salsgiver.com> <7594FB04B1934943A5C02806D1A2204B4BC69809@ESESSMB209.ericsson.se> <5e29dcc7-f8ec-03b0-2ded-dcb8a7b2a388@alum.mit.edu> From: Paul Kyzivat Message-ID: <8b22a4c6-c07a-ac43-edbe-2b6cf0e4babb@alum.mit.edu> Date: Tue, 30 Aug 2016 12:41:00 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfOpZ1bo0/224tf34BpgQir36hxVjFRwPM0I+7Aotcxv1gj7BaMhI1CW2hlDTGiMpAzE9dZRQMLVTq5B83wNYRFu311YmwVRbQjsk6binrynVx1/62wTy VXagBSLtaY94WuYWrnZ+QZqYyqhCYL+o8K/cUZvNi7mQ7j1N4hVFpR9Nh3pmRVp9rtvBEj8s48G8feL4lFb7zibiA/UNaVt0S4i9aDN5nkffRMT1bQZljhBG Archived-At: Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 16:41:04 -0000 On 8/30/16 2:28 AM, Christer Holmberg wrote: > Hi, > >>>> Christer seems to think that if we send a body part in an INFO message >>>> that isnt defined in an INFO package, that it constitutes a pre-6086 >>>> INFO use, which is not allowed. >Here, were using Call-Info to point >>>> to, and label the body part, recognizing that there is another body >>>> part that IS part of the INFO package in the message. >>>> >>>> The fact that the Call-Info body part is in the INFO message doesnt >>>> make it a pre-6086 use of INFO. Its just introduced by Call-Info >>>> rather than INFO. >>> >>> I am saying that: >>> >>> 1) the data you send is associated with the ecall application; and >>> 2) that the data is NOT associated with a pre-6086 use of INFO - it is >>> a new INFO usage >>> >>> ...and therefore you have to use an Info Package. >> >> And I"m saying: >> >> - if you have an application that can get information using a variety >> of sip mechanisms (e.g., from call-info in an invite, and from an >> info package body) >> - then more than one mechanism is applicable to a single message >> (e.g. a call-info in an INFO) then you can use whatever combination >> makes sense. > > So, by claiming that content X can also be sent in a non-INFO request you > dont have to define an Info Package? I don't need to do so if I don't use INFO. > Which also means that the usage will not be registered in the info package > registry (and probably not in any other registry either), which means that > others can define a slightly different usage of INFO for delivering > exactly the same content, with the same semantics - again, one of the > things we wanted to prevent with RFC 6086 and the info package registry I'm not sure I understand what you are saying here. I *think* you are talking about a case where I'm piggybacking on a *legacy* INFO. Is that what you mean? I thought we agreed to take that off the table. Legacy INFO can only be used for legacy cases. This clearly isn't a legacy case. I guess, in theory, you might have need to use a legacy INFO for one of the legacy purposes for which it is already valid. And you might also have a need to send something like a call-info with a body. In that case I suppose you *might* consider piggybacking it on that INFO. It is a hazy case, because the usage of legacy INFO is so ill-defined. My guess is that it wouldn't work. But this is different from using a legacy info *solely* as a carrier for a call-info body. That seems to be entirely invalid. Thanks, Paul From nobody Tue Aug 30 10:25:37 2016 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 1C7F412D0E4 for ; Tue, 30 Aug 2016 10:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JX_0XeNJ9Pk for ; Tue, 30 Aug 2016 10:25:34 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C68912B010 for ; Tue, 30 Aug 2016 10:25:34 -0700 (PDT) X-AuditID: c1b4fb3a-c91fe700000009bd-04-57c5c189145b Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by (Symantec Mail Security) with SMTP id F1.2C.02493.981C5C75; Tue, 30 Aug 2016 19:25:32 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0301.000; Tue, 30 Aug 2016 19:25:28 +0200 From: Christer Holmberg To: "Dale R. Worley" Thread-Topic: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 Thread-Index: AQHSAtNR+pjwWhmVIEetajd/MHhvMaBhv+EQ Date: Tue, 30 Aug 2016 17:25:28 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC778D6@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BC72486@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) <87fupm1di5.fsf@hobgoblin.ariadne.com> In-Reply-To: <87fupm1di5.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGbFdVLfn4NFwg0nv1C2mHdvAbvH1xyY2 i5cnyhyYPSbv/8rssWTJTyaPRYd+sAYwR3HZpKTmZJalFunbJXBlbO3axVbQL1Ax83hWA+N/ ni5GTg4JAROJ6/9Ps3UxcnEICaxnlNj84Q4bSEJIYAmjRPfFpC5GDg42AQuJ7n/aIKaIgKZE x4IckApmgSCJn8eWsYCEhQU8JV6sLAAJiwh4Sdx+8ZAdwjaS2Dl7HytICYuAqsSJTeogYV4B X4n/PZuYIZZOZ5RY8HEW2FJOAWOJZ/O2soDYjAJiEt9PrWGCWCUucevJfCaIiwUkluw5zwxh i0q8fPyPFcJWklix/RIjRL2OxILdn9ggbG2JZQtfM0MsFpQ4OfMJywRG0VlIxs5C0jILScss JC0LGFlWMYoWpxYX56YbGemlFmUmFxfn5+nlpZZsYgRGzMEtv612MB587niIUYCDUYmHV6Hi SLgQa2JZcWXuIUYJDmYlEd6qfUfDhXhTEiurUovy44tKc1KLDzFKc7AoifP6v1QMFxJITyxJ zU5NLUgtgskycXBKNTAmsv9me/J7r3O64mItHdFdR74t1XWc06G5ykGmLZP/xmHer/e/XM9a 3VPEz9wRvULsl4Ggd5Rm1G9FzxqvCYaliR3+vT88fswL6qr+YJzttKhj3c49O7MspVU7XZ8c LxU2WeXgujVB1Vded1PfR7e7vpbXNn9bJS/wRJJl0gfpLeEd/27vXqXEUpyRaKjFXFScCAB8 kDwOlAIAAA== Archived-At: Cc: "sipcore@ietf.org" , "br@salsgiver.com" Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 17:25:36 -0000 Hi, >> I may have missed something, but to me this seems more or less like=20 >> what has already been discussed in ECRIT: associate the MSD inside an=20 >> info package, but still use Call-Info to point to it. >> >> And, how is that different from what is currently specified in=20 >> draft-ecall-11? > > It *is* "more or less" like draft-ietf-ecrit-ecall-11, but it has differe= nces, and those differences are critical to=20 > not violating RFC 6086. (Which I gather is the entire point of this conv= ersation.) > > In particular what is allowed as a body for the emergencyCallData.eCall.M= SD info package is changed to also allow multipart bodies,=20 > some of which parts can be Additional Data types. Thus, we can move the A= dditional Data blocks *into* the info package body. Nothing prevents you from having a multipart body, with a SINGLE body insid= e. There is even an example of that in RFC 6086. >> BTW, the name of the package would better be "emergencyCallData.eCall" >> than "emergencyCallData.eCall.MSD". >> >> As a side note, it's important to separate the *transport mechanism*=20 >> defined in Additional Data (chapter 6 of RFC 7852), and the *data >> structures* (Device Information) defined in Additional Data. There is=20 >> currently no requirement for ecall to support the data structures, and=20 >> they are not mentioned/referenced in draft-ecall. > > That's true, but seems to be well-understood. I just wanted to point it out, since you started to talk about the AD data = structures. > That fact does have a technical consequence, though: The Additional Data= components need > to have "Content-Disposition: > ...;handling=3Doptional" headers so that the callees know that if they do= n't know how to process=20 > (a particular type of) Additional Data, the request should be accepted. = But that's discussed in RRC 7852. When you indicate support of an info package, you indicate that you support= all MIME types associated with the info package. Regards, Christer From nobody Tue Aug 30 10:26:14 2016 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 8467E12D12E for ; Tue, 30 Aug 2016 10:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0DOEjTrNPMj for ; Tue, 30 Aug 2016 10:26:10 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5418D12D0E4 for ; Tue, 30 Aug 2016 10:26:10 -0700 (PDT) X-AuditID: c1b4fb25-ca31e98000001071-1a-57c5c1b06620 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by (Symantec Mail Security) with SMTP id C1.79.04209.0B1C5C75; Tue, 30 Aug 2016 19:26:08 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0301.000; Tue, 30 Aug 2016 19:25:40 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 Thread-Index: AQHSAiYM+pjwWhmVIEetajd/MHhvMaBgS2qAgAAv+uD//++FgIAAjvfggABrcgCAAFlWYA== Date: Tue, 30 Aug 2016 17:25:40 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC778E6@ESESSMB209.ericsson.se> References: <87eg572yxn.fsf@hobgoblin.ariadne.com> <76D1BB4B-CE62-42BD-A694-E5140341DD7E@salsgiver.com> <7594FB04B1934943A5C02806D1A2204B4BC72486@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC72B1C@ESESSMB209.ericsson.se> <0a72071a-d1ea-d203-f47b-5eb260f6cdb5@alum.mit.edu> In-Reply-To: <0a72071a-d1ea-d203-f47b-5eb260f6cdb5@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM2K7uu6Gg0fDDfq/6lms2HCA1eLrj01s Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfG37svWAveB1ec3rOXsYHxjlUXIyeHhICJ xJa9n1i7GLk4hATWM0pc332PDcJZwigx69B2pi5GDg42AQuJ7n/aIA0iAoESV5dMYAYJCwt4 SrxYWQAR9pK4/eIhO4QdJrHh02MWEJtFQFWiZfcEVhCbV8BX4t3m1SwQ4+8xSexaeIYRJMEp 4CAx82sHG4jNKCAm8f3UGiYQm1lAXOLWk/lMEIcKSCzZc54ZwhaVePn4HyuErSSxYvslRoh6 HYkFuz+xQdjaEssWvmaGWCwocXLmE5YJjCKzkIydhaRlFpKWWUhaFjCyrGIULU4tTspNNzLW Sy3KTC4uzs/Ty0st2cQIjIeDW36r7mC8/MbxEKMAB6MSD69CxZFwIdbEsuLK3EOMEhzMSiK8 VfuOhgvxpiRWVqUW5ccXleakFh9ilOZgURLn9X+pGC4kkJ5YkpqdmlqQWgSTZeLglGpglI14 pMEQIJ2pacGrnePhGCG9bmWV+JLQ8PS7t2MDFU+LWXafuKyUH6juFTPXde37hdOvlHonHVi3 mutqcfik14tKF647KnKbbbXyK8+bbYHz7hy903nqi+kGJqkrzqJNJ2+lxHeV2Rl7v72bxB+7 NGx5ZP6czADLGKPsd6kngpWDEgIvGAQrsRRnJBpqMRcVJwIA6Qsu3YMCAAA= Archived-At: Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 17:26:12 -0000 Hi, >>> No, this really does return the MSD in an info block, but it also has >>> the Additional Data header pointing to the body part that contains the = MSD. >> >> That's what I said :) >> >> And, how is that different from what is currently specified in=20 >> draft-ecall-11? > > Its different because of the nesting structure of the body parts, and the= ir respective content-disposition values. > > In this form the MSD has a c-d of by-reference, as it should. And yet it = meets your objections because it is *part* of=20 > the info package body that has a c-d of info-package, as it should. It still uses Call-Info to define the semantics of content - THAT is my obj= ection. You don't define the semantics within the info package description = - you are only using an info package as a "cosmetic wrapper" for another me= chanism. Regards, Christer > > > > > On Aug 29, 2016, at 3:10 PM, Christer Holmberg > > wrote: > > > > I may have missed something, but to me this seems more or less like > what has already been discussed in ECRIT: associate the MSD inside > an info package, but still use Call-Info to point to it. > > As a side note, it's important to separate the *transport mechanism* > defined in Additional Data (chapter 6 of RFC 7852), and the *data > structures* (Device Information) defined in Additional Data. There > is currently no requirement for ecall to support the data > structures, and they are not mentioned/referenced in draft-ecall. > > Regards, > > Christer > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Brian Ro= sen > Sent: 30 August 2016 00:02 > To: Dale R. Worley > > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Using an INFO package in > draft-ietf-ecrit-ecall-11 > > Verrrry interesting. > > About the only part I don't get is the Content Disposition of > Info-Package on the whole body, no Content Disposition on the MSD, > and then a different Content Disposition on the DeviceInfo block. > > But I think it would be fairly easy to deal with if you were > expecting it, which is what an implementation that handled eCall > (and thus the emergencyCallData.eCall.MSD part) would do. > > It's clever, I will say that. > > Brian > > > On Aug 29, 2016, at 11:49 AM, Dale R. Worley > wrote: > > TL;DR: If the body for an emergencyCallData.eCall.MSD info > package is > defined correctly, we can organize the data in an INFO request th= e > same way that we do in an INVITE request and still follow the inf= o > package rules strictly. > > > After asking around, I have learned that my previous message on > this > subject severely buried the lead: The useful point followed a lo= ng > message example, which itself followed several pages of recap of > the > points in question. As far as I can tell, nobody had the > stamina to > read that far, and in retrospect, I don't blame them. > > So this time, I'm going recap my proposal and put the important > points > *first*: > > It it possible to define an info package for use by > draft-ietf-ecrit-ecall-11 that includes all of the Additional Dat= a > (RFC > 7852) in a way that strictly follows the rules for info packages > (RFC > 6086), but also uses the same data format used by initial > Additional > Data reporting. This solves the dilemma that we have been > discussing. > > The key is to define the info package properly. The info package > definition is: > > The body for an emergencyCallData.eCall.MSD info package is: > > - either an application/emergencyCallData.eCall.MSD+per > (containing > the MSD), or > > - a multipart body containing exactly: > > - exactly one application/emergencyCallData.eCall.MSD+per p= art > (containing the MSD), > > - zero or more application/EmergencyCallData.DeviceInfo+xml > parts (containing Additional Data), and > > - zero or one application/pidf+xml part (containing > geolocation > data). > > This allows all of the information items that we want to carry > in the > INFO message to be part of one info package, which is the body > of the > INFO message. > > In draft-ietf-ecrit-ecall-11 usage, all body parts will > typically be > pointed to by a Geolocation or Call-Info header. > > A typical example is this INFO request. I've assembled the > example by > inserting the Additional Data from an example in RFC 7852 into th= e > response INFO request in draft-ietf-ecrit-ecall-11: > > INFO urn:service:sos.ecall.automatic SIP/2.0 > To: urn:service:sos.ecall.automatic > From: ;tag=3D9fxced76sl > Call-ID: 3848276298220188511@atlanta.example.com > > Call-Info: ; > purpose=3DemergencyCallData.eCall.MSD > Call-Info: > ;purpose=3Dicon, > ;purpose=3Dinfo, > > ;purpose=3DEmergencyCallData.ProviderInfo, > > ;purpose=3DEmergencyCallData.DeviceInfo > Geolocation: > Geolocation-Routing: yes > Accept: application/sdp, application/pidf+xml, > application/emergencyCallData.eCall.control+xml > CSeq: 51862 INFO > Info-Package: emergencyCallData.eCall.MSD > Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, > SUBSCRIBE, NOTIFY, UPDATE > Content-Disposition: info-package > Content-Transfer-Encoding: binary > Content-Type: multipart/mixed; boundary=3Dboundary1 > Content-Length: ... > > --boundary1 > Content-Type: application/emergencyCallData.eCall.MSD+per > Content-ID: 4567890123@atlanta.example.com > > > ...MSD in ASN.1 PER encoding goes here... > > --boundary1 > Content-Type: application/EmergencyCallData.DeviceInfo+xml > Content-ID: <0123456789@atlanta.example.com > > > Content-Disposition: by-reference;handling=3Doptional > > > xmlns:dev=3D > "urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo"> > ... > > > --boundary1 > Content-Type: application/EmergencyCallData.ProviderInfo+xml > Content-ID: <1234567890@atlanta.example.com > > > Content-Disposition: by-reference;handling=3Doptional > > > xmlns:pi=3D > "urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo"= > > ... > > --boundary1-- > > Note the absence of a Recv-Info header (which is forbidden in INF= O > requests (RFC 6086 section 4.2.1). > > Note the positioning of the Info-Package header as applying to th= e > entire body. > > As indicated by the Info-Package header, the entire multipart > body is > the body of the info package. The info package body includes > all of > the information contained in the body, including the MSD and the > Additional Data, thus strictly following RFC 6086. > > Three of the Call-Info header values, > cid:4567890123@atlanta.example.com; > purpose=3DemergencyCallData.eCall.MSD > > ;purpose=3DEmergencyCallData.ProviderInfo > > ;purpose=3DEmergencyCallData.DeviceInfo > point to body parts within the info package that provide Addition= al > Data. > > The Geolocation header points to an external application/pidf+xml > resource. But it could contain a cid: URL pointing to an > additional > application/pidf+xml body part. > > Note that the layout of the body parts is the same as is used in = an > INFO request containing Additional Data. (Compare with the > example in > RFC > 7852 section 7.) > > This implies that the logic for inserting an additional Additiona= l > Data part into an INFO request is essentially the same as the log= ic > for inserting it into an INVITE request. > > Dale > > _______________________________________________ > 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 > > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Aug 30 10:29:59 2016 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 23B8112D61F for ; Tue, 30 Aug 2016 10:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DccUa9GDRcs for ; Tue, 30 Aug 2016 10:29:55 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D414E12D608 for ; Tue, 30 Aug 2016 10:29:54 -0700 (PDT) X-AuditID: c1b4fb3a-c7bff700000009bd-ba-57c5c29062c2 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by (Symantec Mail Security) with SMTP id 20.9C.02493.092C5C75; Tue, 30 Aug 2016 19:29:53 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0301.000; Tue, 30 Aug 2016 19:29:52 +0200 From: Christer Holmberg To: "Dale R. Worley" , "sipcore@ietf.org" Thread-Topic: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 Thread-Index: AQHSAtFA+pjwWhmVIEetajd/MHhvMaBhwaHw Date: Tue, 30 Aug 2016 17:29:51 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC77944@ESESSMB209.ericsson.se> References: <87eg572yxn.fsf@hobgoblin.ariadne.com> (worley@ariadne.com) <87oa4a1e6t.fsf@hobgoblin.ariadne.com> In-Reply-To: <87oa4a1e6t.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM2K7ou7EQ0fDDV5tE7L4+mMTm8XLE2UO TB6T939l9liy5CdTAFMUl01Kak5mWWqRvl0CV8bdXX2MBSc5KnYdOMvewPiSrYuRk0NCwETi +9Z1rF2MXBxCAusZJVr3rmMBSQgJLGGU6Lgs08XIwcEmYCHR/U8bJCwiECSxqXMFM0hYWMBT 4sXKAoiwl8TtFw/ZIWwjia8LnoDZLAKqEs+mH2MGsXkFfCUWL9rBDjG9QGLjwk1MIDangLHE 7ZcTwbYyCohJfD+1BizOLCAucevJfCaIMwUkluw5zwxhi0q8fPyPFcJWklix/RIjRL2OxILd n9ggbG2JZQtfQ+0VlDg58wnLBEaRWUjGzkLSMgtJyywkLQsYWVYxihanFhfnphsZ6aUWZSYX F+fn6eWllmxiBEbCwS2/rXYwHnzueIhRgINRiYdXoeJIuBBrYllxZe4hRgkOZiUR3qp9R8OF eFMSK6tSi/Lji0pzUosPMUpzsCiJ8/q/VAwXEkhPLEnNTk0tSC2CyTJxcEo1MC5Yu3HD1WVR Tzd7W978dsIx8dzvd0a1stIPXSsPrzgZy2jxybeJXfZpAFM2v7L0Xk22Ocoyk7rWMvm7S2de UgllcbmrFZMRcmT9yf8Tr2uUftrJlNZasmDdxOakZ4ZTJrSafHm01SiSbcKdiZIT3Z8svFQR eClzpvTtyYq6P54JdfYnWu1sOK3EUpyRaKjFXFScCAApm82AgAIAAA== Archived-At: Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 17:29:56 -0000 Hi, ... > In re the Content-Disposition of the whole body, it is required to be "in= fo-package", because of RFC 6086 and that we're=20 > constructing the info package so that the entire body is the contents the= reof. > > In re the Content-Disposition of the Additional Data parts, I've used "by= -reference", because that's what's shown in=20 > draft-ietf-ecrit-ecall-11. The draft seems to copy that from RFC 7852, w= hich is about how Additional Data is carried in=20 > INVITE. That references back to RFC 5621, which says that by-reference i= nforms the UAS that the body part can only=20 > be processed correctly in the context of the reference to the body part, = and warns the UAS not to process the body part=20 > if the UAS can't find the reference. In this case, the reference is in t= he corresponding Call-Info header value. ...and that's the issue. When you use an info package, you define which MIM= E types are associated with the info package, and the semantics/context of = those MIME types. There is no need for Call-Info. Regards, Christer From nobody Wed Aug 31 08:59:26 2016 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 9CA5212D512 for ; Wed, 31 Aug 2016 08:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSeg_k9lwVtq for ; Wed, 31 Aug 2016 08:59:20 -0700 (PDT) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6A0912D5AF for ; Wed, 31 Aug 2016 08:56:17 -0700 (PDT) Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-10v.sys.comcast.net with SMTP id f7r4byaqHRingf7s9bjdTi; Wed, 31 Aug 2016 15:56:17 +0000 Received: from hobgoblin.ariadne.com ([73.100.16.189]) by resomta-ch2-11v.sys.comcast.net with SMTP id f7s8b2ZbHiwRZf7s8bUDTi; Wed, 31 Aug 2016 15:56:17 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u7VFuGaD007475; Wed, 31 Aug 2016 11:56:16 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u7VFuGrG007472; Wed, 31 Aug 2016 11:56:16 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC778E6@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 31 Aug 2016 11:56:16 -0400 Message-ID: <87d1kp9bkv.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfAZMEkvkFQ/8Trfe9cesWaNgojCsr6z2XSj878bYnuJE8zC1XabYedfOLTh43kOdxBSqJM96QrjxJuoxuZqKg9wZ6f8M1+xjoNfNbGXApp3muZPcky1y sz93TkqDjGgVw2LqmjkYAXIWsimp8va6Fb1f5NXAIexEFi266FYW34Fcnrn04xBJIdMePFCfy4GJVrCvj2foxmfTxHHZ99Gte+R8VltI1EyR/H7Nt3NFP/HD Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 15:59:25 -0000 Christer Holmberg writes: > It still uses Call-Info to define the semantics of content - THAT is > my objection. You don't define the semantics within the info package > description - you are only using an info package as a "cosmetic > wrapper" for another mechanism. Not necessarily. We could *define* the semantics of the body parts to be due to their Mime types, and then say that in *this* usage, you also provide the UAS with a hint in the form of Call-Info headers. Really, the same thing comes up with the original INVITE. The UAS can tell from the Mime types how to handle the body parts, but RFC 7852 specifies that Call-Info headers must also be supplied. If I'd been commenting on that draft, I'd have asked why the redundancy. But IMHO this is slicing hairs finer than even I am willing to go. I think we've got a solution that is within the rules of RFC 6086, even if they are read strictly. It solves all the practical problems. And it doesn't require much additional implementation work (beyond what is needed for INVITEs) -- other than the question of how intermediaries recognize which INFOs need to have Additional Data attached. Dale From nobody Wed Aug 31 09:21:21 2016 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 2EBF812B074 for ; Wed, 31 Aug 2016 09:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cvf2VCDGppv for ; Wed, 31 Aug 2016 09:21:12 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34CF412D0B0 for ; Wed, 31 Aug 2016 09:21:12 -0700 (PDT) X-AuditID: c1b4fb30-ea88e980000009f9-18-57c703f6b9d6 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by (Symantec Mail Security) with SMTP id FE.E5.02553.6F307C75; Wed, 31 Aug 2016 18:21:10 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0301.000; Wed, 31 Aug 2016 18:21:10 +0200 From: Christer Holmberg To: "Dale R. Worley" Thread-Topic: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 Thread-Index: AQHSA6A0+pjwWhmVIEetajd/MHhvMaBjPd5Q Date: Wed, 31 Aug 2016 16:21:09 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC7B00A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BC778E6@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) <87d1kp9bkv.fsf@hobgoblin.ariadne.com> In-Reply-To: <87d1kp9bkv.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM2K7ge435uPhBue3qVl8/bGJzeLliTIH Jo/J+78yeyxZ8pMpgCmKyyYlNSezLLVI3y6BK+P2jKvMBft4Ki6sOMXSwPiTs4uRk0NCwETi xpc1zCC2kMB6Rom1a7Ug7CWMEh+e5XUxcnCwCVhIdP/TBjFFBDQlOhbkgFQwA5mPdu5lAgkL C3hKvFhZABIWEfCSuP3iITuEbSRx5+g6VpASFgFViavPqkHCvAK+ElMPP2frYuQC2jOdUWJN zzmwAzgFjCVOru1nA7EZBcQkvp9awwSxSlzi1pP5TBAHC0gs2XOeGcIWlXj5+B8rhK0ksej2 Z6h6HYkFuz+xQdjaEssWvmaGWCwocXLmE5YJjKKzkIydhaRlFpKWWUhaFjCyrGIULU4tTspN NzLSSy3KTC4uzs/Ty0st2cQIjI6DW34b7GB8+dzxEKMAB6MSD+/Ck0fDhVgTy4orcw8xSnAw K4nwLmQ4Hi7Em5JYWZValB9fVJqTWnyIUZqDRUmc1/+lYriQQHpiSWp2ampBahFMlomDU6qB UcCxyHvLdDnFL7tSwst7FPuXxIn/eLJzssfzvqN3N8n7/fo29QxnjI2TshT70QLWtdlzFTuS W3j2BN4UfdO3c3VtTPKc4gLXa4WXRDSlGCbHZd1Wvb3j1h9JeyYNgcdRLH0unKdOfjwR5MR9 jXP+dIc2fb1FLxevVT3tfN9d3/LUUpYPwa/YlViKMxINtZiLihMBkPLpoIoCAAA= Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 16:21:18 -0000 Hi, >> It still uses Call-Info to define the semantics of content - THAT is=20 >> my objection. You don't define the semantics within the info package=20 >> description - you are only using an info package as a "cosmetic=20 >> wrapper" for another mechanism. > >Not necessarily. We could *define* the semantics of the body parts to be = due to their Mime types, and then >say that in *this* usage, you also provide the UAS with a hint in the form= of Call-Info headers. > >Really, the same thing comes up with the original INVITE. The UAS can tel= l from the Mime types how to handle=20 >the body parts, but RFC 7852 specifies that Call-Info headers must also be= supplied. If I'd been commenting on=20 >that draft, I'd have asked why the redundancy. In general, the MIME types alone don't always tell you everything about the= semantics/context - that's one of the reason we did RFC 6086. In INVITEs we don't use info packages, so one way to associate semantics/co= ntext with MIME bodies is using Call-Info. >But IMHO this is slicing hairs finer than even I am willing to go. I thin= k we've got a solution that is within the rules of RFC 6086, even if they a= re read strictly. It solves all the >practical problems.=20 What practical problems?=20 >And it doesn't require much additional implementation work (beyond what is= needed for INVITEs) -- other than the question of how intermediaries=20 >recognize which INFOs need to have Additional Data attached. Not sure I understand your issue regarding intermediaries. Regards, Christer From nobody Wed Aug 31 13:18:08 2016 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 3E38212D0E6 for ; Wed, 31 Aug 2016 13:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvLs0x6oNgw4 for ; Wed, 31 Aug 2016 13:18:00 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F96E12D09D for ; Wed, 31 Aug 2016 13:18:00 -0700 (PDT) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-05v.sys.comcast.net with SMTP id fBvSb2Wv72FGMfBxPbDL88; Wed, 31 Aug 2016 20:17:59 +0000 Received: from hobgoblin.ariadne.com ([73.100.16.189]) by resomta-ch2-01v.sys.comcast.net with SMTP id fBxOb4pkrL4G2fBxPbuBnV; Wed, 31 Aug 2016 20:17:59 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u7VKHwvQ019356; Wed, 31 Aug 2016 16:17:58 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u7VKHvxh019353; Wed, 31 Aug 2016 16:17:58 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC7B00A@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 31 Aug 2016 16:17:57 -0400 Message-ID: <871t14ae16.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfK3z4ttWtsxbi4o3FDE8ANDmyLylMQfhxRmxICBt4QZmiFyBzoLxQR0wqmrfPdFxYeGxDamKoXQJVhkHr4qf+P+8yLJg4uU/XXe47m2/Gll06yrlxpbl 0bpw/6KrECcgFqN923eRWFScpjayLosx3fSaa06O/10WpNBYU6EMOPmflKc3OJQcto0I8De5BSkVhmmunZmGz+dGsTbmNlOmcpf0dqBDnGDJsFgUm9wvIS4d Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 20:18:01 -0000 Christer Holmberg writes: >>But IMHO this is slicing hairs finer than even I am willing to go. I >>think we've got a solution that is within the rules of RFC 6086, even >>if they are read strictly. It solves all the practical problems. > > What practical problems? As far as I can see, we need a way of carrying the Additional Data, and it would be useful to carry it in much the same way as it is carried in the INVITE. Are there others? >>other than the question of how intermediaries recognize which INFOs >>need to have Additional Data attached. > > Not sure I understand your issue regarding intermediaries. If I understand the processing correctly, the caller sends an INFO request containing the control data block, but various intermediaries between the caller and the callee add the Additional Data blocks. In order to get the mechanism to work correctly, the intermediaries need to recognize the INFO requests to which they should add Additional Data resends. There needs to be a clear specification which INFO requests get this processing and which don't, and that specification has to allow for unanticipated future uses. Dale From nobody Wed Aug 31 13:32:21 2016 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 7D4BA12D780 for ; Wed, 31 Aug 2016 13:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cA-ZNlzHpOJD for ; Wed, 31 Aug 2016 13:32:16 -0700 (PDT) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51C4312D775 for ; Wed, 31 Aug 2016 13:32:16 -0700 (PDT) Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-09v.sys.comcast.net with SMTP id fCB0bQyVy1XXBfCBDbeJat; Wed, 31 Aug 2016 20:32:15 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-02v.sys.comcast.net with SMTP id fCBCbnqOSHQ26fCBDbbCT1; Wed, 31 Aug 2016 20:32:15 +0000 To: sipcore@ietf.org References: <7594FB04B1934943A5C02806D1A2204B4BC778E6@ESESSMB209.ericsson.se> <87d1kp9bkv.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B4BC7B00A@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <1f97dad7-d573-0276-edd5-2a5ff5d63f74@alum.mit.edu> Date: Wed, 31 Aug 2016 16:32:13 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC7B00A@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfKoTC369DPve3VSbKtfZVCCoPA6mtk/Yf5DNyhcVNHSeTTsoixjsWsrb45G6XsS7dCXqe2NwatPvsPa/x8gcVDNk4eT/jeHwMqT+Wh+xNo+ghKU1xajf QxdhKzcW/wzVKGOaI1r1CcFn+4TwpefQoM0QCm0+B7tcI3ssNTpgZV9YnfKzZAs+kGAh1V3lNKqC3w== Archived-At: Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 20:32:19 -0000 On 8/31/16 12:21 PM, Christer Holmberg wrote: > Hi, > >>> It still uses Call-Info to define the semantics of content - THAT is >>> my objection. You don't define the semantics within the info package >>> description - you are only using an info package as a "cosmetic >>> wrapper" for another mechanism. >> >> Not necessarily. We could *define* the semantics of the body parts to be due to their Mime types, and then >> say that in *this* usage, you also provide the UAS with a hint in the form of Call-Info headers. >> >> Really, the same thing comes up with the original INVITE. The UAS can tell from the Mime types how to handle >> the body parts, but RFC 7852 specifies that Call-Info headers must also be supplied. If I'd been commenting on >> that draft, I'd have asked why the redundancy. > > In general, the MIME types alone don't always tell you everything about the semantics/context - that's one of the reason we did RFC 6086. +1 > In INVITEs we don't use info packages, so one way to associate semantics/context with MIME bodies is using Call-Info. But call-info (with or without an attached body) wasn't defined solely for INVITE. It was defined for any message in which you have need to attach info described by one of the defined call-info purposes. So, the UA can have logic that says: I'm sending a request, is there some call-info data that I should attach to it? And if the answer is yes, then it can do so in a consistent way. It would be much more of a mess if it then had to consider what the method was, and special case how it attaches the information. Thanks, Paul >> But IMHO this is slicing hairs finer than even I am willing to go. I think we've got a solution that is within the rules of RFC 6086, even if they are read strictly. It solves all the >practical problems. > > What practical problems? > >> And it doesn't require much additional implementation work (beyond what is needed for INVITEs) -- other than the question of how intermediaries >> recognize which INFOs need to have Additional Data attached. > > Not sure I understand your issue regarding intermediaries. > > Regards, > > Christer > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Wed Aug 31 13:44:28 2016 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0951D12D76A; Wed, 31 Aug 2016 13:44:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.31.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147267626703.31865.1491771995696925817.idtracker@ietfa.amsl.com> Date: Wed, 31 Aug 2016 13:44:27 -0700 Archived-At: Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-dns-dual-stack-08.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 20:44:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core of the IETF. Title : Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network Authors : Olle E. Johansson Gonzalo Salgueiro Vijay Gurbani Dale R. Worley Filename : draft-ietf-sipcore-dns-dual-stack-08.txt Pages : 12 Date : 2016-08-31 Abstract: RFC 3263 defines how a Session Initiation Protocol (SIP) implementation, given a SIP Uniform Resource Identifier (URI), should locate the next-hop SIP server using Domain Name System (DNS) procedures. As SIP networks increasingly transition from IPv4-only to dual-stack, a quality user experience must be ensured for dual- stack SIP implementations. This document updates the DNS procedures described in RFC 3263 for dual-stack SIP implementations in preparation for forthcoming specifications for applying Happy Eyeballs principles to SIP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-dns-dual-stack/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sipcore-dns-dual-stack-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-dns-dual-stack-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 31 13:46:47 2016 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 9D74512B018 for ; Wed, 31 Aug 2016 13:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XinUCNRg8PlA for ; Wed, 31 Aug 2016 13:46:42 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70CB012B014 for ; Wed, 31 Aug 2016 13:46:42 -0700 (PDT) X-AuditID: c1b4fb3a-0618b980000009bd-05-57c74230f126 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by (Symantec Mail Security) with SMTP id 66.D9.02493.03247C75; Wed, 31 Aug 2016 22:46:40 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0301.000; Wed, 31 Aug 2016 22:46:38 +0200 From: Christer Holmberg To: "Dale R. Worley" Thread-Topic: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 Thread-Index: AQHSA8TD+pjwWhmVIEetajd/MHhvMaBjh4YA Date: Wed, 31 Aug 2016 20:46:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC7BD90@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BC7B00A@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) <871t14ae16.fsf@hobgoblin.ariadne.com> In-Reply-To: <871t14ae16.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM2K7qK6B0/Fwg8nHjS2+/tjEZvHyRJkD k8fk/V+ZPZYs+ckUwBTFZZOSmpNZllqkb5fAlbH63AW2gk+8Fesuz2RuYOzg7mLk5JAQMJH4 1PqMpYuRi0NIYD2jxNxNq5khnCWMEjNvvGbsYuTgYBOwkOj+pw1iighoSnQsyAHpZQYyH+3c ywQSFhbwlHixsgAkLCLgJXH7xUN2CNtIomvrSzYQm0VAVaJx3SJWEJtXwFfi49c5jBCbpjNK tHZ0giU4BYwlnk67AdbAKCAm8f3UGiaIXeISt57MZ4K4WUBiyZ7zzBC2qMTLx/9YIWwliUW3 P0PV60gs2P2JDcLWlli28DUzxGJBiZMzn7BMYBSdhWTsLCQts5C0zELSsoCRZRWjaHFqcXFu upGRXmpRZnJxcX6eXl5qySZGYIwc3PLbagfjweeOhxgFOBiVeHgVpI+HC7EmlhVX5h5ilOBg VhLhdXEACvGmJFZWpRblxxeV5qQWH2KU5mBREuf1f6kYLiSQnliSmp2aWpBaBJNl4uCUamBU tg/e7pNs02szNfm7w6F7Aiav+7crlLz/f+5FfviFtsnB5vzGFhE3Qmb1GbteC/Vu9b/qGPaa nam+xtLdje3z256m7NrL6/Q0XmwNzX+mdnSdlNzEA9MsszdF6Zt17NxUk8vWv+zfW8OdTL4/ shZb9AQI5XyYuvGG0DP1sGrvHNmqlSoic5VYijMSDbWYi4oTAaMckM6NAgAA Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 20:46:45 -0000 Hi, >>>But IMHO this is slicing hairs finer than even I am willing to go. I=20 >>>think we've got a solution that is within the rules of RFC 6086, even=20 >>>if they are read strictly. It solves all the practical problems. >> >> What practical problems?=20 > > As far as I can see, we need a way of carrying the Additional Data, and i= t would be useful to carry it in much the same way as it is carried in the = INVITE. Are there others? People want to use the Call-Info header field in INFO because it is used in= INVITE (and possibly other methods), but technically you don't need it in = order to get things to work if you are using an info package. >>>>other than the question of how intermediaries recognize which INFOs=20 >>>>need to have Additional Data attached. >>> >>> Not sure I understand your issue regarding intermediaries. > > If I understand the processing correctly, the caller sends an INFO reques= t containing the control data block, but=20 > various intermediaries between the caller and the callee add the Addition= al Data blocks. In order to get the=20 > mechanism to work correctly, the intermediaries need to recognize the INF= O requests to which they should=20 > add Additional Data resends. There needs to be a clear specification whi= ch INFO requests get this processing=20 > and which don't, and that specification has to allow for unanticipated fu= ture uses. In general, if intermediaries are going to add content to INFO, and if such= information can only be added to specific INFO usages, the intermediaries = will have to look at the Info-Package header field (and in some cases perha= ps also look at the content) in order to figure out what the INFO is all ab= out. Regards, Christer From nobody Wed Aug 31 13:50:04 2016 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 D6DAD12B063; Wed, 31 Aug 2016 13:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.069 X-Spam-Level: X-Spam-Status: No, score=-15.069 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7rvCX2ZeBZU; Wed, 31 Aug 2016 13:49:55 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 414CC12D773; Wed, 31 Aug 2016 13:49:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9062; q=dns/txt; s=iport; t=1472676595; x=1473886195; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+DMSAU9NVZNzVzxaPXJz3ObUEyca0zVHAS2ZEvkEgE4=; b=QO9z5gWbRrRmiwg9wkyxYJfQejuLQRL0NfTOndw49S0XjfhYQph0pHip xXWiAFBs9xJ2BYj1JGYT1oMf4qR+pl6W6gTSw+Lxitt4Iet7X/b14yTRT NIUlyyeDPhoTg1ktwbeyUNwRrI5YwRuGfPyR1v/qguSRK2kTB+mEgbjlm o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AtAgDxQcdX/5FdJa1dg1ABAQEBAR5Xf?= =?us-ascii?q?AeDQLJSgg+CAR+FfQIcgS04FAECAQEBAQEBAV4nhGEBAQQBIxE+BwULAgEIGAI?= =?us-ascii?q?CIwMCAgIwFAEQAgQOBYg+CA6vMI8RAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIEFh?= =?us-ascii?q?SqBeAiCTYQqgxgrgi8FhhKIEossAYYfgwGCeoMVgW2EXYkNjEiDeAEeNoJ6gTV?= =?us-ascii?q?wAQEBhWp/AQEB?= X-IronPort-AV: E=Sophos;i="5.30,263,1470700800"; d="scan'208";a="317836219" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Aug 2016 20:49:54 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u7VKnsht010341 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 31 Aug 2016 20:49:54 GMT Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 31 Aug 2016 15:49:53 -0500 Received: from xch-aln-009.cisco.com ([173.36.7.19]) by XCH-ALN-009.cisco.com ([173.36.7.19]) with mapi id 15.00.1210.000; Wed, 31 Aug 2016 15:49:53 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: Suresh Krishnan Thread-Topic: Suresh Krishnan's Discuss on draft-ietf-sipcore-dns-dual-stack-07: (with DISCUSS) Thread-Index: AQHR/oPDG5fffFhK70W0JbKQU/W66A== Date: Wed, 31 Aug 2016 20:49:53 +0000 Message-ID: <420D8F57-8B5C-4F05-9463-9ED72F02F53F@cisco.com> References: <87k2fc7b8f.fsf@hobgoblin.ariadne.com> <39AEA207-8847-4178-8079-F31D1B50653F@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.212.176] Content-Type: text/plain; charset="utf-8" Content-ID: <17D169F44259A941AFECB040AF17B53A@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: SIPCORE , "draft-ietf-sipcore-dns-dual-stack@ietf.org" , The IESG , "sipcore-chairs@ietf.org" Subject: Re: [sipcore] Suresh Krishnan's Discuss on draft-ietf-sipcore-dns-dual-stack-07: (with DISCUSS) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 20:49:57 -0000 SGkgU3VyZXNoIC0gDQoNCldl4oCZdmUgcG9zdGVkIHRoZSBuZXcgdmVyc2lvbi4NCg0KVGhhbmtz LA0KDQpHb256YWxvDQoNCg0KDQo+IE9uIEF1ZyAzMCwgMjAxNiwgYXQgMTA6NDggQU0sIFN1cmVz aCBLcmlzaG5hbiA8c3VyZXNoLmtyaXNobmFuQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+IA0KPiBI aSBHb256YWxvLA0KPiAgIExvb2tzIGdvb2QgdG8gbWUuIEkgd2lsbCBjbGVhciBvbmNlIHRoZSBu ZXcgcmV2IGhpdHMuDQo+IA0KPiBUaGFua3MNCj4gU3VyZXNoDQo+IA0KPiBHb256YWxvIFNhbGd1 ZWlybyAoZ3NhbGd1ZWkpIHdyb3RlOg0KPj4gSGkgU3VyZXNoIC0NCj4+IA0KPj4gDQo+PiBKdXN0 IGZvbGxvd2luZyB1cCBvbiB0aGlzLiAgVGhlIHVwZGF0ZWQgZHJhZnQgKC0wOCkgYXR0ZW1wdHMg dG8gYWRkcmVzcyB5b3VyDQo+PiBESVNDVVNTLiAgWW91IGNhbiBzZWUgdGhlIGRpZmZzIGhlcmU6 DQo+PiANCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMT1kcmFmdC1pZXRmLXNp cGNvcmUtZG5zLWR1YWwtc3RhY2stMDcmdXJsMj1odHRwOi8vc3ZuLnJlc2lwcm9jYXRlLm9yZy9y ZXAvaWV0Zi1kcmFmdHMvd29ybGV5L2RyYWZ0LWlldGYtc2lwY29yZS1kbnMtZHVhbC1zdGFjay0w OC50eHQNCj4+IA0KPj4gYW5kIHRoZSBlbnRpcmUgY3VycmVudCBkcmFmdCBjYW4gYmUgZm91bmQg aGVyZToNCj4+IA0KPj4gaHR0cDovL3N2bi5yZXNpcHJvY2F0ZS5vcmcvcmVwL2lldGYtZHJhZnRz L3dvcmxleS9kcmFmdC1pZXRmLXNpcGNvcmUtZG5zLWR1PQ0KPj4gYWwtc3RhY2stMDgudHh0DQo+ PiA8aHR0cDovL3N2bi5yZXNpcHJvY2F0ZS5vcmcvcmVwL2lldGYtZHJhZnRzL3dvcmxleS9kcmFm dC1pZXRmLXNpcGNvcmUtZG5zLWR1YWwtc3RhY2stMDgudHh0Pg0KPj4gDQo+PiBPbmNlIHlvdSBj b25maXJtIHlvdXIgcG9pbnRzIGFyZSBhZGRyZXNzZWQgd2Ugd2lsbCBwdWJsaXNoIHRoZSAtMDgg dmVyc2lvbi4NCj4+IA0KPj4gVGhhbmtzLA0KPj4gDQo+PiBHb256YWxvDQo+PiANCj4+IA0KPj4+ IE9uIEF1ZyAxOSwgMjAxNiwgYXQgNDozMCBQTSwgRGFsZSBSLiBXb3JsZXkgPHdvcmxleUBhcmlh ZG5lLmNvbQ0KPj4+IDxtYWlsdG86d29ybGV5QGFyaWFkbmUuY29tPj4gd3JvdGU6DQo+Pj4gDQo+ Pj4gIlN1cmVzaCBLcmlzaG5hbiIgPHN1cmVzaC5rcmlzaG5hbkBlcmljc3Nvbi5jb20NCj4+PiA8 bWFpbHRvOnN1cmVzaC5rcmlzaG5hbkBlcmljc3Nvbi5jb20+PiB3cml0ZXM6DQo+Pj4+ICogU2Vj dGlvbiAzLjENCj4+Pj4gDQo+Pj4+IEl0IGlzIG5vdCBjbGVhciB0byBtZSB3aGF0IGV4YWN0bHkg dGhlIG5vcm1hdGl2ZSBhZGRlbmR1bSBpcyByZXF1aXJpbmcNCj4+Pj4gdGhlIGNsaWVudCB0byBk byBhcyByZWdhcmRzIHRvIHRoZSBETlMgcXVlcnkgd2hpbGUgaW1wbGVtZW50aW5nICJUaGUNCj4+ Pj4gZHVhbC1zdGFjayBjbGllbnQgU0hPVUxEIGxvb2sgdXAgYWxsIGFkZHJlc3MgcmVjb3JkcyIu IERvZXMgdGhpcyBtZWFuDQo+Pj4+IHRoYXQgdGhlIGNsaWVudCBzaG91bGQgZG8gYSBBQUFBICgy OCkgcXVlcnkgZm9sbG93ZWQgYnkgKG9yIGluIHBhcmFsbGVsDQo+Pj4+IG9yIHByZWNlZGVkICkg Zm9yIGEgQSAoMSkgcXVlcnk/IEkgdGhpbmsgaXQgd291bGQgYmUgZ29vZCB0byBjbGFyaWZ5IHRo ZQ0KPj4+PiB0eXBlcyBhbmQgb3JkZXJpbmcvY29uY3VycmVuY3kgb2YgdGhlIHF1ZXJpZXMuDQo+ Pj4gDQo+Pj4gR2l2ZW4gdGhhdCB0aGUgcmVzcG9uc2VzIHRvIEROUyBxdWVyaWVzIGRvIG5vdCBk ZXBlbmQgb24gdGhlIG9yZGVyIGluDQo+Pj4gd2hpY2ggdGhleSBhcmUgZG9uZSwgaXQgc2VlbXMg dG8gbWUgdGhhdCB0aGUgb25seSBuZWNlc3NpdHkgaXMgdG8NCj4+PiBzcGVjaWZ5IHRoYXQgdGhl IGNsaWVudCBtdXN0IGRvIGJvdGggQSBhbmQgQUFBQSBxdWVyaWVzLg0KPj4+IA0KPj4+IEluIHJl Z2FyZCB0byB0aGUgc3BlY2lmaWMgcmVjb3JkIHR5cGVzLCBvbmUgb2Ygb3VyIGdvYWxzIHdhcyB0 aGF0IHRoZQ0KPj4+IHdvcmRpbmcgc2hvdWxkIGJlIHJvYnVzdCB0byB0aGUgcG9zc2liaWxpdHkg b2YgYWRkaXRpb25hbCBhZGRyZXNzDQo+Pj4gZmFtaWxpZXMgYmVpbmcgY3JlYXRlZC4gIFRodXMg d2UgdXNlZCB0aGUgd29yZGluZw0KPj4+IA0KPj4+ICAgICBUaGUgZHVhbC1zdGFjayBjbGllbnQg U0hPVUxEIGxvb2sgdXAgYWxsIGFkZHJlc3MgcmVjb3JkcyBbLi4uXSBmb3INCj4+PiAgICAgYWxs IGFkZHJlc3MgZmFtaWx5KGllcykgdGhhdCBpdCBzdXBwb3J0cyBbLi4uXSBmb3IgdGhlIGRvbWFp biBuYW1lDQo+Pj4gICAgIGFuZCBhZGQgdGhlIHJlc3VsdGluZyBhZGRyZXNzZXMgdG8gdGhlIGxp c3Qgb2YgSVAgYWRkcmVzc2VzIHRvIGJlDQo+Pj4gICAgIGNvbnRhY3RlZC4NCj4+PiANCj4+PiBB c3N1bWluZyB0aGF0IHRoZSBjbGllbnQgc3VwcG9ydHMgZXhhY3RseSBJUHY0IGFuZCBJUHY2LCB0 aGUgcXVlcmllcyB0bw0KPj4+IG9idGFpbiBhZGRyZXNzIHJlY29yZHMgZm9yIHRob3NlIGZhbWls aWVzIGFyZSBBIGFuZCBBQUFBLiAgSSBkb24ndCBzZWUNCj4+PiB0aGF0IHRoZSB0ZXh0IGNhbiBi ZSBpbnRlcnByZXRlZCBpbiBhIGRpZmZlcmVudCB3YXkuDQo+Pj4gDQo+Pj4+ICogU2VjdGlvbiA0 DQo+Pj4+IA0KPj4+PiBJIGFtIGEgYml0IHB1enpsZWQgYnkgdGhlIG1lcmdpbmcgb2YgdGhlIGFk ZHJlc3MgbGlzdHMgZnJvbSB0d28gc2VwYXJhdGUNCj4+Pj4gRE5TIHF1ZXJpZXMgaW4gcmVsYXRp b24gdG8gUkZDNjcyNC4gVGhpcyBpcyBob3cgSSBzZWUgdGhlIGRlc3RpbmF0aW9uDQo+Pj4+IGFk ZHJlc3Mgc2VsZWN0aW9uIGluIFJGQzY3MjQuIFRoZSBhcHBsaWNhdGlvbiBlbmRzIHVwIGNhbGxp bmcgc29tZSBraW5kDQo+Pj4+IG9mIG5hbWUgcmVzb2x1dGlvbiBBUEkgKHNvbWV0aGluZyBsaWtl IGdldGFkZHJpbmZvKCkpIHdpdGggYQ0KPj4+PiBob3N0bmFtZS9GUUROIChzYXkgc2lwLTEuZXhh bXBsZS5jb20gPGh0dHA6Ly9zaXAtMS5leGFtcGxlLmNvbT4pIGFuZCB0aGlzDQo+Pj4+IHJlc3Vs dHMgaW4gYSBzZXQgb2YNCj4+Pj4gYWRkcmVzc2VzIGJlaW5nIHJldHVybmVkLiBUaGUgZGVzdGlu YXRpb24gYWRkcmVzcyBzZWxlY3Rpb24gYWxnb3JpdGhtDQo+Pj4+IHNwZWNpZmllZCBpbiBTZWN0 aW9uIDYgb2YgUkZDNjcyNCB0aGVuIG9yZGVycyB0aGVzZSBhZGRyZXNzZXMgYW5kIHBpY2tzDQo+ Pj4+IG9uZS4gSSBhbSBub3Qgc2VlaW5nIGhvdyB0aGUgc2Vjb25kIEZRRE4gYW5kIGl0cyBhc3Nv Y2lhdGVkIHNldCBvZg0KPj4+PiBhZGRyZXNzZXMgYmVjb21lIGludm9sdmVkIGluIHRoZSBSRkM2 NzI0IHByb2Nlc3MuIElzIHRoaXMgc29tZXRoaW5nIHRoYXQNCj4+Pj4geW91IGFyZSBhZGRpbmcg b24gdG9wIG9mIFJGQzY3MjQ/IFBsZWFzZSBjbGFyaWZ5Lg0KPj4+IA0KPj4+IE9uZSB3YXkgb2Yg bG9va2luZyBhdCBpdCBpcyB0aGF0IHRoZSBmdWxsIHByb2Nlc3Mgb2YgcmVzb2x2aW5nIHRoZQ0K Pj4+IHNlcnZlcidzIGFkZHJlc3MgaXMgdGhlIHByb2Nlc3MgZm9yIFNSViByZWNvcmRzIChSRkMg Mjc4Mikgb24gdG9wIG9mIHRoZQ0KPj4+IGRlc3RpbmF0aW9uIGFkZHJlc3Mgc2VsZWN0aW9uIHBy b2Nlc3MgKFJGQyA2NzI0KS4gIFlvdSd2ZSBpZGVudGlmaWVkDQo+Pj4gdGhhdCBjb3JyZWN0bHku DQo+Pj4gDQo+Pj4gVGhlIGZ1bGwgcHJvY2VzcyBpcyBmYWlybHkgY29tcGxpY2F0ZWQsIGFuZCB0 aGUgZnVsbCBkb2N1bWVudGF0aW9uDQo+Pj4gaW52b2x2ZXMgdGhlIGludGVyYWN0aW9uIG9mIFJG QyAzMjYzLCBSRkMgMjc4MiwgYW5kIFJGQyA2NzI0LiAgQnV0DQo+Pj4gcmVzdHJpY3Rpbmcgb3Vy IGF0dGVudGlvbiB0byB0aGUgY2FzZSBpbiBxdWVzdGlvbjoNCj4+PiANCj4+PiAtIFRoZSBTUlYg cmVjb3JkcyBmb3IgZG9tYWluIG5hbWUgaW4gdGhlIGRlc3RpbmF0aW9uIFNJUCBVUkwgYXJlIGxv b2tlZA0KPj4+IHVwLiAgKFJGQyAzMjYzKQ0KPj4+IA0KPj4+IC0gRGVwZW5kaW5nIG9uIHRoZSBw cmlvcml0eSBhbmQgd2VpZ2h0IGZpZWxkcyAoYW5kIHRoZSByYW5kb21pemF0aW9uDQo+Pj4gaW1w bGllZCBieSB0aGVtISksIHRoZSAidGFyZ2V0IiBkb21haW4gbmFtZXMgb2YgdGhlIFNSViByZWNv cmRzIGFyZQ0KPj4+IGxpc3RlZCBpbiBhIHBhcnRpY3VsYXIgb3JkZXIuICAoUkZDIDI3ODIpDQo+ Pj4gDQo+Pj4gVGhlIGNhc2UgaW4gcXVlc3Rpb24gaXMgd2hlbiB0aGVyZSBhcmUgbW9yZSB0aGFu IG9uZSBTUlYgcmVjb3JkcyBmb3IgdGhlDQo+Pj4gZGVzdGluYXRpb24gZG9tYWluIG5hbWUsIGFu ZCBoZW5jZSBtb3JlIHRoYW4gb25lIHRhcmdldCBkb21haW4gbmFtZS4NCj4+PiANCj4+PiAtIEVh Y2ggb2YgdGhvc2UgdGFyZ2V0IGRvbWFpbiBuYW1lcyBpcyBleHBhbmRlZCBpbnRvIGEgZ3JvdXAg b2YgSVB2NCBhbmQNCj4+PiBJUHY2IGFkZHJlc3NlcyBieSBsb29raW5nIHVwIHRoZSBBIGFuZCBB QUFBIHJlY29yZHMgZm9yIHRoZSBuYW1lLiAgRWFjaA0KPj4+IGdyb3VwIGlzIHNvcnRlZCBieSB0 aGUgZGVzdGluYXRpb24gc2VsZWN0aW9uIGFsZ29yaXRobS4gIChUaGlzIGNhbiBiZQ0KPj4+IGFj Y29tcGxpc2hlZCBieSBjYWxsaW5nIGdldGFkZHJpbmZvKCkgb24gdGhlIHRhcmdldCBkb21haW4g bmFtZS4pDQo+Pj4gKFJGQyA2NzI0KQ0KPj4+IA0KPj4+IC0gVGhlIHNvcnRlZCBncm91cHMgb2Yg YWRkcmVzc2VzIGZvciB0aGUgdGFyZ2V0IGRvbWFpbiBuYW1lcyBhcmUNCj4+PiBjb25jYXRlbmF0 ZWQgaW4gdGhlIG9yZGVyIG9mIHRoZSB0YXJnZXQgZG9tYWluIG5hbWVzLg0KPj4+IA0KPj4+IFRo ZSBjcnVjaWFsIHBvaW50IGhlcmUgaXMgdGhhdCB0aGUgZGVzdGluYXRpb24gc2VsZWN0aW9uIHJl b3JkZXJpbmcgaXMNCj4+PiBvbmx5IHdpdGhpbiB0aGUgZ3JvdXBzIHRoYXQgcmVzdWx0IGZyb20g dGhlIHRhcmdldCBkb21haW4gbmFtZXMgb2YgdGhlDQo+Pj4gU1JWcyAtLSBUaGUgd2hvbGUgYWxn b3JpdGhtIGlzIGEgdHdvLWZpZWxkIHNvcnQgd2l0aCB0aGUgIm1ham9yIiBzb3J0DQo+Pj4gYmVp bmcgZG9uZSBieSB0aGUgU1JWIGFsZ29yaXRobSBhbmQgdGhlICJtaW5vciIgc29ydCBiZWluZyBk b25lIGJ5DQo+Pj4gZGVzdGluYXRpb24gc2VsZWN0aW9uLg0KPj4+IA0KPj4+IFRoZSBvcmlnaW5h bCBSRkMgMzI2MyBzcGVjaWZpY2F0aW9uIGRlc2NyaWJlcyB0aGUgZmlyc3QgdHdvIHN0ZXBzLCBi dXQNCj4+PiBwcmVzdW1lcyB0aGF0IHRoZSB0aGlyZCBzdGVwIGRvZXMgbm90IGV4cGxpY2l0bHkg c29ydCB0aGUgYWRkcmVzc2VzIHRoYXQNCj4+PiBhcmUgb2J0YWluZWQgZm9yIHRoZSB0YXJnZXQg ZG9tYWluIG5hbWUuICBBcyBhIGdlbmVyYWwgcnVsZSwgcGVvcGxlIHdobw0KPj4+IGhhdmUgZGln ZXN0ZWQgdGhlIHJ1bGVzIG9mIFJGQyAzMjYzIGFncmVlIHRoYXQgdGhlICJuYXR1cmFsbHkgY29y cmVjdCINCj4+PiB3YXkgdG8gaW5jb3Jwb3JhdGUgZGVzdGluYXRpb24gc2VsZWN0aW9uIChub3cg dGhhdCBpdCBleGlzdHMgZm9yIElQdjYpDQo+Pj4gaXMgdG8gZXhwYW5kIHRoZSB0aGlyZCBzdGVw IHRvIGluY2x1ZGUgdGhhdCBzb3J0YXRpb24gLS0gYW5kLA0KPj4+IGNyaXRpY2FsbHksIHRoYXQg ZGVzdGluYXRpb24gc2VsZWN0aW9uIGNhbm5vdCByZW9yZGVyIHR3byBhZGRyZXNzZXMNCj4+PiBi ZXR3ZWVuIGdyb3VwcyB0aGF0IGRlcml2ZSBmcm9tIGRpZmZlcmVudCB0YXJnZXQgZG9tYWluIG5h bWVzLg0KPj4+IA0KPj4+IFRoZSBwdXJwb3NlIG9mIHNlY3Rpb24gNCBpcyB0byBtYWtlIHRoYXQg dW5kZXJzdGFuZGluZyBub3JtYXRpdmUuDQo+Pj4gDQo+Pj4gTm93LCBjb21wYXJpbmcgd2hhdCBJ IGhhdmUgd3JpdHRlbiBoZXJlIHdpdGggdGhlIHRleHQgaW4gc2VjdGlvbiA0LCBJDQo+Pj4gc2Vl IHRoYXQgc2VjdGlvbiA0IGRvZXMgbm90IG1ha2UgZXhwbGljaXQgdGhlIG9yZGVyZWQgbGlzdCBv ZiB0YXJnZXQNCj4+PiBkb21haW4gbmFtZXMgZnJvbSB0aGUgU1JWIHJlY29yZHMuICBBbmQgSSBj YW4gc2VlIHRoYXQgaWYgdGhlIHJlYWRlciBpcw0KPj4+IG5vdCB0aG9yb3VnaGx5IGZhbWlsaWFy IHdpdGggUkZDIDMyNjMsIHRoYXQgbWFrZXMgdGhlIG92ZXJhbGwgcHJvY2Vzcw0KPj4+IHNpZ25p ZmljYW50bHkgbGVzcyBjbGVhciwgYmVjYXVzZSBpdCBkb2Vzbid0IG1ha2Ugc3RlcCAyIGFib3Zl IGV4cGxpY2l0Lg0KPj4+IA0KPj4+IEkndmUgdXBkYXRlZCB0aGUgZHJhZnQgLTA4IHRvIHNob3cg dGhlIGxpc3Qgb2YgdGFyZ2V0IGRvbWFpbiBuYW1lcy4NCj4+PiBZb3UgY2FuIHNlZSB0aGUgZGlm ZmVyZW5jZSBpbg0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMT1kcmFmdC1p ZXRmLXNpcGNvcmUtZG5zLWR1YWwtc3RhY2stMDcmdXJsMj1odHRwOi8vc3ZuLnJlc2lwcm9jYXRl Lm9yZy9yZXAvaWV0Zi1kcmFmdHMvd29ybGV5L2RyYWZ0LWlldGYtc2lwY29yZS1kbnMtZHVhbC1z dGFjay0wOC50eHQNCj4+PiBhbmQgdGhlIGVudGlyZSBjdXJyZW50IGRyYWZ0IGluDQo+Pj4gaHR0 cDovL3N2bi5yZXNpcHJvY2F0ZS5vcmcvcmVwL2lldGYtZHJhZnRzL3dvcmxleS9kcmFmdC1pZXRm LXNpcGNvcmUtZG5zLWR1YWwtc3RhY2stMDgue3R4dCxodG1sfQ0KPj4+IA0KPj4+IERhbGUNCj4+ IA0KPiANCg0K From nobody Wed Aug 31 13:53:21 2016 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 CA9A712D1C0 for ; Wed, 31 Aug 2016 13:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85UUtb4G4E8S for ; Wed, 31 Aug 2016 13:53:18 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0EF212D100 for ; Wed, 31 Aug 2016 13:53:17 -0700 (PDT) X-AuditID: c1b4fb2d-cf87d980000019a3-22-57c743bb094d Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by (Symantec Mail Security) with SMTP id 62.CB.06563.BB347C75; Wed, 31 Aug 2016 22:53:16 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0301.000; Wed, 31 Aug 2016 22:53:14 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 Thread-Index: AQHSA6A0+pjwWhmVIEetajd/MHhvMaBjPd5QgAAm3YCAACZcMA== Date: Wed, 31 Aug 2016 20:53:14 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC7BDF6@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BC778E6@ESESSMB209.ericsson.se> <87d1kp9bkv.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B4BC7B00A@ESESSMB209.ericsson.se> <1f97dad7-d573-0276-edd5-2a5ff5d63f74@alum.mit.edu> In-Reply-To: <1f97dad7-d573-0276-edd5-2a5ff5d63f74@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM2K7me4e5+PhBpvvc1us2HCA1eLrj01s Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGipWbGAt+8FS8enubpYFxHlcXIyeHhICJ xL6H91m6GLk4hATWM0qcvPMRylnCKHH28Dm2LkYODjYBC4nuf9ogDSICgRJXl0xgBgkLC3hK vFhZABH2krj94iE7hO0kMfHLfUYQm0VAVeLPwjtgcV4BX4nOlXvAbCGBD4wSL5YFgticAg4S 7Zt/soDYjAJiEt9PrWECsZkFxCVuPZnPBHGngMSSPeeZIWxRiZeP/7FC2EoSi25/hqrXkViw +xMbhK0tsWzha2aIvYISJ2c+YZnAKDILydhZSFpmIWmZhaRlASPLKkbR4tTi4tx0I2O91KLM 5OLi/Dy9vNSSTYzAaDi45bfuDsbVrx0PMQpwMCrx8CpIHw8XYk0sK67MPcQowcGsJMJ7ywko xJuSWFmVWpQfX1Sak1p8iFGag0VJnNf/pWK4kEB6YklqdmpqQWoRTJaJg1OqgVHhAGOh2WqZ o0+PCEiL6S/NvchTsPBqhKH5nDzjQ7cWKoswu03MvOua7Bwif0mx4kZB4mMz7Wa95p/Pvwo3 2nqlO2UG52su/np1pnDI/W1B3Vu28Uac3WFx8f3Cv6uOTVBk+hF29/guq6ubGn0dn3rHcOz/ 2jvvuFf8ivnrOR9+1pdraU/bcUaJpTgj0VCLuag4EQAcR3SzggIAAA== Archived-At: Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 20:53:20 -0000 Hi, ... > So, the UA can have logic that says: I'm sending a request, is there some= call-info data that I should attach > to it? And if the answer is yes, then it can do so in a consistent way. > > It would be much more of a mess if it then had to consider what the metho= d was, and special case how it attaches the information. IF method =3D=3D INFO Attach this way ELSE Attach that way It's not that difficult :) There are much more complicated things that you have to do based on the met= hod. For example, you need to check whether the method falls under certain = race condition rules, you have to check whether a method somehow affects so= me SIP level properties etc. Adding the content to the message is the easy = part :) Regards, Christer >> But IMHO this is slicing hairs finer than even I am willing to go. I th= ink we've got a solution that is within the rules of RFC 6086, even if they= are read strictly. It solves all the >practical problems. > > What practical problems? > >> And it doesn't require much additional implementation work (beyond=20 >> what is needed for INVITEs) -- other than the question of how intermedia= ries recognize which INFOs need to have Additional Data attached. > > Not sure I understand your issue regarding intermediaries. > > Regards, > > Christer > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Aug 31 15:50:13 2016 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 DFEE612D7B7 for ; Wed, 31 Aug 2016 15:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.768 X-Spam-Level: X-Spam-Status: No, score=-4.768 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJk_1UFGVebj for ; Wed, 31 Aug 2016 15:50:09 -0700 (PDT) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49E8912D76E for ; Wed, 31 Aug 2016 15:50:08 -0700 (PDT) Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by tcmail91.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 01 Sep 2016 00:50:05 +0200 X-IronPort-AV: E=Sophos;i="5.30,264,1470693600"; d="scan'208";a="1133897165" Received: from he105662.emea1.cds.t-internal.com ([10.169.119.58]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/AES256-SHA; 01 Sep 2016 00:50:05 +0200 Received: from HE105660.EMEA1.cds.t-internal.com (10.169.119.56) by HE105662.emea1.cds.t-internal.com (10.169.119.58) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 1 Sep 2016 00:50:05 +0200 Received: from HE105660.EMEA1.cds.t-internal.com ([fe80::c5cd:6c67:9f4d:7318]) by HE105660.emea1.cds.t-internal.com ([fe80::c5cd:6c67:9f4d:7318%26]) with mapi id 15.00.1178.000; Thu, 1 Sep 2016 00:50:05 +0200 From: To: , , Thread-Topic: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 Thread-Index: AQHSA6A0d/XIbuDzEUiW8mmXtS+eVaBjHpWAgABGJoCAAAXfAIAAOYfQ Date: Wed, 31 Aug 2016 22:50:05 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B4BC778E6@ESESSMB209.ericsson.se> <87d1kp9bkv.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B4BC7B00A@ESESSMB209.ericsson.se> <1f97dad7-d573-0276-edd5-2a5ff5d63f74@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC7BDF6@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC7BDF6@ESESSMB209.ericsson.se> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.213.93.147] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 22:50:12 -0000 Hi,=20 Here are my 5 Cent. You are still discussing the stuff. And you are not far from each other. All want to have a workable solution. >From one side I can follow Christer's approach to have the clear use of SIP= mechanisms that should be followed. But to be provocative, seen it from operator point of view I do not care wh= at mechanism my application will use. If it is the "wrong" Call-Info Header= approach (If it is really wrong you are still fighting) or the correct INF= O-Package mechanism. So if both is correctly used within the INFO and satisfy any rule written w= ithin the RFC's why not. It will not harm the core implementation of SIP. For me it looks more complex for an application to look on two mechanisms t= o identify the content of the MIME and the INFO Package. Also looking on th= e processing it will be more complex and resource consuming.=20 >From pure operational perspective (where are network operators are interest= ed in) at least the Call-Info header can be used as trigger within the trac= ing tool to track the eCall relevant messages containing MSD information. A= lone from that perspective I would like to keep it within the INFO. So looking into the draft I personally do not see anything what is contradi= cting to that what was said until now.=20 But if people see phrases which needs progress why not point to them and pr= opose improved text? But the we should shift the discussion back to ecrit.=20 Thank you and Best Regards Roland Mit freundlichen Gr=FC=DFen =A0 Roland Jesske Deutsche Telekom=A0Technik GmbH Fixed Mobile Engineering Deutschland Roland Jesske Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt +49 6151 58-12766 (Tel.) +49 6151 58-13395 (Fax) +49 171 8618-445 (Mobil) http://www.telekom.com Erleben, was verbindet. Pflichtangaben gem=E4=DF =A7 35 a GmbHG www.telekom.de/pflichtangaben-dttechnik Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und nicht jede= E-Mail drucken.=20