From vumip1@gmail.com  Sun Feb  3 18:37:24 2013
Return-Path: <vumip1@gmail.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0205521F87ED; Sun,  3 Feb 2013 18:37:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ogq5Y-+pBcA; Sun,  3 Feb 2013 18:37:23 -0800 (PST)
Received: from mail-la0-x22d.google.com (la-in-x022d.1e100.net [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id A15E421F873D; Sun,  3 Feb 2013 18:37:11 -0800 (PST)
Received: by mail-la0-f45.google.com with SMTP id er20so4114245lab.4 for <multiple recipients>; Sun, 03 Feb 2013 18:37:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=5/bTlmPzPLrOs2LW7+pjaShJqDy4uZMlbGCFn2gfpxw=; b=i9BgH8dEW/ykmo+qRZj/nGrbrfyqz6PRu1Xxs4MGiPudYANm/jh4A5nq/jNg70VIYo RWOV1aZdrATQ0E46F5/ajjjgwkT/bOHNrrut0SjovaWenrPyuH2fT9TgU4wp9GrnRUtA usyvYxXldeHZJpCqkcM//5+/rbV9uyscDubLfoZP6t8umAiGQHTln+Z9ktcG61n8cBXy bxK3wmDdCBMhmTl1aHyrtBFLJdhrXY46BgB6T8M1vPD2r80QER2TlHcL6G0wMCrSGbzs eiT7A1G4vTX3T0GosfV0qp2gTQtRj6/PCKQwDgLaIAvDlX3puTLZxi/WDis7E2I/dDgu WBbg==
MIME-Version: 1.0
X-Received: by 10.112.17.166 with SMTP id p6mr2076855lbd.41.1359945430450; Sun, 03 Feb 2013 18:37:10 -0800 (PST)
Received: by 10.114.29.198 with HTTP; Sun, 3 Feb 2013 18:37:10 -0800 (PST)
Date: Sun, 3 Feb 2013 21:37:10 -0500
Message-ID: <CANtnpwjqyR06eg9nXc3x_gjtWs54n+JgL37F_iLM_SbmT5PyHA@mail.gmail.com>
From: "B.Khasnabish@ieee.org" <vumip1@gmail.com>
To: dispatch@ietf.org, opsawg@ietf.org, ppsp@ietf.org
Content-Type: multipart/alternative; boundary=bcaec55400f04bc1d804d4dcf8d3
Subject: [dispatch] Fwd: End-point based Multimedia QoE Management draft (draft-khasnabish-dispatch-qoe-management-00.txt) published
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Feb 2013 02:37:24 -0000

--bcaec55400f04bc1d804d4dcf8d3
Content-Type: text/plain; charset=ISO-8859-1

Hello,
FYI, and kind review/comments/suggestions.
Thanks.
Best.
Bhumip and Gerard

I-D Action: draft-khasnabish-dispatch-qoe-management-00.txt
------------------------------

   - *To*: i-d-announce at ietf.org <i-d-announce%20at%20DOMAIN.HIDDEN>
   - *Subject*: I-D Action: draft-khasnabish-dispatch-qoe-management-00.txt
   - *From*: internet-drafts at ietf.org<internet-drafts%20at%20DOMAIN.HIDDEN>
   - *Date*: Mon, 31 Dec 2012 19:18:28 -0800
   - *Delivered-to*: i-d-announce at
ietfa.amsl.com<i-d-announce%20at%20DOMAIN.HIDDEN>
   - *List-archive*: <http://www.ietf.org/mail-archive/web/i-d-announce>
   - *List-help*: <mailto:i-d-announce-request at
ietf.org?subject=help<i-d-announce-request%20at%20ietf.org?subject=help>>

   - *List-id*: Internet Draft Announcements only <i-d-announce.ietf.org>
   - *List-post*: <mailto:i-d-announce at
ietf.org<i-d-announce%20at%20ietf.org>>

   - *List-subscribe*: <https://www.ietf.org/mailman/listinfo/i-d-announce>,
   <mailto:i-d-announce-request at
ietf.org?subject=subscribe<i-d-announce-request%20at%20ietf.org?subject=subscribe>>

   - *List-unsubscribe*: <https://www.ietf.org/mailman/options/i-d-announce>,
   <mailto:i-d-announce-request at
ietf.org?subject=unsubscribe<i-d-announce-request%20at%20ietf.org?subject=unsubscribe>>

   - *Reply-to*: internet-drafts at
ietf.org<internet-drafts%20at%20DOMAIN.HIDDEN>

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

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title           : End-point based Multimedia QoE Management
	Author(s)       : Bhumip Khasnabish
                          Gerard Fernando
	Filename        : draft-khasnabish-dispatch-qoe-management-00.txt
	Pages           : 17
	Date            : 2012-12-31

Abstract:
   This draft describes a method for improving the quality of experience
   (QoE) for real-time video and other multimedia services using
   features and functions of the end-point only, that is, without
   requiring any upgrade to the network transport infrastructure.  Any
   upgrade to the network transport infrastructure not only incurs
   significant costs, these are also time consuming and technology-
   dependent.  Therefore, these QoE improvement mechanisms are
   significantly more attractive to both network operators and service
   providers.


The IETF datatracker status page for this draft
is:https://datatracker.ietf.org/doc/draft-khasnabish-dispatch-qoe-management

There's also a htmlized version available
at:http://tools.ietf.org/html/draft-khasnabish-dispatch-qoe-management-00


Internet-Drafts are also available by anonymous FTP
at:ftp://ftp.ietf.org/internet-drafts/

--bcaec55400f04bc1d804d4dcf8d3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div><font color=3D"#000099" size=3D"4" face=3D"georgia,serif">Hello,</font=
></div>
<div><font color=3D"#000099" size=3D"4" face=3D"georgia,serif">FYI, and kin=
d review/comments/suggestions. </font></div>
<div><font color=3D"#000099" size=3D"4" face=3D"georgia,serif">Thanks.=A0 <=
/font></div>
<div><font color=3D"#000099" size=3D"4" face=3D"georgia,serif">Best.</font>=
</div>
<div><font color=3D"#000099" size=3D"4" face=3D"georgia,serif">Bhumip and G=
erard=A0 </font><br clear=3D"all">=A0</div>
<h1>I-D Action: draft-khasnabish-dispatch-qoe-management-00.txt</h1>
<hr>

<ul>
<li><em>To</em>: <a href=3D"mailto:i-d-announce%20at%20DOMAIN.HIDDEN" rel=
=3D"nofollow">i-d-announce at ietf.org</a>=20
<li><em>Subject</em>: I-D Action: draft-khasnabish-dispatch-qoe-management-=
00.txt=20
<li><em>From</em>: <a href=3D"mailto:internet-drafts%20at%20DOMAIN.HIDDEN" =
rel=3D"nofollow">internet-drafts at ietf.org</a>=20
<li><em>Date</em>: Mon, 31 Dec 2012 19:18:28 -0800=20
<li><em>Delivered-to</em>: <a href=3D"mailto:i-d-announce%20at%20DOMAIN.HID=
DEN" rel=3D"nofollow">i-d-announce at ietfa.amsl.com</a>=20
<li><em>List-archive</em>: &lt;<a href=3D"http://www.ietf.org/mail-archive/=
web/i-d-announce" rel=3D"nofollow">http://www.ietf.org/mail-archive/web/i-d=
-announce</a>&gt;=20
<li><em>List-help</em>: &lt;<a href=3D"mailto:i-d-announce-request%20at%20i=
etf.org?subject=3Dhelp" rel=3D"nofollow">mailto:i-d-announce-request at iet=
f.org?subject=3Dhelp</a>&gt;=20
<li><em>List-id</em>: Internet Draft Announcements only &lt;<a href=3D"http=
://i-d-announce.ietf.org/" rel=3D"nofollow">i-d-announce.ietf.org</a>&gt;=
=20
<li><em>List-post</em>: &lt;<a href=3D"mailto:i-d-announce%20at%20ietf.org"=
 rel=3D"nofollow">mailto:i-d-announce at ietf.org</a>&gt;=20
<li><em>List-subscribe</em>: &lt;<a href=3D"https://www.ietf.org/mailman/li=
stinfo/i-d-announce" rel=3D"nofollow">https://www.ietf.org/mailman/listinfo=
/i-d-announce</a>&gt;, &lt;<a href=3D"mailto:i-d-announce-request%20at%20ie=
tf.org?subject=3Dsubscribe" rel=3D"nofollow">mailto:i-d-announce-request at=
 ietf.org?subject=3Dsubscribe</a>&gt;=20
<li><em>List-unsubscribe</em>: &lt;<a href=3D"https://www.ietf.org/mailman/=
options/i-d-announce" rel=3D"nofollow">https://www.ietf.org/mailman/options=
/i-d-announce</a>&gt;, &lt;<a href=3D"mailto:i-d-announce-request%20at%20ie=
tf.org?subject=3Dunsubscribe" rel=3D"nofollow">mailto:i-d-announce-request =
at ietf.org?subject=3Dunsubscribe</a>&gt;=20
<li><em>Reply-to</em>: <a href=3D"mailto:internet-drafts%20at%20DOMAIN.HIDD=
EN" rel=3D"nofollow">internet-drafts at ietf.org</a> </li></li></li></li></=
li></li></li></li></li></li></li></li></ul>
<hr>
<pre>A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.


	Title           : End-point based Multimedia QoE Management
	Author(s)       : Bhumip Khasnabish
                          Gerard Fernando
	Filename        : draft-khasnabish-dispatch-qoe-management-00.txt
	Pages           : 17
	Date            : 2012-12-31

Abstract:
   This draft describes a method for improving the quality of experience
   (QoE) for real-time video and other multimedia services using
   features and functions of the end-point only, that is, without
   requiring any upgrade to the network transport infrastructure.  Any
   upgrade to the network transport infrastructure not only incurs
   significant costs, these are also time consuming and technology-
   dependent.  Therefore, these QoE improvement mechanisms are
   significantly more attractive to both network operators and service
   providers.


The IETF datatracker status page for this draft is:
<a href=3D"https://datatracker.ietf.org/doc/draft-khasnabish-dispatch-qoe-m=
anagement" rel=3D"nofollow">https://datatracker.ietf.org/doc/draft-khasnabi=
sh-dispatch-qoe-management</a>

There&#39;s also a htmlized version available at:
<a href=3D"http://tools.ietf.org/html/draft-khasnabish-dispatch-qoe-managem=
ent-00" rel=3D"nofollow">http://tools.ietf.org/html/draft-khasnabish-dispat=
ch-qoe-management-00</a>


Internet-Drafts are also available by anonymous FTP at:
<a href=3D"ftp://ftp.ietf.org/internet-drafts/" rel=3D"nofollow">ftp://ftp.=
ietf.org/internet-drafts/</a>
</pre>

--bcaec55400f04bc1d804d4dcf8d3--

From ag@ag-projects.com  Mon Feb  4 07:20:15 2013
Return-Path: <ag@ag-projects.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D4D21F88AC for <dispatch@ietfa.amsl.com>; Mon,  4 Feb 2013 07:20:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.059
X-Spam-Level: 
X-Spam-Status: No, score=-1.059 tagged_above=-999 required=5 tests=[AWL=0.929,  BAYES_00=-2.599, HELO_MISMATCH_NET=0.611]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbI5-40Bv2qA for <dispatch@ietfa.amsl.com>; Mon,  4 Feb 2013 07:20:14 -0800 (PST)
Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5053021F8818 for <dispatch@ietf.org>; Mon,  4 Feb 2013 07:20:14 -0800 (PST)
Received: by mail.sipthor.net (Postfix, from userid 5001) id 679F3B35E3; Mon,  4 Feb 2013 16:20:13 +0100 (CET)
Received: from ag-retina.fritz.box (xs4all.dns-hosting.info [82.161.39.123]) by mail.sipthor.net (Postfix) with ESMTPSA id 74DE1B0067 for <dispatch@ietf.org>; Mon,  4 Feb 2013 16:20:12 +0100 (CET)
From: Adrian Georgescu <ag@ag-projects.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Mon, 4 Feb 2013 16:20:19 +0100
Message-Id: <99D2D5AB-A2B7-493F-BA28-01C12FB26936@ag-projects.com>
To: dispatch@ietf.org
Mime-Version: 1.0 (Apple Message framework v1283)
X-Mailer: Apple Mail (2.1283)
Subject: [dispatch] Feedback for SIMPLE/MSRP to XMPP interoperability
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Feb 2013 15:20:15 -0000

Hello,

By implementing the draft specifications for SIMPLE/MSRP to XMPP and =
MSRP-switch to MUC gateway we discovered several issues that we needed =
to tackle differently or were not addressed at all at the moment of =
their writing. The drafts I am referring to are:

http://tools.ietf.org/html/draft-saintandre-sip-xmpp-core-01
=
http://xmpp.org/internet-drafts/draft-saintandre-sip-xmpp-presence-02.html=

http://xmpp.org/internet-drafts/draft-saintandre-sip-xmpp-im-01.html
http://xmpp.org/internet-drafts/draft-saintandre-sip-xmpp-chat-03.html
=
http://xmpp.org/internet-drafts/draft-saintandre-sip-xmpp-groupchat-01.htm=
l

As there are many comments, we made a web page to summarize them as best =
as we could.

http://sylkserver.ag-projects.com/projects/sylkserver/wiki/XMPP-Interop

The software implementing these drafts is now available in the public =
domain. I hope this feedback can be used to continue and finalize the =
standardization works started in those drafts. I am not sure which WG is =
the best place for this, so I mailed all three I am aware of.

Regards,
Adrian





From worley@shell01.TheWorld.com  Mon Feb  4 12:54:03 2013
Return-Path: <worley@shell01.TheWorld.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B1A21F8B3A for <dispatch@ietfa.amsl.com>; Mon,  4 Feb 2013 12:54:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.622
X-Spam-Level: 
X-Spam-Status: No, score=-2.622 tagged_above=-999 required=5 tests=[AWL=0.358,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRtqe+UHNMKO for <dispatch@ietfa.amsl.com>; Mon,  4 Feb 2013 12:54:02 -0800 (PST)
Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 868EB21F8B34 for <dispatch@ietf.org>; Mon,  4 Feb 2013 12:54:02 -0800 (PST)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r14KquHM011339 for <dispatch@ietf.org>; Mon, 4 Feb 2013 15:52:58 -0500
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r14KqueJ1198350 for <dispatch@ietf.org>; Mon, 4 Feb 2013 15:52:56 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r14Kqu3E1205998; Mon, 4 Feb 2013 15:52:56 -0500 (EST)
Date: Mon, 4 Feb 2013 15:52:56 -0500 (EST)
Message-Id: <201302042052.r14Kqu3E1205998@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: dispatch@ietf.org
In-reply-to: <55A5A9A87506CB4BA580BF9D531957DA921A03FA@STNTEXCH01.cis.neustar.com> (jon.peterson@neustar.biz)
References: <55A5A9A87506CB4BA580BF9D531957DA921A03FA@STNTEXCH01.cis.neustar.com>
Subject: Re: [dispatch] TeRQ use cases
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Feb 2013 20:54:03 -0000

That loods like a very good start on enunciating the problems to be
addressed.

One thing that I noticed is that all of the use cases have
authentication/authorization aspects, some of which are more subtle
that the common authentication approaches.  (In one case, the client
has to authenticate itself to get the query processed, but the
multiple query responses themselves carry authentication by different
authorities, based on which the client may individually accept or
discard responses.)  So it would suggest that the Security
Considerations section of the draft is quite central to the
architecture.

Dale

From stpeter@stpeter.im  Mon Feb  4 19:27:02 2013
Return-Path: <stpeter@stpeter.im>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51DAA21F8A51 for <dispatch@ietfa.amsl.com>; Mon,  4 Feb 2013 19:27:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.569
X-Spam-Level: 
X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GK3Z8ppLGFnE for <dispatch@ietfa.amsl.com>; Mon,  4 Feb 2013 19:27:01 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 59F0221F8862 for <dispatch@ietf.org>; Mon,  4 Feb 2013 19:26:57 -0800 (PST)
Received: from [192.168.1.5] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 63F1740564 for <dispatch@ietf.org>; Mon,  4 Feb 2013 20:33:24 -0700 (MST)
Message-ID: <51102D21.10503@stpeter.im>
Date: Mon, 04 Feb 2013 14:50:25 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: dispatch@ietf.org
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: [dispatch] URI schemes in P-Asserted-Identity
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Feb 2013 03:27:02 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear DISPATCHers,

At the XMPP Summit last week, for various reasons that aren't
particularly relevant here, we talked a bit about how to include an
XMPP address in the header of a SIP message. Folks at the meeting
concluded that the P-Asserted-Identity header would work quite well
(certainly better than a second Contact header). Unfortunately, RFC
3225 defines the P-Asserted-Identity as follows:

   A P-Asserted-Identity header field value MUST consist of exactly one
   name-addr or addr-spec.  There may be one or two P-Asserted-Identity
   values.  If there is one value, it MUST be a sip, sips, or tel URI.
   If there are two values, one value MUST be a sip or sips URI and the
   other MUST be a tel URI.

It's not clear to me why the definition restricts the scheme to sip,
sips, or tel. Could someone provide some insight about that? Would
things break if we allowed more URI schemes there, in particular the
xmpp scheme?

Thanks!

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlEQLSEACgkQNL8k5A2w/vyr8ACfcAqzu+1ceGZxu0qvQLECL4rg
6DIAoMFh0zKEs2sjN1R3yUy6HyJGU2N/
=lu3v
-----END PGP SIGNATURE-----

From gsalguei@cisco.com  Mon Feb  4 19:59:22 2013
Return-Path: <gsalguei@cisco.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1860F21F87B2 for <dispatch@ietfa.amsl.com>; Mon,  4 Feb 2013 19:59:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.449
X-Spam-Level: 
X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRocuaEalBmk for <dispatch@ietfa.amsl.com>; Mon,  4 Feb 2013 19:59:21 -0800 (PST)
Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 259B321F8759 for <dispatch@ietf.org>; Mon,  4 Feb 2013 19:59:21 -0800 (PST)
X-TACSUNS: Virus Scanned
Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r153xKHv028493 for <dispatch@ietf.org>; Mon, 4 Feb 2013 22:59:20 -0500 (EST)
Received: from rtp-gsalguei-8918.cisco.com (rtp-gsalguei-8918.cisco.com [10.116.132.57]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r153xAJq013703; Mon, 4 Feb 2013 22:59:10 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Gonzalo Salgueiro <gsalguei@cisco.com>
In-Reply-To: <51102D21.10503@stpeter.im>
Date: Mon, 4 Feb 2013 22:59:10 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <4108EC5C-3B6B-43FB-8303-B894FEAB4F00@cisco.com>
References: <51102D21.10503@stpeter.im>
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Mailer: Apple Mail (2.1499)
Cc: dispatch@ietf.org
Subject: Re: [dispatch] URI schemes in P-Asserted-Identity
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Feb 2013 03:59:22 -0000

RFC 5876 extends the P-Asserted-Identity header to cover unexpected URI =
schemes (i.e., other than SIP/SIPS/TEL):

   RFC 3325 allows the P-Asserted-Identity and P-Preferred-Identity
   header fields each to contain at most two URIs, where one is a SIP or
   SIPS URI [RFC3261] and the other is a TEL URI [RFC3966].  This may be
   unduly restrictive in the future, for example, if there is a need to
   allow other URI schemes, if there is a need to allow both a SIP and a
   SIPS URI, or if there is a need to allow more than one URI with the
   same scheme (e.g., a SIP URI based on a telephone number and a SIP
   URI that is not based on a telephone number).  This document
   therefore provides forwards compatibility by mandating tolerance to
   the receipt of unexpected URIs.

See Section 4.5 for general handling of unexpected URI schemes.

Regards,

Gonzalo


On Feb 4, 2013, at 4:50 PM, Peter Saint-Andre <stpeter@stpeter.im> =
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> Dear DISPATCHers,
>=20
> At the XMPP Summit last week, for various reasons that aren't
> particularly relevant here, we talked a bit about how to include an
> XMPP address in the header of a SIP message. Folks at the meeting
> concluded that the P-Asserted-Identity header would work quite well
> (certainly better than a second Contact header). Unfortunately, RFC
> 3225 defines the P-Asserted-Identity as follows:
>=20
>   A P-Asserted-Identity header field value MUST consist of exactly one
>   name-addr or addr-spec.  There may be one or two P-Asserted-Identity
>   values.  If there is one value, it MUST be a sip, sips, or tel URI.
>   If there are two values, one value MUST be a sip or sips URI and the
>   other MUST be a tel URI.
>=20
> It's not clear to me why the definition restricts the scheme to sip,
> sips, or tel. Could someone provide some insight about that? Would
> things break if we allowed more URI schemes there, in particular the
> xmpp scheme?
>=20
> Thanks!
>=20
> Peter
>=20
> - --=20
> Peter Saint-Andre
> https://stpeter.im/
>=20
>=20
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>=20
> iEYEARECAAYFAlEQLSEACgkQNL8k5A2w/vyr8ACfcAqzu+1ceGZxu0qvQLECL4rg
> 6DIAoMFh0zKEs2sjN1R3yUy6HyJGU2N/
> =3Dlu3v
> -----END PGP SIGNATURE-----
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>=20


From pkyzivat@alum.mit.edu  Mon Feb  4 21:19:19 2013
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6EE521F878F for <dispatch@ietfa.amsl.com>; Mon,  4 Feb 2013 21:19:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.338
X-Spam-Level: 
X-Spam-Status: No, score=-0.338 tagged_above=-999 required=5 tests=[AWL=0.099,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnykZptkZXhq for <dispatch@ietfa.amsl.com>; Mon,  4 Feb 2013 21:19:18 -0800 (PST)
Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id A2AEB21F85D4 for <dispatch@ietf.org>; Mon,  4 Feb 2013 21:19:17 -0800 (PST)
Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta02.westchester.pa.mail.comcast.net with comcast id wUsJ1k0050EZKEL51VKHXs; Tue, 05 Feb 2013 05:19:17 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id wVKH1k0033ZTu2S3MVKHC5; Tue, 05 Feb 2013 05:19:17 +0000
Message-ID: <51109654.40002@alum.mit.edu>
Date: Tue, 05 Feb 2013 00:19:16 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: dispatch@ietf.org
References: <51102D21.10503@stpeter.im>
In-Reply-To: <51102D21.10503@stpeter.im>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1360041557; bh=QnzbiXPDPLXeOA/noRJd1pMcM7vD3KlQlG+NDuowWJY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=lcolRfXR6SFju9HFyf8mSpH5dFfoqBHhUe8I9zBD9DpTZCM9h0ZPyiCZrEhy8AE1Z 54rXswc5JqTK/+Bu1QGAAe4yJXqAN9/5U+NSZczSV5PI5qsxZj0MF2BOwBdtLqRZjr LhJJyB5Km0XuqZQC0bkwCGb32qd+P/Kc3UvyAHQ4h9kDf3rN+wV98fTfCBixxTkOYm Sy8q+QQBloYOXGfiVPqqkLY5KORAK2Ko/xYBt5ZLuP1u7CQpMDJ8KRM7qwApPnzEil 7ql4hpuQM1gUObaLDmmtRRI6r/Jc8fdGndTEodtzlprBqTg4chgNdsFPkmTocqCq4M EQe4NQUsp8qPA==
Subject: Re: [dispatch] URI schemes in P-Asserted-Identity
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Feb 2013 05:19:19 -0000

Not responsive to your specific query, but what places did you consider?

Reply-To is a possibility.

And while Contact isn't viable for this in most messages, in REGISTER it 
can work.

	Thanks,
	Paul

On 2/4/13 4:50 PM, Peter Saint-Andre wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dear DISPATCHers,
>
> At the XMPP Summit last week, for various reasons that aren't
> particularly relevant here, we talked a bit about how to include an
> XMPP address in the header of a SIP message. Folks at the meeting
> concluded that the P-Asserted-Identity header would work quite well
> (certainly better than a second Contact header). Unfortunately, RFC
> 3225 defines the P-Asserted-Identity as follows:
>
>     A P-Asserted-Identity header field value MUST consist of exactly one
>     name-addr or addr-spec.  There may be one or two P-Asserted-Identity
>     values.  If there is one value, it MUST be a sip, sips, or tel URI.
>     If there are two values, one value MUST be a sip or sips URI and the
>     other MUST be a tel URI.
>
> It's not clear to me why the definition restricts the scheme to sip,
> sips, or tel. Could someone provide some insight about that? Would
> things break if we allowed more URI schemes there, in particular the
> xmpp scheme?
>
> Thanks!
>
> Peter
>
> - --
> Peter Saint-Andre
> https://stpeter.im/
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlEQLSEACgkQNL8k5A2w/vyr8ACfcAqzu+1ceGZxu0qvQLECL4rg
> 6DIAoMFh0zKEs2sjN1R3yUy6HyJGU2N/
> =lu3v
> -----END PGP SIGNATURE-----
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>


From ag@ag-projects.com  Mon Feb  4 05:08:23 2013
Return-Path: <ag@ag-projects.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EEDE21F85B1; Mon,  4 Feb 2013 05:08:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.129
X-Spam-Level: 
X-Spam-Status: No, score=-0.129 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_MISMATCH_NET=0.611]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id piq5oXXvbdyl; Mon,  4 Feb 2013 05:08:22 -0800 (PST)
Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 897A721F84E0; Mon,  4 Feb 2013 05:08:13 -0800 (PST)
Received: by mail.sipthor.net (Postfix, from userid 5001) id D85ABB35E2; Mon,  4 Feb 2013 14:08:11 +0100 (CET)
Received: from ag-retina.fritz.box (xs4all.dns-hosting.info [82.161.39.123]) by mail.sipthor.net (Postfix) with ESMTPSA id 6906CB35E0; Mon,  4 Feb 2013 14:08:10 +0100 (CET)
From: Adrian Georgescu <ag@ag-projects.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Mon, 4 Feb 2013 14:08:11 +0100
Message-Id: <67896036-9CE7-427A-9D15-3B75C76CE829@ag-projects.com>
To: xmpp@ietf.org, dispatch@ietf.org, simple@ietf.org
Mime-Version: 1.0 (Apple Message framework v1283)
X-Mailer: Apple Mail (2.1283)
X-Mailman-Approved-At: Tue, 05 Feb 2013 04:45:06 -0800
Subject: [dispatch] Feedback for SIMPLE/MSRP to XMPP interoperability
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Feb 2013 13:08:23 -0000

Hello,

By implementing the draft specifications for SIMPLE/MSRP to XMPP and =
MSRP-switch to MUC gateway we discovered several issues that we needed =
to tackle differently or were not addressed at all at the moment of =
their writing. The drafts I am referring to are:

http://tools.ietf.org/html/draft-saintandre-sip-xmpp-core-01
=
http://xmpp.org/internet-drafts/draft-saintandre-sip-xmpp-presence-02.html=

http://xmpp.org/internet-drafts/draft-saintandre-sip-xmpp-im-01.html
http://xmpp.org/internet-drafts/draft-saintandre-sip-xmpp-chat-03.html
=
http://xmpp.org/internet-drafts/draft-saintandre-sip-xmpp-groupchat-01.htm=
l

As there are many comments, we made a web page to summarize them as best =
as we could.

http://sylkserver.ag-projects.com/projects/sylkserver/wiki/XMPP-Interop

The software implementing these drafts is now available in the public =
domain. I hope this feedback can be used to continue and finalize the =
standardization works started in those drafts. I am not sure which WG is =
the best place for this, so I mailed all three I am aware of.

Regards,
Adrian


=20

=20=

From emil@sip-communicator.org  Tue Feb  5 06:28:03 2013
Return-Path: <emil@sip-communicator.org>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6921321F85FD for <dispatch@ietfa.amsl.com>; Tue,  5 Feb 2013 06:28:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGiZ5upcbg4r for <dispatch@ietfa.amsl.com>; Tue,  5 Feb 2013 06:28:02 -0800 (PST)
Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA5421F87D3 for <dispatch@ietf.org>; Tue,  5 Feb 2013 06:28:02 -0800 (PST)
Received: by mail-pa0-f51.google.com with SMTP id hz1so171791pad.10 for <dispatch@ietf.org>; Tue, 05 Feb 2013 06:28:02 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=pewMh2JniPbDO1L70bcAZb8MDzv+gj2l/yE6fwvlJCo=; b=T4QFMsF3dp6xobOeWdI8nbVXjvsxa4lZeNSUe67VVe6vRyBdnNA0zXRbqBcilKvsRT 4W2KaL6zpudFQ9KrXdtwdfkwuP+IKp+chcKIFMpyg+uKFqSrgDwVdKwWXx/303G5OhbR xSQzMMtgfiy8p70+rhYahcpktk+SAeZy6450YzvAKy+GZKi438uT5bDPgpg4DZoZwT7G aYuwmlx5Iu4cFhf6LWSklQN0hEs9wcucNfJtg6lNz1J9e2Dhg1G7LZZ6mUT3RzRm8+5s r2aFaUSYIVzRrGKUc4hXpaFSsZj1HSDafdDeeVwE0Or3IS++xpn7AdEWRsVs3+h0dHp0 Qt7w==
X-Received: by 10.66.82.35 with SMTP id f3mr64568407pay.49.1360074481903; Tue, 05 Feb 2013 06:28:01 -0800 (PST)
Received: from camionet.local (static-155-212-214-60.mas.onecommunications.net. [155.212.214.60]) by mx.google.com with ESMTPS id w2sm24388112pax.22.2013.02.05.06.28.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Feb 2013 06:28:01 -0800 (PST)
Message-ID: <511116EE.4060705@jitsi.org>
Date: Tue, 05 Feb 2013 09:27:58 -0500
From: Emil Ivov <emcho@jitsi.org>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
References: <51102D21.10503@stpeter.im> <51109654.40002@alum.mit.edu>
In-Reply-To: <51109654.40002@alum.mit.edu>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQngEGV8AshGy++VaNpuG22t4RATIkMDcBchHZUkYgucFOarsFYkRCTaEv9jkmTpa6HUDo+j
Cc: dispatch@ietf.org
Subject: Re: [dispatch] URI schemes in P-Asserted-Identity
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Feb 2013 14:28:03 -0000

Hey Paul,

On 05.02.13, 00:19, Paul Kyzivat wrote:
> Not responsive to your specific query, but what places did you consider?
> 
> Reply-To is a possibility.
> 
> And while Contact isn't viable for this in most messages, in REGISTER it 
> can work.

Right, but we really need something in the INVITE in order to avoid
having to look through a roster for an entry or an entry's vCard
matching the "From" header (which also has security issues).

Emil
> 
> 	Thanks,
> 	Paul
> 
> On 2/4/13 4:50 PM, Peter Saint-Andre wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Dear DISPATCHers,
>>
>> At the XMPP Summit last week, for various reasons that aren't
>> particularly relevant here, we talked a bit about how to include an
>> XMPP address in the header of a SIP message. Folks at the meeting
>> concluded that the P-Asserted-Identity header would work quite well
>> (certainly better than a second Contact header). Unfortunately, RFC
>> 3225 defines the P-Asserted-Identity as follows:
>>
>>     A P-Asserted-Identity header field value MUST consist of exactly one
>>     name-addr or addr-spec.  There may be one or two P-Asserted-Identity
>>     values.  If there is one value, it MUST be a sip, sips, or tel URI.
>>     If there are two values, one value MUST be a sip or sips URI and the
>>     other MUST be a tel URI.
>>
>> It's not clear to me why the definition restricts the scheme to sip,
>> sips, or tel. Could someone provide some insight about that? Would
>> things break if we allowed more URI schemes there, in particular the
>> xmpp scheme?
>>
>> Thanks!
>>
>> Peter
>>
>> - --
>> Peter Saint-Andre
>> https://stpeter.im/
>>
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>> iEYEARECAAYFAlEQLSEACgkQNL8k5A2w/vyr8ACfcAqzu+1ceGZxu0qvQLECL4rg
>> 6DIAoMFh0zKEs2sjN1R3yUy6HyJGU2N/
>> =lu3v
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> 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
> 

-- 
https://jitsi.org

From stpeter@stpeter.im  Tue Feb  5 07:56:18 2013
Return-Path: <stpeter@stpeter.im>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC5321F85CC for <dispatch@ietfa.amsl.com>; Tue,  5 Feb 2013 07:56:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.589
X-Spam-Level: 
X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IE2g44o-eT9F for <dispatch@ietfa.amsl.com>; Tue,  5 Feb 2013 07:56:17 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2076321F85BC for <dispatch@ietf.org>; Tue,  5 Feb 2013 07:56:04 -0800 (PST)
Received: from [192.168.1.5] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 821B54060C; Tue,  5 Feb 2013 09:02:42 -0700 (MST)
Message-ID: <51112B93.7070307@stpeter.im>
Date: Tue, 05 Feb 2013 08:56:03 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Gonzalo Salgueiro <gsalguei@cisco.com>
References: <51102D21.10503@stpeter.im> <4108EC5C-3B6B-43FB-8303-B894FEAB4F00@cisco.com>
In-Reply-To: <4108EC5C-3B6B-43FB-8303-B894FEAB4F00@cisco.com>
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: dispatch@ietf.org
Subject: Re: [dispatch] URI schemes in P-Asserted-Identity
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Feb 2013 15:56:18 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2/4/13 8:59 PM, Gonzalo Salgueiro wrote:
> RFC 5876 extends the P-Asserted-Identity header to cover
> unexpected URI schemes (i.e., other than SIP/SIPS/TEL):

Hi Gonzalo,

Thanks for the pointer. I'll read RFC 3325 and RFC 5876 more
thoroughly before replying again, and ponder whether
draft-ivov-xmpp-cusax is a Spec(T) in the sense defined within RFC 3324...

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlERK5MACgkQNL8k5A2w/vzf2QCgs9kapj8fI3CbYcKm+IbhKEl7
7iMAoOwyN+KfOQLUTTPRaiGvEciAXAyI
=/GDN
-----END PGP SIGNATURE-----

From pkyzivat@alum.mit.edu  Tue Feb  5 08:36:16 2013
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4F721F873B for <dispatch@ietfa.amsl.com>; Tue,  5 Feb 2013 08:36:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Level: 
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id op+qlISZOZIY for <dispatch@ietfa.amsl.com>; Tue,  5 Feb 2013 08:36:15 -0800 (PST)
Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id D7CDD21F85C2 for <dispatch@ietf.org>; Tue,  5 Feb 2013 08:35:39 -0800 (PST)
Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta03.westchester.pa.mail.comcast.net with comcast id wbqa1k0051ei1Bg53gbfKq; Tue, 05 Feb 2013 16:35:39 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([155.212.214.60]) by omta24.westchester.pa.mail.comcast.net with comcast id wgZV1k0091JlX8B3kgZXnb; Tue, 05 Feb 2013 16:33:37 +0000
Message-ID: <51112E7B.90908@alum.mit.edu>
Date: Tue, 05 Feb 2013 11:08:27 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Emil Ivov <emcho@jitsi.org>
References: <51102D21.10503@stpeter.im> <51109654.40002@alum.mit.edu> <511116EE.4060705@jitsi.org>
In-Reply-To: <511116EE.4060705@jitsi.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1360082139; bh=vgWFt+G8gXs5tIB/TfAUPYIraUWe49+n7enVBTMpEME=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Mk3yP+uVWaYgc9QanVzCbMgwGltOgn9QX25eC+KvBURHXONCTJTmEOgDpXwXhsWXD 06mud/A9koeP2bLkALd6zT+NytIYz2/Z6ZSqkFVayGOhSVl0RLWfNF5SxkyTFGA6Ey sOtwwp293tiNvUQ4032MxcAGaXfmzLlhXNqe6Z0lwpBGkitNQUUVwfTqgGF0yoWfDu 0umeoyylC/VZHDJhLo9lYUiD7cQ7PzI2mO/f7vTkwmf5fkXI4ypVcZ7IDvYsokP1qO TpJnjwhkuP4pqkKoU7LZ7cJ+31WW/DbysfITJFK8o8+05k5ZVgZUr8Q+znM8++gqdq yf6K/MU1fXB9Q==
Cc: dispatch@ietf.org
Subject: Re: [dispatch] URI schemes in P-Asserted-Identity
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Feb 2013 16:36:16 -0000

On 2/5/13 9:27 AM, Emil Ivov wrote:
> Hey Paul,
>
> On 05.02.13, 00:19, Paul Kyzivat wrote:
>> Not responsive to your specific query, but what places did you consider?
>>
>> Reply-To is a possibility.
>>
>> And while Contact isn't viable for this in most messages, in REGISTER it
>> can work.
>
> Right, but we really need something in the INVITE in order to avoid
> having to look through a roster for an entry or an entry's vCard
> matching the "From" header (which also has security issues).

I wasn't aware of the context of your discussion, but I was assuming 
that REGISTER wasn't what you were looking for.

Reply-To can work here. Neither it nor P-Asserted-Identity are ideal - 
neither have precisely the right semantics. AFAIK Reply-To is present 
only as a carry over from HTTP - I've never heard of it being used. That 
could be viewed as a good thing or a bad thing. P-Asserted-Identity is 
really about identity and authorization, not about addressability. On 
margin I think I like Reply-To better among the two.

	Thanks,
	Paul

> Emil
>>
>> 	Thanks,
>> 	Paul
>>
>> On 2/4/13 4:50 PM, Peter Saint-Andre wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Dear DISPATCHers,
>>>
>>> At the XMPP Summit last week, for various reasons that aren't
>>> particularly relevant here, we talked a bit about how to include an
>>> XMPP address in the header of a SIP message. Folks at the meeting
>>> concluded that the P-Asserted-Identity header would work quite well
>>> (certainly better than a second Contact header). Unfortunately, RFC
>>> 3225 defines the P-Asserted-Identity as follows:
>>>
>>>      A P-Asserted-Identity header field value MUST consist of exactly one
>>>      name-addr or addr-spec.  There may be one or two P-Asserted-Identity
>>>      values.  If there is one value, it MUST be a sip, sips, or tel URI.
>>>      If there are two values, one value MUST be a sip or sips URI and the
>>>      other MUST be a tel URI.
>>>
>>> It's not clear to me why the definition restricts the scheme to sip,
>>> sips, or tel. Could someone provide some insight about that? Would
>>> things break if we allowed more URI schemes there, in particular the
>>> xmpp scheme?
>>>
>>> Thanks!
>>>
>>> Peter
>>>
>>> - --
>>> Peter Saint-Andre
>>> https://stpeter.im/
>>>
>>>
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>>
>>> iEYEARECAAYFAlEQLSEACgkQNL8k5A2w/vyr8ACfcAqzu+1ceGZxu0qvQLECL4rg
>>> 6DIAoMFh0zKEs2sjN1R3yUy6HyJGU2N/
>>> =lu3v
>>> -----END PGP SIGNATURE-----
>>> _______________________________________________
>>> 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 emil@sip-communicator.org  Wed Feb  6 08:24:36 2013
Return-Path: <emil@sip-communicator.org>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D6221F87A4 for <dispatch@ietfa.amsl.com>; Wed,  6 Feb 2013 08:24:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9xYzWLtkarT for <dispatch@ietfa.amsl.com>; Wed,  6 Feb 2013 08:24:35 -0800 (PST)
Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) by ietfa.amsl.com (Postfix) with ESMTP id DE29121F879A for <dispatch@ietf.org>; Wed,  6 Feb 2013 08:24:34 -0800 (PST)
Received: by mail-pa0-f50.google.com with SMTP id fa11so919428pad.9 for <dispatch@ietf.org>; Wed, 06 Feb 2013 08:24:34 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=VH3xQ5bn1vFuWHPA55nf6P5XZ86rVuuG6wXxX0MtEXU=; b=Y2zA3seR864U8ZLC1Rp89a2rqRvrvNtMySpKa39PWHUDurlO37wX/2MfNUsWLNHe8f 5xJ0rR0jHA54WZ7AlInu8QCNjZdO7GSfgUQ7UPyWKWBhixYVaYGxnjETxhm3/HtVsj0Y Eq23GN19eW6pvbRFrfDvq9tS+2Lg5tsGzbypPhXrAoe+cwzD+Q8f54sSIEjXu/ZRXk2h /KmL6kzL1tvGEJz/L05P8GzKFOnXl+8DfrvAY8XcN0KfNRYqmcmjIQoo4GUbI3MsPSUI EE7XEb286Iwt4QiHAV+NCOdzRar8cMUC9eocB6rHL159qfV5du4J1HKeqXQn6i6BUyAq rl0g==
X-Received: by 10.66.85.161 with SMTP id i1mr10567214paz.67.1360167874351; Wed, 06 Feb 2013 08:24:34 -0800 (PST)
Received: from camionet.local (static-155-212-214-60.mas.onecommunications.net. [155.212.214.60]) by mx.google.com with ESMTPS id i6sm38861323paw.19.2013.02.06.08.24.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Feb 2013 08:24:33 -0800 (PST)
Message-ID: <511283BE.2030700@jitsi.org>
Date: Wed, 06 Feb 2013 11:24:30 -0500
From: Emil Ivov <emcho@jitsi.org>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
References: <51102D21.10503@stpeter.im> <51109654.40002@alum.mit.edu> <511116EE.4060705@jitsi.org> <51112E7B.90908@alum.mit.edu>
In-Reply-To: <51112E7B.90908@alum.mit.edu>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQmIVF6TPBgewthvFRrCqprQk8SymlOFI9C67TgBo/cCsYyxRKtBArr34h8xQg+FpWD6QKE8
Cc: dispatch@ietf.org
Subject: Re: [dispatch] URI schemes in P-Asserted-Identity
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Feb 2013 16:24:36 -0000

On 05.02.13, 11:08, Paul Kyzivat wrote:
> On 2/5/13 9:27 AM, Emil Ivov wrote:
>> Hey Paul,
>>
>> On 05.02.13, 00:19, Paul Kyzivat wrote:
>>> Not responsive to your specific query, but what places did you consider?
>>>
>>> Reply-To is a possibility.
>>>
>>> And while Contact isn't viable for this in most messages, in REGISTER it
>>> can work.
>>
>> Right, but we really need something in the INVITE in order to avoid
>> having to look through a roster for an entry or an entry's vCard
>> matching the "From" header (which also has security issues).
> 
> I wasn't aware of the context of your discussion, but I was assuming 
> that REGISTER wasn't what you were looking for.
> 
> Reply-To can work here. Neither it nor P-Asserted-Identity are ideal - 
> neither have precisely the right semantics. AFAIK Reply-To is present 
> only as a carry over from HTTP - I've never heard of it being used.

It definitely sounds like a good backup option so thanks for sending it!

> That 
> could be viewed as a good thing or a bad thing. P-Asserted-Identity is 
> really about identity and authorization, not about addressability.

Well, it could be argued that in CUSAX your XMPP JID _is_ your identity.
That's how people learn about you (in their roster) and that's the
address you would put on a business card. Your SIP AOR is just a thing
you use for making calls.

So in other words P-Asserted-Identity would be telling the other side:
hey this is who I really am.

Emil

> On 
> margin I think I like Reply-To better among the two.
> 
> 	Thanks,
> 	Paul
> 
>> Emil
>>>
>>> 	Thanks,
>>> 	Paul
>>>
>>> On 2/4/13 4:50 PM, Peter Saint-Andre wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Dear DISPATCHers,
>>>>
>>>> At the XMPP Summit last week, for various reasons that aren't
>>>> particularly relevant here, we talked a bit about how to include an
>>>> XMPP address in the header of a SIP message. Folks at the meeting
>>>> concluded that the P-Asserted-Identity header would work quite well
>>>> (certainly better than a second Contact header). Unfortunately, RFC
>>>> 3225 defines the P-Asserted-Identity as follows:
>>>>
>>>>      A P-Asserted-Identity header field value MUST consist of exactly one
>>>>      name-addr or addr-spec.  There may be one or two P-Asserted-Identity
>>>>      values.  If there is one value, it MUST be a sip, sips, or tel URI.
>>>>      If there are two values, one value MUST be a sip or sips URI and the
>>>>      other MUST be a tel URI.
>>>>
>>>> It's not clear to me why the definition restricts the scheme to sip,
>>>> sips, or tel. Could someone provide some insight about that? Would
>>>> things break if we allowed more URI schemes there, in particular the
>>>> xmpp scheme?
>>>>
>>>> Thanks!
>>>>
>>>> Peter
>>>>
>>>> - --
>>>> Peter Saint-Andre
>>>> https://stpeter.im/
>>>>
>>>>
>>>> -----BEGIN PGP SIGNATURE-----
>>>> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
>>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>>>
>>>> iEYEARECAAYFAlEQLSEACgkQNL8k5A2w/vyr8ACfcAqzu+1ceGZxu0qvQLECL4rg
>>>> 6DIAoMFh0zKEs2sjN1R3yUy6HyJGU2N/
>>>> =lu3v
>>>> -----END PGP SIGNATURE-----
>>>> _______________________________________________
>>>> 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
>>>
>>
> 
> 

-- 
https://jitsi.org

From keith.drage@alcatel-lucent.com  Wed Feb  6 08:47:21 2013
Return-Path: <keith.drage@alcatel-lucent.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B16821F8548 for <dispatch@ietfa.amsl.com>; Wed,  6 Feb 2013 08:47:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -107.174
X-Spam-Level: 
X-Spam-Status: No, score=-107.174 tagged_above=-999 required=5 tests=[AWL=-0.925, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFoCAXz5UWye for <dispatch@ietfa.amsl.com>; Wed,  6 Feb 2013 08:47:20 -0800 (PST)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id 611F521F85A2 for <dispatch@ietf.org>; Wed,  6 Feb 2013 08:47:19 -0800 (PST)
Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r16GlFZP011258 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 6 Feb 2013 17:47:16 +0100
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.48]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 6 Feb 2013 17:47:16 +0100
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: Emil Ivov <emcho@jitsi.org>, Paul Kyzivat <pkyzivat@alum.mit.edu>
Date: Wed, 6 Feb 2013 17:47:14 +0100
Thread-Topic: [dispatch] URI schemes in P-Asserted-Identity
Thread-Index: Ac4EhnnF6OZn62OXQ2qpdaG3sEDR+gAApypw
Message-ID: <EDC0A1AE77C57744B664A310A0B23AE20D97134B2B@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
References: <51102D21.10503@stpeter.im> <51109654.40002@alum.mit.edu> <511116EE.4060705@jitsi.org> <51112E7B.90908@alum.mit.edu> <511283BE.2030700@jitsi.org>
In-Reply-To: <511283BE.2030700@jitsi.org>
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-Scanned-By: MIMEDefang 2.69 on 155.132.188.80
Cc: "dispatch@ietf.org" <dispatch@ietf.org>
Subject: Re: [dispatch] URI schemes in P-Asserted-Identity
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Feb 2013 16:47:21 -0000

> So in other words P-Asserted-Identity would be telling the other side:
> hey this is who I really am.
>
No it would be whoever you have established a secure connection with tellin=
g you who they believe the other side is. It is a hop by hop trust model.

P-Preferred-Identity is telling the first entity who you really are, and yo=
u may not be believed.

Keith

> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> Behalf Of Emil Ivov
> Sent: 06 February 2013 16:25
> To: Paul Kyzivat
> Cc: dispatch@ietf.org
> Subject: Re: [dispatch] URI schemes in P-Asserted-Identity
>=20
> On 05.02.13, 11:08, Paul Kyzivat wrote:
> > On 2/5/13 9:27 AM, Emil Ivov wrote:
> >> Hey Paul,
> >>
> >> On 05.02.13, 00:19, Paul Kyzivat wrote:
> >>> Not responsive to your specific query, but what places did you
> consider?
> >>>
> >>> Reply-To is a possibility.
> >>>
> >>> And while Contact isn't viable for this in most messages, in REGISTER
> it
> >>> can work.
> >>
> >> Right, but we really need something in the INVITE in order to avoid
> >> having to look through a roster for an entry or an entry's vCard
> >> matching the "From" header (which also has security issues).
> >
> > I wasn't aware of the context of your discussion, but I was assuming
> > that REGISTER wasn't what you were looking for.
> >
> > Reply-To can work here. Neither it nor P-Asserted-Identity are ideal -
> > neither have precisely the right semantics. AFAIK Reply-To is present
> > only as a carry over from HTTP - I've never heard of it being used.
>=20
> It definitely sounds like a good backup option so thanks for sending it!
>=20
> > That
> > could be viewed as a good thing or a bad thing. P-Asserted-Identity is
> > really about identity and authorization, not about addressability.
>=20
> Well, it could be argued that in CUSAX your XMPP JID _is_ your identity.
> That's how people learn about you (in their roster) and that's the
> address you would put on a business card. Your SIP AOR is just a thing
> you use for making calls.
>=20
> So in other words P-Asserted-Identity would be telling the other side:
> hey this is who I really am.
>=20
> Emil
>=20
> > On
> > margin I think I like Reply-To better among the two.
> >
> > 	Thanks,
> > 	Paul
> >
> >> Emil
> >>>
> >>> 	Thanks,
> >>> 	Paul
> >>>
> >>> On 2/4/13 4:50 PM, Peter Saint-Andre wrote:
> >>>> -----BEGIN PGP SIGNED MESSAGE-----
> >>>> Hash: SHA1
> >>>>
> >>>> Dear DISPATCHers,
> >>>>
> >>>> At the XMPP Summit last week, for various reasons that aren't
> >>>> particularly relevant here, we talked a bit about how to include an
> >>>> XMPP address in the header of a SIP message. Folks at the meeting
> >>>> concluded that the P-Asserted-Identity header would work quite well
> >>>> (certainly better than a second Contact header). Unfortunately, RFC
> >>>> 3225 defines the P-Asserted-Identity as follows:
> >>>>
> >>>>      A P-Asserted-Identity header field value MUST consist of exactl=
y
> one
> >>>>      name-addr or addr-spec.  There may be one or two P-Asserted-
> Identity
> >>>>      values.  If there is one value, it MUST be a sip, sips, or tel
> URI.
> >>>>      If there are two values, one value MUST be a sip or sips URI an=
d
> the
> >>>>      other MUST be a tel URI.
> >>>>
> >>>> It's not clear to me why the definition restricts the scheme to sip,
> >>>> sips, or tel. Could someone provide some insight about that? Would
> >>>> things break if we allowed more URI schemes there, in particular the
> >>>> xmpp scheme?
> >>>>
> >>>> Thanks!
> >>>>
> >>>> Peter
> >>>>
> >>>> - --
> >>>> Peter Saint-Andre
> >>>> https://stpeter.im/
> >>>>
> >>>>
> >>>> -----BEGIN PGP SIGNATURE-----
> >>>> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> >>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >>>>
> >>>> iEYEARECAAYFAlEQLSEACgkQNL8k5A2w/vyr8ACfcAqzu+1ceGZxu0qvQLECL4rg
> >>>> 6DIAoMFh0zKEs2sjN1R3yUy6HyJGU2N/
> >>>> =3Dlu3v
> >>>> -----END PGP SIGNATURE-----
> >>>> _______________________________________________
> >>>> 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
> --
> https://jitsi.org
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

From worley@shell01.TheWorld.com  Wed Feb  6 09:13:12 2013
Return-Path: <worley@shell01.TheWorld.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76BA621F8633 for <dispatch@ietfa.amsl.com>; Wed,  6 Feb 2013 09:13:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.647
X-Spam-Level: 
X-Spam-Status: No, score=-2.647 tagged_above=-999 required=5 tests=[AWL=0.333,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwbrXkFYuRCH for <dispatch@ietfa.amsl.com>; Wed,  6 Feb 2013 09:13:10 -0800 (PST)
Received: from TheWorld.com (pcls4.std.com [192.74.137.144]) by ietfa.amsl.com (Postfix) with ESMTP id 566F121F8681 for <dispatch@ietf.org>; Wed,  6 Feb 2013 09:13:07 -0800 (PST)
Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r16HCv3C024102; Wed, 6 Feb 2013 12:12:59 -0500
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r16HCuxf1313741; Wed, 6 Feb 2013 12:12:57 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r16HCspL1309432; Wed, 6 Feb 2013 12:12:54 -0500 (EST)
Date: Wed, 6 Feb 2013 12:12:54 -0500 (EST)
Message-Id: <201302061712.r16HCspL1309432@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: Peter Saint-Andre <stpeter@stpeter.im>
In-reply-to: <51112B93.7070307@stpeter.im>
References: <51102D21.10503@stpeter.im> <4108EC5C-3B6B-43FB-8303-B894FEAB4F00@cisco.com> <51112B93.7070307@stpeter.im>
Cc: dispatch@ietf.org
Subject: Re: [dispatch] URI schemes in P-Asserted-Identity
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Feb 2013 17:13:12 -0000

> From: Peter Saint-Andre <stpeter@stpeter.im>
> 
> At the XMPP Summit last week, for various reasons that aren't
> particularly relevant here, we talked a bit about how to include an
> XMPP address in the header of a SIP message. Folks at the meeting
> concluded that the P-Asserted-Identity header would work quite well
> (certainly better than a second Contact header).

What is the semantics of the usage?  That determines where to put the
XMPP URI.  I can't imagine a single meaning which could justify use in
either Contact and P-Asserted-Identity.

Dale

From mary.ietf.barnes@gmail.com  Thu Feb  7 10:28:02 2013
Return-Path: <mary.ietf.barnes@gmail.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4BC21F8584 for <dispatch@ietfa.amsl.com>; Thu,  7 Feb 2013 10:28:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.577
X-Spam-Level: 
X-Spam-Status: No, score=-103.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iw9HVnUFI81d for <dispatch@ietfa.amsl.com>; Thu,  7 Feb 2013 10:28:01 -0800 (PST)
Received: from mail-qe0-f42.google.com (mail-qe0-f42.google.com [209.85.128.42]) by ietfa.amsl.com (Postfix) with ESMTP id 683B421F855D for <dispatch@ietf.org>; Thu,  7 Feb 2013 10:28:01 -0800 (PST)
Received: by mail-qe0-f42.google.com with SMTP id 2so1341708qeb.15 for <dispatch@ietf.org>; Thu, 07 Feb 2013 10:28:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=IlE3VYAUBdkR7LjBaUCSUZ4/FRWYGLMZjdp+cAA5vEI=; b=vxIXCwyuZLuaotD5aqctMB5mHyyQjxEr8TtXa/CJNdjGxyLkvJ5ZjG9wSsnos4+cbR 2Rtgz3NaTaS98KepoLtg+IAlVn6TPgeEFXQX/6NacThTPcMrTrNv8WCgEMHj4QP4R1YE 7Jnsnq0LtNsjixrJMocChgWgkq6/70yOvfAfqyxTPuW8UEVLZ4hWbMVW+jo6yaYxO8IE +7o5l+Xkf9DdEcoVzbr1sXlbgHFqI1vwvuf0oSKhfn+w3ZuY3VyhCCZhxiadJ0Y/F7ez oyRj0rAVM0nFFYLZoZ0bkoOAcnKMkyjaQXE4KMyogPA3fAdVkCt0iYm/O/+s9QVL+vN8 QSpQ==
MIME-Version: 1.0
X-Received: by 10.224.195.138 with SMTP id ec10mr1093592qab.3.1360261680874; Thu, 07 Feb 2013 10:28:00 -0800 (PST)
Received: by 10.49.131.199 with HTTP; Thu, 7 Feb 2013 10:28:00 -0800 (PST)
Date: Thu, 7 Feb 2013 12:28:00 -0600
Message-ID: <CAHBDyN5jf65Ci11rRsb-ecXLBYkz73yK9QM9rOvcxJmb38SOwQ@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: DISPATCH <dispatch@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Cullen Jennings <fluffy@cisco.com>
Subject: [dispatch] Reminder: IETF-86 Deadlines
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Feb 2013 18:28:02 -0000

Hi all,

Please note that the deadline for agenda requests for the DISPATCH
meeting @ IETF-86 is Monday, February 11, 2013. per the wiki:
http://trac.tools.ietf.org/wg/dispatch/trac/wiki
Charters, etc. are due on Feb 15th, 2013.  The -00 draft deadline is
Feb. 18th, 2013.

At this time, we are anticipating a one hour meeting slot, so the
agenda will be allocated to topics that have already received feedback
on the mailing list.

Thanks,
Mary
DISPATCH WG co-chair

From emil@sip-communicator.org  Thu Feb  7 10:35:17 2013
Return-Path: <emil@sip-communicator.org>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 571CE21F868F for <dispatch@ietfa.amsl.com>; Thu,  7 Feb 2013 10:35:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-K4nlXH+gA7 for <dispatch@ietfa.amsl.com>; Thu,  7 Feb 2013 10:35:16 -0800 (PST)
Received: from mail-da0-f46.google.com (mail-da0-f46.google.com [209.85.210.46]) by ietfa.amsl.com (Postfix) with ESMTP id 4B66121F85EE for <dispatch@ietf.org>; Thu,  7 Feb 2013 10:35:16 -0800 (PST)
Received: by mail-da0-f46.google.com with SMTP id p5so1346380dak.5 for <dispatch@ietf.org>; Thu, 07 Feb 2013 10:35:15 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=uTaunmZuG+GNTkouza1A1UJMAyEvpPTscV+02HNxuEc=; b=FO5zUlie5nbPGCzs0DItG9nzGidvhqIPQ1BNHJkHcms569+6NCsJ3Rwjgl09/CB09N 7J1kWOquwxfNCIfaE6zHXVJP2O52Yfk8UDAb9J9sLgq5bwf7C0Yl4ZCTePMpFTFRQ3oE JlBKxJB8ZQwtGh6FkLZFhjeKQ0YJodn8heryqbeofz0HuzPuunH3NWeyLiFLlxulb5VH 6GhEssnfZVXKujLukXFxrwL9R3fESWsEJLsojLKmHClqJPd0Prnql+ibYpDfadKT/ZtS /ZONg6cbDmxw04b8quWZeBqvSCwlclsj3In9nDNvXF7c6b2jZ4veyAoAb/9d1Ds11mnj o91Q==
X-Received: by 10.66.89.132 with SMTP id bo4mr8230742pab.62.1360262115785; Thu, 07 Feb 2013 10:35:15 -0800 (PST)
Received: from camionet.local (static-155-212-214-60.mas.onecommunications.net. [155.212.214.60]) by mx.google.com with ESMTPS id d8sm47856530pax.23.2013.02.07.10.35.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Feb 2013 10:35:14 -0800 (PST)
Message-ID: <5113F3DE.8040300@jitsi.org>
Date: Thu, 07 Feb 2013 13:35:10 -0500
From: Emil Ivov <emcho@jitsi.org>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: "Dale R. Worley" <worley@ariadne.com>
References: <51102D21.10503@stpeter.im> <4108EC5C-3B6B-43FB-8303-B894FEAB4F00@cisco.com> <51112B93.7070307@stpeter.im> <201302061712.r16HCspL1309432@shell01.TheWorld.com>
In-Reply-To: <201302061712.r16HCspL1309432@shell01.TheWorld.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQlbSzn8e824ElSQPnjlvWJrHIB3FjVONiaXddpLg02ihQL4wKizaXOTXM3j5KakDJjV49cP
Cc: dispatch@ietf.org
Subject: Re: [dispatch] URI schemes in P-Asserted-Identity
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Feb 2013 18:35:17 -0000

Hey,

On 06.02.13, 12:12, Dale R. Worley wrote:
>> From: Peter Saint-Andre <stpeter@stpeter.im>
>>
>> At the XMPP Summit last week, for various reasons that aren't
>> particularly relevant here, we talked a bit about how to include an
>> XMPP address in the header of a SIP message. Folks at the meeting
>> concluded that the P-Asserted-Identity header would work quite well
>> (certainly better than a second Contact header).
> 
> What is the semantics of the usage?  That determines where to put the
> XMPP URI.  I can't imagine a single meaning which could justify use in
> either Contact and P-Asserted-Identity.

We discussed this offline but for the sake of completeness:

The semantics come from draft-ivov-xmpp-cusax. The point is to be able
to discover the XMPP identity (JID) of an incoming SIP request and
potentially match it to an entry in a locally available XMPP roster.

A simple use case is: Bob gets an INVITE from sip:alice@example.com. The
INVITE says that Alice's XMPP identity is xmpp:alice@example.com, so
Bob's agent can now use this to lookup Alice's entry in his XMPP roster
and then show her picture on the call alert window/dialog.

Cheers,
Emil
> 
> Dale
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> 

-- 
https://jitsi.org

From emil@sip-communicator.org  Thu Feb  7 13:09:58 2013
Return-Path: <emil@sip-communicator.org>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD14A21F8870 for <dispatch@ietfa.amsl.com>; Thu,  7 Feb 2013 13:09:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVCOb8GZ90Nx for <dispatch@ietfa.amsl.com>; Thu,  7 Feb 2013 13:09:57 -0800 (PST)
Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by ietfa.amsl.com (Postfix) with ESMTP id F3E4D21F8A1D for <dispatch@ietf.org>; Thu,  7 Feb 2013 13:09:56 -0800 (PST)
Received: by mail-pa0-f46.google.com with SMTP id kp14so1678101pab.33 for <dispatch@ietf.org>; Thu, 07 Feb 2013 13:09:56 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:subject:references:in-reply-to :x-forwarded-message-id:content-type:content-transfer-encoding :x-gm-message-state; bh=5Jm8EF6MNE/7UACZkFtBMTud/fVvVAA7qBG8HEnH2S4=; b=RqP2pDxSVld9N1jwGWL0N/dqdwnlgAF7bhgXCF9Pyd6UJis8Fj8TTzksizojYlxkLt 0a1BjCzzn1D9wOatGvC3DVuoxxFuI55LlEc4vfSRc57Azs5s+glX8fZeNPuk+rA1UpL+ H8f0BUziEXmSWlNafrr6ljtHIx0VB8/yhnmcl46b3YAvPHFtBUvodnetzVts3VP+4XCF zpvoB8PFnb7YSlxDcqjPtKtO1Sh5pdPRgfD+RapeN2MopoDpzQslZq4uY++HhG5nGzEB 3Y1gjWl/4cksHzE4dV5GspDarLo5wNh2RsVI7LrvHnMecqf8cLdpAQAIHyoQbkOX+s2J 5ArQ==
X-Received: by 10.66.73.164 with SMTP id m4mr9712111pav.12.1360271390214; Thu, 07 Feb 2013 13:09:50 -0800 (PST)
Received: from camionet.local (static-155-212-214-60.mas.onecommunications.net. [155.212.214.60]) by mx.google.com with ESMTPS id w2sm43249962pax.22.2013.02.07.13.09.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Feb 2013 13:09:49 -0800 (PST)
Message-ID: <5114181A.8060106@jitsi.org>
Date: Thu, 07 Feb 2013 16:09:46 -0500
From: Emil Ivov <emcho@jitsi.org>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: "dispatch@ietf.org" <dispatch@ietf.org>
References: <20130207210849.18001.1459.idtracker@ietfa.amsl.com>
In-Reply-To: <20130207210849.18001.1459.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20130207210849.18001.1459.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQlbvsPGBZ9fMAWiCt0+baV1s6g/s9+Kv5tetRz9R+YyVyJ8dBQKfGMAjr6kInGB1oL52OYT
Subject: [dispatch] Trickle ICE for SIP
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Feb 2013 21:09:58 -0000

Hey all,

As per the discussion on the MMUSIC/RTCWEB interim in Boston, we are now
resubmitting this draft in dispatch and we are hoping to find a new home
for it.

I suppose it would also be helpful to have some agenda time for it in
Orlando.

Cheers,
Emil


-------- Original Message --------
Subject: New Version Notification for
draft-ivov-dispatch-trickle-ice-sip-00.txt
Date: Thu, 07 Feb 2013 13:08:49 -0800
From: internet-drafts@ietf.org
To: emcho@jitsi.org
CC: enrico.marocco@telecomitalia.it, christer.holmberg@ericsson.com


A new version of I-D, draft-ivov-dispatch-trickle-ice-sip-00.txt
has been successfully submitted by Emil Ivov and posted to the
IETF repository.

Filename:	 draft-ivov-dispatch-trickle-ice-sip
Revision:	 00
Title:		 A Session Initiation Protocol (SIP) usage for Trickle ICE
Creation date:	 2013-02-07
WG ID:		 Individual Submission
Number of pages: 9
URL:
http://www.ietf.org/internet-drafts/draft-ivov-dispatch-trickle-ice-sip-00.txt
Status:
http://datatracker.ietf.org/doc/draft-ivov-dispatch-trickle-ice-sip
Htmlized:
http://tools.ietf.org/html/draft-ivov-dispatch-trickle-ice-sip-00


Abstract:
   The Interactive Connectivity Establishment (ICE) protocol describes a
   Network Address Translator (NAT) traversal for UDP-based multimedia
   sessions established with the offer/answer model.  The ICE extension
   for Incremental Provisioning of Candidates (Trickle ICE) defines a
   mechanism that allows ICE agents to shorten session establishment
   delays by making the candidate gathering and connectivity checking
   phases of ICE non-blocking.

   This document defines usage semantics for Trickle ICE with SIP.





The IETF Secretariat





From lishitao@huawei.com  Thu Feb  7 17:32:50 2013
Return-Path: <lishitao@huawei.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2961F11E80A2 for <dispatch@ietfa.amsl.com>; Thu,  7 Feb 2013 17:32:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcWB4jn0-Wpc for <dispatch@ietfa.amsl.com>; Thu,  7 Feb 2013 17:32:49 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EDCE111E809C for <dispatch@ietf.org>; Thu,  7 Feb 2013 17:32:48 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APN48754; Fri, 08 Feb 2013 01:32:47 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 8 Feb 2013 01:31:47 +0000
Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 8 Feb 2013 09:32:46 +0800
Received: from NKGEML501-MBX.china.huawei.com ([169.254.1.81]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.01.0323.007; Fri, 8 Feb 2013 09:32:23 +0800
From: Lishitao <lishitao@huawei.com>
To: Emil Ivov <emcho@jitsi.org>, "dispatch@ietf.org" <dispatch@ietf.org>
Thread-Topic: [dispatch] Trickle ICE for SIP
Thread-Index: AQHOBXd/TkM5klHbpUKYDvHofaDHaJhvKRxw
Date: Fri, 8 Feb 2013 01:32:22 +0000
Message-ID: <DA165A8A2929C6429CAB403A76B573A523ABEC15@nkgeml501-mbx.china.huawei.com>
References: <20130207210849.18001.1459.idtracker@ietfa.amsl.com> <5114181A.8060106@jitsi.org>
In-Reply-To: <5114181A.8060106@jitsi.org>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.73.75]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [dispatch] Trickle ICE for SIP
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Feb 2013 01:32:50 -0000

Hi Emil

I agree that this topic should discuss in dispatch group. I have submitted =
a related draft several month ago. draft-li-dispatch-ice-trickling-signalli=
ng-00, you can find it at http://datatracker.ietf.org/doc/draft-li-dispatch=
-ice-trickling-signalling/?include_text=3D1.

This draft is discussing some general problems for ICE trickling, and also =
suggests some possible solutions. INFO method is also mentioned in this dra=
ft, seems to be the best one.

I am glad to discuss this topic together with you, and of course hopefully =
we can have some agenda time in Orlando.

Regards
shitao



> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> Behalf Of Emil Ivov
> Sent: Friday, February 08, 2013 5:10 AM
> To: dispatch@ietf.org
> Subject: [dispatch] Trickle ICE for SIP
>=20
> Hey all,
>=20
> As per the discussion on the MMUSIC/RTCWEB interim in Boston, we are now
> resubmitting this draft in dispatch and we are hoping to find a new home
> for it.
>=20
> I suppose it would also be helpful to have some agenda time for it in
> Orlando.
>=20
> Cheers,
> Emil
>=20
>=20
> -------- Original Message --------
> Subject: New Version Notification for
> draft-ivov-dispatch-trickle-ice-sip-00.txt
> Date: Thu, 07 Feb 2013 13:08:49 -0800
> From: internet-drafts@ietf.org
> To: emcho@jitsi.org
> CC: enrico.marocco@telecomitalia.it, christer.holmberg@ericsson.com
>=20
>=20
> A new version of I-D, draft-ivov-dispatch-trickle-ice-sip-00.txt
> has been successfully submitted by Emil Ivov and posted to the
> IETF repository.
>=20
> Filename:	 draft-ivov-dispatch-trickle-ice-sip
> Revision:	 00
> Title:		 A Session Initiation Protocol (SIP) usage for Trickle ICE
> Creation date:	 2013-02-07
> WG ID:		 Individual Submission
> Number of pages: 9
> URL:
> http://www.ietf.org/internet-drafts/draft-ivov-dispatch-trickle-ice-sip-0=
0.txt
> Status:
> http://datatracker.ietf.org/doc/draft-ivov-dispatch-trickle-ice-sip
> Htmlized:
> http://tools.ietf.org/html/draft-ivov-dispatch-trickle-ice-sip-00
>=20
>=20
> Abstract:
>    The Interactive Connectivity Establishment (ICE) protocol describes a
>    Network Address Translator (NAT) traversal for UDP-based multimedia
>    sessions established with the offer/answer model.  The ICE extension
>    for Incremental Provisioning of Candidates (Trickle ICE) defines a
>    mechanism that allows ICE agents to shorten session establishment
>    delays by making the candidate gathering and connectivity checking
>    phases of ICE non-blocking.
>=20
>    This document defines usage semantics for Trickle ICE with SIP.
>=20
>=20
>=20
>=20
>=20
> The IETF Secretariat
>=20
>=20
>=20
>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

From stpeter@stpeter.im  Sun Feb 10 23:35:40 2013
Return-Path: <stpeter@stpeter.im>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B35BC21F89A6 for <dispatch@ietfa.amsl.com>; Sun, 10 Feb 2013 23:35:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.555
X-Spam-Level: 
X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4K49fH7xHMtq for <dispatch@ietfa.amsl.com>; Sun, 10 Feb 2013 23:35:40 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D733F21F8955 for <dispatch@ietf.org>; Sun, 10 Feb 2013 23:35:39 -0800 (PST)
Received: from [192.168.6.135] (unknown [64.134.134.157]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E94234004E; Mon, 11 Feb 2013 00:42:29 -0700 (MST)
Message-ID: <511868C8.7020808@stpeter.im>
Date: Sun, 10 Feb 2013 20:43:04 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Mary Barnes <mary.ietf.barnes@gmail.com>
References: <CAHBDyN5jf65Ci11rRsb-ecXLBYkz73yK9QM9rOvcxJmb38SOwQ@mail.gmail.com>
In-Reply-To: <CAHBDyN5jf65Ci11rRsb-ecXLBYkz73yK9QM9rOvcxJmb38SOwQ@mail.gmail.com>
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: DISPATCH <dispatch@ietf.org>
Subject: Re: [dispatch] Reminder: IETF-86 Deadlines
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Feb 2013 07:35:40 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2/7/13 11:28 AM, Mary Barnes wrote:
> Hi all,
> 
> Please note that the deadline for agenda requests for the DISPATCH 
> meeting @ IETF-86 is Monday, February 11, 2013. per the wiki: 
> http://trac.tools.ietf.org/wg/dispatch/trac/wiki

I would like to propose a coordinated effort to complete a series of
documents on interoperability between SIP and XMPP:

draft-saintandre-sip-xmpp-core
draft-saintandre-sip-xmpp-presence
draft-saintandre-sip-xmpp-im
draft-saintandre-sip-xmpp-chat
draft-saintandre-sip-xmpp-groupchat
draft-saintandre-sip-xmpp-media

Work on these documents began a number of years ago, but I recently
updated several of them based on feedback from implementers and I
think there is now enough energy to quickly finish them in a focused
effort within the RAI area.

Emil Ivov, Enrico Marocco, and I have also been working on a document
(draft-ivov-xmpp-cusax) about dual-stack SIP/XMPP endpoints (using SIP
for audio/video and XMPP for IM/presence), but we have agreement from
one of the RAI ADs to pursue that as an AD-sponsored document.
However, it might be valuable for one of us to describe that work
briefly during the DISPATCH session in Orlando.

> Charters, etc. are due on Feb 15th, 2013.  The -00 draft deadline
> is Feb. 18th, 2013.

I'll send a proposed charter for the SIP-XMPP mapping specs before the
deadline.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRGGjHAAoJEOoGpJErxa2p2IkP/2/amd3SZcz28PG6VD9Sk3P/
LsDN+mlJaWSu1146/kI4U2T05tGdXMkyvbyP0iAUMBKZEfdb6YD8Mcjcj53ToKNm
wKuqAvSc5sgw2LKqXE1Okzxys8OGzJb/n+tgE6f2Mh9b9Gkgl/eHNFRrl0dLAlEz
OT1ZWoHI+2/GGoVOZAUNPvRx43nhDoyxggLmuT8Tf0wxVQaLM07dEKhSSh4FUur6
6Kj2tZIypAAJ3zg3sawSB22No3G50DbO/cGlMn9nCw5gyHXsvg+75izMvwEWI0JI
aOhxL702z3JHecH0E6nEsO9TS2rL3PQpsAKaBFwPfhjrfxRFJGfdJYJ8YiI89+Z3
lgvVvLYNbmLMwB6cpsWo4isRqsrq0+IRJOI0iUMsu121tZYOC81IhQ/ADrvVDfpR
mHWueeSgwonyAm8VuaHMQNOvnvecZBRujSwTiIGOCmUdozcP+JRi1fxv7wwIDldD
bS8bklMZZx5wceja4Wu6ha+i7+/FWY2N/F/Oo8uBbMLHuwuq0egEjArlgQZTGKSO
CHtPjKTR9RURqcm1rAQ72wVqjND7MkL/gPkfju3bnDZfh0S+I/2FWcRwgmSdZVHP
5fcATTdgGrh8uVse6n1DnoNM9Aa4QucDTt33EC7u4PlYIj85OA889pqq55FZF1Bk
MrAIVWBGEtRCEmVmMWy9
=i5iD
-----END PGP SIGNATURE-----

From salvatore.loreto@ericsson.com  Mon Feb 11 05:15:00 2013
Return-Path: <salvatore.loreto@ericsson.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4069121F8585 for <dispatch@ietfa.amsl.com>; Mon, 11 Feb 2013 05:15:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Level: 
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-ZS2+DcZPXd for <dispatch@ietfa.amsl.com>; Mon, 11 Feb 2013 05:14:58 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 625E721F8319 for <dispatch@ietf.org>; Mon, 11 Feb 2013 05:14:54 -0800 (PST)
X-AuditID: c1b4fb30-b7f0d6d000007e61-14-5118eecd57c4
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id E4.46.32353.DCEE8115; Mon, 11 Feb 2013 14:14:53 +0100 (CET)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Mon, 11 Feb 2013 14:14:52 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 341502ACC	for <dispatch@ietf.org>; Mon, 11 Feb 2013 15:14:53 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0878C541A7	for <dispatch@ietf.org>; Mon, 11 Feb 2013 15:14:51 +0200 (EET)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 1AEEF5416A	for <dispatch@ietf.org>; Mon, 11 Feb 2013 15:14:48 +0200 (EET)
Message-ID: <5118EEC9.1090902@ericsson.com>
Date: Mon, 11 Feb 2013 15:14:49 +0200
From: Salvatore Loreto <salvatore.loreto@ericsson.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: dispatch@ietf.org
References: <CAHBDyN5jf65Ci11rRsb-ecXLBYkz73yK9QM9rOvcxJmb38SOwQ@mail.gmail.com> <511868C8.7020808@stpeter.im>
In-Reply-To: <511868C8.7020808@stpeter.im>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrALMWRmVeSWpSXmKPExsUyM+Jvje7ZdxKBBh3PVC2WTlrA6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujIZj95gL5ohVHD22gbWB8Y9QFyMnh4SAicS13S+YIWwxiQv3 1rOB2EICJxkleiZ6QNgbGCXmbGfsYuQCsi8xSvx/cYIFwjnKKHHg2moo5xyjREPDciaQFl4B bYkNs3cxgtgsAqoSnZdPgMXZBMwknj/cArZOVCBZ4uOda6wQ9YISJ2c+YQGxRQREJeavWMQO YgsLGEu8n70G6qQ8idPTj4LFOQW0JLau2Qw2k1nAVuLCnOssELa8xPa3c6DeUZO4em4TM0Sv lkTv2U6mCYwis5Csm4WkfRaS9gWMzKsY2XMTM3PSy803MQJD+eCW3wY7GDfdFzvEKM3BoiTO G+56IUBIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDoyCvvKnGFzZNDqXlzZWHv9ysv+GkpbyO 3+/tCknuT2/P8RY+ZJhQ17xNTUlfS92iSeFp2c+9KcdfZDLoqR2+HBQbWWXiKBlXd6prSrLq 6sDML90rTxU07XrZc1t04ybvLU5b7hj8v+/+4onftZ+3069U1ASdvTQ7P6A3YI9yiP6RWUvE t3r5KbEUZyQaajEXFScCABcSlZszAgAA
Subject: Re: [dispatch] Reminder: IETF-86 Deadlines
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Feb 2013 13:15:00 -0000

I concur that it something worth to discuss and to be done

cheers
Salvatore

On 2/11/13 5:43 AM, Peter Saint-Andre wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2/7/13 11:28 AM, Mary Barnes wrote:
>> Hi all,
>>
>> Please note that the deadline for agenda requests for the DISPATCH
>> meeting @ IETF-86 is Monday, February 11, 2013. per the wiki:
>> http://trac.tools.ietf.org/wg/dispatch/trac/wiki
> I would like to propose a coordinated effort to complete a series of
> documents on interoperability between SIP and XMPP:
>
> draft-saintandre-sip-xmpp-core
> draft-saintandre-sip-xmpp-presence
> draft-saintandre-sip-xmpp-im
> draft-saintandre-sip-xmpp-chat
> draft-saintandre-sip-xmpp-groupchat
> draft-saintandre-sip-xmpp-media
>
> Work on these documents began a number of years ago, but I recently
> updated several of them based on feedback from implementers and I
> think there is now enough energy to quickly finish them in a focused
> effort within the RAI area.
>
> Emil Ivov, Enrico Marocco, and I have also been working on a document
> (draft-ivov-xmpp-cusax) about dual-stack SIP/XMPP endpoints (using SIP
> for audio/video and XMPP for IM/presence), but we have agreement from
> one of the RAI ADs to pursue that as an AD-sponsored document.
> However, it might be valuable for one of us to describe that work
> briefly during the DISPATCH session in Orlando.
>
>> Charters, etc. are due on Feb 15th, 2013.  The -00 draft deadline
>> is Feb. 18th, 2013.
> I'll send a proposed charter for the SIP-XMPP mapping specs before the
> deadline.
>
> Peter
>
> - -- 
> Peter Saint-Andre
> https://stpeter.im/
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJRGGjHAAoJEOoGpJErxa2p2IkP/2/amd3SZcz28PG6VD9Sk3P/
> LsDN+mlJaWSu1146/kI4U2T05tGdXMkyvbyP0iAUMBKZEfdb6YD8Mcjcj53ToKNm
> wKuqAvSc5sgw2LKqXE1Okzxys8OGzJb/n+tgE6f2Mh9b9Gkgl/eHNFRrl0dLAlEz
> OT1ZWoHI+2/GGoVOZAUNPvRx43nhDoyxggLmuT8Tf0wxVQaLM07dEKhSSh4FUur6
> 6Kj2tZIypAAJ3zg3sawSB22No3G50DbO/cGlMn9nCw5gyHXsvg+75izMvwEWI0JI
> aOhxL702z3JHecH0E6nEsO9TS2rL3PQpsAKaBFwPfhjrfxRFJGfdJYJ8YiI89+Z3
> lgvVvLYNbmLMwB6cpsWo4isRqsrq0+IRJOI0iUMsu121tZYOC81IhQ/ADrvVDfpR
> mHWueeSgwonyAm8VuaHMQNOvnvecZBRujSwTiIGOCmUdozcP+JRi1fxv7wwIDldD
> bS8bklMZZx5wceja4Wu6ha+i7+/FWY2N/F/Oo8uBbMLHuwuq0egEjArlgQZTGKSO
> CHtPjKTR9RURqcm1rAQ72wVqjND7MkL/gPkfju3bnDZfh0S+I/2FWcRwgmSdZVHP
> 5fcATTdgGrh8uVse6n1DnoNM9Aa4QucDTt33EC7u4PlYIj85OA889pqq55FZF1Bk
> MrAIVWBGEtRCEmVmMWy9
> =i5iD
> -----END PGP SIGNATURE-----
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch


-- 
Salvatore Loreto, PhD
www.sloreto.com


From dean.willis@softarmor.com  Mon Feb 11 10:47:33 2013
Return-Path: <dean.willis@softarmor.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FCD621F883C for <dispatch@ietfa.amsl.com>; Mon, 11 Feb 2013 10:47:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level: 
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UXyIGCXJtUk for <dispatch@ietfa.amsl.com>; Mon, 11 Feb 2013 10:47:32 -0800 (PST)
Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) by ietfa.amsl.com (Postfix) with ESMTP id 43F8321F87BB for <dispatch@ietf.org>; Mon, 11 Feb 2013 10:47:32 -0800 (PST)
Received: by mail-oa0-f42.google.com with SMTP id i18so6631860oag.1 for <dispatch@ietf.org>; Mon, 11 Feb 2013 10:47:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=yLroNasbR3I01Vrk0zw4lawZaBT+OwLZ9Lxyne7I9yo=; b=R64m43b3Sl0A+iBDrbv8JReToXx+Zz3AWBpl/BPBix/zfkB9THR3xeUxyPTcHgJbHu H6PYt/WlV5e2hpVSb1SaqzzHL4iOq/6JR45lnNYFkYYsQVyZYujPSSTBaEaMFRSWoA/U 6H683wi/3Qv4U3mp8n713Roir7trMBXIuQXiY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=yLroNasbR3I01Vrk0zw4lawZaBT+OwLZ9Lxyne7I9yo=; b=pKvfWIQFBVQFHmx2AzMK728+tZnq72AnAiWTW9mXlBS7ed1lmnZWci13oQcgFzvm5a T9Tvccuen3p0nWALq2GFBFQNBXH8Cgopl34WXP/tAPQW1mkZIdYrhh2PLlfkZOQ3kvBY Fsn5jpCzPCN5kgfZd/W4RefO64EjxLyOf6DjX5zsJFP2k3/JWDYINTJRDKP0QvGkuWL9 ISZb/++o84CA9JxdEqZWwMMHwIy7APf+a+ASYat6nNyr13OX/FccVg+/JQFEKZzU/jHx iWW977bpAxCgwZKoa2O0vb9cwmW7cuUySsy6EvKBKWkzCe9M+fQE8vOlq2nU78MwLTd1 xMwQ==
X-Received: by 10.60.24.162 with SMTP id v2mr11489000oef.96.1360608451805; Mon, 11 Feb 2013 10:47:31 -0800 (PST)
Received: from [192.168.2.114] (cpe-72-181-157-19.tx.res.rr.com. [72.181.157.19]) by mx.google.com with ESMTPS id rn9sm49903136obb.11.2013.02.11.10.47.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Feb 2013 10:47:31 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_ECDD2332-5B82-48BC-B0F2-756315293336"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Dean Willis <dean.willis@softarmor.com>
In-Reply-To: <51102D21.10503@stpeter.im>
Date: Mon, 11 Feb 2013 12:47:16 -0600
Message-Id: <7D58B263-0EA7-4F3C-9274-175B10E9713B@softarmor.com>
References: <51102D21.10503@stpeter.im>
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQlZmzaJryHuVPk1vQmMjFVRJCs3K+p+P3Ez2RwYlBydbHNmJQuWneAVblIf1H3isOCqWGKl
Cc: dispatch@ietf.org
Subject: Re: [dispatch] URI schemes in P-Asserted-Identity
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Feb 2013 18:47:34 -0000

--Apple-Mail=_ECDD2332-5B82-48BC-B0F2-756315293336
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Feb 4, 2013, at 3:50 PM, Peter Saint-Andre <stpeter@stpeter.im> =
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> Dear DISPATCHers,
>=20
> At the XMPP Summit last week, for various reasons that aren't
> particularly relevant here, we talked a bit about how to include an
> XMPP address in the header of a SIP message.=20



IIRC, we meant to use Contact: for alt-protocol references.

RFC 3261 11.2 shows the use of a Contact: field in a response to an =
Options request to indicate an alternate protocol contact:

"Contact header fields MAY be present in a 200 (OK)  response and have =
the same semantics as in a 3xx response.  That is,  they may list a set =
of alternative names and methods of reaching the user."

Example:
      SIP/2.0 200 OK
      Via: SIP/2.0/UDP pc33.atlanta.com;branch=3Dz9hG4bKhjhs8ass877
       ;received=3D192.0.2.4
      To: <sip:carol@chicago.com>;tag=3D93810874
      From: Alice <sip:alice@atlanta.com>;tag=3D1928301774
      Call-ID: a84b4c76e66710
      CSeq: 63104 OPTIONS
      Contact: <sip:carol@chicago.com>
      Contact: <mailto:carol@chicago.com>
      Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
      Accept: application/sdp
      Accept-Encoding: gzip
      Accept-Language: en
      Supported: foo
      Content-Type: application/sdp
      Content-Length: 274

      (SDP not shown)
I suspect that RFC 3261 12.1.2 is overstrict in its restriction of =
Contact in an dialog-initiating request to encode exactly one URI which =
must be SIP or SIPS.  I'm thinking it should say "Exactly one SIP or =
SIPS URI" without restricting additional URIs that might be present.

--
Dean=

--Apple-Mail=_ECDD2332-5B82-48BC-B0F2-756315293336
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On Feb 4, 2013, at 3:50 PM, Peter Saint-Andre &lt;<a =
href=3D"mailto:stpeter@stpeter.im">stpeter@stpeter.im</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite">-----BEGIN PGP SIGNED MESSAGE-----<br>Hash: =
SHA1<br><br>Dear DISPATCHers,<br><br>At the XMPP Summit last week, for =
various reasons that aren't<br>particularly relevant here, we talked a =
bit about how to include an<br>XMPP address in the header of a SIP =
message.&nbsp;</blockquote><br></div><div><br></div><div><br></div><div>II=
RC, we meant to use Contact: for alt-protocol =
references.</div><div><br></div><div>RFC 3261 11.2 shows the use of a =
Contact: field in a response to an Options request to indicate an =
alternate protocol contact:</div><div><br></div><div>"<span =
style=3D"white-space: pre-wrap; ">Contact header fields MAY be present =
in a 200 (OK) </span><span style=3D"white-space: pre-wrap; "> response =
and have the same semantics as in a 3xx response.  That is, </span><span =
style=3D"white-space: pre-wrap; "> they may list a set of alternative =
names and methods of reaching the</span><span style=3D"white-space: =
pre-wrap; "> =
user."</span></div><div><br></div><div>Example:</div><div><pre =
style=3D"word-wrap: break-word; white-space: pre-wrap; ">      SIP/2.0 =
200 OK
      Via: SIP/2.0/UDP <a =
href=3D"http://pc33.atlanta.com">pc33.atlanta.com</a>;branch=3Dz9hG4bKhjhs=
8ass877
       ;received=3D192.0.2.4
      To: &lt;<a =
href=3D"sip:carol@chicago.com">sip:carol@chicago.com</a>&gt;;tag=3D9381087=
4
      From: Alice &lt;<a =
href=3D"sip:alice@atlanta.com">sip:alice@atlanta.com</a>&gt;;tag=3D1928301=
774
      Call-ID: a84b4c76e66710
      CSeq: 63104 OPTIONS
      Contact: &lt;<a =
href=3D"sip:carol@chicago.com">sip:carol@chicago.com</a>&gt;
      Contact: &lt;<a =
href=3D"mailto:carol@chicago.com">mailto:carol@chicago.com</a>&gt;
      Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
      Accept: application/sdp
      Accept-Encoding: gzip
      Accept-Language: en
      Supported: foo
      Content-Type: application/sdp
      Content-Length: 274

      (SDP not shown)</pre><div>I suspect that RFC 3261 12.1.2 is =
overstrict in its restriction of Contact in an dialog-initiating request =
to encode exactly one URI which must be SIP or SIPS. &nbsp;I'm thinking =
it should say "Exactly one SIP or SIPS URI" without restricting =
additional URIs that might be =
present.</div><div><br></div><div>--</div><div>Dean</div></div></body></ht=
ml>=

--Apple-Mail=_ECDD2332-5B82-48BC-B0F2-756315293336--

From pkyzivat@alum.mit.edu  Mon Feb 11 13:27:18 2013
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4FD21F8ACA for <dispatch@ietfa.amsl.com>; Mon, 11 Feb 2013 13:27:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.357
X-Spam-Level: 
X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[AWL=0.080,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDX6-7tOrliJ for <dispatch@ietfa.amsl.com>; Mon, 11 Feb 2013 13:27:18 -0800 (PST)
Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id E2C6521F8ABD for <dispatch@ietf.org>; Mon, 11 Feb 2013 13:27:15 -0800 (PST)
Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta04.westchester.pa.mail.comcast.net with comcast id z0yU1k0030xGWP8549TFPv; Mon, 11 Feb 2013 21:27:15 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id z9TE1k00m3ZTu2S3Y9TE62; Mon, 11 Feb 2013 21:27:15 +0000
Message-ID: <51196232.7080109@alum.mit.edu>
Date: Mon, 11 Feb 2013 16:27:14 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: dispatch@ietf.org
References: <51102D21.10503@stpeter.im> <7D58B263-0EA7-4F3C-9274-175B10E9713B@softarmor.com>
In-Reply-To: <7D58B263-0EA7-4F3C-9274-175B10E9713B@softarmor.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1360618035; bh=QPggMvPxPJendLG/MPhqfjyoo0lx2dCdIXG7nx/vSyU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=BgiuDq57iNxsk3lhHs6rJxy5dVRYlvIxFrsKQS6Xc1HNgnmG6lFuVwjOedOzmOpzm mkfdzyuMAJPT08DyMLuJzczmrRRUtsNJFlRbl3Qi9AVH8LS/ql7v6sfpEfILUR3qjC vvn9kBN585BK63Svwm5XLkwrk1PqJN1zFsC1Wf2Ogodq5Sf/qmSzLR3lIIWebNp2tH 0WtRF0xxDNLcPJx44APh463HiTRjjHrqexMYK1oFCXBXbtb3XNd7w3ARm0fo5IXrCZ KT0e9l/zaZhrMetxs8n1AVJAtuGCMBbue5aY7IfDwRhuk3QA13IFR/B53v43/JjpuD k0B+RYT6P9PjQ==
Subject: Re: [dispatch] URI schemes in P-Asserted-Identity
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Feb 2013 21:27:18 -0000

On 2/11/13 1:47 PM, Dean Willis wrote:

> I suspect that RFC 3261 12.1.2 is overstrict in its restriction of
> Contact in an dialog-initiating request to encode exactly one URI which
> must be SIP or SIPS.  I'm thinking it should say "Exactly one SIP or
> SIPS URI" without restricting additional URIs that might be present.

Hmm. Interesting idea.

Regardless of how interesting it is, I think it won't fly well as an 
extension now. I'm pretty certain that many (most/all) implementations 
would barf on this usage in an INVITE or other dialog establishing request.

IMO there needs to be a clear separation between what is to be used to 
establish the dialog, and what could be used to communicate *outside* of 
this dialog.

	Thanks,
	Paul


From worley@shell01.TheWorld.com  Wed Feb 13 05:47:04 2013
Return-Path: <worley@shell01.TheWorld.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9915D21F86F2 for <dispatch@ietfa.amsl.com>; Wed, 13 Feb 2013 05:47:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.716
X-Spam-Level: 
X-Spam-Status: No, score=-2.716 tagged_above=-999 required=5 tests=[AWL=0.264,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46tYBm0Dm91h for <dispatch@ietfa.amsl.com>; Wed, 13 Feb 2013 05:47:03 -0800 (PST)
Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id DD2C221F86F0 for <dispatch@ietf.org>; Wed, 13 Feb 2013 05:47:02 -0800 (PST)
Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1DDk121024611 for <dispatch@ietf.org>; Wed, 13 Feb 2013 08:46:04 -0500
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r1DDk0t71786382 for <dispatch@ietf.org>; Wed, 13 Feb 2013 08:46:00 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1DDjwOa1783885; Wed, 13 Feb 2013 08:45:58 -0500 (EST)
Date: Wed, 13 Feb 2013 08:45:58 -0500 (EST)
Message-Id: <201302131345.r1DDjwOa1783885@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: dispatch@ietf.org
In-reply-to: <7D58B263-0EA7-4F3C-9274-175B10E9713B@softarmor.com> (dean.willis@softarmor.com)
References: <51102D21.10503@stpeter.im> <7D58B263-0EA7-4F3C-9274-175B10E9713B@softarmor.com>
Subject: Re: [dispatch] URI schemes in P-Asserted-Identity
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Feb 2013 13:47:04 -0000

> From: Dean Willis <dean.willis@softarmor.com>
> 
> IIRC, we meant to use Contact: for alt-protocol references.
> 
> RFC 3261 11.2 shows the use of a Contact: field in a response to an
> Options request to indicate an alternate protocol contact:
> 
> "Contact header fields MAY be present in a 200 (OK)  response and
> have the same semantics as in a 3xx response.  That is,  they may
> list a set of alternative names and methods of reaching the user."

> I suspect that RFC 3261 12.1.2 is overstrict in its restriction of
> Contact in an dialog-initiating request to encode exactly one URI
> which must be SIP or SIPS.  I'm thinking it should say "Exactly one
> SIP or SIPS URI" without restricting additional URIs that might be
> present.

I agree with Paul here.

The difficulty with Contact is that it has two distinctly different
uses.  One use is to indicate "You can contact this AOR here."  That's
its purpose in 3xx responses and 2xx responses to OPTIONS.  The other
use is, "This is the routing address for this endpoint, for this
dialog."  That's its purpose in INVITE and 2xx responses to INVITEs.

As far as I can tell, this unspoken distinction was well-established
by the time RFC 3261 was approved.

Dale

From gonzalo.camarillo@ericsson.com  Wed Feb 13 09:00:40 2013
Return-Path: <gonzalo.camarillo@ericsson.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8BB21F8844 for <dispatch@ietfa.amsl.com>; Wed, 13 Feb 2013 09:00:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.194
X-Spam-Level: 
X-Spam-Status: No, score=-106.194 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkopaivxOz6p for <dispatch@ietfa.amsl.com>; Wed, 13 Feb 2013 09:00:38 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 04D9D21F8842 for <dispatch@ietf.org>; Wed, 13 Feb 2013 09:00:28 -0800 (PST)
X-AuditID: c1b4fb30-b7f0d6d000007e61-4f-511bc6aa845f
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id F8.8F.32353.AA6CB115; Wed, 13 Feb 2013 18:00:27 +0100 (CET)
Received: from [131.160.126.60] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Wed, 13 Feb 2013 18:00:26 +0100
Message-ID: <511BC6A9.8070700@ericsson.com>
Date: Wed, 13 Feb 2013 19:00:25 +0200
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: R.Jesske@telekom.de
References: <580BEA5E3B99744AB1F5BFF5E9A3C67D15C2188307@HE111648.emea1.cds.t-internal.com>
In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D15C2188307@HE111648.emea1.cds.t-internal.com>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3Rnf1MelAg6n7uS2WTlrAatF0p4vN gcljyZKfTB5tLxUCmKK4bFJSczLLUov07RK4MlrXPWUs2MZf0bXwEFsD43qeLkZODgkBE4mJ 946xQNhiEhfurWfrYuTiEBI4ySix9/tWRghnDaPE02vXgao4OHgFtCX2fPQEaWARUJXY29TN CGKzCVhIbLl1H2yQqECUxPurTcwgNq+AoMTJmU/A4iIC4hJ9D5cwgdjMAqISM5/uBusVFrCU 2LH4DZgtBNTbcaMVrIZTIFri/dZTjBDHSUosmtbJAtFrIHFk0RxWCFteonnrbGaIXm2J5c9a WCYwCs1CsnoWkpZZSFoWMDKvYmTPTczMSS8338QIDNSDW34b7GDcdF/sEKM0B4uSOG+464UA IYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYyM9dVP1Pf6SXSZLr9482Lwko0zzv3N4lyif/+v z9X3kQE1Am7OxgYbH7I17XVzDfCTOHYp6P2RXLEZXkbi6V/C/1d9qwp65191dZUHh/9Hr9Wp 58oWBfhxyUj/CHeSzea9nV9jsiyguHOp9eSYkJsCM7rabk6N+JuTdXqj5PmEDt8Xus3yIUos xRmJhlrMRcWJALyneX0iAgAA
Cc: dispatch@ietf.org
Subject: Re: [dispatch] draft-drage-sipping-rfc3455bis-06
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Feb 2013 17:00:40 -0000

Folks,

I have not seen any comments on this document. Before I agree to AD
sponsor it, I would like to get at least a dedicated reviewer to look at
it, mostly to make sure there is nothing controversial in this bis
draft. If you want to volunteer to review this document, please let the
DISPATCH chairs know and send your review directly to this mailing list.

Thanks,

Gonzalo

On 07/12/2012 10:48 AM, R.Jesske@telekom.de wrote:
> Dear all,
> please find attached a link to an updated RFC3455 which is a private
> draft for 3GPP extensions used only within the 3GPP IMS. The draft can
> be found under:
>  
> http://tools.ietf.org/id/draft-drage-sipping-rfc3455bis-06.txt
>  
> Now we would like to proceed the draft towards publication as a private RFC.
> Within Section 10 it is described what changes where done compared to
> the already published RFC3455. 
> Advised by Gonzalo I'm now asking here on the list for comments
> and advice if this is the correct group to look on these extensions.
>  
> Comments are welcome.
>  
> 
> Thank you and Best Regards
> 
> Roland Jesske
> 
> Deutsche Telekom Technik GmbH
> Fixed Mobile Engineering Deutschland
> Roland Jesske
> Heinrich-Hertz-Straße 3-7, 64295 Darmstadt
> +49 6151 58-12766 (Tel.)
> +49 6151 58-13395 (Fax)
> +49 171 8618-445 (Mobil)
> http://www.telekom.com <http://www.telekom.com/>
> 
> Erleben, was verbindet.
> 
> Deutsche Telekom Technik GmbH
> Aufsichtsrat: Dr. Thomas Knoll (Vorsitzender)
> Geschäftsführung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert
> Matheis, Klaus Peren
> Handelsregister: Amtsgericht Bonn HRB 14190
> Sitz der Gesellschaft: Bonn
> USt-IdNr.: DE 814645262
> 
> *Große Veränderungen fangen klein an –Ressourcen schonen und nicht jede
> E-Mail drucken.*
> 
>  
> 
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> 


From atle.monrad@ericsson.com  Thu Feb 14 06:16:33 2013
Return-Path: <atle.monrad@ericsson.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C0721F87DF for <dispatch@ietfa.amsl.com>; Thu, 14 Feb 2013 06:16:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6OhJS0VPYUY for <dispatch@ietfa.amsl.com>; Thu, 14 Feb 2013 06:16:32 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 14C0521F8806 for <dispatch@ietf.org>; Thu, 14 Feb 2013 06:16:30 -0800 (PST)
X-AuditID: c1b4fb30-b7f0d6d000007e61-e0-511cf1bda653
Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 97.74.32353.DB1FC115; Thu, 14 Feb 2013 15:16:29 +0100 (CET)
Received: from ESESSMB203.ericsson.se ([169.254.3.65]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0318.004; Thu, 14 Feb 2013 15:16:29 +0100
From: Atle Monrad <atle.monrad@ericsson.com>
To: Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, "rjsparks@nostrum.com" <rjsparks@nostrum.com>, Richard Barnes <rbarnes@bbn.com>, "dispatch-chairs@tools.ietf.org" <dispatch-chairs@tools.ietf.org>, "R.Jesske@telekom.de" <R.Jesske@telekom.de>
Thread-Topic: [dispatch] draft-drage-sipping-rfc3455bis-06
Thread-Index: AQHOCgusW4yLFCkq5UuCiJN3Q92vfph5YCGg
Date: Thu, 14 Feb 2013 14:16:28 +0000
Message-ID: <7D2F7D7ADBA812449F25F4A69922881C0650CF@ESESSMB203.ericsson.se>
References: <580BEA5E3B99744AB1F5BFF5E9A3C67D15C2188307@HE111648.emea1.cds.t-internal.com> <511BC6A9.8070700@ericsson.com>
In-Reply-To: <511BC6A9.8070700@ericsson.com>
Accept-Language: nb-NO, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.16]
Content-Type: multipart/mixed; boundary="_002_7D2F7D7ADBA812449F25F4A69922881C0650CFESESSMB203ericsso_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLIsWRmVeSWpSXmKPExsUyM+Jvje7ejzKBBlO/GVs0Nexgttj6YjWL xdJJC1gtnjaeZbRoutPFZrFv2gdmi2tzGtkc2D1an+1l9Zh6PtRjyZKfTB6nH+Z4zNr5hMWj 7aWCx5fLn9kC2KO4bFJSczLLUov07RK4Ms7em8ZcsPQTS8W7k5ENjAvusnQxcnJICJhI9Oz8 ywRhi0lcuLeerYuRi0NI4BCjxI5N/5lBEkICixkl/v8TArHZBHQkzv28wwpSJCLwl1Hi54eJ jCAOs8B3oKI9f9lAqoQFLCXetv1kBbFFBKwktt7oYIawjST6f11gBLFZBFQlOqdMBYpzcPAK eEtc31MKsaxGYuqbb2BjOIGWtc5awwJSwiggKzG3iRckzCwgLnHryXyoo0UkHl48zQZhi0q8 fPyPFcJWlNh5tp0Zoj5T4vWPZjCbV0BQ4uTMJywTGEVnIRk1C0nZLCRlEHE9iRtTp7BB2NoS yxa+ZoawvSSevLsL1asjMbH1OusscEhsZZSYtRomoSgxpfsh+wJGzlWM7LmJmTnp5eabGIFR fnDLb4MdjJvuix1ilOZgURLnDXe9ECAkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBUbhrZUBB 2D9Poc9uCvfvnRXbbumtZLuk9SCD09TXlezW3NKZ/0sP5Wv8mn/m6/nZqto2Ivv4Shk57D3f 7syOkr/6zFD+h03nX59FgcXiE7KFg77FznJgeMoS8C/mmuedQ+9CFs+asfySVqDVb4OzK3QO HpkS7W79anbaCqYXSzc2XK4Sdq22UmIpzkg01GIuKk4EANte7gLAAgAA
Cc: "3GPP_TSG_CT_IETF-COORD@LIST.ETSI.ORG" <3GPP_TSG_CT_IETF-COORD@LIST.ETSI.ORG>, "dispatch@ietf.org" <dispatch@ietf.org>
Subject: Re: [dispatch] draft-drage-sipping-rfc3455bis-06
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Feb 2013 14:16:34 -0000

--_002_7D2F7D7ADBA812449F25F4A69922881C0650CFESESSMB203ericsso_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

All

A few words from a 3GPP / IETF coordination POW. This draft has been around=
 in 3GPP for long time. As far as I know, nobody within the 3GPP-community =
see anything controversial in this draft.

I have also provided the most recent version of the draft to the 3GPP-IETF =
mailing list and asked for comments and review. Hopefully a couple of more =
reviewers can help pushing this draft the final mile ;-)
____________

I have read through the draft again and attached is a word-version with a n=
umber of nits. A few of them must be taken onboard, but many are mainly for=
 alignment and of more cosmetic nature if the authors take a minimalistic a=
pproach ...

I do not really have anything major comments, but I in section "4.4.2.2.  P=
roxy behavior", there is some text (marked in green in the attached file) t=
hat to me don't really makes sense. I've removed a few words, but please ch=
eck. Note also that clause "8.  Contributors and Acknowledgements" seems to=
 be from RFC 3455...

As I am no ABNF-expert, don't see lack of comments in this area as proof of=
 flawless text ;-)

thanks
/atle

________________________________=20


Atle Monrad
3GPP CT Chairman
Standardization and Regulation,
Group Function Technology and Portfolio Management=20
Ericsson


-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal=
f Of Gonzalo Camarillo
Sent: 13. februar 2013 18:00
To: R.Jesske@telekom.de
Cc: dispatch@ietf.org
Subject: Re: [dispatch] draft-drage-sipping-rfc3455bis-06

Folks,

I have not seen any comments on this document. Before I agree to AD sponsor=
 it, I would like to get at least a dedicated reviewer to look at it, mostl=
y to make sure there is nothing controversial in this bis draft. If you wan=
t to volunteer to review this document, please let the DISPATCH chairs know=
 and send your review directly to this mailing list.

Thanks,

Gonzalo

On 07/12/2012 10:48 AM, R.Jesske@telekom.de wrote:
> Dear all,
> please find attached a link to an updated RFC3455 which is a private=20
> draft for 3GPP extensions used only within the 3GPP IMS. The draft can=20
> be found under:
> =20
> http://tools.ietf.org/id/draft-drage-sipping-rfc3455bis-06.txt
> =20
> Now we would like to proceed the draft towards publication as a private R=
FC.
> Within Section 10 it is described what changes where done compared to=20
> the already published RFC3455.
> Advised by Gonzalo I'm now asking here on the list for comments and=20
> advice if this is the correct group to look on these extensions.
> =20
> Comments are welcome.
> =20
>=20
> Thank you and Best Regards
>=20
> Roland Jesske
>=20
> Deutsche Telekom Technik GmbH
> Fixed Mobile Engineering Deutschland
> Roland Jesske
> Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt
> +49 6151 58-12766 (Tel.)
> +49 6151 58-13395 (Fax)
> +49 171 8618-445 (Mobil)
> http://www.telekom.com <http://www.telekom.com/>
>=20
> Erleben, was verbindet.
>=20
> Deutsche Telekom Technik GmbH
> Aufsichtsrat: Dr. Thomas Knoll (Vorsitzender)
> Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert=20
> Matheis, Klaus Peren
> Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft:=20
> Bonn
> USt-IdNr.: DE 814645262
>=20
> *Gro=DFe Ver=E4nderungen fangen klein an -Ressourcen schonen und nicht=20
> jede E-Mail drucken.*
>=20
> =20
>=20
>=20
> _______________________________________________
> 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

--_002_7D2F7D7ADBA812449F25F4A69922881C0650CFESESSMB203ericsso_
Content-Type: application/x-zip-compressed; name="draft-rfc3455bis-am.zip"
Content-Description: draft-rfc3455bis-am.zip
Content-Disposition: attachment; filename="draft-rfc3455bis-am.zip";
	size=55362; creation-date="Thu, 14 Feb 2013 14:16:27 GMT";
	modification-date="Thu, 14 Feb 2013 14:16:27 GMT"
Content-Transfer-Encoding: base64

UEsDBBQAAAAIABp2TkJm7rWkstcAAAC2BQAXAAAAZHJhZnQtcmZjMzQ1NWJpcy1hbS5kb2PsvQuU
JNlVIJYzDCCxapD4iF1AS9BCO91SZnb9+jsaMdVd1d2lme4uVVXPIIY2RGVGVcZ0ZkRORGRV1yy7
C2vAy0/ALodj2YuxAAM+GI53F/PR2WXBZ+0jg8GwfFYgBAZj2fxstLssa++AfL/vExH5qeqUEGZC
etOVmfHue+++++6979777vv5/+V1/+t7/tHn/Faj9Lyt8QmNP/vIqxuf5HyHf//Ko/LhtY3G++Hv
R+DPP/vIRz6CX/08fP4FKP8Syi9C+SUovwzlI688H7fPH/xXP9V405e/+rFG448+/Z/zzC7oZP/C
ex9pfGpj94XdF37oj3/ojxuV59WPvb7R/vpHG//zdzao/MI/fqT6kvN85COfNvVvfb6H/nvhsYb5
1/173L+f6UB4u3y/9fceHftvF/79EfgXKVXfP/0bjzbeBgP59m/g90767/0PPtrAvwYf5M+z/PuF
8O+X/+ajjR589b7ferTxMnz+Vvj+sxrVR8f9nm/WJek/5f7oe/rvt37Qr1fGp9bTRz9/L9R7Cv79
BKlf/hfh/8qnV+GUP98vtf8Jpc+zPjqeafD0c3mcJ30Uno7n6+Hf18C/r93/9E9876f8nFkKSm+H
3/Vo4+cvV/ul/f4Q/PvWBtMfPvrev/ht/vfGrz/a+F7n80nxVX4QDq4bhauP4uez4fedBo/zURjV
f/qNjzZ+rGHb3/ymRxvfBv/+Dvz7zyYzAHrGrRelxzJdjnv+EPDx+mkvNca3p3gur4vyv/oof3D/
fezqI43b1x+hf+t+xwd/H1cfn1n4mvsvcm38F6htBmy/8rzyTHpOnbodFYdpdj94Dv4TJ/vBjSwd
DYPZn6fbwVoW7kenNpIiypKoaMHHvWJaNfdZ7XfCIuq3nhl1oqQgQEk36gZ5ERaj/Eqwkeyl2SAs
4jQJ+1NgXWsHN9P+YDfK9k+tPxjGWQQAboVHwdJCE8ri8pT67rOexZ08T5NT016c8my1g7dHeX4/
OjGgtWhU5J1eFOxE/eh+OjgpoNvpQYS4CRYvEDaWTp06tZnFB4D+4GYUduGXM5st/utssP4AJiIH
rOdBkQYFNL8Nw4DPMCNxEdOEBJtZWqSdtG+6dGZ7Y/NsADNGNZazbutGlESZvB1mBXzIe/EQa74Q
dYrgzPKNzc2zdUPqIiW1ukherTweDoE+W9leZ3nl/PndOG8tXDh1anU3L7KwU5zC+ju9OA+6aWc0
ADoKulHeyeLdKA/CII+KIN0LhjLWKePgIfQYIXtx1O/miBf+Ij8bjHKgzt2jmgFi7fFjbAZhP4U1
dhgXPawcZ0E4HPbjTrgb9+PiqBkc9uJOL4hzhNOPB3EBDQHuhwAy7oz6YRZEyUGcpQmOMG/jkKNA
e6ZdDbOI8B8ilIMwi6PiiEY/yoZpDvjA9uOEup/w8ocZ7oUFfTOU7uMomwghTjr9URd5Q6cXZvv4
R5h04WuzKoNwNx0VPrww6IR9wibMzwHAi/L2qVPbtKSxMwXO1a1okNqZK3EQ+CYf7QIOEAnQ3b1R
vx90Um426UQGjQhgmKUHMdMqAL96bTO4eIm6SX9eblMrfgOMqEPhe0o20rnIvBysJzDmKMrgLepq
mN8PrqcZdODMxvrO9bNtXFdAVITBFKpmwT4y0TwYAN8J+3kadGOg0nh3VFBfq02G5cHr1PahInao
M8oypGnzFsKRUQCeoOFeUQyvnDvXDQHDsCDuR1kb5n2vnWb752gd5ecEyLnxyKAXnX4dhP24y7QE
g3kQD0YD7E0ePwgGaVL0iE4RyzjS3SgYDaH9qNsMsmjYDzv4F9RNd/O0HxW8ZhhBztALAHBEdBIP
Ihj2Bs18nMDKyFJYsLheYQkANVa7nENDexEMqkOIBWqEaQIZgcwnDToxzUo0kEZhghKsc5oEHlAU
NLAPAiJvnx5LhIcxEF1EgiQAQnclCaDxWjo8yuL9XoEUEEMnEIz98kznLHHZAOkk2MlGeUHYomUG
SwKpNe4CGmJYuV3smlCz4WHhqOilGVLDKvSDoOKY8yg7iLrtGqbHi4Z4DmDAWQdE0qYbj+fBM9F+
SOtz0y6dragPCxpIE+rSy2s6T8QWhcYKhBBFlr6Ag4GgiFrIEs4iYqO9PexByjwGaQLIBmTNKVIV
mgGsqrDfDtxHhPUUWf38JtQPFu+dGqNuIJsNgHsHKsVcIaaPkYIiAeGr4WgX2TAxM2VOilPo52Y/
CoH+suggjg5xTPCh66KmA6sH+ROwcJ7FIyN+gqN0lOnU4UzAKIEZdArqE/Ew+GYI+KJFkFYav5Z2
I/jPYJgmtGKiByTxgGD2snTgvx4MYGos0wZJFw9AwBB5Xd1eC57hmQoKAII91U4Sg92OqFPBSpum
C3uDKgeRLVGLSyo4EmQZxHhRW8ORoBQ4DLMsTEDihIQZrwXSIWp7VEfLyFSA3xch1DRLm8bs0yYu
d/yGF1/CnJY6SdOa96ApeGUA9CAT3YfeHYRxP9ztR8C3gMFFhioQyiIR4MIl4cK8Vs+A5MfuZGm/
T2sEfumYtQ59zNNBpNTjsSMcSJICjwZBCLIBsBOVFyR9ZEhAAiA500MCkXYBVUyYJJnyEegHls+B
WgjIt7BAvibdMAMlAKaqg6wNoTwnU5PuIi5ZgAeAjRdHuDJl9So1jRmukoM/Yrc3ebNMizJsWAM8
jqiLUKZ3uknUBasXtbX4gIU0DT8mqAhFAHeyCCXOTECjB51oSPhlzYXWSUHizV3/IRJ3sHX9mogR
WG1J3kdMxTho+KYfJvsjYEQ5CxZGDdQBTQHJrX1q6jMfPrh0b658cIeWA2AZFxFxNloL0L87oMAB
TQarrrYaBO0Z/xecR0BLxMuSA5R31I1p1cYBWpYeETOeVmUSoBX4g5Dkb4Gusxo9FYgFhKAWjTa+
CpvGDuot3dbdrQ1vHzEeqAJiUAjMRzZuhiNaVrq1Kjek9fXx2p02DqcjF9yO4KTdzZHYRC2ePDwP
0EVFzZJBzTWgIqiHW6Sj1sbabH0MLtkeLc2ImlJDc8INLBOnJzW4mTi+GkAr7WWDm2dBsiJSxSIz
qboDaNn2aHkW3JQxMZd2azAxDaoBtKKYWLELqIMM21YFtXL6jC1etD1aqcHE9nRMnKzdS267detl
PFQf0GXFxHm7XmTH3bo+Skg5a612u7hlAQkhMKo9WlqwPTp/MkxU25XWbPM17S667datjumjYUBm
dVyoYuJZ0FKh22NH7/VoxfbowiyYqDY0hnNMbremJ+fdnkzCjT++KqALLqBlDxAqKnHRitN4an8A
0CUX0IoLKMNtIKzduBNPkFg+IKTZ66hW9YPtI9DZH0yvWAEkC4BpdpygyRn6bICWCNAYrpxP7acF
tNyezCqn9MoCWmlP4TSTe7W8oIDOt+sXamVJ1QNcXlRAF3xAPv1Nx9HykgK6iItVdcgEdDMxmE6o
7AEikYK9gY3oKMP1CeoiavVZeCyNcVlW/YV6OppWvQ5QPR1NBVAFNJaOpoEoAxpPR1OBEKDzCmg6
HU0GdEEB1dPR1J74gJCGNlZvr55w6gnQxfntsJbnu8OCr9CmYIwUacaGlNXO/SQ9BNraj9iiMW2A
AOgyS7Mo6cYPrgSA9gQ3pLSJx70rOkmmYW2ZOPfiQtsBtD0aDMKM/AUdgbkL1BVFSQBbeDK2FgHa
891pWRGuBKBgyV0r1TPdwaG2FhYm9Ghl0QBaqgLCugxjcdrQVpYMoOU6QIsCaGkqoGUDaKUO0JIA
Wj4GoPN1gJYF0MpUQCsG0IU6QCsCaOr0O4Au1gHSCbswG6BFmPotNcfPyvTrABEoAHab/UsH0fHB
OoCAjowD+figGNAqm+Efn6j+TgF0fpI9yD7z4Vsr9+bKt8bagMRqGxHEyAJCezbbeMnq61sF70dB
J8rQFIm1wzwfDYbM5bNoP8zI1Sh+xKBIh2k/3T9qBv04uY9DU/rEFpE+++khm+D64RGwpabxdoiF
lzV9qx4jEZAHg7cWeeT2gDqURcE+eXT7/aPg9p2dYHVz85mNa6tXn1lXI7ZxDqKxMDjspf2IwSGA
QYScM84HLh56ETob8T/dKI/3E3bs5kCU+R57krPoxRFMsPEplHAY8dRtReyLOO+9j64WRMjzwGtX
Fi4t38MNDQJhh3IUo50ySFIdWEt8wUGe9slWHhzCSIb9MEnQaXeIvcXqcZKP9vZgH4Azlw5FHIfk
EouyOCI3LOLAWNPRVZeg1leQk3iPvdDSrG0OKCKJoq54CKk99DGmFvf+uylZa48ipJ9ilEW82+AK
3QhoqZ87XmiXpsjsb37KaViWUpto485Hfa5Xsp2MdnNxieD2MAoRk1oTjbwli6ZZDPejIzRZd/Pg
9K272zunm/wv0hL+vbX+jrsbW+tr+Pf2zdVnnjF/8BsIBj7fufuMvIJ/2crX7ty6tX57jevfWn3n
aSb503c2dzbu3F595rSuOYRjPYkZzc1uhCbsKBtm5JAtu4CQfpYWFy/fw+G5dlYztp1enHWDmUI6
gh6Az4FeyVlF65X6hJgeSrgFx1JAxyIgGHLW8PqNQnQSHybBAOYmHkTdGIM4cuYuzDgK8kYk5Moi
10AeQBO37PvbMH9HOWzwgzMbt7bRT39GaYZp2wYwiKcSXgNkCkFFXcENEVLQCRPE3l46ouAHWo2E
lO1gabm9tHQpeH5nm/+6R2Og5Yq/rsB3l+lX+use9IR+A6I2TpHC+C2ErcG/mxu3b5hgAQkpoCCD
6EGck5sWX/b8kMYbF/YHKXqbgWEj6D3R6kMibF55Jf6D1X2WsmdxskurhyNEjvS1Lnu8wm43ZtgI
wm8J8ATrIMrUg48dZlNLnGs8ivLhSgcsM6PYBBknE2qYWB4snnridIdMYjZwRCOXBJ1emBtuNY3P
LsqrLBjbZRTFHL2AETDQKnxwWQg0jZte4rHeCA6FjWqUD/NH6AtjFH1Ylr+CsFHWp9YoRJf0GMFw
bB76B7vpkOVXfcCTxjk5ErlIqSOsvwDwtDRcgLbuMThizBI3JQYhn3UiX/aYB65AXLLKNHcjkM3I
SCb6WfDnmXwn1kNs+sCOUhTBoDlgjE1IlAa8bZQlNuwrNEADAEozyzEtXIvmUzDTSvdaWdQBooUu
PYeyZS9OIrXk+v6WuWlr5+errQW+f6PJPFaUiCXYQ5258/RZCjpIKRYA6CnYWr+xsb2zvkU0Aby4
rfx+sr+HdKphmhUU9KD4tjUQCqJcl+FEhFPPV5PSdFF8E/1hQtQw/CXumNiDjAQNkkIn5CVPpI7D
zmiikWaQMEdo4MRts0MuEmCQe+IAWyIYQl5JtbfcIxKoTn8pnOOlKEsDR9AgAtpoXh2FHCHCTBlQ
T6g5QxpLLXxRZakrPg2fJd5kx6wcY6Q23NANGkRMtGuWDzMjHSbWv7t6Db9FcwTQzTClVTQiK9Pe
iBg8hiShwsPtKiIL4hjMg5kRYi+bpAAmR0132hw5JTNnh4a0OAbZTB4m0q7p6OigKYfII5sOjWWk
QESkOhqyG4PMgJhVL+zvqdAjhIH2k/RZN6/0CKFosCaMBiYzKXSJ7ZS8RgLTLLE4d9YBdQemeZf0
ClkmRJSgR0mzwh1T7I1Lph3UPY9wbYteJevDYgDXziFSCvTBTovQrRvGmocDwgxTCv61UWhUHwjp
PAbZ1Qx6sNcChbDJTeFMsWCj3lBQWhacQVUZVGLFtdOZApTBvbNm8LiwjhQ7k6ZEFSRa0NDhQRRy
NEyIigSQB5L6kUeLgLKbtrNxzi8S6VXeRSxReAz3JO/ARqcuCmyVVgdq8kSJsDGkfUZkEV8eBGLe
TrXgFbuNgA5DVBEwTrEXde7jHogmaAJOeJotwCZGpKBe2gVNLmXM1Gw9bWyMvycAudXebzdl3dNs
Axl3a6SBCbW1tE1ClMj7IOyPmPXT6h3be6RyDRILyQYacsybu1iE1KtSigIxNarNVK90xnRUI2cd
iVNaVRGuq429ep4gm04P2YIn2HJZhgITAMoWBwrFrDTCprUfv8RUyMrNDG75mVSfadIYV7vVNGM2
CZiIbLOpx+bwF8OEYyM9Na5NBDkHpxZxJBsPkalAcgin0w9j2FtBO24vckD9fdaYrqMx2v2NgkOF
phik9gfwyvy84GkBxIwyXA+0w+d15gapa9dRUJmwWexsNkPngz5MH+wSoTHgqDQMNRvZHtHLcU6E
JyGxGrlJmi5VQ97rNJNyS9ABK23x/wlH0oU5rZFE3KQwBSSuxd5SjzJZ9NEDnNcYNwnQf1ilLeqf
XeS8euZqRLwwX7X0+OFEhuwdGQK8QLXNKYshEWEKvAThzKL0cmseGOZuPAnDdDjqWz0vNEyGhSoR
WeYxPumCoz4wB7f6LjMgZ4T5aGgV6slDNIqcKhEF0VHMGqvHz0ZZTAwsKbVGdilGqq6iaWg1RoUK
k6YVQPa+MZgNd3MyGaLoTqoNkb4WJ13SLa1Kk6TuYGAk8O7jLFzVEtJW8iKPLwZ8dkdI5sIu7q7y
3oLkLso5mIEIDcHh9NG6I+XJExLiLeSYkbJK2DF0XoKqTKYq5+qhBhQ07XBA5gmqx8e5kg1urEpK
YNssoxrCNtsfS8wp7HfVtFqzc66StKOjczukJoGURItPrUKAcFQR1UU1hv1RN8kWQZCQwonz1Gsh
hB4RDv6WTvog3Nr0CQ8piXWFFMMmETibfgHzSWHm1WBRR+erbf4AVYVwtI8U7e+OXODqYlXsAtJV
HQM1TnCi0ri8oaCxIiDqa4VWaC/ibbhxpdeqX2U0nkz9Em4NQI6rfq2WjyBskE0VLX/LSxcW7zXH
rBL3aMCU3ri7ccYcbLnpS9xGKIqr5Bwbr4Mdw1nDZ5Zq+YzBtrAbxyqFhClcRw5PkE8xfgk/Vuaw
qWHuhqT8cdDiMcgeZ0opt++IlthsEGT3JoJAJngmOVA/NZ5kZfSNFa7UKO0wS4K1kw4GYSuPYE0q
v/BkLW+9pwpbmUpySNmZzFQ3R/GLhv08mlTRq2VtCnSYQ46uOVtr2x+mXQeLWRWLeQ+FKZ9lmJ/i
dnG+iht8FRawwHq0hWX6X66lf+C8D9QnDBQ2iAapRZiYUpGND7WmV9GITvibqiEgrAkTg0cKQ/gv
HSQ5wnXQjfBMYUW4Gv9vRsd6SBlhZmK5ijQxtP0n0wrunY6UirxNKY56tiB2WXjcgFhEVGcNp9QF
gjkaxh0yaYlvPAk2bj+7sbNu+UKUtDJg4ZFsOJF9gpxQm0dlhdUqrji+LQZIJCl8yRiDuPex6oq+
Qfju6rY9tGhWYnnpNNWikkcUN+AwURpY+f2cV0ucHMRFaBzSKsnOkP/1QQhKUMQv4u4HAYmJKo/R
TxgmUTrKAXujnA45oSbDh5lku3VXbKr0yy6+hc4Q+UV9JKobOn2BLqjz8WzbogEbHwnz8MzHAoe4
h42a6pKu2qEIhHDUjfEs3Qh6FvaBPHiLCf1pwpRSMBZ8kRpFEXuurlLtYAlhQrjSUWZvd3M0s7nx
AxNdpDSifdw+kw6IEHT+DJLOVObuLNEik8SRmZ02eehZS8FggE5kJlB24tpY7WzQPMEPYWUG4UvS
HGSBCFSkNcfyYqmEmqGgEydIoWcbRDDaJhrj0haaSyKJzBtTuUJVPOUD4pvGdboXDuL+kQhj1Lok
7AXWYyzmYpgH0PhSWZS1SCjkhHuFkD3jok4y/mrEfpPMgghdtXfUN6sEToo4RuwqlaPzSzeLhERH
deEpdcnuhZSVZq7cBA50LkdKBF0TWBB6SNQGLQ4CY3SrcgdnNZKSwjBdbuAcFXUcmLQHKojHzRwu
g3CMk9kq+MD+YJ4HgOAY97QgIVRLhB4OiNnCZzKpkg1a+ojVTRQD21cPFYdibnuAyyPkvqIzBJkU
m77obLAwe2Yewu81mgkhiDzJoiLMqIr+gORQ441Q5uHyekdIyiH9HI2YwvkVmD04u3ukUNggxuOp
07grfg7dj4SOFi1alJz1NzSG3NSQmHaEsdE0cOJCKJi1CZ6MaJwEcoVXlXzuJBGtBUCkbhvx/fJO
iz0s6twchOj3yh367ZA4J9SUFA9xO1R8bWJX5hAMEqqrfdyU7fdqOyBGXNnvQF/oLWmWXRmgRfBU
U8RHHhcjXtNN7gxH/hx6SURQ5c0tdYa7oPHNT/28NH/108RzKf5ghmGaiyvmiOqOFX3kVNzFGEGY
COA8Xc5I0Y0zikTC8XVkn40n+kFlUGaADy7TGMWwnAsPsyw+EANw0VPlyKw2Xcd2WhSQdaUtGZ3h
GrD4mHK0lDU7s9ArFGD2ofgQIYYYdZOXl3aVgaFIzMcZEWJjTIK/6pVFYQrYbewd4l0PcjP2CFPK
E4Zh0fM8KlCvyfasBC1uYY6yoRszIM/sU+6bm9mlurCFzziaryzAQgm6/BOJLCYcDcJhZWx/hBFn
kziII4AQCkNWX95qwjs/9ZDamEVLLDQT0DhOfMEudRmZ0Qxjz0RVy1vZvFWJxK9HUFjUclsmQXYY
Ok2zLTGsxUBsPWA5TjksxHifMwg4iu0YXx53mvXAqhJ4aHm/0waxI+kGwrNdyePhlbi72JyGI7Go
yetPjcLmEwiIY7SKXuSjRk2TlZFz/SUF57nnx7eOLUlNaNmuSEMX1tpFTLfq2QJsOL4egxgzRylH
OtaaX/OKDIoLYoaYmoTEFedzCFJUI4hj+TY5tY/xNPNuA1sty++2412X1Y8iJd7TIfhWEs3chG3z
pNIYHKWvbj+4G3VC3F2le2oZ9dz95T5JjIlBtPYAtfm2GiR4t6j9DWxoAUkmH5x1yolznMaiIoP2
6F2JgpEFLa7WphOjIK53GPE2Rv2xGY5iDolx1MaVkPYrXQ1HRYq7SrYKOBirXz5kuHMEfV1U207P
i/xD3tRBgvA1ZwQ0Y6y5saRh3QTDcdFst5+Fwx6GQOI+4LC0U3N4o0dBMh2AdyPDCVt5mnEeLDSX
iVRHLiRVzc4jZw+szipKLuX7ugXB72NNMegKCjLZS1c4UxYNy5PSPNTndN0G4ljGbXawuo/YPHN3
9axr+RfNgeJdSXM4s7l41mYImY/GdXnuGhfsiTtRAjugtNomPkB1rVYr2Fw8dcp8d30RKEbiIvD3
t+HPfjWzN0AmKfTQ7qQD7OK5pfZC6fVn4/CK/nTu7tpmsHgZ/movtVeunF+4sPDEbgYipffkS5d7
N1Z2n07CvNfNL5Zg7KRXqDXUAxZbusN+ymm8VAF9UNOqPFGE+0+unL+wtHKpVBsNfK2NtSvBpZXl
S4sXLyxfvHBpZWl54fLlS3k3zLu9hcvlGtvRi1eCxUtLFzyzufsGc+krwVtNr54ymHibETK0QaN8
c5YhEN2p5UBMHPDdOQ5VNh5CbOX60sfB9BVlfPrTp0M5xvTVVaHpW16B6atMhk7f0jvqp2+xPEgz
fRcfYvqeQfdAU9nig6Nz1nOD/MLujav7BjzxiSBC1UWFyyydNcqq6i3Y9OO5b2WqD02o8DjaJdhN
uWkd2TR5SfbRiIe8GqEou65y6mGoRg3ckY86PR50dXNC8tTZJzimazVSpF6sJskflGUosQ619ywJ
TNywNSbFlPoThar6I7tixMNJIlRSiM1T9KdIdqQdkaCOPSaUtI/OSwiHFC/dgAaeNQvtyZNZkkdC
M7Ji/mfJ5cjLgJYDTIO4uVS7oGU2J3fmuKt7aaFueS8sd18I06jcA13fEzA+doELyXMt+eDUo1V+
eflSXlmyJ+XRC4tqolOey6sNcO8b5ZgVuzY2/Na1w7lb3KrVTWyOlV1cvf0NYbg7rnlpF5JtceGj
oF3ANK4Y2lxE2ry7OoU2Lc88LkEu1hLk/sqlvLe4VBY4f+nJerxRtuyL5OjjsjWW4mEQEPy8n/qc
1/EbdEeRKsZ1O3LXPSMhskaPqdvV3JYzrtrxJM2MgYrdUNVY9Zx29xIuxByaFy5b9TrQixDlgmOy
cfYLYw1TngfuOdqTHgh4tQehKQUPXahxzvcNSCwFWZTkHC++1MOdUBe2g8AEztDJzT2S7mwjPuvK
Q/LIcVSf43VGQPWpybhl69VFODX2sJRNZdwhR57FeckwtrFnNQYvTA0613X0nBrzKfcf440QEPoH
8bcBtITMaA+QFlw/T7RHMUmeHbE271vZnu6DumD1io6kPTSODMuuiZwT4FlqScDB47YWvtyjwzPX
zxO/B3h07O0KrzT49hUB/FHjVNKdC68IEvf585ieysKbtoGeZXqf80xcY+UQEoCegzFiSPi1MfRM
Y9ayJ6EIoENghmjbVClAgDRfgRzYCIsaKTRXrWvOSa5PnDqzGt60M/W10kmUQ1ejQDTqCTQ1yqmE
mzBdhHJKUmHc22Um7QAyKoo48azAcfT0CWftEI5G+OxKygSAx8KWqASFlvWA1IXzIAxOhE4Zqnl3
vhf3xSgoxFWK9/HQgBBcjSPdcwfX1lz5FMhJW1lU/ysYJxkYeuZ2Dbuo9yKU1TJ2bQtqrXdbQsFq
zKvjZw+BlCawtJip5+i2oJKXzSHNYJT0RS0sOdhFu2AFZMs1WHNMfX1yEclhjokIaHLJqr20snKP
jGK01EjPQDKJE9ZZR/kYdcNfBHgKkvtJ7n1Mg4WQbRM0LQloEWToNrs/CTc8ZnrZWZemiY5X7Vgd
zzibqAvpGjrpGlTeW16DYXUFesTMepUTRsdGIMMTCu/QqhOhX+OHxgVnvNfb4ofT4Ep0JG2bgBz/
RNFEDBPxymE/HYUJ0neR4MViVaOfEZDrskQyr5q5XHXUAd40fWAko32BDGzOKc1rZaamFDXD8RjN
VFOzfxjD6xNy8EsIha7jNNNtTNQ20LdLh28cBDFxdexxlKm6fF24Ky3VakB5UQklEEOn9qU+9HUK
XbsHP11TpwgWS3i9arioTHwyA9nJTOs2VeWGtzf1I4KISig3f5iL75RJTmWPeNLyquihuzqII1Bk
ohOy6rBuu4cWAeYGtpaCWTHWRqmv/tDE0ASNa9w0kQJlBqDEA8btrlRdc64HNc0mHsthlnEsyvXF
aj4/FW7O+fkDHJm6nIV0ON/qYnBGL+84376oIcqMTFrP7i65vI6EFmfZBjuMX6VEZQnbVaRrS0wC
BSvROKOYYLL0sgRUTWLGlY73Ql9g2ARgTA6xk30Ien5AmhpCOczwGq5u1IfuZd5ZMCeqrk4kwRLm
kCYTxoJBAQiSRHg/CjPyt/QyEvk2Lw3VHupNFHtOQEzbI/00q8upUDo9ZBAu7JLicRDKFHp3GVB5
lsuSiVDGHMeawxw/ks9+DIcMx0UBySit3D2BnEEQ5ehSlm3LbdV9puSdp25w9i09F48aYAev16Hx
7NHpo35flhN8zlOljJ64t7RqMzjg1hxgwDpRNaEgH764yY3HKEGwYSVZGg5oGvezSJNH4YJ0D2NK
Y24PlEZ7Eg4oFy+xooaaNKq9uxT5xKHLfdGqpD2TQWJE6aDydJR1WDXkNGIiFUvDJMZJDIDS/4S0
BdoL856xemJ4ra6qNOH8YKqHkxnT5nckJj8shAXb1YJgUs6VYbCDb7voLPWryUGNcixYjt+S4K/i
18TSEfFTHjPRg0tAmbIytQKEtIFl+yrzYl0V3rgk0D2JtEvVyQvU3MvYdveEClJ7fXe1bQmXTdT7
RCNh/zA8slu7uq7Iyqg5kSdtP5BwTpfUVKXW9EIibeoGkR7SLTs1zV4Xk0KO5ydoKvOYAoDoarew
0+PrBfHAajSg+Gw2eRvJUCU7Op5IXnA1VncMsSg6MSVEospFBRNxXqpqjykgkP1+uktb6VESv4gH
j4kqYAA8QpQEPJQXRylFfmG4E2aFQBVKrlws0vuROYzlEoXlv9VewMwBp49tLj6XhmsJ2Ajsyiqg
PnMSLD1kWlleRkYR2so0zzx1NnvRWI6LHaCnvD+tqVE1GEUao7iXiqcEAXTirDMasORk1j2IMAp8
bjrb/DN+LyoHIVZQSkKLK4usS3Qeq7Arz2VP1qKtPMojK5anB3Foj59EuLPp8zmAXjw04BROBcYY
5se05GTa0iwDCmjXHPgiUSmXbsFalgz+NiGRBnFubMKPzWD16dVmYK/X2Hlm28bKr1KGEzkklUsM
e710GiMf8TEy+UzoihvmzIWqMaXzvAGfEjDD01AZF5tnhRm3SzuW2OOXqRWBFS1BUz+ZZiLrfOsq
68LuPZ77HIwaXnEJKkkDN5iTOhKRVlvmno7hVdutNlrhl5gn0vRbDEB8KLMWDJ2VE2ooek4GStdb
6SfWMiRQ01Y35Rhe06TbFv/Yiyn9R8BXkKzS0XE6zgsaf4u4ZYVLE4MuuzvrqacWL9SaXk2DNhNM
m1V3jJ/OKcdhP91vxXLVMFEy/agtnZF14dlBz5I0kQXVR1oyICWkOBTIJTCcBXjbwmGdSc0aYQ2r
D/jahZ2ebaTQO3vxwHEw7sAxGtL24iwvZA8vPalXGnyWgnsK1AylZ34VBeRxqDQrN6+qlY2Vi606
V5pHHuYlM0ytkbJOrjwUJbDaRJ0EDbwc2RSrgC0/EswL5z47ZtwiU49/VdZkwVl2u4zkkLCeFksV
oePG7ODM0UydhZaRAoIgajVj90XSj2sXmzBIhML6GfBuc+zV65rpDHevZv053ggjLsfiPPAMv1VQ
/iTDXgNtu6Brlfca48aPQ+atorDhnEPdY87QXFHbEM7MWw9xg+L+LWZ1XQ8a1W+lzCFsRyzWdJyO
8sC2Gy+dVfO1xJUkoQ0yexY0ipJZIJdjjarBs5UO3zo4EmMiqKzYfrB2e9t4qAAjKR3fm5+eNucb
DgJNCSzyvJSXyKLCGJoxT0kS2Ajapobq2GPuieGBbuKrAC1RwFsRQ5iyLhO6tKAQClmy+aSjOfaJ
NwfwMQ1jkRK7CtvfXWXEiRiuWDh9M6KYEBGOZ0WkJEeOcWYa8xHPnaDS7godd6UkW6kXlDZ/Nu9N
aYmzHCo5W7uwpGQjc6CUa9iwc0tN1V5y1vf9eCPE8+9TdjPCZT1sWg2yYxISzQTG7N/oPKeuYoeb
onWz4MzF1V9punjEpf6QLUjkd1fvWx+DPIQi+BOt9jYm2KVDBEhGeoY41myYVtPUDWDV1kcTR8oa
5mzRXJQOt1b9lT3Jng5Be2SeEgSDrDTpZEdDpFXfKYJEnmp+XitBOAyEqiDFlSMCrGYzWQUxCXFr
iU1P3zod1xTHDkQcSsKpfRCQHDxFnNC7ZQvs1BVGmvKGqM+5nvOuaVgd1nSBFmMKCanGeuPLbnLk
97GDpD27Ll72EdTbiutOHUq+sClLC0HUuCLO9NIhX6deWiROd42RiOYAAak6g21ikGGo5+qHUdYL
h8CgcXyGnNBLYiKMHJWczntb75Snm4zVmOyYoQ0JGTI9rBlhjDvKIV9dfcboQUxOTs4Pb1Z1ZNCU
eniE0KOuHty0KTcUZ01WOPgoJbWkKhOfb0QNR+eVD5bXEXzbKiI+9SnZkGgKKUl07LJEup6bZFAv
zAaBPZo3G17bx1N+ObMqJQDiLe2YQ6vcidiNHjFdBsLnJGjMOUntz9v+IeamKgoIyGEcld1VILtY
gY2oJBFRNnSTXc3hfTMJXMpwKhnIZtgo8o7Sd7fT9MixUX6rTalqcB7ovAFQxmEWi5bo7NqZ6xD/
NVqFen9k0hkeG+n8zW3uJvjbvnt1+9rWxlX7K8KQF87zVSpb69cdjw//eH7xvD15atx84UEaU9qO
vX7cUSeKZRu4n7XhUholRRxxROogjLfGFaMKu9Gf4wQHmQMhdMgGiZY8ZvNoK04YMl99owq2x0Gn
Ti4vcATo8DwnoU7ZUG3H3h0Z92FeyS+CYTjYX1yQxjRH20WesxJUv33c6WSwATFoaKqRS2IN3PTj
qPWLKGHHnbk9yqZaxpd4mzDbCvdsdfPbSsz/+g1EL9BgIto04BeGqbfomCyUyu/cIXK6AVpFaA5L
+EJHWmuHid0xoPRgAV23f7OxKqWd6v4ozEIYqZo0aJLJvqmWSvHVsqViYrTQXeOGCjr9mJaJvalq
JjZmFAhinbKFkeh804cpiTaJlpgVE607yr1J0TKRQbtbAIQwnQrj2qgRb0+lQm5SdIYHsz4RpoJx
NcWKfSX0LCyeTZNIsVZ/lc4rEmyqA5HEuS5X5INGZo+1SLtoT52DxbVzUJbx6harG+1MvBI5j6Ql
82xWNb4By8GNduaofmbXJFNUM6Bx/Ue2T4OkUyvDFFjwUdBFTTIR+1ApYMtx71FiYM/LRxN3bE+1
iQag3BPGHlFNv+c5BbV3Pj2XostkSoiPzzgrVcqYiRhoJZjcnmwFqJoZ3Gi7nj0dZG+68KGOXQh+
jBDGdEqfhNTpIq3O0QnHIvxw6mhMRYZNZ6rJjFuzGsqsU3bhjkufrPXd8eGBTb6eBVvWJefURlK0
p5bHIXSsGcHwbfSOrTPFUd/J5s32zMhsLjUjSOyQ2QO7HdFjz/K6wTKNXr3Cpkugb+5n4UBOXtWd
mS6flKZ/2BS1tbolWw3aFXC38IRX7hEYhxx3xP6aWDsW+XV5KdEiyeJ9TRRIEvzu6iKhvaA7oAKT
VEyYkOkESrtFNpkSnFHBmYeYMrBVgNQunXaHGmSx8aPndH0inPFaJtQteurjyZ3OOMY560TYMowQ
3c2bS+35aWFzvm0CvrpVN2lmcOxVnkU94SRz/LyS4yQ4yfmwueQ42UjkzOZSU9YDLOGw27VmUtc+
lB5jGbgTvGQnmM8Tbi7NeYKHi22R3G2g9dIELy0sx/v97jQY04nkL3AmlZMSif9y3dK+Epx+trQB
kI3/4mkigusYI9nnayCY2JYdYutGHTo6U5jT1ciDfcoj4xKQFp0qIN6v1Ols0RyKu77sEBwdErYS
yRvP8ciuSnVLbbJo1dHcbtJNDu5PA3Bssp0D1R6XaB+KZo9NslMp9jgEW0+vZs6aE0l3pb1izCir
dGrCQkn2/Ow6VtHRm1rtzbHFTBBko4FwyiZYGOPeCE3/OPEtVkL9TRepKkOJLadL2xHO0jn6M1g2
hpMDjB/TKEXHgSVnQqJOL8Gr4dmfJKePyCixyrGxXrSl7ztCVb8f+pcpmsMDCKfcCHuExXDOo+Ao
2VLgrpjt5qYUzf8mh1wSLlgXFal/NizVy2NPbvsBbhVNaPKeTUhxd1Xs4k5md+qXJEwci/1hmMvZ
vrrDG4J8pXI1LmZhN06rM0PThZl26OdOhH4nYsbFkYYs0c4lL10ayyxYY5TlLmreeriOgSbmkjJX
V5T7Fho7i35jaQLBMk1b2ob58shbT70EeGExghnq6cxQ82BgnIF3DAonvRMOOSRXg5V0ehwYeu5G
UihSzuemgZA7J0tMo4XsfLlZFyZO5yHmyi34ctgxU1cc8dWZJTSpZ4CJBtmEZFjUuxrachO3oTKy
UqPhJh/FBVnRYKL04K/5rnJ8TTEF3WAzc16BCr0zYTF8Z1TqnthQb3ppBHwlPEMwAUyFTd/kWgWm
oNM6LZC1z2FeKKq+ND2dDF1YfKcjeuncY7XW4uFQi7mbwCCrsId9yst8YA2gCMI0w+zeotvcmQBw
D4Hp9R2UYgPd0Fwmr+RRDmmi0eAPZlGLdYBWukFMjE4asZwRCjE6mDFNhJVF+2hYTTPTIHt2yAyH
4+mGYkoPObQBwdMZE+IrBPYIL8qQqartDZtRMWZhEGX7FAiFhheJZXGDs9FIF6Jvzt4qwdi2NcVK
hyvcekHHUkjdrBFxcMwQ1kdM9qPufjSW1ar9EM0PnV4cyblY4n6xnjFDX77eL7/tpfdxuXyzXosY
pzh00CAS+dKHQ64Tc57W7yuC8GPkr3HAVWFzsg8nuJVRYaqeb9iuu5d1rDJ0KpCnpFZZz1osoXKA
MMRXjOEsB3GWJnLEiwhGJ1VZFMLRWLpCs+3C2uE6OI0UD6UcyUwmBpABBmDXwl1joeMqSmxWxORT
EukowsgVLQZFuHT0ijATPGln24Q7Gks6gDSrlSeLFrXVoTiGkRi+4wTUmDumVM4KWVJDXD7lqFo3
9FxCk3oea5J1EQan1zEOngLEOeM164jYMLxN30TmjdNI1Ekn1tzkWeSMwxuEyceP/OwgdGjFuDiR
K0CPUKrFaHiiGWb2YQ9TEE9hjy6FSpBwkruzCY+VZWp7IWGYovV6OTDEgGsyXWDbI3GpzU0vnf8V
D8jd/NV/EIV9a1ifvikJ9PoCtJdLPhQ8B0HnytBKzZ5EmCOkpcIe8CzrvXb95TXemj1zcZ49HcIa
GB95EcpgBzydvQkHabKf80x6ewgKGMojpg8xMfMtPfZcb0V/blNQLW2inE5qznjL5RGOCCdYmOle
dRwFHbjw+tr2IvPUY+HxM4r5MBpYPUcjmrV8rwYlGVWl3Jj2jhvoJ/o+qmMJHAXyiAchLLzuQuFZ
tr/P8eFY99rpwM9HkdoEFqqmF3LdNGBhPxVlgwMdafLxMmm9sQzFkNULx5/0JK6KcFAtdu6JmzaI
wFxv7NCOI11vetJVs2p4iRM8jdnV1HUuGJLcIJJSKr7S/qXOlR3n7jV2+0maRXqL0AwH3QwtVJBn
ZUB1wy1vVn+meAqJdFdM+67jpHpmycWSoI6dcVkkZgAURCRKHNluZ7SyK6kJnjRr+aq5ppDGoBtH
Q4UJBVILv+dhou9/mFeAmVARXrIaRgEfVrt8AtuKcY409L1LFEiMizLFy1lzZo7lUTq4aRJyiRGF
3e4UqkU44vGkiCw12HuR7LygUSsDQtiNeuFBnOpVqqivICH4d5hayUe6n3dbezfOO/00NzkviAOx
EzQcYKK43A3+mI13BBz8QbpRPa+wurpZ0YaNu4RFfm4+AqpyYQqpC+2h4CL8iW+aNfR+ZCKBPF4X
BJp+aYrLXKiT+vF4rt5cy1CGGhhiF/cE13c1MK/L3Ip7qnLX76wGm1M0HdEVRroRkz3ZqVnDTIYa
q1ndVnuMBIfH8HNvu4aHlZx8tDWRgWUEmKZ9/moyqdUcqT3+WVrC8aY9Tott8kHaOap6c75bgte4
RHU9OCovcyYzkxtErnutMNHalVqWe20PZpmzjWNrFbWb6Mbq/6VTMVM5hvI7BIMsj4P/2nTKueTe
p2Fn0SDlm4XHj9LfOztJYILTQmgtIfLuaT//ytCPXqnnMrx66A5qDA/iS6uE7bmY0jCO2VV0uc0d
BY2bC7DpyNXAvVlKelUVqbrMrDHaGKHUZWAPerPJkWdT+R9bUdiwhSCMbatq/CmtYeYbVj+xbFC7
Mibpg1iJNtbc0e6GOewkKHIsfokPZ/iGQu+IuWFddfYeN6+y4dIIYgKjLp3dYPaHpyf8OCxXcfIu
tcR7okKSuLF320Eq2rQYq3wchbBJTVrSVDkwy1hcrQRy7V7jZaPMNGAir+G8/hJnJhxTZFKSBprf
kzweiAwjUBzUGaqkIdSeQSMd5rxxxF3rhdk+dLN1fZTQbrO1KndN+Fs6mmfipj0nrXdIedWyeJfC
ucKs04tR9o8yyZACgEZ9CjwN8PJjtFwgHB0v2SdZJnZSCmiPkwPMRE6DsSgUNLlOhLaoMHzwy814
gyjke8gs/btgw3IglGWmfC4/6AhOgj3BSdi3XS28y42tnEQEmIpyQRgqXeY7Cq1y7KQmvaeyQRSu
hOGYWhGHDmCKfAVEBwoMYdR07kqg0xlcs/mhdGaDM9euXT9LWFw/EBox79uX1uElIA94V3ylnE84
3dtr9bFDZkBnbNa+lO4XLIZh3MXJAnlRmPcQ2HoZWOLDQiByUpBgZVFrLCyedMl6O+DMuaEke0LW
STt+DidFlOE4aMjYhSQILVdxnAw6BwgD9oIg7kK0b8ceI0erxp4cDy3sOQXbA2meRZDtgZP1Hzsj
hjjsj17rAsoSZR1CfY0tEAhDQjPDoogGQ5QzidGMzRx0wyJUxrLOwK9ZwDQ50BHW7805NTnDJffp
aSSjRqCdAckHglRzBCCI2dlEWy/XrG2EJYe0I3ZA79JqxfcDW/NMp7PXWiKrI/5xlrg+AoLZ54Ms
2F8FInzNnXSDZKUZ9OxK4mJ7bbJRpcmyToHO9kgS0Y1zfMlhIPOLLlya/x0mt5A22QhPvK+sQBoy
khsk90jRg9FSgzvbxPNBE15ZCJ7f2ea/+LSTvEC/XjC/XliQ407PGX+0CmF1xwixTKQoVDxFhj5Q
ZZbPu1UsjaSn1ZwJpdVtFx4vSbpNqdZ4tkeHFHjCmzLj2HN9V4SxeZ/oo54gKmfa2phqrk/5Dsqc
AZvwdE9zxsJqrV4yOdt3tztWpjiHm3ZVhXYPk0vWQFY+5IhPYfMIIJjiWGqBuY0z8yPb8046tObd
2Eml41zLSWci3MAM21FNOshkgEdM9+L9UcY2Ljyebzlnyk7EdFcD4wdsZQodlzktdmCV6PwVBWg2
x1oVDyW32gRtaed4mGQ/nEkvFqPLx5NquoTqj8uwVbuTpmg/MR4eV8DG5jL6bilBKIpZLy+wp8mJ
L8Goxu7a9zhD+4TDxvUrK1w0NHEa2ZD2pChbgSiBXu05YM/ga29pc5Cr8RO1iHRO2cpmDyFUdMKT
DnZMCjkEZs8LjEshF3CqNjI1niihk5/JSalYfqwmdHL52tgzuzZHmLpJS5u5see7QqVpBeCZ5ijN
WuCk1WfgdL4gUHfFxKYUrH+iTNeR7kI005lR5Ct6PPdn+QT9KbWlHaomjrZaikZrlAnObkH2bE46
atbDms28Rjy5GLNTJCY99iy9gq/HmNwRjPAn7n0USnkLZP0hdMZfEqchPddcSwysoGlH6+ClFAVo
BmSVGtkCYcOCuvkpa3O++kS+pn1EYbRnIjCRV3VXLczIdsRGU3JXObmaXT9B6YC/aQNhTGNvJtt8
yZAvsDUNDILy7Y/hxMQeTvfqvHkmoYvxIXppYq0rhfMJSAYcBNyDPSuGutNGXSIvyuswSdkMLwTv
OG/UDODJWM9ZdAy0M/8wyWOPi3nXglcalTMkR8ieCng5ibVTksWUbnKpXWuOTQOBeGual64s5oCd
9+OAcEUNJqoojxXNkc2Ao3zELsIup13EQSMe99TKihZIDpQ1C2fiGfEdtw0r/FnpOSIb91Dr2qrK
Sstdny7qLBOl/TiIk5CvVC/0NNCsyxpGtY1xSHdXczZ/ScwP3XVLQjyoRmbQmI0GHsN6j/d7BZ/r
zp3cxqFYpFVkiD5aTDmxXRmmKhxA0ds7t4N9+OkQE9TzdKFej/ZK2A4N4gdRdlYykhU26/hkMUlA
jHgRLt/2zx42eTAVR+qxFpiqpbXbx0PXckHcLR2aTYQqsWSmdFWG42RzwrmOBzHsAckdR9s6L4Ld
O4Wri3t2WsJOoPVzlFBeDsdaVI9hXVr1qQ82yZdZy/4m+cZrbg/wN7rUKTXWHmNw1QQKM1cdJ9JM
8EJQ2m6U73UJgz6G76a65XDot5QBsYLlSs4DCcUj5uroW33lRBXps7FnaG4i9mfD/DHR3tR1nEVF
hpG6Sk6uIDC5Q6oiHbE+0qa9GyckuA1hYdBoB1pqR8BkFCfWCkmmxDGr0WFpc1ML53+dysTkGEMO
iimU//BUi+HYGs2OacRVjmRcvy6xW9kxHcOOZDzhUFx387HHYbjUn+NB/1NmbrfH35COJ++rp/7v
rgoJbCR+Fw4j7957PFoPkwS18FpXa8SZLFCM+ULHTXfCzpBPwJoOPKvnMbIJwMDakkOA+lcJMthL
Z8ohME7xrs0YQKccOCMAIgj7wDbyumFKLjA9fz+B4MwMX18M5IpXmk3/0L17vWu49BR6txfxwCQy
BP9c7AnOo7pH7c1ZVLcV+7Nz9DRctC/UHqM/1gl6PWVaMiw5p0u1UTMeg7ilwLsb1z3L/hB4Gy62
zet1qFte2e/FF8PdhZU/F+T/OePevDOZuINOZ+9JrLWI/3sCXXDm43LTQpnykAvPVFx6gl155osV
ZnO38ZZJzP5oGRruuL1rO73trHxnXfMSgS2Gn7JJqs4bHwRX3XyT6AdD7Wp+CsH87+ogZjbNCOYp
6noNgDPXzwJ+AB0f9xEed+i4SprJDhfHp+4afHevHz2I5TMMn9ASGU3Exsa5cMXWgXHwaGcz13qa
w0KeD4UORqicr4xKNre6x8HU+k1zYFZsOUB6ekyMiLNsJ7UmVJKbNrDMo2taCo6q7042rIU8dj0S
psm0fKyS+8Rp/vioExo7+rC1LCh+pskbpHLmRktvTvYS7NWArh2KwpwDIHfZOoYgoj1ot1AjmAFw
wIQXOxSGuw7/OrM68jY7rTIo8ervxX05ijPRq49QrGN/dhcutlw6fxMnxuwztU9o1pbl4foCLCHx
1CAIl5hkW8zbp+40KJ7lv+hlQN82cmgMSRR6SQqNHygvi7pXmNXe2rbhQRt6lvTMxrWNtbNqNqRV
ZkI8lDuVtvyawZWAQm1jc5TwY2KPZqUjkA1DZYCZjTsbkvebKpMZxeKbN4pkPNVKeeDGblTCvWom
l28AGJlrKRhVNX4g7gNCUU99Ncspx7Ly/XKHIfElOalqXkUATmLL2Pc+GTzJsZZD7NIAtuEosa6g
QSHt+FAEDYpQNABLlk3XAKzy0p8eWu6GBeHvAt4fj+EtMB0uqk1iaHcDQB3hy/wKZ1ck+RTcUDzs
i52r6WuQI78QDuI+od6UGCiF/rmeYuOmtHdPlPg57KbSTmxtNgaEsC/nbAp3m1ahIw7M6TLP9VDw
kQDsJI3coWphEMYgH/ZFzMjV0Ham1hQ7ZpGOR9AaG020X5LiMQwo6S7TiMWe4wzIC9ADtFHttY16
w2l3QMhSESlkrxhks7FWD4fDKKRzVSBqutyxVNa49qw0DXyxh9jfYR+ajEG/qBom8loc9dm4iTCY
47k42UQgkLVZKXWtfrzh/PTK+d8t4hPJLBSiw3NIhAC5VHJSEkFAlkqmkciOCQRG+0D0AM/Scdu7
xoOgIOqUC9rKsN5GdxLkBYddSxVzmtalHF/LDPrA4CmxquiEd2/tbNfG5hNTXl9fDy4twPZncdcm
yufD8laOenZS9JghW9L0JYZ3ZZFmt6dYJ7FL6anYQXr8iDzeHLSdsy56Z/XDReEFEoKHsE4YhWdf
VmVudhVOo/CCUggeQjlhFJ7pzkczBK9mr1Yfb1dxmcru75ihbuP2hjtTXxsTw1YKYENYY0zBmTms
Nu0qHV6w4h6RtS8H49xj3N7hN3sCYubR1Iam+XFpcotpwqE2uizZOp4Js6rpWV0kQ2zyNswarDYI
EzyQ7zI16ONhaE8SGo+27G+9nQAQjG5DSXeavEepbnaPg8qHujs1mG/g29lTIgfTkwW8qVdNwRw7
4O0vQqTbsTvht65dKneiGvtmOuGQptYuy8D6gLc7Q1UQm0E4DZFDuU5GL1fSpuoHQwqnhtGVIzgo
wEWUQ3yEZHJPVDEdF+a6Kzn8h9dWtvTaynO4/OanHc7/ugh8aLVKYFoZE1MpS2Po8bE7bM3vwa+I
k9kkuRvTnHMdK/IVcoWJlWw2YYCb1jHkqRbTSeF2DycgrZmBLs1z8FTnx2+a3ILYibKtAW00NbY5
hOEaaoRN2zsmXYVkalSaShDiz879cRMH6oQRxkXTmVmEUo7JIzO/OQckQSSmhycIpDORgJVAunF9
1Sga1simYB0wy/cz0cGx7qhTy0iZjOYafBa6cUMil07Jypxd6KgsdCOyxgdkOWFqNTFqNfjElbPK
YfcSlTYmJO0vVDAanb/Fk+YmEsZMuXW2BL7HOp8aelbLI5wTEFOjzaaHmiGY+mizaaFmfqAZwqmJ
NZtxRF5wGYKahEZZOh8fwWV1A5oQUFb3+rQgsupWgKRAJZaMbVpRObCZwndL+39aGfkRsMEHzcA6
F9DSUvH4jHX3UC+MVPlYhJTVYO8vYxjZ/C+a0EwGeqdMMS1krDorCGamMLFZ0IbAXAPGlP7hgrNh
YMcM3mXC3Yw4x0O/lgiUAvwmbW4XVX6OwfXMqndObiMY9/qwCx8H0WkTAtOCqbFpO7zqZ72MRgJ6
yi65kwWPuZFjCOZEwWNB2cf80YodYxKZLV6MHif46YU0cm8HqIY/0fOQ4Uv0aAxTqcXSW8eJI6Pn
WAFNXGNcVBP/OjWsLJgcWUbPw2N4c7Yos2lg/lJOlP9idaUEcSfutkiGP7m4tLyy27l86eKF6IlS
xZqHKhq3cCssnuRWL7QvzVAbuVErTuMnDbreeIqf+Qj3OV+YgEJkuWytEBcbDkPOxzGzrvmFGGm3
G824u7OXstl779WhZ2woGlIRouRhyHSYx9iXtRcIyPTE6FKo57p2dmf3o75G730RdFtGteTcrTZB
tVEPpV4eYcYwpzrW5QOGBlGSzRpELZ65gD2pOLIYV5IIrzRyTKIW9ffIkSEm+Ah3UR3YCLsCWLYy
Ed2TOkxhb+md9QDV2X2dkMRZtXF3dlVvzVNodX5+yehBneUxrZXzk5FUM5qDRINBR3m+oKbjdORh
IhhtVLFRQYEGnrjdgV7fxk0+VNELEuKC+pjQ5fP21lc0EOCOHwWuznG/L67i0nxPMUPQqLedRGIS
39nJ1CE0zckGOi2nFxN69xeOpDi00Ml0w9shVvcAoTr8HZxeBIOkqUgv5SKOEAed8WuYtEPAjDMN
uT9pfGKO7asdjCDstoq0hceFDuLo0NI2UUwsALtIFE3RdWMJ3/GSYFY6ogPB7bJRQcd4ICfynYSW
6YNIyZb9pTigXLz3dI31gHRaBGXjcyTmyedcRqs7GE8Sq+466dHRY+4Frq0jwUewN8qIwHGNxqIH
hgPKRsUeev3B7awkJErYvIubm4y3GWSzwczvZu/PLSr7rrcSWlOH85vd6MtqEGMJbWuOyHNTxTVH
dNC0EcLSjOc7jiTX/iabWrF2Of+pzwiZThHS2ISHyo/Q2sdG+FHfZi+NJUoDOsbxIrt0VXQ/7Chq
qt2Xk3QOQ2HErZTlnhjRW6gBqODjF6fYYfHPbcwkSQsArRZXl67KCUtkhfXAA01xXc+O6FfHOE0n
svmzuIba/q0lKjKwL5wW2u7Ha1sn64oIPWTa7vEcNbsYe6GYZLqlq+5NgCbmRjtksdCPJHM4pXbm
BR7SHSWDtEDBpfcPc0fqsB/nihinx/KibPj61qNq23GamKPSNefbAJimphkoj7dqayZYfGan3Z88
xfa0H7E1dXHzuq1d37m3wKetbmIlpQUOeDnPBD3ASx3I+MgcFyhKGnPCY9y8Qr7UINniGjSJTchB
jZwDXTHh3mifBQOoRJ37o7x1Oxxl1Hxw5urt62dNiDnA37p+DYEswT4ieB4+4B/3sLPM5pugEh7Q
XRRQUW6TIbehqJLwCtlLyU0bcGZt6oVEXwEDi8hOi/Ic1V9N52ePLpCA2AsHcT8WTUZXOwBgKYEQ
XSMTtoKdXV66sMh51+BDaQwSf1L2sDgCmHNdbbZWTZRr6+7WhgrG3E4Trmf+aC1c9ZVil6DDXExM
9jBcpR4/Twany7+cDm5eu/PMndungqnP88NWmKetURa3kHTuzVDlzWeu3bl1azXwa561Nf0fzNdP
khbbwsBpgLG9fmsjCOMWWdydyvpV4D9PshM87vCvtCqIU7Rwcw3D3sQrrp0LXqdMwZha0+YgqGtR
Oni68ssx5oEv6m4NoR5wI8TbqQm/0dc1+OwM4YUyRu2XXosVjJ6nHe+k+92n4HR8xRJaEUAtZmsg
CGarvxwDucGB8NkSYsc/SuNeRQen3ve22pPBmSJFbfVc8OIoxf7iMa9k/+xsbdIcGtDlefR/MF9X
V8acpPucE8CfJ8VyYq7waWxzfM3JBFZfVThn9ZdZKYsDrlqIHiIDJZrS9zqF5dflAZqRXygK+Zy+
1+mHeT6VcJSRch00u5eaI6DOA4PGQOkWB0qfhvbczyF8Ma1J9/3dMoD9YwJICAASVOvG+tbq7Vmq
09t3d+Dt1vW1NQuAv9qhr6YCWV3bfoaq4h9L9q+30J9b8vNUMNsK5qb7B8O70d6+OSOYZ7X2hv6B
I1pqLX7xLLX13dbNrc01p/bdW1dnqb5259r2xrY/k8unvU/Ho4vlqAQsPl71F0rVR8erHpaocjmM
jgngfhlA75gAXiwDSI4H4MhH/0tQ+/SN7Z3bp6cDoaWwXrc+1o+3QgxVXY8GRcoUvXnnNv0RfDH+
uTgrmOn9mQ5na7W8NJyOrT17tbV1bXtpOpyABLTPI4nVOq88WeJILn/Bj37/p7fJrz/3jAvshvvh
5vbmqh3aDFj1RpEMa195suZSEH/cMYlBt0ZnP24t7w+H0JcRWoxaeHMFap385bRudfN+y9zHcS6I
W4d9gIHZ/gDG9OodbnwJqkZFz4E0a8XWHlIEVN/DBMXHAJDgiPfzInHqUFxDq4hBx34JnSfngu7B
bivr5Euzj8iE7rQclJ+a8Jvoc+yhkxfNpPgPzK/+cjpYf8fd1Wem9QafyQpqzaTjA01Vf5lboyUy
0Qca9X+ZW4MemdoHGnR/mUNz89LFl+efxh4eb43ZB9Dg/jIHNPCvpTWpDzTn/zK3Bg078R9cN/LL
3JsSBqSP0xT/cowGp7ToMyvzQIveL/NrsML8+MFFU/rlOG36bUmVu+sO27UPNOX+cpxmJixQrI+7
TZcJo+XXROWbk9JecGTplmqE4h9J9Z3q6PW17LpZy0/JU1Hmec0yU0JrpCXgZpXC1L5dogM2/xrb
rSacX1ppLy1dxoTz/Nc9Mm6eb0/JYjR5y15zAHI8CHfvTmh0zW6nHBBYUyeUzW3jgc+6h3cecnOy
PY1NKbnZ0Vd/Mgu/WgmfJ6s/GBtd+YexoBRSZw8VIvov39tyLuJ/SpYfAQMv1jzIijp7smYqKkY0
tlI0vhJ3pqYO/TChqfpaUX0tdvpMJKRyjmpYf7VJbZ3LfM7giHEpyQU4+nVHvqYh6Cly79odBKTu
eQ1RxHjIDkWoALj2xOt6TCWEEz/EdT3GNU6A3Ot6Ts0zsmp5zknZz1PmrLFBIjPzE7/aeLu9UF21
pj4+J+EflXs40XIzMBJ/gdfyCYdF6POkiaxjU/45EysHfwLaB/qn48Cfuu8IAt/zeS4oezu1sToW
YkddBoo6uflx3Ar3m6ir7ntbGQom2BEABgGVBwDoj+NaNyirq6w/jq3sILla2f6o9Z2vWpiSuAqG
vnbBrL3j7h2N1pZXVD6wsKn8clbq1AAvuwLc3yQISCbSI6AWBn2MG3ipog+UAtHW7uxUK9QAoped
3q0+s3lzNXhzcIb/OBesbdzY2Dk7rgtOzcU306s1b9qR8Jun8Qu1c3hrwHue9P3/4+ihftXUABhP
0lbDrPIge0G7XXEh5s9Jupiv5cieRzKZ2pw3s0hOJkgaMPfc6sZa03i++dAmywmbas7cG+jk0qs9
YOzdRoBAnHs0Av/UaNGziUUUIXKISSOM3GEYhJph2v4iqPE5txAMvuF0ws+3ZdFk2zRsRVNp0QfT
dm4R2qQAIJgjGJVcnU5if0I6LjrKaHITOTltGG9HpH87KZ7GJ0SrSdehcJ1JcPuCwygRgwaWSCAT
HftUKaoNniIC5zb12JEDdShH+llpkeuTvfR+Jrw3cDLp83EfDzUzd0+ntYIS6Z4Ltb57CKGuh0oD
LoOfcebdQN1xs9yePd8dgqnOsIaetqvdrEcdT151cssYY0DHw9aMqNIu1GJrZlTNT1Odf574h1mk
HtnMvAImzCECOsaaVIr3ZKBltKY7JXbJZ7ydvAmlkXPko72gFdvU6EYKQy2l/ZMbGqWzhBp4K5Xc
Ik6H4rxGJKVe6lJegdYGY/IQwX4vlfyA2pdcx6BxzE6oJcLB+G3JYvXGWlwdVzohjNJWb6x0ctuR
+Gl7fDLXHJW9qcH0NnQ/zvDyPuqDl5SKskDYAyOSrsxT+q0jItfj2iTlJVY7i/QAvyByY33nujni
yRNB+RTynExHF3GOaTOb7lHsK/c4ZyTTD4vcpMSmyu+uccoPXIR2ud6SRC16IXzNYDvi3EIX24uK
eXijZU6hkv6CG23TYQQiAM4DAMxnCzyGM2Qv6bLDVjZuX7+D2ZJ6aZejAy9fvOBUIHxrna2oHyva
oRvkc8uZyjOTtQbec3q/dI+jk8e2f3dzbRU2C04PlpcXF+u6rKITa9kD43R2kjKzFXKwEimL4Kws
XVI4AMa2iYC21q+vb3mtnl9ERJHSQzWW3V5u3r36zMb2TalgkHt5Yfkex3fddInWPHxOQ1ZJsHrt
6eDqO9eDa6u3MZY6uLO5g9moEPgpfv/LHu4RKGPCKJce2P1GELRqCpr1WwZIbRBgsEX/DQdZGUiq
APBfA6Q23k2BMKbqgKQekNrYJnnCrulJGkwCMs46wkBoPMcAYmx0LpCZekKPseyp9aaefvxn++7V
4DZsTDe3VnHZ4tIJbm3fQFr+WNCP/9TRD5Up9OM9iqcKCUyhn2MCmUQ/DpDaMhP9HB9IDf3MCMQj
nrlplvO/cGDMI/Lxik/xcv4Nx4PGU5B3owylzDX3OFSOP9YFpds9t+e+KkaZkbbjg9JNhi20U+N5
N+OjGZrcnXh7Gg4ZdwHQ/lZY9CT1ENTL48GQUgybtsmRhkBgIzfKoiZLSj4VMYwSyt4tqsbd1Wt1
qZLCUZEirA53hftNekiUYTOROUpqstaxUd45uweNFqI32OuMSQF1UmX1wyM7EpM+CYXqUC63cFJh
IhDTHotKGgL22ua8qCS8EESLrSIQBTksirBD2fBiTPKZYpWY8zYkSYonCpt6cxl2nM4o5vF+QipO
wpuOwTDsFE5mzj5AxFZBmcuOSAFv6olTBzGoY6bD1u5RC/5pkiu0D12UIxHw5/0gx/OflAaqcyRT
owqr3ssGU9RLs/glpDDa+kku/eu86dRssZgoB5CeYdY/QR6qgmGiqnQr3WvpTSNk9aEj71Bj0css
gL3cx0UuWQVJdwIqdnYjHBWM1cl+1e6HeeHBmHFJIBRaFTxjwHCSIAL0513Y7Q5pk4CzovelkCrr
X6Qk3iEcBQIzGcr00t5unHf6qWSFckYAfch5j11tDwEREeyHfAGESQap6bqwNu9MQaPHnRJT9dY6
Wp3Xb6+trwWaur6UdUh3ZnQyLkfmAx+ctOBN0eQsXclcOcfN6YiihqFNo7o2srLa0x1Ey5IIHBHB
LGTqsQ7JeeTmWEas67KPk0IyzmFyOGcZ8WiR1cKq7QD7N8YLlxkQF0pkyUbZTOu97eRoKzSxNJ0v
ky0VndDGznXCUc4dA+k4MLtZ2fx7l3HIVrJEjxzMoNRol6hdl7oIuRu6DKOu7tYRAhGXrnnk6bpb
xZdgwAAIU7+ZwcBcA3oGzTIxSVKkFPNG70ZTCAsB1dDW8QiLloZPW+MOujim+vGHWeQce22GTDq5
x0isSZEZBj3n5DyJiJqrDSI8WE7/En1aw2CV8kpXkbt5mXlXZc/1C0jTOCdulbw9li7tDSJWlLFV
itE4sJcKelRubEdTMdeen1o2/3z9DndEuKBJxCEdSGdtJx6qsZ/J2hy8ZI88HTvl5HWW4AjSPjER
R+ewNSkf4CgPNjZhBQQ6p8RTTFiAc8ATM3lkXeYyw4xNG5xSkNhPTvQ99qQNM4hghw6YrkkyXopO
GpBy4dlgQAcCGV6Q1T2QTNd8qFWYnkAOQE4CGUE1vmMGRsqWiqWVe/bMJB/KJtLkq6SNG8ex9TTx
HkayOCmjo5nkA7GShFISiHq3G6m00ZVAx0jdjGRRduBlRmVjbSRnebERZ7HZOyb0OCreFdOPUSKY
BHseQqIHQ9p06LnaSdFVgXBVJ5ViiZeULzdQxmL12rurCObMbsTSgb96PPf5CyWF1sPELj/SMRCR
eU2dLaU9jEC7R2dh2SY32zDcDUfo5pQQfmDTuaCiL+rsrqSAJwlRpGbkVljBnDiqL2dgIDmiue9S
zfXBNUsZORU95Ts7lX7EYisyJbd3nEnnUVQ2g1ER90G9tefxnbGKmdixZcqAac0SWDesUBtgPaKL
iV6J6NwrN7SaZiHxNUpHlXAyoiSp1V9EHKNVHO+WQyZG+Xs4CyyJAWZs0kBpSG2z2FXY4tsGM7ua
Pac06wilg4nmPK16/DE+tWqD6lMYTiwnvYlUiJaZYNwMgKWurgZZuj/yXtoL+3kNvXvTRu12U8Qb
yWPWt9DJUeDmBGNGWYUSgssYhWytB+2QwkXtTXtKV5bVGzWlYuKOadGB4hlRisMBCJ3+kbJZ1eDz
IyBnmMJ+fJ/5Igz1FjohzCx7PEkS/dONGZxplqzSAos8RrBvwx1anvZHrMtRp5FP2w0asTJCjXKa
GaYQPaAw70dWFUIHoTUTeHin8RBLj6CVjTVvl1KzvEjWoqnPsAp/3VOPy6ubkx3zvZctjJfj7Q/z
fvy1xcuev2YBgPOq920Y8ou6FdgKwjQAHQG1FUkYBTqF+Il+65krbOiwx7dFzpE3EFVCzX2EDApp
JOzT9h9aA4joeuRry4y6wDoc8HHSCwraLdTh3V+ZCGKGmRX93UU/oidBXdNcRDNKcP+PHJvzI2N/
RomoP1FXnZTm+gu9deLsHLOTLM8/X/8qjNK580DddL4QTIy5TJ21JmV2lYZcQabJjWjGLNPAeRTS
SYwVAyfWmQnkcmMmeRzbRTCV2W2bYTqC0FsOtFVTJuKpZSbr1oyEFOdq14zog/AucVNigjCzOGRn
YhbtUGM1WIRBdzWpXV1SaPacj9ENSkuZmU6TsvY4+yRzjWkMNMsWPUJ5FdEzDn6AiIP5GrEbvbAX
OoWebCfWx9SU8uUaOsdq+ZA6JSGolRBN40bvjV1vJuFQLkRbaJAq6oz1SddtLIJSHmPRLpI0aXka
3JF2jeOdU5ulTtF3gDmsxIlKUkEMKLSzmXowgUbDO2WjP1E6Msqfsxv1woNYkaa7BXOnEpnd3G03
C77yPrcuWXFNT8ooIdag1zcElMfKv2Yh9VIyukpdHmlniYdQjvAe30gae+ZFFo6Ssq7mgiRGD8a4
A0MuTcwhGTES2csZY0JJ/27KgmIzp2uZzke7ObyDl6+ETlyMCSDZExSpbVdjGs2ioyxvU/fK4cx7
ZXOfKO4EWdDV7p0JgGyfMZINgx0kRSOPndcGmsE07RC6Qthw4yazFuowPHcCdVRMk5EzZOLxZjuk
3U/ZgmQMC6B1x7wqakPq/7xWwrisj4b0iamdjPod0ueF8PFD/WQwQpKvuYXBjWcy9PmXiPzrSKJM
85bgqT9TaH5eSuKcLwXA4KeN1durFddsINYSey8NWdpQt+MUaapT+fE7LsaI9Z/ZjQCjie5MBIcA
6wEeYzkd2Nvj8qgCJ+elsRtFJgui2ZeLufdIzOtl4eWFZ3nxV21COK5sICkki9DqcgiFtjE90too
SAw2o47BXuxZCPE54DI4rhtZOhrazZXNtO/EqfHF7eqnIHe04K88ZuoCjcAeBsKEb7dHOG9XzExS
SNT58/KGzPh1otTb4SC6UuNX51evpeRnpRR5Ci7BqMeHba3s+vooN1fjDfkotzhGjfxoNjlFXfuY
NG0v/pjc3KU2Z3rP4t0RpTxEIbrawYzVQBf7bOUxy8RZHJVba6nP2EEWcpooFFU2TReJYMh6xdxI
2RQKhFvx/ijqBzfCDGi/dQsdIYn496Ousv7y4mhWCZjNEvVut3mx8zmngQ+UCSIe1oBkQEbfAj0o
98Y/ccNHUn49iztAFkkW38/TpFx5kpYY8mHucbIU+7WVoonyVtg7QuNSTBI7VlMsaB6wxTZ7SdbW
co9cRBWT+2SrSab7DJI7TQqfT0519NGkISMEZ9Qw+y4ObQsGnraBRtf70OZqAng4xFSnEYC8Ee7C
wK+GL9xP4UOavBT2iWFcC8le2odvn8Z9dCC0dCNKs30kG1Qj1yJo9zl4KwYdzqKMXMxvT2E3jd9s
gdKbwPzvN4N3hoBylDo7YWJ8okRE124vBs/dwGugd+XKaoRRUAw23shFxtc0MaNCbeVym0K80Rj9
4EoAc5mg55r2yPoaYQPjt9wMt3upHnytD89CbxarZ+0yF8L1zFeEi9YcW6UjSVkaT27EAKpr7Dkx
DXEoQFz00QiDDjLjChezhIHCWqSJdoFNIB62CbuaJR31SWv4cf3RBkRhzMKifQhQZzDkNmJHrOds
YmpbIvyOCxPRab4JFJ9mR+4yvhKs+qPBNBSKcVJpushtItnK1UCgl8Kgn6LqxvZ4eogIvHD6JwLX
Z8TJ1A9Za7PpfV20wHBBn+Jlj+S0srSyYuIFQisxumZSvA6W55l2eupwQk0O9HrayKcoHPYl+CYs
nL0f49MAKiHWbuf898v4j3NzQo4e3Ftl6Ddw7pSgJcieEJovS0+cYrlIVX01IMhraO/FCtWWxgyP
AKrDt03xo+KY69tJmthtnCGaHVWRpbvqVaZHnTc5ba9gVBFeoHTexFt4QVmwLJDrgtCA4fDm3a5q
zYLMWwt8A/d4ckm8ADaeVjbrCi3UrCM1OittcNJ4zk0/LqqqSi9muGaY5JfO2Y8W5/nIYUJ52j+A
jbSlXg8B2OJo2EVVniUNLTBywLk3lU0mOBs9tRuZTBBdhwxjDx0YYIh8u6tYQJMyHl0Z2TT4yNGO
+DIGtWOFeNTDTjBvX9VJVscBMoqMDdilOMs4mGktl4RCaFyglnNXdIigrNjqdF3hw2mYX4IUPn57
pY35lBddnD+/fC9wr6mlByC8OILJQfYa3pdc/WGnQ3c4lGQK+rHtDZm5XKtKT9GrXKQtF3/AWpIr
RMXTP+r0yEHIt1gMHM4JlIrBG3ujfp99LbG9vsWYXmyf2oGeFDIQdNS05Ijwu3ZbbTeeiKwrwenS
Bj51UJsc94JZkiVzU3vnnIhfv5/9Eti6G20tUc9gB8XJQesW0ozecGsAjLnpduZrbi3vrLvu9hjD
NIDG3nkbTL7wFu0vFr0mRpd74SesqbnD1dy+Z0DMdiHuWKxbxCTjjbHT78Z18WvvyHWpXjA94YJc
A6P2ntxZLsk1ECakmirdmVs11VYUh/ZpWg+oT41hnBcmMU6HYVrmd3zG6TJMy3SOyThdhmmZ6HEY
pxmtJzxPwDi95X18xqk1mZSSWZburBzK2163A48hjb1yW+HMyI/q+dAJ2K7PhwyA2fmR/oOyQ+/h
9oT0BCY0gflMRexsDMeh9Fku5R7DcCbjtT0rxzFgpnm8xjIZy7UrSGUmg87tYAuU0X2+KIXm3MYJ
Wo+bSo6o00vSfrrvBnoL3sdbpGArGyRkwERQqOYyODvvCpaiLTNBAWw7FLOoVLiB4iMK5qUENIXd
TUp0R3AbJ+8Gn3/HQZlAwjO3b9w+S1OIV1fZwETiRocVMen0CvD0bGjyKta8EDjZDi1Lf2BMFbxR
Ntwah5Kk7LlxeLGbMtEZGJINp4YEKYBH6AvrPuHlYc/Gidw8lMm7YoBQdu9AsvA3Szn0/c8Jfi7l
q7fbJ01b39QU2U3JSt+UpPRNzUnftCnpm5Jy3gGzId87KeC9T6H/MTIfDQhJ9e699oL/cVSCuTsG
ShiVXrwPn7386v7PyRg4R/57L51msvUyrbvTzBuuC7wOvZ1w9AA35ECdNkvGwy1CVCYMLE4Dfm3t
1urSwsLCabQVVQUsmY7C/VSX4BJ7z7LIozDn6oDm/HYYc74MRL8vXV3QdG8uMBYs3sf38Zp6a8FC
P7uDJNQduoCo9Mg1XZTR6iSEQk+tOcBg3JHTp8y8YZqui/KSG+6MIYn0AMfn6QTz0OPsRkS0t43D
WBRJPs5Jr4ggcABaPID4alpDgwm15x0uXaelWy2BQndx0bkN9QPRI45ZTpRbk0keLWWsuYFk4gT6
gHQL0wBSBoqcGgUFTl1TD3HQhmA/CxPklRLzJTAo3MDREl1NKlSjNV1cZmIfzI20d1eveCn8HTZH
33Le/qabmF8/UF5+4hH0kTLzw1jvOFei06MBKWKWYtfWtLg/Z+Pmx9RV8evSKnoCgzVzf1pJLRja
3EzFmMuGTbNKyarPn29fqOxcxEdA0+PewOPwtbHa8mptt8hNZC2NVtFIU/+UjmZswcn1M8z4ArsZ
7I4ci2jBtvU6Q/dRcEhmOWLfovqCEo8GdNNVq7F4TcKoSSO0A2kGbtZn09sJ6lOTjMNphwK1je6k
a1vsnIUaP0trRo8rHS81UA1P4eRAx8oMZOl8TIqgyfmBxqB0aPIEwU+XyazppY5xTglxIgR+c3Gh
jfKY24EBXxGn2dJFcRhJuKnpSs6BbnKgnxFh56fneDlRkczidOSEkR1ELiDoC4kIBwCMYh/tCuSW
8be/5ImBTRpOK/aR9Wyn9w7PB8h6TGx5qQ0CysKi21vdLrgvriwYEM/vbPM395qyzY9l4Y6IJsvL
yOuIq9K68JfOz9iRC5WOXDhBR1yjS14c9WnPmewzGeRHg128GtPpBVRdI6emjWViHmz5Csce9/vc
W2cAZ+J21A5wHwM7TjwQiETJoWa5RE4tLjo0EQGLSDOScOKyRa2/H+/T8WSecu6znmPe4isxGano
oNSYPb2L12xyO2nXWpNglQFA9MznvseT1/shpYM7LXtlkU8K6TR1yjlWQt2yuZjowTxlFDdHa8m6
ordHg0HIUV86xGpmO8EUB5vcxuy1O3eIvNfXNnbubF0JNp9ZX91eD7bWb915Fn68ubEdbK9f29m4
czu4un79ztY6r/Nrq/jVHM94rMz5XgxADk7/tRImbHwC4L21sGBc9XPy1M/LUV/X1LH99A/vpjfy
7GG89A/jpCfnvPbmIXz05mZafE7kondd806Hjuuhd92azjwd20Ff9uCWHSn1bzt7CGJz6pZXKMf2
zhu7l0I4kXPeJdoT+ebVWW1m+CFd83PwzNvWHsYxb6jlJH75+pWM7c3slh/bnxmc8kGdM14BzeiT
H+eLVzAz+eTHuuLnYaCdbGcoeiWLjmMrjOxm1rcZVs1YK76EOmHYgGv8OGHUQDiXoAHs8UljBsj1
ZbpzgpABJ1RAwZzY8aUOL9OfWf1e9R4Mw0Rn9HrVTbtZGrP45ae5webiBTupE8w4vwxapvnA+LjQ
WF+8S34P5w2bxSM/0TFmBO40h/w0v5iReOP98VPcYgphgj9+0hht9YneeM9BNq89w5wvtAnYb1fP
Ho8bG3AC9ujyRSsnT8AeXb5oVJrZ2eOF2kgqd/Uckz36fNHwhanscWI4QAVDk/njuGgAA2Y8N5yN
DyqgcexwBj5YGtJJY5PMlNeEBByH+Smc8eFIUyMBrISdNQKpwvAUxOwBSGMYngKaIQBpchiAYd4T
mVzA3sd5GPvnYeufl6n/4Sz9cuaWsDcPQ/9c7PwPb+afh5V/Lkb+h7PxjzPxLy5QDs+yMa21sCB2
tEVjR1tTGeCYfkNOuhaJJR0Gick3cIgZ8tKmiglnaYWcNypwbh2oPewmNMY2PfgbxZ7RF90NYWiS
ZaJZH0/Ee0k6aQ2aYz46VDO9nKbUHAki1AE5RHt7MJOSpAcjX7o2n6mzy1cwqZy3Wl46b2JlHEmK
EMnIFHZ6yJB5T08WcLRUChC1ddsDYYQFaJVEPspja3rbwi09LOuPzuZW4Ph7WtYbyIr/sdxo1wdC
eUvb0NZx46C8+CeFcvwwqAlcp32SKKg5BUE9VAzU3FT5+d/4g8+E0KzaUCwbgmUgnCASSyOwvF4c
KxCrFH+lgI4Xh1UOv/KgzB6GVYq+8qDMGIW10p5DENb0gJ5ZYrAeJgRLp3NOkU7HDnRCwTSPOKc5
hDnNK8ppXkFO84pxmlOI01winE4W4ETa2nKttrYo2tqS0dZU83dGwhcU44t0QzGSXFpEhoTR/Ywo
hgrwpiVlep10elX8XJ+F49lCPaq7F5xRZRhDAMzeWQ1NZwliChDP3En6qOia180rvJ9IcF8O/eq7
khXpkLaRapEgOU1OEu1WJZ3vWas1XT1i+w9nXxjqXmalvUiGEewa/72EuRFKTmJno0nmyJeiLMWM
/Qh3VAReRmTZqLntqCn7fHvREAJ6dCK8bNhZILxFYoNngXc5oHKbRNLSjojpwlFYoGXMsqxeotzd
TSgc3E0PRgOC5FxXMMrimoVfHrpV96wpibAkV6aBAm62aYipXFyblBIPvcgg5M85J37hncd5vbOP
mburfIZSZzJKDntpP3JMddCo6S4xXaqPTcaY6DvB10g0wUpZqV0pS7JSls1Kcaxjhk8Sy3avVjQW
LqWk2zAHrl1teca6LhJxs++uU/cibQcA+WiVkOzRNKKA+alp878+Z8Ub6gqRLenCnjrSO80BZTRn
52vnbFnmbKUyZ4DBJqF/RdYuplVfDLzrFAV6wPO2rtFCFCaE4TMUPSMkllMvLtT2YkV6YZNAXOM0
zDJ7fE0JQvXdUcumbZyxEUgpQymx56WjiS8xaUMzflurV29fp65erO2qBsFcqOsq1rVdwBc7HmzV
1o6GUa5+ZvkOw+8wAmex7QXL4ReLJE40Ns/9MeCb5pYWFy/fA06Zhd0E7a3bbRB2T5NJCOOmVCzz
foc24hsScaMEL8+WzZ8cPAMyop+D2Lx6bTNYXGnSLhxbagLNZ6BaLF6+fLFt+7C0vAJ9uAYr8j7l
G4E+rAPfQSRstoM7IHCifh/3CqN9hA8MEpGFfdumtVnqyrZrVQGVElF7WjoBTTXtqvD7QTm5AjeT
yduhJ9ud3qj/Eqg5Cazmm/CFkzPlBnx8e9pL8iJNmqVerMJvm2QTw8uCCBLImvuYQgX+vgmD60dH
gJA2a/Tr7fIoOr0U2GyGO6GNTbRF8rUlG5QrmMhiM0uLtJP2ZXDY/3Iv3j4CyQKK7VKb6AHpfcOJ
1qyjCLynEe1KSXoQJkIRKN+Q19CljrcoPk4xCq+XG73TKVJmOgsLHnqXyuilod9s+0g+7V8HWQK+
6VwOueVdDjkeQSUQZ2AoZy3SQKtw0WS7e566G3Z6TZrN0xNaYJgtJb1Sg+uUMPC2c42mbf283/q8
BMf8L/gwV2hWlgiTxzTklHAi93N6xITgmy75uPNBd2IEz4UFLahbNCF0ycYOXrLh8B9mW7px0xs2
Ss1vyH0bpuUllzGUmsYLPylZ0nCXONHVdnMqm7g5iotoEAK/aJfXBxL9Wju4Mcow4/h0srITVAKE
46zcUaojgk5j7qZO7YjwUtLA40izTSJzjFI3/DkE0LBehsAisdFlp1G81RRIK44G8awrauLQeVlt
F2hB2xzt9ktrC5rziGnFdmVl4RJ2pZR4i2hqIxnCtmE567YciyNGNMEHzIRaZUcvgJQOzuCyQvRI
CJxPkClr8DLcMimOG7wMBDvblEW/cN4ZxNIKroirIazxXHq/mliM6a6niuTqGFyUI2q3xKMo8V9W
aBj0YutlwnbXj3YUNnzLsOG7dK/0LluATwMfuoVWW7ovKNge7UoI5JmNW9tnn8DJBW6GZj98vwRi
Zztg2AFtLBZUvQCetWhb5+3m2NYHtnW6ABst1VlKWZwYKbtyQ0cJwnTSxWWub63ZLed45K9tmhEv
y4idm3DIzLBQUTNkoTkjlnMN9SPeAQJ1nKvQtUGYhJwS8Qm763e+LMExryCqY8xAS6FXCd2+kXTi
YT/Knc6Xjl3wQ8HiC81xnb/wUev8RGozbuVS9y/UdH+50n155iO953wBwyonB3y8dD2wk/IPP672
Ua/vt54ZdcSJ9o5R2MUM8yDeQMONbmIU6o0swoyCzwF3AFaHb20fxkkXZfJzcZ8P+999muCvD8K4
fwVDx/ejp0KB3ifoeG0kqxXXelmMuWiDm2kf+0wuSUyBmOe8Vm7GWR72oRdxFCwu4jdvT7ODEDhe
ECwsrSzR7FyPkz7uivDvzR709YrTgY400e5JE09FAt92YyvF+sHbATv3CRtr0ajIO8A+kejuczD7
zShOoGYPUJ8VL7W2iywEZAbLrYtUI8wGIIu7BfbswsryAn17A7QTjMO1PQvesnL5wiKIyUuLSxcv
XHA6mrVfoPafKrjNdjc6Vf/Mh8wwhfOpxivPsZ5PajSiVzcan/ApjcbwtY3Ge6G86nWNxv/dbDT+
CMqo1WgcQHlqsdH4eijvh/LtTzQa3wHlX0H5grc2Gn0oH3qy0fhdKH8A5W++rdH4CijvgvIPoPzn
UP4hlH8C5Ueg/DiU90L5p1B+Esr/AOV9UH52tdH4ZShfsd5ovPzhlz/0gZffB/+Df34C//PD73n5
PS+/6+Wvfvk9P/yul1+E/+2/XBnMZzzyqq967OYjjU/sbQ8+ff/1vcf2k8abGq/6qtf3Vr7oSuOz
6b8d+L3bw7f1v/iurblFNfHN6TXx3elvvcOD/w4D3363eYw2n4Z3P/Oz6Ed+cXDzDY/lUBqlb18D
376m8u0nw7ef/Fjjk7Q5mP9HXtVoPArlaSjfBuWDUP4G0EQK5cegPAK08einMI08DeUboPwklJ+C
8tNQfgbKZ/yVRuMdUN4N5TehfMFrGo0QSgplCOWroXwNlP8Ryu9B+X/daXvlw8fuAz6PfVpjv4vT
33gDzv8vvPeRxp+W33nl+f/589hjjUceeQTX4u9DWQDBmUF5L5Q/gfLvoax+aqPxdVB+BsqrP63R
+BQob4PyRVA2obwDyrdB+edQfhLKI69tNN4MZQAlgZK+lmXKj7+W5congFx5DMonvm5man3lw7w/
4OOsf5yLdSjvgvIrUD7v0xuNL4PyDVC+EcrPQfnMz2g0vgTKd0D536C85TMbjReh/CiUP4Ny/bMa
jeegfDGUd0L5EijPQ/lSKPeg/EdQvgzKl0MJoex+1sy9feXDvD/g48w/zkUHShdKBGUPyj6UHpQY
ygtQ7kPpQxlASaCkUIZQXoSSQcmhFFBGUA6gHEJ5AOWnoPz3UP7K6xuN10A5BeXzoQSvn7m3r3yY
9wd8nPnHuYih/GMo/wHK2mc3Gt8E5WehvP6vwrqF8v1QfhfK0l8D3R7Kv4Dyb6C89XNAp4Pyc1D+
FMr1z200vhnK+6F88ueBjIDybii/DeWNbwAagvLfQfmzN8zc21c+zPsDPs7841zc+OuNxrdA+VUo
pz8f1juUH4byp1CuBzCnUN4P5Qu+APgBlH8C5WUo66dBbkD5V1DeD+VXofwalDe+sdH4QigDKAmU
FMqPQXnkCxuNt0P5B184c29f+TDvD/g4849z8etQ3vQmmCsoPwql8TcajQ0ofx/KB6B84eMwl1AS
KCmUIZQXoWRQcigFlBGUAyiHUB5AOYLyEpS/CeUroPwtKH8byt+B8pWPz9zbVz7M+wM+zvzjXHwV
lL8L5T+G8tVQvgbK10L5T6D8PShfB+XroXwDlG+E8k1Q3gXlm6F8C5RvhfL3oXwAyq9DedMZICEo
j0NZhXIVyldC+Z+gvO5so7F1dubevvJh3h/wceYf5+LdUH4DyhveDDoglP8Gyr+F8ta3NBpPQnkb
lNtQ7kD5dii/AeVzm7BXgPIGKG+G8hYoGZQfh/L/QHmqBTQE5WehvKYNdaF8E5RfhvJ552bu7Ssf
5v0BH2f+cS66UH4Ayh9CObcAn6FEUPagfDWUr4Hyg1B+CMq/g/LkItAElC9aZLvw14lt+Beh/BKU
X4byuUuw14PyLijfDOX9UD5vGfZ+UL5veebevvJh3h/wceYf5+IPoSysgAyH8oNQfgjKv4Vy5TzI
BCg/DeVTLzQanw3lr0L5cijfB+WPoFy6CDoBlCGUfwTlX0N54hLIEyjvg/Kqy43GO6CEUHahfD+U
//ryzL195cO8P+DjzD/Oxb+GcgU+/F0oPwPlM59oNJ6H8r1QfgHKv4Tyi1B+CcovQ/kV8f0Eb2X/
zwtQ7osf6Duh/JdQ/k8ob3kS9EMofxvK34HyPiive1ujcfdtM/f2lQ/z/oCPM/84F98B5aeh/AyU
34Py+1AWvgh0eCjvhfIhKP8HlIWnQLeH8lNQXr3aaDShtKDkUP4plFddbTRuQfk2KB+Acvpao7EE
ZRnKO6F8CZT/AsqvXpu5t698mPcHfJz5x7n4NSh/bQ14NJTvh/IHUP4Uyp9BWVsHvQ3Ku6B8M5Rv
gfKrUH4Nyhuvw94QypugLEFZhnIXyrNQvhPKb0M5c6PROAtlC8o2lH94Y+aevvKh0fjj2V6bPN3y
0KyjR9yZ/89DX/vfknnFOT0Dc/YqmKNTUD4A5begfPAm6PxQfgvK70P5N1D+BMq/h/IfoLxmA96H
Er290RhAKaB8DZSvhfJ1UL4TyndB+W4oPwjlh6H8KJSvfAb2l1D++MMf+sCH3/fhn/jwD7znw+/B
//zAh9/11R9+cf/D+y/i/3ew865f/Dufv1zjF/8yz8t+r9b/j5+rNe95Nb/0GDW/1Kv5/DFqPu/V
/A6qef/z4xlqPndM/794+p1ogx3Tz0aA6/F3oDRhHkdQfgLK62Au3wnlu6D8OpQPQvl8mK9dKP8M
ymNPNxrPQNmDsg/l+6H8X1DOw1z+LSg/AuVHoXwEyqlboDtCuQXl26H85q2ZSfdj9eGh19hJPvzR
bK899Ade67hi6tc/rr8Pw5z8CZR33wZdAMp3Q/keKJ+2CXQA5fugvACrMINyBOV3oPzvUD4E5feg
/BGUx+4C34DyOVDeBuVpKNeebTRuQ9mE8m4o/xmUr3on6BlQPvdLGo2Xf/flX4H//cxPvvyD3/3y
u7/25Xe//BXZy72X72YvfwV82Sg90znAnremIqJyfNN+t1fz3b75bnoLXa+Fbg203WNA2z3mSp4O
8ctL8Uhvg+1Z9a0X4S3hCn8d1+ObYK57UP5bKH8M5d9BefIOzBWUn4bymk1Yx1A+dZNp4os3mS6+
C8p3Q/me/4+d+wCr6sgCOD5XsUWNRgVLrDEWFI0du1EsSewtaixRsxG7IvZKRMVuVBSwUMSGFBsa
O2LXgL2BIioSRUB9Krag7n8e7OOiZHPN9xL22+/O29/CubwyeO7MnLnvERzCYeTpSA2A/vgBm3Aa
Z/BJJ2rATv9t9D36w5/owV8L3h3/xlFv/E6eG6K4zIc37qFqZ/buaIiJCEV2xnY7eOIuOjKu+6If
NiEBFRnXjtiHLN0Y+1iC8/i0uxCt8BUW42p3zVOXeYN0/yoaH/NXgn/qdTQGqpbRmVBc5qMU83EN
1MQETMQkTMYUTMU0OPVImb9Ppc7hhZjDLWEFOzRHfyzGJWTvyTGMhTuO4hhy9tLcfT0wdyCbav8n
1+EYVO3DOYD13wsxvS857scc/wNz+RDqd9xH66Hs49AdVxwYy4jAy1G8BgJHCxGEzSgyhnMBW1Bz
nBBNMQbO2DqV2gEhPwsR9rOs/28YkgwXDCf2G7b7GZbPN0yQ/0c0wtCLfUGntNV1knF1zZavcLq1
UMbvr3KO6dZqxwwfmfH6ODzdI0caHynv+eePHJnukUNNj0w7NsR07ENW/neOZudodgsN/RmUttK/
+xz5eY78FqXlWCyDDnDFUWTtTS2PbpiBmTiBjzk/umAlbuMTzpUe8MAKXMJlPEZVzqHRWI97KMb5
VA/1+2k+U/+p4H9sxjZvoGppq75q/pf5cMZxXMFVRCAS13AdUbiBaFTsL4Q1RsERo7EQIcjGfNEa
UxACA/L/i/ME38EXcajyo+bu64G5A9lU87/MRR98j/V4CNsBjHN0hSduwdpeiJ5wxGYkoQKzzCCs
xB7sxRXkHETNCFccQ87BjHtMhAdWDNbcWz0wdyCbKv8yF1Eoz/reHh3QEZ3QGV2GpNQAnql1wD3E
pdYD1akDamA2zqHoMCF6wwuxsBkuhAP24BIuo8QI6oIRmnurB+YOZFN//pdcuMEdYQiH5UjWdXjj
HuJQlTpvHA4gDveRi5rvI7SHPQbKGhDxqO7IHhH9sRH3YUNdaI+BozX3Vg/MHcimyr/MxVzMwwVY
Uq9bofCYlBq+X2od748ABCIJDcaSSwxEEJ6iFbX9TMxCGD4Zz/yBIRiKzTiKY+M191YPzB3Ipsq/
zMVjPEHNCezRsAPP0HAi+UNXrMId2Eyi9oM/AvAEtpOFcMJJfDyFtQPuiEJR9nnF0AdDMQxBUzX3
Vg/MHcimyr/MxQmcxCn8ijBYTmMewPfoi37wgwH1nYSYjoVYhEso+pMQdVEPTtiKbXiBJtOZF3AS
p1DQWXNv9cDcgWyq/Mtc2KIupuAILGawl0M7uOEa4pGAWjMZwxiOdViPe6g8i1oPe3ALt1HZhf0C
vOGDO6g4m/vN1txbPTB3IJsq/zIXo+CI0diPA8gxh30bcqEj3HAYR5BnLusCViMWNvN4PPZCmc8a
gHz4FqsRg1ILqBWwGUkLNPdWD8wdyKbKv8xFo4XM2TiJ/Iuo/bEKd1DpZ3KLNfDFCzRdzHyOY8i1
hPUeyxGKQ8ixlD0BvHELpV3JPfZhPw64au6tHpg7kE2Vf3n9fT458oAPefFHAIIQglzLhOiGOx7M
/3iCxqtZ0+EMF1TzpE7A463UjNvYT+BBMHsCBO9gTUAEIhGNWLTdKURn/A7lFyEmYBqOIxyVd7OH
RCSSHyffe3wvOep8csiO5DXJ7skL5PfO3KYljzHdhiSn/YJp19vnGa+3uxbbpTrmZfq0TfaUL6qf
zTH+7HzZ9n9wzT3tnjNM91Rfh5fx+9fhZ6R7X8D5Ax7p/IGfEUh7lZ9Mr5J2bLrpWOq7AhUPpOY5
57KUXHdCZ3SBO6JQeDl7QdiiLqZiJVYhDOHI5yZEd3ghGhXchbBDcyxAGHJz7nSBu4fms1UPzB3I
phr/Mhe3UG2FEL3RB764B+uVzP9wwG6IVUJ8hc7ogpFwwC+4hLzMBR+jK1YjFlWYF5rBDs3RwvOd
/iSpA42/gx5oDlTNmHU59tXv/8h8LMQiXEUEIlHCizGMimiJMdiN+/KYtxDfYTL8sAkJyOnDHIIK
+BYrcAP51jDfYxp8cHqN5u7rgbkD2VTjX+Yiry/jFl0xEZPghXB5fC31P1xxBMo6IWqgM6bhBE7i
GZ6jyXpqAoTDcgO1A7qjB76DL9Zu0NxbPTB3IJsq/zIXiXiAh7DdyLjGEbzGG7TyY47AeUTjJspv
EmIotuN3NPMXYizG4QBEAHM+5uE8buIWrAOFGBSoubd6YO5ANlX+ZS42wg9xqBYkxHjsxUu8QpPN
zN9oh+WIRPEtQvTFRhhQn9p/Cg7jAR7iEQxbU/YFDbal7A1mYtY2zb3VA3MHsqnyL3PhgrOw2k5d
B1dcR1n2b/YIxD7sRxKeoQl7OBdcRmn2cEMQAAMasn+bg8u4jRh8tkuIwViAhbs091YPzB3Ipsq/
zMVarEMc6rLf7oKucMMtVNjD2o2eWItE1NzLfI8QXMFVRCAS13AdUSi/j8djJBwwCvP2ae6tHpg7
kE2Vf3l95SZcyOkCnCM353EFURh8gNxhIibDN0SIM4iAz0EhnEKZz7HgCOMarthwlDkDvsc4V9Dg
uBCFT/Bi+A0JcD8pP/eZZEg0xHA7awj1DTV4GBZNNowy2PcydOKW1t206xc+xusX4/M++KBPT6Y9
3jXDv7OSV4fev/KyNN01m6UZXEdaYjrWQORULI3f/ffnlI+YcyqHoojFfOdcSclTyaK4+oHv/lBD
P+en6+d8U5+yp3zJ4O+/vE3/CqKkHIvzcRrRuIly+6ntEIx4JOALcj8FR5CD3LfHEnjBGzGoxPng
iO34HXU4LzqiE1wwG2dDNZ+pf2PwN150+Buf+q8EqmYc9cZTQrX/l/kockiIPvDEWZyD5WHmfHgj
FtaM62HYhmdoxPh2QhgsGePd4Q0frDmWMvYTUsd/Hca/Lepi8nHNXf+ngv+xjJk3ULUM8y/zsQVb
8RwtmJtnIwyFmaM/RzkMxV68QYtTjGl0xnLswE68RctfWQcQgEC8QNMwIZzhgRVhmrv+Nwb/1ylP
F6iaMevGWV+Vf7kOe2IDuQvGbdxDBHmLxjHyFQbrcCGqo8NZcogENDzHvh/r4I8oxODT80KUQZEL
nDsoeEmIomiFtnC6TM2AvleEGIA6V4Www3hMRUCEELvxAE9hH8n5ibcYdo01BrWus+fEhhtCtIkW
on+MrCfucovilvK3JMabn/HmlfrVz7CMGz+UX+aqagx1y/AvJVTrp6+pCkk7tiaDYytN62zasRWm
Y3+tgvHI4DndMji2XP0e1zvr/0bHAi5WA39txz9ZDTke7yI3uc2DXliLWCThGRqeZt+OWQiH1Rkh
KsMGY7AXFpwPbdEO7c+mnCceqedKDO4gFlk4P7Ke03z66oG5A9lU9b/MhR2aYzYuoAJjdwg2YQ/2
IgvjuBtWIQaVLlLXoyF6ohc8EYuqjPH26IDFiEBJxvsP2IrEy5p7qwfmDmRT5V/mohZzsBOWww27
sQeCubgDvPAbKjIX10U9TMQZfBrJHgQ/YkBkyly9JTJlvn6F35GMFszZ83Ecea9r7q0emDuQTZV/
mYuGaIQe+A7eOIAQvMYbvEXjKOp89IAbbqAs629P9II3fLAXsficddkOI7AKOxCByGjNvdUDcwey
qa//kIsnKHGTGgo+OIh4FLlFzYeuWIk7iMVv+OI2az/GYhzGIxSHkJvCIg/yogm+xCAMxja8itHc
Wz0wdyCb+u9/yMVAnE0Qolgi32P1Q/bvGPpIiFHISZ1siamYgfUIwOjHrAOIRTxCnghxFJ89pT7A
g2esF8+FmAuvF+wTcBzh2PKSPSN60bn+8P+dNQPxyUIYsP+1EIex8I0QrtiPw3iIJLx6K38RRdRG
AwThBVoqinDFCjTMoohm2I7duGLBz7IponouJeW/OXXundtxeXC/6bZddfOTP0rZQXj+Z9vwZ/uE
YGMNnq3y16pj2zM4ti2DY1szOLbFdOxD9g7v1/9rTXsV0UiOxaZ3qP0QhoKx1PawgQOCEYKDyPUb
dR2WIwKl7rL2wx+PkP2eEDnQFktxEcXi2OfBBbMRhkL3NZ+temDuQDbV+Je56I6pmIZjyBUvRCd4
IBqv8QZ2zBGzEY7TOJOQMm8UTUyZO37Av/AjgvAcpTnJymAAAvEE9R5q7q0emDuQTZV/mYtmsIML
LqD4I+ZkbMBGPEQjJr3GmIlZOI/CzPmd0QW+eAxb5v8p8IQX7sOCtSAbvsVqRD/V3Fs9MHcgmyr/
Mhc3UT6JOh0jsRvPUZz1uwT6Yx3ikYDEZylru+3zlPX9J0yHM8JQiPW9OxwwCuuxAY9QizW/xUvN
vdUDcweyqfIvc9ESc3EWWbmzBVrDHbuwG1cRgTLUaIOxC9cRhZLUawMQgFdoSt02BxfxBE9hRc1W
GL3h80Zzb/XA3IFsqvzLXDxDXerpyZiH+QiHFfV0f/gjAIGpdfbz1Fq7KTV2M9hhLq6gNHV2c7SA
C04jEtfwHC/QOKuitbd6YO5ANlX+ZS56oTc8sAIrcRMV2C8NgxvccRbnEI/i7KP6YhZ+QRxyZFdE
NVRHW0zFUeTKoYgv0BdLsCWHnv9MC2RT5V/mIgIFciqiA2ZiFlwwG3MwF/NwEZdQkv1zKZRGK3yF
ZbiBCh8pYiQcsAdZczMfoAXm4yIK59Hzn2mBbKr8y2shtfElWqIn+qESuasMGwyAPQZiGLkbjQt5
OW9Q+2NF2KIemuQjzxgAewzEG1jkV0RF2KAemsANq/ErwlDoE0UUgyigiG8KKMbPht01XDwl/3fQ
sNPg62FYZJi8iO+SDKNSb/bv/l5/+u7pZtM7n+rPVcn4/c9VBXDftEcGmB6ZdmyP8TqKmDI93bPJ
+P1n25PuU1qBGTzbDtOzpR3b+QGvsDPdK/ibXuH96z9Bae//lpNjsT4aYCbCUJC8tkFbLEMIDiI3
OW6LdliGG4iGQo6zoA2W4wYKk9Mi+BJN0Rf9sB6J+fXxn2mBbOr3/8hFHcbdBIQgGa/xBm9Tx+PX
qWNyKVyxDL9gFzitRDu4wR8BCEQIDiJbIR6LJbiGspacE5Z6/jMtkE2V/29S8/kMyShFzsrBDs3R
AsHka4WVIvKUpJYvpYjQMooYXI7jyFaeuqGCItbibBXOGRyooYi7CG2giOPY0ZicN1GE55fUg005
D5opwro5NSGatOJ18DUeMDs9RcPW7Cswpo0iJsEJp9ooqZ/vYUEIMYQkGYKT+Bps/GxPiKvB1TDX
4DTM4GS8BctfUj1jtuzol8GM+SjdjPnIONfKe6Yde2g69s7KYsXKYqVeWR780T1zc8/cGv+7ru+9
g3DwA+b/g+l+my3vzf8ZvmdQSY7FphgAewQiCHdRjJx3wWKE4hAOIw73Ub2wImpgBNYiBgWLsJaj
ERpjGuZhPsLwGrZF9fGfaYFsqvEvc+EAf1zDdUThBioUo26DA0bBEavhiZtIQCLKf6qI4diEKJQo
rog+WI3bsC7BngBBSETtknr+My2QTZV/mYvR2I6nqM38PhZ7YVFaEa2xFNegMO+3hw+O4yXqfqaI
cdgCA74uy74fG3AFBT6nLoQL9uMFbMrp+c+0QDZV/mUu7DEQg8qlrOvbU9f213iDt6jJOj8caxGN
fKz338AJ+2BAlYqK+BHuCENOa0XkwkfIjTzoBDdrPf+ZFsimyr/MxU2UqKSIkuiAjvDARvhhE+7D
rrIiFuISPrKhdsMY+CMAgXiChtSAMxCOG4jGTdzCbcRU0fOfaYFsqvzLXNxBLKpWpSbHeEzARHjD
B3G4j3jU/EIRQxCKItUU0Q3uuIQC1RXRAzuRmz1AFyzELtzCZzV5bE09/5kWyKbKv8zFUAzDcGxH
EurX4hzARIQiEQ9Qs7YiJiME2etQD8AdkTDgMWrbch8c/jc79x0uRXX3AfwMHUMRpYPSSwSNUhQR
FAQBC1WwECkXqdKr0kG6SEcFqSpRigoRlaKIWAhFNIAgCGggqCASpWMS5f0MF3UT0/7I8973fZ79
wYfl7M4Os/M958zM7nLJUiUKdXiUCUxkUpVk/mnWiCsh/ziLXeym+PVRKEFJuvAKf+QgZavqH6zg
HDld119MUyYwkV0UrRaFe7iXPvTlNUL1KNRjPNurJ/NPs0ZcCfnHWRS+MQot6EwXlnKKqje5fucd
staIQgOmsZBFfE3lmuYI1pLhZuf/TGQ7n/E5X3CIw1SoZQ6plcw/zRpxJeQfZzGIwQzhVVawklXs
YCdH+RPVa0fhYTZw8S1RaMZM9nOUP3FtHetjBaepVjcK49hGoXrR+feu/sOtTTb+2424EvKPs5jP
U6xiNZlvNdaZyi52U+C2KLRiIUf5K9+R/3aP0ZLn+JpKd8ifIQy98P7txgvv4V5aPwq56yfzT7NG
XInf/5VFHlryNHvZx7dxRtRqEIWxbCV3Q8cJBjKIt8ncKAo3U4txvE+2xlHITkMe5xOKN4lCR17m
TJNk/mnWiCsh/3hM5pfzEzKZQ/OmUWhNpbsc/5nLIa69Owq57olCPgYzggH3Gtvc1zwKbej4a+d7
jGvhHJ/7W0ahB4NaW563yZ7i/JD325lf2utvXNHB9Ucnz+vpvIHSvVxHDnLuyZHBzjGG6IM8PDYK
75FvnOPUdOeUj5mnGD4/Cpt55inXrk9HocjiKPTiTVKWRWHJsh8+O/ri2N4f/rLtx1/uenvZnLfj
26nxHz/8Tm2Ef/b/PErmOf9xz99+npL681tO/PTzW/5uqdTPfX62VOHEpX726E+f6hz/Z58y/eyb
Dsd+XPJffv5zfTwWb7ozCm1px2JOUEAfKEgnXuRLjlCxmes56jKBreTWP+7jSWYxmzkX+s4XF/rP
NfpPBSry4N3J8Z9mjbgSxn+cxeukN54LUJAWLOZrchnfl9CcRRwlu7GegybM5FVWsIe9XG4OaMdr
/Jm/UOO+KIzhfXK2SOafZo24EvKPs2jKfN5jC5/xOWXN3UN4h7N8y42tojCaLeQwn9/JXN5kHW9d
mOezpaTO9Xdx94U5vwc9eTUlmX+aNeJKyD/OYi/7KN7GMZxnWMARTnOGsxS8Pwq30JZ2tGcsL7Od
D9nBGUq3tSx1qEsnZrKSVW2T+adZI66E/OMsVrOX3M7JKlKJytzNCJ7mGRawic1c4rytAZOYzJT2
qedzey6c05VyTleaMnThBU5RsqPHOibzT7NGXAn5x1l0YDRj2MQvnIs3pBvd6cF0HmMfpR+QKUs5
ySmqdtZXWE+OLvoOc9lP2a5ReIDlnOHGbsn806wRV+L//5DFSDaQqXsUbmcyi1jMUa7p4bqKNZyj
nmu00YxhbM/U67ZtF67dCrt2u4zLacezfE2V3q4beZMsfZL5p1kjroT84ywaMo0dFOwbhSu5ir6s
IV2/KNRiFGvJ/KDn8Bg7ueyhKLTmOY5SqX8U+jGVaewizwDXiCzg6IBk/mnWiCvx+9+yqDwwCgN4
m4sGRaE+09hDwcFRKEQLFnCIw3w5OPW9mUpDUt+fGcJQhrGR7zlH7aHmCLZScFgU7mfJsGT+adaI
KyH/OItjVB0ehf4sZgnfUPlhufIuOUa4TuQJ9lJ8ZBRSGMZwFrOEk1QeFYVBrCXLaMcLJrGTvGOi
kG9MMv80a8SVkH+cRQue4jBn+TbOh+vGOm4zhKEMY/jY1PdhN194LzbPOJmOS31P9iZqMIYPyP2I
63+eZBYHKT/ecWV8Mv80a8SVkH+cxeuER12rM5aN5Jjg+o4pfETRia4TWMYZKk0yzunPG+znACUn
W44XOE31Kc4V2cIlU/UHZk1N5p9mjbgS8o+zOEj5aa73WEGYHoWbGc5yXuaV6amfuZybnvq5y63c
xu1MYRfFHnedx3L+TM0novAIW8g9w/kf8zgwI5l/mjXiSsg/zqLczCj0YQYz2UexJ6PQiZc4Q7VZ
jgO8RebZUbiF+2nLGMbyAbnnOJ6wgMPkmev4wF3MYS4H5ibzT7NGXIn5y6LcvCj05CVOUHW+rBnK
sPmpn69uuvAZa+6nZEpe7mE2n1HuaetgPk9xgLLPRKEzy/mCQ5RfEIXuC5L5p1kjroT84yxWcI66
v4nCRLaT61nHaypzLUNYT7bnzPncwXT2UnxhFDryKBPYTr5FUbiBarSiNY/xOFsXJfNPs0ZcCfnH
WWwj/2LnbpSiNGUoS8/Fqd+leI3XWcPXfMOlS8wH1KcBfenHTJ5kI5vI+HwUMlGUYtR+Ppl/mjXi
Ssg/zuIWxvIEM5jJIhaznt+R9QXne9zOdLaxnYIvRqE581nFanaxmzxLo3ANFejFK/yB/UuT+adZ
I66E/OMsSi+LQkta0XpZ6nemFi9L/d7USU5xmqq/jUIPerKKI3xF5ZccH1jDG2RcLnMq0p81vEH0
srHPwy8n80+zRlyJ7//J9VtKrorC8/yV61cbz/yerasv/Kzkz4999PerSdb/dmXK2/G7lA9+9l2+
zBl6829+/vM//P5flngsjuBdcrziPJ7yVGUwi1jMSv7Mza+6HmAWs1nMca5d4XqAe+nAUk6Rb6Vz
CwpQkEIUXpkc/2nWiCth/MdZXMblFKEjnXiJ5bzM79jARxwmpzmiGGUoy+3cQX3a0I1hTGMu81jE
Nrbz4apk/mnWiCsh/ziLz/iWfOb6K6myOvUY0IQe9KQXvelDX/rxIA/RnwEMZBCDGcJQhjGchxnB
SEatTuafZo24EvKPsxjNBwnH+/9wTWdDsv7/VRQS889QPlwzuWNUZNnvf1V02R+qF1s2LmNxSkwe
l7EkpZaFkG/ZO+nyk23yO+n+3cqTlaxkJStZyUpWspKVrGQlK1nJSlaykvV/rUanuzhcEqIwO+QM
GbTTn783w79+UrKS9V+u2iHUOHYundtsP3a+TKFB6B56ha4hJXTRjt9+LBxq3ZY/tKoXZUhx27Ve
1gzd6uXK0NttH7f/aL01axw/91S83ow/3JdXq11ob619rbdPKBoa+XsvOpz/s0fo6L46/u1uHo2r
SehU48S55W5/Wku20NSybayhnaX/dksLh3ynjaRKOzOF6KL0XVL/ktE9KfHd6cIvLFM2dK5x8tw6
t+HHdWY+v56i4Y7QKfQ+/2//8Jbro6FdjSgcd5tN6/x7tyFXqGcb6ls6fgW9zr+mH7aij1/tQltL
XWdkZ19fIVw8PX3ZzK9f1CjHwVwP5clWYH7hSkU3lLivzDdXjLwqf4XnK9e4Pvx95bevc4eGt2UI
jWlJq3rZ7ffc5x/dGn/TI4RH0oWs4ZyK74subPHtTGcfpd3ZnZVEHkxHem5nPG+yjk1s5lJ7qDEz
+ZRiUk2hOz0YySjW8yVHuNqG9GI1ZzhLzUwhjGMzWTOHcBE3chONaMx01vImUZYQrqAr3ehOD1ax
mvRZzYtk5BYmspPCF4XQivE8yvvkFnBz5vBHygmtJyv4njrZQ7ibe7iX5vya+2hBS1rRmhTacD9t
aUd7OtCRTjxAZ7rQlW50pwc96UVv+tCXfjzIQ6zjLX6RQ58mO0UoSide4i/UzhnCBLaQ92Lbx0IO
UyFXCAN5hxNUu0RGvM931Lk0hEnsIrPu04iZHKBEHtvNK3xP3bwhTGY3xfN5XbzMd9TJbz3solgB
r5vl/JVbCsqEj9jFbj6mRKEQStKVbnRnJVHhEG5jGnspdZnHWUG4PIRbmcoeShbxfLrRnR70pBe9
6UNf+vEgD9GfAQxkEIMZwlCGMZyHGcFIRjGaMYxlHI8wnkeZwEQmMZkpTGUPeylV1FijDDW5mWFs
JFcxcxgz+YTLiutHPM9JqpUIoTo30oCGPM4nFCqpj3MZV1COXqziW2qUst1sIVtpz2UCOyhcRp9l
CUf5lcmuLe1oz0hG8QIvcprqv7Qd3EQNxvEI2/mQHRS6wrhgIpPYReFyxgnPcZSry8uEF3iRk1S9
0v5mEzmuCiEf+WnNc3xDlV/JmB78luPccLWs2ECWa8wdpNCGhSziOFUrWI7N5K5oTPMsW9nGdj5k
Bzv5iKKV9GUeoDNdmMd8DlGusj7GEIaygVzXhtCMOWxiM19yhKuv0/dYzed8wdVV9EnWkdVEX54r
6c3rZHE4qc909lD8BmOaitxLc+aym48pUM3rZyFf8R3fU7u67JnIJCazm48pcaNxRCkqUJFm3MU8
DlD2phB+SRPuZDYHKV9DlrxBrpq2iafZyz6K3CwL1pChVgh30J4OLORPVK5tDPIqKzhH9lv0A+rz
OJ9Sqo55lWWc4jTV6xqvbCJbPc8jBzm5h3t5mmdYwFu8TbZbvUbacD+LeZ8PyHWb/cp8DnGVg+YN
VGMA68h0h/HIXL6gcX19lRQW8xVlG8iR10nX0HGVqWyjUCPzKfWYwi6KNLb/qUh/BjCQQQxmCEMZ
xnA2sZncTULIQ15qUZs2TGEHme50H/2YwbusJ0tT/ZtGTOdd0jeTB3czklFsIMddITRlFgfIdbd9
y0yeZAc7Oc5V95h3eZZDFLw3hOupygh+x0fsYjcfs4e97OMTPqVsc32OXvSmDxNZS8Zf258MZi3H
uPg+20VznuEwV7ZwzKYVz/I117X0WmjGXPbzy1bmBHqzlFOUae04yyxW8xofkSVF9kxnPVnaeG0M
YCZPso/S95tzaURjmnAnTWnGXOZxiMN8yTVt9QHGspUC7Zx3MI/PKN/e8Y3V7GAnl3WQN08wg/fY
Qp6OMmI+hzjMVZ0cB3mDw3xJ1gecg9GQDnTkBY5wTWd9mjYs5EvKO5HuQEceYTzbydNVHyQf+Umh
DUt4nhc4xQ3dPJ+OvMhJ6nbX1xjNe+TqYT/RmS4s5V3Wc5wTVOxp7uEVTlOtl+fQjNkcpHxv/Ycl
PM8JrutjDLGRHH3lwgz2UaCf/kpLutCVF9nARjaxmffI86DXSytak8IijlH1IccbJjKJHRTo7xjG
9Qzjt7zEWW4a4PWzkU1cOtB2UoXBvEOGQfo9DXiCPRzhKyoNtq104zc8yyHKDdFfWM1+DlBuqH7O
fJ7iIGWHWY5e9KYPa3iDzMP1cbLSmCd4m3fI9rB9zhw+o/wIz+c1opH2Lzm5izn8kSKjZM9STlF9
tP3BRi4eo88ym4NcMdb6eJpnOEvNcfYV68n6iPx4nHW8Rebx+jLz2U/RR/17vM4a3mAtWSZ4Pk24
k6bMYB/5JurDXEcVhjCL2bzHFnJOcoxhHp9SZrL5l9pM4L3/Ye/Oo3Ws4niBP08pZKrMoqRMpUHG
ZEimJiVDRVEqpGSKlIQGQ5kyO8ZjKBxDQuYxEkLmeeZkPGQeCvfTdf+4f9z7913rrt1an9bq/b7P
8+5n798e3tVa7yFdX/dlCAd4vJ/5TAPGcpTC/T0nrZjLf1/QnqUWtWlJK2azhQwD9St1GEEyjwxy
rqQSlalCb/qwnR3sJM9g7aQQVWnLXI7/99oQaycdmEgSJ0mToJ8oyKsMZS+Zhtqf6cRo1pFhmLZR
h/Z8zijW/vf6cPXDAJYTj7DWUYtOrGQVF7lEhZHO3Kwl6yh7Eq9Tl3qMZRwpnOI0pRK1n+Vc4zrV
RusLNrKP/RQYY34zg394Zqz9kXYsIhqnL+nBRvZzgMI/2BOYwESO8fiPznDM5wpXqTBe3/ASg9hJ
7gnWCSZwhjITzW2WcYrT/M0ZzvJUkjWNLnSlG+vJNkldMIDdPDDZesoUFrCQC1ykwhTXsZW8U62n
TOYMZX9yhmcrBzlEvmnOu/SiN+P4gWOU/tnnUofBHKDgdGPBG4wjhWIz9CWL2cZ2drCTXexmDwVm
up6WtKI1PejJOvaxn/y/GCtmcoKTPDZL37Gc1LPNd/oxikQO8dAcawcz+IeSc9UfNelGd9aTY575
yEjWs4Gs8z0XiSRTeIH1lelcpNxCaxZryLpIXZLIaMYwlpOkUHKxuqQ0HZjGz1yiyhLtYA3ZlzqH
k59mzOc6VX7VZmoxiF+YxQ2qLjNOTGYKl6m43DmLBIZyhHS/Wat5k3Ekc4GLlF2hxujKWrL9bo+g
CG2ZT6qV6pmXeJkaJDCUQxwmmVtWOUNSicp0ZxMFV6s9kpjHfG75w5xmOId4aI2apyxv8CYjSebR
tT6XGvRlB/euc3bnZ1Io/qcxYRCDmcs8ovWuYxR/UWiDseBJ2vMn92z0/ZdGNKYJ0/iZq/zDv1TZ
pD75nQybtZVy1KUeiSxiMde4zg3Kb1Ej1GUwe3lgq+fkTRIZzXySeXCbPqQFw/mFHezkHHm2O1sx
miWcIMcO5zXqMIzDJPMXj+00lnxCOz5lKb+SbpfaIAMVeJqmfMB0rlJxt7FkDZn3qA+K0IqZLGYJ
afcaJwaxg/v26Vcm8Te37zdfqU5/NpPrgHWRbnRnDVkO6i860okVpD1kHpDAPq5xnUqHXcda1vEn
68mZ7N68y3s0YiqXyPuX7z40ZgrnePKIfYBKdGMTuY/qZ8YzgdOUO2Y86UJXNpL9uPlJbcZyllIn
rFGMZBTHSXXSGY5XGcE+9lMgxVjTkrlcIvcp48w7/MAJTpLCKUqdVsd8yVd8zRqy/K3vaEVrfmQ8
f1P8jBqmKt+xnlvPahcvMIQ5zGU7O7j/nFpgDrvZw73n9R2TuUrFC/YSNnOO82S7qF+oz2guUvqS
NZAe9GQt2S57RiYxmSlM5RKXqXjFuFCJ79hG3qvWF6rQjXXsZBeXuEz5f8wt6pPAUIaxn4L/Ws8Z
zBDWs4ET5L6mHunKbI6R+rp9nqJUpyO/kfaGucXb9GMaO/jv/9zVoAtd6UZ3vuU7erCZLdwbx9F9
5KUazzKQvRS8JY5a0op53HprHFWmCj3ZTPZUcVSGp+jCGjLfFkcvUp2BLGYJ6W73Gi8xkL3sI04d
R7fwIoPYS/Y0cZSDp6nI2zTkR1IomTaOPmMx/3KN69wguiOOnuN5+jOAgcxmDlE6bWAwk5jMFBaz
hNvSu5Z+7OKBDNpBRRrThClM5Qi5MsZRbfqylF9ZxjGOUzRTHD1BC8ZxiMx3xlEWylGeTvSgJ2u4
Rqm79D2T2MVu9rCXgnfHUSFa0ZqPGcFI9nOSFApkjqPmJLGHPFniqAEjOEjhrMY4682/7pxCiWxx
1IYZnKdE9jj6hPmkyhFHL9CfXcQ54+hlRvM7VyidK47aMY0zPHdPHHVkPNu4O7dxphsLuUyRPPqU
92nKB8xgJte4zg2K3etZGMc+Mt1nnOjMAs7wSN44asQQ1pDm/jhKyx2kIz01Gcx+8uQzB6jBKyQw
gYkkcZxKD8RRb7Zwx4NxVIG2TGIyUzhH2fxx9A1r2cs+9nOAgxziMMk8WiCOHuNTPqM9iYzmGMc5
QbGCcfQhS8lRKI5eK3TzL6lu4e7CcVSXWaR7SA3SmzkcIN/DrqUZH9GcGVygTBGfS3uWksIpij0S
Rx1YzO2PGl+GsJMznKXEY97DMtI8HkdV6UkvetOH7ewgX1Hzhwdpxi8c4jCFntAmZnODTMXi6E5q
04vebCdv8Th6nbq0oS3ziUpYr+jBJnKXjKP6fEgzfuICZUqZXywnbWlzn/5MYCKnKfGkvmAxqcqo
W3qziWT+4ghHOcYTT+krOvAFHZnFbOYwly1sJYVTlCsbR1+xkjvLxVEdEjhACqcoWd79mM1Fylaw
brORe56Oo3dJZDRzmUfqip6JfmxnBzmfiaO3mEAK/3KNHJVkNGA8pyle2WfSkU50ZhWryVzFOkVW
GjCG3ezhClepVNX+wgayVDMGfE4HlpH62Th6hkp8yzrSPxdHGXiZQewl3/PWAGZyiQovxNF7NCKJ
c+R80XpLU6ZynBMUq64OqUYvNpDlpTh6k6EMYzgjGMkRjlL0ZWNJMdqxgFtr+BxyUZ8kTnPXK+Yc
9ZhIChlqxlFGapLALGazi93cW+vmX1CZz1X+4ena1j/WkamOeieRNawlmb8o9KoxYTmXuUL51+zp
rCXj63FUi5EsYSm/soz0dbWNV3mN12lJK2axmz3kq6fPGcs4TnCRS1wm1xv2e9574+Zf72hMd2ay
ic1s4RIF3vReqlKNpiQwh7nMYzdZ6utvilOC1/iaMYxlHKv5g7sbqG368D196ccudpP/LZ9LQZox
hQs8+LaMJnSlG6tJ11DN0ZwWDW/+9YkBDGx4868dFHjHffiJ81ygzLvaxwoyvqe9jOQAhRrZr5jB
Jco3tgewktub2C/5nokkkULR9637LOQGzzbVRrrRnW/ZyCZyf2CP4l4a8SOnKf2hOcsS0jTzTPRn
C7k+sg/yKG1ZyC3NzT+6sJjULVzDQLaSp6UzFuNJoXgr+z796M92srY2nxhHCiU+tmayjDvaONu1
ufmL0bva3PzF6HuozziOcozjnKD4J66nI53ozCquc4PK7fQFG8j1qXWPSZyhzGf2LpKYxN+UaO9e
/EbGz80pBrObfB2cHenMlyQxifOU+MI6xWLSdDQW9GEr2To5h1Kf0RzjMle4SqnOxoGOdKIzX/IV
f7CGrF+6D9mpwNN040+yfGV+MpRhHKbI18aMBUTfmEt0ZxUZu5gL9GUbebuqb6ZxieLdPA+fsYgD
HOTB7t7HFC5S7lv1xlru/u7mr7H+77/E2pzZ/Pfrn8/wJTOYyS/M4gZRL/skz/NCr5u/Crqd+3ub
E8zgKhX7+N7BWrJ8r4YYxUEe7mtPZwgJ7OH+ftYOpnOJsv31Mb+SeoA1hnd5j25050+yDDRWjOMY
WQfpe15lBCM5yMODrYNM5xxlhrg/nejMl6zmD7IkuA/ZeJ3hJPPwUPcgkdEcpNAwZw9mcISjFBlu
nWE2N6g2wrmCTdw1Uv9TgpJ0ZAXpR+lPXmQAu8mXaJ2mJ73YRPbRvndRlrd4m4EMYgMbyTHG+JOf
AhSk0Jibv8rXmvksYCGn+ZvMYz031XmJtnxCAkNZxWpuG2eNIy/3U5kqdGcwQ0hgIkms4HfS/qBm
eIEBbPzh5q/L5frR3koic5nHdnaQdbx1kydozS/s5wAFJjib8BZv05AkJnGeC1ykzETrPa2YywlO
UiJJ3yfd/BWzRdw2yedQjM9YyCLiyTd/pewrvuY3Mk5RCxShDF8wkSTmcJVnpqophjGcJM5S8ic1
RV2a8BMXyD7NuJGTXNxDbvJwL/fxPk2Zzgxm8jsr2cYxMv1sXChIIV7gRarzDs3pTH9GMoqJbGQT
m0nmCtmn21MozZPUpCWtaM3HtKEtn9COT/mM9nxOB76YfvNXoTrRmS/5iq/5hi505U/Ws4mhURRl
ejy6+U/n/yXN//yP1P/HLApZyEIWspCFLGQhC1nIQhaykIUsZCELWcj+X2VRyEIWspCFLGQhC1nI
QhaykIUsZCELWchCFrKQhSxkIQtZyEIWspCFLGQhC1nIQhaykIUsZCELWchCFrKQhSxkIQtZyEIW
spCFLGQhC1nIQhaykIUsZCELWchCFrKQhSxkIQtZyEIWspCFLGQhC1nIQhaykIUsZCELWchCFrKQ
hSxkIQtZyEIWspCFLGQhC1nIQhaykIUsZCELWchCFrKQhSxkIQtZyEIWspCFLGQhC1nIQhaykIUs
ZCELWchCFrKQhSxkIQtZyEIWspCFLGQhC1nIQhaykIUsZCELWchCFrKQhSxkIQtZyEIWspCFLGQh
C1nIQhaykIUsZCELWchCFrKQhSxkIQtZyEIWspCFLGQhC1nIQhaykIUsZCELWchCFrKQhSxkIQtZ
yEIWspCFLGQhC1nIQhaykIUsZCELWchCFrKQhSxkIQtZyEIWspCFLGQhC1nIQhaykIUsZCELWchC
FrKQ/X+XRf+X7L9/xdzCCwxgDwW82II5xMJbuJUX6MESlrKaP8h8axS9QgL7uD9VFDWkBS35hi6s
4DgnePy2KGrNPC5xmYq3R9G3/EFarbuD8lSgBq8wgMUsIU4TRQ/xEc1pQUvmMo9b00ZRKm6jCr3Z
Su47ougtetCTdWRJF0X1GMEhHk4fRa2YzXWqZoii13idutTjDd6kPg14i7dpyDu8y3s0ojFNeJ+m
fMCHNOMjmtOClrSiNR/ThrZ8Qjs+ZSm/ki5jFKUnA/eRl6ZM5x8qZ4qiXqwl253axwSO8cRdUfQ5
yzlH2buNEeu4RtXMUdSH7aTOov9J4CAPZNVufuE61bJF0ffsIF92z8VMrlE1h/uwnftzem5m8C9V
chkTtrGdHezkgXui6EE+ojktmEOcO4qepz+7yZ9Hzmyie6PoOfqxiwfvcz3NaUFLWtGaj2lDWz6h
HZ/yGe35nA58QUc60Zkv+Yqv+YYudKUb3fmW7+hBT3rRmz58T1/6sYvd5M9rrlGQijxDZ1Zx1/1R
VJME9pInnzpiMucp+0AUlaM8L/Eyg9jLPQ+qcfLwEA/Tmrlc4en82s1a0hdwLb3YQu6CapZJpPBY
If9NIxrzDV2YwlQuUq6wdlCBp/mW79jEZrZwz0PmBb3pw3ZyP2yeMJ4UHi9iTJjCVM5T5hH9zWoy
PhpF2cnB24znb0o/Zoxpyc+c5anHjRUrSVPU2kFD3mECEzlLmSe8jz/IUsyc5kc2sJFNbGYLW9lG
3uJqmQ/4kGaMIpGjPFxCjdGRTqzkrpJRVIcRrOYPjnOCx0upPebxF0d4vLSaZClpn4yiIjzCxywg
TZkoqs4AdpHvKXOaYtSlHiPZwU5ylvX8TOAk17hO5XLGnt704Xt2sJMHyptH5OcJilGHVxnFQQpV
iKLC1KQWwzlMkaeNJYu4q6I2MYbd7OG+Z4wFC0lVKYpepDFNmMApSlQ2B5nFbG6QoYo6oDqD2Ef+
qtZVpnGBi5SrZr6ymvTPuo6MZOJ16jKGsYzjV5aR/jnPyDu8SxLr+JO7ntevJHKUR22aT1GW9izl
9hfNR0ZyhFeqq1UaksRJCr1kHFnALS/bV+nHRu6pYT3lWfqynfte0f8U4zPa8zkd+IKOdKIzX7Ka
P8hSM4qyko1KVOYd+rKF22t5jU8Ywm+sIE1t9U0NBvAbt9YxHrzGN3RhJRlfjaLaDOMgd72mb0lg
KFvYylkefd26y48cJVfdKHqSMnzN72xjOzvYyS52s4e97KNQPTVHaz6mDb1ZzG1v6E++YDFnuPNN
7aIeYznGI/Xt2bzFj5ymVAPPQh1GcoDCb1kT+JifuEDBt+2zDGMe89lGmobGngGsIM07no32JDCU
PRR415pLDV6hJrWoTR1GMoqjHOM4Rd9TA3RnAzkbOXcwimSKNLa/MY8tbCVPE+PNYIawhrVkfd8Y
kchRjvFoU/sgizjGcdJ+4AzGyzThfaZwgqIfqmneYQLHKdLM+3if7+jBJrJ+pAbJTg4a8g6TmMwU
LvBUc9fzPlM5T7UWao2urOGulvqJD2nGT/zGCs5yjmKtrD38wkXKtnYNdRjOYYp8rH6YxGTOUaqN
OcQqMrY1LgxhDzk/Ua80oBkfMZWVrGI1f7CGrO08L2/xNg2ZyBnKfGq/oTd92ELOz+xhPElnfmY6
l6nQ3vOzitVk/lw7Kc0XLCdVB3XPSwxmFyc4SfEvtJXm/MCPHOXhjuqFeRzgIA93UuckMprDFOrs
fbTmY9qwkEWk/lKNk5ZXGMwylpP+K33OCJIp8rXrmU/8jf4lE68ygkPc18XY8xMXKNdVf7CKO7up
WYZzmIe6ux9jGMtlKn6rr1hB2u+MH4NYyq+k7qGWSeQAeXv6PBawkEUsJk0v11OTWtRmCHvI3lsN
U4rSdGQYw1nDWjL1sccwin0U/N76S2V6sYZ0fd2XIRzg8X7mMw0Yy1EK9/ectGIu/31Be5Za1KYl
rZjNFjIM1K/UYQTJPDLIuZJKVKYKvenDdnawkzyDtZNCVKUtczn+32tDrJ10YCJJnCRNgn6iIK8y
lL1kGmp/phOjWUeGYdpGHdrzOaNY+9/rw9UPA1hOPMJaRy06sZJVXOQSFUY6c7OWrKPsSbxOXeox
lnGkcIrTlErUfpZzjetUG60v2Mg+9lNgjPnNDP7hmbH2R9qxiGicvqQHG9nPAQr/YE9gAhM5xuM/
OsMxnytcpcJ4fcNLDGInuSdYJ5jAGcpMNLdZxilO8zdnOMtTSdY0utCVbqwn2yR1wQB288Bk6ylT
WMBCLnCRClNcx1byTrWeMpkzlP3JGZ6tHOQQ+aY579KL3ozjB45R+mefSx0Gc4CC040FbzCOFIrN
0JcsZhvb2cFOdrGbPRSY6Xpa0orW9KAn69jHfvL/YqyYyQlO8tgsfcdyUs823+nHKBI5xENzrB3M
4B9KzlV/1KQb3VlPjnnmIyNZzwayzvdcJJJM4QXWV6ZzkXILrVmsIesidUkioxnDWE6SQsnF6pLS
dGAaP3OJKku0gzVkX+ocTn6aMZ/rVPlVm6nFIH5hFjeousw4MZkpXKbicucsEhjKEdL9Zq3mTcaR
zAUuUnaFGqMra8n2uz2CIrRlPqlWqmde4mVqkMBQDnGYZG5Z5QxJJSrTnU0UXK32SGIe87nlD3Oa
4RzioTVqnrK8wZuMJJlH1/pcatCXHdy7ztmdn0mh+J/GhEEMZi7ziNa7jlH8RaENxoInac+f3LPR
918a0ZgmTONnrvIP/1Jlk/rkdzJs1lbKUZd6JLKIxVzjOjcov0WNUJfB7OWBrZ6TN0lkNPNJ5sFt
+pAWDOcXdrCTc+TZ7mzFaJZwghw7nNeowzAOk8xfPLbTWPIJ7fiUpfxKul1qgwxU4Gma8gHTuUrF
3caSNWTeoz4oQitmspglpN1rnBjEDu7bp1+ZxN/cvt98pTr92UyuA9ZFutGdNWQ5qL/oSCdWkPaQ
eUAC+7jGdSoddh1rWcefrCdnsnvzLu/RiKlcIu9fvvvQmCmc48kj9gEq0Y1N5D6qnxnPBE5T7pjx
pAtd2Uj24+YntRnLWUqdsEYxklEcJ9VJZzheZQT72E+BFGNNS+ZyidynjDPv8AMnOEkKpyh1Wh3z
JV/xNWvI8re+oxWt+ZHx/E3xM2qYqnzHem49q128wBDmMJft7OD+c2qBOexmD/ee13dM5ioVL9hL
2Mw5zpPton6hPqO5SOlL1kB60JO1ZLvsGZnEZKYwlUtcpuIV40IlvmMbea9aX6hCN9axk11c4jLl
/zG3qE8CQxnGfgr+az1nMENYzwZOkPuaeqQrszlG6uv2eYpSnY78Rtob5hZv049p7ODuKI5q0IWu
dKM73/IdPdjMFu6N4+g+8lKNZxnIXgreEkctacU8br01jipThZ5sJnuqOCrDU3RhDZlvi6MXqc5A
FrOEdLd7jZcYyF72EaeOo1t4kUHsJXuaOMrB01TkbRryIymUTBtHn7GYf7nGdW4Q3RFHz/E8/RnA
QGYzhyidNjCYSUxmCotZwm3pXUs/dvFABu2gIo1pwhSmcoRcGeOoNn1Zyq8s4xjHKZopjp6gBeM4
ROY74ygL5ShPJ3rQkzVco9Rd+p5J7GI3e9hLwbvjqBCtaM3HjGAk+zlJCgUyx1FzkthDnixx1IAR
HKRwVmPMVFIokS2O2jCD85TIHkefMJ9UOeLoBfqzizhnHL3MaH7nCqVzxVE7pnGG5+6Jo46MZxt3
5zbOdGMhlymSR5/yPk35gBnM5BrXuUGxez0L49hHpvuME51ZwBkeyRtHjRjCGtLcH0dpuYN0pKcm
g9lPnnzmADV4hQQmMJEkjlPpgTjqzRbueDCOKtCWSUxmCucomz+OvmEte9nHfg5wkEMcJplHC8TR
Y3zKZ7QnkdEc4zgnKFYwjj5kKTkKxdFrDGELdxeOo7rMIt1DapDezOEA+R52Lc34iObM4AJlivhc
2rOUFE5R7JE46sBibn/U+DKEnZzhLCUe8x6WkebxOKpKT3rRmz5sZwf5ipo/PEgzfuEQhyn0hDYx
mxtkKhZHd1KbXvRmO3mLx9Hr1KUNbZlPVMJ6RQ82kbtkHNXnQ5rxExcoU8r8YjlpS5v79GcCEzlN
iSf1BYtJVUbd0ptNJPMXRzjKMZ54Sl/RgS/oyCxmM4e5bGErKZyiXNk4+oqV3FkujuqQwAFSOEXJ
8u7HbC5StoJ1m43c83QcvUsio5nLPFJX9Ez0Yzs7yPlMHL3FBFL4l2vkqCSjAeM5TfHKPpOOdKIz
q1hN5irWKbLSgDHsZg9XuEqlqvYXNpClmjHgczqwjNTPxtEzVOJb1pH+uTjKwMsMYi/5nrcGMJNL
VHghjt6jEUmcI+eL1luaMpXjnKBYdXVINXqxgSwvxdGbDGUYwxnBSI5wlKIvG0uK0Y4F3FrD55CL
+iRxmrteMeeox0RSyFAzjjJSkwRmMZtd7ObeWtrPfK7yD0/Xtv6xjkx11DuJrGEtyfxFoVeNCcu5
zBXKv2ZPZy0ZX4+jWoxkCUv5lWWkr6ttvMprvE5LWjGL3ewhXz19zljGcYKLXOIyud6w3/MejWhM
d2ayic1s4RIF3vReqlKNpiQwh7nMYzdZ6utvilOC1/iaMYxlHKv5g7sbqG368D196ccudpP/LZ9L
QZoxhQs8+LaMJnSlG6tJ11DN0ZwWtGQAA9lDgXfch584zwXKvKt9rCDje9rLSA5QqJH9ihlconxj
ewArub2J/ZLvmUgSKRR937rPQm7wbFNtpBvd+ZaN/A927QO+prt/4Pj3kIgtIsSIGqVSe8WIUTVa
s8bDo5QSEYQmkUFjxQ01ahMrEjEaNFFFYs9WlceqkRbFgyC1iqpNyfO5N9fr1X8fgvSRf8S3r9f7
vtx8cs79nXHP+Z28Gg/nvtyj8AY8sRjXUKsf31l8g6yfsE0IxU8o7M19EBUxAJuRyYfvH0ZhK+x8
WQYzcBhF+zPHwhJcQXU/7vuYhlAcRX5/vk+IwhW4BnDNxHfIHsjcDqE4jsIDuF6hK6JwARdxCZdR
fSDLIxjDYcIuPEISGn/KvsBBFA7iuoeluA63Qdy7EIOl+A2ug1kXvkfuIXynMAsnUHIoc0eYEIIY
LMVNuA7jOoWtyBrMscBkHEaB4cxD0RULcBF3cQ/3UdPEcUAwhsOEEIzAHuxF/hDWAye8gwYYg/1w
HMH3E3MQjnMoP5Jjhk2Qz/guYSx2IfcovguYiiMoPprzGytwB9XHsD0YhC1IwBmUGsvvYRluo97n
nG/YB4dxjAHhOIfy4/luYC1kAtdthCAOq7Aaa5AEmch9Es3RAlNxFCUm8Z1AHO7j3ck8d2AfHKdw
DmEezqDcVO7pmI0w/BslpnHtQCzuoG4o+xjbYDedaww80BNjMBb74TiDY4UoXET+mex7/BNzEYkz
KDeL6yBicQNus1k/hsOEEOzGHjiGsR4UwIeIQCLKzWEdmI8FOAOXcOYeiMN5XED5CK4zWIskvD+X
eQXikTeS/Q9X1EAwdiDnPPYnWmI6TqDkfK7TmICJiIfTAp67UBfd0B0zMBMHcQgFF3L8URpvoQxc
4Ad/bMQmbMY1/IZ8X7DdaIUPMAADEYY52IXdsI3iGofiKIHGaIKxmIXZCEM0YrADO5FtEecMWmA6
DiEehRdzb8V8rMcGHMXPyL+E6yaqwh+rcRoJeOtL5ibohu5wRwyW4iZu4Tbcorneww/rcRm/wjWG
fY/N2ALbpXwOqmEQNmMLjK/YRozASHyP3Ms4F1AebhiGaMRgHe6j4decUwhHBGLwO2os55xCJ/TG
ctyC0wqOGwqhMIrAGUXxBoqhD7wQiziswk78C0dwEXlWclxQBi5ogZZohR7wgQmhiMQ8ROMQ4vEj
EnEPTrHcU1ALtdEO/eEHfwQgEAMwEJ8iCIMwGEMwFMMQjOEwIQQjMBKfYRRGYz8OIB6z5an/76E2
bdq0adOmTZs2bdq0adOmTZs2bdq0adOmTZs2bdq0adOmTZs2bdq0adOmTZs2bdq0adOmTZu2dNtM
2tKspfYYvSrHLyNsgzZt2rRllCapXE6bNm3atGnTpk3bq9Mklctp0/b/3V7nc/d13nbdLxm3pXT8
9Nimj6bHQZs2bdq0adOmTZs2bdpeXpNULvc6t7TeZ2n9edq0aXu+JqlcTlvGbSmdE3q+aNOmTZs2
bdq0adOmTZu29NQklcultqX0ealtGWEsGaGl9X7J6J+n7dVuGf18yQjblxG24XXevlelpfVxSOvP
0/a/bS/j+L2Mdb6Mz0tpOW3atGnTln6a6SW0tP68V6Wlp2OU2vYyxvky1vkyWkY/fq/KNqSn9jL2
2ctYpzZt2rRpSz9NUrmcNm3atGnTllGbpHK5V2Wdab1caltKn5fWY0ntONPTOrVpS88tted8Sstp
06ZNmzZt2rRp06ZNmzZt2rRp05bemsnQpk2bNm3atGnTpk2bNm3atGnT9rq01P4NSZs2bdq0adOm
TZs2bdq0adOmTZs2bdq0adOmTZs2bdq0adOmTZs2bdq0adOmTZs2bdq0adOmTZs2bdq0adOmTZs2
bdq0adOmTZs2bdq0adOmTZs2bdq0adOmTZs2bdq0adOmTdur1OQpTbKIDG0iMralSJHOInuniBxb
zzK7RHqcFamSzZDmDobsbmnI0hWGHNxgyEkWu4rfcNO8DkOEX5NcyAdnFEN5NDCSP+NSThHbvKwz
v0jxAiKPioqElmIoZUTavc0ylUSWVBOJri3Sob7Iz41EIt4XOdVKpHM7kaMfimTtIuLmLlLBU2RO
X9blK9InUGRHkMjXwXz2SBG/sSK3Jopsmc42hIk0iRT5YaFI1BIRr2Uio2NFJq0TGb9J5MC3bPtO
1rVXJPNBkSuH2YYTbP8pkftsu+MlkdrXGAMb2eSeyIJHIvUzG7LCzhCnnIZcsTekQX5DahYyxPUN
Q8qXNmTW24acrWBIv2qGTK5lSHw9Q6o1MsSjqSGOrQy5086QTzsakqerIWvcDVnf05DSfQyp72NI
1kDWOZj9bGL9YwwZMN6Q8GmGnJmNSEN8o9j/0YY0/sqQhOWGjFhliPM6Q35cb8ioDcnHhqFLAs6A
TZBzSMQvOI8LuAg2TS7jV1wBmynX8Ttu4BZu4w7ugs2X+3iAP/AQ7A5JMh9+jnEmsGvEBrbIAnaT
ZEV25AC7THIjD9h1khecWuIIdqMUgBMKgl0qhVEERcHuleIogZJ4E6XALpe3UAYuYPdLWZQDh0Eq
ohIqowqqgkMj1eGKGqgJDpXUhhvqoC44dFIf7+BdNASHUhobyee0eX+fNu+DJAfLD3xOVMxtz5fh
xC9Dc2cRX97l5V2XRPO7/tZ3zpZ3ftZ3J86Z3/lbl3M+b34X8Hg5Swt83CzrHGBtpcISC2SRgdbW
0/LuU2s7N9v8LsjaoizvBllbT8u7wY/XYnk3xPqb52aZ3w19vJzl3bDHvxlhfhf8+PMs74ZbWxTv
9nU3xCxhkSHGYkPsrdysGixJNn5psqlwWGlI4dhkla3iY827lrPJfEnhNZP57JLMllcby09sLa9Z
LK92ltesltdsltccltfsltecltdclmVzW/6dx/Jqb3nNa3k9zJjNLjHu7IyzoFUDq2ZLkk1hvDOt
CjHuN2OT1bR6PO7kUYtlxObx2iafKJaRmsdpHmUOfss8QvP4zKMzj808MvO48lqXqWX9d1nTAH8f
twCPPp7e7gEVvL08/H0DfHsFVvDw9Xbz7dXLy8PTLcDb3T8w0L13gI2pkVfgIDHVs37eiyybzdTm
E3cPzw/cvT2TV5AldStoP6g/K2ho3RMvsoLcJg/fAT6B/oMq+Hv29vL1ERM3AnF4wbXYmvqbhyEm
dq7RvusZ8361rCR5d/7fV4fn/red5TXLn37y37+TfAKY/+NuKs3hyY98wfkjXKXlmvXs8GRFPujP
GbEOG5CJMyOIs2EYfuIWeRRvcJssiWOFuQVhWjGRWbjuwuUZDbhtjsU4HELPstwO4VmOWx2GYyRW
Yz0+Ki/SDZkqsC34Hbcxo6JIGDpzC/4Y0ViG3pVF+uEIt+Vi1bn0wgvvu4q0wJoaIhtRjrO1EoZg
ONbVEdmEuLoia9GKE6otesIHU3AUx1CSW31FzpequMgt/wpmNRYJR56mIh3RCQuwh6nAfsxozXgR
0lZkF/YgH1OEImiIVnBHf0zBPPyIz/7B/kKjDmwDFnfk5ziF6xCmGBVQFwHYgAS4dGIqg904jFMo
w1TpbfhhCCYiAluwDzYfMSY0x1SsQxIyM4Wp052pC6KxDMfcOXt6MDZMQAcPkbmYh/PI24vbI9y8
RN5DQW+R7uiBGBhMgbJi5UCRndiLXxDAtCgIgSaRQdg6gTOZqVE2tEXlmdzW0ARd0Id54ieYOIcx
45257Ct0nsd5g9+jGXsM+wejMGG5yHRsi+Nz8W+cwRdbmFbgCipv5baLGmjzL5Gu6IswzMFZlNjH
rRy9D4mswErcxxKmYxuxHYm4ilJHOEZohEWIRomfmQZgGEyYgMkIOsbPcIA5UCHmQIXhgavMXWsy
36mFEKxivrMWX99luoO7eJf5zhHmOZdxD87Md8qiO3wwGnfwAPOZA0XhPh6hGteCmvDDIIzHFNRj
ntQAHdEZCTiHKcyZQmEwb7LBOEzEfhxCHeZR9XEfD+HKnKo2pmEm7Jl7OyIOa7ENO8zzceZdzdAc
obiOW8jJXMwepeGC1czLvsUq5u/nkZ05WmHUR3t0xVTMwUJsxDeYzTwuHKuwFnuwH0eQgF9xG7ns
udnjGu7AhXlfZTRAU4QjGquwDT/hGE7iLHIxL3RFBwRiOuIQj5twZM7oig4YiJnYiOOwYS5ZCi3Q
D8NgQijicBwPYDDftENr+GIB9mE/OjIP7YxeCIQ9c1IH5EchTOR5JxxLsBqPYDBnLYgi6Ith+Axx
WIWHaMMzkgnbsAMncBrhzHGjsQwrcA4XsJp573oUYe77FmrgXbTBR/BCAEZgAsKxCF9hOWKxGvvx
I47jJG7hLuyZT+dDWVRAJubWtigEZ7RDB3RCFxzASSQiCS7MwcvDA14IQjAmYg7mYhGWYQU2Ygsu
4xruw445vAOc8AZKog7eQVf0xWAEIxKLsRHf4TTO4iHMzwHF8SbqoQHa4B/ojb4Yh1BEYRm2Yx9O
4yz+QBIK8TzhDFfUQnO0Qg94IgLzsAUJuIYbyMkziD0qox5aoS2mYDo2YAtCeE6ehAQk4hYewo7n
l+xoh274AQfhzTNNfxg819igFprgSyxF+cqGVIIH+mMypsOX5x9/3MAd2PMs5IhiPA+VxxiMhx3P
RjnxgGcjt5rsO3TCxxiOUdiO3chWi0dZfID2CMXm2mwXvocNz1PZ0QytMQnTEY+LuIrVPF+txw3c
gYnnq1EYg13YjXxNWDdmY24zQ+Yj8gOuV7iAkq051qgCm/ZcM7AV25GpoyE5sAXfmX3I9nXid/BP
TPuY7wJOoHQ3vuMYhr04iEM4jL48KARgI77BSZxFEmzc+a4gG0qiLDz7GNIHn3uxDsTDua8hYYhA
pDfXGezk0f8wyvryvUO+QM4VdEAownEclwcYUn0g5yGCUXYoxxkjTFx7sRf5Q/iujWUfoco4fh9r
JrCvcRtJkIkcD6zHJhyexHmHWpP5riH3dMaAkNnse+yBYxjfR3yI7ohAFBLxK8rNMaQq/DA4kv2H
zzEBcViD4ziJovMYN3rO57uIKMTiGE7hLh5hzAK+o/gOO2CzkHMTxVAKLvCDPzai4ReGvAcP9MNy
rMZPURxb3MUf8ONhLwi/4QH68KDXHx2WsG1w/9KQGCzFTTjFcEzhgkpojtYotoJx4CAO4zaSYLeS
fbgy+QHX/LBYCmVQDi3QBj3gCR/4wYSRCMVMRGIhovEVDuEIEnEB95CDh04H1EVbdIAvRmO+9aHU
Tpxh+yfOf/n3kzyr/51lnvR7f/2Z7VM8rT9ruRfZ1pT207PWmdK2PWnZFxnr313+7/jrem2e8vnP
Ws/zfEZqPGvd/+uxPktafMbzSKsxpHRsijzhZ09bNqWfPe2znjW2vy73rPXZypN//0XGlJrxPc/n
vMh2vcgYU9p+M7H+NcvH+testX/6a1YktiIiM0/+OIOLKGXDkzp6whu7EI8BtiJDsRk70DiLyPuY
gCn4AYcxi4+dZ/fffyXLinxoiraYilD8jNMoll2kJHqgH5xyiBRHV3hiPpahYk6RKgjEEGzAZvOf
DXOJZEYztMqV/Fe5UWiZR6QdwhCNEzD/fbGkvUhZ9IY3VmE77uIR6ucVeQ8j8TkO4DSaOoi0wUSE
4hguoV0+kc6Yhbk4h5vo4si+xAIswVU8QtX8IrUQBBO+xS5kLyDigNmIQAISUdaJbcd/2rsLuCyy
vYHjZwgDC2PNVbGxMFgLdW3FAJPFRkyQUiTMBUQUxcIOFEFxVURFsVjFFsVADOzGLmww4P0NBy7u
6q7o9V73897n+PnyPD4x58ycmPo/MyPgjh3YDd2iQuSEOX7BNSSgcjHqEc5ww+/YBZ3i1AXM0Lm4
PEp5J/0oZSC8DYSYjqM4iUJlqAtYwAoBCMF13IZBWSGqwQZOWI+NeA2lHJ/DPbiWZ16xA7vwDtkr
CNEC7piMqTiBc8hXUYgS6AIrzEQAzuE6SleiDjEEw7EOO5GI1yhgKMSPqI1G8MV0JOOd4cdHYc/h
SmV5NHYaLuISSlcVogLWIALG1fguRsITr6FUF6IxmmMiJuMY4pDfSIgfMAD2WIMwPEcSrGrQ5hGB
KLzEe/xck2UDH/ghCKtxBCeQqxbTRTdYYQjc8RJJaFyb8sAHvjiO0yhiLERx+GMuVmOT8cdHi4dj
FIzqCFEPbhiLIziOZXWFWIGTuArjekI0xFh4YCcOwri+EHUwE3OwH4eRuwHLBiuxCruwB7lMhNCH
AQzRCd2wHltxBTdQoaEQNWCCNvDHQgRhDdo1ou1gIOwQivV4grdo05ixofHHR7UNURMmaINghKBa
E9oSAhGEE7iJO0jEyKa0JezBfhRqRvtFb/RHCFahbHP6Jhzggt3Yi44t6L8IxSY8xQvUb0k9whez
0KkVYyIWYhlu4BYMWwtRFXZwxyZsh34b+gKaojX8MRvHENfm46P1vyEcBdvSTtAb/TAbcxGOCDzA
IxRqJ0RJTMJkLEcEHuARarUXogHGYSr24wxydhAiDzrDEkFYg/t4gjAz8sITvEJVc9oh3DASu3AE
uh0Zz2AOC5zBVczpxDLCRVzp9OVnHRp2o/4xDhNwxIK2jvy/0IdgiV5YiiDcwj30tqQ/Wn7+LMXX
npXo05vpYyVW4SFeo2YfyozVWAuTvowhCMIKJOA+qlnRp3EZCahrzViBsfDGtf5C3EXlASzzAR+f
1XiCVPgNZDzFaZxFv0GMQQhGGO7iAWoMpg3DBWOwE3swaAhtFUsQgqI21Al6YwCWIxS1bCkjRsMD
exCDp0hBl6G0XWzAFjyGsBPiJzREKDbiEV6hhj2vwwljcRjHEY9L9h+fpdmA7UhCCn52FKIZwrEV
r/EO7Zxogyg0TIhisEQfHEYs6g7nuxgJD2zDbiRDOAvRBO0QiCDcwV3UGMEygCvG4hXew8SFcsAb
PjiKE8jvSv6wQE8sxgpcwz2UdmOaGAw7t4/PPm1wZ+xAEt6i2UjWQ5iMabiEBBiMYszBJExGKnKO
ZoxBJxQfw7oEFmOpUyxFMG7gHhqOYxsSIzAGD/ACRr+yvoALRmEndsPIg9fhhnG4g8eo6sny8ZRn
y7yQ24sxDd3QC4uwFJbj6TdYhjW4i0TU8KatwA1joDOBdRB6oBeWIRi3cQ9lfehrsIMT7uEhkpCK
phOFaAVvTMZRxKHgJJYJeqMfAhGCO3gMN1/mF2+RipaThWgPX0zDYZxC7imM57BAL+j5McajCyyx
HGEoN5VlBju4TP34LKIlemIxgnANd1B6OmMEvDARy7EBvWYI0RfBCMENJKLKTMY1zMRsxOI88voz
TsISfbAYK/AQz2E8i/qEA5yxEmvxAMloMJv+AheMxg7sgfYcIbKhPTqjFwYjEvvQfS7jB5ZhFe5C
zPvjWVMrGMxnGwL9YI9grMaTBSynhXwWZvDGFETjOLov5vvYhv14jRSYBPAdjMMEHF3C+gLNl7LP
gCmIRtFAIUoFyrOzQ/AMyTBZxjgMD0xBNGLQLoj5hD8W4gwuo3Iw9QQnOGMLopAC7eUsK+yH9gra
CFrDHNPhjzO4iGoh1AXs4Y6HeKm+tpIxC2PghSgcQCry/ca6ER2wEMG4jBsYsIo6RSg24gVeo/Fq
lj08MREHEbtanp02WSPPTk/AKVxBsVDqCJYYiPkIwlVcR8W19F0MhTs2IAJ7EYPmYfQhlFvHOAVH
jMZ6bMMLvEGT9Szj9Zlnxc/jGipsoM3AAc6Yi0V4iOfq83D6BhJwH1U2Uh78hnAk4gXqbmJMwCiM
3yTPusdvkmfd76uvR7B8EYcrMNzMdiac4Iyt2Km+toVlCE9MQjRioLeVMR9dYIG5WILbeITq26hL
uMEdW7ALKRDb6WdoAwv0wqntMpDUOpJ+hSCsQdHfGfvQB65YgkAsx0pU20EZMQyjsRk70XQn7R/e
WIdYnEXRKMZD9IJ1lIw+eBAlow/q7KIfYD3eIBWmu9lGhh9mIxZnUXwP5YITnBGF3VD2MgbBFJ3Q
HTbQ2sf2ItqiPfwRirfQ2k+bQRtMxHTcx3MMOEBbQyjW4iGeo8VBpoXTOIuS0az3omWA6q/Yixjk
OkR5DsloigWHZBTFDTxEInIcZhxHPC6hSgzLE45wRxi2oecR6gCBCMFtPEL1o6wH0QKdEIRVuIv7
6nvHWOdiDoJxCbdR5jhjCSKwFYlIQb1Y+iW84YelCIX2CeYFXbEU9/AUVeNo6xgHH5zEZZQ6SR88
KaNE1p+UUSLJSEWeU9QP/BCDc9A/TTnREh2xHGvR7Az/xyKE4DpuomI88xYvo04i42XUSUK8jDop
d1ZGnTSH6Tm+jynwx0lcPSejT7ywD4dR+wJ94oKMQvGB/kXW3WiBttiMHWh5iXYCP8xCLM6i8GXa
NlwwFluxE12u0AaxEIG4hASUvUpdYwicsQ7heA7da9QlLDEPW3AW11HyOvOHAbBHLM6iyA3GTvRC
fxzGaeS+yXuwgCUCsBQ3cA+tE1jfwQ8bE2T0TdFbMvqmP2xgj3BswRuo0cm2cMQrJKPRHfo8psAf
8biM0ndpZxgEOzzDS7S4R1vCGdxE8ft8FisRhpdIhckDtgfgCV88whv0ecj6GCsQiuqPGO+wG9FI
Qc7HlBPuWIuIxzKaqO4TGU3kiSmYhlO4BKtExj+4wwPPkYJ6T6l7TMMcnMJlLH7GmIjdOIbyz9mv
gwPc8Tt2ocwL1hOwxQi8h85L1j+YgbO4iLfI8YrtE9hgBW4iGW/R8DV9Ah6YjBM4h2JJ5I1BGJok
o6NeJcnoqKbJ1DPMMA2zcQHXUe4NdYEpmIU4nMMNPEKzt6wncROPUeUd8/FORlvdfyejrUq8l9FW
Vu9ltJUP1qXQZ/AMySkyyqqVkFFWo4WMslqACooiDGGKBQjGUVxWMiOuqmopwhg7sRvZtBWRAzMw
D2dxHsV1FNEAvjoyQisWJ1FYVxGlsACLkTebIgpgAQJxG8/RMbsiumEhgnEdN1EyB+WEKSywGleQ
iOdokFMRTTEW3jn/GNFlqicjumYhAKvROZciemARliBHbkXkhhl64wquo2IeRdRES5jmkRFft5Ez
ryKKoRG65pURXzPzZkZ8HUQM/PMpYjnCsCtfZoRXEX1FlMB4TNaXkV7v9GWEl1n+zMguNaLrAdwK
UGe4iftIRbaC1Ce6wQXeuInHyF1YET+hG0ZgNjbiJJ6jYBHeRze4Yi4icQHaRRVRDu0wFLOwEReK
ysgv9ZcGauSXORyxDHtwsFhmBFgq9IrLSLABmIeliMXl4pkRYTYYh7kIQBg24y3UX8UURRUMg+uP
mZFj13E7PXJMT40Mg0V65NjG9Iixd9AtpYj8sERvuGA8DuEYbuERjEsron5pGWHmgRCsKS0jzWJR
2ID6gjFaYArm4ylewaKMInrhOV6hTFnaKwKwFIXKyQi0tuVk5NmccjLSLCOiLCOSrBXaYQw8y2dG
kjVBM0zC5PRIsssfRJKNq6gILwyvJCPIblaSEWJqRJihYWYkWEYE2EVDGflVtLKM+LKCE3ZUlhFd
+auw3NETQzEHIVVkxNY13KkiI7YM0yO1kqBVjedojv2IRt3qlBse8MJeHENOI+YZi7EUl3HHKDMy
ywMTcRBxyFVTET+gLSxqygitAFSqRf+slRmptQ07kIRctRm3YIzhGIlIHICWMW0DluiLaJzFRdxF
uZ+Yf/TGQLSvQ3vHdMxBPM7Dpy59HJvxoq6MAGtQT0aA/VpPRn7tqycjv3LUl5FfZvVl5Nes+jLi
S9tERnyZmsiIr2kmMuLrpImM+HqF8w1ZRmjaiOULH/jhCOJRsDFtFN1hjQQ8QIOfqRN4whdNmjCW
YSpm4gzOo1RTRZTFYLhiBVZBr5ki8qAzumIugvBjc9oz+sMWodiARLyB+qsfHVjDAWuwEc+QjHot
FdGwpYxcO9RSRqwVaMXnYYcQrMM1JKB1a8Yx+GEGirShzOiH0YjGceiZ0q4wFTMQhzPo0pY+gIUI
wHUkoEI72g/s4Iyt2IE3EO1Z1miNMETgFZJg34ExGeHYgbpmLGfMxBycxmVYmTNGmsvIu9vmMvKu
ZkfKDC/swj5k60RfRBg24RmSsbYzywGJeA2LLowfCMAKRCIKZbrSF2EDR0RhL1p0o10hDhdQwIIx
BZbog+VYjRM4jaq/KKI2vOCD7diHaBxBM0uWB07gPPJ3p9z4Bb0RhFXdZcRgrh4yYtACkdiHCj3J
A3ZwxGO8wA99qdO+MrLwQl8ZWVjeij6IWtiAGCThjZWMLPTBXhxGF2vmCbfwGEb9Wb/BBaOwFbvR
fADlhx9m4DjiUXggbRpWcMJKrMM9PEXNQYwjcMYo/I4YpCLHYKaJDpiKGcg7hOWMruiBBViFl3iL
BjbUDTzhjQM4jHy2LFN0QldbGQkZZysjIUsMpc/hJzhgFtZhG14jGT52zBsO4Rj07alzWKIHyjqw
TDEOXjiAo9BzpMxoj66YhjmOmZGW+ZxoX1iCUFzBLVQYxutYj014Ce3hbBfhZ/yKicjrzDoQJVEZ
A2GHtdiIl0hF4xGM/yjgwvJ0kRGds1xkROcFrHWlH7rKyE5jNxnZOQ6+CEEcTmOmO9scOI8LKDuS
9oRW6A87OGMTNiMZNUbRPtAWXvBDElLQeDRtHBMxGccQi8JjWFegN2wQiJVIwP0xmRGntnDDO6Si
8TjKggmYiGgkodOv5I35CMAV3MBqD+oaT/HKQ0awxnjKCNZCXrQNVMB0zEc8Lqmvj1eEAfpgMF4j
FcberEswFj7Yhxhkn0CfhRm6Ygbm4Qcftu1hgYFYgCBcQQIqTaSPwBEu2IpIpMB4EnWCs6jqS3+G
I0YiAlvxHiloOZl6xzTMxGnEo9gUliWCsQEP8AjGfoy9iMJeZJ/KuIO26AxfzJ0qI3pToEbymmIB
AnAVt2E4neljOFwQiR1QZtC/YYr2OI2LKDGTtoyVWId7SERtf9okxsADCbgPw1mMnRiGEdiOHUhB
rtmMBegIH0zFYcTOzows7oAesIEz4nEeJeYy9mMghiAUYUjEa4yZx7Y/as+nXNiOA3gDnQWUCW0X
yMjlwwtk5HLBhcwbLGGFxViOhIUycrnKIhm5PAwj4Ykai1mnwxkzEImdcAugjSEKu5BtCcsTldEa
5rDAXMzHBegvpV/BYGlmZLQPfFEwkPUEFiMQN3ELlZfRruAEV5QKol+iKdoFyQjocsEyAnpYsIyA
jsQLpGD0cvoi4nAOFVYwT/CDP9YhElEr6XMrZcTz6lUy4vk5WqxhfjAVMzAplH0ETA+jnYXJyOdq
G2Rkc8VwGdncLlxGNluHy8hmh3AZ2ewRLiObZ4XLyOYl4TKyeVW4jGyOC5eRzQnhMrI5KfxzEc0f
RqYZf6Gv/Z7Gp/1Tluf3LMff5a2dhe//u77HvP9V5OjXfu9rpvW5PD73uW/tfy3f7+l7z/P3zv9b
+v80L1/reyyD75Hn1+b9rcbm/7T/dvn+2/l9TZ5ZqzvtLEzpW8nqHGSt5F/mz9PMqs9NNys+N61v
lc+X5Pm5737uM/8tn6ufb11XX+J75Ps98vxcvt+rTP+kcvy5HX7PsvwT8v8r/7Ry/bfHk6xOPyv9
7UupKbG8/O2c+vsj9bdHxyOEuIl5e4XYDv0YGTtodEyIrriQHkN1Kz12yOCNEKZo1EQRHaDdSREl
8S79+J16vO7EJ4/ZZZWaMq5RJKei/u5cEXdF11oiIyla6Rf20xHyEnu30t/IC918RcTP9euJwF4N
xE9NTIRu1bbiZLmOwq60rdAZ4ijEuPEiqsdU0brzajGn+Dbx3jpWHDG/KUbmeSxSmyqe8hpJqrHX
1VgX+TyjXGrS0k/PLo4CdlIv4tdUvR6kllAvGmchHIUdnIQ7fwuJZsJF2ItBwkCY8ZqjcBbWYqCo
LmqLesJI1ORfvbT/qd/PIT5OSvqU1ZSaqv76Vv37x+e6aFN4JqXT0sqmraujq6Wt88REXGs2UuzO
mfFdWXbRTdgKB8ozghKZ8+jOYxdK5kC5WDiiDtPRErq6ipaSPZuWbvb0r+uLzOSp/ukqRvGd/nzT
nv8ZV0zLPVc2HS016aSSe4tP5N6M+bclJ/U7berMVDz1KHFOHS3dHNo6zOa1t++jhxZI/06gkPNt
Rl7q0rOlfAOEDTkKUT3VONVA5B1ccogQTeqk5Z1dO6eWlq6Wzl/m3YJvuqblP4i/GXMvRFma0XDf
qUVF4gkytEn79IYRBSap1Odaoi1/bzUV4uFwtTlcEWrD09b/QfvPr6qvqClBVyTqiw8vD6hJWU8h
2XZnjxARwsurwE9/fOc5w4zq30la/3qm1PburNbTp3pdZjLtrv6tnJiqDgUMmQmMOU/Kq/0v1eNT
1CFHTbX/MBW1zPKKsWpqltb2XGh9TrREO9qiZfoztY0P4f9t+J/aWofx/D/xr316SbI+PmX9k5r0
bZN6ecFsH7TbjKTgmk/gs+SONvqh/jlE1UqbztfktUOKvEip+v5MIVv8AiGvT5sg5EozUci1hr4i
L3H6oyIveGqoyBVqfUVet7a7Ii91OpBHPR4nKPIatjMVeR3bAEWudFcp8nq2GxS5qtjGY0Eedysy
f7XXlOKxJcwHubg7OdsZWPLH1nGIQRtnJ9dhBllPatstlT4fIv15UaH+oNF+kIGZk6Oz9cDqtesZ
1axZr3rtjPc//OyHz9V5NXdydrC2z/p0an+Qp1nGlWkNOqZdlVadqYG83lT9wqt1tfUynts8ub1d
77jy4XO1PtQ6Uh/V9Yj6qK5L0lcimqRJmqRJmqRJmqRJmqRJmqRJmvQ/lv5u/1/rzLEzAUYl9GfP
Z/+/WvK6mkLe9Sh3+vs2Qu6XDxNyf3+CkPv7U4U8RjAHRRAgRNp9dFYIuf++Vsj99wgUxg4h9/f3
CzntAn/ar1dfa+VsO2DECCf1IHLaPqx6NFR9vJL+f/XInfqYr1KutLxEep6feiylL8vfXHyL4wW5
9WVp1ZKqc9/Nll18kbH/rUmapEmapEmapEmapEmapEmapEma9E9Iafv54u/vL6ueZ1b3ndX9cHU/
XT0nr+736wu5n6+ew1f35wvhByH36dX9fvUcdjEURwn8iJJC7imXhgHKCDVGSohyKI8KqIhKMERl
VEFVVEN1GKGGkDcgryXkOXNjqAE9dVAX9YS8520DqDEzDdEIjfEzmgh57ryZkMcBWggZP9AKrdEG
plCjs9pBjQvoINR4MSHM0RGd0BldhBqxpka/CWGBX2Ap0q6rLXqgJ3qhN/qgL6zQD9bojwFQz+0P
wmAMEfL4ii2GirTrRqfFtTlAPQiixqkNw3CRdo1mMQIucIUb1NizkRiF0RiDsRiHX+EhZKidF8bD
W8jjNz6YCDU4zReTMQV+Qh7XmYbpmCFk/Ic/ZmG2kMd75oq0a9qK+ULGhSzEIiwW8jjQEiwVavyd
EMsQhGAsF/L4UAhW4jeswmqsQaiQx43CsA7rsQHh2IhNQh5P2owt2IptIu06oiISvwt5nGknorAL
u7EHe7FPyONPB3AQ0TiEw4jBERzFMRxHLE4gDidxCqdxBvE4i3M4jwu4iEu4LOQxq6u4Jr7uzuqP
hby7eqL44x3WX4gvu8u62vkV9Vib8td3Ws+p/PFu63mUT99xvaDy+buuq3FAJRV55/XSMFC+7O7r
1ZRvewf2psrHd2FvpajHRFNT2/BoirZop6Rd60h0gFn6+x157ITO6IKu6AYL/AJLRcY39UBP9EJv
9EFfWKEfrNEfAxQZBzUIgzFEkdGithgKO9jDQZE3zXHCMAyHM0bABa5wgztGYhRGYwzGYhx+hQc8
4YXx8FZk/JUPJmISfDEZU+CH9OuDiOmYocg4LX/MwmzMwVzMw3wswEIswmJFxnMtwVIEYhmCEIzl
WIEQrFTkTYHUuK/VWINQrEUY1mG9IuPBwrERmxCBzdiiyBsKqXFi2xGJ37EDOxGFXYqMH9uDvdiH
/TiAg4hWZKzbYcTgCI7iGI4jFicQh5M4hdM4g3icxTmcxwVcxCVcxhVcxTVcxw3cRAJu4Tbu4C7u
4T4e4CEe4bEib5aUiKd4hud4gZd4hddIQjLe4C3e4T1SlPS4Za20aHehBW3oQBfZkB05kBN6yIXc
yIO8yAd95EcBFEQh/IDCKIKiKIbiKIEfURKlUBoGKIOyKIfyqICKqARDVEYVVEU1VIcRaqAmaqE2
jPET6qAu6qE+GsAEDdEIjfEzmqApmqE5WqAlWqE12sAUbdEO7dEBZjBHR3RCZ3RBV3SDBX6BJbqj
B3qiF3qjD/rCCv1gjf4YgIEYhMEYAhvYYijsYA8HOMIJwzAczhgBF7jCDe4YiVEYjTEYi3H4FR7w
hBfGwxsT4IOJmARfTMYU+GEqpmE6ZmAm/DELszEHczEP87EAC7EIixGAJVryBl+BWIYgBGM5ViAE
K/EbVmE11iAUaxGGdViPDQjHRmxCBDZjC7ZiG7YjEr9jB3YiSkveYEwdx/fwuBf7sB8HcBDR6e8f
5jEGR3AUx3Acsenvv/8LZ9Pfz/BPTeqvM5zYcjRgy9eRR+e0Lcasp8JsMWRMS92HyKYOGEJuWwm5
Kf2vpB9QSjdS77hyXiv9Zx5C3ea2Jldr8bVJj62XD+fnc59XU2t17NOXz2ux1W7NFrh92pb3l6e8
5K9OTt1nymr+5nxh/w25nGRs/kCWgxP7AK5pv55xTNuSz1oqTv7qlNT9tqzmryajKTJ/XfZc1FzV
X+iodd+W3AenlckhrWZs06Lx/zoZfsXy361mrS+f6340519Wnvrkr+63fkn+hz7IX0n75Y4D+1Id
aQVD/+5rn0wF0n4n9WXzr6bhn/vAF6SvyT8jqW33nzw+adJ/NinUvraebEN/HrvVYzSf/A2CQUun
Aa4Ogxxd0g4NmXVVX+OltD6lPjfKeN+ovnjRYOO3bOua9G3T/wFQSwECFAAUAAAACAAadk5CZu61
pLLXAAAAtgUAFwAAAAAAAAABACAAAAAAAAAAZHJhZnQtcmZjMzQ1NWJpcy1hbS5kb2NQSwUGAAAA
AAEAAQBFAAAA59cAAAAA

--_002_7D2F7D7ADBA812449F25F4A69922881C0650CFESESSMB203ericsso_--

From mary.ietf.barnes@gmail.com  Fri Feb 15 10:48:55 2013
Return-Path: <mary.ietf.barnes@gmail.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF0221F8801 for <dispatch@ietfa.amsl.com>; Fri, 15 Feb 2013 10:48:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.586
X-Spam-Level: 
X-Spam-Status: No, score=-103.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2ZKDCkM4Y1o for <dispatch@ietfa.amsl.com>; Fri, 15 Feb 2013 10:48:55 -0800 (PST)
Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by ietfa.amsl.com (Postfix) with ESMTP id E6AB121F877B for <dispatch@ietf.org>; Fri, 15 Feb 2013 10:48:54 -0800 (PST)
Received: by mail-qe0-f48.google.com with SMTP id 3so1572543qea.21 for <dispatch@ietf.org>; Fri, 15 Feb 2013 10:48:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=hMeY+0uVk8d44QjBNSfNvF3bbUrzWhj8X+Vzkf5IT8Q=; b=yeIrMt9lClUsyuSoyRWW2A1lTASBfFzHDbsQssii73+pXMHv82rpcCkj0EruQhPwxI uWM+6kevzaNM0hpFOi3SAdO3/Gjnv9dcEetpKhOKLQS1lX6tixkdcWhtxBvV08Q5Z02z TEXVIOq9QTfzPOgWBk0IkPtdQu8oA9f56EQJLeLq8zPFGDB2G4FyJT6+DRTdW4gLRtXi fYAC8sU9NDO/MMDmzpVbQ4tVhZxDjwj8BhDdAiUrT92PC7J13jJHXEKiruEt781BRvm8 SjymE82tozaDEHekLrp/Hes4+W+YVbsT6QBLXZA11b1g07gVp7srykARi5HFB9IoRaT/ cbqw==
MIME-Version: 1.0
X-Received: by 10.229.201.200 with SMTP id fb8mr271900qcb.122.1360954134442; Fri, 15 Feb 2013 10:48:54 -0800 (PST)
Received: by 10.49.131.199 with HTTP; Fri, 15 Feb 2013 10:48:54 -0800 (PST)
In-Reply-To: <20130215184321.8607.90539.idtracker@ietfa.amsl.com>
References: <20130215184321.8607.90539.idtracker@ietfa.amsl.com>
Date: Fri, 15 Feb 2013 12:48:54 -0600
Message-ID: <CAHBDyN7NPDca2UwhmgXHmRJFjYSxhmm6Vo_HfCpfOnTG4fUGeQ@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: DISPATCH <dispatch@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Subject: [dispatch] Fwd: Internet Draft Initial Version (-00) Cut-Off Monday, February 18
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Feb 2013 18:48:55 -0000

As a reminder, charter proposals are due the end of today (from folks
that let us know they had a topic they are pursuing) and obviously any
relevant drafts due by Monday.
Mary.

---------- Forwarded message ----------
From: Internet-Drafts Administrator <internet-drafts@ietf.org>
Date: Fri, Feb 15, 2013 at 12:43 PM
Subject: Internet Draft Initial Version (-00) Cut-Off Monday, February 18
To: IETF Announcement List <ietf-announce@ietf.org>
Cc: ietf@ietf.org



This is a reminder that the Internet Draft Initial Version (-00) cut-
off is this coming Monday, February 18th, 2013. Please note that, because
the AMS office is closed this Monday, manual submissions will not be
processed until Tuesday, February 19th.

All Initial Version (-00) submissions are due by UTC 24:00.

All drafts can be uploaded using the ID submission tool located here:
https://datatracker.ietf.org/submit/

The Internet-Draft cutoff dates as well as other significant dates for
IETF 86 can be found at:
https://www.ietf.org/meeting/cutoff-dates-2013.html#IETF86

Thank you for your understanding and cooperation. If you have any
questions or concerns please send a message to
internet-drafts@ietf.org.

From keith.drage@alcatel-lucent.com  Fri Feb 15 14:08:05 2013
Return-Path: <keith.drage@alcatel-lucent.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A73C121E8045 for <dispatch@ietfa.amsl.com>; Fri, 15 Feb 2013 14:08:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.943
X-Spam-Level: 
X-Spam-Status: No, score=-108.943 tagged_above=-999 required=5 tests=[AWL=1.306, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBB4O-6Yf-C6 for <dispatch@ietfa.amsl.com>; Fri, 15 Feb 2013 14:08:03 -0800 (PST)
Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC9721F85CE for <dispatch@ietf.org>; Fri, 15 Feb 2013 14:08:03 -0800 (PST)
Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1FM81Wl006229 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <dispatch@ietf.org>; Fri, 15 Feb 2013 23:08:02 +0100
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Fri, 15 Feb 2013 23:08:02 +0100
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: "dispatch@ietf.org" <dispatch@ietf.org>
Date: Fri, 15 Feb 2013 23:08:01 +0100
Thread-Topic: Proposed charter for work on logging
Thread-Index: Ac4LyOtf/7ujcRPHQoOZ6+wpJgfGIA==
Message-ID: <EDC0A1AE77C57744B664A310A0B23AE210701601FC@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.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-Scanned-By: MIMEDefang 2.69 on 155.132.188.84
Subject: [dispatch] Proposed charter for work on logging
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Feb 2013 22:08:05 -0000

Peter Dawes has submitted

https://datatracker.ietf.org/doc/draft-dawes-dispatch-logme-reqs/

as a set of requirements that will work with the session identifier produce=
d by the INSIPID working group to enable identification of loggable session=
s.

The INIPID WG did consider this work, but considered it was out of scope of=
 the work they are currently chartered to do.

I propose the following scope for DISPATCH to consider based on the Abstrac=
t of the above document.

   SIP networks use signalling monitoring tools to diagnose user
   reported problem and for regression testing if network or client
   software is upgraded.  As networks grow and become interconnected,
   including connection via transit networks, it becomes impractical to
   predict the path that SIP signalling will take between clients, and
   therefore impractical to monitor SIP signalling end-to-end.

   This work will provide for adding an indicator to the SIP
   protocol which can be used to mark signalling as subject to logging.
   Such marking will typically be applied as part of network testing
   controlled by the network operator and not used in regular client
   signalling.  However, such marking can be carried end-to-end
   including the SIP terminals, even if a session originates and
   terminates in different networks.


Milestones

Dec 2013	Requirements for marking SIP sessions for logging to IESG (Informa=
tional)
Mar 2014	Protocol for marking SIP sessions for logging to IESG (Proposed st=
andard)

I would note that the work does not necessarily need a new working group, i=
t could for example be an extension of the work of either the SIPCORE WG or=
 the INSIPID WG, but that is for the discussion to decide.

Your comments and proposals for revision are welcome.

For information there have been a number of previous documents on the subje=
ct, but these might or might not form part of the proposed solution, partic=
ularly given that some of them predate the INSIPID work.

http://tools.ietf.org/html/draft-dawes-sipping-debug-id-01
http://tools.ietf.org/html/draft-dawes-sipping-debug-event-01
http://tools.ietf.org/html/draft-kaithal-dispatch-sip-log-information-00=20
http://tools.ietf.org/html/draft-dawes-sipping-debug-05
http://tools.ietf.org/html/draft-dawes-dispatch-debug-00
http://tools.ietf.org/html/draft-kaithal-sipclf-sip-log-information-00=20


Regards

Keith

From stpeter@stpeter.im  Fri Feb 15 14:37:32 2013
Return-Path: <stpeter@stpeter.im>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E44C221F85C6 for <dispatch@ietfa.amsl.com>; Fri, 15 Feb 2013 14:37:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.593
X-Spam-Level: 
X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yq7itOfW3wPX for <dispatch@ietfa.amsl.com>; Fri, 15 Feb 2013 14:37:32 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1094C21F85BC for <dispatch@ietf.org>; Fri, 15 Feb 2013 14:37:32 -0800 (PST)
Received: from [192.168.1.7] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1A03A406A8 for <dispatch@ietf.org>; Fri, 15 Feb 2013 15:44:44 -0700 (MST)
Message-ID: <511EB8B0.8090104@stpeter.im>
Date: Fri, 15 Feb 2013 15:37:36 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: DISPATCH <dispatch@ietf.org>
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: [dispatch] Charter Proposal: SIP-XMPP Mapping
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Feb 2013 22:37:33 -0000

Charter Proposal: SIP-XMPP Mapping
DISPATCH WG
IETF 86, Orlando

Problem Statement

The IETF has defined two signalling technologies that can be used
for multimedia session negotiation, instant messaging, presence,
file transfer, capabilities discovery, notifications, and other types of
real-time functionality:

o  The Session Initiation Protocol (SIP), along with various SIP
   extensions developed within the SIP for Instant Messaging and
   Presence Leveraging Extensions (SIMPLE) Working Group.

o  The Extensible Messaging and Presence Protocol (XMPP), along
   with various XMPP extensions developed by the IETF as well as by
   the XMPP Standards Foundation.

SIP has been focused primarily on media session negotiation (e.g. audio
and video), whereas XMPP has been focused primarily on messaging and
presence.  As a result, the technologies are mostly complementary.
However, there is also some overlap between SIP and XMPP, since there
are SIP extensions for messaging, presence, groupchat, file transfer
(etc.) and there are XMPP extensions for multimedia session negotiation.
This overlap has practical implications, since some deployed services
use SIP for both media and (broadly) messaging, whereas other deployed
services use XMPP for both messaging and media.  When such services wish
to exchange information, they often need to translate their native
protocol (either SIP or XMPP) to the other protocol (either XMPP or
SIP).

Implementers needing to perform such protocol mappings have often worked
out their own heuristics for doing so.  Unfortunately, these heuristics
are not always consistent, which can lead to interoperability problems.

Objectives

To make it easier for implementers to enable interworking between
SIP-based systems and XMPP-based systems, several Internet-Drafts have
defined guidelines for protocol mapping between SIP and XMPP, starting
with draft-saintandre-xmpp-simple-00 in early 2004.  The current
documents are:

draft-saintandre-sip-xmpp-core
draft-saintandre-sip-xmpp-presence
draft-saintandre-sip-xmpp-im
draft-saintandre-sip-xmpp-chat
draft-saintandre-sip-xmpp-groupchat

These documents are quite stable and the authors have received feedback
from a number of implementers over the years.  However, implementers do
not always know about these documents because they are Internet-Drafts
and sometimes have expired.  Thus it would be helpful to polish them off
and publish them as RFCs (and perhaps other documents in the same series,
covering topics like media signalling, capabilities discovery, and file
transfer).

Deliverables

1. Address mapping and error handling
2. Presence mapping
3. Mapping for single instant messages
4. Mapping for one-to-one text chat sessions
5. Mapping for multi-user text chat sessions

Any additional work would require a recharter.

Milestones

To be determined.

###


From prvs=755906ac4=christou_chris@bah.com  Mon Feb 18 18:32:24 2013
Return-Path: <prvs=755906ac4=christou_chris@bah.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A4421E808E for <dispatch@ietfa.amsl.com>; Mon, 18 Feb 2013 18:32:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xy1yhHujA4kH for <dispatch@ietfa.amsl.com>; Mon, 18 Feb 2013 18:32:24 -0800 (PST)
Received: from mclniron02-ext.bah.com (mclniron02-ext.bah.com [128.229.5.22]) by ietfa.amsl.com (Postfix) with ESMTP id E1D5721E8053 for <dispatch@ietf.org>; Mon, 18 Feb 2013 18:32:23 -0800 (PST)
x-SBRS: None
X-REMOTE-IP: 10.12.10.219
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqAEAE3jIlEKDArb/2dsb2JhbABEwC+BG3OCHwEBAQQBAQE3NBcEAgEIEQQBAQsUCQcnCxQJCAIEAQkJCIgWsTmPeQSOfSYSBoJZYQOpfg2CJw
X-IronPort-AV: E=Sophos;i="4.84,692,1355115600"; d="scan'208";a="470636289"
Received: from ashbcwsv04.usae.bah.com (HELO ASHBCSHB07.resource.ds.bah.com) ([10.12.10.219]) by mclniron02-int.bah.com with ESMTP; 18 Feb 2013 21:32:23 -0500
Received: from ASHBDAG1M1.resource.ds.bah.com ([169.254.1.38]) by ASHBCSHB07.resource.ds.bah.com ([10.12.10.219]) with mapi id 14.02.0318.004; Mon, 18 Feb 2013 21:32:23 -0500
From: "Christou, Christos [USA]" <christou_chris@bah.com>
To: Peter Saint-Andre <stpeter@stpeter.im>, DISPATCH <dispatch@ietf.org>
Thread-Topic: [External]  [dispatch] Charter Proposal: SIP-XMPP Mapping
Thread-Index: AQHOC8z8WBBDDFMJWUefxNf0dk+JUpiAepsQ
Date: Tue, 19 Feb 2013 02:32:22 +0000
Message-ID: <462D69106F82344E95BC83996D8039D24D16A8AA@ASHBDAG1M1.resource.ds.bah.com>
References: <511EB8B0.8090104@stpeter.im>
In-Reply-To: <511EB8B0.8090104@stpeter.im>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.12.5.20]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dispatch] [External]   Charter Proposal: SIP-XMPP Mapping
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Feb 2013 02:32:25 -0000

Peter,

I definitely support this work since reviewing and finalizing these documen=
ts will be critical to enabling the interworking between these two importan=
t protocols. =20



-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal=
f Of Peter Saint-Andre
Sent: Friday, February 15, 2013 5:38 PM
To: DISPATCH
Subject: [External] [dispatch] Charter Proposal: SIP-XMPP Mapping

Charter Proposal: SIP-XMPP Mapping
DISPATCH WG
IETF 86, Orlando

Problem Statement

The IETF has defined two signalling technologies that can be used for multi=
media session negotiation, instant messaging, presence, file transfer, capa=
bilities discovery, notifications, and other types of real-time functionali=
ty:

o  The Session Initiation Protocol (SIP), along with various SIP
   extensions developed within the SIP for Instant Messaging and
   Presence Leveraging Extensions (SIMPLE) Working Group.

o  The Extensible Messaging and Presence Protocol (XMPP), along
   with various XMPP extensions developed by the IETF as well as by
   the XMPP Standards Foundation.

SIP has been focused primarily on media session negotiation (e.g. audio and=
 video), whereas XMPP has been focused primarily on messaging and presence.=
  As a result, the technologies are mostly complementary.
However, there is also some overlap between SIP and XMPP, since there are S=
IP extensions for messaging, presence, groupchat, file transfer
(etc.) and there are XMPP extensions for multimedia session negotiation.
This overlap has practical implications, since some deployed services use S=
IP for both media and (broadly) messaging, whereas other deployed services =
use XMPP for both messaging and media.  When such services wish to exchange=
 information, they often need to translate their native protocol (either SI=
P or XMPP) to the other protocol (either XMPP or SIP).

Implementers needing to perform such protocol mappings have often worked ou=
t their own heuristics for doing so.  Unfortunately, these heuristics are n=
ot always consistent, which can lead to interoperability problems.

Objectives

To make it easier for implementers to enable interworking between SIP-based=
 systems and XMPP-based systems, several Internet-Drafts have defined guide=
lines for protocol mapping between SIP and XMPP, starting with draft-sainta=
ndre-xmpp-simple-00 in early 2004.  The current documents are:

draft-saintandre-sip-xmpp-core
draft-saintandre-sip-xmpp-presence
draft-saintandre-sip-xmpp-im
draft-saintandre-sip-xmpp-chat
draft-saintandre-sip-xmpp-groupchat

These documents are quite stable and the authors have received feedback fro=
m a number of implementers over the years.  However, implementers do not al=
ways know about these documents because they are Internet-Drafts and someti=
mes have expired.  Thus it would be helpful to polish them off and publish =
them as RFCs (and perhaps other documents in the same series, covering topi=
cs like media signalling, capabilities discovery, and file transfer).

Deliverables

1. Address mapping and error handling
2. Presence mapping
3. Mapping for single instant messages
4. Mapping for one-to-one text chat sessions 5. Mapping for multi-user text=
 chat sessions

Any additional work would require a recharter.

Milestones

To be determined.

###

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

From ben@nostrum.com  Tue Feb 19 12:49:44 2013
Return-Path: <ben@nostrum.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2FF521F887F for <dispatch@ietfa.amsl.com>; Tue, 19 Feb 2013 12:49:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.517
X-Spam-Level: 
X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yan5smanbsFq for <dispatch@ietfa.amsl.com>; Tue, 19 Feb 2013 12:49:43 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id D742D21F8878 for <dispatch@ietf.org>; Tue, 19 Feb 2013 12:49:42 -0800 (PST)
Received: from [10.0.1.14] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r1JKnbiN087397 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Feb 2013 14:49:37 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <462D69106F82344E95BC83996D8039D24D16A8AA@ASHBDAG1M1.resource.ds.bah.com>
Date: Tue, 19 Feb 2013 14:49:37 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <02977D33-5D2C-4277-BDE8-F6AF0F50F594@nostrum.com>
References: <511EB8B0.8090104@stpeter.im> <462D69106F82344E95BC83996D8039D24D16A8AA@ASHBDAG1M1.resource.ds.bah.com>
To: "Christou, Christos [USA]" <christou_chris@bah.com>
X-Mailer: Apple Mail (2.1499)
Received-SPF: pass (shaman.nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism)
Cc: DISPATCH <dispatch@ietf.org>
Subject: Re: [dispatch] [External]   Charter Proposal: SIP-XMPP Mapping
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Feb 2013 20:49:44 -0000

I also support moving this forward.

On Feb 18, 2013, at 8:32 PM, "Christou, Christos [USA]" =
<christou_chris@bah.com> wrote:

> Peter,
>=20
> I definitely support this work since reviewing and finalizing these =
documents will be critical to enabling the interworking between these =
two important protocols. =20
>=20
>=20
>=20
> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On =
Behalf Of Peter Saint-Andre
> Sent: Friday, February 15, 2013 5:38 PM
> To: DISPATCH
> Subject: [External] [dispatch] Charter Proposal: SIP-XMPP Mapping
>=20
> Charter Proposal: SIP-XMPP Mapping
> DISPATCH WG
> IETF 86, Orlando
>=20
> Problem Statement
>=20
> The IETF has defined two signalling technologies that can be used for =
multimedia session negotiation, instant messaging, presence, file =
transfer, capabilities discovery, notifications, and other types of =
real-time functionality:
>=20
> o  The Session Initiation Protocol (SIP), along with various SIP
>   extensions developed within the SIP for Instant Messaging and
>   Presence Leveraging Extensions (SIMPLE) Working Group.
>=20
> o  The Extensible Messaging and Presence Protocol (XMPP), along
>   with various XMPP extensions developed by the IETF as well as by
>   the XMPP Standards Foundation.
>=20
> SIP has been focused primarily on media session negotiation (e.g. =
audio and video), whereas XMPP has been focused primarily on messaging =
and presence.  As a result, the technologies are mostly complementary.
> However, there is also some overlap between SIP and XMPP, since there =
are SIP extensions for messaging, presence, groupchat, file transfer
> (etc.) and there are XMPP extensions for multimedia session =
negotiation.
> This overlap has practical implications, since some deployed services =
use SIP for both media and (broadly) messaging, whereas other deployed =
services use XMPP for both messaging and media.  When such services wish =
to exchange information, they often need to translate their native =
protocol (either SIP or XMPP) to the other protocol (either XMPP or =
SIP).
>=20
> Implementers needing to perform such protocol mappings have often =
worked out their own heuristics for doing so.  Unfortunately, these =
heuristics are not always consistent, which can lead to interoperability =
problems.
>=20
> Objectives
>=20
> To make it easier for implementers to enable interworking between =
SIP-based systems and XMPP-based systems, several Internet-Drafts have =
defined guidelines for protocol mapping between SIP and XMPP, starting =
with draft-saintandre-xmpp-simple-00 in early 2004.  The current =
documents are:
>=20
> draft-saintandre-sip-xmpp-core
> draft-saintandre-sip-xmpp-presence
> draft-saintandre-sip-xmpp-im
> draft-saintandre-sip-xmpp-chat
> draft-saintandre-sip-xmpp-groupchat
>=20
> These documents are quite stable and the authors have received =
feedback from a number of implementers over the years.  However, =
implementers do not always know about these documents because they are =
Internet-Drafts and sometimes have expired.  Thus it would be helpful to =
polish them off and publish them as RFCs (and perhaps other documents in =
the same series, covering topics like media signalling, capabilities =
discovery, and file transfer).
>=20
> Deliverables
>=20
> 1. Address mapping and error handling
> 2. Presence mapping
> 3. Mapping for single instant messages
> 4. Mapping for one-to-one text chat sessions 5. Mapping for multi-user =
text chat sessions
>=20
> Any additional work would require a recharter.
>=20
> Milestones
>=20
> To be determined.
>=20
> ###
>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch


From spromano@unina.it  Wed Feb 20 00:19:28 2013
Return-Path: <spromano@unina.it>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B73621F874F for <dispatch@ietfa.amsl.com>; Wed, 20 Feb 2013 00:19:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.718
X-Spam-Level: 
X-Spam-Status: No, score=-100.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGb6-QAl7QOp for <dispatch@ietfa.amsl.com>; Wed, 20 Feb 2013 00:19:27 -0800 (PST)
Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE0821F87AD for <dispatch@ietf.org>; Wed, 20 Feb 2013 00:19:27 -0800 (PST)
Received: from [143.225.229.230] ([143.225.229.230]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id r1K8JNpL004177 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Feb 2013 09:19:25 +0100
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_1F39E0E2-61AF-40C0-8B48-CE73027FE835"
From: Simon Pietro Romano <spromano@unina.it>
In-Reply-To: <511EB8B0.8090104@stpeter.im>
Date: Wed, 20 Feb 2013 09:19:37 +0100
Message-Id: <EB87EC1E-0A4E-487E-AD74-B76105F20CD8@unina.it>
References: <511EB8B0.8090104@stpeter.im>
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Mailer: Apple Mail (2.1283)
Cc: DISPATCH <dispatch@ietf.org>
Subject: Re: [dispatch] Charter Proposal: SIP-XMPP Mapping
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Feb 2013 08:19:28 -0000

--Apple-Mail=_1F39E0E2-61AF-40C0-8B48-CE73027FE835
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

I strongly support this work.

Simon

Il giorno 15/feb/2013, alle ore 23:37, Peter Saint-Andre ha scritto:

> Charter Proposal: SIP-XMPP Mapping
> DISPATCH WG
> IETF 86, Orlando
>=20
> Problem Statement
>=20
> The IETF has defined two signalling technologies that can be used
> for multimedia session negotiation, instant messaging, presence,
> file transfer, capabilities discovery, notifications, and other types =
of
> real-time functionality:
>=20
> o  The Session Initiation Protocol (SIP), along with various SIP
>   extensions developed within the SIP for Instant Messaging and
>   Presence Leveraging Extensions (SIMPLE) Working Group.
>=20
> o  The Extensible Messaging and Presence Protocol (XMPP), along
>   with various XMPP extensions developed by the IETF as well as by
>   the XMPP Standards Foundation.
>=20
> SIP has been focused primarily on media session negotiation (e.g. =
audio
> and video), whereas XMPP has been focused primarily on messaging and
> presence.  As a result, the technologies are mostly complementary.
> However, there is also some overlap between SIP and XMPP, since there
> are SIP extensions for messaging, presence, groupchat, file transfer
> (etc.) and there are XMPP extensions for multimedia session =
negotiation.
> This overlap has practical implications, since some deployed services
> use SIP for both media and (broadly) messaging, whereas other deployed
> services use XMPP for both messaging and media.  When such services =
wish
> to exchange information, they often need to translate their native
> protocol (either SIP or XMPP) to the other protocol (either XMPP or
> SIP).
>=20
> Implementers needing to perform such protocol mappings have often =
worked
> out their own heuristics for doing so.  Unfortunately, these =
heuristics
> are not always consistent, which can lead to interoperability =
problems.
>=20
> Objectives
>=20
> To make it easier for implementers to enable interworking between
> SIP-based systems and XMPP-based systems, several Internet-Drafts have
> defined guidelines for protocol mapping between SIP and XMPP, starting
> with draft-saintandre-xmpp-simple-00 in early 2004.  The current
> documents are:
>=20
> draft-saintandre-sip-xmpp-core
> draft-saintandre-sip-xmpp-presence
> draft-saintandre-sip-xmpp-im
> draft-saintandre-sip-xmpp-chat
> draft-saintandre-sip-xmpp-groupchat
>=20
> These documents are quite stable and the authors have received =
feedback
> from a number of implementers over the years.  However, implementers =
do
> not always know about these documents because they are Internet-Drafts
> and sometimes have expired.  Thus it would be helpful to polish them =
off
> and publish them as RFCs (and perhaps other documents in the same =
series,
> covering topics like media signalling, capabilities discovery, and =
file
> transfer).
>=20
> Deliverables
>=20
> 1. Address mapping and error handling
> 2. Presence mapping
> 3. Mapping for single instant messages
> 4. Mapping for one-to-one text chat sessions
> 5. Mapping for multi-user text chat sessions
>=20
> Any additional work would require a recharter.
>=20
> Milestones
>=20
> To be determined.
>=20
> ###
>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>=20

                     					       _\\|//_
                           				      ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    				Simon Pietro Romano
             				 Universita' di Napoli Federico =
II
                		     Computer Engineering Department=20
	             Phone: +39 081 7683823 -- Fax: +39 081 7683816
                                           e-mail: spromano@unina.it

		    <<Molti mi dicono che lo scoraggiamento =CB l'alibi =
degli=20
		    idioti. Ci rifletto un istante; e mi scoraggio>>. =
Magritte.
               			                     oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
					                 \ (            =
(   )
			                                  \_)          ) =
/
                                                                       =
(_/






--Apple-Mail=_1F39E0E2-61AF-40C0-8B48-CE73027FE835
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I =
strongly support this =
work.<div><br></div><div>Simon</div><div><br><div><div>Il giorno =
15/feb/2013, alle ore 23:37, Peter Saint-Andre ha scritto:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div>Charter=
 Proposal: SIP-XMPP Mapping<br>DISPATCH WG<br>IETF 86, =
Orlando<br><br>Problem Statement<br><br>The IETF has defined two =
signalling technologies that can be used<br>for multimedia session =
negotiation, instant messaging, presence,<br>file transfer, capabilities =
discovery, notifications, and other types of<br>real-time =
functionality:<br><br>o &nbsp;The Session Initiation Protocol (SIP), =
along with various SIP<br> &nbsp;&nbsp;extensions developed within the =
SIP for Instant Messaging and<br> &nbsp;&nbsp;Presence Leveraging =
Extensions (SIMPLE) Working Group.<br><br>o &nbsp;The Extensible =
Messaging and Presence Protocol (XMPP), along<br> &nbsp;&nbsp;with =
various XMPP extensions developed by the IETF as well as by<br> =
&nbsp;&nbsp;the XMPP Standards Foundation.<br><br>SIP has been focused =
primarily on media session negotiation (e.g. audio<br>and video), =
whereas XMPP has been focused primarily on messaging and<br>presence. =
&nbsp;As a result, the technologies are mostly =
complementary.<br>However, there is also some overlap between SIP and =
XMPP, since there<br>are SIP extensions for messaging, presence, =
groupchat, file transfer<br>(etc.) and there are XMPP extensions for =
multimedia session negotiation.<br>This overlap has practical =
implications, since some deployed services<br>use SIP for both media and =
(broadly) messaging, whereas other deployed<br>services use XMPP for =
both messaging and media. &nbsp;When such services wish<br>to exchange =
information, they often need to translate their native<br>protocol =
(either SIP or XMPP) to the other protocol (either XMPP =
or<br>SIP).<br><br>Implementers needing to perform such protocol =
mappings have often worked<br>out their own heuristics for doing so. =
&nbsp;Unfortunately, these heuristics<br>are not always consistent, =
which can lead to interoperability problems.<br><br>Objectives<br><br>To =
make it easier for implementers to enable interworking =
between<br>SIP-based systems and XMPP-based systems, several =
Internet-Drafts have<br>defined guidelines for protocol mapping between =
SIP and XMPP, starting<br>with draft-saintandre-xmpp-simple-00 in early =
2004. &nbsp;The current<br>documents =
are:<br><br>draft-saintandre-sip-xmpp-core<br>draft-saintandre-sip-xmpp-pr=
esence<br>draft-saintandre-sip-xmpp-im<br>draft-saintandre-sip-xmpp-chat<b=
r>draft-saintandre-sip-xmpp-groupchat<br><br>These documents are quite =
stable and the authors have received feedback<br>from a number of =
implementers over the years. &nbsp;However, implementers do<br>not =
always know about these documents because they are =
Internet-Drafts<br>and sometimes have expired. &nbsp;Thus it would be =
helpful to polish them off<br>and publish them as RFCs (and perhaps =
other documents in the same series,<br>covering topics like media =
signalling, capabilities discovery, and =
file<br>transfer).<br><br>Deliverables<br><br>1. Address mapping and =
error handling<br>2. Presence mapping<br>3. Mapping for single instant =
messages<br>4. Mapping for one-to-one text chat sessions<br>5. Mapping =
for multi-user text chat sessions<br><br>Any additional work would =
require a recharter.<br><br>Milestones<br><br>To be =
determined.<br><br>###<br><br>____________________________________________=
___<br>dispatch mailing list<br><a =
href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</a><br>https://www.iet=
f.org/mailman/listinfo/dispatch<br><br></div></blockquote></div><br><div =
apple-content-edited=3D"true">
<span class=3D"Apple-style-span" style=3D"border-collapse: separate; =
color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: =
0px; text-transform: none; white-space: normal; widows: 2; word-spacing: =
0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; color: =
rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; =
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div =
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family: =
Helvetica; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; orphans: 2; =
text-align: -webkit-auto; text-indent: 0px; text-transform: none; =
white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div =
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><div><div>&nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<span =
class=3D"Apple-tab-span" style=3D"white-space: pre; ">				=
	</span><span class=3D"Apple-converted-space">&nbsp;</span>&nbsp; =
&nbsp; &nbsp; _\\|//_</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<span =
class=3D"Apple-tab-span" style=3D"white-space: pre; ">				=
</span>&nbsp; &nbsp; &nbsp;&nbsp;( O-O )</div><div>&nbsp; =
&nbsp;~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~</div><di=
v>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;<span class=3D"Apple-converted-space">&nbsp;</span><span =
class=3D"Apple-tab-span" style=3D"white-space: pre; ">				=
</span>Simon Pietro Romano</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp;<span class=3D"Apple-tab-span" style=3D"white-space: pre; =
">				</span><span =
class=3D"Apple-converted-space">&nbsp;</span>Universita' di Napoli =
Federico II</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;&nbsp;<span class=3D"Apple-tab-span" style=3D"white-space: pre; ">	=
	</span>&nbsp; &nbsp; &nbsp;Computer Engineering =
Department&nbsp;</div><div><span class=3D"Apple-tab-span" =
style=3D"white-space: pre; ">	</span>&nbsp; &nbsp; &nbsp;&nbsp; &nbsp; =
&nbsp; &nbsp; Phone: +39 081 7683823 -- Fax: +39 081 =
7683816</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;e-mail: <a =
href=3D"mailto:spromano@unina.it">spromano@unina.it</a></div><div><br></di=
v><div><span class=3D"Apple-tab-span" style=3D"white-space: pre; ">		=
</span>&nbsp; &nbsp; &lt;&lt;Molti mi dicono che lo scoraggiamento =CB =
l'alibi degli&nbsp;</div><div><span class=3D"Apple-tab-span" =
style=3D"white-space: pre; ">		</span>&nbsp;&nbsp; =
&nbsp;idioti. Ci rifletto un istante; e mi scoraggio&gt;&gt;. =
Magritte.</div><div>&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; &nbsp; &nbsp; =
&nbsp;<span class=3D"Apple-converted-space">&nbsp;</span><span =
class=3D"Apple-tab-span" style=3D"white-space: pre; ">			=
</span>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp;oooO</div><div>&nbsp; ~~~~~~~~~~~~~~~~~~~~~~~( &nbsp; =
)~~~&nbsp;Oooo~~~~~~~~~~~~~~~~~~~~~~~~~</div><div><span =
class=3D"Apple-tab-span" style=3D"white-space: pre; ">				=
	</span>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;\ ( &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;( &nbsp; =
)</div><div><span class=3D"Apple-tab-span" style=3D"white-space: pre; ">	=
		</span>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
\_) &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;) /</div><div>&nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp;(_/</div></div><div><br></div></div></span><br =
class=3D"Apple-interchange-newline"></div></span><br =
class=3D"Apple-interchange-newline"></span><br =
class=3D"Apple-interchange-newline">
</div>
<br></div></body></html>=

--Apple-Mail=_1F39E0E2-61AF-40C0-8B48-CE73027FE835--

From lorenzo@meetecho.com  Wed Feb 20 02:04:51 2013
Return-Path: <lorenzo@meetecho.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07E5621F8713 for <dispatch@ietfa.amsl.com>; Wed, 20 Feb 2013 02:04:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.719
X-Spam-Level: 
X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+2KEEMV3Bmj for <dispatch@ietfa.amsl.com>; Wed, 20 Feb 2013 02:04:49 -0800 (PST)
Received: from smtpdg10.aruba.it (smtpdg228.aruba.it [62.149.158.228]) by ietfa.amsl.com (Postfix) with ESMTP id 12EB121F86EA for <dispatch@ietf.org>; Wed, 20 Feb 2013 02:04:46 -0800 (PST)
Received: from lminiero-acer ([143.225.229.181]) by smtpcmd04.ad.aruba.it with bizsmtp id 2a4h1l00A3vURzj01a4iMk; Wed, 20 Feb 2013 11:04:43 +0100
Date: Wed, 20 Feb 2013 11:04:31 +0100
From: Lorenzo Miniero <lorenzo@meetecho.com>
To: Simon Pietro Romano <spromano@unina.it>
Message-ID: <20130220110431.02b96db9@lminiero-acer>
In-Reply-To: <EB87EC1E-0A4E-487E-AD74-B76105F20CD8@unina.it>
References: <511EB8B0.8090104@stpeter.im> <EB87EC1E-0A4E-487E-AD74-B76105F20CD8@unina.it>
Organization: Meetecho
X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.0; i386-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: DISPATCH <dispatch@ietf.org>
Subject: Re: [dispatch] Charter Proposal: SIP-XMPP Mapping
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Feb 2013 10:04:51 -0000

Me too, especially considering there's a strong basis of pre-existing
work to start from.

L.

Il giorno Wed, 20 Feb 2013 09:19:37 +0100
Simon Pietro Romano <spromano@unina.it> ha scritto:

> I strongly support this work.
>=20
> Simon
>=20
> Il giorno 15/feb/2013, alle ore 23:37, Peter Saint-Andre ha scritto:
>=20
> > Charter Proposal: SIP-XMPP Mapping
> > DISPATCH WG
> > IETF 86, Orlando
> >=20
> > Problem Statement
> >=20
> > The IETF has defined two signalling technologies that can be used
> > for multimedia session negotiation, instant messaging, presence,
> > file transfer, capabilities discovery, notifications, and other
> > types of real-time functionality:
> >=20
> > o  The Session Initiation Protocol (SIP), along with various SIP
> >   extensions developed within the SIP for Instant Messaging and
> >   Presence Leveraging Extensions (SIMPLE) Working Group.
> >=20
> > o  The Extensible Messaging and Presence Protocol (XMPP), along
> >   with various XMPP extensions developed by the IETF as well as by
> >   the XMPP Standards Foundation.
> >=20
> > SIP has been focused primarily on media session negotiation (e.g.
> > audio and video), whereas XMPP has been focused primarily on
> > messaging and presence.  As a result, the technologies are mostly
> > complementary. However, there is also some overlap between SIP and
> > XMPP, since there are SIP extensions for messaging, presence,
> > groupchat, file transfer (etc.) and there are XMPP extensions for
> > multimedia session negotiation. This overlap has practical
> > implications, since some deployed services use SIP for both media
> > and (broadly) messaging, whereas other deployed services use XMPP
> > for both messaging and media.  When such services wish to exchange
> > information, they often need to translate their native protocol
> > (either SIP or XMPP) to the other protocol (either XMPP or SIP).
> >=20
> > Implementers needing to perform such protocol mappings have often
> > worked out their own heuristics for doing so.  Unfortunately, these
> > heuristics are not always consistent, which can lead to
> > interoperability problems.
> >=20
> > Objectives
> >=20
> > To make it easier for implementers to enable interworking between
> > SIP-based systems and XMPP-based systems, several Internet-Drafts
> > have defined guidelines for protocol mapping between SIP and XMPP,
> > starting with draft-saintandre-xmpp-simple-00 in early 2004.  The
> > current documents are:
> >=20
> > draft-saintandre-sip-xmpp-core
> > draft-saintandre-sip-xmpp-presence
> > draft-saintandre-sip-xmpp-im
> > draft-saintandre-sip-xmpp-chat
> > draft-saintandre-sip-xmpp-groupchat
> >=20
> > These documents are quite stable and the authors have received
> > feedback from a number of implementers over the years.  However,
> > implementers do not always know about these documents because they
> > are Internet-Drafts and sometimes have expired.  Thus it would be
> > helpful to polish them off and publish them as RFCs (and perhaps
> > other documents in the same series, covering topics like media
> > signalling, capabilities discovery, and file transfer).
> >=20
> > Deliverables
> >=20
> > 1. Address mapping and error handling
> > 2. Presence mapping
> > 3. Mapping for single instant messages
> > 4. Mapping for one-to-one text chat sessions
> > 5. Mapping for multi-user text chat sessions
> >=20
> > Any additional work would require a recharter.
> >=20
> > Milestones
> >=20
> > To be determined.
> >=20
> > ###
> >=20
> > _______________________________________________
> > 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 Engineering Department=20
> 	             Phone: +39 081 7683823 -- Fax: +39 081 7683816
>                                            e-mail: spromano@unina.it
>=20
> 		    <<Molti mi dicono che lo scoraggiamento =CB l'alibi
> degli idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
>                			                     oooO
>   ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
> 					                 \
> (            (   ) \_)          ) /
>                                                                        (_/
>=20
>=20
>=20
>=20
>=20



--=20
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com

From salvatore.loreto@ericsson.com  Wed Feb 20 12:42:48 2013
Return-Path: <salvatore.loreto@ericsson.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C63CD21F874F for <dispatch@ietfa.amsl.com>; Wed, 20 Feb 2013 12:42:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.158
X-Spam-Level: 
X-Spam-Status: No, score=-106.158 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcSXIXrUUjrJ for <dispatch@ietfa.amsl.com>; Wed, 20 Feb 2013 12:42:48 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8228421F8721 for <dispatch@ietf.org>; Wed, 20 Feb 2013 12:42:47 -0800 (PST)
X-AuditID: c1b4fb30-b7f0d6d000007e61-d2-512535467dbb
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 99.7E.32353.64535215; Wed, 20 Feb 2013 21:42:46 +0100 (CET)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Wed, 20 Feb 2013 21:42:45 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id C7F2E2B2D	for <dispatch@ietf.org>; Wed, 20 Feb 2013 22:42:45 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 62E3654391	for <dispatch@ietf.org>; Wed, 20 Feb 2013 22:42:43 +0200 (EET)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 1ECD2541AF	for <dispatch@ietf.org>; Wed, 20 Feb 2013 22:42:43 +0200 (EET)
Message-ID: <51253544.3020901@ericsson.com>
Date: Wed, 20 Feb 2013 22:42:44 +0200
From: Salvatore Loreto <salvatore.loreto@ericsson.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: dispatch@ietf.org
References: <511EB8B0.8090104@stpeter.im>
In-Reply-To: <511EB8B0.8090104@stpeter.im>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUyM+Jvja6bqWqgQcMrFYulkxawOjB6LFny kymAMYrLJiU1J7MstUjfLoEro7nvKWvBLKmK7+8PMTcwbhXtYuTkkBAwkZjwYCYzhC0mceHe erYuRi4OIYGTjBLn5t9ih3A2MEosbGpmgnAuMUqs6r3HCOEcZZSYffMTlHOOUeLtmzssIMN4 BbQl1jxfwwpiswioSlz6AjKYk4NNwEzi+cMtYAtFBZIl/j06wghRLyhxcuYTsF4RAVGJ+SsW sYPYwgJWEktvHwKbIySgKXGzpQOsnlNAS+LLxe1gcWYBW4kLc66zQNjyEtvfzoF6SE3i6rlN zBC9WhK9ZzuZJjCKzEKybhaS9llI2hcwMq9iZM9NzMxJLzffxAgM54NbfhvsYNx0X+wQozQH i5I4b7jrhQAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjGIab+UsFX95pF2u/Bpp0nBSQjZx aS/Tbd6AY99a5d90mLzMX11ZvqrROsxtXST/xAm8vRcuflmlmx7vu/2X2aXrp+a9vF0iV9h3 xNutVWylzR/VfP/fpwwzY7YsWJkV82aSMOdhh8X3GfWVHy/WvJOv3m+iKmvRLStf/d7dMehy xM7AuUeklViKMxINtZiLihMBWHikbDUCAAA=
Subject: Re: [dispatch] Charter Proposal: SIP-XMPP Mapping
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Feb 2013 20:42:48 -0000

I do support this proposal


/Sal

On 2/16/13 12:37 AM, Peter Saint-Andre wrote:
> Charter Proposal: SIP-XMPP Mapping
> DISPATCH WG
> IETF 86, Orlando
>
> Problem Statement
>
> The IETF has defined two signalling technologies that can be used
> for multimedia session negotiation, instant messaging, presence,
> file transfer, capabilities discovery, notifications, and other types of
> real-time functionality:
>
> o  The Session Initiation Protocol (SIP), along with various SIP
>     extensions developed within the SIP for Instant Messaging and
>     Presence Leveraging Extensions (SIMPLE) Working Group.
>
> o  The Extensible Messaging and Presence Protocol (XMPP), along
>     with various XMPP extensions developed by the IETF as well as by
>     the XMPP Standards Foundation.
>
> SIP has been focused primarily on media session negotiation (e.g. audio
> and video), whereas XMPP has been focused primarily on messaging and
> presence.  As a result, the technologies are mostly complementary.
> However, there is also some overlap between SIP and XMPP, since there
> are SIP extensions for messaging, presence, groupchat, file transfer
> (etc.) and there are XMPP extensions for multimedia session negotiation.
> This overlap has practical implications, since some deployed services
> use SIP for both media and (broadly) messaging, whereas other deployed
> services use XMPP for both messaging and media.  When such services wish
> to exchange information, they often need to translate their native
> protocol (either SIP or XMPP) to the other protocol (either XMPP or
> SIP).
>
> Implementers needing to perform such protocol mappings have often worked
> out their own heuristics for doing so.  Unfortunately, these heuristics
> are not always consistent, which can lead to interoperability problems.
>
> Objectives
>
> To make it easier for implementers to enable interworking between
> SIP-based systems and XMPP-based systems, several Internet-Drafts have
> defined guidelines for protocol mapping between SIP and XMPP, starting
> with draft-saintandre-xmpp-simple-00 in early 2004.  The current
> documents are:
>
> draft-saintandre-sip-xmpp-core
> draft-saintandre-sip-xmpp-presence
> draft-saintandre-sip-xmpp-im
> draft-saintandre-sip-xmpp-chat
> draft-saintandre-sip-xmpp-groupchat
>
> These documents are quite stable and the authors have received feedback
> from a number of implementers over the years.  However, implementers do
> not always know about these documents because they are Internet-Drafts
> and sometimes have expired.  Thus it would be helpful to polish them off
> and publish them as RFCs (and perhaps other documents in the same series,
> covering topics like media signalling, capabilities discovery, and file
> transfer).
>
> Deliverables
>
> 1. Address mapping and error handling
> 2. Presence mapping
> 3. Mapping for single instant messages
> 4. Mapping for one-to-one text chat sessions
> 5. Mapping for multi-user text chat sessions
>
> Any additional work would require a recharter.
>
> Milestones
>
> To be determined.
>
> ###
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch


-- 
Salvatore Loreto, PhD
www.sloreto.com


From emil@sip-communicator.org  Wed Feb 20 12:46:38 2013
Return-Path: <emil@sip-communicator.org>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77BC021E8039 for <dispatch@ietfa.amsl.com>; Wed, 20 Feb 2013 12:46:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTbH5VYwOCQw for <dispatch@ietfa.amsl.com>; Wed, 20 Feb 2013 12:46:37 -0800 (PST)
Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 5F81021E8037 for <dispatch@ietf.org>; Wed, 20 Feb 2013 12:46:37 -0800 (PST)
Received: by mail-we0-f171.google.com with SMTP id u54so6845787wey.2 for <dispatch@ietf.org>; Wed, 20 Feb 2013 12:46:36 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=ajOAdU3DMS21RFimqHlPDzUeLxLqxH9QimCRXtxgKqk=; b=LvZCq9HiyQM0jb8pvUTlw6GEtZ+dJl9JjOlEuyEopv05VZlIp2n0voMMVmd+19vNZJ LCDDVCTiz0TUs4K+ChM9hRysJGZSGYbmrPAtRM4zJHyUR9PIAjz90hUUiSomaAwop9cy ED66natbayclWooD9+xG319hb2rp0y80URTjNJG2IkY6xtjYbKY2noo9uluVe39ImnPV pvgwSQ+6pzUmfui5+OkOmOBQXgrpx+GXwCgKz3njkXtxR3TticksP4g9pe3B9BStLJyP WdIy9R3/xkGfMvaYoPYyNiNp1QikPlScEoITHbbcEgeeNsgBiqvsxLA4yrcARsrx+jbO W1Xg==
X-Received: by 10.194.156.196 with SMTP id wg4mr36728712wjb.22.1361393196421;  Wed, 20 Feb 2013 12:46:36 -0800 (PST)
Received: from camionet.local ([2a01:e35:8a55:abc0:b157:7625:962e:97dc]) by mx.google.com with ESMTPS id o8sm33314548wix.7.2013.02.20.12.46.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Feb 2013 12:46:35 -0800 (PST)
Message-ID: <51253628.7030209@jitsi.org>
Date: Wed, 20 Feb 2013 21:46:32 +0100
From: Emil Ivov <emcho@jitsi.org>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Peter Saint-Andre <stpeter@stpeter.im>
References: <511EB8B0.8090104@stpeter.im>
In-Reply-To: <511EB8B0.8090104@stpeter.im>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQkZ7m9vVhS4bt91oVO8XofX7HlhkbzIrL+5NTLcFjjKmoYL8lmk11kFE8994VFxE96fK5lR
Cc: DISPATCH <dispatch@ietf.org>
Subject: Re: [dispatch] Charter Proposal: SIP-XMPP Mapping
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Feb 2013 20:46:38 -0000

Mapping SIP to XMPP is something I personally view as very important and
this proposal seems very reasonable and well targeted at addressing the
issue.

Emil

On 15.02.13, 23:37, Peter Saint-Andre wrote:
> Charter Proposal: SIP-XMPP Mapping
> DISPATCH WG
> IETF 86, Orlando
> 
> Problem Statement
> 
> The IETF has defined two signalling technologies that can be used
> for multimedia session negotiation, instant messaging, presence,
> file transfer, capabilities discovery, notifications, and other types of
> real-time functionality:
> 
> o  The Session Initiation Protocol (SIP), along with various SIP
>    extensions developed within the SIP for Instant Messaging and
>    Presence Leveraging Extensions (SIMPLE) Working Group.
> 
> o  The Extensible Messaging and Presence Protocol (XMPP), along
>    with various XMPP extensions developed by the IETF as well as by
>    the XMPP Standards Foundation.
> 
> SIP has been focused primarily on media session negotiation (e.g. audio
> and video), whereas XMPP has been focused primarily on messaging and
> presence.  As a result, the technologies are mostly complementary.
> However, there is also some overlap between SIP and XMPP, since there
> are SIP extensions for messaging, presence, groupchat, file transfer
> (etc.) and there are XMPP extensions for multimedia session negotiation.
> This overlap has practical implications, since some deployed services
> use SIP for both media and (broadly) messaging, whereas other deployed
> services use XMPP for both messaging and media.  When such services wish
> to exchange information, they often need to translate their native
> protocol (either SIP or XMPP) to the other protocol (either XMPP or
> SIP).
> 
> Implementers needing to perform such protocol mappings have often worked
> out their own heuristics for doing so.  Unfortunately, these heuristics
> are not always consistent, which can lead to interoperability problems.
> 
> Objectives
> 
> To make it easier for implementers to enable interworking between
> SIP-based systems and XMPP-based systems, several Internet-Drafts have
> defined guidelines for protocol mapping between SIP and XMPP, starting
> with draft-saintandre-xmpp-simple-00 in early 2004.  The current
> documents are:
> 
> draft-saintandre-sip-xmpp-core
> draft-saintandre-sip-xmpp-presence
> draft-saintandre-sip-xmpp-im
> draft-saintandre-sip-xmpp-chat
> draft-saintandre-sip-xmpp-groupchat
> 
> These documents are quite stable and the authors have received feedback
> from a number of implementers over the years.  However, implementers do
> not always know about these documents because they are Internet-Drafts
> and sometimes have expired.  Thus it would be helpful to polish them off
> and publish them as RFCs (and perhaps other documents in the same series,
> covering topics like media signalling, capabilities discovery, and file
> transfer).
> 
> Deliverables
> 
> 1. Address mapping and error handling
> 2. Presence mapping
> 3. Mapping for single instant messages
> 4. Mapping for one-to-one text chat sessions
> 5. Mapping for multi-user text chat sessions
> 
> Any additional work would require a recharter.
> 
> Milestones
> 
> To be determined.
> 
> ###
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> 

-- 
https://jitsi.org

From michaellundberg.ietf@gmail.com  Wed Feb 20 12:55:26 2013
Return-Path: <michaellundberg.ietf@gmail.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F2021F865D for <dispatch@ietfa.amsl.com>; Wed, 20 Feb 2013 12:55:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLj8T1r0pxct for <dispatch@ietfa.amsl.com>; Wed, 20 Feb 2013 12:55:25 -0800 (PST)
Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id 243E521F85F5 for <dispatch@ietf.org>; Wed, 20 Feb 2013 12:55:23 -0800 (PST)
Received: by mail-wi0-f180.google.com with SMTP id hi8so6784454wib.1 for <dispatch@ietf.org>; Wed, 20 Feb 2013 12:55:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=it4X2eI++maSSt29uV3vUCMpGC/qNUqEb5AgAe3Rfws=; b=AbmFK+GOcP82TfOiV9Pus+5oFtnHfp3do9McyhMeO6rjnsWolYrtgezT4e0PQSaDr/ LplNuzf15dsQf++on8Ny0HktjNAkRraDddPv81Dse6qxNOEzjg1VD1zAeiVbHUzxespk c4/V2c28jF/xXrPWgn4QSvcBlYODz9Q4jAv7N503NsbpsMcuUQCHGE1Vrm7BNsj6VXIp +XTSkmnNWmDzBmuEnMpA6B2+J9pUv05SfoWsg8rGihD/sxffmmW96FMvMZhqG/5JXZ0r /E1HZd1+tuYEN/qVMTgaJ3dZBmnoMjcBEdZVuOOkCRYp1dUbb5dhdtrPDhH0omu6UpnY 1dZA==
MIME-Version: 1.0
X-Received: by 10.180.104.10 with SMTP id ga10mr35483119wib.23.1361393723255;  Wed, 20 Feb 2013 12:55:23 -0800 (PST)
Received: by 10.216.231.217 with HTTP; Wed, 20 Feb 2013 12:55:23 -0800 (PST)
In-Reply-To: <51253544.3020901@ericsson.com>
References: <511EB8B0.8090104@stpeter.im> <51253544.3020901@ericsson.com>
Date: Wed, 20 Feb 2013 15:55:23 -0500
Message-ID: <CANVDpGFPfgeo5_zu0S1cf1foHMwax0MohdY-MfaVjySC7634LQ@mail.gmail.com>
From: Michael Lundberg <michaellundberg.ietf@gmail.com>
To: dispatch@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [dispatch] Charter Proposal: SIP-XMPP Mapping
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Feb 2013 20:55:26 -0000

I strongly support this proposal!

Michael

On Wed, Feb 20, 2013 at 3:42 PM, Salvatore Loreto
<salvatore.loreto@ericsson.com> wrote:
> I do support this proposal
>
>
> /Sal
>
> On 2/16/13 12:37 AM, Peter Saint-Andre wrote:
>>
>> Charter Proposal: SIP-XMPP Mapping
>> DISPATCH WG
>> IETF 86, Orlando
>>
>> Problem Statement
>>
>> The IETF has defined two signalling technologies that can be used
>> for multimedia session negotiation, instant messaging, presence,
>> file transfer, capabilities discovery, notifications, and other types of
>> real-time functionality:
>>
>> o  The Session Initiation Protocol (SIP), along with various SIP
>>     extensions developed within the SIP for Instant Messaging and
>>     Presence Leveraging Extensions (SIMPLE) Working Group.
>>
>> o  The Extensible Messaging and Presence Protocol (XMPP), along
>>     with various XMPP extensions developed by the IETF as well as by
>>     the XMPP Standards Foundation.
>>
>> SIP has been focused primarily on media session negotiation (e.g. audio
>> and video), whereas XMPP has been focused primarily on messaging and
>> presence.  As a result, the technologies are mostly complementary.
>> However, there is also some overlap between SIP and XMPP, since there
>> are SIP extensions for messaging, presence, groupchat, file transfer
>> (etc.) and there are XMPP extensions for multimedia session negotiation.
>> This overlap has practical implications, since some deployed services
>> use SIP for both media and (broadly) messaging, whereas other deployed
>> services use XMPP for both messaging and media.  When such services wish
>> to exchange information, they often need to translate their native
>> protocol (either SIP or XMPP) to the other protocol (either XMPP or
>> SIP).
>>
>> Implementers needing to perform such protocol mappings have often worked
>> out their own heuristics for doing so.  Unfortunately, these heuristics
>> are not always consistent, which can lead to interoperability problems.
>>
>> Objectives
>>
>> To make it easier for implementers to enable interworking between
>> SIP-based systems and XMPP-based systems, several Internet-Drafts have
>> defined guidelines for protocol mapping between SIP and XMPP, starting
>> with draft-saintandre-xmpp-simple-00 in early 2004.  The current
>> documents are:
>>
>> draft-saintandre-sip-xmpp-core
>> draft-saintandre-sip-xmpp-presence
>> draft-saintandre-sip-xmpp-im
>> draft-saintandre-sip-xmpp-chat
>> draft-saintandre-sip-xmpp-groupchat
>>
>> These documents are quite stable and the authors have received feedback
>> from a number of implementers over the years.  However, implementers do
>> not always know about these documents because they are Internet-Drafts
>> and sometimes have expired.  Thus it would be helpful to polish them off
>> and publish them as RFCs (and perhaps other documents in the same series,
>> covering topics like media signalling, capabilities discovery, and file
>> transfer).
>>
>> Deliverables
>>
>> 1. Address mapping and error handling
>> 2. Presence mapping
>> 3. Mapping for single instant messages
>> 4. Mapping for one-to-one text chat sessions
>> 5. Mapping for multi-user text chat sessions
>>
>> Any additional work would require a recharter.
>>
>> Milestones
>>
>> To be determined.
>>
>> ###
>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>
>
>
> --
> Salvatore Loreto, PhD
> www.sloreto.com
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

From saul@ag-projects.com  Wed Feb 20 13:03:29 2013
Return-Path: <saul@ag-projects.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFCF021F8703 for <dispatch@ietfa.amsl.com>; Wed, 20 Feb 2013 13:03:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.688
X-Spam-Level: 
X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MuIOSr2uoSgB for <dispatch@ietfa.amsl.com>; Wed, 20 Feb 2013 13:03:29 -0800 (PST)
Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id B085F21F8721 for <dispatch@ietf.org>; Wed, 20 Feb 2013 13:03:28 -0800 (PST)
Received: by mail.sipthor.net (Postfix, from userid 5001) id 3566BB35DF; Wed, 20 Feb 2013 22:03:27 +0100 (CET)
Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 68B8AB0067; Wed, 20 Feb 2013 22:03:25 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= <saul@ag-projects.com>
In-Reply-To: <51253628.7030209@jitsi.org>
Date: Wed, 20 Feb 2013 22:03:25 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <299FC19C-95D9-4A71-8602-AE239FDD89A6@ag-projects.com>
References: <511EB8B0.8090104@stpeter.im> <51253628.7030209@jitsi.org>
To: Emil Ivov <emcho@jitsi.org>
X-Mailer: Apple Mail (2.1085)
Cc: DISPATCH <dispatch@ietf.org>
Subject: Re: [dispatch] Charter Proposal: SIP-XMPP Mapping
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Feb 2013 21:03:29 -0000

On Feb 20, 2013, at 9:46 PM, Emil Ivov wrote:

> Mapping SIP to XMPP is something I personally view as very important =
and
> this proposal seems very reasonable and well targeted at addressing =
the
> issue.
>=20

+1.

> Emil
>=20
> On 15.02.13, 23:37, Peter Saint-Andre wrote:
>> Charter Proposal: SIP-XMPP Mapping
>> DISPATCH WG
>> IETF 86, Orlando
>>=20
>> Problem Statement
>>=20
>> The IETF has defined two signalling technologies that can be used
>> for multimedia session negotiation, instant messaging, presence,
>> file transfer, capabilities discovery, notifications, and other types =
of
>> real-time functionality:
>>=20
>> o  The Session Initiation Protocol (SIP), along with various SIP
>>   extensions developed within the SIP for Instant Messaging and
>>   Presence Leveraging Extensions (SIMPLE) Working Group.
>>=20
>> o  The Extensible Messaging and Presence Protocol (XMPP), along
>>   with various XMPP extensions developed by the IETF as well as by
>>   the XMPP Standards Foundation.
>>=20
>> SIP has been focused primarily on media session negotiation (e.g. =
audio
>> and video), whereas XMPP has been focused primarily on messaging and
>> presence.  As a result, the technologies are mostly complementary.
>> However, there is also some overlap between SIP and XMPP, since there
>> are SIP extensions for messaging, presence, groupchat, file transfer
>> (etc.) and there are XMPP extensions for multimedia session =
negotiation.
>> This overlap has practical implications, since some deployed services
>> use SIP for both media and (broadly) messaging, whereas other =
deployed
>> services use XMPP for both messaging and media.  When such services =
wish
>> to exchange information, they often need to translate their native
>> protocol (either SIP or XMPP) to the other protocol (either XMPP or
>> SIP).
>>=20
>> Implementers needing to perform such protocol mappings have often =
worked
>> out their own heuristics for doing so.  Unfortunately, these =
heuristics
>> are not always consistent, which can lead to interoperability =
problems.
>>=20
>> Objectives
>>=20
>> To make it easier for implementers to enable interworking between
>> SIP-based systems and XMPP-based systems, several Internet-Drafts =
have
>> defined guidelines for protocol mapping between SIP and XMPP, =
starting
>> with draft-saintandre-xmpp-simple-00 in early 2004.  The current
>> documents are:
>>=20
>> draft-saintandre-sip-xmpp-core
>> draft-saintandre-sip-xmpp-presence
>> draft-saintandre-sip-xmpp-im
>> draft-saintandre-sip-xmpp-chat
>> draft-saintandre-sip-xmpp-groupchat
>>=20
>> These documents are quite stable and the authors have received =
feedback
>> from a number of implementers over the years.  However, implementers =
do
>> not always know about these documents because they are =
Internet-Drafts
>> and sometimes have expired.  Thus it would be helpful to polish them =
off
>> and publish them as RFCs (and perhaps other documents in the same =
series,
>> covering topics like media signalling, capabilities discovery, and =
file
>> transfer).
>>=20
>> Deliverables
>>=20
>> 1. Address mapping and error handling
>> 2. Presence mapping
>> 3. Mapping for single instant messages
>> 4. Mapping for one-to-one text chat sessions
>> 5. Mapping for multi-user text chat sessions
>>=20
>> Any additional work would require a recharter.
>>=20
>> Milestones
>>=20
>> To be determined.
>>=20
>> ###
>>=20
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>>=20
>=20
> --=20
> https://jitsi.org
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

--
Sa=FAl Ibarra Corretg=E9
AG Projects




From stpeter@stpeter.im  Wed Feb 20 18:27:54 2013
Return-Path: <stpeter@stpeter.im>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 438DD21F8D0A for <dispatch@ietfa.amsl.com>; Wed, 20 Feb 2013 18:27:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.592
X-Spam-Level: 
X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6Vq2gs7d84L for <dispatch@ietfa.amsl.com>; Wed, 20 Feb 2013 18:27:53 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 56A4821F88CA for <dispatch@ietf.org>; Wed, 20 Feb 2013 18:27:53 -0800 (PST)
Received: from [192.168.1.7] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B455C403CD; Wed, 20 Feb 2013 19:35:20 -0700 (MST)
Message-ID: <51258623.1060202@stpeter.im>
Date: Wed, 20 Feb 2013 19:27:47 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: "Dale R. Worley" <worley@ariadne.com>
References: <51102D21.10503@stpeter.im> <7D58B263-0EA7-4F3C-9274-175B10E9713B@softarmor.com> <201302131345.r1DDjwOa1783885@shell01.TheWorld.com>
In-Reply-To: <201302131345.r1DDjwOa1783885@shell01.TheWorld.com>
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: dispatch@ietf.org
Subject: Re: [dispatch] URI schemes in P-Asserted-Identity
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Feb 2013 02:27:54 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2/13/13 6:45 AM, Dale R. Worley wrote:
>> From: Dean Willis <dean.willis@softarmor.com>
>> 
>> IIRC, we meant to use Contact: for alt-protocol references.
>> 
>> RFC 3261 11.2 shows the use of a Contact: field in a response to
>> an Options request to indicate an alternate protocol contact:
>> 
>> "Contact header fields MAY be present in a 200 (OK)  response
>> and have the same semantics as in a 3xx response.  That is,  they
>> may list a set of alternative names and methods of reaching the
>> user."
> 
>> I suspect that RFC 3261 12.1.2 is overstrict in its restriction
>> of Contact in an dialog-initiating request to encode exactly one
>> URI which must be SIP or SIPS.  I'm thinking it should say
>> "Exactly one SIP or SIPS URI" without restricting additional URIs
>> that might be present.
> 
> I agree with Paul here.
> 
> The difficulty with Contact is that it has two distinctly
> different uses.  One use is to indicate "You can contact this AOR
> here."  That's its purpose in 3xx responses and 2xx responses to
> OPTIONS.  The other use is, "This is the routing address for this
> endpoint, for this dialog."  That's its purpose in INVITE and 2xx
> responses to INVITEs.
> 
> As far as I can tell, this unspoken distinction was
> well-established by the time RFC 3261 was approved.

Revisiting this topic, I understand the distinction here, but that
leaves me wondering how to include an XMPP address in a SIP INVITE.
Apparently both P-Asserted-Identity (or P-Preferred-Identity) and
Contact are inappropriate. And defining a new SIP header seems to be a
non-starter. However, I suppose the Contact header could be included
in non-INVITE messages, such as OPTIONS.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRJYYjAAoJEOoGpJErxa2pcH8P/ArcB3Kwki7ZDf+fB4jNQoY+
X6rK/1UqGzBsn5usraenL/zwr5Q7asOTGZOpEt6KPfszyKa7+AhQGfFWNji9ifj5
KTZqfeDO2VXXVDr2nTQJffxMXHt6q6Ate1KhrYfctyjYW0wZMF08el9kZtLMKFwc
qiRASCcrA0nv6oqOFO6vRQ99BfP94TGII4TqNU41pBphDwyX/61Ln9yMzfpEuh/2
VlO5+kZoV1auyawBYb5wHakioFc2bqGR3wwAVPrpqhs6DZtRY/jArMaa/MUHdBhL
k8Aw799RN55MaIePtdq4AjlgpCYmpKy4kYkfl8TBQ1hQSjoAtU5dZwhcpgEt27YY
mqe23aXegT/O0hhEcl2L/rmgm7CDYTKgjZ+t/0N6yg/FzE8PnUJl8JOPXs4+J3NC
2kpOnpnTUKhC7nD6IzRTrud2uHU5UFJWodsubzVDF1nUD/F/m/b2Sg/8twZW+P/Z
W3fY3gi374+ZiEzZqh9+Eumvda/12UGKjYcSGDuYDD403ONvW24aURAMD9N3WtWY
HXzio+foM5YKB1Zu3FImDbAmu7EIogGpAyhF6fazGOk0Ytyr000URfI/pj8gPYQi
BYJV5klSdq6U7QVXAry+5cMJjfCAD24V4ia7H6C3chRQXMRZDCY6yCrBtbfXsYAm
MF+//A+qeyD4x/i5Q96c
=z5X3
-----END PGP SIGNATURE-----

From prvs=757a03c31=ross_christopher@bah.com  Wed Feb 20 18:42:48 2013
Return-Path: <prvs=757a03c31=ross_christopher@bah.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2A51F0D08 for <dispatch@ietfa.amsl.com>; Wed, 20 Feb 2013 18:42:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level: 
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVNxRGRXl5Hq for <dispatch@ietfa.amsl.com>; Wed, 20 Feb 2013 18:42:46 -0800 (PST)
Received: from mclniron01-ext.bah.com (mclniron01-ext.bah.com [128.229.5.20]) by ietfa.amsl.com (Postfix) with ESMTP id 0734021F87E0 for <dispatch@ietf.org>; Wed, 20 Feb 2013 18:42:45 -0800 (PST)
x-SBRS: None
X-REMOTE-IP: 10.12.10.57
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqIEAOqIJVEKDAo5/2dsb2JhbAA8CcBdgRtzgh8BAQEDAQEBATcPBSAQBwYBCA0EAwEBAQEKAgERCSgGCgEUCQkBBAoJCAwJBIdfAwkStksNiVqMN4EGBwmBDgIGBRsGDgSCWWEDlFABh3CFMYgcgXI1
X-IronPort-AV: E=Sophos;i="4.84,705,1355115600"; d="scan'208";a="215947940"
Received: from unknown (HELO ASHBCSHB03.resource.ds.bah.com) ([10.12.10.57]) by mclniron01-int.bah.com with ESMTP; 20 Feb 2013 21:42:42 -0500
Received: from ASHBDAG1M1.resource.ds.bah.com ([169.254.1.38]) by ASHBCSHB03.resource.ds.bah.com ([10.12.10.57]) with mapi id 14.02.0318.004; Wed, 20 Feb 2013 21:42:41 -0500
From: "Ross, Christopher [USA]" <ross_christopher@bah.com>
To: "dispatch@ietf.org" <dispatch@ietf.org>
Thread-Topic: Charter Proposal: SIP-XMPP Mapping 
Thread-Index: Ac4P3Mkw7PigsQK+SIWK9KUzeEzlfA==
Date: Thu, 21 Feb 2013 02:42:41 +0000
Message-ID: <250DB97B56739E46BCC637EEE443BDA14D2ADCDF@ASHBDAG1M1.resource.ds.bah.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.12.5.20]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dispatch] Charter Proposal: SIP-XMPP Mapping
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Feb 2013 02:42:48 -0000

Continuing this work and making it official would help to solve a lot of th=
e interoperability challenges and mapping issues we see between products to=
day.=20

I hope the community can work together to push this work forward.

-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal=
f Of dispatch-request@ietf.org
Sent: Wednesday, February 20, 2013 9:28 PM
To: dispatch@ietf.org
Subject: [External] dispatch Digest, Vol 47, Issue 15

If you have received this digest without all the individual message attachm=
ents you will need to update your digest options in your list subscription.=
  To do so, go to=20

https://www.ietf.org/mailman/listinfo/dispatch

Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME o=
r Plain Text Digests?" to MIME.  You can set this option globally for all t=
he list digests you receive at this point.



Send dispatch mailing list submissions to
	dispatch@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/dispatch
or, via email, send a message with subject or body 'help' to
	dispatch-request@ietf.org

You can reach the person managing the list at
	dispatch-owner@ietf.org

When replying, please edit your Subject line so it is more specific than "R=
e: Contents of dispatch digest..."


Today's Topics:

   1. Re: Charter Proposal: SIP-XMPP Mapping (Salvatore Loreto)
   2. Re: Charter Proposal: SIP-XMPP Mapping (Emil Ivov)
   3. Re: Charter Proposal: SIP-XMPP Mapping (Michael Lundberg)
   4. Re: Charter Proposal: SIP-XMPP Mapping (Sa?l Ibarra Corretg?)
   5. Re: URI schemes in P-Asserted-Identity (Peter Saint-Andre)


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

Message: 1
Date: Wed, 20 Feb 2013 22:42:44 +0200
From: Salvatore Loreto <salvatore.loreto@ericsson.com>
To: dispatch@ietf.org
Subject: Re: [dispatch] Charter Proposal: SIP-XMPP Mapping
Message-ID: <51253544.3020901@ericsson.com>
Content-Type: text/plain; charset=3D"ISO-8859-1"; format=3Dflowed

I do support this proposal


/Sal

On 2/16/13 12:37 AM, Peter Saint-Andre wrote:
> Charter Proposal: SIP-XMPP Mapping
> DISPATCH WG
> IETF 86, Orlando
>
> Problem Statement
>
> The IETF has defined two signalling technologies that can be used for=20
> multimedia session negotiation, instant messaging, presence, file=20
> transfer, capabilities discovery, notifications, and other types of=20
> real-time functionality:
>
> o  The Session Initiation Protocol (SIP), along with various SIP
>     extensions developed within the SIP for Instant Messaging and
>     Presence Leveraging Extensions (SIMPLE) Working Group.
>
> o  The Extensible Messaging and Presence Protocol (XMPP), along
>     with various XMPP extensions developed by the IETF as well as by
>     the XMPP Standards Foundation.
>
> SIP has been focused primarily on media session negotiation (e.g.=20
> audio and video), whereas XMPP has been focused primarily on messaging=20
> and presence.  As a result, the technologies are mostly complementary.
> However, there is also some overlap between SIP and XMPP, since there=20
> are SIP extensions for messaging, presence, groupchat, file transfer
> (etc.) and there are XMPP extensions for multimedia session negotiation.
> This overlap has practical implications, since some deployed services=20
> use SIP for both media and (broadly) messaging, whereas other deployed=20
> services use XMPP for both messaging and media.  When such services=20
> wish to exchange information, they often need to translate their=20
> native protocol (either SIP or XMPP) to the other protocol (either=20
> XMPP or SIP).
>
> Implementers needing to perform such protocol mappings have often=20
> worked out their own heuristics for doing so.  Unfortunately, these=20
> heuristics are not always consistent, which can lead to interoperability =
problems.
>
> Objectives
>
> To make it easier for implementers to enable interworking between=20
> SIP-based systems and XMPP-based systems, several Internet-Drafts have=20
> defined guidelines for protocol mapping between SIP and XMPP, starting=20
> with draft-saintandre-xmpp-simple-00 in early 2004.  The current=20
> documents are:
>
> draft-saintandre-sip-xmpp-core
> draft-saintandre-sip-xmpp-presence
> draft-saintandre-sip-xmpp-im
> draft-saintandre-sip-xmpp-chat
> draft-saintandre-sip-xmpp-groupchat
>
> These documents are quite stable and the authors have received=20
> feedback from a number of implementers over the years.  However,=20
> implementers do not always know about these documents because they are=20
> Internet-Drafts and sometimes have expired.  Thus it would be helpful=20
> to polish them off and publish them as RFCs (and perhaps other=20
> documents in the same series, covering topics like media signalling,=20
> capabilities discovery, and file transfer).
>
> Deliverables
>
> 1. Address mapping and error handling
> 2. Presence mapping
> 3. Mapping for single instant messages 4. Mapping for one-to-one text=20
> chat sessions 5. Mapping for multi-user text chat sessions
>
> Any additional work would require a recharter.
>
> Milestones
>
> To be determined.
>
> ###
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch


--
Salvatore Loreto, PhD
www.sloreto.com



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

Message: 2
Date: Wed, 20 Feb 2013 21:46:32 +0100
From: Emil Ivov <emcho@jitsi.org>
To: Peter Saint-Andre <stpeter@stpeter.im>
Cc: DISPATCH <dispatch@ietf.org>
Subject: Re: [dispatch] Charter Proposal: SIP-XMPP Mapping
Message-ID: <51253628.7030209@jitsi.org>
Content-Type: text/plain; charset=3DISO-8859-1

Mapping SIP to XMPP is something I personally view as very important and
this proposal seems very reasonable and well targeted at addressing the
issue.

Emil

On 15.02.13, 23:37, Peter Saint-Andre wrote:
> Charter Proposal: SIP-XMPP Mapping
> DISPATCH WG
> IETF 86, Orlando
>=20
> Problem Statement
>=20
> The IETF has defined two signalling technologies that can be used
> for multimedia session negotiation, instant messaging, presence,
> file transfer, capabilities discovery, notifications, and other types of
> real-time functionality:
>=20
> o  The Session Initiation Protocol (SIP), along with various SIP
>    extensions developed within the SIP for Instant Messaging and
>    Presence Leveraging Extensions (SIMPLE) Working Group.
>=20
> o  The Extensible Messaging and Presence Protocol (XMPP), along
>    with various XMPP extensions developed by the IETF as well as by
>    the XMPP Standards Foundation.
>=20
> SIP has been focused primarily on media session negotiation (e.g. audio
> and video), whereas XMPP has been focused primarily on messaging and
> presence.  As a result, the technologies are mostly complementary.
> However, there is also some overlap between SIP and XMPP, since there
> are SIP extensions for messaging, presence, groupchat, file transfer
> (etc.) and there are XMPP extensions for multimedia session negotiation.
> This overlap has practical implications, since some deployed services
> use SIP for both media and (broadly) messaging, whereas other deployed
> services use XMPP for both messaging and media.  When such services wish
> to exchange information, they often need to translate their native
> protocol (either SIP or XMPP) to the other protocol (either XMPP or
> SIP).
>=20
> Implementers needing to perform such protocol mappings have often worked
> out their own heuristics for doing so.  Unfortunately, these heuristics
> are not always consistent, which can lead to interoperability problems.
>=20
> Objectives
>=20
> To make it easier for implementers to enable interworking between
> SIP-based systems and XMPP-based systems, several Internet-Drafts have
> defined guidelines for protocol mapping between SIP and XMPP, starting
> with draft-saintandre-xmpp-simple-00 in early 2004.  The current
> documents are:
>=20
> draft-saintandre-sip-xmpp-core
> draft-saintandre-sip-xmpp-presence
> draft-saintandre-sip-xmpp-im
> draft-saintandre-sip-xmpp-chat
> draft-saintandre-sip-xmpp-groupchat
>=20
> These documents are quite stable and the authors have received feedback
> from a number of implementers over the years.  However, implementers do
> not always know about these documents because they are Internet-Drafts
> and sometimes have expired.  Thus it would be helpful to polish them off
> and publish them as RFCs (and perhaps other documents in the same series,
> covering topics like media signalling, capabilities discovery, and file
> transfer).
>=20
> Deliverables
>=20
> 1. Address mapping and error handling
> 2. Presence mapping
> 3. Mapping for single instant messages
> 4. Mapping for one-to-one text chat sessions
> 5. Mapping for multi-user text chat sessions
>=20
> Any additional work would require a recharter.
>=20
> Milestones
>=20
> To be determined.
>=20
> ###
>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>=20

--=20
https://jitsi.org


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

Message: 3
Date: Wed, 20 Feb 2013 15:55:23 -0500
From: Michael Lundberg <michaellundberg.ietf@gmail.com>
To: dispatch@ietf.org
Subject: Re: [dispatch] Charter Proposal: SIP-XMPP Mapping
Message-ID:
	<CANVDpGFPfgeo5_zu0S1cf1foHMwax0MohdY-MfaVjySC7634LQ@mail.gmail.com>
Content-Type: text/plain; charset=3DISO-8859-1

I strongly support this proposal!

Michael

On Wed, Feb 20, 2013 at 3:42 PM, Salvatore Loreto
<salvatore.loreto@ericsson.com> wrote:
> I do support this proposal
>
>
> /Sal
>
> On 2/16/13 12:37 AM, Peter Saint-Andre wrote:
>>
>> Charter Proposal: SIP-XMPP Mapping
>> DISPATCH WG
>> IETF 86, Orlando
>>
>> Problem Statement
>>
>> The IETF has defined two signalling technologies that can be used
>> for multimedia session negotiation, instant messaging, presence,
>> file transfer, capabilities discovery, notifications, and other types of
>> real-time functionality:
>>
>> o  The Session Initiation Protocol (SIP), along with various SIP
>>     extensions developed within the SIP for Instant Messaging and
>>     Presence Leveraging Extensions (SIMPLE) Working Group.
>>
>> o  The Extensible Messaging and Presence Protocol (XMPP), along
>>     with various XMPP extensions developed by the IETF as well as by
>>     the XMPP Standards Foundation.
>>
>> SIP has been focused primarily on media session negotiation (e.g. audio
>> and video), whereas XMPP has been focused primarily on messaging and
>> presence.  As a result, the technologies are mostly complementary.
>> However, there is also some overlap between SIP and XMPP, since there
>> are SIP extensions for messaging, presence, groupchat, file transfer
>> (etc.) and there are XMPP extensions for multimedia session negotiation.
>> This overlap has practical implications, since some deployed services
>> use SIP for both media and (broadly) messaging, whereas other deployed
>> services use XMPP for both messaging and media.  When such services wish
>> to exchange information, they often need to translate their native
>> protocol (either SIP or XMPP) to the other protocol (either XMPP or
>> SIP).
>>
>> Implementers needing to perform such protocol mappings have often worked
>> out their own heuristics for doing so.  Unfortunately, these heuristics
>> are not always consistent, which can lead to interoperability problems.
>>
>> Objectives
>>
>> To make it easier for implementers to enable interworking between
>> SIP-based systems and XMPP-based systems, several Internet-Drafts have
>> defined guidelines for protocol mapping between SIP and XMPP, starting
>> with draft-saintandre-xmpp-simple-00 in early 2004.  The current
>> documents are:
>>
>> draft-saintandre-sip-xmpp-core
>> draft-saintandre-sip-xmpp-presence
>> draft-saintandre-sip-xmpp-im
>> draft-saintandre-sip-xmpp-chat
>> draft-saintandre-sip-xmpp-groupchat
>>
>> These documents are quite stable and the authors have received feedback
>> from a number of implementers over the years.  However, implementers do
>> not always know about these documents because they are Internet-Drafts
>> and sometimes have expired.  Thus it would be helpful to polish them off
>> and publish them as RFCs (and perhaps other documents in the same series=
,
>> covering topics like media signalling, capabilities discovery, and file
>> transfer).
>>
>> Deliverables
>>
>> 1. Address mapping and error handling
>> 2. Presence mapping
>> 3. Mapping for single instant messages
>> 4. Mapping for one-to-one text chat sessions
>> 5. Mapping for multi-user text chat sessions
>>
>> Any additional work would require a recharter.
>>
>> Milestones
>>
>> To be determined.
>>
>> ###
>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>
>
>
> --
> Salvatore Loreto, PhD
> www.sloreto.com
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch


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

Message: 4
Date: Wed, 20 Feb 2013 22:03:25 +0100
From: Sa?l Ibarra Corretg? <saul@ag-projects.com>
To: Emil Ivov <emcho@jitsi.org>
Cc: DISPATCH <dispatch@ietf.org>
Subject: Re: [dispatch] Charter Proposal: SIP-XMPP Mapping
Message-ID: <299FC19C-95D9-4A71-8602-AE239FDD89A6@ag-projects.com>
Content-Type: text/plain; charset=3Diso-8859-1


On Feb 20, 2013, at 9:46 PM, Emil Ivov wrote:

> Mapping SIP to XMPP is something I personally view as very important and
> this proposal seems very reasonable and well targeted at addressing the
> issue.
>=20

+1.

> Emil
>=20
> On 15.02.13, 23:37, Peter Saint-Andre wrote:
>> Charter Proposal: SIP-XMPP Mapping
>> DISPATCH WG
>> IETF 86, Orlando
>>=20
>> Problem Statement
>>=20
>> The IETF has defined two signalling technologies that can be used
>> for multimedia session negotiation, instant messaging, presence,
>> file transfer, capabilities discovery, notifications, and other types of
>> real-time functionality:
>>=20
>> o  The Session Initiation Protocol (SIP), along with various SIP
>>   extensions developed within the SIP for Instant Messaging and
>>   Presence Leveraging Extensions (SIMPLE) Working Group.
>>=20
>> o  The Extensible Messaging and Presence Protocol (XMPP), along
>>   with various XMPP extensions developed by the IETF as well as by
>>   the XMPP Standards Foundation.
>>=20
>> SIP has been focused primarily on media session negotiation (e.g. audio
>> and video), whereas XMPP has been focused primarily on messaging and
>> presence.  As a result, the technologies are mostly complementary.
>> However, there is also some overlap between SIP and XMPP, since there
>> are SIP extensions for messaging, presence, groupchat, file transfer
>> (etc.) and there are XMPP extensions for multimedia session negotiation.
>> This overlap has practical implications, since some deployed services
>> use SIP for both media and (broadly) messaging, whereas other deployed
>> services use XMPP for both messaging and media.  When such services wish
>> to exchange information, they often need to translate their native
>> protocol (either SIP or XMPP) to the other protocol (either XMPP or
>> SIP).
>>=20
>> Implementers needing to perform such protocol mappings have often worked
>> out their own heuristics for doing so.  Unfortunately, these heuristics
>> are not always consistent, which can lead to interoperability problems.
>>=20
>> Objectives
>>=20
>> To make it easier for implementers to enable interworking between
>> SIP-based systems and XMPP-based systems, several Internet-Drafts have
>> defined guidelines for protocol mapping between SIP and XMPP, starting
>> with draft-saintandre-xmpp-simple-00 in early 2004.  The current
>> documents are:
>>=20
>> draft-saintandre-sip-xmpp-core
>> draft-saintandre-sip-xmpp-presence
>> draft-saintandre-sip-xmpp-im
>> draft-saintandre-sip-xmpp-chat
>> draft-saintandre-sip-xmpp-groupchat
>>=20
>> These documents are quite stable and the authors have received feedback
>> from a number of implementers over the years.  However, implementers do
>> not always know about these documents because they are Internet-Drafts
>> and sometimes have expired.  Thus it would be helpful to polish them off
>> and publish them as RFCs (and perhaps other documents in the same series=
,
>> covering topics like media signalling, capabilities discovery, and file
>> transfer).
>>=20
>> Deliverables
>>=20
>> 1. Address mapping and error handling
>> 2. Presence mapping
>> 3. Mapping for single instant messages
>> 4. Mapping for one-to-one text chat sessions
>> 5. Mapping for multi-user text chat sessions
>>=20
>> Any additional work would require a recharter.
>>=20
>> Milestones
>>=20
>> To be determined.
>>=20
>> ###
>>=20
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>>=20
>=20
> --=20
> https://jitsi.org
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

--
Sa?l Ibarra Corretg?
AG Projects





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

Message: 5
Date: Wed, 20 Feb 2013 19:27:47 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
To: "Dale R. Worley" <worley@ariadne.com>
Cc: dispatch@ietf.org
Subject: Re: [dispatch] URI schemes in P-Asserted-Identity
Message-ID: <51258623.1060202@stpeter.im>
Content-Type: text/plain; charset=3DUTF-8

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2/13/13 6:45 AM, Dale R. Worley wrote:
>> From: Dean Willis <dean.willis@softarmor.com>
>>=20
>> IIRC, we meant to use Contact: for alt-protocol references.
>>=20
>> RFC 3261 11.2 shows the use of a Contact: field in a response to
>> an Options request to indicate an alternate protocol contact:
>>=20
>> "Contact header fields MAY be present in a 200 (OK)  response
>> and have the same semantics as in a 3xx response.  That is,  they
>> may list a set of alternative names and methods of reaching the
>> user."
>=20
>> I suspect that RFC 3261 12.1.2 is overstrict in its restriction
>> of Contact in an dialog-initiating request to encode exactly one
>> URI which must be SIP or SIPS.  I'm thinking it should say
>> "Exactly one SIP or SIPS URI" without restricting additional URIs
>> that might be present.
>=20
> I agree with Paul here.
>=20
> The difficulty with Contact is that it has two distinctly
> different uses.  One use is to indicate "You can contact this AOR
> here."  That's its purpose in 3xx responses and 2xx responses to
> OPTIONS.  The other use is, "This is the routing address for this
> endpoint, for this dialog."  That's its purpose in INVITE and 2xx
> responses to INVITEs.
>=20
> As far as I can tell, this unspoken distinction was
> well-established by the time RFC 3261 was approved.

Revisiting this topic, I understand the distinction here, but that
leaves me wondering how to include an XMPP address in a SIP INVITE.
Apparently both P-Asserted-Identity (or P-Preferred-Identity) and
Contact are inappropriate. And defining a new SIP header seems to be a
non-starter. However, I suppose the Contact header could be included
in non-INVITE messages, such as OPTIONS.

Peter

- --=20
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRJYYjAAoJEOoGpJErxa2pcH8P/ArcB3Kwki7ZDf+fB4jNQoY+
X6rK/1UqGzBsn5usraenL/zwr5Q7asOTGZOpEt6KPfszyKa7+AhQGfFWNji9ifj5
KTZqfeDO2VXXVDr2nTQJffxMXHt6q6Ate1KhrYfctyjYW0wZMF08el9kZtLMKFwc
qiRASCcrA0nv6oqOFO6vRQ99BfP94TGII4TqNU41pBphDwyX/61Ln9yMzfpEuh/2
VlO5+kZoV1auyawBYb5wHakioFc2bqGR3wwAVPrpqhs6DZtRY/jArMaa/MUHdBhL
k8Aw799RN55MaIePtdq4AjlgpCYmpKy4kYkfl8TBQ1hQSjoAtU5dZwhcpgEt27YY
mqe23aXegT/O0hhEcl2L/rmgm7CDYTKgjZ+t/0N6yg/FzE8PnUJl8JOPXs4+J3NC
2kpOnpnTUKhC7nD6IzRTrud2uHU5UFJWodsubzVDF1nUD/F/m/b2Sg/8twZW+P/Z
W3fY3gi374+ZiEzZqh9+Eumvda/12UGKjYcSGDuYDD403ONvW24aURAMD9N3WtWY
HXzio+foM5YKB1Zu3FImDbAmu7EIogGpAyhF6fazGOk0Ytyr000URfI/pj8gPYQi
BYJV5klSdq6U7QVXAry+5cMJjfCAD24V4ia7H6C3chRQXMRZDCY6yCrBtbfXsYAm
MF+//A+qeyD4x/i5Q96c
=3Dz5X3
-----END PGP SIGNATURE-----


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

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


End of dispatch Digest, Vol 47, Issue 15
****************************************

From pkyzivat@alum.mit.edu  Wed Feb 20 21:10:11 2013
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC8C121F8840 for <dispatch@ietfa.amsl.com>; Wed, 20 Feb 2013 21:10:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Level: 
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZJ7RDCYm7Zw for <dispatch@ietfa.amsl.com>; Wed, 20 Feb 2013 21:10:09 -0800 (PST)
Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED2521F8855 for <dispatch@ietf.org>; Wed, 20 Feb 2013 21:10:08 -0800 (PST)
Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta06.westchester.pa.mail.comcast.net with comcast id 2tA81l0011HzFnQ56tA8my; Thu, 21 Feb 2013 05:10:08 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([IPv6:2002:328a:e5a4:0:a8f1:ff66:6d55:2419]) by omta14.westchester.pa.mail.comcast.net with comcast id 2tA51l00Q1YAVJP3atA5Ga; Thu, 21 Feb 2013 05:10:08 +0000
Message-ID: <5125AC2D.1020701@alum.mit.edu>
Date: Thu, 21 Feb 2013 00:10:05 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: dispatch@ietf.org
References: <51102D21.10503@stpeter.im> <7D58B263-0EA7-4F3C-9274-175B10E9713B@softarmor.com> <201302131345.r1DDjwOa1783885@shell01.TheWorld.com> <51258623.1060202@stpeter.im>
In-Reply-To: <51258623.1060202@stpeter.im>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361423408; bh=XIyUToqO9j4vTCcpwxKch5/86GJaDofMEV6THFmezt0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=jBCvQP95vV0djoC3zkMyBUt7bpYpUIYy9/BgTQZ58yaT/aphr6Ou/Mrbvkue7XZ8i F6uTpH0muMGTPxYUUjaLdk8z0NT6Xkm6kibAVX0G8ooPUsnP4xYlGYgE3QFMXxQNY8 BfnEw35CWSBpRo10FDRyK46dhaLzhmJGd/rJqVvGBfnlWRptYlD3oWJzIwUCG/Sowg Ss370X5IaRrnHdgBPjONdnBwoEikwhp6VY4IZ8CJZq0U+gCHPDFYxiMIxVelW5NrCo SJ08bF2GDHck0UZVOFItBZD886f53egEl1VlHzExdkZHCFxz+QG9v5A2itW8F+GX+V hnMYVvPFXFqPg==
Subject: Re: [dispatch] URI schemes in P-Asserted-Identity
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Feb 2013 05:10:11 -0000

On 2/20/13 9:27 PM, Peter Saint-Andre wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2/13/13 6:45 AM, Dale R. Worley wrote:
>>> From: Dean Willis <dean.willis@softarmor.com>
>>>
>>> IIRC, we meant to use Contact: for alt-protocol references.
>>>
>>> RFC 3261 11.2 shows the use of a Contact: field in a response to
>>> an Options request to indicate an alternate protocol contact:
>>>
>>> "Contact header fields MAY be present in a 200 (OK)  response
>>> and have the same semantics as in a 3xx response.  That is,  they
>>> may list a set of alternative names and methods of reaching the
>>> user."
>>
>>> I suspect that RFC 3261 12.1.2 is overstrict in its restriction
>>> of Contact in an dialog-initiating request to encode exactly one
>>> URI which must be SIP or SIPS.  I'm thinking it should say
>>> "Exactly one SIP or SIPS URI" without restricting additional URIs
>>> that might be present.
>>
>> I agree with Paul here.
>>
>> The difficulty with Contact is that it has two distinctly
>> different uses.  One use is to indicate "You can contact this AOR
>> here."  That's its purpose in 3xx responses and 2xx responses to
>> OPTIONS.  The other use is, "This is the routing address for this
>> endpoint, for this dialog."  That's its purpose in INVITE and 2xx
>> responses to INVITEs.
>>
>> As far as I can tell, this unspoken distinction was
>> well-established by the time RFC 3261 was approved.
>
> Revisiting this topic, I understand the distinction here, but that
> leaves me wondering how to include an XMPP address in a SIP INVITE.
> Apparently both P-Asserted-Identity (or P-Preferred-Identity) and
> Contact are inappropriate. And defining a new SIP header seems to be a
> non-starter. However, I suppose the Contact header could be included
> in non-INVITE messages, such as OPTIONS.

I still offer Reply-To as a possibility.

	Thanks,
	Paul

> Peter
>
> - --
> Peter Saint-Andre
> https://stpeter.im/
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJRJYYjAAoJEOoGpJErxa2pcH8P/ArcB3Kwki7ZDf+fB4jNQoY+
> X6rK/1UqGzBsn5usraenL/zwr5Q7asOTGZOpEt6KPfszyKa7+AhQGfFWNji9ifj5
> KTZqfeDO2VXXVDr2nTQJffxMXHt6q6Ate1KhrYfctyjYW0wZMF08el9kZtLMKFwc
> qiRASCcrA0nv6oqOFO6vRQ99BfP94TGII4TqNU41pBphDwyX/61Ln9yMzfpEuh/2
> VlO5+kZoV1auyawBYb5wHakioFc2bqGR3wwAVPrpqhs6DZtRY/jArMaa/MUHdBhL
> k8Aw799RN55MaIePtdq4AjlgpCYmpKy4kYkfl8TBQ1hQSjoAtU5dZwhcpgEt27YY
> mqe23aXegT/O0hhEcl2L/rmgm7CDYTKgjZ+t/0N6yg/FzE8PnUJl8JOPXs4+J3NC
> 2kpOnpnTUKhC7nD6IzRTrud2uHU5UFJWodsubzVDF1nUD/F/m/b2Sg/8twZW+P/Z
> W3fY3gi374+ZiEzZqh9+Eumvda/12UGKjYcSGDuYDD403ONvW24aURAMD9N3WtWY
> HXzio+foM5YKB1Zu3FImDbAmu7EIogGpAyhF6fazGOk0Ytyr000URfI/pj8gPYQi
> BYJV5klSdq6U7QVXAry+5cMJjfCAD24V4ia7H6C3chRQXMRZDCY6yCrBtbfXsYAm
> MF+//A+qeyD4x/i5Q96c
> =z5X3
> -----END PGP SIGNATURE-----
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>


From stpeter@stpeter.im  Wed Feb 20 21:15:36 2013
Return-Path: <stpeter@stpeter.im>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7384A21F8899 for <dispatch@ietfa.amsl.com>; Wed, 20 Feb 2013 21:15:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.585
X-Spam-Level: 
X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHFevFZYoS24 for <dispatch@ietfa.amsl.com>; Wed, 20 Feb 2013 21:15:35 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 06B8321F841D for <dispatch@ietf.org>; Wed, 20 Feb 2013 21:15:35 -0800 (PST)
Received: from [192.168.1.7] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6D5A2403CD; Wed, 20 Feb 2013 22:23:04 -0700 (MST)
Message-ID: <5125AD71.8080104@stpeter.im>
Date: Wed, 20 Feb 2013 22:15:29 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
References: <51102D21.10503@stpeter.im> <7D58B263-0EA7-4F3C-9274-175B10E9713B@softarmor.com> <201302131345.r1DDjwOa1783885@shell01.TheWorld.com> <51258623.1060202@stpeter.im> <5125AC2D.1020701@alum.mit.edu>
In-Reply-To: <5125AC2D.1020701@alum.mit.edu>
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: dispatch@ietf.org
Subject: Re: [dispatch] URI schemes in P-Asserted-Identity
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Feb 2013 05:15:37 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2/20/13 10:10 PM, Paul Kyzivat wrote:
> On 2/20/13 9:27 PM, Peter Saint-Andre wrote: On 2/13/13 6:45 AM,
> Dale R. Worley wrote:
>>>>> From: Dean Willis <dean.willis@softarmor.com>
>>>>> 
>>>>> IIRC, we meant to use Contact: for alt-protocol
>>>>> references.
>>>>> 
>>>>> RFC 3261 11.2 shows the use of a Contact: field in a
>>>>> response to an Options request to indicate an alternate
>>>>> protocol contact:
>>>>> 
>>>>> "Contact header fields MAY be present in a 200 (OK)
>>>>> response and have the same semantics as in a 3xx response.
>>>>> That is,  they may list a set of alternative names and
>>>>> methods of reaching the user."
>>>> 
>>>>> I suspect that RFC 3261 12.1.2 is overstrict in its
>>>>> restriction of Contact in an dialog-initiating request to
>>>>> encode exactly one URI which must be SIP or SIPS.  I'm
>>>>> thinking it should say "Exactly one SIP or SIPS URI"
>>>>> without restricting additional URIs that might be present.
>>>> 
>>>> I agree with Paul here.
>>>> 
>>>> The difficulty with Contact is that it has two distinctly 
>>>> different uses.  One use is to indicate "You can contact this
>>>> AOR here."  That's its purpose in 3xx responses and 2xx
>>>> responses to OPTIONS.  The other use is, "This is the routing
>>>> address for this endpoint, for this dialog."  That's its
>>>> purpose in INVITE and 2xx responses to INVITEs.
>>>> 
>>>> As far as I can tell, this unspoken distinction was 
>>>> well-established by the time RFC 3261 was approved.
> 
> Revisiting this topic, I understand the distinction here, but that 
> leaves me wondering how to include an XMPP address in a SIP
> INVITE. Apparently both P-Asserted-Identity (or
> P-Preferred-Identity) and Contact are inappropriate. And defining a
> new SIP header seems to be a non-starter. However, I suppose the
> Contact header could be included in non-INVITE messages, such as
> OPTIONS.
> 
>> I still offer Reply-To as a possibility.

Does Reply-To imply that all replies in the session ought to be
directed to that address? We don't want to "hijack" the session so
that traffic is redirected to the XMPP address, only to advertise the
fact that a dual-stack client can be contacted via the XMPP path in
addition to the SIP path.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRJa1xAAoJEOoGpJErxa2pcNcP/1KZ4Um9meMSIb8OTEzIQU5u
34L/ayV8GVy5/sbetpgdtBHBf/IkM2yVq2FzdIgUWjwu9okLCW4DV9bGzz2jBnvY
CG8Ez5AiPMf7sZx8kNuA75oEPP1Gd+imevRP4Ky206amZgvnjdM/SkRutII51j8u
Vo1vjb7AmvkoxeFrc77gl6+HWcOGiUmlNXJ9vUlRBRrHeWZFOuWWls2fUT/D1DM/
DAuz0f8r+aP5+qVTzna4rdHAGatLX0YvwVXvpYrs22/Cb314BekzHhkw/n5+erpc
17rtcYB2a6b1cG0+WT2ZtfEY9SvXtbwt4N84wal84TCH2SuHxzx6lo1BcuDa3OcV
mD7v/rt5t3pEKP+I32DiQ5lRtxNwd/dI381J6wI6xzX5ZkP7/cFAIB1XmoI7m5Q/
JxEtHR/+jobqXTPF+rfDRNsA77cXTv7584o6B+u1g697t0QGF7nICoZ2MAdLilHU
ebXz6Y0putwCGzjglLUEmsltJ+c06TZg6w1k8nWbQiLNJNvg4yUZRe65XDXu4+BP
A1OP1NnyGhWY/MgIHHBNr6zj4q11bWxAosCm1Ydxw9lcPQu3h34oTQktvSUSeYxF
WVM/j8R8iY6elk31tR2TPKIdZbJfWqfx/F5Z7NCHqqJKGPHXvbbNHS8NLDHGlcxu
kr2rv2Uaj5QKR5fQntcF
=eeai
-----END PGP SIGNATURE-----

From worley@shell01.TheWorld.com  Thu Feb 21 06:31:06 2013
Return-Path: <worley@shell01.TheWorld.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EEE621F8BE0 for <dispatch@ietfa.amsl.com>; Thu, 21 Feb 2013 06:31:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.695
X-Spam-Level: 
X-Spam-Status: No, score=-2.695 tagged_above=-999 required=5 tests=[AWL=0.285,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvIyckNQyq0k for <dispatch@ietfa.amsl.com>; Thu, 21 Feb 2013 06:31:05 -0800 (PST)
Received: from TheWorld.com (pcls4.std.com [192.74.137.144]) by ietfa.amsl.com (Postfix) with ESMTP id 91E7421F881D for <dispatch@ietf.org>; Thu, 21 Feb 2013 06:31:05 -0800 (PST)
Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1LEUcRk019681; Thu, 21 Feb 2013 09:30:40 -0500
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r1LEUbdw2288967; Thu, 21 Feb 2013 09:30:37 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1LEUa632296902; Thu, 21 Feb 2013 09:30:36 -0500 (EST)
Date: Thu, 21 Feb 2013 09:30:36 -0500 (EST)
Message-Id: <201302211430.r1LEUa632296902@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: Peter Saint-Andre <stpeter@stpeter.im>
In-reply-to: <51258623.1060202@stpeter.im>
References: <51102D21.10503@stpeter.im> <7D58B263-0EA7-4F3C-9274-175B10E9713B@softarmor.com> <201302131345.r1DDjwOa1783885@shell01.TheWorld.com> <51258623.1060202@stpeter.im>
Cc: dispatch@ietf.org
Subject: Re: [dispatch] URI schemes in P-Asserted-Identity
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Feb 2013 14:31:06 -0000

> From: Peter Saint-Andre <stpeter@stpeter.im>
> 
> Revisiting this topic, I understand the distinction here, but that
> leaves me wondering how to include an XMPP address in a SIP INVITE.
> Apparently both P-Asserted-Identity (or P-Preferred-Identity) and
> Contact are inappropriate. And defining a new SIP header seems to be a
> non-starter. However, I suppose the Contact header could be included
> in non-INVITE messages, such as OPTIONS.

It seems that the semantic you want is "The UAC asserts this is an
alternative identity for the caller identified by the From: header."
I would think one of the many "identity" headers would supply that,
but after looking a bit, it seems that there is none such defined.

In practice, Remote-Party-Id seems to have that sort of intention, but
there is a general attitude that people are only interested in
"identities" if some trusted network can vouch for them.  You might
want to look into draft-dcsgroup-sip-privacy and
draft-ietf-sip-privacy and the discussions surrounding them to see why
Remote-Party-Id didn't get standardized.

In any case, please don't bastardize some header that has an
incompatible definition.

Dale

From pkyzivat@alum.mit.edu  Thu Feb 21 06:51:02 2013
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E79621F8C55 for <dispatch@ietfa.amsl.com>; Thu, 21 Feb 2013 06:51:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.361
X-Spam-Level: 
X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[AWL=0.076,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BS0l5ljeVEvW for <dispatch@ietfa.amsl.com>; Thu, 21 Feb 2013 06:51:02 -0800 (PST)
Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id CBBF821F8AC3 for <dispatch@ietf.org>; Thu, 21 Feb 2013 06:51:01 -0800 (PST)
Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta15.westchester.pa.mail.comcast.net with comcast id 2zp01l0030mv7h05F2r1DK; Thu, 21 Feb 2013 14:51:01 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id 32r01l01a3ZTu2S3X2r0Dj; Thu, 21 Feb 2013 14:51:01 +0000
Message-ID: <51263454.3040005@alum.mit.edu>
Date: Thu, 21 Feb 2013 09:51:00 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: Peter Saint-Andre <stpeter@stpeter.im>
References: <51102D21.10503@stpeter.im> <7D58B263-0EA7-4F3C-9274-175B10E9713B@softarmor.com> <201302131345.r1DDjwOa1783885@shell01.TheWorld.com> <51258623.1060202@stpeter.im> <5125AC2D.1020701@alum.mit.edu> <5125AD71.8080104@stpeter.im>
In-Reply-To: <5125AD71.8080104@stpeter.im>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361458261; bh=Yvc03ouKAKQmW5zRVZ7oV4PSqgw24ZOMnI9CEKIarvw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=cDYgSrjupQBJsuH7XCu2CxAgT9wl/5D15CyqCKLU7TddXUPUaudQNsKnCvyTu2FvZ WjvRTYZy5e+bdXCQsw5dGAVxK2xH/PDUMeq4EMelv0j0cQh2o8roEfl9dEKdR5O1ip A7J/5GJ5J4ZohYasdFqBDgh85caVuqToTSrvOsLPU1wlyDE6LgdL8mBVHmtuzkl33k Wrz4WouBxa1+Q6UzDaC2KRmNLbqpwRT2XRygRCThosVhJGviA4rbjYzNAwLYn8pgxF hh4Y6MVon8zAt2zU+9sXAUYAnDiXn9k2wXS2eGAbHoY508vXs7w41vgL1OmvpspNgs S9ssXgGYEx6PA==
Cc: dispatch@ietf.org
Subject: Re: [dispatch] URI schemes in P-Asserted-Identity
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Feb 2013 14:51:02 -0000

On 2/21/13 12:15 AM, Peter Saint-Andre wrote:

>>> I still offer Reply-To as a possibility.
>
> Does Reply-To imply that all replies in the session ought to be
> directed to that address? We don't want to "hijack" the session so
> that traffic is redirected to the XMPP address, only to advertise the
> fact that a dual-stack client can be contacted via the XMPP path in
> addition to the SIP path.

AFAIK there is *no* history of Reply-To being used with SIP, though it 
has been present in the syntax forever.

I *guess* that it is present based on analogy to email. In email I guess 
Reply-To typically takes precedence over From as a destination for 
future messages.

So using Reply-To here would be breaking new ground, almost as much as 
introducing a new header would.

To avoid hyjacking, I suppose one could put *both* a sip URI and an xmpp 
URI in the Reply-To. In email that would presumably mean to reply to 
*both*, but in sip it couldn't very well mean that, so someone wanting 
to follow it would be forced to choose.

If we expect anyone to implement this behavior there will need to be 
some document that specifies precisely what behavior is expected. So it 
probably doesn't matter much whether Reply-To is adopted for this 
behavior or a new header is defined.

	Thanks,
	Paul


From stpeter@stpeter.im  Thu Feb 21 07:10:10 2013
Return-Path: <stpeter@stpeter.im>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0386221F8E69 for <dispatch@ietfa.amsl.com>; Thu, 21 Feb 2013 07:10:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.585
X-Spam-Level: 
X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vv7p2rPB+4fv for <dispatch@ietfa.amsl.com>; Thu, 21 Feb 2013 07:10:08 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7132221F8E68 for <dispatch@ietf.org>; Thu, 21 Feb 2013 07:10:08 -0800 (PST)
Received: from [192.168.1.2] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 230FD403CD; Thu, 21 Feb 2013 08:17:39 -0700 (MST)
Message-ID: <512638CF.6020508@stpeter.im>
Date: Thu, 21 Feb 2013 08:10:07 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: "Dale R. Worley" <worley@ariadne.com>
References: <51102D21.10503@stpeter.im> <7D58B263-0EA7-4F3C-9274-175B10E9713B@softarmor.com> <201302131345.r1DDjwOa1783885@shell01.TheWorld.com> <51258623.1060202@stpeter.im> <201302211430.r1LEUa632296902@shell01.TheWorld.com>
In-Reply-To: <201302211430.r1LEUa632296902@shell01.TheWorld.com>
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: dispatch@ietf.org
Subject: Re: [dispatch] URI schemes in P-Asserted-Identity
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Feb 2013 15:10:10 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2/21/13 7:30 AM, Dale R. Worley wrote:
>> From: Peter Saint-Andre <stpeter@stpeter.im>
>> 
>> Revisiting this topic, I understand the distinction here, but
>> that leaves me wondering how to include an XMPP address in a SIP
>> INVITE. Apparently both P-Asserted-Identity (or
>> P-Preferred-Identity) and Contact are inappropriate. And defining
>> a new SIP header seems to be a non-starter. However, I suppose
>> the Contact header could be included in non-INVITE messages, such
>> as OPTIONS.
> 
> It seems that the semantic you want is "The UAC asserts this is an 
> alternative identity for the caller identified by the From:
> header." I would think one of the many "identity" headers would
> supply that, but after looking a bit, it seems that there is none
> such defined.
> 
> In practice, Remote-Party-Id seems to have that sort of intention,
> but there is a general attitude that people are only interested in 
> "identities" if some trusted network can vouch for them.  You
> might want to look into draft-dcsgroup-sip-privacy and 
> draft-ietf-sip-privacy and the discussions surrounding them to see
> why Remote-Party-Id didn't get standardized.
> 
> In any case, please don't bastardize some header that has an 
> incompatible definition.

Certainly not. That's why we're trying to find out what these headers
really mean in practice so that we don't use the wrong one. Although
I'm starting to get the sense that there is no right one, and this use
case might not warrant a new one (which probably would be stripped out
by b2bua's and such anyway).

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRJjjPAAoJEOoGpJErxa2pvewQAKfkp261PrJdl9IVG5aAoOwG
3sraYYE1mmvxWRSqi85bE/aC9Rs/MtLYwbzJpt1RIIE93/qlN+InBednztjtLZaO
jfvfX+Vy39u4YpjocQRncFLEfmu1cX/m1o6avJSgEqUITA7sYK3T/26TpISlYf7l
gLDMrH4udpoJzCIMcctCEP8DRssgkqTk+PsMajWU0X7Gyffkwvo8xFv1dEdTJ3hP
vRD0/6YFG3osR1r/KQ79x3Sna5yTU0E5rWOdlB/9OX0SWYBFWqvIGd0C63dHwqZ3
eGRSEzVm8JXahn46JUeZIqfD3bL1JDmQe4s59vH50u5KhYvf2xwEN76v9xhr8gTc
4MzRGWsdOrw5qmJV/v7sYclUNMtTokG/Jgr3rNxBgxYwtKsFnrLJdZlqDc14qYbO
hOq2LehjgVEycbc5pw5Hoe6Fs62vqrs4O4ASLGTx/wuP35pns//4hmlrtv+29edH
Z2H/JYanVJW8+5xK/1oORvTtDd4UxCTn7r1OReLNLzG4qgrXEST6YbrxXXK5Mxwe
2P3m6hocwculvOg48wajGgkMqhz+JUCB/d21eC9yrnEFJ1di5aU0EvxaBDNmqxtu
jftkFxAOJmijfmmsketKN9xVnmIt00i1EvodbUAZImn1g1o06PdNOaad0B/MXgW7
2ufFGlqNQOUdMgcuT95+
=Wm1x
-----END PGP SIGNATURE-----

From saul@ag-projects.com  Thu Feb 21 07:19:33 2013
Return-Path: <saul@ag-projects.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A99A21F880F for <dispatch@ietfa.amsl.com>; Thu, 21 Feb 2013 07:19:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.688
X-Spam-Level: 
X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ow3AEFN82znT for <dispatch@ietfa.amsl.com>; Thu, 21 Feb 2013 07:19:32 -0800 (PST)
Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3B47E21F89A3 for <dispatch@ietf.org>; Thu, 21 Feb 2013 07:19:32 -0800 (PST)
Received: by mail.sipthor.net (Postfix, from userid 5001) id 09E69B019B; Thu, 21 Feb 2013 16:19:30 +0100 (CET)
Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 2A851B0132; Thu, 21 Feb 2013 16:19:30 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= <saul@ag-projects.com>
In-Reply-To: <512638CF.6020508@stpeter.im>
Date: Thu, 21 Feb 2013 16:19:29 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <E9347623-B663-4BD0-84EF-B9976AEDE5E8@ag-projects.com>
References: <51102D21.10503@stpeter.im> <7D58B263-0EA7-4F3C-9274-175B10E9713B@softarmor.com> <201302131345.r1DDjwOa1783885@shell01.TheWorld.com> <51258623.1060202@stpeter.im> <201302211430.r1LEUa632296902@shell01.TheWorld.com> <512638CF.6020508@stpeter.im>
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Mailer: Apple Mail (2.1085)
Cc: dispatch@ietf.org
Subject: Re: [dispatch] URI schemes in P-Asserted-Identity
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Feb 2013 15:19:33 -0000

Hi,

On Feb 21, 2013, at 4:10 PM, Peter Saint-Andre wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> On 2/21/13 7:30 AM, Dale R. Worley wrote:
>>> From: Peter Saint-Andre <stpeter@stpeter.im>
>>>=20
>>> Revisiting this topic, I understand the distinction here, but
>>> that leaves me wondering how to include an XMPP address in a SIP
>>> INVITE. Apparently both P-Asserted-Identity (or
>>> P-Preferred-Identity) and Contact are inappropriate. And defining
>>> a new SIP header seems to be a non-starter. However, I suppose
>>> the Contact header could be included in non-INVITE messages, such
>>> as OPTIONS.
>>=20
>> It seems that the semantic you want is "The UAC asserts this is an=20
>> alternative identity for the caller identified by the From:
>> header." I would think one of the many "identity" headers would
>> supply that, but after looking a bit, it seems that there is none
>> such defined.
>>=20
>> In practice, Remote-Party-Id seems to have that sort of intention,
>> but there is a general attitude that people are only interested in=20
>> "identities" if some trusted network can vouch for them.  You
>> might want to look into draft-dcsgroup-sip-privacy and=20
>> draft-ietf-sip-privacy and the discussions surrounding them to see
>> why Remote-Party-Id didn't get standardized.
>>=20
>> In any case, please don't bastardize some header that has an=20
>> incompatible definition.
>=20
> Certainly not. That's why we're trying to find out what these headers
> really mean in practice so that we don't use the wrong one. Although
> I'm starting to get the sense that there is no right one, and this use
> case might not warrant a new one (which probably would be stripped out
> by b2bua's and such anyway).
>=20

What about using a Contact header parameter instead of a header? =
Something like this:

Contact: =
<sip:47065391@192.168.99.53:54819>;+sip.instance=3D"urn:uuid:2af16065-6f4c=
-40a5-8bee-c38678776dec";+xmpp.jid=3D"user@domain.tld"


Regards,

--
Sa=FAl Ibarra Corretg=E9
AG Projects




From victor.pascual.avila@gmail.com  Thu Feb 21 09:38:15 2013
Return-Path: <victor.pascual.avila@gmail.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B24F221F8DE4 for <dispatch@ietfa.amsl.com>; Thu, 21 Feb 2013 09:38:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59YsaZV8LkyX for <dispatch@ietfa.amsl.com>; Thu, 21 Feb 2013 09:38:15 -0800 (PST)
Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by ietfa.amsl.com (Postfix) with ESMTP id CF21A21F8AC3 for <dispatch@ietf.org>; Thu, 21 Feb 2013 09:38:14 -0800 (PST)
Received: by mail-lb0-f175.google.com with SMTP id n3so6950938lbo.20 for <dispatch@ietf.org>; Thu, 21 Feb 2013 09:38:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=vG2IXv6z9ACMZtgHJlbZrZugFPydFbmQ8lkFf65DQbo=; b=YURAvTNu5Fw2Zf0KCHJKKX/tfu/Zo2iWOgyMzaTzOKsJQ93+UCvme732ti3Rk6ypS3 0eCLMivIpzMcvjvIvFggJoA8+r4rQ36VS0kQib6YQnFGfNlltkOobtFT0ABVTF426eHg wiUvLcYXypVwshehUGfCTQG4czGeurACEGI5DrlKUPXyW5wztFFmoRiWM4acNEIOeqKy moXBiwfdM7S+E2EWG+E7iVmabEmAmK2vyOu6aHRnargi9GLqzPAD0TpER3W5uV8DzCb0 JlFFLAHXSnfMIwKAlwVluT85vsmaI9W5p10ygfrrCzjy/CU5hnJRSo7v1GWPtDIdkgu3 j4ug==
MIME-Version: 1.0
X-Received: by 10.152.113.164 with SMTP id iz4mr22062702lab.50.1361468293649;  Thu, 21 Feb 2013 09:38:13 -0800 (PST)
Received: by 10.114.29.101 with HTTP; Thu, 21 Feb 2013 09:38:13 -0800 (PST)
In-Reply-To: <CD442C6C.B156%vpascual@acmepacket.com>
References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <CD442C6C.B156%vpascual@acmepacket.com>
Date: Thu, 21 Feb 2013 18:38:13 +0100
Message-ID: <CAGTXFp-Ee_XsD0NdmrFxjqyUN9cP-+Q2XNAKV35MMTtZJxUEcA@mail.gmail.com>
From: Victor Pascual Avila <victor.pascual.avila@gmail.com>
To: DISPATCH <dispatch@ietf.org>
Content-Type: text/plain; charset=UTF-8
Subject: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Feb 2013 17:38:15 -0000

Hi all,

We have submitted a new Internet draft to describe the WebSocket
Protocol as a Transport for the Binary Floor Control Protocol (BFCP).
We are looking forward to your review comments.

http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00

Best regards,
-Victor


On 2/15/13 6:17 PM, "internet-drafts@ietf.org" <internet-drafts@ietf.org>
wrote:

>
>A new version of I-D, draft-pascual-dispatch-bfcp-websocket-00.txt
>has been successfully submitted by Victor Pascual and posted to the
>IETF repository.
>
>Filename:       draft-pascual-dispatch-bfcp-websocket
>Revision:       00
>Title:          The WebSocket Protocol as a Transport for the Binary Floor
>Control Protocol (BFCP)
>Creation date:  2013-02-15
>Group:          Individual Submission
>Number of pages: 9
>URL:
>http://www.ietf.org/internet-drafts/draft-pascual-dispatch-bfcp-websocket-
>00.txt
>Status:
>http://datatracker.ietf.org/doc/draft-pascual-dispatch-bfcp-websocket
>Htmlized:
>http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00
>
>
>Abstract:
>   The WebSocket protocol enables two-way realtime communication between
>   clients and servers.  This document specifies a new WebSocket sub-
>   protocol as a reliable transport mechanism between Binary Floor
>   Control Protocol (BFCP) entities to enable usage of BFCP in new
>   scenarios.  This document normatively updates
>   [I-D.draft-ietf-bfcpbis-rfc4582bis] and
>   [I-D.draft-ietf-bfcpbis-rfc4583bis]
>
>
>
>
>
>The IETF Secretariat
>

From pkyzivat@alum.mit.edu  Thu Feb 21 13:32:18 2013
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E03321E8034 for <dispatch@ietfa.amsl.com>; Thu, 21 Feb 2013 13:32:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Level: 
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93uqdP3o4eQL for <dispatch@ietfa.amsl.com>; Thu, 21 Feb 2013 13:32:17 -0800 (PST)
Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 4527021E8030 for <dispatch@ietf.org>; Thu, 21 Feb 2013 13:32:17 -0800 (PST)
Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta03.westchester.pa.mail.comcast.net with comcast id 2zjT1l00E1ZXKqc539YGWB; Thu, 21 Feb 2013 21:32:16 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([IPv6:2002:328a:e5a4:0:89fe:3e95:7c2f:c652]) by omta21.westchester.pa.mail.comcast.net with comcast id 39YE1l0202PtzEp3h9YFkC; Thu, 21 Feb 2013 21:32:16 +0000
Message-ID: <5126925E.2010102@alum.mit.edu>
Date: Thu, 21 Feb 2013 16:32:14 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: dispatch@ietf.org
References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <CD442C6C.B156%vpascual@acmepacket.com> <CAGTXFp-Ee_XsD0NdmrFxjqyUN9cP-+Q2XNAKV35MMTtZJxUEcA@mail.gmail.com>
In-Reply-To: <CAGTXFp-Ee_XsD0NdmrFxjqyUN9cP-+Q2XNAKV35MMTtZJxUEcA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361482336; bh=Av8Z0+C1N89rLvn043gw42RhdQ0JHECWMBhRNTm9AF8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ISI+po34lnTIFg5nekALy5OK0g4q56mb871yKR7D6cwW8AP8/P+rRXyfenyKP9PvU 9qS6pEkwJQUORVwjs4QZkhywqf21FkVQs0y6nYnfvYU3+I62RPRgaF/htxaJE6ny/m cUgjQAKbdKJXpQTw4uYSyWs4BRNEFe+9V0KS5M6TiJJCJ01VW8DUzJlaEBIyufOtgF S+8I6M2y6jd4QI6CRRpG8/ExxYfB892/UDjUlBl/DCUE0SwkjYXZeZnt5xwrJAHRmx QVYUBw4pgvhsjNL6mzwTjdT2gaxvBvCAQ9iraRdVw5AWpJPKLcf+HtOtRUeoaz3Jpd qAmVGiYVSWi8g==
Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Feb 2013 21:32:18 -0000

Victor,

A question for you:

Another possibility is to map bfcp over a data channel as being 
specified for rtcweb.

If that were done, would it be a suitable alternative to bfcp over 
websocket?

We are also going to need bfcp support in conjunction with CLUE.
And CLUE is going to have its own data channel. We are aiming to use an 
rtcweb-compatible data channel so that we can have rtcweb browser based 
clue clients.

If bfcp also worked over a data channel, then these multiple uses of 
data channels could all coexist on a single SCTP association. And they 
could work the same regardless of whether or not there are web clients.

	Thanks,
	Paul

On 2/21/13 12:38 PM, Victor Pascual Avila wrote:
> Hi all,
>
> We have submitted a new Internet draft to describe the WebSocket
> Protocol as a Transport for the Binary Floor Control Protocol (BFCP).
> We are looking forward to your review comments.
>
> http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00
>
> Best regards,
> -Victor
>
>
> On 2/15/13 6:17 PM, "internet-drafts@ietf.org" <internet-drafts@ietf.org>
> wrote:
>
>>
>> A new version of I-D, draft-pascual-dispatch-bfcp-websocket-00.txt
>> has been successfully submitted by Victor Pascual and posted to the
>> IETF repository.
>>
>> Filename:       draft-pascual-dispatch-bfcp-websocket
>> Revision:       00
>> Title:          The WebSocket Protocol as a Transport for the Binary Floor
>> Control Protocol (BFCP)
>> Creation date:  2013-02-15
>> Group:          Individual Submission
>> Number of pages: 9
>> URL:
>> http://www.ietf.org/internet-drafts/draft-pascual-dispatch-bfcp-websocket-
>> 00.txt
>> Status:
>> http://datatracker.ietf.org/doc/draft-pascual-dispatch-bfcp-websocket
>> Htmlized:
>> http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00
>>
>>
>> Abstract:
>>    The WebSocket protocol enables two-way realtime communication between
>>    clients and servers.  This document specifies a new WebSocket sub-
>>    protocol as a reliable transport mechanism between Binary Floor
>>    Control Protocol (BFCP) entities to enable usage of BFCP in new
>>    scenarios.  This document normatively updates
>>    [I-D.draft-ietf-bfcpbis-rfc4582bis] and
>>    [I-D.draft-ietf-bfcpbis-rfc4583bis]
>>
>>
>>
>>
>>
>> The IETF Secretariat
>>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>


From stpeter@stpeter.im  Thu Feb 21 13:37:43 2013
Return-Path: <stpeter@stpeter.im>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E84A021E8034 for <dispatch@ietfa.amsl.com>; Thu, 21 Feb 2013 13:37:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.586
X-Spam-Level: 
X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-1y6my1RCXJ for <dispatch@ietfa.amsl.com>; Thu, 21 Feb 2013 13:37:43 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E039821E8030 for <dispatch@ietf.org>; Thu, 21 Feb 2013 13:37:42 -0800 (PST)
Received: from [192.168.1.2] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7DDF1403CD for <dispatch@ietf.org>; Thu, 21 Feb 2013 14:45:14 -0700 (MST)
Message-ID: <512693A0.3060307@stpeter.im>
Date: Thu, 21 Feb 2013 14:37:36 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: DISPATCH <dispatch@ietf.org>
References: <511EB8B0.8090104@stpeter.im>
In-Reply-To: <511EB8B0.8090104@stpeter.im>
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [dispatch] Charter Proposal: SIP-XMPP Mapping
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Feb 2013 21:37:44 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2/15/13 3:37 PM, Peter Saint-Andre wrote:

<snip/>

> The current documents are:
> 
> draft-saintandre-sip-xmpp-core draft-saintandre-sip-xmpp-presence 
> draft-saintandre-sip-xmpp-im draft-saintandre-sip-xmpp-chat 
> draft-saintandre-sip-xmpp-groupchat
> 
> These documents are quite stable and the authors have received
> feedback from a number of implementers over the years.

Another document is draft-saintandre-sip-xmpp-media (republished last
night). It and the groupchat spec are a bit less polished, but I think
they can be cleaned up fairly quickly (and it seems that I'll have a
new co-author on one or both of them to get these done). Just FYI...

Peter

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRJpOgAAoJEOoGpJErxa2pCZcP/01N5FFJcKma6w0SKjPlFTqv
3yzCi9z0tXBChO2FJFMtfiHP43F6qMpgY0weYtqqtHTRbgUvmNdmA8PQfgzdIyc8
ESj5mpDHRWU7ujO1d/Bjf0GQ+sFVCLrT+V7apXV1ED9CZkuA3E6pOYDxjuLoskY4
qur5tGOZr7nU2s0X4ptyjW6L4v/LvefF2x9oGapJJDHd6M8NoEmePql/e6i5CY5C
tnVEMUpUv+ApIHg259XKbkRKwJOsZZWAdadl9QNC2BQv6PTE4lDY75SMYmI99Jwb
+so1gH5OKKNvpYB+/waMkNUligpOkaoWpB6/XxMHlmJ1/Y6JpqjOPvSsAeA4tQ1a
mjIJadrRRi8II87ddhlyT7WLVg+hzHzE7bHjliCKz06dR+B2DyzUVGqKOT0Wsc2T
GyJtiXKOCKJrv3QHjvo0+5O0Ns6je7Yhe6kFBj/Mv4A1NMQu12UvtFWTYN+3yMZr
mKydi6gYwbZild1RYBSNtZJwlKS4NzMfZ4qWY+13Y5XxWfjNVCy+q4jtpdTLj17v
yeq317qBfWZ+2UphWdV4PJNyPEGB2S1U0kXHgXIoAwcogZ7SOnPD/L34kZLuY66/
GYekmABDsX5HsBa9ez/EJQQQwT2u2o5KpFhze0jRvusCOkXSzxHANZ6BViHJHFp4
ZYNMQwpljpFspG9I86Zh
=+tn/
-----END PGP SIGNATURE-----

From ben@nostrum.com  Thu Feb 21 14:23:58 2013
Return-Path: <ben@nostrum.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC8B21F87B6 for <dispatch@ietfa.amsl.com>; Thu, 21 Feb 2013 14:23:57 -0800 (PST)
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.059, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjb9nDxQv2Nx for <dispatch@ietfa.amsl.com>; Thu, 21 Feb 2013 14:23:53 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id EB14021F856D for <dispatch@ietf.org>; Thu, 21 Feb 2013 14:23:50 -0800 (PST)
Received: from [10.0.1.14] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r1LMNjHo040931 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 Feb 2013 16:23:45 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <CAGTXFp9dFa03RB8Ri=b=Lo4VDB_-RpJ9tEjAFiqKZ=A7q3CO4A@mail.gmail.com>
Date: Thu, 21 Feb 2013 16:23:45 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <BDA5C305-7E7D-4D81-A06B-422B37F22AF8@nostrum.com>
References: <20121217161521.30393.14625.idtracker@ietfa.amsl.com> <CCF55522.7A92%vpascual@acmepacket.com> <CAGTXFp9dFa03RB8Ri=b=Lo4VDB_-RpJ9tEjAFiqKZ=A7q3CO4A@mail.gmail.com>
To: Victor Pascual Avila <victor.pascual.avila@gmail.com>
X-Mailer: Apple Mail (2.1499)
Received-SPF: pass (shaman.nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism)
Cc: DISPATCH <dispatch@ietf.org>
Subject: Re: [dispatch] New Version Notification for draft-pd-dispatch-msrp-websocket-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Feb 2013 22:23:58 -0000

Hi,

(I apologize for just getting to this now (usual excuses apply). I hope =
to avoid rehashing things already brought up, but if I fail in that, =
further apologies.)

I think this work is interesting, and I support it. I do have some =
concerns (that seem to pop up whenever adapting a protocol to ws is =
concerned):

** Major:

-- General: Interworking with legacy relays and endpoints:

I infer that an MSRP WebSocket Server is expected to also act as an =
ordinary MSRP relay, in that it can talk to legacy relays and clients. =
Is there a normative requirement for that that I missed? Is it allowed =
to have an MSRP WebSocket server that only enables communication between =
WebSocket Clients?

-- Use of TLS:

I'm very concerned about downgrading the 4976 MUST on use of TLS between =
a client and a relay that it authenticates to. This seems unacceptable =
on it's face. You indicate that the client code may have no control over =
this--can you elaborate?

** Minor:

-- 5.1:

Be careful with the terminology. In MSRP, a "message" means the =
pre-chunked content. If you split it, each piece is a "chunk". I think =
you mean to say that each WebSocket message must contain a single MSRP =
"chunk", correct?

Also, are there issues with large chunks? Does the MSRP concept of =
starting to send large content in a single chunk, but interrupting it if =
needed work with WebSockets?

-- 7:

Can you offer guidance on what should happen if a server tries to use =
HTTP Digest at the MSRP layer, but the client doesn't support it? (The =
reciprocal of "MAY" us usually "MUST". That is, if a device MAY do =
something, the peer MUST gracefully handle it.)

-- 9.1:

I'd like to see some guidance about server certificate matching. Do the =
rules in 4976 and 4975 still apply?



On Dec 17, 2012, at 4:29 PM, Victor Pascual Avila =
<victor.pascual.avila@gmail.com> wrote:

> Dear DISPATCH,
>=20
> comments on the draft below[1] would be appreciated. The proposed =
mechanism has been implemented and there's open-source code available =
for both client[2] and server[3] side implementations.
>=20
> [1] http://tools.ietf.org/html/draft-pd-dispatch-msrp-websocket-00
> [2] http://code.google.com/p/crocodile-msrp/wiki/Overview
> [3] http://www.kamailio.org/wiki/features/new-in-devel#websocket
>=20
> Thanks,
> Peter, Gavin and Victor
>=20
> On 12/17/12 5:15 PM, "internet-drafts@ietf.org" =
<internet-drafts@ietf.org>
> wrote:
>=20
> >
> >A new version of I-D, draft-pd-dispatch-msrp-websocket-00.txt
> >has been successfully submitted by Peter Dunkley and posted to the
> >IETF repository.
> >
> >Filename:       draft-pd-dispatch-msrp-websocket
> >Revision:       00
> >Title:          The WebSocket Protocol as a Transport for the Message =
Session
> >Relay Protocol (MSRP)
> >Creation date:  2012-12-17
> >WG ID:          Individual Submission
> >Number of pages: 19
> >URL:
> =
>http://www.ietf.org/internet-drafts/draft-pd-dispatch-msrp-websocket-00.t=
x
> >t
> >Status:
> >http://datatracker.ietf.org/doc/draft-pd-dispatch-msrp-websocket
> >Htmlized:
> >http://tools.ietf.org/html/draft-pd-dispatch-msrp-websocket-00
> >
> >
> >Abstract:
> >   The WebSocket protocol enables two-way real-time communication
> >   between clients and servers.  This document specifies a new =
WebSocket
> >   sub-protocol as a reliable transport mechanism between MSRP =
(Message
> >   Session Relay Protocol) clients and relays to enable usage of MSRP =
in
> >   new scenarios.  This document normatively updates RFC 4975 and RFC
> >   4976.
> >
> >
> >
> >
> >
> >The IETF Secretariat
> >
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch


From ben@nostrum.com  Thu Feb 21 14:28:13 2013
Return-Path: <ben@nostrum.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7DA21F8883 for <dispatch@ietfa.amsl.com>; Thu, 21 Feb 2013 14:28:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.547
X-Spam-Level: 
X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNAPwjOIwzuJ for <dispatch@ietfa.amsl.com>; Thu, 21 Feb 2013 14:28:05 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9C77121F87B6 for <dispatch@ietf.org>; Thu, 21 Feb 2013 14:27:51 -0800 (PST)
Received: from [10.0.1.14] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r1LMRcnA041350 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 Feb 2013 16:27:43 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <1357579689.29808.16.camel@pd-notebook-linux.croc.internal>
Date: Thu, 21 Feb 2013 16:27:38 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <1D6ABD12-DDDA-4B4C-8B00-1385764D5226@nostrum.com>
References: <20121217161521.30393.14625.idtracker@ietfa.amsl.com> <CCF55522.7A92%vpascual@acmepacket.com> <CAGTXFp9dFa03RB8Ri=b=Lo4VDB_-RpJ9tEjAFiqKZ=A7q3CO4A@mail.gmail.com> <4A541458-A884-4BB9-8C0C-EDD8C7CCB2D0@ag-projects.com> <1357579689.29808.16.camel@pd-notebook-linux.croc.internal>
To: Peter Dunkley <peter.dunkley@crocodile-rcs.com>
X-Mailer: Apple Mail (2.1499)
Received-SPF: pass (shaman.nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism)
Cc: DISPATCH <dispatch@ietf.org>
Subject: Re: [dispatch] New Version Notification for draft-pd-dispatch-msrp-websocket-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Feb 2013 22:28:13 -0000

On Jan 7, 2013, at 11:28 AM, Peter Dunkley =
<peter.dunkley@crocodile-rcs.com> wrote:

>> - Section 6: maybe it should be mentioned that in the absence of a WS =
pint mechanism the defined MSRP way (that is, an empty SEND) should be =
used?
>>=20
>>=20
> I will add this to the next issue of the draft.
>=20
>>=20

Am I correct in assuming the _initial_  (possible empty) MSRP send still =
applies? That has downstream implications if you have non-WebSocket =
clients and/or relays on the other end.=

From peter.dunkley@crocodile-rcs.com  Thu Feb 21 14:40:41 2013
Return-Path: <peter.dunkley@crocodile-rcs.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE9721E803F for <dispatch@ietfa.amsl.com>; Thu, 21 Feb 2013 14:40:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.869
X-Spam-Level: 
X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwXi1AFm5FEU for <dispatch@ietfa.amsl.com>; Thu, 21 Feb 2013 14:40:36 -0800 (PST)
Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 3208D21E803D for <dispatch@ietf.org>; Thu, 21 Feb 2013 14:40:35 -0800 (PST)
Received: (qmail 3394 invoked by uid 0); 21 Feb 2013 22:40:13 -0000
Received: from unknown (HELO just121.justhost.com) (173.254.28.121) by oproxy7.bluehost.com with SMTP; 21 Feb 2013 22:40:13 -0000
Received: from [86.15.139.171] (port=57685 helo=[192.168.111.15]) by just121.justhost.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from <peter.dunkley@crocodile-rcs.com>) id 1U8eoH-00072D-Fu; Thu, 21 Feb 2013 15:40:13 -0700
References: <20121217161521.30393.14625.idtracker@ietfa.amsl.com> <CCF55522.7A92%vpascual@acmepacket.com> <CAGTXFp9dFa03RB8Ri=b=Lo4VDB_-RpJ9tEjAFiqKZ=A7q3CO4A@mail.gmail.com> <4A541458-A884-4BB9-8C0C-EDD8C7CCB2D0@ag-projects.com> <1357579689.29808.16.camel@pd-notebook-linux.croc.internal> <1D6ABD12-DDDA-4B4C-8B00-1385764D5226@nostrum.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <1D6ABD12-DDDA-4B4C-8B00-1385764D5226@nostrum.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <A85F4909-9B07-4D7C-9B04-4E2C154766BE@crocodile-rcs.com>
X-Mailer: iPhone Mail (10B146)
From: Peter Dunkley <peter.dunkley@crocodile-rcs.com>
Date: Thu, 21 Feb 2013 22:40:10 +0000
To: Ben Campbell <ben@nostrum.com>
X-Identified-User: {596:just121.justhost.com:crocodi1:crocodile-rcs.com} {sentby:smtp auth 86.15.139.171 authed with peter.dunkley+crocodile-rcs.com}
Cc: DISPATCH <dispatch@ietf.org>
Subject: Re: [dispatch] New Version Notification for draft-pd-dispatch-msrp-websocket-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Feb 2013 22:40:41 -0000

Yes, the initial SEND still applies.  What are the downstream implications t=
hat you see?

Regards,

Peter

On 21 Feb 2013, at 22:27, Ben Campbell <ben@nostrum.com> wrote:

>=20
> On Jan 7, 2013, at 11:28 AM, Peter Dunkley <peter.dunkley@crocodile-rcs.co=
m> wrote:
>=20
>>> - Section 6: maybe it should be mentioned that in the absence of a WS pi=
nt mechanism the defined MSRP way (that is, an empty SEND) should be used?
>>>=20
>>>=20
>> I will add this to the next issue of the draft.
>>=20
>>>=20
>=20
> Am I correct in assuming the _initial_  (possible empty) MSRP send still a=
pplies? That has downstream implications if you have non-WebSocket clients a=
nd/or relays on the other end.

From ben@nostrum.com  Thu Feb 21 15:10:44 2013
Return-Path: <ben@nostrum.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB4D21E803D for <dispatch@ietfa.amsl.com>; Thu, 21 Feb 2013 15:10:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.552
X-Spam-Level: 
X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJpUoB85Yna3 for <dispatch@ietfa.amsl.com>; Thu, 21 Feb 2013 15:10:43 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id ADA7021E8039 for <dispatch@ietf.org>; Thu, 21 Feb 2013 15:10:43 -0800 (PST)
Received: from [10.0.1.14] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r1LNAXoG046047 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 Feb 2013 17:10:39 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <A85F4909-9B07-4D7C-9B04-4E2C154766BE@crocodile-rcs.com>
Date: Thu, 21 Feb 2013 17:10:33 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <D9B189A3-8C94-4251-BAD6-704958BADF13@nostrum.com>
References: <20121217161521.30393.14625.idtracker@ietfa.amsl.com> <CCF55522.7A92%vpascual@acmepacket.com> <CAGTXFp9dFa03RB8Ri=b=Lo4VDB_-RpJ9tEjAFiqKZ=A7q3CO4A@mail.gmail.com> <4A541458-A884-4BB9-8C0C-EDD8C7CCB2D0@ag-projects.com> <1357579689.29808.16.camel@pd-notebook-linux.croc.internal> <1D6ABD12-DDDA-4B4C-8B00-1385764D5226@nostrum.com> <A85F4909-9B07-4D7C-9B04-4E2C154766BE@crocodile-rcs.com>
To: Peter Dunkley <peter.dunkley@crocodile-rcs.com>
X-Mailer: Apple Mail (2.1499)
Received-SPF: pass (shaman.nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism)
Cc: DISPATCH <dispatch@ietf.org>
Subject: Re: [dispatch] New Version Notification for draft-pd-dispatch-msrp-websocket-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Feb 2013 23:10:44 -0000

If the downstream peer is the passive party in the TCP connection, it =
uses the initial send to make sure the peer has knowledge of it's MSRP =
URI from the SDP offer/answer. A downstream relay uses the initial send =
to trigger connection setup.

Thanks!

Ben.

On Feb 21, 2013, at 4:40 PM, Peter Dunkley =
<peter.dunkley@crocodile-rcs.com> wrote:

> Yes, the initial SEND still applies.  What are the downstream =
implications that you see?
>=20
> Regards,
>=20
> Peter
>=20
> On 21 Feb 2013, at 22:27, Ben Campbell <ben@nostrum.com> wrote:
>=20
>>=20
>> On Jan 7, 2013, at 11:28 AM, Peter Dunkley =
<peter.dunkley@crocodile-rcs.com> wrote:
>>=20
>>>> - Section 6: maybe it should be mentioned that in the absence of a =
WS pint mechanism the defined MSRP way (that is, an empty SEND) should =
be used?
>>>>=20
>>>>=20
>>> I will add this to the next issue of the draft.
>>>=20
>>>>=20
>>=20
>> Am I correct in assuming the _initial_  (possible empty) MSRP send =
still applies? That has downstream implications if you have =
non-WebSocket clients and/or relays on the other end.


From stephane.cazeaux@orange.com  Fri Feb 22 08:41:04 2013
Return-Path: <stephane.cazeaux@orange.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B9221F8E17 for <dispatch@ietfa.amsl.com>; Fri, 22 Feb 2013 08:41:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Z7ZwMORffit for <dispatch@ietfa.amsl.com>; Fri, 22 Feb 2013 08:41:03 -0800 (PST)
Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5C50421F8DA0 for <dispatch@ietf.org>; Fri, 22 Feb 2013 08:40:57 -0800 (PST)
Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CEEB5DE400E; Fri, 22 Feb 2013 17:42:37 +0100 (CET)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id C5366DE400B; Fri, 22 Feb 2013 17:42:37 +0100 (CET)
Received: from FTRDCH02.rd.francetelecom.fr ([10.194.32.13]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 22 Feb 2013 17:40:55 +0100
Received: from FTRDMB03.rd.francetelecom.fr ([fe80::4c06:6ece:ed2d:797e]) by FTRDCH02.rd.francetelecom.fr ([::1]) with mapi id 14.02.0283.003; Fri, 22 Feb 2013 17:40:55 +0100
From: <stephane.cazeaux@orange.com>
To: <pkyzivat@alum.mit.edu>, <dispatch@ietf.org>
Thread-Topic: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt
Thread-Index: AQF9z8UEz2ObgxCIVknVqREfJG8ROQHWQip3ArH0DGMCE05AoJjxUtBA
Date: Fri, 22 Feb 2013 16:40:38 +0000
Message-ID: <FEE7A6136F518B4B87037A58924AB6B0067596FB@FTRDMB03.rd.francetelecom.fr>
References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <CD442C6C.B156%vpascual@acmepacket.com> <CAGTXFp-Ee_XsD0NdmrFxjqyUN9cP-+Q2XNAKV35MMTtZJxUEcA@mail.gmail.com> <5126925E.2010102@alum.mit.edu>
In-Reply-To: <5126925E.2010102@alum.mit.edu>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.193.193.193]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 22 Feb 2013 16:40:55.0607 (UTC) FILETIME=[62956470:01CE111B]
Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Feb 2013 16:41:04 -0000

Hi Paul,

Having BFCP over data channel would limit the applicability of BFCP to webr=
tc (other formulation: it would require the webrtc framework to get BFCP in=
 the browser), while we might want to have BFCP protocol in web client outs=
ide of webrtc.

St=E9phane.

-----Message d'origine-----
De=A0: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20
Envoy=E9=A0: jeudi 21 f=E9vrier 2013 22:32
=C0=A0: dispatch@ietf.org
Objet=A0: Re: [dispatch] FW: New Version Notification for draft-pascual-dis=
patch-bfcp-websocket-00.txt

Victor,

A question for you:

Another possibility is to map bfcp over a data channel as being specified f=
or rtcweb.

If that were done, would it be a suitable alternative to bfcp over websocke=
t?

We are also going to need bfcp support in conjunction with CLUE.
And CLUE is going to have its own data channel. We are aiming to use an rtc=
web-compatible data channel so that we can have rtcweb browser based clue c=
lients.
     =20
If bfcp also worked over a data channel, then these multiple uses of data c=
hannels could all coexist on a single SCTP association. And they could work=
 the same regardless of whether or not there are web clients.

	Thanks,
	Paul

On 2/21/13 12:38 PM, Victor Pascual Avila wrote:
> Hi all,
>
> We have submitted a new Internet draft to describe the WebSocket=20
> Protocol as a Transport for the Binary Floor Control Protocol (BFCP).
> We are looking forward to your review comments.
>
> http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00
>
> Best regards,
> -Victor
>
>
> On 2/15/13 6:17 PM, "internet-drafts@ietf.org"=20
> <internet-drafts@ietf.org>
> wrote:
>
>>
>> A new version of I-D, draft-pascual-dispatch-bfcp-websocket-00.txt
>> has been successfully submitted by Victor Pascual and posted to the=20
>> IETF repository.
>>
>> Filename:       draft-pascual-dispatch-bfcp-websocket
>> Revision:       00
>> Title:          The WebSocket Protocol as a Transport for the Binary Flo=
or
>> Control Protocol (BFCP)
>> Creation date:  2013-02-15
>> Group:          Individual Submission
>> Number of pages: 9
>> URL:
>> http://www.ietf.org/internet-drafts/draft-pascual-dispatch-bfcp-webso
>> cket-
>> 00.txt
>> Status:
>> http://datatracker.ietf.org/doc/draft-pascual-dispatch-bfcp-websocket
>> Htmlized:
>> http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00
>>
>>
>> Abstract:
>>    The WebSocket protocol enables two-way realtime communication between
>>    clients and servers.  This document specifies a new WebSocket sub-
>>    protocol as a reliable transport mechanism between Binary Floor
>>    Control Protocol (BFCP) entities to enable usage of BFCP in new
>>    scenarios.  This document normatively updates
>>    [I-D.draft-ietf-bfcpbis-rfc4582bis] and
>>    [I-D.draft-ietf-bfcpbis-rfc4583bis]
>>
>>
>>
>>
>>
>> The IETF Secretariat
>>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>



From prvs=3766500123=aallen@rim.com  Sat Feb 23 15:32:32 2013
Return-Path: <prvs=3766500123=aallen@rim.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6367E21F8C16 for <dispatch@ietfa.amsl.com>; Sat, 23 Feb 2013 15:32:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.777
X-Spam-Level: 
X-Spam-Status: No, score=-4.777 tagged_above=-999 required=5 tests=[AWL=-0.774, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_93=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShKJhVRc95or for <dispatch@ietfa.amsl.com>; Sat, 23 Feb 2013 15:32:31 -0800 (PST)
Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id C398721F8BA6 for <dispatch@ietf.org>; Sat, 23 Feb 2013 15:32:30 -0800 (PST)
X-AuditID: 0a41282f-b7f606d000004b92-e7-51295182fd91
Received: from XCT101ADS.rim.net (xct101ads.rim.net [10.67.111.42]) by mhs060cnc.rim.net (SBG) with SMTP id E6.A1.19346.28159215; Sat, 23 Feb 2013 17:32:18 -0600 (CST)
Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT101ADS.rim.net ([fe80::2c7e:1215:d554:35b5%20]) with mapi id 14.02.0328.009; Sat, 23 Feb 2013 17:32:18 -0600
From: Andrew Allen <aallen@rim.com>
To: "dispatch@ietf.org" <dispatch@ietf.org>
Thread-Topic: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid submitted
Thread-Index: Ac4SGjQ2NY4BBw8lQLGFyvdxq0DTwg==
Date: Sat, 23 Feb 2013 23:32:17 +0000
Message-ID: <BBF5DDFE515C3946BC18D733B20DAD2338D1B432@XMB104ADS.rim.net>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.67.110.251]
Content-Type: text/plain; charset="us-ascii"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDKsWRmVeSWpSXmKPExsXC5ZyvpdsUqBlo8Oa9pcXSSQtYLTYtX8nk wOTx6+tVNo8lS34yBTBFNTDaJCWWlAVnpufp29kk5uXllySWpCqkpBYn2yr5pKYn5igEFGWW JSZXKrhkFifnJGbmphYpKWSm2CqZKCkU5CQmp+am5pXYKiUWFKTmpSjZcSlgABugssw8hdS8 5PyUzLx0WyXPYH9dCwtTS11DJTvdhE6ejO7+lSwFu/IrOk7PYWpgfBfSxcjJISFgIjF163tG CFtM4sK99WxdjFwcQgIrGSUO3rsP5WxmlOj4so0JpIpNQFli+e8ZYB0iAtoSR1d1MYMUMQu0 MkrcWfMYLCEsUCcxqXk5E0hCRKCZUeJYywM2iA49ibW9M9lBbBYBVYnLZz+zgNi8Ah4Sr79v YgWxGQVkJXafvQ62jVlAXOLWk/lMEPcJSCzZc54ZwhaVePn4HyuErSgxY898Voh6HYkFuz+x QdjaEssWvmaGmC8ocXLmE5YJjCKzkIydhaRlFpKWWUhaFjCyrGIUzM0oNjAzSM5L1ivKzNXL Sy3ZxAiKfkcN/R2Mb99bHGIU4GBU4uF19NUMFGJNLCuuzD3EKMHBrCTCa3VNI1CINyWxsiq1 KD++qDQntfgQoyvQ9xOZpbiT84GJKa8k3tjAADdHSZxXJFA0UEggHZhqslNTC1KLYOYwcXCC 7OGSEikGJozUosTSkox4UFqLLwYmNqkGxksq+x6evTSd6/1+Obb2012y6lNiysI/qfdKJyw2 Yzkz2WH/A/d369xX7D/3JXGSn5frjsk7D/UvdL7/gCXv5MfuZb0xdlG5z7hNxDs/ZXjqlPzZ vPfoHMfyyes7O7ZdfjPNcv93rxdBc48+rynmUDbY8Hv1o7uduw4fe5cZNWP/5kqrbYVuPRJK LMUZiYZazEXFiQDnVzKoPwMAAA==
Cc: Michael Montemurro <mmontemurro@rim.com>
Subject: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid submitted
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Feb 2013 23:32:32 -0000

New versions of draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei=
-urn-as-instanceid submitted have recently been submitted

They can be found at:

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

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

These replace the 12 and 07 versions of these drafts submitted earlier in Fe=
bruary and contain only minor corrections over the 12 and 07 versions with d=
raft-montemurro-gsma-imei-urn-13 only correcting some additional incorrect i=
nformation about the check digit and draft-allen-dispatch-imei-urn-as-instan=
ceid-08 only correcting the references to draft-montemurro-gsma-imei-urn-13.=
 The main significant changes to these draft were included previously in the=
 12 and 07 versions to address Dale Worley's comments below (see inline comm=
ents prepended with [AA]).

Thanks to Dale for working through these with me during downtime after the r=
ecent RTCweb/MMUSIC interim.

I believe these changes now address all Dale's comments. Cullen made some ad=
ditional comments back in January which I responded as did Dale too but no r=
esponse back to us has been received.

I would like to see us move forward towards publication of these drafts whic=
h are required by 3GPP.

Thanks
Andrew


-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf=
 Of Dale R. Worley
Sent: Tuesday, November 27, 2012 4:53 PM
To: dispatch@ietf.org
Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and,=
 draft-allen-dispatch-imei-urn-as-instanceid submitted

In regard to the privacy issue, I agree with the authors that privacy has be=
en addressed more vigorously than it is in regular SIP networks (where it is=
 often handled very sloppily), and that (as regarding standards), and that i=
s sufficient.

Below I have noted some specific comments, only two of which have technical=
 content:  (1) What is the permitted character set of the "gsma-*" symbols i=
n the generic syntax?  (2) What is the intended lexical equivalence algorith=
m?

Resolving these comments should be straightforward, after which I think thes=
e documents should progress to RFCs.

Good work!

Dale


*** Comments on draft-montemurro-gsma-imei-urn-11

Technical issues:

   3.1.  GSMA

      The <gsma-specifier>, <gsma-specifier-defined-string>, <gsma-
      specifier-defined-substring>, <gsma-specifier-defined-param-name>
      and <gsma-specifier-defined-param-val> can comprise any ASCII
      characters compliant with URN syntax and must not contain the ":"
      character or ";" character or "=3D" character(see STD 66, RFC 2141
      [5]).

This contradicts the ABNF in the same section, as there are quite a number o=
f "unreserved" characters for URNs (see RFC 2141, section 2.2, symbol <other=
>) that are not included in this document's <unreserved>.
What is the intended generic syntax of these symbols?


Within this text, "can comprise any ASCII characters ... and must not ..." w=
ould be better phrased "can comprise any ASCII characters except/but it must=
 not ...".

[AA] Done. This passage has been rewritten as follows:
	      The <gsma-specifier>, <gsma-specifier-defined-string>, <gsma-
	      specifier-defined-substring>, <gsma-specifier-defined-param-name>
	      and <gsma-specifier-defined-param-val> can comprise any ASCII
	      characters compliant with the above ABNF.  


   Rules for Lexical Equivalence:
      Consider each field of the IMEI gsma-defined substring to be a
      sequence of decimial digits.  Then, to compare a pair of IMEIs,
      arithmetically compare the corresponding fields of the gsma-
      defined substring from each IMEI in order of significance and
      according to their data type.  Two IMEIs are equal if and only if
      all the corresponding fields are equal.

      The lexical equivalence of the GSMA namespace-specific strings
      (NSSs) is defined as an exact, but not case-sensitive, string
      match.

      Any identifier in GSMA namespaces can be compared using the normal
      mechanisms for percent-encoded UTF-8 strings.

I think this passage has not been updated to match the symbols in the ABNF.=
  For instance, there isn't a "gsma-defined substring" in the grammar.  But=
 it's not clear to me what the comparison process is.
E.g., how are parameters compared?  What is a "field"?


(What is the informal description of the equality test?  I assume we've alre=
ady agreed on that and it's just a matter of specifying it formally.  draft-=
allen-dispatch-imei-urn-as-instanceid-06 section 5 gives "any optional or va=
riable components of the URN (e.g., the "vers" parameter) MUST be presented=
 with the same values and in the same order)".  Is that correct?)

[AA] Done. The rules for Lexical equivalence has been re-written as follows:
	   Rules for Lexical Equivalence:
	      Two IMEI URNs are equivalent if the single gsma-defined-substrings
	      in the two URNs are the same, and the sequences of gsma-specifier-
	      params are the same and in the same order, with the exception that
	      the gsma-specifier-param "vers=3D0" is to be ignored for purposes of
	      comparison.  All of these comparisons are to be case-insensitive.

	      Any identifier in GSMA namespaces can be compared using the normal
	      mechanisms for percent-encoded UTF-8 strings.


Editorial:

   1.  Introduction

   GSMA is an identifier for a namespace for identities used by Mobile
   ^^^^

I think this would be more clearly written as '"gsma"', that is, lower-case=
 (as the actual namespace ID is), and in quotes (as the subject of the sente=
nce is the name of the namespace, not the GSMA.

[AA] Done

Perhaps a less syntactically awkward way to write it would be "The namespace=
 "gsma" is a namespace for ...".

[AA] Done

"sub namespace" should probably be hyphenated, as "sub" is not generally use=
d as a separate word.

[AA] Done

      3.1.  GSMA

      A IMEI is an identifier under the GSMA namespace that uniquely
      ^

This should be "An".

[AA] Done

      The formal definition of the IMEI string representation for the
      gsma-specifier-defined-substring for the "imei" gsma-specifier is
      provided by the following ABNF [8]:

The BNF and text do not explicitly state that URNs in the "imei"
sub-namespace use exactly one gsma-specifier-defined-substring, whereas that=
 requirement is intended but the generic syntax allows zero or more gsma-spe=
cifier-defined-substrings.  This wording would correct that:

      A URN with the "imei" gsma-specifier contains exactly one
      gsma-specifier-defined-substring, and its formal definition is
      provided by the following ABNF [8]:

[AA] Done

      The GSMA will take responsibility for the gsma-specifier "imei"
      and manage the sub level.
                     ^^^^^^^^^

This seems awkward, as "sub-level" is not commonly a word.  Perhaps this exp=
resses the intended meaning:

      The GSMA will take responsibility for the gsma-specifier "imei"
      and will manage the URNs in its sub-namespace.

[AA] Done

   4.1.3.  Spare

   The Spare is a single decimal digit that is used as a security check
   digit to combat potential spoofing.  The Spare is always set to zero
   when transmitted by the Mobile Equipment. 

There are repeated uses of the phrase "the spare is always set to zero when=
 transmitted by the mobile equipment".  I suspect this also means that "spar=
e" is always "0" in IMEI URNs, but the text doesn't say that directly.  Sinc=
e other forms of "transmission by the Mobile Equipment"
are out of scope for this document, perhaps the second sentence could be cha=
nged to:

   The Spare is always set to zero in an IMEI URN.

Is there a security concern if the "actual" check digit is accidentally used=
 as the "spare" field in an IMEI URN?  If so, a sentence to that effect shou=
ld be added to "Security considerations".

   8.  Security considerations

   It is therefore RECOMMENDED that the IMEISV is not delivered to
   devices that are not trusted.

[AA] The text regarding the spare digit was inaccurate and has been correcte=
d to reflect its actual purpose. It is not in fact a security feature but a=
 is used as a check digit to ensure valid entry and verbal communication of=
 the actual IMEI value. The text has been updated to correctly reflect this.

In the document, there is no explicit statement that IMEISV is logically int=
erchangeable with "IMEI URN with svn parameter", which might cause an implem=
enter to overlook the implications of the above sentence.  So I would sugges=
t augmenting it:

   It is therefore RECOMMENDED that the IMEISV (that is, the IMEI URN
   with svn parameter) is not delivered to devices that are not
   trusted.

[AA] Done

Similarly, for thoroughness:

   In particular, the IMEI URN MUST NOT be included in messages
   intended to convey any level of anonymity.

[AA] After discussion with Dale he agrees this was an incorrect comment (pro=
bably IMEI vs IMEISV confusion)

*** Comments on draft-allen-dispatch-imei-urn-as-instanceid-06

Editorial:

   Abstract

   This specification defines how the Uniform Resource Name namespace
   reserved for GSMA (Global Sstandard for Mobiles Association) ...

The expansion of the acronym GSMA provided here is different from the one in=
 draft-montemurro-gsma-imei-urn-11, and does not agree with the expansion of=
 "GSM" provided by Wikipedia ("Global System for Mobile Communications, orig=
inally Groupe SpC)cial Mobile").

[AA] Done

   ... identities and its sub namespace for the IMEI (International Mobile

"sub namespace" should probably be hyphenated or made one word.

   station Equipment Identity) can be used as an instance-id as
   specified in RFC 5626 [1] and also as used by RFC 5627 [2].

[AA] Done sub-namespace hyphenated


   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Background  . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  3GPP Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . 5
   5.  User Agent Client Procedures  . . . . . . . . . . . . . . . . . 5
   6.  User Agent Server Procedures  . . . . . . . . . . . . . . . . . 6
   7.  3GPP Registrar Procedures . . . . . . . . . . . . . . . . . . . 7
   8.  Security considerations . . . . . . . . . . . . . . . . . . . . 7
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     10.1.  Normative references . . . . . . . . . . . . . . . . . . . 8
     10.2.  Informative references . . . . . . . . . . . . . . . . . . 8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 9

The capitalization of the section titles is inconsistent.  (But you can prob=
ably leave fixing that to the RFC Editor.)

[AA] Done

   1.  Introduction

   meets this requirement by specifying how the GSMA IEMEI URN is used
                                                     ^^^^^

Should be "IMEI".

[AA] Done

   3.  Background

   Amongst other things in some
   regulatory jurisdictions the IMEI is used to identify a stolen mobile
                                                        ^ Adding "that" here=
 makes this easier to read.  Otherwise, one tends to read "identify a stolen=
 mobile".
   is being used and help to identify the subscription that is using it
                ^^^^

[AA] Done

There are three clauses here, so there should be only one "and", and the sec=
ond clause should start "to help".

[AA] Done

   and to prevent its use.  Whilst GSM was originally a circuit switched
   system enhancements such as GPRS (General Packet Radio Service) and
         ^
Adding a comma makes this easier to read.  Otherwise, one tends to read "a c=
ircuit switched system enhancements".

[AA] Done

   UMTS have added IP data capabilities which along with the definition
   of the IP Multimedia Subsystem (IMS) has made SIP based calls and IP
   multimedia sessions from mobile devices possible.

   Center) server enhanced for ICS which controls mobile voice call
   setup over the circuit switched radio access while establishing the
   corresponding voice session in the core network using SIP/IMS.  To
   enable this the MSC server enhanced for ICS (IMS centralized
   services) performs SIP registration on behalf of the mobile device

Move the expansion of "ICS" to its first use.

[AA] Done

The phrase "MSC server enhanced for ICS" is used several times.  I assume th=
at this is a specific technical term.  Is there a shorter form?

[AA] Yes this is a term used in 3GPP specifications and there is no abbrevia=
tion

   Additionally in order to meet the regulatory requirements to use the
   IMEI to identify a stolen mobile is being used and help to identify
   the subscription that is using it and to prevent its use the same
   IMEI that is obtained from the circuit switched signaling needs to be
   obtainable from SIP signaling.

Much of this duplicates the first sentences of the section.  Perhaps it coul=
d be shortened to:

   Additionally, in order to meet the above regulatory requirements,
   the IMEI that is obtained from the circuit switched signaling needs
   to be obtainable from SIP signaling.

[AA] Done

   4.  3GPP Use Cases

   call as from the same mobile device that was in the emergency session
        ^^

This probably should be "is".

[AA] Done

   5.  User Agent Client Procedures

   When registering with a non 3GPP IMS network ...

There are a number of instances where "non" is presented as a stand-alone wo=
rd.

[AA] Done hyphenated form is used

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

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.

From pkyzivat@alum.mit.edu  Sat Feb 23 17:32:10 2013
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED3521F8F73 for <dispatch@ietfa.amsl.com>; Sat, 23 Feb 2013 17:32:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Level: 
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kE35To1gCHge for <dispatch@ietfa.amsl.com>; Sat, 23 Feb 2013 17:32:10 -0800 (PST)
Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:211]) by ietfa.amsl.com (Postfix) with ESMTP id 47EDB21F8F68 for <dispatch@ietf.org>; Sat, 23 Feb 2013 17:32:10 -0800 (PST)
Received: from omta11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by qmta11.emeryville.ca.mail.comcast.net with comcast id 41Th1l0030mlR8UAB1YA9a; Sun, 24 Feb 2013 01:32:10 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([125.122.241.79]) by omta11.emeryville.ca.mail.comcast.net with comcast id 41Vx1l00S1jVNfx8X1W08i; Sun, 24 Feb 2013 01:30:07 +0000
Message-ID: <51296D15.1030105@alum.mit.edu>
Date: Sat, 23 Feb 2013 20:29:57 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: stephane.cazeaux@orange.com
References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <CD442C6C.B156%vpascual@acmepacket.com> <CAGTXFp-Ee_XsD0NdmrFxjqyUN9cP-+Q2XNAKV35MMTtZJxUEcA@mail.gmail.com> <5126925E.2010102@alum.mit.edu> <FEE7A6136F518B4B87037A58924AB6B0067596FB@FTRDMB03.rd.francetelecom.fr>
In-Reply-To: <FEE7A6136F518B4B87037A58924AB6B0067596FB@FTRDMB03.rd.francetelecom.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361669530; bh=GFROh/+iGPWWKNQ80Rnv9UKm7e609vD6JLWRNIbPC80=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Is0LMnq6cHPweakX+Xx9h/qVOl7pd5OuQoE1M2eadEePOMUvP7Wf1psQuHV0iYH2q HvZ8goCCDVSnIwfdb5TJLe9MwFb80Oxo/ml6hj7A0hqm+bykRGXVPIj7PL5mthRJ9z wnK14vb8ipBEPat65K8+S1WCE2T+TKFfq7aCtXvMhTh0+XtKO+Sr7PW2RpW6K4Zq1z Oqf1LQ0mmFTiKSW5tCmG+OpK10jus5oZFRTc1scfcHszR15JcE4VVOsBZTPB/sb1Aq +26145BkLp15u9jetFcue4BjSkOcqPIghP68/kJmPkSGHErkHLFaAep43gjsPIe1Tx I5vUZOCnERJvg==
Cc: dispatch@ietf.org
Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 24 Feb 2013 01:32:10 -0000

On 2/22/13 11:40 AM, stephane.cazeaux@orange.com wrote:
> Hi Paul,
>
> Having BFCP over data channel would limit the applicability of BFCP to webrtc (other formulation: it would require the webrtc framework to get BFCP in the browser), while we might want to have BFCP protocol in web client outside of webrtc.

I guess I didn't explain myself well enough.

What I am suggesting is bfcp over the DTLS/SCTP stack that is being used 
for RTCWEB data channels, and that the mechanisms used to negotiate the 
stream numbers for each direction be compatible with RTCWEB. In this way 
a true RTCWEB browser client can be implemented, but a non-RTCWEB (e.g. 
C-based) implementation is also possible.

This is the same direction we are investigating for the clue data channel.

The term "data channel" here is perhaps overloaded, because it could 
mean a real RTCWEB data channel, or something similar for other 
environments. Ideally we would just use SCTP terms, but it has no term 
for a bidirectional "channel", only unidirectional streams. But this 
should end up being formalized in the SDP.

	Thanks,	
	Paul

> Stéphane.
>
> -----Message d'origine-----
> De : Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
> Envoyé : jeudi 21 février 2013 22:32
> À : dispatch@ietf.org
> Objet : Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt
>
> Victor,
>
> A question for you:
>
> Another possibility is to map bfcp over a data channel as being specified for rtcweb.
>
> If that were done, would it be a suitable alternative to bfcp over websocket?
>
> We are also going to need bfcp support in conjunction with CLUE.
> And CLUE is going to have its own data channel. We are aiming to use an rtcweb-compatible data channel so that we can have rtcweb browser based clue clients.
>
> If bfcp also worked over a data channel, then these multiple uses of data channels could all coexist on a single SCTP association. And they could work the same regardless of whether or not there are web clients.
>
> 	Thanks,
> 	Paul
>
> On 2/21/13 12:38 PM, Victor Pascual Avila wrote:
>> Hi all,
>>
>> We have submitted a new Internet draft to describe the WebSocket
>> Protocol as a Transport for the Binary Floor Control Protocol (BFCP).
>> We are looking forward to your review comments.
>>
>> http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00
>>
>> Best regards,
>> -Victor
>>
>>
>> On 2/15/13 6:17 PM, "internet-drafts@ietf.org"
>> <internet-drafts@ietf.org>
>> wrote:
>>
>>>
>>> A new version of I-D, draft-pascual-dispatch-bfcp-websocket-00.txt
>>> has been successfully submitted by Victor Pascual and posted to the
>>> IETF repository.
>>>
>>> Filename:       draft-pascual-dispatch-bfcp-websocket
>>> Revision:       00
>>> Title:          The WebSocket Protocol as a Transport for the Binary Floor
>>> Control Protocol (BFCP)
>>> Creation date:  2013-02-15
>>> Group:          Individual Submission
>>> Number of pages: 9
>>> URL:
>>> http://www.ietf.org/internet-drafts/draft-pascual-dispatch-bfcp-webso
>>> cket-
>>> 00.txt
>>> Status:
>>> http://datatracker.ietf.org/doc/draft-pascual-dispatch-bfcp-websocket
>>> Htmlized:
>>> http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00
>>>
>>>
>>> Abstract:
>>>     The WebSocket protocol enables two-way realtime communication between
>>>     clients and servers.  This document specifies a new WebSocket sub-
>>>     protocol as a reliable transport mechanism between Binary Floor
>>>     Control Protocol (BFCP) entities to enable usage of BFCP in new
>>>     scenarios.  This document normatively updates
>>>     [I-D.draft-ietf-bfcpbis-rfc4582bis] and
>>>     [I-D.draft-ietf-bfcpbis-rfc4583bis]
>>>
>>>
>>>
>>>
>>>
>>> The IETF Secretariat
>>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
>
>
>


From stephane.cazeaux@orange.com  Sun Feb 24 01:28:41 2013
Return-Path: <stephane.cazeaux@orange.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B38621F900F for <dispatch@ietfa.amsl.com>; Sun, 24 Feb 2013 01:28:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.248
X-Spam-Level: 
X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mg0yuE8F9UP4 for <dispatch@ietfa.amsl.com>; Sun, 24 Feb 2013 01:28:40 -0800 (PST)
Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 5995A21F86BC for <dispatch@ietf.org>; Sun, 24 Feb 2013 01:28:39 -0800 (PST)
Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2811D4110A8; Sun, 24 Feb 2013 10:28:38 +0100 (CET)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 1CBC1410E44; Sun, 24 Feb 2013 10:28:38 +0100 (CET)
Received: from FTRDCH01.rd.francetelecom.fr ([10.194.32.11]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Sun, 24 Feb 2013 10:28:37 +0100
Received: from FTRDMB03.rd.francetelecom.fr ([fe80::4c06:6ece:ed2d:797e]) by FTRDCH01.rd.francetelecom.fr ([::1]) with mapi id 14.02.0283.003; Sun, 24 Feb 2013 10:28:36 +0100
From: <stephane.cazeaux@orange.com>
To: <pkyzivat@alum.mit.edu>
Thread-Topic: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt
Thread-Index: AQF9z8UEz2ObgxCIVknVqREfJG8ROQHWQip3ArH0DGMCE05AoJjxUtBAgAJ9p4CAAJaA/w==
Date: Sun, 24 Feb 2013 09:28:20 +0000
Message-ID: <FEE7A6136F518B4B87037A58924AB6B00675A13A@FTRDMB03.rd.francetelecom.fr>
References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <CD442C6C.B156%vpascual@acmepacket.com> <CAGTXFp-Ee_XsD0NdmrFxjqyUN9cP-+Q2XNAKV35MMTtZJxUEcA@mail.gmail.com> <5126925E.2010102@alum.mit.edu> <FEE7A6136F518B4B87037A58924AB6B0067596FB@FTRDMB03.rd.francetelecom.fr>, <51296D15.1030105@alum.mit.edu>
In-Reply-To: <51296D15.1030105@alum.mit.edu>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_FEE7A6136F518B4B87037A58924AB6B00675A13AFTRDMB03rdfranc_"
MIME-Version: 1.0
X-OriginalArrivalTime: 24 Feb 2013 09:28:37.0638 (UTC) FILETIME=[532CEA60:01CE1271]
Cc: dispatch@ietf.org
Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 24 Feb 2013 09:28:41 -0000

--_000_FEE7A6136F518B4B87037A58924AB6B00675A13AFTRDMB03rdfranc_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

That was my understanding. My point is that on the browser, the data channe=
l is part of the webrtc stuff. While websocket is to me more suitable for s=
uch browser to server exchange.
Btw, what is the rationale of having bfcp over sctp/dtls on a CLUE endpoint=
 since, unless I am wrong, a CLUE endpoint will also have to support bfcp o=
ver tcp (or udp) to interwork with legacy ?

St=E9phane.
________________________________
De : Paul Kyzivat
Envoy=E9 : 24/02/2013 02:32
=C0 : CAZEAUX Stephane OLNC/OLPS
Cc : dispatch@ietf.org
Objet : Re: [dispatch] FW: New Version Notification for draft-pascual-dispa=
tch-bfcp-websocket-00.txt

On 2/22/13 11:40 AM, stephane.cazeaux@orange.com wrote:
> Hi Paul,
>
> Having BFCP over data channel would limit the applicability of BFCP to we=
brtc (other formulation: it would require the webrtc framework to get BFCP =
in the browser), while we might want to have BFCP protocol in web client ou=
tside of webrtc.

I guess I didn't explain myself well enough.

What I am suggesting is bfcp over the DTLS/SCTP stack that is being used
for RTCWEB data channels, and that the mechanisms used to negotiate the
stream numbers for each direction be compatible with RTCWEB. In this way
a true RTCWEB browser client can be implemented, but a non-RTCWEB (e.g.
C-based) implementation is also possible.

This is the same direction we are investigating for the clue data channel.

The term "data channel" here is perhaps overloaded, because it could
mean a real RTCWEB data channel, or something similar for other
environments. Ideally we would just use SCTP terms, but it has no term
for a bidirectional "channel", only unidirectional streams. But this
should end up being formalized in the SDP.

        Thanks,
        Paul

> St=E9phane.
>
> -----Message d'origine-----
> De : Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
> Envoy=E9 : jeudi 21 f=E9vrier 2013 22:32
> =C0 : dispatch@ietf.org
> Objet : Re: [dispatch] FW: New Version Notification for draft-pascual-dis=
patch-bfcp-websocket-00.txt
>
> Victor,
>
> A question for you:
>
> Another possibility is to map bfcp over a data channel as being specified=
 for rtcweb.
>
> If that were done, would it be a suitable alternative to bfcp over websoc=
ket?
>
> We are also going to need bfcp support in conjunction with CLUE.
> And CLUE is going to have its own data channel. We are aiming to use an r=
tcweb-compatible data channel so that we can have rtcweb browser based clue=
 clients.
>
> If bfcp also worked over a data channel, then these multiple uses of data=
 channels could all coexist on a single SCTP association. And they could wo=
rk the same regardless of whether or not there are web clients.
>
>        Thanks,
>        Paul
>
> On 2/21/13 12:38 PM, Victor Pascual Avila wrote:
>> Hi all,
>>
>> We have submitted a new Internet draft to describe the WebSocket
>> Protocol as a Transport for the Binary Floor Control Protocol (BFCP).
>> We are looking forward to your review comments.
>>
>> http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00
>>
>> Best regards,
>> -Victor
>>
>>
>> On 2/15/13 6:17 PM, "internet-drafts@ietf.org"
>> <internet-drafts@ietf.org>
>> wrote:
>>
>>>
>>> A new version of I-D, draft-pascual-dispatch-bfcp-websocket-00.txt
>>> has been successfully submitted by Victor Pascual and posted to the
>>> IETF repository.
>>>
>>> Filename:       draft-pascual-dispatch-bfcp-websocket
>>> Revision:       00
>>> Title:          The WebSocket Protocol as a Transport for the Binary Fl=
oor
>>> Control Protocol (BFCP)
>>> Creation date:  2013-02-15
>>> Group:          Individual Submission
>>> Number of pages: 9
>>> URL:
>>> http://www.ietf.org/internet-drafts/draft-pascual-dispatch-bfcp-webso
>>> cket-
>>> 00.txt
>>> Status:
>>> http://datatracker.ietf.org/doc/draft-pascual-dispatch-bfcp-websocket
>>> Htmlized:
>>> http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00
>>>
>>>
>>> Abstract:
>>>     The WebSocket protocol enables two-way realtime communication betwe=
en
>>>     clients and servers.  This document specifies a new WebSocket sub-
>>>     protocol as a reliable transport mechanism between Binary Floor
>>>     Control Protocol (BFCP) entities to enable usage of BFCP in new
>>>     scenarios.  This document normatively updates
>>>     [I-D.draft-ietf-bfcpbis-rfc4582bis] and
>>>     [I-D.draft-ietf-bfcpbis-rfc4583bis]
>>>
>>>
>>>
>>>
>>>
>>> The IETF Secretariat
>>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
>
>
>


--_000_FEE7A6136F518B4B87037A58924AB6B00675A13AFTRDMB03rdfranc_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<meta name=3D"Generator" content=3D"Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; pad=
ding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>
<div>
<div style=3D"font-family:Calibri,sans-serif; font-size:11pt">That was my u=
nderstanding. My point is that on the browser, the data channel is part of =
the webrtc stuff. While websocket is to me more suitable for such browser t=
o server exchange.
<br>
Btw, what is the rationale of having bfcp over sctp/dtls on a CLUE endpoint=
 since, unless I am wrong, a CLUE endpoint will also have to support bfcp o=
ver tcp (or udp) to interwork with legacy ?<br>
<br>
St=E9phane.<br>
</div>
</div>
<hr>
<span style=3D"font-family:Tahoma,sans-serif; font-size:10pt; font-weight:b=
old">De :
</span><span style=3D"font-family:Tahoma,sans-serif; font-size:10pt">Paul K=
yzivat</span><br>
<span style=3D"font-family:Tahoma,sans-serif; font-size:10pt; font-weight:b=
old">Envoy=E9 :
</span><span style=3D"font-family:Tahoma,sans-serif; font-size:10pt">24/02/=
2013 02:32</span><br>
<span style=3D"font-family:Tahoma,sans-serif; font-size:10pt; font-weight:b=
old">=C0&nbsp;:
</span><span style=3D"font-family:Tahoma,sans-serif; font-size:10pt">CAZEAU=
X Stephane OLNC/OLPS</span><br>
<span style=3D"font-family:Tahoma,sans-serif; font-size:10pt; font-weight:b=
old">Cc :
</span><span style=3D"font-family:Tahoma,sans-serif; font-size:10pt">dispat=
ch@ietf.org</span><br>
<span style=3D"font-family:Tahoma,sans-serif; font-size:10pt; font-weight:b=
old">Objet :
</span><span style=3D"font-family:Tahoma,sans-serif; font-size:10pt">Re: [d=
ispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-webso=
cket-00.txt</span><br>
<br>
</div>
<font size=3D"2"><span style=3D"font-size:10pt;">
<div class=3D"PlainText">On 2/22/13 11:40 AM, stephane.cazeaux@orange.com w=
rote:<br>
&gt; Hi Paul,<br>
&gt;<br>
&gt; Having BFCP over data channel would limit the applicability of BFCP to=
 webrtc (other formulation: it would require the webrtc framework to get BF=
CP in the browser), while we might want to have BFCP protocol in web client=
 outside of webrtc.<br>
<br>
I guess I didn't explain myself well enough.<br>
<br>
What I am suggesting is bfcp over the DTLS/SCTP stack that is being used <b=
r>
for RTCWEB data channels, and that the mechanisms used to negotiate the <br=
>
stream numbers for each direction be compatible with RTCWEB. In this way <b=
r>
a true RTCWEB browser client can be implemented, but a non-RTCWEB (e.g. <br=
>
C-based) implementation is also possible.<br>
<br>
This is the same direction we are investigating for the clue data channel.<=
br>
<br>
The term &quot;data channel&quot; here is perhaps overloaded, because it co=
uld <br>
mean a real RTCWEB data channel, or something similar for other <br>
environments. Ideally we would just use SCTP terms, but it has no term <br>
for a bidirectional &quot;channel&quot;, only unidirectional streams. But t=
his <br>
should end up being formalized in the SDP.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Thanks, <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Paul<br>
<br>
&gt; St=E9phane.<br>
&gt;<br>
&gt; -----Message d'origine-----<br>
&gt; De : Paul Kyzivat [<a href=3D"mailto:pkyzivat@alum.mit.edu">mailto:pky=
zivat@alum.mit.edu</a>]<br>
&gt; Envoy=E9 : jeudi 21 f=E9vrier 2013 22:32<br>
&gt; =C0 : dispatch@ietf.org<br>
&gt; Objet : Re: [dispatch] FW: New Version Notification for draft-pascual-=
dispatch-bfcp-websocket-00.txt<br>
&gt;<br>
&gt; Victor,<br>
&gt;<br>
&gt; A question for you:<br>
&gt;<br>
&gt; Another possibility is to map bfcp over a data channel as being specif=
ied for rtcweb.<br>
&gt;<br>
&gt; If that were done, would it be a suitable alternative to bfcp over web=
socket?<br>
&gt;<br>
&gt; We are also going to need bfcp support in conjunction with CLUE.<br>
&gt; And CLUE is going to have its own data channel. We are aiming to use a=
n rtcweb-compatible data channel so that we can have rtcweb browser based c=
lue clients.<br>
&gt;<br>
&gt; If bfcp also worked over a data channel, then these multiple uses of d=
ata channels could all coexist on a single SCTP association. And they could=
 work the same regardless of whether or not there are web clients.<br>
&gt;<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Thanks,<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Paul<br>
&gt;<br>
&gt; On 2/21/13 12:38 PM, Victor Pascual Avila wrote:<br>
&gt;&gt; Hi all,<br>
&gt;&gt;<br>
&gt;&gt; We have submitted a new Internet draft to describe the WebSocket<b=
r>
&gt;&gt; Protocol as a Transport for the Binary Floor Control Protocol (BFC=
P).<br>
&gt;&gt; We are looking forward to your review comments.<br>
&gt;&gt;<br>
&gt;&gt; <a href=3D"http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-=
websocket-00">
http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00</a><br>
&gt;&gt;<br>
&gt;&gt; Best regards,<br>
&gt;&gt; -Victor<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On 2/15/13 6:17 PM, &quot;internet-drafts@ietf.org&quot;<br>
&gt;&gt; &lt;internet-drafts@ietf.org&gt;<br>
&gt;&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; A new version of I-D, draft-pascual-dispatch-bfcp-websocket-00=
.txt<br>
&gt;&gt;&gt; has been successfully submitted by Victor Pascual and posted t=
o the<br>
&gt;&gt;&gt; IETF repository.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Filename:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; draft-pascual-di=
spatch-bfcp-websocket<br>
&gt;&gt;&gt; Revision:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 00<br>
&gt;&gt;&gt; Title:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; T=
he WebSocket Protocol as a Transport for the Binary Floor<br>
&gt;&gt;&gt; Control Protocol (BFCP)<br>
&gt;&gt;&gt; Creation date:&nbsp; 2013-02-15<br>
&gt;&gt;&gt; Group:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I=
ndividual Submission<br>
&gt;&gt;&gt; Number of pages: 9<br>
&gt;&gt;&gt; URL:<br>
&gt;&gt;&gt; <a href=3D"http://www.ietf.org/internet-drafts/draft-pascual-d=
ispatch-bfcp-webso">
http://www.ietf.org/internet-drafts/draft-pascual-dispatch-bfcp-webso</a><b=
r>
&gt;&gt;&gt; cket-<br>
&gt;&gt;&gt; 00.txt<br>
&gt;&gt;&gt; Status:<br>
&gt;&gt;&gt; <a href=3D"http://datatracker.ietf.org/doc/draft-pascual-dispa=
tch-bfcp-websocket">
http://datatracker.ietf.org/doc/draft-pascual-dispatch-bfcp-websocket</a><b=
r>
&gt;&gt;&gt; Htmlized:<br>
&gt;&gt;&gt; <a href=3D"http://tools.ietf.org/html/draft-pascual-dispatch-b=
fcp-websocket-00">
http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Abstract:<br>
&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; The WebSocket protocol enables two-way=
 realtime communication between<br>
&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; clients and servers.&nbsp; This docume=
nt specifies a new WebSocket sub-<br>
&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; protocol as a reliable transport mecha=
nism between Binary Floor<br>
&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; Control Protocol (BFCP) entities to en=
able usage of BFCP in new<br>
&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; scenarios.&nbsp; This document normati=
vely updates<br>
&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; [I-D.draft-ietf-bfcpbis-rfc4582bis] an=
d<br>
&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; [I-D.draft-ietf-bfcpbis-rfc4583bis]<br=
>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; The IETF Secretariat<br>
&gt;&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; dispatch mailing list<br>
&gt;&gt; dispatch@ietf.org<br>
&gt;&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/dispatch">https:/=
/www.ietf.org/mailman/listinfo/dispatch</a><br>
&gt;&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
<br>
</div>
</span></font>
</body>
</html>

--_000_FEE7A6136F518B4B87037A58924AB6B00675A13AFTRDMB03rdfranc_--

From pkyzivat@alum.mit.edu  Sun Feb 24 15:20:16 2013
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5D521F909D for <dispatch@ietfa.amsl.com>; Sun, 24 Feb 2013 15:20:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Level: 
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MeWeFPPrfoLb for <dispatch@ietfa.amsl.com>; Sun, 24 Feb 2013 15:20:15 -0800 (PST)
Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id D0F8121F909A for <dispatch@ietf.org>; Sun, 24 Feb 2013 15:20:14 -0800 (PST)
Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta01.emeryville.ca.mail.comcast.net with comcast id 4K8X1l0081eYJf8A1PLEHs; Sun, 24 Feb 2013 23:20:14 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([115.198.251.22]) by omta19.emeryville.ca.mail.comcast.net with comcast id 4PHm1l00A0VlArX01PHsVR; Sun, 24 Feb 2013 23:18:09 +0000
Message-ID: <512A8982.3080809@alum.mit.edu>
Date: Mon, 25 Feb 2013 05:43:30 +0800
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: stephane.cazeaux@orange.com
References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <CD442C6C.B156%vpascual@acmepacket.com> <CAGTXFp-Ee_XsD0NdmrFxjqyUN9cP-+Q2XNAKV35MMTtZJxUEcA@mail.gmail.com> <5126925E.2010102@alum.mit.edu> <FEE7A6136F518B4B87037A58924AB6B0067596FB@FTRDMB03.rd.francetelecom.fr>, <51296D15.1030105@alum.mit.edu> <FEE7A6136F518B4B87037A58924AB6B00675A13A@FTRDMB03.rd.francetelecom.fr>
In-Reply-To: <FEE7A6136F518B4B87037A58924AB6B00675A13A@FTRDMB03.rd.francetelecom.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361748014; bh=B/OSG8LPqxpmut6MQWM4bGqaWA8fYhqtoOBz3vUWv+M=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=WLHIMKLehAKZG6tbg0Nt7lrPCQ0s2TWQ2JuLKnnH04bB1GZbby1QYhXQQQLdoyCZE AvJ53haWG6GCxOwGUR+tCkPSPj5bu0JbUnUxFYhxpUF/3jBSEd2fN4yGC3Wa1Gajb2 f5YjB9EGv7ADnhWjuiH34KGYYw52gaZ0nonUvIfGQJ6a4mn6+2SWv/GF/lF/7P80CC fQQWjislfabGMQcWra053or066h2sOZOyURHRih8CVYK38RwPww6Qryg9XgLann5ut rnFOmxBRqyA/bHg0dnXM8B/PqyLYxqwHavaM0Faloc6CWpBonD6rPpMuDUPU86cpRb j0wTP/oxrf1eg==
Cc: dispatch@ietf.org
Subject: [dispatch] Remapping existing protocols for web usage: websockets or data channels?
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 24 Feb 2013 23:20:16 -0000

On 2/24/13 5:28 PM, stephane.cazeaux@orange.com wrote:
> That was my understanding. My point is that on the browser, the data
> channel is part of the webrtc stuff. While websocket is to me more
> suitable for such browser to server exchange.
> Btw, what is the rationale of having bfcp over sctp/dtls on a CLUE
> endpoint since, unless I am wrong, a CLUE endpoint will also have to
> support bfcp over tcp (or udp) to interwork with legacy ?

First, AFAIK there are currently no plans to put bfcp over a data 
channel, but I think there should be.

My reason is because that is a mechanism that could be supported by a an 
RTCWEB client. And yes, it indeed may be the case that a CLUE endpoint 
may still need to support bfcp over tcp or udp for legacy interworking.

It would also be possible for an RTCWEB clue client to use bfcp over a 
websocket.

The question is: how many of these alternatives do we want to define and 
then ask people to support in their products. The more alternatives we 
have the less likely we are to get interoperability.

We have now started down the path of remapping existing protocols (first 
SIP, then MSRP, now maybe BFCP) over websockets. Meanwhile RTCWEB is 
defining data channels over SCTP and and CLUE is tentatively planning to 
put its protocol over that. So maybe we had better have a discussion of 
where we are trying to go, and if what we are doing will get us to a 
good place.

	Thanks,
	Paul

> Stéphane.
> ------------------------------------------------------------------------
> De : Paul Kyzivat
> Envoyé : 24/02/2013 02:32
> À : CAZEAUX Stephane OLNC/OLPS
> Cc : dispatch@ietf.org
> Objet : Re: [dispatch] FW: New Version Notification for
> draft-pascual-dispatch-bfcp-websocket-00.txt
>
> On 2/22/13 11:40 AM, stephane.cazeaux@orange.com wrote:
>> Hi Paul,
>>
>> Having BFCP over data channel would limit the applicability of BFCP to webrtc (other formulation: it would require the webrtc framework to get BFCP in the browser), while we might want to have BFCP protocol in web client outside of webrtc.
>
> I guess I didn't explain myself well enough.
>
> What I am suggesting is bfcp over the DTLS/SCTP stack that is being used
> for RTCWEB data channels, and that the mechanisms used to negotiate the
> stream numbers for each direction be compatible with RTCWEB. In this way
> a true RTCWEB browser client can be implemented, but a non-RTCWEB (e.g.
> C-based) implementation is also possible.
>
> This is the same direction we are investigating for the clue data channel.
>
> The term "data channel" here is perhaps overloaded, because it could
> mean a real RTCWEB data channel, or something similar for other
> environments. Ideally we would just use SCTP terms, but it has no term
> for a bidirectional "channel", only unidirectional streams. But this
> should end up being formalized in the SDP.
>
>          Thanks,
>          Paul
>
>> Stéphane.
>>
>> -----Message d'origine-----
>> De : Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>> Envoyé : jeudi 21 février 2013 22:32
>> À : dispatch@ietf.org
>> Objet : Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt
>>
>> Victor,
>>
>> A question for you:
>>
>> Another possibility is to map bfcp over a data channel as being specified for rtcweb.
>>
>> If that were done, would it be a suitable alternative to bfcp over websocket?
>>
>> We are also going to need bfcp support in conjunction with CLUE.
>> And CLUE is going to have its own data channel. We are aiming to use an rtcweb-compatible data channel so that we can have rtcweb browser based clue clients.
>>
>> If bfcp also worked over a data channel, then these multiple uses of data channels could all coexist on a single SCTP association. And they could work the same regardless of whether or not there are web clients.
>>
>>        Thanks,
>>        Paul
>>
>> On 2/21/13 12:38 PM, Victor Pascual Avila wrote:
>>> Hi all,
>>>
>>> We have submitted a new Internet draft to describe the WebSocket
>>> Protocol as a Transport for the Binary Floor Control Protocol (BFCP).
>>> We are looking forward to your review comments.
>>>
>>>http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00
>>>
>>> Best regards,
>>> -Victor
>>>
>>>
>>> On 2/15/13 6:17 PM, "internet-drafts@ietf.org"
>>> <internet-drafts@ietf.org>
>>> wrote:
>>>
>>>>
>>>> A new version of I-D, draft-pascual-dispatch-bfcp-websocket-00.txt
>>>> has been successfully submitted by Victor Pascual and posted to the
>>>> IETF repository.
>>>>
>>>> Filename:       draft-pascual-dispatch-bfcp-websocket
>>>> Revision:       00
>>>> Title:          The WebSocket Protocol as a Transport for the Binary Floor
>>>> Control Protocol (BFCP)
>>>> Creation date:  2013-02-15
>>>> Group:          Individual Submission
>>>> Number of pages: 9
>>>> URL:
>>>>http://www.ietf.org/internet-drafts/draft-pascual-dispatch-bfcp-webso
>>>> cket-
>>>> 00.txt
>>>> Status:
>>>>http://datatracker.ietf.org/doc/draft-pascual-dispatch-bfcp-websocket
>>>> Htmlized:
>>>>http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00
>>>>
>>>>
>>>> Abstract:
>>>>     The WebSocket protocol enables two-way realtime communication between
>>>>     clients and servers.  This document specifies a new WebSocket sub-
>>>>     protocol as a reliable transport mechanism between Binary Floor
>>>>     Control Protocol (BFCP) entities to enable usage of BFCP in new
>>>>     scenarios.  This document normatively updates
>>>>     [I-D.draft-ietf-bfcpbis-rfc4582bis] and
>>>>     [I-D.draft-ietf-bfcpbis-rfc4583bis]
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> The IETF Secretariat
>>>>
>>> _______________________________________________
>>> dispatch mailing list
>>> dispatch@ietf.org
>>>https://www.ietf.org/mailman/listinfo/dispatch
>>>
>>
>>
>>
>


From mary.ietf.barnes@gmail.com  Wed Feb 27 14:53:13 2013
Return-Path: <mary.ietf.barnes@gmail.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA65521F85A1 for <dispatch@ietfa.amsl.com>; Wed, 27 Feb 2013 14:53:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.579
X-Spam-Level: 
X-Spam-Status: No, score=-103.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lj2h1hcPeazb for <dispatch@ietfa.amsl.com>; Wed, 27 Feb 2013 14:53:13 -0800 (PST)
Received: from mail-qe0-f50.google.com (mail-qe0-f50.google.com [209.85.128.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6E521F8533 for <dispatch@ietf.org>; Wed, 27 Feb 2013 14:53:13 -0800 (PST)
Received: by mail-qe0-f50.google.com with SMTP id w7so920311qeb.23 for <dispatch@ietf.org>; Wed, 27 Feb 2013 14:53:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=EaOq2GeNpuK0pZp8U7oDhTDMa4SRGK2KsARsLTEEptU=; b=PzMwb8uTd8B55LIKmN4hJZ2rBjWjyXra3eAsbRDSuIVUFDS8bynzJrPU60LQv+ELaw 7y02MFy+7SLAzDxEYoVPxoOTgZkW2F3nnbH6aNjTgb9ip0oRffFiY0mRsnjO72M1eYz5 +9P/UFfVgKSPYju0tOjDo08lnMLJWanSp2ApzvmbYGtAxXBNmj8v71YsTLBIDEf1J9yF 60Nugnpty7sn9EJ6IRu7Gi9McdFY+D4d5eg7h08UbwVl0x4dCiPG5zpHUxd91aiYyQMk 8ApdIrT7gL7pu9MSRbYgASiYZsmsy1awwF27agC9pc2ozrle9N0jzQO6q58P8B0U9iHI nOYw==
MIME-Version: 1.0
X-Received: by 10.49.127.139 with SMTP id ng11mr6924743qeb.54.1362005592595; Wed, 27 Feb 2013 14:53:12 -0800 (PST)
Received: by 10.49.24.130 with HTTP; Wed, 27 Feb 2013 14:53:12 -0800 (PST)
Date: Wed, 27 Feb 2013 16:53:12 -0600
Message-ID: <CAHBDyN7RK24iQnsJmeaATK45MYF=Yg=yw=Giusy1ckGFxSJc0w@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: DISPATCH <dispatch@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Cullen Jennings <fluffy@cisco.com>, Richard Barnes <rbarnes@bbn.com>, "rai-ads@tools.ietf.org" <rai-ads@tools.ietf.org>
Subject: [dispatch] IETF-86 DISPATCH Topics
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Feb 2013 22:53:13 -0000

Hi all,

The chairs met with the ADs yesterday to review the topics and that
have been posted for discussion since IETF-85.  The summary of the
dispatching of the topics is below.  Please let us know if you have
any questions or concerns.

The DISPATCH agenda for IETF-86 has been uploaded to the proceedings
and the wiki will be updated shortly:
https://datatracker.ietf.org/meeting/86/agenda/dispatch/
Please send comments on the agenda no later than Friday, March 1st, 2013.

Note that since our WG session is Monday afternoon, the chairs are
requesting the slides be submitted no later than 6pm (Orlando time)
Saturday, March 9th, so we can get them uploaded for access by remote
participants and Meetecho.

Thanks,
Mary.


IETF-86 DISPATCH Topics
=====================

Topics to be discussed at IETF-86:
1) SIP/XMPP Interworking:
http://www.ietf.org/mail-archive/web/dispatch/current/msg04561.html

2) Logging Requirements:
 http://www.ietf.org/mail-archive/web/dispatch/current/msg04560.html


Topics that are proposed to be dispatched to other WGs:
1) SIP Usage for Trickle ICE ( MMUSIC WG):
http://www.ietf.org/mail-archive/web/dispatch/current/msg04550.html
Documents:  and draft-ivov-dispatch-sdpfrag/  (Note that this work
will require review by related WGs such as SIPCORE and RTCWEB)

2) BFCP over websockets (BFCPBIS WG):
http://www.ietf.org/mail-archive/web/dispatch/current/msg04578.html
(Note that any concerns about this decision should be discussed on the
DISPATCH WG mailing list.  The related updates to the BFCPbis WG
charter and the decision as to whether the document is to be accepted
as a WG document are to be discussed on the BFCPBIS WG mailing list.)

Topics that are proposed to be AD sponsored:
1)  MSRP over Websockets:
http://www.ietf.org/mail-archive/web/dispatch/current/msg04493.html
(Richard will be the responsible AD)

Topics for which agenda time was requested that have not received
enough WG feedback:
1) QoE:  http://www.ietf.org/mailarchive/web/dispatch/current/msg04535.html
(The WG needs a clear problem statement before being able to make any
decision on this work).

From mary.ietf.barnes@gmail.com  Thu Feb 28 08:53:29 2013
Return-Path: <mary.ietf.barnes@gmail.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 207D621F8C11; Thu, 28 Feb 2013 08:53:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.581
X-Spam-Level: 
X-Spam-Status: No, score=-103.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCh4ar+2vjCP; Thu, 28 Feb 2013 08:53:23 -0800 (PST)
Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9200E21F8BD4; Thu, 28 Feb 2013 08:53:19 -0800 (PST)
Received: by mail-qa0-f48.google.com with SMTP id j8so1509517qah.14 for <multiple recipients>; Thu, 28 Feb 2013 08:53:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=nuu7zvgMwUH2UDNh8XFyqk74qQ9CkXvbSqqIqd5qHo8=; b=KTSUGdIbmIfCoPM6bqtzloqiVH8q5jxOv6/W4vmNgDOgyDXE22+mxZzqRO62lJ8hsu HwhGgvZKUlS93HhdBDMTNjwDqFzr7QISAAIcc0Qk+BVaSgX+UxOeaSYWbo5VuyhlKhmJ Hhqz5MK5H6o+ujD9fuLACxcUZY7abz9T0Yz7ACxyk64ZQFFwP42j230XyuDDIFvQHz+w sOFExHCxiWNoC0giz+qw05QbypKPzbK11yQv6anBWPoH6U5NlZVEYIrt+F6+OpQmAXdM PSayOTh67xq0FZT3wiksjrx528Y8EYYDr/2YAhLzvS0ep1Lg37poCrgvVDAtbGyg8kFc XAog==
MIME-Version: 1.0
X-Received: by 10.224.193.200 with SMTP id dv8mr7273935qab.85.1362070399115; Thu, 28 Feb 2013 08:53:19 -0800 (PST)
Received: by 10.49.24.130 with HTTP; Thu, 28 Feb 2013 08:53:19 -0800 (PST)
Date: Thu, 28 Feb 2013 10:53:19 -0600
Message-ID: <CAHBDyN69YX0TFVoCh75ADy1LTEnctzzZY16jbKHOvdy5GKgiEg@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: DISPATCH <dispatch@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Cullen Jennings <fluffy@cisco.com>, Richard Barnes <rbarnes@bbn.com>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, "rai-ads@tools.ietf.org" <rai-ads@tools.ietf.org>, "draft-pascual-dispatch-bfcp-websocket@tools.ietf.org" <draft-pascual-dispatch-bfcp-websocket@tools.ietf.org>
Subject: [dispatch] DISPATCHING BFCP over websockets
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Feb 2013 16:53:29 -0000

Just in case you missed this, the following is noted under the "Topics
that are proposed to be dispatched to other WGs:"
http://www.ietf.org/mail-archive/web/dispatch/current/msg04590.html

2) BFCP over websockets (BFCPBIS WG):
http://www.ietf.org/mail-archive/web/dispatch/current/msg04578.html
(Note that any concerns about this decision should be discussed on the
DISPATCH WG mailing list.  The related updates to the BFCPbis WG
charter and the decision as to whether the document is to be accepted
as a WG document are to be discussed on the BFCPBIS WG mailing list.)

Comments/concerns are requested no later than March 8th, 2013.

Note, that while the BFCPbis WG is not meeting in Orlando, if folks
are okay with this proposal, discussion of the solution can start on
the BFCPbis WG mailing list.

Regards,
Mary.