From fluffy@cisco.com Fri Oct 1 10:07:56 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 968283A6CF5 for ; Fri, 1 Oct 2010 10:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.507 X-Spam-Level: X-Spam-Status: No, score=-110.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXMtj1AjSIkP for ; Fri, 1 Oct 2010 10:07:55 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 03A173A6D0D for ; Fri, 1 Oct 2010 10:07:55 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAE+ypUyrR7Ht/2dsb2JhbACiOHGraZw3hUQEhFGFa4MC X-IronPort-AV: E=Sophos;i="4.57,267,1283731200"; d="scan'208";a="367267801" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 01 Oct 2010 17:08:35 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o91H8YTL010534 for ; Fri, 1 Oct 2010 17:08:34 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 1 Oct 2010 11:08:34 -0600 Message-Id: <96093D65-B54D-4CFE-821C-0630AF2DCF9E@cisco.com> To: DISPATCH list Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [dispatch] time for next meeting X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 17:07:56 -0000 This time could change but FYI ... DISPATCH Session 1 (2 hours) Thursday, Afternoon Session II 1520-1720 Room Name: Valley Ballroom C ---------------------------------------------- From gao.yang2@zte.com.cn Sun Oct 10 19:18:05 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E6593A68B9 for ; Sun, 10 Oct 2010 19:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.419 X-Spam-Level: X-Spam-Status: No, score=-100.419 tagged_above=-999 required=5 tests=[AWL=1.419, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlhP2v3jM6wY for ; Sun, 10 Oct 2010 19:18:04 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 086AC3A68B8 for ; Sun, 10 Oct 2010 19:18:00 -0700 (PDT) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 3510992332426; Mon, 11 Oct 2010 10:17:53 +0800 (CST) Received: from [10.32.0.74] by [192.168.168.15] with StormMail ESMTP id 55813.3501342888; Mon, 11 Oct 2010 10:19:07 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse3.zte.com.cn with ESMTP id o9B2IYUx083557; Mon, 11 Oct 2010 10:18:50 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) To: "dispatch@ietf.org" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 11 Oct 2010 10:16:38 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-10-11 10:18:44, Serialize complete at 2010-10-11 10:18:44 Content-Type: multipart/alternative; boundary="=_alternative 000CB19E482577B9_=" X-MAIL: mse3.zte.com.cn o9B2IYUx083557 Cc: drsubirsaha@yahoo.com Subject: [dispatch] Comments on draft-avasarala-dispatch-comm-div-notification-05 //About forking X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 02:18:05 -0000 This is a multipart message in MIME format. --=_alternative 000CB19E482577B9_= Content-Type: text/plain; charset="US-ASCII" In our implementation(the background system is IMS) of this draft, we find one problem about forking. In section 6.9(Handling of Forked Requests) of this draft: This specification only allows a single dialog to be constructed as a result of emitting an initial SUBSCRIBE request. This guarantees that only a single notifier is generating notifications for a particular subscription to a particular user. we could find that forked subscription is forbidden for this Event package. While in real IMS network, there are cases the div-services are deployed in different ASs. Then, the subscription should be forked to the different ASs, if there are more than one AS do div-services for the specific service user. We once considered one way to avoid the forking condition. The way is to let the user send different subscription for different div-service. But by the end user's viewpoint, he/she have no idea of the deployment of the div-servies(in ASs). So, he/she does't know when should he/she send separated subscription or not. So, I suggest to allow forking for this Event package. Thanks, Gao =================================== Zip : 210012 Tel : 87211 Tel2 :(+86)-025-52877211 e_mail : gao.yang2@zte.com.cn =================================== -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 000CB19E482577B9_= Content-Type: text/html; charset="US-ASCII"
In our implementation(the background system is IMS) of this draft, we find one problem about forking.

In section 6.9(Handling of Forked Requests) of this draft:

This specification only allows a single dialog to be constructed as a
   result of emitting an initial SUBSCRIBE request.  This guarantees
   that only a single notifier is generating notifications for a
   particular subscription to a particular user.

we could find that forked subscription is forbidden for this Event package.

While in real IMS network, there are cases the div-services are deployed in different ASs. Then, the subscription should be forked to the different ASs, if there are more than one AS do div-services for the specific service user.

We once considered one way to avoid the forking condition. The way is to let the user send different subscription for different div-service. But by the end user's viewpoint, he/she have no idea of the deployment of the div-servies(in ASs). So, he/she does't know when should he/she send separated subscription or not.  

So, I suggest to allow forking for this Event package.

Thanks,

Gao

===================================
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2@zte.com.cn
===================================
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 000CB19E482577B9_=-- From ranjit@motorola.com Tue Oct 12 04:52:25 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C74C73A695A for ; Tue, 12 Oct 2010 04:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.439 X-Spam-Level: X-Spam-Status: No, score=-6.439 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2W0rZrHVmsFx for ; Tue, 12 Oct 2010 04:52:23 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id 11E883A692E for ; Tue, 12 Oct 2010 04:52:21 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-6.tower-119.messagelabs.com!1286884414!38456058!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 10572 invoked from network); 12 Oct 2010 11:53:35 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Oct 2010 11:53:35 -0000 Received: from il27exr03.cig.mot.com ([10.17.196.72]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id o9CBrYdU022728 for ; Tue, 12 Oct 2010 04:53:34 -0700 (MST) Received: from il27vts03 (il27vts03.cig.mot.com [10.17.196.87]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id o9CBpYig017011 for ; Tue, 12 Oct 2010 06:51:34 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id o9CBpWPO016958 for ; Tue, 12 Oct 2010 06:51:33 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB6A03.C358AFDF" Date: Tue, 12 Oct 2010 19:51:10 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0ABAB06D@ZMY16EXM66.ds.mot.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-avasarala-dispatch-comm-div-notification-05 //About forking thread-index: Acto6rWw6S2QoKm2TbWiMNC25QOtNQBGMM7w References: From: "Avasarala Ranjit-A20990" To: , X-CFilter-Loop: Reflected Cc: drsubirsaha@yahoo.com Subject: Re: [dispatch] Comments on draft-avasarala-dispatch-comm-div-notification-05 //About forking X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 11:52:25 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB6A03.C358AFDF Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi =20 Yes we did not want to support forking for the CDIV package since the CDIV notification is only intended for the subscriber who subscribed it .=20 =20 Regards Ranjit =20 From: gao.yang2@zte.com.cn [mailto:gao.yang2@zte.com.cn]=20 Sent: Monday, October 11, 2010 7:47 AM To: dispatch@ietf.org Cc: Avasarala Ranjit-A20990; jbakker@rim.com; drsubirsaha@yahoo.com Subject: Comments on draft-avasarala-dispatch-comm-div-notification-05 //About forking =20 In our implementation(the background system is IMS) of this draft, we find one problem about forking.=20 In section 6.9(Handling of Forked Requests) of this draft:=20 This specification only allows a single dialog to be constructed as a=20 result of emitting an initial SUBSCRIBE request. This guarantees=20 that only a single notifier is generating notifications for a=20 particular subscription to a particular user.=20 we could find that forked subscription is forbidden for this Event package.=20 While in real IMS network, there are cases the div-services are deployed in different ASs. Then, the subscription should be forked to the different ASs, if there are more than one AS do div-services for the specific service user.=20 We once considered one way to avoid the forking condition. The way is to let the user send different subscription for different div-service. But by the end user's viewpoint, he/she have no idea of the deployment of the div-servies(in ASs). So, he/she does't know when should he/she send separated subscription or not. =20 So, I suggest to allow forking for this Event package.=20 Thanks,=20 Gao=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Zip : 210012 Tel : 87211 Tel2 :(+86)-025-52877211 e_mail : gao.yang2@zte.com.cn =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. ------_=_NextPart_001_01CB6A03.C358AFDF Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi

 

Yes we did not want to support forking for the CDIV = package since the CDIV notification is only intended for the subscriber who = subscribed it .

 

Regards

Ranjit

 

From:= = gao.yang2@zte.com.cn [mailto:gao.yang2@zte.com.cn]
Sent: Monday, October 11, 2010 7:47 AM
To: dispatch@ietf.org
Cc: Avasarala Ranjit-A20990; jbakker@rim.com; = drsubirsaha@yahoo.com
Subject: Comments on = draft-avasarala-dispatch-comm-div-notification-05 //About forking

 


In our implementation(the background system is IMS) of this draft, we find one = problem about forking.

In = section 6.9(Handling of Forked Requests) of this draft:

This specification only allows a single dialog to be constructed as a =
   result of emitting an initial SUBSCRIBE request.  This = guarantees
   that only a single notifier is generating notifications for = a
   particular subscription to a particular user.

we = could find that forked subscription is forbidden for this Event package. =

While = in real IMS network, there are cases the div-services are deployed in different = ASs. Then, the subscription should be forked to the different ASs, if there = are more than one AS do div-services for the specific service user.

We = once considered one way to avoid the forking condition. The way is to let the = user send different subscription for different div-service. But by the end = user's viewpoint, he/she have no idea of the deployment of the div-servies(in = ASs). So, he/she does't know when should he/she send separated subscription or = not.  

So, I = suggest to allow forking for this Event package.

Thanks,

Gao =

=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2@zte.com.cn
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 
----------------------------------------=
----------------
ZTE Information Security&=
nbsp;Notice: The information contained in this&n=
bsp;mail is solely property of the sender's=
 organization. This mail communication is c=
onfidential. Recipients named above are obligate=
d to maintain secrecy and are not perm=
itted to disclose the contents of this =
;communication to others.
This email&=
nbsp;and any files transmitted with it are&=
nbsp;confidential and intended solely for the&nb=
sp;use of the individual or entity to =
whom they are addressed. If you have r=
eceived this email in error please notify&n=
bsp;the originator of the message. Any view=
s expressed in this message are those =
of the individual sender.
This m=
essage has been scanned for viruses and&nbs=
p;Spam by ZTE Anti-Spam system.
------_=_NextPart_001_01CB6A03.C358AFDF-- From gao.yang2@zte.com.cn Tue Oct 12 06:04:25 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 103703A67AE for ; Tue, 12 Oct 2010 06:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.248 X-Spam-Level: X-Spam-Status: No, score=-98.248 tagged_above=-999 required=5 tests=[AWL=-0.613, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXFZnIWANyur for ; Tue, 12 Oct 2010 06:04:23 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 113273A67D3 for ; Tue, 12 Oct 2010 06:04:22 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 20595992332426; Tue, 12 Oct 2010 21:03:05 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 38058.3501342888; Tue, 12 Oct 2010 21:02:57 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o9CD1vG0084987; Tue, 12 Oct 2010 21:01:57 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0ABAB06D@ZMY16EXM66.ds.mot.com> To: "Avasarala Ranjit-A20990" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 12 Oct 2010 20:59:31 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-10-12 21:01:38, Serialize complete at 2010-10-12 21:01:38 Content-Type: multipart/alternative; boundary="=_alternative 00478D54482577BA_=" X-MAIL: mse2.zte.com.cn o9CD1vG0084987 Cc: dispatch@ietf.org, drsubirsaha@yahoo.com Subject: Re: [dispatch] Comments on draft-avasarala-dispatch-comm-div-notification-05 //About forking X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 13:04:25 -0000 This is a multipart message in MIME format. --=_alternative 00478D54482577BA_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgUmFuaml0LA0KDQpJJ2QgbGlrZSB0byBwb2ludCBvdXQgSSBoYWQgb2ZmZXJlZCBvbmUgcmVh bCByZXF1aXJlbWVudCBhYm91dCBzdXBwb3J0aW5nIA0KZm9ya2luZyBmb3IgdGhpcyBFdmVudCBw YWNrYWdlLiBJTU8sIGl0IGlzIHJlYXNvbmFibGUgdG8gc3VwcG9ydGluZyANCmZvcmtpbmcgaGVy ZS4NCg0KVGhhbmtzLA0KDQpHYW8NCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0NCiBaaXAgICAgOiAyMTAwMTINCiBUZWwgICAgOiA4NzIxMQ0KIFRlbDIgICA6KCs4NiktMDI1 LTUyODc3MjExDQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY24NCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09DQoNCg0KDQoiQXZhc2FyYWxhIFJhbmppdC1BMjA5OTAiIDxy YW5qaXRAbW90b3JvbGEuY29tPiANCjIwMTAtMTAtMTIgMTk6NTENCg0KytW8/sjLDQo8Z2FvLnlh bmcyQHp0ZS5jb20uY24+LCA8ZGlzcGF0Y2hAaWV0Zi5vcmc+DQqzrcvNDQo8amJha2tlckByaW0u Y29tPiwgPGRyc3ViaXJzYWhhQHlhaG9vLmNvbT4NCtb3zOINClJFOiBDb21tZW50cyBvbiBkcmFm dC1hdmFzYXJhbGEtZGlzcGF0Y2gtY29tbS1kaXYtbm90aWZpY2F0aW9uLTA1ICAvL0Fib3V0IA0K Zm9ya2luZw0KDQoNCg0KDQoNCg0KSGkNCiANClllcyB3ZSBkaWQgbm90IHdhbnQgdG8gc3VwcG9y dCBmb3JraW5nIGZvciB0aGUgQ0RJViBwYWNrYWdlIHNpbmNlIHRoZSBDRElWIA0Kbm90aWZpY2F0 aW9uIGlzIG9ubHkgaW50ZW5kZWQgZm9yIHRoZSBzdWJzY3JpYmVyIHdobyBzdWJzY3JpYmVkIGl0 IC4gDQogDQpSZWdhcmRzDQpSYW5qaXQNCiANCkZyb206IGdhby55YW5nMkB6dGUuY29tLmNuIFtt YWlsdG86Z2FvLnlhbmcyQHp0ZS5jb20uY25dIA0KU2VudDogTW9uZGF5LCBPY3RvYmVyIDExLCAy MDEwIDc6NDcgQU0NClRvOiBkaXNwYXRjaEBpZXRmLm9yZw0KQ2M6IEF2YXNhcmFsYSBSYW5qaXQt QTIwOTkwOyBqYmFra2VyQHJpbS5jb207IGRyc3ViaXJzYWhhQHlhaG9vLmNvbQ0KU3ViamVjdDog Q29tbWVudHMgb24gZHJhZnQtYXZhc2FyYWxhLWRpc3BhdGNoLWNvbW0tZGl2LW5vdGlmaWNhdGlv bi0wNSANCi8vQWJvdXQgZm9ya2luZw0KIA0KDQpJbiBvdXIgaW1wbGVtZW50YXRpb24odGhlIGJh Y2tncm91bmQgc3lzdGVtIGlzIElNUykgb2YgdGhpcyBkcmFmdCwgd2UgZmluZCANCm9uZSBwcm9i bGVtIGFib3V0IGZvcmtpbmcuIA0KDQpJbiBzZWN0aW9uIDYuOShIYW5kbGluZyBvZiBGb3JrZWQg UmVxdWVzdHMpIG9mIHRoaXMgZHJhZnQ6IA0KDQpUaGlzIHNwZWNpZmljYXRpb24gb25seSBhbGxv d3MgYSBzaW5nbGUgZGlhbG9nIHRvIGJlIGNvbnN0cnVjdGVkIGFzIGEgDQogICByZXN1bHQgb2Yg ZW1pdHRpbmcgYW4gaW5pdGlhbCBTVUJTQ1JJQkUgcmVxdWVzdC4gIFRoaXMgZ3VhcmFudGVlcyAN CiAgIHRoYXQgb25seSBhIHNpbmdsZSBub3RpZmllciBpcyBnZW5lcmF0aW5nIG5vdGlmaWNhdGlv bnMgZm9yIGEgDQogICBwYXJ0aWN1bGFyIHN1YnNjcmlwdGlvbiB0byBhIHBhcnRpY3VsYXIgdXNl ci4gDQoNCndlIGNvdWxkIGZpbmQgdGhhdCBmb3JrZWQgc3Vic2NyaXB0aW9uIGlzIGZvcmJpZGRl biBmb3IgdGhpcyBFdmVudCANCnBhY2thZ2UuIA0KDQpXaGlsZSBpbiByZWFsIElNUyBuZXR3b3Jr LCB0aGVyZSBhcmUgY2FzZXMgdGhlIGRpdi1zZXJ2aWNlcyBhcmUgZGVwbG95ZWQgDQppbiBkaWZm ZXJlbnQgQVNzLiBUaGVuLCB0aGUgc3Vic2NyaXB0aW9uIHNob3VsZCBiZSBmb3JrZWQgdG8gdGhl IGRpZmZlcmVudCANCkFTcywgaWYgdGhlcmUgYXJlIG1vcmUgdGhhbiBvbmUgQVMgZG8gZGl2LXNl cnZpY2VzIGZvciB0aGUgc3BlY2lmaWMgDQpzZXJ2aWNlIHVzZXIuIA0KDQpXZSBvbmNlIGNvbnNp ZGVyZWQgb25lIHdheSB0byBhdm9pZCB0aGUgZm9ya2luZyBjb25kaXRpb24uIFRoZSB3YXkgaXMg dG8gDQpsZXQgdGhlIHVzZXIgc2VuZCBkaWZmZXJlbnQgc3Vic2NyaXB0aW9uIGZvciBkaWZmZXJl bnQgZGl2LXNlcnZpY2UuIEJ1dCBieSANCnRoZSBlbmQgdXNlcidzIHZpZXdwb2ludCwgaGUvc2hl IGhhdmUgbm8gaWRlYSBvZiB0aGUgZGVwbG95bWVudCBvZiB0aGUgDQpkaXYtc2VydmllcyhpbiBB U3MpLiBTbywgaGUvc2hlIGRvZXMndCBrbm93IHdoZW4gc2hvdWxkIGhlL3NoZSBzZW5kIA0Kc2Vw YXJhdGVkIHN1YnNjcmlwdGlvbiBvciBub3QuICAgDQoNClNvLCBJIHN1Z2dlc3QgdG8gYWxsb3cg Zm9ya2luZyBmb3IgdGhpcyBFdmVudCBwYWNrYWdlLiANCg0KVGhhbmtzLCANCg0KR2FvIA0KDQo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KWmlwICAgIDogMjEwMDEyDQpUZWwg ICAgOiA4NzIxMQ0KVGVsMiAgIDooKzg2KS0wMjUtNTI4NzcyMTENCmVfbWFpbCA6IGdhby55YW5n MkB6dGUuY29tLmNuDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KIA0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpU RSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQg aW4gdGhpcyBtYWlsIGlzIA0Kc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6 YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIA0KY29uZmlkZW50aWFsLiBSZWNpcGll bnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgDQph cmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5p Y2F0aW9uIHRvIA0Kb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVk IHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgDQpzb2xlbHkgZm9yIHRoZSB1 c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2Vk LiANCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlm eSB0aGUgb3JpZ2luYXRvciBvZiANCnRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGlu IHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIA0KaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlz IG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50 aS1TcGFtIA0Kc3lzdGVtLg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6 IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0 eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBp cyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBt YWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29u dGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFu eSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVk IHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0 aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJy b3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdz IGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNl bmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFt IGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 00478D54482577BA_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFJhbmppdCw8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkknZCBsaWtlIHRvIHBvaW50 IG91dCBJIGhhZCBvZmZlcmVkDQpvbmUgcmVhbCByZXF1aXJlbWVudCBhYm91dCBzdXBwb3J0aW5n IGZvcmtpbmcgZm9yIHRoaXMgRXZlbnQgcGFja2FnZS4gSU1PLA0KaXQgaXMgcmVhc29uYWJsZSB0 byBzdXBwb3J0aW5nIGZvcmtpbmcgaGVyZS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyw8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPkdhbzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQog WmlwICZuYnNwOyAmbmJzcDs6IDIxMDAxMjxicj4NCiBUZWwgJm5ic3A7ICZuYnNwOzogODcyMTE8 YnI+DQogVGVsMiAmbmJzcDsgOigrODYpLTAyNS01Mjg3NzIxMTxicj4NCiBlX21haWwgOiBnYW8u eWFuZzJAenRlLmNvbS5jbjxicj4NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZCB3aWR0aD0zNSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPiZx dW90O0F2YXNhcmFsYSBSYW5qaXQtQTIwOTkwJnF1b3Q7DQombHQ7cmFuaml0QG1vdG9yb2xhLmNv bSZndDs8L2I+IDwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEw LTEwLTEyIDE5OjUxPC9mb250Pg0KPHRkIHdpZHRoPTY0JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0K PHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPiZsdDtnYW8ueWFuZzJAenRlLmNvbS5jbiZndDssICZsdDtkaXNwYXRjaEBp ZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmln aHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZsdDtqYmFra2VyQHJpbS5jb20mZ3Q7LCAm bHQ7ZHJzdWJpcnNhaGFAeWFob28uY29tJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwv Zm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UkU6IENvbW1l bnRzIG9uIGRyYWZ0LWF2YXNhcmFsYS1kaXNwYXRjaC1jb21tLWRpdi1ub3RpZmljYXRpb24tMDUN CiZuYnNwOy8vQWJvdXQgZm9ya2luZzwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRy IHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPkhpPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj5ZZXMg d2UgZGlkIG5vdCB3YW50IHRvIHN1cHBvcnQNCmZvcmtpbmcgZm9yIHRoZSBDRElWIHBhY2thZ2Ug c2luY2UgdGhlIENESVYgbm90aWZpY2F0aW9uIGlzIG9ubHkgaW50ZW5kZWQNCmZvciB0aGUgc3Vi c2NyaWJlciB3aG8gc3Vic2NyaWJlZCBpdCAuIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29s b3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+UmVnYXJkczwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgY29sb3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj5SYW5qaXQ8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPkZyb206PC9iPiBnYW8ueWFuZzJAenRlLmNv bS5jbiBbbWFpbHRvOmdhby55YW5nMkB6dGUuY29tLmNuXQ0KPGI+PGJyPg0KU2VudDo8L2I+IE1v bmRheSwgT2N0b2JlciAxMSwgMjAxMCA3OjQ3IEFNPGI+PGJyPg0KVG86PC9iPiBkaXNwYXRjaEBp ZXRmLm9yZzxiPjxicj4NCkNjOjwvYj4gQXZhc2FyYWxhIFJhbmppdC1BMjA5OTA7IGpiYWtrZXJA cmltLmNvbTsgZHJzdWJpcnNhaGFAeWFob28uY29tPGI+PGJyPg0KU3ViamVjdDo8L2I+IENvbW1l bnRzIG9uIGRyYWZ0LWF2YXNhcmFsYS1kaXNwYXRjaC1jb21tLWRpdi1ub3RpZmljYXRpb24tMDUN Ci8vQWJvdXQgZm9ya2luZzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+ DQpJbiBvdXIgaW1wbGVtZW50YXRpb24odGhlIGJhY2tncm91bmQgc3lzdGVtIGlzIElNUykgb2Yg dGhpcyBkcmFmdCwgd2UgZmluZA0Kb25lIHByb2JsZW0gYWJvdXQgZm9ya2luZy48L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXpl PTIgZmFjZT0iQXJpYWwiPjxicj4NCkluIHNlY3Rpb24gNi45KEhhbmRsaW5nIG9mIEZvcmtlZCBS ZXF1ZXN0cykgb2YgdGhpcyBkcmFmdDo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpU aGlzIHNwZWNpZmljYXRpb24gb25seSBhbGxvd3MgYSBzaW5nbGUgZGlhbG9nIHRvIGJlIGNvbnN0 cnVjdGVkIGFzIGE8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQogJm5ic3A7IHJlc3VsdCBvZiBl bWl0dGluZyBhbiBpbml0aWFsIFNVQlNDUklCRSByZXF1ZXN0LiAmbmJzcDtUaGlzIGd1YXJhbnRl ZXM8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZv bnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQogJm5ic3A7IHRoYXQgb25seSBhIHNpbmdsZSBu b3RpZmllciBpcyBnZW5lcmF0aW5nIG5vdGlmaWNhdGlvbnMgZm9yIGE8L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFy aWFsIj48YnI+DQogJm5ic3A7IHBhcnRpY3VsYXIgc3Vic2NyaXB0aW9uIHRvIGEgcGFydGljdWxh ciB1c2VyLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjxicj4N CjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCndlIGNvdWxkIGZpbmQgdGhh dCBmb3JrZWQgc3Vic2NyaXB0aW9uIGlzIGZvcmJpZGRlbiBmb3IgdGhpcyBFdmVudCBwYWNrYWdl LjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjxicj4NCjwvZm9u dD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCldoaWxlIGluIHJlYWwgSU1TIG5ldHdv cmssIHRoZXJlIGFyZSBjYXNlcyB0aGUgZGl2LXNlcnZpY2VzIGFyZSBkZXBsb3llZA0KaW4gZGlm ZmVyZW50IEFTcy4gVGhlbiwgdGhlIHN1YnNjcmlwdGlvbiBzaG91bGQgYmUgZm9ya2VkIHRvIHRo ZSBkaWZmZXJlbnQNCkFTcywgaWYgdGhlcmUgYXJlIG1vcmUgdGhhbiBvbmUgQVMgZG8gZGl2LXNl cnZpY2VzIGZvciB0aGUgc3BlY2lmaWMgc2VydmljZQ0KdXNlci48L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0i QXJpYWwiPjxicj4NCldlIG9uY2UgY29uc2lkZXJlZCBvbmUgd2F5IHRvIGF2b2lkIHRoZSBmb3Jr aW5nIGNvbmRpdGlvbi4gVGhlIHdheSBpcyB0bw0KbGV0IHRoZSB1c2VyIHNlbmQgZGlmZmVyZW50 IHN1YnNjcmlwdGlvbiBmb3IgZGlmZmVyZW50IGRpdi1zZXJ2aWNlLiBCdXQNCmJ5IHRoZSBlbmQg dXNlcidzIHZpZXdwb2ludCwgaGUvc2hlIGhhdmUgbm8gaWRlYSBvZiB0aGUgZGVwbG95bWVudCBv ZiB0aGUNCmRpdi1zZXJ2aWVzKGluIEFTcykuIFNvLCBoZS9zaGUgZG9lcyd0IGtub3cgd2hlbiBz aG91bGQgaGUvc2hlIHNlbmQgc2VwYXJhdGVkDQpzdWJzY3JpcHRpb24gb3Igbm90LiAmbmJzcDs8 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8YnI+DQo8L2ZvbnQ+ PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpTbywgSSBzdWdnZXN0IHRvIGFsbG93IGZv cmtpbmcgZm9yIHRoaXMgRXZlbnQgcGFja2FnZS48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48 YnI+DQpUaGFua3MsPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8 YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpHYW88L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXpl PTIgZmFjZT0iQXJpYWwiPjxicj4NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PGJyPg0KWmlwICZuYnNwOyAmbmJzcDs6IDIxMDAxMjxicj4NClRlbCAmbmJzcDsgJm5ic3A7OiA4 NzIxMTxicj4NClRlbDIgJm5ic3A7IDooKzg2KS0wMjUtNTI4NzcyMTE8YnI+DQplX21haWwgOiBn YW8ueWFuZzJAenRlLmNvbS5jbjxicj4NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+LS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5aVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90 aWNlOiBUaGUNCmluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHBy b3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uDQpUaGlzIG1haWwgY29tbXVuaWNh dGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRl ZA0KdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2Ug dGhlIGNvbnRlbnRzIG9mIHRoaXMNCmNvbW11bmljYXRpb24gdG8gb3RoZXJzLjwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPlRoaXMgZW1haWwgYW5kIGFueSBmaWxl cyB0cmFuc21pdHRlZA0Kd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xl bHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwNCm9yIGVudGl0eSB0byB3aG9tIHRoZXkg YXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbg0KZXJyb3Ig cGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4 cHJlc3NlZA0KaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5k ZXIuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+VGhpcyBtZXNz YWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMNCmFuZCBTcGFtIGJ5IFpURSBBbnRpLVNw YW0gc3lzdGVtLjwvZm9udD4NCjxicj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9u Jm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJz cDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xl bHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdh bml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMm bmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUm bmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVj eSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7 ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2Nv bW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2Fu ZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQm bmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3Nv bGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5k aXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZu YnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDty ZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVh c2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUm bmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4m bmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0 aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDto YXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQm bmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8 L3ByZT4= --=_alternative 00478D54482577BA_=-- From magnus.westerlund@ericsson.com Tue Oct 12 06:45:51 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20A493A67F4 for ; Tue, 12 Oct 2010 06:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.476 X-Spam-Level: X-Spam-Status: No, score=-106.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qGSwPotCTsu for ; Tue, 12 Oct 2010 06:45:50 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id B58563A67EA for ; Tue, 12 Oct 2010 06:45:49 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae000006ad7-ce-4cb466d67f17 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 25.82.27351.6D664BC4; Tue, 12 Oct 2010 15:47:02 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Oct 2010 15:47:01 +0200 Received: from [147.214.183.82] ([147.214.183.82]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Oct 2010 15:47:01 +0200 Message-ID: <4CB466D5.8060601@ericsson.com> Date: Tue, 12 Oct 2010 15:47:01 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: dispatch@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 12 Oct 2010 13:47:01.0675 (UTC) FILETIME=[F291B7B0:01CB6A13] X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] Comments on the proposed Telepresence Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 13:45:51 -0000 Hi, Some colleagues and I have reviewed the two telepresence drafts and version 5 of the charter and have some comments on the charter. To make our comments more understandable I think we should explain our view on telepresence. First we are expecting great variations in the capabilities of the participating terminals in a session. From personal terminals for individual users up to multi-display, cameras and microphone setups. We also expect that more than two end-points being present in the same session. As we see it it will require good support for centralized media handling in a mixer (MCU). We also see video streams not only of high quality to be presented for maximum immersion, but also lower qualities that can be used to monitor activity in other rooms that aren't the ones selected for high quality. Independent if one uses a central mixer or a full mesh there appears to be a lack in media stream negotiation for how to negotiate what capabilities the receiving client has in receiving, decoding and rendering when it comes to number of simultaneous streams. Our understanding is that RTP mandates any number of streams, while in reality outside of conferencing that is in fact one single stream. However with telepresence and conferencing there is a need to negotiate the actual capability, especially between a mixer and client when it comes to deliver multiple streams for various usages. We also think there is missing functionality for expressing who are the currently active speakers. The RTP CSRC field are not sufficient as they express which end-points are included in the mix. However, as one likely include in a mix more rooms than the active speakers to ensure that any interruption and ambient sound are correctly captured an mechanism for indicating the currently active speakers are needed. There is also need to agree on the type of identifier to be used that allow for mapping to full user names when appropriate. The charter includes an item to work on control between client and a mixer what streams should be delivered. We would like to extended this to allow also the mixer to control the client on when streams are delivered. In cases where there are more users then available display area and a particular user is not actually included in any outgoing mix/selection from the mixer then there is little point in that the client consumes network resources. Thus we suggest that the stream selection and control work is extended to allow also the mixer to pause individual streams from the client to the mixer. Please note that such control needs to be responsive, thus using the SIP signaling path for this is to slow, it needs to be on the media path. Another question to the group is, are there agreement on how streams should organized into RTP sessions and how they are utilized? If anything is documented I would appreciate a pointer. The media streams are for different purposes from different end-points which are then mixed by a central point and delivered to end-points. My impression for example is that most proprietary system breaks the RTP semantics and use individual sessions between the mixer and each end-point, instead of a joint session. Here also different robustification tools for RTP such as FEC and Retransmission needs to be considered. This might be work that belongs in AVT, but are there need for further clarification into this field? Comments much appreciated and we can gladly suggest text additions to the charter proposal. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From peter.musgrave@magorcorp.com Tue Oct 12 08:35:52 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51F673A63EB for ; Tue, 12 Oct 2010 08:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.853 X-Spam-Level: X-Spam-Status: No, score=-101.853 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ub8OE2Fu9hds for ; Tue, 12 Oct 2010 08:35:51 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id E49D43A6996 for ; Tue, 12 Oct 2010 08:35:50 -0700 (PDT) Received: by qwc9 with SMTP id 9so2459812qwc.31 for ; Tue, 12 Oct 2010 08:37:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.174.138 with SMTP id t10mr5793041qaz.265.1286897824981; Tue, 12 Oct 2010 08:37:04 -0700 (PDT) Received: by 10.229.42.196 with HTTP; Tue, 12 Oct 2010 08:37:04 -0700 (PDT) In-Reply-To: <4CB466D5.8060601@ericsson.com> References: <4CB466D5.8060601@ericsson.com> Date: Tue, 12 Oct 2010 11:37:04 -0400 Message-ID: From: Peter Musgrave To: Magnus Westerlund Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dispatch@ietf.org Subject: Re: [dispatch] Comments on the proposed Telepresence Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 15:35:52 -0000 Hi Magnus, I concur with your viewpoints on highly diverse endpoints, multi-point (up to and including mesh connections). I have more specific comments inline. There is only one point below which I think requires language in the charter. Please see if you agree. Regards, Peter Musgrave On Tue, Oct 12, 2010 at 9:47 AM, Magnus Westerlund wrote: > Hi, > > Some colleagues and I have reviewed the two telepresence drafts and > version 5 of the charter and have some comments on the charter. > > To make our comments more understandable I think we should explain our > view on telepresence. First we are expecting great variations in the > capabilities of the participating terminals in a session. From personal > terminals for individual users up to multi-display, cameras and > microphone setups. We also expect that more than two end-points being > present in the same session. As we see it it will require good support > for centralized media handling in a mixer (MCU). We also see video > streams not only of high quality to be presented for maximum immersion, > but also lower qualities that can be used to monitor activity in other > rooms that aren't the ones selected for high quality. Agreed. > > Independent if one uses a central mixer or a full mesh there appears to > be a lack in media stream negotiation for how to negotiate what > capabilities the receiving client has in receiving, decoding and > rendering when it comes to number of simultaneous streams. Our > understanding is that RTP mandates any number of streams, while in > reality outside of conferencing that is in fact one single stream. > However with telepresence and conferencing there is a need to negotiate > the actual capability, especially between a mixer and client when it > comes to deliver multiple streams for various usages. Agreed. The charter does speak to identifying endpoint capabilities and I view what you describe here as the kind of meta-information which needs to fit into that framework. > > We also think there is missing functionality for expressing who are the > currently active speakers. The RTP CSRC field are not sufficient as they > express which end-points are included in the mix. However, as one likely > include in a mix more rooms than the active speakers to ensure that any > interruption and ambient sound are correctly captured an mechanism for > indicating the currently active speakers are needed. There is also need > to agree on the type of identifier to be used that allow for mapping to > full user names when appropriate. I agree with this. In my opinion this is a separable problem since it applies to generic audio conferencing as well. There is tangential work in the conference event package and probably in the XCON stuff - but I lack detailed background in XCON. In the context of the TP charter I think the work on indicating which audio stream is associated with which speaker (or part of the room) is a slightly different issue - since it's about which stream and not which speaker within a stream. > > The charter includes an item to work on control between client and a > mixer what streams should be delivered. We would like to extended this > to allow also the mixer to control the client on when streams are > delivered. In cases where there are more users then available display > area and a particular user is not actually included in any outgoing > mix/selection from the mixer then there is little point in that the > client consumes network resources. Thus we suggest that the stream > selection and control work is extended to allow also the mixer to pause > individual streams from the client to the mixer. Please note that such > control needs to be responsive, thus using the SIP signaling path for > this is to slow, it needs to be on the media path. I concur. The charter sentence: "The WG will create specifications for SIP-based conferencing systems to enable communication of enough information about each media stream so that each receiving system or bridge system can make reasonable decisions about selecting and rendering media streams. This enables systems to make display choices that optimize the "just like being there" experience. " is specific to selection of streams and not to the ability to control them. I don't see anything here which prevents a source from not sending selected streams - but I have no objection to making this more explicit. How about adding: "Selection choices will be communicated to the sending party to allow the sender to optionally present information on which streams are in use and to optionally suspend streams which are not in use." ?? > > Another question to the group is, are there agreement on how streams > should organized into RTP sessions and how they are utilized? If > anything is documented I would appreciate a pointer. The media streams > are for different purposes from different end-points which are then > mixed by a central point and delivered to end-points. My impression for > example is that most proprietary system breaks the RTP semantics and use > individual sessions between the mixer and each end-point, instead of a > joint session. Here also different robustification tools for RTP such as > FEC and Retransmission needs to be considered. This might be work that > belongs in AVT, but are there need for further clarification into this > field? I think this is something which will have to be thought through and standardized if TP interoperability is to succeed. I would view the semantics of how the streams are assigned in scope and the "plumbing" either comes from the AVT/MMUSIC media cap stuff or any additions are developed in those WGs. > > Comments much appreciated and we can gladly suggest text additions to > the charter proposal. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287 > F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From adam@nostrum.com Tue Oct 12 09:04:10 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D4DA3A63EB for ; Tue, 12 Oct 2010 09:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.952 X-Spam-Level: X-Spam-Status: No, score=-101.952 tagged_above=-999 required=5 tests=[AWL=0.646, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnT57nJ1fSdS for ; Tue, 12 Oct 2010 09:04:09 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 787753A68D5 for ; Tue, 12 Oct 2010 09:04:07 -0700 (PDT) Received: from hydra-3.local (ppp-70-242-117-72.dsl.rcsntx.swbell.net [70.242.117.72]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o9CG5JRH093659 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 12 Oct 2010 11:05:20 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4CB4873F.9030101@nostrum.com> Date: Tue, 12 Oct 2010 11:05:19 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Avasarala Ranjit-A20990 References: <750BBC72E178114F9DC4872EBFF29A5B0ABAB06D@ZMY16EXM66.ds.mot.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0ABAB06D@ZMY16EXM66.ds.mot.com> Content-Type: multipart/alternative; boundary="------------020000070107010405030804" Cc: dispatch@ietf.org, drsubirsaha@yahoo.com Subject: Re: [dispatch] Comments on draft-avasarala-dispatch-comm-div-notification-05 //About forking X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 16:04:10 -0000 This is a multi-part message in MIME format. --------------020000070107010405030804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ranjit: I would strongly suggest that you adopt Gao's proposal to allow multiple subscriptions to result from a fork. The more event packages are defined, the more I think that any package that specifies that only one subscription can be established as the result of forking simply reflects a lack of imagination on the part of the draft author. For example: the registration event package in RFC 3680 also chose to specify that only one subscription can be established. The explanation (in section 4.9) literally evaluates to "we can't imagine why this might be useful, so we're going to prevent it." Fast-forward 4 years. We're doing work in MARTINI that is predicated on a network in which multiple registrars for an AOR are possible. We're having to update RFC3680 in the solution document to say, "whoops, that was wrong, we really do need multiple subscriptions sometimes." I think RFC 3265 actually got this wrong. The suggestion that whole classes of events never make sense in the context of forking is looking increasingly like a failure to envision novel uses of the protocol. And, in fact, with GRUUs, it's no longer necessary to even have this kind of behavior. If a user doesn't want a SUBSCRIBE to fork, they use a GRUU. In particular, since Gao has apparently identified a system right now that would benefit from multiple subscriptions, it doesn't even require that much imagination to forsee a system that might require this. /a On 10/12/10 06:51, Oct 12, Avasarala Ranjit-A20990 wrote: > > Hi > > Yes we did not want to support forking for the CDIV package since the > CDIV notification is only intended for the subscriber who subscribed it . > > Regards > > Ranjit > > *From:* gao.yang2@zte.com.cn [mailto:gao.yang2@zte.com.cn] > *Sent:* Monday, October 11, 2010 7:47 AM > *To:* dispatch@ietf.org > *Cc:* Avasarala Ranjit-A20990; jbakker@rim.com; drsubirsaha@yahoo.com > *Subject:* Comments on > draft-avasarala-dispatch-comm-div-notification-05 //About forking > > > In our implementation(the background system is IMS) of this draft, we > find one problem about forking. > > In section 6.9(Handling of Forked Requests) of this draft: > > This specification only allows a single dialog to be constructed as a > result of emitting an initial SUBSCRIBE request. This guarantees > that only a single notifier is generating notifications for a > particular subscription to a particular user. > > we could find that forked subscription is forbidden for this Event > package. > > While in real IMS network, there are cases the div-services are > deployed in different ASs. Then, the subscription should be forked to > the different ASs, if there are more than one AS do div-services for > the specific service user. > > We once considered one way to avoid the forking condition. The way is > to let the user send different subscription for different div-service. > But by the end user's viewpoint, he/she have no idea of the deployment > of the div-servies(in ASs). So, he/she does't know when should he/she > send separated subscription or not. > > So, I suggest to allow forking for this Event package. > > Thanks, > > Gao > > =================================== > Zip : 210012 > Tel : 87211 > Tel2 :(+86)-025-52877211 > e_mail : gao.yang2@zte.com.cn > =================================== > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --------------020000070107010405030804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ranjit:

I would strongly suggest that you adopt Gao's proposal to allow multiple subscriptions to result from a fork.

The more event packages are defined, the more I think that any package that specifies that only one subscription can be established as the result of forking simply reflects a lack of imagination on the part of the draft author.

For example: the registration event package in RFC 3680 also chose to specify that only one subscription can be established. The explanation (in section 4.9) literally evaluates to "we can't imagine why this might be useful, so we're going to prevent it."

Fast-forward 4 years. We're doing work in MARTINI that is predicated on a network in which multiple registrars for an AOR are possible. We're having to update RFC3680 in the solution document to say, "whoops, that was wrong, we really do need multiple subscriptions sometimes."

I think RFC 3265 actually got this wrong. The suggestion that whole classes of events never make sense in the context of forking is looking increasingly like a failure to envision novel uses of the protocol. And, in fact, with GRUUs, it's no longer necessary to even have this kind of behavior. If a user doesn't want a SUBSCRIBE to fork, they use a GRUU.

In particular, since Gao has apparently identified a system right now that would benefit from multiple subscriptions, it doesn't even require that much imagination to forsee a system that might require this.

/a

On 10/12/10 06:51, Oct 12, Avasarala Ranjit-A20990 wrote:

Hi

 

Yes we did not want to support forking for the CDIV package since the CDIV notification is only intended for the subscriber who subscribed it .

 

Regards

Ranjit

 

From: gao.yang2@zte.com.cn [mailto:gao.yang2@zte.com.cn]
Sent: Monday, October 11, 2010 7:47 AM
To: dispatch@ietf.org
Cc: Avasarala Ranjit-A20990; jbakker@rim.com; drsubirsaha@yahoo.com
Subject: Comments on draft-avasarala-dispatch-comm-div-notification-05 //About forking

 


In our implementation(the background system is IMS) of this draft, we find one problem about forking.

In section 6.9(Handling of Forked Requests) of this draft:

This specification only allows a single dialog to be constructed as a
   result of emitting an initial SUBSCRIBE request.  This guarantees
   that only a single notifier is generating notifications for a
   particular subscription to a particular user.

we could find that forked subscription is forbidden for this Event package.

While in real IMS network, there are cases the div-services are deployed in different ASs. Then, the subscription should be forked to the different ASs, if there are more than one AS do div-services for the specific service user.

We once considered one way to avoid the forking condition. The way is to let the user send different subscription for different div-service. But by the end user's viewpoint, he/she have no idea of the deployment of the div-servies(in ASs). So, he/she does't know when should he/she send separated subscription or not.  

So, I suggest to allow forking for this Event package.

Thanks,

Gao

===================================
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2@zte.com.cn
===================================

 
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

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

--------------020000070107010405030804-- From ranjit@motorola.com Tue Oct 12 21:19:20 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31F093A68B1 for ; Tue, 12 Oct 2010 21:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDYfxwmeId3a for ; Tue, 12 Oct 2010 21:19:18 -0700 (PDT) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id 3FE463A6B37 for ; Tue, 12 Oct 2010 21:19:18 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-4.tower-55.messagelabs.com!1286943631!94499859!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [136.182.1.13] Received: (qmail 25355 invoked from network); 13 Oct 2010 04:20:32 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (136.182.1.13) by server-4.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Oct 2010 04:20:32 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate3.mot.com (8.14.3/8.14.3) with ESMTP id o9D4KVm2013181 for ; Tue, 12 Oct 2010 21:20:31 -0700 (MST) Received: from il27vts03 (il27vts03.cig.mot.com [10.17.196.87]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id o9D4KV3A010806 for ; Tue, 12 Oct 2010 23:20:31 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id o9D4KTGi010795 for ; Tue, 12 Oct 2010 23:20:30 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB6A8D.EB68B62D" Date: Wed, 13 Oct 2010 12:20:06 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0ABAB13C@ZMY16EXM66.ds.mot.com> In-Reply-To: <4CB4873F.9030101@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Comments on draft-avasarala-dispatch-comm-div-notification-05 //About forking thread-index: ActqJ04QivEvZbJnSLOavyIhEwUb3AAZmX3g References: <750BBC72E178114F9DC4872EBFF29A5B0ABAB06D@ZMY16EXM66.ds.mot.com> <4CB4873F.9030101@nostrum.com> From: "Avasarala Ranjit-A20990" To: "Adam Roach" X-CFilter-Loop: Reflected Cc: dispatch@ietf.org, drsubirsaha@yahoo.com Subject: Re: [dispatch] Comments on draft-avasarala-dispatch-comm-div-notification-05 //About forking X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 04:19:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB6A8D.EB68B62D Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Adam =20 So will RFC 3265 be updated to reflect the change of SUBSCRIBE request getting forked? =20 =20 Regards Ranjit =20 =20 From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: Tuesday, October 12, 2010 9:35 PM To: Avasarala Ranjit-A20990 Cc: gao.yang2@zte.com.cn; dispatch@ietf.org; drsubirsaha@yahoo.com Subject: Re: [dispatch] Comments on draft-avasarala-dispatch-comm-div-notification-05 //About forking =20 Ranjit: I would strongly suggest that you adopt Gao's proposal to allow multiple subscriptions to result from a fork. The more event packages are defined, the more I think that any package that specifies that only one subscription can be established as the result of forking simply reflects a lack of imagination on the part of the draft author. For example: the registration event package in RFC 3680 also chose to specify that only one subscription can be established. The explanation (in section 4.9) literally evaluates to "we can't imagine why this might be useful, so we're going to prevent it." Fast-forward 4 years. We're doing work in MARTINI that is predicated on a network in which multiple registrars for an AOR are possible. We're having to update RFC3680 in the solution document to say, "whoops, that was wrong, we really do need multiple subscriptions sometimes." I think RFC 3265 actually got this wrong. The suggestion that whole classes of events never make sense in the context of forking is looking increasingly like a failure to envision novel uses of the protocol. And, in fact, with GRUUs, it's no longer necessary to even have this kind of behavior. If a user doesn't want a SUBSCRIBE to fork, they use a GRUU. In particular, since Gao has apparently identified a system right now that would benefit from multiple subscriptions, it doesn't even require that much imagination to forsee a system that might require this. /a On 10/12/10 06:51, Oct 12, Avasarala Ranjit-A20990 wrote:=20 Hi =20 Yes we did not want to support forking for the CDIV package since the CDIV notification is only intended for the subscriber who subscribed it .=20 =20 Regards Ranjit =20 From: gao.yang2@zte.com.cn [mailto:gao.yang2@zte.com.cn]=20 Sent: Monday, October 11, 2010 7:47 AM To: dispatch@ietf.org Cc: Avasarala Ranjit-A20990; jbakker@rim.com; drsubirsaha@yahoo.com Subject: Comments on draft-avasarala-dispatch-comm-div-notification-05 //About forking =20 In our implementation(the background system is IMS) of this draft, we find one problem about forking.=20 In section 6.9(Handling of Forked Requests) of this draft:=20 This specification only allows a single dialog to be constructed as a=20 result of emitting an initial SUBSCRIBE request. This guarantees=20 that only a single notifier is generating notifications for a=20 particular subscription to a particular user.=20 we could find that forked subscription is forbidden for this Event package.=20 While in real IMS network, there are cases the div-services are deployed in different ASs. Then, the subscription should be forked to the different ASs, if there are more than one AS do div-services for the specific service user.=20 We once considered one way to avoid the forking condition. The way is to let the user send different subscription for different div-service. But by the end user's viewpoint, he/she have no idea of the deployment of the div-servies(in ASs). So, he/she does't know when should he/she send separated subscription or not. =20 So, I suggest to allow forking for this Event package.=20 Thanks,=20 Gao=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Zip : 210012 Tel : 87211 Tel2 :(+86)-025-52877211 e_mail : gao.yang2@zte.com.cn =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. =20 =20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch =20 ------_=_NextPart_001_01CB6A8D.EB68B62D Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi Adam

 

So will RFC 3265 be updated to reflect the change of = SUBSCRIBE request getting forked?

 

 

Regards

Ranjit

 

 

From: Adam Roach = [mailto:adam@nostrum.com]
Sent: Tuesday, October 12, 2010 9:35 PM
To: Avasarala Ranjit-A20990
Cc: gao.yang2@zte.com.cn; dispatch@ietf.org; = drsubirsaha@yahoo.com
Subject: Re: [dispatch] Comments on draft-avasarala-dispatch-comm-div-notification-05 //About = forking

 

Ranjit:

I would strongly suggest that you adopt Gao's proposal to allow multiple subscriptions to result from a fork.

The more event packages are defined, the more I think that any package = that specifies that only one subscription can be established as the result of forking simply reflects a lack of imagination on the part of the draft = author.

For example: the registration event package in RFC 3680 also chose to = specify that only one subscription can be established. The explanation (in = section 4.9) literally evaluates to "we can't imagine why this might be useful, = so we're going to prevent it."

Fast-forward 4 years. We're doing work in MARTINI that is predicated on = a network in which multiple registrars for an AOR are possible. We're = having to update RFC3680 in the solution document to say, "whoops, that was = wrong, we really do need multiple subscriptions sometimes."

I think RFC 3265 actually got this wrong. The suggestion that whole = classes of events never make sense in the context of forking is looking = increasingly like a failure to envision novel uses of the protocol. And, in fact, with = GRUUs, it's no longer necessary to even have this kind of behavior. If a user = doesn't want a SUBSCRIBE to fork, they use a GRUU.

In particular, since Gao has apparently identified a system right now = that would benefit from multiple subscriptions, it doesn't even require that = much imagination to forsee a system that might require this.

/a

On 10/12/10 06:51, Oct 12, Avasarala Ranjit-A20990 wrote: =

Hi

 

Yes we did not want to support forking for the CDIV package since the CDIV notification is only intended for the subscriber who subscribed it . =

 

Regards

Ranjit

 

From:= gao.yang2@zte.com.cn [mailto:gao.yang2@zte.com.cn] =
Sent: Monday, October 11, 2010 7:47 AM
To: dispatch@ietf.org
Cc: Avasarala Ranjit-A20990; jbakker@rim.com; drsubirsaha@yahoo.com
Subject: Comments on = draft-avasarala-dispatch-comm-div-notification-05 //About forking

 


In our implementation(the background system is IMS) of this draft, we find one = problem about forking.

In = section 6.9(Handling of Forked Requests) of this draft:

This specification only allows a single dialog to be constructed as a =
   result of emitting an initial SUBSCRIBE request.  This = guarantees
   that only a single notifier is generating notifications for = a
   particular subscription to a particular user.

we = could find that forked subscription is forbidden for this Event package. =

While = in real IMS network, there are cases the div-services are deployed in different = ASs. Then, the subscription should be forked to the different ASs, if there = are more than one AS do div-services for the specific service user.

We = once considered one way to avoid the forking condition. The way is to let the = user send different subscription for different div-service. But by the end = user's viewpoint, he/she have no idea of the deployment of the div-servies(in = ASs). So, he/she does't know when should he/she send separated subscription or = not.  

So, I = suggest to allow forking for this Event package.

Thanks,

Gao =

=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2@zte.com.cn
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 
----------------------------------------=
----------------
ZTE Information Security&=
nbsp;Notice: The information contained in this&n=
bsp;mail is solely property of the sender's=
 organization. This mail communication is c=
onfidential. Recipients named above are obligate=
d to maintain secrecy and are not perm=
itted to disclose the contents of this =
;communication to others.
This email&=
nbsp;and any files transmitted with it are&=
nbsp;confidential and intended solely for the&nb=
sp;use of the individual or entity to =
whom they are addressed. If you have r=
eceived this email in error please notify&n=
bsp;the originator of the message. Any view=
s expressed in this message are those =
of the individual sender.
This m=
essage has been scanned for viruses and&nbs=
p;Spam by ZTE Anti-Spam system.
=
 
 
_________________=
______________________________
dispatch mailing =
list
dispatch@ietf.org
<= pre>https://www.ietf.= org/mailman/listinfo/dispatch

 

------_=_NextPart_001_01CB6A8D.EB68B62D-- From adam@nostrum.com Tue Oct 12 21:26:44 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33F8F3A6B3D for ; Tue, 12 Oct 2010 21:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.275 X-Spam-Level: X-Spam-Status: No, score=-102.275 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLTly9Z8q6bW for ; Tue, 12 Oct 2010 21:26:42 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 6CFFE3A68B1 for ; Tue, 12 Oct 2010 21:26:41 -0700 (PDT) Received: from hydra-3.local (ppp-70-242-117-72.dsl.rcsntx.swbell.net [70.242.117.72]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o9D4Rtfp051662 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 12 Oct 2010 23:27:55 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4CB5354B.7080206@nostrum.com> Date: Tue, 12 Oct 2010 23:27:55 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Avasarala Ranjit-A20990 References: <750BBC72E178114F9DC4872EBFF29A5B0ABAB06D@ZMY16EXM66.ds.mot.com> <4CB4873F.9030101@nostrum.com> <750BBC72E178114F9DC4872EBFF29A5B0ABAB13C@ZMY16EXM66.ds.mot.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0ABAB13C@ZMY16EXM66.ds.mot.com> Content-Type: multipart/alternative; boundary="------------070509030508030900060807" Cc: dispatch@ietf.org, drsubirsaha@yahoo.com Subject: Re: [dispatch] Comments on draft-avasarala-dispatch-comm-div-notification-05 //About forking X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 04:26:44 -0000 This is a multi-part message in MIME format. --------------070509030508030900060807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The 3265bis document already requires the use of GRUUs. I'm going to look carefully at the section regarding forking to see what reasonable changes we can make there to prevent this kind of problem in the future. But, unless you're going to wait for 3265bis to conclude, div-notification will be based on 3265. Your best bet is to clearly specify that multiple subscriptions may legally be established by a single SUBSCRIBE request. /a On 10/12/10 23:20, Oct 12, Avasarala Ranjit-A20990 wrote: > > Hi Adam > > So will RFC 3265 be updated to reflect the change of SUBSCRIBE request > getting forked? > > Regards > > Ranjit > > *From:* Adam Roach [mailto:adam@nostrum.com] > *Sent:* Tuesday, October 12, 2010 9:35 PM > *To:* Avasarala Ranjit-A20990 > *Cc:* gao.yang2@zte.com.cn; dispatch@ietf.org; drsubirsaha@yahoo.com > *Subject:* Re: [dispatch] Comments on > draft-avasarala-dispatch-comm-div-notification-05 //About forking > > Ranjit: > > I would strongly suggest that you adopt Gao's proposal to allow > multiple subscriptions to result from a fork. > > The more event packages are defined, the more I think that any package > that specifies that only one subscription can be established as the > result of forking simply reflects a lack of imagination on the part of > the draft author. > > For example: the registration event package in RFC 3680 also chose to > specify that only one subscription can be established. The explanation > (in section 4.9) literally evaluates to "we can't imagine why this > might be useful, so we're going to prevent it." > > Fast-forward 4 years. We're doing work in MARTINI that is predicated > on a network in which multiple registrars for an AOR are possible. > We're having to update RFC3680 in the solution document to say, > "whoops, that was wrong, we really do need multiple subscriptions > sometimes." > > I think RFC 3265 actually got this wrong. The suggestion that whole > classes of events never make sense in the context of forking is > looking increasingly like a failure to envision novel uses of the > protocol. And, in fact, with GRUUs, it's no longer necessary to even > have this kind of behavior. If a user doesn't want a SUBSCRIBE to > fork, they use a GRUU. > > In particular, since Gao has apparently identified a system right now > that would benefit from multiple subscriptions, it doesn't even > require that much imagination to forsee a system that might require this. > > /a > > On 10/12/10 06:51, Oct 12, Avasarala Ranjit-A20990 wrote: > > Hi > > Yes we did not want to support forking for the CDIV package since the > CDIV notification is only intended for the subscriber who subscribed it . > > Regards > > Ranjit > > *From:* gao.yang2@zte.com.cn > [mailto:gao.yang2@zte.com.cn] > *Sent:* Monday, October 11, 2010 7:47 AM > *To:* dispatch@ietf.org > *Cc:* Avasarala Ranjit-A20990; jbakker@rim.com > ; drsubirsaha@yahoo.com > > *Subject:* Comments on > draft-avasarala-dispatch-comm-div-notification-05 //About forking > > > In our implementation(the background system is IMS) of this draft, we > find one problem about forking. > > In section 6.9(Handling of Forked Requests) of this draft: > > This specification only allows a single dialog to be constructed as a > result of emitting an initial SUBSCRIBE request. This guarantees > that only a single notifier is generating notifications for a > particular subscription to a particular user. > > we could find that forked subscription is forbidden for this Event > package. > > While in real IMS network, there are cases the div-services are > deployed in different ASs. Then, the subscription should be forked to > the different ASs, if there are more than one AS do div-services for > the specific service user. > > We once considered one way to avoid the forking condition. The way is > to let the user send different subscription for different div-service. > But by the end user's viewpoint, he/she have no idea of the deployment > of the div-servies(in ASs). So, he/she does't know when should he/she > send separated subscription or not. > > So, I suggest to allow forking for this Event package. > > Thanks, > > Gao > > =================================== > Zip : 210012 > Tel : 87211 > Tel2 :(+86)-025-52877211 > e_mail : gao.yang2@zte.com.cn > =================================== > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --------------070509030508030900060807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The 3265bis document already requires the use of GRUUs. I'm going to look carefully at the section regarding forking to see what reasonable changes we can make there to prevent this kind of problem in the future.

But, unless you're going to wait for 3265bis to conclude, div-notification will be based on 3265. Your best bet is to clearly specify that multiple subscriptions may legally be established by a single SUBSCRIBE request.

/a

On 10/12/10 23:20, Oct 12, Avasarala Ranjit-A20990 wrote:

Hi Adam

 

So will RFC 3265 be updated to reflect the change of SUBSCRIBE request getting forked?

 

 

Regards

Ranjit

 

 

From: Adam Roach [mailto:adam@nostrum.com]
Sent: Tuesday, October 12, 2010 9:35 PM
To: Avasarala Ranjit-A20990
Cc: gao.yang2@zte.com.cn; dispatch@ietf.org; drsubirsaha@yahoo.com
Subject: Re: [dispatch] Comments on draft-avasarala-dispatch-comm-div-notification-05 //About forking

 

Ranjit:

I would strongly suggest that you adopt Gao's proposal to allow multiple subscriptions to result from a fork.

The more event packages are defined, the more I think that any package that specifies that only one subscription can be established as the result of forking simply reflects a lack of imagination on the part of the draft author.

For example: the registration event package in RFC 3680 also chose to specify that only one subscription can be established. The explanation (in section 4.9) literally evaluates to "we can't imagine why this might be useful, so we're going to prevent it."

Fast-forward 4 years. We're doing work in MARTINI that is predicated on a network in which multiple registrars for an AOR are possible. We're having to update RFC3680 in the solution document to say, "whoops, that was wrong, we really do need multiple subscriptions sometimes."

I think RFC 3265 actually got this wrong. The suggestion that whole classes of events never make sense in the context of forking is looking increasingly like a failure to envision novel uses of the protocol. And, in fact, with GRUUs, it's no longer necessary to even have this kind of behavior. If a user doesn't want a SUBSCRIBE to fork, they use a GRUU.

In particular, since Gao has apparently identified a system right now that would benefit from multiple subscriptions, it doesn't even require that much imagination to forsee a system that might require this.

/a

On 10/12/10 06:51, Oct 12, Avasarala Ranjit-A20990 wrote:

Hi

 

Yes we did not want to support forking for the CDIV package since the CDIV notification is only intended for the subscriber who subscribed it .

 

Regards

Ranjit

 

From: gao.yang2@zte.com.cn [mailto:gao.yang2@zte.com.cn]
Sent: Monday, October 11, 2010 7:47 AM
To: dispatch@ietf.org
Cc: Avasarala Ranjit-A20990; jbakker@rim.com; drsubirsaha@yahoo.com
Subject: Comments on draft-avasarala-dispatch-comm-div-notification-05 //About forking

 


In our implementation(the background system is IMS) of this draft, we find one problem about forking.

In section 6.9(Handling of Forked Requests) of this draft:

This specification only allows a single dialog to be constructed as a
   result of emitting an initial SUBSCRIBE request.  This guarantees
   that only a single notifier is generating notifications for a
   particular subscription to a particular user.

we could find that forked subscription is forbidden for this Event package.

While in real IMS network, there are cases the div-services are deployed in different ASs. Then, the subscription should be forked to the different ASs, if there are more than one AS do div-services for the specific service user.

We once considered one way to avoid the forking condition. The way is to let the user send different subscription for different div-service. But by the end user's viewpoint, he/she have no idea of the deployment of the div-servies(in ASs). So, he/she does't know when should he/she send separated subscription or not.  

So, I suggest to allow forking for this Event package.

Thanks,

Gao

===================================
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2@zte.com.cn
===================================

 
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
 
 
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

 


--------------070509030508030900060807-- From magnus.westerlund@ericsson.com Wed Oct 13 02:09:59 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE2373A6807 for ; Wed, 13 Oct 2010 02:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.481 X-Spam-Level: X-Spam-Status: No, score=-106.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1-My2SS5yga for ; Wed, 13 Oct 2010 02:09:57 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id A39743A6405 for ; Wed, 13 Oct 2010 02:09:56 -0700 (PDT) X-AuditID: c1b4fb3d-b7c3aae000000b22-59-4cb577af29ab Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id CF.91.02850.FA775BC4; Wed, 13 Oct 2010 11:11:12 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Oct 2010 11:11:11 +0200 Received: from [147.214.183.82] ([147.214.183.82]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Oct 2010 11:11:11 +0200 Message-ID: <4CB577AF.3070903@ericsson.com> Date: Wed, 13 Oct 2010 11:11:11 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Peter Musgrave References: <4CB466D5.8060601@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 13 Oct 2010 09:11:11.0796 (UTC) FILETIME=[947C5740:01CB6AB6] X-Brightmail-Tracker: AAAAAA== Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comments on the proposed Telepresence Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 09:09:59 -0000 Hi Peter, Good that we are in agreement on a number of things. Response and clarifications inline. Peter Musgrave skrev 2010-10-12 17:37: >> >> Independent if one uses a central mixer or a full mesh there appears to >> be a lack in media stream negotiation for how to negotiate what >> capabilities the receiving client has in receiving, decoding and >> rendering when it comes to number of simultaneous streams. Our >> understanding is that RTP mandates any number of streams, while in >> reality outside of conferencing that is in fact one single stream. >> However with telepresence and conferencing there is a need to negotiate >> the actual capability, especially between a mixer and client when it >> comes to deliver multiple streams for various usages. > Agreed. The charter does speak to identifying endpoint capabilities > and I view what you describe here as the kind of meta-information > which needs to fit into that framework. Okay, as long as this is included in the thinking about capabilities I am fine. However, the charter proposal isn't particular detailed in this regards. But I guess the following charter text is matching this: "Information between sources and sinks about media stream capabilities will be exchanged." >> >> We also think there is missing functionality for expressing who are the >> currently active speakers. The RTP CSRC field are not sufficient as they >> express which end-points are included in the mix. However, as one likely >> include in a mix more rooms than the active speakers to ensure that any >> interruption and ambient sound are correctly captured an mechanism for >> indicating the currently active speakers are needed. There is also need >> to agree on the type of identifier to be used that allow for mapping to >> full user names when appropriate. > I agree with this. In my opinion this is a separable problem since it > applies to generic audio conferencing as well. There is tangential > work in the conference event package and probably in the XCON stuff - > but I lack detailed background in XCON. > > In the context of the TP charter I think the work on indicating which > audio stream is associated with which speaker (or part of the room) is > a slightly different issue - since it's about which stream and not > which speaker within a stream. I should probably have been clearer. I am concerned that even on media stream level there is missing functionality to indicate which streams that contains active speakers and has been included in a mix produced by the mixer. From our side we see a difference between being included in the mix and being tagged as currently an active speaker. I think this is currently missing functionality for which requirements needs to be agreed on and then a solution developed. However, the solution might better fit another WG, like AVT. But I think that is for later determination. I think the requirements phase makes sense to have in the Telepresence group. I do agree that such functionality do have a wider usage scope than just telepresence and can be used in any case of centralized mixers where special activity needs to be pointed out, with audio being the foremost example of such media. > >> >> The charter includes an item to work on control between client and a >> mixer what streams should be delivered. We would like to extended this >> to allow also the mixer to control the client on when streams are >> delivered. In cases where there are more users then available display >> area and a particular user is not actually included in any outgoing >> mix/selection from the mixer then there is little point in that the >> client consumes network resources. Thus we suggest that the stream >> selection and control work is extended to allow also the mixer to pause >> individual streams from the client to the mixer. Please note that such >> control needs to be responsive, thus using the SIP signaling path for >> this is to slow, it needs to be on the media path. > I concur. > > The charter sentence: > "The WG will create specifications for SIP-based conferencing systems > to enable communication of enough information about each media stream > so that each receiving system or bridge system can make reasonable > decisions about selecting and rendering media streams. This enables > systems to make display choices that optimize the "just like being > there" experience. " > > is specific to selection of streams and not to the ability to control > them. I don't see anything here which prevents a source from not > sending selected streams - but I have no objection to making this more > explicit. How about adding: > > "Selection choices will be communicated to the sending party to allow > the sender to optionally present information on which streams are in > use and to optionally suspend streams which are not in use." ?? > When I wrote the above comment I was mostly considering the following chart text bullet: * Which sources a receiver wants to receive. For example, it might want the source for the left camera, or might want the source chosen by VAD (Voice Activity Detection). I think your proposed text combined with the above bullet gives all the room I see needed for media stream control. However, maybe a modification of the above to make it clear. * Which sources a receiver or mixer wants to have transmitted. For example, it might want the source for the left camera, or might want the source chosen by VAD (Voice Activity Detection). > >> >> Another question to the group is, are there agreement on how streams >> should organized into RTP sessions and how they are utilized? If >> anything is documented I would appreciate a pointer. The media streams >> are for different purposes from different end-points which are then >> mixed by a central point and delivered to end-points. My impression for >> example is that most proprietary system breaks the RTP semantics and use >> individual sessions between the mixer and each end-point, instead of a >> joint session. Here also different robustification tools for RTP such as >> FEC and Retransmission needs to be considered. This might be work that >> belongs in AVT, but are there need for further clarification into this >> field? > I think this is something which will have to be thought through and > standardized if TP interoperability is to succeed. I would view the > semantics of how the streams are assigned in scope and the "plumbing" > either comes from the AVT/MMUSIC media cap stuff or any additions are > developed in those WGs. > I agree with that the right place to do specification work is likely these two groups. However, I think telepresence needs to provide requirements for such work. Making such requirement development explicit in the charter would make it clear that we do expect work to happen somewhere else. At the same time it is after all possible to request that another WG's charter is updated to cover such work. The WG may identify interoperability obstacles in existing open standards. The WG may develop requirements to be communicated to other IETF WGs or Standards Forums as a kind request to try to meet these requirements. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From peter.musgrave@magorcorp.com Wed Oct 13 03:28:48 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56ADF3A68ED for ; Wed, 13 Oct 2010 03:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.858 X-Spam-Level: X-Spam-Status: No, score=-101.858 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id poj-FyrSVfBX for ; Wed, 13 Oct 2010 03:28:46 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 89C823A692B for ; Wed, 13 Oct 2010 03:28:45 -0700 (PDT) Received: by qyk36 with SMTP id 36so3836143qyk.10 for ; Wed, 13 Oct 2010 03:30:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.110.10 with SMTP id l10mr2056456qcp.32.1286965801390; Wed, 13 Oct 2010 03:30:01 -0700 (PDT) Received: by 10.229.42.196 with HTTP; Wed, 13 Oct 2010 03:30:01 -0700 (PDT) In-Reply-To: <4CB577AF.3070903@ericsson.com> References: <4CB466D5.8060601@ericsson.com> <4CB577AF.3070903@ericsson.com> Date: Wed, 13 Oct 2010 06:30:01 -0400 Message-ID: From: Peter Musgrave To: Magnus Westerlund Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comments on the proposed Telepresence Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 10:28:48 -0000 HI Magnus, I have no issues with your proposed changes to the wording. As for the rest I believe we are in agreement. Regards, Peter On Wed, Oct 13, 2010 at 5:11 AM, Magnus Westerlund wrote: > Hi Peter, > > Good that we are in agreement on a number of things. Response and > clarifications inline. > > Peter Musgrave skrev 2010-10-12 17:37: >>> >>> Independent if one uses a central mixer or a full mesh there appears to >>> be a lack in media stream negotiation for how to negotiate what >>> capabilities the receiving client has in receiving, decoding and >>> rendering when it comes to number of simultaneous streams. Our >>> understanding is that RTP mandates any number of streams, while in >>> reality outside of conferencing that is in fact one single stream. >>> However with telepresence and conferencing there is a need to negotiate >>> the actual capability, especially between a mixer and client when it >>> comes to deliver multiple streams for various usages. > >> Agreed. The charter does speak to identifying endpoint capabilities >> and I view what you describe here as the kind of meta-information >> which needs to fit into that framework. > > Okay, as long as this is included in the thinking about capabilities I > am fine. However, the charter proposal isn't particular detailed in this > regards. But I guess the following charter text is matching this: > > "Information between sources and sinks about media stream capabilities > will be exchanged." > >>> >>> We also think there is missing functionality for expressing who are the >>> currently active speakers. The RTP CSRC field are not sufficient as the= y >>> express which end-points are included in the mix. However, as one likel= y >>> include in a mix more rooms than the active speakers to ensure that any >>> interruption and ambient sound are correctly captured an mechanism for >>> indicating the currently active speakers are needed. There is also need >>> to agree on the type of identifier to be used that allow for mapping to >>> full user names when appropriate. > >> I agree with this. In my opinion this is a separable problem since it >> applies to generic audio conferencing as well. There is tangential >> work in the conference event package and probably in the XCON stuff - >> but I lack detailed background in XCON. >> >> In the context of the TP charter I think the work on indicating which >> audio stream is associated with which speaker (or part of the room) is >> a slightly different issue - since it's about which stream and not >> which speaker within a stream. > > I should probably have been clearer. I am concerned that even on media > stream level there is missing functionality to indicate which streams > that contains active speakers and has been included in a mix produced by > the mixer. From our side we see a difference between being included in > the mix and being tagged as currently an active speaker. > > I think this is currently missing functionality for which requirements > needs to be agreed on and then a solution developed. However, the > solution might better fit another WG, like AVT. But I think that is for > later determination. I think the requirements phase makes sense to have > in the Telepresence group. > > I do agree that such functionality do have a wider usage scope than just > telepresence and can be used in any case of centralized mixers where > special activity needs to be pointed out, with audio being the foremost > example of such media. > >> >>> >>> The charter includes an item to work on control between client and a >>> mixer what streams should be delivered. We would like to extended this >>> to allow also the mixer to control the client on when streams are >>> delivered. In cases where there are more users then available display >>> area and a particular user is not actually included in any outgoing >>> mix/selection from the mixer then there is little point in that the >>> client consumes network resources. Thus we suggest that the stream >>> selection and control work is extended to allow also the mixer to pause >>> individual streams from the client to the mixer. Please note that such >>> control needs to be responsive, thus using the SIP signaling path for >>> this is to slow, it needs to be on the media path. >> I concur. >> >> The charter sentence: >> =A0"The WG will create specifications for SIP-based conferencing systems >> to enable communication of enough information about each media stream >> so that each receiving system or bridge system can make reasonable >> decisions about selecting and rendering media streams. This enables >> systems to make display choices that optimize the "just like being >> there" experience. " >> >> is specific to selection of streams and not to the ability to control >> them. I don't see anything here which prevents a source from not >> sending selected streams - but I have no objection to making this more >> explicit. How about adding: >> >> "Selection choices will be communicated to the sending party to allow >> the sender to optionally present information on which streams are in >> use and to optionally suspend streams which are not in use." ?? >> > > When I wrote the above comment I was mostly considering the following > chart text bullet: > > * Which sources a receiver wants to receive. =A0For example, it might wan= t > the source for the left camera, or might want the source chosen by VAD > (Voice Activity Detection). > > I think your proposed text combined with the above bullet gives all the > room I see needed for media stream control. However, maybe a > modification of the above to make it clear. > > * Which sources a receiver or mixer wants to have transmitted. =A0For > example, it might want the source for the left camera, or might want the > source chosen by VAD (Voice Activity Detection). > >> >>> >>> Another question to the group is, are there agreement on how streams >>> should organized into RTP sessions and how they are utilized? If >>> anything is documented I would appreciate a pointer. The media streams >>> are for different purposes from different end-points which are then >>> mixed by a central point and delivered to end-points. My impression for >>> example is that most proprietary system breaks the RTP semantics and us= e >>> individual sessions between the mixer and each end-point, instead of a >>> joint session. Here also different robustification tools for RTP such a= s >>> FEC and Retransmission needs to be considered. This might be work that >>> belongs in AVT, but are there need for further clarification into this >>> field? > >> I think this is something which will have to be thought through and >> standardized if TP interoperability is to succeed. I would view the >> semantics of how the streams are assigned in scope and the "plumbing" >> either comes from the AVT/MMUSIC media cap stuff or any additions are >> developed in those WGs. >> > > I agree with that the right place to do specification work is likely > these two groups. However, I think telepresence needs to provide > requirements for such work. Making such requirement development explicit > in the charter would make it clear that we do expect work to happen > somewhere else. At the same time it is after all possible to request > that another WG's charter is updated to cover such work. > > The WG may identify interoperability obstacles in existing open > standards. The WG may develop requirements to be communicated to other > IETF WGs or Standards Forums as a kind request to try to meet these > requirements. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287 > F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > From allyn@cisco.com Wed Oct 13 09:46:23 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4D1B3A69C2 for ; Wed, 13 Oct 2010 09:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.341 X-Spam-Level: X-Spam-Status: No, score=-10.341 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZM-fz-BKrdi for ; Wed, 13 Oct 2010 09:46:22 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 74DE13A69A0 for ; Wed, 13 Oct 2010 09:46:22 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABeAtUyrR7Ht/2dsb2JhbAChT3GhXZxmAoVGBIRSiHg X-IronPort-AV: E=Sophos;i="4.57,326,1283731200"; d="scan'208";a="370622241" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 13 Oct 2010 16:47:39 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9DGld3J018622; Wed, 13 Oct 2010 16:47:39 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Oct 2010 09:47:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Oct 2010 09:47:38 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02A47987@xmb-sjc-221.amer.cisco.com> In-Reply-To: <4CB466D5.8060601@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Comments on the proposed Telepresence Charter Thread-Index: ActqE/mHH0VnqGVlRdSKOtrz9muIyQAeoEZg References: <4CB466D5.8060601@ericsson.com> From: "Allyn Romanow (allyn)" To: "Magnus Westerlund" , X-OriginalArrivalTime: 13 Oct 2010 16:47:39.0335 (UTC) FILETIME=[58BB2570:01CB6AF6] Subject: Re: [dispatch] Comments on the proposed Telepresence Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 16:46:23 -0000 Hi Magnus, I was really glad that you had a chance to carefully consider the = proposed work. Like Peter, I too agree with most of your comments. Specific points below. Best regards, Allyn -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Magnus Westerlund Sent: Tuesday, October 12, 2010 6:47 AM To: dispatch@ietf.org Subject: [dispatch] Comments on the proposed Telepresence Charter Hi, Some colleagues and I have reviewed the two telepresence drafts and version 5 of the charter and have some comments on the charter. To make our comments more understandable I think we should explain our view on telepresence. First we are expecting great variations in the capabilities of the participating terminals in a session. From personal terminals for individual users up to multi-display, cameras and microphone setups. We also expect that more than two end-points being present in the same session. As we see it it will require good support for centralized media handling in a mixer (MCU). We also see video streams not only of high quality to be presented for maximum immersion, but also lower qualities that can be used to monitor activity in other rooms that aren't the ones selected for high quality. [AR] Yes, absolutely. Independent if one uses a central mixer or a full mesh there appears to be a lack in media stream negotiation for how to negotiate what capabilities the receiving client has in receiving, decoding and rendering when it comes to number of simultaneous streams. Our understanding is that RTP mandates any number of streams, while in reality outside of conferencing that is in fact one single stream. However with telepresence and conferencing there is a need to negotiate the actual capability, especially between a mixer and client when it comes to deliver multiple streams for various usages. [AR] Yes, agree - as you saw, this is covered in the charter. We also think there is missing functionality for expressing who are the currently active speakers. The RTP CSRC field are not sufficient as they express which end-points are included in the mix. However, as one likely include in a mix more rooms than the active speakers to ensure that any interruption and ambient sound are correctly captured an mechanism for indicating the currently active speakers are needed. There is also need to agree on the type of identifier to be used that allow for mapping to full user names when appropriate. [AR] Yes.. Both of these points are covered in the charter too, right? The charter includes an item to work on control between client and a mixer what streams should be delivered. We would like to extended this to allow also the mixer to control the client on when streams are delivered. In cases where there are more users then available display area and a particular user is not actually included in any outgoing mix/selection from the mixer then there is little point in that the client consumes network resources. Thus we suggest that the stream selection and control work is extended to allow also the mixer to pause individual streams from the client to the mixer. Please note that such control needs to be responsive, thus using the SIP signaling path for this is to slow, it needs to be on the media path. [AR} I agree with your point that it would be good to pause the sender, = but I think that falls under the category of "continuous conference control" which is out of = the scope of this charter. Such a feedback mechanism falls probably under AVT. I think it would be good to add a sentence saying something like, As = control issues=20 necessary for interoperability arise, they will be directed = appropriately. What do you think? Another question to the group is, are there agreement on how streams should organized into RTP sessions and how they are utilized? If anything is documented I would appreciate a pointer. The media streams are for different purposes from different end-points which are then mixed by a central point and delivered to end-points. My impression for example is that most proprietary system breaks the RTP semantics and use individual sessions between the mixer and each end-point, instead of a joint session. Here also different robustification tools for RTP such as FEC and Retransmission needs to be considered. This might be work that belongs in AVT, but are there need for further clarification into this field? [AR} Agree this needs to be worked out for Telepresence, and that any = activity about it would go to AVT and/or MMUSIC. Comments much appreciated and we can gladly suggest text additions to the charter proposal. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From peter.musgrave@magorcorp.com Thu Oct 14 02:24:11 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B00E93A6AA4 for ; Thu, 14 Oct 2010 02:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.86 X-Spam-Level: X-Spam-Status: No, score=-101.86 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vu4VSCk4FLvP for ; Thu, 14 Oct 2010 02:24:10 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 5D4813A6965 for ; Thu, 14 Oct 2010 02:24:10 -0700 (PDT) Received: by qwc9 with SMTP id 9so3740654qwc.31 for ; Thu, 14 Oct 2010 02:25:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.66.33 with SMTP id l33mr7614783qai.221.1287048328100; Thu, 14 Oct 2010 02:25:28 -0700 (PDT) Received: by 10.229.42.196 with HTTP; Thu, 14 Oct 2010 02:25:28 -0700 (PDT) In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02A47987@xmb-sjc-221.amer.cisco.com> References: <4CB466D5.8060601@ericsson.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02A47987@xmb-sjc-221.amer.cisco.com> Date: Thu, 14 Oct 2010 05:25:28 -0400 Message-ID: From: Peter Musgrave To: "Allyn Romanow (allyn)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dispatch@ietf.org Subject: Re: [dispatch] Comments on the proposed Telepresence Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 09:24:11 -0000 HI Allyn/Magnus, W.R.T "[AR} I agree with your point that it would be good to pause the sender, but I think that falls under the category of "continuous conference control" which is out of the scope of this charter. Such a feedback mechanism falls probably under AVT. I think it would be good to add a sentence saying something like, As control issues necessary for interoperability arise, they will be directed appropriately. What do you think?" I think these words leave room to *not* do what Magnus is suggesting. e.g. If I have a 1 screen home TP system getting three streams from a 3 camera system and selecting only one it is not really "necessary" to tell the 3 camera system to pause two streams - but it is a really good idea to have a way to that! I don't view this is a continuous conference control issue (since that gets into floor control which I agree is out of scope) but more like onhold/offhold type negotiation. I think this is to some extent a plumbing issue (and based on the desired response time SIP or media path messages will be required). So I would still like to see a statement which makes it clear that it not just an issue of receiver selection but there is a need to communicate that selection back to the sender. The current text does not say this. Hence my suggestion: "Selection choices will be communicated to the sending party to allow the sender to optionally present information on which streams are in use and to optionally suspend streams which are not in use." ?? I'm open to other words or some indication of which language in the current charter ensures this is in scope. Regards, Peter Musgrave On Wed, Oct 13, 2010 at 12:47 PM, Allyn Romanow (allyn) w= rote: > Hi Magnus, > I was really glad that you had a chance to carefully consider the propose= d work. > Like Peter, I too agree with most of your comments. > Specific points below. > > Best regards, > Allyn > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Beh= alf Of Magnus Westerlund > Sent: Tuesday, October 12, 2010 6:47 AM > To: dispatch@ietf.org > Subject: [dispatch] Comments on the proposed Telepresence Charter > > Hi, > > Some colleagues and I have reviewed the two telepresence drafts and > version 5 of the charter and have some comments on the charter. > > To make our comments more understandable I think we should explain our > view on telepresence. First we are expecting great variations in the > capabilities of the participating terminals in a session. From personal > terminals for individual users up to multi-display, cameras and > microphone setups. We also expect that more than two end-points being > present in the same session. As we see it it will require good support > for centralized media handling in a mixer (MCU). We also see video > streams not only of high quality to be presented for maximum immersion, > but also lower qualities that can be used to monitor activity in other > rooms that aren't the ones selected for high quality. > > [AR] Yes, absolutely. > > Independent if one uses a central mixer or a full mesh there appears to > be a lack in media stream negotiation for how to negotiate what > capabilities the receiving client has in receiving, decoding and > rendering when it comes to number of simultaneous streams. Our > understanding is that RTP mandates any number of streams, while in > reality outside of conferencing that is in fact one single stream. > However with telepresence and conferencing there is a need to negotiate > the actual capability, especially between a mixer and client when it > comes to deliver multiple streams for various usages. > > [AR] Yes, agree - as you saw, this is covered in the charter. > > We also think there is missing functionality for expressing who are the > currently active speakers. The RTP CSRC field are not sufficient as they > express which end-points are included in the mix. However, as one likely > include in a mix more rooms than the active speakers to ensure that any > interruption and ambient sound are correctly captured an mechanism for > indicating the currently active speakers are needed. There is also need > to agree on the type of identifier to be used that allow for mapping to > full user names when appropriate. > > [AR] Yes.. Both of these points are covered in the charter too, right? > > The charter includes an item to work on control between client and a > mixer what streams should be delivered. We would like to extended this > to allow also the mixer to control the client on when streams are > delivered. In cases where there are more users then available display > area and a particular user is not actually included in any outgoing > mix/selection from the mixer then there is little point in that the > client consumes network resources. Thus we suggest that the stream > selection and control work is extended to allow also the mixer to pause > individual streams from the client to the mixer. Please note that such > control needs to be responsive, thus using the SIP signaling path for > this is to slow, it needs to be on the media path. > > [AR} I agree with your point that it would be good to pause the sender, b= ut I think that falls > =A0under the category of "continuous conference control" which is out of = the scope of this charter. > =A0Such a feedback mechanism falls probably under AVT. > I think it would be good to add a sentence saying something like, As cont= rol issues > necessary for interoperability arise, they will be directed appropriately= . > What do you think? > > > Another question to the group is, are there agreement on how streams > should organized into RTP sessions and how they are utilized? If > anything is documented I would appreciate a pointer. The media streams > are for different purposes from different end-points which are then > mixed by a central point and delivered to end-points. My impression for > example is that most proprietary system breaks the RTP semantics and use > individual sessions between the mixer and each end-point, instead of a > joint session. Here also different robustification tools for RTP such as > FEC and Retransmission needs to be considered. This might be work that > belongs in AVT, but are there need for further clarification into this > field? > > [AR} Agree this needs to be worked out for Telepresence, and that any act= ivity about it would go to AVT and/or MMUSIC. > > Comments much appreciated and we can gladly suggest text additions to > the charter proposal. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287 > F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ > 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 hmmr@cisco.com Thu Oct 14 06:44:55 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF0B33A69DC for ; Thu, 14 Oct 2010 06:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=-3.925, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mt7hJxICY7Au for ; Thu, 14 Oct 2010 06:44:54 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 7BF003A6948 for ; Thu, 14 Oct 2010 06:44:53 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoAEAPCmtkyQ/khMgWdsb2JhbAChKRUBARYiIqBDnGIChUYEhFOIfA X-IronPort-AV: E=Sophos;i="4.57,330,1283731200"; d="scan'208";a="11329226" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 14 Oct 2010 13:46:11 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o9EDk9Q2008927; Thu, 14 Oct 2010 13:46:11 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Oct 2010 08:46:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Oct 2010 08:46:08 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Comments on the proposed Telepresence Charter Thread-Index: ActrgcyGr2IESMdKSW2vLokzl9UESwAH/tHg References: <4CB466D5.8060601@ericsson.com><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02A47987@xmb-sjc-221.amer.cisco.com> From: "Mike Hammer (hmmr)" To: "Peter Musgrave" , "Allyn Romanow (allyn)" X-OriginalArrivalTime: 14 Oct 2010 13:46:10.0336 (UTC) FILETIME=[28CB8200:01CB6BA6] Cc: dispatch@ietf.org Subject: Re: [dispatch] Comments on the proposed Telepresence Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 13:44:55 -0000 Peter, I have not issue with your proposed words, since they are essentially = asking for a "mute" button for all types of communications used by a = sender. This may complicate the algorithm for all the receive systems = to know what to display, if for example, you continue to speak, but turn = off the video transmission. A "mute all" option might be more polite. I did have issue with this comment: "more like onhold/offhold type = negotiation" I am not sure I would agree with this. =20 There needs to be a distinction between when a call starts and when a = call stops, the call being *all* communications (sessions) between two = points. Granted putting a call on hold seems like floor control, but = the participants of the call on hold are effectively out of the call = (left the room) until brought off-hold. This is SIP level action. There needs to be a clear distinction between negotiating capabilities, = aka knowing what capabilities an endpoint has, and using those = capabilities during a call. That learning process is done via SDP. The latter part seems to be floor control, continuous conference = control, or whatever you want to call it. There seems to be splitting = of hairs over whether the floor control is manual or automatic = (determined by the loudest speaker). This may be AVT. In summary, you have room access, you define capabilities, you have = "speaker" conflict resolution control. (Note, point-to-point calls are = devolution since resolution of conflict is a non-problem with only one = opposing party.) Did I miss some other nuance? Mike -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Peter Musgrave Sent: Thursday, October 14, 2010 5:25 AM To: Allyn Romanow (allyn) Cc: dispatch@ietf.org Subject: Re: [dispatch] Comments on the proposed Telepresence Charter HI Allyn/Magnus, W.R.T "[AR} I agree with your point that it would be good to pause the sender, but I think that falls under the category of "continuous conference control" which is out of the scope of this charter. Such a feedback mechanism falls probably under AVT. I think it would be good to add a sentence saying something like, As control issues necessary for interoperability arise, they will be directed = appropriately. What do you think?" I think these words leave room to *not* do what Magnus is suggesting. e.g. If I have a 1 screen home TP system getting three streams from a 3 camera system and selecting only one it is not really "necessary" to tell the 3 camera system to pause two streams - but it is a really good idea to have a way to that! I don't view this is a continuous conference control issue (since that gets into floor control which I agree is out of scope) but more like onhold/offhold type negotiation. I think this is to some extent a plumbing issue (and based on the desired response time SIP or media path messages will be required). So I would still like to see a statement which makes it clear that it not just an issue of receiver selection but there is a need to communicate that selection back to the sender. The current text does not say this. Hence my suggestion: "Selection choices will be communicated to the sending party to allow the sender to optionally present information on which streams are in use and to optionally suspend streams which are not in use." ?? I'm open to other words or some indication of which language in the current charter ensures this is in scope. Regards, Peter Musgrave On Wed, Oct 13, 2010 at 12:47 PM, Allyn Romanow (allyn) = wrote: > Hi Magnus, > I was really glad that you had a chance to carefully consider the = proposed work. > Like Peter, I too agree with most of your comments. > Specific points below. > > Best regards, > Allyn > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Magnus Westerlund > Sent: Tuesday, October 12, 2010 6:47 AM > To: dispatch@ietf.org > Subject: [dispatch] Comments on the proposed Telepresence Charter > > Hi, > > Some colleagues and I have reviewed the two telepresence drafts and > version 5 of the charter and have some comments on the charter. > > To make our comments more understandable I think we should explain our > view on telepresence. First we are expecting great variations in the > capabilities of the participating terminals in a session. From = personal > terminals for individual users up to multi-display, cameras and > microphone setups. We also expect that more than two end-points being > present in the same session. As we see it it will require good support > for centralized media handling in a mixer (MCU). We also see video > streams not only of high quality to be presented for maximum = immersion, > but also lower qualities that can be used to monitor activity in other > rooms that aren't the ones selected for high quality. > > [AR] Yes, absolutely. > > Independent if one uses a central mixer or a full mesh there appears = to > be a lack in media stream negotiation for how to negotiate what > capabilities the receiving client has in receiving, decoding and > rendering when it comes to number of simultaneous streams. Our > understanding is that RTP mandates any number of streams, while in > reality outside of conferencing that is in fact one single stream. > However with telepresence and conferencing there is a need to = negotiate > the actual capability, especially between a mixer and client when it > comes to deliver multiple streams for various usages. > > [AR] Yes, agree - as you saw, this is covered in the charter. > > We also think there is missing functionality for expressing who are = the > currently active speakers. The RTP CSRC field are not sufficient as = they > express which end-points are included in the mix. However, as one = likely > include in a mix more rooms than the active speakers to ensure that = any > interruption and ambient sound are correctly captured an mechanism for > indicating the currently active speakers are needed. There is also = need > to agree on the type of identifier to be used that allow for mapping = to > full user names when appropriate. > > [AR] Yes.. Both of these points are covered in the charter too, right? > > The charter includes an item to work on control between client and a > mixer what streams should be delivered. We would like to extended this > to allow also the mixer to control the client on when streams are > delivered. In cases where there are more users then available display > area and a particular user is not actually included in any outgoing > mix/selection from the mixer then there is little point in that the > client consumes network resources. Thus we suggest that the stream > selection and control work is extended to allow also the mixer to = pause > individual streams from the client to the mixer. Please note that such > control needs to be responsive, thus using the SIP signaling path for > this is to slow, it needs to be on the media path. > > [AR} I agree with your point that it would be good to pause the = sender, but I think that falls > =A0under the category of "continuous conference control" which is out = of the scope of this charter. > =A0Such a feedback mechanism falls probably under AVT. > I think it would be good to add a sentence saying something like, As = control issues > necessary for interoperability arise, they will be directed = appropriately. > What do you think? > > > Another question to the group is, are there agreement on how streams > should organized into RTP sessions and how they are utilized? If > anything is documented I would appreciate a pointer. The media streams > are for different purposes from different end-points which are then > mixed by a central point and delivered to end-points. My impression = for > example is that most proprietary system breaks the RTP semantics and = use > individual sessions between the mixer and each end-point, instead of a > joint session. Here also different robustification tools for RTP such = as > FEC and Retransmission needs to be considered. This might be work that > belongs in AVT, but are there need for further clarification into this > field? > > [AR} Agree this needs to be worked out for Telepresence, and that any = activity about it would go to AVT and/or MMUSIC. > > Comments much appreciated and we can gladly suggest text additions to > the charter proposal. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287 > F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ > 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 > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From mary.ietf.barnes@gmail.com Thu Oct 14 07:40:31 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B7013A6A4C for ; Thu, 14 Oct 2010 07:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARRRSciMRO9j for ; Thu, 14 Oct 2010 07:40:30 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 2F5373A6AB0 for ; Thu, 14 Oct 2010 07:40:30 -0700 (PDT) Received: by iwn10 with SMTP id 10so9633558iwn.31 for ; Thu, 14 Oct 2010 07:41:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=pgC55VsTY0bAqmMZwCU24M3KStuMfk0UHzBVw1VNZBs=; b=HqPrYd5BnkTBMsbhGN7WeNyK0qGbemfU8L3foig5CRt3def1XLu7eIrV6jDxzwTlMd QLwQOWVNQ3E89eCpTRsMFxL0W6fQNQfk2LxIKZaauQWStY8TuGcutvUrIPdFodMcfYSb YTCy1NEXExbeZaV7qYrp08eqFjKMaCoi4Pwjs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=XjUbe0MG1tWEz7n1KNsTYPfd6xQjUEXxouvxcdsys9j8jypKgeFB2yamMDL/eNCfUb QBtXCp09gUk0mS/7TbCmOz8Cnkx8G9naVaeLwGDvg+4z0id+0STSOAk6EzrsXFxsydxi UGOmiQ2j42tIfnC2UPoM1rbk0Z8WZcpfWMWOg= MIME-Version: 1.0 Received: by 10.42.176.194 with SMTP id bf2mr2201425icb.435.1287067308921; Thu, 14 Oct 2010 07:41:48 -0700 (PDT) Received: by 10.236.108.172 with HTTP; Thu, 14 Oct 2010 07:41:48 -0700 (PDT) In-Reply-To: <20101013235546.6CB2D3A69EF@core3.amsl.com> References: <20101013235546.6CB2D3A69EF@core3.amsl.com> Date: Thu, 14 Oct 2010 09:41:48 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: text/plain; charset=ISO-8859-1 Subject: [dispatch] Fwd: New Non-WG Mailing List: maitai -- Multi-stream Attributes for Improving Telepresence Application Interoperability X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 14:40:31 -0000 FYI...this is for discussion (as noted below) of technical issues and not for charter discussion. Please continue to post comments wrt the charter on the DISPATCH WG mailing list. Regards, Mary. DISPATCH WG co-chair ---------- Forwarded message ---------- From: IETF Secretariat Date: Wed, Oct 13, 2010 at 6:55 PM Subject: New Non-WG Mailing List: maitai -- Multi-stream Attributes for Improving Telepresence Application Interoperability To: IETF Announcement list Cc: maitai@ietf.org, allyn@cisco.com, mary.ietf.barnes@gmail.com A new IETF non-working group email list has been created. List address: maitai@ietf.org (Multi-stream Attributes for Improving Telepresence Application Interoperability) Archive: http://www.ietf.org/mail-archive/web/maitai/ To subscribe: https://www.ietf.org/mailman/listinfo/maitai Description: Discussions pertaining to the issues involved in handling multiple streams of media for telepresence conferences. Not for discussion of charter of proposed working group. For additional information, please contact the list administrators. From spromano@unina.it Thu Oct 14 07:48:35 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 275D43A6961 for ; Thu, 14 Oct 2010 07:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.719 X-Spam-Level: X-Spam-Status: No, score=-100.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcIuais39FEN for ; Thu, 14 Oct 2010 07:48:33 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by core3.amsl.com (Postfix) with ESMTP id 0EE623A68DB for ; Thu, 14 Oct 2010 07:48:32 -0700 (PDT) Received: from [10.85.1.155] ([213.61.72.5]) (authenticated bits=0) by smtp1.unina.it (8.14.0/8.14.0) with ESMTP id o9EEnnxf012045 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 14 Oct 2010 16:49:50 +0200 Message-ID: <4CB7186A.10707@unina.it> Date: Thu, 14 Oct 2010 16:49:14 +0200 From: Simon Pietro Romano User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; it; rv:1.9.1.12) Gecko/20100914 Thunderbird/3.0.8 MIME-Version: 1.0 To: dispatch@ietf.org References: <4CB466D5.8060601@ericsson.com><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02A47987@xmb-sjc-221.amer.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dispatch] Comments on the proposed Telepresence Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 14:48:35 -0000 Hi, let me jump into the "mute" (aka on-hold/off-hold) discussion. I would suggest that BFCP can be fruitfully employed here. BFCP can surely provide the mixer with a chance to add/remove streams to the mixed flow by using a policy-based approach. With respect to the issue raised in this thread, which I report here for brevity: > We would like to extended this > to allow also the mixer to control the client on when streams are > delivered. In cases where there are more users then available display > area and a particular user is not actually included in any outgoing > mix/selection from the mixer then there is little point in that the > client consumes network resources. Thus we suggest that the stream > selection and control work is extended to allow also the mixer to pause > individual streams from the client to the mixer. Please note that such > control needs to be responsive, thus using the SIP signaling path for > this is to slow, it needs to be on the media path. I would say that also here BFCP might play a role. If the mixer, acting as a floor control server, removes the floor from a BFCP-aware client, such client is expected (even though it is not required) to stop sending data to the mixer, since it can be sure that such contribution will not be taken into account when building up the mix. Simon Il 14/10/2010 15.46, Mike Hammer (hmmr) ha scritto: > Peter, > > I have not issue with your proposed words, since they are essentially asking for a "mute" button for all types of communications used by a sender. This may complicate the algorithm for all the receive systems to know what to display, if for example, you continue to speak, but turn off the video transmission. A "mute all" option might be more polite. > > I did have issue with this comment: "more like onhold/offhold type negotiation" > > I am not sure I would agree with this. > > There needs to be a distinction between when a call starts and when a call stops, the call being *all* communications (sessions) between two points. Granted putting a call on hold seems like floor control, but the participants of the call on hold are effectively out of the call (left the room) until brought off-hold. This is SIP level action. > > There needs to be a clear distinction between negotiating capabilities, aka knowing what capabilities an endpoint has, and using those capabilities during a call. That learning process is done via SDP. > > The latter part seems to be floor control, continuous conference control, or whatever you want to call it. There seems to be splitting of hairs over whether the floor control is manual or automatic (determined by the loudest speaker). This may be AVT. > > In summary, you have room access, you define capabilities, you have "speaker" conflict resolution control. (Note, point-to-point calls are devolution since resolution of conflict is a non-problem with only one opposing party.) > > Did I miss some other nuance? > > Mike > > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Peter Musgrave > Sent: Thursday, October 14, 2010 5:25 AM > To: Allyn Romanow (allyn) > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Comments on the proposed Telepresence Charter > > HI Allyn/Magnus, > > W.R.T > > "[AR} I agree with your point that it would be good to pause the > sender, but I think that falls > under the category of "continuous conference control" which is out of > the scope of this charter. > Such a feedback mechanism falls probably under AVT. > I think it would be good to add a sentence saying something like, As > control issues > necessary for interoperability arise, they will be directed appropriately. > What do you think?" > > I think these words leave room to *not* do what Magnus is suggesting. > e.g. If I have a 1 screen home TP system getting three streams from a > 3 camera system and selecting only one it is not really "necessary" to > tell the 3 camera system to pause two streams - but it is a really > good idea to have a way to that! I don't view this is a continuous > conference control issue (since that gets into floor control which I > agree is out of scope) but more like onhold/offhold type negotiation. > I think this is to some extent a plumbing issue (and based on the > desired response time SIP or media path messages will be required). > > So I would still like to see a statement which makes it clear that it > not just an issue of receiver selection but there is a need to > communicate that selection back to the sender. The current text does > not say this. Hence my suggestion: > > "Selection choices will be communicated to the sending party to allow > the sender to optionally present information on which streams are in > use and to optionally suspend streams which are not in use." ?? > > I'm open to other words or some indication of which language in the > current charter ensures this is in scope. > > Regards, > > Peter Musgrave > > > > > On Wed, Oct 13, 2010 at 12:47 PM, Allyn Romanow (allyn) wrote: > >> Hi Magnus, >> I was really glad that you had a chance to carefully consider the proposed work. >> Like Peter, I too agree with most of your comments. >> Specific points below. >> >> Best regards, >> Allyn >> >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Magnus Westerlund >> Sent: Tuesday, October 12, 2010 6:47 AM >> To: dispatch@ietf.org >> Subject: [dispatch] Comments on the proposed Telepresence Charter >> >> Hi, >> >> Some colleagues and I have reviewed the two telepresence drafts and >> version 5 of the charter and have some comments on the charter. >> >> To make our comments more understandable I think we should explain our >> view on telepresence. First we are expecting great variations in the >> capabilities of the participating terminals in a session. From personal >> terminals for individual users up to multi-display, cameras and >> microphone setups. We also expect that more than two end-points being >> present in the same session. As we see it it will require good support >> for centralized media handling in a mixer (MCU). We also see video >> streams not only of high quality to be presented for maximum immersion, >> but also lower qualities that can be used to monitor activity in other >> rooms that aren't the ones selected for high quality. >> >> [AR] Yes, absolutely. >> >> Independent if one uses a central mixer or a full mesh there appears to >> be a lack in media stream negotiation for how to negotiate what >> capabilities the receiving client has in receiving, decoding and >> rendering when it comes to number of simultaneous streams. Our >> understanding is that RTP mandates any number of streams, while in >> reality outside of conferencing that is in fact one single stream. >> However with telepresence and conferencing there is a need to negotiate >> the actual capability, especially between a mixer and client when it >> comes to deliver multiple streams for various usages. >> >> [AR] Yes, agree - as you saw, this is covered in the charter. >> >> We also think there is missing functionality for expressing who are the >> currently active speakers. The RTP CSRC field are not sufficient as they >> express which end-points are included in the mix. However, as one likely >> include in a mix more rooms than the active speakers to ensure that any >> interruption and ambient sound are correctly captured an mechanism for >> indicating the currently active speakers are needed. There is also need >> to agree on the type of identifier to be used that allow for mapping to >> full user names when appropriate. >> >> [AR] Yes.. Both of these points are covered in the charter too, right? >> >> The charter includes an item to work on control between client and a >> mixer what streams should be delivered. We would like to extended this >> to allow also the mixer to control the client on when streams are >> delivered. In cases where there are more users then available display >> area and a particular user is not actually included in any outgoing >> mix/selection from the mixer then there is little point in that the >> client consumes network resources. Thus we suggest that the stream >> selection and control work is extended to allow also the mixer to pause >> individual streams from the client to the mixer. Please note that such >> control needs to be responsive, thus using the SIP signaling path for >> this is to slow, it needs to be on the media path. >> >> [AR} I agree with your point that it would be good to pause the sender, but I think that falls >> under the category of "continuous conference control" which is out of the scope of this charter. >> Such a feedback mechanism falls probably under AVT. >> I think it would be good to add a sentence saying something like, As control issues >> necessary for interoperability arise, they will be directed appropriately. >> What do you think? >> >> >> Another question to the group is, are there agreement on how streams >> should organized into RTP sessions and how they are utilized? If >> anything is documented I would appreciate a pointer. The media streams >> are for different purposes from different end-points which are then >> mixed by a central point and delivered to end-points. My impression for >> example is that most proprietary system breaks the RTP semantics and use >> individual sessions between the mixer and each end-point, instead of a >> joint session. Here also different robustification tools for RTP such as >> FEC and Retransmission needs to be considered. This might be work that >> belongs in AVT, but are there need for further clarification into this >> field? >> >> [AR} Agree this needs to be worked out for Telepresence, and that any activity about it would go to AVT and/or MMUSIC. >> >> Comments much appreciated and we can gladly suggest text additions to >> the charter proposal. >> >> Cheers >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Färögatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> _______________________________________________ >> 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 >> >> > _______________________________________________ > 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 > > -- _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Science Department Phone: +39 081 7683823 -- Fax: +39 081 7684219 e-mail: spromano@unina.it http://www.comics.unina.it/simonpietro.romano <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ From peter.musgrave@magorcorp.com Thu Oct 14 07:53:16 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B57E3A6953 for ; Thu, 14 Oct 2010 07:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.861 X-Spam-Level: X-Spam-Status: No, score=-101.861 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7PFIEqRC18B for ; Thu, 14 Oct 2010 07:53:14 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 431663A68ED for ; Thu, 14 Oct 2010 07:53:14 -0700 (PDT) Received: by qyk36 with SMTP id 36so5822048qyk.10 for ; Thu, 14 Oct 2010 07:54:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.89.11 with SMTP id c11mr4023581qam.25.1287068070653; Thu, 14 Oct 2010 07:54:30 -0700 (PDT) Received: by 10.229.42.196 with HTTP; Thu, 14 Oct 2010 07:54:30 -0700 (PDT) In-Reply-To: References: <4CB466D5.8060601@ericsson.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02A47987@xmb-sjc-221.amer.cisco.com> Date: Thu, 14 Oct 2010 10:54:30 -0400 Message-ID: From: Peter Musgrave To: "Mike Hammer (hmmr)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dispatch@ietf.org Subject: Re: [dispatch] Comments on the proposed Telepresence Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 14:53:16 -0000 Hi Mike, I agree the onhld/offhold analogy is a poor one. It is a suspension of a call - which is not intended. Let me re-phrase and see if we agree: A sends B three video streams and one audio stream . B has one display and opts to display one of the three streams. There is a mechanism for B to tell A that this has happened (and to say when it wishes to display some other stream from A). Do we think that the work to do this type of stream-suspension is floor control? (My opinion is no. I view floor control more as who is the source for a given stream and not a selection of an agreed upon stream). Do we think this work is in scope for Telepresence Interoperability? I think this is an essential element to deployable TP operation especially as in expands to "at home" use. If an architecture in which a room sends all video all the time (even though it's not being used) is viewed as necessary to avoid complexity/meet responsiveness requirements is thought to be ok then I'd like to make sure we are clear that that these limitations exist upfront. My preference is obviously to permit this feedback and tweak the proposed charter. Other opinions? Regards, Peter Musgrave On Thu, Oct 14, 2010 at 9:46 AM, Mike Hammer (hmmr) wrote: > Peter, > > I have not issue with your proposed words, since they are essentially ask= ing for a "mute" button for all types of communications used by a sender. = =A0This may complicate the algorithm for all the receive systems to know wh= at to display, if for example, you continue to speak, but turn off the vide= o transmission. =A0A "mute all" option might be more polite. > > I did have issue with this comment: =A0"more like onhold/offhold type neg= otiation" > > I am not sure I would agree with this. > > There needs to be a distinction between when a call starts and when a cal= l stops, the call being *all* communications (sessions) between two points.= =A0Granted putting a call on hold seems like floor control, but the partic= ipants of the call on hold are effectively out of the call (left the room) = until brought off-hold. =A0This is SIP level action. > > There needs to be a clear distinction between negotiating capabilities, a= ka knowing what capabilities an endpoint has, and using those capabilities = during a call. =A0That learning process is done via SDP. > > The latter part seems to be floor control, continuous conference control,= or whatever you want to call it. =A0There seems to be splitting of hairs o= ver whether the floor control is manual or automatic (determined by the lou= dest speaker). =A0This may be AVT. > > In summary, you have room access, you define capabilities, you have "spea= ker" conflict resolution control. =A0(Note, point-to-point calls are devolu= tion since resolution of conflict is a non-problem with only one opposing p= arty.) > > Did I miss some other nuance? > > Mike > > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Beh= alf Of Peter Musgrave > Sent: Thursday, October 14, 2010 5:25 AM > To: Allyn Romanow (allyn) > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Comments on the proposed Telepresence Charter > > HI Allyn/Magnus, > > W.R.T > > "[AR} I agree with your point that it would be good to pause the > sender, but I think that falls > =A0under the category of "continuous conference control" which is out of > the scope of this charter. > =A0Such a feedback mechanism falls probably under AVT. > I think it would be good to add a sentence saying something like, As > control issues > necessary for interoperability arise, they will be directed appropriately= . > What do you think?" > > I think these words leave room to *not* do what Magnus is suggesting. > e.g. If I have a 1 screen home TP system getting three streams from a > 3 camera system and selecting only one it is not really "necessary" to > tell the 3 camera system to pause two streams - but it is a really > good idea to have a way to that! I don't view this is a continuous > conference control issue (since that gets into floor control which I > agree is out of scope) but more like onhold/offhold type negotiation. > I think this is to some extent a plumbing issue (and based on the > desired response time SIP or media path messages will be required). > > So I would still like to see a statement which makes it clear that it > not just an issue of receiver selection but there is a need to > communicate that selection back to the sender. The current text does > not say this. Hence my suggestion: > > "Selection choices will be communicated to the sending party to allow > the sender to optionally present information on which streams are in > use and to optionally suspend streams which are not in use." ?? > > I'm open to other words or some indication of which language in the > current charter ensures this is in scope. > > Regards, > > Peter Musgrave > > > > > On Wed, Oct 13, 2010 at 12:47 PM, Allyn Romanow (allyn) = wrote: >> Hi Magnus, >> I was really glad that you had a chance to carefully consider the propos= ed work. >> Like Peter, I too agree with most of your comments. >> Specific points below. >> >> Best regards, >> Allyn >> >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Be= half Of Magnus Westerlund >> Sent: Tuesday, October 12, 2010 6:47 AM >> To: dispatch@ietf.org >> Subject: [dispatch] Comments on the proposed Telepresence Charter >> >> Hi, >> >> Some colleagues and I have reviewed the two telepresence drafts and >> version 5 of the charter and have some comments on the charter. >> >> To make our comments more understandable I think we should explain our >> view on telepresence. First we are expecting great variations in the >> capabilities of the participating terminals in a session. From personal >> terminals for individual users up to multi-display, cameras and >> microphone setups. We also expect that more than two end-points being >> present in the same session. As we see it it will require good support >> for centralized media handling in a mixer (MCU). We also see video >> streams not only of high quality to be presented for maximum immersion, >> but also lower qualities that can be used to monitor activity in other >> rooms that aren't the ones selected for high quality. >> >> [AR] Yes, absolutely. >> >> Independent if one uses a central mixer or a full mesh there appears to >> be a lack in media stream negotiation for how to negotiate what >> capabilities the receiving client has in receiving, decoding and >> rendering when it comes to number of simultaneous streams. Our >> understanding is that RTP mandates any number of streams, while in >> reality outside of conferencing that is in fact one single stream. >> However with telepresence and conferencing there is a need to negotiate >> the actual capability, especially between a mixer and client when it >> comes to deliver multiple streams for various usages. >> >> [AR] Yes, agree - as you saw, this is covered in the charter. >> >> We also think there is missing functionality for expressing who are the >> currently active speakers. The RTP CSRC field are not sufficient as they >> express which end-points are included in the mix. However, as one likely >> include in a mix more rooms than the active speakers to ensure that any >> interruption and ambient sound are correctly captured an mechanism for >> indicating the currently active speakers are needed. There is also need >> to agree on the type of identifier to be used that allow for mapping to >> full user names when appropriate. >> >> [AR] Yes.. Both of these points are covered in the charter too, right? >> >> The charter includes an item to work on control between client and a >> mixer what streams should be delivered. We would like to extended this >> to allow also the mixer to control the client on when streams are >> delivered. In cases where there are more users then available display >> area and a particular user is not actually included in any outgoing >> mix/selection from the mixer then there is little point in that the >> client consumes network resources. Thus we suggest that the stream >> selection and control work is extended to allow also the mixer to pause >> individual streams from the client to the mixer. Please note that such >> control needs to be responsive, thus using the SIP signaling path for >> this is to slow, it needs to be on the media path. >> >> [AR} I agree with your point that it would be good to pause the sender, = but I think that falls >> =A0under the category of "continuous conference control" which is out of= the scope of this charter. >> =A0Such a feedback mechanism falls probably under AVT. >> I think it would be good to add a sentence saying something like, As con= trol issues >> necessary for interoperability arise, they will be directed appropriatel= y. >> What do you think? >> >> >> Another question to the group is, are there agreement on how streams >> should organized into RTP sessions and how they are utilized? If >> anything is documented I would appreciate a pointer. The media streams >> are for different purposes from different end-points which are then >> mixed by a central point and delivered to end-points. My impression for >> example is that most proprietary system breaks the RTP semantics and use >> individual sessions between the mixer and each end-point, instead of a >> joint session. Here also different robustification tools for RTP such as >> FEC and Retransmission needs to be considered. This might be work that >> belongs in AVT, but are there need for further clarification into this >> field? >> >> [AR} Agree this needs to be worked out for Telepresence, and that any ac= tivity about it would go to AVT and/or MMUSIC. >> >> Comments much appreciated and we can gladly suggest text additions to >> the charter proposal. >> >> Cheers >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287 >> F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> _______________________________________________ >> 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 >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From hmmr@cisco.com Thu Oct 14 08:54:19 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14D553A6B0F for ; Thu, 14 Oct 2010 08:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.739 X-Spam-Level: X-Spam-Status: No, score=-9.739 tagged_above=-999 required=5 tests=[AWL=0.860, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txKzDbX5Zoku for ; Thu, 14 Oct 2010 08:54:02 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 6F8093A6B09 for ; Thu, 14 Oct 2010 08:53:54 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACvFtkytJV2Z/2dsb2JhbAChKXGjP5x6AoMECII6BIRTgSmEAYNS X-IronPort-AV: E=Sophos;i="4.57,330,1283731200"; d="scan'208";a="170703679" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-2.cisco.com with ESMTP; 14 Oct 2010 15:55:12 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o9EFtC4u024789; Thu, 14 Oct 2010 15:55:12 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Oct 2010 10:55:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Oct 2010 10:55:11 -0500 Message-ID: In-Reply-To: <4CB7186A.10707@unina.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Comments on the proposed Telepresence Charter Thread-Index: ActrrxLg4w325jIAQIyX7NHzDp7wTgABvGJQ References: <4CB466D5.8060601@ericsson.com><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02A47987@xmb-sjc-221.amer.cisco.com> <4CB7186A.10707@unina.it> From: "Mike Hammer (hmmr)" To: "Simon Pietro Romano" , X-OriginalArrivalTime: 14 Oct 2010 15:55:12.0366 (UTC) FILETIME=[2F6788E0:01CB6BB8] Subject: Re: [dispatch] Comments on the proposed Telepresence Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 15:54:19 -0000 Simon, Agree that SIP is likely too slow. Plus my concern that it's connection = into other back-end systems (e.g. accounting) might affect those = secondary systems. I agree that BFCP might be able to provide needed capabilities, and thus = should not be excluded by the charter. However, when studying the problem space, I would hope we would not be = too constrained by earlier designs, if more recent experience might = suggest a different approach. =20 For example, we gained advantages by separating the signaling and media = planes for VoIP. Here too, we might find that it is useful to separate = out into different protocols the aspects of: - declaring media control powers (who is capable of MCU mixing) - selection/assignment of powers to a particular device - passing of powers (e.g. host or presenter) from one device to another - execution of powers at a particular point - response to power assertion by non-power devices. Note, that some of the above could be done in SDP with Offer/Answer, = some could be power agreements in some signaling protocol, and some = could be media plane controls. In essence, the (floor control) policy = control and policy execution could be split into two or three planes. My point here is not to agree to any such thing at this time, only the = recognition that the existing protocols may prove deficient, and though = overlapping, the WG should be allowed the latitude to do the smart thing = and not be overly constrained. I am sure the AD's can help guide the = WG, if they see it getting too far out of bounds. Thanks, Mike -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Simon Pietro Romano Sent: Thursday, October 14, 2010 10:49 AM To: dispatch@ietf.org Subject: Re: [dispatch] Comments on the proposed Telepresence Charter Hi, let me jump into the "mute" (aka on-hold/off-hold) discussion. I would=20 suggest that BFCP can be fruitfully employed here. BFCP can surely=20 provide the mixer with a chance to add/remove streams to the mixed flow=20 by using a policy-based approach. With respect to the issue raised in=20 this thread, which I report here for brevity: > We would like to extended this > to allow also the mixer to control the client on when streams are > delivered. In cases where there are more users then available display > area and a particular user is not actually included in any outgoing > mix/selection from the mixer then there is little point in that the > client consumes network resources. Thus we suggest that the stream > selection and control work is extended to allow also the mixer to = pause > individual streams from the client to the mixer. Please note that such > control needs to be responsive, thus using the SIP signaling path for > this is to slow, it needs to be on the media path. I would say that also here BFCP might play a role. If the mixer, acting=20 as a floor control server, removes the floor from a BFCP-aware client,=20 such client is expected (even though it is not required) to stop sending = data to the mixer, since it can be sure that such contribution will not=20 be taken into account when building up the mix. Simon Il 14/10/2010 15.46, Mike Hammer (hmmr) ha scritto: > Peter, > > I have not issue with your proposed words, since they are essentially = asking for a "mute" button for all types of communications used by a = sender. This may complicate the algorithm for all the receive systems = to know what to display, if for example, you continue to speak, but turn = off the video transmission. A "mute all" option might be more polite. > > I did have issue with this comment: "more like onhold/offhold type = negotiation" > > I am not sure I would agree with this. > > There needs to be a distinction between when a call starts and when a = call stops, the call being *all* communications (sessions) between two = points. Granted putting a call on hold seems like floor control, but = the participants of the call on hold are effectively out of the call = (left the room) until brought off-hold. This is SIP level action. > > There needs to be a clear distinction between negotiating = capabilities, aka knowing what capabilities an endpoint has, and using = those capabilities during a call. That learning process is done via = SDP. > > The latter part seems to be floor control, continuous conference = control, or whatever you want to call it. There seems to be splitting = of hairs over whether the floor control is manual or automatic = (determined by the loudest speaker). This may be AVT. > > In summary, you have room access, you define capabilities, you have = "speaker" conflict resolution control. (Note, point-to-point calls are = devolution since resolution of conflict is a non-problem with only one = opposing party.) > > Did I miss some other nuance? > > Mike > > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Peter Musgrave > Sent: Thursday, October 14, 2010 5:25 AM > To: Allyn Romanow (allyn) > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Comments on the proposed Telepresence Charter > > HI Allyn/Magnus, > > W.R.T > > "[AR} I agree with your point that it would be good to pause the > sender, but I think that falls > under the category of "continuous conference control" which is out = of > the scope of this charter. > Such a feedback mechanism falls probably under AVT. > I think it would be good to add a sentence saying something like, As > control issues > necessary for interoperability arise, they will be directed = appropriately. > What do you think?" > > I think these words leave room to *not* do what Magnus is suggesting. > e.g. If I have a 1 screen home TP system getting three streams from a > 3 camera system and selecting only one it is not really "necessary" to > tell the 3 camera system to pause two streams - but it is a really > good idea to have a way to that! I don't view this is a continuous > conference control issue (since that gets into floor control which I > agree is out of scope) but more like onhold/offhold type negotiation. > I think this is to some extent a plumbing issue (and based on the > desired response time SIP or media path messages will be required). > > So I would still like to see a statement which makes it clear that it > not just an issue of receiver selection but there is a need to > communicate that selection back to the sender. The current text does > not say this. Hence my suggestion: > > "Selection choices will be communicated to the sending party to allow > the sender to optionally present information on which streams are in > use and to optionally suspend streams which are not in use." ?? > > I'm open to other words or some indication of which language in the > current charter ensures this is in scope. > > Regards, > > Peter Musgrave > > > > > On Wed, Oct 13, 2010 at 12:47 PM, Allyn Romanow = (allyn) wrote: > =20 >> Hi Magnus, >> I was really glad that you had a chance to carefully consider the = proposed work. >> Like Peter, I too agree with most of your comments. >> Specific points below. >> >> Best regards, >> Allyn >> >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Magnus Westerlund >> Sent: Tuesday, October 12, 2010 6:47 AM >> To: dispatch@ietf.org >> Subject: [dispatch] Comments on the proposed Telepresence Charter >> >> Hi, >> >> Some colleagues and I have reviewed the two telepresence drafts and >> version 5 of the charter and have some comments on the charter. >> >> To make our comments more understandable I think we should explain = our >> view on telepresence. First we are expecting great variations in the >> capabilities of the participating terminals in a session. From = personal >> terminals for individual users up to multi-display, cameras and >> microphone setups. We also expect that more than two end-points being >> present in the same session. As we see it it will require good = support >> for centralized media handling in a mixer (MCU). We also see video >> streams not only of high quality to be presented for maximum = immersion, >> but also lower qualities that can be used to monitor activity in = other >> rooms that aren't the ones selected for high quality. >> >> [AR] Yes, absolutely. >> >> Independent if one uses a central mixer or a full mesh there appears = to >> be a lack in media stream negotiation for how to negotiate what >> capabilities the receiving client has in receiving, decoding and >> rendering when it comes to number of simultaneous streams. Our >> understanding is that RTP mandates any number of streams, while in >> reality outside of conferencing that is in fact one single stream. >> However with telepresence and conferencing there is a need to = negotiate >> the actual capability, especially between a mixer and client when it >> comes to deliver multiple streams for various usages. >> >> [AR] Yes, agree - as you saw, this is covered in the charter. >> >> We also think there is missing functionality for expressing who are = the >> currently active speakers. The RTP CSRC field are not sufficient as = they >> express which end-points are included in the mix. However, as one = likely >> include in a mix more rooms than the active speakers to ensure that = any >> interruption and ambient sound are correctly captured an mechanism = for >> indicating the currently active speakers are needed. There is also = need >> to agree on the type of identifier to be used that allow for mapping = to >> full user names when appropriate. >> >> [AR] Yes.. Both of these points are covered in the charter too, = right? >> >> The charter includes an item to work on control between client and a >> mixer what streams should be delivered. We would like to extended = this >> to allow also the mixer to control the client on when streams are >> delivered. In cases where there are more users then available display >> area and a particular user is not actually included in any outgoing >> mix/selection from the mixer then there is little point in that the >> client consumes network resources. Thus we suggest that the stream >> selection and control work is extended to allow also the mixer to = pause >> individual streams from the client to the mixer. Please note that = such >> control needs to be responsive, thus using the SIP signaling path for >> this is to slow, it needs to be on the media path. >> >> [AR} I agree with your point that it would be good to pause the = sender, but I think that falls >> under the category of "continuous conference control" which is out = of the scope of this charter. >> Such a feedback mechanism falls probably under AVT. >> I think it would be good to add a sentence saying something like, As = control issues >> necessary for interoperability arise, they will be directed = appropriately. >> What do you think? >> >> >> Another question to the group is, are there agreement on how streams >> should organized into RTP sessions and how they are utilized? If >> anything is documented I would appreciate a pointer. The media = streams >> are for different purposes from different end-points which are then >> mixed by a central point and delivered to end-points. My impression = for >> example is that most proprietary system breaks the RTP semantics and = use >> individual sessions between the mixer and each end-point, instead of = a >> joint session. Here also different robustification tools for RTP such = as >> FEC and Retransmission needs to be considered. This might be work = that >> belongs in AVT, but are there need for further clarification into = this >> field? >> >> [AR} Agree this needs to be worked out for Telepresence, and that any = activity about it would go to AVT and/or MMUSIC. >> >> Comments much appreciated and we can gladly suggest text additions to >> the charter proposal. >> >> Cheers >> >> Magnus Westerlund >> >> = ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> = ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> = ---------------------------------------------------------------------- >> _______________________________________________ >> 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 > _______________________________________________ > 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 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Science Department Phone: +39 081 7683823 -- Fax: +39 081 7684219 e-mail: spromano@unina.it http://www.comics.unina.it/simonpietro.romano <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From lorenzo@meetecho.com Thu Oct 14 08:57:11 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E27C93A6A67 for ; Thu, 14 Oct 2010 08:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.694 X-Spam-Level: X-Spam-Status: No, score=-0.694 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 403HFmmqKFAA for ; Thu, 14 Oct 2010 08:57:10 -0700 (PDT) Received: from smtplq03.aruba.it (smtplq-out10.aruba.it [62.149.158.30]) by core3.amsl.com (Postfix) with SMTP id 56FA53A6956 for ; Thu, 14 Oct 2010 08:57:08 -0700 (PDT) Received: (qmail 17955 invoked by uid 89); 14 Oct 2010 15:58:18 -0000 Received: from unknown (HELO smtp5.aruba.it) (62.149.128.201) by smtplq03.aruba.it with SMTP; 14 Oct 2010 15:58:18 -0000 Received: (qmail 6397 invoked by uid 89); 14 Oct 2010 15:58:19 -0000 Received: from unknown (HELO lminiero-acer) (lorenzo@meetecho.com@143.225.229.172) by smtp5.ad.aruba.it with SMTP; 14 Oct 2010 15:58:19 -0000 Date: Thu, 14 Oct 2010 17:55:49 +0200 From: Lorenzo Miniero To: Peter Musgrave Message-Id: <20101014175549.1fab4bfe.lorenzo@meetecho.com> In-Reply-To: References: <4CB466D5.8060601@ericsson.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02A47987@xmb-sjc-221.amer.cisco.com> Organization: Meetecho X-Mailer: Sylpheed 2.6.0 (GTK+ 2.16.6; i586-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Rating: smtp5.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq03.aruba.it 1.6.2 0/1000/N Cc: dispatch@ietf.org Subject: Re: [dispatch] Comments on the proposed Telepresence Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 15:57:12 -0000 Hi Peter, I also see it as an important use case to have in the charter. I agree that floor control (e.g. BFCP) may not be needed in here (not an authorization scenario) even though it may come in handy and as such could at least be considered when we'll be talking about solutions. >From a "technical" point of view, I guess that, if we find a way to identify streams (what is what) then even just SDP updates may do the trick then: e.g., video 1 recvonly, video 2 and 3 inactive. But this would imply implicit feedback (I'm just telling I want one video out of three, and not why), and so may be restrictive for the use case. L. On Thu, 14 Oct 2010 10:54:30 -0400 Peter Musgrave wrote: > Hi Mike, >=20 > I agree the onhld/offhold analogy is a poor one. It is a suspension of > a call - which is not intended. >=20 > Let me re-phrase and see if we agree: >=20 > A sends B three video streams and one audio stream . > B has one display and opts to display one of the three streams. > There is a mechanism for B to tell A that this has happened (and to > say when it wishes to display some other stream from A). >=20 > Do we think that the work to do this type of stream-suspension is > floor control? (My opinion is no. I view floor control more as who is > the source for a given stream and not a selection of an agreed upon > stream). >=20 > Do we think this work is in scope for Telepresence Interoperability? I > think this is an essential element to deployable TP operation > especially as in expands to "at home" use. If an architecture in which > a room sends all video all the time (even though it's not being used) > is viewed as necessary to avoid complexity/meet responsiveness > requirements is thought to be ok then I'd like to make sure we are > clear that that these limitations exist upfront. >=20 > My preference is obviously to permit this feedback and tweak the > proposed charter. >=20 > Other opinions? >=20 > Regards, >=20 >=20 > Peter Musgrave >=20 > On Thu, Oct 14, 2010 at 9:46 AM, Mike Hammer (hmmr) wrot= e: > > Peter, > > > > I have not issue with your proposed words, since they are essentially a= sking for a "mute" button for all types of communications used by a sender.= =A0This may complicate the algorithm for all the receive systems to know w= hat to display, if for example, you continue to speak, but turn off the vid= eo transmission. =A0A "mute all" option might be more polite. > > > > I did have issue with this comment: =A0"more like onhold/offhold type n= egotiation" > > > > I am not sure I would agree with this. > > > > There needs to be a distinction between when a call starts and when a c= all stops, the call being *all* communications (sessions) between two point= s. =A0Granted putting a call on hold seems like floor control, but the part= icipants of the call on hold are effectively out of the call (left the room= ) until brought off-hold. =A0This is SIP level action. > > > > There needs to be a clear distinction between negotiating capabilities,= aka knowing what capabilities an endpoint has, and using those capabilitie= s during a call. =A0That learning process is done via SDP. > > > > The latter part seems to be floor control, continuous conference contro= l, or whatever you want to call it. =A0There seems to be splitting of hairs= over whether the floor control is manual or automatic (determined by the l= oudest speaker). =A0This may be AVT. > > > > In summary, you have room access, you define capabilities, you have "sp= eaker" conflict resolution control. =A0(Note, point-to-point calls are devo= lution since resolution of conflict is a non-problem with only one opposing= party.) > > > > Did I miss some other nuance? > > > > Mike > > > > > > -----Original Message----- > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On B= ehalf Of Peter Musgrave > > Sent: Thursday, October 14, 2010 5:25 AM > > To: Allyn Romanow (allyn) > > Cc: dispatch@ietf.org > > Subject: Re: [dispatch] Comments on the proposed Telepresence Charter > > > > HI Allyn/Magnus, > > > > W.R.T > > > > "[AR} I agree with your point that it would be good to pause the > > sender, but I think that falls > > =A0under the category of "continuous conference control" which is out of > > the scope of this charter. > > =A0Such a feedback mechanism falls probably under AVT. > > I think it would be good to add a sentence saying something like, As > > control issues > > necessary for interoperability arise, they will be directed appropriate= ly. > > What do you think?" > > > > I think these words leave room to *not* do what Magnus is suggesting. > > e.g. If I have a 1 screen home TP system getting three streams from a > > 3 camera system and selecting only one it is not really "necessary" to > > tell the 3 camera system to pause two streams - but it is a really > > good idea to have a way to that! I don't view this is a continuous > > conference control issue (since that gets into floor control which I > > agree is out of scope) but more like onhold/offhold type negotiation. > > I think this is to some extent a plumbing issue (and based on the > > desired response time SIP or media path messages will be required). > > > > So I would still like to see a statement which makes it clear that it > > not just an issue of receiver selection but there is a need to > > communicate that selection back to the sender. The current text does > > not say this. Hence my suggestion: > > > > "Selection choices will be communicated to the sending party to allow > > the sender to optionally present information on which streams are in > > use and to optionally suspend streams which are not in use." ?? > > > > I'm open to other words or some indication of which language in the > > current charter ensures this is in scope. > > > > Regards, > > > > Peter Musgrave > > > > > > > > > > On Wed, Oct 13, 2010 at 12:47 PM, Allyn Romanow (allyn) wrote: > >> Hi Magnus, > >> I was really glad that you had a chance to carefully consider the prop= osed work. > >> Like Peter, I too agree with most of your comments. > >> Specific points below. > >> > >> Best regards, > >> Allyn > >> > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Magnus Westerlund > >> Sent: Tuesday, October 12, 2010 6:47 AM > >> To: dispatch@ietf.org > >> Subject: [dispatch] Comments on the proposed Telepresence Charter > >> > >> Hi, > >> > >> Some colleagues and I have reviewed the two telepresence drafts and > >> version 5 of the charter and have some comments on the charter. > >> > >> To make our comments more understandable I think we should explain our > >> view on telepresence. First we are expecting great variations in the > >> capabilities of the participating terminals in a session. From personal > >> terminals for individual users up to multi-display, cameras and > >> microphone setups. We also expect that more than two end-points being > >> present in the same session. As we see it it will require good support > >> for centralized media handling in a mixer (MCU). We also see video > >> streams not only of high quality to be presented for maximum immersion, > >> but also lower qualities that can be used to monitor activity in other > >> rooms that aren't the ones selected for high quality. > >> > >> [AR] Yes, absolutely. > >> > >> Independent if one uses a central mixer or a full mesh there appears to > >> be a lack in media stream negotiation for how to negotiate what > >> capabilities the receiving client has in receiving, decoding and > >> rendering when it comes to number of simultaneous streams. Our > >> understanding is that RTP mandates any number of streams, while in > >> reality outside of conferencing that is in fact one single stream. > >> However with telepresence and conferencing there is a need to negotiate > >> the actual capability, especially between a mixer and client when it > >> comes to deliver multiple streams for various usages. > >> > >> [AR] Yes, agree - as you saw, this is covered in the charter. > >> > >> We also think there is missing functionality for expressing who are the > >> currently active speakers. The RTP CSRC field are not sufficient as th= ey > >> express which end-points are included in the mix. However, as one like= ly > >> include in a mix more rooms than the active speakers to ensure that any > >> interruption and ambient sound are correctly captured an mechanism for > >> indicating the currently active speakers are needed. There is also need > >> to agree on the type of identifier to be used that allow for mapping to > >> full user names when appropriate. > >> > >> [AR] Yes.. Both of these points are covered in the charter too, right? > >> > >> The charter includes an item to work on control between client and a > >> mixer what streams should be delivered. We would like to extended this > >> to allow also the mixer to control the client on when streams are > >> delivered. In cases where there are more users then available display > >> area and a particular user is not actually included in any outgoing > >> mix/selection from the mixer then there is little point in that the > >> client consumes network resources. Thus we suggest that the stream > >> selection and control work is extended to allow also the mixer to pause > >> individual streams from the client to the mixer. Please note that such > >> control needs to be responsive, thus using the SIP signaling path for > >> this is to slow, it needs to be on the media path. > >> > >> [AR} I agree with your point that it would be good to pause the sender= , but I think that falls > >> =A0under the category of "continuous conference control" which is out = of the scope of this charter. > >> =A0Such a feedback mechanism falls probably under AVT. > >> I think it would be good to add a sentence saying something like, As c= ontrol issues > >> necessary for interoperability arise, they will be directed appropriat= ely. > >> What do you think? > >> > >> > >> Another question to the group is, are there agreement on how streams > >> should organized into RTP sessions and how they are utilized? If > >> anything is documented I would appreciate a pointer. The media streams > >> are for different purposes from different end-points which are then > >> mixed by a central point and delivered to end-points. My impression for > >> example is that most proprietary system breaks the RTP semantics and u= se > >> individual sessions between the mixer and each end-point, instead of a > >> joint session. Here also different robustification tools for RTP such = as > >> FEC and Retransmission needs to be considered. This might be work that > >> belongs in AVT, but are there need for further clarification into this > >> field? > >> > >> [AR} Agree this needs to be worked out for Telepresence, and that any = activity about it would go to AVT and/or MMUSIC. > >> > >> Comments much appreciated and we can gladly suggest text additions to > >> the charter proposal. > >> > >> Cheers > >> > >> Magnus Westerlund > >> > >> ---------------------------------------------------------------------- > >> Multimedia Technologies, Ericsson Research EAB/TVM > >> ---------------------------------------------------------------------- > >> Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287 > >> F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079 > >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > >> ---------------------------------------------------------------------- > >> _______________________________________________ > >> 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 > >> > > _______________________________________________ > > 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 Lorenzo Miniero Meetecho s.r.l. http://www.meetecho.com From hmmr@cisco.com Thu Oct 14 09:07:25 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16D373A693D for ; Thu, 14 Oct 2010 09:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.204 X-Spam-Level: X-Spam-Status: No, score=-9.204 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FB_ROLLER_IS_T=1.357, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bI2Qexc2976H for ; Thu, 14 Oct 2010 09:07:23 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id E5C773A6AFC for ; Thu, 14 Oct 2010 09:07:22 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAILHtkytJV2a/2dsb2JhbAChKXGjUJx6AoVGBIRTiHw X-IronPort-AV: E=Sophos;i="4.57,331,1283731200"; d="scan'208";a="170707995" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-2.cisco.com with ESMTP; 14 Oct 2010 16:08:41 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o9EG8f9D031679; Thu, 14 Oct 2010 16:08:41 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Oct 2010 11:08:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Oct 2010 11:08:40 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Comments on the proposed Telepresence Charter Thread-Index: Actrr7fUOU4Um5l6T2CX88LmZ+CNhwACXi8g References: <4CB466D5.8060601@ericsson.com><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02A47987@xmb-sjc-221.amer.cisco.com> From: "Mike Hammer (hmmr)" To: "Peter Musgrave" X-OriginalArrivalTime: 14 Oct 2010 16:08:41.0491 (UTC) FILETIME=[11AE3630:01CB6BBA] Cc: dispatch@ietf.org Subject: Re: [dispatch] Comments on the proposed Telepresence Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 16:07:25 -0000 Peter, I see who is the source of a given stream as something that is a = declared capability at the beginning of the call. Floor control IMHO is the "green light" to transmit content onto the = wire (floor). In the 2-way case you describe, the floor controller is the receiver, in = this case the end-consumer versus the MCU. I don't see these models as being incompatible and do think discussion = should be allowed in the charter. I also agree that it is goodness *not* to waste network bandwidth if no = one will render it at a receive point. So, hope the charter allows that. Thanks, Mike -----Original Message----- From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com]=20 Sent: Thursday, October 14, 2010 10:55 AM To: Mike Hammer (hmmr) Cc: Allyn Romanow (allyn); dispatch@ietf.org Subject: Re: [dispatch] Comments on the proposed Telepresence Charter Hi Mike, I agree the onhld/offhold analogy is a poor one. It is a suspension of a call - which is not intended. Let me re-phrase and see if we agree: A sends B three video streams and one audio stream . B has one display and opts to display one of the three streams. There is a mechanism for B to tell A that this has happened (and to say when it wishes to display some other stream from A). Do we think that the work to do this type of stream-suspension is floor control? (My opinion is no. I view floor control more as who is the source for a given stream and not a selection of an agreed upon stream). Do we think this work is in scope for Telepresence Interoperability? I think this is an essential element to deployable TP operation especially as in expands to "at home" use. If an architecture in which a room sends all video all the time (even though it's not being used) is viewed as necessary to avoid complexity/meet responsiveness requirements is thought to be ok then I'd like to make sure we are clear that that these limitations exist upfront. My preference is obviously to permit this feedback and tweak the proposed charter. Other opinions? Regards, Peter Musgrave On Thu, Oct 14, 2010 at 9:46 AM, Mike Hammer (hmmr) = wrote: > Peter, > > I have not issue with your proposed words, since they are essentially = asking for a "mute" button for all types of communications used by a = sender. =A0This may complicate the algorithm for all the receive systems = to know what to display, if for example, you continue to speak, but turn = off the video transmission. =A0A "mute all" option might be more polite. > > I did have issue with this comment: =A0"more like onhold/offhold type = negotiation" > > I am not sure I would agree with this. > > There needs to be a distinction between when a call starts and when a = call stops, the call being *all* communications (sessions) between two = points. =A0Granted putting a call on hold seems like floor control, but = the participants of the call on hold are effectively out of the call = (left the room) until brought off-hold. =A0This is SIP level action. > > There needs to be a clear distinction between negotiating = capabilities, aka knowing what capabilities an endpoint has, and using = those capabilities during a call. =A0That learning process is done via = SDP. > > The latter part seems to be floor control, continuous conference = control, or whatever you want to call it. =A0There seems to be splitting = of hairs over whether the floor control is manual or automatic = (determined by the loudest speaker). =A0This may be AVT. > > In summary, you have room access, you define capabilities, you have = "speaker" conflict resolution control. =A0(Note, point-to-point calls = are devolution since resolution of conflict is a non-problem with only = one opposing party.) > > Did I miss some other nuance? > > Mike > > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Peter Musgrave > Sent: Thursday, October 14, 2010 5:25 AM > To: Allyn Romanow (allyn) > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Comments on the proposed Telepresence Charter > > HI Allyn/Magnus, > > W.R.T > > "[AR} I agree with your point that it would be good to pause the > sender, but I think that falls > =A0under the category of "continuous conference control" which is out = of > the scope of this charter. > =A0Such a feedback mechanism falls probably under AVT. > I think it would be good to add a sentence saying something like, As > control issues > necessary for interoperability arise, they will be directed = appropriately. > What do you think?" > > I think these words leave room to *not* do what Magnus is suggesting. > e.g. If I have a 1 screen home TP system getting three streams from a > 3 camera system and selecting only one it is not really "necessary" to > tell the 3 camera system to pause two streams - but it is a really > good idea to have a way to that! I don't view this is a continuous > conference control issue (since that gets into floor control which I > agree is out of scope) but more like onhold/offhold type negotiation. > I think this is to some extent a plumbing issue (and based on the > desired response time SIP or media path messages will be required). > > So I would still like to see a statement which makes it clear that it > not just an issue of receiver selection but there is a need to > communicate that selection back to the sender. The current text does > not say this. Hence my suggestion: > > "Selection choices will be communicated to the sending party to allow > the sender to optionally present information on which streams are in > use and to optionally suspend streams which are not in use." ?? > > I'm open to other words or some indication of which language in the > current charter ensures this is in scope. > > Regards, > > Peter Musgrave > > > > > On Wed, Oct 13, 2010 at 12:47 PM, Allyn Romanow (allyn) = wrote: >> Hi Magnus, >> I was really glad that you had a chance to carefully consider the = proposed work. >> Like Peter, I too agree with most of your comments. >> Specific points below. >> >> Best regards, >> Allyn >> >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Magnus Westerlund >> Sent: Tuesday, October 12, 2010 6:47 AM >> To: dispatch@ietf.org >> Subject: [dispatch] Comments on the proposed Telepresence Charter >> >> Hi, >> >> Some colleagues and I have reviewed the two telepresence drafts and >> version 5 of the charter and have some comments on the charter. >> >> To make our comments more understandable I think we should explain = our >> view on telepresence. First we are expecting great variations in the >> capabilities of the participating terminals in a session. From = personal >> terminals for individual users up to multi-display, cameras and >> microphone setups. We also expect that more than two end-points being >> present in the same session. As we see it it will require good = support >> for centralized media handling in a mixer (MCU). We also see video >> streams not only of high quality to be presented for maximum = immersion, >> but also lower qualities that can be used to monitor activity in = other >> rooms that aren't the ones selected for high quality. >> >> [AR] Yes, absolutely. >> >> Independent if one uses a central mixer or a full mesh there appears = to >> be a lack in media stream negotiation for how to negotiate what >> capabilities the receiving client has in receiving, decoding and >> rendering when it comes to number of simultaneous streams. Our >> understanding is that RTP mandates any number of streams, while in >> reality outside of conferencing that is in fact one single stream. >> However with telepresence and conferencing there is a need to = negotiate >> the actual capability, especially between a mixer and client when it >> comes to deliver multiple streams for various usages. >> >> [AR] Yes, agree - as you saw, this is covered in the charter. >> >> We also think there is missing functionality for expressing who are = the >> currently active speakers. The RTP CSRC field are not sufficient as = they >> express which end-points are included in the mix. However, as one = likely >> include in a mix more rooms than the active speakers to ensure that = any >> interruption and ambient sound are correctly captured an mechanism = for >> indicating the currently active speakers are needed. There is also = need >> to agree on the type of identifier to be used that allow for mapping = to >> full user names when appropriate. >> >> [AR] Yes.. Both of these points are covered in the charter too, = right? >> >> The charter includes an item to work on control between client and a >> mixer what streams should be delivered. We would like to extended = this >> to allow also the mixer to control the client on when streams are >> delivered. In cases where there are more users then available display >> area and a particular user is not actually included in any outgoing >> mix/selection from the mixer then there is little point in that the >> client consumes network resources. Thus we suggest that the stream >> selection and control work is extended to allow also the mixer to = pause >> individual streams from the client to the mixer. Please note that = such >> control needs to be responsive, thus using the SIP signaling path for >> this is to slow, it needs to be on the media path. >> >> [AR} I agree with your point that it would be good to pause the = sender, but I think that falls >> =A0under the category of "continuous conference control" which is out = of the scope of this charter. >> =A0Such a feedback mechanism falls probably under AVT. >> I think it would be good to add a sentence saying something like, As = control issues >> necessary for interoperability arise, they will be directed = appropriately. >> What do you think? >> >> >> Another question to the group is, are there agreement on how streams >> should organized into RTP sessions and how they are utilized? If >> anything is documented I would appreciate a pointer. The media = streams >> are for different purposes from different end-points which are then >> mixed by a central point and delivered to end-points. My impression = for >> example is that most proprietary system breaks the RTP semantics and = use >> individual sessions between the mixer and each end-point, instead of = a >> joint session. Here also different robustification tools for RTP such = as >> FEC and Retransmission needs to be considered. This might be work = that >> belongs in AVT, but are there need for further clarification into = this >> field? >> >> [AR} Agree this needs to be worked out for Telepresence, and that any = activity about it would go to AVT and/or MMUSIC. >> >> Comments much appreciated and we can gladly suggest text additions to >> the charter proposal. >> >> Cheers >> >> Magnus Westerlund >> >> = ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> = ---------------------------------------------------------------------- >> Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287 >> F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 = 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> = ---------------------------------------------------------------------- >> _______________________________________________ >> 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 >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From allyn@cisco.com Thu Oct 14 16:22:38 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F39073A69AE for ; Thu, 14 Oct 2010 16:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.355 X-Spam-Level: X-Spam-Status: No, score=-10.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVUl4tb-UUiw for ; Thu, 14 Oct 2010 16:22:36 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 8CF993A6973 for ; Thu, 14 Oct 2010 16:22:36 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHctt0yrR7H+/2dsb2JhbAChI3GkN5xrAoJxglUEhFOIfA X-IronPort-AV: E=Sophos;i="4.57,333,1283731200"; d="scan'208";a="269815193" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 14 Oct 2010 23:23:56 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o9ENNuMK001615; Thu, 14 Oct 2010 23:23:56 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Oct 2010 16:23:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Oct 2010 16:23:54 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02B01E5F@xmb-sjc-221.amer.cisco.com> In-Reply-To: <4CB577AF.3070903@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Comments on the proposed Telepresence Charter Thread-Index: ActqtpoDUYqil9iASe2P4zIJlrr7AABPexRQ References: <4CB466D5.8060601@ericsson.com> <4CB577AF.3070903@ericsson.com> From: "Allyn Romanow (allyn)" To: "Magnus Westerlund" , "Peter Musgrave" X-OriginalArrivalTime: 14 Oct 2010 23:23:56.0164 (UTC) FILETIME=[DF3D1440:01CB6BF6] Cc: dispatch@ietf.org Subject: Re: [dispatch] Comments on the proposed Telepresence Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 23:22:38 -0000 Hi Magnus, You have made some very helpful points. In particular you've pointed out = that the charter talks about the receiver's ability to respond, but not = the sender's. Also the charter is not explicit about necessary = discussion of Telepresence interoperability issues that are not within = the charter of the multi-stream WG to do anything about. =20 I'd like to propose some wording in the charter that I think will = address your concerns. See what you think- some of the wording is yours = :).. Instead of The WG will create specifications for SIP-based conferencing systems to = enable communication of enough information about each media stream so = that each receiving system or bridge system can make reasonable = decisions about selecting and rendering media streams. This enables = systems to make display choices that optimize the "just like being = there" experience. I propose The WG will create specifications for SIP-based conferencing systems to = enable communication of enough information about each media stream so = that each sending system, receiving system, or bridge system can make = reasonable decisions about transmitting, selecting, and rendering media = streams. This enables systems to make choices that optimize the "just = like being there" experience. I would not like to change: * Which sources a receiver wants to receive. For example, it might = want the source for the left camera, or might want the source chosen by = VAD (Voice Activity Detection). To the proposed: * Which sources a receiver wants transmitted. For example, it might = want the source for the left camera, or might want the source chosen by = VAD (Voice Activity Detection). Because there are multiple receivers. A receiver cannot say what should = be transmitted, it can only say what itself wants to get, or receive. = But I think your concern about sender behavior is covered by the changes = to the paragraph above. I also propose the following addition: This working group is not currently chartered to work on issues of = continuous conference control including: far end camera control, = indication of fast frame update for video codecs or other rapid = switches, floor control, conference roster. The working group may = identify interoperability obstacles in existing openstandards. If so, = the WG will develp requirements to be communicated to other IETF WGs or = Standards Forums as a kind request to try to meet these requirements. What do you think? Best regards, Allyn -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Magnus Westerlund Sent: Wednesday, October 13, 2010 2:11 AM To: Peter Musgrave Cc: dispatch@ietf.org Subject: Re: [dispatch] Comments on the proposed Telepresence Charter Hi Peter, Good that we are in agreement on a number of things. Response and clarifications inline. Peter Musgrave skrev 2010-10-12 17:37: >> >> Independent if one uses a central mixer or a full mesh there appears = to >> be a lack in media stream negotiation for how to negotiate what >> capabilities the receiving client has in receiving, decoding and >> rendering when it comes to number of simultaneous streams. Our >> understanding is that RTP mandates any number of streams, while in >> reality outside of conferencing that is in fact one single stream. >> However with telepresence and conferencing there is a need to = negotiate >> the actual capability, especially between a mixer and client when it >> comes to deliver multiple streams for various usages. > Agreed. The charter does speak to identifying endpoint capabilities > and I view what you describe here as the kind of meta-information > which needs to fit into that framework. Okay, as long as this is included in the thinking about capabilities I am fine. However, the charter proposal isn't particular detailed in this regards. But I guess the following charter text is matching this: "Information between sources and sinks about media stream capabilities will be exchanged." >> >> We also think there is missing functionality for expressing who are = the >> currently active speakers. The RTP CSRC field are not sufficient as = they >> express which end-points are included in the mix. However, as one = likely >> include in a mix more rooms than the active speakers to ensure that = any >> interruption and ambient sound are correctly captured an mechanism = for >> indicating the currently active speakers are needed. There is also = need >> to agree on the type of identifier to be used that allow for mapping = to >> full user names when appropriate. > I agree with this. In my opinion this is a separable problem since it > applies to generic audio conferencing as well. There is tangential > work in the conference event package and probably in the XCON stuff - > but I lack detailed background in XCON. >=20 > In the context of the TP charter I think the work on indicating which > audio stream is associated with which speaker (or part of the room) is > a slightly different issue - since it's about which stream and not > which speaker within a stream. I should probably have been clearer. I am concerned that even on media stream level there is missing functionality to indicate which streams that contains active speakers and has been included in a mix produced by the mixer. From our side we see a difference between being included in the mix and being tagged as currently an active speaker. I think this is currently missing functionality for which requirements needs to be agreed on and then a solution developed. However, the solution might better fit another WG, like AVT. But I think that is for later determination. I think the requirements phase makes sense to have in the Telepresence group. I do agree that such functionality do have a wider usage scope than just telepresence and can be used in any case of centralized mixers where special activity needs to be pointed out, with audio being the foremost example of such media. >=20 >> >> The charter includes an item to work on control between client and a >> mixer what streams should be delivered. We would like to extended = this >> to allow also the mixer to control the client on when streams are >> delivered. In cases where there are more users then available display >> area and a particular user is not actually included in any outgoing >> mix/selection from the mixer then there is little point in that the >> client consumes network resources. Thus we suggest that the stream >> selection and control work is extended to allow also the mixer to = pause >> individual streams from the client to the mixer. Please note that = such >> control needs to be responsive, thus using the SIP signaling path for >> this is to slow, it needs to be on the media path. > I concur. >=20 > The charter sentence: > "The WG will create specifications for SIP-based conferencing systems > to enable communication of enough information about each media stream > so that each receiving system or bridge system can make reasonable > decisions about selecting and rendering media streams. This enables > systems to make display choices that optimize the "just like being > there" experience. " >=20 > is specific to selection of streams and not to the ability to control > them. I don't see anything here which prevents a source from not > sending selected streams - but I have no objection to making this more > explicit. How about adding: >=20 > "Selection choices will be communicated to the sending party to allow > the sender to optionally present information on which streams are in > use and to optionally suspend streams which are not in use." ?? >=20 When I wrote the above comment I was mostly considering the following chart text bullet: * Which sources a receiver wants to receive. For example, it might want the source for the left camera, or might want the source chosen by VAD (Voice Activity Detection). I think your proposed text combined with the above bullet gives all the room I see needed for media stream control. However, maybe a modification of the above to make it clear. * Which sources a receiver or mixer wants to have transmitted. For example, it might want the source for the left camera, or might want the source chosen by VAD (Voice Activity Detection). >=20 >> >> Another question to the group is, are there agreement on how streams >> should organized into RTP sessions and how they are utilized? If >> anything is documented I would appreciate a pointer. The media = streams >> are for different purposes from different end-points which are then >> mixed by a central point and delivered to end-points. My impression = for >> example is that most proprietary system breaks the RTP semantics and = use >> individual sessions between the mixer and each end-point, instead of = a >> joint session. Here also different robustification tools for RTP such = as >> FEC and Retransmission needs to be considered. This might be work = that >> belongs in AVT, but are there need for further clarification into = this >> field? > I think this is something which will have to be thought through and > standardized if TP interoperability is to succeed. I would view the > semantics of how the streams are assigned in scope and the "plumbing" > either comes from the AVT/MMUSIC media cap stuff or any additions are > developed in those WGs. >=20 I agree with that the right place to do specification work is likely these two groups. However, I think telepresence needs to provide requirements for such work. Making such requirement development explicit in the charter would make it clear that we do expect work to happen somewhere else. At the same time it is after all possible to request that another WG's charter is updated to cover such work. The WG may identify interoperability obstacles in existing open standards. The WG may develop requirements to be communicated to other IETF WGs or Standards Forums as a kind request to try to meet these requirements. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From peter.musgrave@magorcorp.com Fri Oct 15 02:48:40 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2274F3A6AC1 for ; Fri, 15 Oct 2010 02:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.862 X-Spam-Level: X-Spam-Status: No, score=-101.862 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cB-wzfVhyq6G for ; Fri, 15 Oct 2010 02:48:38 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 90D9D3A6AA7 for ; Fri, 15 Oct 2010 02:48:38 -0700 (PDT) Received: by qwc9 with SMTP id 9so378665qwc.31 for ; Fri, 15 Oct 2010 02:49:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.80.7 with SMTP id r7mr512546qck.99.1287136198929; Fri, 15 Oct 2010 02:49:58 -0700 (PDT) Received: by 10.229.42.196 with HTTP; Fri, 15 Oct 2010 02:49:58 -0700 (PDT) In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02B01E5F@xmb-sjc-221.amer.cisco.com> References: <4CB466D5.8060601@ericsson.com> <4CB577AF.3070903@ericsson.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02B01E5F@xmb-sjc-221.amer.cisco.com> Date: Fri, 15 Oct 2010 05:49:58 -0400 Message-ID: From: Peter Musgrave To: "Allyn Romanow (allyn)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dispatch@ietf.org Subject: Re: [dispatch] Comments on the proposed Telepresence Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 09:48:40 -0000 Hi Allyn, This text works for me. Thanks, Peter Musgrave On Thu, Oct 14, 2010 at 7:23 PM, Allyn Romanow (allyn) wr= ote: > Hi Magnus, > You have made some very helpful points. In particular you've pointed out = that the charter talks about the receiver's ability to respond, but not the= sender's. Also the charter is not explicit about necessary discussion of T= elepresence interoperability issues that are not within the charter of the = multi-stream WG to do anything about. > > I'd like to propose some wording in the charter that I think will address= your concerns. See what you think- some of the wording is yours :).. > > Instead of > > =A0 =A0 =A0 =A0The WG will create specifications for SIP-based conferenci= ng systems to enable =A0communication of enough information about each medi= a stream so that each receiving system =A0 =A0 =A0 or bridge system can mak= e reasonable decisions about selecting and rendering media =A0 =A0 =A0strea= ms. This enables systems to make display choices that optimize the "just li= ke being =A0 =A0 =A0 =A0there" experience. > I propose > =A0 =A0 =A0 =A0The WG will create specifications for SIP-based conferenci= ng systems to enable =A0communication of enough information about each medi= a stream so that each sending system, =A0 =A0 =A0 =A0receiving system, or b= ridge system can make reasonable decisions about transmitting, =A0 =A0selec= ting, and rendering media streams. This enables systems to make choices tha= t =A0 =A0 =A0 optimize the "just like being there" experience. > > I would not like to change: > =A0 =A0 =A0 =A0* Which sources a receiver wants to receive. =A0For exampl= e, it might want the source for =A0 =A0 =A0 =A0 the left camera, or might w= ant the source chosen by VAD (Voice Activity Detection). > To the proposed: > =A0 =A0 =A0 =A0* Which sources a receiver wants transmitted. =A0For examp= le, it might want the source for =A0 =A0 =A0 =A0the left camera, or might w= ant the source chosen by VAD (Voice Activity Detection). > > Because there are multiple receivers. A receiver cannot say what should b= e transmitted, it can only say what itself wants to get, or receive. But I = think your concern about sender behavior is covered by the changes to the p= aragraph above. > > I also propose the following addition: > =A0 =A0 =A0 =A0This working group is not currently chartered to work on i= ssues of continuous conference =A0 =A0 =A0 =A0control including: far end ca= mera control, indication of fast frame update for video =A0 =A0codecs or ot= her rapid switches, floor control, conference roster. The working group may= =A0 =A0 =A0 =A0 identify interoperability obstacles in existing openstanda= rds. If so, the WG will develp =A0 =A0 =A0 =A0requirements to be communicat= ed to other IETF WGs or Standards Forums as a kind request =A0 =A0 =A0 =A0 = to try to meet these requirements. > > What do you think? > > Best regards, > Allyn > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Beh= alf Of Magnus Westerlund > Sent: Wednesday, October 13, 2010 2:11 AM > To: Peter Musgrave > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Comments on the proposed Telepresence Charter > > Hi Peter, > > Good that we are in agreement on a number of things. Response and > clarifications inline. > > Peter Musgrave skrev 2010-10-12 17:37: >>> >>> Independent if one uses a central mixer or a full mesh there appears to >>> be a lack in media stream negotiation for how to negotiate what >>> capabilities the receiving client has in receiving, decoding and >>> rendering when it comes to number of simultaneous streams. Our >>> understanding is that RTP mandates any number of streams, while in >>> reality outside of conferencing that is in fact one single stream. >>> However with telepresence and conferencing there is a need to negotiate >>> the actual capability, especially between a mixer and client when it >>> comes to deliver multiple streams for various usages. > >> Agreed. The charter does speak to identifying endpoint capabilities >> and I view what you describe here as the kind of meta-information >> which needs to fit into that framework. > > Okay, as long as this is included in the thinking about capabilities I > am fine. However, the charter proposal isn't particular detailed in this > regards. But I guess the following charter text is matching this: > > "Information between sources and sinks about media stream capabilities > will be exchanged." > >>> >>> We also think there is missing functionality for expressing who are the >>> currently active speakers. The RTP CSRC field are not sufficient as the= y >>> express which end-points are included in the mix. However, as one likel= y >>> include in a mix more rooms than the active speakers to ensure that any >>> interruption and ambient sound are correctly captured an mechanism for >>> indicating the currently active speakers are needed. There is also need >>> to agree on the type of identifier to be used that allow for mapping to >>> full user names when appropriate. > >> I agree with this. In my opinion this is a separable problem since it >> applies to generic audio conferencing as well. There is tangential >> work in the conference event package and probably in the XCON stuff - >> but I lack detailed background in XCON. >> >> In the context of the TP charter I think the work on indicating which >> audio stream is associated with which speaker (or part of the room) is >> a slightly different issue - since it's about which stream and not >> which speaker within a stream. > > I should probably have been clearer. I am concerned that even on media > stream level there is missing functionality to indicate which streams > that contains active speakers and has been included in a mix produced by > the mixer. From our side we see a difference between being included in > the mix and being tagged as currently an active speaker. > > I think this is currently missing functionality for which requirements > needs to be agreed on and then a solution developed. However, the > solution might better fit another WG, like AVT. But I think that is for > later determination. I think the requirements phase makes sense to have > in the Telepresence group. > > I do agree that such functionality do have a wider usage scope than just > telepresence and can be used in any case of centralized mixers where > special activity needs to be pointed out, with audio being the foremost > example of such media. > >> >>> >>> The charter includes an item to work on control between client and a >>> mixer what streams should be delivered. We would like to extended this >>> to allow also the mixer to control the client on when streams are >>> delivered. In cases where there are more users then available display >>> area and a particular user is not actually included in any outgoing >>> mix/selection from the mixer then there is little point in that the >>> client consumes network resources. Thus we suggest that the stream >>> selection and control work is extended to allow also the mixer to pause >>> individual streams from the client to the mixer. Please note that such >>> control needs to be responsive, thus using the SIP signaling path for >>> this is to slow, it needs to be on the media path. >> I concur. >> >> The charter sentence: >> =A0"The WG will create specifications for SIP-based conferencing systems >> to enable communication of enough information about each media stream >> so that each receiving system or bridge system can make reasonable >> decisions about selecting and rendering media streams. This enables >> systems to make display choices that optimize the "just like being >> there" experience. " >> >> is specific to selection of streams and not to the ability to control >> them. I don't see anything here which prevents a source from not >> sending selected streams - but I have no objection to making this more >> explicit. How about adding: >> >> "Selection choices will be communicated to the sending party to allow >> the sender to optionally present information on which streams are in >> use and to optionally suspend streams which are not in use." ?? >> > > When I wrote the above comment I was mostly considering the following > chart text bullet: > > * Which sources a receiver wants to receive. =A0For example, it might wan= t > the source for the left camera, or might want the source chosen by VAD > (Voice Activity Detection). > > I think your proposed text combined with the above bullet gives all the > room I see needed for media stream control. However, maybe a > modification of the above to make it clear. > > * Which sources a receiver or mixer wants to have transmitted. =A0For > example, it might want the source for the left camera, or might want the > source chosen by VAD (Voice Activity Detection). > >> >>> >>> Another question to the group is, are there agreement on how streams >>> should organized into RTP sessions and how they are utilized? If >>> anything is documented I would appreciate a pointer. The media streams >>> are for different purposes from different end-points which are then >>> mixed by a central point and delivered to end-points. My impression for >>> example is that most proprietary system breaks the RTP semantics and us= e >>> individual sessions between the mixer and each end-point, instead of a >>> joint session. Here also different robustification tools for RTP such a= s >>> FEC and Retransmission needs to be considered. This might be work that >>> belongs in AVT, but are there need for further clarification into this >>> field? > >> I think this is something which will have to be thought through and >> standardized if TP interoperability is to succeed. I would view the >> semantics of how the streams are assigned in scope and the "plumbing" >> either comes from the AVT/MMUSIC media cap stuff or any additions are >> developed in those WGs. >> > > I agree with that the right place to do specification work is likely > these two groups. However, I think telepresence needs to provide > requirements for such work. Making such requirement development explicit > in the charter would make it clear that we do expect work to happen > somewhere else. At the same time it is after all possible to request > that another WG's charter is updated to cover such work. > > The WG may identify interoperability obstacles in existing open > standards. The WG may develop requirements to be communicated to other > IETF WGs or Standards Forums as a kind request to try to meet these > requirements. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287 > F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From aallen@rim.com Fri Oct 15 03:33:27 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCFE23A689A for ; Fri, 15 Oct 2010 03:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.663 X-Spam-Level: X-Spam-Status: No, score=-5.663 tagged_above=-999 required=5 tests=[AWL=-0.461, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wzb+DETfG2qK for ; Fri, 15 Oct 2010 03:33:26 -0700 (PDT) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id C15CD3A6941 for ; Fri, 15 Oct 2010 03:33:25 -0700 (PDT) X-AuditID: 0a401fcb-b7be0ae0000073e9-f1-4cb82e46f252 Received: from XCH138CNC.rim.net ( [10.65.20.127]) by mhs03ykf.rim.net (RIM Mail) with SMTP id 35.E3.29673.64E28BC4; Fri, 15 Oct 2010 06:34:46 -0400 (EDT) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH138CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Oct 2010 06:34:46 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB6C54.961A9A20" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 15 Oct 2010 05:34:44 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-allen-dispatch-imei-urn-as-instanceid-00 Thread-Index: ActsU0Uwj/0B4vmORnumoq4/0HlTsgAAUaKg From: "Andrew Allen" To: X-OriginalArrivalTime: 15 Oct 2010 10:34:46.0265 (UTC) FILETIME=[962B1690:01CB6C54] X-Brightmail-Tracker: AAAAAgAAAZEWVk5X Subject: [dispatch] draft-allen-dispatch-imei-urn-as-instanceid-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 10:33:28 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB6C54.961A9A20 Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable A new Internet Draft draft-allen-dispatch-imei-urn-as-instanceid-00 has been submitted. It can be found at: http://www.ietf.org/id/draft-allen-dispatch-imei-urn-as-instanceid-00.tx t The referenced URN definition draft can also be found at: http://www.ietf.org/id/draft-montemurro-gsma-imei-urn-05.txt The draft defines how the IMEI (International Mobile Equipment Identifier) encoded as a URN can be used as an Instance ID as defined in Outbound (RFC 5626) and as used by GRUU (RFC 5627). 3GPP have a need to use the IMEI as an Instance ID as explained in the draft. Please provide comments and feedback. Thanks Andrew ---------------------------------------------------------------------=0A= 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. ------_=_NextPart_001_01CB6C54.961A9A20 Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

 

A new Internet Draft draft-allen-dispatch-imei-urn-as-instanceid-00 has been submitted. It can be found at:

 <= /p>

http://www.ietf.org/id/draft-allen-dispatch-imei-urn-as-instanceid-00= .txt

 <= /p>

The referenced URN definition draft can also be found a= t:

 <= /p>

http:/= /www.ietf.org/id/draft-montemurro-gsma-imei-urn-05.txt=

 <= /p>

 <= /p>

The draft defines how the= IMEI (International Mobile Equipment Identifier) encoded as a URN can be used as= an Instance ID as defined in Outbound (RFC 5626) and as used by GRUU (RFC 5627)= . 3GPP have a need to use the IMEI as an Instance ID as explained in the draft= .

 <= /p>

Please provide comments a= nd feedback.

 <= /p>

Thanks

Andrew

---------------------------------------------------------------------
= =0A= 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. ------_=_NextPart_001_01CB6C54.961A9A20-- From pkyzivat@cisco.com Fri Oct 15 09:32:21 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F31F83A6CD4 for ; Fri, 15 Oct 2010 09:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.194 X-Spam-Level: X-Spam-Status: No, score=-110.194 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EpZ+bmWyrB5 for ; Fri, 15 Oct 2010 09:32:16 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 325493A6CB7 for ; Fri, 15 Oct 2010 09:32:14 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.57,336,1283731200"; d="scan'208";a="171137071" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 15 Oct 2010 16:33:14 +0000 Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o9FGXErH014220; Fri, 15 Oct 2010 16:33:14 GMT Message-ID: <4CB8824A.5090200@cisco.com> Date: Fri, 15 Oct 2010 12:33:14 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: dispatch@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] draft-allen-dispatch-imei-urn-as-instanceid-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 16:32:21 -0000 Andrew, I don't understand the point of this draft. The sip.instance feature tag takes a urn as a value. Either the imei urn works with that or it doesn't. If it does, no draft is needed. If it doesn't, then I don't think a draft will help, unless it is an extension to 5626. 5626 is a little hazy on whether all URNs are ok or not. It implies that it only works for ones that can be compared as strings for equality. Operationally I think that must be the requirement. It would be very bad if implementors of gruu and outbound had to understand each type of URN that might be used as the instance id. I gather that the imei urn might not always work with simple string comparison as the identity test. Hence you have included registrar procedures to ignore parameters when comparing the imei urns. ISTM that you should not be imposing *any* new requirements on registrars. I guess there could be a purpose for such a draft if it was to impose requirements on user agents, about how they format their imei URNs so that they will work with generic comparison procedures at the registrar. Thanks, Paul On 10/15/2010 6:34 AM, Andrew Allen wrote: > A new Internet Draft draft-allen-dispatch-imei-urn-as-instanceid-00 has > been submitted. It can be found at: > > http://www.ietf.org/id/draft-allen-dispatch-imei-urn-as-instanceid-00.txt > > The referenced URN definition draft can also be found at: > > http://www.ietf.org/id/draft-montemurro-gsma-imei-urn-05.txt > > The draft defines how the IMEI (International Mobile Equipment > Identifier) encoded as a URN can be used as an Instance ID as defined in > Outbound (RFC 5626) and as used by GRUU (RFC 5627). 3GPP have a need to > use the IMEI as an Instance ID as explained in the draft. > > Please provide comments and feedback. > > Thanks > > Andrew > > --------------------------------------------------------------------- > 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 pkyzivat@cisco.com Fri Oct 15 10:16:11 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA6693A6CD9 for ; Fri, 15 Oct 2010 10:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.493 X-Spam-Level: X-Spam-Status: No, score=-110.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tz9Ii5OfxPWK for ; Fri, 15 Oct 2010 10:16:08 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id D8ADD3A6CAA for ; Fri, 15 Oct 2010 10:16:07 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAC4puExAZnwM/2dsb2JhbAChJHGjVZxlAoJ0glMEikqDBA X-IronPort-AV: E=Sophos;i="4.57,337,1283731200"; d="scan'208";a="170948941" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 15 Oct 2010 17:17:29 +0000 Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9FHHT9r002353 for ; Fri, 15 Oct 2010 17:17:29 GMT Message-ID: <4CB88CA9.7080504@cisco.com> Date: Fri, 15 Oct 2010 13:17:29 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: dispatch@ietf.org References: <4CB466D5.8060601@ericsson.com><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02A47987@xmb-sjc-221.amer.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dispatch] Comments on the proposed Telepresence Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 17:16:11 -0000 Discussions of putting something "on-hold/off-hold" in the context of sip are necessarily imprecise. SIP really has no concept of hold - it is an application level issue. SIP has mechanisms for negotiating how media streams are used, and those are often *used* to accomplish a hold feature. But the recipient of an offer that manipulates a=sendonly/... does not know if this is because of "hold" or something else. And those mechanisms are per-media-stream. Most of the examples people are familiar with are on calls that only have one media stream, so on can be sloppy and think it is about the call as a whole, but that isn't so. As soon as you add a 2nd media stream, you have the potential to negotiation the directionality of the media independently for each m-line. Bottom line - IMO its perfectly fine for telepresence devices to use the same mechanism to negotiate the directionality (or inactivity) of individual media streams. That mechanism *might* be used as part of floor control policy (if done by a focus), or not (if done by a regular endpoint that just doesn't want to receive stuff it is ignoring.) Thanks, Paul On 10/14/2010 9:46 AM, Mike Hammer (hmmr) wrote: > Peter, > > I have not issue with your proposed words, since they are essentially asking for a "mute" button for all types of communications used by a sender. This may complicate the algorithm for all the receive systems to know what to display, if for example, you continue to speak, but turn off the video transmission. A "mute all" option might be more polite. > > I did have issue with this comment: "more like onhold/offhold type negotiation" > > I am not sure I would agree with this. > > There needs to be a distinction between when a call starts and when a call stops, the call being *all* communications (sessions) between two points. Granted putting a call on hold seems like floor control, but the participants of the call on hold are effectively out of the call (left the room) until brought off-hold. This is SIP level action. > > There needs to be a clear distinction between negotiating capabilities, aka knowing what capabilities an endpoint has, and using those capabilities during a call. That learning process is done via SDP. > > The latter part seems to be floor control, continuous conference control, or whatever you want to call it. There seems to be splitting of hairs over whether the floor control is manual or automatic (determined by the loudest speaker). This may be AVT. > > In summary, you have room access, you define capabilities, you have "speaker" conflict resolution control. (Note, point-to-point calls are devolution since resolution of conflict is a non-problem with only one opposing party.) > > Did I miss some other nuance? > > Mike > > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Peter Musgrave > Sent: Thursday, October 14, 2010 5:25 AM > To: Allyn Romanow (allyn) > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Comments on the proposed Telepresence Charter > > HI Allyn/Magnus, > > W.R.T > > "[AR} I agree with your point that it would be good to pause the > sender, but I think that falls > under the category of "continuous conference control" which is out of > the scope of this charter. > Such a feedback mechanism falls probably under AVT. > I think it would be good to add a sentence saying something like, As > control issues > necessary for interoperability arise, they will be directed appropriately. > What do you think?" > > I think these words leave room to *not* do what Magnus is suggesting. > e.g. If I have a 1 screen home TP system getting three streams from a > 3 camera system and selecting only one it is not really "necessary" to > tell the 3 camera system to pause two streams - but it is a really > good idea to have a way to that! I don't view this is a continuous > conference control issue (since that gets into floor control which I > agree is out of scope) but more like onhold/offhold type negotiation. > I think this is to some extent a plumbing issue (and based on the > desired response time SIP or media path messages will be required). > > So I would still like to see a statement which makes it clear that it > not just an issue of receiver selection but there is a need to > communicate that selection back to the sender. The current text does > not say this. Hence my suggestion: > > "Selection choices will be communicated to the sending party to allow > the sender to optionally present information on which streams are in > use and to optionally suspend streams which are not in use." ?? > > I'm open to other words or some indication of which language in the > current charter ensures this is in scope. > > Regards, > > Peter Musgrave > > > > > On Wed, Oct 13, 2010 at 12:47 PM, Allyn Romanow (allyn) wrote: >> Hi Magnus, >> I was really glad that you had a chance to carefully consider the proposed work. >> Like Peter, I too agree with most of your comments. >> Specific points below. >> >> Best regards, >> Allyn >> >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Magnus Westerlund >> Sent: Tuesday, October 12, 2010 6:47 AM >> To: dispatch@ietf.org >> Subject: [dispatch] Comments on the proposed Telepresence Charter >> >> Hi, >> >> Some colleagues and I have reviewed the two telepresence drafts and >> version 5 of the charter and have some comments on the charter. >> >> To make our comments more understandable I think we should explain our >> view on telepresence. First we are expecting great variations in the >> capabilities of the participating terminals in a session. From personal >> terminals for individual users up to multi-display, cameras and >> microphone setups. We also expect that more than two end-points being >> present in the same session. As we see it it will require good support >> for centralized media handling in a mixer (MCU). We also see video >> streams not only of high quality to be presented for maximum immersion, >> but also lower qualities that can be used to monitor activity in other >> rooms that aren't the ones selected for high quality. >> >> [AR] Yes, absolutely. >> >> Independent if one uses a central mixer or a full mesh there appears to >> be a lack in media stream negotiation for how to negotiate what >> capabilities the receiving client has in receiving, decoding and >> rendering when it comes to number of simultaneous streams. Our >> understanding is that RTP mandates any number of streams, while in >> reality outside of conferencing that is in fact one single stream. >> However with telepresence and conferencing there is a need to negotiate >> the actual capability, especially between a mixer and client when it >> comes to deliver multiple streams for various usages. >> >> [AR] Yes, agree - as you saw, this is covered in the charter. >> >> We also think there is missing functionality for expressing who are the >> currently active speakers. The RTP CSRC field are not sufficient as they >> express which end-points are included in the mix. However, as one likely >> include in a mix more rooms than the active speakers to ensure that any >> interruption and ambient sound are correctly captured an mechanism for >> indicating the currently active speakers are needed. There is also need >> to agree on the type of identifier to be used that allow for mapping to >> full user names when appropriate. >> >> [AR] Yes.. Both of these points are covered in the charter too, right? >> >> The charter includes an item to work on control between client and a >> mixer what streams should be delivered. We would like to extended this >> to allow also the mixer to control the client on when streams are >> delivered. In cases where there are more users then available display >> area and a particular user is not actually included in any outgoing >> mix/selection from the mixer then there is little point in that the >> client consumes network resources. Thus we suggest that the stream >> selection and control work is extended to allow also the mixer to pause >> individual streams from the client to the mixer. Please note that such >> control needs to be responsive, thus using the SIP signaling path for >> this is to slow, it needs to be on the media path. >> >> [AR} I agree with your point that it would be good to pause the sender, but I think that falls >> under the category of "continuous conference control" which is out of the scope of this charter. >> Such a feedback mechanism falls probably under AVT. >> I think it would be good to add a sentence saying something like, As control issues >> necessary for interoperability arise, they will be directed appropriately. >> What do you think? >> >> >> Another question to the group is, are there agreement on how streams >> should organized into RTP sessions and how they are utilized? If >> anything is documented I would appreciate a pointer. The media streams >> are for different purposes from different end-points which are then >> mixed by a central point and delivered to end-points. My impression for >> example is that most proprietary system breaks the RTP semantics and use >> individual sessions between the mixer and each end-point, instead of a >> joint session. Here also different robustification tools for RTP such as >> FEC and Retransmission needs to be considered. This might be work that >> belongs in AVT, but are there need for further clarification into this >> field? >> >> [AR} Agree this needs to be worked out for Telepresence, and that any activity about it would go to AVT and/or MMUSIC. >> >> Comments much appreciated and we can gladly suggest text additions to >> the charter proposal. >> >> Cheers >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Färögatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> _______________________________________________ >> 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 >> > _______________________________________________ > 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 hmmr@cisco.com Fri Oct 15 13:21:02 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE9BC3A6805 for ; Fri, 15 Oct 2010 13:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.888 X-Spam-Level: X-Spam-Status: No, score=-9.888 tagged_above=-999 required=5 tests=[AWL=0.711, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VnfRyYDcqZmj for ; Fri, 15 Oct 2010 13:21:01 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 06EF23A63D2 for ; Fri, 15 Oct 2010 13:21:00 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIpUuEytJV2d/2dsb2JhbAChJHGkRJxJAoJ0glMEhFSJAA X-IronPort-AV: E=Sophos;i="4.57,337,1283731200"; d="scan'208";a="171027928" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-1.cisco.com with ESMTP; 15 Oct 2010 20:22:22 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id o9FKMM0c010112 for ; Fri, 15 Oct 2010 20:22:22 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Oct 2010 15:22:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Oct 2010 15:22:21 -0500 Message-ID: In-Reply-To: <4CB88CA9.7080504@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Comments on the proposed Telepresence Charter Thread-Index: ActsjN+rHsTiCbkgR1m99HaK9I+iTAAGRsYw References: <4CB466D5.8060601@ericsson.com><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02A47987@xmb-sjc-221.amer.cisco.com> <4CB88CA9.7080504@cisco.com> From: "Mike Hammer (hmmr)" To: "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 15 Oct 2010 20:22:22.0474 (UTC) FILETIME=[AC81A6A0:01CB6CA6] Subject: Re: [dispatch] Comments on the proposed Telepresence Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 20:21:03 -0000 Paul, I can also drive a screw with a hammer. That doesn't mean it is the = right tool. :) In this case, I am not so certain that the use of a 3-way handshake is = necessary. In any case, I think the charter allows us the flexibility to make an = informed decision. Cheers, Mike -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Paul Kyzivat (pkyzivat) Sent: Friday, October 15, 2010 1:17 PM To: dispatch@ietf.org Subject: Re: [dispatch] Comments on the proposed Telepresence Charter Discussions of putting something "on-hold/off-hold" in the context of=20 sip are necessarily imprecise. SIP really has no concept of hold - it is = an application level issue. SIP has mechanisms for negotiating how media streams are used, and those = are often *used* to accomplish a hold feature. But the recipient of an=20 offer that manipulates a=3Dsendonly/... does not know if this is because = of "hold" or something else. And those mechanisms are per-media-stream.=20 Most of the examples people are familiar with are on calls that only=20 have one media stream, so on can be sloppy and think it is about the=20 call as a whole, but that isn't so. As soon as you add a 2nd media=20 stream, you have the potential to negotiation the directionality of the=20 media independently for each m-line. Bottom line - IMO its perfectly fine for telepresence devices to use the = same mechanism to negotiate the directionality (or inactivity) of=20 individual media streams. That mechanism *might* be used as part of=20 floor control policy (if done by a focus), or not (if done by a regular=20 endpoint that just doesn't want to receive stuff it is ignoring.) Thanks, Paul On 10/14/2010 9:46 AM, Mike Hammer (hmmr) wrote: > Peter, > > I have not issue with your proposed words, since they are essentially = asking for a "mute" button for all types of communications used by a = sender. This may complicate the algorithm for all the receive systems = to know what to display, if for example, you continue to speak, but turn = off the video transmission. A "mute all" option might be more polite. > > I did have issue with this comment: "more like onhold/offhold type = negotiation" > > I am not sure I would agree with this. > > There needs to be a distinction between when a call starts and when a = call stops, the call being *all* communications (sessions) between two = points. Granted putting a call on hold seems like floor control, but = the participants of the call on hold are effectively out of the call = (left the room) until brought off-hold. This is SIP level action. > > There needs to be a clear distinction between negotiating = capabilities, aka knowing what capabilities an endpoint has, and using = those capabilities during a call. That learning process is done via = SDP. > > The latter part seems to be floor control, continuous conference = control, or whatever you want to call it. There seems to be splitting = of hairs over whether the floor control is manual or automatic = (determined by the loudest speaker). This may be AVT. > > In summary, you have room access, you define capabilities, you have = "speaker" conflict resolution control. (Note, point-to-point calls are = devolution since resolution of conflict is a non-problem with only one = opposing party.) > > Did I miss some other nuance? > > Mike > > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Peter Musgrave > Sent: Thursday, October 14, 2010 5:25 AM > To: Allyn Romanow (allyn) > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Comments on the proposed Telepresence Charter > > HI Allyn/Magnus, > > W.R.T > > "[AR} I agree with your point that it would be good to pause the > sender, but I think that falls > under the category of "continuous conference control" which is out = of > the scope of this charter. > Such a feedback mechanism falls probably under AVT. > I think it would be good to add a sentence saying something like, As > control issues > necessary for interoperability arise, they will be directed = appropriately. > What do you think?" > > I think these words leave room to *not* do what Magnus is suggesting. > e.g. If I have a 1 screen home TP system getting three streams from a > 3 camera system and selecting only one it is not really "necessary" to > tell the 3 camera system to pause two streams - but it is a really > good idea to have a way to that! I don't view this is a continuous > conference control issue (since that gets into floor control which I > agree is out of scope) but more like onhold/offhold type negotiation. > I think this is to some extent a plumbing issue (and based on the > desired response time SIP or media path messages will be required). > > So I would still like to see a statement which makes it clear that it > not just an issue of receiver selection but there is a need to > communicate that selection back to the sender. The current text does > not say this. Hence my suggestion: > > "Selection choices will be communicated to the sending party to allow > the sender to optionally present information on which streams are in > use and to optionally suspend streams which are not in use." ?? > > I'm open to other words or some indication of which language in the > current charter ensures this is in scope. > > Regards, > > Peter Musgrave > > > > > On Wed, Oct 13, 2010 at 12:47 PM, Allyn Romanow = (allyn) wrote: >> Hi Magnus, >> I was really glad that you had a chance to carefully consider the = proposed work. >> Like Peter, I too agree with most of your comments. >> Specific points below. >> >> Best regards, >> Allyn >> >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Magnus Westerlund >> Sent: Tuesday, October 12, 2010 6:47 AM >> To: dispatch@ietf.org >> Subject: [dispatch] Comments on the proposed Telepresence Charter >> >> Hi, >> >> Some colleagues and I have reviewed the two telepresence drafts and >> version 5 of the charter and have some comments on the charter. >> >> To make our comments more understandable I think we should explain = our >> view on telepresence. First we are expecting great variations in the >> capabilities of the participating terminals in a session. From = personal >> terminals for individual users up to multi-display, cameras and >> microphone setups. We also expect that more than two end-points being >> present in the same session. As we see it it will require good = support >> for centralized media handling in a mixer (MCU). We also see video >> streams not only of high quality to be presented for maximum = immersion, >> but also lower qualities that can be used to monitor activity in = other >> rooms that aren't the ones selected for high quality. >> >> [AR] Yes, absolutely. >> >> Independent if one uses a central mixer or a full mesh there appears = to >> be a lack in media stream negotiation for how to negotiate what >> capabilities the receiving client has in receiving, decoding and >> rendering when it comes to number of simultaneous streams. Our >> understanding is that RTP mandates any number of streams, while in >> reality outside of conferencing that is in fact one single stream. >> However with telepresence and conferencing there is a need to = negotiate >> the actual capability, especially between a mixer and client when it >> comes to deliver multiple streams for various usages. >> >> [AR] Yes, agree - as you saw, this is covered in the charter. >> >> We also think there is missing functionality for expressing who are = the >> currently active speakers. The RTP CSRC field are not sufficient as = they >> express which end-points are included in the mix. However, as one = likely >> include in a mix more rooms than the active speakers to ensure that = any >> interruption and ambient sound are correctly captured an mechanism = for >> indicating the currently active speakers are needed. There is also = need >> to agree on the type of identifier to be used that allow for mapping = to >> full user names when appropriate. >> >> [AR] Yes.. Both of these points are covered in the charter too, = right? >> >> The charter includes an item to work on control between client and a >> mixer what streams should be delivered. We would like to extended = this >> to allow also the mixer to control the client on when streams are >> delivered. In cases where there are more users then available display >> area and a particular user is not actually included in any outgoing >> mix/selection from the mixer then there is little point in that the >> client consumes network resources. Thus we suggest that the stream >> selection and control work is extended to allow also the mixer to = pause >> individual streams from the client to the mixer. Please note that = such >> control needs to be responsive, thus using the SIP signaling path for >> this is to slow, it needs to be on the media path. >> >> [AR} I agree with your point that it would be good to pause the = sender, but I think that falls >> under the category of "continuous conference control" which is out = of the scope of this charter. >> Such a feedback mechanism falls probably under AVT. >> I think it would be good to add a sentence saying something like, As = control issues >> necessary for interoperability arise, they will be directed = appropriately. >> What do you think? >> >> >> Another question to the group is, are there agreement on how streams >> should organized into RTP sessions and how they are utilized? If >> anything is documented I would appreciate a pointer. The media = streams >> are for different purposes from different end-points which are then >> mixed by a central point and delivered to end-points. My impression = for >> example is that most proprietary system breaks the RTP semantics and = use >> individual sessions between the mixer and each end-point, instead of = a >> joint session. Here also different robustification tools for RTP such = as >> FEC and Retransmission needs to be considered. This might be work = that >> belongs in AVT, but are there need for further clarification into = this >> field? >> >> [AR} Agree this needs to be worked out for Telepresence, and that any = activity about it would go to AVT and/or MMUSIC. >> >> Comments much appreciated and we can gladly suggest text additions to >> the charter proposal. >> >> Cheers >> >> Magnus Westerlund >> >> = ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> = ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> = ---------------------------------------------------------------------- >> _______________________________________________ >> 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 >> > _______________________________________________ > 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 > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From dworley@avaya.com Fri Oct 15 13:47:59 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA4603A6CDE for ; Fri, 15 Oct 2010 13:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.844 X-Spam-Level: X-Spam-Status: No, score=-101.844 tagged_above=-999 required=5 tests=[AWL=-0.445, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, J_CHICKENPOX_44=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qh6zHECkGzNP for ; Fri, 15 Oct 2010 13:47:58 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 233473A6C9C for ; Fri, 15 Oct 2010 13:47:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,338,1283745600"; d="scan'208";a="242942820" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 15 Oct 2010 16:49:19 -0400 X-IronPort-AV: E=Sophos;i="4.57,338,1283745600"; d="scan'208";a="523430840" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 15 Oct 2010 16:49:19 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.129]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Fri, 15 Oct 2010 16:49:19 -0400 From: "Worley, Dale R (Dale)" To: Paul Kyzivat , "dispatch@ietf.org" Date: Fri, 15 Oct 2010 16:45:43 -0400 Thread-Topic: [dispatch] draft-allen-dispatch-imei-urn-as-instanceid-00 Thread-Index: Actshr9ePoQ0XSGJQj+SWOAtd4DcQwAIzAbz Message-ID: References: , <4CB8824A.5090200@cisco.com> In-Reply-To: <4CB8824A.5090200@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] draft-allen-dispatch-imei-urn-as-instanceid-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 20:48:00 -0000 ________________________________________ From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of Pa= ul Kyzivat [pkyzivat@cisco.com] I don't understand the point of this draft. The sip.instance feature tag takes a urn as a value. Either the imei urn works with that or it doesn't. If it does, no draft is needed. If it doesn't, then I don't think a draft will help, unless it is an extension to 5626. _______________________________________________ As I see it, the point of the draft is the definition/registration of the "= gsma:" scheme for URNs. In that regard, it is a proper step to enable use = of "gsma:imea" URNs as instance identifiers. In that regard, though, I don't see the function of section 4. It seems to= describe now IMEAs can be encoded via BCD, which seems to have nothing to = do with the gsma:imea URNs within SIP. Also, in the Abstract, the expansion of the acronym GSMA should have been d= one the first time it is used, rather than the last time. Dale From pkyzivat@cisco.com Fri Oct 15 15:50:23 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0A253A68E0 for ; Fri, 15 Oct 2010 15:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.495 X-Spam-Level: X-Spam-Status: No, score=-110.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iETFpTSa360t for ; Fri, 15 Oct 2010 15:50:20 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 07EF73A6A30 for ; Fri, 15 Oct 2010 15:50:19 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.57,338,1283731200"; d="scan'208";a="171067287" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 15 Oct 2010 22:51:42 +0000 Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9FMpfAb020006; Fri, 15 Oct 2010 22:51:42 GMT Message-ID: <4CB8DAFE.4090605@cisco.com> Date: Fri, 15 Oct 2010 18:51:42 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Mike Hammer (hmmr)" References: <4CB466D5.8060601@ericsson.com><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02A47987@xmb-sjc-221.amer.cisco.com> <4CB88CA9.7080504@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Comments on the proposed Telepresence Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 22:50:24 -0000 On 10/15/2010 4:22 PM, Mike Hammer (hmmr) wrote: > Paul, > > I can also drive a screw with a hammer. That doesn't mean it is the right tool. :) > > In this case, I am not so certain that the use of a 3-way handshake is necessary. > > In any case, I think the charter allows us the flexibility to make an informed decision. I'm not saying its the only way, or the best way for the purpose, but its certainly a candidate. And it can be 2-way rather than 3-way (with UPDATE). Thanks, Paul > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat (pkyzivat) > Sent: Friday, October 15, 2010 1:17 PM > To: dispatch@ietf.org > Subject: Re: [dispatch] Comments on the proposed Telepresence Charter > > Discussions of putting something "on-hold/off-hold" in the context of > sip are necessarily imprecise. SIP really has no concept of hold - it is > an application level issue. > > SIP has mechanisms for negotiating how media streams are used, and those > are often *used* to accomplish a hold feature. But the recipient of an > offer that manipulates a=sendonly/... does not know if this is because > of "hold" or something else. And those mechanisms are per-media-stream. > Most of the examples people are familiar with are on calls that only > have one media stream, so on can be sloppy and think it is about the > call as a whole, but that isn't so. As soon as you add a 2nd media > stream, you have the potential to negotiation the directionality of the > media independently for each m-line. > > Bottom line - IMO its perfectly fine for telepresence devices to use the > same mechanism to negotiate the directionality (or inactivity) of > individual media streams. That mechanism *might* be used as part of > floor control policy (if done by a focus), or not (if done by a regular > endpoint that just doesn't want to receive stuff it is ignoring.) > > Thanks, > Paul > > On 10/14/2010 9:46 AM, Mike Hammer (hmmr) wrote: >> Peter, >> >> I have not issue with your proposed words, since they are essentially asking for a "mute" button for all types of communications used by a sender. This may complicate the algorithm for all the receive systems to know what to display, if for example, you continue to speak, but turn off the video transmission. A "mute all" option might be more polite. >> >> I did have issue with this comment: "more like onhold/offhold type negotiation" >> >> I am not sure I would agree with this. >> >> There needs to be a distinction between when a call starts and when a call stops, the call being *all* communications (sessions) between two points. Granted putting a call on hold seems like floor control, but the participants of the call on hold are effectively out of the call (left the room) until brought off-hold. This is SIP level action. >> >> There needs to be a clear distinction between negotiating capabilities, aka knowing what capabilities an endpoint has, and using those capabilities during a call. That learning process is done via SDP. >> >> The latter part seems to be floor control, continuous conference control, or whatever you want to call it. There seems to be splitting of hairs over whether the floor control is manual or automatic (determined by the loudest speaker). This may be AVT. > >> >> In summary, you have room access, you define capabilities, you have "speaker" conflict resolution control. (Note, point-to-point calls are devolution since resolution of conflict is a non-problem with only one opposing party.) >> >> Did I miss some other nuance? >> >> Mike >> >> >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Peter Musgrave >> Sent: Thursday, October 14, 2010 5:25 AM >> To: Allyn Romanow (allyn) >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] Comments on the proposed Telepresence Charter >> >> HI Allyn/Magnus, >> >> W.R.T >> >> "[AR} I agree with your point that it would be good to pause the >> sender, but I think that falls >> under the category of "continuous conference control" which is out of >> the scope of this charter. >> Such a feedback mechanism falls probably under AVT. >> I think it would be good to add a sentence saying something like, As >> control issues >> necessary for interoperability arise, they will be directed appropriately. >> What do you think?" >> >> I think these words leave room to *not* do what Magnus is suggesting. >> e.g. If I have a 1 screen home TP system getting three streams from a >> 3 camera system and selecting only one it is not really "necessary" to >> tell the 3 camera system to pause two streams - but it is a really >> good idea to have a way to that! I don't view this is a continuous >> conference control issue (since that gets into floor control which I >> agree is out of scope) but more like onhold/offhold type negotiation. >> I think this is to some extent a plumbing issue (and based on the >> desired response time SIP or media path messages will be required). >> >> So I would still like to see a statement which makes it clear that it >> not just an issue of receiver selection but there is a need to >> communicate that selection back to the sender. The current text does >> not say this. Hence my suggestion: >> >> "Selection choices will be communicated to the sending party to allow >> the sender to optionally present information on which streams are in >> use and to optionally suspend streams which are not in use." ?? >> >> I'm open to other words or some indication of which language in the >> current charter ensures this is in scope. >> >> Regards, >> >> Peter Musgrave >> >> >> >> >> On Wed, Oct 13, 2010 at 12:47 PM, Allyn Romanow (allyn) wrote: >>> Hi Magnus, >>> I was really glad that you had a chance to carefully consider the proposed work. >>> Like Peter, I too agree with most of your comments. >>> Specific points below. >>> >>> Best regards, >>> Allyn >>> >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Magnus Westerlund >>> Sent: Tuesday, October 12, 2010 6:47 AM >>> To: dispatch@ietf.org >>> Subject: [dispatch] Comments on the proposed Telepresence Charter >>> >>> Hi, >>> >>> Some colleagues and I have reviewed the two telepresence drafts and >>> version 5 of the charter and have some comments on the charter. >>> >>> To make our comments more understandable I think we should explain our >>> view on telepresence. First we are expecting great variations in the >>> capabilities of the participating terminals in a session. From personal >>> terminals for individual users up to multi-display, cameras and >>> microphone setups. We also expect that more than two end-points being >>> present in the same session. As we see it it will require good support >>> for centralized media handling in a mixer (MCU). We also see video >>> streams not only of high quality to be presented for maximum immersion, >>> but also lower qualities that can be used to monitor activity in other >>> rooms that aren't the ones selected for high quality. >>> >>> [AR] Yes, absolutely. >>> >>> Independent if one uses a central mixer or a full mesh there appears to >>> be a lack in media stream negotiation for how to negotiate what >>> capabilities the receiving client has in receiving, decoding and >>> rendering when it comes to number of simultaneous streams. Our >>> understanding is that RTP mandates any number of streams, while in >>> reality outside of conferencing that is in fact one single stream. >>> However with telepresence and conferencing there is a need to negotiate >>> the actual capability, especially between a mixer and client when it >>> comes to deliver multiple streams for various usages. >>> >>> [AR] Yes, agree - as you saw, this is covered in the charter. >>> >>> We also think there is missing functionality for expressing who are the >>> currently active speakers. The RTP CSRC field are not sufficient as they >>> express which end-points are included in the mix. However, as one likely >>> include in a mix more rooms than the active speakers to ensure that any >>> interruption and ambient sound are correctly captured an mechanism for >>> indicating the currently active speakers are needed. There is also need >>> to agree on the type of identifier to be used that allow for mapping to >>> full user names when appropriate. >>> >>> [AR] Yes.. Both of these points are covered in the charter too, right? >>> >>> The charter includes an item to work on control between client and a >>> mixer what streams should be delivered. We would like to extended this >>> to allow also the mixer to control the client on when streams are >>> delivered. In cases where there are more users then available display >>> area and a particular user is not actually included in any outgoing >>> mix/selection from the mixer then there is little point in that the >>> client consumes network resources. Thus we suggest that the stream >>> selection and control work is extended to allow also the mixer to pause >>> individual streams from the client to the mixer. Please note that such >>> control needs to be responsive, thus using the SIP signaling path for >>> this is to slow, it needs to be on the media path. >>> >>> [AR} I agree with your point that it would be good to pause the sender, but I think that falls >>> under the category of "continuous conference control" which is out of the scope of this charter. >>> Such a feedback mechanism falls probably under AVT. >>> I think it would be good to add a sentence saying something like, As control issues >>> necessary for interoperability arise, they will be directed appropriately. >>> What do you think? >>> >>> >>> Another question to the group is, are there agreement on how streams >>> should organized into RTP sessions and how they are utilized? If >>> anything is documented I would appreciate a pointer. The media streams >>> are for different purposes from different end-points which are then >>> mixed by a central point and delivered to end-points. My impression for >>> example is that most proprietary system breaks the RTP semantics and use >>> individual sessions between the mixer and each end-point, instead of a >>> joint session. Here also different robustification tools for RTP such as >>> FEC and Retransmission needs to be considered. This might be work that >>> belongs in AVT, but are there need for further clarification into this >>> field? >>> >>> [AR} Agree this needs to be worked out for Telepresence, and that any activity about it would go to AVT and/or MMUSIC. >>> >>> Comments much appreciated and we can gladly suggest text additions to >>> the charter proposal. >>> >>> Cheers >>> >>> Magnus Westerlund >>> >>> ---------------------------------------------------------------------- >>> Multimedia Technologies, Ericsson Research EAB/TVM >>> ---------------------------------------------------------------------- >>> Ericsson AB | Phone +46 10 7148287 >>> Färögatan 6 | Mobile +46 73 0949079 >>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >>> ---------------------------------------------------------------------- >>> _______________________________________________ >>> 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 >>> >> _______________________________________________ >> 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 >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From pkyzivat@cisco.com Fri Oct 15 17:05:27 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26C793A6992 for ; Fri, 15 Oct 2010 17:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.896 X-Spam-Level: X-Spam-Status: No, score=-109.896 tagged_above=-999 required=5 tests=[AWL=-0.497, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0O7sPTARQuB for ; Fri, 15 Oct 2010 17:05:26 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 04B303A6973 for ; Fri, 15 Oct 2010 17:05:25 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEeJuExAZnwM/2dsb2JhbAChMXGjV5xDhUkEikqDBA X-IronPort-AV: E=Sophos;i="4.57,338,1283731200"; d="scan'208";a="171081952" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 16 Oct 2010 00:06:48 +0000 Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9G06mfo007565; Sat, 16 Oct 2010 00:06:48 GMT Message-ID: <4CB8EC98.5010803@cisco.com> Date: Fri, 15 Oct 2010 20:06:48 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Worley, Dale R (Dale)" References: , <4CB8824A.5090200@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] draft-allen-dispatch-imei-urn-as-instanceid-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2010 00:05:27 -0000 On 10/15/2010 4:45 PM, Worley, Dale R (Dale) wrote: > ________________________________________ > From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat [pkyzivat@cisco.com] > > I don't understand the point of this draft. > > The sip.instance feature tag takes a urn as a value. Either the imei urn > works with that or it doesn't. If it does, no draft is needed. If it > doesn't, then I don't think a draft will help, unless it is an extension > to 5626. > _______________________________________________ > > As I see it, the point of the draft is the definition/registration of the "gsma:" scheme for URNs. In that regard, it is a proper step to enable use of "gsma:imea" URNs as instance identifiers. This draft doesn't define a new urn scheme. IIUC the one referenced has previously been defined. However, I went and checked 5656 again, and I see that it does have a normative requirement on an RFC for use of something other than a UUID urn. So there is point to this draft. But my other points hold. As I interpret things, registrars should not have to change to accommodate new URNs in this role. IMO 5626 should simply have spelled out the required characteristics for a URN that can be used, rather than requiring an RFC. But that is water over the dam. Thanks, Paul > In that regard, though, I don't see the function of section 4. It seems to describe now IMEAs can be encoded via BCD, which seems to have nothing to do with the gsma:imea URNs within SIP. > > Also, in the Abstract, the expansion of the acronym GSMA should have been done the first time it is used, rather than the last time. > > Dale > From aallen@rim.com Sat Oct 16 12:06:59 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A97063A6B20 for ; Sat, 16 Oct 2010 12:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.298 X-Spam-Level: X-Spam-Status: No, score=-5.298 tagged_above=-999 required=5 tests=[AWL=-0.695, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gkk6KDhrhA7i for ; Sat, 16 Oct 2010 12:06:58 -0700 (PDT) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id 339AF3A69A1 for ; Sat, 16 Oct 2010 12:06:58 -0700 (PDT) X-AuditID: 0a401fcb-b7bdeae0000009e4-96-4cb9f824e056 Received: from XCH139CNC.rim.net ( [10.65.10.235]) by mhs03ykf.rim.net (RIM Mail) with SMTP id 40.85.02532.428F9BC4; Sat, 16 Oct 2010 15:08:20 -0400 (EDT) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH139CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 16 Oct 2010 15:08:20 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sat, 16 Oct 2010 14:08:18 -0500 Message-ID: In-Reply-To: <4CB8824A.5090200@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] draft-allen-dispatch-imei-urn-as-instanceid-00 Thread-Index: Actshr8Kahxx1uHBRK6ZbR7Xok03kgA3r6fx From: "Andrew Allen" To: , X-OriginalArrivalTime: 16 Oct 2010 19:08:20.0460 (UTC) FILETIME=[7F45DAC0:01CB6D65] X-Brightmail-Tracker: AAAAAgAAAZEWVk1C Subject: Re: [dispatch] draft-allen-dispatch-imei-urn-as-instanceid-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2010 19:06:59 -0000 Paul The reason for the draft is that RFC 5626 requires an RFC for use of URNs ot= her than UUID as instance IDs. With regard to your comments about putting requirements on the registrar may= be any requirements for gr parameter generation can be left to 3GPP since th= at is domain specific policy in any case. Andrew ----- Original Message ----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Friday, October 15, 2010 12:33 PM To: dispatch@ietf.org Subject: Re: [dispatch] draft-allen-dispatch-imei-urn-as-instanceid-00 Andrew, I don't understand the point of this draft. The sip.instance feature tag takes a urn as a value. Either the imei urn works with that or it doesn't. If it does, no draft is needed. If it doesn't, then I don't think a draft will help, unless it is an extension to 5626. 5626 is a little hazy on whether all URNs are ok or not. It implies that it only works for ones that can be compared as strings for equality. Operationally I think that must be the requirement. It would be very bad if implementors of gruu and outbound had to understand each type of URN that might be used as the instance id. I gather that the imei urn might not always work with simple string comparison as the identity test. Hence you have included registrar procedures to ignore parameters when comparing the imei urns. ISTM that you should not be imposing *any* new requirements on registrars. I guess there could be a purpose for such a draft if it was to impose requirements on user agents, about how they format their imei URNs so that they will work with generic comparison procedures at the registrar. Thanks, Paul On 10/15/2010 6:34 AM, Andrew Allen wrote: > A new Internet Draft draft-allen-dispatch-imei-urn-as-instanceid-00 has > been submitted. It can be found at: > > http://www.ietf.org/id/draft-allen-dispatch-imei-urn-as-instanceid-00.txt > > The referenced URN definition draft can also be found at: > > http://www.ietf.org/id/draft-montemurro-gsma-imei-urn-05.txt > > The draft defines how the IMEI (International Mobile Equipment > Identifier) encoded as a URN can be used as an Instance ID as defined in > Outbound (RFC 5626) and as used by GRUU (RFC 5627). 3GPP have a need to > use the IMEI as an Instance ID as explained in the draft. > > Please provide comments and feedback. > > Thanks > > Andrew > > --------------------------------------------------------------------- > 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 ---------------------------------------------------------------------=0A= 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 dworley@avaya.com Sun Oct 17 17:26:33 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAAD73A6C44 for ; Sun, 17 Oct 2010 17:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.438 X-Spam-Level: X-Spam-Status: No, score=-102.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NiMJ2xKbTQgQ for ; Sun, 17 Oct 2010 17:26:32 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id BC8C43A6C43 for ; Sun, 17 Oct 2010 17:26:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,343,1283745600"; d="scan'208";a="39424435" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 17 Oct 2010 20:27:59 -0400 X-IronPort-AV: E=Sophos;i="4.57,343,1283745600"; d="scan'208";a="523801768" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 17 Oct 2010 20:27:19 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Sun, 17 Oct 2010 20:27:19 -0400 From: "Worley, Dale R (Dale)" To: Paul Kyzivat Date: Sun, 17 Oct 2010 20:25:44 -0400 Thread-Topic: [dispatch] draft-allen-dispatch-imei-urn-as-instanceid-00 Thread-Index: ActsxgvZLpOUp6NESuKk1GR92UjjEABlPUcp Message-ID: References: , <4CB8824A.5090200@cisco.com> , <4CB8EC98.5010803@cisco.com> In-Reply-To: <4CB8EC98.5010803@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] draft-allen-dispatch-imei-urn-as-instanceid-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 00:26:34 -0000 _______________________________________ From: Paul Kyzivat [pkyzivat@cisco.com] This draft doesn't define a new urn scheme. IIUC the one referenced has previously been defined. _______________________________________ I don't see "gsma" listed in the IANA registry (http://www.iana.org/assignm= ents/uri-schemes.html). Dale From pkyzivat@cisco.com Mon Oct 18 06:05:19 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 443D03A6BC3 for ; Mon, 18 Oct 2010 06:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.193 X-Spam-Level: X-Spam-Status: No, score=-110.193 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPWnayAAp3Cz for ; Mon, 18 Oct 2010 06:05:17 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id E8C8B3A6AC2 for ; Mon, 18 Oct 2010 06:05:16 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAI/ju0xAZnwM/2dsb2JhbAChLHGgcJwhgnWCVASKSoMF X-IronPort-AV: E=Sophos;i="4.57,345,1283731200"; d="scan'208";a="172011218" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 18 Oct 2010 13:06:45 +0000 Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9ID6ioq009069; Mon, 18 Oct 2010 13:06:44 GMT Message-ID: <4CBC4664.9020509@cisco.com> Date: Mon, 18 Oct 2010 09:06:44 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Andrew Allen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-allen-dispatch-imei-urn-as-instanceid-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 13:05:19 -0000 On 10/16/2010 3:08 PM, Andrew Allen wrote: > > Paul > > The reason for the draft is that RFC 5626 requires an RFC for use of URNs other than UUID as instance IDs. Yes, my bad. > With regard to your comments about putting requirements on the registrar maybe any requirements for gr parameter generation can be left to 3GPP since that is domain specific policy in any case. My concern was mostly with imposing particular URN comparison requirements on the registrar. IMO the registrar must not be required to understand this particular URN or apply any new comparison rules when it is used. The registrar should apply the same procedures regardless of URN type. Thanks, Paul > Andrew > > ----- Original Message ----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, October 15, 2010 12:33 PM > To: dispatch@ietf.org > Subject: Re: [dispatch] draft-allen-dispatch-imei-urn-as-instanceid-00 > > Andrew, > > I don't understand the point of this draft. > > The sip.instance feature tag takes a urn as a value. Either the imei urn > works with that or it doesn't. If it does, no draft is needed. If it > doesn't, then I don't think a draft will help, unless it is an extension > to 5626. > > 5626 is a little hazy on whether all URNs are ok or not. It implies that > it only works for ones that can be compared as strings for equality. > Operationally I think that must be the requirement. > > It would be very bad if implementors of gruu and outbound had to > understand each type of URN that might be used as the instance id. > > I gather that the imei urn might not always work with simple string > comparison as the identity test. Hence you have included registrar > procedures to ignore parameters when comparing the imei urns. > > ISTM that you should not be imposing *any* new requirements on > registrars. I guess there could be a purpose for such a draft if it was > to impose requirements on user agents, about how they format their imei > URNs so that they will work with generic comparison procedures at the > registrar. > > Thanks, > Paul > > On 10/15/2010 6:34 AM, Andrew Allen wrote: >> A new Internet Draft draft-allen-dispatch-imei-urn-as-instanceid-00 has >> been submitted. It can be found at: >> >> http://www.ietf.org/id/draft-allen-dispatch-imei-urn-as-instanceid-00.txt >> >> The referenced URN definition draft can also be found at: >> >> http://www.ietf.org/id/draft-montemurro-gsma-imei-urn-05.txt >> >> The draft defines how the IMEI (International Mobile Equipment >> Identifier) encoded as a URN can be used as an Instance ID as defined in >> Outbound (RFC 5626) and as used by GRUU (RFC 5627). 3GPP have a need to >> use the IMEI as an Instance ID as explained in the draft. >> >> Please provide comments and feedback. >> >> Thanks >> >> Andrew >> >> --------------------------------------------------------------------- >> 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 > > --------------------------------------------------------------------- > 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. > From pkyzivat@cisco.com Mon Oct 18 06:06:40 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F77A3A6D5B for ; Mon, 18 Oct 2010 06:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.492 X-Spam-Level: X-Spam-Status: No, score=-110.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KErcxbxGr19d for ; Mon, 18 Oct 2010 06:06:38 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 9C1C33A6BC3 for ; Mon, 18 Oct 2010 06:06:38 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAI/ju0xAZnwM/2dsb2JhbAChLHGgcJwhhUkEikqDBQ X-IronPort-AV: E=Sophos;i="4.57,345,1283731200"; d="scan'208";a="172011832" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 18 Oct 2010 13:08:04 +0000 Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9ID848a009399; Mon, 18 Oct 2010 13:08:04 GMT Message-ID: <4CBC46B4.6000702@cisco.com> Date: Mon, 18 Oct 2010 09:08:04 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Worley, Dale R (Dale)" References: , <4CB8824A.5090200@cisco.com> , <4CB8EC98.5010803@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] draft-allen-dispatch-imei-urn-as-instanceid-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 13:06:40 -0000 On 10/17/2010 8:25 PM, Worley, Dale R (Dale) wrote: > _______________________________________ > From: Paul Kyzivat [pkyzivat@cisco.com] > > This draft doesn't define a new urn scheme. IIUC the one referenced has > previously been defined. > _______________________________________ > > I don't see "gsma" listed in the IANA registry (http://www.iana.org/assignments/uri-schemes.html). Maybe its in progress or something. I didn't see anything in this draft that actually registers a new urn scheme. Thanks, Paul From dworley@avaya.com Mon Oct 18 08:13:18 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57F543A6DFC for ; Mon, 18 Oct 2010 08:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.44 X-Spam-Level: X-Spam-Status: No, score=-102.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VF8NO66-1PU for ; Mon, 18 Oct 2010 08:13:16 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 82F353A6AE1 for ; Mon, 18 Oct 2010 08:13:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,345,1283745600"; d="scan'208";a="243220783" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 18 Oct 2010 11:14:44 -0400 X-IronPort-AV: E=Sophos;i="4.57,345,1283745600"; d="scan'208";a="524027716" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 18 Oct 2010 11:14:44 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Mon, 18 Oct 2010 11:14:44 -0400 From: "Worley, Dale R (Dale)" To: Paul Kyzivat Date: Mon, 18 Oct 2010 11:14:43 -0400 Thread-Topic: [dispatch] draft-allen-dispatch-imei-urn-as-instanceid-00 Thread-Index: ActuxYRHFC/N9HzWQkW9v5R5oKQ5tAAEIXqw Message-ID: References: , <4CB8824A.5090200@cisco.com> , <4CB8EC98.5010803@cisco.com> , <4CBC46B4.6000702@cisco.com> In-Reply-To: <4CBC46B4.6000702@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] draft-allen-dispatch-imei-urn-as-instanceid-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 15:13:18 -0000 ________________________________________ From: Paul Kyzivat [pkyzivat@cisco.com] On 10/17/2010 8:25 PM, Worley, Dale R (Dale) wrote: > I don't see "gsma" listed in the IANA registry (http://www.iana.org/assig= nments/uri-schemes.html). Maybe its in progress or something. I didn't see anything in this draft that actually registers a new urn scheme. ________________________________________ OK, there it is: https://datatracker.ietf.org/doc/draft-montemurro-gsma-im= ei-urn/ That draft has been kicking around for several years. Dale From dworley@avaya.com Mon Oct 18 08:19:17 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 779BC3A6CAF for ; Mon, 18 Oct 2010 08:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z70y7LOozMmT for ; Mon, 18 Oct 2010 08:19:15 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 789C73A6C77 for ; Mon, 18 Oct 2010 08:19:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,345,1283745600"; d="scan'208";a="39516024" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 18 Oct 2010 11:20:36 -0400 X-IronPort-AV: E=Sophos;i="4.57,345,1283745600"; d="scan'208";a="524029962" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 18 Oct 2010 11:20:01 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Mon, 18 Oct 2010 11:20:00 -0400 From: "Worley, Dale R (Dale)" To: Paul Kyzivat , Andrew Allen Date: Mon, 18 Oct 2010 11:16:37 -0400 Thread-Topic: [dispatch] draft-allen-dispatch-imei-urn-as-instanceid-00 Thread-Index: ActuxVWlYNhBHlz/RzySpQFuBLZbvQAEh9vG Message-ID: References: , <4CBC4664.9020509@cisco.com> In-Reply-To: <4CBC4664.9020509@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] draft-allen-dispatch-imei-urn-as-instanceid-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 15:19:18 -0000 ________________________________________ From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of Pa= ul Kyzivat [pkyzivat@cisco.com] My concern was mostly with imposing particular URN comparison requirements on the registrar. IMO the registrar must not be required to understand this particular URN or apply any new comparison rules when it is used. The registrar should apply the same procedures regardless of URN type. _______________________________________________ The sensible rules are spelled out in RFC 5626 section 4.1: Thus, equality comparisons are performed using the rules for URN equality that are specific to the scheme in the URN. If the element performing the comparisons does not understand the URN scheme, it performs the comparisons using the lexical equality rules defined in [RFC2141]. Lexical equality could result in two URNs being considered unequal when they are actually equal. In this specific usage of URNs, the only element that provides the URN is the SIP UA instance identified by that URN. As a result, the UA instance has to provide lexically equivalent URNs in each registration it generates. This is likely to be normal behavior in any case; clients are not likely to modify the value of the instance ID so that it remains functionally equivalent to (yet lexicographically different from) previous registrations. The problem isn't that the URN scheme definition provides an elaborate defi= nition of equality that is suitable to its application, but that UAs must a= lways provide instance ids that are the same character string, even if the = URN scheme allows them flexibility in how to represent the URN. Dale From pkyzivat@cisco.com Mon Oct 18 08:59:12 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D91F3A6A56 for ; Mon, 18 Oct 2010 08:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.492 X-Spam-Level: X-Spam-Status: No, score=-110.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69nXKmd+niLl for ; Mon, 18 Oct 2010 08:59:11 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 6BC3D3A697C for ; Mon, 18 Oct 2010 08:59:11 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABsMvExAZnwN/2dsb2JhbAChLHGibJxAhUkEikqDBQ X-IronPort-AV: E=Sophos;i="4.57,345,1283731200"; d="scan'208";a="171873986" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 18 Oct 2010 16:00:39 +0000 Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o9IG0Z0O023692; Mon, 18 Oct 2010 16:00:35 GMT Message-ID: <4CBC6F23.1010306@cisco.com> Date: Mon, 18 Oct 2010 12:00:35 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Worley, Dale R (Dale)" References: , <4CBC4664.9020509@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] draft-allen-dispatch-imei-urn-as-instanceid-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 15:59:12 -0000 On 10/18/2010 11:16 AM, Worley, Dale R (Dale) wrote: > ________________________________________ > From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat [pkyzivat@cisco.com] > > My concern was mostly with imposing particular URN comparison > requirements on the registrar. IMO the registrar must not be required to > understand this particular URN or apply any new comparison rules when it > is used. The registrar should apply the same procedures regardless of > URN type. > _______________________________________________ > > The sensible rules are spelled out in RFC 5626 section 4.1: > > Thus, equality comparisons are performed using the rules for > URN equality that are specific to the scheme in the URN. If the > element performing the comparisons does not understand the URN > scheme, it performs the comparisons using the lexical equality > rules defined in [RFC2141]. Lexical equality could result in two > URNs being considered unequal when they are actually equal. In > this specific usage of URNs, the only element that provides the > URN is the SIP UA instance identified by that URN. As a result, > the UA instance has to provide lexically equivalent URNs in each > registration it generates. This is likely to be normal behavior > in any case; clients are not likely to modify the value of the > instance ID so that it remains functionally equivalent to (yet > lexicographically different from) previous registrations. > > The problem isn't that the URN scheme definition provides an elaborate definition of equality that is suitable to its application, but that UAs must always provide instance ids that are the same character string, even if the URN scheme allows them flexibility in how to represent the URN. IMO the problem is that this draft expects the registrar to use special comparison rules for this sort of URN. If it removed that requirement, and instead put a requirement on the UA to construct its URN in such a way that the lexical equality rule of 2141 is sufficient, then I think all would be well. Thanks, Paul From dworley@avaya.com Mon Oct 18 14:21:56 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 486FD3A6DAB for ; Mon, 18 Oct 2010 14:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.444 X-Spam-Level: X-Spam-Status: No, score=-102.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkLtQVCrIJQQ for ; Mon, 18 Oct 2010 14:21:55 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 14ACC3A6A82 for ; Mon, 18 Oct 2010 14:21:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,346,1283745600"; d="scan'208";a="39572529" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 18 Oct 2010 17:23:24 -0400 X-IronPort-AV: E=Sophos;i="4.57,346,1283745600"; d="scan'208";a="524154512" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 18 Oct 2010 17:22:49 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Mon, 18 Oct 2010 17:22:48 -0400 From: "Worley, Dale R (Dale)" To: Paul Kyzivat Date: Mon, 18 Oct 2010 17:19:48 -0400 Thread-Topic: [dispatch] draft-allen-dispatch-imei-urn-as-instanceid-00 Thread-Index: Actu3aKJNPdcvGjCRaiwRmJz0dH11QALI81+ Message-ID: References: , <4CBC4664.9020509@cisco.com> , <4CBC6F23.1010306@cisco.com> In-Reply-To: <4CBC6F23.1010306@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] draft-allen-dispatch-imei-urn-as-instanceid-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 21:21:56 -0000 > From: Paul Kyzivat [pkyzivat@cisco.com] >=20 > IMO the problem is that this draft expects the registrar to use special > comparison rules for this sort of URN. >=20 > If it removed that requirement, and instead put a requirement on the UA > to construct its URN in such a way that the lexical equality rule of > 2141 is sufficient, then I think all would be well. Yes, clearly, having the UAs depend on special behavior in the registrar for this URN scheme would mean that only specialized registrars could cope with UAs that used these URNs as their instance id. That would minimize compatibility. The draft needs to be revised to follow RFC 5626 section 4.1 (which is referenced from the GRUU RFC). Dale From john.elwell@siemens-enterprise.com Tue Oct 19 04:02:41 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5940C3A67CF for ; Tue, 19 Oct 2010 04:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.618 X-Spam-Level: X-Spam-Status: No, score=-102.618 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKZeKLlW92OW for ; Tue, 19 Oct 2010 04:02:40 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 3ADF83A67B8 for ; Tue, 19 Oct 2010 04:02:39 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1956128 for dispatch@ietf.org; Tue, 19 Oct 2010 13:04:09 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 7DEF41EB82AB for ; Tue, 19 Oct 2010 13:04:09 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 19 Oct 2010 13:04:09 +0200 From: "Elwell, John" To: DISPATCH list Date: Tue, 19 Oct 2010 13:04:08 +0200 Thread-Topic: Comment on draft-kaplan-dispatch-gruu-problematic-00 Thread-Index: ActvfVpEDoNf7xSVRw2ytDbfFoc91Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dispatch] Comment on draft-kaplan-dispatch-gruu-problematic-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 11:02:41 -0000 An interesting draft. One particular point I noticed, in section 6: "Furthermore, due to the proliferation of B2BUAs in the signaling=20 path, it's not very common that a Contact URI is not routable-to by=20 a UA." The problem is out-of-dialog requests, when the contact URI supplied by a B= 2BUA does not have a lifetime beyond that of the original dialog. So you mi= ght be able to route back to the B2BUA, but whether it will be interpreted = correctly when you get there is another matter. Apart from call transfer, another problem might be the routing of a callbac= k to a device that initiated an emergency call. The "Global Contacts" solut= ion would work only if a global contact has a lifetime beyond a given dialo= g. John= From pkyzivat@cisco.com Tue Oct 19 06:40:59 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D6C53A6814 for ; Tue, 19 Oct 2010 06:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.493 X-Spam-Level: X-Spam-Status: No, score=-110.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0bir4khkfGv for ; Tue, 19 Oct 2010 06:40:58 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id ED61E3A680A for ; Tue, 19 Oct 2010 06:40:57 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmIFAEI9vUxAZnwN/2dsb2JhbACTbo16caEYnFOFSgSKS4ME X-IronPort-AV: E=Sophos;i="4.57,350,1283731200"; d="scan'208";a="172472848" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 19 Oct 2010 13:42:26 +0000 Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o9JDgQP7001565 for ; Tue, 19 Oct 2010 13:42:26 GMT Message-ID: <4CBDA041.5080804@cisco.com> Date: Tue, 19 Oct 2010 09:42:25 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: dispatch@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] Comment on draft-kaplan-dispatch-gruu-problematic-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 13:40:59 -0000 I haven't seen the announcement for this draft yet, so this was my first introduction to it. While there are some real problems identified in here, for the most part this is calling out cases where things have been done wrong or poorly, and blaming gruu. I do think it will be useful to go through this point by point and discuss plausible remedies. IMO it is the responsibility of those deploying B2BUAs to do so in a way that doesn't break things. I realize that in some cases the *purpose* of the B2BUA is to break things, and that can be a valid thing to do, as long as it only breaks the things that should be broken. Also, ISTM that its about time to start doing something about access limited networks. Access limiting sip networks makes as little sense as access limiting email networks. In spite of spam problems, the world would not work if email was restricted the way sip is. Thanks, Paul On 10/19/2010 7:04 AM, Elwell, John wrote: > An interesting draft. > > One particular point I noticed, in section 6: > "Furthermore, due to the proliferation of B2BUAs in the signaling > path, it's not very common that a Contact URI is not routable-to by > a UA." > > The problem is out-of-dialog requests, when the contact URI supplied by a B2BUA does not have a lifetime beyond that of the original dialog. So you might be able to route back to the B2BUA, but whether it will be interpreted correctly when you get there is another matter. > > Apart from call transfer, another problem might be the routing of a callback to a device that initiated an emergency call. The "Global Contacts" solution would work only if a global contact has a lifetime beyond a given dialog. > > John > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From HKaplan@acmepacket.com Tue Oct 19 08:50:34 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48E733A689E for ; Tue, 19 Oct 2010 08:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xhfxmEokPea for ; Tue, 19 Oct 2010 08:50:33 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id F0A9B3A6831 for ; Tue, 19 Oct 2010 08:50:32 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 19 Oct 2010 11:52:03 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 19 Oct 2010 11:51:44 -0400 From: Hadriel Kaplan To: "Elwell, John" Date: Tue, 19 Oct 2010 11:51:42 -0400 Thread-Topic: [dispatch] Comment on draft-kaplan-dispatch-gruu-problematic-00 Thread-Index: ActvpYbjnGtCX/iSTa2IiMygrd7Vkw== Message-ID: <59CD5FE4-2976-4EE0-B309-B1AFB0FD2A88@acmepacket.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DISPATCH list Subject: Re: [dispatch] Comment on draft-kaplan-dispatch-gruu-problematic-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 15:50:34 -0000 Sorry, I didn't announce it because it's not my final version - I just subm= itted what I had as a placeholder due to the deadline. (there's a loophole = in the whole I-D submission thing that you can't submit draft-00 after yest= erday, but you can submit a 00 yesterday as a placeholder and then a 01 nex= t week, effectively letting you submit a brand new I-D a week late. :) With regards to below, yes absolutely - if the Global Contact doesn't survi= ve a dialog's lifetime, then by definition it wont' be usable later. I don= 't know of any B2BUA's that generate Global Contacts that have only a lifet= ime of a dialog *on purpose*, but since the original Contact-URI they gener= ated the Global based on may only have a lifetime of a dialog, the Global C= ontact would inherit that behavior as well in effect. And I do know of som= e devices which generate Contact-URIs which only last a dialog (because the= y encode call-specific info in their contact). So if their request goes th= rough a B2BUA, the Global Contact created by the B2BUA for them only lasts = that long too, from a usefulness perspective. -hadriel On Oct 19, 2010, at 7:04 AM, Elwell, John wrote: > An interesting draft. >=20 > One particular point I noticed, in section 6: > "Furthermore, due to the proliferation of B2BUAs in the signaling=20 > path, it's not very common that a Contact URI is not routable-to by=20 > a UA." >=20 > The problem is out-of-dialog requests, when the contact URI supplied by a= B2BUA does not have a lifetime beyond that of the original dialog. So you = might be able to route back to the B2BUA, but whether it will be interprete= d correctly when you get there is another matter. >=20 > Apart from call transfer, another problem might be the routing of a callb= ack to a device that initiated an emergency call. The "Global Contacts" sol= ution would work only if a global contact has a lifetime beyond a given dia= log. >=20 > John > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From adam@nostrum.com Tue Oct 19 09:32:04 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEEF63A68DE for ; Tue, 19 Oct 2010 09:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BXH1j5H6nMs for ; Tue, 19 Oct 2010 09:31:57 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 648CA3A68BA for ; Tue, 19 Oct 2010 09:31:56 -0700 (PDT) Received: from hydra-3.local (ppp-70-242-117-72.dsl.rcsntx.swbell.net [70.242.117.72]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o9JGXP2p078944 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 19 Oct 2010 11:33:25 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4CBDC855.1040506@nostrum.com> Date: Tue, 19 Oct 2010 11:33:25 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: dispatch@ietf.org, Russ Housley , Henrik Levkowetz References: <59CD5FE4-2976-4EE0-B309-B1AFB0FD2A88@acmepacket.com> In-Reply-To: <59CD5FE4-2976-4EE0-B309-B1AFB0FD2A88@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.117.72 is authenticated by a trusted mechanism) Subject: [dispatch] Placeholder Drafts to Circumvent Deadlines (was Re: Comment on draft-kaplan-dispatch-gruu-problematic-00) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 16:32:05 -0000 On 10/19/10 10:51, Oct 19, Hadriel Kaplan wrote: > Sorry, I didn't announce it because it's not my final version - I just submitted what I had as a placeholder due to the deadline. (there's a loophole in the whole I-D submission thing that you can't submit draft-00 after yesterday, but you can submit a 00 yesterday as a placeholder and then a 01 next week, effectively letting you submit a brand new I-D a week late. :) I don't think that's the intention. In fact, historically (prior to the tools), the i-d repository manager would reject such submissions as being in violation of the deadlines. You can see, for example, discussion of the "no placeholder" rule in this email exchange: https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=21546&tid=1259394188 I can't find any current policy documents that outline this, and I'm not sure whether the tools allow you to bypass the deadlines the way you intend (I guess you'll find out). But I believe that omitting discussion of the "no placeholder" rule in the i-d author guidelines document is an oversight. The idea, of course, is that people need additional time to digest new ideas than they do to process updates to existing documents. Submitting an unfinished placeholder to subvert this intention seems outside the spirit of the deadlines. I'm copying Russ here as current author of the "Guidelines to Authors of Internet Drafts," and Henrik as an Important Person in the tools pantheon to see if they can comment on official policy and tools behavior on this matter. /a From stpeter@stpeter.im Tue Oct 19 09:39:22 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 335723A68B1 for ; Tue, 19 Oct 2010 09:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgTkINvvigbo for ; Tue, 19 Oct 2010 09:39:20 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id B717E3A689C for ; Tue, 19 Oct 2010 09:39:20 -0700 (PDT) Received: from dhcp-64-101-72-188.cisco.com (dhcp-64-101-72-188.cisco.com [64.101.72.188]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 01FD740074; Tue, 19 Oct 2010 10:48:11 -0600 (MDT) Message-ID: <4CBDCA12.1060400@stpeter.im> Date: Tue, 19 Oct 2010 10:40:50 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Adam Roach References: <59CD5FE4-2976-4EE0-B309-B1AFB0FD2A88@acmepacket.com> <4CBDC855.1040506@nostrum.com> In-Reply-To: <4CBDC855.1040506@nostrum.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060809070003020208080100" Cc: dispatch@ietf.org, Russ Housley , Henrik Levkowetz Subject: Re: [dispatch] Placeholder Drafts to Circumvent Deadlines (was Re: Comment on draft-kaplan-dispatch-gruu-problematic-00) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 16:39:22 -0000 This is a cryptographically signed message in MIME format. --------------ms060809070003020208080100 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/19/10 10:33 AM, Adam Roach wrote: > On 10/19/10 10:51, Oct 19, Hadriel Kaplan wrote: >> Sorry, I didn't announce it because it's not my final version - I just= >> submitted what I had as a placeholder due to the deadline. (there's a >> loophole in the whole I-D submission thing that you can't submit >> draft-00 after yesterday, but you can submit a 00 yesterday as a >> placeholder and then a 01 next week, effectively letting you submit a >> brand new I-D a week late. :) >=20 > I don't think that's the intention. In fact, historically (prior to the= > tools), the i-d repository manager would reject such submissions as > being in violation of the deadlines. You can see, for example, > discussion of the "no placeholder" rule in this email exchange: >=20 > https://www.ietf.org/ibin/c5i?mid=3D6&rid=3D49&gid=3D0&k1=3D933&k2=3D21= 546&tid=3D1259394188 >=20 >=20 > I can't find any current policy documents that outline this, and I'm no= t > sure whether the tools allow you to bypass the deadlines the way you > intend (I guess you'll find out). But I believe that omitting discussio= n > of the "no placeholder" rule in the i-d author guidelines document is a= n > oversight. >=20 > The idea, of course, is that people need additional time to digest new > ideas than they do to process updates to existing documents. Submitting= > an unfinished placeholder to subvert this intention seems outside the > spirit of the deadlines. However, the matter is not always clear-cut. Sometimes an author has found the time to roughly sketch out a proposal (resulting in -00) and wants to get that out for discussion, but hasn't yet had time to create examples, track down all the references, etc. It's not always easy to draw a sharp line between "placeholder", "stub", "rough draft", etc. Do we have examples of true placeholders that were then replaced with something totally different? Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms060809070003020208080100 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAx OTE2NDA1MFowIwYJKoZIhvcNAQkEMRYEFHXEN1NESOFoSy1ddL4JDxTgPz5RMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQAjvHtdv3vRi5oaRUDOvtYz/ELwM184xOgcSgjTDMCM1184e99nzholf243 I+NY8lQt5llqNcbTZhv3EpVmdSCXS9OgzvjIzs+ovPtN86/S4u2Why05vCf2gU8YduaJvA4A AdeOAfRB6K/RLoH3LOXYkEgGGjHx0l+ppN1sfbehVuNEnhayovN/hEGitHQ83I5PsSjvVkgZ QjZxweBZStcbTuRvUv8wxv2x2Pkjwmn4rhAjR+pFOVQaVE5kF9xkdkDLonXMDndkpqI5QG1C zd+jGWyDzZl2B77dUSzfR00PBLOuAYtM7Jt4gxap1mr4DaeazTvrDW3Yg0Pwl4ykdoYbAAAA AAAA --------------ms060809070003020208080100-- From adam@nostrum.com Tue Oct 19 09:46:55 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B51E3A68BA for ; Tue, 19 Oct 2010 09:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Pk8uu5AqHUT for ; Tue, 19 Oct 2010 09:46:54 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id E8DD73A68D3 for ; Tue, 19 Oct 2010 09:46:53 -0700 (PDT) Received: from hydra-3.local (ppp-70-242-117-72.dsl.rcsntx.swbell.net [70.242.117.72]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o9JGmNSx080143 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 19 Oct 2010 11:48:23 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4CBDCBD7.20708@nostrum.com> Date: Tue, 19 Oct 2010 11:48:23 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Peter Saint-Andre References: <59CD5FE4-2976-4EE0-B309-B1AFB0FD2A88@acmepacket.com> <4CBDC855.1040506@nostrum.com> <4CBDCA12.1060400@stpeter.im> In-Reply-To: <4CBDCA12.1060400@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (nostrum.com: 70.242.117.72 is authenticated by a trusted mechanism) Cc: dispatch@ietf.org, Russ Housley , Henrik Levkowetz Subject: Re: [dispatch] Placeholder Drafts to Circumvent Deadlines (was Re: Comment on draft-kaplan-dispatch-gruu-problematic-00) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 16:46:55 -0000 On 10/19/10 11:40, Oct 19, Peter Saint-Andre wrote: > On 10/19/10 10:51, Oct 19, Hadriel Kaplan wrote: >> >> Sorry, I didn't announce it because it's not my final version - I just >> >> submitted what I had as a placeholder due to the deadline. ... > However, the matter is not always clear-cut. Sometimes an author has > found the time to roughly sketch out a proposal (resulting in -00) and > wants to get that out for discussion, but hasn't yet had time to > create examples, track down all the references, etc. It's not always > easy to draw a sharp line between "placeholder", "stub", "rough > draft", etc. Perhaps I'm being naïve, but I would suspect an author calling their own draft a "placeholder" actually puts a pretty bright line around it. More to the point: if you have something together by the -00 deadline that is sufficient to foster discussion, there's no real rush to get the i's dotted and the t's crossed by the -01 deadline. Just hold off on the examples, references, and other polish until after the meeting. On the other hand, if it's not in good enough shape that people can use it as the basis of a technical conversation, it is exactly equivalent to an empty placeholder. /a From HKaplan@acmepacket.com Tue Oct 19 09:51:16 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2A243A68DA for ; Tue, 19 Oct 2010 09:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaM7TAhYbkF4 for ; Tue, 19 Oct 2010 09:51:13 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 1696D3A68E9 for ; Tue, 19 Oct 2010 09:51:12 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 19 Oct 2010 12:52:43 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 19 Oct 2010 12:52:38 -0400 From: Hadriel Kaplan To: Paul Kyzivat Date: Tue, 19 Oct 2010 12:52:37 -0400 Thread-Topic: [dispatch] Comment on draft-kaplan-dispatch-gruu-problematic-00 Thread-Index: Actvrgk4+W36I+U0ROSArZxRoyhQUg== Message-ID: <044360F3-B0E3-46AC-8C94-532428AFDD41@acmepacket.com> References: <4CBDA041.5080804@cisco.com> In-Reply-To: <4CBDA041.5080804@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comment on draft-kaplan-dispatch-gruu-problematic-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 16:51:16 -0000 Hi Paul, comments inline... On Oct 19, 2010, at 9:42 AM, Paul Kyzivat wrote: > I haven't seen the announcement for this draft yet, so this was my first= =20 > introduction to it. >=20 > While there are some real problems identified in here, for the most part= =20 > this is calling out cases where things have been done wrong or poorly,=20 > and blaming gruu. I don't think I'm "blaming gruu" (well... except for the argument that the = RFC should have made the UA insert a Record-Route of its real contact). In= general the draft isn't trying to blame gruu - it's trying to explain why = gruu isn't a magic cure-all. > I do think it will be useful to go through this point by point and=20 > discuss plausible remedies. How would you like to do that? Email in dispatch, or separate mailing list= , or future IETF Dispatch meeting, or BOF? > IMO it is the responsibility of those deploying B2BUAs to do so in a way= =20 > that doesn't break things. I realize that in some cases the *purpose* of= =20 > the B2BUA is to break things, and that can be a valid thing to do, as=20 > long as it only breaks the things that should be broken. I think the hard part here is figuring out which behavior doesn't break thi= ngs. I've convinced myself that "passing on" the GRUU will break things mo= re than replacing it, but I'm not sure whether replacing it with a self-mad= e GRUU is actually good or bad. I'm not sure that a B2BUA or any system ev= er really knows whether its Contact URI is globally routable to, or whether= it actually matters or not. > Also, ISTM that its about time to start doing something about access=20 > limited networks. Access limiting sip networks makes as little sense as=20 > access limiting email networks. In spite of spam problems, the world=20 > would not work if email was restricted the way sip is. Good luck with that. :) Email's spam level would destroy voip's viability, never-mind the regulator= y, billing, and interop issues. There are free SIP domains without access = restrictions, but they're the minority afaict. Over time this may well change, but I doubt it'll be soon. -hadriel From stpeter@stpeter.im Tue Oct 19 09:52:01 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE7443A6907 for ; Tue, 19 Oct 2010 09:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGQc7Flo55mG for ; Tue, 19 Oct 2010 09:52:00 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id C171B3A68EE for ; Tue, 19 Oct 2010 09:52:00 -0700 (PDT) Received: from dhcp-64-101-72-188.cisco.com (dhcp-64-101-72-188.cisco.com [64.101.72.188]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1BC2E400EE; Tue, 19 Oct 2010 11:00:52 -0600 (MDT) Message-ID: <4CBDCD0A.6050003@stpeter.im> Date: Tue, 19 Oct 2010 10:53:30 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Adam Roach References: <59CD5FE4-2976-4EE0-B309-B1AFB0FD2A88@acmepacket.com> <4CBDC855.1040506@nostrum.com> <4CBDCA12.1060400@stpeter.im> <4CBDCBD7.20708@nostrum.com> In-Reply-To: <4CBDCBD7.20708@nostrum.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010008000805000009030905" Cc: dispatch@ietf.org, Russ Housley , Henrik Levkowetz Subject: Re: [dispatch] Placeholder Drafts to Circumvent Deadlines (was Re: Comment on draft-kaplan-dispatch-gruu-problematic-00) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 16:52:02 -0000 This is a cryptographically signed message in MIME format. --------------ms010008000805000009030905 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/19/10 10:48 AM, Adam Roach wrote: > On 10/19/10 11:40, Oct 19, Peter Saint-Andre wrote: >> On 10/19/10 10:51, Oct 19, Hadriel Kaplan wrote: >>> >> Sorry, I didn't announce it because it's not my final version - I= >>> just >>> >> submitted what I had as a placeholder due to the deadline. > ... >> However, the matter is not always clear-cut. Sometimes an author has >> found the time to roughly sketch out a proposal (resulting in -00) and= >> wants to get that out for discussion, but hasn't yet had time to >> create examples, track down all the references, etc. It's not always >> easy to draw a sharp line between "placeholder", "stub", "rough >> draft", etc. >=20 > Perhaps I'm being na=C3=AFve, but I would suspect an author calling the= ir own > draft a "placeholder" actually puts a pretty bright line around it. Given that we don't have a clear definition of "placeholder", I'm not so sure. Is it a sketch, a stub, something that you submitted only to get draft-smith-foobar-00 and then you're going to completely change the meaning of "foobar" next week? > More to the point: if you have something together by the -00 deadline > that is sufficient to foster discussion, there's no real rush to get th= e > i's dotted and the t's crossed by the -01 deadline. Just hold off on th= e > examples, references, and other polish until after the meeting.=20 Some people are perfectionists and it pains them to submit anything that's merely a rough draft. > On the > other hand, if it's not in good enough shape that people can use it as > the basis of a technical conversation, it is exactly equivalent to an > empty placeholder. Ah, you didn't say "empty placeholder" before. That makes all the difference. :) Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms010008000805000009030905 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAx OTE2NTMzMFowIwYJKoZIhvcNAQkEMRYEFKMsQQckTomGAh7n1nZM6A2KFw4FMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBfww9y6fmxuegL5kR3t4SvFK9DVRUyjwWXMmwisfyAF0Nh9Uk0i+3Li5dG Hqs3Fehu9RW21rV9bAkawKrJz66eoRlwdIEh54tpUYCVrQvS6/bKbQOhHFwaZZZjZRM+czEi My1g3v6RIhcP4JPC2mOF6ISzSeDZqIO0ejVhp82PVbBdK8LRkyCcnTdzmo/5Ty10DU+X4FdC TEFoOCz3c9pvNpFHwQkPskHQsFLeg+pEvczPgFFjIWhO+xLmNACAuvuEdWnRg2SfriM1NPqi +Tpvhn4bK0QxXatyytE9UoZFjWP1XE4iYhVJkcvYA/h03JSFtbmXaUbwSzj4yeg5v3T3AAAA AAAA --------------ms010008000805000009030905-- From HKaplan@acmepacket.com Tue Oct 19 10:03:33 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34F8F3A68E2 for ; Tue, 19 Oct 2010 10:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkBtuQilrCvb for ; Tue, 19 Oct 2010 10:03:32 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id EC5993A68E1 for ; Tue, 19 Oct 2010 10:03:31 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 19 Oct 2010 13:05:02 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 19 Oct 2010 13:04:52 -0400 From: Hadriel Kaplan To: Adam Roach Date: Tue, 19 Oct 2010 13:04:40 -0400 Thread-Topic: [dispatch] Placeholder Drafts to Circumvent Deadlines (was Re: Comment on draft-kaplan-dispatch-gruu-problematic-00) Thread-Index: Actvr75ENdYx2/nJTDGgoBpjPi+5qg== Message-ID: <00BD638C-1F3D-49EF-B6A5-45C69063C953@acmepacket.com> References: <59CD5FE4-2976-4EE0-B309-B1AFB0FD2A88@acmepacket.com> <4CBDC855.1040506@nostrum.com> In-Reply-To: <4CBDC855.1040506@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" , Russ Housley , Henrik Levkowetz Subject: Re: [dispatch] Placeholder Drafts to Circumvent Deadlines (was Re: Comment on draft-kaplan-dispatch-gruu-problematic-00) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 17:03:33 -0000 Oh the tool will let you do it unless it's been changed recently - I've don= e it several times before. Although in my defense the draft's weren't real= ly "placeholders" in the sense of being empty boilerplates, but more like I= hadn't completely finished them. But I don't think the tool should be changed to prevent it - the real purpo= se as you say is to provide people with time to read, and if people feel a = late draft is too late, then they won't read it and it wont' get time at th= e meeting anyway. And in some of the RAI working groups in particular you = couldn't expect meeting time for a draft submitted *before* the deadline, l= et alone after, because our agenda is fixed long before the submission dead= line. (September 6th in Dispatch's case) =20 I didn't submit this I-D for meeting time. -hadriel On Oct 19, 2010, at 12:33 PM, Adam Roach wrote: > On 10/19/10 10:51, Oct 19, Hadriel Kaplan wrote: >> Sorry, I didn't announce it because it's not my final version - I just s= ubmitted what I had as a placeholder due to the deadline. (there's a loopho= le in the whole I-D submission thing that you can't submit draft-00 after y= esterday, but you can submit a 00 yesterday as a placeholder and then a 01 = next week, effectively letting you submit a brand new I-D a week late. :) >=20 > I don't think that's the intention. In fact, historically (prior to the=20 > tools), the i-d repository manager would reject such submissions as=20 > being in violation of the deadlines. You can see, for example,=20 > discussion of the "no placeholder" rule in this email exchange: >=20 > https://www.ietf.org/ibin/c5i?mid=3D6&rid=3D49&gid=3D0&k1=3D933&k2=3D2154= 6&tid=3D1259394188 >=20 > I can't find any current policy documents that outline this, and I'm not= =20 > sure whether the tools allow you to bypass the deadlines the way you=20 > intend (I guess you'll find out). But I believe that omitting discussion= =20 > of the "no placeholder" rule in the i-d author guidelines document is an= =20 > oversight. >=20 > The idea, of course, is that people need additional time to digest new=20 > ideas than they do to process updates to existing documents. Submitting=20 > an unfinished placeholder to subvert this intention seems outside the=20 > spirit of the deadlines. >=20 > I'm copying Russ here as current author of the "Guidelines to Authors of= =20 > Internet Drafts," and Henrik as an Important Person in the tools=20 > pantheon to see if they can comment on official policy and tools=20 > behavior on this matter. >=20 > /a > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From HKaplan@acmepacket.com Tue Oct 19 10:10:32 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E2313A68C2 for ; Tue, 19 Oct 2010 10:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXjJKGsRbnPW for ; Tue, 19 Oct 2010 10:10:18 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id CF83A3A6902 for ; Tue, 19 Oct 2010 10:10:17 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 19 Oct 2010 13:11:48 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 19 Oct 2010 13:11:33 -0400 From: Hadriel Kaplan To: Adam Roach Date: Tue, 19 Oct 2010 13:11:31 -0400 Thread-Topic: [dispatch] Placeholder Drafts to Circumvent Deadlines (was Re: Comment on draft-kaplan-dispatch-gruu-problematic-00) Thread-Index: ActvsK0rV8uogVtBSyG/n6j+YPPUsQ== Message-ID: <0DBECAA7-730D-4830-9EC5-FFA4984C2594@acmepacket.com> References: <59CD5FE4-2976-4EE0-B309-B1AFB0FD2A88@acmepacket.com> <4CBDC855.1040506@nostrum.com> <4CBDCA12.1060400@stpeter.im> <4CBDCBD7.20708@nostrum.com> In-Reply-To: <4CBDCBD7.20708@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" , Russ Housley , Henrik Levkowetz Subject: Re: [dispatch] Placeholder Drafts to Circumvent Deadlines (was Re: Comment on draft-kaplan-dispatch-gruu-problematic-00) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 17:10:34 -0000 X-List-Received-Date: Tue, 19 Oct 2010 17:10:34 -0000 Ahh - sorry for the confusion - it's not a "placeholder" in the sense of em= pty boilerplate - more like I wanted to tidy it up a bit before announcing = it because I'm a nit-picker. I'm not asking for any meeting time for this topic - I just wanted to get i= t in before IETF-79 because I had promised I would submit such a draft at t= he face-to-face meeting of Martini in Maastricht. -hadriel On Oct 19, 2010, at 12:48 PM, Adam Roach wrote: > Perhaps I'm being na=EFve, but I would suspect an author calling their ow= n=20 > draft a "placeholder" actually puts a pretty bright line around it. >=20 > More to the point: if you have something together by the -00 deadline=20 > that is sufficient to foster discussion, there's no real rush to get the= =20 > i's dotted and the t's crossed by the -01 deadline. Just hold off on the= =20 > examples, references, and other polish until after the meeting. On the=20 > other hand, if it's not in good enough shape that people can use it as=20 > the basis of a technical conversation, it is exactly equivalent to an=20 > empty placeholder. >=20 From stpeter@stpeter.im Tue Oct 19 10:16:54 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 571043A68C2 for ; Tue, 19 Oct 2010 10:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRxe33Vh1mXd for ; Tue, 19 Oct 2010 10:16:53 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 0406B3A68C0 for ; Tue, 19 Oct 2010 10:16:53 -0700 (PDT) Received: from dhcp-64-101-72-188.cisco.com (dhcp-64-101-72-188.cisco.com [64.101.72.188]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 29DE240074; Tue, 19 Oct 2010 11:25:44 -0600 (MDT) Message-ID: <4CBDD2DE.8090000@stpeter.im> Date: Tue, 19 Oct 2010 11:18:22 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Hadriel Kaplan References: <59CD5FE4-2976-4EE0-B309-B1AFB0FD2A88@acmepacket.com> <4CBDC855.1040506@nostrum.com> <4CBDCA12.1060400@stpeter.im> <4CBDCBD7.20708@nostrum.com> <0DBECAA7-730D-4830-9EC5-FFA4984C2594@acmepacket.com> In-Reply-To: <0DBECAA7-730D-4830-9EC5-FFA4984C2594@acmepacket.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040207090809020007020500" Cc: Russ Housley , "dispatch@ietf.org" , Henrik Levkowetz Subject: Re: [dispatch] Placeholder Drafts to Circumvent Deadlines (was Re: Comment on draft-kaplan-dispatch-gruu-problematic-00) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 17:16:54 -0000 This is a cryptographically signed message in MIME format. --------------ms040207090809020007020500 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/19/10 11:11 AM, Hadriel Kaplan wrote: > Ahh - sorry for the confusion - it's not a "placeholder" in the sense > of empty boilerplate - more like I wanted to tidy it up a bit before > announcing it because I'm a nit-picker. Tempest, meet teapot. :) --------------ms040207090809020007020500 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAx OTE3MTgyMlowIwYJKoZIhvcNAQkEMRYEFAe6ucvYhtnnRraQ9ouVCSxjvm9xMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQAjTvKfQ5wb2tWoHYYVlDIL+3Pekj3gXKrJdh61e2wlcbCz1m42ScH8uCW9 ga3YTBvbvQYDnhYRf17tn5wkJVGD1mVAWjc4OzEpGJ+l/s9QR4G258r1tpv+V2DvPUoMW16H KTdMERnEC9vteZjTZqaTCX+J/17QxCC15QaunObpCbv5aMdfY3AAwcgL6CJFjPjQy/PmnZ+G KUHjQzLtIw96t4Y+uEXvxGyBi+MGcMhkVb3YNFB8q6ifaeiTsSRstiDhEDEzmFFcMqWHWrfG Ppz7U12Ik7kHbhzrAVx/hdqlUYRMsVGWUhTzfAXmUATih6FR4YlvvHu/eL+yHO2ye/SaAAAA AAAA --------------ms040207090809020007020500-- From dworley@avaya.com Tue Oct 19 10:25:16 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4F3B3A68C0 for ; Tue, 19 Oct 2010 10:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.445 X-Spam-Level: X-Spam-Status: No, score=-102.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPGlGooJrnjW for ; Tue, 19 Oct 2010 10:25:16 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id CAAA33A68AC for ; Tue, 19 Oct 2010 10:25:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,351,1283745600"; d="scan'208";a="39714642" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 19 Oct 2010 13:26:43 -0400 X-IronPort-AV: E=Sophos;i="4.57,351,1283745600"; d="scan'208";a="524468248" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 19 Oct 2010 13:26:03 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Tue, 19 Oct 2010 13:26:03 -0400 From: "Worley, Dale R (Dale)" To: Hadriel Kaplan Date: Tue, 19 Oct 2010 13:21:50 -0400 Thread-Topic: [dispatch] Comment on draft-kaplan-dispatch-gruu-problematic-00 Thread-Index: Actvrgk4+W36I+U0ROSArZxRoyhQUgABBR4f Message-ID: References: <4CBDA041.5080804@cisco.com>, <044360F3-B0E3-46AC-8C94-532428AFDD41@acmepacket.com> In-Reply-To: <044360F3-B0E3-46AC-8C94-532428AFDD41@acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comment on draft-kaplan-dispatch-gruu-problematic-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 17:25:16 -0000 My first impression is "Don't *do* that!". At the very least, the element that mints GRUUs, or rather the administrati= ve structure that is responsible for it, is responsible for ensuring that t= he GRUUs are *globally routable*. If the SIP domain is part of an access-l= imited network, then they need to construct proper globally-advertised and = globally-accessible incoming gateways. If they're minting URIs that claim to be GRUUs but are not, the problem isn= 't with GRUUs per se but rather that they're not minting GRUUs. More subtl= y, the problem may be that there are situations where it is *not possible* = to provide a globally-routable URI for a UA that has a indefinite lifetime.= We may need to provide alternative solutions for that problem. Dale From adam@nostrum.com Tue Oct 19 10:29:32 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3929C3A68C2 for ; Tue, 19 Oct 2010 10:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.235 X-Spam-Level: X-Spam-Status: No, score=-102.235 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ugM2P-v2l9M for ; Tue, 19 Oct 2010 10:29:30 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 260F53A68AC for ; Tue, 19 Oct 2010 10:29:29 -0700 (PDT) Received: from hydra-3.local (ppp-70-242-117-72.dsl.rcsntx.swbell.net [70.242.117.72]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o9JHUuhG083769 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 19 Oct 2010 12:30:56 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4CBDD5D0.4030203@nostrum.com> Date: Tue, 19 Oct 2010 12:30:56 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Worley, Dale R (Dale)" References: <4CBDA041.5080804@cisco.com>, <044360F3-B0E3-46AC-8C94-532428AFDD41@acmepacket.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010806030807050905080701" Received-SPF: pass (nostrum.com: 70.242.117.72 is authenticated by a trusted mechanism) Cc: "dispatch@ietf.org" , Hadriel Kaplan Subject: Re: [dispatch] Comment on draft-kaplan-dispatch-gruu-problematic-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 17:29:32 -0000 This is a multi-part message in MIME format. --------------010806030807050905080701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/19/10 12:21, Oct 19, Worley, Dale R (Dale) wrote: > More subtly, the problem may be that there are situations where it is*not possible* to provide a globally-routable URI for a UA that has a indefinite lifetime. Huh? Do you mean GRUU or temp GRUU? /a --------------010806030807050905080701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 10/19/10 12:21, Oct 19, Worley, Dale R (Dale) wrote: 
More subtly, the problem may be that there are situations where it is *not possible* to provide a globally-routable URI for a UA that has a indefinite lifetime.

Huh?

Do you mean GRUU or temp GRUU?

/a
--------------010806030807050905080701-- From dworley@avaya.com Tue Oct 19 10:34:14 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ED683A690A for ; Tue, 19 Oct 2010 10:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.447 X-Spam-Level: X-Spam-Status: No, score=-102.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRC3bkXASlde for ; Tue, 19 Oct 2010 10:34:13 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 9A4A43A681B for ; Tue, 19 Oct 2010 10:34:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,351,1283745600"; d="scan'208";a="39716034" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 19 Oct 2010 13:35:23 -0400 X-IronPort-AV: E=Sophos;i="4.57,351,1283745600"; d="scan'208";a="527946795" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 19 Oct 2010 13:35:23 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Tue, 19 Oct 2010 13:35:22 -0400 From: "Worley, Dale R (Dale)" To: Adam Roach Date: Tue, 19 Oct 2010 13:33:07 -0400 Thread-Topic: [dispatch] Comment on draft-kaplan-dispatch-gruu-problematic-00 Thread-Index: Actvs2tKq9haVdbKRCa3WdGiqYep4wAAEZJL Message-ID: References: <4CBDA041.5080804@cisco.com>, <044360F3-B0E3-46AC-8C94-532428AFDD41@acmepacket.com> , <4CBDD5D0.4030203@nostrum.com> In-Reply-To: <4CBDD5D0.4030203@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" , Hadriel Kaplan Subject: Re: [dispatch] Comment on draft-kaplan-dispatch-gruu-problematic-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 17:34:14 -0000 ________________________________________ From: Adam Roach [adam@nostrum.com] > More subtly, the problem may be that there are situations where it is *no= t possible* > to provide a globally-routable URI for a UA that has a indefinite lifetim= e. Huh? Do you mean GRUU or temp GRUU? ________________________________________ If the only way for global access to a UA is through some sort of border SB= C, and if the border SBC won't keep any information around much longer than= the length of a call, then it is impossible to provide a globally-routable= , long-term URI to the UA. (Or at least, it appears so to me at this momen= t. There may be tricks to avoid the problem.) Which means that it is impo= ssible to provide a GRUU for the UA. Dale From HKaplan@acmepacket.com Tue Oct 19 11:16:25 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A64DE3A6919 for ; Tue, 19 Oct 2010 11:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUnLY8-paLMF for ; Tue, 19 Oct 2010 11:16:22 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 652D13A68C2 for ; Tue, 19 Oct 2010 11:16:22 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 19 Oct 2010 14:17:53 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 19 Oct 2010 14:17:39 -0400 From: Hadriel Kaplan To: "Worley, Dale R (Dale)" Date: Tue, 19 Oct 2010 14:17:38 -0400 Thread-Topic: [dispatch] Comment on draft-kaplan-dispatch-gruu-problematic-00 Thread-Index: Actvuel2nBGEyQyqTYe7oos9yMQdwA== Message-ID: <0B2570E8-F3AE-4A8A-A460-12FA4711CF92@acmepacket.com> References: <4CBDA041.5080804@cisco.com>, <044360F3-B0E3-46AC-8C94-532428AFDD41@acmepacket.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comment on draft-kaplan-dispatch-gruu-problematic-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 18:16:26 -0000 On Oct 19, 2010, at 1:21 PM, Worley, Dale R (Dale) wrote: > My first impression is "Don't *do* that!". > At the very least, the element that mints GRUUs, or rather the administra= tive structure that is responsible for it, is responsible for ensuring that= the GRUUs are *globally routable*. If the SIP domain is part of an access= -limited network, then they need to construct proper globally-advertised an= d globally-accessible incoming gateways. Then by definition they're *not* an access-restricted domain. There's no d= ebate that if everyone can successfully send a request into your domain, fr= om anywhere on the public Internets (v4 and v6), you can use GRUUs. The dr= aft doesn't say otherwise. What it says is that most domains don't fit tha= t bill, so they shouldn't mint GRUUs. =20 And before you say "well, duh!", I should point out 3GPP specs think they c= an use GRUUs, when they really can't. There isn't a single 3GPP deployment= I can think of that could really use a GRUU as intended. =20 And at least one Enterprise-based vendor provides GRUUs by default, even th= ough in every deployment I've seen them used in they shouldn't be. =20 I just don't think it's clear to folks what the ramifications are of mintin= g a GRUU. At least if we assume UAs really would change behavior when get= ting a GRUU contact. (for example, if they switch to using out-of-dialog RE= FER, or a b2bua decides to pass the gruu contact on) -hadriel From HKaplan@acmepacket.com Tue Oct 19 11:25:20 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE20C3A6918 for ; Tue, 19 Oct 2010 11:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXm3zmV3k89d for ; Tue, 19 Oct 2010 11:25:13 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 172803A68E1 for ; Tue, 19 Oct 2010 11:25:09 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 19 Oct 2010 14:26:40 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 19 Oct 2010 14:26:34 -0400 From: Hadriel Kaplan To: "Worley, Dale R (Dale)" Date: Tue, 19 Oct 2010 14:26:24 -0400 Thread-Topic: [dispatch] Comment on draft-kaplan-dispatch-gruu-problematic-00 Thread-Index: ActvuyhbXxby3UdGR0CXcI+eVVDNCQ== Message-ID: <307B5EF5-16E0-4366-BE0B-085B2281507F@acmepacket.com> References: <4CBDA041.5080804@cisco.com>, <044360F3-B0E3-46AC-8C94-532428AFDD41@acmepacket.com> , <4CBDD5D0.4030203@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comment on draft-kaplan-dispatch-gruu-problematic-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 18:25:20 -0000 On Oct 19, 2010, at 1:33 PM, Worley, Dale R (Dale) wrote: > If the only way for global access to a UA is through some sort of border = SBC, and if the border SBC won't keep any information around much longer th= an the length of a call, then it is impossible to provide a globally-routab= le, long-term URI to the UA. (Or at least, it appears so to me at this mom= ent. There may be tricks to avoid the problem.) Which means that it is im= possible to provide a GRUU for the UA. It's not the "SBC" that isn't keeping the info around - afaik most SBC's ha= ve the ability to generate "Global Contacts" which last exactly as long as = the Contact they generated it based on. (which itself may or may not be pas= t the duration of a call) For example, they generate an encrypted version = of the original. The problem would be if the original contact they generat= ed it based on didn't last long, which does happen in practice. But that's= not a "problem" the draft really focuses on, or is meant to. (and arguably= it's not a "problem" to begin with) -hadriel From aallen@rim.com Tue Oct 19 12:54:38 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 645483A694E for ; Tue, 19 Oct 2010 12:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.552 X-Spam-Level: X-Spam-Status: No, score=-5.552 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1Ep7dmHL8cH for ; Tue, 19 Oct 2010 12:54:37 -0700 (PDT) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id CEB083A67AB for ; Tue, 19 Oct 2010 12:54:36 -0700 (PDT) X-AuditID: 0a401fcb-b7bbeae000000588-f1-4cbdf7d6436b Received: from XCH139CNC.rim.net ( [10.65.10.235]) by mhs03ykf.rim.net (RIM Mail) with SMTP id 03.71.01416.6D7FDBC4; Tue, 19 Oct 2010 15:56:06 -0400 (EDT) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH139CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Oct 2010 15:56:06 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 19 Oct 2010 14:56:03 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] draft-allen-dispatch-imei-urn-as-instanceid-00 Thread-Index: Actu3aKJNPdcvGjCRaiwRmJz0dH11QALI81+AC9dlIU= From: "Andrew Allen" To: , X-OriginalArrivalTime: 19 Oct 2010 19:56:06.0560 (UTC) FILETIME=[AAD74200:01CB6FC7] X-Brightmail-Tracker: AAAAAQAAAZE= Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-allen-dispatch-imei-urn-as-instanceid-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 19:54:38 -0000 Dale, Paul Thank you for your comments. I plan to make a revision based on them and hop= efully resubmit before the 2nd deadline. Hopefully we can discuss in Beijing= . Andrew ----- Original Message ----- From: Worley, Dale R (Dale) [mailto:dworley@avaya.com] Sent: Monday, October 18, 2010 05:19 PM To: Paul Kyzivat Cc: Andrew Allen; dispatch@ietf.org Subject: RE: [dispatch] draft-allen-dispatch-imei-urn-as-instanceid-00 > From: Paul Kyzivat [pkyzivat@cisco.com] > > IMO the problem is that this draft expects the registrar to use special > comparison rules for this sort of URN. > > If it removed that requirement, and instead put a requirement on the UA > to construct its URN in such a way that the lexical equality rule of > 2141 is sufficient, then I think all would be well. Yes, clearly, having the UAs depend on special behavior in the registrar for this URN scheme would mean that only specialized registrars could cope with UAs that used these URNs as their instance id. That would minimize compatibility. The draft needs to be revised to follow RFC 5626 section 4.1 (which is referenced from the GRUU RFC). Dale ---------------------------------------------------------------------=0A= 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 stpeter@stpeter.im Tue Oct 19 13:15:31 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 178943A6960 for ; Tue, 19 Oct 2010 13:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.297 X-Spam-Level: X-Spam-Status: No, score=-102.297 tagged_above=-999 required=5 tests=[AWL=-0.298, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2Tb0ec4cfRp for ; Tue, 19 Oct 2010 13:15:27 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 4F43F3A6956 for ; Tue, 19 Oct 2010 13:15:26 -0700 (PDT) Received: from dhcp-64-101-72-188.cisco.com (dhcp-64-101-72-188.cisco.com [64.101.72.188]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2947A40074 for ; Tue, 19 Oct 2010 14:24:19 -0600 (MDT) Message-ID: <4CBDFCB8.302@stpeter.im> Date: Tue, 19 Oct 2010 14:16:56 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "dispatch@ietf.org" X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080704080403000901010508" Subject: [dispatch] proposed SIXPAC charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 20:15:31 -0000 This is a cryptographically signed message in MIME format. --------------ms080704080403000901010508 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Earlier this year, some folks in the RAI area proposed an initiative to define a few small extensions to both SIP and XMPP that would make it easier to develop and deploy dual-stack SIP+XMPP endpoints. Based on feedback provided on the DISPATCH list and received from the RAI ADs, I've taken the liberty of rewriting the proposed charter, in the hopes that fresh text will spur a more conclusive discussion. I'm mostly just trying to help the proponents put their best foot forward, so if folks here have more feedback I'd expect that people like Simo Veikkolainen and Emil Ivov will be able to engage in further discussion. /psa ### SIXPAC (SIP Integration with XMPP in Presence Aware Clients) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Problem Statement Both the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) are widely deployed technologies for real-time communication over the Internet. In order to offer a complete suite of features as well as communication across multiple networks, several user-oriented software applications support both SIP and XMPP, and more software developers have expressed interest in building such "dual-stack" solutions. Unfortunately, it is difficult to provide a good end-user experience in such applications because SIP and XMPP are not aware of each other. For example: - XMPP presence does not include availability states related to a SIP voice call or video call (e.g., "on the phone"), thus preventing an a dual-stack endpoint from showing presence-based communication hints - There is no correlation between an XMPP IM session and a SIP voice or video session, thus preventing a dual-stack endpoint from providing integrated user interfaces and communications history - SIP accounts and XMPP accounts are not directly correlated in contact lists or vCards (and not all deployed services support storage of such information), thus preventing a dual-stack endpoint from knowing that a contact has both SIP and XMPP capabilities Although some proprietary solutions exist to the foregoing problems, it would be preferable to define standardized solutions for the sake of improved interoperability. Objectives Because both SIP and XMPP are easily extended through new SIP headers and XMPP elements, it should be possible to provide tighter integration within dual-stack SIP/XMPP user agents to improve the user experience. Any such extensions should meet the following criteria: - Be completely optional and backwards-compatible for all endpoints - Work without changes to deployed infrastructure such as existing SIP and XMPP servers, B2BUAs, firewalls, etc. The SIXPAC WG will define a small number of SIP and XMPP extensions to solve the following use cases in dual-stack endpoints: - Including SIP-based availability states in XMPP presence (limited to basic presence and availability states only, not the full range of PIDF extensions) - Correlating an XMPP IM session with a SIP voice/video session, and vice-versa - Advertising a SIP account address over XMPP and an XMPP account address over SIP Additional use cases are out of scope, including anything related to or requiring server integration, multiparty communication, SIP-based IM and presence, XMPP-based voice and video, file transfer, generalized service discovery and capabilities exchange, full protocol translation in communication gateways, shared credentials across both SIP and XMPP accounts, rich presence extensions for features such as geolocation, etc. Although such topics are important and interesting, they are out of scope for this group. However, in addition to the protocol extensions explicitly mentioned above, the group may also define best practices related to the implementation and deployment of dual-stack SIP/XMPP endpoints, including topics such as user agent configuration. Deliverables - Use cases and protocol requirements - XMPP presence extension for SIP-based availability states - Media session correlation extensions for SIP and XMPP - Contact address advertisement extensions for SIP and XMPP - Best practices for implementation and deployment of dual-stack endpoints Milestones Feb 2011 Submit use cases and protocol requirements document to IESG (Informational) Oct 2011 Submit XMPP presence extension document to IESG (Standards Track) Oct 2011 Submit media session correlation extensions document to IESG (Standards Track) Oct 2011 Submit contact address advertisement extension document to IESG (Standards Track) Oct 2011 Submit best practices document to IESG (Informational) ### --------------ms080704080403000901010508 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAx OTIwMTY1NlowIwYJKoZIhvcNAQkEMRYEFPqtg86GlT+uPkkPokvctbwMOQrQMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCnGFxqOU5C+yIi/1aHsbQ/nfZgPgC98SzpWBOwI+7QB2ZT6b5tb4HPR8MJ WhRs8UloQasLh9PwcgttSb8LUIb/3NBWrTkOq5cS6c3Hn8mwd580I54axDFX5Q+VbFUWxo4e FKhzpAIQBFPV5oAvWsW2A015LluddgSY4R+vA/vockL9O4fjrSg3sVDgWWcaERUfAdt7LNzo 6pub6qo9DAYQub0jCYK0WedRBdKJR3dDMmfRLabBNJ9esiSej0/T2wFtAlv72PR8vR5PrqgV NfbChzgKCw73wDzRyI3BLKCaajwFykpYQabBdYAxxKyPM4XEeU6GpQaZqSexQQWvBholAAAA AAAA --------------ms080704080403000901010508-- From HKaplan@acmepacket.com Tue Oct 19 13:45:32 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58AAC3A696E for ; Tue, 19 Oct 2010 13:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJ941VSQGsY2 for ; Tue, 19 Oct 2010 13:45:31 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 5AD053A697E for ; Tue, 19 Oct 2010 13:45:31 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 19 Oct 2010 16:47:01 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 19 Oct 2010 16:46:41 -0400 From: Hadriel Kaplan To: "dispatch@ietf.org list" Date: Tue, 19 Oct 2010 16:46:40 -0400 Thread-Topic: New I-D: draft-kaplan-dispatch-gruu-problematic-00 Thread-Index: Actvzrs2IgYdPRiiQnmjobzjHnIofw== Message-ID: <5D3F6C26-D143-4BD1-A8C8-F8A2BE772772@acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dispatch] New I-D: draft-kaplan-dispatch-gruu-problematic-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 20:45:32 -0000 So I suppose there's no point in waiting for a dotting of i's and crossing = of t's... During the Martini WG meeting in Maastricht, and a debate about mandating S= SPs mint GRUUs in GIN, I mentioned that GRUU's weren't as useful as we thin= k they are, and that they have some issues. I was then told to submit an I= -D, which is what this I-D announcement is about. Below is the link to an I-D discussing some issues with GRUUs discovered in= deployments, cases in which using GRUUs may make things worse, and conside= rations for B2BUAs. -hadriel p.s. and yes, the draft name is meant to be humorous ........................... A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Problems with the SIP Globally Routable User Agent URIs = (GRUUs) Author(s) : H. Kaplan Filename : draft-kaplan-dispatch-gruu-problematic-00.txt Pages : 11 Date : 2010-10-18 This document identifies some issues discovered in deployments of=20 the SIP GRUU mechanism defined in [RFC5627], cases in which GRUUs=20 may be harmful, and considerations for B2BUAs handling GRUUs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kaplan-dispatch-gruu-problematic-= 00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From pkyzivat@cisco.com Tue Oct 19 17:20:10 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B07623A697D for ; Tue, 19 Oct 2010 17:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.495 X-Spam-Level: X-Spam-Status: No, score=-110.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6c19ShDyzx2 for ; Tue, 19 Oct 2010 17:20:09 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 85EDF3A696E for ; Tue, 19 Oct 2010 17:20:09 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEPTvUxAZnwN/2dsb2JhbAChU3GnUpxAhUoEikuDBA X-IronPort-AV: E=Sophos;i="4.57,353,1283731200"; d="scan'208";a="172705686" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 20 Oct 2010 00:21:41 +0000 Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o9K0LfFL026344; Wed, 20 Oct 2010 00:21:41 GMT Message-ID: <4CBE3614.10302@cisco.com> Date: Tue, 19 Oct 2010 20:21:40 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Hadriel Kaplan References: <4CBDA041.5080804@cisco.com> <044360F3-B0E3-46AC-8C94-532428AFDD41@acmepacket.com> In-Reply-To: <044360F3-B0E3-46AC-8C94-532428AFDD41@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comment on draft-kaplan-dispatch-gruu-problematic-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 00:20:10 -0000 On 10/19/2010 12:52 PM, Hadriel Kaplan wrote: > Hi Paul, > comments inline... > > On Oct 19, 2010, at 9:42 AM, Paul Kyzivat wrote: > >> I haven't seen the announcement for this draft yet, so this was my first >> introduction to it. >> >> While there are some real problems identified in here, for the most part >> this is calling out cases where things have been done wrong or poorly, >> and blaming gruu. > > I don't think I'm "blaming gruu" (well... except for the argument that the RFC should have made the UA insert a Record-Route of its real contact). In general the draft isn't trying to blame gruu - it's trying to explain why gruu isn't a magic cure-all. Well, I *took* it as blame. :-) I don't really want to end up as an apologist for gruu. Its not a wonderful thing. But its what we have, and I think we should try to make it work before giving up on it. >> I do think it will be useful to go through this point by point and >> discuss plausible remedies. > > How would you like to do that? Email in dispatch, or separate mailing list, or future IETF Dispatch meeting, or BOF? I don't think it warrants its own mailing list, or scheduled time at the meeting. So I think either discussion on some existing list (dispatch or sipcore would do), and/or informal time in Beijing. >> IMO it is the responsibility of those deploying B2BUAs to do so in a way >> that doesn't break things. I realize that in some cases the *purpose* of >> the B2BUA is to break things, and that can be a valid thing to do, as >> long as it only breaks the things that should be broken. > > I think the hard part here is figuring out which behavior doesn't break things. I've convinced myself that "passing on" the GRUU will break things more than replacing it, but I'm not sure whether replacing it with a self-made GRUU is actually good or bad. I'm not sure that a B2BUA or any system ever really knows whether its Contact URI is globally routable to, or whether it actually matters or not. I think the hard part here is understanding the environments where things will break. In every case it seems to come down to: - operators of some system/domain want to restrict use in some way - B2BUAs (or maybe just firewalls, NATs, etc.) are inserted to accomplish that - are the restrictions reasonable, or simply wrong headed? - which things *should* work given reasonable restrictions - do GRUUs contribute to a solution, or just make it worse? - how must GRUUs be managed so that they do work in the cases where they should? This is in some sense a revisiting of the "what is an SBC" question. >> Also, ISTM that its about time to start doing something about access >> limited networks. Access limiting sip networks makes as little sense as >> access limiting email networks. In spite of spam problems, the world >> would not work if email was restricted the way sip is. > > Good luck with that. :) I realize it seems like an impossible task. But it also once seemed like an impossible task to federate all the disparate networks in the world. That pretty much got done. > Email's spam level would destroy voip's viability, Certainly. But if email were being deployed for the first time today it would have a lot of the things that have now been invented to address the problem but haven't been widely adopted. > never-mind the regulatory, billing, and interop issues. There are free SIP domains without access restrictions, but they're the minority afaict. > Over time this may well change, but I doubt it'll be soon. It'll change or else everybody will just use Skype and the PSTN will die. Thanks, Paul From pkyzivat@cisco.com Tue Oct 19 17:26:28 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31FA43A6982 for ; Tue, 19 Oct 2010 17:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.495 X-Spam-Level: X-Spam-Status: No, score=-110.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90eBtZYGli+A for ; Tue, 19 Oct 2010 17:26:27 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 11D093A697D for ; Tue, 19 Oct 2010 17:26:27 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAHDUvUyrRN+K/2dsb2JhbACTYY1ycacznEOFSgSKS4ME X-IronPort-AV: E=Sophos;i="4.57,353,1283731200"; d="scan'208";a="203479349" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 20 Oct 2010 00:27:58 +0000 Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o9K0RwmV027234 for ; Wed, 20 Oct 2010 00:27:58 GMT Message-ID: <4CBE378E.6080506@cisco.com> Date: Tue, 19 Oct 2010 20:27:58 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: dispatch@ietf.org References: <4CBDA041.5080804@cisco.com>, <044360F3-B0E3-46AC-8C94-532428AFDD41@acmepacket.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] Comment on draft-kaplan-dispatch-gruu-problematic-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 00:26:28 -0000 On the surface this seems something like the ICE problem. ICE assumes that the UA can't really know if it has a public address. Its a bit different here in that we aren't talking about individual UAs - its really a domain administration problem. It should be possible for the administrator of a domain to know if it has publicly routable addresses or not, and then to provision those elements that will be minting GRUUs (or not) accordingly. A registrar that doesn't have a public address should not support handing out GRUUs. That will limit the functionality of the devices it services. The fits in with Martini - which potentially gives a registrar without its own public address a way to mint gruus for its devices. Thanks, Paul On 10/19/2010 1:21 PM, Worley, Dale R (Dale) wrote: > My first impression is "Don't *do* that!". > > At the very least, the element that mints GRUUs, or rather the administrative structure that is responsible for it, is responsible for ensuring that the GRUUs are *globally routable*. If the SIP domain is part of an access-limited network, then they need to construct proper globally-advertised and globally-accessible incoming gateways. > > If they're minting URIs that claim to be GRUUs but are not, the problem isn't with GRUUs per se but rather that they're not minting GRUUs. More subtly, the problem may be that there are situations where it is *not possible* to provide a globally-routable URI for a UA that has a indefinite lifetime. We may need to provide alternative solutions for that problem. > > Dale > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From pkyzivat@cisco.com Tue Oct 19 17:29:29 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AD803A68E3 for ; Tue, 19 Oct 2010 17:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.496 X-Spam-Level: X-Spam-Status: No, score=-110.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYM2UraKTAbJ for ; Tue, 19 Oct 2010 17:29:28 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 188C23A68AC for ; Tue, 19 Oct 2010 17:29:28 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAHDUvUyrRN+K/2dsb2JhbACTYY1ycacznEOFSgSKS4ME X-IronPort-AV: E=Sophos;i="4.57,353,1283731200"; d="scan'208";a="203480423" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 20 Oct 2010 00:31:00 +0000 Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o9K0UxDQ028998 for ; Wed, 20 Oct 2010 00:30:59 GMT Message-ID: <4CBE3843.3040704@cisco.com> Date: Tue, 19 Oct 2010 20:30:59 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: dispatch@ietf.org References: <4CBDA041.5080804@cisco.com>, <044360F3-B0E3-46AC-8C94-532428AFDD41@acmepacket.com> <0B2570E8-F3AE-4A8A-A460-12FA4711CF92@acmepacket.com> In-Reply-To: <0B2570E8-F3AE-4A8A-A460-12FA4711CF92@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] Comment on draft-kaplan-dispatch-gruu-problematic-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 00:29:29 -0000 I think we need to separate out the ipv6 issue from the gruu issue. If I have a publicly routable URI that is only v4, then I think it still can qualify as a GRUU, even though v6-only nodes cannot use it. We need some sort of mechanism to solve the v4/v6 problem for such cases. Thanks, Paul On 10/19/2010 2:17 PM, Hadriel Kaplan wrote: > > On Oct 19, 2010, at 1:21 PM, Worley, Dale R (Dale) wrote: > >> My first impression is "Don't *do* that!". >> At the very least, the element that mints GRUUs, or rather the administrative structure that is responsible for it, is responsible for ensuring that the GRUUs are *globally routable*. If the SIP domain is part of an access-limited network, then they need to construct proper globally-advertised and globally-accessible incoming gateways. > > Then by definition they're *not* an access-restricted domain. There's no debate that if everyone can successfully send a request into your domain, from anywhere on the public Internets (v4 and v6), you can use GRUUs. The draft doesn't say otherwise. What it says is that most domains don't fit that bill, so they shouldn't mint GRUUs. > > And before you say "well, duh!", I should point out 3GPP specs think they can use GRUUs, when they really can't. There isn't a single 3GPP deployment I can think of that could really use a GRUU as intended. > And at least one Enterprise-based vendor provides GRUUs by default, even though in every deployment I've seen them used in they shouldn't be. > > I just don't think it's clear to folks what the ramifications are of minting a GRUU. At least if we assume UAs really would change behavior when getting a GRUU contact. (for example, if they switch to using out-of-dialog REFER, or a b2bua decides to pass the gruu contact on) > > -hadriel > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From john.elwell@siemens-enterprise.com Wed Oct 20 00:44:21 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1FED3A69DB for ; Wed, 20 Oct 2010 00:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.318 X-Spam-Level: X-Spam-Status: No, score=-102.318 tagged_above=-999 required=5 tests=[AWL=-0.319, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmHT2qyW0FKm for ; Wed, 20 Oct 2010 00:44:20 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 6462F3A69DA for ; Wed, 20 Oct 2010 00:44:20 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1969304; Wed, 20 Oct 2010 09:45:51 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 0E6021EB82AB; Wed, 20 Oct 2010 09:45:51 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 20 Oct 2010 09:45:51 +0200 From: "Elwell, John" To: Peter Saint-Andre , "dispatch@ietf.org" Date: Wed, 20 Oct 2010 09:45:49 +0200 Thread-Topic: [dispatch] proposed SIXPAC charter Thread-Index: ActvypzJ6EHXgiwVRXmixTa9CbUA/gAXt36A Message-ID: References: <4CBDFCB8.302@stpeter.im> In-Reply-To: <4CBDFCB8.302@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] proposed SIXPAC charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 07:44:21 -0000 I find this a worthwhile topic to pursue. I had been wondering whether this= activity would turn out to be more of a profiling exercise, and whether th= e IETF might not be the best choice of venue for such work. From the curren= t draft charter it looks like there will be at least some protocol extensio= n work, for which I believe the IETF is the correct venue. On the other han= d, the Unified Communications Interoperability Forum (UCIF) is seeking to a= dvance the state of play on XMPP interoperability, and if we were just talk= ing about a profile or BCP, that might have been a better venue. Perhaps th= e IETF should focus on requirements and protocol extensions, and consider w= hether the BCP work would be better done elsewhere. Or at least, there shou= ld be some coordination with other activities relating to XMPP interoperabi= lity. John =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Peter Saint-Andre > Sent: 19 October 2010 21:17 > To: dispatch@ietf.org > Subject: [dispatch] proposed SIXPAC charter >=20 > Earlier this year, some folks in the RAI area proposed an=20 > initiative to > define a few small extensions to both SIP and XMPP that would make it > easier to develop and deploy dual-stack SIP+XMPP endpoints. Based on > feedback provided on the DISPATCH list and received from the RAI ADs, > I've taken the liberty of rewriting the proposed charter, in the hopes > that fresh text will spur a more conclusive discussion. I'm=20 > mostly just > trying to help the proponents put their best foot forward, so if folks > here have more feedback I'd expect that people like Simo Veikkolainen > and Emil Ivov will be able to engage in further discussion. >=20 > /psa >=20 > ### >=20 > SIXPAC (SIP Integration with XMPP in Presence Aware Clients) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Problem Statement >=20 > Both the Session Initiation Protocol (SIP) and the Extensible=20 > Messaging > and Presence Protocol (XMPP) are widely deployed technologies for > real-time communication over the Internet. In order to offer=20 > a complete > suite of features as well as communication across multiple networks, > several user-oriented software applications support both SIP and XMPP, > and more software developers have expressed interest in building such > "dual-stack" solutions. Unfortunately, it is difficult to provide a > good end-user experience in such applications because SIP and XMPP are > not aware of each other. For example: >=20 > - XMPP presence does not include availability states related to a SIP > voice call or video call (e.g., "on the phone"), thus preventing an > a dual-stack endpoint from showing presence-based=20 > communication hints >=20 > - There is no correlation between an XMPP IM session and a SIP voice > or video session, thus preventing a dual-stack endpoint=20 > from providing > integrated user interfaces and communications history >=20 > - SIP accounts and XMPP accounts are not directly correlated=20 > in contact > lists or vCards (and not all deployed services support=20 > storage of such > information), thus preventing a dual-stack endpoint from=20 > knowing that > a contact has both SIP and XMPP capabilities >=20 > Although some proprietary solutions exist to the foregoing=20 > problems, it > would be preferable to define standardized solutions for the sake of > improved interoperability. >=20 > Objectives >=20 > Because both SIP and XMPP are easily extended through new SIP headers > and XMPP elements, it should be possible to provide tighter=20 > integration > within dual-stack SIP/XMPP user agents to improve the user experience. >=20 > Any such extensions should meet the following criteria: >=20 > - Be completely optional and backwards-compatible for all endpoints >=20 > - Work without changes to deployed infrastructure such as existing > SIP and XMPP servers, B2BUAs, firewalls, etc. >=20 > The SIXPAC WG will define a small number of SIP and XMPP extensions to > solve the following use cases in dual-stack endpoints: >=20 > - Including SIP-based availability states in XMPP presence (limited to > basic presence and availability states only, not the full range of > PIDF extensions) >=20 > - Correlating an XMPP IM session with a SIP voice/video session, and > vice-versa >=20 > - Advertising a SIP account address over XMPP and an XMPP account > address over SIP >=20 > Additional use cases are out of scope, including anything=20 > related to or > requiring server integration, multiparty communication, SIP-based IM > and presence, XMPP-based voice and video, file transfer, generalized > service discovery and capabilities exchange, full protocol translation > in communication gateways, shared credentials across both SIP and XMPP > accounts, rich presence extensions for features such as geolocation, > etc. Although such topics are important and interesting, they are out > of scope for this group. >=20 > However, in addition to the protocol extensions explicitly mentioned > above, the group may also define best practices related to the > implementation and deployment of dual-stack SIP/XMPP endpoints, > including topics such as user agent configuration. >=20 > Deliverables >=20 > - Use cases and protocol requirements >=20 > - XMPP presence extension for SIP-based availability states >=20 > - Media session correlation extensions for SIP and XMPP >=20 > - Contact address advertisement extensions for SIP and XMPP >=20 > - Best practices for implementation and deployment of dual-stack > endpoints >=20 > Milestones >=20 > Feb 2011 Submit use cases and protocol requirements document to > IESG (Informational) >=20 > Oct 2011 Submit XMPP presence extension document to IESG > (Standards Track) >=20 > Oct 2011 Submit media session correlation extensions document to IESG > (Standards Track) >=20 > Oct 2011 Submit contact address advertisement extension document to > IESG (Standards Track) >=20 > Oct 2011 Submit best practices document to IESG (Informational) >=20 > ### >=20 >=20 > = From peter.musgrave@magorcorp.com Wed Oct 20 03:37:07 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C63D3A68A2 for ; Wed, 20 Oct 2010 03:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.566 X-Spam-Level: X-Spam-Status: No, score=-101.566 tagged_above=-999 required=5 tests=[AWL=-0.190, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+MhU8QPIGnY for ; Wed, 20 Oct 2010 03:37:03 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id A7E6D3A6887 for ; Wed, 20 Oct 2010 03:37:02 -0700 (PDT) Received: by qwc9 with SMTP id 9so2285058qwc.31 for ; Wed, 20 Oct 2010 03:38:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.231.11 with SMTP id jo11mr6313390qcb.66.1287571113895; Wed, 20 Oct 2010 03:38:33 -0700 (PDT) Received: by 10.229.42.196 with HTTP; Wed, 20 Oct 2010 03:38:33 -0700 (PDT) In-Reply-To: References: <4CBDFCB8.302@stpeter.im> Date: Wed, 20 Oct 2010 06:38:33 -0400 Message-ID: From: Peter Musgrave To: "Elwell, John" Content-Type: multipart/alternative; boundary=00163630f4bbdde96504930a02a3 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] proposed SIXPAC charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 10:37:07 -0000 --00163630f4bbdde96504930a02a3 Content-Type: text/plain; charset=ISO-8859-1 I also think this is a worthwhile topic. I understand John's reservation about just doing profile work - although I would prefer if this was done elsewhere it be be in an open forum (it's my understanding UCIF is a 'paying members only' organization). Peter Musgrave On Wed, Oct 20, 2010 at 3:45 AM, Elwell, John < john.elwell@siemens-enterprise.com> wrote: > I find this a worthwhile topic to pursue. I had been wondering whether this > activity would turn out to be more of a profiling exercise, and whether the > IETF might not be the best choice of venue for such work. From the current > draft charter it looks like there will be at least some protocol extension > work, for which I believe the IETF is the correct venue. On the other hand, > the Unified Communications Interoperability Forum (UCIF) is seeking to > advance the state of play on XMPP interoperability, and if we were just > talking about a profile or BCP, that might have been a better venue. Perhaps > the IETF should focus on requirements and protocol extensions, and consider > whether the BCP work would be better done elsewhere. Or at least, there > should be some coordination with other activities relating to XMPP > interoperability. > > John > > > -----Original Message----- > > From: dispatch-bounces@ietf.org > > [mailto:dispatch-bounces@ietf.org] On Behalf Of Peter Saint-Andre > > Sent: 19 October 2010 21:17 > > To: dispatch@ietf.org > > Subject: [dispatch] proposed SIXPAC charter > > > > Earlier this year, some folks in the RAI area proposed an > > initiative to > > define a few small extensions to both SIP and XMPP that would make it > > easier to develop and deploy dual-stack SIP+XMPP endpoints. Based on > > feedback provided on the DISPATCH list and received from the RAI ADs, > > I've taken the liberty of rewriting the proposed charter, in the hopes > > that fresh text will spur a more conclusive discussion. I'm > > mostly just > > trying to help the proponents put their best foot forward, so if folks > > here have more feedback I'd expect that people like Simo Veikkolainen > > and Emil Ivov will be able to engage in further discussion. > > > > /psa > > > > ### > > > > SIXPAC (SIP Integration with XMPP in Presence Aware Clients) > > ============================================================== > > =========== > > > > Problem Statement > > > > Both the Session Initiation Protocol (SIP) and the Extensible > > Messaging > > and Presence Protocol (XMPP) are widely deployed technologies for > > real-time communication over the Internet. In order to offer > > a complete > > suite of features as well as communication across multiple networks, > > several user-oriented software applications support both SIP and XMPP, > > and more software developers have expressed interest in building such > > "dual-stack" solutions. Unfortunately, it is difficult to provide a > > good end-user experience in such applications because SIP and XMPP are > > not aware of each other. For example: > > > > - XMPP presence does not include availability states related to a SIP > > voice call or video call (e.g., "on the phone"), thus preventing an > > a dual-stack endpoint from showing presence-based > > communication hints > > > > - There is no correlation between an XMPP IM session and a SIP voice > > or video session, thus preventing a dual-stack endpoint > > from providing > > integrated user interfaces and communications history > > > > - SIP accounts and XMPP accounts are not directly correlated > > in contact > > lists or vCards (and not all deployed services support > > storage of such > > information), thus preventing a dual-stack endpoint from > > knowing that > > a contact has both SIP and XMPP capabilities > > > > Although some proprietary solutions exist to the foregoing > > problems, it > > would be preferable to define standardized solutions for the sake of > > improved interoperability. > > > > Objectives > > > > Because both SIP and XMPP are easily extended through new SIP headers > > and XMPP elements, it should be possible to provide tighter > > integration > > within dual-stack SIP/XMPP user agents to improve the user experience. > > > > Any such extensions should meet the following criteria: > > > > - Be completely optional and backwards-compatible for all endpoints > > > > - Work without changes to deployed infrastructure such as existing > > SIP and XMPP servers, B2BUAs, firewalls, etc. > > > > The SIXPAC WG will define a small number of SIP and XMPP extensions to > > solve the following use cases in dual-stack endpoints: > > > > - Including SIP-based availability states in XMPP presence (limited to > > basic presence and availability states only, not the full range of > > PIDF extensions) > > > > - Correlating an XMPP IM session with a SIP voice/video session, and > > vice-versa > > > > - Advertising a SIP account address over XMPP and an XMPP account > > address over SIP > > > > Additional use cases are out of scope, including anything > > related to or > > requiring server integration, multiparty communication, SIP-based IM > > and presence, XMPP-based voice and video, file transfer, generalized > > service discovery and capabilities exchange, full protocol translation > > in communication gateways, shared credentials across both SIP and XMPP > > accounts, rich presence extensions for features such as geolocation, > > etc. Although such topics are important and interesting, they are out > > of scope for this group. > > > > However, in addition to the protocol extensions explicitly mentioned > > above, the group may also define best practices related to the > > implementation and deployment of dual-stack SIP/XMPP endpoints, > > including topics such as user agent configuration. > > > > Deliverables > > > > - Use cases and protocol requirements > > > > - XMPP presence extension for SIP-based availability states > > > > - Media session correlation extensions for SIP and XMPP > > > > - Contact address advertisement extensions for SIP and XMPP > > > > - Best practices for implementation and deployment of dual-stack > > endpoints > > > > Milestones > > > > Feb 2011 Submit use cases and protocol requirements document to > > IESG (Informational) > > > > Oct 2011 Submit XMPP presence extension document to IESG > > (Standards Track) > > > > Oct 2011 Submit media session correlation extensions document to IESG > > (Standards Track) > > > > Oct 2011 Submit contact address advertisement extension document to > > IESG (Standards Track) > > > > Oct 2011 Submit best practices document to IESG (Informational) > > > > ### > > > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --00163630f4bbdde96504930a02a3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I also think this is a worthwhile topic.=A0

I understand= John's reservation about just doing profile work - although I would pr= efer if this was done elsewhere it be be in an open forum (it's my unde= rstanding UCIF is a 'paying members only' organization).=A0

Peter Musgrave

On Wed= , Oct 20, 2010 at 3:45 AM, Elwell, John <john.elwell@siemens-enterprise.com= > wrote:
I find this a worthwhile topic to pursue. I= had been wondering whether this activity would turn out to be more of a pr= ofiling exercise, and whether the IETF might not be the best choice of venu= e for such work. From the current draft charter it looks like there will be= at least some protocol extension work, for which I believe the IETF is the= correct venue. On the other hand, the Unified Communications Interoperabil= ity Forum (UCIF) is seeking to advance the state of play on XMPP interopera= bility, and if we were just talking about a profile or BCP, that might have= been a better venue. Perhaps the IETF should focus on requirements and pro= tocol extensions, and consider whether the BCP work would be better done el= sewhere. Or at least, there should be some coordination with other activiti= es relating to XMPP interoperability.

John

> -----Original Message-----
> From: dispatch-bounces@ie= tf.org
> [mailto:dispatch-bounces@= ietf.org] On Behalf Of Peter Saint-Andre
> Sent: 19 October 2010 21:17
> To: dispatch@ietf.org
> Subject: [dispatch] proposed SIXPAC charter
>
> Earlier this year, some folks in the RAI area proposed an
> initiative to
> define a few small extensions to both SIP and XMPP that would make it<= br> > easier to develop and deploy dual-stack SIP+XMPP endpoints. Based on > feedback provided on the DISPATCH list and received from the RAI ADs,<= br> > I've taken the liberty of rewriting the proposed charter, in the h= opes
> that fresh text will spur a more conclusive discussion. I'm
> mostly just
> trying to help the proponents put their best foot forward, so if folks=
> here have more feedback I'd expect that people like Simo Veikkolai= nen
> and Emil Ivov will be able to engage in further discussion.
>
> /psa
>
> ###
>
> SIXPAC (SIP Integration with XMPP in Presence Aware Clients)
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> Problem Statement
>
> Both the Session Initiation Protocol (SIP) and the Extensible
> Messaging
> and Presence Protocol (XMPP) are widely deployed technologies for
> real-time communication over the Internet. =A0In order to offer
> a complete
> suite of features as well as communication across multiple networks, > several user-oriented software applications support both SIP and XMPP,=
> and more software developers have expressed interest in building such<= br> > "dual-stack" solutions. =A0Unfortunately, it is difficult to= provide a
> good end-user experience in such applications because SIP and XMPP are=
> not aware of each other. =A0For example:
>
> - XMPP presence does not include availability states related to a SIP<= br> > =A0 voice call or video call (e.g., "on the phone"), thus pr= eventing an
> =A0 a dual-stack endpoint from showing presence-based
> communication hints
>
> - There is no correlation between an XMPP IM session and a SIP voice > =A0 or video session, thus preventing a dual-stack endpoint
> from providing
> =A0 integrated user interfaces and communications history
>
> - SIP accounts and XMPP accounts are not directly correlated
> in contact
> =A0 lists or vCards (and not all deployed services support
> storage of such
> =A0 information), thus preventing a dual-stack endpoint from
> knowing that
> =A0 a contact has both SIP and XMPP capabilities
>
> Although some proprietary solutions exist to the foregoing
> problems, it
> would be preferable to define standardized solutions for the sake of > improved interoperability.
>
> Objectives
>
> Because both SIP and XMPP are easily extended through new SIP headers<= br> > and XMPP elements, it should be possible to provide tighter
> integration
> within dual-stack SIP/XMPP user agents to improve the user experience.=
>
> Any such extensions should meet the following criteria:
>
> - Be completely optional and backwards-compatible for all endpoints >
> - Work without changes to deployed infrastructure such as existing
> =A0 SIP and XMPP servers, B2BUAs, firewalls, etc.
>
> The SIXPAC WG will define a small number of SIP and XMPP extensions to=
> solve the following use cases in dual-stack endpoints:
>
> - Including SIP-based availability states in XMPP presence (limited to=
> =A0 basic presence and availability states only, not the full range of=
> =A0 PIDF extensions)
>
> - Correlating an XMPP IM session with a SIP voice/video session, and > =A0 vice-versa
>
> - Advertising a SIP account address over XMPP and an XMPP account
> =A0 address over SIP
>
> Additional use cases are out of scope, including anything
> related to or
> requiring server integration, multiparty communication, SIP-based IM > and presence, XMPP-based voice and video, file transfer, generalized > service discovery and capabilities exchange, full protocol translation=
> in communication gateways, shared credentials across both SIP and XMPP=
> accounts, rich presence extensions for features such as geolocation, > etc. =A0Although such topics are important and interesting, they are o= ut
> of scope for this group.
>
> However, in addition to the protocol extensions explicitly mentioned > above, the group may also define best practices related to the
> implementation and deployment of dual-stack SIP/XMPP endpoints,
> including topics such as user agent configuration.
>
> Deliverables
>
> - Use cases and protocol requirements
>
> - XMPP presence extension for SIP-based availability states
>
> - Media session correlation extensions for SIP and XMPP
>
> - Contact address advertisement extensions for SIP and XMPP
>
> - Best practices for implementation and deployment of dual-stack
> =A0 endpoints
>
> Milestones
>
> Feb 2011 =A0Submit use cases and protocol requirements document to
> =A0 =A0 =A0 =A0 =A0 IESG (Informational)
>
> Oct 2011 =A0Submit XMPP presence extension document to IESG
> =A0 =A0 =A0 =A0 =A0 (Standards Track)
>
> Oct 2011 =A0Submit media session correlation extensions document to IE= SG
> =A0 =A0 =A0 =A0 =A0 (Standards Track)
>
> Oct 2011 =A0Submit contact address advertisement extension document to=
> =A0 =A0 =A0 =A0 =A0 IESG (Standards Track)
>
> Oct 2011 =A0Submit best practices document to IESG (Informational)
>
> ###
>
>
>
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--00163630f4bbdde96504930a02a3-- From dworley@avaya.com Wed Oct 20 07:15:10 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 761AB3A69C5 for ; Wed, 20 Oct 2010 07:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.448 X-Spam-Level: X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qw1j003Yc-6Q for ; Wed, 20 Oct 2010 07:15:09 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 50C193A67D1 for ; Wed, 20 Oct 2010 07:15:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,355,1283745600"; d="scan'208";a="39855046" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 20 Oct 2010 10:16:42 -0400 X-IronPort-AV: E=Sophos;i="4.57,355,1283745600"; d="scan'208";a="524835296" Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 20 Oct 2010 10:16:05 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Wed, 20 Oct 2010 10:16:05 -0400 From: "Worley, Dale R (Dale)" To: Hadriel Kaplan Date: Wed, 20 Oct 2010 10:16:05 -0400 Thread-Topic: [dispatch] Comment on draft-kaplan-dispatch-gruu-problematic-00 Thread-Index: Actvuel2nBGEyQyqTYe7oos9yMQdwAApqLGi Message-ID: References: <4CBDA041.5080804@cisco.com>, <044360F3-B0E3-46AC-8C94-532428AFDD41@acmepacket.com> , <0B2570E8-F3AE-4A8A-A460-12FA4711CF92@acmepacket.com> In-Reply-To: <0B2570E8-F3AE-4A8A-A460-12FA4711CF92@acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comment on draft-kaplan-dispatch-gruu-problematic-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 14:15:10 -0000 ________________________________________ From: Hadriel Kaplan [HKaplan@acmepacket.com] I should point out 3GPP specs think they can use GRUUs, when they really ca= n't. ________________________________________ That doesn't surprise me. But is that a problem with GRUU or with 3GPP? I= n a world where people consider it normal for a network to have *no* global= ly-accessible ingress points, it's not surprising that they have trouble im= plementing internet protocols. ________________________________________ From: Hadriel Kaplan [HKaplan@acmepacket.com] I don't think I'm "blaming gruu" ________________________________________ You have titled the I-D, "Problems with the SIP Globally Routable User Agen= t URIs (GRUUs)". Dale From dworley@avaya.com Wed Oct 20 07:19:30 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8B3F3A6824 for ; Wed, 20 Oct 2010 07:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPxIjEGG3Hu6 for ; Wed, 20 Oct 2010 07:19:28 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 646F53A681E for ; Wed, 20 Oct 2010 07:19:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,355,1283745600"; d="scan'208";a="243590072" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 20 Oct 2010 10:21:01 -0400 X-IronPort-AV: E=Sophos;i="4.57,355,1283745600"; d="scan'208";a="528272501" Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 20 Oct 2010 10:21:01 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Wed, 20 Oct 2010 10:21:00 -0400 From: "Worley, Dale R (Dale)" To: Hadriel Kaplan Date: Wed, 20 Oct 2010 10:19:16 -0400 Thread-Topic: [dispatch] Comment on draft-kaplan-dispatch-gruu-problematic-00 Thread-Index: Actvuel2nBGEyQyqTYe7oos9yMQdwAAp93Y2 Message-ID: References: <4CBDA041.5080804@cisco.com>, <044360F3-B0E3-46AC-8C94-532428AFDD41@acmepacket.com> , <0B2570E8-F3AE-4A8A-A460-12FA4711CF92@acmepacket.com> In-Reply-To: <0B2570E8-F3AE-4A8A-A460-12FA4711CF92@acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comment on draft-kaplan-dispatch-gruu-problematic-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 14:19:30 -0000 ________________________________________ From: Hadriel Kaplan [HKaplan@acmepacket.com] I just don't think it's clear to folks what the ramifications are of mintin= g a GRUU. ________________________________________ Strictly speaking, what you mean is "I don't think it's clear to folks what= the requirements are on what constitutes a GRUU." If something constructs= a URI and it's not globally-routable, it's not a GRUU, regardless of wheth= er it is claimed to be one. Dale From HKaplan@acmepacket.com Wed Oct 20 08:28:37 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FD8C3A67D3 for ; Wed, 20 Oct 2010 08:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDTv0OKlVhPr for ; Wed, 20 Oct 2010 08:28:35 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 3F93E3A67AD for ; Wed, 20 Oct 2010 08:28:35 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 20 Oct 2010 11:30:08 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 20 Oct 2010 11:30:07 -0400 From: Hadriel Kaplan To: "Worley, Dale R (Dale)" Date: Wed, 20 Oct 2010 11:29:59 -0400 Thread-Topic: [dispatch] Comment on draft-kaplan-dispatch-gruu-problematic-00 Thread-Index: Actwa6ykFwfYwc3cT1ypb+kHdMi6mw== Message-ID: <271ED498-1D0C-4DC7-916B-E58B3FF78A9F@acmepacket.com> References: <4CBDA041.5080804@cisco.com>, <044360F3-B0E3-46AC-8C94-532428AFDD41@acmepacket.com> , <0B2570E8-F3AE-4A8A-A460-12FA4711CF92@acmepacket.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comment on draft-kaplan-dispatch-gruu-problematic-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 15:28:37 -0000 On Oct 20, 2010, at 10:16 AM, Worley, Dale R (Dale) wrote: > ________________________________________ > From: Hadriel Kaplan [HKaplan@acmepacket.com] >=20 > I don't think I'm "blaming gruu" > ________________________________________ >=20 > You have titled the I-D, "Problems with the SIP Globally Routable User Ag= ent URIs (GRUUs)". So? If I titled it "Problems with SDP", would it imply I'm blaming SDP for= the problems? -hadriel= From HKaplan@acmepacket.com Wed Oct 20 08:34:12 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D21953A6935 for ; Wed, 20 Oct 2010 08:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69IWDKUEeqyT for ; Wed, 20 Oct 2010 08:34:09 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 4A8DF3A681F for ; Wed, 20 Oct 2010 08:34:08 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 20 Oct 2010 11:35:31 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 20 Oct 2010 11:35:10 -0400 From: Hadriel Kaplan To: "Worley, Dale R (Dale)" Date: Wed, 20 Oct 2010 11:35:09 -0400 Thread-Topic: [dispatch] Comment on draft-kaplan-dispatch-gruu-problematic-00 Thread-Index: ActwbGEFicve3jpMT1qBoTr9Sh5c+Q== Message-ID: <80504FC9-C835-4F60-9DBD-87055395DD0F@acmepacket.com> References: <4CBDA041.5080804@cisco.com>, <044360F3-B0E3-46AC-8C94-532428AFDD41@acmepacket.com> , <0B2570E8-F3AE-4A8A-A460-12FA4711CF92@acmepacket.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comment on draft-kaplan-dispatch-gruu-problematic-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 15:34:13 -0000 On Oct 20, 2010, at 10:19 AM, Worley, Dale R (Dale) wrote: > From: Hadriel Kaplan [HKaplan@acmepacket.com] >=20 > I just don't think it's clear to folks what the ramifications are of mint= ing a GRUU. > ________________________________________ >=20 > Strictly speaking, what you mean is "I don't think it's clear to folks wh= at the requirements are on what constitutes a GRUU." If something construc= ts a URI and it's not globally-routable, it's not a GRUU, regardless of whe= ther it is claimed to be one. Yup.=20 Note, though, that global reachability is only one of the "problems" discus= sed in the draft (although a big section). -hadriel= From hmmr@cisco.com Wed Oct 20 12:17:29 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 702633A67DF for ; Wed, 20 Oct 2010 12:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.977 X-Spam-Level: X-Spam-Status: No, score=-9.977 tagged_above=-999 required=5 tests=[AWL=0.622, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlYxsicO3KP8 for ; Wed, 20 Oct 2010 12:17:13 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 75D4A3A680D for ; Wed, 20 Oct 2010 12:17:10 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFbdvkytJV2Z/2dsb2JhbAChT3GjHpxQhUoEhFWJAA X-IronPort-AV: E=Sophos;i="4.57,356,1283731200"; d="scan'208";a="173062050" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-2.cisco.com with ESMTP; 20 Oct 2010 19:18:43 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o9KJIhEF031043; Wed, 20 Oct 2010 19:18:43 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Oct 2010 14:18:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Oct 2010 14:18:42 -0500 Message-ID: In-Reply-To: <271ED498-1D0C-4DC7-916B-E58B3FF78A9F@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Comment on draft-kaplan-dispatch-gruu-problematic-00 Thread-Index: Actwa6ykFwfYwc3cT1ypb+kHdMi6mwAH6iiw References: <4CBDA041.5080804@cisco.com>, <044360F3-B0E3-46AC-8C94-532428AFDD41@acmepacket.com>, <0B2570E8-F3AE-4A8A-A460-12FA4711CF92@acmepacket.com> <271ED498-1D0C-4DC7-916B-E58B3FF78A9F@acmepacket.com> From: "Mike Hammer (hmmr)" To: "Hadriel Kaplan" , "Worley, Dale R (Dale)" X-OriginalArrivalTime: 20 Oct 2010 19:18:43.0879 (UTC) FILETIME=[9C830B70:01CB708B] Cc: dispatch@ietf.org Subject: Re: [dispatch] Comment on draft-kaplan-dispatch-gruu-problematic-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 19:17:29 -0000 Maybe you should title it: "Best Common Practices for using GRUU Correctly" Then you could describe various problems: X hurts, don't do that. Or, be sure you do this instead. Mike =20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Wednesday, October 20, 2010 11:30 AM To: Worley, Dale R (Dale) Cc: dispatch@ietf.org Subject: Re: [dispatch] Comment on draft-kaplan-dispatch-gruu-problematic-00 On Oct 20, 2010, at 10:16 AM, Worley, Dale R (Dale) wrote: > ________________________________________ > From: Hadriel Kaplan [HKaplan@acmepacket.com] >=20 > I don't think I'm "blaming gruu" > ________________________________________ >=20 > You have titled the I-D, "Problems with the SIP Globally Routable User Agent URIs (GRUUs)". So? If I titled it "Problems with SDP", would it imply I'm blaming SDP for the problems? -hadriel _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From dworley@avaya.com Wed Oct 20 12:34:26 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45A5A3A686D for ; Wed, 20 Oct 2010 12:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.451 X-Spam-Level: X-Spam-Status: No, score=-102.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50fqNMQyWs0B for ; Wed, 20 Oct 2010 12:34:25 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 4E1333A686A for ; Wed, 20 Oct 2010 12:34:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,356,1283745600"; d="scan'208";a="243650235" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 20 Oct 2010 15:35:58 -0400 X-IronPort-AV: E=Sophos;i="4.57,356,1283745600"; d="scan'208";a="524953249" Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 20 Oct 2010 15:35:58 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Wed, 20 Oct 2010 15:35:57 -0400 From: "Worley, Dale R (Dale)" To: Hadriel Kaplan Date: Wed, 20 Oct 2010 15:35:57 -0400 Thread-Topic: [dispatch] Comment on draft-kaplan-dispatch-gruu-problematic-00 Thread-Index: Actwa6ykFwfYwc3cT1ypb+kHdMi6mwAIJi6m Message-ID: References: <4CBDA041.5080804@cisco.com>, <044360F3-B0E3-46AC-8C94-532428AFDD41@acmepacket.com> , <0B2570E8-F3AE-4A8A-A460-12FA4711CF92@acmepacket.com> , <271ED498-1D0C-4DC7-916B-E58B3FF78A9F@acmepacket.com> In-Reply-To: <271ED498-1D0C-4DC7-916B-E58B3FF78A9F@acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comment on draft-kaplan-dispatch-gruu-problematic-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 19:34:26 -0000 ________________________________________ From: Hadriel Kaplan [HKaplan@acmepacket.com] So? If I titled it "Problems with SDP", would it imply I'm blaming SDP for= the problems? ________________________________________ It sounds like that to me -- you're saying the problem is with the design o= f SDP. If you said, "Problems using SDP", that would have a very different meaning= . Consider "Problems with Hadriel's work" vs. "Problems applying Hadriel's wo= rk". Which would you rather have your boss say? And the abstract doesn't make it clear that the core of the problem is syst= ems attempting to create GRUUs that are not, in fact, globally routable. A= better description is "There are many SIP architectures in which GRUUs can= not be constructed. Thus, alternative means need to be found to solve the = problems for which GRUUs are commonly considered to be the solution." Dale From emcho@sip-communicator.org Thu Oct 21 09:52:27 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B53AD3A69D4 for ; Thu, 21 Oct 2010 09:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.866 X-Spam-Level: X-Spam-Status: No, score=-1.866 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTANlDFNgJc3 for ; Thu, 21 Oct 2010 09:52:25 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 778753A699A for ; Thu, 21 Oct 2010 09:52:25 -0700 (PDT) Received: by ewy27 with SMTP id 27so221505ewy.31 for ; Thu, 21 Oct 2010 09:54:00 -0700 (PDT) Received: by 10.216.23.199 with SMTP id v49mr9941638wev.43.1287680040400; Thu, 21 Oct 2010 09:54:00 -0700 (PDT) Received: from porcinet.local (shm67-5-88-165-90-188.fbx.proxad.net [88.165.90.188]) by mx.google.com with ESMTPS id b10sm1194189wer.41.2010.10.21.09.53.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 21 Oct 2010 09:53:59 -0700 (PDT) Message-ID: <4CC07024.9080900@sip-communicator.org> Date: Thu, 21 Oct 2010 18:53:56 +0200 From: Emil Ivov Organization: SIP Communicator User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Elwell, John" References: <4CBDFCB8.302@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org" Subject: Re: [dispatch] proposed SIXPAC charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 16:52:27 -0000 Hey folks, =D0=9D=D0=B0 20.10.10 09:45, Elwell, John =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0= =B0: > I find this a worthwhile topic to pursue. I had been wondering > whether this activity would turn out to be more of a profiling > exercise, and whether the IETF might not be the best choice of venue > for such work. From the current draft charter it looks like there > will be at least some protocol extension work, for which I believe > the IETF is the correct venue. On the other hand, the Unified > Communications Interoperability Forum (UCIF) is seeking to advance > the state of play on XMPP interoperability, and if we were just > talking about a profile or BCP, that might have been a better venue. As you mention yourself, it is likely that the charter would involve extension work that could lead to, for example, new SIP headers. These are undoubtedly best handled here. Cheers, Emil > Perhaps the IETF should focus on requirements and protocol > extensions, and consider whether the BCP work would be better done > elsewhere. Or at least, there should be some coordination with other > activities relating to XMPP interoperability. >=20 > John >=20 >> -----Original Message----- From: dispatch-bounces@ietf.org=20 >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Peter Saint-Andre=20 >> Sent: 19 October 2010 21:17 To: dispatch@ietf.org Subject: >> [dispatch] proposed SIXPAC charter >>=20 >> Earlier this year, some folks in the RAI area proposed an=20 >> initiative to define a few small extensions to both SIP and XMPP >> that would make it easier to develop and deploy dual-stack SIP+XMPP >> endpoints. Based on feedback provided on the DISPATCH list and >> received from the RAI ADs, I've taken the liberty of rewriting the >> proposed charter, in the hopes that fresh text will spur a more >> conclusive discussion. I'm mostly just trying to help the >> proponents put their best foot forward, so if folks here have more >> feedback I'd expect that people like Simo Veikkolainen and Emil >> Ivov will be able to engage in further discussion. >>=20 >> /psa >>=20 >> ### >>=20 >> SIXPAC (SIP Integration with XMPP in Presence Aware Clients)=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> Problem Statement >>=20 >> Both the Session Initiation Protocol (SIP) and the Extensible=20 >> Messaging and Presence Protocol (XMPP) are widely deployed >> technologies for real-time communication over the Internet. In >> order to offer a complete suite of features as well as >> communication across multiple networks, several user-oriented >> software applications support both SIP and XMPP, and more software >> developers have expressed interest in building such "dual-stack" >> solutions. Unfortunately, it is difficult to provide a good >> end-user experience in such applications because SIP and XMPP are=20 >> not aware of each other. For example: >>=20 >> - XMPP presence does not include availability states related to a >> SIP voice call or video call (e.g., "on the phone"), thus >> preventing an a dual-stack endpoint from showing presence-based=20 >> communication hints >>=20 >> - There is no correlation between an XMPP IM session and a SIP >> voice or video session, thus preventing a dual-stack endpoint from >> providing integrated user interfaces and communications history >>=20 >> - SIP accounts and XMPP accounts are not directly correlated in >> contact lists or vCards (and not all deployed services support=20 >> storage of such information), thus preventing a dual-stack endpoint >> from knowing that a contact has both SIP and XMPP capabilities >>=20 >> Although some proprietary solutions exist to the foregoing=20 >> problems, it would be preferable to define standardized solutions >> for the sake of improved interoperability. >>=20 >> Objectives >>=20 >> Because both SIP and XMPP are easily extended through new SIP >> headers and XMPP elements, it should be possible to provide tighter >> integration within dual-stack SIP/XMPP user agents to improve the >> user experience. >>=20 >> Any such extensions should meet the following criteria: >>=20 >> - Be completely optional and backwards-compatible for all >> endpoints >>=20 >> - Work without changes to deployed infrastructure such as existing=20 >> SIP and XMPP servers, B2BUAs, firewalls, etc. >>=20 >> The SIXPAC WG will define a small number of SIP and XMPP extensions >> to solve the following use cases in dual-stack endpoints: >>=20 >> - Including SIP-based availability states in XMPP presence (limited >> to basic presence and availability states only, not the full range >> of PIDF extensions) >>=20 >> - Correlating an XMPP IM session with a SIP voice/video session, >> and vice-versa >>=20 >> - Advertising a SIP account address over XMPP and an XMPP account=20 >> address over SIP >>=20 >> Additional use cases are out of scope, including anything related >> to or requiring server integration, multiparty communication, >> SIP-based IM and presence, XMPP-based voice and video, file >> transfer, generalized service discovery and capabilities exchange, >> full protocol translation in communication gateways, shared >> credentials across both SIP and XMPP accounts, rich presence >> extensions for features such as geolocation, etc. Although such >> topics are important and interesting, they are out of scope for >> this group. >>=20 >> However, in addition to the protocol extensions explicitly >> mentioned above, the group may also define best practices related >> to the implementation and deployment of dual-stack SIP/XMPP >> endpoints, including topics such as user agent configuration. >>=20 >> Deliverables >>=20 >> - Use cases and protocol requirements >>=20 >> - XMPP presence extension for SIP-based availability states >>=20 >> - Media session correlation extensions for SIP and XMPP >>=20 >> - Contact address advertisement extensions for SIP and XMPP >>=20 >> - Best practices for implementation and deployment of dual-stack=20 >> endpoints >>=20 >> Milestones >>=20 >> Feb 2011 Submit use cases and protocol requirements document to=20 >> IESG (Informational) >>=20 >> Oct 2011 Submit XMPP presence extension document to IESG=20 >> (Standards Track) >>=20 >> Oct 2011 Submit media session correlation extensions document to >> IESG (Standards Track) >>=20 >> Oct 2011 Submit contact address advertisement extension document >> to IESG (Standards Track) >>=20 >> Oct 2011 Submit best practices document to IESG (Informational) >>=20 >> ### >>=20 >>=20 >>=20 > _______________________________________________ dispatch mailing > list dispatch@ietf.org=20 > https://www.ietf.org/mailman/listinfo/dispatch >=20 --=20 Emil Ivov, Ph.D. 67000 Strasbourg, Project Lead France SIP Communicator emcho@sip-communicator.org PHONE: +33.1.77.62.43.30 http://sip-communicator.org FAX: +33.1.77.62.47.31 From fluffy@cisco.com Sat Oct 23 06:54:06 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEDEC3A6855 for ; Sat, 23 Oct 2010 06:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.52 X-Spam-Level: X-Spam-Status: No, score=-110.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzGYTqXUq64r for ; Sat, 23 Oct 2010 06:54:05 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 1D02E3A677D for ; Sat, 23 Oct 2010 06:54:05 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABKGwkyrR7Ht/2dsb2JhbAChanGeKZwMhUgEhFSFeYMG X-IronPort-AV: E=Sophos;i="4.58,227,1286150400"; d="scan'208";a="205403113" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 23 Oct 2010 13:55:45 +0000 Received: from [192.168.4.4] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9NDti9i012878; Sat, 23 Oct 2010 13:55:45 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851B8056@ESESSCMS0356.eemea.ericsson.se> Date: Sat, 23 Oct 2010 07:55:46 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <430FC6BDED356B4C8498F634416644A92694381B86@mail> <1D062974A4845E4D8A343C6538049202036C3B5F@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381C2C@mail> <1D062974A4845E4D8A343C6538049202036C3C98@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A92694381E9F@mail> <4C729FEF.6020509@cisco.com> <430FC6BDED356B4C8498F634416644A92694381F16@mail> <4C72C9CA.3070304@cisco.com> <430FC6BDED356B4C8498F634416644A92694381FDF@mail> <4C72EFCC.2000107@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851B8056@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1081) Cc: DISPATCH list Subject: [dispatch] 3GPP DTMF Package X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Oct 2010 13:54:06 -0000 Christer, can you send me a bit more info about this - perhaps a pointer = to the 3GPP spec. Do you know if anyone is following up with the = registration of this? Thanks, Cullen On Aug 23, 2010, at 6:53 PM, Christer Holmberg wrote: >=20 > Hi, >=20 > A while ago, 3GPP also defined a DTMF package. For some reason it = hasn't been registered with IANA yet, but I have requested to ensure = that it happens. >=20 > Regards, >=20 > Christer From fluffy@cisco.com Sat Oct 23 07:08:59 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6071D3A67E7 for ; Sat, 23 Oct 2010 07:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.521 X-Spam-Level: X-Spam-Status: No, score=-110.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id anHQadFY5V1k for ; Sat, 23 Oct 2010 07:08:55 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 35CAB3A677D for ; Sat, 23 Oct 2010 07:08:55 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJeJwkyrR7Ht/2dsb2JhbAChanGeQpwJhUgEhFSFeYMGgmY X-IronPort-AV: E=Sophos;i="4.58,227,1286150400"; d="scan'208";a="274404399" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 23 Oct 2010 14:10:35 +0000 Received: from [192.168.4.4] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9NEAXbF001544; Sat, 23 Oct 2010 14:10:33 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851B8654@ESESSCMS0356.eemea.ericsson.se> Date: Sat, 23 Oct 2010 08:10:35 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <8DD97253-F7BC-4553-8303-4DB9FDD5D9F4@cisco.com> References: <430FC6BDED356B4C8498F634416644A92694381B86@mail><1D062974A4845E4D8A343C6538049202036C3B5F@XMB-BGL-414.cisco.com><430FC6BDED356B4C8498F634416644A92694381C2C@mail><1D062974A4845E4D8A343C6538049202036C3C98@XMB-BGL-414.cisco.com><430FC6BDED356B4C8498F634416644A92694381E9F@mail><4C729FEF.6020509@cisco.com><430FC6BDED356B4C8498F634416644A92694381F16@mail><4C72C9CA.3070304@cisco.com><430FC6BDED356B4C8498F634416644A92694381FDF@mail><4C72EFCC.2000107@cisco.com><430FC6BDED356B4C8498F634416644A92694382179@mail> <4C73EA66.4000305@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851B8637@ESESSCMS0356.eemea.ericsson.se> <4C7413D9.80804@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851B8650@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05851B8652@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C6538049202036C3F6D@XMB-BGL-414.cisco.com> <7F2 072F1E0DE894DA4B517B93C6A05851B8654@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1081) Cc: DISPATCH list Subject: Re: [dispatch] I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Oct 2010 14:08:59 -0000 Uh, same as Paul, sorry, ignore my previous email. Don't know how I = missed this on first search. Thank you for sending the pointer to this.=20= What is the sate of this 3GPP doc and what is going on with the = registration? Thanks, Cullen On Aug 24, 2010, at 9:57 PM, Christer Holmberg wrote: >=20 > Hi, >=20 > The package definition can be found in Annex P of 3GPP TS 24.229: >=20 > http://www.3gpp.org/ftp/Specs/archive/24_series/24.229/24229-a00.zip >=20 > The MIME body used by the package to transport the digits is defined = in Annex G of 3GPP TS 29.163 (it re-uses a body used for overlap = dialling, in case the wording confuses):=20 >=20 > http://www.3gpp.org/ftp/Specs/archive/29_series/29.163/29163-920.zip >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >> -----Original Message----- >> From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com]=20= >> Sent: 25. elokuuta 2010 6:47 >> To: Christer Holmberg; Parthasarathi R (partr); Paul Kyzivat=20 >> (pkyzivat) >> Cc: dispatch@ietf.org; Hadriel Kaplan >> Subject: RE:=20 >> [dispatch]I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt >>=20 >> Can you please provide the pointer to the 3GPP spec=20 >> describing this DTMF INFO package? >>=20 >> thanks, >> Muthu >>=20 >> |-----Original Message----- >> |From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> |Sent: Wednesday, August 25, 2010 9:05 AM >> |To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat) >> |Cc: dispatch@ietf.org; Hadriel Kaplan; Muthu ArulMozhi Perumal >> (mperumal) >> |Subject: RE: >> [dispatch]I-DAction:draft-kaplan-dispatch-info-dtmf-package- >> |00.txt >> | >> | >> |Hi, >> | >> |>1) whether 3GPP DTMF Info package is in the state to be accepted as >> IETF >> |standards. >> | >> |The Info Package registration procedure requires an expert review, >> which >> |purpose is to ensure that the Info Package does not break the SIP >> protocol >> |etc. I assume such review will take place when the package is >> registered >> |with IANA. >> | >> |Regards, >> | >> |Christer >> | >> | >> | >> | >> |________________________________ >> | >> | From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> | Sent: Wed 8/25/2010 8:45 AM >> | To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat) >> | Cc: dispatch@ietf.org; Hadriel Kaplan; Muthu ArulMozhi Perumal >> |(mperumal) >> | Subject: RE: >> [dispatch]I-DAction:draft-kaplan-dispatch-info-dtmf- >> |package-00.txt >> | >> | >> | >> | >> | Hi, >> | >> | >In case IMS needs new INFO based DTMF relay mechanism, I agree >> that >> |it is the valid requirement and we need to evaluate it. Before >> concluding >> |about new >> | >INFO based mechanism in IMS, Please throw the light for not >> selecting >> |KPML in IMS. I'm comparing KPML vs INFO based mechanism as both are >> based on >> |SIP >> | >signaling based mechanism. KPML has limited deployment as >> mentioned >> |in Hadriel Info draft but new INFO package is yet to be=20 >> defined. It is=20 >> |better to have >> | >the single active IETF SIP signaling based dtmf-relay=20 >> mechanism=20 >> |rather than producing more standards wherein implementers will >> completely >> |confused which >> | >one to select. >> | > >> | >As Muthu mentioned, I also heard about KPML deployment issues >> but the >> |legacy INFO based dtmf-relay has lot more caveats. I guess that Info >> package >> |is >> | >designed as generic as KPML, and then both KPML and INFO may >> look >> |heavyweight. >> | >> | The 3GPP DTMF Info Package is very simple. >> | >> | Regards, >> | >> | Christer >> | >> | >> | >> | >> | ________________________________ >> | >> | From: dispatch-bounces@ietf.org on behalf of Paul >> Kyzivat >> |(pkyzivat) >> | Sent: Wed 8/25/2010 12:17 AM >> | To: Christer Holmberg >> | Cc: dispatch@ietf.org; Hadriel Kaplan >> | Subject: Re: [dispatch]I-D >> Action:draft-kaplan-dispatch-info- >> |dtmf-package-00.txt >> | >> | >> | >> | >> | >> | Christer Holmberg wrote: >> | > Hi, >> | > >> | > I think it is strange to reject something based on a >> claim >> |there already exists a number of legacy ways of there. Not=20 >> everyone has=20 >> |implemented the same (if any) of them, and the whole purpose of the >> Info >> |Package framework is to come up with a mechanism for which the usage >> can be >> |negotiated. >> | > >> | > And, as I said earlier, at least in IMS an Info >> Package is >> |being used for DTMF transport. It is currently defined in 3GPP=20 >> |specifications, but there shouldn't be anything IMS specific=20 >> about the=20 >> |package itself. >> | >> | I wasn't asserting a general principle. >> | I was talking about this particular mechanism. >> | >> | If there is yet another dtmf package, then I guess we >> can >> |consider the >> | pros/cons of it. Those are probably best assessed by >> those who >> |use the >> | existing one and/or might use whatever info package you >> might >> |propose to >> | replace it. >> | >> | We clearly suffer from a surplus of ways to convey dtmf. >> | While its not impossible to argue than another=20 >> one would=20 >> |improve the >> | situation, it is going to be a hard sell. >> | >> | OTOH, the more there are the more case it makes for >> having an >> |SBC in the >> | path to "fix" the interoperability. We sell them, so >> maybe I >> |should be >> | cheering on every new one as a way to boost sales. >> | >> | Thanks, >> | Paul >> | >> | > Regards, >> | > >> | > Christer >> | > >> | > >> | > >> | >> -----Original Message----- >> | >> From: dispatch-bounces@ietf.org >> | >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul=20= >> |Kyzivat >> | >> Sent: 24. elokuuta 2010 18:51 >> | >> To: Hadriel Kaplan >> | >> Cc: dispatch@ietf.org >> | >> Subject: Re: [dispatch] I-D >> | >> Action:draft-kaplan-dispatch-info-dtmf-package-00.txt >> | >> >> | >> Maybe we should ask our ADs if they have an opinion >> about >> |this. >> | >> >> | >> Thanks, >> | >> Paul >> | >> >> | >> Hadriel Kaplan wrote: >> | >>>> -----Original Message----- >> | >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> | >>>> Sent: Monday, August 23, 2010 6:02 PM >> | >>>> To: Hadriel Kaplan >> | >>>> >> | >>>> That reduces things somewhat. But if=20 >> everybody that=20 >> |supports the >> | >>>> package also supports the legacy approach, what is >> the >> |win? >> | >>> The legacy mode has no published standards document >> | >> defining it. I thought when the info-packages work >> was >> | >> started, DTMF-in-info was one of the main drivers. >> But I >> | >> take your point - if people would prefer to just >> document >> |it >> | >> as it is today (sans info-packages), I can change the >> draft >> | >> to just be that. I'm cool with either way (defining >> the >> | >> current dtmf-relay as a legacy mode was Option-2). >> | >>> -hadriel >> | >>> >> | >> _______________________________________________ >> | >> 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 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From magnus.westerlund@ericsson.com Sun Oct 24 03:53:16 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B6A33A67D7 for ; Sun, 24 Oct 2010 03:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.573 X-Spam-Level: X-Spam-Status: No, score=-106.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVszHuCWp-aA for ; Sun, 24 Oct 2010 03:53:15 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 874D53A6403 for ; Sun, 24 Oct 2010 03:53:14 -0700 (PDT) X-AuditID: c1b4fb39-b7b54ae000003464-9d-4cc4107f7eda Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id FC.C0.13412.F7014CC4; Sun, 24 Oct 2010 12:54:55 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 24 Oct 2010 12:54:47 +0200 Received: from [153.88.46.45] ([153.88.46.45]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 24 Oct 2010 12:54:46 +0200 Message-ID: <4CC41076.8080100@ericsson.com> Date: Sun, 24 Oct 2010 12:54:46 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: "Allyn Romanow (allyn)" References: <4CB466D5.8060601@ericsson.com> <4CB577AF.3070903@ericsson.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02B01E5F@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02B01E5F@xmb-sjc-221.amer.cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 24 Oct 2010 10:54:46.0989 (UTC) FILETIME=[DF92C7D0:01CB7369] X-Brightmail-Tracker: AAAAAA== Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comments on the proposed Telepresence Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2010 10:53:17 -0000 Hi Allyn, That way of getting it into the charter is fine with me. Magnus Allyn Romanow (allyn) skrev 2010-10-15 01:23: > Hi Magnus, > You have made some very helpful points. In particular you've pointed out that the charter talks about the receiver's ability to respond, but not the sender's. Also the charter is not explicit about necessary discussion of Telepresence interoperability issues that are not within the charter of the multi-stream WG to do anything about. > > I'd like to propose some wording in the charter that I think will address your concerns. See what you think- some of the wording is yours :).. > > Instead of > > The WG will create specifications for SIP-based conferencing systems to enable communication of enough information about each media stream so that each receiving system or bridge system can make reasonable decisions about selecting and rendering media streams. This enables systems to make display choices that optimize the "just like being there" experience. > I propose > The WG will create specifications for SIP-based conferencing systems to enable communication of enough information about each media stream so that each sending system, receiving system, or bridge system can make reasonable decisions about transmitting, selecting, and rendering media streams. This enables systems to make choices that optimize the "just like being there" experience. > > I would not like to change: > * Which sources a receiver wants to receive. For example, it might want the source for the left camera, or might want the source chosen by VAD (Voice Activity Detection). > To the proposed: > * Which sources a receiver wants transmitted. For example, it might want the source for the left camera, or might want the source chosen by VAD (Voice Activity Detection). > > Because there are multiple receivers. A receiver cannot say what should be transmitted, it can only say what itself wants to get, or receive. But I think your concern about sender behavior is covered by the changes to the paragraph above. > > I also propose the following addition: > This working group is not currently chartered to work on issues of continuous conference control including: far end camera control, indication of fast frame update for video codecs or other rapid switches, floor control, conference roster. The working group may identify interoperability obstacles in existing openstandards. If so, the WG will develp requirements to be communicated to other IETF WGs or Standards Forums as a kind request to try to meet these requirements. > > What do you think? > > Best regards, > Allyn > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Magnus Westerlund > Sent: Wednesday, October 13, 2010 2:11 AM > To: Peter Musgrave > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Comments on the proposed Telepresence Charter > > Hi Peter, > > Good that we are in agreement on a number of things. Response and > clarifications inline. > > Peter Musgrave skrev 2010-10-12 17:37: >>> >>> Independent if one uses a central mixer or a full mesh there appears to >>> be a lack in media stream negotiation for how to negotiate what >>> capabilities the receiving client has in receiving, decoding and >>> rendering when it comes to number of simultaneous streams. Our >>> understanding is that RTP mandates any number of streams, while in >>> reality outside of conferencing that is in fact one single stream. >>> However with telepresence and conferencing there is a need to negotiate >>> the actual capability, especially between a mixer and client when it >>> comes to deliver multiple streams for various usages. > >> Agreed. The charter does speak to identifying endpoint capabilities >> and I view what you describe here as the kind of meta-information >> which needs to fit into that framework. > > Okay, as long as this is included in the thinking about capabilities I > am fine. However, the charter proposal isn't particular detailed in this > regards. But I guess the following charter text is matching this: > > "Information between sources and sinks about media stream capabilities > will be exchanged." > >>> >>> We also think there is missing functionality for expressing who are the >>> currently active speakers. The RTP CSRC field are not sufficient as they >>> express which end-points are included in the mix. However, as one likely >>> include in a mix more rooms than the active speakers to ensure that any >>> interruption and ambient sound are correctly captured an mechanism for >>> indicating the currently active speakers are needed. There is also need >>> to agree on the type of identifier to be used that allow for mapping to >>> full user names when appropriate. > >> I agree with this. In my opinion this is a separable problem since it >> applies to generic audio conferencing as well. There is tangential >> work in the conference event package and probably in the XCON stuff - >> but I lack detailed background in XCON. >> >> In the context of the TP charter I think the work on indicating which >> audio stream is associated with which speaker (or part of the room) is >> a slightly different issue - since it's about which stream and not >> which speaker within a stream. > > I should probably have been clearer. I am concerned that even on media > stream level there is missing functionality to indicate which streams > that contains active speakers and has been included in a mix produced by > the mixer. From our side we see a difference between being included in > the mix and being tagged as currently an active speaker. > > I think this is currently missing functionality for which requirements > needs to be agreed on and then a solution developed. However, the > solution might better fit another WG, like AVT. But I think that is for > later determination. I think the requirements phase makes sense to have > in the Telepresence group. > > I do agree that such functionality do have a wider usage scope than just > telepresence and can be used in any case of centralized mixers where > special activity needs to be pointed out, with audio being the foremost > example of such media. > >> >>> >>> The charter includes an item to work on control between client and a >>> mixer what streams should be delivered. We would like to extended this >>> to allow also the mixer to control the client on when streams are >>> delivered. In cases where there are more users then available display >>> area and a particular user is not actually included in any outgoing >>> mix/selection from the mixer then there is little point in that the >>> client consumes network resources. Thus we suggest that the stream >>> selection and control work is extended to allow also the mixer to pause >>> individual streams from the client to the mixer. Please note that such >>> control needs to be responsive, thus using the SIP signaling path for >>> this is to slow, it needs to be on the media path. >> I concur. >> >> The charter sentence: >> "The WG will create specifications for SIP-based conferencing systems >> to enable communication of enough information about each media stream >> so that each receiving system or bridge system can make reasonable >> decisions about selecting and rendering media streams. This enables >> systems to make display choices that optimize the "just like being >> there" experience. " >> >> is specific to selection of streams and not to the ability to control >> them. I don't see anything here which prevents a source from not >> sending selected streams - but I have no objection to making this more >> explicit. How about adding: >> >> "Selection choices will be communicated to the sending party to allow >> the sender to optionally present information on which streams are in >> use and to optionally suspend streams which are not in use." ?? >> > > When I wrote the above comment I was mostly considering the following > chart text bullet: > > * Which sources a receiver wants to receive. For example, it might want > the source for the left camera, or might want the source chosen by VAD > (Voice Activity Detection). > > I think your proposed text combined with the above bullet gives all the > room I see needed for media stream control. However, maybe a > modification of the above to make it clear. > > * Which sources a receiver or mixer wants to have transmitted. For > example, it might want the source for the left camera, or might want the > source chosen by VAD (Voice Activity Detection). > >> >>> >>> Another question to the group is, are there agreement on how streams >>> should organized into RTP sessions and how they are utilized? If >>> anything is documented I would appreciate a pointer. The media streams >>> are for different purposes from different end-points which are then >>> mixed by a central point and delivered to end-points. My impression for >>> example is that most proprietary system breaks the RTP semantics and use >>> individual sessions between the mixer and each end-point, instead of a >>> joint session. Here also different robustification tools for RTP such as >>> FEC and Retransmission needs to be considered. This might be work that >>> belongs in AVT, but are there need for further clarification into this >>> field? > >> I think this is something which will have to be thought through and >> standardized if TP interoperability is to succeed. I would view the >> semantics of how the streams are assigned in scope and the "plumbing" >> either comes from the AVT/MMUSIC media cap stuff or any additions are >> developed in those WGs. >> > > I agree with that the right place to do specification work is likely > these two groups. However, I think telepresence needs to provide > requirements for such work. Making such requirement development explicit > in the charter would make it clear that we do expect work to happen > somewhere else. At the same time it is after all possible to request > that another WG's charter is updated to cover such work. > > The WG may identify interoperability obstacles in existing open > standards. The WG may develop requirements to be communicated to other > IETF WGs or Standards Forums as a kind request to try to meet these > requirements. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Sun Oct 24 04:02:21 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97EB43A6802 for ; Sun, 24 Oct 2010 04:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.577 X-Spam-Level: X-Spam-Status: No, score=-106.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTlyXc+QPzsu for ; Sun, 24 Oct 2010 04:02:20 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 670363A67D7 for ; Sun, 24 Oct 2010 04:02:18 -0700 (PDT) X-AuditID: c1b4fb39-b7b54ae000003464-1b-4cc412a0fcd9 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 81.31.13412.0A214CC4; Sun, 24 Oct 2010 13:04:01 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 24 Oct 2010 13:03:52 +0200 Received: from [153.88.46.45] ([153.88.46.45]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 24 Oct 2010 13:03:52 +0200 Message-ID: <4CC41297.5090204@ericsson.com> Date: Sun, 24 Oct 2010 13:03:51 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: Peter Musgrave References: <4CB466D5.8060601@ericsson.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02A47987@xmb-sjc-221.amer.cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 24 Oct 2010 11:03:52.0070 (UTC) FILETIME=[24778A60:01CB736B] X-Brightmail-Tracker: AAAAAA== Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comments on the proposed Telepresence Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2010 11:02:21 -0000 Hi, Sorry for the delay in responding. When it comes to controlling the mix, that is clearly a dynamic control. A user must be able to basically click or select a particular user as the one it currently finds most important, and then at some point later do another selection or go back to letting the mixer do the selection based on activity. I don't know the background to the charter paragraph: This working group is not currently chartered to work on issues of continuous conference control including: far end camera control, indication of fast frame update for video codecs or other rapid switches, floor control, conference roster. But, I guess what I believe is needed will fall under the part of continuous conference control. I don't see the SIP signalling path work as this is something that has the potential for being updated often during a session's duration, and also should be quickly responsive. If we can't change the charter to perform work on stream selection in mixers, then can the Telepresence group at least work on requirements that can be thrown over the wall to some other WG? I also think we need to have some discussion where this would be appropriate, or if even a new WG is needed for that topic. I know that we within Ericsson has been discussing something that is an extension to BFCP. Cheers Magnus Peter Musgrave skrev 2010-10-14 16:54: > Hi Mike, > > I agree the onhld/offhold analogy is a poor one. It is a suspension of > a call - which is not intended. > > Let me re-phrase and see if we agree: > > A sends B three video streams and one audio stream . > B has one display and opts to display one of the three streams. > There is a mechanism for B to tell A that this has happened (and to > say when it wishes to display some other stream from A). > > Do we think that the work to do this type of stream-suspension is > floor control? (My opinion is no. I view floor control more as who is > the source for a given stream and not a selection of an agreed upon > stream). > > Do we think this work is in scope for Telepresence Interoperability? I > think this is an essential element to deployable TP operation > especially as in expands to "at home" use. If an architecture in which > a room sends all video all the time (even though it's not being used) > is viewed as necessary to avoid complexity/meet responsiveness > requirements is thought to be ok then I'd like to make sure we are > clear that that these limitations exist upfront. > > My preference is obviously to permit this feedback and tweak the > proposed charter. > > Other opinions? > > Regards, > > > Peter Musgrave > > On Thu, Oct 14, 2010 at 9:46 AM, Mike Hammer (hmmr) wrote: >> Peter, >> >> I have not issue with your proposed words, since they are essentially asking for a "mute" button for all types of communications used by a sender. This may complicate the algorithm for all the receive systems to know what to display, if for example, you continue to speak, but turn off the video transmission. A "mute all" option might be more polite. >> >> I did have issue with this comment: "more like onhold/offhold type negotiation" >> >> I am not sure I would agree with this. >> >> There needs to be a distinction between when a call starts and when a call stops, the call being *all* communications (sessions) between two points. Granted putting a call on hold seems like floor control, but the participants of the call on hold are effectively out of the call (left the room) until brought off-hold. This is SIP level action. >> >> There needs to be a clear distinction between negotiating capabilities, aka knowing what capabilities an endpoint has, and using those capabilities during a call. That learning process is done via SDP. >> >> The latter part seems to be floor control, continuous conference control, or whatever you want to call it. There seems to be splitting of hairs over whether the floor control is manual or automatic (determined by the loudest speaker). This may be AVT. >> >> In summary, you have room access, you define capabilities, you have "speaker" conflict resolution control. (Note, point-to-point calls are devolution since resolution of conflict is a non-problem with only one opposing party.) >> >> Did I miss some other nuance? >> >> Mike >> >> >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Peter Musgrave >> Sent: Thursday, October 14, 2010 5:25 AM >> To: Allyn Romanow (allyn) >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] Comments on the proposed Telepresence Charter >> >> HI Allyn/Magnus, >> >> W.R.T >> >> "[AR} I agree with your point that it would be good to pause the >> sender, but I think that falls >> under the category of "continuous conference control" which is out of >> the scope of this charter. >> Such a feedback mechanism falls probably under AVT. >> I think it would be good to add a sentence saying something like, As >> control issues >> necessary for interoperability arise, they will be directed appropriately. >> What do you think?" >> >> I think these words leave room to *not* do what Magnus is suggesting. >> e.g. If I have a 1 screen home TP system getting three streams from a >> 3 camera system and selecting only one it is not really "necessary" to >> tell the 3 camera system to pause two streams - but it is a really >> good idea to have a way to that! I don't view this is a continuous >> conference control issue (since that gets into floor control which I >> agree is out of scope) but more like onhold/offhold type negotiation. >> I think this is to some extent a plumbing issue (and based on the >> desired response time SIP or media path messages will be required). >> >> So I would still like to see a statement which makes it clear that it >> not just an issue of receiver selection but there is a need to >> communicate that selection back to the sender. The current text does >> not say this. Hence my suggestion: >> >> "Selection choices will be communicated to the sending party to allow >> the sender to optionally present information on which streams are in >> use and to optionally suspend streams which are not in use." ?? >> >> I'm open to other words or some indication of which language in the >> current charter ensures this is in scope. >> >> Regards, >> >> Peter Musgrave >> >> >> >> >> On Wed, Oct 13, 2010 at 12:47 PM, Allyn Romanow (allyn) wrote: >>> Hi Magnus, >>> I was really glad that you had a chance to carefully consider the proposed work. >>> Like Peter, I too agree with most of your comments. >>> Specific points below. >>> >>> Best regards, >>> Allyn >>> >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Magnus Westerlund >>> Sent: Tuesday, October 12, 2010 6:47 AM >>> To: dispatch@ietf.org >>> Subject: [dispatch] Comments on the proposed Telepresence Charter >>> >>> Hi, >>> >>> Some colleagues and I have reviewed the two telepresence drafts and >>> version 5 of the charter and have some comments on the charter. >>> >>> To make our comments more understandable I think we should explain our >>> view on telepresence. First we are expecting great variations in the >>> capabilities of the participating terminals in a session. From personal >>> terminals for individual users up to multi-display, cameras and >>> microphone setups. We also expect that more than two end-points being >>> present in the same session. As we see it it will require good support >>> for centralized media handling in a mixer (MCU). We also see video >>> streams not only of high quality to be presented for maximum immersion, >>> but also lower qualities that can be used to monitor activity in other >>> rooms that aren't the ones selected for high quality. >>> >>> [AR] Yes, absolutely. >>> >>> Independent if one uses a central mixer or a full mesh there appears to >>> be a lack in media stream negotiation for how to negotiate what >>> capabilities the receiving client has in receiving, decoding and >>> rendering when it comes to number of simultaneous streams. Our >>> understanding is that RTP mandates any number of streams, while in >>> reality outside of conferencing that is in fact one single stream. >>> However with telepresence and conferencing there is a need to negotiate >>> the actual capability, especially between a mixer and client when it >>> comes to deliver multiple streams for various usages. >>> >>> [AR] Yes, agree - as you saw, this is covered in the charter. >>> >>> We also think there is missing functionality for expressing who are the >>> currently active speakers. The RTP CSRC field are not sufficient as they >>> express which end-points are included in the mix. However, as one likely >>> include in a mix more rooms than the active speakers to ensure that any >>> interruption and ambient sound are correctly captured an mechanism for >>> indicating the currently active speakers are needed. There is also need >>> to agree on the type of identifier to be used that allow for mapping to >>> full user names when appropriate. >>> >>> [AR] Yes.. Both of these points are covered in the charter too, right? >>> >>> The charter includes an item to work on control between client and a >>> mixer what streams should be delivered. We would like to extended this >>> to allow also the mixer to control the client on when streams are >>> delivered. In cases where there are more users then available display >>> area and a particular user is not actually included in any outgoing >>> mix/selection from the mixer then there is little point in that the >>> client consumes network resources. Thus we suggest that the stream >>> selection and control work is extended to allow also the mixer to pause >>> individual streams from the client to the mixer. Please note that such >>> control needs to be responsive, thus using the SIP signaling path for >>> this is to slow, it needs to be on the media path. >>> >>> [AR} I agree with your point that it would be good to pause the sender, but I think that falls >>> under the category of "continuous conference control" which is out of the scope of this charter. >>> Such a feedback mechanism falls probably under AVT. >>> I think it would be good to add a sentence saying something like, As control issues >>> necessary for interoperability arise, they will be directed appropriately. >>> What do you think? >>> >>> >>> Another question to the group is, are there agreement on how streams >>> should organized into RTP sessions and how they are utilized? If >>> anything is documented I would appreciate a pointer. The media streams >>> are for different purposes from different end-points which are then >>> mixed by a central point and delivered to end-points. My impression for >>> example is that most proprietary system breaks the RTP semantics and use >>> individual sessions between the mixer and each end-point, instead of a >>> joint session. Here also different robustification tools for RTP such as >>> FEC and Retransmission needs to be considered. This might be work that >>> belongs in AVT, but are there need for further clarification into this >>> field? >>> >>> [AR} Agree this needs to be worked out for Telepresence, and that any activity about it would go to AVT and/or MMUSIC. >>> >>> Comments much appreciated and we can gladly suggest text additions to >>> the charter proposal. >>> >>> Cheers >>> >>> Magnus Westerlund >>> >>> ---------------------------------------------------------------------- >>> Multimedia Technologies, Ericsson Research EAB/TVM >>> ---------------------------------------------------------------------- >>> Ericsson AB | Phone +46 10 7148287 >>> Färögatan 6 | Mobile +46 73 0949079 >>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >>> ---------------------------------------------------------------------- >>> _______________________________________________ >>> 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 >>> >> _______________________________________________ >> 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 > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From peter.musgrave@magorcorp.com Sun Oct 24 04:30:15 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C20573A6843 for ; Sun, 24 Oct 2010 04:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.854 X-Spam-Level: X-Spam-Status: No, score=-101.854 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Syn8fcIky49Z for ; Sun, 24 Oct 2010 04:30:12 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id D82B03A682C for ; Sun, 24 Oct 2010 04:30:01 -0700 (PDT) Received: by qwb7 with SMTP id 7so671928qwb.31 for ; Sun, 24 Oct 2010 04:31:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.220.11 with SMTP id hw11mr4707274qcb.218.1287919902662; Sun, 24 Oct 2010 04:31:42 -0700 (PDT) Received: by 10.229.225.207 with HTTP; Sun, 24 Oct 2010 04:31:42 -0700 (PDT) In-Reply-To: <4CC41297.5090204@ericsson.com> References: <4CB466D5.8060601@ericsson.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02A47987@xmb-sjc-221.amer.cisco.com> <4CC41297.5090204@ericsson.com> Date: Sun, 24 Oct 2010 07:31:42 -0400 Message-ID: From: Peter Musgrave To: Magnus Westerlund Content-Type: multipart/alternative; boundary=0016363b83f84c21f904935b38fb Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comments on the proposed Telepresence Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2010 11:30:15 -0000 --0016363b83f84c21f904935b38fb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Magnus/Mike: Allyn had previously proposed: " also propose the following addition: This working group is not currently chartered to work on issues of continuous conference control including: far end camera control, indication of fast frame update for video codecs or other rapid switches= , floor control, conference roster. The working group may identify interoperability obstacles in existing open standards. If so, the WG will develp requirements to be communicated to other IETF WGs or Standard= s Forums as a kind request to try to meet these requirements. " Here the "..will define requirements..." applies to interoperability obstacles. I would regard a single panel system having a way of determinin= g dynamically which video stream it gets from a multi-video source as an interoperability issue. Hence I would view this as "in scope". I agree that on-demand media source selection will be a critical requirement. Personally, I view it as quite different from floor control so I'm not sure I'd start with BFCP - but I think that discussion makes more sense when the requirements have been well defined. Regards, Peter Musgrave On Sun, Oct 24, 2010 at 7:03 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > > Sorry for the delay in responding. > > When it comes to controlling the mix, that is clearly a dynamic control. > A user must be able to basically click or select a particular user as > the one it currently finds most important, and then at some point later > do another selection or go back to letting the mixer do the selection > based on activity. > > I don't know the background to the charter paragraph: > This working group is not currently chartered to work on issues of > continuous conference control including: far end camera control, > indication of fast frame update for video codecs or other rapid > switches, floor control, conference roster. > > But, I guess what I believe is needed will fall under the part of > continuous conference control. I don't see the SIP signalling path work > as this is something that has the potential for being updated often > during a session's duration, and also should be quickly responsive. > > If we can't change the charter to perform work on stream selection in > mixers, then can the Telepresence group at least work on requirements > that can be thrown over the wall to some other WG? I also think we need > to have some discussion where this would be appropriate, or if even a > new WG is needed for that topic. > > I know that we within Ericsson has been discussing something that is an > extension to BFCP. > > Cheers > > Magnus > > Peter Musgrave skrev 2010-10-14 16:54: > > Hi Mike, > > > > I agree the onhld/offhold analogy is a poor one. It is a suspension of > > a call - which is not intended. > > > > Let me re-phrase and see if we agree: > > > > A sends B three video streams and one audio stream . > > B has one display and opts to display one of the three streams. > > There is a mechanism for B to tell A that this has happened (and to > > say when it wishes to display some other stream from A). > > > > Do we think that the work to do this type of stream-suspension is > > floor control? (My opinion is no. I view floor control more as who is > > the source for a given stream and not a selection of an agreed upon > > stream). > > > > Do we think this work is in scope for Telepresence Interoperability? I > > think this is an essential element to deployable TP operation > > especially as in expands to "at home" use. If an architecture in which > > a room sends all video all the time (even though it's not being used) > > is viewed as necessary to avoid complexity/meet responsiveness > > requirements is thought to be ok then I'd like to make sure we are > > clear that that these limitations exist upfront. > > > > My preference is obviously to permit this feedback and tweak the > > proposed charter. > > > > Other opinions? > > > > Regards, > > > > > > Peter Musgrave > > > > On Thu, Oct 14, 2010 at 9:46 AM, Mike Hammer (hmmr) > wrote: > >> Peter, > >> > >> I have not issue with your proposed words, since they are essentially > asking for a "mute" button for all types of communications used by a send= er. > This may complicate the algorithm for all the receive systems to know wh= at > to display, if for example, you continue to speak, but turn off the video > transmission. A "mute all" option might be more polite. > >> > >> I did have issue with this comment: "more like onhold/offhold type > negotiation" > >> > >> I am not sure I would agree with this. > >> > >> There needs to be a distinction between when a call starts and when a > call stops, the call being *all* communications (sessions) between two > points. Granted putting a call on hold seems like floor control, but the > participants of the call on hold are effectively out of the call (left th= e > room) until brought off-hold. This is SIP level action. > >> > >> There needs to be a clear distinction between negotiating capabilities= , > aka knowing what capabilities an endpoint has, and using those capabiliti= es > during a call. That learning process is done via SDP. > >> > >> The latter part seems to be floor control, continuous conference > control, or whatever you want to call it. There seems to be splitting of > hairs over whether the floor control is manual or automatic (determined b= y > the loudest speaker). This may be AVT. > >> > >> In summary, you have room access, you define capabilities, you have > "speaker" conflict resolution control. (Note, point-to-point calls are > devolution since resolution of conflict is a non-problem with only one > opposing party.) > >> > >> Did I miss some other nuance? > >> > >> Mike > >> > >> > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Peter Musgrave > >> Sent: Thursday, October 14, 2010 5:25 AM > >> To: Allyn Romanow (allyn) > >> Cc: dispatch@ietf.org > >> Subject: Re: [dispatch] Comments on the proposed Telepresence Charter > >> > >> HI Allyn/Magnus, > >> > >> W.R.T > >> > >> "[AR} I agree with your point that it would be good to pause the > >> sender, but I think that falls > >> under the category of "continuous conference control" which is out of > >> the scope of this charter. > >> Such a feedback mechanism falls probably under AVT. > >> I think it would be good to add a sentence saying something like, As > >> control issues > >> necessary for interoperability arise, they will be directed > appropriately. > >> What do you think?" > >> > >> I think these words leave room to *not* do what Magnus is suggesting. > >> e.g. If I have a 1 screen home TP system getting three streams from a > >> 3 camera system and selecting only one it is not really "necessary" to > >> tell the 3 camera system to pause two streams - but it is a really > >> good idea to have a way to that! I don't view this is a continuous > >> conference control issue (since that gets into floor control which I > >> agree is out of scope) but more like onhold/offhold type negotiation. > >> I think this is to some extent a plumbing issue (and based on the > >> desired response time SIP or media path messages will be required). > >> > >> So I would still like to see a statement which makes it clear that it > >> not just an issue of receiver selection but there is a need to > >> communicate that selection back to the sender. The current text does > >> not say this. Hence my suggestion: > >> > >> "Selection choices will be communicated to the sending party to allow > >> the sender to optionally present information on which streams are in > >> use and to optionally suspend streams which are not in use." ?? > >> > >> I'm open to other words or some indication of which language in the > >> current charter ensures this is in scope. > >> > >> Regards, > >> > >> Peter Musgrave > >> > >> > >> > >> > >> On Wed, Oct 13, 2010 at 12:47 PM, Allyn Romanow (allyn) < > allyn@cisco.com> wrote: > >>> Hi Magnus, > >>> I was really glad that you had a chance to carefully consider the > proposed work. > >>> Like Peter, I too agree with most of your comments. > >>> Specific points below. > >>> > >>> Best regards, > >>> Allyn > >>> > >>> -----Original Message----- > >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Magnus Westerlund > >>> Sent: Tuesday, October 12, 2010 6:47 AM > >>> To: dispatch@ietf.org > >>> Subject: [dispatch] Comments on the proposed Telepresence Charter > >>> > >>> Hi, > >>> > >>> Some colleagues and I have reviewed the two telepresence drafts and > >>> version 5 of the charter and have some comments on the charter. > >>> > >>> To make our comments more understandable I think we should explain ou= r > >>> view on telepresence. First we are expecting great variations in the > >>> capabilities of the participating terminals in a session. From person= al > >>> terminals for individual users up to multi-display, cameras and > >>> microphone setups. We also expect that more than two end-points being > >>> present in the same session. As we see it it will require good suppor= t > >>> for centralized media handling in a mixer (MCU). We also see video > >>> streams not only of high quality to be presented for maximum immersio= n, > >>> but also lower qualities that can be used to monitor activity in othe= r > >>> rooms that aren't the ones selected for high quality. > >>> > >>> [AR] Yes, absolutely. > >>> > >>> Independent if one uses a central mixer or a full mesh there appears = to > >>> be a lack in media stream negotiation for how to negotiate what > >>> capabilities the receiving client has in receiving, decoding and > >>> rendering when it comes to number of simultaneous streams. Our > >>> understanding is that RTP mandates any number of streams, while in > >>> reality outside of conferencing that is in fact one single stream. > >>> However with telepresence and conferencing there is a need to negotia= te > >>> the actual capability, especially between a mixer and client when it > >>> comes to deliver multiple streams for various usages. > >>> > >>> [AR] Yes, agree - as you saw, this is covered in the charter. > >>> > >>> We also think there is missing functionality for expressing who are t= he > >>> currently active speakers. The RTP CSRC field are not sufficient as > they > >>> express which end-points are included in the mix. However, as one > likely > >>> include in a mix more rooms than the active speakers to ensure that a= ny > >>> interruption and ambient sound are correctly captured an mechanism fo= r > >>> indicating the currently active speakers are needed. There is also ne= ed > >>> to agree on the type of identifier to be used that allow for mapping = to > >>> full user names when appropriate. > >>> > >>> [AR] Yes.. Both of these points are covered in the charter too, right= ? > >>> > >>> The charter includes an item to work on control between client and a > >>> mixer what streams should be delivered. We would like to extended thi= s > >>> to allow also the mixer to control the client on when streams are > >>> delivered. In cases where there are more users then available display > >>> area and a particular user is not actually included in any outgoing > >>> mix/selection from the mixer then there is little point in that the > >>> client consumes network resources. Thus we suggest that the stream > >>> selection and control work is extended to allow also the mixer to pau= se > >>> individual streams from the client to the mixer. Please note that suc= h > >>> control needs to be responsive, thus using the SIP signaling path for > >>> this is to slow, it needs to be on the media path. > >>> > >>> [AR} I agree with your point that it would be good to pause the sende= r, > but I think that falls > >>> under the category of "continuous conference control" which is out o= f > the scope of this charter. > >>> Such a feedback mechanism falls probably under AVT. > >>> I think it would be good to add a sentence saying something like, As > control issues > >>> necessary for interoperability arise, they will be directed > appropriately. > >>> What do you think? > >>> > >>> > >>> Another question to the group is, are there agreement on how streams > >>> should organized into RTP sessions and how they are utilized? If > >>> anything is documented I would appreciate a pointer. The media stream= s > >>> are for different purposes from different end-points which are then > >>> mixed by a central point and delivered to end-points. My impression f= or > >>> example is that most proprietary system breaks the RTP semantics and > use > >>> individual sessions between the mixer and each end-point, instead of = a > >>> joint session. Here also different robustification tools for RTP such > as > >>> FEC and Retransmission needs to be considered. This might be work tha= t > >>> belongs in AVT, but are there need for further clarification into thi= s > >>> field? > >>> > >>> [AR} Agree this needs to be worked out for Telepresence, and that any > activity about it would go to AVT and/or MMUSIC. > >>> > >>> Comments much appreciated and we can gladly suggest text additions to > >>> the charter proposal. > >>> > >>> Cheers > >>> > >>> Magnus Westerlund > >>> > >>> ---------------------------------------------------------------------= - > >>> Multimedia Technologies, Ericsson Research EAB/TVM > >>> ---------------------------------------------------------------------= - > >>> Ericsson AB | Phone +46 10 7148287 > >>> F=E4r=F6gatan 6 | Mobile +46 73 0949079 > >>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > >>> ---------------------------------------------------------------------= - > >>> _______________________________________________ > >>> 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 > >>> > >> _______________________________________________ > >> 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 > > > > > -- > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > --0016363b83f84c21f904935b38fb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Magnus/Mike:

Allyn had previously proposed:
"=A0also propose the fol= lowing addition:
=A0 =A0 =A0 =A0This working group is not currently chartered to work on iss= ues of continuous conference =A0 =A0 =A0 =A0control including: far end came= ra control, indication of fast frame update for video =A0 =A0codecs or othe= r rapid switches, floor control, conference roster. The working group may i= dentify interoperability obstacles in existing open standards. If so, the W= G will develp =A0 =A0 =A0 =A0requirements to be communicated to other IETF = WGs or Standards Forums as a kind request to try to meet these requirements= .
"

Here the "..will define require= ments..." applies to interoperability obstacles. =A0I would regard a s= ingle panel system having a way of determining dynamically which video stre= am it gets from a multi-video source as an interoperability issue. Hence I = would view this as "in scope".=A0

I agree that on-demand media source selection will be a= critical requirement. Personally, I view it as quite different from floor = control so I'm not sure I'd start with BFCP - but I think that disc= ussion makes more sense when the requirements have been well defined.=A0

Regards,=A0

Peter Musgrave

On Sun, Oct 24, 2010 at 7:03 AM, Magn= us Westerlund <magnus.westerlund@ericsson.com> wrote:
Hi,

Sorry for the delay in responding.

When it comes to controlling the mix, that is clearly a dynamic control. A user must be able to basically click or select a particular user as
the one it currently finds most important, and then at some point later
do another selection or go back to letting the mixer do the selection
based on activity.

I don't know the background to the charter paragraph:
This working group is not currently chartered to work on = issues of
continuous conference control including: far end camera control,
indication of fast frame update for video codecs or other rapid
switches, floor control, conference roster.

But, I guess what I believe is needed will fall under the part of
continuous conference control. I don't see the SIP signalling path work=
as this is something that has the potential for being updated often
during a session's duration, and also should be quickly responsive.

If we can't change the charter to perform work on stream selection in mixers, then can the Telepresence group at least work on requirements
that can be thrown over the wall to some other WG? I also think we need
to have some discussion where this would be appropriate, or if even a
new WG is needed for that topic.

I know that we within Ericsson has been discussing something that is an
extension to BFCP.

Cheers

Magnus

Peter Musgrave skrev 2010-10-14 16:54:
> Hi Mike,
>
> I agree the onhld/offhold analogy is a poor one. It is a suspension of=
> a call - which is not intended.
>
> Let me re-phrase and see if we agree:
>
> A sends B three video streams and one audio stream .
> B has one display and opts to display one of the three streams.
> There is a mechanism for B to tell A that this has happened (and to > say when it wishes to display some other stream from A).
>
> Do we think that the work to do this type of stream-suspension is
> floor control? (My opinion is no. I view floor control more as who is<= br> > the source for a given stream and not a selection of an agreed upon > stream).
>
> Do we think this work is in scope for Telepresence Interoperability? I=
> think this is an essential element to deployable TP operation
> especially as in expands to "at home" use. If an architectur= e in which
> a room sends all video all the time (even though it's not being us= ed)
> is viewed as necessary to avoid complexity/meet responsiveness
> requirements is thought to be ok then I'd like to make sure we are=
> clear that that these limitations exist upfront.
>
> My preference is obviously to permit this feedback and tweak the
> proposed charter.
>
> Other opinions?
>
> Regards,
>
>
> Peter Musgrave
>
> On Thu, Oct 14, 2010 at 9:46 AM, Mike Hammer (hmmr) <hmmr@cisco.com> wrote:
>> Peter,
>>
>> I have not issue with your proposed words, since they are essentia= lly asking for a "mute" button for all types of communications us= ed by a sender. =A0This may complicate the algorithm for all the receive sy= stems to know what to display, if for example, you continue to speak, but t= urn off the video transmission. =A0A "mute all" option might be m= ore polite.
>>
>> I did have issue with this comment: =A0"more like onhold/offh= old type negotiation"
>>
>> I am not sure I would agree with this.
>>
>> There needs to be a distinction between when a call starts and whe= n a call stops, the call being *all* communications (sessions) between two = points. =A0Granted putting a call on hold seems like floor control, but the= participants of the call on hold are effectively out of the call (left the= room) until brought off-hold. =A0This is SIP level action.
>>
>> There needs to be a clear distinction between negotiating capabili= ties, aka knowing what capabilities an endpoint has, and using those capabi= lities during a call. =A0That learning process is done via SDP.
>>
>> The latter part seems to be floor control, continuous conference c= ontrol, or whatever you want to call it. =A0There seems to be splitting of = hairs over whether the floor control is manual or automatic (determined by = the loudest speaker). =A0This may be AVT.
>>
>> In summary, you have room access, you define capabilities, you hav= e "speaker" conflict resolution control. =A0(Note, point-to-point= calls are devolution since resolution of conflict is a non-problem with on= ly one opposing party.)
>>
>> Did I miss some other nuance?
>>
>> Mike
>>
>>
>> -----Original Message-----
>> From: dispatch-bounce= s@ietf.org [mailto:dispatc= h-bounces@ietf.org] On Behalf Of Peter Musgrave
>> Sent: Thursday, October 14, 2010 5:25 AM
>> To: Allyn Romanow (allyn)
>> Cc: dispatch@ietf.org
>> Subject: Re: [dispatch] Comments on the proposed Telepresence Char= ter
>>
>> HI Allyn/Magnus,
>>
>> W.R.T
>>
>> "[AR} I agree with your point that it would be good to pause = the
>> sender, but I think that falls
>> =A0under the category of "continuous conference control"= which is out of
>> the scope of this charter.
>> =A0Such a feedback mechanism falls probably under AVT.
>> I think it would be good to add a sentence saying something like, = As
>> control issues
>> necessary for interoperability arise, they will be directed approp= riately.
>> What do you think?"
>>
>> I think these words leave room to *not* do what Magnus is suggesti= ng.
>> e.g. If I have a 1 screen home TP system getting three streams fro= m a
>> 3 camera system and selecting only one it is not really "nece= ssary" to
>> tell the 3 camera system to pause two streams - but it is a really=
>> good idea to have a way to that! I don't view this is a contin= uous
>> conference control issue (since that gets into floor control which= I
>> agree is out of scope) but more like onhold/offhold type negotiati= on.
>> I think this is to some extent a plumbing issue (and based on the<= br> >> desired response time SIP or media path messages will be required)= .
>>
>> So I would still like to see a statement which makes it clear that= it
>> not just an issue of receiver selection but there is a need to
>> communicate that selection back to the sender. The current text do= es
>> not say this. Hence my suggestion:
>>
>> "Selection choices will be communicated to the sending party = to allow
>> the sender to optionally present information on which streams are = in
>> use and to optionally suspend streams which are not in use." = ??
>>
>> I'm open to other words or some indication of which language i= n the
>> current charter ensures this is in scope.
>>
>> Regards,
>>
>> Peter Musgrave
>>
>>
>>
>>
>> On Wed, Oct 13, 2010 at 12:47 PM, Allyn Romanow (allyn) <allyn@cisco.com> wrote:
>>> Hi Magnus,
>>> I was really glad that you had a chance to carefully consider = the proposed work.
>>> Like Peter, I too agree with most of your comments.
>>> Specific points below.
>>>
>>> Best regards,
>>> Allyn
>>>
>>> -----Original Message-----
>>> From: dispatch-bo= unces@ietf.org [mailto:dis= patch-bounces@ietf.org] On Behalf Of Magnus Westerlund
>>> Sent: Tuesday, October 12, 2010 6:47 AM
>>> To: dispatch@ietf.org=
>>> Subject: [dispatch] Comments on the proposed Telepresence Char= ter
>>>
>>> Hi,
>>>
>>> Some colleagues and I have reviewed the two telepresence draft= s and
>>> version 5 of the charter and have some comments on the charter= .
>>>
>>> To make our comments more understandable I think we should exp= lain our
>>> view on telepresence. First we are expecting great variations = in the
>>> capabilities of the participating terminals in a session. From= personal
>>> terminals for individual users up to multi-display, cameras an= d
>>> microphone setups. We also expect that more than two end-point= s being
>>> present in the same session. As we see it it will require good= support
>>> for centralized media handling in a mixer (MCU). We also see v= ideo
>>> streams not only of high quality to be presented for maximum i= mmersion,
>>> but also lower qualities that can be used to monitor activity = in other
>>> rooms that aren't the ones selected for high quality.
>>>
>>> [AR] Yes, absolutely.
>>>
>>> Independent if one uses a central mixer or a full mesh there a= ppears to
>>> be a lack in media stream negotiation for how to negotiate wha= t
>>> capabilities the receiving client has in receiving, decoding a= nd
>>> rendering when it comes to number of simultaneous streams. Our=
>>> understanding is that RTP mandates any number of streams, whil= e in
>>> reality outside of conferencing that is in fact one single str= eam.
>>> However with telepresence and conferencing there is a need to = negotiate
>>> the actual capability, especially between a mixer and client w= hen it
>>> comes to deliver multiple streams for various usages.
>>>
>>> [AR] Yes, agree - as you saw, this is covered in the charter.<= br> >>>
>>> We also think there is missing functionality for expressing wh= o are the
>>> currently active speakers. The RTP CSRC field are not sufficie= nt as they
>>> express which end-points are included in the mix. However, as = one likely
>>> include in a mix more rooms than the active speakers to ensure= that any
>>> interruption and ambient sound are correctly captured an mecha= nism for
>>> indicating the currently active speakers are needed. There is = also need
>>> to agree on the type of identifier to be used that allow for m= apping to
>>> full user names when appropriate.
>>>
>>> [AR] Yes.. Both of these points are covered in the charter too= , right?
>>>
>>> The charter includes an item to work on control between client= and a
>>> mixer what streams should be delivered. We would like to exten= ded this
>>> to allow also the mixer to control the client on when streams = are
>>> delivered. In cases where there are more users then available = display
>>> area and a particular user is not actually included in any out= going
>>> mix/selection from the mixer then there is little point in tha= t the
>>> client consumes network resources. Thus we suggest that the st= ream
>>> selection and control work is extended to allow also the mixer= to pause
>>> individual streams from the client to the mixer. Please note t= hat such
>>> control needs to be responsive, thus using the SIP signaling p= ath for
>>> this is to slow, it needs to be on the media path.
>>>
>>> [AR} I agree with your point that it would be good to pause th= e sender, but I think that falls
>>> =A0under the category of "continuous conference control&q= uot; which is out of the scope of this charter.
>>> =A0Such a feedback mechanism falls probably under AVT.
>>> I think it would be good to add a sentence saying something li= ke, As control issues
>>> necessary for interoperability arise, they will be directed ap= propriately.
>>> What do you think?
>>>
>>>
>>> Another question to the group is, are there agreement on how s= treams
>>> should organized into RTP sessions and how they are utilized? = If
>>> anything is documented I would appreciate a pointer. The media= streams
>>> are for different purposes from different end-points which are= then
>>> mixed by a central point and delivered to end-points. My impre= ssion for
>>> example is that most proprietary system breaks the RTP semanti= cs and use
>>> individual sessions between the mixer and each end-point, inst= ead of a
>>> joint session. Here also different robustification tools for R= TP such as
>>> FEC and Retransmission needs to be considered. This might be w= ork that
>>> belongs in AVT, but are there need for further clarification i= nto this
>>> field?
>>>
>>> [AR} Agree this needs to be worked out for Telepresence, and t= hat any activity about it would go to AVT and/or MMUSIC.
>>>
>>> Comments much appreciated and we can gladly suggest text addit= ions to
>>> the charter proposal.
>>>
>>> Cheers
>>>
>>> Magnus Westerlund
>>>
>>> --------------------------------------------------------------= --------
>>> Multimedia Technologies, Ericsson Research EAB/TVM
>>> --------------------------------------------------------------= --------
>>> Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7= 148287
>>> F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73= 0949079
>>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
>>> --------------------------------------------------------------= --------
>>> _______________________________________________
>>> 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
>>>
>> _______________________________________________
>> 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
>


--

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

--0016363b83f84c21f904935b38fb-- From allyn@cisco.com Sun Oct 24 17:22:26 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C23953A67D9 for ; Sun, 24 Oct 2010 17:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.368 X-Spam-Level: X-Spam-Status: No, score=-10.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+eW8-3sZOIf for ; Sun, 24 Oct 2010 17:22:24 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id B625F3A677E for ; Sun, 24 Oct 2010 17:22:24 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADprxEyrRN+K/2dsb2JhbAChXnGfMps1AoJxglUEhFSJBQ X-IronPort-AV: E=Sophos;i="4.58,233,1286150400"; d="scan'208";a="205920675" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 25 Oct 2010 00:24:08 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o9P0O82u028992; Mon, 25 Oct 2010 00:24:08 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 24 Oct 2010 17:24:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 24 Oct 2010 17:24:01 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02BB1882@xmb-sjc-221.amer.cisco.com> In-Reply-To: <4CC41297.5090204@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Comments on the proposed Telepresence Charter Thread-Index: ActzazayGbUpMP9oTRipZDXw3fKQbQAbu4Eg References: <4CB466D5.8060601@ericsson.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02A47987@xmb-sjc-221.amer.cisco.com> <4CC41297.5090204@ericsson.com> From: "Allyn Romanow (allyn)" To: "Magnus Westerlund" , "Peter Musgrave" X-OriginalArrivalTime: 25 Oct 2010 00:24:08.0199 (UTC) FILETIME=[F04F6170:01CB73DA] Cc: dispatch@ietf.org Subject: Re: [dispatch] Comments on the proposed Telepresence Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 00:22:26 -0000 Hi Magnus -=20 I agree with you that the issues you bring up need to be dealt with, and = I feel they should potentially result in requirements from this working = group. With respect in particular to your next to last paragraph below, did you = not think that my proposed change to the charter (as Peter quoted), = covered your concern? "also propose the following addition: This working group is not currently chartered to work on issues = of continuous conference control including: far end camera = control, indication of fast frame update for video codecs or other rapid = switches, floor control, conference roster. The working group may = identify interoperability obstacles in existing open standards. If so, = the WG will develop requirements to be communicated to other IETF = WGs or Standards Forums as a kind request to try to meet these = requirements." Best regards, Allyn -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Magnus Westerlund Sent: Sunday, October 24, 2010 4:04 AM To: Peter Musgrave Cc: dispatch@ietf.org Subject: Re: [dispatch] Comments on the proposed Telepresence Charter Hi, Sorry for the delay in responding. When it comes to controlling the mix, that is clearly a dynamic control. A user must be able to basically click or select a particular user as the one it currently finds most important, and then at some point later do another selection or go back to letting the mixer do the selection based on activity. I don't know the background to the charter paragraph: This working group is not currently chartered to work on issues of continuous conference control including: far end camera control, indication of fast frame update for video codecs or other rapid switches, floor control, conference roster. But, I guess what I believe is needed will fall under the part of continuous conference control. I don't see the SIP signalling path work as this is something that has the potential for being updated often during a session's duration, and also should be quickly responsive. If we can't change the charter to perform work on stream selection in mixers, then can the Telepresence group at least work on requirements that can be thrown over the wall to some other WG? I also think we need to have some discussion where this would be appropriate, or if even a new WG is needed for that topic. I know that we within Ericsson has been discussing something that is an extension to BFCP. Cheers Magnus Peter Musgrave skrev 2010-10-14 16:54: > Hi Mike, >=20 > I agree the onhld/offhold analogy is a poor one. It is a suspension of > a call - which is not intended. >=20 > Let me re-phrase and see if we agree: >=20 > A sends B three video streams and one audio stream . > B has one display and opts to display one of the three streams. > There is a mechanism for B to tell A that this has happened (and to > say when it wishes to display some other stream from A). >=20 > Do we think that the work to do this type of stream-suspension is > floor control? (My opinion is no. I view floor control more as who is > the source for a given stream and not a selection of an agreed upon > stream). >=20 > Do we think this work is in scope for Telepresence Interoperability? I > think this is an essential element to deployable TP operation > especially as in expands to "at home" use. If an architecture in which > a room sends all video all the time (even though it's not being used) > is viewed as necessary to avoid complexity/meet responsiveness > requirements is thought to be ok then I'd like to make sure we are > clear that that these limitations exist upfront. >=20 > My preference is obviously to permit this feedback and tweak the > proposed charter. >=20 > Other opinions? >=20 > Regards, >=20 >=20 > Peter Musgrave >=20 > On Thu, Oct 14, 2010 at 9:46 AM, Mike Hammer (hmmr) = wrote: >> Peter, >> >> I have not issue with your proposed words, since they are essentially = asking for a "mute" button for all types of communications used by a = sender. This may complicate the algorithm for all the receive systems = to know what to display, if for example, you continue to speak, but turn = off the video transmission. A "mute all" option might be more polite. >> >> I did have issue with this comment: "more like onhold/offhold type = negotiation" >> >> I am not sure I would agree with this. >> >> There needs to be a distinction between when a call starts and when a = call stops, the call being *all* communications (sessions) between two = points. Granted putting a call on hold seems like floor control, but = the participants of the call on hold are effectively out of the call = (left the room) until brought off-hold. This is SIP level action. >> >> There needs to be a clear distinction between negotiating = capabilities, aka knowing what capabilities an endpoint has, and using = those capabilities during a call. That learning process is done via = SDP. >> >> The latter part seems to be floor control, continuous conference = control, or whatever you want to call it. There seems to be splitting = of hairs over whether the floor control is manual or automatic = (determined by the loudest speaker). This may be AVT. >> >> In summary, you have room access, you define capabilities, you have = "speaker" conflict resolution control. (Note, point-to-point calls are = devolution since resolution of conflict is a non-problem with only one = opposing party.) >> >> Did I miss some other nuance? >> >> Mike >> >> >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Peter Musgrave >> Sent: Thursday, October 14, 2010 5:25 AM >> To: Allyn Romanow (allyn) >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] Comments on the proposed Telepresence Charter >> >> HI Allyn/Magnus, >> >> W.R.T >> >> "[AR} I agree with your point that it would be good to pause the >> sender, but I think that falls >> under the category of "continuous conference control" which is out = of >> the scope of this charter. >> Such a feedback mechanism falls probably under AVT. >> I think it would be good to add a sentence saying something like, As >> control issues >> necessary for interoperability arise, they will be directed = appropriately. >> What do you think?" >> >> I think these words leave room to *not* do what Magnus is suggesting. >> e.g. If I have a 1 screen home TP system getting three streams from a >> 3 camera system and selecting only one it is not really "necessary" = to >> tell the 3 camera system to pause two streams - but it is a really >> good idea to have a way to that! I don't view this is a continuous >> conference control issue (since that gets into floor control which I >> agree is out of scope) but more like onhold/offhold type negotiation. >> I think this is to some extent a plumbing issue (and based on the >> desired response time SIP or media path messages will be required). >> >> So I would still like to see a statement which makes it clear that it >> not just an issue of receiver selection but there is a need to >> communicate that selection back to the sender. The current text does >> not say this. Hence my suggestion: >> >> "Selection choices will be communicated to the sending party to allow >> the sender to optionally present information on which streams are in >> use and to optionally suspend streams which are not in use." ?? >> >> I'm open to other words or some indication of which language in the >> current charter ensures this is in scope. >> >> Regards, >> >> Peter Musgrave >> >> >> >> >> On Wed, Oct 13, 2010 at 12:47 PM, Allyn Romanow (allyn) = wrote: >>> Hi Magnus, >>> I was really glad that you had a chance to carefully consider the = proposed work. >>> Like Peter, I too agree with most of your comments. >>> Specific points below. >>> >>> Best regards, >>> Allyn >>> >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] = On Behalf Of Magnus Westerlund >>> Sent: Tuesday, October 12, 2010 6:47 AM >>> To: dispatch@ietf.org >>> Subject: [dispatch] Comments on the proposed Telepresence Charter >>> >>> Hi, >>> >>> Some colleagues and I have reviewed the two telepresence drafts and >>> version 5 of the charter and have some comments on the charter. >>> >>> To make our comments more understandable I think we should explain = our >>> view on telepresence. First we are expecting great variations in the >>> capabilities of the participating terminals in a session. From = personal >>> terminals for individual users up to multi-display, cameras and >>> microphone setups. We also expect that more than two end-points = being >>> present in the same session. As we see it it will require good = support >>> for centralized media handling in a mixer (MCU). We also see video >>> streams not only of high quality to be presented for maximum = immersion, >>> but also lower qualities that can be used to monitor activity in = other >>> rooms that aren't the ones selected for high quality. >>> >>> [AR] Yes, absolutely. >>> >>> Independent if one uses a central mixer or a full mesh there appears = to >>> be a lack in media stream negotiation for how to negotiate what >>> capabilities the receiving client has in receiving, decoding and >>> rendering when it comes to number of simultaneous streams. Our >>> understanding is that RTP mandates any number of streams, while in >>> reality outside of conferencing that is in fact one single stream. >>> However with telepresence and conferencing there is a need to = negotiate >>> the actual capability, especially between a mixer and client when it >>> comes to deliver multiple streams for various usages. >>> >>> [AR] Yes, agree - as you saw, this is covered in the charter. >>> >>> We also think there is missing functionality for expressing who are = the >>> currently active speakers. The RTP CSRC field are not sufficient as = they >>> express which end-points are included in the mix. However, as one = likely >>> include in a mix more rooms than the active speakers to ensure that = any >>> interruption and ambient sound are correctly captured an mechanism = for >>> indicating the currently active speakers are needed. There is also = need >>> to agree on the type of identifier to be used that allow for mapping = to >>> full user names when appropriate. >>> >>> [AR] Yes.. Both of these points are covered in the charter too, = right? >>> >>> The charter includes an item to work on control between client and a >>> mixer what streams should be delivered. We would like to extended = this >>> to allow also the mixer to control the client on when streams are >>> delivered. In cases where there are more users then available = display >>> area and a particular user is not actually included in any outgoing >>> mix/selection from the mixer then there is little point in that the >>> client consumes network resources. Thus we suggest that the stream >>> selection and control work is extended to allow also the mixer to = pause >>> individual streams from the client to the mixer. Please note that = such >>> control needs to be responsive, thus using the SIP signaling path = for >>> this is to slow, it needs to be on the media path. >>> >>> [AR} I agree with your point that it would be good to pause the = sender, but I think that falls >>> under the category of "continuous conference control" which is out = of the scope of this charter. >>> Such a feedback mechanism falls probably under AVT. >>> I think it would be good to add a sentence saying something like, As = control issues >>> necessary for interoperability arise, they will be directed = appropriately. >>> What do you think? >>> >>> >>> Another question to the group is, are there agreement on how streams >>> should organized into RTP sessions and how they are utilized? If >>> anything is documented I would appreciate a pointer. The media = streams >>> are for different purposes from different end-points which are then >>> mixed by a central point and delivered to end-points. My impression = for >>> example is that most proprietary system breaks the RTP semantics and = use >>> individual sessions between the mixer and each end-point, instead of = a >>> joint session. Here also different robustification tools for RTP = such as >>> FEC and Retransmission needs to be considered. This might be work = that >>> belongs in AVT, but are there need for further clarification into = this >>> field? >>> >>> [AR} Agree this needs to be worked out for Telepresence, and that = any activity about it would go to AVT and/or MMUSIC. >>> >>> Comments much appreciated and we can gladly suggest text additions = to >>> the charter proposal. >>> >>> Cheers >>> >>> Magnus Westerlund >>> >>> = ---------------------------------------------------------------------- >>> Multimedia Technologies, Ericsson Research EAB/TVM >>> = ---------------------------------------------------------------------- >>> Ericsson AB | Phone +46 10 7148287 >>> F=E4r=F6gatan 6 | Mobile +46 73 0949079 >>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >>> = ---------------------------------------------------------------------- >>> _______________________________________________ >>> 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 >>> >> _______________________________________________ >> 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 Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From allyn@cisco.com Sun Oct 24 18:13:03 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C285C3A691B for ; Sun, 24 Oct 2010 18:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.379 X-Spam-Level: X-Spam-Status: No, score=-10.379 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6m+xaYw-q31U for ; Sun, 24 Oct 2010 18:12:53 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 0BFA93A67F7 for ; Sun, 24 Oct 2010 18:12:52 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAC53xEyrRN+J/2dsb2JhbAChXXGfNZszhUgEhFSJBQ X-IronPort-AV: E=Sophos;i="4.58,233,1286150400"; d="scan'208";a="374098580" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 25 Oct 2010 01:14:20 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o9P1EKhY006059; Mon, 25 Oct 2010 01:14:20 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 24 Oct 2010 18:14:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sun, 24 Oct 2010 18:14:19 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02BB188B@xmb-sjc-221.amer.cisco.com> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058501703C50@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Telepresence charter version 5 Thread-Index: ActPmkA59SRpRJvGStyI1NQx2FdsDwAVkXxwAUKqrKAA6kTeoAAVWaHgABQtK0AAAEn6sAAAOkXABncPLxA= References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0254DFFA@xmb-sjc-221.amer.cisco.com><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02700028@xmb-sjc-221.amer.cisco.com> <7F2072F1E0DE894DA4B517B93C6A058501653F94@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058501703C4C@ESESSCMS0356.eemea.ericsson.se> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC027B1D20@xmb-sjc-221.amer.cisco.com> <7F2072F1E0DE894DA4B517B93C6A058501703C50@ESESSCMS0356.eemea.ericsson.se> From: "Allyn Romanow (allyn)" To: "Christer Holmberg" , "Charles Eckel (eckelcu)" , "Elwell, John" , "DISPATCH list" X-OriginalArrivalTime: 25 Oct 2010 01:14:20.0625 (UTC) FILETIME=[F3DB1C10:01CB73E1] Subject: Re: [dispatch] Telepresence charter version 5 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 01:13:05 -0000 Hi Christer, In reviewing this, I think it would be fine to just omit the sentence at issue- In addition, there is no standardized way to exchange semantic information about what each media stream represents. =20 Because I feel that the sentence just prior to it says adequately what is necessary. It is A major factor in the inability of telepresence systems to interwork is that there is no standardized way to describe and negotiate the use of the multiple streams of audio and video that comprise the media flows. What do you think? Best regards, Allyn -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Monday, September 20, 2010 10:19 PM To: Allyn Romanow (allyn); Charles Eckel (eckelcu); Elwell, John; DISPATCH list Subject: RE: [dispatch] Telepresence charter version 5 Hi,=20 >Thanks for pointing out that the original sentence is not=20 >strictly accurate, and also not precisely what was meant. I=20 >think it is fine to change the wording along the lines you=20 >suggest, can I get back to you shortly on precise wording? =20 Sure, no problem. Regards, Christer > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, September 20, 2010 10:07 PM > To: Charles Eckel (eckelcu); Allyn Romanow (allyn); Elwell,=20 > John; DISPATCH list > Subject: RE: [dispatch] Telepresence charter version 5 >=20 >=20 > Hi Charles,=20 >=20 > >I think RFC label attribute may be useful; however, we would=20 > >need to establish and register set of tokens and the=20 > >semantics of those tokens. > >Once we get to the actual design, that would be worth considering. > >Without addition specification, I think you would have=20 > >proprietary sets of labels being used at best. >=20 > Yes, I agree that we would need to specify the labels. >=20 > My point was that there does exist a mechanism for doing so. So, maybe > the text could say something like: >=20 > "In addition, standardization work, in order to be able to exchange > semantic > information about what each media stream represents, might be needed." >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > > > -----Original Message----- > > > From: dispatch-bounces@ietf.org=20 > > [mailto:dispatch-bounces@ietf.org] On > > Behalf Of Christer Holmberg > > > Sent: Monday, September 20, 2010 2:18 AM > > > To: Allyn Romanow (allyn); Elwell, John; DISPATCH list > > > Subject: Re: [dispatch] Telepresence charter version 5 > > >=20 > > >=20 > > > Hi, > > >=20 > > > One question for clarification. The text says: > > >=20 > > > "In addition, there is no standardized way to exchange semantic > > information about what each media > > > stream represents." > > >=20 > > > Isn't that something RFC 4574 could be used for? > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > -----Original Message----- > > > From: dispatch-bounces@ietf.org=20 > > [mailto:dispatch-bounces@ietf.org] On > > Behalf Of Allyn Romanow (allyn) > > > Sent: 15. syyskuuta 2010 20:42 > > > To: Elwell, John; DISPATCH list > > > Subject: [dispatch] Telepresence charter version 5 > > >=20 > > > In keeping with John's good catch, the reference to BFCP has been > > removed. > > > This was the only suggested change to the charter. > > >=20 > > >=20 > > > Thanks, > > > Allyn > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > MALT - Multi-stream Attributes for Lifelike Telepresence=20 > COCKTAIL - > > Communication and Correlation of > > > Key Telepresence Attributes for Interoperable Links MAITAI - > > Multi-stream Attributes for Improving > > > Telepresence Application Interoperability TEQUILA - Telepresence > > Encoding of QUalifiers for > > > Interoperable Lifelike Applications MOJITO - Multi-stream=20 > > Orientation > > for Joining of Interoperable > > > Telepresence Operations > > >=20 > > >=20 > > > In the context of this WG, the term telepresence is used in=20 > > a general > > manner to describe systems that > > > provide high definition, high quality audio/video enabling a > > "being-there" experience. One example is > > > an immersive telepresence system using specially designed=20 > > and special > > purpose rooms with multiple > > > displays permitting life size image reproduction using multiple > > cameras, encoders, decoders, > > > microphones and loudspeakers. > > >=20 > > > Current telepresence systems are based on open standards=20 > > such as RTP, > > SIP, H.264, the H.323 suite, > > > however, they cannot easily interoperate with each other without > > operator assistance and expensive > > > additional equipment which translates from one vendor to=20 > another. A > > major factor in the inability of > > > telepresence systems to interwork is that there is no=20 > > standardized way > > to describe and negotiate the > > > use of the multiple streams of audio and video that=20 > > comprise the media > > flows. In addition, there is no > > > standardized way to exchange semantic information about what each > > media stream represents. > > >=20 > > > The WG will create specifications for SIP-based=20 > conferencing systems > > to enable communication of enough > > > information about each media stream so that each=20 > receiving system or > > bridge system can make reasonable > > > decisions about selecting and rendering media streams.=20 > This enables > > systems to make display choices > > > that optimize the "just like being there" experience. > > >=20 > > > This working group is chartered to specify the information=20 > > about media > > streams from one entity to > > > another entity: > > >=20 > > > * Spatial relationships of cameras, displays, microphones, and > > > Speakers - in relation to each other and to likely positions of > > > participants > > >=20 > > > * Specific characteristics such as viewpoint, field of=20 > view/capture > > > for camera/microphone/display/speaker - so that senders and > > >=20 > > > middleboxes can understand how best to compose streams for > > > receivers, and the receivers will know the=20 > characteristics of its > > > received streams > > >=20 > > > *Usage of the stream, for example whether the stream is=20 > > presentation, > > or document camera output > > >=20 > > > * Aspect ratio of cameras and displays > > >=20 > > > * Which sources a receiver wants to receive. For=20 > example, it might > > want the source for the left > > > camera, or might want the source chosen by VAD (Voice Activity > > Detection). > > >=20 > > >=20 > > > Information between sources and sinks about media stream=20 > > capabilities > > will be exchanged. > > >=20 > > > The working group will define the semantics, syntax, and=20 > transport > > mechanism necessary for > > > communicating the necessary information. It will consider=20 > > whether the > > existing signaling mechanisms > > > (e. g., SDP) can be extended, or another messaging method=20 > should be > > used. > > >=20 > > > The scope of the work includes describing relatively static=20 > > relations > > between entities (participants > > > and devices). It also includes handling more dynamic=20 > relationships, > > such as identifying the audio and > > > video streams for the current speaker. The scope includes=20 > > both systems > > that provide a fully immersive > > > experience, and systems that interwork with them and=20 > > therefore need to > > understand the same multiple > > > stream semantics. > > >=20 > > > The focus of this work is on multiple audio and video=20 > > streams. Other > > media types may be considered, > > > however development of methodologies for them is not within=20 > > the scope > > of this work. > > >=20 > > > Interoperation with SIP and related standards for audio=20 > and video is > > required. However, backwards > > > compatibility with existing non-standards compliant telepresence > > systems is not required. > > >=20 > > > This working group is not currently chartered to work on issues of > > continuous conference control > > > including: far end camera control, indication of fast frame=20 > > update for > > video codecs or other rapid > > > switches, floor control, conference roster. > > >=20 > > > Reuse of existing protocols and backwards compatibility with > > SIP-compliant audio/video endpoints are > > > important factors for the working group to consider. The work will > > closely coordinate with the > > > appropriate areas and working groups including OPS Area,=20 > > AVT, MMUSIC, > > MEDIACTRL, XCON, and SIPCORE. > > >=20 > > > Milestones > > >=20 > > > Nov 2010 Submit information draft to IESG on use cases and > > requirements > > >=20 > > > Nov 2011 Submit standards track specification to IESG indicating > > spatial relationships of screens > > > cameras (including variable field of view and=20 > orientation), speakers > > and microphones; and the "usage" > > > of a stream as defined in the charter. Semantics, language and > > transport mechanism will be specified. > > >=20 > > >=20 > > >=20 > > > > > -------------------------------------------------------------- > > ---------- > > > -------- > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Thursday, September 09, 2010 12:31 AM > > > To: Allyn Romanow (allyn); DISPATCH list > > > Subject: RE: Telepresence charter version 4 > > >=20 > > > Allyn, > > >=20 > > > Can you explain the following: > > > "It will consider whether the existing signaling=20 > mechanisms (e. g., > > .... > > > BFCP) can be extended, or another messaging method should be used" > > >=20 > > > and > > >=20 > > > "This working group is not currently chartered to work on=20 > issues of=20 > > > continuous conference control including: .... floor control..." > > >=20 > > > It is unclear to me how BFCP can be within scope yet floor=20 > > control is=20 > > > out of scope. > > >=20 > > > John > > > _______________________________________________ > > > 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 From tme@americafree.tv Sun Oct 24 20:44:27 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA35C3A6359 for ; Sun, 24 Oct 2010 20:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PeeoCY0v1rhZ for ; Sun, 24 Oct 2010 20:44:26 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 002E73A6936 for ; Sun, 24 Oct 2010 20:44:25 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 8AA4D9177C9C; Sun, 24 Oct 2010 23:46:09 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Marshall Eubanks In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02BB188B@xmb-sjc-221.amer.cisco.com> Date: Sun, 24 Oct 2010 23:46:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <383AAA4F-B7A4-40E2-9F37-1772A60B0EDA@americafree.tv> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0254DFFA@xmb-sjc-221.amer.cisco.com><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02700028@xmb-sjc-221.amer.cisco.com> <7F2072F1E0DE894DA4B517B93C6A058501653F94@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058501703C4C@ESESSCMS0356.eemea.ericsson.se> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC027B1D20@xmb-sjc-221.amer.cisco.com> <7F2072F1E0DE894DA4B517B93C6A058501703C50@ESESSCMS0356.eemea.ericsson.se> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02BB188B@xmb-sjc-221.amer.cisco.com> To: "Allyn Romanow (allyn)" X-Mailer: Apple Mail (2.1081) Cc: DISPATCH list Subject: Re: [dispatch] Telepresence charter version 5 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 03:44:28 -0000 On Oct 24, 2010, at 9:14 PM, Allyn Romanow (allyn) wrote: > Hi Christer, >=20 > In reviewing this, I think it would be fine to just omit the sentence = at > issue- > In addition, there is no standardized way to exchange semantic > information about what each media stream represents. =20 >=20 > Because I feel that the sentence just prior to it says adequately what > is necessary. It is > A major factor in the inability of telepresence systems to > interwork is that there is no standardized way to describe and > negotiate the use of the multiple streams of audio and video that > comprise the media flows. That would work for me. This sentence, however, has too many thats. How about =20 A major factor limiting the interoperability of telepresence systems=20 is the lack of a standardized way to describe and negotiate the use of = the multiple streams of audio and video comprising the media flows. Marshall >=20 >=20 > What do you think? >=20 > Best regards, > Allyn > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: Monday, September 20, 2010 10:19 PM > To: Allyn Romanow (allyn); Charles Eckel (eckelcu); Elwell, John; > DISPATCH list > Subject: RE: [dispatch] Telepresence charter version 5 >=20 >=20 > Hi,=20 >=20 >> Thanks for pointing out that the original sentence is not=20 >> strictly accurate, and also not precisely what was meant. I=20 >> think it is fine to change the wording along the lines you=20 >> suggest, can I get back to you shortly on precise wording? =20 >=20 > Sure, no problem. >=20 > Regards, >=20 > Christer >=20 >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: Monday, September 20, 2010 10:07 PM >> To: Charles Eckel (eckelcu); Allyn Romanow (allyn); Elwell,=20 >> John; DISPATCH list >> Subject: RE: [dispatch] Telepresence charter version 5 >>=20 >>=20 >> Hi Charles,=20 >>=20 >>> I think RFC label attribute may be useful; however, we would=20 >>> need to establish and register set of tokens and the=20 >>> semantics of those tokens. >>> Once we get to the actual design, that would be worth considering. >>> Without addition specification, I think you would have=20 >>> proprietary sets of labels being used at best. >>=20 >> Yes, I agree that we would need to specify the labels. >>=20 >> My point was that there does exist a mechanism for doing so. So, = maybe >> the text could say something like: >>=20 >> "In addition, standardization work, in order to be able to exchange >> semantic >> information about what each media stream represents, might be = needed." >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >>=20 >>>> -----Original Message----- >>>> From: dispatch-bounces@ietf.org=20 >>> [mailto:dispatch-bounces@ietf.org] On >>> Behalf Of Christer Holmberg >>>> Sent: Monday, September 20, 2010 2:18 AM >>>> To: Allyn Romanow (allyn); Elwell, John; DISPATCH list >>>> Subject: Re: [dispatch] Telepresence charter version 5 >>>>=20 >>>>=20 >>>> Hi, >>>>=20 >>>> One question for clarification. The text says: >>>>=20 >>>> "In addition, there is no standardized way to exchange semantic >>> information about what each media >>>> stream represents." >>>>=20 >>>> Isn't that something RFC 4574 could be used for? >>>>=20 >>>> Regards, >>>>=20 >>>> Christer >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: dispatch-bounces@ietf.org=20 >>> [mailto:dispatch-bounces@ietf.org] On >>> Behalf Of Allyn Romanow (allyn) >>>> Sent: 15. syyskuuta 2010 20:42 >>>> To: Elwell, John; DISPATCH list >>>> Subject: [dispatch] Telepresence charter version 5 >>>>=20 >>>> In keeping with John's good catch, the reference to BFCP has been >>> removed. >>>> This was the only suggested change to the charter. >>>>=20 >>>>=20 >>>> Thanks, >>>> Allyn >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> MALT - Multi-stream Attributes for Lifelike Telepresence=20 >> COCKTAIL - >>> Communication and Correlation of >>>> Key Telepresence Attributes for Interoperable Links MAITAI - >>> Multi-stream Attributes for Improving >>>> Telepresence Application Interoperability TEQUILA - Telepresence >>> Encoding of QUalifiers for >>>> Interoperable Lifelike Applications MOJITO - Multi-stream=20 >>> Orientation >>> for Joining of Interoperable >>>> Telepresence Operations >>>>=20 >>>>=20 >>>> In the context of this WG, the term telepresence is used in=20 >>> a general >>> manner to describe systems that >>>> provide high definition, high quality audio/video enabling a >>> "being-there" experience. One example is >>>> an immersive telepresence system using specially designed=20 >>> and special >>> purpose rooms with multiple >>>> displays permitting life size image reproduction using multiple >>> cameras, encoders, decoders, >>>> microphones and loudspeakers. >>>>=20 >>>> Current telepresence systems are based on open standards=20 >>> such as RTP, >>> SIP, H.264, the H.323 suite, >>>> however, they cannot easily interoperate with each other without >>> operator assistance and expensive >>>> additional equipment which translates from one vendor to=20 >> another. A >>> major factor in the inability of >>>> telepresence systems to interwork is that there is no=20 >>> standardized way >>> to describe and negotiate the >>>> use of the multiple streams of audio and video that=20 >>> comprise the media >>> flows. In addition, there is no >>>> standardized way to exchange semantic information about what each >>> media stream represents. >>>>=20 >>>> The WG will create specifications for SIP-based=20 >> conferencing systems >>> to enable communication of enough >>>> information about each media stream so that each=20 >> receiving system or >>> bridge system can make reasonable >>>> decisions about selecting and rendering media streams.=20 >> This enables >>> systems to make display choices >>>> that optimize the "just like being there" experience. >>>>=20 >>>> This working group is chartered to specify the information=20 >>> about media >>> streams from one entity to >>>> another entity: >>>>=20 >>>> * Spatial relationships of cameras, displays, microphones, and >>>> Speakers - in relation to each other and to likely positions of >>>> participants >>>>=20 >>>> * Specific characteristics such as viewpoint, field of=20 >> view/capture >>>> for camera/microphone/display/speaker - so that senders and >>>>=20 >>>> middleboxes can understand how best to compose streams for >>>> receivers, and the receivers will know the=20 >> characteristics of its >>>> received streams >>>>=20 >>>> *Usage of the stream, for example whether the stream is=20 >>> presentation, >>> or document camera output >>>>=20 >>>> * Aspect ratio of cameras and displays >>>>=20 >>>> * Which sources a receiver wants to receive. For=20 >> example, it might >>> want the source for the left >>>> camera, or might want the source chosen by VAD (Voice Activity >>> Detection). >>>>=20 >>>>=20 >>>> Information between sources and sinks about media stream=20 >>> capabilities >>> will be exchanged. >>>>=20 >>>> The working group will define the semantics, syntax, and=20 >> transport >>> mechanism necessary for >>>> communicating the necessary information. It will consider=20 >>> whether the >>> existing signaling mechanisms >>>> (e. g., SDP) can be extended, or another messaging method=20 >> should be >>> used. >>>>=20 >>>> The scope of the work includes describing relatively static=20 >>> relations >>> between entities (participants >>>> and devices). It also includes handling more dynamic=20 >> relationships, >>> such as identifying the audio and >>>> video streams for the current speaker. The scope includes=20 >>> both systems >>> that provide a fully immersive >>>> experience, and systems that interwork with them and=20 >>> therefore need to >>> understand the same multiple >>>> stream semantics. >>>>=20 >>>> The focus of this work is on multiple audio and video=20 >>> streams. Other >>> media types may be considered, >>>> however development of methodologies for them is not within=20 >>> the scope >>> of this work. >>>>=20 >>>> Interoperation with SIP and related standards for audio=20 >> and video is >>> required. However, backwards >>>> compatibility with existing non-standards compliant telepresence >>> systems is not required. >>>>=20 >>>> This working group is not currently chartered to work on issues of >>> continuous conference control >>>> including: far end camera control, indication of fast frame=20 >>> update for >>> video codecs or other rapid >>>> switches, floor control, conference roster. >>>>=20 >>>> Reuse of existing protocols and backwards compatibility with >>> SIP-compliant audio/video endpoints are >>>> important factors for the working group to consider. The work will >>> closely coordinate with the >>>> appropriate areas and working groups including OPS Area,=20 >>> AVT, MMUSIC, >>> MEDIACTRL, XCON, and SIPCORE. >>>>=20 >>>> Milestones >>>>=20 >>>> Nov 2010 Submit information draft to IESG on use cases and >>> requirements >>>>=20 >>>> Nov 2011 Submit standards track specification to IESG indicating >>> spatial relationships of screens >>>> cameras (including variable field of view and=20 >> orientation), speakers >>> and microphones; and the "usage" >>>> of a stream as defined in the charter. Semantics, language and >>> transport mechanism will be specified. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>> -------------------------------------------------------------- >>> ---------- >>>> -------- >>>> -----Original Message----- >>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>> Sent: Thursday, September 09, 2010 12:31 AM >>>> To: Allyn Romanow (allyn); DISPATCH list >>>> Subject: RE: Telepresence charter version 4 >>>>=20 >>>> Allyn, >>>>=20 >>>> Can you explain the following: >>>> "It will consider whether the existing signaling=20 >> mechanisms (e. g., >>> .... >>>> BFCP) can be extended, or another messaging method should be used" >>>>=20 >>>> and >>>>=20 >>>> "This working group is not currently chartered to work on=20 >> issues of=20 >>>> continuous conference control including: .... floor control..." >>>>=20 >>>> It is unclear to me how BFCP can be within scope yet floor=20 >>> control is=20 >>>> out of scope. >>>>=20 >>>> John >>>> _______________________________________________ >>>> 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 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From allyn@cisco.com Sun Oct 24 22:38:30 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB7AA3A67D0 for ; Sun, 24 Oct 2010 22:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.39 X-Spam-Level: X-Spam-Status: No, score=-10.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxF8CzBGOXsO for ; Sun, 24 Oct 2010 22:38:24 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 1F5A83A67A7 for ; Sun, 24 Oct 2010 22:38:23 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANO0xEyrR7Ht/2dsb2JhbAChXHGfMJtEhUgEhFSJBQ X-IronPort-AV: E=Sophos;i="4.58,234,1286150400"; d="scan'208";a="244049017" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 25 Oct 2010 05:40:07 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9P5e7Fv010474; Mon, 25 Oct 2010 05:40:07 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 24 Oct 2010 22:40:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sun, 24 Oct 2010 22:40:05 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02BB18F2@xmb-sjc-221.amer.cisco.com> In-Reply-To: <383AAA4F-B7A4-40E2-9F37-1772A60B0EDA@americafree.tv> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Telepresence charter version 5 Thread-Index: Actz9zVBRnRP/6gLQXKuasQsvPLj1wAD64+g References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0254DFFA@xmb-sjc-221.amer.cisco.com><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02700028@xmb-sjc-221.amer.cisco.com> <7F2072F1E0DE894DA4B517B93C6A058501653F94@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058501703C4C@ESESSCMS0356.eemea.ericsson.se> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC027B1D20@xmb-sjc-221.amer.cisco.com> <7F2072F1E0DE894DA4B517B93C6A058501703C50@ESESSCMS0356.eemea.ericsson.se> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02BB188B@xmb-sjc-221.amer.cisco.com> <383AAA4F-B7A4-40E2-9F37-1772A60B0EDA@americafree.tv> From: "Allyn Romanow (allyn)" To: "Marshall Eubanks" X-OriginalArrivalTime: 25 Oct 2010 05:40:07.0301 (UTC) FILETIME=[14D0C350:01CB7407] Cc: DISPATCH list Subject: Re: [dispatch] Telepresence charter version 5 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 05:38:30 -0000 Much improved. Will incorporate it in next version, which I hope to send out Monday night. Thanks, Allyn=20 > -----Original Message----- > From: Marshall Eubanks [mailto:tme@americafree.tv]=20 > Sent: Sunday, October 24, 2010 8:46 PM > To: Allyn Romanow (allyn) > Cc: Christer Holmberg; Charles Eckel (eckelcu); Elwell, John;=20 > DISPATCH list > Subject: Re: [dispatch] Telepresence charter version 5 >=20 >=20 > On Oct 24, 2010, at 9:14 PM, Allyn Romanow (allyn) wrote: >=20 > > Hi Christer, > >=20 > > In reviewing this, I think it would be fine to just omit=20 > the sentence=20 > > at > > issue- > > In addition, there is no standardized way to exchange semantic > > information about what each media stream represents. =20 > >=20 > > Because I feel that the sentence just prior to it says=20 > adequately what=20 > > is necessary. It is > > A major factor in the inability of telepresence systems to > > interwork is that there is no standardized way to describe and > > negotiate the use of the multiple streams of audio and=20 > video that > > comprise the media flows. >=20 > That would work for me. This sentence, however, has too many thats. >=20 > How about =20 >=20 > A major factor limiting the interoperability of telepresence=20 > systems is the lack of a standardized way to describe and=20 > negotiate the use of the multiple streams of audio and video=20 > comprising the media flows. >=20 > Marshall >=20 >=20 > >=20 > >=20 > > What do you think? > >=20 > > Best regards, > > Allyn > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Monday, September 20, 2010 10:19 PM > > To: Allyn Romanow (allyn); Charles Eckel (eckelcu); Elwell, John;=20 > > DISPATCH list > > Subject: RE: [dispatch] Telepresence charter version 5 > >=20 > >=20 > > Hi, > >=20 > >> Thanks for pointing out that the original sentence is not strictly=20 > >> accurate, and also not precisely what was meant. I think=20 > it is fine=20 > >> to change the wording along the lines you suggest, can I=20 > get back to=20 > >> you shortly on precise wording? > >=20 > > Sure, no problem. > >=20 > > Regards, > >=20 > > Christer > >=20 > >> -----Original Message----- > >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > >> Sent: Monday, September 20, 2010 10:07 PM > >> To: Charles Eckel (eckelcu); Allyn Romanow (allyn); Elwell, John;=20 > >> DISPATCH list > >> Subject: RE: [dispatch] Telepresence charter version 5 > >>=20 > >>=20 > >> Hi Charles, > >>=20 > >>> I think RFC label attribute may be useful; however, we=20 > would need to=20 > >>> establish and register set of tokens and the semantics of those=20 > >>> tokens. > >>> Once we get to the actual design, that would be worth considering. > >>> Without addition specification, I think you would have=20 > proprietary=20 > >>> sets of labels being used at best. > >>=20 > >> Yes, I agree that we would need to specify the labels. > >>=20 > >> My point was that there does exist a mechanism for doing so. So,=20 > >> maybe the text could say something like: > >>=20 > >> "In addition, standardization work, in order to be able to=20 > exchange=20 > >> semantic information about what each media stream=20 > represents, might=20 > >> be needed." > >>=20 > >> Regards, > >>=20 > >> Christer > >>=20 > >>=20 > >>=20 > >>>> -----Original Message----- > >>>> From: dispatch-bounces@ietf.org > >>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Christer Holmberg > >>>> Sent: Monday, September 20, 2010 2:18 AM > >>>> To: Allyn Romanow (allyn); Elwell, John; DISPATCH list > >>>> Subject: Re: [dispatch] Telepresence charter version 5 > >>>>=20 > >>>>=20 > >>>> Hi, > >>>>=20 > >>>> One question for clarification. The text says: > >>>>=20 > >>>> "In addition, there is no standardized way to exchange semantic > >>> information about what each media > >>>> stream represents." > >>>>=20 > >>>> Isn't that something RFC 4574 could be used for? > >>>>=20 > >>>> Regards, > >>>>=20 > >>>> Christer > >>>>=20 > >>>>=20 > >>>>=20 > >>>>=20 > >>>>=20 > >>>>=20 > >>>>=20 > >>>>=20 > >>>>=20 > >>>>=20 > >>>> -----Original Message----- > >>>> From: dispatch-bounces@ietf.org > >>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Allyn Romanow=20 > >>> (allyn) > >>>> Sent: 15. syyskuuta 2010 20:42 > >>>> To: Elwell, John; DISPATCH list > >>>> Subject: [dispatch] Telepresence charter version 5 > >>>>=20 > >>>> In keeping with John's good catch, the reference to BFCP has been > >>> removed. > >>>> This was the only suggested change to the charter. > >>>>=20 > >>>>=20 > >>>> Thanks, > >>>> Allyn > >>>>=20 > >>>>=20 > >>>>=20 > >>>>=20 > >>>>=20 > >>>>=20 > >>>> MALT - Multi-stream Attributes for Lifelike Telepresence > >> COCKTAIL - > >>> Communication and Correlation of > >>>> Key Telepresence Attributes for Interoperable Links MAITAI - > >>> Multi-stream Attributes for Improving > >>>> Telepresence Application Interoperability TEQUILA - Telepresence > >>> Encoding of QUalifiers for > >>>> Interoperable Lifelike Applications MOJITO - Multi-stream > >>> Orientation > >>> for Joining of Interoperable > >>>> Telepresence Operations > >>>>=20 > >>>>=20 > >>>> In the context of this WG, the term telepresence is used in > >>> a general > >>> manner to describe systems that > >>>> provide high definition, high quality audio/video enabling a > >>> "being-there" experience. One example is > >>>> an immersive telepresence system using specially designed > >>> and special > >>> purpose rooms with multiple > >>>> displays permitting life size image reproduction using multiple > >>> cameras, encoders, decoders, > >>>> microphones and loudspeakers. > >>>>=20 > >>>> Current telepresence systems are based on open standards > >>> such as RTP, > >>> SIP, H.264, the H.323 suite, > >>>> however, they cannot easily interoperate with each other without > >>> operator assistance and expensive > >>>> additional equipment which translates from one vendor to > >> another. A > >>> major factor in the inability of > >>>> telepresence systems to interwork is that there is no > >>> standardized way > >>> to describe and negotiate the > >>>> use of the multiple streams of audio and video that > >>> comprise the media > >>> flows. In addition, there is no > >>>> standardized way to exchange semantic information about what each > >>> media stream represents. > >>>>=20 > >>>> The WG will create specifications for SIP-based > >> conferencing systems > >>> to enable communication of enough > >>>> information about each media stream so that each > >> receiving system or > >>> bridge system can make reasonable > >>>> decisions about selecting and rendering media streams.=20 > >> This enables > >>> systems to make display choices > >>>> that optimize the "just like being there" experience. > >>>>=20 > >>>> This working group is chartered to specify the information > >>> about media > >>> streams from one entity to > >>>> another entity: > >>>>=20 > >>>> * Spatial relationships of cameras, displays, microphones, and =20 > >>>> Speakers - in relation to each other and to likely positions of =20 > >>>> participants > >>>>=20 > >>>> * Specific characteristics such as viewpoint, field of > >> view/capture > >>>> for camera/microphone/display/speaker - so that senders and > >>>>=20 > >>>> middleboxes can understand how best to compose streams for =20 > >>>> receivers, and the receivers will know the > >> characteristics of its > >>>> received streams > >>>>=20 > >>>> *Usage of the stream, for example whether the stream is > >>> presentation, > >>> or document camera output > >>>>=20 > >>>> * Aspect ratio of cameras and displays > >>>>=20 > >>>> * Which sources a receiver wants to receive. For > >> example, it might > >>> want the source for the left > >>>> camera, or might want the source chosen by VAD (Voice Activity > >>> Detection). > >>>>=20 > >>>>=20 > >>>> Information between sources and sinks about media stream > >>> capabilities > >>> will be exchanged. > >>>>=20 > >>>> The working group will define the semantics, syntax, and > >> transport > >>> mechanism necessary for > >>>> communicating the necessary information. It will consider > >>> whether the > >>> existing signaling mechanisms > >>>> (e. g., SDP) can be extended, or another messaging method > >> should be > >>> used. > >>>>=20 > >>>> The scope of the work includes describing relatively static > >>> relations > >>> between entities (participants > >>>> and devices). It also includes handling more dynamic > >> relationships, > >>> such as identifying the audio and > >>>> video streams for the current speaker. The scope includes > >>> both systems > >>> that provide a fully immersive > >>>> experience, and systems that interwork with them and > >>> therefore need to > >>> understand the same multiple > >>>> stream semantics. > >>>>=20 > >>>> The focus of this work is on multiple audio and video > >>> streams. Other > >>> media types may be considered, > >>>> however development of methodologies for them is not within > >>> the scope > >>> of this work. > >>>>=20 > >>>> Interoperation with SIP and related standards for audio > >> and video is > >>> required. However, backwards > >>>> compatibility with existing non-standards compliant telepresence > >>> systems is not required. > >>>>=20 > >>>> This working group is not currently chartered to work on=20 > issues of > >>> continuous conference control > >>>> including: far end camera control, indication of fast frame > >>> update for > >>> video codecs or other rapid > >>>> switches, floor control, conference roster. > >>>>=20 > >>>> Reuse of existing protocols and backwards compatibility with > >>> SIP-compliant audio/video endpoints are > >>>> important factors for the working group to consider. The=20 > work will > >>> closely coordinate with the > >>>> appropriate areas and working groups including OPS Area, > >>> AVT, MMUSIC, > >>> MEDIACTRL, XCON, and SIPCORE. > >>>>=20 > >>>> Milestones > >>>>=20 > >>>> Nov 2010 Submit information draft to IESG on use cases and > >>> requirements > >>>>=20 > >>>> Nov 2011 Submit standards track specification to IESG indicating > >>> spatial relationships of screens > >>>> cameras (including variable field of view and > >> orientation), speakers > >>> and microphones; and the "usage" > >>>> of a stream as defined in the charter. Semantics, language and > >>> transport mechanism will be specified. > >>>>=20 > >>>>=20 > >>>>=20 > >>>>=20 > >>> -------------------------------------------------------------- > >>> ---------- > >>>> -------- > >>>> -----Original Message----- > >>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >>>> Sent: Thursday, September 09, 2010 12:31 AM > >>>> To: Allyn Romanow (allyn); DISPATCH list > >>>> Subject: RE: Telepresence charter version 4 > >>>>=20 > >>>> Allyn, > >>>>=20 > >>>> Can you explain the following: > >>>> "It will consider whether the existing signaling > >> mechanisms (e. g., > >>> .... > >>>> BFCP) can be extended, or another messaging method=20 > should be used" > >>>>=20 > >>>> and > >>>>=20 > >>>> "This working group is not currently chartered to work on > >> issues of > >>>> continuous conference control including: .... floor control..." > >>>>=20 > >>>> It is unclear to me how BFCP can be within scope yet floor > >>> control is > >>>> out of scope. > >>>>=20 > >>>> John > >>>> _______________________________________________ > >>>> 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 > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > >=20 >=20 >=20 From christer.holmberg@ericsson.com Sun Oct 24 22:40:54 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FB123A6939 for ; Sun, 24 Oct 2010 22:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.054 X-Spam-Level: X-Spam-Status: No, score=-6.054 tagged_above=-999 required=5 tests=[AWL=0.545, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wP3TcXfJFSHY for ; Sun, 24 Oct 2010 22:40:49 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 847B73A67A7 for ; Sun, 24 Oct 2010 22:40:48 -0700 (PDT) X-AuditID: c1b4fb39-b7b54ae000003464-d8-4cc518c7ea0b Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id B3.08.13412.7C815CC4; Mon, 25 Oct 2010 07:42:31 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Mon, 25 Oct 2010 07:42:30 +0200 From: Christer Holmberg To: Cullen Jennings Date: Mon, 25 Oct 2010 07:40:50 +0200 Thread-Topic: [dispatch] I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt Thread-Index: ActyvBHJ0YGajZnzRrWZ3HNtWXa8bABSxzPt Message-ID: <7F2072F1E0DE894DA4B517B93C6A058502C717F2@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05851B8654@ESESSCMS0356.eemea.ericsson.se>, <8DD97253-F7BC-4553-8303-4DB9FDD5D9F4@cisco.com> In-Reply-To: <8DD97253-F7BC-4553-8303-4DB9FDD5D9F4@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH list Subject: Re: [dispatch] I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 05:40:54 -0000 Hi, >Uh, same as Paul, sorry, ignore my previous email. Don't know how I missed= this on first search. Thank you for sending the pointer to this. > >What is the sate of this 3GPP doc and what is going on with the registrati= on? The document is stable. A reason the package hasn't been registered yet mig= ht be that people assume the info-event draft has to become RFC first. But, if that is not the case, I can inform people that the package can be r= egistered. Regards, Christer On Aug 24, 2010, at 9:57 PM, Christer Holmberg wrote: > > Hi, > > The package definition can be found in Annex P of 3GPP TS 24.229: > > http://www.3gpp.org/ftp/Specs/archive/24_series/24.229/24229-a00.zip > > The MIME body used by the package to transport the digits is defined in A= nnex G of 3GPP TS 29.163 (it re-uses a body used for overlap dialling, in c= ase the wording confuses): > > http://www.3gpp.org/ftp/Specs/archive/29_series/29.163/29163-920.zip > > Regards, > > Christer > > > >> -----Original Message----- >> From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] >> Sent: 25. elokuuta 2010 6:47 >> To: Christer Holmberg; Parthasarathi R (partr); Paul Kyzivat >> (pkyzivat) >> Cc: dispatch@ietf.org; Hadriel Kaplan >> Subject: RE: >> [dispatch]I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt >> >> Can you please provide the pointer to the 3GPP spec >> describing this DTMF INFO package? >> >> thanks, >> Muthu >> >> |-----Original Message----- >> |From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> |Sent: Wednesday, August 25, 2010 9:05 AM >> |To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat) >> |Cc: dispatch@ietf.org; Hadriel Kaplan; Muthu ArulMozhi Perumal >> (mperumal) >> |Subject: RE: >> [dispatch]I-DAction:draft-kaplan-dispatch-info-dtmf-package- >> |00.txt >> | >> | >> |Hi, >> | >> |>1) whether 3GPP DTMF Info package is in the state to be accepted as >> IETF >> |standards. >> | >> |The Info Package registration procedure requires an expert review, >> which >> |purpose is to ensure that the Info Package does not break the SIP >> protocol >> |etc. I assume such review will take place when the package is >> registered >> |with IANA. >> | >> |Regards, >> | >> |Christer >> | >> | >> | >> | >> |________________________________ >> | >> | From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> | Sent: Wed 8/25/2010 8:45 AM >> | To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat) >> | Cc: dispatch@ietf.org; Hadriel Kaplan; Muthu ArulMozhi Perumal >> |(mperumal) >> | Subject: RE: >> [dispatch]I-DAction:draft-kaplan-dispatch-info-dtmf- >> |package-00.txt >> | >> | >> | >> | >> | Hi, >> | >> | >In case IMS needs new INFO based DTMF relay mechanism, I agree >> that >> |it is the valid requirement and we need to evaluate it. Before >> concluding >> |about new >> | >INFO based mechanism in IMS, Please throw the light for not >> selecting >> |KPML in IMS. I'm comparing KPML vs INFO based mechanism as both are >> based on >> |SIP >> | >signaling based mechanism. KPML has limited deployment as >> mentioned >> |in Hadriel Info draft but new INFO package is yet to be >> defined. It is >> |better to have >> | >the single active IETF SIP signaling based dtmf-relay >> mechanism >> |rather than producing more standards wherein implementers will >> completely >> |confused which >> | >one to select. >> | > >> | >As Muthu mentioned, I also heard about KPML deployment issues >> but the >> |legacy INFO based dtmf-relay has lot more caveats. I guess that Info >> package >> |is >> | >designed as generic as KPML, and then both KPML and INFO may >> look >> |heavyweight. >> | >> | The 3GPP DTMF Info Package is very simple. >> | >> | Regards, >> | >> | Christer >> | >> | >> | >> | >> | ________________________________ >> | >> | From: dispatch-bounces@ietf.org on behalf of Paul >> Kyzivat >> |(pkyzivat) >> | Sent: Wed 8/25/2010 12:17 AM >> | To: Christer Holmberg >> | Cc: dispatch@ietf.org; Hadriel Kaplan >> | Subject: Re: [dispatch]I-D >> Action:draft-kaplan-dispatch-info- >> |dtmf-package-00.txt >> | >> | >> | >> | >> | >> | Christer Holmberg wrote: >> | > Hi, >> | > >> | > I think it is strange to reject something based on a >> claim >> |there already exists a number of legacy ways of there. Not >> everyone has >> |implemented the same (if any) of them, and the whole purpose of the >> Info >> |Package framework is to come up with a mechanism for which the usage >> can be >> |negotiated. >> | > >> | > And, as I said earlier, at least in IMS an Info >> Package is >> |being used for DTMF transport. It is currently defined in 3GPP >> |specifications, but there shouldn't be anything IMS specific >> about the >> |package itself. >> | >> | I wasn't asserting a general principle. >> | I was talking about this particular mechanism. >> | >> | If there is yet another dtmf package, then I guess we >> can >> |consider the >> | pros/cons of it. Those are probably best assessed by >> those who >> |use the >> | existing one and/or might use whatever info package you >> might >> |propose to >> | replace it. >> | >> | We clearly suffer from a surplus of ways to convey dtmf. >> | While its not impossible to argue than another >> one would >> |improve the >> | situation, it is going to be a hard sell. >> | >> | OTOH, the more there are the more case it makes for >> having an >> |SBC in the >> | path to "fix" the interoperability. We sell them, so >> maybe I >> |should be >> | cheering on every new one as a way to boost sales. >> | >> | Thanks, >> | Paul >> | >> | > Regards, >> | > >> | > Christer >> | > >> | > >> | > >> | >> -----Original Message----- >> | >> From: dispatch-bounces@ietf.org >> | >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul >> |Kyzivat >> | >> Sent: 24. elokuuta 2010 18:51 >> | >> To: Hadriel Kaplan >> | >> Cc: dispatch@ietf.org >> | >> Subject: Re: [dispatch] I-D >> | >> Action:draft-kaplan-dispatch-info-dtmf-package-00.txt >> | >> >> | >> Maybe we should ask our ADs if they have an opinion >> about >> |this. >> | >> >> | >> Thanks, >> | >> Paul >> | >> >> | >> Hadriel Kaplan wrote: >> | >>>> -----Original Message----- >> | >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> | >>>> Sent: Monday, August 23, 2010 6:02 PM >> | >>>> To: Hadriel Kaplan >> | >>>> >> | >>>> That reduces things somewhat. But if >> everybody that >> |supports the >> | >>>> package also supports the legacy approach, what is >> the >> |win? >> | >>> The legacy mode has no published standards document >> | >> defining it. I thought when the info-packages work >> was >> | >> started, DTMF-in-info was one of the main drivers. >> But I >> | >> take your point - if people would prefer to just >> document >> |it >> | >> as it is today (sans info-packages), I can change the >> draft >> | >> to just be that. I'm cool with either way (defining >> the >> | >> current dtmf-relay as a legacy mode was Option-2). >> | >>> -hadriel >> | >>> >> | >> _______________________________________________ >> | >> 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 >> | >> | >> | >> >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch= From magnus.westerlund@ericsson.com Mon Oct 25 01:44:17 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A32953A6778 for ; Mon, 25 Oct 2010 01:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.492 X-Spam-Level: X-Spam-Status: No, score=-106.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8gGzF8WJL9Q for ; Mon, 25 Oct 2010 01:44:16 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id DAA8F3A68B0 for ; Mon, 25 Oct 2010 01:44:15 -0700 (PDT) X-AuditID: c1b4fb39-b7b54ae000003464-3f-4cc543c6fb91 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id A7.C3.13412.6C345CC4; Mon, 25 Oct 2010 10:45:58 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Oct 2010 10:45:58 +0200 Received: from [147.214.183.82] ([147.214.183.82]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Oct 2010 10:45:57 +0200 Message-ID: <4CC543C5.1010004@ericsson.com> Date: Mon, 25 Oct 2010 10:45:57 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: "Allyn Romanow (allyn)" References: <4CB466D5.8060601@ericsson.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02A47987@xmb-sjc-221.amer.cisco.com> <4CC41297.5090204@ericsson.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02BB1882@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02BB1882@xmb-sjc-221.amer.cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 25 Oct 2010 08:45:57.0676 (UTC) FILETIME=[0AF4F6C0:01CB7421] X-Brightmail-Tracker: AAAAAA== Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comments on the proposed Telepresence Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 08:44:17 -0000 Allyn Romanow (allyn) skrev 2010-10-25 02:24: > Hi Magnus - > > I agree with you that the issues you bring up need to be dealt with, and I feel they should potentially result in requirements from this working group. > > With respect in particular to your next to last paragraph below, did you not think that my proposed change to the charter (as Peter quoted), covered your concern? > > "also propose the following addition: > This working group is not currently chartered to work on issues of continuous conference control including: far end camera control, indication of fast frame update for video codecs or other rapid switches, floor control, conference roster. The working group may identify interoperability obstacles in existing open standards. If so, the WG will develop requirements to be communicated to other IETF WGs or Standards Forums as a kind request to try to meet these requirements." Ok, I missed that proposal. That seems fine, except that I would possibly add that a recharter is one possible way of realizing the requirements? cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From allyn@cisco.com Mon Oct 25 12:13:35 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAADC3A6784 for ; Mon, 25 Oct 2010 12:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6LuclMs6AVl for ; Mon, 25 Oct 2010 12:13:33 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id B17273A6867 for ; Mon, 25 Oct 2010 12:13:31 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIt0xUyrRN+K/2dsb2JhbAChT3GiCZxRAoJxglUEhFSJBQ X-IronPort-AV: E=Sophos;i="4.58,237,1286150400"; d="scan'208";a="609538158" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 25 Oct 2010 19:15:17 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o9PJFHHF022869; Mon, 25 Oct 2010 19:15:17 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Oct 2010 12:15:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Oct 2010 12:15:02 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02C59B38@xmb-sjc-221.amer.cisco.com> In-Reply-To: <4CC543C5.1010004@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Comments on the proposed Telepresence Charter Thread-Index: Act0IQ6R3+jligZhTEe2VSuiIDVY7QAUyAGw References: <4CB466D5.8060601@ericsson.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02A47987@xmb-sjc-221.amer.cisco.com> <4CC41297.5090204@ericsson.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02BB1882@xmb-sjc-221.amer.cisco.com> <4CC543C5.1010004@ericsson.com> From: "Allyn Romanow (allyn)" To: "Magnus Westerlund" X-OriginalArrivalTime: 25 Oct 2010 19:15:16.0875 (UTC) FILETIME=[F5317DB0:01CB7478] Cc: dispatch@ietf.org Subject: Re: [dispatch] Comments on the proposed Telepresence Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 19:13:36 -0000 Okay, how about This working group is not currently chartered to work on issues of = continuous conference control including: far end camera control, = indication of fast frame update for video codecs or other rapid = switches, floor control, conference roster. The working group may = identify interoperability obstacles in existing open standards. If so, = the WG will develop requirements to be communicated to other IETF = WGs or Standards Forums, or recharter as appropriate." -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: Monday, October 25, 2010 1:46 AM To: Allyn Romanow (allyn) Cc: Peter Musgrave; dispatch@ietf.org Subject: Re: [dispatch] Comments on the proposed Telepresence Charter Allyn Romanow (allyn) skrev 2010-10-25 02:24: > Hi Magnus - >=20 > I agree with you that the issues you bring up need to be dealt with, = and I feel they should potentially result in requirements from this = working group. >=20 > With respect in particular to your next to last paragraph below, did = you not think that my proposed change to the charter (as Peter quoted), = covered your concern? >=20 > "also propose the following addition: > This working group is not currently chartered to work on issues = of continuous conference control including: far end camera = control, indication of fast frame update for video codecs or other rapid = switches, floor control, conference roster. The working group may = identify interoperability obstacles in existing open standards. If so, = the WG will develop requirements to be communicated to other IETF = WGs or Standards Forums as a kind request to try to meet these = requirements." Ok, I missed that proposal. That seems fine, except that I would possibly add that a recharter is one possible way of realizing the requirements? cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From allyn@cisco.com Mon Oct 25 15:57:23 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D138E3A690C for ; Mon, 25 Oct 2010 15:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.408 X-Spam-Level: X-Spam-Status: No, score=-10.408 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtzzzLHBl5FS for ; Mon, 25 Oct 2010 15:57:15 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 58E283A6C00 for ; Mon, 25 Oct 2010 15:57:10 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAM+oxUyrR7Ht/2dsb2JhbACBRaAOcaMMnFKCc4JVBIFagnqJBQ X-IronPort-AV: E=Sophos;i="4.58,238,1286150400"; d="scan'208,217";a="206522420" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 25 Oct 2010 22:58:56 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9PMwut1000708 for ; Mon, 25 Oct 2010 22:58:56 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Oct 2010 15:58:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: AEMn AkyS Ap0Q Be9n BrMs Btb/ Bx6F DRlk EROB EtDq FMD7 Fvbb GG+l GOkF GkGU H/YO; 1; ZABpAHMAcABhAHQAYwBoAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {2511A029-8474-426D-B98F-0E60431E3C77}; YQBsAGwAeQBuAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Mon, 25 Oct 2010 22:58:49 GMT; VABlAGwAZQBwAHIAZQBzAGUAbgBjAGUAIABjAGgAYQByAHQAZQByACAAdgBlAHIAcwBpAG8AbgAgADYA MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB7498.337DB4CC" x-cr-puzzleid: {2511A029-8474-426D-B98F-0E60431E3C77} Content-class: urn:content-classes:message Date: Mon, 25 Oct 2010 15:58:49 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02C59C7C@xmb-sjc-221.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Telepresence charter version 6 Thread-Index: Act0mC+au5LgrKDkRH+R861i7OrkWg== From: "Allyn Romanow (allyn)" To: X-OriginalArrivalTime: 25 Oct 2010 22:58:56.0079 (UTC) FILETIME=[33A985F0:01CB7498] Subject: [dispatch] Telepresence charter version 6 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 22:57:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB7498.337DB4CC Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In preparation for discussion in DISPATCH meeting, here are the changes since the last draft. They include: =20 Changes from Version 5 * Editorial comments from Jonathan Lennox * Christer Holmberg - "In addition, standardization work, in order to be able to exchange semantic information about what each media stream represents, might be needed." Propose leave out sentence * Magnus Westerlund - include transmitting system, add WG chartered to make requirements for TP interoperability to distribute or handle as appropriate * Ted Hardie - early milestone, use case without participants (use case draft) * Minor editorial changes ------------------------ =20 MAITAI - Multi-stream Attributes for Improving Telepresence Application Interoperability CLUE -- ControLling mUltiple streams for tElepresence =20 In the context of this WG, the term telepresence is used in a general manner to describe systems that provide high definition, high quality audio/video enabling a "being-there" experience. One example is an immersive telepresence system using specially designed and special purpose rooms with multiple displays permitting life size image reproduction using multiple cameras, encoders, decoders, microphones and loudspeakers. =20 Current telepresence systems are based on open standards such as RTP, SIP, H.264, the H.323 suite. However, they cannot easily interoperate with each other without operator assistance and expensive additional equipment which translates from one vendor to another. A major factor limiting the interoperability of telepresence systems is the lack of a standardized way to describe and negotiate the use of the multiple streams of audio and video comprising the media flows. =20 The WG will create specifications for SIP-based conferencing systems to enable communication of information about media streams so that a sending system, receiving system, or intermediate system can make reasonable decisions about transmitting, selecting, and rendering media streams. This enables systems to make choices that optimize user experience. =20 This working group is chartered to specify information about media streams from one entity to another entity:=20 =20 * Spatial relationships of cameras, displays, microphones, and speakers - relative to each other and to likely positions of participants =20 * Specific characteristics such as viewpoint, field of view/capture for camera/microphone/display/speaker - so that senders and intermediate devices can understand how best to compose streams for receivers, and the receiver will know the characteristics of its received streams =20 * Usage of the stream, for example whether the stream is presentation, or document camera output =20 * Aspect ratio of cameras and displays=20 =20 *Which sources a receiver wants to receive. For example, it might want the source for the left camera, or might want the source chosen by VAD (Voice Activity Detection) =20 Information between sources and sinks about media stream capabilities will be exchanged.=20 =20 The working group will define the semantics, syntax, and transport mechanism necessary for communicating the necessary information. It will consider whether the existing signaling mechanisms (e. g., SDP) can be extended, or another messaging method should be used. =20 =20 The scope of the work includes describing relatively static relations between entities (participants and devices). It also includes handling more dynamic relationships, such as identifying the audio and video streams for the current speaker. The scope includes both systems that provide a fully immersive experience, and systems that interwork with them and therefore need to understand the same multiple stream semantics. =20 =20 The focus of this work is on multiple audio and video streams. Other media types may be considered, however development of methodologies for them is not within the scope of this work. =20 Interoperation with SIP and related standards for audio and video is required. However, backwards compatibility with existing non-standards compliant telepresence systems is not required. =20 This working group is not currently chartered to work on issues of continuous conference control including: far end camera control, indication of fast frame update for video codecs or other rapid switches, floor control, conference roster. The working group may identify interoperability obstacles in existing open standards. If so, the WG will develop requirements to be communicated to other IETF WGs or Standards Forums, or recharter as appropriate. =20 Reuse of existing protocols and backwards compatibility with SIP-compliant audio/video endpoints are important factors for the working group to consider. The work will closely coordinate with the appropriate areas (e. g., OPS, SEC), and working groups including AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE. =20 Milestones =20 =20 July 2011 Submit informational draft to IESG on use cases=20 =20 July 2011 Submit informational draft to IESG on framework and requirements =20 Nov 2011 Submit standards track specification(s) to IESG to support framework and requirements =20 ------_=_NextPart_001_01CB7498.337DB4CC Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

In preparation for discussion in DISPATCH meeting, = here are the changes since the last draft. They include:

 

Changes from Version 5

·         Editorial comments from Jonathan Lennox

·         Christer Holmberg – “In addition, standardization work, in order to = be able to exchange semantic information about what each media stream = represents, might be needed.”

      Propose leave out sentence

·         Magnus Westerlund – include transmitting system, add WG chartered to make requirements for TP interoperability to distribute or handle as = appropriate

·         Ted Hardie – early milestone, use case without participants  (use = case draft)

·         Minor editorial changes

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

 

MAITAI – Multi-stream Attributes for = Improving Telepresence Application Interoperability

CLUE -- ControLling mUltiple streams for = tElepresence

 

In the context of this WG, the term telepresence is = used in a general manner to describe systems that provide high definition, high = quality audio/video enabling a "being-there" experience.  One = example is an immersive telepresence system using specially designed and special = purpose rooms with multiple displays permitting life size image reproduction = using multiple cameras, encoders, decoders, microphones and = loudspeakers.

 

Current telepresence systems are based on open = standards such as RTP, SIP, H.264, the H.323 suite. However, they cannot easily = interoperate with each other without operator assistance and expensive additional = equipment which translates from one vendor to another. A major factor limiting the interoperability of telepresence systems  is the lack of a = standardized way to describe and negotiate the use of the multiple streams of audio = and video comprising the media flows.

 

The WG will create specifications for SIP-based = conferencing systems to enable communication of  information about media streams = so that a sending system,  receiving system, or intermediate system = can make reasonable decisions about transmitting, selecting, and rendering media streams. This enables systems to make choices that optimize user experience.

 

This working group is chartered to specify  information about media streams from one entity to = another entity:

 

* Spatial relationships of cameras, displays, = microphones, and speakers – relative to each other and to likely positions of participants

 

* Specific characteristics such as viewpoint, field = of view/capture for camera/microphone/display/speaker – so that = senders and intermediate devices can understand how best to compose streams for receivers, and = the receiver will know the characteristics of its received = streams

 

* Usage of the stream, for example whether the stream is presentation, or document = camera output

 

* Aspect ratio of cameras and displays =

 

*Which sources a receiver wants to receive.  = For example, it might  want the source for the left camera, or might = want the source chosen by VAD (Voice Activity Detection)

 

Information between sources and sinks about media = stream capabilities will be exchanged. 

 

The working group will define the semantics, = syntax, and transport mechanism necessary for communicating the necessary = information. It will consider whether the existing signaling mechanisms (e. g., SDP) can = be extended, or another messaging method should be used. =  

 

The scope of the work includes describing = relatively static relations between entities (participants and devices). It also includes handling more dynamic relationships, such as identifying the audio and = video streams for the current speaker. The scope includes both systems that = provide a fully immersive experience, and systems that interwork with them and = therefore need to understand the same multiple stream semantics. =  

 

The focus of this work is on multiple audio and = video streams.  Other media types may be considered, however development = of methodologies for them is not within the scope of this = work.

 

Interoperation with SIP and related standards for = audio and video is required.  However, backwards compatibility with existing non-standards compliant telepresence systems is not = required.

 

This working group is not currently chartered to = work on issues of continuous conference control including: far end camera = control, indication of fast frame update for video codecs or other rapid = switches, floor control, conference roster. The working group may identify = interoperability obstacles in existing open standards. If so, the WG will develop = requirements to be communicated to other IETF WGs or Standards Forums, or recharter = as appropriate.

 

Reuse of existing protocols and backwards = compatibility with SIP-compliant audio/video endpoints are important factors for the = working group to consider. The work will closely coordinate with the appropriate areas = (e. g., OPS, SEC), and working groups including  AVT, MMUSIC, = MEDIACTRL, XCON, and SIPCORE.

 

 Milestones  

 

July 2011 Submit informational draft to IESG on use = cases

 

July 2011 Submit informational draft to IESG on = framework and requirements

 

Nov 2011 Submit standards track specification(s) to = IESG to support framework and requirements

 =

------_=_NextPart_001_01CB7498.337DB4CC-- From pkyzivat@cisco.com Tue Oct 26 07:26:22 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B08963A6818 for ; Tue, 26 Oct 2010 07:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.788 X-Spam-Level: X-Spam-Status: No, score=-107.788 tagged_above=-999 required=5 tests=[AWL=-2.611, BAYES_50=0.001, CN_BODY_35=0.339, CN_BODY_509=0.029, CN_BODY_832=0.004, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtbV-dOzBYzr for ; Tue, 26 Oct 2010 07:26:21 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 1C70A3A6844 for ; Tue, 26 Oct 2010 07:26:21 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABOCxkxAZnwN/2dsb2JhbACDH54vcaQaiiQIkgkCgRyDMngEhDtxhSeDCA X-IronPort-AV: E=Sophos;i="4.58,241,1286150400"; d="scan'208";a="175135840" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 26 Oct 2010 14:28:08 +0000 Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o9QES8Ph026970; Tue, 26 Oct 2010 14:28:08 GMT Message-ID: <4CC6E578.6090806@cisco.com> Date: Tue, 26 Oct 2010 10:28:08 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: Lili Yang_lili References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Cc: "dispatch@ietf.org" , Spencer Dawkins Subject: Re: [dispatch] Asking comments for draft-yang-dispatch-sip-connection-address-type X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 14:26:22 -0000 Lili, I guess there is growing interest in involving a separate video device in a call, because I have seen several different proposals for how to do it. Regarding this draft - from a technical perspective, because it proposes a change to SDP, it should probably be discussed in MMUSIC. But given that it competes with other proposed mechanisms that are not entirely SDP, perhaps dispatch is a good place for it. I don't understand the premise of this draft - that the party sending the offer doesn't know the address of the media stream - only the sip URI, and that therefore the other party should use the sip address to establish the media stream. Some UA will presumably have to establish a separate sip dialog in order to determine the media capabilities and address. The question is which UA should it be. I see no advantage in delegating this responsibility from the device that knows the SIP URI to the other unsuspecting party. Doing so reduces the likelihood of a successful call by imposing additional requirements on the other party. I see no particular advantage to this approach over: - Alice calls Anna's device sip:anna@example2.net - Alice discovers Anna's device video address and codecs - Alice combines that video information with her own audio information into an offer to Bob. (I'm glossing over the details here. But its well understood 3pcc.) In that way, Bob's device need have no particular capabilities other than the ability to support video and some video codec in common with Anna's device. Thanks, Paul On 10/26/2010 8:04 AM, Lili Yang_lili wrote: > Hello Paul, > > I am Lili Yang from Huawei. > > Georg Mayer and I wrote an I-D > (http://tools.ietf.org/html/draft-yang-dispatch-sip-connection-address-type) > , which is related to a current 3GPP Rel-10 feature, namely > Inter-UE-Transfer for cases when a so-called collaborative session is > established during a SIP session establishment. > > So far we did not receive any feed-back from IETF list on the draft and > we would like to hear your point of view. > > I will attend the upcoming IETF#79 Beijing meeting, and it¡¯s appreciated > if you have some time to discuss the draft during the meeting. > > Looking forward to your feedback! > > Thanks and best regards, > > Lili > > ------------------------------------------------------------------------ > > Lili Yang > »ªÎª¼¼ÊõÓÐÏÞ¹«Ë¾Huawei Technologies Co., Ltd. > Company_logo > > Phone: +86-755-28422553 > Fax: +86-755-28420413 > Mobile:+86-13632632065 > Email: Lili.yang@huawei.com > µØÖ·£ºÉîÛÚÊÐÁú¸ÚÇøÛàÌﻪΪ»ùµØÓʱࣺ518129 > Huawei Technologies Co., Ltd. > Bantian, Longgang District,Shenzhen 518129, P.R.China > http://www.huawei.com > > ------------------------------------------------------------------------ > > ±¾Óʼþ¼°Æ丽¼þº¬ÓлªÎª¹«Ë¾µÄ±£ÃÜÐÅÏ¢£¬½öÏÞÓÚ·¢Ë͸øÉÏÃæµØÖ·ÖÐÁгöµÄ¸öÈË»ò > Ⱥ×é¡£½û > Ö¹ÈκÎÆäËûÈËÒÔÈκÎÐÎʽʹÓ㨰üÀ¨µ«²»ÏÞÓÚÈ«²¿»ò²¿·ÖµØй¶¡¢¸´ÖÆ¡¢»òÉ¢·¢£© > ±¾ÓʼþÖÐ > µÄÐÅÏ¢¡£Èç¹ûÄú´íÊÕÁ˱¾Óʼþ£¬ÇëÄúÁ¢¼´µç»°»òÓʼþ֪ͨ·¢¼þÈ˲¢É¾³ý±¾Óʼþ£¡ > This e-mail and its attachments contain confidential information from > HUAWEI, which > is intended only for the person or entity whose address is listed above. > Any use of the > information contained herein in any way (including, but not limited to, > total or partial > disclosure, reproduction, or dissemination) by persons other than the > intended > recipient(s) is prohibited. If you receive this e-mail in error, please > notify the sender by > phone or email immediately and delete it! > From magnus.westerlund@ericsson.com Tue Oct 26 07:56:04 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FD2D3A699C for ; Tue, 26 Oct 2010 07:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.696 X-Spam-Level: X-Spam-Status: No, score=-106.696 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5YbJx+JPLoF for ; Tue, 26 Oct 2010 07:55:53 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 6D3453A68E6 for ; Tue, 26 Oct 2010 07:55:50 -0700 (PDT) X-AuditID: c1b4fb39-b7b54ae000003464-1c-4cc6ec611b25 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 86.D1.13412.16CE6CC4; Tue, 26 Oct 2010 16:57:37 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Oct 2010 16:57:37 +0200 Received: from [153.88.46.183] ([153.88.46.183]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Oct 2010 16:57:36 +0200 Message-ID: <4CC6EC5E.8010101@ericsson.com> Date: Tue, 26 Oct 2010 16:57:34 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: "Allyn Romanow (allyn)" References: <4CB466D5.8060601@ericsson.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02A47987@xmb-sjc-221.amer.cisco.com> <4CC41297.5090204@ericsson.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02BB1882@xmb-sjc-221.amer.cisco.com> <4CC543C5.1010004@ericsson.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02C59B38@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC02C59B38@xmb-sjc-221.amer.cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 26 Oct 2010 14:57:36.0591 (UTC) FILETIME=[208F1DF0:01CB751E] X-Brightmail-Tracker: AAAAAA== Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comments on the proposed Telepresence Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 14:56:04 -0000 Allyn Romanow (allyn) skrev 2010-10-25 21:15: > Okay, how about > > This working group is not currently chartered to work on issues of continuous conference control including: far end camera control, indication of fast frame update for video codecs or other rapid switches, floor control, conference roster. The working group may identify interoperability obstacles in existing open standards. If so, the WG will develop requirements to be communicated to other IETF WGs or Standards Forums, or recharter as appropriate." Yes, that sounds good. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From 2mkristensen@gmail.com Tue Oct 26 14:29:52 2010 Return-Path: <2mkristensen@gmail.com> X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C9BA3A68DC for ; Tue, 26 Oct 2010 14:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ArsZOmbI5Se for ; Tue, 26 Oct 2010 14:29:38 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 28A863A68CE for ; Tue, 26 Oct 2010 14:29:08 -0700 (PDT) Received: by qwb7 with SMTP id 7so3066805qwb.31 for ; Tue, 26 Oct 2010 14:30:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=bKltz15Vwj7dNkOyJUAQRfqL1J6+/758DaRtrspxsSo=; b=mM+pqQatoZ9Bo6umd0Y4A3w81TaMCy8pBVOfLVJLAoydn1qpi7Vm7LufLmKc5T6UPS jjkgeJeQ4erBH0uxWhgTuNkhK+d9CpN41pwckHtHFa0wH/VD01KYUMUES3ol10aduKGm nq03EfhyB8yS/QFOiNZutU2dC5hc3M/Vfwp0w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=wqguVcjcCHDc/T0syHrFqIcQYIKmD1/wWuvksHYUu3jgQSa8x1dYKZes3gVatJPNrt RnZkhm19qcknphApzyTrlZllqwJeU5PlH+zqFGugkmROeX90S1WmvOa9M/QhLAc14/FY wxv6mBgyIKb2Y06mzN7BJJ19XSdovX19VBLl4= MIME-Version: 1.0 Received: by 10.229.241.12 with SMTP id lc12mr8265130qcb.178.1288128652632; Tue, 26 Oct 2010 14:30:52 -0700 (PDT) Received: by 10.229.13.16 with HTTP; Tue, 26 Oct 2010 14:30:52 -0700 (PDT) In-Reply-To: <20101025214502.6B3243A68D3@core3.amsl.com> References: <20101025214502.6B3243A68D3@core3.amsl.com> Date: Tue, 26 Oct 2010 23:30:52 +0200 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: DISPATCH list Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Tom Kristensen Subject: Re: [dispatch] I-D Action:draft-sandbakken-dispatch-bfcp-udp-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 21:29:53 -0000 On 25 October 2010 23:45, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Revision of the Binary Floor C= ontrol Protocol (BFCP) for use over an unreliable transport > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : T. Kristensen, et al. > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-sandbakken-dispatch-bfcp-u= dp-01.txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 26 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2010-10-25 > > This memo extends the Binary Floor Control Protocol (BFCP) for use > over an unreliable transport. =A0It details a set of revisions to the > protocol definition document and the specification of Session > Description Protocol (SDP) format for BFCP streams. > > A URL for this Internet-Draft is: http://tools.ietf.org/html/draft-sandbakken-dispatch-bfcp-udp-01 We managed to submit this version before the IETF-79 great wall surrounded the draft submission tool yesterday. This is the basis for the planned UDP/BFCP presentation/discussion at the Dispatch meeting in Beijing: http://tools.ietf.org/wg/dispatch/agenda Changes from -00: http://tools.ietf.org/html/draft-sandbakken-dispatch-bfcp-udp-01#appendix= -A Most notable changes: - Removed the - too verbose and not directly related - rationale/ motivation text describing background and why other approaches where not chosen. Focus on the actual extensions. - Not mandate ICE as a SHALL, but leave it as a non-mandatory way of solving the potential need for NAT/FW traversal. - Emphasized that the reference to DTLS-SRTP are merely informational. - Decision made to not increase the protocol version number as a result of this extension. -- Tom From dyork@voxeo.com Tue Oct 26 17:55:04 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0EBF3A68D2 for ; Tue, 26 Oct 2010 17:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.999 X-Spam-Level: X-Spam-Status: No, score=-100.999 tagged_above=-999 required=5 tests=[AWL=0.999, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id suuHYDJTaqdw for ; Tue, 26 Oct 2010 17:55:01 -0700 (PDT) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with ESMTP id 953663A68F3 for ; Tue, 26 Oct 2010 17:55:00 -0700 (PDT) Received: from [74.70.78.98] (account dyork@voxeo.com HELO pc-00148.lodestar2.local) by voxeo.com (CommuniGate Pro SMTP 5.3.8) with ESMTPSA id 73942775; Wed, 27 Oct 2010 00:56:47 +0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-1-596152662 From: Dan York In-Reply-To: <4CBDFCB8.302@stpeter.im> Date: Tue, 26 Oct 2010 20:56:37 -0400 Message-Id: References: <4CBDFCB8.302@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1081) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] proposed SIXPAC charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 00:55:04 -0000 --Apple-Mail-1-596152662 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I definitely support this work. I've been involved lately in several = instances where both SIP and XMPP were included on the client side. Any = work that can help make the user experience more positive would be a = good thing. Regards, Dan On Oct 19, 2010, at 4:16 PM, Peter Saint-Andre wrote: > Earlier this year, some folks in the RAI area proposed an initiative = to > define a few small extensions to both SIP and XMPP that would make it > easier to develop and deploy dual-stack SIP+XMPP endpoints. Based on > feedback provided on the DISPATCH list and received from the RAI ADs, > I've taken the liberty of rewriting the proposed charter, in the hopes > that fresh text will spur a more conclusive discussion. I'm mostly = just > trying to help the proponents put their best foot forward, so if folks > here have more feedback I'd expect that people like Simo Veikkolainen > and Emil Ivov will be able to engage in further discussion. >=20 > /psa >=20 > ### >=20 > SIXPAC (SIP Integration with XMPP in Presence Aware Clients) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Problem Statement >=20 > Both the Session Initiation Protocol (SIP) and the Extensible = Messaging > and Presence Protocol (XMPP) are widely deployed technologies for > real-time communication over the Internet. In order to offer a = complete > suite of features as well as communication across multiple networks, > several user-oriented software applications support both SIP and XMPP, > and more software developers have expressed interest in building such > "dual-stack" solutions. Unfortunately, it is difficult to provide a > good end-user experience in such applications because SIP and XMPP are > not aware of each other. For example: >=20 > - XMPP presence does not include availability states related to a SIP > voice call or video call (e.g., "on the phone"), thus preventing an > a dual-stack endpoint from showing presence-based communication hints >=20 > - There is no correlation between an XMPP IM session and a SIP voice > or video session, thus preventing a dual-stack endpoint from = providing > integrated user interfaces and communications history >=20 > - SIP accounts and XMPP accounts are not directly correlated in = contact > lists or vCards (and not all deployed services support storage of = such > information), thus preventing a dual-stack endpoint from knowing that > a contact has both SIP and XMPP capabilities >=20 > Although some proprietary solutions exist to the foregoing problems, = it > would be preferable to define standardized solutions for the sake of > improved interoperability. >=20 > Objectives >=20 > Because both SIP and XMPP are easily extended through new SIP headers > and XMPP elements, it should be possible to provide tighter = integration > within dual-stack SIP/XMPP user agents to improve the user experience. >=20 > Any such extensions should meet the following criteria: >=20 > - Be completely optional and backwards-compatible for all endpoints >=20 > - Work without changes to deployed infrastructure such as existing > SIP and XMPP servers, B2BUAs, firewalls, etc. >=20 > The SIXPAC WG will define a small number of SIP and XMPP extensions to > solve the following use cases in dual-stack endpoints: >=20 > - Including SIP-based availability states in XMPP presence (limited to > basic presence and availability states only, not the full range of > PIDF extensions) >=20 > - Correlating an XMPP IM session with a SIP voice/video session, and > vice-versa >=20 > - Advertising a SIP account address over XMPP and an XMPP account > address over SIP >=20 > Additional use cases are out of scope, including anything related to = or > requiring server integration, multiparty communication, SIP-based IM > and presence, XMPP-based voice and video, file transfer, generalized > service discovery and capabilities exchange, full protocol translation > in communication gateways, shared credentials across both SIP and XMPP > accounts, rich presence extensions for features such as geolocation, > etc. Although such topics are important and interesting, they are out > of scope for this group. >=20 > However, in addition to the protocol extensions explicitly mentioned > above, the group may also define best practices related to the > implementation and deployment of dual-stack SIP/XMPP endpoints, > including topics such as user agent configuration. >=20 > Deliverables >=20 > - Use cases and protocol requirements >=20 > - XMPP presence extension for SIP-based availability states >=20 > - Media session correlation extensions for SIP and XMPP >=20 > - Contact address advertisement extensions for SIP and XMPP >=20 > - Best practices for implementation and deployment of dual-stack > endpoints >=20 > Milestones >=20 > Feb 2011 Submit use cases and protocol requirements document to > IESG (Informational) >=20 > Oct 2011 Submit XMPP presence extension document to IESG > (Standards Track) >=20 > Oct 2011 Submit media session correlation extensions document to IESG > (Standards Track) >=20 > Oct 2011 Submit contact address advertisement extension document to > IESG (Standards Track) >=20 > Oct 2011 Submit best practices document to IESG (Informational) >=20 > ### >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --=20 Dan York, Director of Conversations Voxeo Corporation http://www.voxeo.com dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork =20 Join the Voxeo conversation: Blogs: http://blogs.voxeo.com Twitter: http://twitter.com/voxeo http://twitter.com/danyork Facebook: http://www.facebook.com/voxeo --Apple-Mail-1-596152662 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = definitely support this work.  I've been involved lately in several = instances where both SIP and XMPP were included on the client side. =  Any work that can help make the user experience more positive = would be a good = thing.

Regards,
Dan

=
On Oct 19, 2010, at 4:16 PM, Peter Saint-Andre wrote:

Earlier= this year, some folks in the RAI area proposed an initiative = to
define a few small extensions to both SIP and XMPP that would make = it
easier to develop and deploy dual-stack SIP+XMPP endpoints. Based = on
feedback provided on the DISPATCH list and received from the RAI = ADs,
I've taken the liberty of rewriting the proposed charter, in the = hopes
that fresh text will spur a more conclusive discussion. I'm = mostly just
trying to help the proponents put their best foot = forward, so if folks
here have more feedback I'd expect that people = like Simo Veikkolainen
and Emil Ivov will be able to engage in = further discussion.

/psa

###

SIXPAC (SIP = Integration with XMPP in Presence Aware = Clients)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

Problem Statement

Both the Session Initiation = Protocol (SIP) and the Extensible Messaging
and Presence Protocol = (XMPP) are widely deployed technologies for
real-time communication = over the Internet.  In order to offer a complete
suite of = features as well as communication across multiple networks,
several = user-oriented software applications support both SIP and XMPP,
and = more software developers have expressed interest in building = such
"dual-stack" solutions.  Unfortunately, it is difficult to = provide a
good end-user experience in such applications because SIP = and XMPP are
not aware of each other.  For example:

- = XMPP presence does not include availability states related to a SIP
=  voice call or video call (e.g., "on the phone"), thus preventing = an
 a dual-stack endpoint from showing presence-based = communication hints

- There is no correlation between an XMPP IM = session and a SIP voice
 or video session, thus preventing a = dual-stack endpoint from providing
 integrated user interfaces = and communications history

- SIP accounts and XMPP accounts are = not directly correlated in contact
 lists or vCards (and not = all deployed services support storage of such
 information), = thus preventing a dual-stack endpoint from knowing that
 a = contact has both SIP and XMPP capabilities

Although some = proprietary solutions exist to the foregoing problems, it
would be = preferable to define standardized solutions for the sake of
improved = interoperability.

Objectives

Because both SIP and XMPP are = easily extended through new SIP headers
and XMPP elements, it should = be possible to provide tighter integration
within dual-stack SIP/XMPP = user agents to improve the user experience.

Any such extensions = should meet the following criteria:

- Be completely optional and = backwards-compatible for all endpoints

- Work without changes to = deployed infrastructure such as existing
 SIP and XMPP servers, = B2BUAs, firewalls, etc.

The SIXPAC WG will define a small number = of SIP and XMPP extensions to
solve the following use cases in = dual-stack endpoints:

- Including SIP-based availability states = in XMPP presence (limited to
 basic presence and availability = states only, not the full range of
 PIDF extensions)

- = Correlating an XMPP IM session with a SIP voice/video session, and
=  vice-versa

- Advertising a SIP account address over XMPP = and an XMPP account
 address over SIP

Additional use = cases are out of scope, including anything related to or
requiring = server integration, multiparty communication, SIP-based IM
and = presence, XMPP-based voice and video, file transfer, = generalized
service discovery and capabilities exchange, full = protocol translation
in communication gateways, shared credentials = across both SIP and XMPP
accounts, rich presence extensions for = features such as geolocation,
etc.  Although such topics are = important and interesting, they are out
of scope for this = group.

However, in addition to the protocol extensions explicitly = mentioned
above, the group may also define best practices related to = the
implementation and deployment of dual-stack SIP/XMPP = endpoints,
including topics such as user agent = configuration.

Deliverables

- Use cases and protocol = requirements

- XMPP presence extension for SIP-based availability = states

- Media session correlation extensions for SIP and = XMPP

- Contact address advertisement extensions for SIP and = XMPP

- Best practices for implementation and deployment of = dual-stack
 endpoints

Milestones

Feb 2011 =  Submit use cases and protocol requirements document to
=          IESG = (Informational)

Oct 2011  Submit XMPP presence extension = document to IESG
=          (Standards = Track)

Oct 2011  Submit media session correlation extensions = document to IESG
=          (Standards = Track)

Oct 2011  Submit contact address advertisement = extension document to
=          IESG (Standards = Track)

Oct 2011  Submit best practices document to IESG = (Informational)

###


____________________________________= ___________
dispatch mailing list
dispatch@ietf.org
https://www.iet= f.org/mailman/listinfo/dispatch

Dan York, = Director of Conversations
Voxeo Corporation   http://www.voxeo.com  dyork@voxeo.com
Phone: = +1-407-455-5859    Skype: = danyork  
<= /span>

= --Apple-Mail-1-596152662-- From pkyzivat@cisco.com Wed Oct 27 06:16:59 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F00133A6A1F for ; Wed, 27 Oct 2010 06:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.495 X-Spam-Level: X-Spam-Status: No, score=-107.495 tagged_above=-999 required=5 tests=[AWL=-2.877, BAYES_50=0.001, CN_BODY_35=0.339, CN_BODY_509=0.029, CN_BODY_832=0.004, DC_PNG_UNO_LARGO=0.558, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8PCxr5x70MD for ; Wed, 27 Oct 2010 06:16:56 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id BBAC73A686D for ; Wed, 27 Oct 2010 06:16:54 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlAFAKLDx0xAZnwM/2dsb2JhbACBRYFblmCGel9xoFiKJAiRZwKCcYFdeASFLIUngwg X-IronPort-AV: E=Sophos;i="4.58,246,1286150400"; d="scan'208,217,150";a="175755167" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 27 Oct 2010 13:18:44 +0000 Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9RDIh3G028549; Wed, 27 Oct 2010 13:18:43 GMT Message-ID: <4CC826B3.3000509@cisco.com> Date: Wed, 27 Oct 2010 09:18:43 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: Lili Yang_lili References: <4CC6E578.6090806@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070709080607020403090005" Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Asking comments for draft-yang-dispatch-sip-connection-address-type X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 13:17:00 -0000 This is a multi-part message in MIME format. --------------070709080607020403090005 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Lili - comments inline. On 10/27/2010 3:46 AM, Lili Yang_lili wrote: > > Hello Paul, > > Thanks for your feedback! > > The premise of this draft is to fulfill the specific requirement in > 3GPP. And it's a different case with the 3PCC as you mentioned. > > Concurrent with a normal session set-up towards a remote party, UE-1 > wants to establish a Collaborative Session, which is anchored at the > SCC AS, > What is an SCC? > with a new Media Flow-A on itself and a new Media Flow-B on another > UE-2. Following is the information flow defined in 3GPP: > I'd like to see the intended o/a details for each of steps 1-6 above. > And in step1, the ession setup request shall include enough > information for the SCC AS to: > > - identify that Media-A shall be established in UE-1; > > - identify that Media-B shall be established in UE-2 and the requested > media type associated with Media-B (e.g. video); > > Normally the UE-1 doesn¡¯t know the IP address of the UE-2 but only the > SIP address, hence we propose UE-1 sending the offer with the UE-2¡¯s > SIP address, to identify the requested media will be established in UE-2. > Having the above detail would allow a more informed discussion of the possibilities. (I don't have enough detail to know if this would work, but perhaps UE-1 could simply send a REFER to UE-2, with Refer-To of the SCC and a Join header.) I am much happier knowing that its the SCC, which is presumably a resource under the control of UE-1, that is doing the heavy lifting, rather than putting the burden on remote-party, which is an innocent bystander. Thanks, Paul > Hope this clarifies. > > Thanks and best regards, > > Lili > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, October 26, 2010 10:28 PM > To: Lili Yang_lili > Cc: Spencer Dawkins; 'Mayer Georg'; dispatch@ietf.org > Subject: Re: Asking comments for > draft-yang-dispatch-sip-connection-address-type > > Lili, > > I guess there is growing interest in involving a separate video device > > in a call, because I have seen several different proposals for how to > do it. > > Regarding this draft - from a technical perspective, because it proposes > > a change to SDP, it should probably be discussed in MMUSIC. But given > > that it competes with other proposed mechanisms that are not entirely > > SDP, perhaps dispatch is a good place for it. > > I don't understand the premise of this draft - that the party sending > > the offer doesn't know the address of the media stream - only the sip > > URI, and that therefore the other party should use the sip address to > > establish the media stream. > > Some UA will presumably have to establish a separate sip dialog in order > > to determine the media capabilities and address. The question is which > > UA should it be. I see no advantage in delegating this responsibility > > from the device that knows the SIP URI to the other unsuspecting party. > > Doing so reduces the likelihood of a successful call by imposing > > additional requirements on the other party. > > I see no particular advantage to this approach over: > > - Alice calls Anna's device sip:anna@example2.net > > - Alice discovers Anna's device video address and codecs > > - Alice combines that video information with her own > > audio information into an offer to Bob. > > (I'm glossing over the details here. But its well understood 3pcc.) > > In that way, Bob's device need have no particular capabilities other > > than the ability to support video and some video codec in common with > > Anna's device. > > Thanks, > > Paul > > On 10/26/2010 8:04 AM, Lili Yang_lili wrote: > > > Hello Paul, > > > > > > I am Lili Yang from Huawei. > > > > > > Georg Mayer and I wrote an I-D > > > (http://tools.ietf.org/html/draft-yang-dispatch-sip-connection-address-type) > > > , which is related to a current 3GPP Rel-10 feature, namely > > > Inter-UE-Transfer for cases when a so-called collaborative session is > > > established during a SIP session establishment. > > > > > > So far we did not receive any feed-back from IETF list on the draft and > > > we would like to hear your point of view. > > > > > > I will attend the upcoming IETF#79 Beijing meeting, and it¡¯s appreciated > > > if you have some time to discuss the draft during the meeting. > > > > > > Looking forward to your feedback! > > > > > > Thanks and best regards, > > > > > > Lili > > > > > > ------------------------------------------------------------------------ > > > > > > Lili Yang > > > »ªÎª¼¼ÊõÓÐÏÞ¹«Ë¾Huawei Technologies Co., Ltd. > > > Company_logo > > > > > > Phone: +86-755-28422553 > > > Fax: +86-755-28420413 > > > Mobile:+86-13632632065 > > > Email: Lili.yang@huawei.com > > > µØÖ·£ºÉîÛÚÊÐÁú¸ÚÇøÛàÌﻪΪ»ùµØÓʱࣺ518129 > > > Huawei Technologies Co., Ltd. > > > Bantian, Longgang District,Shenzhen 518129, P.R.China > > > http://www.huawei.com > > > > > > ------------------------------------------------------------------------ > > > > > > ±¾Óʼþ¼°Æ丽¼þº¬ÓлªÎª¹«Ë¾µÄ±£ÃÜÐÅÏ¢£¬½öÏÞÓÚ·¢Ë͸øÉÏÃæµØÖ·ÖÐÁгöµÄ¸öÈË »ò > > > Ⱥ×é¡£½û > > > Ö¹ÈκÎÆäËûÈËÒÔÈκÎÐÎʽʹÓ㨰üÀ¨µ«²»ÏÞÓÚÈ«²¿»ò²¿·ÖµØй¶¡¢¸´ÖÆ¡¢»òÉ¢ ·¢£© > > > ±¾ÓʼþÖÐ > > > µÄÐÅÏ¢¡£Èç¹ûÄú´íÊÕÁ˱¾Óʼþ£¬ÇëÄúÁ¢¼´µç»°»òÓʼþ֪ͨ·¢¼þÈ˲¢É¾³ý±¾Óʼþ£¡ > > > This e-mail and its attachments contain confidential information from > > > HUAWEI, which > > > is intended only for the person or entity whose address is listed above. > > > Any use of the > > > information contained herein in any way (including, but not limited to, > > > total or partial > > > disclosure, reproduction, or dissemination) by persons other than the > > > intended > > > recipient(s) is prohibited. If you receive this e-mail in error, please > > > notify the sender by > > > phone or email immediately and delete it! > > > > --------------070709080607020403090005 Content-Type: multipart/related; boundary="------------010308010703090009080509" --------------010308010703090009080509 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: 8bit Lili - comments inline.

On 10/27/2010 3:46 AM, Lili Yang_lili wrote:

Hello Paul,

 

Thanks for your feedback!

 

The premise of this draft is to fulfill the specific requirement in 3GPP. And it's a different case with the 3PCC as you mentioned.

Concurrent with a normal session set-up towards a remote party, UE-1 wants to establish a Collaborative Session, which is anchored at the SCC AS,


What is an SCC?

with a new Media Flow-A on itself and a new Media Flow-B on another UE-2. Following is the information flow defined in 3GPP:

 


I'd like to see the intended o/a details for each of steps 1-6 above.

And in step1, the ession setup request shall include enough information for the SCC AS to:

-        identify that Media-A shall be established in UE-1;

-        identify that Media-B shall be established in UE-2 and the requested media type associated with Media-B (e.g. video);

 

Normally the UE-1 doesn¡¯t know the IP address of the UE-2 but only the SIP address, hence we propose UE-1 sending the offer with the UE-2¡¯s SIP address, to identify the requested media will be established in UE-2.


Having the above detail would allow a more informed discussion of the possibilities.
(I don't have enough detail to know if this would work, but perhaps UE-1 could simply send a REFER to UE-2, with Refer-To of the SCC and a Join header.)

I am much happier knowing that its the SCC, which is presumably a resource under the control of UE-1, that is doing the heavy lifting, rather than putting the burden on remote-party, which is an innocent bystander.

    Thanks,
    Paul

 

Hope this clarifies.

 

Thanks and best regards,

Lili

 

 

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
Sent: Tuesday, October 26, 2010 10:28 PM
To: Lili Yang_lili
Cc: Spencer Dawkins; 'Mayer Georg'; dispatch@ietf.org
Subject: Re: Asking comments for draft-yang-dispatch-sip-connection-address-type

 

Lili,

 

I guess there is growing interest in involving a separate video device

in a call, because I have seen several different proposals for how to do it.

 

Regarding this draft - from a technical perspective, because it proposes

a change to SDP, it should probably be discussed in MMUSIC. But given

that it competes with other proposed mechanisms that are not entirely

SDP, perhaps dispatch is a good place for it.

 

I don't understand the premise of this draft - that the party sending

the offer doesn't know the address of the media stream - only the sip

URI, and that therefore the other party should use the sip address to

establish the media stream.

 

Some UA will presumably have to establish a separate sip dialog in order

to determine the media capabilities and address. The question is which

UA should it be. I see no advantage in delegating this responsibility

from the device that knows the SIP URI to the other unsuspecting party.

Doing so reduces the likelihood of a successful call by imposing

additional requirements on the other party.

 

I see no particular advantage to this approach over:

- Alice calls Anna's device sip:anna@example2.net

- Alice discovers Anna's device video address and codecs

- Alice combines that video information with her own

  audio information into an offer to Bob.

(I'm glossing over the details here. But its well understood 3pcc.)

 

In that way, Bob's device need have no particular capabilities other

than the ability to support video and some video codec in common with

Anna's device.

 

         Thanks,

         Paul

 

 

On 10/26/2010 8:04 AM, Lili Yang_lili wrote:

> Hello Paul,

>

> I am Lili Yang from Huawei.

>

> Georg Mayer and I wrote an I-D

> (http://tools.ietf.org/html/draft-yang-dispatch-sip-connection-address-type)

> , which is related to a current 3GPP Rel-10 feature, namely

> Inter-UE-Transfer for cases when a so-called collaborative session is

> established during a SIP session establishment.

>

> So far we did not receive any feed-back from IETF list on the draft and

> we would like to hear your point of view.

>

> I will attend the upcoming IETF#79 Beijing meeting, and it¡¯s appreciated

> if you have some time to discuss the draft during the meeting.

>

> Looking forward to your feedback!

>

> Thanks and best regards,

>

> Lili

>

> ------------------------------------------------------------------------

>

> Lili Yang

> »ªÎª¼¼ÊõÓÐÏÞ¹«Ë¾Huawei Technologies Co., Ltd.

> Company_logo

>

> Phone: +86-755-28422553

> Fax: +86-755-28420413

> Mobile:+86-13632632065

> Email: Lili.yang@huawei.com

> µØÖ·£ºÉîÛÚÊÐÁú¸ÚÇøÛàÌﻪΪ»ùµØÓʱࣺ518129

> Huawei Technologies Co., Ltd.

> Bantian, Longgang District,Shenzhen 518129, P.R.China

> http://www.huawei.com

>

> ------------------------------------------------------------------------

>

> ±¾Óʼþ¼°Æ丽¼þº¬ÓлªÎª¹«Ë¾µÄ±£ÃÜÐÅÏ¢£¬½öÏÞÓÚ·¢Ë͸øÉÏÃæµØÖ·ÖÐÁгöµÄ¸öÈË »ò

> Ⱥ×é¡£½û

> Ö¹ÈκÎÆäËûÈËÒÔÈκÎÐÎʽʹÓ㨰üÀ¨µ«²»ÏÞÓÚÈ«²¿»ò²¿·ÖµØй¶¡¢¸´ÖÆ¡¢»òÉ¢ ·¢£©

> ±¾ÓʼþÖÐ

> µÄÐÅÏ¢¡£Èç¹ûÄú´íÊÕÁ˱¾Óʼþ£¬ÇëÄúÁ¢¼´µç»°»òÓʼþ֪ͨ·¢¼þÈ˲¢É¾³ý±¾Óʼþ£¡

> This e-mail and its attachments contain confidential information from

> HUAWEI, which

> is intended only for the person or entity whose address is listed above.

> Any use of the

> information contained herein in any way (including, but not limited to,

> total or partial

> disclosure, reproduction, or dissemination) by persons other than the

> intended

> recipient(s) is prohibited. If you receive this e-mail in error, please

> notify the sender by

> phone or email immediately and delete it!

>

--------------010308010703090009080509 Content-Type: image/png Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAAoIAAAIDCAYAAACQHH9oAAAAAXNSR0ICQMB9xQAAAAlwSFlz AAAOxAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAFQV SURBVHja7Z1PqGNbdp9lbExj327a7jbdmvWkRIMnBZpkUANlZAjk0kUmb6BAQYUQ0KQHNego g349KGyjQZu4iAdReIEKtCFEprAnnqQGIu6BC97QKU0qiePywCYvoTAd5w+K1s1Z9X533bXP H0lXV1f6Fnzce4/O2Weffc5d59Pe50/vRz/6UQ8AAAAAzg8aAQAAAODcRfAb3/jGP/3mN7/5 Odx/vva1r/3DuzyoOJZOB9uXJEqAMxeFXu/bv/qrv/ofyIm7s2nL0dGKoFXwxz/+8fr169dw j/nBD36w3vzD/tu7PKg4lk4D24e2L0/5BLfZvn+/Scxr2A1rR4TppEVwNBgMPpAXd+PJkyf2 //LpUYugVZS43/HZZ58dhQhyLN3/sH146iL41a9+9a/evXvHzt4hrP2sHRGm0xbB4XD4xa7H yosXL9bPnz+/wV2fLz58+HCQ9fzwhz9EBInbD0SQ2FcggkSbQAQRwbbx6NGj9YMHD65J4NOn T6+m2c+7CJfTQwQiSBwkEEFiX4EIEm0CEUQE24aJoBHj1atXV5cYvH379uDHrwvpIQIRJA4S iCCxr0AEiTaBCCKCbaMkgu/fv7/qFXzz5s3HaSZnNi3rLXz8+PH65cuXH3sYnz17diWRNt3+ tp8a1uvn89pnLpw2PVuH91J67+W+AhEkDhKIILGvQASJNoEIIoJtIxNBkzIXLw8TO5vPPjNJ tM9V7mxe+9zE0XoTXdrsd5tmn7nAuVDaZ/q3lWvXBtq6XCS9jrY++9ymaVm7BiJIHCQQQWJf gQgSbQIRRATbhkmVDQG7uDnaS2dh0+IwsU6LvYdR1ux3F06b13oPYz1UFP13y3kqpKVp2wYi SBwkEEFiX4EIEm0CEUQE20bsEfShWRU1EzyTRZ/XsWl+Xukqgjpv/FxF0HsL47oRQeJeBSJI 7CsQQaJNIIKIYNvIhoZdvry3z6TN5S3ij3nZVQRtKNiHmqMI+pBzZB+BCO4p7EAo7RQ9UHy+ jLZ3Jvk1BPcpEMFuUTqW7BjR46R0LLVJED6fHU/3KRBBok0ggohg2yjdLBKnx15Cy51+zaB/ 3lYEs2v8bHnrjfR549Cw5mq7tjDefLJtIIJ7Cv/2kIXe4WM/s2sRsjuK6g7aQ91Wvq9ABNuH D0FkMqeJyefLjqWmIQMfVvCfd/WsrG0CEezWVm0ejOvzxWuWtp0vO6brvrzaidROgMa+HtWB CCKCbaMkgna8W45VOXNZ87uD480ibUXQ5c56AV3qtA66Lgv/3NbrQ9fcLHJk0UUEtx3X9zuF 7MBEBBHBuvnqIt7p5kMe96W3FBFsdwzFa4qyi9P1zsZ9zFfaX3aclr7o+p2ZWu4+ejoQQUSw bfiXkNJner6149lzaFzG5tMvPPa55lX7XZexc7rfiZytPz5L0P7fbL22/q5fxuoCEdxT3LYI 2gHj3w7oEUQEm+arC0s8Mencp2MKEWyObH96L4K2ox0/8YTi8/kwVNv5SmEnLZe9OK+VadP1 5Gm/a0/ItoEIIoJEu0AE9xSH6BG8jydtD0Swfdy2CMbwh6bSI3g6IqjPJ9OwLwEuXdazUOp5 s+l+PLSdr64u/lBdW3/Mm9mQnA+97RKIICJItAtEcE+xj2sE28odIogI6ny7XG/qZXKN4GmJ oPfA1V1z17bXbZfeOe/xi797+JcQq+++/zcRQUSQaBeI4J6iSQT9263PV3cLul+TUHrXICJ4 3iLo0ubz2bFVugPdL+534hBc6SLpYw5EsFtO8i8LdtzEh+O26U1uO18WMVdl1xXa/vRXcPm1 grsOC1sggogg0S4QwT1F9m03S6RthoYtYfsJOuvZQQRPWwSz91tm+77N0LBfU+rEZ2Ldp55A D0SwW/gduX4jhl+n1/ZygG0vG/Dj2F+vZcQ7I7N9672ZcRi5ayCCiCDRLhDBPYXfzBGHYfxC a5/ONYKIYJsoDcfp9G2vEfRj9T5KoP9PIYLlsJ7eUn7QS1Asj5RkS+9KbDtfDFsmexuC5sN4 V6VH3RfrtoEIIoJEu0AE9xg+vOFDdX5XnfbquQjqcF3dMHAWiODpi6AeJ3Ys+WMD9OToImgn 3OxYKj23zcuJ83OzyGmIoIt+9gUhPrA23rFr4T158XKWpvnq1hXzl38J8UdhxEAE4ZhE0P8H mt5FvE0u29dzM3cJRHDP4c8E8m/C2SMc4jfkumHgLCxx7uMamkMGItg9dDjPe/D08Rv+XMkS pQTjw3OR+3JMIYLtcoR+kdAhVw3f9/7lNXtIbpf5dB+VRE4fY+PS6ncf6xfoXb/sIoKI4L6i dG3/rtdY+2vj7joQQeIggQgS+wpEsF34o1lKXySy+epGG9rO5/OWLj3w13L5/6I/WkZvFtnH w3IRQURwX1G6pMuvtY7T/O078Yu7hU33nkA/1kuvqLV5DvE6WUSQOEgggsS+AhEk2gQiiAju K0oiGHu+vYdQRwZdBvXNOX55hN4lnz1n81DPd0UEiYMEIkjsKxBBok0ggojgviIbGvbrWP3y CLs7Pg4Ta8959rxWHRqO18XWXV6x70AEiYMEIkjsKxBBok0ggojgviJ7EUTdg/iza12z67Dj NYLaA5j1EN5WIILEQQIRJPYViCDRJhBBRHBf0eaxbzYE7Ne6+vBwFMF4HWCc5u/ltmjzHu99 BSJIHCQQQWJfgQgSbQIRRAT3FW1EMHsndxwabhJBHw72u/IPFYggcZBABIl9BSJItAlEEBHc V7QVQR0qNpmz4eQmEYzDxT70vI8759sGIkgcJBBBYl+BCBJtAhFEBPcVbUTQn4npQ8N+jZ8+ PD2KoA8fZy+dOGQggsRBAhEk9hWIINEmEEFE8C5i1wdEWw/hoV//iQgSBwlEkNhXIIJEm0AE EcH7FPbgaHsEzaGeHaiBCBIHCUSQ2FcggkSbQAQRwfsU/riZQz0yRgMRJA4SiCCxr0AEiTaB CCKCRLs4ehE0ebA7b+D+841vfOOf3uVB9a1vfetfsR9OA9uXpy6CP/nJT66k91j5wz/8w6Ou n7UfInjyIvidX/zFX/wbcuJeeHK0InhmB/Waf27Y07H0zpIkbXE/2Xxp+ufW63nM/NzP/dz/ OfY6WjtyPMExiavlZtoCEUQEAREE8hUAIgiIIIkVEEEgXwEggoAIklgBEQTyFQAiCIggACII 5CsARBARJLECIIJAvgJABBFBEisAIgjkKwBEEBEksQIggkC+AkAEEUESKwAiCOQrAEQQESSx AiCCQL4CQAQRQRIrkHAQQSBfASCCiCCJFRBBAPIVACKICJJYAREEIF8BIIKIIIkVEEEA8hUA IogIklgBEQQgXwEggoggiRUQQQDyFQAiiAiSWAERBCBfASCCiCCJFRBBAPIVACKICJJYAREE IF8BIIKI4Ekn1k30N4w6LjPeMLWfLecfZL+3mf+Wt314T46VASII5CsARBARJLHeRj2WJnUd BHC1YV6J4MKWb7mOYcWySc7alLnD9i7k99U9OE6GWudDimD1JWFxov9/s/vyRYB8BYAIIoIk 1ttY/2UlaK1EsJKCVTx5VlI4v0ciePTyt8U23ZYI3uq+OIIvQIggIgiACCKCZyuC1iMyqnr2 2ojgNOsd2sRFKHPlPYV+os1E0H+XeRfJ9IXKpw2RirwaM62br7uatgjzDippXcs8K6nfIMjt JClnVmibeVhXv5o+Dts4TKZbnS9L5WiPYM32/8WGP83KDPUsrTfui7Fsu/cAD0NvqtbL5/H5 xyWprD5fyfGy1P0v9VzpMSD1Gcp8i0Kb1ra1lL881GUI5CsARBAQwaNMrB1EcFE3XyWVSxfD 6oS7qhHBucpKmEflbyTLLFzQ9O9qG1ay7rFKWyUcU5W/IIKzMP+qZn3jsN0D7TXzayeremud dDtWIoujqi1K5QxbbP9fVL2C1+Qn2Uc31ivTfdkLny8T9yh2svwkLp+IoK5nqj3J+ney/1dZ L54cM53amh5BRBAAEUQESazdRXDeIII3yvETemlouJKfkYhcOnxcfTaIw7qVBC2r5WfhMxeZ qQ5/F0SwL+IwDj1dM9+2SrzmBcFaVvXpS3ssZdmpCNZCyh40lHNNuArbf9UjmElaIvPX1iuC Fus57iKCYT1LFdbC8ku51nQqvcnp/m8QwW3aGhFEBAEQQUSQxNpBBCcFuRjpCbitCMow6FSG 7+pEcJgIx1gFIEz3k/+kqUdQxGBUicNI1jsNTArtMxbpUHGMy2uv1VyHswvl1AnXuIsIZust iOC0mm8XEZx2FMFp3N6OItiprRFBRBAAEUQESawdRFDEaJT0Ms20J0162eqGhlfh+sJVGBq+ KJQzkmXm2mMXBOEyzNckguN4F3RSTia7gzDE6TfhjENZF1X5F6GdLqTHMytH26y0/a17BJP1 9pN9MS+IYGyvZXZc+PY0iOA8DMe7rPUb9v84OWY6tTUiiAgCIIKIIIm1IDd11wKGi/hnSW+W 9vLoTQeZCC7jY2iq3ruhDJHGci6l92ouZcVtmMnyfhODDvcuVTCCWMyCjHnP4jy79q3Fdi9k +kwkaBGHm7NyQpuVtr+tCJbWq+21kHIHSS/aXG/yCG1aN3weRbAvN5nMws0rs7D/V+H4myY3 EnVt60UUfUAEARBBRPAcRfAi9AYN9O/CMsNK2gY1n/W1zMLvo+rk3td6VHXo+2ehfJ8+Km1D Vkf52Rd5iI/CybbnxvoKbTKK213XVjKkOWgqJ7RZtv12o8jfbdqWhvUOXMST6cPwZWAU2nRV 7YNx3V24hfYdFfaz16cfeiJ1+mDHth42HeuACAIggoggiRWO/Vi60zeL9G752Yy9E3z245Ec Nz/e8P02xw75CgARRAQRQUAES+tf3Ofyz/i4ed37/8/VND6vk0LyFQAiiAjegghu+PQW+EE1 3Aa3CCIIJyaC6zopRAQBEEFE8P6I4G9WCR5ulzXcOj/lOLtVvmixD1wKEUEARBAR3LcIHnHd Lquer4vqIvtRMo9dlD/pWO5IbjSY7lC/Sd3dnlW9J1uUeZGUM5W6T3stnysYtnnSYv1bt3XW I6ht0LWtpS7K+A7a+vc2/Evhdwo9tP+gMM+/7H35lhe4yecNEviuuo7wISIIgAgiguclgvrs uHUvf8fwqld4aHFNuVM52S+2rNvVW0DqbiDohWfytd3m5I7Zj8/O65UfWlwnaB8f1txi/Vu3 dUEEr72armNbZA+ZTt+1fAxtXdXVHz007335iJg+1xfW7ofXdfJ3X/IVACKICCKC+63Xx96f 3pdvBcneaLHo3XwDxLCXPKS3mj4IIpiJgNFvqN+sYlHqpXJBCT/TunWUk2mHdvRn4807iOBW ba0iKO147WHQXdq6l7/FZViS77ts66r3ehHFUH6fH9s1nUcogqn8IYIAiCAieJ4i+PGhySIn 8971NzosqhPwMsznD15eSo9MfCDztTd8VIK4FMFbNQz7+ls4xqXent7NB1f7NsxrZGbfInjZ Zbld2tpFsHf9gc+rXngFXNu2LojgpNBbeedtHcoZBREc0StYbKsndfKHCAIggojgmYlgJQqr RE4+nkxlaDYKQHyl2yT2hvWSV73Fa+h68l7gwkl+mUlrg5zM6iSkg5ysEoYNbdpVBLdp67+u LuhfBHFbbtPWMkwdt/XymNtaylaR7vd4DuHJfnEFQAQRQRLrfusUXwM2TGRiItdjxVeMOf4a umsn/DA0HN9bO5Vlpy4yFQuRHr12bNVreJ1ZUodd5KQkqDfquq0IbtnWfxOlLiuvbVsXegQv M/E+lrYWkR4nyyCCiCAAIogIklh3FMF5JRH+nt4oJ6NwfdqwjQj2vnyv7EivI4x36cp69OaB WXaS30FOJlvKyY267iiCXdv6L9qIYNu2Ll0PWCNwd9rWcnNL6c5mRBARBEAEEUESa4s69bOh YTkBL+O1atXvizDkOJeT9VymLxIRjEOdi8JwZekatRu9QFvKifc0XYTtmHcRuqTcaRC0i175 Hc3btvV/2/BJkPhpIoJt2zrrERztsUdwb20t16EOC58PEEFEEAARRARJrO3rtQx3f+rw26r3 5bPphjJkOwjDlYsgG/pZFMFxGO6ctRU+lYpEThay/mGoT0ka5uGatEUQq+y6tUVHEZxmj4LZ pa3lZpFZth+2aOthYVvHdfW+i7aWm16uIZ+Puz7eBhBBAEQQETxnERz3kufFte2d6TI99twc URsMbrn8+R7K6Mvv154j2OIRPOfU1gseH4MIAiCCiCCJtVvdlhyYt9a2o33LT493DRclk95A RBAAEUQESazbnUCPptcIEMEt2+WSdkAEARBBRJDECoggAPkKABFEBEmsgAgCkK8AEEFEkMQK iCAA+QoAEUQESayACAKQrwAQQUSQxAqIIAD5CgARRARJrIAIApCvABBBRJDECoggIIK0BQAi iAiSWAERBPIVACCCiCCJFRBBIF8BACKICJJYAREE8hUAIIKIIIkVEEEgXwEggoggIkhiBUQQ yFcAiCAggiRWQASBfAWACAIiSGIFRBDIVwCIICCC7HxABIF8BYAIIoIk1vvGt771rX9l2wAA AMfFN7/5zX+PXCCCiCAieKtsEs3nr1+/XhMEQRDHE+/evVt/9atf/SvkAhFEBBFBRJAgCOLM AhFEBBFBRBARJAiCONNABBFBRBARRAQJgiDONBBBRBARRAQRQYIgiDMNRBARRAQRQUSQIAji TAMRRAQRQUQQESQIgjjTQAQRQUQQEUQECYIgzjQQQUQQEUQEEUGCIIgzDUQQEUQEEUFEkCAI 4kwDEUQEEUFEEBEkCII400AEEUFEEBFEBAmCIM40EEFEEBFEBBFBgiCIMw1EEBFEBBFBRJAg COJMAxFEBBFBRBARJAiCONNABBFBRBARRAQJgiDONBBBRBARRAQRQYIgiDMNRBARRAQRQUSQ IAjiTAMRRAQRQUQQETyjePPmzRVv377tNH9k1/jw4cMVpXU2zRPn7bL9x7pfjjWyY8Wm+b7p eoy8f/9+b8cRsXsggoggIogIIoJnEo8ePVo/ffp0/fz586vf7WeTnDx48OBqXuXx48e1yz17 9qzxJG/rLq3f1tk0T5y3Tdjx521wbGHbcYxiZHWyNsuOJd832TFiZAL56tWrq/ltWdsPWdnE YQMRRAQRQUQQETyDcAnysF6ZJokqSUBT2DL7EME20WVeE9gXL150WuZQcd9FsMuxYTLoYTJo +4S4u0AEEUFEEBFEBM8ktIdmHyL48uXLjz2EVpad4G2a9xDZ+rwMm0d7E7VHyPHIegSzdfm8 Xo79br2RpfByrQwrT9tF6+FleO+Vr9OX0bqo9JbqGLfT2j6rW0kEfT1aNwv73afbOrL9Wdo2 3y9ZfW9TBGMvofdQE4ggIogIIoKIIHHAsJN/nTS5BGTDft6DY5+51Ni+9SFXlSObpoLhn/nw tIeLYUkES+uy6V4fu2atJCU2j0uoC5u2hfZKucSqnHlb2Lrtp18fpz2tWR1dxHQ7VUI9SiIY 6+YSG3t4rdxs27Pl7W/fniix2TGwzdBwm+F3b8tMjInDBSKICCKCiCAieGZhJ+k2J2qXgHgT gEuQ9ySZUGpPTxwats9s37usuAhqT5CLiYuFy43PU1pXlJ+SCLrA+ja41JWWKQmQXl/puMzU 1dHXX5Kekgh6eb4uW4f3omn7ubhmy2tYHXz/6PaVtretCMZjxLdf20n//+3LQZtLCIjbD0QQ EUQEEUFE8Iyiy80Sba4R9J4vH0L1dWiPoEuD9zptI4KldbURQZck7bHyIeXSMnUiaOtWwTG0 hzDW0cK23UUxGwqtE8G4LpO52Dalof44TfdBWxHMyo09w6XQYW2f3y8fQAKPIxBBRBARRAQR wTMJOxlnw5KlaBJBFR0dllUR1GFUFR4XqihKKhaxRzBbVxsRNDGLw+DagxZvYLC/4xCwrzMO odp0q5v/jHW09ah4e09YjJIYxbp5m2h7WZRugvFtiW3RVgSzuum2ldq8FN5+TY8FIg4XiCAi iAgigojgGYSJgh1D2WNgopSpHNQ9PsakwnvHfMjSpc0FRh9Z49O9R8s/85seolioCJbW1UYE VVqiJFldSo808Xp5XV0mvQ3i9FId42N7StcIZtdiet1sHd7T6MPL2tvmvZwxStvWRQRt3Vo/ 7U0t1b30+BibN87PXcOIICCCiCAiSNxy+B282UN/rXem9IDppocFe+9eXF6vJbT9bvJjAuMP iXZsuShGpQdKZ+uKvWhZr1ppCNLq42XZ71aPOK/XL9s+E5hsetYe1gZ11whmbezb7nXT/x// zNajd2eXtjMu78vW/R3L8P2YbXPbB0rXbSdxN4EIIoKIICKICBLEPQu/a9ikzCSNx7AQ2wYi iAgigoggIkgQ9zD8ers2b4khiFIggoggIogIIoIEQRBnGoggIogIIoKIIEEQxJkGIogIIoKI ICJIEARxpoEIIoKIICKICBIEQZxpIIKIICKICCKCBEEQZxqIICKICCKCiCBBEMSZBiKICCKC iCAiSBAEcaaBCCKCiCAiiAgSBEGcaSCCiCAiiAgiggRBEGcaiCAiiAgigoggQRDEmQYiiAgi goggIkgQBHGmgQgigoggIogIEgRBnGkggoggIogIIoIEQRBnGoggIogIIoKIIEEQxJkGIogI IoKIICJIEARxpoEIIoKIICKICBIEQZxpIIKIICKICCKCBEEQZxqIICKICCKCiCBBEMSZBiKI CCKCiOBB+NrXvvbHtg0AAHBc/PIv//J/RC4QQUQQEYTzOZbeWdKhLYB8BYAIIoIkVkAEAchX AIggIkhiBUQQgHwFgAgigiRWQAQByFcAiCAiSGIFRBCAfAWACCKCJFZABAHIVwCIICJIYgVE EIB8BYAIIoIkVkAEAchXAIggIkhiBUQQgHwFgAgigiRWQAQBEQQARBARJLECIgjkKwBABBFB EisggkC+AgBEEBEksQIiCOQrAEAEEUESKyCCQL4CQARpC0SQxAqIIJCvABBBQARJrIAIAvkK ABEERJDECoggkK8AEEFABAEQQSBfASCCiCCJFQARBPIVACKICJJYARBBIF8BIIKIIIkVABEE 8hUAIogIklgBEEE40Xy1icmG6YYxbX6jXS72VFafNj1MmyCCiCAiCIggkK/al7/YMN8wrH7O bmkdw3vY9tYegz2VtTri7Tz4/rF23bBEBBFBRBAQQYA7FkH5fdhWWKp5h7FXpzrBf5xuPWp2 ws96G6vPLrK/XUx8PQ1Ckc6TTbd6FabfKCdKYLbNPk9dPb1dY9nV9EHDtg3Cclndb7SVbGe/ rk2y/SPLNtUtnS9rY9+3Pr+tr1rvINmei116YhFBRBARBEQQyFfbrWuiYlgzn53AZxUmOKNq +rzqXZq6XNhn1TyzeHKv5ptmf1fLeFlXvZZJPS6r9fg8C5Edr+Pce54qQfH55y69NeUsRayW Up+Vi1M1fVmVN89EumrXlWzbTNa3LGyby+My1Gcuyw+krZayP3w/+N8ubStZflWt49r+EUGr a/dh2D9LaY9xbONq3dPQVl6HSSKi810uU0AEEUFEEBBBIF91W0e/Oqmvmk7AIgHeczeqGOtQ n4tHFKqOIngpn62Snier80SXl/VdBrHw6yAXQdAuGsoZVtu2qNm2WZDkbFtXumzoCf0o0zXt PA/rGYsgfmwrF7uw7S5l07D8MmxnqW6Dhrppe0x1fil7Go6Poaw/tu9qx+MZEUQEEUFABIF8 tcW6htmJP5lvIT1CYxGAlfT6GGu/FmwbEQzzLnXeatpltU7v0Yo9ZI7XtS9/z6Uns1SOSkxc 90p6HocdRHAYr42LkpbNF7bn43bFtkqWm0pv3LBO1EMvpLbdpK5u2h4i2DM5BobJvo71XIkU zhFBRBARBEQQ4EcHuUbwMhGuYYvl+jKsp71OQ6VBjrqK4KRQl5EMNXqv1iirSzX/IA7xFso5 lAguWorgpNC+24jgoCCCy7iOwnWGmQgO5HgY1rVhUs+5HE8jRBARRAQBEQQ4jAhqT86FS5Cf rJP54wncr68bheHCYYuh4UkYElyEoeFJVq8w/zhKWDLUOxchmsv0mVwLl5WzlOvolkEY021r EsGaNh80tHOs+0SHhluIYFx+WrgWMtZtmd2cEuYbyTCvHgMXIsxNIjjyXsg9HNOIICKICAIi COSrluWPw3DgOIpcssw8DB8ORaxWMqQ4DtMnSVlxuDPeLLKsues4DmXOqumDUOaisL5FQzmL sG3ZNi+CCC4KIriUXrO0zZNtWyTiq3UYFERwEUUwWX4RhNhv3BiHfThr0e7aHnpsLIKEqwh6 z20U5CkiiAgigoAIAhw4X23zHLnStYS9js/ey+bXmyt2qEe/ND37rE29e3t6ruAuZfV2fBDz Lm0qIrhsauMt6rWsW24Tv7nhn2z4NiKICCKCgAgC+eq0t/toH8DMMXnzGsEdyxv5I28a5ntd 3Xyyrn5PpRARRARJrIAIAvnq/m/3lP1/tPvmonTjzg4iOG0xn4rguiSFiCAiSGIFRBBOKl9V JzqAc+eLgghGKfxnG/4L+QMRRAQBEYRTEcERAPQ+b5BAy8c/3vD36BFEBBFBQASBfPVlGSO5 czS9Fkse39H1Ro+FlLvtzQ+X1R2m/ab1dChzUrhLedH78h2+2UOam65TG7atyzG1dXKn97W3 rxxTW1fzL+Qu51E1/U2N/D2U5RkaRgQRQUAEgXwlZcQHE2evNJtXJ9Zhx7JXIgMXW9bPHzMy q5ln2rHMabZM78vn2pUenjxsEOpV2xsljqmte1++i9i38zKr2zG0de/6Y4xGst1+jeB/jfIX lkcEEUFEEBBBIF9Vy497N9+Fa0IwT06++jy4vjz/LYqMv7d3VJITmWfa0NPnz5Pr190pLD2a Pkzo5Y93kZMO7ehvvZh0FMGjaOte/oq+ZaGNvK0vqrIvq7Int93W1ToXST2tjCcb/lGv4RV0 iCAiiAgCIgjkq+sn0VH8u3f9Qb7j3pcPTB7KUN5YhjEvq3m99857eW68YcMFo/flGyVqBc9P 7L3Cw5VdKmT+lcpRL38g87a9VBclQal+DjuK4FG0ddIjOO4VntvXu/46vJXUYZFJ2L7bOpQx 6IW3yvQaHi2ECCKCiCAggkC+un4y7ie9Kwu59mohQuKf6Vsg/DVygyA1FwU5GWfz1NRvJJK0 aCGCixYS0kZOVsl1a5OG9uwqgkfR1jJMvQy/D5pEsGnbb7GtL7IvB72G92EjgoggIgiIIJCv Cr0nIiBj7YkLn7koRG6IQEFOLsMJfyUyoGWNqmu+dN51g5zEV5XtIoLLGtm7VtcdRfAY2job Gp4WbmZZZdu6owh2amuZPi61KyKICCKCgAgC+WpLEZQT9cdrCIOcjJMTdqOcyFDeqCAWw971 99LOwnDhvDD82FUEJwVpWbURutINDduI4JG0dSaCoy5tVCOCe21raZfLpnZFBBFBRBAQQSBf tZSRRE4WlUgMgmBcu35M5Szc0TlJ5MR7ci7iPIUeo34iJ6s9iKDfhDIJkrkIstH6ruGCHF2U 7rI9sraO1wiOam4W6SqCe23rpKxh3ZcbRBARRAQBEQTyVXn5SbhreC4ychmut9PPpjLcOJd5 BiI1erLXZWd6HVgvee5dJSLzQp0Xyd2zC9meSdi+0t2sI6lrth3bPEdwkJVTmPco2lqWaXWN nqwn29b5bba1CGpk0NTeiCAiiAgCIgjkq0JvEG15q/toTjscrq1Ld5YjgoggIgiIIJCv8jKm TSdP2Kl9B7TDQdq532vx1hNEEBFEBAERBPIVsgKn979w0XI+RBARRAQBEQTyFcCZ/s8ggogg iRUQQSBfASCCgAiSWAERBPIVACIIiCCJFRBBIF8BIIKACJJYAREE8hUAIkh7kVgBEEEgXwEg goggiRUAEQTyFQAiiAiSWAEQQSBfASCCiCCJFQARBPIVACKICJJYARBBIF8BIIKIIIkVABEE 8hUAIogIklgBEaQtgHwFgAgigiRWQAQByFcAiCAiSGIFRBCAfAWACCKCJFZABAHIVwCIICJI YgVEEIB8BYAIIoIkVkAEAchXAIggIkhiBUQQgHx1x+0827CgLRBBRJDECoAIAvnqvNr4csNq w5L2QAQRQRIrACII5Kvzad8LE8CqR3DZYv75hmm1zESmLSoGMq9Ps3kvZd6xTB8HIV1Wn81D OZNYVmkd1fSpfHaJCAIiSGIFRBDIV5CL3aXLXYv5lxVDkUgXwpH1LEq52XRf3pbtV7+Pqt+t V3JUzfdRTKvpc5HFpnXMZP6P60AEAREksQIiCOQr+LJtrZdtVv3eRQTH1e/DStKGgovdPPb4 xeVlvd7LOAvzWtmD6mdfp4sIZutYVcLodZrHshFBQATZ+YAIAvnq3Nt2VfWe+TDqynvYGkRw GERwGZiIaC6reRZxeRXQ6uc0W5eLXxTBmnVkdZojgoAIklgBEQTyFVyXsOkOIjhIJG1STZ94 L141DLySHkPtEZxVTKKseU9gSQRr1rEK1yqOzuk6QUQQESSxAiIIZ5mvNvEV2mwnKVzK39du /MhEUOabVwI2DdfpLarpY5G6pQzdjnXY10VUhnPnKn6JCJbWMZUh6rFee4gIAiKICAIiCCeU r6qT3vc3fL7hM9ps63YeaW9gJVMXyXyTOF3u6J2Ga/l8+kxkb1lJ4EynV5/1pXfy2nWEUVrr 1lFNH/u1geckgYggIogIAiIIJ5+vNvFdkb+1gAge//681qMIiCAiiAgCIgjQmK8q+ft0w58F +UME79f+XCCCiCAiiAgCIgjQOl9t+IMa+QOAm3wgfyCCiCAggnAy+YoeQYDW/zP0CCKCiCAg gnC6+apGCj9rKGsQHisykMen6PSL8JDkYVLWsGmeE2n/UdU+o2T7s7uKL7ZpCy8rK7NDGf1d lu9a18IxcdF03LVcx4WXtcWyJoJ/EY5PvZHmrF65hwgigoAIwgnnqyCFTSK4kN/n8iDjmT9c ufpsmjyUeBXuZM0+X55Y2/tr36ZRRqrpq6yNs+kN6xnK6+S2voZQ9kP/FttkmO3navo6e3D1 NseGfEEZ6nHbctm/X9UlPX79zS/kF0SQAwAQQTipfLWJr9d8Ng6PHVlp740+uLjwlotxeKPF qnDCn5xQ2w9LAiMi3EoQt11PhzIG+qaUOxLBZfLMw5HL2DYiuGUdTQT/V5h2GY7fxSF6TxFB RBAQQYCjyFdRWjJpk2fdpSfh8J7dVeHzbLlF6J0ZSB3m0mMzE6lZyts+ZpVQLLJ1BYmdyXoW YXu9vGEmufL5WOqwynqkpKdwFsqZBeEo1efa9KxHUOZZxB7ZpD7+XMJBnYhWdbzWtrLeTnUt iOBCh9Gr/TuR7dP54ltW4nFyo0ewdCy1FMFlaAd6BRFBAEQQTj9fFV5Tdum9V9XJddLUGxPk axWuwZpmw5IuR0EqplFGg8wtRDgv9B26Oq/IhT88eaond/27rrdS5VDKHrToEewHuVgmPas3 6uO9ZEGWllLGsFr/oiQyhfoMpIxRzReCC2nblUyfxzapq2tBBMehnGUY+ta2vghvQ4nLTcOy xWMpEcFsaFgFddC15xYRJLECIIJwX0WwTmj8vbhLOeG2FUE90c5r5KMvsnitjCgzsv5VLNN7 m2LPm0xfihBOwzyrtm0jbwmpFUFpk4FKYZSrWJ/YvkF2lkGUhtX+8Z7Ti971dyRfyLa7lM/r rqvrfflKulmo6ygRuGJdS+0oZfo6hlLeKtR/Jb2Uw/hlJK4vO5aq9pnK71c9guGLyqx0vCGC JFYARBDOSgR74XVqTSf/0Es07nISlWHXWXWSnjWJoAjqTK87E7Hwd/sutMcqEa9paV0NIjjv IIIT2bZJgwjeqFdJBOWaP19+LNJ5bWg0GS4t3jQiw7JTvW4uEbFdRND3y0J7VgsiOFWRrRPB 0rEkkuztfWNouLCNiCAiCIAIwlmI4CBI1qgwjLvSR8pkQtf1JFqdfC+jZDX0CM4LvVNxSNjf s7uQ5WZhO+cNIthPbpxZVcu2EcG+SEg/2Y4b9anachHadpkI2CybJ6t/Mn2hyxe+EPRbiGCx rjUiOA7XPQ512Dy09VzaZVon43XHUqhLdo3gRRg+7yOCiCAnGUAE4WzylYpK9fcsDO+uRJqm yWdb9aZIr5733CziNX+JXI2l52ieXIe3FMFdSy9lX3rRfPsum+ob6riQdmgUwVinRBJL9VnK 9GUigpd6Q0qv8Fgal+Fk+ihp377eWSw3jAxKIlhX1wbJ1BtRVOZiWy+Tus1l20vLXjuWEhHM rhGch/ZZkGMQQQBEEM5FBKfZXcJyzV3dA6WzOzOHHdbt17lde2hycveuiohfuzhK6tyvq4ds U79tfWV98XEwxYcnt61TVp8w/aKXPFBa6jSs2dZBL3mIc838/Wqdo7Avarc7q2tWl5rli9sV 5htX60ofKF06lkIZ3+nVPFC6mmfeq7kLGxEksQIggnBy+ap3Yg98Bigc5yaC72o+v+B/ARFE BAERhHMUwXHpzl6AMxLBaY+HSSOC7HxABIF8BXB+IgiIIIkVEEEgXwEggoAIAiCCQL4CQAQR QRIrACII5CsARBARJLEeUT311vfhGe6ncfzbn7Afpg/q2ip5FMYwe+L+KYigv2op2/6aY+yi 4zqKj4joenwn0y5JzIggACKICJ59YpUHqvrDMM/qwZfVw1SnInr6qqWFvhUhebXSx1cvVZ9P k/eirvbxDKljEkF5wGp8VtxUH7obBHqdPZm/YT36TtPFlnX9+F7YZPqc5IwIAiCCiOC5i+Cs 6wn6xPbRMrTFLJGeqYpJJkUiQrWvyzoREVxmjwYReV4kx9hyWxHcsa6Lqvey9GosHu2ACAIg gojgWYvgsuoVm7TpuZJ3Oa7k9UazrEcxvKDb3/84lJeRe4+bP80+vuR8JoJxo6zSOkTAlvKS 9NKT5bW+k+T1WBdNYuK9hgURHBYkROu3atrWSgR/P5mur2cahddRzf2p+qEtxkHcVoXXJy3i fpVXMi2Tnj9/RdUqOcZmItSl+gzC9FXsEUyWXTQcryvZluwSAHoFEUEARBARPGsRXFUnyWvv Y2wQQZW3aXivoovMIPS2TasTb1x+JO93vDbcKL05U32BuAzdltYxCvOPCu+snCfipqIzy15I X2jDoYiQy0s6LCllef0uRFhK2/pfN/xpsq0zkch5aFt9+fpQ1yXiusqu3Uv260xkrNQOU9n/ Y2n7uUpyTX0+7n89TsI7QOfhZfDLmusSJ1LnGy+w90sBSNCIIAAiiAieswgOE6kZNYhgfDH7 XCRgJlLjQjWRnrphckJeZSdl6aGb6pBtIhVxHVNZbirC009krCQRIxGrcQcRjNcIThrachza LN3WqkfwXbKtg/AS+alKsghVbItxXFdd2+j+aSGCo9CDOJLP6uqT9SQOk2NuIGWu5J2gU33P rbTVUNY7ivuOBI0IAiCCiCCJ9frJd7qDCF4bHvXhVzn5l0RwmIjAWOUmE8HCOqbSy6lcNMhO Ns9lEK0ozv26oeGGdvY6XgYRnBZE8DtxW6WsgV/zJgI0KYjXVOWspQj224qg7NMLabs6EZzG Ye2SCMqw+VSOj2EYTp/LjT/xxp05IogIAiCCiCCJ9brEXMTeuQ4iOA89WCM5Ec+jUIkIXBQE YxTLrpGj0jrGoY4XlSRFycuGouPNIpO6IdGmm0VatmG/hQja0PDvFwTV7+KNvaSDwj6etxDB eSLbyw4iOHfCdtTVJ+7/bGg4O16HhfrHfTkI11D2EUFEEAARRATPOrGGHpZlOHEv2kqMSNvK r+EKvYXLcI2grnMscrPSGybq5Ki0jqTHbZkNgcabBZKbVZYqxoXPFlm9Wgr4LNywMWjoEfzT wraOqsezDEVoVXhm0t6LUrvW1HEWbkppI4Jep1HyWak+uv8XBRHU/b0oDb+XvtDo/DqEDYgg ACKICJ5tYq0EZNy7/gDfi1LPYOEEO6rK6CfTb1wjWIlGNr9PH4W6XNT8fW0dQVonDT2cy4Ls TpLev/hA6bi+i17LhybH7RTZTLdVhoaL21q376q6T5L5LhrqOUruti0dF7Huw5rPBoU27vs+ 6xUeKK3HWmkbaq797Etbz3t7eMYj+QoAEQREkMTavk2GTXcmH7g+0/sgAz1eMbfv9rw4puOQ fAWACCKCJNZzaZPBsT27rXTnLCJ40sfhtMfDpMlXAIggIngsiXUT393w6YaHHDCACAIiCIAI IoInnlhF/v6surB+XfcMP0AEaQtABAEQQUTwHifWgvytEUFABAERBEAEEcETTKwt5E/519W8 AMoXG36HdoBbBBEEQAQRQUQQEEFABAEAEUQEb2WopZLC72/4vMfQMLQ/lhgahoPnKwBABBHB W0ys1UEUpRARBEQQEEEARBARPKfEKlL4kAMGEEFABAEQQUSQxAqACAL5CgARRARJrIAIIoJA vgJABBFBEisgggDkKwBEEBEksQIiCEC+AkAEEUESKyCCAOQrAEQQESSxAiIIQL4CQAQRQRIr IIIA5CsARBARJLECIghAvgJABBFBEisgggDkKwBEEBEksQIiCEC+AkAEEUESKyCCgAgCACKI CJJYAREE8hUAIIKIIIkVEEEgXwEAIogIklgBEQTyFQAggoggiRUQQSBfASCCiCAiSGIFRBDI VwCIICCCJFZABIF8BYAIAiJIYgVEEMhXAIggIIIcAIAIAvkKABFEBEmsAIggkK8AEEFEkMQK gAgC+QoAEUQESawAiCCQrwAQQUSQxAqACAL5CgARRARJrACIIJCvABBBRJDECvwDIYJAvgJA BBFBEisgggDkKwBEEBEksQIiCEC+AkAEEUESKyCCAOQrAEQQESSxAiIIQL4CQAQRQRIrIIIA 5CsARBARJLECIghAvgJABBFBEisgggDkKwBEEBEksQIiCEC+AkAEEUESKyCCgAjSDgCIICJI YgVEEMhXAIAIIoIkVkAEd6rzYMPQfrIPyVcAiCAiSGIFOBMR3MRsw3LD1H+yH8lXAIggIkhi BThxEdxEf8Nqw0X1t/UMLtiP5CsARBARJLECnL4ITjbMKyG0oeF+i2WGVc+hCeSqmua9iksV yarspdCX5RcVVs6wmn9c/e3Tx9X0aVZWaR1Slq9n6esgXwEggoAIklgBEfxSsBYiTB/lq0EE Vd6uJC2UOa96F5dh+jhZfuTzheneWzmoltWey3k1rbSOUZh/pPORrwAQQUAESayACFaCFSWv hQiqfC1FzKZV7+BKxG5Z9Tz2s+VVAJPpCy031Htas46pXPc4FZHsn8gxRr4CQAQRQRIrIIJ7 EcEbUrajCE71hpOqh857G6cdRXBeKLNpHdMgkc4F+QoAEQREkMQKiOCPPt4coj2C/S1EcB56 60YyNKxDxpd+rV4YtvUh4Gs3roggjkoiWLOOcajjRSWGiCAAIgiIIIkV7k4EN/GVDZ9s+MmG PzuC+s6l92wZbtBYtBBBF7i5DwubkFWfaW/hMlwjuEzWqY+yWbjk1fUIZuuQ6bpdM/IVACII iCCJFQ4ugpv4usjfz+x4qziKxFT1rE30gdJVL9qgNH8ybVSJXj+ZfuMawUogs/lLdbmo+fva OoK0Tk7tQdnkKwBEEBEkscKRi2Alf082/IGIX+TsElN2LSCQrwAQQUSQxAqnciz9pw3/okb+ AHaG/zUARBARRAThOI8l7xH87oZP7TpAegSBfAWACCKCJFY4IxEM00pSSGIC8hUAIogIkljh lEWwIIV/vuE/y3R/TMq1mx6qmyeGSlLmMHBSN0fIdo6z5wFW23yRzD/o2hZ6I8o2r6VL9kV/ l/qQrwAQQUQQEYQTEsFqnn71aJPvVH/ro07mySNYMgYiHqvw2Uqfr3dCErjSx8jI9q+z7fV2 6biea28t2UIC18m+GMs8S/IVACKICCKCcN4iaLI3qn4fJW/UGPsz/PwhzMnyC5GPZSKaq1Pq GYyvmQvytYzS5u26iwhuUcdhUo/L8NDuq15f8hUAIogIIoJwhiIY397hb/dwMUzmXxaGg/1t HOnjWPy1bQVpWvjPMH0pr2q7FCm9Nr168PM0W1eQ2IWUO4vilvW4yUOpF/ImEu8NvNHTGbZp FGR5Eh5+faM+yfRl1iOYzDPoIILxAdxL8hUAIogIIoJwniI4Tnrwpio6cSixRgSHIkJ6Xdq8 IIdzFzwtW4aXh7GOLpzV7/76uJF8fm3I1utfidMkiNQ4rivUz3vxLkSiVtJG04J8+VtL5sm2 LWX9WX2myXLXRLCabxZktVSXbGh4lEk8+QoAEUQEEUE4PxEsDj1WIjHTnq+WIhivEZyVRKPq gRyJfA6T18ZFgVpVZerbPlYifhMVR6nfTN4LvKjmLT5QOmsbqWOtCGbiFj8r1Oda+5auEZTe 16m8Bm8k5U1VcoVZ0ku43OZGFPIVACKICCKCcGIiWEnUKMxzIVKTXSPYbxoaLqx7LhIzDj2C qQhWf4/kJpaFlHUZRGson6+CJPkd0bcpgouqrgu523rZUJ9GEZRez1m1zCws70PTw8Jwd1wH IgiACCKCiCCcqQhOXJZEPBaJ3NSJYO3NIjXrXoV39LbqESwIqg//6vWAH4dfq3pfRsFqEMFx WF+/7dBwqNMy+axUn3kQ83kignHZeU1dVpnUx97UXW7kIV8BIIKIICII91cE+8k1goswvPvx kSPJY2NWQZa6iODSJUZufpg0iOBcHm2zCNfT6bWBk3A94aX0os3b9mCGOi6lHRpFUOo0S7aj VJ9+Mj2K4Ex6UucqwEld1k2P8un6WBryFQAiiAgignAiIijiNwjTBlWP1qjhgdL9pLxBh/qN qvX0w8OTB6UyZWh2ULfewhD2OBn6HjTUcZg8WPsie2h0Ute67UjrU33mbZ8+UFrqNKjbhroH Sst65uQrAEQQEUQE4XxFcHRqD3yG1sfHYpc7hslXAIggIogIwj0XwWq+WamHC0722Bjpo4HI VwCIICKICMKZiiAA+QoAEUQESayACAKQrwAQQUSQxAqIIAD5CgARRARJrIAIApCvABBBRJDE CoggAPkKABFEBEmsgAgCkK8AEEFEkMQKiCAgggCACCKCJFZABIF8BQCIICJIYgVEEMhXAIAI IoIkVkAEgXwFAIggIkhiBUQQyFcAiCBtgQiSWAERBPIVACIIiCCJFRBBIF8BIIKACJJYAREE 8hUAIgiIIAAiCOQrAEQQESSxAiCCQL4CQAQRQRIrACII5CsARBARJLECIIJAvgJABBFBEisA IgjkKwBEEBEksQIggkC+AkAEEUESK5BwEEEgXwEggoggiRUQQQDyFQAieIoiuImvb/j0hFif 2PZ04Xt3/A/6lQ0/OKH2/GLD75zpsfSEJIoIAiCC5yGCn45Go/UPf/hDuOfc9UnF5OHXf/3X /5Z9cf/5pV/6pb+lNxQRBEAEz0QELfET9z+OQQQ/+eSTD+yJ+x+/9mu/9gERRAQBEEFEkEAE EUFEEBBBAEQQESQQQUQQEQREEAARRAQJRBARRAQBEQRABBFBAhFEBBFBQAQBEEFEkEAEEUFE EBBBAEQQESQQQQIRBEQQABFEBAlEkEAEAREEQAQRQQIRJBBBQAQBEEFEcP327dv148eP1w8e PLjCfn/9+vXeyv/w4cMV28bTp0+v6hh/RwSPSwSfP3++fvTo0cfjyP7eZ7x582anY9yOnfg7 IgiIIAAieNYi+PLly6uT9rNnz65OtIadwC0pvnr1ai/rMLHc5SRucuHL6++I4PGIoO0Xw44n 2z/2RcKn7UsCdylLl9+1LEQQEQQARPBkRNAk8MWLFzemW49JdrJskrDs85K8ZT17TctnZb1/ /762l/AuehDPSQTti4MdRzFsv9h0k8Mu+yvbZ3XyZuXFZeO0NiKYLdfl2EcEEUEARBDulQh6 b2Ap9KToJ3sf+rMeRA/r8bO/fUhQT/72mSVYHSq03000fRjaxVPLV3moE0Ed0o6fZetBBG/n y4QeDyWhs9916Lhuf/nntozNY3/7ceTHo85r81kPth6Dus/rRND/zpaz8GM7OzYRQUQQABGk Le6tCPo1XW2F0U/aJoi2nIudDwH6dYCxh6h0wvdrB7330Ze3YUWbx69TLImgnbD1Wi/r2dTt ietBBG9PBNtcU2r7Ju4vPU58f6nk+99R3vwYs/V6T16UNFvWpa5OBLPlfL3+P+LHj0tpXc8h IogIAiCCcFIi6D1+GipdKoV6sqwTwfh3FAldZyaCfuKPJ2QtO64HEbw9EWxqZ5O1rPdZ930s R4/PTAT17/glIK6zJIJZr7h/EckkMTveEUFEEAARhHspgrFHJoZLVnbiU9nbRgSbREJP9JkI Gj5UGPETd922IYL7FcHsOlOXseyYyKSqqwjqMVf6UuNllkTQb4zKjiP/spFxyLuOEUFEEAAR RARvJewkbckvG9bTnpJMBOs+34cI6vBcSQRtubohX0TwMCJovbelazD1jvRSj6CK+z5FUHuN 60Swrlfclt/X3fOIICIIgAgigkclgn4StxOhDrH6NYA+NJsNu+n1W21EUE+mUQjitX4mdyoI pWsE43p9SM97oRDBw4igtbttb+wV9B5nP7Ziz6HvL/18WxH0YeA2y+vvLov6ZUivcdXrDPXY LPWAIoKIIAAiCPdKBF3E/K5IvzMy9vD4PCaH8flwTSKoy2aC5uLp8hmH3koi6HeJukjGu1cR wcM9R9B7iPXu2nh9Xba/9PM6kfPea//SEkXQQo8dP+a8vLqbRbLl/ItLdmwe+hmEiCAiCIAI IoK3HnaitV4Oo/SMN3/YdBxKtvnjEG0c6rW/9XqxUs+SlR/XHx9BkklIVu+7fPD0ub5izvdh 6S5iEyvfX9mz/jTsmIr73ucp3Qnux3H2iJe648jq4stldwT7dt3FMYUIIoIAiCAiSNyz4F3D BCKICAIggoAIIoKIIIEIIoIAiCAiiAgigogggQgiggCIICKICCKCiCCBCCKCAIggIogIIoKI IIEIIoIAiCAiiAgigogggQgiggCIICJIIIKIIIEIIoIAiCAiSCCCiCAiiAgiggCIICJIIIKI ICIIiCAAIogIEoggIogIAiIIgAgiggQiiAgigoAIAiCCpyCCP+j3+z8bDodfnAIPHz5cn8q2 dOXnf/7n/9cd/4N+8iu/8iundCz9383P/3GOx9Iv/MIv/O/N/vw2iRQRBEAET18Ev7JhdEKs T2x7uvDdI/gnPaX2/EuT2zM9lh6SRBFBAETwDESQxApQPJbeMTwK5CsARBARJLECIghAvgJA BBFBEisgggDkKwBEEBEksQIiCEC+AkAEEUESKyCCAOQrAEQQESSxAiIIQL4CQAQRQRIrIIIA 5CsARBARJLECIghAvgJABBFBEisgggDkKwBEEBEksQIiCIggbQGACCKCJFZABIF8BQCIICJI Yj0Q6/X6exs+hZzf/u3f/uLP//zPf4e26MQT/rfIVwCIICJIYr0fIvjZuoq3b9+unz9/fsX7 9+/XbcKW0Z9t5r3t+PDhwxX7itevX1+1yYsXL1q3S5d48+bN+lSi2sev+d8iXwEggoggifUe ieDjx4/Xjx49uhKeZ8+erR88eLB++fJlo8DYMhb2s0lo2syzbbx69eqq7hYus/sIq7O1jZX3 9OnTq3axde0zrMxjC23PLkJbHQ+IIPkKABFEBO9HYt3E9zZ8Zj/PVQRNcIx4UjdBqesBOyYR 3Kf8aU+gb5+HybGJ4anHNu2JCG6XTxBBAEQQETywCEqy/sLmrXhyriJowpcN2+qwr53gHesx rBNB+9x70rRn0Zf1clQ+vRfSeya9LJ9mP22alaVl23JWP/vd1+USE6XNpNZ737SckqB6uSaE pfDltV28vbSOcZ3as6g9gnXtYO1l07TMTOB0ed+HWk9tk6zcrD29zvazxfFwziL4RHLKF22k EBEEQAQRwQOIYEH+1ucugj/96U//XdPQpJ387fq4+HcmgiYJKhomOzqPyp/NZ6LhPW9+XZ8t 43Wyn7punc9++nzag6W/67b5sLetz6Z7OVnPXxQrFyYdLs/axeXT57N1eHtoD6ut09vC69i2 HVRoM3H15W1+HdZW2dQ6ZeXG9tRyWxwPiOBNilKICAIggojgLYlgC/lTfmvDqIHvFNb33RbL Ol8plNF2+YeF5b/doYxv+3Ibefj9JhGMn9tJ38Uv6xE0YbDfbT7vbcqGhr2nKRuG9B7ArG7e M+i9Z3UiqPLmPZ/2mV8P6bQZBvf1qcDZNC/DtsU+8/Lsd+1NjL2YsX27tEPWLi66TUPyLoxZ OaX21HJbHA+v5bj8+jbH5bb/XzU5oW0dvltz4mmz/G+1yDXXpBARBEAEEcFbEMENv7fhZy2S chc+K6zvJx3KGCXLf6XD8n9WqMM/6VDGD3w5HxrOhkZ1mDBeJ1cSQZ/fhcjnLYmgClkbAdKb N7THrCSC3sumvX5RQJ14p7EJThwW1l5I+xnL8J4yawcfBtdt8J5AH2bdtwhm1/XFdteev7Yi qOW2OB5et+ghy/i0cGy/7lDGdwonjbbLvy7U4Tf3nEs+5hREEAARRARvr0fQBOuTStSapPDJ ObaViaCLkYYPn5o0uEh5mMiY5GQiGHuPogiqUFg5Jk511/KpdOj6moYydT0uj94zqHXS4dso glm7qJRZGXoHsa839gR622hZUSi9Xm3aoSSCcbt8WN6lPJtvGxFscTwwNFzPH1TzfZ0eQQBE EBG8RRFMet3qpPBsRTAOW8abPLznzSXHJSITQZ1Xy/J5/OYCLUevH/ReQh3OjWLkw7FetvW+ mVDGodp4A0apZ1FveMiuj7Rlve5Zu/j2uDjb51l72e++Th9GjtvYph1KIhiX9xtStN28l1Jv QsnKrWvPFscDInidn1V556P8NeUrAEAEEcE9i2ALKTxrEfThTL95I4YLTvwse6C0i5nLhv/0 eayMbB1+XaFeqxeHrGM9dL0+NJ09UDq7K9rX1/Sga22XeB1hXbtkQ8veaxrr3bUd6h7D49dQ xrpaXeKzIevKrWvPhuMBEfxS/j4pXReMCAIggojgHYlgQQofnrsIEsSe4pxF8GEb+UMEARBB RPBIRPDcQQQJRJB8BYAIIoIkVkSQIBBB8hUAIogIkljPTAS/u2EEOb/xG7/xl3/8x3/8CW3R iYf8b5GvABBBRJDECqdwLL0rPUgcgHwFgAgigiRWQAQByFcAiCAiSGIFRBCAfAWACCKCJFZA BAHIVwCIICJIYgVEEIB8BYAIIoIkVkAEAchXAIggIkhiBUQQgHwFgAgigiRWQAQBEQQARBAR JLECIgjkKwBABBFBEisggkC+AgBEEBEksQIiCOQrAEAEEUESKyCCQL4CQAQRQUSQxAqIIJCv ABBBQARJrIAIAvkKABEERJDECoggkK8AEEFABDkAABEE8hUAIogIklgBEEEgXwEggoggiRUA EQTyFQAiiAiSWOH8WK/XozVBEPchnpCzABFEBO9EBDfxkIPndEXw9evX6+fPn68/fPhw48xj 0+3zLvHixYursgz7fduwdb99+7b4udWra90ssu08dJTq7vvBsN8zmuLp06cHr7e267b7RcvJ tnuXMm/z+LBj/EB1RQRP+zz9cIdlEUFEcP8iuInvbfhswxcbXnPwnK4I2onrwYMHN6TNTmZ2 7LSRD41Hjx6t37x5cyVx20rJy5cv148fP76iThS71s1P2ncdpbrbfrC2M+z3riJo7W3LHbre 2q7b7BcN23Y/hpxnz55dHYu3LYPbHB9WV6ufb7f9bvvg1atXncqxY922FRE8WxF8XZ1v7bz7 PUQQEbwTEQzytxYQwRMXQRMIO6FFqbCTk54Y379//1HyNHy6/fSTuIXO5/M0nOw+nlztRGon VFuuTkpsHb7urE5aBztJG9bro/Wwv3W++HtWvktL3B6bv9ROXUQw7o+68HZvI4Jefra9pf3j 85fqre3q8+gxEdun1J4qgpnk6rqzckrbke0Ln0eX1+2o28fxWI2fWxm6DaU29+PQftr89gUo Hn/yNyJ4+iKo593WUogIIoI7iWCN/CGCZySChp2I9KRof+uJ305SPs0E0Xv7XNi8jExmdFmX lZII2HSXmXjyjzLl8uO9MH4CzepqJ1vvZbSeJRWmKMJeP5VhPVH7ttl6dVnvyfPPvF1uWwRt 27y3rE4Evb18e6yOPt0/U5n0feHbmW1PbFcv2/72NvC6ldqzSQRdlLzXulSObofXSY8PX97r 573htnzcDm0vF7tM7Esi6L3ZTW3u2+XtbPWI/x82z5/8yZ98n5x1ViLYWgoRQUSwswi2lD/l 8w0jOD1+93d/9/s6pOUnSjsx6nCXC4H2lLh42UlKh+wymYnX+2UnTz2JumRGYYsypUPHPpxc V1cVMJvXBcI+9/X4NrlMZoLqPZYqktZ2LoJ6vVwmdG1E0P73vF5Om2HLUntZnVxConCpoOj+ iSJeEnPdHhee+Flde0YRdJl27G8/Jpr2i25H9uXAj5Nsed0OF8B4fGUiqP8rLsy277dpcz2e /Biy9f7RH/3Rb5GzTprPW56Pb0ghIogIthLBLeQPzoDRaHRtiNVPUnbiUXEqnZy9JyPrIYk9 Ozav96zYul00tBfHT94uHNpj0yRTXse6usYeTluPbaf3HHmPls8by7F62/xZ+X6NVxwS3FYE Sz2Cvp+c2EtV1yPo22d19eUzMfe/4/RSvaMI6jx6fWOpPbMeQW8H793T8krlxPpqW3i52TZ4 u+tnWr7u5yYRtGNHe/O6tnn8AmHbb8fqkydPyFlQksJ/jAgigogg7CyCfjJSIVQRjBfw+/VV bUTQRS9eR6hyZr97D6DKQxSBNiJYqmtcxoflDO8F9SFyX3csx8XB6ho/6yKC2Tb5kGCdCMa7 auNdriUR9CF8285s/xxCBEvt2TQ0rJci1JWzbxH0Xt66+tb1bm/T5lon7RFHBAERRAQZGoa9 o0PDPiyrQ1b6mZ8s9Zot+9tO0j6M5dc3xZOeDpfqPDG0rDh0F68pzIYgtVcxq2smgj586Ovx Mv0k7PV20czq6T2YbUXQexW1Daw8vdawyzWCbUTQh/+z9itJibapb/e2IljXnk0i6PvGxKqu nDYiGIfrVbbidui22/4pDQ2XRHCbNo9fFrwODA0zNNxjaBgR5GYRuM2bRVRQfLguDqW6KPmF 7dlQpYqgnzh1CNhPbqWh0ewmEr/xIOtV03I9SnX1HhqfNw5tx+u2/CYDL0fv6tRt9vJ0m7O/ Y/31+j8VAZebjG1FMA5p+7Z5+6qE6N/axt6jVur5clHMRLCuPaMIlnqAXaJK5cTtiCLo5foX HseXicdH3PbsZpG6x750afN4Q4vLr1x/+4Scxc0i3CyCCO5dBFtKISJ4wiLYtcep9EiUuoc/ a8/ObUSp3DZ12mWb97E9t9UmXbflkHW87f2y7+V33f5t2zz0jCKC5yWCPD4GETy8CNZIISKI CBIEcaDwywTCZRKI4OmLIA+URgSPRwTD8g85eBBBgiAOJ4LJ6xkRwdM+Tz/cYVlEEBG8XREE RJAgiDsPRBAQQUQQEYQ7P5beWdKhLYB8BYAIIoIkVkAEAchXAIggIkhiBUQQgHwFgAgigiRW QAQByFcAiCAiSGIFRBCAfAWACCKCJFZABAHIVwCIICJIYgVEEIB8BYAIIoIkVkAEAchXAIgg IkhiBUQQgHwFgAgigiRWQAQBEQQARBARJLECIgjkKwBABBFBEisggkC+AgBEEBEksQIiCOQr AEAEEUESKyCCQL4CQARpC0SQxAqIIJCvABBBQARJrIAIAvkKABEERJDECoggkK8AEEFABAEQ QSBfASCCiCCJFQARbM96vX64YQS3zybWtANsyd9BBAERRAQBEbwNEXy9Jgji2OMsZQgRRAQR QbgXIriJ7234zfsqgk+fPl0/fvz4xpnn9evX60ePHq3fvn3b6YzlZVm5XZe1ZWydyqtXr2rX 0yVKZR06srq/ePHiavv999gOhn+ebZeV6bx///5W6l3ap9qu2+yXuA7dFttu+9n1WNomuh4f Vqe4j7ata8O6760MbeIHGz7Z8BVEEBFEBOFkRLCSv882fGHH4X1NVuZ7dvJ68ODBlfjFE7Jt 25s3bzqd0Kwsl5kPHz50Wtbq8uzZs6t1GnZyzOqm69mmbncdWT2eP39+tf3+u7aDkwmGSZ+V 5/vJ2n1XGavbP9nxoNuzaxvHddj2+ReEu9gvdWH19Po6tt+2LedERfB1lSN/tuEnXaQQEUQE EUE4KhFM5E+51yJoJ6/Y2+Q9HH5SthOyCYoRxczkw6eXRNDnMUo9VrY++7xpmp+0rW5eZpSj WFdbvy1j00wwdRtsmtfVlrV5227zy5cvr00zWSst00UEs23OwtYR911JRKyusW623VZvaxOb 7tsel7GfmQhqu/q6tQ10X9e1Z51sWh11m2zZWH5pO/TYzNrBl4/bofPFNmkSOBXzujb3urk8 2t82vwq/zTubzf76BERQaSWFiCAiiAjCnYtgg/ydjAiqwPnJy05OflL2ITCb7kPGPpRlvU8m In5S9HL0hO4y5+JWEpXYI+jykYmjlWHr9jL9hFyqq83nJ2gdhrX5bR+60PmJuW6bdXusHJtf 5dmWMWx9pbpv0yPYJnxYOYbLvrerC5u3i3/m+1Pr5NuZ9RBru+p+cVlr2i9tRFB7BP2YsDK0 jXU7vCfZ6qH7QrfJlnf503bwdVs53ia6HU0i6OVYndq0uUq2fRZ7dO3zyWTy309MBFtJISKI CCKCcCci2EH+YjJ7fd/YnJC+8BOvn7xd7vzE7Z9pT4mdaP3EpVKjPTd6Qtdes9i7EyXAPnOh 8t+zIdEoWX5yL9VVBcyHU/1Eq/Lj6yuVE0/UcZu196jNUGpJBLUdnKZrz6LMxJ5D7aHVIU2t j8pN1sZthoa1nv5Z3X7JjgHF9o3XI26fyZZLudbDpmlPqdc9bpP2hvvy8bgubbuXp/vI/vYv Btu0eWxPm/7555//z/uYXyq65tGPUogIIoKIIBzyWPovG/5Fx6R17/GeGe+xUBnSE1d2cvYT cjyZZyLoJ309WfrJMJYVh0Rd1Jpkypct1TU7wbrwufTaSVu3PSvHJa3UFioLu4hgaWjY6uvr 1HbxHqdSz6Fva9wHcR9GEWySoUwES8dDab+U1uH7Q4UuK8N7hnU7YhuqCGpkXxRsPvv/yPZ9 1iNY6rXdps19H2vP6bt3784mJwUp/DeWmzlHIYKIIBysR3DDaMPvbfjLLZLWve4R9BOhDwtH EdRePT95tRFB713Ra7T0hKsn0EwE/WTYRgR9iC2ra1zGRUHFz4dktbxYTuxp0vK7iGCcbuv1 ddeJoA8t6s0jOrRYCr8GLeudOpQIlvZL3Tq899aHkWOPnv3ubbKNCOoXDT0u43w2Ld781HST xzZtrse8HWfWZpttvJf5ZYsewXU1/2fVyAw9goggIgiHHxqWaV2k8F5fI+gnXu9tcqHQ3kK9 Vs+vn4oneL/mKhsG85OozpNJgF4b5yfE0s0iXge9xrGuripgLqj+mV+w78JaKsfFRG9CiT2o TeLk17zptZBaZpe7hn3b7Wfd9YS67XGZkpRo2/kyTWWXRLBuvzTJpl5XqstZWX78tRXBbHmV TJV6lzjf9ni9ZxsR7NLmun/1etv1adw13Er+wrKIICKICMLdiWBHKby3IqjPhvPn0amw+Gfe exaH6nz4y6Uqe46g33jiJ9fS8+iy5wiW7tj0a86yZ7eV6ur18HltOZcAv74wG66N5fhwog9L enlxu+qepajD2PHGiS7PEdQ66rPsYriIuWz7XatWv7g/9W/73beztD3arnHd8caHpmciltZh 5fixoMeJy16st29fVq4ur+2u26HHdenGlrjObdvct0/bKtzJf4oimMofIogIIoJwlCLYQgrv rQiuCYI4utCbt05IBBvlDxFEBBFBOHoRLEjhTxFBgiB2DX1bicR9FsE/6CJ/iCAiiAjCvRLB +w4iSBDHF8l1mLxrGBBBRBAQwVsRwScbPoXbZxNr2gG25PuIICCCiCAggkC+AkAEAREksQIi COQrAEQQEEESKyCCQL4CQARpLxIrACII5CsARBARJLECIIJAvgJABBFBEisAIgjkKwBEEBEk sQIggkC+AkAEEUESKwAiCOQrAEQQESSxAiCCQL4CQAQRQRIrIIK0BZCvABBBRJDECoggAPkK ABFEBEmsgAgCkK8AEEFEkMQKiCAA+QoAEUQESayACAKQrwAQQUSQxAqIIAD5CgARRARJrIAI ApCvABBBRJDECoggAPkKABFEBEmsgAgCkK8AEEFEkMQKiCAgggCACCKCJFZABIF8BQCIICJI YgVEEMhXAIAIIoIkVkAEgXwFAIggIkhiBUQQyFcAiCBtgQiSWAERBPIVACIIiCCJFRBBIF8B IIKACJJYAREE8hUAIgiIIAAiCOQrAEQQESSxAiCCQL4CQAQRQRIrACII5CsARBARJLECIIJA vgJABBFBEisAIgjkKwBEEBEksQIggkC+AkAEEUESK5BwEEEgXwEggoggiRUQQQDyFQAiiAiS WAERBCBfASCCiCCJFRBBAPIVACKICJJYAREEIF8BIIKIIIkVEEEA8hUAIogIklgBEQQgXwEg goggiRUQQQDyFQAiiAiSWAERBCBfASCCiOBtnbzZ+bCnY+mnG75NWwD5CuBo/me+bbmZtkAE AQAAAAARBAAAAABEEAAAAAAQQQAAAABEEAAAAADOjv8HbnVplxWKO6EAAAAASUVORK5CYII= --------------010308010703090009080509-- --------------070709080607020403090005-- From Sebastian.Schumann@st.sk Tue Oct 26 23:58:44 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 030BD3A67AB for ; Tue, 26 Oct 2010 23:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.094 X-Spam-Level: X-Spam-Status: No, score=-0.094 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOD1E02euDqP for ; Tue, 26 Oct 2010 23:58:42 -0700 (PDT) Received: from mail1.st.sk (mail1.st.sk [195.146.138.74]) by core3.amsl.com (Postfix) with ESMTP id 58FE33A68CE for ; Tue, 26 Oct 2010 23:58:41 -0700 (PDT) X-TM-IMSS-Message-ID: <2394c0260000d850@st.sk> Received: from EXCHANGE1.st.sk ([fe80::5d7a:6a65:c8ef:4439]) by EXCHANGEKE1.st.sk ([fe80::c173:5b2:d585:d82a%10]) with mapi; Wed, 27 Oct 2010 09:00:25 +0200 From: Schumann Sebastian To: Peter Saint-Andre , "dispatch@ietf.org" Date: Wed, 27 Oct 2010 09:00:24 +0200 Thread-Topic: [dispatch] proposed SIXPAC charter Thread-Index: ActvypzJ6EHXgiwVRXmixTa9CbUA/gAXt36AAAjk/WA= Message-ID: <73B99B53AF1D5B4DA6E2BF049DF19C7501A21A3B60@EXCHANGE1.st.sk> References: <4CBDFCB8.302@stpeter.im> In-Reply-To: Accept-Language: en-US, sk-SK Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, sk-SK Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 27 Oct 2010 08:33:53 -0700 Subject: Re: [dispatch] proposed SIXPAC charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 06:59:27 -0000 Dear all, Peter, I think this initiative is touching some very actual problem, I second it a= s well. One question: Would you think that this interaction between SIP and XMPP wo= uld also be targeted not only by dual-stack clients but also on the network= side? That is, having a SIP based telephony infrastructure (w/o SIP presence) wit= h certain users and a XMPP based IM/P network (w/o Jingle) with the same u= sers? Having a mechanism of mapping the users in both networks, XMPP presen= ce could be enhanced with SIP based telephony states. Would you see this in= scope or rather out of scope of your proposal? Thanks. Sebastian > -----Original Message----- > From: dispatch-bounces@ietf.org > [mailto:dispatch-bounces@ietf.org] On Behalf Of Peter Saint-Andre > Sent: 19 October 2010 21:17 > To: dispatch@ietf.org > Subject: [dispatch] proposed SIXPAC charter > > Earlier this year, some folks in the RAI area proposed an > initiative to > define a few small extensions to both SIP and XMPP that would make it > easier to develop and deploy dual-stack SIP+XMPP endpoints. Based on > feedback provided on the DISPATCH list and received from the RAI ADs, > I've taken the liberty of rewriting the proposed charter, in the hopes > that fresh text will spur a more conclusive discussion. I'm > mostly just > trying to help the proponents put their best foot forward, so if folks > here have more feedback I'd expect that people like Simo Veikkolainen > and Emil Ivov will be able to engage in further discussion. > > /psa > > ### > > SIXPAC (SIP Integration with XMPP in Presence Aware Clients) > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Problem Statement > > Both the Session Initiation Protocol (SIP) and the Extensible > Messaging > and Presence Protocol (XMPP) are widely deployed technologies for > real-time communication over the Internet. In order to offer > a complete > suite of features as well as communication across multiple networks, > several user-oriented software applications support both SIP and XMPP, > and more software developers have expressed interest in building such > "dual-stack" solutions. Unfortunately, it is difficult to provide a > good end-user experience in such applications because SIP and XMPP are > not aware of each other. For example: > > - XMPP presence does not include availability states related to a SIP > voice call or video call (e.g., "on the phone"), thus preventing an > a dual-stack endpoint from showing presence-based > communication hints > > - There is no correlation between an XMPP IM session and a SIP voice > or video session, thus preventing a dual-stack endpoint > from providing > integrated user interfaces and communications history > > - SIP accounts and XMPP accounts are not directly correlated > in contact > lists or vCards (and not all deployed services support > storage of such > information), thus preventing a dual-stack endpoint from > knowing that > a contact has both SIP and XMPP capabilities > > Although some proprietary solutions exist to the foregoing > problems, it > would be preferable to define standardized solutions for the sake of > improved interoperability. > > Objectives > > Because both SIP and XMPP are easily extended through new SIP headers > and XMPP elements, it should be possible to provide tighter > integration > within dual-stack SIP/XMPP user agents to improve the user experience. > > Any such extensions should meet the following criteria: > > - Be completely optional and backwards-compatible for all endpoints > > - Work without changes to deployed infrastructure such as existing > SIP and XMPP servers, B2BUAs, firewalls, etc. > > The SIXPAC WG will define a small number of SIP and XMPP extensions to > solve the following use cases in dual-stack endpoints: > > - Including SIP-based availability states in XMPP presence (limited to > basic presence and availability states only, not the full range of > PIDF extensions) > > - Correlating an XMPP IM session with a SIP voice/video session, and > vice-versa > > - Advertising a SIP account address over XMPP and an XMPP account > address over SIP > > Additional use cases are out of scope, including anything > related to or > requiring server integration, multiparty communication, SIP-based IM > and presence, XMPP-based voice and video, file transfer, generalized > service discovery and capabilities exchange, full protocol translation > in communication gateways, shared credentials across both SIP and XMPP > accounts, rich presence extensions for features such as geolocation, > etc. Although such topics are important and interesting, they are out > of scope for this group. > > However, in addition to the protocol extensions explicitly mentioned > above, the group may also define best practices related to the > implementation and deployment of dual-stack SIP/XMPP endpoints, > including topics such as user agent configuration. > > Deliverables > > - Use cases and protocol requirements > > - XMPP presence extension for SIP-based availability states > > - Media session correlation extensions for SIP and XMPP > > - Contact address advertisement extensions for SIP and XMPP > > - Best practices for implementation and deployment of dual-stack > endpoints > > Milestones > > Feb 2011 Submit use cases and protocol requirements document to > IESG (Informational) > > Oct 2011 Submit XMPP presence extension document to IESG > (Standards Track) > > Oct 2011 Submit media session correlation extensions document to IESG > (Standards Track) > > Oct 2011 Submit contact address advertisement extension document to > IESG (Standards Track) > > Oct 2011 Submit best practices document to IESG (Informational) > > ### > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From emcho@sip-communicator.org Wed Oct 27 10:20:43 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07EAE3A69FF for ; Wed, 27 Oct 2010 10:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlVi4dPFm7MQ for ; Wed, 27 Oct 2010 10:20:40 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 112123A698E for ; Wed, 27 Oct 2010 10:20:39 -0700 (PDT) Received: by bwz12 with SMTP id 12so812506bwz.31 for ; Wed, 27 Oct 2010 10:22:29 -0700 (PDT) Received: by 10.204.119.145 with SMTP id z17mr7656273bkq.128.1288200149183; Wed, 27 Oct 2010 10:22:29 -0700 (PDT) Received: from porcinet.local ([78.90.181.123]) by mx.google.com with ESMTPS id d12sm7167084bkw.7.2010.10.27.10.22.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 27 Oct 2010 10:22:26 -0700 (PDT) Message-ID: <4CC85FCF.50009@sip-communicator.org> Date: Wed, 27 Oct 2010 20:22:23 +0300 From: Emil Ivov Organization: SIP Communicator User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: Schumann Sebastian References: <4CBDFCB8.302@stpeter.im> <73B99B53AF1D5B4DA6E2BF049DF19C7501A21A3B60@EXCHANGE1.st.sk> In-Reply-To: <73B99B53AF1D5B4DA6E2BF049DF19C7501A21A3B60@EXCHANGE1.st.sk> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org" Subject: Re: [dispatch] proposed SIXPAC charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 17:20:43 -0000 Hey Sebastian, =D0=9D=D0=B0 27.10.10 10:00, Schumann Sebastian =D0=BD=D0=B0=D0=BF=D0=B8=D1= =81=D0=B0: > Dear all, Peter, I think this initiative is touching some very actual > problem, I second it as well. >=20 > One question: Would you think that this interaction between SIP and > XMPP would also be targeted not only by dual-stack clients but also > on the network side? That is, having a SIP based telephony > infrastructure (w/o SIP presence) with certain users and a XMPP based > IM/P network (w/o Jingle) with the same users? Having a mechanism of > mapping the users in both networks, XMPP presence could be enhanced > with SIP based telephony states. Would you see this in scope or > rather out of scope of your proposal? As it is the charter states: > - Including SIP-based availability states in XMPP presence (limited > to basic presence and availability states only, not the full range > of PIDF extensions) Is this what you mean or did I miss something? Cheers, Emil >=20 > Thanks. Sebastian >=20 >> -----Original Message----- From: dispatch-bounces@ietf.org=20 >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Peter Saint-Andre=20 >> Sent: 19 October 2010 21:17 To: dispatch@ietf.org Subject: >> [dispatch] proposed SIXPAC charter >>=20 >> Earlier this year, some folks in the RAI area proposed an=20 >> initiative to define a few small extensions to both SIP and XMPP >> that would make it easier to develop and deploy dual-stack SIP+XMPP >> endpoints. Based on feedback provided on the DISPATCH list and >> received from the RAI ADs, I've taken the liberty of rewriting the >> proposed charter, in the hopes that fresh text will spur a more >> conclusive discussion. I'm mostly just trying to help the >> proponents put their best foot forward, so if folks here have more >> feedback I'd expect that people like Simo Veikkolainen and Emil >> Ivov will be able to engage in further discussion. >>=20 >> /psa >>=20 >> ### >>=20 >> SIXPAC (SIP Integration with XMPP in Presence Aware Clients) >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> Problem Statement >>=20 >> Both the Session Initiation Protocol (SIP) and the Extensible=20 >> Messaging and Presence Protocol (XMPP) are widely deployed >> technologies for real-time communication over the Internet. In >> order to offer a complete suite of features as well as >> communication across multiple networks, several user-oriented >> software applications support both SIP and XMPP, and more software >> developers have expressed interest in building such "dual-stack" >> solutions. Unfortunately, it is difficult to provide a good >> end-user experience in such applications because SIP and XMPP are=20 >> not aware of each other. For example: >>=20 >> - XMPP presence does not include availability states related to a >> SIP voice call or video call (e.g., "on the phone"), thus >> preventing an a dual-stack endpoint from showing presence-based=20 >> communication hints >>=20 >> - There is no correlation between an XMPP IM session and a SIP >> voice or video session, thus preventing a dual-stack endpoint from >> providing integrated user interfaces and communications history >>=20 >> - SIP accounts and XMPP accounts are not directly correlated in >> contact lists or vCards (and not all deployed services support=20 >> storage of such information), thus preventing a dual-stack endpoint >> from knowing that a contact has both SIP and XMPP capabilities >>=20 >> Although some proprietary solutions exist to the foregoing=20 >> problems, it would be preferable to define standardized solutions >> for the sake of improved interoperability. >>=20 >> Objectives >>=20 >> Because both SIP and XMPP are easily extended through new SIP >> headers and XMPP elements, it should be possible to provide >> tighter integration within dual-stack SIP/XMPP user agents to >> improve the user experience. >>=20 >> Any such extensions should meet the following criteria: >>=20 >> - Be completely optional and backwards-compatible for all >> endpoints >>=20 >> - Work without changes to deployed infrastructure such as existing=20 >> SIP and XMPP servers, B2BUAs, firewalls, etc. >>=20 >> The SIXPAC WG will define a small number of SIP and XMPP extensions >> to solve the following use cases in dual-stack endpoints: >>=20 >> - Including SIP-based availability states in XMPP presence (limited >> to basic presence and availability states only, not the full range >> of PIDF extensions) >>=20 >> - Correlating an XMPP IM session with a SIP voice/video session, >> and vice-versa >>=20 >> - Advertising a SIP account address over XMPP and an XMPP account=20 >> address over SIP >>=20 >> Additional use cases are out of scope, including anything related >> to or requiring server integration, multiparty communication, >> SIP-based IM and presence, XMPP-based voice and video, file >> transfer, generalized service discovery and capabilities exchange, >> full protocol translation in communication gateways, shared >> credentials across both SIP and XMPP accounts, rich presence >> extensions for features such as geolocation, etc. Although such >> topics are important and interesting, they are out of scope for >> this group. >>=20 >> However, in addition to the protocol extensions explicitly >> mentioned above, the group may also define best practices related >> to the implementation and deployment of dual-stack SIP/XMPP >> endpoints, including topics such as user agent configuration. >>=20 >> Deliverables >>=20 >> - Use cases and protocol requirements >>=20 >> - XMPP presence extension for SIP-based availability states >>=20 >> - Media session correlation extensions for SIP and XMPP >>=20 >> - Contact address advertisement extensions for SIP and XMPP >>=20 >> - Best practices for implementation and deployment of dual-stack=20 >> endpoints >>=20 >> Milestones >>=20 >> Feb 2011 Submit use cases and protocol requirements document to=20 >> IESG (Informational) >>=20 >> Oct 2011 Submit XMPP presence extension document to IESG=20 >> (Standards Track) >>=20 >> Oct 2011 Submit media session correlation extensions document to >> IESG (Standards Track) >>=20 >> Oct 2011 Submit contact address advertisement extension document >> to IESG (Standards Track) >>=20 >> Oct 2011 Submit best practices document to IESG (Informational) >>=20 >> ### >>=20 >> _______________________________________________ dispatch mailing >> list dispatch@ietf.org=20 >> https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ dispatch mailing > list dispatch@ietf.org=20 > https://www.ietf.org/mailman/listinfo/dispatch >=20 --=20 Emil Ivov, Ph.D. 67000 Strasbourg, Project Lead France SIP Communicator emcho@sip-communicator.org PHONE: +33.1.77.62.43.30 http://sip-communicator.org FAX: +33.1.77.62.47.31 From fluffy@cisco.com Wed Oct 27 15:36:18 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17E6A3A67B8 for ; Wed, 27 Oct 2010 15:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.517 X-Spam-Level: X-Spam-Status: No, score=-110.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gbz2BSI97hxn for ; Wed, 27 Oct 2010 15:36:16 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 1A7C43A679F for ; Wed, 27 Oct 2010 15:36:16 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGtGyEyrR7Ht/2dsb2JhbAChRHGkIJwjhUgEhFeFfIMI X-IronPort-AV: E=Sophos;i="4.58,248,1286150400"; d="scan'208";a="610663522" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 27 Oct 2010 22:38:04 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9RMc3kI003952; Wed, 27 Oct 2010 22:38:03 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058502C717F2@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 27 Oct 2010 16:38:09 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <72D7C149-465F-4F99-A910-888266865B79@cisco.com> References: <7F2072F1E0DE894DA4B517B93C6A05851B8654@ESESSCMS0356.eemea.ericsson.se>, <8DD97253-F7BC-4553-8303-4DB9FDD5D9F4@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058502C717F2@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1081) Cc: DISPATCH list Subject: Re: [dispatch] I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 22:36:18 -0000 On Oct 24, 2010, at 11:40 PM, Christer Holmberg wrote: > Hi, >=20 >> Uh, same as Paul, sorry, ignore my previous email. Don't know how I = missed this on first search. Thank you for sending the pointer to this. >>=20 >> What is the sate of this 3GPP doc and what is going on with the = registration? >=20 > The document is stable. A reason the package hasn't been registered = yet might be that people assume the info-event draft has to become RFC = first. >=20 > But, if that is not the case, I can inform people that the package can = be registered. >=20 > Regards, >=20 > Christer My understanding of the process is that the IANA registration for this = could be done as soon as IESG had approved info-events. And that has = already happened so I think this could start any time.=20 You can see that IANA has already created the registry at=20 http://www.iana.org/assignments/sip-parameters From christer.holmberg@ericsson.com Wed Oct 27 22:28:07 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A3AD3A683A for ; Wed, 27 Oct 2010 22:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.081 X-Spam-Level: X-Spam-Status: No, score=-6.081 tagged_above=-999 required=5 tests=[AWL=0.518, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWGU+VKm2DMu for ; Wed, 27 Oct 2010 22:28:05 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id F30103A67D7 for ; Wed, 27 Oct 2010 22:28:04 -0700 (PDT) X-AuditID: c1b4fb39-b7b54ae000003464-1c-4cc90a5310dd Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id BD.C7.13412.35A09CC4; Thu, 28 Oct 2010 07:29:55 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Thu, 28 Oct 2010 07:29:54 +0200 From: Christer Holmberg To: Cullen Jennings Date: Thu, 28 Oct 2010 07:29:53 +0200 Thread-Topic: [dispatch] I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt Thread-Index: Act2J6AnSZAOUWl2RAyAj7s1yCw7EAAOUVIA Message-ID: <7F2072F1E0DE894DA4B517B93C6A058502EBE8FB@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05851B8654@ESESSCMS0356.eemea.ericsson.se>, <8DD97253-F7BC-4553-8303-4DB9FDD5D9F4@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058502C717F2@ESESSCMS0356.eemea.ericsson.se> <72D7C149-465F-4F99-A910-888266865B79@cisco.com> In-Reply-To: <72D7C149-465F-4F99-A910-888266865B79@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH list Subject: Re: [dispatch] I-DAction:draft-kaplan-dispatch-info-dtmf-package-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 05:28:07 -0000 Hi,=20 >>>Uh, same as Paul, sorry, ignore my previous email. Don't=20 >>>know how I missed this on first search. Thank you for sending=20 >>>the pointer to this. >>>=20 >>>What is the sate of this 3GPP doc and what is going on=20 >>>with the registration? >>=20 >>The document is stable. A reason the package hasn't been=20 >>registered yet might be that people assume the info-event=20 >>draft has to become RFC first. >>=20 >>But, if that is not the case, I can inform people that the=20 >>package can be registered. >=20 >My understanding of the process is that the IANA registration=20 >for this could be done as soon as IESG had approved=20 >info-events. And that has already happened so I think this =20 >could start any time.=20 >=20 >You can see that IANA has already created the registry at=20 >http://www.iana.org/assignments/sip-parameters Yes. I expect the registration to take place after the next 3GPP CT1 meetin= g (which is held the week after IETF). Regards, Christer From lili.yang@huawei.com Thu Oct 28 00:42:08 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 633E33A683A for ; Thu, 28 Oct 2010 00:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.468 X-Spam-Level: ** X-Spam-Status: No, score=2.468 tagged_above=-999 required=5 tests=[AWL=1.404, BAYES_00=-2.599, DC_PNG_UNO_LARGO=0.558, EXTRA_MPART_TYPE=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bs1VZFb7P8H for ; Thu, 28 Oct 2010 00:42:06 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id A8DAD3A6839 for ; Thu, 28 Oct 2010 00:42:05 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAZ00KIMPGVSA@szxga05-in.huawei.com> for dispatch@ietf.org; Thu, 28 Oct 2010 15:43:44 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAZ00FTRPGUTF@szxga05-in.huawei.com> for dispatch@ietf.org; Thu, 28 Oct 2010 15:43:43 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.218.12; Thu, 28 Oct 2010 15:43:33 +0800 Received: from SZXEML504-MBX.china.huawei.com ([fe80::f572:551b:8896:c6ec]) by SZXEML401-HUB.china.huawei.com ([fe80::6581:44f5:2bdf:e9a5%15]) with mapi id 14.01.0218.012; Thu, 28 Oct 2010 15:43:41 +0800 Date: Thu, 28 Oct 2010 07:44:19 +0000 From: Lili Yang_lili In-reply-to: <4CC826B3.3000509@cisco.com> X-Originating-IP: [10.85.28.187] To: Paul Kyzivat Message-id: MIME-version: 1.0 Content-type: multipart/related; boundary="Boundary_(ID_DnaYF0n0HN1W1ufleB91lQ)"; type="multipart/alternative" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: Asking comments for draft-yang-dispatch-sip-connection-address-type Thread-index: Act1Bem7OXliaEz8RKO1RCrQ5C9I////ohUA//5kwqCAAxotgP/+Xgfw X-MS-Has-Attach: yes X-MS-TNEF-Correlator: References: <4CC6E578.6090806@cisco.com> <4CC826B3.3000509@cisco.com> Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Asking comments for draft-yang-dispatch-sip-connection-address-type X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 07:42:08 -0000 --Boundary_(ID_DnaYF0n0HN1W1ufleB91lQ) Content-type: multipart/alternative; boundary="Boundary_(ID_MDFX1MTDaElmYS1ebwP7+w)" --Boundary_(ID_MDFX1MTDaElmYS1ebwP7+w) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: base64 SGVsbG8gUGF1bCwNClBsZWFzZSBzZWUgaW5saW5lLg0KDQpCZXN0IHJlZ2FyZHMsDQpMaWxpDQoN CkZyb206IFBhdWwgS3l6aXZhdCBbbWFpbHRvOnBreXppdmF0QGNpc2NvLmNvbV0NClNlbnQ6IFdl ZG5lc2RheSwgT2N0b2JlciAyNywgMjAxMCA5OjE5IFBNDQpUbzogTGlsaSBZYW5nX2xpbGkNCkNj OiBkaXNwYXRjaEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IEFza2luZyBjb21tZW50cyBmb3IgZHJh ZnQteWFuZy1kaXNwYXRjaC1zaXAtY29ubmVjdGlvbi1hZGRyZXNzLXR5cGUNCg0KTGlsaSAtIGNv bW1lbnRzIGlubGluZS4NCg0KT24gMTAvMjcvMjAxMCAzOjQ2IEFNLCBMaWxpIFlhbmdfbGlsaSB3 cm90ZToNCg0KSGVsbG8gUGF1bCwNCg0KDQoNClRoYW5rcyBmb3IgeW91ciBmZWVkYmFjayENCg0K DQoNClRoZSBwcmVtaXNlIG9mIHRoaXMgZHJhZnQgaXMgdG8gZnVsZmlsbCB0aGUgc3BlY2lmaWMg cmVxdWlyZW1lbnQgaW4gM0dQUC4gQW5kIGl0J3MgYSBkaWZmZXJlbnQgY2FzZSB3aXRoIHRoZSAz UENDIGFzIHlvdSBtZW50aW9uZWQuDQoNCkNvbmN1cnJlbnQgd2l0aCBhIG5vcm1hbCBzZXNzaW9u IHNldC11cCB0b3dhcmRzIGEgcmVtb3RlIHBhcnR5LCBVRS0xIHdhbnRzIHRvIGVzdGFibGlzaCBh IENvbGxhYm9yYXRpdmUgU2Vzc2lvbiwgd2hpY2ggaXMgYW5jaG9yZWQgYXQgdGhlIFNDQyBBUywN Cg0KV2hhdCBpcyBhbiBTQ0M/DQpbTGlsaV06IFNDQyBBUyBpcyBTZXJ2aWNlIENlbnRyYWxpemF0 aW9uIGFuZCBDb250aW51aXR5IEFwcGxpY2F0aW9uIFNlcnZlciwgaXQgYW5jaG9ycyB0aGUgc2Vz c2lvbiBhbmQgZXhlY3V0ZXMgdHJhbnNmZXJyaW5nIG1lZGlhIGluIGRpZmZlcmVudCBVRXMgcmVs YXRlZCBwcm9jZWR1cmVzLiBBbmQgdGhlIG90aGVyIGtleSB3b3JkICBpcyBDb2xsYWJvcmF0aXZl IFNlc3Npb246IEEgc2V0IG9mIHR3byBvciBtb3JlIEFjY2VzcyBMZWdzIGFuZCByZWxhdGVkIG1l ZGlhIG9uIHR3byBvciBtb3JlIFVFcyBoYXZpbmcgSU1TIHN1YnNjcmlwdGlvbnMgdW5kZXIgdGhl IHNhbWUgb3BlcmF0b3IgdGhhdCBhcmUgcHJlc2VudGVkIGFzIG9uZSBSZW1vdGUgTGVnIGJ5IHRo ZSBTQ0MgQVMuDQoNCg0KDQp3aXRoIGEgbmV3IE1lZGlhIEZsb3ctQSBvbiBpdHNlbGYgYW5kIGEg bmV3IE1lZGlhIEZsb3ctQiBvbiBhbm90aGVyIFVFLTIuIEZvbGxvd2luZyBpcyB0aGUgaW5mb3Jt YXRpb24gZmxvdyBkZWZpbmVkIGluIDNHUFA6DQoNCltjaWQ6aW1hZ2UwMDEucG5nQDAxQ0I3NkFB LkUzNDlCRUQwXQ0KDQoNCg0KSSdkIGxpa2UgdG8gc2VlIHRoZSBpbnRlbmRlZCBvL2EgZGV0YWls cyBmb3IgZWFjaCBvZiBzdGVwcyAxLTYgYWJvdmUuDQoNCltMaWxpXTogRm9sbG93aW5nIGFyZSB0 aGUgZGV0YWlscyBkZWZpbmVkIGluIDNHUFA6DQoyLiAgICAgIFRoZSBTQ0MgQVMgc2VuZHMgYSBy ZXF1ZXN0IHRvIGVzdGFibGlzaCBhbiBBY2Nlc3MgTGVnIGF0IFVFLTIgZm9yIE1lZGlhLUIuDQoz LiAgICAgIFRoZSBTQ0MgQVMgc2VuZHMgYSBzZXNzaW9uIHNldHVwIHJlcXVlc3QgdG8gdGhlIHJl bW90ZSBwYXJ0eS4NCjQuICAgICAgVGhlIHJlbW90ZSBwYXJ0eSBzZW5kcyBhIHJlc3BvbnNlIHdp dGggdGhlIFNEUCBhbnN3ZXIgb2YgTWVkaWEtQSBhbmQgTWVkaWEtQiB0byB0aGUgU0NDIEFTLg0K NS4gICAgICBUaGUgU0NDIEFTIHNlbmRzIGEgcmVzcG9uc2Ugd2l0aCB0aGUgU0RQIGFuc3dlciBv ZiBNZWRpYS1BIHRvIFVFLTEgdG8gZXN0YWJsaXNoIE1lZGlhLUEgaW4gVUXigJExLg0KNi4gICAg ICBUaGUgU0NDIEFTIHNlbmRzIGEgcmVzcG9uc2Ugd2l0aCB0aGUgU0RQIGFuc3dlciBvZiBNZWRp YS1CIHRvIFVFLTIgdG8gZXN0YWJsaXNoIE1lZGlhLUIgaW4gVUXigJEyLg0KQWZ0ZXIgdGhlIGFi b3ZlIG9wZXJhdGlvbiwgYSBDb2xsYWJvcmF0aXZlIFNlc3Npb24gaXMgZXN0YWJsaXNoZWQsIGZv ciB3aGljaCBVRS0xIGJlY29tZXMgdGhlIENvbnRyb2xsZXIgVUUgYW5kIFVF4oCRMiBiZWNvbWVz IGEgQ29udHJvbGxlZSBVRS4gTWVkaWEtQSBpcyBlc3RhYmxpc2hlZCBiZXR3ZWVuIENvbnRyb2xs ZXIgVUUtMSBhbmQgdGhlIHJlbW90ZSBwYXJ0eSwgYW5kIE1lZGlhLUIgaXMgZXN0YWJsaXNoZWQg YmV0d2VlbiBDb250cm9sbGVlIFVFLTIgYW5kIHRoZSByZW1vdGUgcGFydHkuDQoNCg0KDQoNCkFu ZCBpbiBzdGVwMSwgdGhlIGVzc2lvbiBzZXR1cCByZXF1ZXN0IHNoYWxsIGluY2x1ZGUgZW5vdWdo IGluZm9ybWF0aW9uIGZvciB0aGUgU0NDIEFTIHRvOg0KDQotICAgICAgICBpZGVudGlmeSB0aGF0 IE1lZGlhLUEgc2hhbGwgYmUgZXN0YWJsaXNoZWQgaW4gVUUtMTsNCg0KLSAgICAgICAgaWRlbnRp ZnkgdGhhdCBNZWRpYS1CIHNoYWxsIGJlIGVzdGFibGlzaGVkIGluIFVFLTIgYW5kIHRoZSByZXF1 ZXN0ZWQgbWVkaWEgdHlwZSBhc3NvY2lhdGVkIHdpdGggTWVkaWEtQiAoZS5nLiB2aWRlbyk7DQoN Cg0KDQpOb3JtYWxseSB0aGUgVUUtMSBkb2VzbuKAmXQga25vdyB0aGUgSVAgYWRkcmVzcyBvZiB0 aGUgVUUtMiBidXQgb25seSB0aGUgU0lQIGFkZHJlc3MsIGhlbmNlIHdlIHByb3Bvc2UgVUUtMSBz ZW5kaW5nIHRoZSBvZmZlciB3aXRoIHRoZSBVRS0y4oCZcyBTSVAgYWRkcmVzcywgdG8gaWRlbnRp ZnkgdGhlIHJlcXVlc3RlZCBtZWRpYSB3aWxsIGJlIGVzdGFibGlzaGVkIGluIFVFLTIuDQoNCkhh dmluZyB0aGUgYWJvdmUgZGV0YWlsIHdvdWxkIGFsbG93IGEgbW9yZSBpbmZvcm1lZCBkaXNjdXNz aW9uIG9mIHRoZSBwb3NzaWJpbGl0aWVzLg0KKEkgZG9uJ3QgaGF2ZSBlbm91Z2ggZGV0YWlsIHRv IGtub3cgaWYgdGhpcyB3b3VsZCB3b3JrLCBidXQgcGVyaGFwcyBVRS0xIGNvdWxkIHNpbXBseSBz ZW5kIGEgUkVGRVIgdG8gVUUtMiwgd2l0aCBSZWZlci1UbyBvZiB0aGUgU0NDIGFuZCBhIEpvaW4g aGVhZGVyLikNCg0KW0xpbGldOiBUaGUgY2FzZSBVRS0xIHNlbmRpbmcgUkVGRVIgdG8gVUUtMiBv bmx5IGhhcHBlbnMgd2hlbiB0aGUgVUUtMSBhbHJlYWR5IGhhZCBhIHNlc3Npb24gd2l0aCByZW1v dGUgVUUtMy4gSW4gdGhpcyBjYXNlLCB0aGVyZSBpcyBubyBzZXNzaW9uIGJlZm9yZSBzdGVwMS4N Cg0KDQpJIGFtIG11Y2ggaGFwcGllciBrbm93aW5nIHRoYXQgaXRzIHRoZSBTQ0MsIHdoaWNoIGlz IHByZXN1bWFibHkgYSByZXNvdXJjZSB1bmRlciB0aGUgY29udHJvbCBvZiBVRS0xLCB0aGF0IGlz IGRvaW5nIHRoZSBoZWF2eSBsaWZ0aW5nLCByYXRoZXIgdGhhbiBwdXR0aW5nIHRoZSBidXJkZW4g b24gcmVtb3RlLXBhcnR5LCB3aGljaCBpcyBhbiBpbm5vY2VudCBieXN0YW5kZXIuDQpbTGlsaV06 IFllcywgaXTigJlzIHRoZSBTQ0MgQVMgc2hvdWxkIGRvIHRoZSByZWxhdGVkIHNwZWNpZmljIHBy b2NlZHVyZXMuIFRoZXJlIHNob3VsZCBiZSBubyBpbXBhY3Qgb24gcmVtb3RlIFVFLg0KDQoNCiAg ICBUaGFua3MsDQogICAgUGF1bA0KDQoNCg0KDQoNCkhvcGUgdGhpcyBjbGFyaWZpZXMuDQoNCg0K DQpUaGFua3MgYW5kIGJlc3QgcmVnYXJkcywNCg0KTGlsaQ0KDQoNCg0KDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBQYXVsIEt5eml2YXQgW21haWx0bzpwa3l6aXZhdEBjaXNj by5jb21dDQpTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDI2LCAyMDEwIDEwOjI4IFBNDQpUbzogTGls aSBZYW5nX2xpbGkNCkNjOiBTcGVuY2VyIERhd2tpbnM7ICdNYXllciBHZW9yZyc7IGRpc3BhdGNo QGlldGYub3JnPG1haWx0bzpkaXNwYXRjaEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBBc2tpbmcg Y29tbWVudHMgZm9yIGRyYWZ0LXlhbmctZGlzcGF0Y2gtc2lwLWNvbm5lY3Rpb24tYWRkcmVzcy10 eXBlDQoNCg0KDQpMaWxpLA0KDQoNCg0KSSBndWVzcyB0aGVyZSBpcyBncm93aW5nIGludGVyZXN0 IGluIGludm9sdmluZyBhIHNlcGFyYXRlIHZpZGVvIGRldmljZQ0KDQppbiBhIGNhbGwsIGJlY2F1 c2UgSSBoYXZlIHNlZW4gc2V2ZXJhbCBkaWZmZXJlbnQgcHJvcG9zYWxzIGZvciBob3cgdG8gZG8g aXQuDQoNCg0KDQpSZWdhcmRpbmcgdGhpcyBkcmFmdCAtIGZyb20gYSB0ZWNobmljYWwgcGVyc3Bl Y3RpdmUsIGJlY2F1c2UgaXQgcHJvcG9zZXMNCg0KYSBjaGFuZ2UgdG8gU0RQLCBpdCBzaG91bGQg cHJvYmFibHkgYmUgZGlzY3Vzc2VkIGluIE1NVVNJQy4gQnV0IGdpdmVuDQoNCnRoYXQgaXQgY29t cGV0ZXMgd2l0aCBvdGhlciBwcm9wb3NlZCBtZWNoYW5pc21zIHRoYXQgYXJlIG5vdCBlbnRpcmVs eQ0KDQpTRFAsIHBlcmhhcHMgZGlzcGF0Y2ggaXMgYSBnb29kIHBsYWNlIGZvciBpdC4NCg0KDQoN CkkgZG9uJ3QgdW5kZXJzdGFuZCB0aGUgcHJlbWlzZSBvZiB0aGlzIGRyYWZ0IC0gdGhhdCB0aGUg cGFydHkgc2VuZGluZw0KDQp0aGUgb2ZmZXIgZG9lc24ndCBrbm93IHRoZSBhZGRyZXNzIG9mIHRo ZSBtZWRpYSBzdHJlYW0gLSBvbmx5IHRoZSBzaXANCg0KVVJJLCBhbmQgdGhhdCB0aGVyZWZvcmUg dGhlIG90aGVyIHBhcnR5IHNob3VsZCB1c2UgdGhlIHNpcCBhZGRyZXNzIHRvDQoNCmVzdGFibGlz aCB0aGUgbWVkaWEgc3RyZWFtLg0KDQoNCg0KU29tZSBVQSB3aWxsIHByZXN1bWFibHkgaGF2ZSB0 byBlc3RhYmxpc2ggYSBzZXBhcmF0ZSBzaXAgZGlhbG9nIGluIG9yZGVyDQoNCnRvIGRldGVybWlu ZSB0aGUgbWVkaWEgY2FwYWJpbGl0aWVzIGFuZCBhZGRyZXNzLiBUaGUgcXVlc3Rpb24gaXMgd2hp Y2gNCg0KVUEgc2hvdWxkIGl0IGJlLiBJIHNlZSBubyBhZHZhbnRhZ2UgaW4gZGVsZWdhdGluZyB0 aGlzIHJlc3BvbnNpYmlsaXR5DQoNCmZyb20gdGhlIGRldmljZSB0aGF0IGtub3dzIHRoZSBTSVAg VVJJIHRvIHRoZSBvdGhlciB1bnN1c3BlY3RpbmcgcGFydHkuDQoNCkRvaW5nIHNvIHJlZHVjZXMg dGhlIGxpa2VsaWhvb2Qgb2YgYSBzdWNjZXNzZnVsIGNhbGwgYnkgaW1wb3NpbmcNCg0KYWRkaXRp b25hbCByZXF1aXJlbWVudHMgb24gdGhlIG90aGVyIHBhcnR5Lg0KDQoNCg0KSSBzZWUgbm8gcGFy dGljdWxhciBhZHZhbnRhZ2UgdG8gdGhpcyBhcHByb2FjaCBvdmVyOg0KDQotIEFsaWNlIGNhbGxz IEFubmEncyBkZXZpY2Ugc2lwOmFubmFAZXhhbXBsZTIubmV0PG1haWx0bzpzaXA6YW5uYUBleGFt cGxlMi5uZXQ+DQoNCi0gQWxpY2UgZGlzY292ZXJzIEFubmEncyBkZXZpY2UgdmlkZW8gYWRkcmVz cyBhbmQgY29kZWNzDQoNCi0gQWxpY2UgY29tYmluZXMgdGhhdCB2aWRlbyBpbmZvcm1hdGlvbiB3 aXRoIGhlciBvd24NCg0KICBhdWRpbyBpbmZvcm1hdGlvbiBpbnRvIGFuIG9mZmVyIHRvIEJvYi4N Cg0KKEknbSBnbG9zc2luZyBvdmVyIHRoZSBkZXRhaWxzIGhlcmUuIEJ1dCBpdHMgd2VsbCB1bmRl cnN0b29kIDNwY2MuKQ0KDQoNCg0KSW4gdGhhdCB3YXksIEJvYidzIGRldmljZSBuZWVkIGhhdmUg bm8gcGFydGljdWxhciBjYXBhYmlsaXRpZXMgb3RoZXINCg0KdGhhbiB0aGUgYWJpbGl0eSB0byBz dXBwb3J0IHZpZGVvIGFuZCBzb21lIHZpZGVvIGNvZGVjIGluIGNvbW1vbiB3aXRoDQoNCkFubmEn cyBkZXZpY2UuDQoNCg0KDQogICAgICAgICBUaGFua3MsDQoNCiAgICAgICAgIFBhdWwNCg0KDQoN Cg0KDQpPbiAxMC8yNi8yMDEwIDg6MDQgQU0sIExpbGkgWWFuZ19saWxpIHdyb3RlOg0KDQo+IEhl bGxvIFBhdWwsDQoNCj4NCg0KPiBJIGFtIExpbGkgWWFuZyBmcm9tIEh1YXdlaS4NCg0KPg0KDQo+ IEdlb3JnIE1heWVyIGFuZCBJIHdyb3RlIGFuIEktRA0KDQo+IChodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC15YW5nLWRpc3BhdGNoLXNpcC1jb25uZWN0aW9uLWFkZHJlc3MtdHlwZSkN Cg0KPiAsIHdoaWNoIGlzIHJlbGF0ZWQgdG8gYSBjdXJyZW50IDNHUFAgUmVsLTEwIGZlYXR1cmUs IG5hbWVseQ0KDQo+IEludGVyLVVFLVRyYW5zZmVyIGZvciBjYXNlcyB3aGVuIGEgc28tY2FsbGVk IGNvbGxhYm9yYXRpdmUgc2Vzc2lvbiBpcw0KDQo+IGVzdGFibGlzaGVkIGR1cmluZyBhIFNJUCBz ZXNzaW9uIGVzdGFibGlzaG1lbnQuDQoNCj4NCg0KPiBTbyBmYXIgd2UgZGlkIG5vdCByZWNlaXZl IGFueSBmZWVkLWJhY2sgZnJvbSBJRVRGIGxpc3Qgb24gdGhlIGRyYWZ0IGFuZA0KDQo+IHdlIHdv dWxkIGxpa2UgdG8gaGVhciB5b3VyIHBvaW50IG9mIHZpZXcuDQoNCj4NCg0KPiBJIHdpbGwgYXR0 ZW5kIHRoZSB1cGNvbWluZyBJRVRGIzc5IEJlaWppbmcgbWVldGluZywgYW5kIGl04oCZcyBhcHBy ZWNpYXRlZA0KDQo+IGlmIHlvdSBoYXZlIHNvbWUgdGltZSB0byBkaXNjdXNzIHRoZSBkcmFmdCBk dXJpbmcgdGhlIG1lZXRpbmcuDQoNCj4NCg0KPiBMb29raW5nIGZvcndhcmQgdG8geW91ciBmZWVk YmFjayENCg0KPg0KDQo+IFRoYW5rcyBhbmQgYmVzdCByZWdhcmRzLA0KDQo+DQoNCj4gTGlsaQ0K DQo+DQoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCj4NCg0KPiBMaWxpIFlhbmcNCg0KPiDljY7kuLrm ioDmnK/mnInpmZDlhazlj7hIdWF3ZWkgVGVjaG5vbG9naWVzIENvLiwgTHRkLg0KDQo+IENvbXBh bnlfbG9nbw0KDQo+DQoNCj4gUGhvbmU6ICs4Ni03NTUtMjg0MjI1NTMNCg0KPiBGYXg6ICs4Ni03 NTUtMjg0MjA0MTMNCg0KPiBNb2JpbGU6Kzg2LTEzNjMyNjMyMDY1DQoNCj4gRW1haWw6IExpbGku eWFuZ0BodWF3ZWkuY29tPG1haWx0bzpMaWxpLnlhbmdAaHVhd2VpLmNvbT4NCg0KPiDlnLDlnYDv vJrmt7HlnLPluILpvpnlspfljLrlnYLnlLDljY7kuLrln7rlnLDpgq7nvJbvvJo1MTgxMjkNCg0K PiBIdWF3ZWkgVGVjaG5vbG9naWVzIENvLiwgTHRkLg0KDQo+IEJhbnRpYW4sIExvbmdnYW5nIERp c3RyaWN0LFNoZW56aGVuIDUxODEyOSwgUC5SLkNoaW5hDQoNCj4gaHR0cDovL3d3dy5odWF3ZWku Y29tDQoNCj4NCg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KPg0KDQo+IOacrOmCruS7tuWPiuWFtumZ hOS7tuWQq+acieWNjuS4uuWFrOWPuOeahOS/neWvhuS/oeaBr++8jOS7hemZkOS6juWPkemAgee7 meS4iumdouWcsOWdgOS4reWIl+WHuueahOS4quS6uiDmiJYNCg0KPiDnvqTnu4TjgILnpoENCg0K PiDmraLku7vkvZXlhbbku5bkurrku6Xku7vkvZXlvaLlvI/kvb/nlKjvvIjljIXmi6zkvYbkuI3p mZDkuo7lhajpg6jmiJbpg6jliIblnLDms4TpnLLjgIHlpI3liLbjgIHmiJbmlaMg5Y+R77yJDQoN Cj4g5pys6YKu5Lu25LitDQoNCj4g55qE5L+h5oGv44CC5aaC5p6c5oKo6ZSZ5pS25LqG5pys6YKu 5Lu277yM6K+35oKo56uL5Y2z55S16K+d5oiW6YKu5Lu26YCa55+l5Y+R5Lu25Lq65bm25Yig6Zmk 5pys6YKu5Lu277yBDQoNCj4gVGhpcyBlLW1haWwgYW5kIGl0cyBhdHRhY2htZW50cyBjb250YWlu IGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBmcm9tDQoNCj4gSFVBV0VJLCB3aGljaA0KDQo+IGlz IGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHdob3NlIGFkZHJlc3MgaXMg bGlzdGVkIGFib3ZlLg0KDQo+IEFueSB1c2Ugb2YgdGhlDQoNCj4gaW5mb3JtYXRpb24gY29udGFp bmVkIGhlcmVpbiBpbiBhbnkgd2F5IChpbmNsdWRpbmcsIGJ1dCBub3QgbGltaXRlZCB0bywNCg0K PiB0b3RhbCBvciBwYXJ0aWFsDQoNCj4gZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBvciBkaXNz ZW1pbmF0aW9uKSBieSBwZXJzb25zIG90aGVyIHRoYW4gdGhlDQoNCj4gaW50ZW5kZWQNCg0KPiBy ZWNpcGllbnQocykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBlLW1haWwgaW4g ZXJyb3IsIHBsZWFzZQ0KDQo+IG5vdGlmeSB0aGUgc2VuZGVyIGJ5DQoNCj4gcGhvbmUgb3IgZW1h aWwgaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSBpdCENCg0KPg0K --Boundary_(ID_MDFX1MTDaElmYS1ebwP7+w) Content-type: text/html; charset=utf-8 Content-transfer-encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtpZiAhbXNvXT4N CjxzdHlsZT4NCnZcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCm9cOioge2JlaGF2 aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCndcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwp O30NCi5zaGFwZSB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KPC9zdHlsZT4NCjwhW2Vu ZGlmXS0tPjxzdHlsZT4NCjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIg NCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0K CXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAx O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IFw7IjsNCglwYW5vc2Ut MTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0KCXRleHQtanVzdGlmeTpp bnRlci1pZGVvZ3JhcGg7DQoJZm9udC1zaXplOjEwLjVwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvTGlzdCwgbGkuTXNvTGlzdCwg ZGl2Lk1zb0xpc3QNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1hcmdpbi10b3A6MGNtOw0K CW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MTAu MHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJdGV4 dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaDsNCgl0ZXh0LWluZGVudDotMTAuMHB0Ow0KCWZvbnQt c2l6ZToxMC41cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjpibGFjazt9DQpwLk1zb0xpc3QyLCBsaS5Nc29MaXN0MiwgZGl2Lk1zb0xpc3QyDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0K CW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjUuMHB0Ow0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCgltc28tcGFyYS1tYXJnaW4tdG9wOjBjbTsNCgltc28tcGFyYS1tYXJnaW4tcmln aHQ6MGNtOw0KCW1zby1wYXJhLW1hcmdpbi1ib3R0b206MGNtOw0KCW1zby1wYXJhLW1hcmdpbi1s ZWZ0OjIuMGdkOw0KCW1zby1wYXJhLW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWdu Omp1c3RpZnk7DQoJdGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaDsNCgl0ZXh0LWluZGVudDot MTAuMHB0Ow0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi57qv5paH5pysIENoYXIi Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC41 cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9 DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi5om55rOo5qGG5paH5pysIENoYXIiOw0K CW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtYWxpZ246anVzdGlm eTsNCgl0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoOw0KCWZvbnQtc2l6ZTo5LjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4u Q2hhcg0KCXttc28tc3R5bGUtbmFtZToi57qv5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazrnuq/mlofmnKw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkNoYXIwDQoJe21zby1zdHlsZS1uYW1lOiLmibnms6jm oYbmlofmnKwgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OuaJueazqOahhuaWh+acrDt9DQpwLkIyLCBsaS5CMiwgZGl2LkIyDQoJe21zby1zdHlsZS1uYW1l OkIyOw0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRv bTo5LjBwdDsNCgltYXJnaW4tbGVmdDo0Mi41NXB0Ow0KCXRleHQtaW5kZW50Oi0xNC4ycHQ7DQoJ cHVuY3R1YXRpb24td3JhcDpzaW1wbGU7DQoJdGV4dC1hdXRvc3BhY2U6bm9uZTsNCglmb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29s b3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0 OTdEO30NCnAuQjEsIGxpLkIxLCBkaXYuQjENCgl7bXNvLXN0eWxlLW5hbWU6QjE7DQoJbWFyZ2lu LXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjkuMHB0Ow0KCW1h cmdpbi1sZWZ0OjI4LjRwdDsNCgl0ZXh0LWluZGVudDotMTQuMnB0Ow0KCXB1bmN0dWF0aW9uLXdy YXA6c2ltcGxlOw0KCXRleHQtYXV0b3NwYWNlOm5vbmU7DQoJZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnAu Tk8sIGxpLk5PLCBkaXYuTk8NCgl7bXNvLXN0eWxlLW5hbWU6Tk87DQoJbWFyZ2luLXRvcDowY207 DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjkuMHB0Ow0KCW1hcmdpbi1sZWZ0 OjU2Ljc1cHQ7DQoJdGV4dC1pbmRlbnQ6LTQyLjU1cHQ7DQoJcHVuY3R1YXRpb24td3JhcDpzaW1w bGU7DQoJdGV4dC1hdXRvc3BhY2U6bm9uZTsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0 IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30N Ci0tPg0KPC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KICA8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCiA8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iWkgtQ04iIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5I ZWxsbyBQYXVsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UGxlYXNlIHNlZSBpbmxpbmUu IDxvOnA+DQo8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkxpbGkg PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg YWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6d2luZG93dGV4 dCI+DQogUGF1bCBLeXppdmF0IFttYWlsdG86cGt5eml2YXRAY2lzY28uY29tXSA8YnI+DQo8Yj5T ZW50OjwvYj4gV2VkbmVzZGF5LCBPY3RvYmVyIDI3LCAyMDEwIDk6MTkgUE08YnI+DQo8Yj5Ubzo8 L2I+IExpbGkgWWFuZ19saWxpPGJyPg0KPGI+Q2M6PC9iPiBkaXNwYXRjaEBpZXRmLm9yZzxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogQXNraW5nIGNvbW1lbnRzIGZvciBkcmFmdC15YW5nLWRpc3Bh dGNoLXNpcC1jb25uZWN0aW9uLWFkZHJlc3MtdHlwZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRl eHQtYWxpZ246bGVmdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5MaWxpIC0gY29t bWVudHMgaW5saW5lLjxicj4NCjxicj4NCk9uIDEwLzI3LzIwMTAgMzo0NiBBTSwgTGlsaSBZYW5n X2xpbGkgd3JvdGU6IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5IZWxsbyBQYXVsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1V UyI+VGhhbmtzIGZvciB5b3VyIGZlZWRiYWNrITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+VGhl IHByZW1pc2Ugb2YgdGhpcyBkcmFmdCBpcyB0byBmdWxmaWxsIHRoZSBzcGVjaWZpYyByZXF1aXJl bWVudCBpbiAzR1BQLiBBbmQgaXQncyBhIGRpZmZlcmVudCBjYXNlIHdpdGggdGhlIDNQQ0MgYXMg eW91IG1lbnRpb25lZC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5Db25jdXJyZW50IHdpdGggYSBub3JtYWwgc2Vzc2lv biBzZXQtdXAgdG93YXJkcyBhIHJlbW90ZSBwYXJ0eSwgVUUtMSB3YW50cyB0byBlc3RhYmxpc2gg YSBDb2xsYWJvcmF0aXZlIFNlc3Npb24sIHdoaWNoIGlzIGFuY2hvcmVkIGF0IHRoZSBTQ0MgQVMs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQi IHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtmb250LWZhbWlseTrlrovkvZMiPjxicj4NCldoYXQgaXMgYW4gU0NDPzxicj4N Cjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+W0xpbGldOiBTQ0MgQVMgaXMgU2VydmljZSBDZW50 cmFsaXphdGlvbiBhbmQgQ29udGludWl0eSBBcHBsaWNhdGlvbiBTZXJ2ZXI8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPiwgaXQgYW5jaG9ycyB0aGUgc2Vzc2lvbiBhbmQgZXhlY3V0ZXMgdHJhbnNm ZXJyaW5nIG1lZGlhIGluIGRpZmZlcmVudCBVRXMgcmVsYXRlZCBwcm9jZWR1cmVzLiBBbmQgdGhl IG90aGVyIGtleSB3b3JkJm5ic3A7IGlzDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPkNvbGxh Ym9yYXRpdmUgU2Vzc2lvbjogQSBzZXQgb2YgdHdvIG9yIG1vcmUgQWNjZXNzIExlZ3MgYW5kIHJl bGF0ZWQgbWVkaWEgb24gdHdvIG9yIG1vcmUgVUVzIGhhdmluZyBJTVMgc3Vic2NyaXB0aW9ucyB1 bmRlciB0aGUgc2FtZSBvcGVyYXRvciB0aGF0IGFyZSBwcmVzZW50ZWQgYXMgb25lIFJlbW90ZSBM ZWcgYnkgdGhlIFNDQyBBUy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+PGJyPg0KPGJy Pg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tVVMiPndpdGggYSBuZXcgTWVkaWEgRmxvdy1BIG9uIGl0c2VsZiBhbmQgYSBuZXcg TWVkaWEgRmxvdy1CIG9uIGFub3RoZXIgVUUtMi4gRm9sbG93aW5nIGlzIHRoZSBpbmZvcm1hdGlv biBmbG93IGRlZmluZWQgaW4gM0dQUDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGltZyB3aWR0aD0iNjQyIiBoZWlnaHQ9 IjUxNSIgaWQ9Il94MDAwMF9pMTA0MyIgc3JjPSJjaWQ6aW1hZ2UwMDEucG5nQDAxQ0I3NkFBLkUz NDlCRUQwIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTrlrovkvZMiPjxi cj4NCkknZCBsaWtlIHRvIHNlZSB0aGUgaW50ZW5kZWQgby9hIGRldGFpbHMgZm9yIGVhY2ggb2Yg c3RlcHMgMS02IGFib3ZlLjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOiMxRjQ5N0QiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBz dHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48c3BhbiBsYW5nPSJFTi1VUyI+W0xpbGldOiBGb2xsb3dp bmcgYXJlIHRoZSBkZXRhaWxzIGRlZmluZWQgaW4gM0dQUDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVm dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjIuJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRo ZSBTQ0MgQVMgc2VuZHMgYSByZXF1ZXN0IHRvIGVzdGFibGlzaCBhbiBBY2Nlc3MgTGVnIGF0IFVF LTIgZm9yIE1lZGlhLUIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIGxhbmc9IkVOLVVT Ij4zLiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgU0NDIEFTIHNlbmRzIGEgc2Vz c2lvbiBzZXR1cCByZXF1ZXN0IHRvIHRoZSByZW1vdGUgcGFydHkuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWdu OmxlZnQiPjxzcGFuIGxhbmc9IkVOLVVTIj40LiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBUaGUgcmVtb3RlIHBhcnR5IHNlbmRzIGEgcmVzcG9uc2Ugd2l0aCB0aGUgU0RQIGFuc3dlciBv ZiBNZWRpYS1BIGFuZCBNZWRpYS1CIHRvIHRoZSBTQ0MgQVMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxl ZnQiPjxzcGFuIGxhbmc9IkVOLVVTIj41LiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBU aGUgU0NDIEFTIHNlbmRzIGEgcmVzcG9uc2Ugd2l0aCB0aGUgU0RQIGFuc3dlciBvZiBNZWRpYS1B IHRvIFVFLTEgdG8gZXN0YWJsaXNoIE1lZGlhLUEgaW4gVUXigJExLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGln bjpsZWZ0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Ni4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgVGhlIFNDQyBBUyBzZW5kcyBhIHJlc3BvbnNlIHdpdGggdGhlIFNEUCBhbnN3ZXIgb2YgTWVk aWEtQiB0byBVRS0yIHRvIGVzdGFibGlzaCBNZWRpYS1CIGluIFVF4oCRMi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQt YWxpZ246bGVmdCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFmdGVyIHRoZSBhYm92ZSBvcGVyYXRpb24s IGEgQ29sbGFib3JhdGl2ZSBTZXNzaW9uIGlzIGVzdGFibGlzaGVkLCBmb3Igd2hpY2ggVUUtMSBi ZWNvbWVzIHRoZSBDb250cm9sbGVyIFVFIGFuZCBVReKAkTIgYmVjb21lcyBhIENvbnRyb2xsZWUg VUUuIE1lZGlhLUEgaXMgZXN0YWJsaXNoZWQgYmV0d2VlbiBDb250cm9sbGVyDQogVUUtMSBhbmQg dGhlIHJlbW90ZSBwYXJ0eSwgYW5kIE1lZGlhLUIgaXMgZXN0YWJsaXNoZWQgYmV0d2VlbiBDb250 cm9sbGVlIFVFLTIgYW5kIHRoZSByZW1vdGUgcGFydHkuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0 ZXh0LWFsaWduOmxlZnQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTrlrovkvZMiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5BbmQgaW4gc3RlcDEs IHRoZSA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPmVzc2lvbiBzZXR1cCByZXF1ZXN0IHNoYWxs IGluY2x1ZGUgZW5vdWdoIGluZm9ybWF0aW9uIGZvciB0aGUgU0NDIEFTIHRvOg0KPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1HQiI+LSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBpZGVudGlmeSB0aGF0IE1lZGlhLUEgc2hhbGwgYmUgZXN0YWJsaXNoZWQg aW4gVUUtMTs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLUdCIj4tJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlkZW50aWZ5IHRoYXQgTWVkaWEtQiBzaGFs bCBiZSBlc3RhYmxpc2hlZCBpbiBVRS0yIGFuZCB0aGUgcmVxdWVzdGVkIG1lZGlhIHR5cGUgYXNz b2NpYXRlZCB3aXRoIE1lZGlhLUIgKGUuZy4gdmlkZW8pOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tR0IiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tR0IiPk5v cm1hbGx5IHRoZSBVRS0xIGRvZXNuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgOyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+4oCZ PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj50IGtub3cgdGhlIElQIGFkZHJlc3Mgb2YgdGhlIFVF LTIgYnV0IG9ubHkgdGhlIFNJUCBhZGRyZXNzLCBoZW5jZSB3ZSBwcm9wb3NlIFVFLTEgc2VuZGlu ZyB0aGUNCiBvZmZlciB3aXRoIHRoZSBVRS0yPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPuKAmTwvc3Bhbj48c3BhbiBs YW5nPSJFTi1HQiI+cyBTSVAgYWRkcmVzcywgdG8gaWRlbnRpZnkgdGhlIHJlcXVlc3RlZCBtZWRp YSB3aWxsIGJlIGVzdGFibGlzaGVkIGluIFVFLTIuDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0 IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj48YnI+DQpIYXZpbmcgdGhlIGFib3ZlIGRl dGFpbCB3b3VsZCBhbGxvdyBhIG1vcmUgaW5mb3JtZWQgZGlzY3Vzc2lvbiBvZiB0aGUgcG9zc2li aWxpdGllcy48YnI+DQooSSBkb24ndCBoYXZlIGVub3VnaCBkZXRhaWwgdG8ga25vdyBpZiB0aGlz IHdvdWxkIHdvcmssIGJ1dCBwZXJoYXBzIFVFLTEgY291bGQgc2ltcGx5IHNlbmQgYSBSRUZFUiB0 byBVRS0yLCB3aXRoIFJlZmVyLVRvIG9mIHRoZSBTQ0MgYW5kIGEgSm9pbiBoZWFkZXIuKTxicj4N Cjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQi PjxzcGFuIGxhbmc9IkVOLVVTIj5bTGlsaV06PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4gVGhl IGNhc2UgVUUtMSBzZW5kaW5nIFJFRkVSIHRvIFVFLTIgb25seSBoYXBwZW5zIHdoZW4gdGhlIFVF LTEgYWxyZWFkeSBoYWQgYSBzZXNzaW9uIHdpdGggcmVtb3RlIFVFLTMuIEluIHRoaXMgY2FzZSwg dGhlcmUgaXMgbm8gc2Vzc2lvbiBiZWZvcmUgc3RlcDEuDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kzsNCmNvbG9yOiMx RjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWdu PSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj48YnI+ DQpJIGFtIG11Y2ggaGFwcGllciBrbm93aW5nIHRoYXQgaXRzIHRoZSBTQ0MsIHdoaWNoIGlzIHBy ZXN1bWFibHkgYSByZXNvdXJjZSB1bmRlciB0aGUgY29udHJvbCBvZiBVRS0xLCB0aGF0IGlzIGRv aW5nIHRoZSBoZWF2eSBsaWZ0aW5nLCByYXRoZXIgdGhhbiBwdXR0aW5nIHRoZSBidXJkZW4gb24g cmVtb3RlLXBhcnR5LCB3aGljaCBpcyBhbiBpbm5vY2VudCBieXN0YW5kZXIuPGJyPg0KPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj5bTGlsaV06PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4gWWVz LCBpdOKAmXMgdGhlIFNDQyBBUyBzaG91bGQgZG8gdGhlIHJlbGF0ZWQgc3BlY2lmaWMgcHJvY2Vk dXJlcy4gVGhlcmUgc2hvdWxkIGJlIG5vIGltcGFjdCBvbiByZW1vdGUgVUUuDQo8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OuWui+S9 kztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OuWu i+S9kyI+PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYW5rcyw8YnI+DQombmJzcDsmbmJzcDsm bmJzcDsgUGF1bDxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLUdCIj5Ib3BlIHRoaXMgY2xhcmlmaWVzLjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tR0IiPlRoYW5rcyBhbmQgYmVzdCByZWdhcmRzLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu Zz0iRU4tVVMiPkxpbGkgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+ LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBQYXVsIEt5eml2YXQgWzxhIGhy ZWY9Im1haWx0bzpwa3l6aXZhdEBjaXNjby5jb20iPm1haWx0bzpwa3l6aXZhdEBjaXNjby5jb208 L2E+XQ0KPGJyPg0KU2VudDogVHVlc2RheSwgT2N0b2JlciAyNiwgMjAxMCAxMDoyOCBQTTxicj4N ClRvOiBMaWxpIFlhbmdfbGlsaTxicj4NCkNjOiBTcGVuY2VyIERhd2tpbnM7ICdNYXllciBHZW9y Zyc7IDxhIGhyZWY9Im1haWx0bzpkaXNwYXRjaEBpZXRmLm9yZyI+ZGlzcGF0Y2hAaWV0Zi5vcmc8 L2E+PGJyPg0KU3ViamVjdDogUmU6IEFza2luZyBjb21tZW50cyBmb3IgZHJhZnQteWFuZy1kaXNw YXRjaC1zaXAtY29ubmVjdGlvbi1hZGRyZXNzLXR5cGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi PkxpbGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGd1ZXNzIHRoZXJlIGlzIGdyb3dpbmcg aW50ZXJlc3QgaW4gaW52b2x2aW5nIGEgc2VwYXJhdGUgdmlkZW8gZGV2aWNlPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPmlu IGEgY2FsbCwgYmVjYXVzZSBJIGhhdmUgc2VlbiBzZXZlcmFsIGRpZmZlcmVudCBwcm9wb3NhbHMg Zm9yIGhvdyB0byBkbyBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2FyZGluZyB0aGlz IGRyYWZ0IC0gZnJvbSBhIHRlY2huaWNhbCBwZXJzcGVjdGl2ZSwgYmVjYXVzZSBpdCBwcm9wb3Nl czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh bmc9IkVOLVVTIj5hIGNoYW5nZSB0byBTRFAsIGl0IHNob3VsZCBwcm9iYWJseSBiZSBkaXNjdXNz ZWQgaW4gTU1VU0lDLiBCdXQgZ2l2ZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+dGhhdCBpdCBjb21wZXRlcyB3aXRoIG90 aGVyIHByb3Bvc2VkIG1lY2hhbmlzbXMgdGhhdCBhcmUgbm90IGVudGlyZWx5PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlNE UCwgcGVyaGFwcyBkaXNwYXRjaCBpcyBhIGdvb2QgcGxhY2UgZm9yIGl0LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyI+SSBkb24ndCB1bmRlcnN0YW5kIHRoZSBwcmVtaXNlIG9mIHRoaXMgZHJhZnQg LSB0aGF0IHRoZSBwYXJ0eSBzZW5kaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPnRoZSBvZmZlciBkb2Vzbid0IGtub3cg dGhlIGFkZHJlc3Mgb2YgdGhlIG1lZGlhIHN0cmVhbSAtIG9ubHkgdGhlIHNpcDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5V UkksIGFuZCB0aGF0IHRoZXJlZm9yZSB0aGUgb3RoZXIgcGFydHkgc2hvdWxkIHVzZSB0aGUgc2lw IGFkZHJlc3MgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+ZXN0YWJsaXNoIHRoZSBtZWRpYSBzdHJlYW0uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIGxhbmc9IkVOLVVTIj5Tb21lIFVBIHdpbGwgcHJlc3VtYWJseSBoYXZlIHRvIGVzdGFibGlz aCBhIHNlcGFyYXRlIHNpcCBkaWFsb2cgaW4gb3JkZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+dG8gZGV0ZXJtaW5lIHRo ZSBtZWRpYSBjYXBhYmlsaXRpZXMgYW5kIGFkZHJlc3MuIFRoZSBxdWVzdGlvbiBpcyB3aGljaDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj5VQSBzaG91bGQgaXQgYmUuIEkgc2VlIG5vIGFkdmFudGFnZSBpbiBkZWxlZ2F0aW5n IHRoaXMgcmVzcG9uc2liaWxpdHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+ZnJvbSB0aGUgZGV2aWNlIHRoYXQga25vd3Mg dGhlIFNJUCBVUkkgdG8gdGhlIG90aGVyIHVuc3VzcGVjdGluZyBwYXJ0eS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+RG9p bmcgc28gcmVkdWNlcyB0aGUgbGlrZWxpaG9vZCBvZiBhIHN1Y2Nlc3NmdWwgY2FsbCBieSBpbXBv c2luZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IGxhbmc9IkVOLVVTIj5hZGRpdGlvbmFsIHJlcXVpcmVtZW50cyBvbiB0aGUgb3RoZXIgcGFydHku PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIHNlZSBubyBwYXJ0aWN1bGFyIGFkdmFudGFnZSB0 byB0aGlzIGFwcHJvYWNoIG92ZXI6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPi0gQWxpY2UgY2FsbHMgQW5uYSdzIGRldmlj ZSA8YSBocmVmPSJtYWlsdG86c2lwOmFubmFAZXhhbXBsZTIubmV0Ij4NCnNpcDphbm5hQGV4YW1w bGUyLm5ldDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+LSBBbGljZSBkaXNjb3ZlcnMgQW5uYSdzIGRldmljZSB2aWRl byBhZGRyZXNzIGFuZCBjb2RlY3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+LSBBbGljZSBjb21iaW5lcyB0aGF0IHZpZGVv IGluZm9ybWF0aW9uIHdpdGggaGVyIG93bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgYXVkaW8gaW5mb3JtYXRp b24gaW50byBhbiBvZmZlciB0byBCb2IuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPihJJ20gZ2xvc3Npbmcgb3ZlciB0aGUg ZGV0YWlscyBoZXJlLiBCdXQgaXRzIHdlbGwgdW5kZXJzdG9vZCAzcGNjLik8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tVVMiPkluIHRoYXQgd2F5LCBCb2IncyBkZXZpY2UgbmVlZCBoYXZlIG5vIHBhcnRp Y3VsYXIgY2FwYWJpbGl0aWVzIG90aGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPnRoYW4gdGhlIGFiaWxpdHkgdG8gc3Vw cG9ydCB2aWRlbyBhbmQgc29tZSB2aWRlbyBjb2RlYyBpbiBjb21tb24gd2l0aDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5B bm5hJ3MgZGV2aWNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFBhdWw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiAxMC8yNi8yMDEwIDg6MDQgQU0sIExpbGkg WWFuZ19saWxpIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IEhlbGxvIFBhdWwsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsg PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZndDsgSSBhbSBMaWxpIFlhbmcgZnJvbSBIdWF3ZWkuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsg PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZndDsgR2VvcmcgTWF5ZXIgYW5kIEkgd3JvdGUgYW4gSS1EIDxvOnA+DQo8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZndDsgKDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXlhbmctZGlz cGF0Y2gtc2lwLWNvbm5lY3Rpb24tYWRkcmVzcy10eXBlIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC15YW5nLWRpc3BhdGNoLXNpcC1jb25uZWN0aW9uLWFkZHJlc3MtdHlwZTwvYT4p PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZndDsgLCB3aGljaCBpcyByZWxhdGVkIHRvIGEgY3VycmVudCAzR1BQIFJlbC0x MCBmZWF0dXJlLCBuYW1lbHkNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IEludGVyLVVFLVRyYW5zZmVyIGZvciBj YXNlcyB3aGVuIGEgc28tY2FsbGVkIGNvbGxhYm9yYXRpdmUgc2Vzc2lvbiBpcw0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZndDsgZXN0YWJsaXNoZWQgZHVyaW5nIGEgU0lQIHNlc3Npb24gZXN0YWJsaXNobWVudC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBTbyBmYXIgd2UgZGlkIG5vdCByZWNlaXZlIGFueSBm ZWVkLWJhY2sgZnJvbSBJRVRGIGxpc3Qgb24gdGhlIGRyYWZ0IGFuZA0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsg d2Ugd291bGQgbGlrZSB0byBoZWFyIHlvdXIgcG9pbnQgb2Ygdmlldy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n PSJFTi1VUyI+Jmd0OyBJIHdpbGwgYXR0ZW5kIHRoZSB1cGNvbWluZyBJRVRGIzc5IEJlaWppbmcg bWVldGluZywgYW5kIGl0PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPuKAmTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ cyBhcHByZWNpYXRlZA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgaWYgeW91IGhhdmUgc29tZSB0aW1lIHRvIGRp c2N1c3MgdGhlIGRyYWZ0IGR1cmluZyB0aGUgbWVldGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1V UyI+Jmd0OyBMb29raW5nIGZvcndhcmQgdG8geW91ciBmZWVkYmFjayE8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n PSJFTi1VUyI+Jmd0OyBUaGFua3MgYW5kIGJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+Jmd0OyBMaWxpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZndDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgTGlsaSBZYW5nPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsg PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseToNCuWui+S9kyI+5Y2O5Li65oqA5pyv5pyJ 6ZmQ5YWs5Y+4PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj5IdWF3ZWkgVGVjaG5vbG9naWVzIENv LiwgTHRkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IENvbXBhbnlfbG9nbzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT Ij4mZ3Q7IFBob25lOiAmIzQzOzg2LTc1NS0yODQyMjU1MzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IEZheDogJiM0 Mzs4Ni03NTUtMjg0MjA0MTM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBNb2JpbGU6JiM0Mzs4Ni0xMzYzMjYzMjA2 NTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh bmc9IkVOLVVTIj4mZ3Q7IEVtYWlsOiA8YSBocmVmPSJtYWlsdG86TGlsaS55YW5nQGh1YXdlaS5j b20iPg0KTGlsaS55YW5nQGh1YXdlaS5jb208L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseToNCuWui+S9kyI+5Zyw5Z2A77ya5rex5Zyz5biC6b6Z5bKX5Yy6 5Z2C55Sw5Y2O5Li65Z+65Zyw6YKu57yW77yaPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj41MTgx Mjk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyI+Jmd0OyBIdWF3ZWkgVGVjaG5vbG9naWVzIENvLiwgTHRkLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4m Z3Q7IEJhbnRpYW4sIExvbmdnYW5nIERpc3RyaWN0LFNoZW56aGVuIDUxODEyOSwgUC5SLkNoaW5h PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZndDsgPGEgaHJlZj0iaHR0cDovL3d3dy5odWF3ZWkuY29tIj5odHRwOi8vd3d3 Lmh1YXdlaS5jb208L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZndDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseToNCuWui+S9kyI+5pys6YKu5Lu25Y+K5YW26ZmE5Lu25ZCr5pyJ5Y2O5Li65YWs5Y+4 55qE5L+d5a+G5L+h5oGv77yM5LuF6ZmQ5LqO5Y+R6YCB57uZ5LiK6Z2i5Zyw5Z2A5Lit5YiX5Ye6 55qE5Liq5Lq6IOaIljwvc3Bhbj4NCjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5Og0K5a6L5L2TIj7nvqTnu4TjgILnpoE8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6DQrlrovkvZMiPuatouS7u+S9leWFtuS7luS6uuS7peS7u+S9leW9ouW8j+S9 v+eUqO+8iOWMheaLrOS9huS4jemZkOS6juWFqOmDqOaIlumDqOWIhuWcsOazhOmcsuOAgeWkjeWI tuOAgeaIluaVoyDlj5HvvIk8L3NwYW4+DQo8c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZn dDsgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseToNCuWui+S9kyI+5pys6YKu5Lu25Lit PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5Og0K5a6L5L2TIj7nmoTkv6Hmga/jgILlpoLmnpzmgqjplJnmlLbkuobm nKzpgq7ku7bvvIzor7fmgqjnq4vljbPnlLXor53miJbpgq7ku7bpgJrnn6Xlj5Hku7bkurrlubbl iKDpmaTmnKzpgq7ku7bvvIE8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7 IFRoaXMgZS1tYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgY29udGFpbiBjb25maWRlbnRpYWwgaW5m b3JtYXRpb24gZnJvbQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgSFVBV0VJLCB3aGljaDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7 IGlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHdob3NlIGFkZHJlc3Mg aXMgbGlzdGVkIGFib3ZlLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgQW55IHVzZSBvZiB0aGU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+ Jmd0OyBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGluIGFueSB3YXkgKGluY2x1ZGluZywg YnV0IG5vdCBsaW1pdGVkIHRvLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgdG90YWwgb3IgcGFydGlhbDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO LVVTIj4mZ3Q7IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlvbikgYnkg cGVyc29ucyBvdGhlciB0aGFuIHRoZQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgaW50ZW5kZWQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+ Jmd0OyByZWNpcGllbnQocykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBlLW1h aWwgaW4gZXJyb3IsIHBsZWFzZQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgbm90aWZ5IHRoZSBzZW5kZXIgYnk8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n PSJFTi1VUyI+Jmd0OyBwaG9uZSBvciBlbWFpbCBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIGl0ITxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --Boundary_(ID_MDFX1MTDaElmYS1ebwP7+w)-- --Boundary_(ID_DnaYF0n0HN1W1ufleB91lQ) Content-id: Content-type: image/png; name=image001.png Content-transfer-encoding: base64 Content-disposition: inline; filename=image001.png; size=21653; creation-date="Thu, 28 Oct 2010 07:44:19 GMT"; modification-date="Thu, 28 Oct 2010 07:44:19 GMT" Content-description: image001.png iVBORw0KGgoAAAANSUhEUgAAAoIAAAIDCAYAAACQHH9oAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAFQVSURBVHja 7Z1PqGNbdp9lbExj327a7jbdmvWkRIMnBZpkUANlZAjk0kUmb6BAQYUQ0KQHNegog349KGyjQZu4 iAdReIEKtCFEprAnnqQGIu6BC97QKU0qiePywCYvoTAd5w+K1s1Z9X533bXPH0lXV1f6Fnzce4/O 2Weffc5d59Pe50/vRz/6UQ8AAAAAzg8aAQAAAODcRfAb3/jGP/3mN7/5Odx/vva1r/3DuzyoOJZO B9uXJEqAMxeFXu/bv/qrv/ofyIm7s2nL0dGKoFXwxz/+8fr169dwj/nBD36w3vzD/tu7PKg4lk4D 24e2L0/5BLfZvn+/Scxr2A1rR4TppEVwNBgMPpAXd+PJkyf2//LpUYugVZS43/HZZ58dhQhyLN3/ sH146iL41a9+9a/evXvHzt4hrP2sHRGm0xbB4XD4xa7HyosXL9bPnz+/wV2fLz58+HCQ9fzwhz9E BInbD0SQ2FcggkSbQAQRwbbx6NGj9YMHD65J4NOnT6+m2c+7CJfTQwQiSBwkEEFiX4EIEm0CEUQE 24aJoBHj1atXV5cYvH379uDHrwvpIQIRJA4SiCCxr0AEiTaBCCKCbaMkgu/fv7/qFXzz5s3HaSZn Ni3rLXz8+PH65cuXH3sYnz17diWRNt3+tp8a1uvn89pnLpw2PVuH91J67+W+AhEkDhKIILGvQASJ NoEIIoJtIxNBkzIXLw8TO5vPPjNJtM9V7mxe+9zE0XoTXdrsd5tmn7nAuVDaZ/q3lWvXBtq6XCS9 jrY++9ymaVm7BiJIHCQQQWJfgQgSbQIRRATbhkmVDQG7uDnaS2dh0+IwsU6LvYdR1ux3F06b13oP Yz1UFP13y3kqpKVp2wYiSBwkEEFiX4EIEm0CEUQE20bsEfShWRU1EzyTRZ/XsWl+Xukqgjpv/FxF 0HsL47oRQeJeBSJI7CsQQaJNIIKIYNvIhoZdvry3z6TN5S3ij3nZVQRtKNiHmqMI+pBzZB+BCO4p 7EAo7RQ9UHy+jLZ3Jvk1BPcpEMFuUTqW7BjR46R0LLVJED6fHU/3KRBBok0ggohg2yjdLBKnx15C y51+zaB/3lYEs2v8bHnrjfR549Cw5mq7tjDefLJtIIJ7Cv/2kIXe4WM/s2sRsjuK6g7aQ91Wvq9A BNuHD0FkMqeJyefLjqWmIQMfVvCfd/WsrG0CEezWVm0ejOvzxWuWtp0vO6brvrzaidROgMa+HtWB CCKCbaMkgna8W45VOXNZ87uD480ibUXQ5c56AV3qtA66Lgv/3NbrQ9fcLHJk0UUEtx3X9zuF7MBE BBHBuvnqIt7p5kMe96W3FBFsdwzFa4qyi9P1zsZ9zFfaX3aclr7o+p2ZWu4+ejoQQUSwbfiXkNJn er6149lzaFzG5tMvPPa55lX7XZexc7rfiZytPz5L0P7fbL22/q5fxuoCEdxT3LYI2gHj3w7oEUQE m+arC0s8Mencp2MKEWyObH96L4K2ox0/8YTi8/kwVNv5SmEnLZe9OK+VadP15Gm/a0/ItoEIIoJE u0AE9xSH6BG8jydtD0Swfdy2CMbwh6bSI3g6IqjPJ9OwLwEuXdazUOp5s+l+PLSdr64u/lBdW3/M m9mQnA+97RKIICJItAtEcE+xj2sE28odIogI6ny7XG/qZXKN4GmJoPfA1V1z17bXbZfeOe/xi797 +JcQq+++/zcRQUSQaBeI4J6iSQT9263PV3cLul+TUHrXICJ43iLo0ubz2bFVugPdL+534hBc6SLp Yw5EsFtO8i8LdtzEh+O26U1uO18WMVdl1xXa/vRXcPm1grsOC1sggogg0S4QwT1F9m03S6RthoYt YfsJOuvZQQRPWwSz91tm+77N0LBfU+rEZ2Ldp55AD0SwW/gduX4jhl+n1/ZygG0vG/Dj2F+vZcQ7 I7N9672ZcRi5ayCCiCDRLhDBPYXfzBGHYfxCa5/ONYKIYJsoDcfp9G2vEfRj9T5KoP9PIYLlsJ7e Un7QS1Asj5RkS+9KbDtfDFsmexuC5sN4V6VH3RfrtoEIIoJEu0AE9xg+vOFDdX5XnfbquQjqcF3d MHAWiODpi6AeJ3Ys+WMD9OToImgn3OxYKj23zcuJ83OzyGmIoIt+9gUhPrA23rFr4T158XKWpvnq 1hXzl38J8UdhxEAE4ZhE0P8Hmt5FvE0u29dzM3cJRHDP4c8E8m/C2SMc4jfkumHgLCxx7uMamkMG Itg9dDjPe/D08Rv+XMkSpQTjw3OR+3JMIYLtcoR+kdAhVw3f9/7lNXtIbpf5dB+VRE4fY+PS6ncf 6xfoXb/sIoKI4L6idG3/rtdY+2vj7joQQeIggQgS+wpEsF34o1lKXySy+epGG9rO5/OWLj3w13L5 /6I/WkZvFtnHw3IRQURwX1G6pMuvtY7T/O078Yu7hU33nkA/1kuvqLV5DvE6WUSQOEgggsS+AhEk 2gQiiAjuK0oiGHu+vYdQRwZdBvXNOX55hN4lnz1n81DPd0UEiYMEIkjsKxBBok0ggojgviIbGvbr WP3yCLs7Pg4Ta8959rxWHRqO18XWXV6x70AEiYMEIkjsKxBBok0ggojgviJ7EUTdg/iza12z67Dj NYLaA5j1EN5WIILEQQIRJPYViCDRJhBBRHBf0eaxbzYE7Ne6+vBwFMF4HWCc5u/ltmjzHu99BSJI HCQQQWJfgQgSbQIRRAT3FW1EMHsndxwabhJBHw72u/IPFYggcZBABIl9BSJItAlEEBHcV7QVQR0q Npmz4eQmEYzDxT70vI8759sGIkgcJBBBYl+BCBJtAhFEBPcVbUTQn4npQ8N+jZ8+PD2KoA8fZy+d OGQggsRBAhEk9hWIINEmEEFE8C5i1wdEWw/hoV//iQgSBwlEkNhXIIJEm0AEEcH7FPbgaHsEzaGe HaiBCBIHCUSQ2FcggkSbQAQRwfsU/riZQz0yRgMRJA4SiCCxr0AEiTaBCCKCRLs4ehE0ebA7b+D+ 841vfOOf3uVB9a1vfetfsR9OA9uXpy6CP/nJT66k91j5wz/8w6Oun7UfInjyIvidX/zFX/wbcuJe eHK0InhmB/Waf27Y07H0zpIkbXE/2Xxp+ufW63nM/NzP/dz/OfY6WjtyPMExiavlZtoCEUQEAREE 8hUAIgiIIIkVEEEgXwEggoAIklgBEQTyFQAiCIggACII5CsARBARJLECIIJAvgJABBFBEisAIgjk KwBEEBEksQIggkC+AkAEEUESKwAiCOQrAEQQESSxAiCCQL4CQAQRQRIrkHAQQSBfASCCiCCJFRBB APIVACKICJJYAREEIF8BIIKIIIkVEEEA8hUAIogIklgBEQQgXwEggoggiRUQQQDyFQAiiAiSWAER BCBfASCCiCCJFRBBAPIVACKICJJYAREEIF8BIIKI4Ekn1k30N4w6LjPeMLWfLecfZL+3mf+Wt314 T46VASII5CsARBARJLHeRj2WJnUdBHC1YV6J4MKWb7mOYcWySc7alLnD9i7k99U9OE6GWudDimD1 JWFxov9/s/vyRYB8BYAIIoIk1ttY/2UlaK1EsJKCVTx5VlI4v0ciePTyt8U23ZYI3uq+OIIvQIgg IgiACCKCZyuC1iMyqnr22ojgNOsd2sRFKHPlPYV+os1E0H+XeRfJ9IXKpw2RirwaM62br7uatgjz DippXcs8K6nfIMjtJClnVmibeVhXv5o+Dts4TKZbnS9L5WiPYM32/8WGP83KDPUsrTfui7Fsu/cA D0NvqtbL5/H5xyWprD5fyfGy1P0v9VzpMSD1Gcp8i0Kb1ra1lL881GUI5CsARBAQwaNMrB1EcFE3 XyWVSxfD6oS7qhHBucpKmEflbyTLLFzQ9O9qG1ay7rFKWyUcU5W/IIKzMP+qZn3jsN0D7TXzayer emuddDtWIoujqi1K5QxbbP9fVL2C1+Qn2Uc31ivTfdkLny8T9yh2svwkLp+IoK5nqj3J+ney/1dZ L54cM53amh5BRBAAEUQESazdRXDeIII3yvETemlouJKfkYhcOnxcfTaIw7qVBC2r5WfhMxeZqQ5/ F0SwL+IwDj1dM9+2SrzmBcFaVvXpS3ssZdmpCNZCyh40lHNNuArbf9UjmElaIvPX1iuCFus57iKC YT1LFdbC8ku51nQqvcnp/m8QwW3aGhFEBAEQQUSQxNpBBCcFuRjpCbitCMow6FSG7+pEcJgIx1gF IEz3k/+kqUdQxGBUicNI1jsNTArtMxbpUHGMy2uv1VyHswvl1AnXuIsIZustiOC0mm8XEZx2FMFp 3N6OItiprRFBRBAAEUQESawdRFDEaJT0Ms20J0162eqGhlfh+sJVGBq+KJQzkmXm2mMXBOEyzNck guN4F3RSTia7gzDE6TfhjENZF1X5F6GdLqTHMytH26y0/a17BJP19pN9MS+IYGyvZXZc+PY0iOA8 DMe7rPUb9v84OWY6tTUiiAgCIIKIIIm1IDd11wKGi/hnSW+W9vLoTQeZCC7jY2iq3ruhDJHGci6l 92ouZcVtmMnyfhODDvcuVTCCWMyCjHnP4jy79q3Fdi9k+kwkaBGHm7NyQpuVtr+tCJbWq+21kHIH SS/aXG/yCG1aN3weRbAvN5nMws0rs7D/V+H4myY3EnVt60UUfUAEARBBRPAcRfAi9AYN9O/CMsNK 2gY1n/W1zMLvo+rk3td6VHXo+2ehfJ8+Km1DVkf52Rd5iI/CybbnxvoKbTKK213XVjKkOWgqJ7RZ tv12o8jfbdqWhvUOXMST6cPwZWAU2nRV7YNx3V24hfYdFfaz16cfeiJ1+mDHth42HeuACAIggogg iRWO/Vi60zeL9G752Yy9E3z245EcNz/e8P02xw75CgARRAQRQUAES+tf3Ofyz/i4ed37/8/VND6v k0LyFQAiiAjegghu+PQW+EE13Aa3CCIIJyaC6zopRAQBEEFE8P6I4G9WCR5ulzXcOj/lOLtVvmix D1wKEUEARBAR3LcIHnHdLquer4vqIvtRMo9dlD/pWO5IbjSY7lC/Sd3dnlW9J1uUeZGUM5W6T3st nysYtnnSYv1bt3XWI6ht0LWtpS7K+A7a+vc2/Evhdwo9tP+gMM+/7H35lhe4yecNEviuuo7wISII gAgiguclgvrsuHUvf8fwqld4aHFNuVM52S+2rNvVW0DqbiDohWfytd3m5I7Zj8/O65UfWlwnaB8f 1txi/Vu3dUEEr72armNbZA+ZTt+1fAxtXdXVHz007335iJg+1xfW7ofXdfJ3X/IVACKICCKC+63X x96f3pdvBcneaLHo3XwDxLCXPKS3mj4IIpiJgNFvqN+sYlHqpXJBCT/TunWUk2mHdvRn4807iOBW ba0iKO147WHQXdq6l7/FZViS77ts66r3ehHFUH6fH9s1nUcogqn8IYIAiCAieJ4i+PGhySIn8971 NzosqhPwMsznD15eSo9MfCDztTd8VIK4FMFbNQz7+ls4xqXent7NB1f7NsxrZGbfInjZZbld2tpF sHf9gc+rXngFXNu2LojgpNBbeedtHcoZBREc0StYbKsndfKHCAIggojgmYlgJQqrRE4+nkxlaDYK QHyl2yT2hvWSV73Fa+h68l7gwkl+mUlrg5zM6iSkg5ysEoYNbdpVBLdp67+uLuhfBHFbbtPWMkwd t/XymNtaylaR7vd4DuHJfnEFQAQRQRLrfusUXwM2TGRiItdjxVeMOf4aumsn/DA0HN9bO5Vlpy4y FQuRHr12bNVreJ1ZUodd5KQkqDfquq0IbtnWfxOlLiuvbVsXegQvM/E+lrYWkR4nyyCCiCAAIogI klh3FMF5JRH+nt4oJ6NwfdqwjQj2vnyv7EivI4x36cp69OaBWXaS30FOJlvKyY267iiCXdv6L9qI YNu2Ll0PWCNwd9rWcnNL6c5mRBARBEAEEUESa4s69bOhYTkBL+O1atXvizDkOJeT9VymLxIRjEOd i8JwZekatRu9QFvKifc0XYTtmHcRuqTcaRC0i175Hc3btvV/2/BJkPhpIoJt2zrrERztsUdwb20t 16EOC58PEEFEEAARRARJrO3rtQx3f+rw26r35bPphjJkOwjDlYsgG/pZFMFxGO6ctRU+lYpEThay /mGoT0ka5uGatEUQq+y6tUVHEZxmj4LZpa3lZpFZth+2aOthYVvHdfW+i7aWm16uIZ+Puz7eBhBB AEQQETxnERz3kufFte2d6TI99twcURsMbrn8+R7K6Mvv154j2OIRPOfU1gseH4MIAiCCiCCJtVvd lhyYt9a2o33LT493DRclk95ARBAAEUQESazbnUCPptcIEMEt2+WSdkAEARBBRJDECoggAPkKABFE BEmsgAgCkK8AEEFEkMQKiCAA+QoAEUQESayACAKQrwAQQUSQxAqIIAD5CgARRARJrIAIApCvABBB RJDECoggIIK0BQAiiAiSWAERBPIVACCCiCCJFRBBIF8BACKICJJYAREE8hUAIIKIIIkVEEEgXwEg goggIkhiBUQQyFcAiCAggiRWQASBfAWACAIiSGIFRBDIVwCIICCC7HxABIF8BYAIIoIk1vvGt771 rX9l2wAAAMfFN7/5zX+PXCCCiCAieKtsEs3nr1+/XhMEQRDHE+/evVt/9atf/SvkAhFEBBFBRJAg COLMAhFEBBFBRBARJAiCONNABBFBRBARRAQJgiDONBBBRBARRAQRQYIgiDMNRBARRAQRQUSQIAji TAMRRAQRQUQQESQIgjjTQAQRQUQQEUQECYIgzjQQQUQQEUQEEUGCIIgzDUQQEUQEEUFEkCAI4kwD EUQEEUFEEBEkCII400AEEUFEEBFEBAmCIM40EEFEEBFEBBFBgiCIMw1EEBFEBBFBRJAgCOJMAxFE BBFBRBARJAiCONNABBFBRBARRAQJgiDONBBBRBARRAQRQYIgiDMNRBARRAQRQUSQIAjiTAMRRAQR QUQQETyjePPmzRVv377tNH9k1/jw4cMVpXU2zRPn7bL9x7pfjjWyY8Wm+b7peoy8f/9+b8cRsXsg goggIogIIoJnEo8ePVo/ffp0/fz586vf7WeTnDx48OBqXuXx48e1yz179qzxJG/rLq3f1tk0T5y3 Tdjx521wbGHbcYxiZHWyNsuOJd832TFiZAL56tWrq/ltWdsPWdnEYQMRRAQRQUQQETyDcAnysF6Z JokqSUBT2DL7EME20WVeE9gXL150WuZQcd9FsMuxYTLoYTJo+4S4u0AEEUFEEBFEBM8ktIdmHyL4 8uXLjz2EVpad4G2a9xDZ+rwMm0d7E7VHyPHIegSzdfm8Xo79br2RpfByrQwrT9tF6+FleO+Vr9OX 0bqo9JbqGLfT2j6rW0kEfT1aNwv73afbOrL9Wdo23y9ZfW9TBGMvofdQE4ggIogIIoKIIHHAsJN/ nTS5BGTDft6DY5+51Ni+9SFXlSObpoLhn/nwtIeLYUkES+uy6V4fu2atJCU2j0uoC5u2hfZKucSq nHlb2Lrtp18fpz2tWR1dxHQ7VUI9SiIY6+YSG3t4rdxs27Pl7W/fniix2TGwzdBwm+F3b8tMjInD BSKICCKCiCAieGZhJ+k2J2qXgHgTgEuQ9ySZUGpPTxwats9s37usuAhqT5CLiYuFy43PU1pXlJ+S CLrA+ja41JWWKQmQXl/puMzU1dHXX5Kekgh6eb4uW4f3omn7ubhmy2tYHXz/6PaVtretCMZjxLdf 20n//+3LQZtLCIjbD0QQEUQEEUFE8Iyiy80Sba4R9J4vH0L1dWiPoEuD9zptI4KldbURQZck7bHy IeXSMnUiaOtWwTG0hzDW0cK23UUxGwqtE8G4LpO52Dalof44TfdBWxHMyo09w6XQYW2f3y8fQAKP IxBBRBARRAQRwTMJOxlnw5KlaBJBFR0dllUR1GFUFR4XqihKKhaxRzBbVxsRNDGLw+DagxZvYLC/ 4xCwrzMOodp0q5v/jHW09ah4e09YjJIYxbp5m2h7WZRugvFtiW3RVgSzuum2ldq8FN5+TY8FIg4X iCAiiAgigojgGYSJgh1D2WNgopSpHNQ9PsakwnvHfMjSpc0FRh9Z49O9R8s/85seolioCJbW1UYE VVqiJFldSo808Xp5XV0mvQ3i9FId42N7StcIZtdiet1sHd7T6MPL2tvmvZwxStvWRQRt3Vo/7U0t 1b30+BibN87PXcOIICCCiCAiSNxy+B282UN/rXem9IDppocFe+9eXF6vJbT9bvJjAuMPiXZsuShG pQdKZ+uKvWhZr1ppCNLq42XZ71aPOK/XL9s+E5hsetYe1gZ11whmbezb7nXT/x//zNajd2eXtjMu 78vW/R3L8P2YbXPbB0rXbSdxN4EIIoKIICKICBLEPQu/a9ikzCSNx7AQ2wYiiAgigoggIkgQ9zD8 ers2b4khiFIggoggIogIIoIEQRBnGoggIogIIoKIIEEQxJkGIogIIoKIICJIEARxpoEIIoKIICKI CBIEQZxpIIKIICKICCKCBEEQZxqIICKICCKCiCBBEMSZBiKICCKCiCAiSBAEcaaBCCKCiCAiiAgS BEGcaSCCiCAiiAgiggRBEGcaiCAiiAgigoggQRDEmQYiiAgigoggIkgQBHGmgQgigoggIogIEgRB nGkggoggIogIIoIEQRBnGoggIogIIoKIIEEQxJkGIogIIoKIICJIEARxpoEIIoKIICKICBIEQZxp IIKIICKICCKCBEEQZxqIICKICCKCiCBBEMSZBiKICCKCiOBB+NrXvvbHtg0AAHBc/PIv//J/RC4Q QUQQEYTzOZbeWdKhLYB8BYAIIoIkVkAEAchXAIggIkhiBUQQgHwFgAgigiRWQAQByFcAiCAiSGIF RBCAfAWACCKCJFZABAHIVwCIICJIYgVEEIB8BYAIIoIkVkAEAchXAIggIkhiBUQQgHwFgAgigiRW QAQBEQQARBARJLECIgjkKwBABBFBEisggkC+AgBEEBEksQIiCOQrAEAEEUESKyCCQL4CQARpC0SQ xAqIIJCvABBBQARJrIAIAvkKABEERJDECoggkK8AEEFABAEQQSBfASCCiCCJFQARBPIVACKICJJY ARBBIF8BIIKIIIkVABEE8hUAIogIklgBEEE40Xy1icmG6YYxbX6jXS72VFafNj1MmyCCiCAiCIgg kK/al7/YMN8wrH7Obmkdw3vY9tYegz2VtTri7Tz4/rF23bBEBBFBRBAQQYA7FkH5fdhWWKp5h7FX pzrBf5xuPWp2ws96G6vPLrK/XUx8PQ1Ckc6TTbd6FabfKCdKYLbNPk9dPb1dY9nV9EHDtg3Cclnd b7SVbGe/rk2y/SPLNtUtnS9rY9+3Pr+tr1rvINmei116YhFBRBARBEQQyFfbrWuiYlgzn53AZxUm OKNq+rzqXZq6XNhn1TyzeHKv5ptmf1fLeFlXvZZJPS6r9fg8C5Edr+Pce54qQfH55y69NeUsRayW Up+Vi1M1fVmVN89EumrXlWzbTNa3LGyby+My1Gcuyw+krZayP3w/+N8ubStZflWt49r+EUGra/dh 2D9LaY9xbONq3dPQVl6HSSKi810uU0AEEUFEEBBBIF91W0e/Oqmvmk7AIgHeczeqGOtQn4tHFKqO Ingpn62Snier80SXl/VdBrHw6yAXQdAuGsoZVtu2qNm2WZDkbFtXumzoCf0o0zXtPA/rGYsgfmwr F7uw7S5l07D8MmxnqW6Dhrppe0x1fil7Go6Poaw/tu9qx+MZEUQEEUFABIF8tcW6htmJP5lvIT1C YxGAlfT6GGu/FmwbEQzzLnXeatpltU7v0Yo9ZI7XtS9/z6Uns1SOSkxc90p6HocdRHAYr42LkpbN F7bn43bFtkqWm0pv3LBO1EMvpLbdpK5u2h4i2DM5BobJvo71XIkUzhFBRBARBEQQ4EcHuUbwMhGu YYvl+jKsp71OQ6VBjrqK4KRQl5EMNXqv1iirSzX/IA7xFso5lAguWorgpNC+24jgoCCCy7iOwnWG mQgO5HgY1rVhUs+5HE8jRBARRAQBEQQ4jAhqT86FS5CfrJP54wncr68bheHCYYuh4UkYElyEoeFJ Vq8w/zhKWDLUOxchmsv0mVwLl5WzlOvolkEY021rEsGaNh80tHOs+0SHhluIYFx+WrgWMtZtmd2c EuYbyTCvHgMXIsxNIjjyXsg9HNOIICKICAIiCOSrluWPw3DgOIpcssw8DB8ORaxWMqQ4DtMnSVlx uDPeLLKsues4DmXOqumDUOaisL5FQzmLsG3ZNi+CCC4KIriUXrO0zZNtWyTiq3UYFERwEUUwWX4R hNhv3BiHfThr0e7aHnpsLIKEqwh6z20U5CkiiAgigoAIAhw4X23zHLnStYS9js/ey+bXmyt2qEe/ ND37rE29e3t6ruAuZfV2fBDzLm0qIrhsauMt6rWsW24Tv7nhn2z4NiKICCKCgAgC+eq0t/toH8DM MXnzGsEdyxv5I28a5ntd3Xyyrn5PpRARRARJrIAIAvnq/m/3lP1/tPvmonTjzg4iOG0xn4rguiSF iCAiSGIFRBBOKl9VJzqAc+eLgghGKfxnG/4L+QMRRAQBEYRTEcERAPQ+b5BAy8c/3vD36BFEBBFB QASBfPVlGSO5czS9Fkse39H1Ro+FlLvtzQ+X1R2m/ab1dChzUrhLedH78h2+2UOam65TG7atyzG1 dXKn97W3rxxTW1fzL+Qu51E1/U2N/D2U5RkaRgQRQUAEgXwlZcQHE2evNJtXJ9Zhx7JXIgMXW9bP HzMyq5ln2rHMabZM78vn2pUenjxsEOpV2xsljqmte1++i9i38zKr2zG0de/6Y4xGst1+jeB/jfIX lkcEEUFEEBBBIF9Vy497N9+Fa0IwT06++jy4vjz/LYqMv7d3VJITmWfa0NPnz5Pr190pLD2aPkzo 5Y93kZMO7ehvvZh0FMGjaOte/oq+ZaGNvK0vqrIvq7Int93W1ToXST2tjCcb/lGv4RV0iCAiiAgC Igjkq+sn0VH8u3f9Qb7j3pcPTB7KUN5YhjEvq3m99857eW68YcMFo/flGyVqBc9P7L3Cw5VdKmT+ lcpRL38g87a9VBclQal+DjuK4FG0ddIjOO4VntvXu/46vJXUYZFJ2L7bOpQx6IW3yvQaHi2ECCKC iCAggkC+un4y7ie9Kwu59mohQuKf6Vsg/DVygyA1FwU5GWfz1NRvJJK0aCGCixYS0kZOVsl1a5OG 9uwqgkfR1jJMvQy/D5pEsGnbb7GtL7IvB72G92EjgoggIgiIIJCvCr0nIiBj7YkLn7koRG6IQEFO LsMJfyUyoGWNqmu+dN51g5zEV5XtIoLLGtm7VtcdRfAY2jobGp4WbmZZZdu6owh2amuZPi61KyKI CCKCgAgC+WpLEZQT9cdrCIOcjJMTdqOcyFDeqCAWw97199LOwnDhvDD82FUEJwVpWbURutINDduI 4JG0dSaCoy5tVCOCe21raZfLpnZFBBFBRBAQQSBftZSRRE4WlUgMgmBcu35M5Szc0TlJ5MR7ci7i PIUeo34iJ6s9iKDfhDIJkrkIstH6ruGCHF2U7rI9sraO1wiOam4W6SqCe23rpKxh3ZcbRBARRAQB EQTyVXn5SbhreC4ychmut9PPpjLcOJd5BiI1erLXZWd6HVgvee5dJSLzQp0Xyd2zC9meSdi+0t2s I6lrth3bPEdwkJVTmPco2lqWaXWNnqwn29b5bba1CGpk0NTeiCAiiAgCIgjkq0JvEG15q/toTjsc rq1Ld5YjgoggIgiIIJCv8jKmTSdP2Kl9B7TDQdq532vx1hNEEBFEBAERBPIVsgKn979w0XI+RBAR RAQBEQTyFcCZ/s8ggoggiRUQQSBfASCCgAiSWAERBPIVACIIiCCJFRBBIF8BIIKACJJYAREE8hUA Ikh7kVgBEEEgXwEggoggiRUAEQTyFQAiiAiSWAEQQSBfASCCiCCJFQARBPIVACKICJJYARBBIF8B IIKIIIkVABEE8hUAIogIklgBEaQtgHwFgAgigiRWQAQByFcAiCAiSGIFRBCAfAWACCKCJFZABAHI VwCIICJIYgVEEIB8BYAIIoIkVkAEAchXAIggIkhiBUQQgHx1x+0827CgLRBBRJDECoAIAvnqvNr4 csNqw5L2QAQRQRIrACII5Kvzad8LE8CqR3DZYv75hmm1zESmLSoGMq9Ps3kvZd6xTB8HIV1Wn81D OZNYVmkd1fSpfHaJCAIiSGIFRBDIV5CL3aXLXYv5lxVDkUgXwpH1LEq52XRf3pbtV7+Pqt+tV3JU zfdRTKvpc5HFpnXMZP6P60AEAREksQIiCOQr+LJtrZdtVv3eRQTH1e/DStKGgovdPPb4xeVlvd7L OAvzWtmD6mdfp4sIZutYVcLodZrHshFBQATZ+YAIAvnq3Nt2VfWe+TDqynvYGkRwGERwGZiIaC6r eRZxeRXQ6uc0W5eLXxTBmnVkdZojgoAIklgBEQTyFVyXsOkOIjhIJG1STZ94L141DLySHkPtEZxV TKKseU9gSQRr1rEK1yqOzuk6QUQQESSxAiIIZ5mvNvEV2mwnKVzK39du/MhEUOabVwI2DdfpLarp Y5G6pQzdjnXY10VUhnPnKn6JCJbWMZUh6rFee4gIAiKICAIiCCeUr6qT3vc3fL7hM9ps63YeaW9g JVMXyXyTOF3u6J2Ga/l8+kxkb1lJ4EynV5/1pXfy2nWEUVrr1lFNH/u1geckgYggIogIAiIIJ5+v NvFdkb+1gAge//681qMIiCAiiAgCIgjQmK8q+ft0w58F+UME79f+XCCCiCAiiAgCIgjQOl9t+IMa +QOAm3wgfyCCiCAggnAy+YoeQYDW/zP0CCKCiCAggnC6+apGCj9rKGsQHisykMen6PSL8JDkYVLW sGmeE2n/UdU+o2T7s7uKL7ZpCy8rK7NDGf1dlu9a18IxcdF03LVcx4WXtcWyJoJ/EY5PvZHmrF65 hwgigoAIwgnnqyCFTSK4kN/n8iDjmT9cufpsmjyUeBXuZM0+X55Y2/tr36ZRRqrpq6yNs+kN6xnK 6+S2voZQ9kP/FttkmO3navo6e3D1NseGfEEZ6nHbctm/X9UlPX79zS/kF0SQAwAQQTipfLWJr9d8 Ng6PHVlp740+uLjwlotxeKPFqnDCn5xQ2w9LAiMi3EoQt11PhzIG+qaUOxLBZfLMw5HL2DYiuGUd TQT/V5h2GY7fxSF6TxFBRBAQQYCjyFdRWjJpk2fdpSfh8J7dVeHzbLlF6J0ZSB3m0mMzE6lZyts+ ZpVQLLJ1BYmdyXoWYXu9vGEmufL5WOqwynqkpKdwFsqZBeEo1efa9KxHUOZZxB7ZpD7+XMJBnYhW dbzWtrLeTnUtiOBCh9Gr/TuR7dP54ltW4nFyo0ewdCy1FMFlaAd6BRFBAEQQTj9fFV5Tdum9V9XJ ddLUGxPkaxWuwZpmw5IuR0EqplFGg8wtRDgv9B26Oq/IhT88eaond/27rrdS5VDKHrToEewHuVgm Pas36uO9ZEGWllLGsFr/oiQyhfoMpIxRzReCC2nblUyfxzapq2tBBMehnGUY+ta2vghvQ4nLTcOy xWMpEcFsaFgFddC15xYRJLECIIJwX0WwTmj8vbhLOeG2FUE90c5r5KMvsnitjCgzsv5VLNN7m2LP m0xfihBOwzyrtm0jbwmpFUFpk4FKYZSrWJ/YvkF2lkGUhtX+8Z7Ti971dyRfyLa7lM/rrqvrfflK ulmo6ygRuGJdS+0oZfo6hlLeKtR/Jb2Uw/hlJK4vO5aq9pnK71c9guGLyqx0vCGCJFYARBDOSgR7 4XVqTSf/0Es07nISlWHXWXWSnjWJoAjqTK87E7Hwd/sutMcqEa9paV0NIjjvIIIT2bZJgwjeqFdJ BOWaP19+LNJ5bWg0GS4t3jQiw7JTvW4uEbFdRND3y0J7VgsiOFWRrRPB0rEkkuztfWNouLCNiCAi CIAIwlmI4CBI1qgwjLvSR8pkQtf1JFqdfC+jZDX0CM4LvVNxSNjfs7uQ5WZhO+cNIthPbpxZVcu2 EcG+SEg/2Y4b9anachHadpkI2CybJ6t/Mn2hyxe+EPRbiGCxrjUiOA7XPQ512Dy09VzaZVon43XH UqhLdo3gRRg+7yOCiCAnGUAE4WzylYpK9fcsDO+uRJqmyWdb9aZIr5733CziNX+JXI2l52ieXIe3 FMFdSy9lX3rRfPsum+ob6riQdmgUwVinRBJL9VnK9GUigpd6Q0qv8Fgal+Fk+ihp377eWSw3jAxK IlhX1wbJ1BtRVOZiWy+Tus1l20vLXjuWEhHMrhGch/ZZkGMQQQBEEM5FBKfZXcJyzV3dA6WzOzOH Hdbt17lde2hycveuiohfuzhK6tyvq4dsU79tfWV98XEwxYcnt61TVp8w/aKXPFBa6jSs2dZBL3mI c838/Wqdo7Avarc7q2tWl5rli9sV5htX60ofKF06lkIZ3+nVPFC6mmfeq7kLGxEksQIggnBy+ap3 Yg98Bigc5yaC72o+v+B/ARFEBAERhHMUwXHpzl6AMxLBaY+HSSOC7HxABIF8BXB+IgiIIIkVEEEg XwEggoAIAiCCQL4CQAQRQRIrACII5CsARBARJLEeUT311vfhGe6ncfzbn7Afpg/q2ip5FMYwe+L+ KYigv2op2/6aY+yi4zqKj4joenwn0y5JzIggACKICJ59YpUHqvrDMM/qwZfVw1SnInr6qqWFvhUh ebXSx1cvVZ9Pk/eirvbxDKljEkF5wGp8VtxUH7obBHqdPZm/YT36TtPFlnX9+F7YZPqc5IwIAiCC iOC5i+Cs6wn6xPbRMrTFLJGeqYpJJkUiQrWvyzoREVxmjwYReV4kx9hyWxHcsa6Lqvey9GosHu2A CAIggojgWYvgsuoVm7TpuZJ3Oa7k9UazrEcxvKDb3/84lJeRe4+bP80+vuR8JoJxo6zSOkTAlvKS 9NKT5bW+k+T1WBdNYuK9hgURHBYkROu3atrWSgR/P5mur2cahddRzf2p+qEtxkHcVoXXJy3ifpVX Mi2Tnj9/RdUqOcZmItSl+gzC9FXsEUyWXTQcryvZluwSAHoFEUEARBARPGsRXFUnyWvvY2wQQZW3 aXivoovMIPS2TasTb1x+JO93vDbcKL05U32BuAzdltYxCvOPCu+snCfipqIzy15IX2jDoYiQy0s6 LCllef0uRFhK2/pfN/xpsq0zkch5aFt9+fpQ1yXiusqu3Uv260xkrNQOU9n/Y2n7uUpyTX0+7n89 TsI7QOfhZfDLmusSJ1LnGy+w90sBSNCIIAAiiAieswgOE6kZNYhgfDH7XCRgJlLjQjWRnrphckJe ZSdl6aGb6pBtIhVxHVNZbirC009krCQRIxGrcQcRjNcIThrachzaLN3WqkfwXbKtg/AS+alKsghV bItxXFdd2+j+aSGCo9CDOJLP6uqT9SQOk2NuIGWu5J2gU33PrbTVUNY7ivuOBI0IAiCCiCCJ9frJ d7qDCF4bHvXhVzn5l0RwmIjAWOUmE8HCOqbSy6lcNMhONs9lEK0ozv26oeGGdvY6XgYRnBZE8Dtx W6WsgV/zJgI0KYjXVOWspQj224qg7NMLabs6EZzGYe2SCMqw+VSOj2EYTp/LjT/xxp05IogIAiCC iCCJ9brEXMTeuQ4iOA89WCM5Ec+jUIkIXBQEYxTLrpGj0jrGoY4XlSRFycuGouPNIpO6IdGmm0Va tmG/hQja0PDvFwTV7+KNvaSDwj6etxDBeSLbyw4iOHfCdtTVJ+7/bGg4O16HhfrHfTkI11D2EUFE EAARRATPOrGGHpZlOHEv2kqMSNvKr+EKvYXLcI2grnMscrPSGybq5Ki0jqTHbZkNgcabBZKbVZYq xoXPFlm9Wgr4LNywMWjoEfzTwraOqsezDEVoVXhm0t6LUrvW1HEWbkppI4Jep1HyWak+uv8XBRHU /b0oDb+XvtDo/DqEDYggACKICJ5tYq0EZNy7/gDfi1LPYOEEO6rK6CfTb1wjWIlGNr9PH4W6XNT8 fW0dQVonDT2cy4LsTpLev/hA6bi+i17LhybH7RTZTLdVhoaL21q376q6T5L5LhrqOUruti0dF7Hu w5rPBoU27vs+6xUeKK3HWmkbaq797Etbz3t7eMYj+QoAEQREkMTavk2GTXcmH7g+0/sgAz1eMbfv 9rw4puOQfAWACCKCJNZzaZPBsT27rXTnLCJ40sfhtMfDpMlXAIggIngsiXUT393w6YaHHDCACAIi CIAIIoInnlhF/v6surB+XfcMP0AEaQtABAEQQUTwHifWgvytEUFABAERBEAEEcETTKwt5E/519W8 AMoXG36HdoBbBBEEQAQRQUQQEEFABAEAEUQEb2WopZLC72/4vMfQMLQ/lhgahoPnKwBABBHBW0ys 1UEUpRARBEQQEEEARBARPKfEKlL4kAMGEEFABAEQQUSQxAqACAL5CgARRARJrIAIIoJAvgJABBFB EisgggDkKwBEEBEksQIiCEC+AkAEEUESKyCCAOQrAEQQESSxAiIIQL4CQAQRQRIrIIIA5CsARBAR JLECIghAvgJABBFBEisgggDkKwBEEBEksQIiCEC+AkAEEUESKyCCgAgCACKICJJYAREE8hUAIIKI IIkVEEEgXwEAIogIklgBEQTyFQAggoggiRUQQSBfASCCiCAiSGIFRBDIVwCIICCCJFZABIF8BYAI AiJIYgVEEMhXAIggIIIcAIAIAvkKABFEBEmsAIggkK8AEEFEkMQKgAgC+QoAEUQESawAiCCQrwAQ QUSQxAqACAL5CgARRARJrACIIJCvABBBRJDECvwDIYJAvgJABBFBEisgggDkKwBEEBEksQIiCEC+ AkAEEUESKyCCAOQrAEQQESSxAiIIQL4CQAQRQRIrIIIA5CsARBARJLECIghAvgJABBFBEisgggDk KwBEEBEksQIiCEC+AkAEEUESKyCCgAjSDgCIICJIYgVEEMhXAIAIIoIkVkAEd6rzYMPQfrIPyVcA iCAiSGIFOBMR3MRsw3LD1H+yH8lXAIggIkhiBThxEdxEf8Nqw0X1t/UMLtiP5CsARBARJLECnL4I TjbMKyG0oeF+i2WGVc+hCeSqmua9iksVyarspdCX5RcVVs6wmn9c/e3Tx9X0aVZWaR1Slq9n6esg XwEggoAIklgBEfxSsBYiTB/lq0EEVd6uJC2UOa96F5dh+jhZfuTzheneWzmoltWey3k1rbSOUZh/ pPORrwAQQUAESayACFaCFSWvhQiqfC1FzKZV7+BKxG5Z9Tz2s+VVAJPpCy031Htas46pXPc4FZHs n8gxRr4CQAQRQRIrIIJ7EcEbUrajCE71hpOqh857G6cdRXBeKLNpHdMgkc4F+QoAEQREkMQKiOCP Pt4coj2C/S1EcB5660YyNKxDxpd+rV4YtvUh4Gs3roggjkoiWLOOcajjRSWGiCAAIgiIIIkV7k4E N/GVDZ9s+MmGPzuC+s6l92wZbtBYtBBBF7i5DwubkFWfaW/hMlwjuEzWqY+yWbjk1fUIZuuQ6bpd M/IVACIIiCCJFQ4ugpv4usjfz+x4qziKxFT1rE30gdJVL9qgNH8ybVSJXj+ZfuMawUogs/lLdbmo +fvaOoK0Tk7tQdnkKwBEEBEkscKRi2Alf082/IGIX+TsElN2LSCQrwAQQUSQxAqnciz9pw3/okb+ AHaG/zUARBARRAThOI8l7xH87oZP7TpAegSBfAWACCKCJFY4IxEM00pSSGIC8hUAIogIkljhlEWw IIV/vuE/y3R/TMq1mx6qmyeGSlLmMHBSN0fIdo6z5wFW23yRzD/o2hZ6I8o2r6VL9kV/l/qQrwAQ QUQQEYQTEsFqnn71aJPvVH/ro07mySNYMgYiHqvw2Uqfr3dCErjSx8jI9q+z7fV26biea28t2UIC 18m+GMs8S/IVACKICCKCcN4iaLI3qn4fJW/UGPsz/PwhzMnyC5GPZSKaq1PqGYyvmQvytYzS5u26 iwhuUcdhUo/L8NDuq15f8hUAIogIIoJwhiIY397hb/dwMUzmXxaGg/1tHOnjWPy1bQVpWvjPMH0p r2q7FCm9Nr168PM0W1eQ2IWUO4vilvW4yUOpF/ImEu8NvNHTGbZpFGR5Eh5+faM+yfRl1iOYzDPo IILxAdxL8hUAIogIIoJwniI4Tnrwpio6cSixRgSHIkJ6Xdq8IIdzFzwtW4aXh7GOLpzV7/76uJF8 fm3I1utfidMkiNQ4rivUz3vxLkSiVtJG04J8+VtL5sm2LWX9WX2myXLXRLCabxZktVSXbGh4lEk8 +QoAEUQEEUE4PxEsDj1WIjHTnq+WIhivEZyVRKPqgRyJfA6T18ZFgVpVZerbPlYifhMVR6nfTN4L vKjmLT5QOmsbqWOtCGbiFj8r1Oda+5auEZTe16m8Bm8k5U1VcoVZ0ku43OZGFPIVACKICCKCcGIi WEnUKMxzIVKTXSPYbxoaLqx7LhIzDj2CqQhWf4/kJpaFlHUZRGson6+CJPkd0bcpgouqrgu523rZ UJ9GEZRez1m1zCws70PTw8Jwd1wHIgiACCKCiCCcqQhOXJZEPBaJ3NSJYO3NIjXrXoV39LbqESwI qg//6vWAH4dfq3pfRsFqEMFxWF+/7dBwqNMy+axUn3kQ83kignHZeU1dVpnUx97UXW7kIV8BIIKI ICII91cE+8k1goswvPvxkSPJY2NWQZa6iODSJUZufpg0iOBcHm2zCNfT6bWBk3A94aX0os3b9mCG Oi6lHRpFUOo0S7ajVJ9+Mj2K4Ex6UucqwEld1k2P8un6WBryFQAiiAgignAiIijiNwjTBlWP1qjh gdL9pLxBh/qNqvX0w8OTB6UyZWh2ULfewhD2OBn6HjTUcZg8WPsie2h0Ute67UjrU33mbZ8+UFrq NKjbhroHSst65uQrAEQQEUQE4XxFcHRqD3yG1sfHYpc7hslXAIggIogIwj0XwWq+WamHC0722Bjp o4HIVwCIICKICMKZiiAA+QoAEUQESayACAKQrwAQQUSQxAqIIAD5CgARRARJrIAIApCvABBBRJDE CoggAPkKABFEBEmsgAgCkK8AEEFEkMQKiCAgggCACCKCJFZABIF8BQCIICJIYgVEEMhXAIAIIoIk VkAEgXwFAIggIkhiBUQQyFcAiCBtgQiSWAERBPIVACIIiCCJFRBBIF8BIIKACJJYAREE8hUAIgiI IAAiCOQrAEQQESSxAiCCQL4CQAQRQRIrACII5CsARBARJLECIIJAvgJABBFBEisAIgjkKwBEEBEk sQIggkC+AkAEEUESK5BwEEEgXwEggoggiRUQQQDyFQAieIoiuImvb/j0hFif2PZ04Xt3/A/6lQ0/ OKH2/GLD75zpsfSEJIoIAiCC5yGCn45Go/UPf/hDuOfc9UnF5OHXf/3X/5Z9cf/5pV/6pb+lNxQR BEAEz0QELfET9z+OQQQ/+eSTD+yJ+x+/9mu/9gERRAQBEEFEkEAEEUFEEBBBAEQQESQQQUQQEQRE EAARRAQJRBARRAQBEQRABBFBAhFEBBFBQAQBEEFEkEAEEUFEEBBBAEQQESQQQQIRBEQQABFEBAlE kEAEAREEQAQRQQIRJBBBQAQBEEFEcP327dv148eP1w8ePLjCfn/9+vXeyv/w4cMV28bTp0+v6hh/ RwSPSwSfP3++fvTo0cfjyP7eZ7x582anY9yOnfg7IgiIIAAieNYi+PLly6uT9rNnz65OtIadwC0p vnr1ai/rMLHc5SRucuHL6++I4PGIoO0Xw44n2z/2RcKn7UsCdylLl9+1LEQQEQQARPBkRNAk8MWL FzemW49JdrJskrDs85K8ZT17TctnZb1//762l/AuehDPSQTti4MdRzFsv9h0k8Mu+yvbZ3XyZuXF ZeO0NiKYLdfl2EcEEUEARBDulQh6b2Ap9KToJ3sf+rMeRA/r8bO/fUhQT/72mSVYHSq03000fRja xVPLV3moE0Ed0o6fZetBBG/ny4QeDyWhs9916Lhuf/nntozNY3/7ceTHo85r81kPth6Dus/rRND/ zpaz8GM7OzYRQUQQABGkLe6tCPo1XW2F0U/aJoi2nIudDwH6dYCxh6h0wvdrB7330Ze3YUWbx69T LImgnbD1Wi/r2dTtietBBG9PBNtcU2r7Ju4vPU58f6nk+99R3vwYs/V6T16UNFvWpa5OBLPlfL3+ P+LHj0tpXc8hIogIAiCCcFIi6D1+GipdKoV6sqwTwfh3FAldZyaCfuKPJ2QtO64HEbw9EWxqZ5O1 rPdZ930sR4/PTAT17/glIK6zJIJZr7h/EckkMTveEUFEEAARhHspgrFHJoZLVnbiU9nbRgSbREJP 9JkIGj5UGPETd922IYL7FcHsOlOXseyYyKSqqwjqMVf6UuNllkTQb4zKjiP/spFxyLuOEUFEEAAR RARvJewkbckvG9bTnpJMBOs+34cI6vBcSQRtubohX0TwMCJovbelazD1jvRSj6CK+z5FUHuN60Sw rlfclt/X3fOIICIIgAgigkclgn4StxOhDrH6NYA+NJsNu+n1W21EUE+mUQjitX4mdyoIpWsE43p9 SM97oRDBw4igtbttb+wV9B5nP7Ziz6HvL/18WxH0YeA2y+vvLov6ZUivcdXrDPXYLPWAIoKIIAAi CPdKBF3E/K5IvzMy9vD4PCaH8flwTSKoy2aC5uLp8hmH3koi6HeJukjGu1cRwcM9R9B7iPXu2nh9 Xba/9PM6kfPea//SEkXQQo8dP+a8vLqbRbLl/ItLdmwe+hmEiCAiCIAIIoK3HnaitV4Oo/SMN3/Y dBxKtvnjEG0c6rW/9XqxUs+SlR/XHx9BkklIVu+7fPD0ub5izvdh6S5iEyvfX9mz/jTsmIr73ucp 3Qnux3H2iJe648jq4stldwT7dt3FMYUIIoIAiCAiSNyz4F3DBCKICAIggoAIIoKIIIEIIoIAiCAi iAgigogggQgiggCIICKICCKCiCCBCCKCAIggIogIIoKIIIEIIoIAiCAiiAgigogggQgiggCIICJI IIKIIIEIIoIAiCAiSCCCiCAiiAgiggCIICJIIIKIICIIiCAAIogIEoggIogIAiIIgAgiggQiiAgi goAIAiCCpyCCP+j3+z8bDodfnAIPHz5cn8q2dOXnf/7n/9cd/4N+8iu/8iundCz9383P/3GOx9Iv /MIv/O/N/vw2iRQRBEAET18Ev7JhdEKsT2x7uvDdI/gnPaX2/EuT2zM9lh6SRBFBAETwDESQxApQ PJbeMTwK5CsARBARJLECIghAvgJABBFBEisgggDkKwBEEBEksQIiCEC+AkAEEUESKyCCAOQrAEQQ ESSxAiIIQL4CQAQRQRIrIIIA5CsARBARJLECIghAvgJABBFBEisgggDkKwBEEBEksQIiCIggbQGA CCKCJFZABIF8BQCIICJIYj0Q6/X6exs+hZzf/u3f/uLP//zPf4e26MQT/rfIVwCIICJIYr0fIvjZ uoq3b9+unz9/fsX79+/XbcKW0Z9t5r3t+PDhwxX7itevX1+1yYsXL1q3S5d48+bN+lSi2sev+d8i XwEggoggifUeieDjx4/Xjx49uhKeZ8+erR88eLB++fJlo8DYMhb2s0lo2syzbbx69eqq7hYus/sI q7O1jZX39OnTq3axde0zrMxjC23PLkJbHQ+IIPkKABFEBO9HYt3E9zZ8Zj/PVQRNcIx4UjdBqesB OyYR3Kf8aU+gb5+HybGJ4anHNu2JCG6XTxBBAEQQETywCEqy/sLmrXhyriJowpcN2+qwr53gHesx rBNB+9x70rRn0Zf1clQ+vRfSeya9LJ9mP22alaVl23JWP/vd1+USE6XNpNZ737SckqB6uSaEpfDl tV28vbSOcZ3as6g9gnXtYO1l07TMTOB0ed+HWk9tk6zcrD29zvazxfFwziL4RHLKF22kEBEEQAQR wQOIYEH+1ucugj/96U//XdPQpJ387fq4+HcmgiYJKhomOzqPyp/NZ6LhPW9+XZ8t43Wyn7punc9+ +nzag6W/67b5sLetz6Z7OVnPXxQrFyYdLs/axeXT57N1eHtoD6ut09vC69i2HVRoM3H15W1+HdZW 2dQ6ZeXG9tRyWxwPiOBNilKICAIggojgLYlgC/lTfmvDqIHvFNb33RbLOl8plNF2+YeF5b/doYxv +3Ibefj9JhGMn9tJ38Uv6xE0YbDfbT7vbcqGhr2nKRuG9B7ArG7eM+i9Z3UiqPLmPZ/2mV8P6bQZ Bvf1qcDZNC/DtsU+8/Lsd+1NjL2YsX27tEPWLi66TUPyLoxZOaX21HJbHA+v5bj8+jbH5bb/XzU5 oW0dvltz4mmz/G+1yDXXpBARBEAEEcFbEMENv7fhZy2Schc+K6zvJx3KGCXLf6XD8n9WqMM/6VDG D3w5HxrOhkZ1mDBeJ1cSQZ/fhcjnLYmgClkbAdKbN7THrCSC3sumvX5RQJ14p7EJThwW1l5I+xnL 8J4yawcfBtdt8J5AH2bdtwhm1/XFdteev7YiqOW2OB5et+ghy/i0cGy/7lDGdwonjbbLvy7U4Tf3 nEs+5hREEAARRARvr0fQBOuTStSapPDJObaViaCLkYYPn5o0uEh5mMiY5GQiGHuPogiqUFg5Jk51 1/KpdOj6moYydT0uj94zqHXS4dsoglm7qJRZGXoHsa839gR622hZUSi9Xm3aoSSCcbt8WN6lPJtv GxFscTwwNFzPH1TzfZ0eQQBEEBG8RRFMet3qpPBsRTAOW8abPLznzSXHJSITQZ1Xy/J5/OYCLUev H/ReQh3OjWLkw7FetvW+mVDGodp4A0apZ1FveMiuj7Rlve5Zu/j2uDjb51l72e++Th9GjtvYph1K IhiX9xtStN28l1JvQsnKrWvPFscDInidn1V556P8NeUrAEAEEcE9i2ALKTxrEfThTL95I4YLTvws e6C0i5nLhv/0eayMbB1+XaFeqxeHrGM9dL0+NJ09UDq7K9rX1/Sga22XeB1hXbtkQ8veaxrr3bUd 6h7D49dQxrpaXeKzIevKrWvPhuMBEfxS/j4pXReMCAIggojgHYlgQQofnrsIEsSe4pxF8GEb+UME ARBBRPBIRPDcQQQJRJB8BYAIIoIkVkSQIBBB8hUAIogIkljPTAS/u2EEOb/xG7/xl3/8x3/8CW3R iYf8b5GvABBBRJDECqdwLL0rPUgcgHwFgAgigiRWQAQByFcAiCAiSGIFRBCAfAWACCKCJFZABAHI VwCIICJIYgVEEIB8BYAIIoIkVkAEAchXAIggIkhiBUQQgHwFgAgigiRWQAQBEQQARBARJLECIgjk KwBABBFBEisggkC+AgBEEBEksQIiCOQrAEAEEUESKyCCQL4CQAQRQUSQxAqIIJCvABBBQARJrIAI AvkKABEERJDECoggkK8AEEFABDkAABEE8hUAIogIklgBEEEgXwEggoggiRUAEQTyFQAiiAiSWOH8 WK/XozVBEPchnpCzABFEBO9EBDfxkIPndEXw9evX6+fPn68/fPhw48xj0+3zLvHixYursgz7fduw db99+7b4udWra90ssu08dJTq7vvBsN8zmuLp06cHr7e267b7RcvJtnuXMm/z+LBj/EB1RQRP+zz9 cIdlEUFEcP8iuInvbfhswxcbXnPwnK4I2onrwYMHN6TNTmZ27LSRD41Hjx6t37x5cyVx20rJy5cv 148fP76iThS71s1P2ncdpbrbfrC2M+z3riJo7W3LHbre2q7b7BcN23Y/hpxnz55dHYu3LYPbHB9W V6ufb7f9bvvg1atXncqxY922FRE8WxF8XZ1v7bz7PUQQEbwTEQzytxYQwRMXQRMIO6FFqbCTk54Y 379//1HyNHy6/fSTuIXO5/M0nOw+nlztRGonVFuuTkpsHb7urE5aBztJG9bro/Wwv3W++HtWvktL 3B6bv9ROXUQw7o+68HZvI4Jefra9pf3j85fqre3q8+gxEdun1J4qgpnk6rqzckrbke0Ln0eX1+2o 28fxWI2fWxm6DaU29+PQftr89gUoHn/yNyJ4+iKo593WUogIIoI7iWCN/CGCZySChp2I9KRof+uJ 305SPs0E0Xv7XNi8jExmdFmXlZII2HSXmXjyjzLl8uO9MH4CzepqJ1vvZbSeJRWmKMJeP5VhPVH7 ttl6dVnvyfPPvF1uWwRt27y3rE4Evb18e6yOPt0/U5n0feHbmW1PbFcv2/72NvC6ldqzSQRdlLzX ulSObofXSY8PX97r573htnzcDm0vF7tM7Esi6L3ZTW3u2+XtbPWI/x82z5/8yZ98n5x1ViLYWgoR QUSwswi2lD/l8w0jOD1+93d/9/s6pOUnSjsx6nCXC4H2lLh42UlKh+wymYnX+2UnTz2JumRGYYsy pUPHPpxcV1cVMJvXBcI+9/X4NrlMZoLqPZYqktZ2LoJ6vVwmdG1E0P73vF5Om2HLUntZnVxConCp oOj+iSJeEnPdHhee+Flde0YRdJl27G8/Jpr2i25H9uXAj5Nsed0OF8B4fGUiqP8rLsy277dpcz2e /Biy9f7RH/3Rb5GzTprPW56Pb0ghIogIthLBLeQPzoDRaHRtiNVPUnbiUXEqnZy9JyPrIYk9Ozav 96zYul00tBfHT94uHNpj0yRTXse6usYeTluPbaf3HHmPls8by7F62/xZ+X6NVxwS3FYESz2Cvp+c 2EtV1yPo22d19eUzMfe/4/RSvaMI6jx6fWOpPbMeQW8H793T8krlxPpqW3i52TZ4u+tnWr7u5yYR tGNHe/O6tnn8AmHbb8fqkydPyFlQksJ/jAgigogg7CyCfjJSIVQRjBfw+/VVbUTQRS9eR6hyZr97 D6DKQxSBNiJYqmtcxoflDO8F9SFyX3csx8XB6ho/6yKC2Tb5kGCdCMa7auNdriUR9CF8285s/xxC BEvt2TQ0rJci1JWzbxH0Xt66+tb1bm/T5lon7RFHBAERRAQZGoa9o0PDPiyrQ1b6mZ8s9Zot+9tO 0j6M5dc3xZOeDpfqPDG0rDh0F68pzIYgtVcxq2smgj586OvxMv0k7PV20czq6T2YbUXQexW1Daw8 vdawyzWCbUTQh/+z9itJibapb/e2IljXnk0i6PvGxKqunDYiGIfrVbbidui22/4pDQ2XRHCbNo9f FrwODA0zNNxjaBgR5GYRuM2bRVRQfLguDqW6KPmF7dlQpYqgnzh1CNhPbqWh0ewmEr/xIOtV03I9 SnX1HhqfNw5tx+u2/CYDL0fv6tRt9vJ0m7O/Y/31+j8VAZebjG1FMA5p+7Z5+6qE6N/axt6jVur5 clHMRLCuPaMIlnqAXaJK5cTtiCLo5foXHseXicdH3PbsZpG6x750afN4Q4vLr1x/+4Scxc0i3CyC CO5dBFtKISJ4wiLYtcep9EiUuoc/a8/ObUSp3DZ12mWb97E9t9UmXbflkHW87f2y7+V33f5t2zz0 jCKC5yWCPD4GETy8CNZIISKICBIEcaDwywTCZRKI4OmLIA+URgSPRwTD8g85eBBBgiAOJ4LJ6xkR wdM+Tz/cYVlEEBG8XREERJAgiDsPRBAQQUQQEYQ7P5beWdKhLYB8BYAIIoIkVkAEAchXAIggIkhi BUQQgHwFgAgigiRWQAQByFcAiCAiSGIFRBCAfAWACCKCJFZABAHIVwCIICJIYgVEEIB8BYAIIoIk VkAEAchXAIggIkhiBUQQgHwFgAgigiRWQAQBEQQARBARJLECIgjkKwBABBFBEisggkC+AgBEEBEk sQIiCOQrAEAEEUESKyCCQL4CQARpC0SQxAqIIJCvABBBQARJrIAIAvkKABEERJDECoggkK8AEEFA BAEQQSBfASCCiCCJFQARbM96vX64YQS3zybWtANsyd9BBAERRAQBEbwNEXy9Jgji2OMsZQgRRAQR QbgXIriJ7234zfsqgk+fPl0/fvz4xpnn9evX60ePHq3fvn3b6YzlZVm5XZe1ZWydyqtXr2rX0yVK ZR06srq/ePHiavv999gOhn+ebZeV6bx///5W6l3ap9qu2+yXuA7dFttu+9n1WNomuh4fVqe4j7at a8O6760MbeIHGz7Z8BVEEBFEBOFkRLCSv882fGHH4X1NVuZ7dvJ68ODBlfjFE7Jt25s3bzqd0Kws l5kPHz50Wtbq8uzZs6t1GnZyzOqm69mmbncdWT2eP39+tf3+u7aDkwmGSZ+V5/vJ2n1XGavbP9nx oNuzaxvHddj2+ReEu9gvdWH19Po6tt+2LedERfB1lSN/tuEnXaQQEUQEEUE4KhFM5E+51yJoJ6/Y 2+Q9HH5SthOyCYoRxczkw6eXRNDnMUo9VrY++7xpmp+0rW5eZpSjWFdbvy1j00wwdRtsmtfVlrV5 227zy5cvr00zWSst00UEs23OwtYR911JRKyusW623VZvaxOb7tsel7GfmQhqu/q6tQ10X9e1Z51s Wh11m2zZWH5pO/TYzNrBl4/bofPFNmkSOBXzujb3urk82t82vwq/zTubzf76BERQaSWFiCAiiAjC nYtgg/ydjAiqwPnJy05OflL2ITCb7kPGPpRlvU8mIn5S9HL0hO4y5+JWEpXYI+jykYmjlWHr9jL9 hFyqq83nJ2gdhrX5bR+60PmJuW6bdXusHJtf5dmWMWx9pbpv0yPYJnxYOYbLvrerC5u3i3/m+1Pr 5NuZ9RBru+p+cVlr2i9tRFB7BP2YsDK0jXU7vCfZ6qH7QrfJlnf503bwdVs53ia6HU0i6OVYndq0 uUq2fRZ7dO3zyWTy309MBFtJISKICCKCcCci2EH+YjJ7fd/YnJC+8BOvn7xd7vzE7Z9pT4mdaP3E pVKjPTd6Qtdes9i7EyXAPnOh8t+zIdEoWX5yL9VVBcyHU/1Eq/Lj6yuVE0/UcZu196jNUGpJBLUd nKZrz6LMxJ5D7aHVIU2tj8pN1sZthoa1nv5Z3X7JjgHF9o3XI26fyZZLudbDpmlPqdc9bpP2hvvy 8bgubbuXp/vI/vYvBtu0eWxPm/7555//z/uYXyq65tGPUogIIoKIIBzyWPovG/5Fx6R17/GeGe+x UBnSE1d2cvYTcjyZZyLoJ309WfrJMJYVh0Rd1Jpkypct1TU7wbrwufTaSVu3PSvHJa3UFioLu4hg aWjY6uvr1HbxHqdSz6Fva9wHcR9GEWySoUwES8dDab+U1uH7Q4UuK8N7hnU7YhuqCGpkXxRsPvv/ yPZ91iNY6rXdps19H2vP6bt3784mJwUp/DeWmzlHIYKIIBysR3DDaMPvbfjLLZLWve4R9BOhDwtH EdRePT95tRFB713Ra7T0hKsn0EwE/WTYRgR9iC2ra1zGRUHFz4dktbxYTuxp0vK7iGCcbuv1ddeJ oA8t6s0jOrRYCr8GLeudOpQIlvZL3Tq899aHkWOPnv3ubbKNCOoXDT0u43w2Ld781HSTxzZtrse8 HWfWZpttvJf5ZYsewXU1/2fVyAw9goggIgiHHxqWaV2k8F5fI+gnXu9tcqHQ3kK9Vs+vn4oneL/m KhsG85OozpNJgF4b5yfE0s0iXge9xrGuripgLqj+mV+w78JaKsfFRG9CiT2oTeLk17zptZBaZpe7 hn3b7Wfd9YS67XGZkpRo2/kyTWWXRLBuvzTJpl5XqstZWX78tRXBbHmVTJV6lzjf9ni9ZxsR7NLm un/1etv1adw13Er+wrKIICKICMLdiWBHKby3IqjPhvPn0amw+GfeexaH6nz4y6Uqe46g33jiJ9fS 8+iy5wiW7tj0a86yZ7eV6ur18HltOZcAv74wG66N5fhwog9Lenlxu+qepajD2PHGiS7PEdQ66rPs YriIuWz7XatWv7g/9W/73beztD3arnHd8caHpmciltZh5fixoMeJy16st29fVq4ur+2u26HHdenG lrjObdvct0/bKtzJf4oimMofIogIIoJwlCLYQgrvrQiuCYI4utCbt05IBBvlDxFEBBFBOHoRLEjh TxFBgiB2DX1bicR9FsE/6CJ/iCAiiAjCvRLB+w4iSBDHF8l1mLxrGBBBRBAQwVsRwScbPoXbZxNr 2gG25PuIICCCiCAggkC+AkAEAREksQIiCOQrAEQQEEESKyCCQL4CQARpLxIrACII5CsARBARJLEC IIJAvgJABBFBEisAIgjkKwBEEBEksQIggkC+AkAEEUESKwAiCOQrAEQQESSxAiCCQL4CQAQRQRIr IIK0BZCvABBBRJDECoggAPkKABFEBEmsgAgCkK8AEEFEkMQKiCAA+QoAEUQESayACAKQrwAQQUSQ xAqIIAD5CgARRARJrIAIApCvABBBRJDECoggAPkKABFEBEmsgAgCkK8AEEFEkMQKiCAgggCACCKC JFZABIF8BQCIICJIYgVEEMhXAIAIIoIkVkAEgXwFAIggIkhiBUQQyFcAiCBtgQiSWAERBPIVACII iCCJFRBBIF8BIIKACJJYAREE8hUAIgiIIAAiCOQrAEQQESSxAiCCQL4CQAQRQRIrACII5CsARBAR JLECIIJAvgJABBFBEisAIgjkKwBEEBEksQIggkC+AkAEEUESK5BwEEEgXwEggoggiRUQQQDyFQAi iAiSWAERBCBfASCCiCCJFRBBAPIVACKICJJYAREEIF8BIIKIIIkVEEEA8hUAIogIklgBEQQgXwEg goggiRUQQQDyFQAiiAiSWAERBCBfASCCiOBtnbzZ+bCnY+mnG75NWwD5CuBo/me+bbmZtkAEAQAA AAARBAAAAABEEAAAAAAQQQAAAABEEAAAAADOjv8HbnVplxWKO6EAAAAASUVORK5CYII= --Boundary_(ID_DnaYF0n0HN1W1ufleB91lQ)-- From Sebastian.Schumann@st.sk Thu Oct 28 01:51:48 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 346873A689B for ; Thu, 28 Oct 2010 01:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.244 X-Spam-Level: X-Spam-Status: No, score=-0.244 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ixfo7sWT1np for ; Thu, 28 Oct 2010 01:51:46 -0700 (PDT) Received: from mail1.st.sk (mail1.st.sk [195.146.138.74]) by core3.amsl.com (Postfix) with ESMTP id 73B9E3A6893 for ; Thu, 28 Oct 2010 01:51:44 -0700 (PDT) X-TM-IMSS-Message-ID: <2922b13d00000f06@st.sk> Received: from EXCHANGE1.st.sk ([fe80::5d7a:6a65:c8ef:4439]) by EXCHANGEKE1.st.sk ([fe80::c173:5b2:d585:d82a%10]) with mapi; Thu, 28 Oct 2010 10:53:32 +0200 From: Schumann Sebastian To: 'Emil Ivov' Date: Thu, 28 Oct 2010 10:53:31 +0200 Thread-Topic: [dispatch] proposed SIXPAC charter Thread-Index: Act1+4l//Qlp8PpARe2FIPL8SOiG7gAfsFcw Message-ID: <73B99B53AF1D5B4DA6E2BF049DF19C7501A21A3B7C@EXCHANGE1.st.sk> References: <4CBDFCB8.302@stpeter.im> <73B99B53AF1D5B4DA6E2BF049DF19C7501A21A3B60@EXCHANGE1.st.sk> <4CC85FCF.50009@sip-communicator.org> In-Reply-To: <4CC85FCF.50009@sip-communicator.org> Accept-Language: en-US, sk-SK Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, sk-SK Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] proposed SIXPAC charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 08:51:48 -0000 RGVhciBFbWlsDQoNClRoZSBjaGFydGVyIG1lbnRpb25zICJkdWFsLXN0YWNrIGNsaWVudHMiIGFu ZCB0aGF0IHNlcnZlciBpbnRlZ3JhdGlvbiBpcyBvdXQgb2Ygc2NvcGUuDQoNCldoYXQgeW91IHN0 YXRlZCBpcyBiYXNpY2FsbHkgd2hhdCBJIG1lYW50LiBIb3dldmVyLCBub3QgaW4gcmVnYXJkIHRv IGR1YWwtc3RhY2sgY2xpZW50cyBidXQgc2VwYXJhdGUgY2xpZW50cyBpbiBib3RoIG5ldHdvcmtz LiBUaGF0IGlzLCB1c2luZyBlLmcuLCBhIFNJUCBoYXJkIHBob25lIGFuZCBhbiBYTVBQIGNvbW11 bmljYXRvciAic2VwYXJhdGVseSIgd2hpbGUgc3RpbGwgaGF2aW5nIHRoZSBjaGFuY2UgdG8gbWVy Z2UgdGhlIFNJUCBiYXNlZCBzdGF0ZXMgaW4gWE1QUC4NCg0KSSB0aGluayB0aGF0IHRoaXMgc2Vl bXMgb25seSBwb3NzaWJsZSBpbnZvbHZpbmcgaW5mcmFzdHJ1Y3R1cmUgKHdoaWNoIGlzIGluaXRp YWxseSBleGNsdWRlZCkuIE9uZSBwb3NzaWJpbGl0eSBpcywgZS5nLiwgZ2VuZXJhdGluZyBhbmQg aW50ZXJwcmV0aW5nIFNJUCBTSU1QTEUgZGlhbG9naW5mbyBpbmZvcm1hdGlvbiB3L28gY2xpZW50 IGludm9sdmVtZW50LiBUaGlzIGlzIGNvbXBsZXggYW5kIHNob3VsZCBiZSBpbmRlZWQgZXhjbHVk ZWQgSSBhZ3JlZSBoZXJlLiBCdXQgaW4gdGhlIGVuZCB0aGlzIG1pZ2h0IHJlLXVzZSBleGFjdGx5 IHRob3NlIGRlZmluaXRpb25zIGluIFhNUFAgdG8gZGlzcGxheSBhIFNJUCBwaG9uZSBjYWxsIHRo YXQgYXJlIGJlaW5nIGRlZmluZWQgYnkgdGhlIGNoYXJ0ZXIuIFRoZSBpbnRlcmFjdGlvbiBpcyBo b3dldmVyIGRpZmZlcmVudCBmcm9tIHRoZSB5b3VyIHByb3Bvc2FsLg0KDQpBbm90aGVyIG1vcmUg cmVsYXRlZCBvcHRpb24gY291bGQgYmUgdGhlIFNJUCBoYXJkIHBob25lIGFkZGluZyBwb3RlbnRp YWwgYWRkaXRpb25hbCBoZWFkZXJzICh0aGF0IGFyZSBpbiBzY29wZSB0byBiZSBkZWZpbmVkIGlu IHRoZSBjaGFydGVyKSwgZXh0cmFjdGluZyB0aGVtIG9uIGEgU0lQIHByb3h5IGFuZCB1c2luZyBh IGhpZGRlbiBYTVBQIGNsaWVudCBpbnN0YW5jZSBvbiBzZXJ2ZXIgc2lkZSB0byAiYWRkIiB0aGlz IHN0YXRlIGluZm9ybWF0aW9uIGFzIGEgbmV3IHJlc291cmNlIChlLmcuLCBTSVAtUGhvbmUpLiAN CkluIHByaW5jaXBsZSwgSSBzZWUgdGhpcyBzaW1pbGFyICh0byBhIGNlcnRhaW4gZXh0ZW5kKSB0 byB3aGF0IHRoZSBjaGFydGVyIHN1Z2dlc3RzIGFscmVhZHkuIEFsbCBpbmZvcm1hdGlvbiB0aGF0 IGJvdGggc3RhY2tzIGluIHRoZSBjbGllbnRzIGV4Y2hhbmdlIChjb3JyZWxhdGVkIHN0YXRlcywg aWRlbnRpdGllcyBpbiB0aGUgcmVzcGVjdGl2ZSBvdGhlciBzdGFjaykgc2hvdWxkIGJlIGFueXdh eXMgY2FycmllZCBpbiBhbiBleHRlbnNpb24gb2YgZWFjaCBwcm90b2NvbCBhcyBJIHVuZGVyc3Rv b2QuIE9ubHkgdGhlICJoaWRkZW4gaW50ZXJhY3Rpb24iIG9mIHRoZSBkdWFsIHN0YWNrIGNsaWVu dCBiZXR3ZWVuIFNJUCBhbmQgWE1QUCB3b3VsZCBiZSBkZWZpbmVkIGFzIHdlbGwgc28gdGhpcyAi ZnVuY3Rpb25hbGl0eSIgY2FuIGFsc28gYmUgaW1wbGVtZW50ZWQgb3V0IG9mIHRoZSBjbGllbnRz IGFzIHNlcGFyYXRlIG5ldHdvcmsgZW50aXR5LiBUaGlzIHdvdWxkIGJlIHRoZSBvbmx5IGV4dGVu c2lvbiBJIHNlZSB3b3J0aCBjb25zaWRlcmluZy4NCg0KQmVzdCByZWdhcmRzDQpTZWJhc3RpYW4g DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRW1pbCBJdm92IFttYWls dG86ZW1jaG9Ac2lwLWNvbW11bmljYXRvci5vcmddDQo+IFNlbnQ6IFdlZG5lc2RheSwgMjcuIE9j dG9iZXIgMjAxMCAxOToyMg0KPiBUbzogU2NodW1hbm4gU2ViYXN0aWFuDQo+IENjOiBQZXRlciBT YWludC1BbmRyZTsgZGlzcGF0Y2hAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtkaXNwYXRjaF0g cHJvcG9zZWQgU0lYUEFDIGNoYXJ0ZXINCj4gDQo+IEhleSBTZWJhc3RpYW4sDQo+IA0KPiDQndCw IDI3LjEwLjEwIDEwOjAwLCBTY2h1bWFubiBTZWJhc3RpYW4g0L3QsNC/0LjRgdCwOg0KPiA+IERl YXIgYWxsLCBQZXRlciwgSSB0aGluayB0aGlzIGluaXRpYXRpdmUgaXMgdG91Y2hpbmcgc29tZSB2 ZXJ5IGFjdHVhbA0KPiA+IHByb2JsZW0sIEkgc2Vjb25kIGl0IGFzIHdlbGwuDQo+ID4NCj4gPiBP bmUgcXVlc3Rpb246IFdvdWxkIHlvdSB0aGluayB0aGF0IHRoaXMgaW50ZXJhY3Rpb24gYmV0d2Vl biBTSVAgYW5kDQo+ID4gWE1QUCB3b3VsZCBhbHNvIGJlIHRhcmdldGVkIG5vdCBvbmx5IGJ5IGR1 YWwtc3RhY2sgY2xpZW50cyBidXQgYWxzbw0KPiA+IG9uIHRoZSBuZXR3b3JrIHNpZGU/IFRoYXQg aXMsIGhhdmluZyBhIFNJUCBiYXNlZCB0ZWxlcGhvbnkNCj4gPiBpbmZyYXN0cnVjdHVyZSAody9v IFNJUCBwcmVzZW5jZSkgd2l0aCBjZXJ0YWluIHVzZXJzIGFuZCBhIFhNUFAgYmFzZWQNCj4gPiBJ TS9QIG5ldHdvcmsgICh3L28gSmluZ2xlKSB3aXRoIHRoZSBzYW1lIHVzZXJzPyBIYXZpbmcgYSBt ZWNoYW5pc20gb2YNCj4gPiBtYXBwaW5nIHRoZSB1c2VycyBpbiBib3RoIG5ldHdvcmtzLCBYTVBQ IHByZXNlbmNlIGNvdWxkIGJlIGVuaGFuY2VkDQo+ID4gd2l0aCBTSVAgYmFzZWQgdGVsZXBob255 IHN0YXRlcy4gV291bGQgeW91IHNlZSB0aGlzIGluIHNjb3BlIG9yDQo+ID4gcmF0aGVyIG91dCBv ZiBzY29wZSBvZiB5b3VyIHByb3Bvc2FsPw0KPiANCj4gQXMgaXQgaXMgdGhlIGNoYXJ0ZXIgc3Rh dGVzOg0KPiANCj4gPiAtIEluY2x1ZGluZyBTSVAtYmFzZWQgYXZhaWxhYmlsaXR5IHN0YXRlcyBp biBYTVBQIHByZXNlbmNlIChsaW1pdGVkDQo+ID4gdG8gYmFzaWMgcHJlc2VuY2UgYW5kIGF2YWls YWJpbGl0eSBzdGF0ZXMgb25seSwgbm90IHRoZSBmdWxsIHJhbmdlDQo+ID4gb2YgUElERiBleHRl bnNpb25zKQ0KPiANCj4gSXMgdGhpcyB3aGF0IHlvdSBtZWFuIG9yIGRpZCBJIG1pc3Mgc29tZXRo aW5nPw0KPiANCj4gQ2hlZXJzLA0KPiBFbWlsDQo+IA0KPiANCj4gPg0KPiA+IFRoYW5rcy4gU2Vi YXN0aWFuDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbTogZGlzcGF0 Y2gtYm91bmNlc0BpZXRmLm9yZw0KPiA+PiBbbWFpbHRvOmRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBQZXRlciBTYWludC1BbmRyZQ0KPiA+PiBTZW50OiAxOSBPY3RvYmVy IDIwMTAgMjE6MTcgVG86IGRpc3BhdGNoQGlldGYub3JnIFN1YmplY3Q6DQo+ID4+IFtkaXNwYXRj aF0gcHJvcG9zZWQgU0lYUEFDIGNoYXJ0ZXINCj4gPj4NCj4gPj4gRWFybGllciB0aGlzIHllYXIs IHNvbWUgZm9sa3MgaW4gdGhlIFJBSSBhcmVhIHByb3Bvc2VkIGFuDQo+ID4+IGluaXRpYXRpdmUg dG8gZGVmaW5lIGEgZmV3IHNtYWxsIGV4dGVuc2lvbnMgdG8gYm90aCBTSVAgYW5kIFhNUFANCj4g Pj4gdGhhdCB3b3VsZCBtYWtlIGl0IGVhc2llciB0byBkZXZlbG9wIGFuZCBkZXBsb3kgZHVhbC1z dGFjayBTSVArWE1QUA0KPiA+PiBlbmRwb2ludHMuIEJhc2VkIG9uIGZlZWRiYWNrIHByb3ZpZGVk IG9uIHRoZSBESVNQQVRDSCBsaXN0IGFuZA0KPiA+PiByZWNlaXZlZCBmcm9tIHRoZSBSQUkgQURz LCBJJ3ZlIHRha2VuIHRoZSBsaWJlcnR5IG9mIHJld3JpdGluZyB0aGUNCj4gPj4gcHJvcG9zZWQg Y2hhcnRlciwgaW4gdGhlIGhvcGVzIHRoYXQgZnJlc2ggdGV4dCB3aWxsIHNwdXIgYSBtb3JlDQo+ ID4+IGNvbmNsdXNpdmUgZGlzY3Vzc2lvbi4gSSdtIG1vc3RseSBqdXN0IHRyeWluZyB0byBoZWxw IHRoZQ0KPiA+PiBwcm9wb25lbnRzIHB1dCB0aGVpciBiZXN0IGZvb3QgZm9yd2FyZCwgc28gaWYg Zm9sa3MgaGVyZSBoYXZlIG1vcmUNCj4gPj4gZmVlZGJhY2sgSSdkIGV4cGVjdCB0aGF0IHBlb3Bs ZSBsaWtlIFNpbW8gVmVpa2tvbGFpbmVuIGFuZCBFbWlsDQo+ID4+IEl2b3Ygd2lsbCBiZSBhYmxl IHRvIGVuZ2FnZSBpbiBmdXJ0aGVyIGRpc2N1c3Npb24uDQo+ID4+DQo+ID4+IC9wc2ENCj4gPj4N Cj4gPj4gIyMjDQo+ID4+DQo+ID4+IFNJWFBBQyAoU0lQIEludGVncmF0aW9uIHdpdGggWE1QUCBp biBQcmVzZW5jZSBBd2FyZSBDbGllbnRzKQ0KPiA+Pg0KPiA+Pg0KPiA9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+ID4+DQo+ID4+ IFByb2JsZW0gU3RhdGVtZW50DQo+ID4+DQo+ID4+IEJvdGggdGhlIFNlc3Npb24gSW5pdGlhdGlv biBQcm90b2NvbCAoU0lQKSBhbmQgdGhlIEV4dGVuc2libGUNCj4gPj4gTWVzc2FnaW5nIGFuZCBQ cmVzZW5jZSBQcm90b2NvbCAoWE1QUCkgYXJlIHdpZGVseSBkZXBsb3llZA0KPiA+PiB0ZWNobm9s b2dpZXMgZm9yIHJlYWwtdGltZSBjb21tdW5pY2F0aW9uIG92ZXIgdGhlIEludGVybmV0LiAgSW4N Cj4gPj4gb3JkZXIgdG8gb2ZmZXIgYSBjb21wbGV0ZSBzdWl0ZSBvZiBmZWF0dXJlcyBhcyB3ZWxs IGFzDQo+ID4+IGNvbW11bmljYXRpb24gYWNyb3NzIG11bHRpcGxlIG5ldHdvcmtzLCBzZXZlcmFs IHVzZXItb3JpZW50ZWQNCj4gPj4gc29mdHdhcmUgYXBwbGljYXRpb25zIHN1cHBvcnQgYm90aCBT SVAgYW5kIFhNUFAsIGFuZCBtb3JlIHNvZnR3YXJlDQo+ID4+IGRldmVsb3BlcnMgaGF2ZSBleHBy ZXNzZWQgaW50ZXJlc3QgaW4gYnVpbGRpbmcgc3VjaCAiZHVhbC1zdGFjayINCj4gPj4gc29sdXRp b25zLiAgVW5mb3J0dW5hdGVseSwgaXQgaXMgZGlmZmljdWx0IHRvIHByb3ZpZGUgYSBnb29kDQo+ ID4+IGVuZC11c2VyIGV4cGVyaWVuY2UgaW4gc3VjaCBhcHBsaWNhdGlvbnMgYmVjYXVzZSBTSVAg YW5kIFhNUFAgYXJlDQo+ID4+IG5vdCBhd2FyZSBvZiBlYWNoIG90aGVyLiAgRm9yIGV4YW1wbGU6 DQo+ID4+DQo+ID4+IC0gWE1QUCBwcmVzZW5jZSBkb2VzIG5vdCBpbmNsdWRlIGF2YWlsYWJpbGl0 eSBzdGF0ZXMgcmVsYXRlZCB0byBhDQo+ID4+IFNJUCB2b2ljZSBjYWxsIG9yIHZpZGVvIGNhbGwg KGUuZy4sICJvbiB0aGUgcGhvbmUiKSwgdGh1cw0KPiA+PiBwcmV2ZW50aW5nIGFuIGEgZHVhbC1z dGFjayBlbmRwb2ludCBmcm9tIHNob3dpbmcgcHJlc2VuY2UtYmFzZWQNCj4gPj4gY29tbXVuaWNh dGlvbiBoaW50cw0KPiA+Pg0KPiA+PiAtIFRoZXJlIGlzIG5vIGNvcnJlbGF0aW9uIGJldHdlZW4g YW4gWE1QUCBJTSBzZXNzaW9uIGFuZCBhIFNJUA0KPiA+PiB2b2ljZSBvciB2aWRlbyBzZXNzaW9u LCB0aHVzIHByZXZlbnRpbmcgYSBkdWFsLXN0YWNrIGVuZHBvaW50IGZyb20NCj4gPj4gcHJvdmlk aW5nIGludGVncmF0ZWQgdXNlciBpbnRlcmZhY2VzIGFuZCBjb21tdW5pY2F0aW9ucyBoaXN0b3J5 DQo+ID4+DQo+ID4+IC0gU0lQIGFjY291bnRzIGFuZCBYTVBQIGFjY291bnRzIGFyZSBub3QgZGly ZWN0bHkgY29ycmVsYXRlZCBpbg0KPiA+PiBjb250YWN0IGxpc3RzIG9yIHZDYXJkcyAoYW5kIG5v dCBhbGwgZGVwbG95ZWQgc2VydmljZXMgc3VwcG9ydA0KPiA+PiBzdG9yYWdlIG9mIHN1Y2ggaW5m b3JtYXRpb24pLCB0aHVzIHByZXZlbnRpbmcgYSBkdWFsLXN0YWNrIGVuZHBvaW50DQo+ID4+IGZy b20ga25vd2luZyB0aGF0IGEgY29udGFjdCBoYXMgYm90aCBTSVAgYW5kIFhNUFAgY2FwYWJpbGl0 aWVzDQo+ID4+DQo+ID4+IEFsdGhvdWdoIHNvbWUgcHJvcHJpZXRhcnkgc29sdXRpb25zIGV4aXN0 IHRvIHRoZSBmb3JlZ29pbmcNCj4gPj4gcHJvYmxlbXMsIGl0IHdvdWxkIGJlIHByZWZlcmFibGUg dG8gZGVmaW5lIHN0YW5kYXJkaXplZCBzb2x1dGlvbnMNCj4gPj4gZm9yIHRoZSBzYWtlIG9mIGlt cHJvdmVkIGludGVyb3BlcmFiaWxpdHkuDQo+ID4+DQo+ID4+IE9iamVjdGl2ZXMNCj4gPj4NCj4g Pj4gQmVjYXVzZSBib3RoIFNJUCBhbmQgWE1QUCBhcmUgZWFzaWx5IGV4dGVuZGVkIHRocm91Z2gg bmV3IFNJUA0KPiA+PiBoZWFkZXJzIGFuZCBYTVBQIGVsZW1lbnRzLCBpdCBzaG91bGQgYmUgcG9z c2libGUgdG8gcHJvdmlkZQ0KPiA+PiB0aWdodGVyIGludGVncmF0aW9uIHdpdGhpbiBkdWFsLXN0 YWNrIFNJUC9YTVBQIHVzZXIgYWdlbnRzIHRvDQo+ID4+IGltcHJvdmUgdGhlIHVzZXIgZXhwZXJp ZW5jZS4NCj4gPj4NCj4gPj4gQW55IHN1Y2ggZXh0ZW5zaW9ucyBzaG91bGQgbWVldCB0aGUgZm9s bG93aW5nIGNyaXRlcmlhOg0KPiA+Pg0KPiA+PiAtIEJlIGNvbXBsZXRlbHkgb3B0aW9uYWwgYW5k IGJhY2t3YXJkcy1jb21wYXRpYmxlIGZvciBhbGwNCj4gPj4gZW5kcG9pbnRzDQo+ID4+DQo+ID4+ IC0gV29yayB3aXRob3V0IGNoYW5nZXMgdG8gZGVwbG95ZWQgaW5mcmFzdHJ1Y3R1cmUgc3VjaCBh cyBleGlzdGluZw0KPiA+PiBTSVAgYW5kIFhNUFAgc2VydmVycywgQjJCVUFzLCBmaXJld2FsbHMs IGV0Yy4NCj4gPj4NCj4gPj4gVGhlIFNJWFBBQyBXRyB3aWxsIGRlZmluZSBhIHNtYWxsIG51bWJl ciBvZiBTSVAgYW5kIFhNUFAgZXh0ZW5zaW9ucw0KPiA+PiB0byBzb2x2ZSB0aGUgZm9sbG93aW5n IHVzZSBjYXNlcyBpbiBkdWFsLXN0YWNrIGVuZHBvaW50czoNCj4gPj4NCj4gPj4gLSBJbmNsdWRp bmcgU0lQLWJhc2VkIGF2YWlsYWJpbGl0eSBzdGF0ZXMgaW4gWE1QUCBwcmVzZW5jZSAobGltaXRl ZA0KPiA+PiB0byBiYXNpYyBwcmVzZW5jZSBhbmQgYXZhaWxhYmlsaXR5IHN0YXRlcyBvbmx5LCBu b3QgdGhlIGZ1bGwgcmFuZ2UNCj4gPj4gb2YgUElERiBleHRlbnNpb25zKQ0KPiA+Pg0KPiA+PiAt IENvcnJlbGF0aW5nIGFuIFhNUFAgSU0gc2Vzc2lvbiB3aXRoIGEgU0lQIHZvaWNlL3ZpZGVvIHNl c3Npb24sDQo+ID4+IGFuZCB2aWNlLXZlcnNhDQo+ID4+DQo+ID4+IC0gQWR2ZXJ0aXNpbmcgYSBT SVAgYWNjb3VudCBhZGRyZXNzIG92ZXIgWE1QUCBhbmQgYW4gWE1QUCBhY2NvdW50DQo+ID4+IGFk ZHJlc3Mgb3ZlciBTSVANCj4gPj4NCj4gPj4gQWRkaXRpb25hbCB1c2UgY2FzZXMgYXJlIG91dCBv ZiBzY29wZSwgaW5jbHVkaW5nIGFueXRoaW5nIHJlbGF0ZWQNCj4gPj4gdG8gb3IgcmVxdWlyaW5n IHNlcnZlciBpbnRlZ3JhdGlvbiwgbXVsdGlwYXJ0eSBjb21tdW5pY2F0aW9uLA0KPiA+PiBTSVAt YmFzZWQgSU0gYW5kIHByZXNlbmNlLCBYTVBQLWJhc2VkIHZvaWNlIGFuZCB2aWRlbywgZmlsZQ0K PiA+PiB0cmFuc2ZlciwgZ2VuZXJhbGl6ZWQgc2VydmljZSBkaXNjb3ZlcnkgYW5kIGNhcGFiaWxp dGllcyBleGNoYW5nZSwNCj4gPj4gZnVsbCBwcm90b2NvbCB0cmFuc2xhdGlvbiBpbiBjb21tdW5p Y2F0aW9uIGdhdGV3YXlzLCBzaGFyZWQNCj4gPj4gY3JlZGVudGlhbHMgYWNyb3NzIGJvdGggU0lQ IGFuZCBYTVBQIGFjY291bnRzLCByaWNoIHByZXNlbmNlDQo+ID4+IGV4dGVuc2lvbnMgZm9yIGZl YXR1cmVzIHN1Y2ggYXMgZ2VvbG9jYXRpb24sIGV0Yy4gIEFsdGhvdWdoIHN1Y2gNCj4gPj4gdG9w aWNzIGFyZSBpbXBvcnRhbnQgYW5kIGludGVyZXN0aW5nLCB0aGV5IGFyZSBvdXQgb2Ygc2NvcGUg Zm9yDQo+ID4+IHRoaXMgZ3JvdXAuDQo+ID4+DQo+ID4+IEhvd2V2ZXIsIGluIGFkZGl0aW9uIHRv IHRoZSBwcm90b2NvbCBleHRlbnNpb25zIGV4cGxpY2l0bHkNCj4gPj4gbWVudGlvbmVkIGFib3Zl LCB0aGUgZ3JvdXAgbWF5IGFsc28gZGVmaW5lIGJlc3QgcHJhY3RpY2VzIHJlbGF0ZWQNCj4gPj4g dG8gdGhlIGltcGxlbWVudGF0aW9uIGFuZCBkZXBsb3ltZW50IG9mIGR1YWwtc3RhY2sgU0lQL1hN UFANCj4gPj4gZW5kcG9pbnRzLCBpbmNsdWRpbmcgdG9waWNzIHN1Y2ggYXMgdXNlciBhZ2VudCBj b25maWd1cmF0aW9uLg0KPiA+Pg0KPiA+PiBEZWxpdmVyYWJsZXMNCj4gPj4NCj4gPj4gLSBVc2Ug Y2FzZXMgYW5kIHByb3RvY29sIHJlcXVpcmVtZW50cw0KPiA+Pg0KPiA+PiAtIFhNUFAgcHJlc2Vu Y2UgZXh0ZW5zaW9uIGZvciBTSVAtYmFzZWQgYXZhaWxhYmlsaXR5IHN0YXRlcw0KPiA+Pg0KPiA+ PiAtIE1lZGlhIHNlc3Npb24gY29ycmVsYXRpb24gZXh0ZW5zaW9ucyBmb3IgU0lQIGFuZCBYTVBQ DQo+ID4+DQo+ID4+IC0gQ29udGFjdCBhZGRyZXNzIGFkdmVydGlzZW1lbnQgZXh0ZW5zaW9ucyBm b3IgU0lQIGFuZCBYTVBQDQo+ID4+DQo+ID4+IC0gQmVzdCBwcmFjdGljZXMgZm9yIGltcGxlbWVu dGF0aW9uIGFuZCBkZXBsb3ltZW50IG9mIGR1YWwtc3RhY2sNCj4gPj4gZW5kcG9pbnRzDQo+ID4+ DQo+ID4+IE1pbGVzdG9uZXMNCj4gPj4NCj4gPj4gRmViIDIwMTEgIFN1Ym1pdCB1c2UgY2FzZXMg YW5kIHByb3RvY29sIHJlcXVpcmVtZW50cyBkb2N1bWVudCB0bw0KPiA+PiBJRVNHIChJbmZvcm1h dGlvbmFsKQ0KPiA+Pg0KPiA+PiBPY3QgMjAxMSAgU3VibWl0IFhNUFAgcHJlc2VuY2UgZXh0ZW5z aW9uIGRvY3VtZW50IHRvIElFU0cNCj4gPj4gKFN0YW5kYXJkcyBUcmFjaykNCj4gPj4NCj4gPj4g T2N0IDIwMTEgIFN1Ym1pdCBtZWRpYSBzZXNzaW9uIGNvcnJlbGF0aW9uIGV4dGVuc2lvbnMgZG9j dW1lbnQgdG8NCj4gPj4gSUVTRyAoU3RhbmRhcmRzIFRyYWNrKQ0KPiA+Pg0KPiA+PiBPY3QgMjAx MSAgU3VibWl0IGNvbnRhY3QgYWRkcmVzcyBhZHZlcnRpc2VtZW50IGV4dGVuc2lvbiBkb2N1bWVu dA0KPiA+PiB0byBJRVNHIChTdGFuZGFyZHMgVHJhY2spDQo+ID4+DQo+ID4+IE9jdCAyMDExICBT dWJtaXQgYmVzdCBwcmFjdGljZXMgZG9jdW1lbnQgdG8gSUVTRyAoSW5mb3JtYXRpb25hbCkNCg== From melodysong@huawei.com Thu Oct 28 22:58:42 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0739C3A69C3 for ; Thu, 28 Oct 2010 22:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.532 X-Spam-Level: X-Spam-Status: No, score=-99.532 tagged_above=-999 required=5 tests=[AWL=-0.896, BAYES_20=-0.74, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUfYQMlpcaew for ; Thu, 28 Oct 2010 22:58:41 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 2FE3C3A6904 for ; Thu, 28 Oct 2010 22:58:41 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LB100IG2FCNDM@szxga04-in.huawei.com> for dispatch@ietf.org; Fri, 29 Oct 2010 14:00:24 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LB100FCDFCM8Y@szxga04-in.huawei.com> for dispatch@ietf.org; Fri, 29 Oct 2010 14:00:23 +0800 (CST) Received: from s64081a ([10.138.41.74]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LB1002LJFCIDB@szxml04-in.huawei.com> for dispatch@ietf.org; Fri, 29 Oct 2010 14:00:22 +0800 (CST) Date: Fri, 29 Oct 2010 14:00:18 +0800 From: Song Haibin To: dispatch@ietf.org Message-id: <004801cb772e$905dabd0$b1190370$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Act3Loi4FUwI9O90TcqHRrZB+c8t7A== Subject: [dispatch] Is there a BOF on telepresence at Beijing meeting? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 05:58:42 -0000 Thanks, Haibin From stephen.botzko@gmail.com Fri Oct 29 04:30:48 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1E8F3A6A3B for ; Fri, 29 Oct 2010 04:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrNIRS6ZOjnE for ; Fri, 29 Oct 2010 04:30:47 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 7062E3A6810 for ; Fri, 29 Oct 2010 04:30:47 -0700 (PDT) Received: by bwz12 with SMTP id 12so2605358bwz.31 for ; Fri, 29 Oct 2010 04:32:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=i1zQeDMA+Dsk3OBcYw3RsXLNvhNSC3k54JAE4MU0DQA=; b=ZgfmqD95A77nq9azHrT3/nXJNcdnvMCn5RcI0AlC5/XHTWj5Tvg2FreVbSw/l3M3jO WxpJ3xN7tTgH4ItPzjg0uEkd3MGSti7pOUWYqIHSSVeYNjNQKojH+0RHRW9f79KsIGL7 LoXrM6Go4x2jX6Vjc0h1pQ7Yc+OgsNcvVJ5DM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=F1zE8rusjAR7MWri5B8kQ4ACDTLm+UvHep/66M/GdsNVVAmJVI9VcaECSeabDFkqHf PwQ0izl4WQlAA/Ku1lNVF8xD7d4jvETUMsWT5oZSMGpCcwYpsapYXZxjChjPMjDH19oF N28dXi2dJbAYOi+TuQvFtzHdBBZWKetGiin5M= MIME-Version: 1.0 Received: by 10.204.61.81 with SMTP id s17mr3821929bkh.121.1288351961002; Fri, 29 Oct 2010 04:32:41 -0700 (PDT) Received: by 10.204.80.213 with HTTP; Fri, 29 Oct 2010 04:32:40 -0700 (PDT) In-Reply-To: <004801cb772e$905dabd0$b1190370$@com> References: <004801cb772e$905dabd0$b1190370$@com> Date: Fri, 29 Oct 2010 07:32:40 -0400 Message-ID: From: Stephen Botzko To: Song Haibin Content-Type: multipart/alternative; boundary=00504502e44cfb344b0493bfd095 Cc: dispatch@ietf.org Subject: Re: [dispatch] Is there a BOF on telepresence at Beijing meeting? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 11:30:48 -0000 --00504502e44cfb344b0493bfd095 Content-Type: text/plain; charset=ISO-8859-1 There is no BOF, but it is on the agenda for the Dispatch session. Stephen Botzko On Fri, Oct 29, 2010 at 2:00 AM, Song Haibin wrote: > Thanks, > Haibin > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --00504502e44cfb344b0493bfd095 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There is no BOF, but it is on the agenda for the Dispatch session.

= Stephen Botzko

On Fri, Oct 29, 2010 at 2:= 00 AM, Song Haibin <melodysong@huawei.com> wrote:
Thanks,
Haibin


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

--00504502e44cfb344b0493bfd095-- From mary.ietf.barnes@gmail.com Fri Oct 29 06:46:50 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08D523A6907 for ; Fri, 29 Oct 2010 06:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrnIK1f9CpW8 for ; Fri, 29 Oct 2010 06:46:49 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 260473A681F for ; Fri, 29 Oct 2010 06:46:49 -0700 (PDT) Received: by gwb15 with SMTP id 15so2135603gwb.31 for ; Fri, 29 Oct 2010 06:48:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=IUmcHzqRs3Shv6HQuDygvug2X3RfzUcAOoUgSYgZ+Y0=; b=TqwqXoD0GfuNYAT5933x2iEkp9sdAHodafYS5zy55mtpKz78BPC2GOUWaUNn120tAc z6ZQ8QQL1Pet2LhiZkxdRsoZm68jnd8WO3QFFugEz+BrAjZeEm8QsUj7cwk9oX+8sTLv KvnaYrZmPSiH9OcqEX4Tj2Rf9ktVt+2EpPPHk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Yp9iCoc8F8sFEusXrDPs3EknaoHOvYEQRabK6aSD7KjLK8ABGGGjM+yb04YomjlFug DmFK4rBewweth5xukE5OW6/YoOiTwBMP8k227W2/hGtp0GTrK3oY6LNchX0sXoWoZB3Y fcHGiGiJCoVXhYwI8xfXUgLs1/BTo9HGoos5Q= MIME-Version: 1.0 Received: by 10.150.220.16 with SMTP id s16mr22429938ybg.149.1288360121694; Fri, 29 Oct 2010 06:48:41 -0700 (PDT) Received: by 10.236.28.41 with HTTP; Fri, 29 Oct 2010 06:48:41 -0700 (PDT) Date: Fri, 29 Oct 2010 08:48:41 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: text/plain; charset=ISO-8859-1 Subject: [dispatch] IETF-79 Agenda for DISPATCH X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 13:46:50 -0000 Hi folks, FYI, an updated version of the DISPATCH WG agenda (links updated to reflect most recent charters) has been uploaded to the meeting materials: http://www.ietf.org/proceedings/79/agenda/dispatch.html As a reminder, the wiki also contains a summary of the work items that are the focus for IETF-79 (as well as a summary of all previous meetings): http://trac.tools.ietf.org/wg/dispatch/trac/wiki Regards, Mary. From HKaplan@acmepacket.com Fri Oct 29 09:50:35 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A74C33A67FC for ; Fri, 29 Oct 2010 09:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBTozKlIigkK for ; Fri, 29 Oct 2010 09:50:34 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 4C72F3A67FB for ; Fri, 29 Oct 2010 09:50:34 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 29 Oct 2010 12:52:28 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 29 Oct 2010 12:52:07 -0400 From: Hadriel Kaplan To: Mary Barnes Date: Fri, 29 Oct 2010 12:52:06 -0400 Thread-Topic: [dispatch] IETF-79 Agenda for DISPATCH Thread-Index: Act3iZ7LWa+MSDOdRdWV7t4dz1CdCQ== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] IETF-79 Agenda for DISPATCH X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 16:50:35 -0000 I don't think I'll need 45 min for DTMF - maybe 30 mins tops. So teleprese= nce can have another 15. And I'd put mine after telepresence since it's a charter discussion, so the= y can run over. I expect the result of mine will be to go the individual submission path an= yway, since DTMF is too contentious a topic for most folks. But at least t= he presentation debate should be lively and entertaining. :) -hadriel On Oct 29, 2010, at 9:48 AM, Mary Barnes wrote: > Hi folks, >=20 > FYI, an updated version of the DISPATCH WG agenda (links updated to > reflect most recent charters) has been uploaded to the meeting > materials: > http://www.ietf.org/proceedings/79/agenda/dispatch.html >=20 > As a reminder, the wiki also contains a summary of the work items that > are the focus for IETF-79 (as well as a summary of all previous > meetings): > http://trac.tools.ietf.org/wg/dispatch/trac/wiki >=20 > Regards, > Mary. > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From aallen@rim.com Fri Oct 29 09:59:17 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D739C3A682B for ; Fri, 29 Oct 2010 09:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.532 X-Spam-Level: X-Spam-Status: No, score=-5.532 tagged_above=-999 required=5 tests=[AWL=-0.330, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OfiVsuxySm5x for ; Fri, 29 Oct 2010 09:59:16 -0700 (PDT) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id 966E83A67F3 for ; Fri, 29 Oct 2010 09:59:16 -0700 (PDT) X-AuditID: 0a666446-b7bceae000006b6d-f8-4ccafdd5f9ef Received: from XCH139CNC.rim.net ( [10.65.10.235]) by mhs04ykf.rim.net (RIM Mail) with SMTP id 30.88.27501.5DDFACC4; Fri, 29 Oct 2010 13:01:09 -0400 (EDT) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH139CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Oct 2010 13:01:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB778A.CED9B6E3" x-cr-puzzleid: {2BEF7610-80E8-4ACC-928C-92EC0200BEDD} x-cr-hashedpuzzle: E8c= VRw= AyIT BZVM Chok C2Yk EwvK FM2Z FZ2K Gebc G864 HMdI JPR8 KBgn KQsT LPTy; 1; ZABpAHMAcABhAHQAYwBoAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {2BEF7610-80E8-4ACC-928C-92EC0200BEDD}; YQBhAGwAbABlAG4AQAByAGkAbQAuAGMAbwBtAA==; Fri, 29 Oct 2010 17:00:32 GMT; UgBlAHYAaQBzAGUAZAAgAGQAcgBhAGYAdAAgAGQAcgBhAGYAdAAtAGEAbABsAGUAbgAtAGQAaQBzAHAAYQB0AGMAaAAtAGkAbQBlAGkALQB1AHIAbgAtAGEAcwAtAGkAbgBzAHQAYQBuAGMAZQBpAGQA Content-class: urn:content-classes:message Date: Fri, 29 Oct 2010 12:00:32 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revised draft draft-allen-dispatch-imei-urn-as-instanceid Thread-Index: Act3iswYm5bPteDcT4a/QWGsqnDVWQ== From: "Andrew Allen" To: X-OriginalArrivalTime: 29 Oct 2010 17:01:09.0851 (UTC) FILETIME=[E27212B0:01CB778A] X-Brightmail-Tracker: AAAABAAAAZEWfbhdFn3EehZ/0xA= Subject: [dispatch] Revised draft draft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 16:59:17 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB778A.CED9B6E3 Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable A revised version of draft-allen-dispatch-imei-urn-as-instanceid was uploaded earlier this week and can be found at http://www.ietf.org/id/draft-allen-dispatch-imei-urn-as-instanceid-01.tx t Please provide any feedback. Thanks Andrew Allen ---------------------------------------------------------------------=0A= 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. ------_=_NextPart_001_01CB778A.CED9B6E3 Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

A revised version of draft-allen-dispatch-imei-urn-as-i= nstanceid was uploaded earlier this week and can be found at

 

http://www.ietf.org/id/draft-allen-dispatch-imei-urn-as-instanceid-01= .txt

 

Please provide any feedback.

 

Thanks

Andrew Allen

---------------------------------------------------------------------
= =0A= 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. ------_=_NextPart_001_01CB778A.CED9B6E3-- From pkyzivat@cisco.com Fri Oct 29 10:22:38 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4135A3A6807 for ; Fri, 29 Oct 2010 10:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.474 X-Spam-Level: X-Spam-Status: No, score=-110.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmSBZ7c-3FWf for ; Fri, 29 Oct 2010 10:22:36 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 7E8FD3A67FB for ; Fri, 29 Oct 2010 10:22:36 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkFAJafykxAZnwM/2dsb2JhbACTW4VkiBVxoyicH4VIBIpTgwg X-IronPort-AV: E=Sophos;i="4.58,260,1286150400"; d="scan'208";a="176448244" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 29 Oct 2010 17:24:31 +0000 Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9THOVbw005657 for ; Fri, 29 Oct 2010 17:24:31 GMT Message-ID: <4CCB034F.4040303@cisco.com> Date: Fri, 29 Oct 2010 13:24:31 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: dispatch@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] IETF-79 Agenda for DISPATCH X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 17:22:38 -0000 On 10/29/2010 12:52 PM, Hadriel Kaplan wrote: > ... > since DTMF is too contentious a topic for most folks. > But at least the presentation debate should be lively and entertaining. :) Yes, no doubt! But then *all* of Hadriel's presentations seem to be lively and entertaining. Thanks, Paul From pkyzivat@cisco.com Fri Oct 29 10:31:13 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55E3F3A688C for ; Fri, 29 Oct 2010 10:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.475 X-Spam-Level: X-Spam-Status: No, score=-110.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvGToFE8Ruwf for ; Fri, 29 Oct 2010 10:31:12 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 50C743A67FC for ; Fri, 29 Oct 2010 10:31:12 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAO+hykxAZnwN/2dsb2JhbACTW415caM1nByFSASKU4MI X-IronPort-AV: E=Sophos;i="4.58,260,1286150400"; d="scan'208";a="176450709" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 29 Oct 2010 17:33:06 +0000 Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o9THX6Z4011644 for ; Fri, 29 Oct 2010 17:33:07 GMT Message-ID: <4CCB0552.8060403@cisco.com> Date: Fri, 29 Oct 2010 13:33:06 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: dispatch@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] Revised draft draft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 17:31:13 -0000 Andrew, This revision resolves my concerns. I'm happy with this draft. Thanks, Paul On 10/29/2010 1:00 PM, Andrew Allen wrote: > A revised version of draft-allen-dispatch-imei-urn-as-instanceid was > uploaded earlier this week and can be found at > > http://www.ietf.org/id/draft-allen-dispatch-imei-urn-as-instanceid-01.txt > > Please provide any feedback. > > Thanks > > Andrew Allen > > --------------------------------------------------------------------- > 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 HKaplan@acmepacket.com Fri Oct 29 12:49:10 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A5E43A682A for ; Fri, 29 Oct 2010 12:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfZjhe8J6qby for ; Fri, 29 Oct 2010 12:49:09 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 20C853A6A3C for ; Fri, 29 Oct 2010 12:49:08 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 29 Oct 2010 15:51:01 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 29 Oct 2010 15:50:51 -0400 From: Hadriel Kaplan To: Andrew Allen Date: Fri, 29 Oct 2010 15:50:49 -0400 Thread-Topic: [dispatch] Revised draft draft-allen-dispatch-imei-urn-as-instanceid Thread-Index: Act3opZa6p6m6JjaT4aufJOiKEPKBw== Message-ID: <0DA8DBE1-7199-480D-B6B2-8442EAF1A88A@acmepacket.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_0DA8DBE17199480DB6B28442EAF1A88Aacmepacketcom_" MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Revised draft draft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 19:49:10 -0000 --_000_0DA8DBE17199480DB6B28442EAF1A88Aacmepacketcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've read the draft and think it's both clear and useful. The only substan= tive question I have is why is it a separate document from the montemurro d= raft? Why don't you just incorporate both the format and the instance-id u= sage in one draft? The single draft can state the URN format is for genera= l use, while also specifying the instance-id usage, no? Regardless of whether it's one or two drafts, I believe it/they should be D= ISPATCHed as an A-D sponsored document. I don't think it falls within the scope of any current WG, nor does it need= a min-WG created for it. -hadriel On Oct 29, 2010, at 1:00 PM, Andrew Allen wrote: A revised version of draft-allen-dispatch-imei-urn-as-instanceid was upload= ed earlier this week and can be found at http://www.ietf.org/id/draft-allen-dispatch-imei-urn-as-instanceid-01.txt Please provide any feedback. Thanks Andrew Allen --------------------------------------------------------------------- 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. --_000_0DA8DBE17199480DB6B28442EAF1A88Aacmepacketcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
=
A revised version of draft-allen-dispatch-imei-urn-as-instan= ceid was uploaded earlier this week and can be found at
&n= bsp;
--= ------------------------------------------------------------------- 
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 informat= ion 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, distribu= tion, or reproduction of this transmission by unintended recipients is not = authorized and may be unlawful. = <ATT00001..c>

= = --_000_0DA8DBE17199480DB6B28442EAF1A88Aacmepacketcom_-- From aallen@rim.com Fri Oct 29 17:07:13 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC39C3A681D for ; Fri, 29 Oct 2010 17:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.515 X-Spam-Level: X-Spam-Status: No, score=-5.515 tagged_above=-999 required=5 tests=[AWL=-0.313, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HL9IcQZlhe0 for ; Fri, 29 Oct 2010 17:07:11 -0700 (PDT) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id 7F29F3A63D2 for ; Fri, 29 Oct 2010 17:07:09 -0700 (PDT) X-AuditID: 0a666446-b7bceae000006b6d-ec-4ccb6220a992 Received: from XCH139CNC.rim.net ( [10.65.10.235]) by mhs04ykf.rim.net (RIM Mail) with SMTP id E7.CD.27501.0226BCC4; Fri, 29 Oct 2010 20:09:04 -0400 (EDT) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH139CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Oct 2010 20:09:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB77C6.8F6CEF4D" Date: Fri, 29 Oct 2010 19:08:21 -0500 Message-ID: In-Reply-To: <0DA8DBE1-7199-480D-B6B2-8442EAF1A88A@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Revised draft draft-allen-dispatch-imei-urn-as-instanceid Thread-Index: Act3opZa6p6m6JjaT4aufJOiKEPKBwAI6Xng References: <0DA8DBE1-7199-480D-B6B2-8442EAF1A88A@acmepacket.com> From: "Andrew Allen" To: "Hadriel Kaplan" X-OriginalArrivalTime: 30 Oct 2010 00:09:04.0702 (UTC) FILETIME=[A9D96DE0:01CB77C6] X-Brightmail-Tracker: AAAAAwAAAZEWfcR6Fn/TEA== Cc: dispatch@ietf.org Subject: Re: [dispatch] Revised draft draft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 00:07:13 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB77C6.8F6CEF4D Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Hadriel It was previously included in the 04 version of the Montemurro draft but the RAI AD thought that this ought to be in an RAI draft and not in the URN definition draft. I am in favor of this being an AD sponsored document. Andrew From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Sent: Friday, October 29, 2010 2:51 PM To: Andrew Allen Cc: dispatch@ietf.org Subject: Re: [dispatch] Revised draft draft-allen-dispatch-imei-urn-as-instanceid I've read the draft and think it's both clear and useful. The only substantive question I have is why is it a separate document from the montemurro draft? Why don't you just incorporate both the format and the instance-id usage in one draft? The single draft can state the URN format is for general use, while also specifying the instance-id usage, no? Regardless of whether it's one or two drafts, I believe it/they should be DISPATCHed as an A-D sponsored document. I don't think it falls within the scope of any current WG, nor does it need a min-WG created for it. -hadriel On Oct 29, 2010, at 1:00 PM, Andrew Allen wrote: A revised version of draft-allen-dispatch-imei-urn-as-instanceid was uploaded earlier this week and can be found at http://www.ietf.org/id/draft-allen-dispatch-imei-urn-as-instanceid-01.tx t Please provide any feedback. Thanks Andrew Allen --------------------------------------------------------------------- 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. ---------------------------------------------------------------------=0A= 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. ------_=_NextPart_001_01CB77C6.8F6CEF4D Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Hadriel

 

It was previously included in the 04 version of the Montemurr= o draft but the RAI AD thought that this ought to be in an RAI draft and not in the= URN definition draft.

 

I am in favor of this being an AD sponsored document.

 

Andrew

 

From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]
Sent: Friday, October 29, 2010 2:51 PM
To: Andrew Allen
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Revised draft draft-allen-dispatch-imei-urn-as-instanceid

 

 

I've read the draft and think it's both clear and usefu= l.  The only substantive question I have is why is it a separate document from the montemurro draft?  Why don't you just incorporate both the for= mat and the instance-id usage in one draft?  The single draft can state the URN format is for general use, while also specifying the instance-id usage,= no?

 

Regardless of whether it's one or two drafts, I believe it/they should be DISPATCHed as an A-D sponsored document.  =

I don't think it falls within the scope of any current= WG, nor does it need a min-WG created for it.

 

-hadriel

 

On Oct 29, 2010, at 1:00 PM, Andrew Allen wrote:



A revised version of draft-allen-dispatch-imei-urn-as-instanceid was uploaded earlier this week and can be found at

 

 

Please provide any feedback.

 

Thanks

Andrew Allen

-------------------------------------------------------------= -------- 
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 transmissi= on by unintended recipients is not authorized and may be unlawful. <ATT00001..c>

 

---------------------------------------------------------------------
= =0A= 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. ------_=_NextPart_001_01CB77C6.8F6CEF4D--