From pkyzivat@alum.mit.edu Sat Sep 1 08:56:29 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C6F11E80BA for ; Sat, 1 Sep 2012 08:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.136 X-Spam-Level: X-Spam-Status: No, score=-1.136 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vggC1WS+29Am for ; Sat, 1 Sep 2012 08:56:28 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id E742311E810F for ; Sat, 1 Sep 2012 08:56:27 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta03.westchester.pa.mail.comcast.net with comcast id totq1j0041ap0As53rwXJJ; Sat, 01 Sep 2012 15:56:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id trwu1j0093ZTu2S3irwu0D; Sat, 01 Sep 2012 15:56:54 +0000 Message-ID: <5042302A.70505@alum.mit.edu> Date: Sat, 01 Sep 2012 11:56:26 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <502B77D4.5030402@kpfleming.us> <502BC9A3.2030902@alum.mit.edu> <502F1ADD.5060207@alum.mit.edu>, <502F7920.5090507@kpfleming.us> <7F2072F1E0DE894DA4B517B93C6A058534097503E1@ESESSCMS0356.eemea.ericsson.se> <3330DEF2-8487-4FB5-BE0F-6485B1514FAB@cisco.com> In-Reply-To: <3330DEF2-8487-4FB5-BE0F-6485B1514FAB@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] draft-hanes-dispatch-fax-capability-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2012 15:56:29 -0000 David, This version is better! A couple of issues: The shown usage of Accept-Contact: Accept-Contact: +sip.fax="t38" is syntactically incorrect. Minimally it needs to be: Accept-Contact: *;+sip.fax="t38" (That expresses a *preference* for t38, while not excluding callees that don't support fax or that support only some other fax encoding.) The section on values appropriate for use with this feature tag is wishy washy. If "t38" and "passthrough" are simply *typical*, then are other values also permitted? If so, which ones? In the case of passthrough, what does "transmission of fax using an audio codec" *mean*? There must be some encoding. IMO you should spell out the choices as an enumeraton, and each value of the enumeration should normatively reference some standard. Thanks, Paul On 8/31/12 10:15 PM, David Hanes wrote: > Thanks for the constructive feedback on this draft. I posted a new version of the draft for your review. > > The principal changes in this new version are: > > - Per Dan Wing, insertion of a paragraph expanding upon why SDP alone is not suitable for indicating fax capability. > > - Per Christer Holmberg, the +sip.fax tag has been changed from a boolean type to token with an equality relationship so that we can now explicitly define the fax transport being used > > - addressing various nits and formatting issues > > Additional feedback and suggestions on taking this draft forward are welcomed and appreciated. > > Regards, > David From prvs=2594797a31=jbakker@rim.com Tue Sep 4 08:30:03 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4779221F864A for ; Tue, 4 Sep 2012 08:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZH5QgXA2LV0 for ; Tue, 4 Sep 2012 08:30:02 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 6621A21F8671 for ; Tue, 4 Sep 2012 08:30:02 -0700 (PDT) X-AuditID: 0a41282f-b7fbe6d000004851-9e-50461e79b7af Received: from XCT101ADS.rim.net (xct101ads.rim.net [10.67.111.42]) by mhs060cnc.rim.net (SBG) with SMTP id 35.10.18513.97E16405; Tue, 4 Sep 2012 10:30:01 -0500 (CDT) Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT101ADS.rim.net ([fe80::2c7e:1215:d554:35b5%20]) with mapi id 14.02.0298.004; Tue, 4 Sep 2012 10:30:00 -0500 From: John-Luc Bakker To: "dispatch@ietf.org" Thread-Topic: New Version Notification for draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt Thread-Index: AQHNirGS0ZC3wWK0lESLahjsx3+IApd6ThSA Date: Tue, 4 Sep 2012 15:30:00 +0000 Message-ID: <155970D1DA8E174F9E46039E10E2AA351EA834@XMB104ADS.rim.net> References: <20120904152546.18420.91591.idtracker@ietfa.amsl.com> In-Reply-To: <20120904152546.18420.91591.idtracker@ietfa.amsl.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.251] Content-Type: text/plain; charset="utf-8" content-transfer-encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFKsWRmVeSWpSXmKPExsXC5ZyvpVsp5xZgsOiskMXSSQtYHRg9liz5 yRTAGNXAaJOUWFIWnJmep29nk5iXl1+SWJKqkJJanGyr5JOanpijEFCUWZaYXKngklmcnJOY mZtapKSQmWKrZKKkUJCTmJyam5pXYquUWFCQmpeiZMelgAFsgMoy8xRS85LzUzLz0m2VPIP9 dS0sTC11DZXsdBM6eTKO9OxiL1gmVnHrxzL2BsY7ol2MnBwSAiYSK98sY4WwxSQu3FvP1sXI xSEksJJR4sDlw2AJIYFNjBKdE9hBbDYBdYmtK7Yzg9giAtoSR1d1gdnCAskSu/afBKrhAIqn SPQdr4AwjSRmXwsDqWARUJFY9rENbCKvgJvEiWOLmCCmO0psuzyHBcTmFHCSaJ24DSzOKCAr sfvsdTCbWUBc4taT+UwQZwpILNlznhnCFpV4+fgf1PmKEjP2zGcFWcssoCmxfpc+RKuixJTu h+wQawUlTs58wjKBUXQWkqmzEDpmIemYhaRjASPLKkbB3IxiAzOD5LxkvaLMXL281JJNjKCY d9TQ38H49r3FIUYBDkYlHt5pf10DhFgTy4orcw8xSnAwK4nw3l4NFOJNSaysSi3Kjy8qzUkt PsRoAQyTicxS3Mn5wHSUVxJvbGCAwlES511x3CFASCAdmFqyU1MLUotgWpk4OEFGc0mJFAMT RGpRYmlJRjwojcUXAxOZVAPjwoQFWyawiP4MuNqdH3fsg6XkKuvnNu+F7kR+VfmkGXTCUNwi jOPc/oezfiRUn5WqMmCLeNvOrH/x/IKT7Hd2VC4Peb+jbv3fJx7zk49Nn3hize2LPZemCd/w 3Jb9530Di59SVkJu7OPTx138zx+ed3nlzIbgT9P9c36cuyY4perANkWxF9ock5RYijMSDbWY i4oTATfT980tAwAA Subject: Re: [dispatch] New Version Notification for draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 15:30:03 -0000 RGVhciBhbGwsDQoNCkkgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgdmVyc2lvbiBvZiB0aGUgcHJl dmlvdXMgImRyYWZ0LWJha2tlci1zaXBwaW5nLTNncHAtaW1zLXhtbC1ib2R5LWhhbmRsaW5n IiwgdGFraW5nIGludG8gYWNjb3VudCB0aGUgdmFyaW91cyBjb21tZW50cyByZWNlaXZlZC4g VGhlIG1vc3Qgbm90YWJsZSBjaGFuZ2UgaXMgdG8gc3VibWl0IHRoZSBkcmFmdCB0byBESVNQ QVRDSCAoaW5zdGVhZCBvZiBTSVBQSU5HKSBhbmQgdG8gc3VibWl0IHRoZSBkcmFmdCBmb3Ig c3RhbmRhcmRzIHRyYWNrIGNvbnNpZGVyYXRpb24uDQoNCkkgd2VsY29tZSB5b3VyIGNvbW1l bnRzLg0KDQpLaW5kIHJlZ2FyZHMsDQoNCglKb2huLUx1Yw0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAwNCwg MjAxMiAxMDoyNiBBTQ0KVG86IEpvaG4tTHVjIEJha2tlcg0KU3ViamVjdDogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1iYWtrZXItZGlzcGF0Y2gtM2dwcC1pbXMteG1s LWJvZHktaGFuZGxpbmctMDAudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0 LWJha2tlci1kaXNwYXRjaC0zZ3BwLWltcy14bWwtYm9keS1oYW5kbGluZy0wMC50eHQNCmhh cyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSm9obi1MdWMgQmFra2VyIGFuZCBw b3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1iYWtr ZXItZGlzcGF0Y2gtM2dwcC1pbXMteG1sLWJvZHktaGFuZGxpbmcNClJldmlzaW9uOgkgMDAN ClRpdGxlOgkJIFNwZWNpZmljYXRpb24gb2YgM0dQUCBJTSBDTiBTdWJzeXN0ZW0gWE1MIGJv ZHkgaGFuZGxpbmcNCkNyZWF0aW9uIGRhdGU6CSAyMDEyLTA5LTA0DQpXRyBJRDoJCSBJbmRp dmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogOA0KVVJMOiAgICAgICAgICAg ICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1iYWtrZXItZGlz cGF0Y2gtM2dwcC1pbXMteG1sLWJvZHktaGFuZGxpbmctMDAudHh0DQpTdGF0dXM6ICAgICAg ICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYmFra2VyLWRpc3Bh dGNoLTNncHAtaW1zLXhtbC1ib2R5LWhhbmRsaW5nDQpIdG1saXplZDogICAgICAgIGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJha2tlci1kaXNwYXRjaC0zZ3BwLWltcy14 bWwtYm9keS1oYW5kbGluZy0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBy ZWdpc3RlcnMgbmV3IGRpc3Bvc2l0aW9uLXR5cGVzIGZvciB0aGUgQ29udGVudC0NCiAgIERp c3Bvc2l0aW9uIGhlYWRlciBmaWVsZCB0aGF0IGFwcGx5IHRvIHRoZSBhcHBsaWNhdGlvbi8z Z3BwLWltcyt4bWwNCiAgIGJvZHkgKHBhcnQpIHVzZWQgYnkgM0dQUCBbNV0uICBUaGUgYXBw bGljYWJpbGl0eSBvZiB0aGVzZSBjb250ZW50LQ0KICAgZGlzcG9zaXRpb24gdmFsdWVzIGFy ZSBsaW1pdGVkIHRvIDNHUFAgSU1TIFs1XS4gIFRoZSBhcHBsaWNhdGlvbi8NCiAgIDNncHAt aW1zK3htbCBib2R5IChwYXJ0KSBoYXMgdGhlIGZvbGxvd2luZyB0aHJlZSBkaXN0aW5jdCB1 c2VzOiAoMSkNCiAgIGZvciByZWRpcmVjdGluZyB0aGUgZW1lcmdlbmN5IHNlc3Npb24gdG8g dXNlIGEgZGlmZmVyZW50IGRvbWFpbiAoZS5nLg0KICAgdXNpbmcgYSBDaXJjdWl0IFN3aXRj aGVkIGNhbGwpLCAoMikgZm9yIGRlbGl2ZXJpbmcgdXNlciBwcm9maWxlDQogICBzcGVjaWZp YyBpbmZvcm1hdGlvbiBmcm9tIHRoZSBTSVAgcmVnaXN0cmFyIHRvIGFuIEFwcGxpY2F0aW9u IFNlcnZlciwNCiAgIGFuZCAoMykgZm9yIGNhdXNpbmcgYSBVQUMgdG8gYXR0ZW1wdCB0byBy ZS1yZWdpc3RlciB3aXRoIHRoZSBJTVMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhp cyB0cmFuc21pc3Npb24gKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIG1heSBjb250YWlu IGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiwgcHJpdmlsZWdlZCBtYXRlcmlhbCAoaW5jbHVk aW5nIG1hdGVyaWFsIHByb3RlY3RlZCBieSB0aGUgc29saWNpdG9yLWNsaWVudCBvciBvdGhl ciBhcHBsaWNhYmxlIHByaXZpbGVnZXMpLCBvciBjb25zdGl0dXRlIG5vbi1wdWJsaWMgaW5m b3JtYXRpb24uIEFueSB1c2Ugb2YgdGhpcyBpbmZvcm1hdGlvbiBieSBhbnlvbmUgb3RoZXIg dGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGlzIHByb2hpYml0ZWQuIElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRl bHkgcmVwbHkgdG8gdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgaW5mb3JtYXRpb24gZnJv bSB5b3VyIHN5c3RlbS4gVXNlLCBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIG9yIHJl cHJvZHVjdGlvbiBvZiB0aGlzIHRyYW5zbWlzc2lvbiBieSB1bmludGVuZGVkIHJlY2lwaWVu dHMgaXMgbm90IGF1dGhvcml6ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4NCg== From pkyzivat@alum.mit.edu Tue Sep 4 10:20:30 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBBE911E809A for ; Tue, 4 Sep 2012 10:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KRfXQafBDe0 for ; Tue, 4 Sep 2012 10:20:28 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id D870D11E80A3 for ; Tue, 4 Sep 2012 10:20:27 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta03.westchester.pa.mail.comcast.net with comcast id uyr81j0040ldTLk535LXoU; Tue, 04 Sep 2012 17:20:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id v5LL1j00l3ZTu2S3Q5LL2Y; Tue, 04 Sep 2012 17:20:20 +0000 Message-ID: <5046385A.4080803@alum.mit.edu> Date: Tue, 04 Sep 2012 13:20:26 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <20120904152546.18420.91591.idtracker@ietfa.amsl.com> <155970D1DA8E174F9E46039E10E2AA351EA834@XMB104ADS.rim.net> In-Reply-To: <155970D1DA8E174F9E46039E10E2AA351EA834@XMB104ADS.rim.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] New Version Notification for draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 17:20:31 -0000 To make it easier for other readers, here is a link that does the diff of this version to the prior one: http://tools.ietf.org/rfcdiff?url1=draft-bakker-sipping-3gpp-ims-xml-body-handling-08.txt;url2=draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt Regards, Paul On 9/4/12 11:30 AM, John-Luc Bakker wrote: > Dear all, > > I have submitted a new version of the previous "draft-bakker-sipping-3gpp-ims-xml-body-handling", taking into account the various comments received. The most notable change is to submit the draft to DISPATCH (instead of SIPPING) and to submit the draft for standards track consideration. > > I welcome your comments. > > Kind regards, > > John-Luc > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Tuesday, September 04, 2012 10:26 AM > To: John-Luc Bakker > Subject: New Version Notification for draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt > > > A new version of I-D, draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt > has been successfully submitted by John-Luc Bakker and posted to the IETF repository. > > Filename: draft-bakker-dispatch-3gpp-ims-xml-body-handling > Revision: 00 > Title: Specification of 3GPP IM CN Subsystem XML body handling > Creation date: 2012-09-04 > WG ID: Individual Submission > Number of pages: 8 > URL: http://www.ietf.org/internet-drafts/draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt > Status: http://datatracker.ietf.org/doc/draft-bakker-dispatch-3gpp-ims-xml-body-handling > Htmlized: http://tools.ietf.org/html/draft-bakker-dispatch-3gpp-ims-xml-body-handling-00 > > > Abstract: > This document registers new disposition-types for the Content- > Disposition header field that apply to the application/3gpp-ims+xml > body (part) used by 3GPP [5]. The applicability of these content- > disposition values are limited to 3GPP IMS [5]. The application/ > 3gpp-ims+xml body (part) has the following three distinct uses: (1) > for redirecting the emergency session to use a different domain (e.g. > using a Circuit Switched call), (2) for delivering user profile > specific information from the SIP registrar to an Application Server, > and (3) for causing a UAC to attempt to re-register with the IMS. > > > > > The IETF Secretariat > > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From dhanes@cisco.com Tue Sep 4 21:38:55 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0527211E80DE for ; Tue, 4 Sep 2012 21:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUflB0K4RbH1 for ; Tue, 4 Sep 2012 21:38:54 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id DDF3211E80BA for ; Tue, 4 Sep 2012 21:38:53 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q854cn3x008698; Wed, 5 Sep 2012 00:38:50 -0400 (EDT) Received: from rtp-dhanes-8911.cisco.com (rtp-dhanes-8911.cisco.com [10.117.39.194]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q854cmeL016468; Wed, 5 Sep 2012 00:38:49 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: David Hanes In-Reply-To: <5042302A.70505@alum.mit.edu> Date: Wed, 5 Sep 2012 00:38:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2D6852FA-D693-4277-AE9C-82D04B71325B@cisco.com> References: <502B77D4.5030402@kpfleming.us> <502BC9A3.2030902@alum.mit.edu> <502F1ADD.5060207@alum.mit.edu>, <502F7920.5090507@kpfleming.us> <7F2072F1E0DE894DA4B517B93C6A058534097503E1@ESESSCMS0356.eemea.ericsson.se> <3330DEF2-8487-4FB5-BE0F-6485B1514FAB@cisco.com> <5042302A.70505@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1084) Cc: dispatch@ietf.org Subject: [dispatch] draft-hanes-dispatch-fax-capability-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 04:38:55 -0000 Hi Paul, I appreciate the comments and they made a lot of sense. I am in complete = agreement so I went ahead and just spun up another draft (version 2) = taking your comments into account. T.38 and passthrough are the only = options really seen today outside of some proprietary offerings. = Additionally, G.711 is the audio codec that is used for passthrough so I = went ahead and explicitly cited it. If folks could take a look at this latest draft and provide me with any = additional feedback or suggestions it would be appreciated. Regards, David On Sep 1, 2012, at 11:56 AM, Paul Kyzivat wrote: > David, >=20 > This version is better! >=20 > A couple of issues: >=20 > The shown usage of Accept-Contact: >=20 > Accept-Contact: +sip.fax=3D"t38" >=20 > is syntactically incorrect. Minimally it needs to be: >=20 > Accept-Contact: *;+sip.fax=3D"t38" >=20 > (That expresses a *preference* for t38, while not excluding callees = that don't support fax or that support only some other fax encoding.) >=20 > The section on values appropriate for use with this feature tag is = wishy washy. If "t38" and "passthrough" are simply *typical*, then are = other values also permitted? If so, which ones? >=20 > In the case of passthrough, what does "transmission of fax using an = audio codec" *mean*? There must be some encoding. >=20 > IMO you should spell out the choices as an enumeraton, and each value = of the enumeration should normatively reference some standard. >=20 > Thanks, > Paul >=20 >=20 > On 8/31/12 10:15 PM, David Hanes wrote: >> Thanks for the constructive feedback on this draft. I posted a new = version of the draft for your review. >>=20 >> The principal changes in this new version are: >>=20 >> - Per Dan Wing, insertion of a paragraph expanding upon why SDP alone = is not suitable for indicating fax capability. >>=20 >> - Per Christer Holmberg, the +sip.fax tag has been changed from a = boolean type to token with an equality relationship so that we can now = explicitly define the fax transport being used >>=20 >> - addressing various nits and formatting issues >>=20 >> Additional feedback and suggestions on taking this draft forward are = welcomed and appreciated. >>=20 >> Regards, >> David >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@alum.mit.edu Wed Sep 5 07:22:25 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7360621F846A for ; Wed, 5 Sep 2012 07:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ek6AkMDV4Kjt for ; Wed, 5 Sep 2012 07:22:25 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id B782521F841C for ; Wed, 5 Sep 2012 07:22:24 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta02.westchester.pa.mail.comcast.net with comcast id vP4F1j0040cZkys51SNUpX; Wed, 05 Sep 2012 14:22:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id vSNQ1j00C3ZTu2S3WSNQJa; Wed, 05 Sep 2012 14:22:24 +0000 Message-ID: <5047601F.4020802@alum.mit.edu> Date: Wed, 05 Sep 2012 10:22:23 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: David Hanes References: <502B77D4.5030402@kpfleming.us> <502BC9A3.2030902@alum.mit.edu> <502F1ADD.5060207@alum.mit.edu>, <502F7920.5090507@kpfleming.us> <7F2072F1E0DE894DA4B517B93C6A058534097503E1@ESESSCMS0356.eemea.ericsson.se> <3330DEF2-8487-4FB5-BE0F-6485B1514FAB@cisco.com> <5042302A.70505@alum.mit.edu> <2D6852FA-D693-4277-AE9C-82D04B71325B@cisco.com> In-Reply-To: <2D6852FA-D693-4277-AE9C-82D04B71325B@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-hanes-dispatch-fax-capability-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 14:22:25 -0000 On 9/5/12 12:38 AM, David Hanes wrote: > > Hi Paul, > > I appreciate the comments and they made a lot of sense. I am in complete agreement so I went ahead and just spun up another draft (version 2) taking your comments into account. T.38 and passthrough are the only options really seen today outside of some proprietary offerings. Additionally, G.711 is the audio codec that is used for passthrough so I went ahead and explicitly cited it. > > If folks could take a look at this latest draft and provide me with any additional feedback or suggestions it would be appreciated. Much better thanks. Is there a spec for how fax is encoded over G.711? At the very least, I suppose there is a spec for how fax is encoded over analog audio, with that then being sampled for transmission over G.711. ISTM the draft should reference something that specifies how fax is encoded in the passthru case. (Consider some new implementer that has done no fax before. He wants to implement fax support, receiving a fax and saving it as an image file. He finds that some devices he needs to interwork with only support passthru. How does he parse the incoming G.711 frames to extract the fax image? While I don't expect this draft to tell him, I do think it should normatively reference something that does tell him.) Thanks, Paul > Regards, > David > > > > On Sep 1, 2012, at 11:56 AM, Paul Kyzivat wrote: > >> David, >> >> This version is better! >> >> A couple of issues: >> >> The shown usage of Accept-Contact: >> >> Accept-Contact: +sip.fax="t38" >> >> is syntactically incorrect. Minimally it needs to be: >> >> Accept-Contact: *;+sip.fax="t38" >> >> (That expresses a *preference* for t38, while not excluding callees that don't support fax or that support only some other fax encoding.) >> >> The section on values appropriate for use with this feature tag is wishy washy. If "t38" and "passthrough" are simply *typical*, then are other values also permitted? If so, which ones? >> >> In the case of passthrough, what does "transmission of fax using an audio codec" *mean*? There must be some encoding. >> >> IMO you should spell out the choices as an enumeraton, and each value of the enumeration should normatively reference some standard. >> >> Thanks, >> Paul >> >> >> On 8/31/12 10:15 PM, David Hanes wrote: >>> Thanks for the constructive feedback on this draft. I posted a new version of the draft for your review. >>> >>> The principal changes in this new version are: >>> >>> - Per Dan Wing, insertion of a paragraph expanding upon why SDP alone is not suitable for indicating fax capability. >>> >>> - Per Christer Holmberg, the +sip.fax tag has been changed from a boolean type to token with an equality relationship so that we can now explicitly define the fax transport being used >>> >>> - addressing various nits and formatting issues >>> >>> Additional feedback and suggestions on taking this draft forward are welcomed and appreciated. >>> >>> Regards, >>> David >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > From kevin@kpfleming.us Wed Sep 5 08:16:14 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE1621F862B for ; Wed, 5 Sep 2012 08:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+KBdOjOJ16b for ; Wed, 5 Sep 2012 08:16:13 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5A021F85A8 for ; Wed, 5 Sep 2012 08:16:13 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so1081088vcb.31 for ; Wed, 05 Sep 2012 08:16:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=XFIO3uTNCNB0rC9ieANi+M4Dz7VE353JUGf3ZA826nU=; b=ZNE46/jd+zdq36rzpNlEn9TE3Gig/KMZrGhdwoQGBTUDv3GI6HdLXbbIP+NznakJ9+ +dAoMqagXXcHIPtMrFjT1QM9hTPmSvuNBsY/bYLfWEvKo5dvYpt/l9OpxQsKvHEBuqb2 mP+L6e6juFfYRkuAZZd91Wz9j01W5UYKM28KAUOUK5r42ST+7cxvnF9jmBXcbMmglPQy PEXv8jgrU4cJTW/hD7IfnfrxSOzhddF+DBei8ObVGCUTamYbzcaEkJXnTvwhc+ZbnDeQ bmkW/KWw4fVq2Q/9ta45rUrlVo9Lu8CFD7pcGTjtVsQ/2ZXOwpSo/tUt4ztbxauY2HMB CVCw== MIME-Version: 1.0 Received: by 10.220.223.204 with SMTP id il12mr2917948vcb.72.1346858172879; Wed, 05 Sep 2012 08:16:12 -0700 (PDT) Received: by 10.220.214.143 with HTTP; Wed, 5 Sep 2012 08:16:12 -0700 (PDT) In-Reply-To: <5047601F.4020802@alum.mit.edu> References: <502B77D4.5030402@kpfleming.us> <502BC9A3.2030902@alum.mit.edu> <502F1ADD.5060207@alum.mit.edu> <502F7920.5090507@kpfleming.us> <7F2072F1E0DE894DA4B517B93C6A058534097503E1@ESESSCMS0356.eemea.ericsson.se> <3330DEF2-8487-4FB5-BE0F-6485B1514FAB@cisco.com> <5042302A.70505@alum.mit.edu> <2D6852FA-D693-4277-AE9C-82D04B71325B@cisco.com> <5047601F.4020802@alum.mit.edu> Date: Wed, 5 Sep 2012 10:16:12 -0500 Message-ID: From: Kevin Fleming To: Paul Kyzivat Content-Type: multipart/alternative; boundary=14dae9cdbf81f514f504c8f5da04 X-Gm-Message-State: ALoCoQktLAq3K1JWvWnoHVDiz1SY4WXD9WpCZhiJ4LM5vgludOFTe+DqDz7QZla6Qo8Ci77Qr7be Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-hanes-dispatch-fax-capability-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 15:16:14 -0000 --14dae9cdbf81f514f504c8f5da04 Content-Type: text/plain; charset=UTF-8 On Wed, Sep 5, 2012 at 9:22 AM, Paul Kyzivat wrote: > On 9/5/12 12:38 AM, David Hanes wrote: > >> >> Hi Paul, >> >> I appreciate the comments and they made a lot of sense. I am in complete >> agreement so I went ahead and just spun up another draft (version 2) taking >> your comments into account. T.38 and passthrough are the only options >> really seen today outside of some proprietary offerings. Additionally, >> G.711 is the audio codec that is used for passthrough so I went ahead and >> explicitly cited it. >> >> If folks could take a look at this latest draft and provide me with any >> additional feedback or suggestions it would be appreciated. >> > > Much better thanks. > > Is there a spec for how fax is encoded over G.711? > At the very least, I suppose there is a spec for how fax is encoded over > analog audio, with that then being sampled for transmission over G.711. > ISTM the draft should reference something that specifies how fax is encoded > in the passthru case. > > (Consider some new implementer that has done no fax before. He wants to > implement fax support, receiving a fax and saving it as an image file. He > finds that some devices he needs to interwork with only support passthru. > How does he parse the incoming G.711 frames to extract the fax image? While > I don't expect this draft to tell him, I do think it should normatively > reference something that does tell him.) > > That would be the ITU-T T.30 recommendation. --14dae9cdbf81f514f504c8f5da04 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Sep 5, 2012 at 9:22 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
On 9/5/12 12:38 AM, David Hanes wrote:

Hi Paul,

I appreciate the comments and they made a lot of sense. I am in complete ag= reement so I went ahead and just spun up another draft (version 2) taking y= our comments into account. T.38 and passthrough are the only options really= seen today outside of some proprietary offerings. Additionally, G.711 is t= he audio codec that is used for passthrough so I went ahead and explicitly = cited it.

If folks could take a look at this latest draft and provide me with any add= itional feedback or suggestions it would be appreciated.

Much better thanks.

Is there a spec for how fax is encoded over G.711?
At the very least, I suppose there is a spec for how fax is encoded over an= alog audio, with that then being sampled for transmission over G.711. ISTM = the draft should reference something that specifies how fax is encoded in t= he passthru case.

(Consider some new implementer that has done no fax before. He wants to imp= lement fax support, receiving a fax and saving it as an image file. He find= s that some devices he needs to interwork with only support passthru. How d= oes he parse the incoming G.711 frames to extract the fax image? While I do= n't expect this draft to tell him, I do think it should normatively ref= erence something that does tell him.)


That would be the ITU-T T.30 recommend= ation.=C2=A0
--14dae9cdbf81f514f504c8f5da04-- From pkyzivat@alum.mit.edu Wed Sep 5 08:49:58 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2912921F865F for ; Wed, 5 Sep 2012 08:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghjG8efq1huo for ; Wed, 5 Sep 2012 08:49:57 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 965D721F8546 for ; Wed, 5 Sep 2012 08:49:57 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta03.westchester.pa.mail.comcast.net with comcast id vPQu1j00D0xGWP853Tq1Li; Wed, 05 Sep 2012 15:50:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id vTpK1j0033ZTu2S3YTpKQK; Wed, 05 Sep 2012 15:49:19 +0000 Message-ID: <504774A4.10308@alum.mit.edu> Date: Wed, 05 Sep 2012 11:49:56 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Kevin Fleming References: <502B77D4.5030402@kpfleming.us> <502BC9A3.2030902@alum.mit.edu> <502F1ADD.5060207@alum.mit.edu> <502F7920.5090507@kpfleming.us> <7F2072F1E0DE894DA4B517B93C6A058534097503E1@ESESSCMS0356.eemea.ericsson.se> <3330DEF2-8487-4FB5-BE0F-6485B1514FAB@cisco.com> <5042302A.70505@alum.mit.edu> <2D6852FA-D693-4277-AE9C-82D04B71325B@cisco.com> <5047601F.4020802@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-hanes-dispatch-fax-capability-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 15:49:58 -0000 On 9/5/12 11:16 AM, Kevin Fleming wrote: > On Wed, Sep 5, 2012 at 9:22 AM, Paul Kyzivat > wrote: > > On 9/5/12 12:38 AM, David Hanes wrote: > > > Hi Paul, > > I appreciate the comments and they made a lot of sense. I am in > complete agreement so I went ahead and just spun up another > draft (version 2) taking your comments into account. T.38 and > passthrough are the only options really seen today outside of > some proprietary offerings. Additionally, G.711 is the audio > codec that is used for passthrough so I went ahead and > explicitly cited it. > > If folks could take a look at this latest draft and provide me > with any additional feedback or suggestions it would be appreciated. > > > Much better thanks. > > Is there a spec for how fax is encoded over G.711? > At the very least, I suppose there is a spec for how fax is encoded > over analog audio, with that then being sampled for transmission > over G.711. ISTM the draft should reference something that specifies > how fax is encoded in the passthru case. > > (Consider some new implementer that has done no fax before. He wants > to implement fax support, receiving a fax and saving it as an image > file. He finds that some devices he needs to interwork with only > support passthru. How does he parse the incoming G.711 frames to > extract the fax image? While I don't expect this draft to tell him, > I do think it should normatively reference something that does tell > him.) > > > That would be the ITU-T T.30 recommendation. Then can you reference that? Thanks, Paul From dhanes@cisco.com Fri Sep 7 09:18:28 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34BE421F8453 for ; Fri, 7 Sep 2012 09:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orGU1ClrM9-B for ; Fri, 7 Sep 2012 09:18:27 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 374E821F8452 for ; Fri, 7 Sep 2012 09:18:25 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q87GINZk018541; Fri, 7 Sep 2012 12:18:23 -0400 (EDT) Received: from rtp-dhanes-8911.cisco.com (rtp-dhanes-8911.cisco.com [10.117.39.194]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q87GINlh027951; Fri, 7 Sep 2012 12:18:23 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: David Hanes In-Reply-To: <201209051852.q85Iqn02011189@freeze.ariadne.com> Date: Fri, 7 Sep 2012 12:18:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <04C097D6-7427-4EFF-815C-5F1BAE0FF408@cisco.com> References: <201209051852.q85Iqn02011189@freeze.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.1084) Cc: DISPATCH Subject: Re: [dispatch] draft-hanes-dispatch-fax-capability-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 16:18:28 -0000 On Sep 5, 2012, at 2:52 PM, Dale R. Worley wrote: > I think the descriptions of the values could be improved a little bit. You are probably right. :-) >=20 > The "t38" value is better described as "supports the image/t38 media > type[RFC3362] which encodes page images using the ITU-T T.38 fax > protocol[T.38]". That specifies the media type and adds a reference > to the RFC, which includes more details of the specific ITU > recommendations involved. There are probably some implications of > what values of the T.38 SDP attributes are supported -- is there a > default set of attributes which constitute a baseline version of > image/t38? >=20 I like the image/t38 media and RFC specifics that you added above and I = will include these updates in the next version. You also mention specific T.38 attributes. I am not aware of a default = set of attribute values. It seems that each vendor has certain defaults = but it is probably safe to say that many are commonly set the same. = Thinking this through though, it seems like the goal of this feature tag = is to signal the preference that the call lands at a fax capable, or = more specifically in this case, a T.38 capable UA. Once the T.38 capable = UAs are connected, shouldn't they handle the T.38 attribute = exchange/negotiation within SDP? This is how it works now. It seems that = just specifying T.38 would be enough in this case and then the UAs can = deal with the T.38 attribute settings within SDP. =20 > The definition of "passthrough" is incomplete as it stands. The > meaning is "supports the audio/pcmu and audio/pcma media > types[RFC4856] for the transmission of fax images encoded (somehow) as > an analog audio stream, which is in turn encoded using G.711". But > what is the description of "somehow" and the proper reference for it? The "somehow" here is defined by ITU-T T.30, T.4, and T.6 and these are = modulated using common schemes like V.21 and V.17 so that the fax = communication is now an analog stream. I am not sure that we need this = level of detail though. This audio stream generation happens with every = fax machine and gateway. Passthrough is very simple. We are just = replacing human speech over G.711 with an analog fax stream. G.711 has = been used on the PSTN for decades on T1/E1 spans for handling voice and = fax. Basically, when we use the term passthrough, we are saying treat = fax like a G.711 voice call. With that being said, wouldn't just = referencing G.711 be enough from a media feature tag and user preference = perspective? > I don't know fax technologies well enough to know what it is, though > I'm certain that there is a specific standard intended here. >=20 The only attempt that I am aware of towards passthrough (or voice band = data) standardization is ITU-T V.152. However, I have never seen it = implemented... probably because of the signaling portion of it. The part = about vbd/passthrough implementation is really good and most vendors = have implemented it in this manner. Here are Sections 6 and 6.1, which I = think is along the lines of what you all are looking for -=20 6 Definition of the VBD mode of operation Voice-band data is the transport of modem, facsimile, and text telephony = signals over a voice channel of a packet network with a codec = appropriate for such signals. For voice-band data (VBD) mode of operation, all voice-band modulated = signal samples shall be transported across an IP network using the RTP = protocol defined in IETF RFC 3550. When in VBD mode, a V.152 compliant implementation shall: =E2=80=A2 Use a codec that passes voice-band modulated signals = with minimal distortion. This codec shall be assigned as the VBD codec = with a specific RTP payload type which shall be negotiated with the = remote V.152 implementations as described in clause 7. =E2=80=A2 Have end-to-end constant latency. =E2=80=A2 Disable voice activity detection and comfort noise = generation during the data transfer phase. =E2=80=A2 Disable any DC removal filters that may be integral with = the speech encoder used. And should consider the appropriate application = of: =E2=80=A2 The use of echo cancellers on the VBD channel, as per = ITU-T Rec. G.168. =E2=80=A2 Forward Error Correction (FEC) (e.g., RFC 2733) or other = forms of redundancy (e.g., RFC 2198) only if support has been = successfully negotiated with the remote V.152 implementation. =E2=80=A2 Voice packet loss concealment techniques and algorithms = that are suitable for modem and facsimile modulations. 6.1 Minimum requirements for VBD mode of operation For purposes of interoperability, a V.152 compliant implementation shall = support at least both G.711 A-law and G.711 =CE=BC-law codecs as VBD = codecs. When negotiating the VBD codec, the initiating V.152 implementation must = include in the offer either PCMA or PCMU (or both) in the list of VBD = codecs, though other VBD codecs may be additionally specified. The V.152 = implementation answering the offer must indicate support for at least = one VBD codec, which need not be PCM-based. Redundancy as per IETF RFC2198 and forward error correction as per IETF = RFC2733 are supported options. > Do we want to require PCMU and PCMA support, or PCMU *or* PCMA > support? >=20 As with the T.38 SDP attributes, is this something that we want to = address in this draft or just leave it to the SDP portion? With only 2 = codec options, you could have "passthrough-g711=CE=BC" and = "passthrough-g711a" values. However, in reality most folks implementing = passthrough will accept either G.711 variety. > What encoding parameter values are required for support? I expect we > want to add that the audio stream is single-channel and we probably > want to specify that it is at 8000Hz sample rate. >=20 > Also, the reference to the T.38 spec is given as informative, whereas > it is used normatively. >=20 Thanks. I will get that fixed in the next version.=20 > Dale From pkyzivat@alum.mit.edu Fri Sep 7 09:42:53 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB1821F861F for ; Fri, 7 Sep 2012 09:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wa9B0Ut4tiML for ; Fri, 7 Sep 2012 09:42:51 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id ABF0421F861C for ; Fri, 7 Sep 2012 09:42:51 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta08.westchester.pa.mail.comcast.net with comcast id wEX61j0031GhbT858Gip6b; Fri, 07 Sep 2012 16:42:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id wGj61j00E3ZTu2S3TGj6b0; Fri, 07 Sep 2012 16:43:06 +0000 Message-ID: <504A2403.3080202@alum.mit.edu> Date: Fri, 07 Sep 2012 12:42:43 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: David Hanes References: <201209051852.q85Iqn02011189@freeze.ariadne.com> <04C097D6-7427-4EFF-815C-5F1BAE0FF408@cisco.com> In-Reply-To: <04C097D6-7427-4EFF-815C-5F1BAE0FF408@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "Dale R. Worley" , DISPATCH Subject: Re: [dispatch] draft-hanes-dispatch-fax-capability-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 16:42:53 -0000 On 9/7/12 12:18 PM, David Hanes wrote: > > On Sep 5, 2012, at 2:52 PM, Dale R. Worley wrote: > >> I think the descriptions of the values could be improved a little bit. > > You are probably right. :-) > > >> >> The "t38" value is better described as "supports the image/t38 media >> type[RFC3362] which encodes page images using the ITU-T T.38 fax >> protocol[T.38]". That specifies the media type and adds a reference >> to the RFC, which includes more details of the specific ITU >> recommendations involved. There are probably some implications of >> what values of the T.38 SDP attributes are supported -- is there a >> default set of attributes which constitute a baseline version of >> image/t38? >> > > I like the image/t38 media and RFC specifics that you added above and I will include these updates in the next version. > > You also mention specific T.38 attributes. I am not aware of a default set of attribute values. It seems that each vendor has certain defaults but it is probably safe to say that many are commonly set the same. Thinking this through though, it seems like the goal of this feature tag is to signal the preference that the call lands at a fax capable, or more specifically in this case, a T.38 capable UA. Once the T.38 capable UAs are connected, shouldn't they handle the T.38 attribute exchange/negotiation within SDP? This is how it works now. It seems that just specifying T.38 would be enough in this case and then the UAs can deal with the T.38 attribute settings within SDP. Yes, I think that is appropriate. >> The definition of "passthrough" is incomplete as it stands. The >> meaning is "supports the audio/pcmu and audio/pcma media >> types[RFC4856] for the transmission of fax images encoded (somehow) as >> an analog audio stream, which is in turn encoded using G.711". But >> what is the description of "somehow" and the proper reference for it? > > The "somehow" here is defined by ITU-T T.30, T.4, and T.6 and these are modulated using common schemes like V.21 and V.17 so that the fax communication is now an analog stream. I am not sure that we need this level of detail though. This audio stream generation happens with every fax machine and gateway. Passthrough is very simple. We are just replacing human speech over G.711 with an analog fax stream. G.711 has been used on the PSTN for decades on T1/E1 spans for handling voice and fax. Basically, when we use the term passthrough, we are saying treat fax like a G.711 voice call. With that being said, wouldn't just referencing G.711 be enough from a media feature tag and user preference perspective? Not much is needed if the goal is simply to connect existing analog fax machines. But fax is becoming rarer as time goes on. Consider someone that wants to implement software that can transmit/receive images via fax in order to comply with needs of others. (E.g. because fax is the only thing the recipient supports.) This person needs to discover the specs to implement to accomplish this. With T.38 there is a clear reference that someone not familiar with fax can figure out. With passthru, he will need specs for everything. Perhaps the specs you mention above are what he needs. But "common schemes *like" V.21 *and* V.17" would leave me wondering - which other ones might be included, and how do I know which ones to implement? Since fax machines (old and new, cheap and fancy) seem to interoperate fairly successfully I presume there are interoperability and fallback provisions in the various specs. Maybe it is sufficient to reference one or a few, if those in turn reference the others they are interoperable with. I'm not expecting that you write a book here. :-) Just that you point to the key specs that will *lead* a developer to what he needs to know about anything you expect to be compliant with "passthru". Maybe the ones you have mentioned are sufficient. Thanks, Paul From richard@shockey.us Fri Sep 7 11:39:45 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0667621E80CE for ; Fri, 7 Sep 2012 11:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.495 X-Spam-Level: X-Spam-Status: No, score=-100.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I82C1dUc109o for ; Fri, 7 Sep 2012 11:39:44 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id 689EE21F85C7 for ; Fri, 7 Sep 2012 11:39:44 -0700 (PDT) Received: (qmail 4842 invoked by uid 0); 7 Sep 2012 18:39:44 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy7.bluehost.com with SMTP; 7 Sep 2012 18:39:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=tUKyVSMjUP3cUa7kvU2rX//FNtMsbA2IHFy9P1ULoFo=; b=HwCO+ZGO0kDHezXoXyc2Td4MzpqfaDkRkHaHy/Vnf6EcKdHGEUtvuRxNxKEOybZBTiusLL+VrC4Rtfh7WlODmK0dFy30lejQiMJRosr+Q/tQMYUEdTjgR8VvNsQgW1gY; Received: from [71.191.243.130] (port=52760 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TA3Sx-0001mQ-MJ; Fri, 07 Sep 2012 12:39:43 -0600 From: "Richard Shockey" To: "'Paul Kyzivat'" , "'David Hanes'" References: <201209051852.q85Iqn02011189@freeze.ariadne.com> <04C097D6-7427-4EFF-815C-5F1BAE0FF408@cisco.com> <504A2403.3080202@alum.mit.edu> In-Reply-To: <504A2403.3080202@alum.mit.edu> Date: Fri, 7 Sep 2012 14:39:42 -0400 Message-ID: <01d201cd8d28$25b74b30$7125e190$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2NF9TxrrwMD4s2QdCPnQzToShUFgAD693Q Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.191.243.130 authed with richard@shockey.us} Cc: "'Dale R. Worley'" , 'DISPATCH' Subject: Re: [dispatch] draft-hanes-dispatch-fax-capability-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 18:39:45 -0000 But fax is becoming rarer as time goes on. [RS> ] Less relevant but it is NOT going away, especially if you live in countries with non ASCII characters in the language. Fax as a application is imbedded in law since the principal attribute users are comfortable with is non repudiation. ( 3rd party billing ). If sending a PDF over email was acceptable than we wouldn't have this discussion. I point that out only as a reminder. Consider someone that wants to implement software that can transmit/receive images via fax in order to comply with needs of others. (E.g. because fax is the only thing the recipient supports.) This person needs to discover the specs to implement to accomplish this. With T.38 there is a clear reference that someone not familiar with fax can figure out. With passthru, he will need specs for everything. Perhaps the specs you mention above are what he needs. But "common schemes *like" V.21 *and* V.17" would leave me wondering - which other ones might be included, and how do I know which ones to implement? Since fax machines (old and new, cheap and fancy) seem to interoperate fairly successfully I presume there are interoperability and fallback provisions in the various specs. Maybe it is sufficient to reference one or a few, if those in turn reference the others they are interoperable with. I'm not expecting that you write a book here. :-) Just that you point to the key specs that will *lead* a developer to what he needs to know about anything you expect to be compliant with "passthru". Maybe the ones you have mentioned are sufficient. Thanks, Paul _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From richard@shockey.us Fri Sep 7 13:51:34 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 068A821E80E6 for ; Fri, 7 Sep 2012 13:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.328 X-Spam-Level: X-Spam-Status: No, score=-98.328 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWovHMvovYaA for ; Fri, 7 Sep 2012 13:51:29 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id DF44721E80E0 for ; Fri, 7 Sep 2012 13:51:28 -0700 (PDT) Received: (qmail 24599 invoked by uid 0); 7 Sep 2012 20:51:28 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy7.bluehost.com with SMTP; 7 Sep 2012 20:51:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=m4jC7aRFLu3tCMG6QA42OHu+uezRCTBCu55qKmyGA0Y=; b=VdPPosJfkU6VhSh83ftByuW7VsUwwLkNmsysnS5WQV3FQcW0RLQnETSWGIcpUZvO/8BFhMxzuPv2OttqfHi2T11Ry9z3tzv5XqpNNy1QpFzAFpIVi3q3fY08EWT+LOHp; Received: from [71.191.243.130] (port=55185 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TA5WR-0007X7-Tg; Fri, 07 Sep 2012 14:51:28 -0600 From: "Richard Shockey" To: "'DISPATCH'" , , Date: Fri, 7 Sep 2012 16:51:26 -0400 Message-ID: <021401cd8d3a$8cf46960$a6dd3c20$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0215_01CD8D19.05E2C960" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2NOowOW92M10WOQ3+sn3sHdFeGrQ== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.191.243.130 authed with richard@shockey.us} Subject: [dispatch] For your weekend reading... X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 20:51:34 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0215_01CD8D19.05E2C960 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Our dear and beloved colleagues at ATT strolled up to the 8th floor of the US Federal Communications Commission and respectfully suggested they "retire" Time Division Multiplexing networks and services in favor of a all IP ( read SIP ) based Network/Ecosystem. http://apps.fcc.gov/ecfs/document/view?id=7022008762 < insert applause> Gives a whole new meaning to the Death Star logo. don't you think? Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 < mailto:richard(at)shockey.us> skype-linkedin-facebook: rshockey101 http//www.sipforum.org ------=_NextPart_000_0215_01CD8D19.05E2C960 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Our dear = and beloved colleagues at  ATT strolled up to the 8th = floor of the US Federal Communications Commission and respectfully = suggested they “retire”  Time Division Multiplexing = networks and services in favor of a all IP  ( read SIP ) =  based Network/Ecosystem.

 

http://ap= ps.fcc.gov/ecfs/document/view?id=3D7022008762

 

< insert applause> =

 

Gives a whole new meaning to the Death Star = logo… don’t you think? 

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

 

------=_NextPart_000_0215_01CD8D19.05E2C960-- From atle.monrad@ericsson.com Mon Sep 17 04:56:12 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C97721F8647 for ; Mon, 17 Sep 2012 04:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3dfWruROsea for ; Mon, 17 Sep 2012 04:56:11 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id BE32221F847A for ; Mon, 17 Sep 2012 04:56:10 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-76-50570fd97a7e Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 98.C8.25676.9DF07505; Mon, 17 Sep 2012 13:56:09 +0200 (CEST) Received: from ESESSCMS0352.eemea.ericsson.se ([169.254.2.64]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Mon, 17 Sep 2012 13:56:09 +0200 From: Atle Monrad To: Paul Kyzivat , "dispatch@ietf.org" Date: Mon, 17 Sep 2012 13:56:07 +0200 Thread-Topic: [dispatch] New Version Notification for draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt Thread-Index: Ac2KwZhU3LVrhdIuREGO/URHiJakOQKCNcFQ Message-ID: <7A051DFAA46D0246A82293C7CEF621E90709FCB203@ESESSCMS0352.eemea.ericsson.se> References: <20120904152546.18420.91591.idtracker@ietfa.amsl.com> <155970D1DA8E174F9E46039E10E2AA351EA834@XMB104ADS.rim.net> <5046385A.4080803@alum.mit.edu> In-Reply-To: <5046385A.4080803@alum.mit.edu> Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nb-NO, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+Jvre5N/vAAg2s9mhZLJy1gtVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXxf+MT1oJrihVHF8xgbmD8Kd3FyMkhIWAi cfrfXWYIW0ziwr31bF2MXBxCAqcYJZZ8uAjlLGCUeHCigxWkik1AR+LczztgtohAsMTBwztZ uhg5OFgEVCXubOIACQsL5EkcO/mMEaIkX+LmrfcsELaRxMMJt8GW8QqES3y40cMIN//v/Adg MzmB5k/qu8YMMpNRQFZibhMvSJhZQFzi1pP5TBCHCkgs2XMe6mhRiZeP/4G1MgrISKzY+o0N ol5HYsHuT1C2tsSyha+h9gpKnJz5hGUCo+gsJGNnIWmZhaRlFpKWBYwsqxiFcxMzc9LLjfRS izKTi4vz8/SKUzcxAmPk4JbfqjsY75wTOcQozcGiJM5rvXWPv5BAemJJanZqakFqUXxRaU5q 8SFGJg5OqQZGDdtKxS/xAnmXOlTPJaRFb9E2WH3jeZvTd3VB8zo93usV1YbXHL/t1Xo91ULi 9nGjWYncyyRqUoR/7Vx/honNyMuU186dO1l34snCD1KCnLO15Zm/Cn77bFCgXfvxUq38Vrtn irGPNyT4133rcUt9zRLNfpRbrOvPYb7j+ySPbGRsuv5L9qASS3FGoqEWc1FxIgBLmxiiXwIA AA== Subject: Re: [dispatch] New Version Notification for draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 11:56:12 -0000 All 3GPP has been waiting for long time on completion of this draft. I hope tha= t the new version provided by John-Luc is acceptable and can be progressed. As the new version has limited changes compated to the previous version, I = hope that this draft does not need too long time for considerations before = it can be progressed & completed. >From 3GPP, this draft is supported. /atle ________________________________=20 Atle Monrad 3GPP CT Chairman Standardization and Regulation, Group Function Technology and Portfolio Management=20 Ericsson -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Paul Kyzivat Sent: 4. september 2012 19:20 To: dispatch@ietf.org Subject: Re: [dispatch] New Version Notification for draft-bakker-dispatch-= 3gpp-ims-xml-body-handling-00.txt To make it easier for other readers, here is a link that does the diff of t= his version to the prior one: http://tools.ietf.org/rfcdiff?url1=3Ddraft-bakker-sipping-3gpp-ims-xml-body= -handling-08.txt;url2=3Ddraft-bakker-dispatch-3gpp-ims-xml-body-handling-00= .txt Regards, Paul On 9/4/12 11:30 AM, John-Luc Bakker wrote: > Dear all, > > I have submitted a new version of the previous "draft-bakker-sipping-3gpp= -ims-xml-body-handling", taking into account the various comments received.= The most notable change is to submit the draft to DISPATCH (instead of SIP= PING) and to submit the draft for standards track consideration. > > I welcome your comments. > > Kind regards, > > John-Luc > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Tuesday, September 04, 2012 10:26 AM > To: John-Luc Bakker > Subject: New Version Notification for=20 > draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt > > > A new version of I-D,=20 > draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt > has been successfully submitted by John-Luc Bakker and posted to the IETF= repository. > > Filename: draft-bakker-dispatch-3gpp-ims-xml-body-handling > Revision: 00 > Title: Specification of 3GPP IM CN Subsystem XML body handling > Creation date: 2012-09-04 > WG ID: Individual Submission > Number of pages: 8 > URL: http://www.ietf.org/internet-drafts/draft-bakker-dispatc= h-3gpp-ims-xml-body-handling-00.txt > Status: http://datatracker.ietf.org/doc/draft-bakker-dispatch-3g= pp-ims-xml-body-handling > Htmlized: http://tools.ietf.org/html/draft-bakker-dispatch-3gpp-im= s-xml-body-handling-00 > > > Abstract: > This document registers new disposition-types for the Content- > Disposition header field that apply to the application/3gpp-ims+xml > body (part) used by 3GPP [5]. The applicability of these content- > disposition values are limited to 3GPP IMS [5]. The application/ > 3gpp-ims+xml body (part) has the following three distinct uses: (1) > for redirecting the emergency session to use a different domain (e.g. > using a Circuit Switched call), (2) for delivering user profile > specific information from the SIP registrar to an Application Server, > and (3) for causing a UAC to attempt to re-register with the IMS. > > > > > The IETF Secretariat > > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately reply to the sender and delete this information from your system= . Use, dissemination, distribution, or reproduction of this transmission by= unintended recipients is not authorized and may be unlawful. > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@alum.mit.edu Tue Sep 18 09:26:18 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB0621F8523 for ; Tue, 18 Sep 2012 09:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0HZ25IFGJiD for ; Tue, 18 Sep 2012 09:26:18 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 0F73F21F8526 for ; Tue, 18 Sep 2012 09:26:17 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta01.westchester.pa.mail.comcast.net with comcast id 0dED1k0071YDfWL51gSMG1; Tue, 18 Sep 2012 16:26:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([64.134.225.153]) by omta20.westchester.pa.mail.comcast.net with comcast id 0gRN1k0183KCHDc3ggRUrQ; Tue, 18 Sep 2012 16:25:44 +0000 Message-ID: <5058A08E.5000402@alum.mit.edu> Date: Tue, 18 Sep 2012 12:25:50 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Atle Monrad References: <20120904152546.18420.91591.idtracker@ietfa.amsl.com> <155970D1DA8E174F9E46039E10E2AA351EA834@XMB104ADS.rim.net> <5046385A.4080803@alum.mit.edu> <7A051DFAA46D0246A82293C7CEF621E90709FCB203@ESESSCMS0352.eemea.ericsson.se> In-Reply-To: <7A051DFAA46D0246A82293C7CEF621E90709FCB203@ESESSCMS0352.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] New Version Notification for draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 16:26:18 -0000 I have said all I have to say, repeatedly. The fundamental issues I raised, *years* ago now, still remain. It is difficult for me not to believe that the goal all along was to bring in a draft to be "rubber stamped". Suggestions to clean it up were stonewalled, followed by claims that while it could have been better it cannot now be changed because it has been deployed in the current form. Paul On 9/17/12 7:56 AM, Atle Monrad wrote: > All > > 3GPP has been waiting for long time on completion of this draft. I hope that the new version provided by John-Luc is acceptable and can be progressed. > > As the new version has limited changes compated to the previous version, I hope that this draft does not need too long time for considerations before it can be progressed & completed. > >>From 3GPP, this draft is supported. > > /atle > > ________________________________ > > > Atle Monrad > 3GPP CT Chairman > Standardization and Regulation, > Group Function Technology and Portfolio Management > Ericsson > > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 4. september 2012 19:20 > To: dispatch@ietf.org > Subject: Re: [dispatch] New Version Notification for draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt > > To make it easier for other readers, here is a link that does the diff of this version to the prior one: > > http://tools.ietf.org/rfcdiff?url1=draft-bakker-sipping-3gpp-ims-xml-body-handling-08.txt;url2=draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt > > Regards, > Paul > > On 9/4/12 11:30 AM, John-Luc Bakker wrote: >> Dear all, >> >> I have submitted a new version of the previous "draft-bakker-sipping-3gpp-ims-xml-body-handling", taking into account the various comments received. The most notable change is to submit the draft to DISPATCH (instead of SIPPING) and to submit the draft for standards track consideration. >> >> I welcome your comments. >> >> Kind regards, >> >> John-Luc >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Tuesday, September 04, 2012 10:26 AM >> To: John-Luc Bakker >> Subject: New Version Notification for >> draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt >> >> >> A new version of I-D, >> draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt >> has been successfully submitted by John-Luc Bakker and posted to the IETF repository. >> >> Filename: draft-bakker-dispatch-3gpp-ims-xml-body-handling >> Revision: 00 >> Title: Specification of 3GPP IM CN Subsystem XML body handling >> Creation date: 2012-09-04 >> WG ID: Individual Submission >> Number of pages: 8 >> URL: http://www.ietf.org/internet-drafts/draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt >> Status: http://datatracker.ietf.org/doc/draft-bakker-dispatch-3gpp-ims-xml-body-handling >> Htmlized: http://tools.ietf.org/html/draft-bakker-dispatch-3gpp-ims-xml-body-handling-00 >> >> >> Abstract: >> This document registers new disposition-types for the Content- >> Disposition header field that apply to the application/3gpp-ims+xml >> body (part) used by 3GPP [5]. The applicability of these content- >> disposition values are limited to 3GPP IMS [5]. The application/ >> 3gpp-ims+xml body (part) has the following three distinct uses: (1) >> for redirecting the emergency session to use a different domain (e.g. >> using a Circuit Switched call), (2) for delivering user profile >> specific information from the SIP registrar to an Application Server, >> and (3) for causing a UAC to attempt to re-register with the IMS. >> >> >> >> >> The IETF Secretariat >> >> >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From dean.willis@softarmor.com Tue Sep 18 20:57:48 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6370211E80EA for ; Tue, 18 Sep 2012 20:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUsfXRPveoZg for ; Tue, 18 Sep 2012 20:57:47 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB0211E80E7 for ; Tue, 18 Sep 2012 20:57:47 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so738133vbb.31 for ; Tue, 18 Sep 2012 20:57:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ayujby0u7XsPMVn3OSh7zjHqnMDk9OHArTQBHvz/8dc=; b=I7sDoF0b2ZmqzRYvHjUomusQVihEYOr8kRM/yvZ+TGD263BJz3QLDdUB7Cc2d19RfC cW/sCiq3u56Rh+znBEHVN+Y4l2RiWVidMv9OmYQT9oueAuYiAeg7eh1LdcQp0K4mdZZK E6AotJ4/6ZTP4aRTInfP2ajY3ES+sp0Osy+0s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=ayujby0u7XsPMVn3OSh7zjHqnMDk9OHArTQBHvz/8dc=; b=O6pkKQpzVn01KeK9Om+cRj6mIWyAXuwhfB+cL5T1NfAv92hCTBY9rjE6/6eKxrJ6yS 50gwa8rO78B7vCrL3BYkSB5i22jo312O5nUAwMGmseAiBcXUy1hv1QeocsTw6jwMqLA6 eOZ5qsNrJW+vKXozAevFGQanZxT2xd7UaXMLzuI+UNqcG6fWMKLvZRbeWz/+7x23DqIe GeunVKc1qYZdgtzpn0P6gbHihfogRLxZM5FZEPTKUp+mF04a8lgKRAr+g792M2ZoQ75K YBhj/u8YCa6X0/Qx29y784N+o5EffJCMR3CN8mJmbWDLlAbjZD0M90LpYstWnYHlVKzW 4Hcw== MIME-Version: 1.0 Received: by 10.52.26.137 with SMTP id l9mr996055vdg.62.1348027066826; Tue, 18 Sep 2012 20:57:46 -0700 (PDT) Received: by 10.58.163.65 with HTTP; Tue, 18 Sep 2012 20:57:46 -0700 (PDT) In-Reply-To: <155970D1DA8E174F9E46039E10E2AA351EA834@XMB104ADS.rim.net> References: <20120904152546.18420.91591.idtracker@ietfa.amsl.com> <155970D1DA8E174F9E46039E10E2AA351EA834@XMB104ADS.rim.net> Date: Tue, 18 Sep 2012 22:57:46 -0500 Message-ID: From: Dean Willis To: John-Luc Bakker Content-Type: multipart/alternative; boundary=20cf307cfd36773efd04ca060278 X-Gm-Message-State: ALoCoQlMJ65DlfNV2fjKAt5103I7aJNrNNsECbg5crQ8PVfQs7HTUFkYvqJuXiK8ZBvPG98u68w6 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] New Version Notification for draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 03:57:48 -0000 --20cf307cfd36773efd04ca060278 Content-Type: text/plain; charset=ISO-8859-1 Be advised, there appears to be extant IPR covering this approach. I've filed a 3rd party disclosure for the IETF process with respect to publication *US20090119382. * On Tue, Sep 4, 2012 at 10:30 AM, John-Luc Bakker wrote: > Dear all, > > I have submitted a new version of the previous > "draft-bakker-sipping-3gpp-ims-xml-body-handling", taking into account the > various comments received. The most notable change is to submit the draft > to DISPATCH (instead of SIPPING) and to submit the draft for standards > track consideration. > > I welcome your comments. > > Kind regards, > > John-Luc > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Tuesday, September 04, 2012 10:26 AM > To: John-Luc Bakker > Subject: New Version Notification for > draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt > > > A new version of I-D, > draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt > has been successfully submitted by John-Luc Bakker and posted to the IETF > repository. > > Filename: draft-bakker-dispatch-3gpp-ims-xml-body-handling > Revision: 00 > Title: Specification of 3GPP IM CN Subsystem XML body handling > Creation date: 2012-09-04 > WG ID: Individual Submission > Number of pages: 8 > URL: > http://www.ietf.org/internet-drafts/draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt > Status: > http://datatracker.ietf.org/doc/draft-bakker-dispatch-3gpp-ims-xml-body-handling > Htmlized: > http://tools.ietf.org/html/draft-bakker-dispatch-3gpp-ims-xml-body-handling-00 > > > Abstract: > This document registers new disposition-types for the Content- > Disposition header field that apply to the application/3gpp-ims+xml > body (part) used by 3GPP [5]. The applicability of these content- > disposition values are limited to 3GPP IMS [5]. The application/ > 3gpp-ims+xml body (part) has the following three distinct uses: (1) > for redirecting the emergency session to use a different domain (e.g. > using a Circuit Switched call), (2) for delivering user profile > specific information from the SIP registrar to an Application Server, > and (3) for causing a UAC to attempt to re-register with the IMS. > > > > > The IETF Secretariat > > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be unlawful. > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --20cf307cfd36773efd04ca060278 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Be advised, there appears to be extant IPR covering this approach. I've= filed a 3rd party disclosure for the IETF process with respect to publicat= ion US20090119382.




On = Tue, Sep 4, 2012 at 10:30 AM, John-Luc Bakker <jbakker@rim.com> wrote:
Dear all,

I have submitted a new version of the previous "draft-bakker-sipping-3= gpp-ims-xml-body-handling", taking into account the various comments r= eceived. The most notable change is to submit the draft to DISPATCH (instea= d of SIPPING) and to submit the draft for standards track consideration.
I welcome your comments.

Kind regards,

=A0 =A0 =A0 =A0 John-Luc

-----Original Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Tuesday, September 04, 2012 10:26 AM
To: John-Luc Bakker
Subject: New Version Notification for draft-bakker-dispatch-3gpp-ims-xml-bo= dy-handling-00.txt


A new version of I-D, draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.t= xt
has been successfully submitted by John-Luc Bakker and posted to the IETF r= epository.

Filename: =A0 =A0 =A0 =A0draft-bakker-dispatch-3gpp-ims-xml-body-handling Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 Specification of 3GPP IM CN Subsystem XML body h= andling
Creation date: =A0 2012-09-04
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 8
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/internet-drafts/draft-bakker-dispatch-3gpp-ims-xml-bod= y-handling-00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datat= racker.ietf.org/doc/draft-bakker-dispatch-3gpp-ims-xml-body-handling Htmlized: =A0 =A0 =A0 =A0http://tools.iet= f.org/html/draft-bakker-dispatch-3gpp-ims-xml-body-handling-00


Abstract:
=A0 =A0This document registers new disposition-types for the Content-
=A0 =A0Disposition header field that apply to the application/3gpp-ims+xml<= br> =A0 =A0body (part) used by 3GPP [5]. =A0The applicability of these content-=
=A0 =A0disposition values are limited to 3GPP IMS [5]. =A0The application/<= br> =A0 =A03gpp-ims+xml body (part) has the following three distinct uses: (1)<= br> =A0 =A0for redirecting the emergency session to use a different domain (e.g= .
=A0 =A0using a Circuit Switched call), (2) for delivering user profile
=A0 =A0specific information from the SIP registrar to an Application Server= ,
=A0 =A0and (3) for causing a UAC to attempt to re-register with the IMS.



The IETF Secretariat


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful.
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--20cf307cfd36773efd04ca060278-- From dean.willis@softarmor.com Tue Sep 18 21:03:02 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE8E821E8092 for ; Tue, 18 Sep 2012 21:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21OnCDrrW3NG for ; Tue, 18 Sep 2012 21:03:01 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD7D11E80E7 for ; Tue, 18 Sep 2012 21:03:01 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so745227vbb.31 for ; Tue, 18 Sep 2012 21:03:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q3FkMUKwJyDiy/c6HXWEJ04tXIcrNHLmSxcUNHYPzIE=; b=SIFtjgU7ydCD+VC3dYllq4Hy99dae5hdZOjeoeaL5m8bWLV7z3TkIqoKi5wnaYbTgk iLwxRhpJUtrkLiNu9tiivndCrK+I/W96d8skqHsh2k1jR56+h7IpmWMs38nwEHFvq6jC LdYd9IVNdmwOMASyliHx0svjzaTsbik5RCjVY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Q3FkMUKwJyDiy/c6HXWEJ04tXIcrNHLmSxcUNHYPzIE=; b=MfHWjj2ua2mF9mbhq1PTCkiFzUOzpY+RXcgByyEYhH8QFVpTkDwAI4pVNV29lnU6IB XZQr5fAfajP9f6hWGRxQYxNT4suJ/V6XIFuwugipQd0cx1nQ6YhTqJIPGcT72v+DOMe2 qeE2LqIOAwBYWh4R79M80L2D/g4541iTha17aIrdmrToDdXpoJcVlsfPoHrx5SS1LuPr 31mN/UF4Qzl3+8WDRreaf+376fDarRvJj2w5r/Q51wawx/pB/4Rfy7njQg38ulhtmInn L1hfVECeNiRQxqcns0RVBT0jWbcvengQ5J2AqfrsLb2jtxK1EDYiKf/ggx/T4vgBSx8F xKug== MIME-Version: 1.0 Received: by 10.52.74.6 with SMTP id p6mr963957vdv.124.1348027380865; Tue, 18 Sep 2012 21:03:00 -0700 (PDT) Received: by 10.58.163.65 with HTTP; Tue, 18 Sep 2012 21:03:00 -0700 (PDT) In-Reply-To: References: <20120904152546.18420.91591.idtracker@ietfa.amsl.com> <155970D1DA8E174F9E46039E10E2AA351EA834@XMB104ADS.rim.net> Date: Tue, 18 Sep 2012 23:03:00 -0500 Message-ID: From: Dean Willis To: John-Luc Bakker Content-Type: multipart/alternative; boundary=20cf3071ca702f1c4c04ca061536 X-Gm-Message-State: ALoCoQm8WAVZHuo6pFvJP279Ll5+8sePw5Sl2gIidmDglNDhY0WYzUKvZbAR0ZTOzgPG9eAEsM/H Cc: "dispatch@ietf.org" Subject: Re: [dispatch] New Version Notification for draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 04:03:03 -0000 --20cf3071ca702f1c4c04ca061536 Content-Type: text/plain; charset=ISO-8859-1 Well, that was silly of me. There was already one out there. On Tue, Sep 18, 2012 at 10:57 PM, Dean Willis wrote: > Be advised, there appears to be extant IPR covering this approach. I've > filed a 3rd party disclosure for the IETF process with respect to > publication *US20090119382. > > > * > > > On Tue, Sep 4, 2012 at 10:30 AM, John-Luc Bakker wrote: > >> Dear all, >> >> I have submitted a new version of the previous >> "draft-bakker-sipping-3gpp-ims-xml-body-handling", taking into account the >> various comments received. The most notable change is to submit the draft >> to DISPATCH (instead of SIPPING) and to submit the draft for standards >> track consideration. >> >> I welcome your comments. >> >> Kind regards, >> >> John-Luc >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Tuesday, September 04, 2012 10:26 AM >> To: John-Luc Bakker >> Subject: New Version Notification for >> draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt >> >> >> A new version of I-D, >> draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt >> has been successfully submitted by John-Luc Bakker and posted to the IETF >> repository. >> >> Filename: draft-bakker-dispatch-3gpp-ims-xml-body-handling >> Revision: 00 >> Title: Specification of 3GPP IM CN Subsystem XML body handling >> Creation date: 2012-09-04 >> WG ID: Individual Submission >> Number of pages: 8 >> URL: >> http://www.ietf.org/internet-drafts/draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt >> Status: >> http://datatracker.ietf.org/doc/draft-bakker-dispatch-3gpp-ims-xml-body-handling >> Htmlized: >> http://tools.ietf.org/html/draft-bakker-dispatch-3gpp-ims-xml-body-handling-00 >> >> >> Abstract: >> This document registers new disposition-types for the Content- >> Disposition header field that apply to the application/3gpp-ims+xml >> body (part) used by 3GPP [5]. The applicability of these content- >> disposition values are limited to 3GPP IMS [5]. The application/ >> 3gpp-ims+xml body (part) has the following three distinct uses: (1) >> for redirecting the emergency session to use a different domain (e.g. >> using a Circuit Switched call), (2) for delivering user profile >> specific information from the SIP registrar to an Application Server, >> and (3) for causing a UAC to attempt to re-register with the IMS. >> >> >> >> >> The IETF Secretariat >> >> >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential >> information, privileged material (including material protected by the >> solicitor-client or other applicable privileges), or constitute non-public >> information. Any use of this information by anyone other than the intended >> recipient is prohibited. If you have received this transmission in error, >> please immediately reply to the sender and delete this information from >> your system. Use, dissemination, distribution, or reproduction of this >> transmission by unintended recipients is not authorized and may be unlawful. >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > --20cf3071ca702f1c4c04ca061536 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Well, that was silly of me. There was already one out there.

On Tue, Sep 18, 2012 at 10:57 PM, Dean Willis <dean.willis@softarmor.com> wrote:
Be advised, there appears to be extant IPR c= overing this approach. I've filed a 3rd party disclosure for the IETF p= rocess with respect to publication US20090119382.




On Tue, Sep 4, 2012 at 10:30 AM, John-Luc Bakker <jbakker@rim.co= m> wrote:
Dear all,

I have submitted a new version of the previous "draft-bakker-sipping-3= gpp-ims-xml-body-handling", taking into account the various comments r= eceived. The most notable change is to submit the draft to DISPATCH (instea= d of SIPPING) and to submit the draft for standards track consideration.
I welcome your comments.

Kind regards,

=A0 =A0 =A0 =A0 John-Luc

-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Tuesday, September 04, 2012 10:26 AM
To: John-Luc Bakker
Subject: New Version Notification for draft-bakker-dispatch-3gpp-ims-xml-bo= dy-handling-00.txt


A new version of I-D, draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.t= xt
has been successfully submitted by John-Luc Bakker and posted to the IETF r= epository.

Filename: =A0 =A0 =A0 =A0draft-bakker-dispatch-3gpp-ims-xml-body-handling Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 Specification of 3GPP IM CN Subsystem XML body h= andling
Creation date: =A0 2012-09-04
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 8
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/internet-drafts/draft-bakker-dispatch-3gpp-ims-xml-bod= y-handling-00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datat= racker.ietf.org/doc/draft-bakker-dispatch-3gpp-ims-xml-body-handling Htmlized: =A0 =A0 =A0 =A0http://tools.iet= f.org/html/draft-bakker-dispatch-3gpp-ims-xml-body-handling-00


Abstract:
=A0 =A0This document registers new disposition-types for the Content-
=A0 =A0Disposition header field that apply to the application/3gpp-ims+xml<= br> =A0 =A0body (part) used by 3GPP [5]. =A0The applicability of these content-=
=A0 =A0disposition values are limited to 3GPP IMS [5]. =A0The application/<= br> =A0 =A03gpp-ims+xml body (part) has the following three distinct uses: (1)<= br> =A0 =A0for redirecting the emergency session to use a different domain (e.g= .
=A0 =A0using a Circuit Switched call), (2) for delivering user profile
=A0 =A0specific information from the SIP registrar to an Application Server= ,
=A0 =A0and (3) for causing a UAC to attempt to re-register with the IMS.



The IETF Secretariat


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful.
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


--20cf3071ca702f1c4c04ca061536-- From prvs=76156c6274=jbakker@rim.com Tue Sep 25 08:58:16 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A363B21F84CD for ; Tue, 25 Sep 2012 08:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.366 X-Spam-Level: X-Spam-Status: No, score=-6.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HL0YnfmO+8sb for ; Tue, 25 Sep 2012 08:58:16 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id E559121F84C5 for ; Tue, 25 Sep 2012 08:58:15 -0700 (PDT) X-AuditID: 0a412830-b7fab6d000006b80-ac-5061d4963f68 Received: from XCT103ADS.rim.net (xct103ads.rim.net [10.67.111.44]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id A2.01.27520.794D1605; Tue, 25 Sep 2012 15:58:15 +0000 (GMT) Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT103ADS.rim.net ([fe80::c8f6:ae2e:c42b:3614%21]) with mapi id 14.02.0318.001; Tue, 25 Sep 2012 10:58:14 -0500 From: John-Luc Bakker To: "dispatch@ietf.org" Thread-Topic: New Version Notification for draft-avasarala-dispatch-comm-div-notification-10.txt Thread-Index: AQHNmzZq7tn31PZq30ueHicfeePR2ZebNnRA Date: Tue, 25 Sep 2012 15:58:13 +0000 Message-ID: <155970D1DA8E174F9E46039E10E2AA35231658@XMB104ADS.rim.net> References: <20120925155703.6585.453.idtracker@ietfa.amsl.com> In-Reply-To: <20120925155703.6585.453.idtracker@ietfa.amsl.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.252] Content-Type: text/plain; charset="utf-8" content-transfer-encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJKsWRmVeSWpSXmKPExsXC5Zyvozv9SmKAQccdMYulkxawOjB6LFny kymAMaqB0SYpsaQsODM9T9/OJjEvL78ksSRVISW1ONlWySc1PTFHIaAosywxuVLBJbM4OScx Mze1SEkhM8VWyURJoSAnMTk1NzWvxFYpsaAgNS9FyY5LAQPYAJVl5imk5iXnp2TmpdsqeQb7 61pYmFrqGirZ6SZ08mTMu+VTMEGi4nD/W9YGxgPiXYwcHBICJhJvzgR1MXICmWISF+6tZ+ti 5OIQEuhlkmh6tIQJwtnMKPHjxwV2kCo2AXWJrSu2M4PYIgLaEkdXdTGDDBIWSJTY+CkKIpwk cfbNciYI20hi64y5YDaLgKrEsQ//GUFsXgE3icUHToONERKwk/i0o58dZAyngL3E58P6IGFG AVmJ3Wevg7UyC4hL3HoynwniTgGJJXvOM0PYohIvH/9jhbAVJR63dLOAjGEW0JRYv0sfolVR Ykr3Q3aIrYISJ2c+YZnAKDoLydRZCB2zkHTMQtKxgJFlFaNgbkaxgZlhcl6yXlFmrl5easkm RlDEO2oY7GB8/97iEKMAB6MSD2/jxcQAIdbEsuLK3EOMEhzMSiK8sseAQrwpiZVVqUX58UWl OanFhxgtgEEykVmKOzkfmIzySuKNDQxQOErivL/PAfUJpAMTS3ZqakFqEUwrEwcnyGguKZFi YHpILUosLcmIByWx+GJgGpNqYFSY4tM2+17krn+KoZ9v3Yl8FXfNqOcFy5UDMgknb568eue2 Ra2a7ekChvjvk/8uFDy893To5CaLHTqMx8JXbj2n0VBsoVXVx3jy/sytR1nmiHYwurwM/KNn +3rmh2NXXTYzXYz9+ZO13PHnx0s88SoFqlxnPrQ6L2mQmLPoavGjIyonmR4svMuhxFKckWio xVxUnAgA7fJhSywDAAA= Subject: [dispatch] FW: New Version Notification for draft-avasarala-dispatch-comm-div-notification-10.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 15:58:16 -0000 RGVhciBhbGwsDQoNClRoZSBhdXRob3JzIGNvbnRpbnVlIHRvIHdvcmsgb24gdGhlIGNvbW1l bnRzIHJlY2VpdmVkLiBUaGlzIHZlcnNpb24gY29udGFpbnMgbm8gY2hhbmdlcyBvZiBzdWJz dGFuY2UuIEFuIHVwZGF0ZSB3aWxsIGZvbGxvdywgYWRkcmVzc2luZyB0aGUgY29tbWVudHMg cmVjZWl2ZWQuDQoNCktpbmQgcmVnYXJkcywNCg0KCUpMDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDI1LCAy MDEyIDEwOjU3IEFNDQpUbzogSm9obi1MdWMgQmFra2VyDQpDYzogcmFuaml0LmF2YXNhcmFs YUBwb2x5Y29tLmNvbQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1hdmFzYXJhbGEtZGlzcGF0Y2gtY29tbS1kaXYtbm90aWZpY2F0aW9uLTEwLnR4dA0K DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1hdmFzYXJhbGEtZGlzcGF0Y2gtY29t bS1kaXYtbm90aWZpY2F0aW9uLTEwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1p dHRlZCBieSBKb2huIEx1YyBCYWtrZXIgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0 b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LWF2YXNhcmFsYS1kaXNwYXRjaC1jb21tLWRpdi1u b3RpZmljYXRpb24NClJldmlzaW9uOgkgMTANClRpdGxlOgkJIEEgU2Vzc2lvbiBJbml0aWF0 aW9uIFByb3RvY29sIChTSVApIEV2ZW50IFBhY2thZ2UgZm9yIENvbW11bmljYXRpb24gRGl2 ZXJzaW9uIEluZm9ybWF0aW9uIGluIHN1cHBvcnQgb2YgdGhlIENvbW11bmljYXRpb24gRGl2 ZXJzaW9uIChDRElWKSBOb3RpZmljYXRpb24gKENESVZOKSBDRElWIHNlcnZpY2UNCkNyZWF0 aW9uIGRhdGU6CSAyMDEyLTA5LTI1DQpXRyBJRDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24N Ck51bWJlciBvZiBwYWdlczogMjkNClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYXZhc2FyYWxhLWRpc3BhdGNoLWNvbW0tZGl2 LW5vdGlmaWNhdGlvbi0xMC50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1hdmFzYXJhbGEtZGlzcGF0Y2gtY29tbS1kaXYtbm90 aWZpY2F0aW9uDQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWF2YXNhcmFsYS1kaXNwYXRjaC1jb21tLWRpdi1ub3RpZmljYXRpb24tMTANCkRp ZmY6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt YXZhc2FyYWxhLWRpc3BhdGNoLWNvbW0tZGl2LW5vdGlmaWNhdGlvbi0xMA0KDQpBYnN0cmFj dDoNCiAgIDNHUFAgYW5kIFRJU1BBTiBhcmUgZGVmaW5pbmcgdGhlIHByb3RvY29sIHNwZWNp ZmljYXRpb24gZm9yIHRoZQ0KICAgQ29tbXVuaWNhdGlvbiBEaXZlcnNpb24gKENESVYpIHNl cnZpY2UgdXNpbmcgSVAgTXVsdGltZWRpYSAoSU0pIENvcmUNCiAgIE5ldHdvcmsgKENOKSBz dWJzeXN0ZW0gc3VwcGxlbWVudGFyeSBzZXJ2aWNlLiAgQXMgcGFydCBvZiBDRElWLCBhIFNJ UA0KICAgYmFzZWQgRXZlbnQgcGFja2FnZSBmcmFtZXdvcmsgaXMgdXNlZCBmb3Igbm90aWZ5 aW5nIHVzZXJzIGFib3V0DQogICBkaXZlcnNpb25zIChyZS1kaXJlY3Rpb25zIG9yIGZvcndh cmRpbmcpIG9mIHRoZWlyIGluY29taW5nDQogICBjb21tdW5pY2F0aW9uIHNlc3Npb25zLiAg VGhpcyBkb2N1bWVudCBwcm9wb3NlcyBhIG5ldyBTSVAgZXZlbnQNCiAgIHBhY2thZ2UgZm9y IGFsbG93aW5nIHVzZXJzIHRvIHN1YnNjcmliZSB0byBhbmQgcmVjZWl2ZSBzdWNoDQogICBu b3RpZmljYXRpb25zLiAgVXNlcnMgY2FuIGZ1cnRoZXIgZGVmaW5lIGZpbHRlcnMgdG8gY29u dHJvbCB0aGUgcmF0ZQ0KICAgYW5kIGNvbnRlbnQgb2Ygc3VjaCBub3RpZmljYXRpb25zLiAg VGhlIHByb3Bvc2VkIGV2ZW50IHBhY2thZ2UgaXMNCiAgIGFwcGxpY2FibGUgdG8gdGhlIENE SVYgc3VwcGxlbWVudGFyeSBzZXJ2aWNlIGluIElNUyBhbmQgbWF5IG5vdCBiZQ0KICAgYXBw bGljYWJsZSB0byB0aGUgZ2VuZXJhbCBpbnRlcm5ldC4gLg0KDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NClRoaXMgdHJhbnNtaXNzaW9uIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBt YXkgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24sIHByaXZpbGVnZWQgbWF0ZXJp YWwgKGluY2x1ZGluZyBtYXRlcmlhbCBwcm90ZWN0ZWQgYnkgdGhlIHNvbGljaXRvci1jbGll bnQgb3Igb3RoZXIgYXBwbGljYWJsZSBwcml2aWxlZ2VzKSwgb3IgY29uc3RpdHV0ZSBub24t cHVibGljIGluZm9ybWF0aW9uLiBBbnkgdXNlIG9mIHRoaXMgaW5mb3JtYXRpb24gYnkgYW55 b25lIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJpdGVkLiBJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNl IGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIGluZm9y bWF0aW9uIGZyb20geW91ciBzeXN0ZW0uIFVzZSwgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0 aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyB0cmFuc21pc3Npb24gYnkgdW5pbnRlbmRl ZCByZWNpcGllbnRzIGlzIG5vdCBhdXRob3JpemVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuDQo= From gonzalo.camarillo@ericsson.com Wed Sep 26 04:16:15 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E56921F8698 for ; Wed, 26 Sep 2012 04:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.218 X-Spam-Level: X-Spam-Status: No, score=-106.218 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3ZI+S0lIDNu for ; Wed, 26 Sep 2012 04:16:14 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0939621F87BC for ; Wed, 26 Sep 2012 04:16:13 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-b9-5062e3fc52d2 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 3B.D5.17130.CF3E2605; Wed, 26 Sep 2012 13:16:13 +0200 (CEST) Received: from [131.160.36.30] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.264.1; Wed, 26 Sep 2012 13:16:12 +0200 Message-ID: <5062E3FC.4080009@ericsson.com> Date: Wed, 26 Sep 2012 14:16:12 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: John-Luc Bakker References: <20120904152546.18420.91591.idtracker@ietfa.amsl.com> <155970D1DA8E174F9E46039E10E2AA351EA834@XMB104ADS.rim.net> In-Reply-To: <155970D1DA8E174F9E46039E10E2AA351EA834@XMB104ADS.rim.net> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUyM+Jvre7fx0kBBm3HWS2WTlrAavHnYCuL A5PHkiU/mTwmfFnJEsAUxWWTkpqTWZZapG+XwJXRvuEIc8EqpYr7Tz8zNjBule5i5OSQEDCR WLT4GROELSZx4d56ti5GLg4hgVOMEjt+P2MESQgJrGaUaD/m0sXIwcEroC3xY6ELSJhFQFVi 1p5nzCA2m4CFxJZb91lAbFGBYIlzG7exgdi8AoISJ2c+AYuLANU/XHoMbCQz0Jj/19eB2cIC ORK9k68wQayqkfj4pBlsJqeAu8SbNfuZIW6TlHgz+SYLRK+exJSrLVBz5CW2v53DDNGrLbH8 WQvLBEahWUhWz0LSMgtJywJG5lWMwrmJmTnp5eZ6qUWZycXF+Xl6xambGIEBfHDLb4MdjJvu ix1ilOZgURLn1VPd7y8kkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBUb2Kvf6Qlcm6I6pxpbF3 7Hum9S5P5S512bPvnF7I+x0s79i9Jis4+j5ZfNQ2TWbPlR7leoZ71n4LZtYFLY+P3B75bdcy EQ62ru4jqYG3p0rEvHtbd0jjz8Ypj1bkf31tk25w+6HGyp0T5m+5cHq7/p/Tx4443F0QNvfV 1GlG5/d4ntETWzm1UVeJpTgj0VCLuag4EQBEVjijLgIAAA== Cc: "dispatch@ietf.org" Subject: Re: [dispatch] New Version Notification for draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 11:16:15 -0000 Hi John Luc, I have a quick question about this draft. The Abstract identifies three uses for 3gpp-ims+xml bodies: > (1) > for redirecting the emergency session to use a different domain (e.g. > using a Circuit Switched call), (2) for delivering user profile > specific information from the SIP registrar to an Application Server, > and (3) for causing a UAC to attempt to re-register with the IMS. Later, the draft defines two disposition types: > o 3gpp-alternative-service: the body (part) contains 3GPP IM CN > subsystem XML with the 'alternative-service' XML element as > described in Section 4.2; and > > o 3gpp-service-info: the body (part) contains 3GPP IM CN subsystem > XML with the 'service-info' XML element as described in Section > 4.3. I assume "3gpp-alternative-service" covers uses (1) and (3) and "3gpp-service-info" covers use (2). Is this assumption correct? (In any case, the draft could be clearer on that point.) After reading the draft, it seems to me that "3gpp-ims+xml" bodies with disposition type "3gpp-alternative-service" will always be carried in SIP responses while "3gpp-ims+xml" bodies with disposition type "3gpp-service-info" will always be carried in SIP requests. Is my understanding correct? Thanks, Gonzalo On 04/09/2012 6:30 PM, John-Luc Bakker wrote: > Dear all, > > I have submitted a new version of the previous "draft-bakker-sipping-3gpp-ims-xml-body-handling", taking into account the various comments received. The most notable change is to submit the draft to DISPATCH (instead of SIPPING) and to submit the draft for standards track consideration. > > I welcome your comments. > > Kind regards, > > John-Luc > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Tuesday, September 04, 2012 10:26 AM > To: John-Luc Bakker > Subject: New Version Notification for draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt > > > A new version of I-D, draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt > has been successfully submitted by John-Luc Bakker and posted to the IETF repository. > > Filename: draft-bakker-dispatch-3gpp-ims-xml-body-handling > Revision: 00 > Title: Specification of 3GPP IM CN Subsystem XML body handling > Creation date: 2012-09-04 > WG ID: Individual Submission > Number of pages: 8 > URL: http://www.ietf.org/internet-drafts/draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt > Status: http://datatracker.ietf.org/doc/draft-bakker-dispatch-3gpp-ims-xml-body-handling > Htmlized: http://tools.ietf.org/html/draft-bakker-dispatch-3gpp-ims-xml-body-handling-00 > > > Abstract: > This document registers new disposition-types for the Content- > Disposition header field that apply to the application/3gpp-ims+xml > body (part) used by 3GPP [5]. The applicability of these content- > disposition values are limited to 3GPP IMS [5]. The application/ > 3gpp-ims+xml body (part) has the following three distinct uses: (1) > for redirecting the emergency session to use a different domain (e.g. > using a Circuit Switched call), (2) for delivering user profile > specific information from the SIP registrar to an Application Server, > and (3) for causing a UAC to attempt to re-register with the IMS. > > > > > The IETF Secretariat > > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From dhanes@cisco.com Wed Sep 26 08:33:31 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93C4D21F8444 for ; Wed, 26 Sep 2012 08:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BATVMEZinhmY for ; Wed, 26 Sep 2012 08:33:30 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id A564121F8441 for ; Wed, 26 Sep 2012 08:33:30 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8QFXRSF021360; Wed, 26 Sep 2012 11:33:27 -0400 (EDT) Received: from rtp-dhanes-8911.cisco.com (rtp-dhanes-8911.cisco.com [10.117.39.194]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8QFXRFB015037; Wed, 26 Sep 2012 11:33:27 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: David Hanes In-Reply-To: <201209111858.q8BIwvvW006046@freeze.ariadne.com> Date: Wed, 26 Sep 2012 11:33:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201209111858.q8BIwvvW006046@freeze.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.1084) Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-hanes-dispatch-fax-capability-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 15:33:31 -0000 How about the following descriptions for T.38 and passthrough in the = IANA Considerations section? t38: The device supports the image/t38 media type [RFC 3326] and = implements ITU-T T.38 for transporting the ITU-T T.30 and T.4 fax data = over IP.=20 passthrough: The device supports the audio/pcmu and audio/pcma media = types [RFC4856] for transporting ITU-T T.30 and T.4 fax data using the = ITU-T G.711 codec. Additional implementation recommendations are in = ITU-T V.152 Sections 6 and 6.1. Thanks, David On Sep 11, 2012, at 2:58 PM, Dale R. Worley wrote: >> From: David Hanes >>>=20 >>> The "t38" value is better described as "supports the image/t38 media >>> type[RFC3362] which encodes page images using the ITU-T T.38 fax >>> protocol[T.38]". That specifies the media type and adds a reference >>> to the RFC, which includes more details of the specific ITU >>> recommendations involved. There are probably some implications of >>> what values of the T.38 SDP attributes are supported -- is there a >>> default set of attributes which constitute a baseline version of >>> image/t38? >=20 > (I can't remember if in the past I mistakenly considered the fax media > type to be application/t38 (which was proposed in > ietf-mmusic-sdp-t38-00), but the fact that the fax media type is > image/t38 makes it impossible to use the +sip.app-subtype media > feature tag to select fax-capable UAs.) >=20 >> I like the image/t38 media and RFC specifics that you added above and >> I will include these updates in the next version. >=20 > Ideally, we should point to all the standards needed to define the > feature (although in practice, in many respects there is only one > practical way to implement this, so we could force people to figure > things out for themselves). >=20 >> You also mention specific T.38 attributes. I am not aware of a = default >> set of attribute values. It seems that each vendor has certain >> defaults but it is probably safe to say that many are commonly set = the >> same. Thinking this through though, it seems like the goal of this >> feature tag is to signal the preference that the call lands at a fax >> capable, or more specifically in this case, a T.38 capable UA. Once >> the T.38 capable UAs are connected, shouldn't they handle the T.38 >> attribute exchange/negotiation within SDP? This is how it works >> now. It seems that just specifying T.38 would be enough in this case >> and then the UAs can deal with the T.38 attribute settings within = SDP. >=20 > Yes, I agree. >=20 > I wanted to ensure that +sip.fax would require a sufficient set of > image/t38 features (expressed as T38* attributes) that any two UAs > that met the specification would be able to communicate (at least with > a "baseline" capability). Otherwise there could be multiple, > incompatible groups of "sip.fax" UAs. That would indicate that the > sip.fax values should be finer-grained than simply "t38". >=20 > But looking at the T.38 spec, annexes D and H, it appears to me that > T.38 is designed for maximum negotiation and compatibility, and so > there should be little risk of incompatibility if we do not place any > requirements on the T38* attribute values that are supported. >=20 >>> The definition of "passthrough" is incomplete as it stands. The >>> meaning is "supports the audio/pcmu and audio/pcma media >>> types[RFC4856] for the transmission of fax images encoded (somehow) = as >>> an analog audio stream, which is in turn encoded using G.711". But >>> what is the description of "somehow" and the proper reference for = it? >>=20 >> The "somehow" here is defined by ITU-T T.30, T.4, and T.6 and these >> are modulated using common schemes like V.21 and V.17 so that the fax >> communication is now an analog stream. I am not sure that we need = this >> level of detail though. This audio stream generation happens with >> every fax machine and gateway. Passthrough is very simple. We are = just >> replacing human speech over G.711 with an analog fax stream. G.711 = has >> been used on the PSTN for decades on T1/E1 spans for handling voice >> and fax. Basically, when we use the term passthrough, we are saying >> treat fax like a G.711 voice call. With that being said, wouldn't = just >> referencing G.711 be enough from a media feature tag and user >> preference perspective? >>=20 >>> I don't know fax technologies well enough to know what it is, though >>> I'm certain that there is a specific standard intended here. >=20 > As I see it, there is a series of decoding steps: >=20 > - from the incoming RTP packets, the stream of PCM octets is extracted > based on the RTP standards >=20 > - from the PCM octets, an analog signal is constructed via G.711 (PCMA > or PCMU) >=20 > - from the analog signal, a bit stream is constructed via = V.21/V.17/V.* >=20 > - from the bit stream, a fax image is constructed via T.30/T.4/T.6 >=20 > and encoding is done in the reverse order. >=20 > So to specify how meaning is encoded in the packets, you need to > specify that entire stack of standards. Or, to ensure > interoperability, you have to require implementation of a minimal > subset of all those choices. >=20 > The reality is a bit messier, I think, because machines probably > negotiate which "modem" protocol they use (V.21, etc.), and they may > negotiate which fax encoding they use. >=20 > But since fax machines work in practice, there is a standard (or a > ubiquitous de-facto standard) that specifies the two higher levels of > the encoding stack. >=20 > So I think it is necessary to provide specification of the two higher > levels, the "modem" encoding and the page encoding. But I strongly > suspect that there are standards or well-understood BCPs that can be > referenced -- without excluding any practical implementation from > being in conformance with "sip.fax". >=20 >>> Do we want to require PCMU and PCMA support, or PCMU *or* PCMA >>> support? >>=20 >> As with the T.38 SDP attributes, is this something that we want to >> address in this draft or just leave it to the SDP portion? With only = 2 >> codec options, you could have "passthrough-g711=CE=BC" and >> "passthrough-g711a" values. However, in reality most folks >> implementing passthrough will accept either G.711 variety. >=20 > As I said above, I want to ensure that if a call that specifies > "sip.fax" arrives at a UA that registers with "sip.fax", then the fax > call will succeed in practice. Otherwise, defining sip.fax hasn't > gained what we want. >=20 > But given that every SIP G.711 implementation I've ever seen supports > both PCMU and PCMA, I would suggest that we require *both* as part of > the definition. With that, the definition ensures interoperability, > but it does not (in practice) further constrain any implementation. >=20 >>> What encoding parameter values are required for support? I expect = we >>> want to add that the audio stream is single-channel and we probably >>> want to specify that it is at 8000Hz sample rate. >=20 > Or perhaps those parameters are effectively fixed by T.4/T.6/T.30 > (regarding channels) and G.711 (for the bitrate). >=20 >>> Also, the reference to the T.38 spec is given as informative, = whereas >>> it is used normatively. >>=20 >> Thanks. I will get that fixed in the next version.=20 >=20 > Dale From pkyzivat@alum.mit.edu Wed Sep 26 09:05:54 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1FAB21F85AF for ; Wed, 26 Sep 2012 09:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_33=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1HCRmsyW0IF for ; Wed, 26 Sep 2012 09:05:54 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id BBFBB21F84DC for ; Wed, 26 Sep 2012 09:05:53 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta03.westchester.pa.mail.comcast.net with comcast id 3mAQ1k0070xGWP853s5x4n; Wed, 26 Sep 2012 16:05:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id 3s051k0083ZTu2S3Ys05nH; Wed, 26 Sep 2012 16:00:05 +0000 Message-ID: <506326B5.7090009@alum.mit.edu> Date: Wed, 26 Sep 2012 12:00:53 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: David Hanes References: <201209111858.q8BIwvvW006046@freeze.ariadne.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "Dale R. Worley" , dispatch@ietf.org Subject: Re: [dispatch] draft-hanes-dispatch-fax-capability-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 16:05:54 -0000 This sounds pretty reasonable to me. Thanks, Paul On 9/26/12 11:33 AM, David Hanes wrote: > How about the following descriptions for T.38 and passthrough in the IANA Considerations section? > > t38: The device supports the image/t38 media type [RFC 3326] and implements ITU-T T.38 for transporting the ITU-T T.30 and T.4 fax data over IP. > > passthrough: The device supports the audio/pcmu and audio/pcma media types [RFC4856] for transporting ITU-T T.30 and T.4 fax data using the ITU-T G.711 codec. Additional implementation recommendations are in ITU-T V.152 Sections 6 and 6.1. > > Thanks, > David > > > > > > > On Sep 11, 2012, at 2:58 PM, Dale R. Worley wrote: > >>> From: David Hanes >>>> >>>> The "t38" value is better described as "supports the image/t38 media >>>> type[RFC3362] which encodes page images using the ITU-T T.38 fax >>>> protocol[T.38]". That specifies the media type and adds a reference >>>> to the RFC, which includes more details of the specific ITU >>>> recommendations involved. There are probably some implications of >>>> what values of the T.38 SDP attributes are supported -- is there a >>>> default set of attributes which constitute a baseline version of >>>> image/t38? >> >> (I can't remember if in the past I mistakenly considered the fax media >> type to be application/t38 (which was proposed in >> ietf-mmusic-sdp-t38-00), but the fact that the fax media type is >> image/t38 makes it impossible to use the +sip.app-subtype media >> feature tag to select fax-capable UAs.) >> >>> I like the image/t38 media and RFC specifics that you added above and >>> I will include these updates in the next version. >> >> Ideally, we should point to all the standards needed to define the >> feature (although in practice, in many respects there is only one >> practical way to implement this, so we could force people to figure >> things out for themselves). >> >>> You also mention specific T.38 attributes. I am not aware of a default >>> set of attribute values. It seems that each vendor has certain >>> defaults but it is probably safe to say that many are commonly set the >>> same. Thinking this through though, it seems like the goal of this >>> feature tag is to signal the preference that the call lands at a fax >>> capable, or more specifically in this case, a T.38 capable UA. Once >>> the T.38 capable UAs are connected, shouldn't they handle the T.38 >>> attribute exchange/negotiation within SDP? This is how it works >>> now. It seems that just specifying T.38 would be enough in this case >>> and then the UAs can deal with the T.38 attribute settings within SDP. >> >> Yes, I agree. >> >> I wanted to ensure that +sip.fax would require a sufficient set of >> image/t38 features (expressed as T38* attributes) that any two UAs >> that met the specification would be able to communicate (at least with >> a "baseline" capability). Otherwise there could be multiple, >> incompatible groups of "sip.fax" UAs. That would indicate that the >> sip.fax values should be finer-grained than simply "t38". >> >> But looking at the T.38 spec, annexes D and H, it appears to me that >> T.38 is designed for maximum negotiation and compatibility, and so >> there should be little risk of incompatibility if we do not place any >> requirements on the T38* attribute values that are supported. >> >>>> The definition of "passthrough" is incomplete as it stands. The >>>> meaning is "supports the audio/pcmu and audio/pcma media >>>> types[RFC4856] for the transmission of fax images encoded (somehow) as >>>> an analog audio stream, which is in turn encoded using G.711". But >>>> what is the description of "somehow" and the proper reference for it? >>> >>> The "somehow" here is defined by ITU-T T.30, T.4, and T.6 and these >>> are modulated using common schemes like V.21 and V.17 so that the fax >>> communication is now an analog stream. I am not sure that we need this >>> level of detail though. This audio stream generation happens with >>> every fax machine and gateway. Passthrough is very simple. We are just >>> replacing human speech over G.711 with an analog fax stream. G.711 has >>> been used on the PSTN for decades on T1/E1 spans for handling voice >>> and fax. Basically, when we use the term passthrough, we are saying >>> treat fax like a G.711 voice call. With that being said, wouldn't just >>> referencing G.711 be enough from a media feature tag and user >>> preference perspective? >>> >>>> I don't know fax technologies well enough to know what it is, though >>>> I'm certain that there is a specific standard intended here. >> >> As I see it, there is a series of decoding steps: >> >> - from the incoming RTP packets, the stream of PCM octets is extracted >> based on the RTP standards >> >> - from the PCM octets, an analog signal is constructed via G.711 (PCMA >> or PCMU) >> >> - from the analog signal, a bit stream is constructed via V.21/V.17/V.* >> >> - from the bit stream, a fax image is constructed via T.30/T.4/T.6 >> >> and encoding is done in the reverse order. >> >> So to specify how meaning is encoded in the packets, you need to >> specify that entire stack of standards. Or, to ensure >> interoperability, you have to require implementation of a minimal >> subset of all those choices. >> >> The reality is a bit messier, I think, because machines probably >> negotiate which "modem" protocol they use (V.21, etc.), and they may >> negotiate which fax encoding they use. >> >> But since fax machines work in practice, there is a standard (or a >> ubiquitous de-facto standard) that specifies the two higher levels of >> the encoding stack. >> >> So I think it is necessary to provide specification of the two higher >> levels, the "modem" encoding and the page encoding. But I strongly >> suspect that there are standards or well-understood BCPs that can be >> referenced -- without excluding any practical implementation from >> being in conformance with "sip.fax". >> >>>> Do we want to require PCMU and PCMA support, or PCMU *or* PCMA >>>> support? >>> >>> As with the T.38 SDP attributes, is this something that we want to >>> address in this draft or just leave it to the SDP portion? With only 2 >>> codec options, you could have "passthrough-g711μ" and >>> "passthrough-g711a" values. However, in reality most folks >>> implementing passthrough will accept either G.711 variety. >> >> As I said above, I want to ensure that if a call that specifies >> "sip.fax" arrives at a UA that registers with "sip.fax", then the fax >> call will succeed in practice. Otherwise, defining sip.fax hasn't >> gained what we want. >> >> But given that every SIP G.711 implementation I've ever seen supports >> both PCMU and PCMA, I would suggest that we require *both* as part of >> the definition. With that, the definition ensures interoperability, >> but it does not (in practice) further constrain any implementation. >> >>>> What encoding parameter values are required for support? I expect we >>>> want to add that the audio stream is single-channel and we probably >>>> want to specify that it is at 8000Hz sample rate. >> >> Or perhaps those parameters are effectively fixed by T.4/T.6/T.30 >> (regarding channels) and G.711 (for the bitrate). >> >>>> Also, the reference to the T.38 spec is given as informative, whereas >>>> it is used normatively. >>> >>> Thanks. I will get that fixed in the next version. >> >> Dale > > From gsalguei@cisco.com Wed Sep 26 09:30:43 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B010821F852C for ; Wed, 26 Sep 2012 09:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deDu7KkYqml5 for ; Wed, 26 Sep 2012 09:30:42 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id A5BAC21F852A for ; Wed, 26 Sep 2012 09:30:42 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8QGUdTC027709 for ; Wed, 26 Sep 2012 12:30:39 -0400 (EDT) Received: from dhcp-64-102-154-202.cisco.com (dhcp-64-102-154-202.cisco.com [64.102.154.202]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8QGLpxr021179; Wed, 26 Sep 2012 12:21:51 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=utf-8 From: Gonzalo Salgueiro In-Reply-To: <506326B5.7090009@alum.mit.edu> Date: Wed, 26 Sep 2012 12:21:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <48CAA1D0-A0DE-4D1E-816E-6BB22902B4AD@cisco.com> References: <201209111858.q8BIwvvW006046@freeze.ariadne.com> <506326B5.7090009@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1283) Cc: "Dale R. Worley" , DISPATCH Subject: Re: [dispatch] draft-hanes-dispatch-fax-capability-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 16:30:43 -0000 +1=20 Gonzalo On Sep 26, 2012, at 12:00 PM, Paul Kyzivat wrote: > This sounds pretty reasonable to me. >=20 > Thanks, > Paul >=20 > On 9/26/12 11:33 AM, David Hanes wrote: >> How about the following descriptions for T.38 and passthrough in the = IANA Considerations section? >>=20 >> t38: The device supports the image/t38 media type [RFC 3326] and = implements ITU-T T.38 for transporting the ITU-T T.30 and T.4 fax data = over IP. >>=20 >> passthrough: The device supports the audio/pcmu and audio/pcma media = types [RFC4856] for transporting ITU-T T.30 and T.4 fax data using the = ITU-T G.711 codec. Additional implementation recommendations are in = ITU-T V.152 Sections 6 and 6.1. >>=20 >> Thanks, >> David >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On Sep 11, 2012, at 2:58 PM, Dale R. Worley wrote: >>=20 >>>> From: David Hanes >>>>>=20 >>>>> The "t38" value is better described as "supports the image/t38 = media >>>>> type[RFC3362] which encodes page images using the ITU-T T.38 fax >>>>> protocol[T.38]". That specifies the media type and adds a = reference >>>>> to the RFC, which includes more details of the specific ITU >>>>> recommendations involved. There are probably some implications of >>>>> what values of the T.38 SDP attributes are supported -- is there a >>>>> default set of attributes which constitute a baseline version of >>>>> image/t38? >>>=20 >>> (I can't remember if in the past I mistakenly considered the fax = media >>> type to be application/t38 (which was proposed in >>> ietf-mmusic-sdp-t38-00), but the fact that the fax media type is >>> image/t38 makes it impossible to use the +sip.app-subtype media >>> feature tag to select fax-capable UAs.) >>>=20 >>>> I like the image/t38 media and RFC specifics that you added above = and >>>> I will include these updates in the next version. >>>=20 >>> Ideally, we should point to all the standards needed to define the >>> feature (although in practice, in many respects there is only one >>> practical way to implement this, so we could force people to figure >>> things out for themselves). >>>=20 >>>> You also mention specific T.38 attributes. I am not aware of a = default >>>> set of attribute values. It seems that each vendor has certain >>>> defaults but it is probably safe to say that many are commonly set = the >>>> same. Thinking this through though, it seems like the goal of this >>>> feature tag is to signal the preference that the call lands at a = fax >>>> capable, or more specifically in this case, a T.38 capable UA. Once >>>> the T.38 capable UAs are connected, shouldn't they handle the T.38 >>>> attribute exchange/negotiation within SDP? This is how it works >>>> now. It seems that just specifying T.38 would be enough in this = case >>>> and then the UAs can deal with the T.38 attribute settings within = SDP. >>>=20 >>> Yes, I agree. >>>=20 >>> I wanted to ensure that +sip.fax would require a sufficient set of >>> image/t38 features (expressed as T38* attributes) that any two UAs >>> that met the specification would be able to communicate (at least = with >>> a "baseline" capability). Otherwise there could be multiple, >>> incompatible groups of "sip.fax" UAs. That would indicate that the >>> sip.fax values should be finer-grained than simply "t38". >>>=20 >>> But looking at the T.38 spec, annexes D and H, it appears to me that >>> T.38 is designed for maximum negotiation and compatibility, and so >>> there should be little risk of incompatibility if we do not place = any >>> requirements on the T38* attribute values that are supported. >>>=20 >>>>> The definition of "passthrough" is incomplete as it stands. The >>>>> meaning is "supports the audio/pcmu and audio/pcma media >>>>> types[RFC4856] for the transmission of fax images encoded = (somehow) as >>>>> an analog audio stream, which is in turn encoded using G.711". = But >>>>> what is the description of "somehow" and the proper reference for = it? >>>>=20 >>>> The "somehow" here is defined by ITU-T T.30, T.4, and T.6 and these >>>> are modulated using common schemes like V.21 and V.17 so that the = fax >>>> communication is now an analog stream. I am not sure that we need = this >>>> level of detail though. This audio stream generation happens with >>>> every fax machine and gateway. Passthrough is very simple. We are = just >>>> replacing human speech over G.711 with an analog fax stream. G.711 = has >>>> been used on the PSTN for decades on T1/E1 spans for handling voice >>>> and fax. Basically, when we use the term passthrough, we are saying >>>> treat fax like a G.711 voice call. With that being said, wouldn't = just >>>> referencing G.711 be enough from a media feature tag and user >>>> preference perspective? >>>>=20 >>>>> I don't know fax technologies well enough to know what it is, = though >>>>> I'm certain that there is a specific standard intended here. >>>=20 >>> As I see it, there is a series of decoding steps: >>>=20 >>> - from the incoming RTP packets, the stream of PCM octets is = extracted >>> based on the RTP standards >>>=20 >>> - from the PCM octets, an analog signal is constructed via G.711 = (PCMA >>> or PCMU) >>>=20 >>> - from the analog signal, a bit stream is constructed via = V.21/V.17/V.* >>>=20 >>> - from the bit stream, a fax image is constructed via T.30/T.4/T.6 >>>=20 >>> and encoding is done in the reverse order. >>>=20 >>> So to specify how meaning is encoded in the packets, you need to >>> specify that entire stack of standards. Or, to ensure >>> interoperability, you have to require implementation of a minimal >>> subset of all those choices. >>>=20 >>> The reality is a bit messier, I think, because machines probably >>> negotiate which "modem" protocol they use (V.21, etc.), and they may >>> negotiate which fax encoding they use. >>>=20 >>> But since fax machines work in practice, there is a standard (or a >>> ubiquitous de-facto standard) that specifies the two higher levels = of >>> the encoding stack. >>>=20 >>> So I think it is necessary to provide specification of the two = higher >>> levels, the "modem" encoding and the page encoding. But I strongly >>> suspect that there are standards or well-understood BCPs that can be >>> referenced -- without excluding any practical implementation from >>> being in conformance with "sip.fax". >>>=20 >>>>> Do we want to require PCMU and PCMA support, or PCMU *or* PCMA >>>>> support? >>>>=20 >>>> As with the T.38 SDP attributes, is this something that we want to >>>> address in this draft or just leave it to the SDP portion? With = only 2 >>>> codec options, you could have "passthrough-g711=CE=BC" and >>>> "passthrough-g711a" values. However, in reality most folks >>>> implementing passthrough will accept either G.711 variety. >>>=20 >>> As I said above, I want to ensure that if a call that specifies >>> "sip.fax" arrives at a UA that registers with "sip.fax", then the = fax >>> call will succeed in practice. Otherwise, defining sip.fax hasn't >>> gained what we want. >>>=20 >>> But given that every SIP G.711 implementation I've ever seen = supports >>> both PCMU and PCMA, I would suggest that we require *both* as part = of >>> the definition. With that, the definition ensures interoperability, >>> but it does not (in practice) further constrain any implementation. >>>=20 >>>>> What encoding parameter values are required for support? I expect = we >>>>> want to add that the audio stream is single-channel and we = probably >>>>> want to specify that it is at 8000Hz sample rate. >>>=20 >>> Or perhaps those parameters are effectively fixed by T.4/T.6/T.30 >>> (regarding channels) and G.711 (for the bitrate). >>>=20 >>>>> Also, the reference to the T.38 spec is given as informative, = whereas >>>>> it is used normatively. >>>>=20 >>>> Thanks. I will get that fixed in the next version. >>>=20 >>> Dale >>=20 >>=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From James.Rafferty@dialogic.com Wed Sep 26 10:55:40 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4FD521F8588 for ; Wed, 26 Sep 2012 10:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mS90ThUUyQXD for ; Wed, 26 Sep 2012 10:55:40 -0700 (PDT) Received: from outbound.dialogic.com (outbound.dialogic.com [173.210.122.27]) by ietfa.amsl.com (Postfix) with ESMTP id A141A21F858F for ; Wed, 26 Sep 2012 10:55:39 -0700 (PDT) Received: from MBX.dialogic.com ([fe80::d09:39e:8fa1:c2a3]) by pysxht01.dialogic.com ([::1]) with mapi; Wed, 26 Sep 2012 13:55:40 -0400 From: James Rafferty To: Gonzalo Salgueiro , Paul Kyzivat Date: Wed, 26 Sep 2012 13:55:39 -0400 Thread-Topic: [dispatch] draft-hanes-dispatch-fax-capability-02 Thread-Index: Ac2cBEnwkG/LldhgR1Shtyk9b0BT6gAC9BTQ Message-ID: <54633A5E61DC84429CB9FE3D9143C72118008EA7@MBX.dialogic.com> References: <201209111858.q8BIwvvW006046@freeze.ariadne.com> <506326B5.7090009@alum.mit.edu> <48CAA1D0-A0DE-4D1E-816E-6BB22902B4AD@cisco.com> In-Reply-To: <48CAA1D0-A0DE-4D1E-816E-6BB22902B4AD@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "Dale R. Worley" , DISPATCH Subject: Re: [dispatch] draft-hanes-dispatch-fax-capability-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 17:55:40 -0000 KzENCg0KSmFtZXMNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGRpc3BhdGNo LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgR29uemFsbyBTYWxndWVpcm8NClNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDI2 LCAyMDEyIDEyOjIyIFBNDQpUbzogUGF1bCBLeXppdmF0DQpDYzogRGFsZSBSLiBXb3JsZXk7IERJ U1BBVENIDQpTdWJqZWN0OiBSZTogW2Rpc3BhdGNoXSBkcmFmdC1oYW5lcy1kaXNwYXRjaC1mYXgt Y2FwYWJpbGl0eS0wMg0KDQorMQ0KDQpHb256YWxvDQoNCk9uIFNlcCAyNiwgMjAxMiwgYXQgMTI6 MDAgUE0sIFBhdWwgS3l6aXZhdCB3cm90ZToNCg0KPiBUaGlzIHNvdW5kcyBwcmV0dHkgcmVhc29u YWJsZSB0byBtZS4NCj4gDQo+IAlUaGFua3MsDQo+IAlQYXVsDQo+IA0KPiBPbiA5LzI2LzEyIDEx OjMzIEFNLCBEYXZpZCBIYW5lcyB3cm90ZToNCj4+IEhvdyBhYm91dCB0aGUgZm9sbG93aW5nIGRl c2NyaXB0aW9ucyBmb3IgVC4zOCBhbmQgcGFzc3Rocm91Z2ggaW4gdGhlIElBTkEgQ29uc2lkZXJh dGlvbnMgc2VjdGlvbj8NCj4+IA0KPj4gdDM4OglUaGUgZGV2aWNlIHN1cHBvcnRzIHRoZSBpbWFn ZS90MzggbWVkaWEgdHlwZSBbUkZDIDMzMjZdIGFuZCBpbXBsZW1lbnRzIElUVS1UIFQuMzggZm9y IHRyYW5zcG9ydGluZyB0aGUgSVRVLVQgVC4zMCBhbmQgVC40IGZheCBkYXRhIG92ZXIgSVAuDQo+ PiANCj4+IHBhc3N0aHJvdWdoOiBUaGUgZGV2aWNlIHN1cHBvcnRzIHRoZSBhdWRpby9wY211IGFu ZCBhdWRpby9wY21hIG1lZGlhIHR5cGVzIFtSRkM0ODU2XSBmb3IgdHJhbnNwb3J0aW5nIElUVS1U IFQuMzAgYW5kIFQuNCBmYXggZGF0YSB1c2luZyB0aGUgSVRVLVQgRy43MTEgY29kZWMuIEFkZGl0 aW9uYWwgaW1wbGVtZW50YXRpb24gcmVjb21tZW5kYXRpb25zIGFyZSBpbiBJVFUtVCBWLjE1MiBT ZWN0aW9ucyA2IGFuZCA2LjEuDQo+PiANCj4+IFRoYW5rcywNCj4+IERhdmlkDQo+PiANCj4+IA0K Pj4gDQo+PiANCj4+IA0KPj4gDQo+PiBPbiBTZXAgMTEsIDIwMTIsIGF0IDI6NTggUE0sIERhbGUg Ui4gV29ybGV5IHdyb3RlOg0KPj4gDQo+Pj4+IEZyb206IERhdmlkIEhhbmVzIDxkaGFuZXNAY2lz Y28uY29tPg0KPj4+Pj4gDQo+Pj4+PiBUaGUgInQzOCIgdmFsdWUgaXMgYmV0dGVyIGRlc2NyaWJl ZCBhcyAic3VwcG9ydHMgdGhlIGltYWdlL3QzOCANCj4+Pj4+IG1lZGlhIHR5cGVbUkZDMzM2Ml0g d2hpY2ggZW5jb2RlcyBwYWdlIGltYWdlcyB1c2luZyB0aGUgSVRVLVQgVC4zOCANCj4+Pj4+IGZh eCBwcm90b2NvbFtULjM4XSIuICBUaGF0IHNwZWNpZmllcyB0aGUgbWVkaWEgdHlwZSBhbmQgYWRk cyBhIA0KPj4+Pj4gcmVmZXJlbmNlIHRvIHRoZSBSRkMsIHdoaWNoIGluY2x1ZGVzIG1vcmUgZGV0 YWlscyBvZiB0aGUgc3BlY2lmaWMgDQo+Pj4+PiBJVFUgcmVjb21tZW5kYXRpb25zIGludm9sdmVk LiAgVGhlcmUgYXJlIHByb2JhYmx5IHNvbWUgDQo+Pj4+PiBpbXBsaWNhdGlvbnMgb2Ygd2hhdCB2 YWx1ZXMgb2YgdGhlIFQuMzggU0RQIGF0dHJpYnV0ZXMgYXJlIA0KPj4+Pj4gc3VwcG9ydGVkIC0t IGlzIHRoZXJlIGEgZGVmYXVsdCBzZXQgb2YgYXR0cmlidXRlcyB3aGljaCBjb25zdGl0dXRlIA0K Pj4+Pj4gYSBiYXNlbGluZSB2ZXJzaW9uIG9mIGltYWdlL3QzOD8NCj4+PiANCj4+PiAoSSBjYW4n dCByZW1lbWJlciBpZiBpbiB0aGUgcGFzdCBJIG1pc3Rha2VubHkgY29uc2lkZXJlZCB0aGUgZmF4 IA0KPj4+IG1lZGlhIHR5cGUgdG8gYmUgYXBwbGljYXRpb24vdDM4ICh3aGljaCB3YXMgcHJvcG9z ZWQgaW4gDQo+Pj4gaWV0Zi1tbXVzaWMtc2RwLXQzOC0wMCksIGJ1dCB0aGUgZmFjdCB0aGF0IHRo ZSBmYXggbWVkaWEgdHlwZSBpcw0KPj4+IGltYWdlL3QzOCBtYWtlcyBpdCBpbXBvc3NpYmxlIHRv IHVzZSB0aGUgK3NpcC5hcHAtc3VidHlwZSBtZWRpYSANCj4+PiBmZWF0dXJlIHRhZyB0byBzZWxl Y3QgZmF4LWNhcGFibGUgVUFzLikNCj4+PiANCj4+Pj4gSSBsaWtlIHRoZSBpbWFnZS90MzggbWVk aWEgYW5kIFJGQyBzcGVjaWZpY3MgdGhhdCB5b3UgYWRkZWQgYWJvdmUgDQo+Pj4+IGFuZCBJIHdp bGwgaW5jbHVkZSB0aGVzZSB1cGRhdGVzIGluIHRoZSBuZXh0IHZlcnNpb24uDQo+Pj4gDQo+Pj4g SWRlYWxseSwgd2Ugc2hvdWxkIHBvaW50IHRvIGFsbCB0aGUgc3RhbmRhcmRzIG5lZWRlZCB0byBk ZWZpbmUgdGhlIA0KPj4+IGZlYXR1cmUgKGFsdGhvdWdoIGluIHByYWN0aWNlLCBpbiBtYW55IHJl c3BlY3RzIHRoZXJlIGlzIG9ubHkgb25lIA0KPj4+IHByYWN0aWNhbCB3YXkgdG8gaW1wbGVtZW50 IHRoaXMsIHNvIHdlIGNvdWxkIGZvcmNlIHBlb3BsZSB0byBmaWd1cmUgDQo+Pj4gdGhpbmdzIG91 dCBmb3IgdGhlbXNlbHZlcykuDQo+Pj4gDQo+Pj4+IFlvdSBhbHNvIG1lbnRpb24gc3BlY2lmaWMg VC4zOCBhdHRyaWJ1dGVzLiBJIGFtIG5vdCBhd2FyZSBvZiBhIA0KPj4+PiBkZWZhdWx0IHNldCBv ZiBhdHRyaWJ1dGUgdmFsdWVzLiBJdCBzZWVtcyB0aGF0IGVhY2ggdmVuZG9yIGhhcyANCj4+Pj4g Y2VydGFpbiBkZWZhdWx0cyBidXQgaXQgaXMgcHJvYmFibHkgc2FmZSB0byBzYXkgdGhhdCBtYW55 IGFyZSANCj4+Pj4gY29tbW9ubHkgc2V0IHRoZSBzYW1lLiAgVGhpbmtpbmcgdGhpcyB0aHJvdWdo IHRob3VnaCwgaXQgc2VlbXMgbGlrZSANCj4+Pj4gdGhlIGdvYWwgb2YgdGhpcyBmZWF0dXJlIHRh ZyBpcyB0byBzaWduYWwgdGhlIHByZWZlcmVuY2UgdGhhdCB0aGUgDQo+Pj4+IGNhbGwgbGFuZHMg YXQgYSBmYXggY2FwYWJsZSwgb3IgbW9yZSBzcGVjaWZpY2FsbHkgaW4gdGhpcyBjYXNlLCBhIA0K Pj4+PiBULjM4IGNhcGFibGUgVUEuIE9uY2UgdGhlIFQuMzggY2FwYWJsZSBVQXMgYXJlIGNvbm5l Y3RlZCwgc2hvdWxkbid0IA0KPj4+PiB0aGV5IGhhbmRsZSB0aGUgVC4zOCBhdHRyaWJ1dGUgZXhj aGFuZ2UvbmVnb3RpYXRpb24gd2l0aGluIFNEUD8gDQo+Pj4+IFRoaXMgaXMgaG93IGl0IHdvcmtz IG5vdy4gSXQgc2VlbXMgdGhhdCBqdXN0IHNwZWNpZnlpbmcgVC4zOCB3b3VsZCANCj4+Pj4gYmUg ZW5vdWdoIGluIHRoaXMgY2FzZSBhbmQgdGhlbiB0aGUgVUFzIGNhbiBkZWFsIHdpdGggdGhlIFQu MzggYXR0cmlidXRlIHNldHRpbmdzIHdpdGhpbiBTRFAuDQo+Pj4gDQo+Pj4gWWVzLCBJIGFncmVl Lg0KPj4+IA0KPj4+IEkgd2FudGVkIHRvIGVuc3VyZSB0aGF0ICtzaXAuZmF4IHdvdWxkIHJlcXVp cmUgYSBzdWZmaWNpZW50IHNldCBvZg0KPj4+IGltYWdlL3QzOCBmZWF0dXJlcyAoZXhwcmVzc2Vk IGFzIFQzOCogYXR0cmlidXRlcykgdGhhdCBhbnkgdHdvIFVBcyANCj4+PiB0aGF0IG1ldCB0aGUg c3BlY2lmaWNhdGlvbiB3b3VsZCBiZSBhYmxlIHRvIGNvbW11bmljYXRlIChhdCBsZWFzdCANCj4+ PiB3aXRoIGEgImJhc2VsaW5lIiBjYXBhYmlsaXR5KS4gIE90aGVyd2lzZSB0aGVyZSBjb3VsZCBi ZSBtdWx0aXBsZSwgDQo+Pj4gaW5jb21wYXRpYmxlIGdyb3VwcyBvZiAic2lwLmZheCIgVUFzLiAg VGhhdCB3b3VsZCBpbmRpY2F0ZSB0aGF0IHRoZSANCj4+PiBzaXAuZmF4IHZhbHVlcyBzaG91bGQg YmUgZmluZXItZ3JhaW5lZCB0aGFuIHNpbXBseSAidDM4Ii4NCj4+PiANCj4+PiBCdXQgbG9va2lu ZyBhdCB0aGUgVC4zOCBzcGVjLCBhbm5leGVzIEQgYW5kIEgsIGl0IGFwcGVhcnMgdG8gbWUgdGhh dA0KPj4+IFQuMzggaXMgZGVzaWduZWQgZm9yIG1heGltdW0gbmVnb3RpYXRpb24gYW5kIGNvbXBh dGliaWxpdHksIGFuZCBzbyANCj4+PiB0aGVyZSBzaG91bGQgYmUgbGl0dGxlIHJpc2sgb2YgaW5j b21wYXRpYmlsaXR5IGlmIHdlIGRvIG5vdCBwbGFjZSANCj4+PiBhbnkgcmVxdWlyZW1lbnRzIG9u IHRoZSBUMzgqIGF0dHJpYnV0ZSB2YWx1ZXMgdGhhdCBhcmUgc3VwcG9ydGVkLg0KPj4+IA0KPj4+ Pj4gVGhlIGRlZmluaXRpb24gb2YgInBhc3N0aHJvdWdoIiBpcyBpbmNvbXBsZXRlIGFzIGl0IHN0 YW5kcy4gIFRoZSANCj4+Pj4+IG1lYW5pbmcgaXMgInN1cHBvcnRzIHRoZSBhdWRpby9wY211IGFu ZCBhdWRpby9wY21hIG1lZGlhIA0KPj4+Pj4gdHlwZXNbUkZDNDg1Nl0gZm9yIHRoZSB0cmFuc21p c3Npb24gb2YgZmF4IGltYWdlcyBlbmNvZGVkIA0KPj4+Pj4gKHNvbWVob3cpIGFzIGFuIGFuYWxv ZyBhdWRpbyBzdHJlYW0sIHdoaWNoIGlzIGluIHR1cm4gZW5jb2RlZCANCj4+Pj4+IHVzaW5nIEcu NzExIi4gIEJ1dCB3aGF0IGlzIHRoZSBkZXNjcmlwdGlvbiBvZiAic29tZWhvdyIgYW5kIHRoZSBw cm9wZXIgcmVmZXJlbmNlIGZvciBpdD8NCj4+Pj4gDQo+Pj4+IFRoZSAic29tZWhvdyIgaGVyZSBp cyBkZWZpbmVkIGJ5IElUVS1UIFQuMzAsIFQuNCwgYW5kIFQuNiBhbmQgdGhlc2UgDQo+Pj4+IGFy ZSBtb2R1bGF0ZWQgdXNpbmcgY29tbW9uIHNjaGVtZXMgbGlrZSBWLjIxIGFuZCBWLjE3IHNvIHRo YXQgdGhlIA0KPj4+PiBmYXggY29tbXVuaWNhdGlvbiBpcyBub3cgYW4gYW5hbG9nIHN0cmVhbS4g SSBhbSBub3Qgc3VyZSB0aGF0IHdlIA0KPj4+PiBuZWVkIHRoaXMgbGV2ZWwgb2YgZGV0YWlsIHRo b3VnaC4gVGhpcyBhdWRpbyBzdHJlYW0gZ2VuZXJhdGlvbiANCj4+Pj4gaGFwcGVucyB3aXRoIGV2 ZXJ5IGZheCBtYWNoaW5lIGFuZCBnYXRld2F5LiBQYXNzdGhyb3VnaCBpcyB2ZXJ5IA0KPj4+PiBz aW1wbGUuIFdlIGFyZSBqdXN0IHJlcGxhY2luZyBodW1hbiBzcGVlY2ggb3ZlciBHLjcxMSB3aXRo IGFuIA0KPj4+PiBhbmFsb2cgZmF4IHN0cmVhbS4gRy43MTEgaGFzIGJlZW4gdXNlZCBvbiB0aGUg UFNUTiBmb3IgZGVjYWRlcyBvbiANCj4+Pj4gVDEvRTEgc3BhbnMgZm9yIGhhbmRsaW5nIHZvaWNl IGFuZCBmYXguIEJhc2ljYWxseSwgd2hlbiB3ZSB1c2UgdGhlIA0KPj4+PiB0ZXJtIHBhc3N0aHJv dWdoLCB3ZSBhcmUgc2F5aW5nIHRyZWF0IGZheCBsaWtlIGEgRy43MTEgdm9pY2UgY2FsbC4gDQo+ Pj4+IFdpdGggdGhhdCBiZWluZyBzYWlkLCB3b3VsZG4ndCBqdXN0IHJlZmVyZW5jaW5nIEcuNzEx IGJlIGVub3VnaCANCj4+Pj4gZnJvbSBhIG1lZGlhIGZlYXR1cmUgdGFnIGFuZCB1c2VyIHByZWZl cmVuY2UgcGVyc3BlY3RpdmU/DQo+Pj4+IA0KPj4+Pj4gSSBkb24ndCBrbm93IGZheCB0ZWNobm9s b2dpZXMgd2VsbCBlbm91Z2ggdG8ga25vdyB3aGF0IGl0IGlzLCANCj4+Pj4+IHRob3VnaCBJJ20g Y2VydGFpbiB0aGF0IHRoZXJlIGlzIGEgc3BlY2lmaWMgc3RhbmRhcmQgaW50ZW5kZWQgaGVyZS4N Cj4+PiANCj4+PiBBcyBJIHNlZSBpdCwgdGhlcmUgaXMgYSBzZXJpZXMgb2YgZGVjb2Rpbmcgc3Rl cHM6DQo+Pj4gDQo+Pj4gLSBmcm9tIHRoZSBpbmNvbWluZyBSVFAgcGFja2V0cywgdGhlIHN0cmVh bSBvZiBQQ00gb2N0ZXRzIGlzIA0KPj4+IGV4dHJhY3RlZCAgYmFzZWQgb24gdGhlIFJUUCBzdGFu ZGFyZHMNCj4+PiANCj4+PiAtIGZyb20gdGhlIFBDTSBvY3RldHMsIGFuIGFuYWxvZyBzaWduYWwg aXMgY29uc3RydWN0ZWQgdmlhIEcuNzExIA0KPj4+IChQQ01BICBvciBQQ01VKQ0KPj4+IA0KPj4+ IC0gZnJvbSB0aGUgYW5hbG9nIHNpZ25hbCwgYSBiaXQgc3RyZWFtIGlzIGNvbnN0cnVjdGVkIHZp YSANCj4+PiBWLjIxL1YuMTcvVi4qDQo+Pj4gDQo+Pj4gLSBmcm9tIHRoZSBiaXQgc3RyZWFtLCBh IGZheCBpbWFnZSBpcyBjb25zdHJ1Y3RlZCB2aWEgVC4zMC9ULjQvVC42DQo+Pj4gDQo+Pj4gYW5k IGVuY29kaW5nIGlzIGRvbmUgaW4gdGhlIHJldmVyc2Ugb3JkZXIuDQo+Pj4gDQo+Pj4gU28gdG8g c3BlY2lmeSBob3cgbWVhbmluZyBpcyBlbmNvZGVkIGluIHRoZSBwYWNrZXRzLCB5b3UgbmVlZCB0 byANCj4+PiBzcGVjaWZ5IHRoYXQgZW50aXJlIHN0YWNrIG9mIHN0YW5kYXJkcy4gIE9yLCB0byBl bnN1cmUgDQo+Pj4gaW50ZXJvcGVyYWJpbGl0eSwgeW91IGhhdmUgdG8gcmVxdWlyZSBpbXBsZW1l bnRhdGlvbiBvZiBhIG1pbmltYWwgDQo+Pj4gc3Vic2V0IG9mIGFsbCB0aG9zZSBjaG9pY2VzLg0K Pj4+IA0KPj4+IFRoZSByZWFsaXR5IGlzIGEgYml0IG1lc3NpZXIsIEkgdGhpbmssIGJlY2F1c2Ug bWFjaGluZXMgcHJvYmFibHkgDQo+Pj4gbmVnb3RpYXRlIHdoaWNoICJtb2RlbSIgcHJvdG9jb2wg dGhleSB1c2UgKFYuMjEsIGV0Yy4pLCBhbmQgdGhleSBtYXkgDQo+Pj4gbmVnb3RpYXRlIHdoaWNo IGZheCBlbmNvZGluZyB0aGV5IHVzZS4NCj4+PiANCj4+PiBCdXQgc2luY2UgZmF4IG1hY2hpbmVz IHdvcmsgaW4gcHJhY3RpY2UsIHRoZXJlIGlzIGEgc3RhbmRhcmQgKG9yIGEgDQo+Pj4gdWJpcXVp dG91cyBkZS1mYWN0byBzdGFuZGFyZCkgdGhhdCBzcGVjaWZpZXMgdGhlIHR3byBoaWdoZXIgbGV2 ZWxzIA0KPj4+IG9mIHRoZSBlbmNvZGluZyBzdGFjay4NCj4+PiANCj4+PiBTbyBJIHRoaW5rIGl0 IGlzIG5lY2Vzc2FyeSB0byBwcm92aWRlIHNwZWNpZmljYXRpb24gb2YgdGhlIHR3byANCj4+PiBo aWdoZXIgbGV2ZWxzLCB0aGUgIm1vZGVtIiBlbmNvZGluZyBhbmQgdGhlIHBhZ2UgZW5jb2Rpbmcu ICBCdXQgSSANCj4+PiBzdHJvbmdseSBzdXNwZWN0IHRoYXQgdGhlcmUgYXJlIHN0YW5kYXJkcyBv ciB3ZWxsLXVuZGVyc3Rvb2QgQkNQcyANCj4+PiB0aGF0IGNhbiBiZSByZWZlcmVuY2VkIC0tIHdp dGhvdXQgZXhjbHVkaW5nIGFueSBwcmFjdGljYWwgDQo+Pj4gaW1wbGVtZW50YXRpb24gZnJvbSBi ZWluZyBpbiBjb25mb3JtYW5jZSB3aXRoICJzaXAuZmF4Ii4NCj4+PiANCj4+Pj4+IERvIHdlIHdh bnQgdG8gcmVxdWlyZSBQQ01VIGFuZCBQQ01BIHN1cHBvcnQsIG9yIFBDTVUgKm9yKiBQQ01BIA0K Pj4+Pj4gc3VwcG9ydD8NCj4+Pj4gDQo+Pj4+IEFzIHdpdGggdGhlIFQuMzggU0RQIGF0dHJpYnV0 ZXMsIGlzIHRoaXMgc29tZXRoaW5nIHRoYXQgd2Ugd2FudCB0byANCj4+Pj4gYWRkcmVzcyBpbiB0 aGlzIGRyYWZ0IG9yIGp1c3QgbGVhdmUgaXQgdG8gdGhlIFNEUCBwb3J0aW9uPyBXaXRoIA0KPj4+ PiBvbmx5IDIgY29kZWMgb3B0aW9ucywgeW91IGNvdWxkIGhhdmUgInBhc3N0aHJvdWdoLWc3MTHO vCIgYW5kIA0KPj4+PiAicGFzc3Rocm91Z2gtZzcxMWEiIHZhbHVlcy4gSG93ZXZlciwgaW4gcmVh bGl0eSBtb3N0IGZvbGtzIA0KPj4+PiBpbXBsZW1lbnRpbmcgcGFzc3Rocm91Z2ggd2lsbCBhY2Nl cHQgZWl0aGVyIEcuNzExIHZhcmlldHkuDQo+Pj4gDQo+Pj4gQXMgSSBzYWlkIGFib3ZlLCBJIHdh bnQgdG8gZW5zdXJlIHRoYXQgaWYgYSBjYWxsIHRoYXQgc3BlY2lmaWVzIA0KPj4+ICJzaXAuZmF4 IiBhcnJpdmVzIGF0IGEgVUEgdGhhdCByZWdpc3RlcnMgd2l0aCAic2lwLmZheCIsIHRoZW4gdGhl IA0KPj4+IGZheCBjYWxsIHdpbGwgc3VjY2VlZCBpbiBwcmFjdGljZS4gIE90aGVyd2lzZSwgZGVm aW5pbmcgc2lwLmZheCANCj4+PiBoYXNuJ3QgZ2FpbmVkIHdoYXQgd2Ugd2FudC4NCj4+PiANCj4+ PiBCdXQgZ2l2ZW4gdGhhdCBldmVyeSBTSVAgRy43MTEgaW1wbGVtZW50YXRpb24gSSd2ZSBldmVy IHNlZW4gDQo+Pj4gc3VwcG9ydHMgYm90aCBQQ01VIGFuZCBQQ01BLCBJIHdvdWxkIHN1Z2dlc3Qg dGhhdCB3ZSByZXF1aXJlICpib3RoKiANCj4+PiBhcyBwYXJ0IG9mIHRoZSBkZWZpbml0aW9uLiAg V2l0aCB0aGF0LCB0aGUgZGVmaW5pdGlvbiBlbnN1cmVzIA0KPj4+IGludGVyb3BlcmFiaWxpdHks IGJ1dCBpdCBkb2VzIG5vdCAoaW4gcHJhY3RpY2UpIGZ1cnRoZXIgY29uc3RyYWluIGFueSBpbXBs ZW1lbnRhdGlvbi4NCj4+PiANCj4+Pj4+IFdoYXQgZW5jb2RpbmcgcGFyYW1ldGVyIHZhbHVlcyBh cmUgcmVxdWlyZWQgZm9yIHN1cHBvcnQ/ICBJIGV4cGVjdCANCj4+Pj4+IHdlIHdhbnQgdG8gYWRk IHRoYXQgdGhlIGF1ZGlvIHN0cmVhbSBpcyBzaW5nbGUtY2hhbm5lbCBhbmQgd2UgDQo+Pj4+PiBw cm9iYWJseSB3YW50IHRvIHNwZWNpZnkgdGhhdCBpdCBpcyBhdCA4MDAwSHogc2FtcGxlIHJhdGUu DQo+Pj4gDQo+Pj4gT3IgcGVyaGFwcyB0aG9zZSBwYXJhbWV0ZXJzIGFyZSBlZmZlY3RpdmVseSBm aXhlZCBieSBULjQvVC42L1QuMzAgDQo+Pj4gKHJlZ2FyZGluZyBjaGFubmVscykgYW5kIEcuNzEx IChmb3IgdGhlIGJpdHJhdGUpLg0KPj4+IA0KPj4+Pj4gQWxzbywgdGhlIHJlZmVyZW5jZSB0byB0 aGUgVC4zOCBzcGVjIGlzIGdpdmVuIGFzIGluZm9ybWF0aXZlLCANCj4+Pj4+IHdoZXJlYXMgaXQg aXMgdXNlZCBub3JtYXRpdmVseS4NCj4+Pj4gDQo+Pj4+IFRoYW5rcy4gSSB3aWxsIGdldCB0aGF0 IGZpeGVkIGluIHRoZSBuZXh0IHZlcnNpb24uDQo+Pj4gDQo+Pj4gRGFsZQ0KPj4gDQo+PiANCj4g DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGRp c3BhdGNoIG1haWxpbmcgbGlzdA0KPiBkaXNwYXRjaEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoDQo+IA0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZGlzcGF0Y2ggbWFpbGluZyBsaXN0DQpk aXNwYXRjaEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9k aXNwYXRjaA0K From prvs=061659daaa=jbakker@rim.com Wed Sep 26 14:22:56 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5DF21F8594 for ; Wed, 26 Sep 2012 14:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.726 X-Spam-Level: X-Spam-Status: No, score=-5.726 tagged_above=-999 required=5 tests=[AWL=-0.523, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvS2icKIjLT3 for ; Wed, 26 Sep 2012 14:22:55 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1770721F8540 for ; Wed, 26 Sep 2012 14:22:55 -0700 (PDT) X-AuditID: 0a41282f-b7f196d0000008dc-5c-5063722d4642 Received: from XCT102ADS.rim.net (xct102ads.rim.net [10.67.111.43]) by mhs060cnc.rim.net (SBG) with SMTP id 66.F8.02268.D2273605; Wed, 26 Sep 2012 16:22:53 -0500 (CDT) Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT102ADS.rim.net ([fe80::4806:2e1d:2b7c:cfdf%22]) with mapi id 14.02.0318.001; Wed, 26 Sep 2012 16:22:53 -0500 From: John-Luc Bakker To: Gonzalo Camarillo Thread-Topic: [dispatch] New Version Notification for draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt Thread-Index: AQHNm9hb13IDLqBNvUakczbigIMD/5edHqeQ Date: Wed, 26 Sep 2012 21:22:52 +0000 Message-ID: <155970D1DA8E174F9E46039E10E2AA35234163@XMB104ADS.rim.net> References: <20120904152546.18420.91591.idtracker@ietfa.amsl.com> <155970D1DA8E174F9E46039E10E2AA351EA834@XMB104ADS.rim.net> <5062E3FC.4080009@ericsson.com> In-Reply-To: <5062E3FC.4080009@ericsson.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.251] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKKsWRmVeSWpSXmKPExsXC5ZyvratXlBxgcJDPYumkBawWm5avZHJg 8vj19Sqbx5IlP5kCmKIaGG2SEkvKgjPT8/TtbBLz8vJLEktSFVJSi5NtlXxS0xNzFAKKMssS kysVXDKLk3MSM3NTi5QUMlNslUyUFApyEpNTc1PzSmyVEgsKUvNSlOy4FDCADVBZZp5Cal5y fkpmXrqtkmewv66FhamlrqGSnW5CJ09Gz93NzAU3dCpO7XzG2MDYpNLFyMkhIWAicWvxXDYI W0ziwr31QDYXh5DASkaJBRseMUI4mxklls6ewgxSxSagLrF1xXYwW0TATOL9v1VMIDazgLbE /+vrGEFsYYE8iYdXtrBB1ORLfHl6jRHCNpKYOO8LWJxFQFVi8tQVYDavgJvEmlv7oZYtYJT4 0nkDbAGngI7E9q+rwIoYBWQldp+9DrVMXOLWk/lMEGcLSCzZc54ZwhaVePn4HyuErSgxY898 Voh6HYkFuz+xwRy6bOFrZojFghInZz5hmcAoNgvJ2FlIWmYhaZmFpGUBI8sqRsHcjGIDM4Pk vGS9osxcvbzUkk2MoEThqKG/g/Hte4tDjAIcjEo8vD6pyQFCrIllxZW5hxglOJiVRHifZSUF CPGmJFZWpRblxxeV5qQWH2K0AAbLRGYp7uR8YBLLK4k3NjBA4SiJ8/46lxggJJAOTD/ZqakF qUUwrUwcnCCjuaREioFJJLUosbQkIx6U6uKLgclOqoExx770xMTcu7lSFidf7Z30L/x2buXU JVOE0xv//X772feDs9zb+rfnuVcf6unM+jH97btQ13kvvrKGFHAs6Y1lntt70jnHNLsh4HVV 6e6EO/P1k0JE614mVufzWwZ/nrU731Hgl5l4gfJF6x3hxztVJK/qvjy69qzno43Biw4Xtex+ fMUl70STEktxRqKhFnNRcSIAv35GKkgDAAA= Cc: "dispatch@ietf.org" Subject: Re: [dispatch] New Version Notification for draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 21:22:56 -0000 Hi Gonzalo, > I assume "3gpp-alternative-service" covers uses (1) and (3) and "3gpp-serv= ice-info" covers use > (2). Is this assumption correct? (In any case, the draft could be clearer= on that point.) That is correct. I am happy to further clarify that point in the draft. > After reading the draft, it seems to me that "3gpp-ims+xml" bodies with di= sposition type > "3gpp-alternative-service" will always be carried in SIP responses while "= 3gpp-ims+xml" > bodies with disposition type "3gpp-service-info" will always be carried in= SIP requests. > Is my understanding correct? Today, indeed, "3gpp-ims+xml" bodies with disposition type "3gpp-alternative= -service" are carried in SIP responses while "3gpp-ims+xml" bodies with disp= osition type "3gpp-service-info" are carried in SIP requests. I don't know if that "will always" be the case. Kind regards, John-Luc -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] Sent: Wednesday, September 26, 2012 6:16 AM To: John-Luc Bakker Cc: dispatch@ietf.org Subject: Re: [dispatch] New Version Notification for draft-bakker-dispatch-3= gpp-ims-xml-body-handling-00.txt Hi John Luc, I have a quick question about this draft. The Abstract identifies three uses for 3gpp-ims+xml bodies: > (1) > for redirecting the emergency session to use a different domain (e.g. > using a Circuit Switched call), (2) for delivering user profile > specific information from the SIP registrar to an Application Server, > and (3) for causing a UAC to attempt to re-register with the IMS. Later, the draft defines two disposition types: > o 3gpp-alternative-service: the body (part) contains 3GPP IM CN > subsystem XML with the 'alternative-service' XML element as > described in Section 4.2; and > > o 3gpp-service-info: the body (part) contains 3GPP IM CN subsystem > XML with the 'service-info' XML element as described in Section > 4.3. I assume "3gpp-alternative-service" covers uses (1) and (3) and "3gpp-servic= e-info" covers use (2). Is this assumption correct? (In any case, the draft= could be clearer on that point.) After reading the draft, it seems to me that "3gpp-ims+xml" bodies with disp= osition type "3gpp-alternative-service" will always be carried in SIP respon= ses while "3gpp-ims+xml" bodies with disposition type "3gpp-service-info" wi= ll always be carried in SIP requests. Is my understanding correct? Thanks, Gonzalo On 04/09/2012 6:30 PM, John-Luc Bakker wrote: > Dear all, > > I have submitted a new version of the previous "draft-bakker-sipping-3gpp-= ims-xml-body-handling", taking into account the various comments received. T= he most notable change is to submit the draft to DISPATCH (instead of SIPPIN= G) and to submit the draft for standards track consideration. > > I welcome your comments. > > Kind regards, > > John-Luc > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Tuesday, September 04, 2012 10:26 AM > To: John-Luc Bakker > Subject: New Version Notification for > draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt > > > A new version of I-D, > draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt > has been successfully submitted by John-Luc Bakker and posted to the IETF= repository. > > Filename: draft-bakker-dispatch-3gpp-ims-xml-body-handling > Revision: 00 > Title: Specification of 3GPP IM CN Subsystem XML body handling > Creation date: 2012-09-04 > WG ID: Individual Submission > Number of pages: 8 > URL: http://www.ietf.org/internet-drafts/draft-bakker-dispatch= -3gpp-ims-xml-body-handling-00.txt > Status: http://datatracker.ietf.org/doc/draft-bakker-dispatch-3gp= p-ims-xml-body-handling > Htmlized: http://tools.ietf.org/html/draft-bakker-dispatch-3gpp-ims= -xml-body-handling-00 > > > Abstract: > This document registers new disposition-types for the Content- > Disposition header field that apply to the application/3gpp-ims+xml > body (part) used by 3GPP [5]. The applicability of these content- > disposition values are limited to 3GPP IMS [5]. The application/ > 3gpp-ims+xml body (part) has the following three distinct uses: (1) > for redirecting the emergency session to use a different domain (e.g. > using a Circuit Switched call), (2) for delivering user profile > specific information from the SIP registrar to an Application Server, > and (3) for causing a UAC to attempt to re-register with the IMS. > > = > > > The IETF Secretariat > > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential inf= ormation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informatio= n. Any use of this information by anyone other than the intended recipient i= s prohibited. If you have received this transmission in error, please immedi= ately reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From gonzalo.camarillo@ericsson.com Thu Sep 27 00:37:24 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68BBC21F86DF for ; Thu, 27 Sep 2012 00:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.218 X-Spam-Level: X-Spam-Status: No, score=-106.218 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYdcVgZcKgoE for ; Thu, 27 Sep 2012 00:37:23 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 66F6221F847A for ; Thu, 27 Sep 2012 00:37:23 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-cb-50640232d9cb Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 44.4B.11467.23204605; Thu, 27 Sep 2012 09:37:22 +0200 (CEST) Received: from [131.160.36.30] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.264.1; Thu, 27 Sep 2012 09:37:21 +0200 Message-ID: <50640231.2040009@ericsson.com> Date: Thu, 27 Sep 2012 10:37:21 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: John-Luc Bakker References: <20120904152546.18420.91591.idtracker@ietfa.amsl.com> <155970D1DA8E174F9E46039E10E2AA351EA834@XMB104ADS.rim.net> <5062E3FC.4080009@ericsson.com> <155970D1DA8E174F9E46039E10E2AA35234163@XMB104ADS.rim.net> In-Reply-To: <155970D1DA8E174F9E46039E10E2AA35234163@XMB104ADS.rim.net> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLLMWRmVeSWpSXmKPExsUyM+Jvra4RU0qAwcxZ0hZLJy1gtfhzsJXF gcljyZKfTB4TvqxkCWCK4rJJSc3JLEst0rdL4Mr4fuAoW8FS7oqtq4MaGHs5uxg5OSQETCT+ 3v3PAmGLSVy4t56ti5GLQ0jgFKPEtGMzmCGc1YwSL8+tZgOp4hXQlti4bwIjiM0ioCrRsfIZ O4jNJmAhseXWfbBJogLBEuc2boOqF5Q4OfMJWFwEqP7h0mNgvcxAc/5fXwdmCwvkSPROvsIE sew6o8TrvVvBEpwC7hITZ15hgzhPUuLN5JssEM16ElOutkANkpfY/nYOM4gtBDR0+bMWlgmM QrOQ7J6FpGUWkpYFjMyrGIVzEzNz0ssN9VKLMpOLi/Pz9IpTNzECg/jglt+6OxhPnRM5xCjN waIkzsuVtN9fSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2PV/sCQ5woZdfy8MqzLD+kEcDz0 eRnyiVfI0vXK9vztEWbdlfNanNJ919RbV33eecIi47KVwTSe280+3XU3F6ntnrzunYPE4p3u yytteAKsVS3V2Q39w485cjMZdBw+cv38lxU/ZF2jPVY1Ty71NNWZ+N5wQqiFwySRQ1vyDZb9 221Qy7N9hxJLcUaioRZzUXEiAL5oB/gwAgAA Cc: "dispatch@ietf.org" Subject: Re: [dispatch] New Version Notification for draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 07:37:24 -0000 Hi John Luc, > Today, indeed, "3gpp-ims+xml" bodies with disposition type "3gpp-alternative-service" are carried in SIP responses while "3gpp-ims+xml" bodies with disposition type "3gpp-service-info" are carried in SIP requests. > I don't know if that "will always" be the case. right, everybody I have asked about this also tells me what you say above. You can distinguish between those two cases by just checking whether it is a request or a response. The 3GPP specs seem to confirm that is the case as well. Therefore, what you are saying is that based on the *current* requirements and use cases that have been discussed so far, this draft is not needed. With respect to potential future cases where you would carry one of the disposition types in both requests and responses, nobody has given any example of those, at least yet. In any case, one of the main objections we have seen from the dispatch community is that this has been presented as an already-made solution that is already implemented and, thus, could not really be changed much even if the IETF decided to work on it. But given your answer above, it seems we do not need this solution for the *current* requirements and use cases. So, the backward compatibility problem goes away because if there were *new* requirements or use cases at some point , we could work on a solution from scratch. Am I missing something here? Cheers, Gonzalo From bruno.chatras@orange.com Fri Sep 28 01:11:16 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B888221F859C for ; Fri, 28 Sep 2012 01:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPHgSKLHu45J for ; Fri, 28 Sep 2012 01:11:14 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 1714521F856F for ; Fri, 28 Sep 2012 01:11:14 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id E9F7E18C6C6; Fri, 28 Sep 2012 10:11:12 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id BA1DA4C069; Fri, 28 Sep 2012 10:11:12 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Fri, 28 Sep 2012 10:11:12 +0200 From: To: James Rafferty , Gonzalo Salgueiro , Paul Kyzivat Thread-Topic: [dispatch] draft-hanes-dispatch-fax-capability-02 Thread-Index: AQHNm/xLee61c7fOckm+GPzevg+7wZecpraAgAAF24CAABo2gIACodxQ Date: Fri, 28 Sep 2012 08:11:11 +0000 Message-ID: <23170_1348819872_50655BA0_23170_6953_2_88CAD1D4E8773F42858B58CAA28272A008C17C@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <201209111858.q8BIwvvW006046@freeze.ariadne.com> <506326B5.7090009@alum.mit.edu> <48CAA1D0-A0DE-4D1E-816E-6BB22902B4AD@cisco.com> <54633A5E61DC84429CB9FE3D9143C72118008EA7@MBX.dialogic.com> In-Reply-To: <54633A5E61DC84429CB9FE3D9143C72118008EA7@MBX.dialogic.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.28.71515 Cc: "Dale R. Worley" , DISPATCH Subject: Re: [dispatch] draft-hanes-dispatch-fax-capability-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 08:11:16 -0000 VGhlIHByb3Bvc2VkIGRlZmluaXRpb24gZm9yIHRoZSBwYXNzLXRocm91Z2ggbW9kZSBhc3N1bWVz IHRoYXQgRy43MTEgaXMgdXNlZCBhcyBhIHZvaWNlLWJhbmQgY29kZWMuIFRoaXMgaXMgaW5kZWVk IHRoZSBtb3N0IGxpa2VseSBjb25maWd1cmF0aW9uLiBIb3dldmVyLCBhcyBmYXIgYXMgSSBjYW4g cmVtZW1iZXIsIHRoZSBwYXNzLXRocm91Z2ggbW9kZSBhcyBkZXNjcmliZWQgaW4gVi4xNTIgaXMg bm90IHJlc3RyaWN0ZWQgdG8gRy43MTEgKGUuZy4gRy43MjYgaXMgcG9zc2libGUgYXMgd2VsbCku DQpCQw0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBkaXNwYXRjaC1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEg cGFydA0KPiBkZSBKYW1lcyBSYWZmZXJ0eQ0KPiBFbnZvecOpwqA6IG1lcmNyZWRpIDI2IHNlcHRl bWJyZSAyMDEyIDE5OjU2DQo+IMOAwqA6IEdvbnphbG8gU2FsZ3VlaXJvOyBQYXVsIEt5eml2YXQN Cj4gQ2PCoDogRGFsZSBSLiBXb3JsZXk7IERJU1BBVENIDQo+IE9iamV0wqA6IFJlOiBbZGlzcGF0 Y2hdIGRyYWZ0LWhhbmVzLWRpc3BhdGNoLWZheC1jYXBhYmlsaXR5LTAyDQo+IA0KPiArMQ0KPiAN Cj4gSmFtZXMNCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGRpc3Bh dGNoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYNCj4gT2YgR29uemFsbyBTYWxndWVpcm8NCj4gU2VudDogV2VkbmVzZGF5LCBTZXB0 ZW1iZXIgMjYsIDIwMTIgMTI6MjIgUE0NCj4gVG86IFBhdWwgS3l6aXZhdA0KPiBDYzogRGFsZSBS LiBXb3JsZXk7IERJU1BBVENIDQo+IFN1YmplY3Q6IFJlOiBbZGlzcGF0Y2hdIGRyYWZ0LWhhbmVz LWRpc3BhdGNoLWZheC1jYXBhYmlsaXR5LTAyDQo+IA0KPiArMQ0KPiANCj4gR29uemFsbw0KPiAN Cj4gT24gU2VwIDI2LCAyMDEyLCBhdCAxMjowMCBQTSwgUGF1bCBLeXppdmF0IHdyb3RlOg0KPiAN Cj4gPiBUaGlzIHNvdW5kcyBwcmV0dHkgcmVhc29uYWJsZSB0byBtZS4NCj4gPg0KPiA+IAlUaGFu a3MsDQo+ID4gCVBhdWwNCj4gPg0KPiA+IE9uIDkvMjYvMTIgMTE6MzMgQU0sIERhdmlkIEhhbmVz IHdyb3RlOg0KPiA+PiBIb3cgYWJvdXQgdGhlIGZvbGxvd2luZyBkZXNjcmlwdGlvbnMgZm9yIFQu MzggYW5kIHBhc3N0aHJvdWdoIGluIHRoZSBJQU5BDQo+IENvbnNpZGVyYXRpb25zIHNlY3Rpb24/ DQo+ID4+DQo+ID4+IHQzODoJVGhlIGRldmljZSBzdXBwb3J0cyB0aGUgaW1hZ2UvdDM4IG1lZGlh IHR5cGUgW1JGQyAzMzI2XSBhbmQNCj4gaW1wbGVtZW50cyBJVFUtVCBULjM4IGZvciB0cmFuc3Bv cnRpbmcgdGhlIElUVS1UIFQuMzAgYW5kIFQuNCBmYXggZGF0YSBvdmVyDQo+IElQLg0KPiA+Pg0K PiA+PiBwYXNzdGhyb3VnaDogVGhlIGRldmljZSBzdXBwb3J0cyB0aGUgYXVkaW8vcGNtdSBhbmQg YXVkaW8vcGNtYSBtZWRpYQ0KPiB0eXBlcyBbUkZDNDg1Nl0gZm9yIHRyYW5zcG9ydGluZyBJVFUt VCBULjMwIGFuZCBULjQgZmF4IGRhdGEgdXNpbmcgdGhlIElUVS1UDQo+IEcuNzExIGNvZGVjLiBB ZGRpdGlvbmFsIGltcGxlbWVudGF0aW9uIHJlY29tbWVuZGF0aW9ucyBhcmUgaW4gSVRVLVQgVi4x NTINCj4gU2VjdGlvbnMgNiBhbmQgNi4xLg0KPiA+Pg0KPiA+PiBUaGFua3MsDQo+ID4+IERhdmlk DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IE9uIFNlcCAxMSwgMjAx MiwgYXQgMjo1OCBQTSwgRGFsZSBSLiBXb3JsZXkgd3JvdGU6DQo+ID4+DQo+ID4+Pj4gRnJvbTog RGF2aWQgSGFuZXMgPGRoYW5lc0BjaXNjby5jb20+DQo+ID4+Pj4+DQo+ID4+Pj4+IFRoZSAidDM4 IiB2YWx1ZSBpcyBiZXR0ZXIgZGVzY3JpYmVkIGFzICJzdXBwb3J0cyB0aGUgaW1hZ2UvdDM4DQo+ ID4+Pj4+IG1lZGlhIHR5cGVbUkZDMzM2Ml0gd2hpY2ggZW5jb2RlcyBwYWdlIGltYWdlcyB1c2lu ZyB0aGUgSVRVLVQgVC4zOA0KPiA+Pj4+PiBmYXggcHJvdG9jb2xbVC4zOF0iLiAgVGhhdCBzcGVj aWZpZXMgdGhlIG1lZGlhIHR5cGUgYW5kIGFkZHMgYQ0KPiA+Pj4+PiByZWZlcmVuY2UgdG8gdGhl IFJGQywgd2hpY2ggaW5jbHVkZXMgbW9yZSBkZXRhaWxzIG9mIHRoZSBzcGVjaWZpYw0KPiA+Pj4+ PiBJVFUgcmVjb21tZW5kYXRpb25zIGludm9sdmVkLiAgVGhlcmUgYXJlIHByb2JhYmx5IHNvbWUN Cj4gPj4+Pj4gaW1wbGljYXRpb25zIG9mIHdoYXQgdmFsdWVzIG9mIHRoZSBULjM4IFNEUCBhdHRy aWJ1dGVzIGFyZQ0KPiA+Pj4+PiBzdXBwb3J0ZWQgLS0gaXMgdGhlcmUgYSBkZWZhdWx0IHNldCBv ZiBhdHRyaWJ1dGVzIHdoaWNoIGNvbnN0aXR1dGUNCj4gPj4+Pj4gYSBiYXNlbGluZSB2ZXJzaW9u IG9mIGltYWdlL3QzOD8NCj4gPj4+DQo+ID4+PiAoSSBjYW4ndCByZW1lbWJlciBpZiBpbiB0aGUg cGFzdCBJIG1pc3Rha2VubHkgY29uc2lkZXJlZCB0aGUgZmF4DQo+ID4+PiBtZWRpYSB0eXBlIHRv IGJlIGFwcGxpY2F0aW9uL3QzOCAod2hpY2ggd2FzIHByb3Bvc2VkIGluDQo+ID4+PiBpZXRmLW1t dXNpYy1zZHAtdDM4LTAwKSwgYnV0IHRoZSBmYWN0IHRoYXQgdGhlIGZheCBtZWRpYSB0eXBlIGlz DQo+ID4+PiBpbWFnZS90MzggbWFrZXMgaXQgaW1wb3NzaWJsZSB0byB1c2UgdGhlICtzaXAuYXBw LXN1YnR5cGUgbWVkaWENCj4gPj4+IGZlYXR1cmUgdGFnIHRvIHNlbGVjdCBmYXgtY2FwYWJsZSBV QXMuKQ0KPiA+Pj4NCj4gPj4+PiBJIGxpa2UgdGhlIGltYWdlL3QzOCBtZWRpYSBhbmQgUkZDIHNw ZWNpZmljcyB0aGF0IHlvdSBhZGRlZCBhYm92ZQ0KPiA+Pj4+IGFuZCBJIHdpbGwgaW5jbHVkZSB0 aGVzZSB1cGRhdGVzIGluIHRoZSBuZXh0IHZlcnNpb24uDQo+ID4+Pg0KPiA+Pj4gSWRlYWxseSwg d2Ugc2hvdWxkIHBvaW50IHRvIGFsbCB0aGUgc3RhbmRhcmRzIG5lZWRlZCB0byBkZWZpbmUgdGhl DQo+ID4+PiBmZWF0dXJlIChhbHRob3VnaCBpbiBwcmFjdGljZSwgaW4gbWFueSByZXNwZWN0cyB0 aGVyZSBpcyBvbmx5IG9uZQ0KPiA+Pj4gcHJhY3RpY2FsIHdheSB0byBpbXBsZW1lbnQgdGhpcywg c28gd2UgY291bGQgZm9yY2UgcGVvcGxlIHRvIGZpZ3VyZQ0KPiA+Pj4gdGhpbmdzIG91dCBmb3Ig dGhlbXNlbHZlcykuDQo+ID4+Pg0KPiA+Pj4+IFlvdSBhbHNvIG1lbnRpb24gc3BlY2lmaWMgVC4z OCBhdHRyaWJ1dGVzLiBJIGFtIG5vdCBhd2FyZSBvZiBhDQo+ID4+Pj4gZGVmYXVsdCBzZXQgb2Yg YXR0cmlidXRlIHZhbHVlcy4gSXQgc2VlbXMgdGhhdCBlYWNoIHZlbmRvciBoYXMNCj4gPj4+PiBj ZXJ0YWluIGRlZmF1bHRzIGJ1dCBpdCBpcyBwcm9iYWJseSBzYWZlIHRvIHNheSB0aGF0IG1hbnkg YXJlDQo+ID4+Pj4gY29tbW9ubHkgc2V0IHRoZSBzYW1lLiAgVGhpbmtpbmcgdGhpcyB0aHJvdWdo IHRob3VnaCwgaXQgc2VlbXMgbGlrZQ0KPiA+Pj4+IHRoZSBnb2FsIG9mIHRoaXMgZmVhdHVyZSB0 YWcgaXMgdG8gc2lnbmFsIHRoZSBwcmVmZXJlbmNlIHRoYXQgdGhlDQo+ID4+Pj4gY2FsbCBsYW5k cyBhdCBhIGZheCBjYXBhYmxlLCBvciBtb3JlIHNwZWNpZmljYWxseSBpbiB0aGlzIGNhc2UsIGEN Cj4gPj4+PiBULjM4IGNhcGFibGUgVUEuIE9uY2UgdGhlIFQuMzggY2FwYWJsZSBVQXMgYXJlIGNv bm5lY3RlZCwgc2hvdWxkbid0DQo+ID4+Pj4gdGhleSBoYW5kbGUgdGhlIFQuMzggYXR0cmlidXRl IGV4Y2hhbmdlL25lZ290aWF0aW9uIHdpdGhpbiBTRFA/DQo+ID4+Pj4gVGhpcyBpcyBob3cgaXQg d29ya3Mgbm93LiBJdCBzZWVtcyB0aGF0IGp1c3Qgc3BlY2lmeWluZyBULjM4IHdvdWxkDQo+ID4+ Pj4gYmUgZW5vdWdoIGluIHRoaXMgY2FzZSBhbmQgdGhlbiB0aGUgVUFzIGNhbiBkZWFsIHdpdGgg dGhlIFQuMzgNCj4gYXR0cmlidXRlIHNldHRpbmdzIHdpdGhpbiBTRFAuDQo+ID4+Pg0KPiA+Pj4g WWVzLCBJIGFncmVlLg0KPiA+Pj4NCj4gPj4+IEkgd2FudGVkIHRvIGVuc3VyZSB0aGF0ICtzaXAu ZmF4IHdvdWxkIHJlcXVpcmUgYSBzdWZmaWNpZW50IHNldCBvZg0KPiA+Pj4gaW1hZ2UvdDM4IGZl YXR1cmVzIChleHByZXNzZWQgYXMgVDM4KiBhdHRyaWJ1dGVzKSB0aGF0IGFueSB0d28gVUFzDQo+ ID4+PiB0aGF0IG1ldCB0aGUgc3BlY2lmaWNhdGlvbiB3b3VsZCBiZSBhYmxlIHRvIGNvbW11bmlj YXRlIChhdCBsZWFzdA0KPiA+Pj4gd2l0aCBhICJiYXNlbGluZSIgY2FwYWJpbGl0eSkuICBPdGhl cndpc2UgdGhlcmUgY291bGQgYmUgbXVsdGlwbGUsDQo+ID4+PiBpbmNvbXBhdGlibGUgZ3JvdXBz IG9mICJzaXAuZmF4IiBVQXMuICBUaGF0IHdvdWxkIGluZGljYXRlIHRoYXQgdGhlDQo+ID4+PiBz aXAuZmF4IHZhbHVlcyBzaG91bGQgYmUgZmluZXItZ3JhaW5lZCB0aGFuIHNpbXBseSAidDM4Ii4N Cj4gPj4+DQo+ID4+PiBCdXQgbG9va2luZyBhdCB0aGUgVC4zOCBzcGVjLCBhbm5leGVzIEQgYW5k IEgsIGl0IGFwcGVhcnMgdG8gbWUgdGhhdA0KPiA+Pj4gVC4zOCBpcyBkZXNpZ25lZCBmb3IgbWF4 aW11bSBuZWdvdGlhdGlvbiBhbmQgY29tcGF0aWJpbGl0eSwgYW5kIHNvDQo+ID4+PiB0aGVyZSBz aG91bGQgYmUgbGl0dGxlIHJpc2sgb2YgaW5jb21wYXRpYmlsaXR5IGlmIHdlIGRvIG5vdCBwbGFj ZQ0KPiA+Pj4gYW55IHJlcXVpcmVtZW50cyBvbiB0aGUgVDM4KiBhdHRyaWJ1dGUgdmFsdWVzIHRo YXQgYXJlIHN1cHBvcnRlZC4NCj4gPj4+DQo+ID4+Pj4+IFRoZSBkZWZpbml0aW9uIG9mICJwYXNz dGhyb3VnaCIgaXMgaW5jb21wbGV0ZSBhcyBpdCBzdGFuZHMuICBUaGUNCj4gPj4+Pj4gbWVhbmlu ZyBpcyAic3VwcG9ydHMgdGhlIGF1ZGlvL3BjbXUgYW5kIGF1ZGlvL3BjbWEgbWVkaWENCj4gPj4+ Pj4gdHlwZXNbUkZDNDg1Nl0gZm9yIHRoZSB0cmFuc21pc3Npb24gb2YgZmF4IGltYWdlcyBlbmNv ZGVkDQo+ID4+Pj4+IChzb21laG93KSBhcyBhbiBhbmFsb2cgYXVkaW8gc3RyZWFtLCB3aGljaCBp cyBpbiB0dXJuIGVuY29kZWQNCj4gPj4+Pj4gdXNpbmcgRy43MTEiLiAgQnV0IHdoYXQgaXMgdGhl IGRlc2NyaXB0aW9uIG9mICJzb21laG93IiBhbmQgdGhlIHByb3Blcg0KPiByZWZlcmVuY2UgZm9y IGl0Pw0KPiA+Pj4+DQo+ID4+Pj4gVGhlICJzb21laG93IiBoZXJlIGlzIGRlZmluZWQgYnkgSVRV LVQgVC4zMCwgVC40LCBhbmQgVC42IGFuZCB0aGVzZQ0KPiA+Pj4+IGFyZSBtb2R1bGF0ZWQgdXNp bmcgY29tbW9uIHNjaGVtZXMgbGlrZSBWLjIxIGFuZCBWLjE3IHNvIHRoYXQgdGhlDQo+ID4+Pj4g ZmF4IGNvbW11bmljYXRpb24gaXMgbm93IGFuIGFuYWxvZyBzdHJlYW0uIEkgYW0gbm90IHN1cmUg dGhhdCB3ZQ0KPiA+Pj4+IG5lZWQgdGhpcyBsZXZlbCBvZiBkZXRhaWwgdGhvdWdoLiBUaGlzIGF1 ZGlvIHN0cmVhbSBnZW5lcmF0aW9uDQo+ID4+Pj4gaGFwcGVucyB3aXRoIGV2ZXJ5IGZheCBtYWNo aW5lIGFuZCBnYXRld2F5LiBQYXNzdGhyb3VnaCBpcyB2ZXJ5DQo+ID4+Pj4gc2ltcGxlLiBXZSBh cmUganVzdCByZXBsYWNpbmcgaHVtYW4gc3BlZWNoIG92ZXIgRy43MTEgd2l0aCBhbg0KPiA+Pj4+ IGFuYWxvZyBmYXggc3RyZWFtLiBHLjcxMSBoYXMgYmVlbiB1c2VkIG9uIHRoZSBQU1ROIGZvciBk ZWNhZGVzIG9uDQo+ID4+Pj4gVDEvRTEgc3BhbnMgZm9yIGhhbmRsaW5nIHZvaWNlIGFuZCBmYXgu IEJhc2ljYWxseSwgd2hlbiB3ZSB1c2UgdGhlDQo+ID4+Pj4gdGVybSBwYXNzdGhyb3VnaCwgd2Ug YXJlIHNheWluZyB0cmVhdCBmYXggbGlrZSBhIEcuNzExIHZvaWNlIGNhbGwuDQo+ID4+Pj4gV2l0 aCB0aGF0IGJlaW5nIHNhaWQsIHdvdWxkbid0IGp1c3QgcmVmZXJlbmNpbmcgRy43MTEgYmUgZW5v dWdoDQo+ID4+Pj4gZnJvbSBhIG1lZGlhIGZlYXR1cmUgdGFnIGFuZCB1c2VyIHByZWZlcmVuY2Ug cGVyc3BlY3RpdmU/DQo+ID4+Pj4NCj4gPj4+Pj4gSSBkb24ndCBrbm93IGZheCB0ZWNobm9sb2dp ZXMgd2VsbCBlbm91Z2ggdG8ga25vdyB3aGF0IGl0IGlzLA0KPiA+Pj4+PiB0aG91Z2ggSSdtIGNl cnRhaW4gdGhhdCB0aGVyZSBpcyBhIHNwZWNpZmljIHN0YW5kYXJkIGludGVuZGVkIGhlcmUuDQo+ ID4+Pg0KPiA+Pj4gQXMgSSBzZWUgaXQsIHRoZXJlIGlzIGEgc2VyaWVzIG9mIGRlY29kaW5nIHN0 ZXBzOg0KPiA+Pj4NCj4gPj4+IC0gZnJvbSB0aGUgaW5jb21pbmcgUlRQIHBhY2tldHMsIHRoZSBz dHJlYW0gb2YgUENNIG9jdGV0cyBpcw0KPiA+Pj4gZXh0cmFjdGVkICBiYXNlZCBvbiB0aGUgUlRQ IHN0YW5kYXJkcw0KPiA+Pj4NCj4gPj4+IC0gZnJvbSB0aGUgUENNIG9jdGV0cywgYW4gYW5hbG9n IHNpZ25hbCBpcyBjb25zdHJ1Y3RlZCB2aWEgRy43MTENCj4gPj4+IChQQ01BICBvciBQQ01VKQ0K PiA+Pj4NCj4gPj4+IC0gZnJvbSB0aGUgYW5hbG9nIHNpZ25hbCwgYSBiaXQgc3RyZWFtIGlzIGNv bnN0cnVjdGVkIHZpYQ0KPiA+Pj4gVi4yMS9WLjE3L1YuKg0KPiA+Pj4NCj4gPj4+IC0gZnJvbSB0 aGUgYml0IHN0cmVhbSwgYSBmYXggaW1hZ2UgaXMgY29uc3RydWN0ZWQgdmlhIFQuMzAvVC40L1Qu Ng0KPiA+Pj4NCj4gPj4+IGFuZCBlbmNvZGluZyBpcyBkb25lIGluIHRoZSByZXZlcnNlIG9yZGVy Lg0KPiA+Pj4NCj4gPj4+IFNvIHRvIHNwZWNpZnkgaG93IG1lYW5pbmcgaXMgZW5jb2RlZCBpbiB0 aGUgcGFja2V0cywgeW91IG5lZWQgdG8NCj4gPj4+IHNwZWNpZnkgdGhhdCBlbnRpcmUgc3RhY2sg b2Ygc3RhbmRhcmRzLiAgT3IsIHRvIGVuc3VyZQ0KPiA+Pj4gaW50ZXJvcGVyYWJpbGl0eSwgeW91 IGhhdmUgdG8gcmVxdWlyZSBpbXBsZW1lbnRhdGlvbiBvZiBhIG1pbmltYWwNCj4gPj4+IHN1YnNl dCBvZiBhbGwgdGhvc2UgY2hvaWNlcy4NCj4gPj4+DQo+ID4+PiBUaGUgcmVhbGl0eSBpcyBhIGJp dCBtZXNzaWVyLCBJIHRoaW5rLCBiZWNhdXNlIG1hY2hpbmVzIHByb2JhYmx5DQo+ID4+PiBuZWdv dGlhdGUgd2hpY2ggIm1vZGVtIiBwcm90b2NvbCB0aGV5IHVzZSAoVi4yMSwgZXRjLiksIGFuZCB0 aGV5IG1heQ0KPiA+Pj4gbmVnb3RpYXRlIHdoaWNoIGZheCBlbmNvZGluZyB0aGV5IHVzZS4NCj4g Pj4+DQo+ID4+PiBCdXQgc2luY2UgZmF4IG1hY2hpbmVzIHdvcmsgaW4gcHJhY3RpY2UsIHRoZXJl IGlzIGEgc3RhbmRhcmQgKG9yIGENCj4gPj4+IHViaXF1aXRvdXMgZGUtZmFjdG8gc3RhbmRhcmQp IHRoYXQgc3BlY2lmaWVzIHRoZSB0d28gaGlnaGVyIGxldmVscw0KPiA+Pj4gb2YgdGhlIGVuY29k aW5nIHN0YWNrLg0KPiA+Pj4NCj4gPj4+IFNvIEkgdGhpbmsgaXQgaXMgbmVjZXNzYXJ5IHRvIHBy b3ZpZGUgc3BlY2lmaWNhdGlvbiBvZiB0aGUgdHdvDQo+ID4+PiBoaWdoZXIgbGV2ZWxzLCB0aGUg Im1vZGVtIiBlbmNvZGluZyBhbmQgdGhlIHBhZ2UgZW5jb2RpbmcuICBCdXQgSQ0KPiA+Pj4gc3Ry b25nbHkgc3VzcGVjdCB0aGF0IHRoZXJlIGFyZSBzdGFuZGFyZHMgb3Igd2VsbC11bmRlcnN0b29k IEJDUHMNCj4gPj4+IHRoYXQgY2FuIGJlIHJlZmVyZW5jZWQgLS0gd2l0aG91dCBleGNsdWRpbmcg YW55IHByYWN0aWNhbA0KPiA+Pj4gaW1wbGVtZW50YXRpb24gZnJvbSBiZWluZyBpbiBjb25mb3Jt YW5jZSB3aXRoICJzaXAuZmF4Ii4NCj4gPj4+DQo+ID4+Pj4+IERvIHdlIHdhbnQgdG8gcmVxdWly ZSBQQ01VIGFuZCBQQ01BIHN1cHBvcnQsIG9yIFBDTVUgKm9yKiBQQ01BDQo+ID4+Pj4+IHN1cHBv cnQ/DQo+ID4+Pj4NCj4gPj4+PiBBcyB3aXRoIHRoZSBULjM4IFNEUCBhdHRyaWJ1dGVzLCBpcyB0 aGlzIHNvbWV0aGluZyB0aGF0IHdlIHdhbnQgdG8NCj4gPj4+PiBhZGRyZXNzIGluIHRoaXMgZHJh ZnQgb3IganVzdCBsZWF2ZSBpdCB0byB0aGUgU0RQIHBvcnRpb24/IFdpdGgNCj4gPj4+PiBvbmx5 IDIgY29kZWMgb3B0aW9ucywgeW91IGNvdWxkIGhhdmUgInBhc3N0aHJvdWdoLWc3MTHOvCIgYW5k DQo+ID4+Pj4gInBhc3N0aHJvdWdoLWc3MTFhIiB2YWx1ZXMuIEhvd2V2ZXIsIGluIHJlYWxpdHkg bW9zdCBmb2xrcw0KPiA+Pj4+IGltcGxlbWVudGluZyBwYXNzdGhyb3VnaCB3aWxsIGFjY2VwdCBl aXRoZXIgRy43MTEgdmFyaWV0eS4NCj4gPj4+DQo+ID4+PiBBcyBJIHNhaWQgYWJvdmUsIEkgd2Fu dCB0byBlbnN1cmUgdGhhdCBpZiBhIGNhbGwgdGhhdCBzcGVjaWZpZXMNCj4gPj4+ICJzaXAuZmF4 IiBhcnJpdmVzIGF0IGEgVUEgdGhhdCByZWdpc3RlcnMgd2l0aCAic2lwLmZheCIsIHRoZW4gdGhl DQo+ID4+PiBmYXggY2FsbCB3aWxsIHN1Y2NlZWQgaW4gcHJhY3RpY2UuICBPdGhlcndpc2UsIGRl ZmluaW5nIHNpcC5mYXgNCj4gPj4+IGhhc24ndCBnYWluZWQgd2hhdCB3ZSB3YW50Lg0KPiA+Pj4N Cj4gPj4+IEJ1dCBnaXZlbiB0aGF0IGV2ZXJ5IFNJUCBHLjcxMSBpbXBsZW1lbnRhdGlvbiBJJ3Zl IGV2ZXIgc2Vlbg0KPiA+Pj4gc3VwcG9ydHMgYm90aCBQQ01VIGFuZCBQQ01BLCBJIHdvdWxkIHN1 Z2dlc3QgdGhhdCB3ZSByZXF1aXJlICpib3RoKg0KPiA+Pj4gYXMgcGFydCBvZiB0aGUgZGVmaW5p dGlvbi4gIFdpdGggdGhhdCwgdGhlIGRlZmluaXRpb24gZW5zdXJlcw0KPiA+Pj4gaW50ZXJvcGVy YWJpbGl0eSwgYnV0IGl0IGRvZXMgbm90IChpbiBwcmFjdGljZSkgZnVydGhlciBjb25zdHJhaW4g YW55DQo+IGltcGxlbWVudGF0aW9uLg0KPiA+Pj4NCj4gPj4+Pj4gV2hhdCBlbmNvZGluZyBwYXJh bWV0ZXIgdmFsdWVzIGFyZSByZXF1aXJlZCBmb3Igc3VwcG9ydD8gIEkgZXhwZWN0DQo+ID4+Pj4+ IHdlIHdhbnQgdG8gYWRkIHRoYXQgdGhlIGF1ZGlvIHN0cmVhbSBpcyBzaW5nbGUtY2hhbm5lbCBh bmQgd2UNCj4gPj4+Pj4gcHJvYmFibHkgd2FudCB0byBzcGVjaWZ5IHRoYXQgaXQgaXMgYXQgODAw MEh6IHNhbXBsZSByYXRlLg0KPiA+Pj4NCj4gPj4+IE9yIHBlcmhhcHMgdGhvc2UgcGFyYW1ldGVy cyBhcmUgZWZmZWN0aXZlbHkgZml4ZWQgYnkgVC40L1QuNi9ULjMwDQo+ID4+PiAocmVnYXJkaW5n IGNoYW5uZWxzKSBhbmQgRy43MTEgKGZvciB0aGUgYml0cmF0ZSkuDQo+ID4+Pg0KPiA+Pj4+PiBB bHNvLCB0aGUgcmVmZXJlbmNlIHRvIHRoZSBULjM4IHNwZWMgaXMgZ2l2ZW4gYXMgaW5mb3JtYXRp dmUsDQo+ID4+Pj4+IHdoZXJlYXMgaXQgaXMgdXNlZCBub3JtYXRpdmVseS4NCj4gPj4+Pg0KPiA+ Pj4+IFRoYW5rcy4gSSB3aWxsIGdldCB0aGF0IGZpeGVkIGluIHRoZSBuZXh0IHZlcnNpb24uDQo+ ID4+Pg0KPiA+Pj4gRGFsZQ0KPiA+Pg0KPiA+Pg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBkaXNwYXRjaCBtYWlsaW5nIGxpc3QN Cj4gPiBkaXNwYXRjaEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZGlzcGF0Y2gNCj4gPg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gZGlzcGF0Y2ggbWFpbGluZyBsaXN0DQo+IGRpc3BhdGNo QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0 Y2gNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g ZGlzcGF0Y2ggbWFpbGluZyBsaXN0DQo+IGRpc3BhdGNoQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2gNCgpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdl IGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMg Y29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0 cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZv dXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIK YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRl cy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJh dGlvbiwKRnJhbmNlIFRlbGVjb20gLSBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0 ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2ku CgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3 Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQg YXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwg cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgRnJhbmNlIFRlbGVjb20gLSBP cmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQs IGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From richard@shockey.us Fri Sep 28 09:51:09 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9677A21F8570 for ; Fri, 28 Sep 2012 09:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.764 X-Spam-Level: X-Spam-Status: No, score=-98.764 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BABb8cKuoNFP for ; Fri, 28 Sep 2012 09:51:04 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id 6288421F84B9 for ; Fri, 28 Sep 2012 09:51:01 -0700 (PDT) Received: (qmail 23073 invoked by uid 0); 28 Sep 2012 16:50:57 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy8.bluehost.com with SMTP; 28 Sep 2012 16:50:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=v7+2IroOHAE13quhn2VjZBv2KsSUCnSVPmDEMJ63TiM=; b=PHdSYAMHKJ+pISF6535k/NOUYIFoqOphjKHLwMFyIKYhNaGiAw6CWRNsGs5205rxs/dEhESCxM5/qNsbs8tV0Wy68LLw98tBA8ImsKuXFfsuaR24VwA2VFaxqGOXKCbJ; Received: from [71.191.243.130] (port=61644 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1THdmC-00015T-ED; Fri, 28 Sep 2012 10:50:56 -0600 From: "Richard Shockey" To: , "'DISPATCH'" , Date: Fri, 28 Sep 2012 12:50:53 -0400 Message-ID: <013101cd9d99$6d154500$473fcf00$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0132_01CD9D77.E603A500" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2dmWwesgsKc++hQ8CQ/9f8HS7k5g== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.191.243.130 authed with richard@shockey.us} Subject: [dispatch] FYI .. The SIP Forum is considering developing a Profile for the Video Relay Service. X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 16:51:09 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0132_01CD9D77.E603A500 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit At the request of several organizations the SIP Forum is considering developing a task group to undertake a comprehensive SIP interoperability Profile of the Video Relay Service for hearing impaired citizens. This would be similar in scope to work the Forum has undertaken in the past to define a interoperability SIP Profile for SIP PBX to service provider that resulted in the Forum's SIP Connect specification and RFC 6140. We have seen substantial documentation that the state of VRS interoperability is simply appalling. We will certainly want the input and recommendations of the IETF RAI community as we undertake this project. The implications for SIP based Unified Communications should be obvious. As usual we will NOT define new SIP protocols but should issues arise the proposed task group will be chartered to document and report new requirements to DISPATCH as needed. We are open to suggestions that we publish our charter and other documents as Informational RFC's. A mailing list has been established. You all are welcome to join. vrs@sipforum.org http://en.wikipedia.org/wiki/Video_relay_service http://tap.gallaudet.edu/Conferences/NAD2012/ http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-11-184A1.pdf Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 < mailto:richard(at)shockey.us> skype-linkedin-facebook: rshockey101 http//www.sipforum.org ------=_NextPart_000_0132_01CD9D77.E603A500 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

At the = request of several organizations the SIP Forum is considering developing = a task group to undertake a comprehensive SIP interoperability Profile = of the Video Relay Service for hearing impaired citizens.  This = would be similar in scope to work the Forum has undertaken in the past = to define a interoperability SIP Profile for SIP PBX to service provider = that resulted in the Forum’s SIP Connect specification and RFC = 6140.

 

We have seen substantial documentation that the state = of VRS interoperability is simply appalling.

 

We will = certainly want the input and recommendations of the IETF RAI community = as we undertake this project.

 

The = implications for SIP based Unified Communications should be obvious. =

 

As usual we will NOT define new SIP protocols but = should issues arise the proposed task group will be chartered to = document and report new requirements to DISPATCH as = needed.

 

We are open to suggestions that we publish our charter = and other documents as Informational RFC’s.

 

A mailing = list has been established. You all are welcome to join. =  

 

vrs@sipforum.org

 

http://en.wikip= edia.org/wiki/Video_relay_service

 

http://tap.gallaud= et.edu/Conferences/NAD2012/

 

http://hraunfoss.fcc.gov/edocs_public/attachmatch= /FCC-11-184A1.pdf

 

 

 

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

 

------=_NextPart_000_0132_01CD9D77.E603A500-- From dhanes@cisco.com Fri Sep 28 13:39:04 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1686A21F85FC for ; Fri, 28 Sep 2012 13:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccDBZaBC0ZfY for ; Fri, 28 Sep 2012 13:39:03 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id B918D21F85A3 for ; Fri, 28 Sep 2012 13:38:55 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8SKcqTQ022987; Fri, 28 Sep 2012 16:38:52 -0400 (EDT) Received: from rtp-dhanes-8911.cisco.com (rtp-dhanes-8911.cisco.com [10.117.39.194]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8SKcpxj011709; Fri, 28 Sep 2012 16:38:51 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: David Hanes In-Reply-To: <23170_1348819872_50655BA0_23170_6953_2_88CAD1D4E8773F42858B58CAA28272A008C17C@PEXCVZYM12.corporate.adroot.infra.ftgroup> Date: Fri, 28 Sep 2012 16:38:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1317445A-E2EF-4ECE-AFB9-F630A302236B@cisco.com> References: <201209111858.q8BIwvvW006046@freeze.ariadne.com> <506326B5.7090009@alum.mit.edu> <48CAA1D0-A0DE-4D1E-816E-6BB22902B4AD@cisco.com> <54633A5E61DC84429CB9FE3D9143C72118008EA7@MBX.dialogic.com> <23170_1348819872_50655BA0_23170_6953_2_88CAD1D4E8773F42858B58CAA28272A008C17C@PEXCVZYM12.corporate.adroot.infra.ftgroup> To: X-Mailer: Apple Mail (2.1084) Cc: "Dale R. Worley" , DISPATCH Subject: Re: [dispatch] draft-hanes-dispatch-fax-capability-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 20:39:04 -0000 Hi Bruno, You are correct in that V.152 does propose G.726 as a passthrough codec = in addition to G.711. However, this draft only references sections 6 and = 6.1 of V.152 where G.726 is not mentioned and it states that a G.711 = variant is required at a minimum. Please correct me if I am wrong but in = real world scenarios I have only seen G.711 being used for passthrough = and that is why it is the codec explicitly defined. Are you recommending = that G.726 be included as an option in this draft? Or do you think we = need more clarification that G.711 is the only codec that we are = supporting based on the reference to V.152? Thanks, David On Sep 28, 2012, at 4:11 AM, wrote: > The proposed definition for the pass-through mode assumes that G.711 = is used as a voice-band codec. This is indeed the most likely = configuration. However, as far as I can remember, the pass-through mode = as described in V.152 is not restricted to G.711 (e.g. G.726 is possible = as well). > BC >=20 >> -----Message d'origine----- >> De : dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] De = la part >> de James Rafferty >> Envoy=C3=A9 : mercredi 26 septembre 2012 19:56 >> =C3=80 : Gonzalo Salgueiro; Paul Kyzivat >> Cc : Dale R. Worley; DISPATCH >> Objet : Re: [dispatch] draft-hanes-dispatch-fax-capability-02 >>=20 >> +1 >>=20 >> James >>=20 >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf >> Of Gonzalo Salgueiro >> Sent: Wednesday, September 26, 2012 12:22 PM >> To: Paul Kyzivat >> Cc: Dale R. Worley; DISPATCH >> Subject: Re: [dispatch] draft-hanes-dispatch-fax-capability-02 >>=20 >> +1 >>=20 >> Gonzalo >>=20 >> On Sep 26, 2012, at 12:00 PM, Paul Kyzivat wrote: >>=20 >>> This sounds pretty reasonable to me. >>>=20 >>> Thanks, >>> Paul >>>=20 >>> On 9/26/12 11:33 AM, David Hanes wrote: >>>> How about the following descriptions for T.38 and passthrough in = the IANA >> Considerations section? >>>>=20 >>>> t38: The device supports the image/t38 media type [RFC 3326] = and >> implements ITU-T T.38 for transporting the ITU-T T.30 and T.4 fax = data over >> IP. >>>>=20 >>>> passthrough: The device supports the audio/pcmu and audio/pcma = media >> types [RFC4856] for transporting ITU-T T.30 and T.4 fax data using = the ITU-T >> G.711 codec. Additional implementation recommendations are in ITU-T = V.152 >> Sections 6 and 6.1. >>>>=20 >>>> Thanks, >>>> David >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Sep 11, 2012, at 2:58 PM, Dale R. Worley wrote: >>>>=20 >>>>>> From: David Hanes >>>>>>>=20 >>>>>>> The "t38" value is better described as "supports the image/t38 >>>>>>> media type[RFC3362] which encodes page images using the ITU-T = T.38 >>>>>>> fax protocol[T.38]". That specifies the media type and adds a >>>>>>> reference to the RFC, which includes more details of the = specific >>>>>>> ITU recommendations involved. There are probably some >>>>>>> implications of what values of the T.38 SDP attributes are >>>>>>> supported -- is there a default set of attributes which = constitute >>>>>>> a baseline version of image/t38? >>>>>=20 >>>>> (I can't remember if in the past I mistakenly considered the fax >>>>> media type to be application/t38 (which was proposed in >>>>> ietf-mmusic-sdp-t38-00), but the fact that the fax media type is >>>>> image/t38 makes it impossible to use the +sip.app-subtype media >>>>> feature tag to select fax-capable UAs.) >>>>>=20 >>>>>> I like the image/t38 media and RFC specifics that you added above >>>>>> and I will include these updates in the next version. >>>>>=20 >>>>> Ideally, we should point to all the standards needed to define the >>>>> feature (although in practice, in many respects there is only one >>>>> practical way to implement this, so we could force people to = figure >>>>> things out for themselves). >>>>>=20 >>>>>> You also mention specific T.38 attributes. I am not aware of a >>>>>> default set of attribute values. It seems that each vendor has >>>>>> certain defaults but it is probably safe to say that many are >>>>>> commonly set the same. Thinking this through though, it seems = like >>>>>> the goal of this feature tag is to signal the preference that the >>>>>> call lands at a fax capable, or more specifically in this case, a >>>>>> T.38 capable UA. Once the T.38 capable UAs are connected, = shouldn't >>>>>> they handle the T.38 attribute exchange/negotiation within SDP? >>>>>> This is how it works now. It seems that just specifying T.38 = would >>>>>> be enough in this case and then the UAs can deal with the T.38 >> attribute settings within SDP. >>>>>=20 >>>>> Yes, I agree. >>>>>=20 >>>>> I wanted to ensure that +sip.fax would require a sufficient set of >>>>> image/t38 features (expressed as T38* attributes) that any two UAs >>>>> that met the specification would be able to communicate (at least >>>>> with a "baseline" capability). Otherwise there could be multiple, >>>>> incompatible groups of "sip.fax" UAs. That would indicate that = the >>>>> sip.fax values should be finer-grained than simply "t38". >>>>>=20 >>>>> But looking at the T.38 spec, annexes D and H, it appears to me = that >>>>> T.38 is designed for maximum negotiation and compatibility, and so >>>>> there should be little risk of incompatibility if we do not place >>>>> any requirements on the T38* attribute values that are supported. >>>>>=20 >>>>>>> The definition of "passthrough" is incomplete as it stands. The >>>>>>> meaning is "supports the audio/pcmu and audio/pcma media >>>>>>> types[RFC4856] for the transmission of fax images encoded >>>>>>> (somehow) as an analog audio stream, which is in turn encoded >>>>>>> using G.711". But what is the description of "somehow" and the = proper >> reference for it? >>>>>>=20 >>>>>> The "somehow" here is defined by ITU-T T.30, T.4, and T.6 and = these >>>>>> are modulated using common schemes like V.21 and V.17 so that the >>>>>> fax communication is now an analog stream. I am not sure that we >>>>>> need this level of detail though. This audio stream generation >>>>>> happens with every fax machine and gateway. Passthrough is very >>>>>> simple. We are just replacing human speech over G.711 with an >>>>>> analog fax stream. G.711 has been used on the PSTN for decades on >>>>>> T1/E1 spans for handling voice and fax. Basically, when we use = the >>>>>> term passthrough, we are saying treat fax like a G.711 voice = call. >>>>>> With that being said, wouldn't just referencing G.711 be enough >>>>>> from a media feature tag and user preference perspective? >>>>>>=20 >>>>>>> I don't know fax technologies well enough to know what it is, >>>>>>> though I'm certain that there is a specific standard intended = here. >>>>>=20 >>>>> As I see it, there is a series of decoding steps: >>>>>=20 >>>>> - from the incoming RTP packets, the stream of PCM octets is >>>>> extracted based on the RTP standards >>>>>=20 >>>>> - from the PCM octets, an analog signal is constructed via G.711 >>>>> (PCMA or PCMU) >>>>>=20 >>>>> - from the analog signal, a bit stream is constructed via >>>>> V.21/V.17/V.* >>>>>=20 >>>>> - from the bit stream, a fax image is constructed via T.30/T.4/T.6 >>>>>=20 >>>>> and encoding is done in the reverse order. >>>>>=20 >>>>> So to specify how meaning is encoded in the packets, you need to >>>>> specify that entire stack of standards. Or, to ensure >>>>> interoperability, you have to require implementation of a minimal >>>>> subset of all those choices. >>>>>=20 >>>>> The reality is a bit messier, I think, because machines probably >>>>> negotiate which "modem" protocol they use (V.21, etc.), and they = may >>>>> negotiate which fax encoding they use. >>>>>=20 >>>>> But since fax machines work in practice, there is a standard (or a >>>>> ubiquitous de-facto standard) that specifies the two higher levels >>>>> of the encoding stack. >>>>>=20 >>>>> So I think it is necessary to provide specification of the two >>>>> higher levels, the "modem" encoding and the page encoding. But I >>>>> strongly suspect that there are standards or well-understood BCPs >>>>> that can be referenced -- without excluding any practical >>>>> implementation from being in conformance with "sip.fax". >>>>>=20 >>>>>>> Do we want to require PCMU and PCMA support, or PCMU *or* PCMA >>>>>>> support? >>>>>>=20 >>>>>> As with the T.38 SDP attributes, is this something that we want = to >>>>>> address in this draft or just leave it to the SDP portion? With >>>>>> only 2 codec options, you could have "passthrough-g711=CE=BC" and >>>>>> "passthrough-g711a" values. However, in reality most folks >>>>>> implementing passthrough will accept either G.711 variety. >>>>>=20 >>>>> As I said above, I want to ensure that if a call that specifies >>>>> "sip.fax" arrives at a UA that registers with "sip.fax", then the >>>>> fax call will succeed in practice. Otherwise, defining sip.fax >>>>> hasn't gained what we want. >>>>>=20 >>>>> But given that every SIP G.711 implementation I've ever seen >>>>> supports both PCMU and PCMA, I would suggest that we require = *both* >>>>> as part of the definition. With that, the definition ensures >>>>> interoperability, but it does not (in practice) further constrain = any >> implementation. >>>>>=20 >>>>>>> What encoding parameter values are required for support? I = expect >>>>>>> we want to add that the audio stream is single-channel and we >>>>>>> probably want to specify that it is at 8000Hz sample rate. >>>>>=20 >>>>> Or perhaps those parameters are effectively fixed by T.4/T.6/T.30 >>>>> (regarding channels) and G.711 (for the bitrate). >>>>>=20 >>>>>>> Also, the reference to the T.38 spec is given as informative, >>>>>>> whereas it is used normatively. >>>>>>=20 >>>>>> Thanks. I will get that fixed in the next version. >>>>>=20 >>>>> Dale >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>>=20 >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a = ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch