From nobody Wed Aug 7 14:14:55 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59733120059 for ; Wed, 7 Aug 2019 14:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l45h-Y5MWDvf for ; Wed, 7 Aug 2019 14:14:51 -0700 (PDT) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FF2D12003F for ; Wed, 7 Aug 2019 14:14:51 -0700 (PDT) Received: by mail-qk1-x732.google.com with SMTP id s145so67038479qke.7 for ; Wed, 07 Aug 2019 14:14:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Yg8n56+taqFnUD0emWAzPzzp8nKgESOy3eNY1KIaHyk=; b=G67er/7ILy7H4TjLzAZZEfhdYJHDfBwyjLiuDEMGFj+FHmx62aEyJ2Yq/GvNqr9sgS AWCrYL4/riNbgEGg8BGQhD24LNYT/9kZqS8/bHoy3iwpAu9GPgIBotRmSBw7KidxfDLz m8TiptDh9/h8+x9JQQDtKdjlH8jxYy4/kLg4TaWlY1mGSQQf6GNrU03b2cyH0Bj2OWE8 Lvu9wUmaWh2JZOmvgBulSs8JT1G8kb8eRg8nll+Q7+aVrMhUd2rwukc+hXBhVA0KbDfT SXA8uXPqf5PM0qFWh+OpMpAQ/955B7eTgcIalJvSsb3U8utnyWa6thS6ZY3GwTlOhItt iYVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Yg8n56+taqFnUD0emWAzPzzp8nKgESOy3eNY1KIaHyk=; b=N9wUYst7WNw9phxTL+P36hslnpMN6DOvR0rZajny2UL3gOV5wPx0MCoxDK1L2FOzcu Y18492sJfn1zJQ4hH8j0QOlnIfBROb/RXc+tfjEyAbmME9/fkoW3a6XmqjnHHDRXVL+4 dbrEiuiN1T4So40tg+g0K3ZCJlKBsskN3s39MYuRoDlBdWNURa2fS231TVXpBawVptTs pUnMHExVloJp5/IDjnbEVXFRCaHUmi/iI3YOXf1S8K9zKjqQMCHIqqEL4dJw4wHLDxm6 jlhiKIEdzr+cH/zxVHUMzHuoJbZz2tNHjgAMLPJpo8yRngBdylkuqxjzuGd/Aqgeiqeq RupQ== X-Gm-Message-State: APjAAAWMXQN/jBzjtzpPnemzjTnFn2jaykms2a2Jzx8IdC9Q7DtkkyHF 0WiheGuRHK6b1rDFyopBkWDrbGZ0T8c= X-Google-Smtp-Source: APXvYqz1rhq2KEnAxw1dqUsBwCdoDCk9bgD4fGo5X61TxiD3N4HW7IopeENyC47FfvGEinsd8ogBzg== X-Received: by 2002:ae9:f809:: with SMTP id x9mr10422806qkh.86.1565212490255; Wed, 07 Aug 2019 14:14:50 -0700 (PDT) Received: from brians-mbp-2369.lan (dynamic-acs-24-101-114-50.zoominternet.net. [24.101.114.50]) by smtp.gmail.com with ESMTPSA id 67sm39714699qkh.108.2019.08.07.14.14.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Aug 2019 14:14:49 -0700 (PDT) From: Brian Rosen Message-Id: <64B406DC-4171-41EB-9171-A2AF7B78B409@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_576F8FD4-2E26-4631-A811-3C32A415726D" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 7 Aug 2019 17:14:48 -0400 In-Reply-To: <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net> Cc: rum@ietf.org To: "Olle E. Johansson" References: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Rum] Let's get into it X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 21:14:54 -0000 --Apple-Mail=_576F8FD4-2E26-4631-A811-3C32A415726D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Working on these comments. I submitted a new version (-01) I edited the doc to say the client cert is provisioned. Given that = it=E2=80=99s provisioned by the entity that the provides the server, do = I need to say anything else about validating the cert? I=E2=80=99m fine with requiring support for SIP-over-websockets = (RFC7118), but is that a general goodness these days? The general requirements require TLS for SIP, so I don=E2=80=99t think I = need anything else for telephone number privacy, right? 6.2.1 says =E2=80=9CRoute headers MAY be included in one-stage = dial-around calls and emergency calls.=E2=80=9D 6.2.2 is one-stage-dial = around, so it fits the exception for the SHOULD. I added the reference to RFC6351 for xCard. I think we should have a = discussion of whether this mechanism should be retained. The purpose = was to deal with an objection from providers that if they supported this = interface, anyone could download some random code claiming to meet it, = and they wouldn=E2=80=99t have a clue where it came from or a way to = contact anyone if it didn=E2=80=99t behave. As you point out, there = isn=E2=80=99t any way for the server to put any trust in the data. The = requirement for TLS covers eavesdropping, but it still could obtain PII. = I left the text for now, but we should discuss. You said =E2=80=9CThe proxy is found using DNS and may be a list created = from NATPR/DNS SRV records. What is the defintion of =E2=80=9Cthe = proxy=E2=80=9D in this statement?=E2=80=9D, It seems obvious to me that = the proxy URI is found in the configuration and the SRV resolves to an = IP address (or addresses). What is unclear? Simultaneous ring is a pretty well known thing, which I think everyone = does with parallel fork in one form or another. There is only two MUSTs = for the server (if there are multiple registrations, ring them all, and = CANCEL any ringing UAs that didn=E2=80=99t answer). 3261 doesn=E2=80=99t = discuss CANCEL when forking and I don=E2=80=99t see where we say = anything that could be construed as violating anything I can see in = 3261. I=E2=80=99m at a loss to understand what I should change. The reference to OUTBOUND also confuses me. Yeah, you could get some = forking when following Outbound, but that wouldn=E2=80=99t change this = fork of independent registered UAs would it? What text suggestion do = you have? I=E2=80=99m very happy to clarify anything unclear, but I = don=E2=80=99t see the problem yet. I added the RFC references to REFER, and included the 7647 update as = well as explicit support for norefersub, Could we have a discussion of whether we require support for IPv4. I = think we do, but are their other opinions? I fixed =E2=80=9Cdomain = part=E2=80=9D. I replaced the media and SRTP sections with references to the WebRTC = media specifications. There is a significant problem where there are = existing endpoints that simply can=E2=80=99t be upgraded to support SRTP = video. This may be less of a problem if the systems that support those = endpoints anchor media in their SBCs. The example operator URI in Section 11.1 doesn=E2=80=99t contain a = number-which-is-not-an-E164, and thus doesn=E2=80=99t need = user=3Ddialstring. > On Jul 10, 2019, at 6:28 AM, Olle E. Johansson wrote: >=20 >=20 >=20 >> On 9 Jul 2019, at 21:48, Brian Rosen > wrote: >>=20 >> Please comment on anything. >=20 > Section 5: >=20 > "Both HTTPS and all SIP Transactions MUST use TLS 1.2=E2=80=9D >=20 > =E2=80=9CTransactions=E2=80=9D doesn=E2=80=99t work well here. = =E2=80=9CConnections=E2=80=9D would be better. > Instead of hard-coding a specific version of TLS you may want to point = to the BCP by the UTA wg, > unless you anyway will update this profile from time to time. >=20 > " During the establishment of secure connections with a provider, the > RUE MAY be asked by the server for a client certificate. In that > case it SHOULD provide a client certificate. Providers MAY reject > requests that fail to provide a recognized certificate.=E2=80=9D >=20 > What=E2=80=99s in the client cert? How do you validate the client = certs? >=20 > Section 6 doesn=E2=80=99t mentionSIP over WebSockets. I assume that = would apply. >=20 >=20 > Since you are using phone numbers as identifiers, I from an EU = standpoint > suggest disallowing all non-secure transports. Phone numbers are=20 > considered personal identifiers and are affected by the EU GDPR. >=20 >=20 > Section 6.2.1 forbids Route headers in initial INVITE requests. The = example > in 6.2.2 has a very visible Route: header in the initial request. >=20 > Section 6.2.3 talks about an xCard without any references or comments > about trust for that information. >=20 > Section 6.2.4: >=20 > "The RUE MUST accept inbound calls sent to it by the proxy mentioned > in the configuration.=E2=80=9D >=20 > The proxy is found using DNS and may be a list created from NATPR/DNS = SRV > records. What is the defintion of =E2=80=9Cthe proxy=E2=80=9D in this = statement? >=20 > "If Multiple simultaneous RUE SIP registrations from different RUE > devices with the same SIP URI exist, the Provider MUST parallel = fork the call to all registered RUEs so that they ring at the same = time. > The first RUE to reply with a 200 OK answers the call and the > Provider MUST CANCEL other call branches. > " > Is this normative (you have many MUST here). If so - how does this > change the behaviour of RFC 3261? > Also, I think this texts forgets about SIP outbound. Since Outbound is = a MUST, > you need to clarify the mix of parallell and serial forking that will = happen. >=20 >=20 > Section 6.3: >=20 > "The RUE MUST support REFER to enable call transfer.=E2=80=9C >=20 > Which combination of REFER? I assume that =E2=80=9CMid call = signaling=E2=80=9D is =E2=80=9Cin-dialog transactions=E2=80=9D in SIP = lingo, > but REFER with or without Replaces? With or without subscription for = updates? >=20 > Section 6.4: >=20 > " Relay Service URIs and User Address of Records (AoR) MUST resolve = (in > accord with [RFC3263 ]) to = globally routable IPv4 addresses. The AoRs > MAY also resolve to IPv6 addresses.=E2=80=9D >=20 > How do you resolve a complete URI into an IP address? I guess you mean > the domain part that resolves to a list of addresses using DNS. > Why is IPv4 a MUST? >=20 > Section 8: >=20 > "All media streams between the RUE and another endpoint or relay > Provider MUST be exchanged using the secure real-time transport > protocol (SRTP) [RFC3550 ] = using DTLS [RFC5763 ], [RFC5764 = ], except > that for backwards compatibility with older video endpoints, RTP = MAY > be negotiated if SRTP negotiation fails. > =E2=80=9C >=20 > How do you handle the risk of downgrade attacks here? That exception = is dangerous > and maybe should be handled elsewhere, not in the client.=20 >=20 >=20 > Section 11.1 >=20 > The example operator URI for red.example.net = seems to lack =E2=80=9C;user=3Ddialstring=E2=80=9D >=20 > Section 11.2 >=20 > "outbound-proxies: (OPTIONAL) A list of URIs of SIP proxies to be > used when sending requests to the Provider. Multiple URIs > identify alternative (redundant) paths to the Provider. > =E2=80=9C >=20 > Outbound proxy is of course something you look up in DNS to get the = list of > actual servers. Is there a need to have an additional list in this = json format? >=20 > " ice-servers=E2=80=9D - propably a bad name. I don=E2=80=99t remember = seeing =E2=80=9Cice server=E2=80=9D as a term. > As turn servers are also STUN servers, I think =E2=80=9Cturn-servers=E2=80= =9D is better. >=20 > =E2=80=9Ccredentials=E2=80=9D: This is tricky indeed. Sending = credentials in clear text like this, > even if it=E2=80=99s over HTTPS is an interesting approach in this age = and time. > Regardless of that, make sure you consider OAuth/OpenID connect auth > for some services. >=20 > =E2=80=9Clifetime=E2=80=9D:; You are really not clear on what happens = when the configuration > expires. Is the RUE forbidden to use anything here? What about = emergency calls > - will they work even without configuration? >=20 > General: >=20 > You do not mention bundling of RTP streams, which may be beneficial = here. >=20 > Good work! >=20 > /O >=20 >=20 >=20 >=20 >=20 --Apple-Mail=_576F8FD4-2E26-4631-A811-3C32A415726D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Working on these comments.  I submitted a new version = (-01)

I edited the = doc to say the client cert is provisioned.  Given that it=E2=80=99s = provisioned by the entity that the provides the server, do I need to say = anything else about validating the cert?
I=E2=80=99m fine with requiring = support for SIP-over-websockets (RFC7118), but is that a general = goodness these days?

The general requirements require TLS for SIP, so I don=E2=80=99= t think I need anything else for telephone number privacy, = right?

6.2.1 = says =E2=80=9CRoute headers MAY be included in one-stage dial-around = calls and emergency calls.=E2=80=9D  6.2.2 is one-stage-dial = around, so it fits the exception for the SHOULD.

I added the reference to RFC6351 for = xCard.   I think we should have a discussion of whether this = mechanism should be retained.  The purpose was to deal with an = objection from providers that if they supported this interface, anyone = could download some random code claiming to meet it, and they wouldn=E2=80= =99t have a clue where it came from or a way to contact anyone if it = didn=E2=80=99t behave.  As you point out, there isn=E2=80=99t any = way for the server to put any trust in the data.  The requirement = for TLS covers eavesdropping, but it still could obtain PII.  I = left the text for now, but we should discuss.

You said =E2=80=9CThe proxy is found = using DNS and may be a list created from NATPR/DNS SRV records. What is = the defintion of =E2=80=9Cthe proxy=E2=80=9D in this statement?=E2=80=9D, =  It seems obvious to me that the proxy URI is found in the = configuration and the SRV resolves to an IP address (or addresses). =  What is unclear?

Simultaneous ring is a pretty well known thing, which I think = everyone does with parallel fork in one form or another.  There is = only two MUSTs for the server (if there are multiple registrations, ring = them all, and CANCEL any ringing UAs that didn=E2=80=99t answer). 3261 = doesn=E2=80=99t discuss CANCEL when forking and I don=E2=80=99t see = where we say anything that could be construed as violating anything I = can see in 3261.  I=E2=80=99m at a loss to understand what I should = change.

The = reference to OUTBOUND also confuses me.  Yeah, you could get some = forking when following Outbound, but that wouldn=E2=80=99t change this = fork of independent registered UAs would it?  What text suggestion = do you have?  I=E2=80=99m very happy to clarify anything unclear, = but I don=E2=80=99t see the problem yet.

I added the RFC references to REFER, = and included the 7647 update as well as explicit support for = norefersub,

Could we have a discussion of whether we require support for = IPv4.  I think we do, but are their other opinions?  I fixed = =E2=80=9Cdomain part=E2=80=9D.

I replaced the media and SRTP sections = with references to the WebRTC media specifications.  There is a = significant problem where there are existing endpoints that simply = can=E2=80=99t be upgraded to support SRTP video.  This may be less = of a problem if the systems that support those endpoints anchor media in = their SBCs.

The = example operator URI in Section 11.1 doesn=E2=80=99t contain a = number-which-is-not-an-E164, and thus doesn=E2=80=99t need = user=3Ddialstring.



On = Jul 10, 2019, at 6:28 AM, Olle E. Johansson <oej@edvina.net> = wrote:



On 9 Jul 2019, at 21:48, Brian Rosen <br@brianrosen.net> = wrote:

Please comment on = anything.

Section 5:

"Both HTTPS and all = SIP Transactions MUST use TLS 1.2=E2=80=9D

=E2=80=9CTransactions=E2=80=9D = ;doesn=E2=80=99t work well here. =E2=80=9CConnections=E2=80=9D = would be better.
Instead of hard-coding a specific version of TLS you may want = to point to the BCP by the UTA wg,
unless you anyway will update this profile from = time to time.

" During the establishment of secure connections with a = provider, the
   RUE MAY be asked by the server for a client certificate.  In =
that
   case it SHOULD provide a client certificate.  Providers MAY reject
   requests that fail to provide a recognized certificate.=E2=80=9D
<= pre class=3D"newpage" style=3D"font-size: 13.333333015441895px; = margin-top: 0px; margin-bottom: 0px; break-before: page;">
What=E2=80=99s in the client cert? How do you validate the client =
certs?

Section 6 doesn=E2=80=99t mentionSIP over WebSockets. I assume =
that would apply.


Since you are using phone numbers as identifiers, I from an EU =
standpoint
suggest disallowing all non-secure transports. Phone numbers are =

considered =
personal identifiers and are affected by the EU GDPR.


Section 6.2.1 forbids =
Route headers in initial INVITE requests. The example
in 6.2.2 has a very =
visible Route: header in the initial request.

Section 6.2.3 talks about =
an xCard without any references or comments
about trust for that =
information.

Section 6.2.4:

"The RUE MUST accept inbound calls sent to it by the proxy =
mentioned
   in the configuration.=E2=80=9D

The proxy is found using =
DNS and may be a list created from NATPR/DNS SRV
records. What is the =
defintion of =E2=80=9Cthe proxy=E2=80=9D in this statement?

"If Multiple simultaneous =
RUE SIP registrations from different RUE
   devices with the same SIP =
URI exist, the Provider MUST parallel fork   the call to all registered =
RUEs so that they ring at the same time.

   The first =
RUE to reply with a 200 OK answers the call and the
   Provider MUST CANCEL other call branches.
"
Is this normative (you have many MUST here). If so - how does =
this
change the behaviour of RFC 3261?
Also, I think this texts =
forgets about SIP outbound. Since Outbound is a MUST,
you need to clarify the =
mix of parallell and serial forking that will happen.


Section 6.3:

"The RUE MUST support   =
REFER to enable call transfer.=E2=80=9C

Which combination of REFER? I assume = that =E2=80=9CMid call signaling=E2=80=9D is =E2=80=9Cin-dialog = transactions=E2=80=9D in SIP lingo,
but REFER with = or without Replaces? With or without subscription for updates?

Section 6.4:

" Relay Service URIs and User Address = of Records (AoR) MUST resolve (in
   accord with [RFC3263]) to globally routable IPv4 addresses.  The AoRs
   MAY also resolve to IPv6 addresses.=E2=80=9D

How do you resolve a =
complete URI into an IP address? I guess you mean
the domain part that =
resolves to a list of addresses using DNS.
Why is IPv4 a MUST?

Section 8:

"All media streams between =
the RUE and another endpoint or relay
   Provider MUST be exchanged =
using the secure real-time transport
   protocol (SRTP) [RFC3550] using DTLS [RFC5763], [RFC5764], except
   that for backwards compatibility with older video endpoints, RTP MAY
   be negotiated if SRTP negotiation fails.
=E2=80=9C

How do you handle the risk of downgrade attacks here? That = exception is dangerous
and maybe should be handled = elsewhere, not in the client. 


Section 11.1

The example operator URI for red.example.net seems= to lack =E2=80=9C;user=3Ddialstring=E2=80=9D

Section 11.2

"outbound-proxies: (OPTIONAL) A list of = URIs of SIP proxies to be
      used when sending =
requests to the Provider.  Multiple URIs
      identify alternative (redundant) paths to the Provider.
=E2=80=9C

Outbound proxy is of course something you look up in DNS to = get the list of
actual servers. Is there a need to = have an additional list in this json format?

" = ice-servers=E2=80=9D - propably a bad name. I don=E2=80=99t remember = seeing =E2=80=9Cice server=E2=80=9D as a term.
As turn servers are also STUN = servers, I think =E2=80=9Cturn-servers=E2=80=9D is = better.

=E2=80=9Ccredentials=E2=80=9D: This is tricky indeed. Sending = credentials in clear text like this,
even if it=E2=80=99s over HTTPS is an interesting = approach in this age and time.
Regardless of that, make sure you consider = OAuth/OpenID connect auth
for some services.

=E2=80=9Clifetime=E2=80=9D:; You are really not clear on what = happens when the configuration
expires. Is the RUE forbidden to use anything = here? What about emergency calls
- will they work even without = configuration?

General:

You do not mention bundling of = RTP streams, which may be beneficial here.

Good work!

/O






= --Apple-Mail=_576F8FD4-2E26-4631-A811-3C32A415726D-- From nobody Mon Aug 12 15:32:41 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB2F120B43 for ; Mon, 12 Aug 2019 15:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jAWLCRFolch for ; Mon, 12 Aug 2019 15:32:38 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46048120951 for ; Mon, 12 Aug 2019 12:57:05 -0700 (PDT) Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-01v.sys.comcast.net with ESMTP id xFeCh2umfORMIxGREhinmQ; Mon, 12 Aug 2019 19:57:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1565639824; bh=5zux+d6tSTMm7/Cv6nkpyKNU2CJTY7MfIxW4UwE6dVQ=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=SELXJF66ocYWMOWo2q///PIEuRQOl2WVmKAJn9QjzQK4sXoZuyJy03XJBRuyG7BWx 06NKZ/dN2x4SPlE8bWXQQUx7U57cElIdU9bXGi0tCTofoJRS4pIDMaWa1az3HEf5Ri E/1CJQL0mXMTxTv5011kP70mkTdr51hxoePEvvPpEtsMvc/fBGbZyQkez2BfcKOLNy 82hpeTKhv7SUi5KS0VvJot0KPJ+YNT4R7tQioBVfgzeaeWASmtD6gw4PgTuu03Hy0w rEyb5fEg+suVwIocaZ9hn6sdE7yLwfOMw9+iWVDBna+gxQlg+IbdtHbaiG38DisMiF R38wKkZG42g5Q== Received: from Kokiri.localdomain ([24.62.227.142]) by resomta-ch2-03v.sys.comcast.net with ESMTPA id xGRChEILiaZD1xGRDhrBUj; Mon, 12 Aug 2019 19:57:04 +0000 X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgeduvddruddvgedgudeggecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucevohhmtggrshhtqdftvghsihdpqfgfvfdppffquffrtefokffrnecuuegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtgfesthejredttdefjeenucfhrhhomheprfgruhhlucfmhiiiihhvrghtuceophgruhhlrdhkhiiiihhvrghtsegtohhmtggrshhtrdhnvghtqeenucfkphepvdegrdeivddrvddvjedrudegvdenucfrrghrrghmpehhvghlohepmfhokhhirhhirdhlohgtrghlughomhgrihhnpdhinhgvthepvdegrdeivddrvddvjedrudegvddpmhgrihhlfhhrohhmpehprghulhdrkhihiihivhgrthestghomhgtrghsthdrnhgvthdprhgtphhtthhopehruhhmsehivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedt X-Xfinity-VMeta: sc=0;st=legit To: rum@ietf.org References: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net> <64B406DC-4171-41EB-9171-A2AF7B78B409@brianrosen.net> From: Paul Kyzivat Message-ID: <67a7f982-ba69-bea2-0004-666221cbcf2b@comcast.net> Date: Mon, 12 Aug 2019 15:57:02 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <64B406DC-4171-41EB-9171-A2AF7B78B409@brianrosen.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Rum] RUE NAT Traversal in draft-rosen-rue-01 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 22:32:40 -0000 In draft-rosen-rue-00 and earlier section 6.5 on NAT Traversal puts control of ICE, STUN, and TURN on the provider through provisioning of the RUE. The STUN/TURN servers are presumably selected by the provider. In -01 this is changed to simply referencing draft-ietf-rtcweb-transports. That document puts some of the control over these in the hands of the browser, and allows the browser to be configured (presumably by the user). (Of course there is still a lot of control in the hands of the web server.) Given that we are not assuming/requiring that the RUE be browser-based, it isn't clear to me that draft-ietf-rtcweb-transports is a necessary or sufficient condition. OTOH, we don't want to exclude webrtc browser-based implementations. I have a feeling we need more options here. But at least we need more discussion on how this should work. Thanks, Paul From nobody Mon Aug 12 15:37:04 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE949121441 for ; Mon, 12 Aug 2019 15:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cWWQb-FkeUO for ; Mon, 12 Aug 2019 15:37:00 -0700 (PDT) Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81F68122433 for ; Mon, 12 Aug 2019 12:40:57 -0700 (PDT) Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x7CJetrJ017374 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 12 Aug 2019 15:40:56 -0400 To: rum@ietf.org References: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net> <64B406DC-4171-41EB-9171-A2AF7B78B409@brianrosen.net> From: Paul Kyzivat Message-ID: <054dde2a-7fa1-9941-986c-f3b3d8c0f76e@alum.mit.edu> Date: Mon, 12 Aug 2019 15:40:55 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <64B406DC-4171-41EB-9171-A2AF7B78B409@brianrosen.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [Rum] RUE client credentials X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 22:37:03 -0000 On 8/7/19 5:14 PM, Brian Rosen wrote: > Working on these comments.  I submitted a new version (-01) > > I edited the doc to say the client cert is provisioned.  Given that it’s > provisioned by the entity that the provides the server, do I need to say > anything else about validating the cert? I think we need to examine what the goal is here, and whether it is being achieved. I don't think enough is said to decide. This client cert mechanism was first added way back when (2015 I think). IIRC, the motivation was because the providers wanted to restrict access to RUE *implementations* that have passed interoperability testing, in order to reduce the problems of dealing with buggy implementations or attackers. The idea was that certs would only be made available to *implementations* (e.g. images) that have been tested. There was no expectation that each user who obtains a rue would need to have it tested. But the exact mechanism for binding a cert to a tested implementation was never worked out. I've asked around from time to time and I haven't learned of any way to achieve this. Brian's new text pushes this off one level but doesn't solve the problem. The provider's *sip* server can perhaps trust that the rue got the cert from the provider's provisioning server. But the provisioning server still has to decide if this is a trustworthy implementation. The Apple store and the Google Play Store solve this problem by being the distributor of apps. The developer has to submit the app, which is then tested/verified by the store and then being assigned credentials. Potentially we could have something list that by having a RUE Store operated by a RUE testing authority. But I don't think anybody is prepared to operate such a thing and it would require the devices receiving these apps to bypass the normal vendor restrictions on installations. I don't have a good answer here. Thanks, Paul From nobody Mon Aug 12 15:38:35 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1AFD121471 for ; Mon, 12 Aug 2019 15:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jx0Qw3SFz-Bq for ; Mon, 12 Aug 2019 15:38:32 -0700 (PDT) Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA24A120C84 for ; Mon, 12 Aug 2019 13:20:54 -0700 (PDT) Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x7CKKqkE019956 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 12 Aug 2019 16:20:52 -0400 To: rum@ietf.org References: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net> <64B406DC-4171-41EB-9171-A2AF7B78B409@brianrosen.net> From: Paul Kyzivat Message-ID: Date: Mon, 12 Aug 2019 16:20:51 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <64B406DC-4171-41EB-9171-A2AF7B78B409@brianrosen.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Rum] Codec requirements in draft-rosen-rue-01 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 22:38:34 -0000 draft-rosen-rue-01 changes the video codec requirements. It now simply references webrtc RFC7742. RFC7742 distinguishes three types of endpoints: "WebRTC browser", "WebRTC non-browser", and "WebRTC-compatible endpoint". AFAIK it assumes that each end is one of these. Is the expectation here that both the RUE and the provider comply with one of these? In particular, that the provider may simply be a "WebRTC-compatible endpoint? Notably: "WebRTC-compatible endpoints" are free to implement any video codecs they see fit. This follows logically from the definition of "WebRTC- compatible endpoint". It is, of course, advisable to implement at least one of the video codecs that is mandated for WebRTC browsers, and implementors are encouraged to do so. Similarly, the audio requirements have been changed to reference webrtc RFC7874. That one doesn't have the distinction between "WebRTC browser", "WebRTC non-browser", and "WebRTC-compatible endpoint". It applies the same requirements to all. In particular, it requires OPUS support. I don't know why it doesn't make the same endpoint distinctions as for video. I think simply referencing these documents isn't sufficient. Seems like we need a more nuanced specification of what is required, though we may still reference these docs with qualifications. Thanks, Paul From nobody Mon Aug 12 23:45:59 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C311012008C for ; Mon, 12 Aug 2019 23:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nqJ6hRCboec for ; Mon, 12 Aug 2019 23:45:53 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FA79120077 for ; Mon, 12 Aug 2019 23:45:51 -0700 (PDT) Received: from haworthia-20.webway.org (h-205-16.A165.corp.bahnhof.se [176.10.205.16]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 029F12182; Tue, 13 Aug 2019 08:45:47 +0200 (CEST) From: "Olle E. Johansson" Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_924E6295-320B-4A53-A6A9-3934961ABBF0" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 13 Aug 2019 08:45:47 +0200 In-Reply-To: <64B406DC-4171-41EB-9171-A2AF7B78B409@brianrosen.net> Cc: Olle E Johansson , rum@ietf.org To: Brian Rosen References: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net> <64B406DC-4171-41EB-9171-A2AF7B78B409@brianrosen.net> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Rum] Let's get into it X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2019 06:45:59 -0000 --Apple-Mail=_924E6295-320B-4A53-A6A9-3934961ABBF0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 7 Aug 2019, at 23:14, Brian Rosen wrote: >=20 > Working on these comments. I submitted a new version (-01) >=20 > I edited the doc to say the client cert is provisioned. Given that = it=E2=80=99s provisioned by the entity that the provides the server, do = I need to say anything else about validating the cert? I would encourage that to get some base level of interoperability.=20 >=20 > I=E2=80=99m fine with requiring support for SIP-over-websockets = (RFC7118), but is that a general goodness these days? I just noted that it was excluded. Adding it will certainly help = implementations that want to use WebRTC. >=20 > The general requirements require TLS for SIP, so I don=E2=80=99t think = I need anything else for telephone number privacy, right? The phone numbers will end up in log files, in all kind of middle boxes. = TLS is no guarantee of privacy any more, if it ever was. My general experience is that is a bad identifier in SIP as phone = numbers seldom are permanent and people by law has the right to have hidden phone numbers. You want a more permanent = identifier. >=20 > 6.2.1 says =E2=80=9CRoute headers MAY be included in one-stage = dial-around calls and emergency calls.=E2=80=9D 6.2.2 is one-stage-dial = around, so it fits the exception for the SHOULD. ok >=20 > I added the reference to RFC6351 for xCard. =20 ok > I think we should have a discussion of whether this mechanism should = be retained. The purpose was to deal with an objection from providers = that if they supported this interface, anyone could download some random = code claiming to meet it, and they wouldn=E2=80=99t have a clue where it = came from or a way to contact anyone if it didn=E2=80=99t behave. As = you point out, there isn=E2=80=99t any way for the server to put any = trust in the data. The requirement for TLS covers eavesdropping, but it = still could obtain PII. I left the text for now, but we should discuss. >=20 > You said =E2=80=9CThe proxy is found using DNS and may be a list = created from NATPR/DNS SRV records. What is the defintion of =E2=80=9Cthe = proxy=E2=80=9D in this statement?=E2=80=9D, It seems obvious to me that = the proxy URI is found in the configuration and the SRV resolves to an = IP address (or addresses). What is unclear? Usually you start with a name that by using DNS can resolve into many = proxys. you don=E2=80=99t configure =E2=80=9Ca proxy=E2=80=9D in SIP, = you configure a SIP domain and end up with =E2=80=9Cthe proxy=E2=80=9D. = That=E2=80=99s two dfferent things. Your text bypasses the DNS = NAPTR/SRV resolution by indicating that =E2=80=9Cthe proxy=E2=80=9D = should be configured, which I don=E2=80=99t think is a good thing. And since you write about incoming calls, the problem gets worse, sincie = your device may end up with one proxy and get incominig calls from = another, unless you force it by using SIP Outbound. Wiith SIP Outbound the proxy has to use the = incominig connection, which I think is a good thing. >=20 > Simultaneous ring is a pretty well known thing, which I think everyone = does with parallel fork in one form or another. There is only two MUSTs = for the server (if there are multiple registrations, ring them all, and = CANCEL any ringing UAs that didn=E2=80=99t answer). 3261 doesn=E2=80=99t = discuss CANCEL when forking and I don=E2=80=99t see where we say = anything that could be construed as violating anything I can see in = 3261. I=E2=80=99m at a loss to understand what I should change. Implementers may think that by writing something that is obvious in 3261 = you may have changed something. You may add a disclaimer saying =E2=80=9Ct= his is just a clarification, not normative text=E2=80=9D. >=20 > The reference to OUTBOUND also confuses me. Yeah, you could get some = forking when following Outbound, but that wouldn=E2=80=99t change this = fork of independent registered UAs would it? What text suggestion do = you have? I=E2=80=99m very happy to clarify anything unclear, but I = don=E2=80=99t see the problem yet. As most programmers doesn=E2=80=99t have experience of SIP Outbound it = may not be clear that when using outbound there will be a combination of = parallell and serial forking. Parallell on the various registrations, = serial in the various reg-id registrations from the same device. >=20 > I added the RFC references to REFER, and included the 7647 update as = well as explicit support for norefersub, ok >=20 > Could we have a discussion of whether we require support for IPv4. I = think we do, but are their other opinions? I fixed =E2=80=9Cdomain = part=E2=80=9D. What is the problem you are trying to solve by adding this requirement? >=20 > I replaced the media and SRTP sections with references to the WebRTC = media specifications. There is a significant problem where there are = existing endpoints that simply can=E2=80=99t be upgraded to support SRTP = video. This may be less of a problem if the systems that support those = endpoints anchor media in their SBCs. If you switich to WebRTC you are also adding AVPF which is not = compatible with most SIP devices. Some sort of b2bua will be required = for legacy interop. >=20 > The example operator URI in Section 11.1 doesn=E2=80=99t contain a = number-which-is-not-an-E164, and thus doesn=E2=80=99t need = user=3Ddialstring. ok /O >=20 >=20 >=20 >> On Jul 10, 2019, at 6:28 AM, Olle E. Johansson > wrote: >>=20 >>=20 >>=20 >>> On 9 Jul 2019, at 21:48, Brian Rosen > wrote: >>>=20 >>> Please comment on anything. >>=20 >> Section 5: >>=20 >> "Both HTTPS and all SIP Transactions MUST use TLS 1.2=E2=80=9D >>=20 >> =E2=80=9CTransactions=E2=80=9D doesn=E2=80=99t work well here. = =E2=80=9CConnections=E2=80=9D would be better. >> Instead of hard-coding a specific version of TLS you may want to = point to the BCP by the UTA wg, >> unless you anyway will update this profile from time to time. >>=20 >> " During the establishment of secure connections with a provider, the >> RUE MAY be asked by the server for a client certificate. In that >> case it SHOULD provide a client certificate. Providers MAY reject >> requests that fail to provide a recognized certificate.=E2=80=9D >>=20 >> What=E2=80=99s in the client cert? How do you validate the client = certs? >>=20 >> Section 6 doesn=E2=80=99t mentionSIP over WebSockets. I assume that = would apply. >>=20 >>=20 >> Since you are using phone numbers as identifiers, I from an EU = standpoint >> suggest disallowing all non-secure transports. Phone numbers are=20 >> considered personal identifiers and are affected by the EU GDPR. >>=20 >>=20 >> Section 6.2.1 forbids Route headers in initial INVITE requests. The = example >> in 6.2.2 has a very visible Route: header in the initial request. >>=20 >> Section 6.2.3 talks about an xCard without any references or comments >> about trust for that information. >>=20 >> Section 6.2.4: >>=20 >> "The RUE MUST accept inbound calls sent to it by the proxy mentioned >> in the configuration.=E2=80=9D >>=20 >> The proxy is found using DNS and may be a list created from NATPR/DNS = SRV >> records. What is the defintion of =E2=80=9Cthe proxy=E2=80=9D in this = statement? >>=20 >> "If Multiple simultaneous RUE SIP registrations from different RUE >> devices with the same SIP URI exist, the Provider MUST parallel = fork the call to all registered RUEs so that they ring at the same = time. >> The first RUE to reply with a 200 OK answers the call and the >> Provider MUST CANCEL other call branches. >> " >> Is this normative (you have many MUST here). If so - how does this >> change the behaviour of RFC 3261? >> Also, I think this texts forgets about SIP outbound. Since Outbound = is a MUST, >> you need to clarify the mix of parallell and serial forking that will = happen. >>=20 >>=20 >> Section 6.3: >>=20 >> "The RUE MUST support REFER to enable call transfer.=E2=80=9C >>=20 >> Which combination of REFER? I assume that =E2=80=9CMid call = signaling=E2=80=9D is =E2=80=9Cin-dialog transactions=E2=80=9D in SIP = lingo, >> but REFER with or without Replaces? With or without subscription for = updates? >>=20 >> Section 6.4: >>=20 >> " Relay Service URIs and User Address of Records (AoR) MUST resolve = (in >> accord with [RFC3263 ]) to = globally routable IPv4 addresses. The AoRs >> MAY also resolve to IPv6 addresses.=E2=80=9D >>=20 >> How do you resolve a complete URI into an IP address? I guess you = mean >> the domain part that resolves to a list of addresses using DNS. >> Why is IPv4 a MUST? >>=20 >> Section 8: >>=20 >> "All media streams between the RUE and another endpoint or relay >> Provider MUST be exchanged using the secure real-time transport >> protocol (SRTP) [RFC3550 ] = using DTLS [RFC5763 ], [RFC5764 = ], except >> that for backwards compatibility with older video endpoints, RTP = MAY >> be negotiated if SRTP negotiation fails. >> =E2=80=9C >>=20 >> How do you handle the risk of downgrade attacks here? That exception = is dangerous >> and maybe should be handled elsewhere, not in the client.=20 >>=20 >>=20 >> Section 11.1 >>=20 >> The example operator URI for red.example.net = seems to lack =E2=80=9C;user=3Ddialstring=E2=80=9D= >>=20 >> Section 11.2 >>=20 >> "outbound-proxies: (OPTIONAL) A list of URIs of SIP proxies to be >> used when sending requests to the Provider. Multiple URIs >> identify alternative (redundant) paths to the Provider. >> =E2=80=9C >>=20 >> Outbound proxy is of course something you look up in DNS to get the = list of >> actual servers. Is there a need to have an additional list in this = json format? >>=20 >> " ice-servers=E2=80=9D - propably a bad name. I don=E2=80=99t = remember seeing =E2=80=9Cice server=E2=80=9D as a term. >> As turn servers are also STUN servers, I think =E2=80=9Cturn-servers=E2= =80=9D is better. >>=20 >> =E2=80=9Ccredentials=E2=80=9D: This is tricky indeed. Sending = credentials in clear text like this, >> even if it=E2=80=99s over HTTPS is an interesting approach in this = age and time. >> Regardless of that, make sure you consider OAuth/OpenID connect auth >> for some services. >>=20 >> =E2=80=9Clifetime=E2=80=9D:; You are really not clear on what happens = when the configuration >> expires. Is the RUE forbidden to use anything here? What about = emergency calls >> - will they work even without configuration? >>=20 >> General: >>=20 >> You do not mention bundling of RTP streams, which may be beneficial = here. >>=20 >> Good work! >>=20 >> /O >>=20 >>=20 >>=20 >>=20 >>=20 >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum --Apple-Mail=_924E6295-320B-4A53-A6A9-3934961ABBF0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 7 Aug 2019, at 23:14, Brian Rosen <br@brianrosen.net> = wrote:

Working on these comments.  I submitted a new version = (-01)

I edited the = doc to say the client cert is provisioned.  Given that it=E2=80=99s = provisioned by the entity that the provides the server, do I need to say = anything else about validating the cert?
I would encourage that to get some base level of = interoperability. 

I=E2=80=99m fine with requiring support for = SIP-over-websockets (RFC7118), but is that a general goodness these = days?
I just noted that it was excluded. Adding it will certainly = help implementations that want to use WebRTC.


The general requirements = require TLS for SIP, so I don=E2=80=99t think I need anything else for = telephone number privacy, = right?
The phone numbers will end up in log files, in all kind of = middle boxes. TLS is no guarantee of privacy any more, if it ever = was.
My general experience is that is a bad identifier in SIP = as phone numbers seldom are permanent and people by law has = the
right to have hidden phone numbers. You want a more = permanent identifier.


6.2.1 says =E2=80=9CRoute headers MAY be included in = one-stage dial-around calls and emergency calls.=E2=80=9D  6.2.2 is = one-stage-dial around, so it fits the exception for the = SHOULD.
<= /blockquote>ok

I added = the reference to RFC6351 for xCard. =  
ok
I think we should have a discussion of = whether this mechanism should be retained.  The purpose was to deal = with an objection from providers that if they supported this interface, = anyone could download some random code claiming to meet it, and they = wouldn=E2=80=99t have a clue where it came from or a way to contact = anyone if it didn=E2=80=99t behave.  As you point out, there = isn=E2=80=99t any way for the server to put any trust in the data. =  The requirement for TLS covers eavesdropping, but it still could = obtain PII.  I left the text for now, but we should = discuss.

You = said =E2=80=9CThe proxy is found using DNS and may be a list created = from NATPR/DNS SRV records. What is the defintion of =E2=80=9Cthe = proxy=E2=80=9D in this statement?=E2=80=9D,  It seems obvious to me = that the proxy URI is found in the configuration and the SRV resolves to = an IP address (or addresses).  What is = unclear?
=
Usually you start with a name that by using DNS can resolve = into many proxys. you don=E2=80=99t configure =E2=80=9Ca proxy=E2=80=9D = in SIP, you configure a SIP domain and end up with =E2=80=9Cthe = proxy=E2=80=9D. That=E2=80=99s two dfferent things. Your text bypasses = the DNS  NAPTR/SRV resolution by indicating that =E2=80=9Cthe = proxy=E2=80=9D should be configured, which I don=E2=80=99t think is a = good thing.
And since you write about incoming calls, the = problem gets worse, sincie your device may end up with one proxy and get = incominig calls from another, unless you force
it by using SIP = Outbound. Wiith SIP Outbound the proxy has to use the incominig = connection, which I think is a good thing.


Simultaneous ring is a = pretty well known thing, which I think everyone does with parallel fork = in one form or another.  There is only two MUSTs for the server (if = there are multiple registrations, ring them all, and CANCEL any ringing = UAs that didn=E2=80=99t answer). 3261 doesn=E2=80=99t discuss CANCEL = when forking and I don=E2=80=99t see where we say anything that could be = construed as violating anything I can see in 3261.  I=E2=80=99m at = a loss to understand what I should = change.
<= /blockquote>Implementers may think that by writing something that is = obvious in 3261 you may have changed something. You may add a disclaimer = saying =E2=80=9Cthis is just a clarification, not normative text=E2=80=9D.=

The reference to = OUTBOUND also confuses me.  Yeah, you could get some forking when = following Outbound, but that wouldn=E2=80=99t change this fork of = independent registered UAs would it?  What text suggestion do you = have?  I=E2=80=99m very happy to clarify anything unclear, but I = don=E2=80=99t see the problem = yet.
As most programmers doesn=E2=80=99t have experience of SIP = Outbound it may not be clear that when using outbound there will be a = combination of parallell and serial forking. Parallell on the various = registrations, serial in the various reg-id registrations from the same = device.

I added = the RFC references to REFER, and included the 7647 update as well as = explicit support for = norefersub,
ok

Could we = have a discussion of whether we require support for IPv4.  I think = we do, but are their other opinions?  I fixed =E2=80=9Cdomain = part=E2=80=9D.
=
What is the problem you are trying to solve by adding = this requirement?

I = replaced the media and SRTP sections with references to the WebRTC media = specifications.  There is a significant problem where there are = existing endpoints that simply can=E2=80=99t be upgraded to support SRTP = video.  This may be less of a problem if the systems that support = those endpoints anchor media in their = SBCs.
If you switich to WebRTC you are also adding AVPF which is not = compatible with most SIP devices. Some sort of b2bua will be required = for legacy interop.

The example operator URI in Section 11.1 doesn=E2=80=99t = contain a number-which-is-not-an-E164, and thus doesn=E2=80=99t need = user=3Ddialstring.
ok

/O



On Jul = 10, 2019, at 6:28 AM, Olle E. Johansson <oej@edvina.net> = wrote:



On 9 Jul 2019, at 21:48, Brian Rosen <br@brianrosen.net> = wrote:

Please comment on = anything.

Section 5:

"Both HTTPS and all = SIP Transactions MUST use TLS 1.2=E2=80=9D

=E2=80=9CTransactions=E2=80=9D = ;doesn=E2=80=99t work well here. =E2=80=9CConnections=E2=80=9D = would be better.
Instead of hard-coding a specific version of TLS you may want = to point to the BCP by the UTA wg,
unless you anyway will update this profile from = time to time.

" During the establishment of secure connections with a = provider, the
   RUE MAY be asked by the server for a client certificate.  In =
that
   case it SHOULD provide a client certificate.  Providers MAY reject
   requests that fail to provide a recognized certificate.=E2=80=9D
<= pre class=3D"newpage" style=3D"font-size: 13.333333015441895px; = margin-top: 0px; margin-bottom: 0px; break-before: page;">
What=E2=80=99s in the client cert? How do you validate the client =
certs?

Section 6 doesn=E2=80=99t mentionSIP over WebSockets. I assume =
that would apply.


Since you are using phone numbers as identifiers, I from an EU =
standpoint
suggest disallowing all non-secure transports. Phone numbers are =

considered =
personal identifiers and are affected by the EU GDPR.


Section 6.2.1 forbids =
Route headers in initial INVITE requests. The example
in 6.2.2 has a very =
visible Route: header in the initial request.

Section 6.2.3 talks about =
an xCard without any references or comments
about trust for that =
information.

Section 6.2.4:

"The RUE MUST accept inbound calls sent to it by the proxy =
mentioned
   in the configuration.=E2=80=9D

The proxy is found using =
DNS and may be a list created from NATPR/DNS SRV
records. What is the =
defintion of =E2=80=9Cthe proxy=E2=80=9D in this statement?

"If Multiple simultaneous =
RUE SIP registrations from different RUE
   devices with the same SIP =
URI exist, the Provider MUST parallel fork   the call to all registered =
RUEs so that they ring at the same time.

   The first =
RUE to reply with a 200 OK answers the call and the
   Provider MUST CANCEL other call branches.
"
Is this normative (you have many MUST here). If so - how does =
this
change the behaviour of RFC 3261?
Also, I think this texts =
forgets about SIP outbound. Since Outbound is a MUST,
you need to clarify the =
mix of parallell and serial forking that will happen.


Section 6.3:

"The RUE MUST support   =
REFER to enable call transfer.=E2=80=9C

Which combination of REFER? I assume = that =E2=80=9CMid call signaling=E2=80=9D is =E2=80=9Cin-dialog = transactions=E2=80=9D in SIP lingo,
but REFER with = or without Replaces? With or without subscription for updates?

Section 6.4:

" Relay Service URIs and User Address = of Records (AoR) MUST resolve (in
   accord with [RFC3263]) to globally routable IPv4 addresses.  The AoRs
   MAY also resolve to IPv6 addresses.=E2=80=9D

How do you resolve a =
complete URI into an IP address? I guess you mean
the domain part that =
resolves to a list of addresses using DNS.
Why is IPv4 a MUST?

Section 8:

"All media streams between =
the RUE and another endpoint or relay
   Provider MUST be exchanged =
using the secure real-time transport
   protocol (SRTP) [RFC3550] using DTLS [RFC5763], [RFC5764], except
   that for backwards compatibility with older video endpoints, RTP MAY
   be negotiated if SRTP negotiation fails.
=E2=80=9C

How do you handle the risk of downgrade attacks here? That = exception is dangerous
and maybe should be handled = elsewhere, not in the client. 


Section 11.1

The example operator URI for red.example.net seems= to lack =E2=80=9C;user=3Ddialstring=E2=80=9D

Section 11.2

"outbound-proxies: (OPTIONAL) A list of = URIs of SIP proxies to be
      used when sending =
requests to the Provider.  Multiple URIs
      identify alternative (redundant) paths to the Provider.
=E2=80=9C

Outbound proxy is of course something you look up in DNS to = get the list of
actual servers. Is there a need to = have an additional list in this json format?

" = ice-servers=E2=80=9D - propably a bad name. I don=E2=80=99t remember = seeing =E2=80=9Cice server=E2=80=9D as a term.
As turn servers are also STUN = servers, I think =E2=80=9Cturn-servers=E2=80=9D is = better.

=E2=80=9Ccredentials=E2=80=9D: This is tricky indeed. Sending = credentials in clear text like this,
even if it=E2=80=99s over HTTPS is an interesting = approach in this age and time.
Regardless of that, make sure you consider = OAuth/OpenID connect auth
for some services.

=E2=80=9Clifetime=E2=80=9D:; You are really not clear on what = happens when the configuration
expires. Is the RUE forbidden to use anything = here? What about emergency calls
- will they work even without = configuration?

General:

You do not mention bundling of = RTP streams, which may be beneficial here.

Good work!

/O






-- =
Rum mailing list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum

= --Apple-Mail=_924E6295-320B-4A53-A6A9-3934961ABBF0-- From nobody Tue Aug 27 06:52:32 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD9D120047 for ; Tue, 27 Aug 2019 06:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7TfdDvdcZQBB for ; Tue, 27 Aug 2019 06:52:27 -0700 (PDT) Received: from bin-mail-out-05.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2524212007A for ; Tue, 27 Aug 2019 06:52:26 -0700 (PDT) X-Halon-ID: e51d696c-c8d1-11e9-903a-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [88.129.173.120]) by bin-vsp-out-02.atm.binero.net (Halon) with ESMTPSA id e51d696c-c8d1-11e9-903a-005056917f90; Tue, 27 Aug 2019 15:52:23 +0200 (CEST) To: rum@ietf.org From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <9a14addd-9a1c-6130-3880-a814be717323@omnitor.se> Date: Tue, 27 Aug 2019 15:52:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Rum] Real-time text in WebRTC is discussed in mmusic - a topic closely telated to rum X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 13:52:30 -0000 Hi, A topic is currently discussed in mmusic that is closely related to rum. it is WebRTC transport of real-time text. The draft is draft-holmberg-mmusic-t140-usage-data-channel . A good point to start reading could be: https://mailarchive.ietf.org/arch/browse/mmusic/?gbt=1&q=draft-holmberg-mmusic-t140-usage-data-channel Please check if the current state of the discussion suits rum! The only issue that seems to be remaining is how to transport RTT data to and from a conference server that combines all traffic per media in a meeting in one data stream. That is not very elegantly specified for RFC 4103 transport of RTT in RTP either, so we might want to do a rapid action together to solve the multi-party RTT MCU case in a general and consistent way. Regards Gunnar -- ----------------------------------------- Gunnar Hellstrm Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Tue Aug 27 12:32:19 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDAAB120089 for ; Tue, 27 Aug 2019 12:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7-vmxJB9obk for ; Tue, 27 Aug 2019 12:32:14 -0700 (PDT) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 579CD120828 for ; Tue, 27 Aug 2019 12:32:14 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id f10so219662qkg.7 for ; Tue, 27 Aug 2019 12:32:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7ox1yFl6IDIS7FzxWgPH6tsTYdS56/bA7Ag5QCzOJFY=; b=V8/+f8uM521qbSq84K/QXYKZZ4UQOsRgq9Q+k5IwP/pX3d9OGB4stK3QsBcG/1yNs+ eGxp1m7350e+L9ggnIvaAygI+51KNPEiq6LT5cS89FPQ/N88O+DJT5Mmib4bCdj0Y25v nvWy2aKvtUejQnLpIy2mhb9HZv3O126p4FU2w8D+CjK/jOLMr34kWctcGxhI9J+g9l4J mZkU9wfbaXuJqoE4+5h1cfLqimQsLrI+Evxp4aS8koX/PiMp1EDJG/0QufPA4lOeaW34 Py6ZU5yhkvuIogfYRhST34mYvxJrFH6+yIB8kHxw2T1FskXmvEDiXf+v03m0m1T+h4ln gsqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7ox1yFl6IDIS7FzxWgPH6tsTYdS56/bA7Ag5QCzOJFY=; b=BodHkLyJfjxQeEAIdFeFkF3SfH6jWyo3c0Y+bIw8JTuUIkughK+aT8nFo/NzZLmJpp ehU/rKMs17paz6jPtpeffQHmGk9bEI4utUKoeNK+GofFdgaVufuX/0YYvE9tnfUNJNjT BCK5xJhVDX+/OaoQf3kT0fgFfa5B/0Sg0lxzzewLJ+RPXIXsUeMrLkDrCdOwoT9o7IVV 5+VQAd3ziQchFGRA4PVm9qc1PIA9Y9PTk9y2H1h8JvaaGHbzt7mTWfShIklhVKfAvOgu Ulw1OhPsvkRDVoj6/1BIckapInVPwckhrBFPkNnfEbXsXhfiXrHJ0pxeh3/QJV/ytMXQ 59XA== X-Gm-Message-State: APjAAAXs7+bVj+yttQDj6hlh/1ynWnvSmhIUDrw3vvlnpW9GME6X+SWK UX3rT8vsmGPLNh30CLMd7IByPg== X-Google-Smtp-Source: APXvYqwQT5MS1MC4t6UcJiT0zIeRV07as8gmZzqnDx1rpjaH3iDHvMh30V3S3g4BEba2s1Xnpix26g== X-Received: by 2002:a37:e10f:: with SMTP id c15mr130819qkm.219.1566934333276; Tue, 27 Aug 2019 12:32:13 -0700 (PDT) Received: from brians-mbp-2369.lan ([24.154.122.195]) by smtp.gmail.com with ESMTPSA id 143sm161777qkl.114.2019.08.27.12.32.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Aug 2019 12:32:12 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Brian Rosen In-Reply-To: <054dde2a-7fa1-9941-986c-f3b3d8c0f76e@alum.mit.edu> Date: Tue, 27 Aug 2019 15:32:11 -0400 Cc: rum@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <831AD5BE-0D8F-4968-ABC7-B8D52BB8D4B0@brianrosen.net> References: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net> <64B406DC-4171-41EB-9171-A2AF7B78B409@brianrosen.net> <054dde2a-7fa1-9941-986c-f3b3d8c0f76e@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Rum] RUE client credentials X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 19:32:17 -0000 Getting back to this, sorry for the delay. > On Aug 12, 2019, at 3:40 PM, Paul Kyzivat = wrote: >=20 > On 8/7/19 5:14 PM, Brian Rosen wrote: >> Working on these comments. I submitted a new version (-01) >> I edited the doc to say the client cert is provisioned. Given that = it=E2=80=99s provisioned by the entity that the provides the server, do = I need to say anything else about validating the cert? >=20 > I think we need to examine what the goal is here, and whether it is = being achieved. I don't think enough is said to decide. >=20 > This client cert mechanism was first added way back when (2015 I = think). IIRC, the motivation was because the providers wanted to = restrict access to RUE *implementations* that have passed = interoperability testing, in order to reduce the problems of dealing = with buggy implementations or attackers. I think you are confusing validating an implementation from = authenticating a user. The notion of mutual auth with a per-device cert = is completely separate from some notion of =E2=80=9Csigning=E2=80=9D an = implementations code. We can decide we don=E2=80=99t want the option of having mutual auth. >=20 > The idea was that certs would only be made available to = *implementations* (e.g. images) that have been tested. There was no = expectation that each user who obtains a rue would need to have it = tested. >=20 > But the exact mechanism for binding a cert to a tested implementation = was never worked out. I've asked around from time to time and I haven't = learned of any way to achieve this. >=20 > Brian's new text pushes this off one level but doesn't solve the = problem. The provider's *sip* server can perhaps trust that the rue got = the cert from the provider's provisioning server. But the provisioning = server still has to decide if this is a trustworthy implementation. >=20 > The Apple store and the Google Play Store solve this problem by being = the distributor of apps. The developer has to submit the app, which is = then tested/verified by the store and then being assigned credentials. = Potentially we could have something list that by having a RUE Store = operated by a RUE testing authority. But I don't think anybody is = prepared to operate such a thing and it would require the devices = receiving these apps to bypass the normal vendor restrictions on = installations. >=20 > I don't have a good answer here. >=20 > Thanks, > Paul >=20 >=20 From nobody Tue Aug 27 12:34:51 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A36012012E for ; Tue, 27 Aug 2019 12:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irpcOj3HJZgi for ; Tue, 27 Aug 2019 12:34:47 -0700 (PDT) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FFF8120116 for ; Tue, 27 Aug 2019 12:34:47 -0700 (PDT) Received: by mail-qt1-x82b.google.com with SMTP id t12so208554qtp.9 for ; Tue, 27 Aug 2019 12:34:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XFUuKi9XlO/kqtOpHCmW/etxw1mtFdrlVSf+D9Y6fUo=; b=OrCBChXlmNAKlC4jTc4+AjasSlOCsJGVK6ghDksbWWql365Aaek6LfEK+eVZtR0TBF CxypG4Ribeprt7zT5OMmNz2bwgaaTpiNTbcUYf/pmXNAhU521xzXnr/+GLyiNm2cLO5X duQkI1hSm+pPb7gUDYH3giKmQ/D88MS6h0I8HYVNYQWej2gjWikFSmygbNCqB7kVr7H8 cf7gO8nx1L78JQxszzVLLgpdG6VQGranci65gQVlO022O20Fcx51coH/2lj1/MwBwimH HZQy4qbpeKuTnomsvTOqScbbBaoms9h1O5TKREE6zukr0sT6MynUQNFTLbHnPr1iNj5n LAjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XFUuKi9XlO/kqtOpHCmW/etxw1mtFdrlVSf+D9Y6fUo=; b=LAC7plkBaXKHosEbwRLcOaPr7Z4czZnP3jfbk5G+lc7umcnv0Jvvw6wMFXwN/i2Sg/ jCzMqT5uTiui+pYESmA7P/NWSa2qqilA4pec2UDtqyMJLaG1LnnXT6x44FuoRz66IocG Q+mSRTu43XPPQ1T69ONXjZGPE+MYZIpHiUf3nxx/Bc+qNEkOg692r46NZFjL4HmWqQCS UE76fpxxoBoOchjflBViVqSe+Htc3n1hicgwzaLWFud/6IL+dSeTEZbLp/Ov3Kg9mZji nooDMtIjDlvP3NsejzwCOvN5Y5cezbDX3i8k6wkntMAKJ9x0cGIwBV1KTtUbelOJDKoR d//w== X-Gm-Message-State: APjAAAW22AfNGFGupyYCNPFIL5yC/j80FrRehyCLQQWm4yse0CescZ98 gI9j8At/HDeEiyiH6Qgd+mUEJQ== X-Google-Smtp-Source: APXvYqw7TQS8Pn/pAcCbyf/U4n6ti1L0ZqcsjlTbwbpCujrQ6gjAj2zzc1WtgcSGSkBqre7JGiLZ9Q== X-Received: by 2002:ac8:73c7:: with SMTP id v7mr508953qtp.9.1566934486328; Tue, 27 Aug 2019 12:34:46 -0700 (PDT) Received: from brians-mbp-2369.lan ([24.154.122.195]) by smtp.gmail.com with ESMTPSA id g13sm17755qtp.21.2019.08.27.12.34.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Aug 2019 12:34:45 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Brian Rosen In-Reply-To: Date: Tue, 27 Aug 2019 15:34:45 -0400 Cc: rum@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <69F15B2A-0158-4D23-B090-642497E3BDC7@brianrosen.net> References: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net> <64B406DC-4171-41EB-9171-A2AF7B78B409@brianrosen.net> To: Paul Kyzivat , Adam Roach X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 19:34:50 -0000 Well, we certainly want interoperability, and I think we can only get = that with MTI codecs. I think we really are talking about a WebRTC-compatible endpoint, but we = want interoperability with a WebRTC browser endpoint. Not sure how to say this. Maybe Adam can help. Brian > On Aug 12, 2019, at 4:20 PM, Paul Kyzivat = wrote: >=20 > draft-rosen-rue-01 changes the video codec requirements. It now simply = references webrtc RFC7742. >=20 > RFC7742 distinguishes three types of endpoints: "WebRTC browser", = "WebRTC non-browser", and "WebRTC-compatible endpoint". AFAIK it assumes = that each end is one of these. >=20 > Is the expectation here that both the RUE and the provider comply with = one of these? In particular, that the provider may simply be a = "WebRTC-compatible endpoint? Notably: >=20 > "WebRTC-compatible endpoints" are free to implement any video codecs > they see fit. This follows logically from the definition of = "WebRTC- > compatible endpoint". It is, of course, advisable to implement at > least one of the video codecs that is mandated for WebRTC browsers, > and implementors are encouraged to do so. >=20 > Similarly, the audio requirements have been changed to reference = webrtc RFC7874. That one doesn't have the distinction between "WebRTC = browser", "WebRTC non-browser", and "WebRTC-compatible endpoint". It = applies the same requirements to all. In particular, it requires OPUS = support. I don't know why it doesn't make the same endpoint distinctions = as for video. >=20 > I think simply referencing these documents isn't sufficient. Seems = like we need a more nuanced specification of what is required, though we = may still reference these docs with qualifications. >=20 > Thanks, > Paul >=20 >=20 From nobody Tue Aug 27 12:45:26 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D827120113 for ; Tue, 27 Aug 2019 12:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nfmjj0E70JrD for ; Tue, 27 Aug 2019 12:45:18 -0700 (PDT) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CE3D1200FF for ; Tue, 27 Aug 2019 12:45:18 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id l9so262797qtu.6 for ; Tue, 27 Aug 2019 12:45:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=AuWROjL/HhH8wTZnRnTq79QliCy17i2qjVMscdY3+Z0=; b=NeAyw2NU4ifPaHnYX4DfmlCIqLCHoFWqMdVgbc+apMC4UuKIrCSLnTlk8rhxxULwmb ft3Od6PUehHvuswnNLR4F9ocS700DzT0yS2z7hT516qOVbHV2ZMNkst/WLp/n+Os8/N6 f1guMCdwN4dMAmUr0plosyYVzzSl3gtOya9qTmqNBqtucWRw4kHYxcf2CuAL3wAtEyGU MhwuU6+PlvmX0hSb5jlI+Jx0ItzeN6xRbtUjFr5Q6PLg7wKUAvtd2vKx+e6G9w+6yzje XLXVtppbQ53wvmZROJjFVjhWD/Ymf0D3bzMeIwvBRe5nJv1mdmDXcBRQgP326itDKw57 cQcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=AuWROjL/HhH8wTZnRnTq79QliCy17i2qjVMscdY3+Z0=; b=YOFWtVSB86Tee0/anQCOpvasGJLnJYS67UEYBmQ5hJhe3DEDEEU78Jy7vNPSwVx7Tn Dis1DxK+UcfErLnQrxdF6P59Zh4oO81C9/CvCMb5cOHmqzcKYT0XnX6+9vW6ACnrU+my WORxCju5z2FESQJdYTaCOoUhlCKjvzGSmddnKI8pTiw4QLtud+5ZUUvrt8UcGt9cMzSo SLqYgK+PMmsFXjscYM+PCBlVICXBb9jGLnB2HlGp28MtpqrDAKiawPYCSS5AtdE0n9Lu Em9mdUMLeEDkuNnOHsCJ9qjlpexf+K2XtAMuBeZ25tbfYupECj7PVV/kKgLPmpGjrD8+ RgPQ== X-Gm-Message-State: APjAAAVdd5EvSUis86cPeyGW17zsrAJ+IvkrDnHXkUNRlofzi60z9MaR ZMxO/7qIj6g0hS59RQfpFXVG0kNSBVU= X-Google-Smtp-Source: APXvYqxA6zeKhTTiaUn1hC+fqXN6EFac35IDuhi85QfogXcAk6AO4+tFShmq/Xgivo2/8vNmd+9Acg== X-Received: by 2002:ac8:6b93:: with SMTP id z19mr598938qts.48.1566935117131; Tue, 27 Aug 2019 12:45:17 -0700 (PDT) Received: from brians-mbp-2369.lan ([24.154.122.195]) by smtp.gmail.com with ESMTPSA id s3sm205232qkc.57.2019.08.27.12.45.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Aug 2019 12:45:16 -0700 (PDT) From: Brian Rosen Message-Id: <93ABEC0D-9B2D-42BC-A337-1602464F0CB7@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_4248C2AC-09BB-40A2-BF40-90E0D9936134" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 27 Aug 2019 15:45:15 -0400 In-Reply-To: Cc: rum@ietf.org To: "Olle E. Johansson" References: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net> <64B406DC-4171-41EB-9171-A2AF7B78B409@brianrosen.net> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Rum] Let's get into it X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 19:45:24 -0000 --Apple-Mail=_4248C2AC-09BB-40A2-BF40-90E0D9936134 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 13, 2019, at 2:45 AM, Olle E. Johansson wrote: >=20 >=20 >=20 >> On 7 Aug 2019, at 23:14, Brian Rosen > wrote: >>=20 >> Working on these comments. I submitted a new version (-01) >>=20 >> I edited the doc to say the client cert is provisioned. Given that = it=E2=80=99s provisioned by the entity that the provides the server, do = I need to say anything else about validating the cert? > I would encourage that to get some base level of interoperability.=20 See the note to Paul about whether we want to keep this option. If we = do, then what else should the doc say? >>=20 >> I=E2=80=99m fine with requiring support for SIP-over-websockets = (RFC7118), but is that a general goodness these days? > I just noted that it was excluded. Adding it will certainly help = implementations that want to use WebRTC. I=E2=80=99m getting more comfortable doing this. Any other voices for = or against? >=20 >>=20 >> The general requirements require TLS for SIP, so I don=E2=80=99t = think I need anything else for telephone number privacy, right? > The phone numbers will end up in log files, in all kind of middle = boxes. TLS is no guarantee of privacy any more, if it ever was. > My general experience is that is a bad identifier in SIP as phone = numbers seldom are permanent and people by law has the > right to have hidden phone numbers. You want a more permanent = identifier. The use here is for dialing other people by phone number. The whole VRS = system is based on that in the US. There is an ENUM based routing = directory that is used to route calls to a user with a videophone in the = system. We can add text to the security section that discusses this, = but when we have to say =E2=80=9Cworry about log files=E2=80=9D I think = we=E2=80=99re pretty far afield. Would you rather say we can=E2=80=99t = use phone numbers? I don=E2=80=99t think that would work. >=20 >>=20 >> 6.2.1 says =E2=80=9CRoute headers MAY be included in one-stage = dial-around calls and emergency calls.=E2=80=9D 6.2.2 is one-stage-dial = around, so it fits the exception for the SHOULD. > ok >>=20 >> I added the reference to RFC6351 for xCard. =20 > ok >> I think we should have a discussion of whether this mechanism should = be retained. The purpose was to deal with an objection from providers = that if they supported this interface, anyone could download some random = code claiming to meet it, and they wouldn=E2=80=99t have a clue where it = came from or a way to contact anyone if it didn=E2=80=99t behave. As = you point out, there isn=E2=80=99t any way for the server to put any = trust in the data. The requirement for TLS covers eavesdropping, but it = still could obtain PII. I left the text for now, but we should discuss. >>=20 >> You said =E2=80=9CThe proxy is found using DNS and may be a list = created from NATPR/DNS SRV records. What is the defintion of =E2=80=9Cthe = proxy=E2=80=9D in this statement?=E2=80=9D, It seems obvious to me that = the proxy URI is found in the configuration and the SRV resolves to an = IP address (or addresses). What is unclear? > Usually you start with a name that by using DNS can resolve into many = proxys. you don=E2=80=99t configure =E2=80=9Ca proxy=E2=80=9D in SIP, = you configure a SIP domain and end up with =E2=80=9Cthe proxy=E2=80=9D. = That=E2=80=99s two dfferent things. Your text bypasses the DNS = NAPTR/SRV resolution by indicating that =E2=80=9Cthe proxy=E2=80=9D = should be configured, which I don=E2=80=99t think is a good thing. > And since you write about incoming calls, the problem gets worse, = sincie your device may end up with one proxy and get incominig calls = from another, unless you force > it by using SIP Outbound. Wiith SIP Outbound the proxy has to use the = incominig connection, which I think is a good thing. Okay, I see your point. I=E2=80=99ll change the text to just talk about = the provisioned domain. >=20 >>=20 >> Simultaneous ring is a pretty well known thing, which I think = everyone does with parallel fork in one form or another. There is only = two MUSTs for the server (if there are multiple registrations, ring them = all, and CANCEL any ringing UAs that didn=E2=80=99t answer). 3261 = doesn=E2=80=99t discuss CANCEL when forking and I don=E2=80=99t see = where we say anything that could be construed as violating anything I = can see in 3261. I=E2=80=99m at a loss to understand what I should = change. > Implementers may think that by writing something that is obvious in = 3261 you may have changed something. You may add a disclaimer saying = =E2=80=9Cthis is just a clarification, not normative text=E2=80=9D. Ok >>=20 >> The reference to OUTBOUND also confuses me. Yeah, you could get some = forking when following Outbound, but that wouldn=E2=80=99t change this = fork of independent registered UAs would it? What text suggestion do = you have? I=E2=80=99m very happy to clarify anything unclear, but I = don=E2=80=99t see the problem yet. > As most programmers doesn=E2=80=99t have experience of SIP Outbound it = may not be clear that when using outbound there will be a combination of = parallell and serial forking. Parallell on the various registrations, = serial in the various reg-id registrations from the same device. Ok >>=20 >> I added the RFC references to REFER, and included the 7647 update as = well as explicit support for norefersub, > ok >>=20 >> Could we have a discussion of whether we require support for IPv4. I = think we do, but are their other opinions? I fixed =E2=80=9Cdomain = part=E2=80=9D. > What is the problem you are trying to solve by adding this = requirement? Interoperability with other endpoints, and in lots of remaining networks = and systems that don=E2=80=99t yet work without IPv4 >>=20 >> I replaced the media and SRTP sections with references to the WebRTC = media specifications. There is a significant problem where there are = existing endpoints that simply can=E2=80=99t be upgraded to support SRTP = video. This may be less of a problem if the systems that support those = endpoints anchor media in their SBCs. > If you switich to WebRTC you are also adding AVPF which is not = compatible with most SIP devices. Some sort of b2bua will be required = for legacy interop. Yeah, in a pracrucak sense the providers use SBCs, which I don=E2=80=99t = like, but it sure is common. That solves the problem. The problem with = anything else is a downgrade attack. =20 >>=20 >> The example operator URI in Section 11.1 doesn=E2=80=99t contain a = number-which-is-not-an-E164, and thus doesn=E2=80=99t need = user=3Ddialstring. > ok >=20 > /O >>=20 >>=20 >>=20 >>> On Jul 10, 2019, at 6:28 AM, Olle E. Johansson > wrote: >>>=20 >>>=20 >>>=20 >>>> On 9 Jul 2019, at 21:48, Brian Rosen > wrote: >>>>=20 >>>> Please comment on anything. >>>=20 >>> Section 5: >>>=20 >>> "Both HTTPS and all SIP Transactions MUST use TLS 1.2=E2=80=9D >>>=20 >>> =E2=80=9CTransactions=E2=80=9D doesn=E2=80=99t work well here. = =E2=80=9CConnections=E2=80=9D would be better. >>> Instead of hard-coding a specific version of TLS you may want to = point to the BCP by the UTA wg, >>> unless you anyway will update this profile from time to time. >>>=20 >>> " During the establishment of secure connections with a provider, = the >>> RUE MAY be asked by the server for a client certificate. In that >>> case it SHOULD provide a client certificate. Providers MAY = reject >>> requests that fail to provide a recognized certificate.=E2=80=9D >>>=20 >>> What=E2=80=99s in the client cert? How do you validate the client = certs? >>>=20 >>> Section 6 doesn=E2=80=99t mentionSIP over WebSockets. I assume that = would apply. >>>=20 >>>=20 >>> Since you are using phone numbers as identifiers, I from an EU = standpoint >>> suggest disallowing all non-secure transports. Phone numbers are=20 >>> considered personal identifiers and are affected by the EU GDPR. >>>=20 >>>=20 >>> Section 6.2.1 forbids Route headers in initial INVITE requests. The = example >>> in 6.2.2 has a very visible Route: header in the initial request. >>>=20 >>> Section 6.2.3 talks about an xCard without any references or = comments >>> about trust for that information. >>>=20 >>> Section 6.2.4: >>>=20 >>> "The RUE MUST accept inbound calls sent to it by the proxy mentioned >>> in the configuration.=E2=80=9D >>>=20 >>> The proxy is found using DNS and may be a list created from = NATPR/DNS SRV >>> records. What is the defintion of =E2=80=9Cthe proxy=E2=80=9D in = this statement? >>>=20 >>> "If Multiple simultaneous RUE SIP registrations from different RUE >>> devices with the same SIP URI exist, the Provider MUST parallel = fork the call to all registered RUEs so that they ring at the same = time. >>> The first RUE to reply with a 200 OK answers the call and the >>> Provider MUST CANCEL other call branches. >>> " >>> Is this normative (you have many MUST here). If so - how does this >>> change the behaviour of RFC 3261? >>> Also, I think this texts forgets about SIP outbound. Since Outbound = is a MUST, >>> you need to clarify the mix of parallell and serial forking that = will happen. >>>=20 >>>=20 >>> Section 6.3: >>>=20 >>> "The RUE MUST support REFER to enable call transfer.=E2=80=9C >>>=20 >>> Which combination of REFER? I assume that =E2=80=9CMid call = signaling=E2=80=9D is =E2=80=9Cin-dialog transactions=E2=80=9D in SIP = lingo, >>> but REFER with or without Replaces? With or without subscription for = updates? >>>=20 >>> Section 6.4: >>>=20 >>> " Relay Service URIs and User Address of Records (AoR) MUST resolve = (in >>> accord with [RFC3263 ]) to = globally routable IPv4 addresses. The AoRs >>> MAY also resolve to IPv6 addresses.=E2=80=9D >>>=20 >>> How do you resolve a complete URI into an IP address? I guess you = mean >>> the domain part that resolves to a list of addresses using DNS. >>> Why is IPv4 a MUST? >>>=20 >>> Section 8: >>>=20 >>> "All media streams between the RUE and another endpoint or relay >>> Provider MUST be exchanged using the secure real-time transport >>> protocol (SRTP) [RFC3550 ] = using DTLS [RFC5763 ], [RFC5764 = ], except >>> that for backwards compatibility with older video endpoints, RTP = MAY >>> be negotiated if SRTP negotiation fails. >>> =E2=80=9C >>>=20 >>> How do you handle the risk of downgrade attacks here? That exception = is dangerous >>> and maybe should be handled elsewhere, not in the client.=20 >>>=20 >>>=20 >>> Section 11.1 >>>=20 >>> The example operator URI for red.example.net = seems to lack =E2=80=9C;user=3Ddialstring=E2=80=9D= >>>=20 >>> Section 11.2 >>>=20 >>> "outbound-proxies: (OPTIONAL) A list of URIs of SIP proxies to be >>> used when sending requests to the Provider. Multiple URIs >>> identify alternative (redundant) paths to the Provider. >>> =E2=80=9C >>>=20 >>> Outbound proxy is of course something you look up in DNS to get the = list of >>> actual servers. Is there a need to have an additional list in this = json format? >>>=20 >>> " ice-servers=E2=80=9D - propably a bad name. I don=E2=80=99t = remember seeing =E2=80=9Cice server=E2=80=9D as a term. >>> As turn servers are also STUN servers, I think =E2=80=9Cturn-servers=E2= =80=9D is better. >>>=20 >>> =E2=80=9Ccredentials=E2=80=9D: This is tricky indeed. Sending = credentials in clear text like this, >>> even if it=E2=80=99s over HTTPS is an interesting approach in this = age and time. >>> Regardless of that, make sure you consider OAuth/OpenID connect auth >>> for some services. >>>=20 >>> =E2=80=9Clifetime=E2=80=9D:; You are really not clear on what = happens when the configuration >>> expires. Is the RUE forbidden to use anything here? What about = emergency calls >>> - will they work even without configuration? >>>=20 >>> General: >>>=20 >>> You do not mention bundling of RTP streams, which may be beneficial = here. >>>=20 >>> Good work! >>>=20 >>> /O >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >> --=20 >> Rum mailing list >> Rum@ietf.org >> https://www.ietf.org/mailman/listinfo/rum = --Apple-Mail=_4248C2AC-09BB-40A2-BF40-90E0D9936134 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Aug 13, 2019, at 2:45 AM, Olle E. Johansson <oej@edvina.net> = wrote:



On 7 Aug 2019, at 23:14, Brian = Rosen <br@brianrosen.net> wrote:

Working on these comments.  I submitted a new = version (-01)

I = edited the doc to say the client cert is provisioned.  Given that = it=E2=80=99s provisioned by the entity that the provides the server, do = I need to say anything else about validating the cert?
I would encourage that to get some base level of = interoperability. 
See the = note to Paul about whether we want to keep this option.  If we do, = then what else should the doc say?


I=E2=80=99m fine with requiring support = for SIP-over-websockets (RFC7118), but is that a general goodness these = days?
I just noted that it was excluded. Adding it will certainly = help implementations that want to use = WebRTC.
I=E2=80=99m getting more comfortable = doing this.  Any other voices for or against?



The general requirements require TLS = for SIP, so I don=E2=80=99t think I need anything else for telephone = number privacy, = right?
The phone numbers will end up in log files, in all kind of = middle boxes. TLS is no guarantee of privacy any more, if it ever = was.
My general experience is that is a bad identifier in = SIP as phone numbers seldom are permanent and people by law has = the
right to have hidden phone numbers. You want a more = permanent identifier.
The use here is for = dialing other people by phone number.  The whole VRS system is = based on that in the US.  There is an ENUM based routing directory = that is used to route calls to a user with a videophone in the system. =  We can add text to the security section that discusses this, but = when we have to say =E2=80=9Cworry about log files=E2=80=9D I think = we=E2=80=99re pretty far afield.   Would you rather say we can=E2=80=99= t use phone numbers?  I don=E2=80=99t think that would work.


6.2.1 says =E2=80=9CRoute headers MAY = be included in one-stage dial-around calls and emergency calls.=E2=80=9D =  6.2.2 is one-stage-dial around, so it fits the exception for the = SHOULD.
<= /blockquote>ok

I added = the reference to RFC6351 for xCard. =  
ok
I think we should have a discussion of = whether this mechanism should be retained.  The purpose was to deal = with an objection from providers that if they supported this interface, = anyone could download some random code claiming to meet it, and they = wouldn=E2=80=99t have a clue where it came from or a way to contact = anyone if it didn=E2=80=99t behave.  As you point out, there = isn=E2=80=99t any way for the server to put any trust in the data. =  The requirement for TLS covers eavesdropping, but it still could = obtain PII.  I left the text for now, but we should = discuss.

You = said =E2=80=9CThe proxy is found using DNS and may be a list created = from NATPR/DNS SRV records. What is the defintion of =E2=80=9Cthe = proxy=E2=80=9D in this statement?=E2=80=9D,  It seems obvious to me = that the proxy URI is found in the configuration and the SRV resolves to = an IP address (or addresses).  What is = unclear?
=
Usually you start with a name that by using DNS can resolve = into many proxys. you don=E2=80=99t configure =E2=80=9Ca proxy=E2=80=9D = in SIP, you configure a SIP domain and end up with =E2=80=9Cthe = proxy=E2=80=9D. That=E2=80=99s two dfferent things. Your text bypasses = the DNS  NAPTR/SRV resolution by indicating that =E2=80=9Cthe = proxy=E2=80=9D should be configured, which I don=E2=80=99t think is a = good thing.
And since you write about incoming calls, the problem = gets worse, sincie your device may end up with one proxy and get = incominig calls from another, unless you force
it by = using SIP Outbound. Wiith SIP Outbound the proxy has to use the = incominig connection, which I think is a good = thing.
Okay, I see your point.  I=E2=80=99ll = change the text to just talk about the provisioned domain.


Simultaneous ring is a pretty well = known thing, which I think everyone does with parallel fork in one form = or another.  There is only two MUSTs for the server (if there are = multiple registrations, ring them all, and CANCEL any ringing UAs that = didn=E2=80=99t answer). 3261 doesn=E2=80=99t discuss CANCEL when forking = and I don=E2=80=99t see where we say anything that could be construed as = violating anything I can see in 3261.  I=E2=80=99m at a loss to = understand what I should = change.
<= /blockquote>Implementers may think that by writing something that is = obvious in 3261 you may have changed something. You may add a disclaimer = saying =E2=80=9Cthis is just a clarification, not normative text=E2=80=9D.=
Ok

The reference to OUTBOUND also confuses = me.  Yeah, you could get some forking when following Outbound, but = that wouldn=E2=80=99t change this fork of independent registered UAs = would it?  What text suggestion do you have?  I=E2=80=99m very = happy to clarify anything unclear, but I don=E2=80=99t see the problem = yet.
As most programmers doesn=E2=80=99t have experience of SIP = Outbound it may not be clear that when using outbound there will be a = combination of parallell and serial forking. Parallell on the various = registrations, serial in the various reg-id registrations from the same = device.
Ok


I added the RFC references to REFER, = and included the 7647 update as well as explicit support for = norefersub,
ok

Could we = have a discussion of whether we require support for IPv4.  I think = we do, but are their other opinions?  I fixed =E2=80=9Cdomain = part=E2=80=9D.
=
What is the problem you are trying to solve by adding = this requirement?
Interoperability = with other endpoints, and in lots of remaining networks and systems that = don=E2=80=99t yet work without IPv4

I replaced the media and SRTP sections = with references to the WebRTC media specifications.  There is a = significant problem where there are existing endpoints that simply = can=E2=80=99t be upgraded to support SRTP video.  This may be less = of a problem if the systems that support those endpoints anchor media in = their = SBCs.
If you switich to WebRTC you are also adding AVPF which is not = compatible with most SIP devices. Some sort of b2bua will be required = for legacy interop.
Yeah, in a = pracrucak sense the providers use SBCs, which I don=E2=80=99t like, but = it sure is common.  That solves the problem.  The problem with = anything else is a downgrade attack.  

The example operator URI in Section = 11.1 doesn=E2=80=99t contain a number-which-is-not-an-E164, and thus = doesn=E2=80=99t need = user=3Ddialstring.
ok

/O



On Jul 10, 2019, at 6:28 AM, Olle E. = Johansson <oej@edvina.net> wrote:



On 9 Jul = 2019, at 21:48, Brian Rosen <br@brianrosen.net> wrote:

Please comment on = anything.

Section 5:

"Both HTTPS and all = SIP Transactions MUST use TLS 1.2=E2=80=9D

=E2=80=9CTransactions=E2=80=9D doesn=E2=80=99t work well = here. =E2=80=9CConnections=E2=80=9D would be = better.
Instead = of hard-coding a specific version of TLS you may want to point to the = BCP by the UTA wg,
unless you anyway will update this profile from time to = time.

" During the establishment of = secure connections with a provider, the
   RUE MAY be asked by the =
server for a client certificate.  In that
   case it SHOULD provide a client certificate.  Providers MAY reject
   requests that fail to provide a recognized certificate.=E2=80=9D
<= pre class=3D"newpage" style=3D"font-size: 13.333333015441895px; = margin-top: 0px; margin-bottom: 0px; break-before: page;">
What=E2=80=99s in the client cert? How do you validate the client =
certs?

Section 6 doesn=E2=80=99t mentionSIP over WebSockets. I assume =
that would apply.


Since you are using phone numbers as identifiers, I from an EU =
standpoint
suggest disallowing all non-secure transports. Phone numbers are =

considered =
personal identifiers and are affected by the EU GDPR.


Section 6.2.1 forbids =
Route headers in initial INVITE requests. The example
in 6.2.2 has a very =
visible Route: header in the initial request.

Section 6.2.3 talks about =
an xCard without any references or comments
about trust for that =
information.

Section 6.2.4:

"The RUE MUST accept inbound calls sent to it by the proxy =
mentioned
   in the configuration.=E2=80=9D

The proxy is found using =
DNS and may be a list created from NATPR/DNS SRV
records. What is the =
defintion of =E2=80=9Cthe proxy=E2=80=9D in this statement?

"If Multiple simultaneous =
RUE SIP registrations from different RUE
   devices with the same SIP =
URI exist, the Provider MUST parallel fork   the call to all registered =
RUEs so that they ring at the same time.

   The first =
RUE to reply with a 200 OK answers the call and the
   Provider MUST CANCEL other call branches.
"
Is this normative (you have many MUST here). If so - how does =
this
change the behaviour of RFC 3261?
Also, I think this texts =
forgets about SIP outbound. Since Outbound is a MUST,
you need to clarify the =
mix of parallell and serial forking that will happen.


Section 6.3:

"The RUE MUST support   =
REFER to enable call transfer.=E2=80=9C

Which combination of REFER? I assume = that =E2=80=9CMid call signaling=E2=80=9D is =E2=80=9Cin-dialog = transactions=E2=80=9D in SIP lingo,
but REFER with = or without Replaces? With or without subscription for updates?

Section 6.4:

" Relay Service URIs and User = Address of Records (AoR) MUST resolve (in
   accord with [RFC3263]) to globally routable IPv4 addresses.  The AoRs
   MAY also resolve to IPv6 addresses.=E2=80=9D

How do you resolve a =
complete URI into an IP address? I guess you mean
the domain part that =
resolves to a list of addresses using DNS.
Why is IPv4 a MUST?

Section 8:

"All media streams between =
the RUE and another endpoint or relay
   Provider MUST be exchanged =
using the secure real-time transport
   protocol (SRTP) [RFC3550] using DTLS [RFC5763], [RFC5764], except
   that for backwards compatibility with older video endpoints, RTP MAY
   be negotiated if SRTP negotiation fails.
=E2=80=9C

How do you handle the risk of downgrade attacks here? That = exception is dangerous
and maybe should be handled = elsewhere, not in the client. 


Section 11.1

The example operator URI for red.example.net seems= to lack =E2=80=9C;user=3Ddialstring=E2=80=9D

Section 11.2

"outbound-proxies: (OPTIONAL) A list of URIs of = SIP proxies to be
      used when sending requests to the Provider.  Multiple URIs
      identify alternative (redundant) paths to the Provider.
=E2=80=9C

Outbound proxy is of course something you look up in DNS to = get the list of
actual servers. Is there a need to = have an additional list in this json format?

" ice-servers=E2=80=9D - = propably a bad name. I don=E2=80=99t remember seeing =E2=80=9Cice = server=E2=80=9D as a term.
As turn servers are also STUN servers, I = think =E2=80=9Cturn-servers=E2=80=9D is better.

=E2=80=9Ccredentials=E2=80=9D: = This is tricky indeed. Sending credentials in clear text like = this,
even if = it=E2=80=99s over HTTPS is an interesting approach in this age and = time.
Regardless = of that, make sure you consider OAuth/OpenID connect = auth
for some = services.

=E2=80=9Clifetime=E2=80=9D:; You are really not clear on what = happens when the configuration
expires. Is the RUE forbidden to use anything = here? What about emergency calls
- will they work even without = configuration?

General:

You do not mention bundling of = RTP streams, which may be beneficial here.

Good work!

/O






--<= span class=3D"Apple-converted-space"> 
Rum = mailing list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum

= --Apple-Mail=_4248C2AC-09BB-40A2-BF40-90E0D9936134-- From nobody Tue Aug 27 12:49:05 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5962120113 for ; Tue, 27 Aug 2019 12:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-QW-kwJa66t for ; Tue, 27 Aug 2019 12:49:01 -0700 (PDT) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 997C91200FF for ; Tue, 27 Aug 2019 12:49:01 -0700 (PDT) Received: by mail-qt1-x835.google.com with SMTP id u34so297404qte.2 for ; Tue, 27 Aug 2019 12:49:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=og3ySeOdJykWlZeNjK8sbuqm2ux8R3WsFJPSrajzZo8=; b=Q6C7QFB6BpSsK4S3aFks2su0r6J6l+qfJTd69ozS+V3VDbXiIlkHuww4TvGFQBVtrw ev3YYreVZxCnABBBcP/s9ZMi/KlExqFLjCN6HPhz2ZzQHIeotlNE1UOVBqvBwzzSCtwx n/vq4soV4+AzYINEZ4y3iWPCbypD4wNbfKPWRpkK4kUA8+ZyyqLLQcobp+x4wqdLkVtg wOR90DPq+syubq/F2dswGK3nwJ9DqeKPFjW2YG9v9blG9aOhDe2642r/jK0mcRn1ATUW 1Zl7VRsJsmqZ92905B+lhjftE2oCpLrGVVOWIaNdkd/ivaOdVBusK5pjSAjtGhv7fx0d ECxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=og3ySeOdJykWlZeNjK8sbuqm2ux8R3WsFJPSrajzZo8=; b=UH4f/TGO+akI5D1hcUZgSjeBz/6al49L1zPlgh5ZYa1PLMg+n2XJbrgpfyQd4mofYD 1SuS+wNR+WKKk69QUQiblGwpjHWdaw8oo3RRyMqebRPSERgiF6Cyp+pTE0oNwIvxrvxE ySfRhojtLn6B686UNKk/PQ/QkvKV42cwRdOn+LCuwYg1r4gDm7xwj9BPII8bEsUCllzw IngPvc67p4uBDUqY8QTaSAl9fXJuNxdSZ5s3JxSqrmX9lDmNYwvnaND2YltoYiKC8SDc gWedD7CRe+i+S7NssdQ6/H9L3+o1rUgZMBFHEB0Xw6roJ6dVuFQbchTRpaHmI8Ge482G 4Gjw== X-Gm-Message-State: APjAAAU8A8sIx7/DY5s2HKv9FNg6zoBJnVPKEq0znWKnjibvP1gXZZxa 38m06nXHWzVEcXKaiWxE9nhcuZN9F/4= X-Google-Smtp-Source: APXvYqwqdTbXHnhuJXeZ6D2yNttnjlvJ1XBAoAEVXVbMaXc7aE7xAKEyHcfHb3m7D4QtUKjute0vgQ== X-Received: by 2002:ac8:3315:: with SMTP id t21mr571091qta.392.1566935340213; Tue, 27 Aug 2019 12:49:00 -0700 (PDT) Received: from brians-mbp-2369.lan ([24.154.122.195]) by smtp.gmail.com with ESMTPSA id o127sm185506qkd.104.2019.08.27.12.48.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Aug 2019 12:48:59 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Brian Rosen In-Reply-To: <9a14addd-9a1c-6130-3880-a814be717323@omnitor.se> Date: Tue, 27 Aug 2019 15:48:59 -0400 Cc: rum@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <9a14addd-9a1c-6130-3880-a814be717323@omnitor.se> To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Rum] Real-time text in WebRTC is discussed in mmusic - a topic closely telated to rum X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 19:49:04 -0000 The problem of conference 4103 RTT is high on my list of work I need to = get done. So, I=E2=80=99m motivated to help out. The basic problem is that we=E2=80=99re going to get very inconsistent = UI doing it that way, because of how systems will handle backspace of = one party that extends beyond responses from other parties: Alice: I waited for you Bob: I didn=E2=80=99t see you Alice: sorry And then Alice types 12 backspaces. What should happen? Brian > On Aug 27, 2019, at 9:52 AM, Gunnar Hellstr=C3=B6m = wrote: >=20 > Hi, >=20 > A topic is currently discussed in mmusic that is closely related to = rum. it is WebRTC transport of real-time text. >=20 > The draft is draft-holmberg-mmusic-t140-usage-data-channel . >=20 > A good point to start reading could be: >=20 > = https://mailarchive.ietf.org/arch/browse/mmusic/?gbt=3D1&q=3Ddraft-holmber= g-mmusic-t140-usage-data-channel >=20 > Please check if the current state of the discussion suits rum! >=20 > The only issue that seems to be remaining is how to transport RTT data = to and from a conference server that combines all traffic per media in a = meeting in one data stream. That is not very elegantly specified for RFC = 4103 transport of RTT in RTP either, so we might want to do a rapid = action together to solve the multi-party RTT MCU case in a general and = consistent way. >=20 > Regards >=20 > Gunnar >=20 > --=20 > ----------------------------------------- > Gunnar Hellstr=C3=B6m > Omnitor > gunnar.hellstrom@omnitor.se > +46 708 204 288 >=20 >=20 From nobody Tue Aug 27 13:43:21 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDCE120113 for ; Tue, 27 Aug 2019 13:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGz3w8Ks3Aiv for ; Tue, 27 Aug 2019 13:43:17 -0700 (PDT) Received: from vsp-unauthed02.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21BED1200DE for ; Tue, 27 Aug 2019 13:43:16 -0700 (PDT) X-Halon-ID: 41a615c5-c90b-11e9-bdc3-005056917a89 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [88.129.173.120]) by bin-vsp-out-01.atm.binero.net (Halon) with ESMTPSA id 41a615c5-c90b-11e9-bdc3-005056917a89; Tue, 27 Aug 2019 22:43:00 +0200 (CEST) To: Brian Rosen Cc: rum@ietf.org References: <9a14addd-9a1c-6130-3880-a814be717323@omnitor.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Tue, 27 Aug 2019 22:43:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rum] Real-time text in WebRTC is discussed in mmusic - a topic closely telated to rum X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 20:43:21 -0000 Den 2019-08-27 kl. 21:48, skrev Brian Rosen: > The problem of conference 4103 RTT is high on my list of work I need to get done. So, I’m motivated to help out. Thanks, great. > The basic problem is that we’re going to get very inconsistent UI doing it that way, because of how systems will handle backspace of one party that extends beyond responses from other parties: (well, for me the currently most basic problem is to have a reliable way to append received text to the already presented text of the right participant. And that is getting worse in WebRTC than it was in RFC 4103. But we will sort it out.) > > Alice: I waited for you > Bob: I didn’t see you > Alice: sorry > > And then Alice types 12 backspaces. > > What should happen? You are right that there are a number of ways to handle the RTT UI. And just as inconsistencies are common with a message oriented UI, where messages show up in a confusing order because two users completed messages in an unexpected time order, it is possible that RTT text gets displayed in a strange order after erasure and retyping. It is better for RTT than for message oriented presentation, and user get used to it in both cases.  With the labelled style in one column you have in the example, I would recommend that first 5 backspaces erase "sorry", next backspace erases the line separator, and pulls down "I waited for you" to be shown last, as an uncompleted text. Then the next 6 backspaces erase so that only "I waited f" is displayed. When Alice adds text and end with a new line, the corrected sentence is allowed to flow up when new text is added from any participant.  That causes a bit strange order, but it is just as manageable as when text in messaging applications appear in an unexpected order so that one message seems to be a respone on something totally else than what was intended. A sophisticated UI may mark text that is moved and modified. We want to keep sentences or at least phrases from each participant together in a readable unit. Already that causes a design decision on where to place the completed chunk of text once the user has completed it. The start of the chunk may be older than completed text from other participants which would motivate to move it up a bit in the presentation. But the end of it is at that moment the latest text to present. I think it is best to let the finished text be presented last on the display, but let others' newer text push everything up and be displayed last. T.140 has information on how to handle erasure: -------------------From T.140--------------------------- 8.2 Erase last character Purpose: Erase the last character sent from the display at the receiving end. Code: BS: 0008. Procedure: On the receiving end: Move the insertion point to the last character and erase it. Combined characters are erased as a unit, with one BS erasing the whole character even if it is combined from more than one component. Control sequences (like CR LF) are erased in one operation. NOTE – The same action shall be taken on the local display. ------------------------------------------------------------   /Gunnar > > Brian > >> On Aug 27, 2019, at 9:52 AM, Gunnar Hellström wrote: >> >> Hi, >> >> A topic is currently discussed in mmusic that is closely related to rum. it is WebRTC transport of real-time text. >> >> The draft is draft-holmberg-mmusic-t140-usage-data-channel . >> >> A good point to start reading could be: >> >> https://mailarchive.ietf.org/arch/browse/mmusic/?gbt=1&q=draft-holmberg-mmusic-t140-usage-data-channel >> >> Please check if the current state of the discussion suits rum! >> >> The only issue that seems to be remaining is how to transport RTT data to and from a conference server that combines all traffic per media in a meeting in one data stream. That is not very elegantly specified for RFC 4103 transport of RTT in RTP either, so we might want to do a rapid action together to solve the multi-party RTT MCU case in a general and consistent way. >> >> Regards >> >> Gunnar >> >> -- >> ----------------------------------------- >> Gunnar Hellström >> Omnitor >> gunnar.hellstrom@omnitor.se >> +46 708 204 288 >> >> -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Tue Aug 27 14:16:09 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF2B8120113 for ; Tue, 27 Aug 2019 14:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wo5KfD8DcgjG for ; Tue, 27 Aug 2019 14:16:03 -0700 (PDT) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACAAD12083E for ; Tue, 27 Aug 2019 14:16:02 -0700 (PDT) Received: by mail-qt1-x82d.google.com with SMTP id k13so502011qtm.12 for ; Tue, 27 Aug 2019 14:16:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=U5lBe4mWrYdoFCZ0p6cC8NPR8GvKzAy3RIBeWDVbTaM=; b=w2johvPHJTpD4Do44eJUTB2e6UAd/MsJsAFpa++rVwGugxh0w7Cem9+gPWKeWJZCoi xFaZEAf7EaPf0KHezCPE45F0CS5Kyw3BO8y+lvEvYZwJCrkYrJ967Dq6Ko20+tw2GsfW vWgBn6QtNkzWyiWpffU57/iM5xzwt+oRak8mS1P9oZGDQZUsAB2A3aZYs9qTEkt2ZoA1 ocqS6WV+QzsrD3AAbFtJOCa5YVyo1zx2AkUSGaczaVfFySv5ABs2LWJ0wqWEnRUs44sD TloWBkAnKaduw/QFfa/t2jMCnoo81cCrjQ2Ive4zNJ+VSl1+2NtXThtzmtQbDCHjaboa 91uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=U5lBe4mWrYdoFCZ0p6cC8NPR8GvKzAy3RIBeWDVbTaM=; b=R3Pw4QMSRBTJeLCk75SPL+V2Y6sh1+nWdTz1zVbSuJwEZEEwB8mhPWb0tftC+XvkWu T2rrdr1kS8ZcMXIJp0LC3GIc/Ni+2rIYL2t22ZrFybZzq+nC/EHKjek8XePhgLmoSzP2 ymW38Zjpu5rjkYD9IMuKzvDqc73NyTVqdXDKHcsgxcCIcOyE02EsjPdzNxnIf1Vl996H Rav9mUt1heN1fl3ds87pq8t3v12fqwyQMTrSfDVXGy1IKn3T+Ttq4hn/1E1MYGUlcs/w hRPI3xBHfcSwVPQLYQncaQ3e22tLZEz9136jLoREFMT1LTn317J0WH7xgPtkI2s+WtAK xwyw== X-Gm-Message-State: APjAAAWEpj2JOE1cRzWt9EnHTrnz10ViJ7A9YgFSpmMSSyXyPn0fAUvJ xd+pUUnoNDR5IhvDb19cOKlFioVlQ3E= X-Google-Smtp-Source: APXvYqw++1r63o7dy/KhvmVLWGiMALeE8NYQ4ynzZiz+E3EM7HRTq+pjCE3D1qmDjvoK8WMwMdzGRw== X-Received: by 2002:ad4:420c:: with SMTP id k12mr610729qvp.94.1566940561595; Tue, 27 Aug 2019 14:16:01 -0700 (PDT) Received: from brians-mbp-2369.lan ([24.154.122.195]) by smtp.gmail.com with ESMTPSA id m194sm288997qke.123.2019.08.27.14.16.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Aug 2019 14:16:01 -0700 (PDT) From: Brian Rosen Message-Id: <59F6B4E5-16DF-42EB-A654-1749BC9487B5@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_9BF8F82D-8143-4E4B-ABDF-2E0FA7E56B74" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 27 Aug 2019 17:15:58 -0400 In-Reply-To: Cc: rum@ietf.org To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= References: <9a14addd-9a1c-6130-3880-a814be717323@omnitor.se> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Rum] Real-time text in WebRTC is discussed in mmusic - a topic closely telated to rum X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 21:16:07 -0000 --Apple-Mail=_9BF8F82D-8143-4E4B-ABDF-2E0FA7E56B74 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 At least by centralizing the problem at a =E2=80=9Cmixer=E2=80=9D, Alice = and Bob will see the same thing. You don=E2=80=99t have the problem in Instant Messaging, because you = can=E2=80=99t backspace or delete a sent message. Of course if multiple = people are typing simultaneously in such systems, message order will be = confusing in that instant.=20 Anyway, we need to specify the mixer for RTT so it receives each of the = RTT streams and produces a single composite stream for each participant. > On Aug 27, 2019, at 4:43 PM, Gunnar Hellstr=C3=B6m = wrote: >=20 > Den 2019-08-27 kl. 21:48, skrev Brian Rosen: >> The problem of conference 4103 RTT is high on my list of work I need = to get done. So, I=E2=80=99m motivated to help out. > Thanks, great. >> The basic problem is that we=E2=80=99re going to get very = inconsistent UI doing it that way, because of how systems will handle = backspace of one party that extends beyond responses from other parties: > (well, for me the currently most basic problem is to have a reliable = way to append received text to the already presented text of the right = participant. And that is getting worse in WebRTC than it was in RFC = 4103. But we will sort it out.) >>=20 >> Alice: I waited for you >> Bob: I didn=E2=80=99t see you >> Alice: sorry >>=20 >> And then Alice types 12 backspaces. >>=20 >> What should happen? >=20 > You are right that there are a number of ways to handle the RTT UI. = And just as inconsistencies are common with a message oriented UI, where = messages show up in a confusing order because two users completed = messages in an unexpected time order, it is possible that RTT text gets = displayed in a strange order after erasure and retyping. It is better = for RTT than for message oriented presentation, and user get used to it = in both cases. With the labelled style in one column you have in the = example, I would recommend that first 5 backspaces erase "sorry", next = backspace erases the line separator, and pulls down "I waited for you" = to be shown last, as an uncompleted text. Then the next 6 backspaces = erase so that only "I waited f" is displayed. When Alice adds text and = end with a new line, the corrected sentence is allowed to flow up when = new text is added from any participant. That causes a bit strange = order, but it is just as manageable as when text in messaging = applications appear in an unexpected order so that one message seems to = be a respone on something totally else than what was intended. >=20 > A sophisticated UI may mark text that is moved and modified. >=20 > We want to keep sentences or at least phrases from each participant = together in a readable unit. Already that causes a design decision on = where to place the completed chunk of text once the user has completed = it. The start of the chunk may be older than completed text from other = participants which would motivate to move it up a bit in the = presentation. But the end of it is at that moment the latest text to = present. I think it is best to let the finished text be presented last = on the display, but let others' newer text push everything up and be = displayed last. >=20 >=20 > T.140 has information on how to handle erasure: >=20 > -------------------=46rom T.140--------------------------- >=20 > 8.2 Erase last character > Purpose: Erase the last character sent from the display at the = receiving end. > Code: BS: 0008. > Procedure: On the receiving end: Move the insertion point to the last = character and erase it. > Combined characters are erased as a unit, with one BS erasing the = whole character even if it is > combined from more than one component. > Control sequences (like CR LF) are erased in one operation. > NOTE =E2=80=93 The same action shall be taken on the local display. >=20 > ------------------------------------------------------------ >=20 > /Gunnar >=20 >>=20 >> Brian >>=20 >>> On Aug 27, 2019, at 9:52 AM, Gunnar Hellstr=C3=B6m = wrote: >>>=20 >>> Hi, >>>=20 >>> A topic is currently discussed in mmusic that is closely related to = rum. it is WebRTC transport of real-time text. >>>=20 >>> The draft is draft-holmberg-mmusic-t140-usage-data-channel . >>>=20 >>> A good point to start reading could be: >>>=20 >>> = https://mailarchive.ietf.org/arch/browse/mmusic/?gbt=3D1&q=3Ddraft-holmber= g-mmusic-t140-usage-data-channel >>>=20 >>> Please check if the current state of the discussion suits rum! >>>=20 >>> The only issue that seems to be remaining is how to transport RTT = data to and from a conference server that combines all traffic per media = in a meeting in one data stream. That is not very elegantly specified = for RFC 4103 transport of RTT in RTP either, so we might want to do a = rapid action together to solve the multi-party RTT MCU case in a general = and consistent way. >>>=20 >>> Regards >>>=20 >>> Gunnar >>>=20 >>> --=20 >>> ----------------------------------------- >>> Gunnar Hellstr=C3=B6m >>> Omnitor >>> gunnar.hellstrom@omnitor.se >>> +46 708 204 288 >>>=20 >>>=20 > --=20 > ----------------------------------------- > Gunnar Hellstr=C3=B6m > Omnitor > gunnar.hellstrom@omnitor.se > +46 708 204 288 --Apple-Mail=_9BF8F82D-8143-4E4B-ABDF-2E0FA7E56B74 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
At least by centralizing the problem at a =E2=80=9Cmixer=E2=80=9D= , Alice and Bob will see the same thing.

You don=E2=80=99t have the problem in = Instant Messaging, because you can=E2=80=99t backspace or delete a sent = message.  Of course if multiple people are typing simultaneously in = such systems, message order will be confusing in that = instant. 

Anyway, we need to specify the mixer for RTT so it receives = each of the RTT streams and produces a single composite stream for each = participant.

On Aug 27, 2019, at 4:43 PM, = Gunnar Hellstr=C3=B6m <gunnar.hellstrom@omnitor.se> wrote:

Den 2019-08-27 kl. 21:48, skrev = Brian Rosen:
The = problem of conference 4103 RTT is high on my list of work I need to get = done.  So, I=E2=80=99m motivated to help out.
Thanks, great.
The basic problem is that we=E2=80=99re= going to get very inconsistent UI doing it that way, because of how = systems will handle backspace of one party that extends beyond responses = from other parties:
(well, for me the currently most basic problem is to have a = reliable way to append received text to the already presented text of = the right participant. And that is getting worse in WebRTC than it was = in RFC 4103. But we will sort it out.)

Alice: I waited for = you
Bob: I didn=E2=80=99t see you
Alice: = sorry

And then Alice types 12 = backspaces.

What should happen?

You are right that there are a number of ways to handle the = RTT UI. And just as inconsistencies are common with a message oriented = UI, where messages show up in a confusing order because two users = completed messages in an unexpected time order, it is possible that RTT = text gets displayed in a strange order after erasure and retyping. It is = better for RTT than for message oriented presentation, and user get used = to it in both cases.  With the labelled style in one column you = have in the example, I would recommend that first 5 backspaces erase = "sorry", next backspace erases the line separator, and pulls down "I = waited for you" to be shown last, as an uncompleted text. Then the next = 6 backspaces erase so that only "I waited f" is displayed. When Alice = adds text and end with a new line, the corrected sentence is allowed to = flow up when new text is added from any participant.  That causes a = bit strange order, but it is just as manageable as when text in = messaging applications appear in an unexpected order so that one message = seems to be a respone on something totally else than what was = intended.

A = sophisticated UI may mark text that is moved and modified.

We want to keep sentences or at = least phrases from each participant together in a readable unit. Already = that causes a design decision on where to place the completed chunk of = text once the user has completed it. The start of the chunk may be older = than completed text from other participants which would motivate to move = it up a bit in the presentation. But the end of it is at that moment the = latest text to present. I think it is best to let the finished text be = presented last on the display, but let others' newer text push = everything up and be displayed last.


T.140 has information on how to handle erasure:

-------------------=46rom = T.140---------------------------

8.2 Erase last character
Purpose: Erase the last character sent from the display at = the receiving end.
Code: BS: 0008.
Procedure: On the receiving end: Move the insertion point to = the last character and erase it.
Combined characters are erased as a unit, with one BS erasing = the whole character even if it is
combined from more than one component.
Control sequences (like CR LF) = are erased in one operation.
NOTE =E2=80=93 The same action shall be taken on the local = display.

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

  = /Gunnar


Brian

On Aug 27, 2019, at 9:52 AM, Gunnar Hellstr=C3=B6m <gunnar.hellstrom@omnitor.se> wrote:

Hi,

A topic is currently = discussed in mmusic that is closely related to rum. it is WebRTC = transport of real-time text.

The draft is = draft-holmberg-mmusic-t140-usage-data-channel .

A good point to start reading could be:

https://mailarchive.ietf.org/arch/browse/mmusic/?gbt=3D1&q=3D= draft-holmberg-mmusic-t140-usage-data-channel

Please check if the current state of the discussion suits = rum!

The only issue that seems to be = remaining is how to transport RTT data to and from a conference server = that combines all traffic per media in a meeting in one data stream. = That is not very elegantly specified for RFC 4103 transport of RTT in = RTP either, so we might want to do a rapid action together to solve the = multi-party RTT MCU case in a general and consistent way.

Regards

Gunnar

-- 
-----------------------------------------
Gunnar = Hellstr=C3=B6m
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288


-- 
-----------------------------------------
Gunnar Hellstr=C3=B6m
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288

= --Apple-Mail=_9BF8F82D-8143-4E4B-ABDF-2E0FA7E56B74-- From nobody Tue Aug 27 14:57:56 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C6012021D for ; Tue, 27 Aug 2019 14:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1IAvDL2hi_f for ; Tue, 27 Aug 2019 14:57:52 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D12312004D for ; Tue, 27 Aug 2019 14:57:52 -0700 (PDT) Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x7RLvfAr080483 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 27 Aug 2019 16:57:43 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1566943063; bh=PzPQ9fmOzqiCtD1M57JXhBhMYFTxj+dM/uFjXNO8lso=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=oaNxxpl+WhsVGYnKBmSNqC05Y/zQ8SKkWRP8mjQgTTAdVYPg5mV6DLxxo/q7Cyd+M t4yqjUIyuVLvfgUCNC7WVWwabUQt/+JCpoOUDBoNLdpC8bLxqIZ8gFlESF/tj72xAs 3WKkvR3FcsYU0AGr84ezbntpeAouhC88B8WdkL3o= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: Brian Rosen , Paul Kyzivat Cc: rum@ietf.org References: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net> <64B406DC-4171-41EB-9171-A2AF7B78B409@brianrosen.net> <69F15B2A-0158-4D23-B090-642497E3BDC7@brianrosen.net> From: Adam Roach Message-ID: Date: Tue, 27 Aug 2019 16:57:36 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <69F15B2A-0158-4D23-B090-642497E3BDC7@brianrosen.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 21:57:55 -0000 I certainly have thoughts. The executive summary is that I personally believe RUM should specify Opus as the one audio codec MTI, and match RFC 7742's "Non-Browser" requirements for the video codec MTI. Rationale below. From an interop perspective, the important thing is that any given profile has (at least) one MTI video codec and (at least) one MTI audio codec. I know there is a strong desire -- one that I share -- that these endpoints can talk to/be implemented in web browsers without the need for media transcoding. For audio: WebRTC selected G.711 and Opus as both MTI; the former because it works without transcoding to landline PSTN destinations, and the latter because it sounds much, much better. RUM could make the same decision; or it could decide to move away from a codec that is as old as I am and opt to designate Opus as the only MTI. Given that RUM inherently needs to deploy into audio/video environments, backwards compatibility with the PSTN seems to be unnecessary baggage. For video: While specifying either VP8 or H.264 would be sufficient for system interop, and for interop with compliant WebRTC endpoints, I'd really prefer not to re-live the WebRTC video codec wars. Concretely, what I would propose is that RUM indicate that the video codec requirements are defined to be identical to those defined for "WebRTC Non-Browsers" in Section 5 of RFC 7742. It should be made clear that RUM endpoints *are* *not* WebRTC Non-Browsers per se; merely that they comply with the same video codec requirements as WebRTC Non-Browsers. /a On 8/27/19 2:34 PM, Brian Rosen wrote: > Well, we certainly want interoperability, and I think we can only get that with MTI codecs. > > I think we really are talking about a WebRTC-compatible endpoint, but we want interoperability with a WebRTC browser endpoint. > > Not sure how to say this. Maybe Adam can help. > > Brian > >> On Aug 12, 2019, at 4:20 PM, Paul Kyzivat wrote: >> >> draft-rosen-rue-01 changes the video codec requirements. It now simply references webrtc RFC7742. >> >> RFC7742 distinguishes three types of endpoints: "WebRTC browser", "WebRTC non-browser", and "WebRTC-compatible endpoint". AFAIK it assumes that each end is one of these. >> >> Is the expectation here that both the RUE and the provider comply with one of these? In particular, that the provider may simply be a "WebRTC-compatible endpoint? Notably: >> >> "WebRTC-compatible endpoints" are free to implement any video codecs >> they see fit. This follows logically from the definition of "WebRTC- >> compatible endpoint". It is, of course, advisable to implement at >> least one of the video codecs that is mandated for WebRTC browsers, >> and implementors are encouraged to do so. >> >> Similarly, the audio requirements have been changed to reference webrtc RFC7874. That one doesn't have the distinction between "WebRTC browser", "WebRTC non-browser", and "WebRTC-compatible endpoint". It applies the same requirements to all. In particular, it requires OPUS support. I don't know why it doesn't make the same endpoint distinctions as for video. >> >> I think simply referencing these documents isn't sufficient. Seems like we need a more nuanced specification of what is required, though we may still reference these docs with qualifications. >> >> Thanks, >> Paul >> >> From nobody Tue Aug 27 15:34:08 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 375E612011F for ; Tue, 27 Aug 2019 15:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qElvahv3gUfj for ; Tue, 27 Aug 2019 15:34:04 -0700 (PDT) Received: from gateway24.websitewelcome.com (gateway24.websitewelcome.com [192.185.50.84]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 884EF12004D for ; Tue, 27 Aug 2019 15:34:04 -0700 (PDT) Received: from cm11.websitewelcome.com (cm11.websitewelcome.com [100.42.49.5]) by gateway24.websitewelcome.com (Postfix) with ESMTP id 026083E24 for ; Tue, 27 Aug 2019 17:34:02 -0500 (CDT) Received: from box5527.bluehost.com ([162.241.218.19]) by cmsmtp with SMTP id 2k2LiBSYodnCe2k2LiZPEi; Tue, 27 Aug 2019 17:34:01 -0500 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To :References:Message-ID:CC:To:From:Subject:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=BLKsXuwDDu1eYDDz6bSRmZ/AQejrw3kQ/WjtS3XIp70=; b=WzTh3nbinM2LIxMAKHIbs1ylft 2+wypRjyUPGkq06Qh66nKm3LUEtymVJH8FPWaqd0VlSWalmMeKgi3ActA0LFQCPS60133aihjdU0M 8izP1hkBmWeYf+JVwEExGrM5D; Received: from pool-100-36-47-17.washdc.fios.verizon.net ([100.36.47.17]:53118 helo=[192.168.1.156]) by box5527.bluehost.com with esmtpa (Exim 4.92) (envelope-from ) id 1i2k2L-000tCp-G7; Tue, 27 Aug 2019 17:34:01 -0500 User-Agent: Microsoft-MacOutlook/10.1c.0.190812 Date: Tue, 27 Aug 2019 18:34:00 -0400 From: Richard Shockey To: Adam Roach , Brian Rosen , Paul Kyzivat CC: Message-ID: Thread-Topic: [Rum] Codec requirements in draft-rosen-rue-01 References: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net> <64B406DC-4171-41EB-9171-A2AF7B78B409@brianrosen.net> <69F15B2A-0158-4D23-B090-642497E3BDC7@brianrosen.net> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5527.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 100.36.47.17 X-Source-L: No X-Exim-ID: 1i2k2L-000tCp-G7 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-47-17.washdc.fios.verizon.net ([192.168.1.156]) [100.36.47.17]:53118 X-Source-Auth: richard+shockey.us X-Email-Count: 1 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NTUyNy5ibHVlaG9zdC5jb20= X-Local-Domain: yes Archived-At: Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 22:34:07 -0000 +1 to Adam's excellent comments.=20 =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook =E2=80=93Twitter rshockey101 PSTN +1 703-593-2683 =20 =EF=BB=BFOn 8/27/19, 5:57 PM, "Rum on behalf of Adam Roach" wrote: I certainly have thoughts. The executive summary is that I personally=20 believe RUM should specify Opus as the one audio codec MTI, and match=20 RFC 7742's "Non-Browser" requirements for the video codec MTI. Rational= e=20 below. =20 From an interop perspective, the important thing is that any given=20 profile has (at least) one MTI video codec and (at least) one MTI audio= =20 codec. I know there is a strong desire -- one that I share -- that thes= e=20 endpoints can talk to/be implemented in web browsers without the need=20 for media transcoding. =20 For audio: WebRTC selected G.711 and Opus as both MTI; the former=20 because it works without transcoding to landline PSTN destinations, and= =20 the latter because it sounds much, much better. RUM could make the same= =20 decision; or it could decide to move away from a codec that is as old a= s=20 I am and opt to designate Opus as the only MTI. Given that RUM=20 inherently needs to deploy into audio/video environments, backwards=20 compatibility with the PSTN seems to be unnecessary baggage. =20 For video: While specifying either VP8 or H.264 would be sufficient for= =20 system interop, and for interop with compliant WebRTC endpoints, I'd=20 really prefer not to re-live the WebRTC video codec wars. Concretely,=20 what I would propose is that RUM indicate that the video codec=20 requirements are defined to be identical to those defined for "WebRTC=20 Non-Browsers" in Section 5 of RFC 7742. It should be made clear that RU= M=20 endpoints *are* *not* WebRTC Non-Browsers per se; merely that they=20 comply with the same video codec requirements as WebRTC Non-Browsers. =20 /a =20 On 8/27/19 2:34 PM, Brian Rosen wrote: > Well, we certainly want interoperability, and I think we can only get= that with MTI codecs. > > I think we really are talking about a WebRTC-compatible endpoint, but= we want interoperability with a WebRTC browser endpoint. > > Not sure how to say this. Maybe Adam can help. > > Brian > >> On Aug 12, 2019, at 4:20 PM, Paul Kyzivat wr= ote: >> >> draft-rosen-rue-01 changes the video codec requirements. It now simp= ly references webrtc RFC7742. >> >> RFC7742 distinguishes three types of endpoints: "WebRTC browser", "W= ebRTC non-browser", and "WebRTC-compatible endpoint". AFAIK it assumes that = each end is one of these. >> >> Is the expectation here that both the RUE and the provider comply wi= th one of these? In particular, that the provider may simply be a "WebRTC-co= mpatible endpoint? Notably: >> >> "WebRTC-compatible endpoints" are free to implement any video cod= ecs >> they see fit. This follows logically from the definition of "Web= RTC- >> compatible endpoint". It is, of course, advisable to implement a= t >> least one of the video codecs that is mandated for WebRTC browser= s, >> and implementors are encouraged to do so. >> >> Similarly, the audio requirements have been changed to reference web= rtc RFC7874. That one doesn't have the distinction between "WebRTC browser",= "WebRTC non-browser", and "WebRTC-compatible endpoint". It applies the same= requirements to all. In particular, it requires OPUS support. I don't know = why it doesn't make the same endpoint distinctions as for video. >> >> I think simply referencing these documents isn't sufficient. Seems l= ike we need a more nuanced specification of what is required, though we may = still reference these docs with qualifications. >> >> Thanks, >> Paul >> >> =20 --=20 Rum mailing list Rum@ietf.org https://www.ietf.org/mailman/listinfo/rum =20 From nobody Tue Aug 27 23:16:06 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2DA3120858 for ; Tue, 27 Aug 2019 23:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I63UesVuaJ8d for ; Tue, 27 Aug 2019 23:15:57 -0700 (PDT) Received: from vsp-unauthed02.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6B9512089C for ; Tue, 27 Aug 2019 23:15:56 -0700 (PDT) X-Halon-ID: 48dea6d1-c95b-11e9-837a-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [88.129.173.120]) by bin-vsp-out-03.atm.binero.net (Halon) with ESMTPSA id 48dea6d1-c95b-11e9-837a-0050569116f7; Wed, 28 Aug 2019 08:15:52 +0200 (CEST) To: Brian Rosen Cc: rum@ietf.org References: <9a14addd-9a1c-6130-3880-a814be717323@omnitor.se> <59F6B4E5-16DF-42EB-A654-1749BC9487B5@brianrosen.net> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Wed, 28 Aug 2019 08:15:50 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <59F6B4E5-16DF-42EB-A654-1749BC9487B5@brianrosen.net> Content-Type: multipart/alternative; boundary="------------C8C7BCA112E5F5FF36B3C94E" Content-Language: en-US Archived-At: Subject: Re: [Rum] Real-time text in WebRTC is discussed in mmusic - a topic closely telated to rum X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 06:16:04 -0000 This is a multi-part message in MIME format. --------------C8C7BCA112E5F5FF36B3C94E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Den 2019-08-27 kl. 23:15, skrev Brian Rosen: > At least by centralizing the problem at a “mixer”, Alice and Bob will > see the same thing. > > You don’t have the problem in Instant Messaging, because you can’t > backspace or delete a sent message.  Of course if multiple people are > typing simultaneously in such systems, message order will be confusing > in that instant. Right, it is a similar kind of problem that text appears in an unexpected order. There is also at least one instant messaging service that allows modification in already sent message. But I think it has limitations to only accept that in the last message sent. it is convenient anyway. > > Anyway, we need to specify the mixer for RTT so it receives each of > the RTT streams and produces a single composite stream for each > participant. Yes, right, and there is an effort in that direction in: http://www.realtimetext.org/sites/default/files/Files_and_Documents/Specifications/multiparty-real-time-text-mixer-2011-04-30.pdf It is written for conference-unaware user devices. The goals are specified as follows: The procedures are intended to make best efforts to present a multi-party text conversation on a terminal that has no awareness of multi-party calls. There are some obvious drawbacks, and a terminal designed with multi-party awareness will be able to present multi-party call contents in a more flexible way. Only two parties at a time will be allowed to display added text in real-time, while the other parties’ produced text will need to be stored in the multi-party server for a moment awaiting a suitable occasion to be displayed. There are also some cases of erasure that will not be performed on the target text but only indicated in another way. Even with these drawbacks, the procedure provides an opportunity to display text from more than two parties in a smooth and readable way. --------------------------------------------------------------------------------------------------- I see such mixer procedures as a fall-back for cases without conference awareness, but want to see support for conference-aware terminals, where text from more than two parties can be presented in real-time, and the end user or app can have influence over the presentation style - e.g. select between the multiple column view and the one-column-with-labels view.  A mixer for that case would only need to assure that the receiver has the right kind of multi-party awareness and send RTT text with source information attached, and let the receiving terminal sort out the presentation. This is already possible with CSRC and CNAME when using RTP, but we lose that possibility natively when using the WebRTC data channel to transport RTT, and would need to specify a way to include the source also for that case. ------------------------------------------------------ By the way, what is your current view of how to transport RTT for RUM, now when you say that you will use WebRTC transports for media? Regards Gunnar > >> On Aug 27, 2019, at 4:43 PM, Gunnar Hellström >> > wrote: >> >> Den 2019-08-27 kl. 21:48, skrev Brian Rosen: >>> The problem of conference 4103 RTT is high on my list of work I need >>> to get done.  So, I’m motivated to help out. >> Thanks, great. >>> The basic problem is that we’re going to get very inconsistent UI >>> doing it that way, because of how systems will handle backspace of >>> one party that extends beyond responses from other parties: >> (well, for me the currently most basic problem is to have a reliable >> way to append received text to the already presented text of the >> right participant. And that is getting worse in WebRTC than it was in >> RFC 4103. But we will sort it out.) >>> >>> Alice: I waited for you >>> Bob: I didn’t see you >>> Alice: sorry >>> >>> And then Alice types 12 backspaces. >>> >>> What should happen? >> >> You are right that there are a number of ways to handle the RTT UI. >> And just as inconsistencies are common with a message oriented UI, >> where messages show up in a confusing order because two users >> completed messages in an unexpected time order, it is possible that >> RTT text gets displayed in a strange order after erasure and >> retyping. It is better for RTT than for message oriented >> presentation, and user get used to it in both cases.  With the >> labelled style in one column you have in the example, I would >> recommend that first 5 backspaces erase "sorry", next backspace >> erases the line separator, and pulls down "I waited for you" to be >> shown last, as an uncompleted text. Then the next 6 backspaces erase >> so that only "I waited f" is displayed. When Alice adds text and end >> with a new line, the corrected sentence is allowed to flow up when >> new text is added from any participant.  That causes a bit strange >> order, but it is just as manageable as when text in messaging >> applications appear in an unexpected order so that one message seems >> to be a respone on something totally else than what was intended. >> >> A sophisticated UI may mark text that is moved and modified. >> >> We want to keep sentences or at least phrases from each participant >> together in a readable unit. Already that causes a design decision on >> where to place the completed chunk of text once the user has >> completed it. The start of the chunk may be older than completed text >> from other participants which would motivate to move it up a bit in >> the presentation. But the end of it is at that moment the latest text >> to present. I think it is best to let the finished text be presented >> last on the display, but let others' newer text push everything up >> and be displayed last. >> >> >> T.140 has information on how to handle erasure: >> >> -------------------From T.140--------------------------- >> >> 8.2 Erase last character >> Purpose: Erase the last character sent from the display at the >> receiving end. >> Code: BS: 0008. >> Procedure: On the receiving end: Move the insertion point to the last >> character and erase it. >> Combined characters are erased as a unit, with one BS erasing the >> whole character even if it is >> combined from more than one component. >> Control sequences (like CR LF) are erased in one operation. >> NOTE – The same action shall be taken on the local display. >> >> ------------------------------------------------------------ >> >>   /Gunnar >> >>> >>> Brian >>> >>>> On Aug 27, 2019, at 9:52 AM, Gunnar Hellström >>>> > >>>> wrote: >>>> >>>> Hi, >>>> >>>> A topic is currently discussed in mmusic that is closely related to >>>> rum. it is WebRTC transport of real-time text. >>>> >>>> The draft is draft-holmberg-mmusic-t140-usage-data-channel . >>>> >>>> A good point to start reading could be: >>>> >>>> https://mailarchive.ietf.org/arch/browse/mmusic/?gbt=1&q=draft-holmberg-mmusic-t140-usage-data-channel >>>> >>>> Please check if the current state of the discussion suits rum! >>>> >>>> The only issue that seems to be remaining is how to transport RTT >>>> data to and from a conference server that combines all traffic per >>>> media in a meeting in one data stream. That is not very elegantly >>>> specified for RFC 4103 transport of RTT in RTP either, so we might >>>> want to do a rapid action together to solve the multi-party RTT MCU >>>> case in a general and consistent way. >>>> >>>> Regards >>>> >>>> Gunnar >>>> >>>> -- >>>> ----------------------------------------- >>>> Gunnar Hellström >>>> Omnitor >>>> gunnar.hellstrom@omnitor.se >>>> +46 708 204 288 >>>> >>>> >> -- >> ----------------------------------------- >> Gunnar Hellström >> Omnitor >> gunnar.hellstrom@omnitor.se >> +46 708 204 288 > > -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------C8C7BCA112E5F5FF36B3C94E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Den 2019-08-27 kl. 23:15, skrev Brian Rosen:
At least by centralizing the problem at a “mixer”, Alice and Bob will see the same thing.

You don’t have the problem in Instant Messaging, because you can’t backspace or delete a sent message.  Of course if multiple people are typing simultaneously in such systems, message order will be confusing in that instant.
Right, it is a similar kind of problem that text appears in an unexpected order. There is also at least one instant messaging service that allows modification in already sent message. But I think it has limitations to only accept that in the last message sent. it is convenient anyway.

Anyway, we need to specify the mixer for RTT so it receives each of the RTT streams and produces a single composite stream for each participant.

Yes, right, and there is an effort in that direction in:

http://www.realtimetext.org/sites/default/files/Files_and_Documents/Specifications/multiparty-real-time-text-mixer-2011-04-30.pdf

It is written for conference-unaware user devices.

The goals are specified as follows:

The procedures are intended to make best efforts to present a multi-party text conversation on a terminal that has no awareness of multi-party calls. There are some obvious drawbacks, and a terminal designed with multi-party awareness will be able to present multi-party call contents in a more flexible way. Only two parties at a time will be allowed to display added text in real-time, while the other parties’ produced text will need to be stored in the multi-party server for a moment awaiting a suitable occasion to be displayed. There are also some cases of erasure that will not be performed on the target text but only indicated in another way. Even with these drawbacks, the procedure provides an opportunity to display text from more than two parties in a smooth and readable way.

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

I see such mixer procedures as a fall-back for cases without conference awareness, but want to see support for conference-aware terminals, where text from more than two parties can be presented in real-time, and the end user or app can have influence over the presentation style - e.g. select between the multiple column view and the one-column-with-labels view.  A mixer for that case would only need to assure that the receiver has the right kind of multi-party awareness and send RTT text with source information attached, and let the receiving terminal sort out the presentation. This is already possible with CSRC and CNAME when using RTP, but we lose that possibility natively when using the WebRTC data channel to transport RTT, and would need to specify a way to include the source also for that case.

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

By the way, what is your current view of how to transport RTT for RUM, now when you say that you will use WebRTC transports for media?

Regards

Gunnar


On Aug 27, 2019, at 4:43 PM, Gunnar Hellström <gunnar.hellstrom@omnitor.se> wrote:

Den 2019-08-27 kl. 21:48, skrev Brian Rosen:
The problem of conference 4103 RTT is high on my list of work I need to get done.  So, I’m motivated to help out.
Thanks, great.
The basic problem is that we’re going to get very inconsistent UI doing it that way, because of how systems will handle backspace of one party that extends beyond responses from other parties:
(well, for me the currently most basic problem is to have a reliable way to append received text to the already presented text of the right participant. And that is getting worse in WebRTC than it was in RFC 4103. But we will sort it out.)

Alice: I waited for you
Bob: I didn’t see you
Alice: sorry

And then Alice types 12 backspaces.

What should happen?

You are right that there are a number of ways to handle the RTT UI. And just as inconsistencies are common with a message oriented UI, where messages show up in a confusing order because two users completed messages in an unexpected time order, it is possible that RTT text gets displayed in a strange order after erasure and retyping. It is better for RTT than for message oriented presentation, and user get used to it in both cases.  With the labelled style in one column you have in the example, I would recommend that first 5 backspaces erase "sorry", next backspace erases the line separator, and pulls down "I waited for you" to be shown last, as an uncompleted text. Then the next 6 backspaces erase so that only "I waited f" is displayed. When Alice adds text and end with a new line, the corrected sentence is allowed to flow up when new text is added from any participant.  That causes a bit strange order, but it is just as manageable as when text in messaging applications appear in an unexpected order so that one message seems to be a respone on something totally else than what was intended.

A sophisticated UI may mark text that is moved and modified.

We want to keep sentences or at least phrases from each participant together in a readable unit. Already that causes a design decision on where to place the completed chunk of text once the user has completed it. The start of the chunk may be older than completed text from other participants which would motivate to move it up a bit in the presentation. But the end of it is at that moment the latest text to present. I think it is best to let the finished text be presented last on the display, but let others' newer text push everything up and be displayed last.


T.140 has information on how to handle erasure:

-------------------From T.140---------------------------

8.2 Erase last character
Purpose: Erase the last character sent from the display at the receiving end.
Code: BS: 0008.
Procedure: On the receiving end: Move the insertion point to the last character and erase it.
Combined characters are erased as a unit, with one BS erasing the whole character even if it is
combined from more than one component.
Control sequences (like CR LF) are erased in one operation.
NOTE – The same action shall be taken on the local display.

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

  /Gunnar


Brian

On Aug 27, 2019, at 9:52 AM, Gunnar Hellström <gunnar.hellstrom@omnitor.se> wrote:

Hi,

A topic is currently discussed in mmusic that is closely related to rum. it is WebRTC transport of real-time text.

The draft is draft-holmberg-mmusic-t140-usage-data-channel .

A good point to start reading could be:

https://mailarchive.ietf.org/arch/browse/mmusic/?gbt=1&q=draft-holmberg-mmusic-t140-usage-data-channel

Please check if the current state of the discussion suits rum!

The only issue that seems to be remaining is how to transport RTT data to and from a conference server that combines all traffic per media in a meeting in one data stream. That is not very elegantly specified for RFC 4103 transport of RTT in RTP either, so we might want to do a rapid action together to solve the multi-party RTT MCU case in a general and consistent way.

Regards

Gunnar

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288


-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288


-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------C8C7BCA112E5F5FF36B3C94E-- From nobody Wed Aug 28 06:47:50 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 446901201DB for ; Wed, 28 Aug 2019 06:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjU3hAhy-f-V for ; Wed, 28 Aug 2019 06:47:47 -0700 (PDT) Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED7981200E3 for ; Wed, 28 Aug 2019 06:47:46 -0700 (PDT) Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x7SDlhZr002411 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 28 Aug 2019 09:47:44 -0400 To: Brian Rosen Cc: rum@ietf.org References: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net> <64B406DC-4171-41EB-9171-A2AF7B78B409@brianrosen.net> <054dde2a-7fa1-9941-986c-f3b3d8c0f76e@alum.mit.edu> <831AD5BE-0D8F-4968-ABC7-B8D52BB8D4B0@brianrosen.net> From: Paul Kyzivat Message-ID: <30a05d55-3aee-3195-3e2e-9ac1d92b886d@alum.mit.edu> Date: Wed, 28 Aug 2019 09:47:43 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <831AD5BE-0D8F-4968-ABC7-B8D52BB8D4B0@brianrosen.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rum] RUE client credentials X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 13:47:48 -0000 On 8/27/19 3:32 PM, Brian Rosen wrote: > Getting back to this, sorry for the delay. > > > >> On Aug 12, 2019, at 3:40 PM, Paul Kyzivat wrote: >> >> On 8/7/19 5:14 PM, Brian Rosen wrote: >>> Working on these comments. I submitted a new version (-01) >>> I edited the doc to say the client cert is provisioned. Given that it’s provisioned by the entity that the provides the server, do I need to say anything else about validating the cert? >> >> I think we need to examine what the goal is here, and whether it is being achieved. I don't think enough is said to decide. >> >> This client cert mechanism was first added way back when (2015 I think). IIRC, the motivation was because the providers wanted to restrict access to RUE *implementations* that have passed interoperability testing, in order to reduce the problems of dealing with buggy implementations or attackers. > I think you are confusing validating an implementation from authenticating a user. The notion of mutual auth with a per-device cert is completely separate from some notion of “signing” an implementations code. No. You can argue that the client cert mechanism in not an appropriate mechanism for this, but it was the intent when the mechanism was proposed. I can see how this might be confused if you weren't there at the time. And perhaps the thinking about it has evolved since it was first included. I wasn't party to what happened during 2016-18. IIUC the providers still want this - a way to screen out RUE *implementations* that have not passed their testing. However, I don't know how to achieve that goal. And I'm inclined to think that it is an unreasonable expectation. It is akin to web site operators asking for a way to screen out any browser implementations that they haven't already tested against. > We can decide we don’t want the option of having mutual auth. Clearly there is need for some mechanism to securely associate a RUE with an account at the provider and a phone number. And this needs to work with devices that are persistently connected. If a RUE suffers a power or network outage that is restored in the middle of the night then it should be able to reconnect without a user login so that it can be available for incoming calls. That was intended to be covered by passwords. But care must be taken to secure those. Thanks, Paul From nobody Wed Aug 28 07:15:53 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0DDB120043 for ; Wed, 28 Aug 2019 07:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wc7hPEl_26XQ for ; Wed, 28 Aug 2019 07:15:50 -0700 (PDT) Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA03A12001E for ; Wed, 28 Aug 2019 07:15:49 -0700 (PDT) Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x7SEFinJ004315 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 28 Aug 2019 10:15:45 -0400 To: Adam Roach , Brian Rosen Cc: rum@ietf.org References: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net> <64B406DC-4171-41EB-9171-A2AF7B78B409@brianrosen.net> <69F15B2A-0158-4D23-B090-642497E3BDC7@brianrosen.net> From: Paul Kyzivat Message-ID: <3fdefa0c-3a64-3445-8ceb-d293fe4b4831@alum.mit.edu> Date: Wed, 28 Aug 2019 10:15:44 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 14:15:52 -0000 Inline... On 8/27/19 5:57 PM, Adam Roach wrote: > I certainly have thoughts. The executive summary is that I personally > believe RUM should specify Opus as the one audio codec MTI, and match > RFC 7742's "Non-Browser" requirements for the video codec MTI. Rationale > below. > > From an interop perspective, the important thing is that any given > profile has (at least) one MTI video codec and (at least) one MTI audio > codec. I know there is a strong desire -- one that I share -- that these > endpoints can talk to/be implemented in web browsers without the need > for media transcoding. > > For audio: WebRTC selected G.711 and Opus as both MTI; the former > because it works without transcoding to landline PSTN destinations, and > the latter because it sounds much, much better. RUM could make the same > decision; or it could decide to move away from a codec that is as old as > I am and opt to designate Opus as the only MTI. Given that RUM > inherently needs to deploy into audio/video environments, backwards > compatibility with the PSTN seems to be unnecessary baggage. Please keep in mind where we are coming from. The RUM will be a new interface to the *existing* VRS infrastructure. That infrastructure currently has proprietary devices that serve the RUE function, deployed to VRS users and to Communications Assistants (CAs, Interpreters). These have G.711 MTI, and also *recommend* G.722.2. Making OPUS the only MTI audio codec would be problematic. > For video: While specifying either VP8 or H.264 would be sufficient for > system interop, and for interop with compliant WebRTC endpoints, I'd > really prefer not to re-live the WebRTC video codec wars. Concretely, > what I would propose is that RUM indicate that the video codec > requirements are defined to be identical to those defined for "WebRTC > Non-Browsers" in Section 5 of RFC 7742. It should be made clear that RUM > endpoints *are* *not* WebRTC Non-Browsers per se; merely that they > comply with the same video codec requirements as WebRTC Non-Browsers. Continuing my comment above, existing devices have H.264 Constrained Baseline Profile, Level 1.3, packetization mode 1 as the MTI codec. Odds are many of these devices aren't capable of VP8. We can't realistically require a wholesale swap out of existing devices before the RUE defined by RUM can work. We can *discuss* whether forcing the providers to transcode is a practical way forward. I'm dubious. Thanks, Paul > /a > > On 8/27/19 2:34 PM, Brian Rosen wrote: >> Well, we certainly want interoperability, and I think we can only get >> that with MTI codecs. >> >> I think we really are talking about a WebRTC-compatible endpoint, but >> we want interoperability with a WebRTC browser endpoint. >> >> Not sure how to say this.  Maybe Adam can help. >> >> Brian >> >>> On Aug 12, 2019, at 4:20 PM, Paul Kyzivat wrote: >>> >>> draft-rosen-rue-01 changes the video codec requirements. It now >>> simply references webrtc RFC7742. >>> >>> RFC7742 distinguishes three types of endpoints: "WebRTC browser", >>> "WebRTC non-browser", and "WebRTC-compatible endpoint". AFAIK it >>> assumes that each end is one of these. >>> >>> Is the expectation here that both the RUE and the provider comply >>> with one of these? In particular, that the provider may simply be a >>> "WebRTC-compatible endpoint? Notably: >>> >>>    "WebRTC-compatible endpoints" are free to implement any video codecs >>>    they see fit.  This follows logically from the definition of "WebRTC- >>>    compatible endpoint".  It is, of course, advisable to implement at >>>    least one of the video codecs that is mandated for WebRTC browsers, >>>    and implementors are encouraged to do so. >>> >>> Similarly, the audio requirements have been changed to reference >>> webrtc RFC7874. That one doesn't have the distinction between "WebRTC >>> browser", "WebRTC non-browser", and "WebRTC-compatible endpoint". It >>> applies the same requirements to all. In particular, it requires OPUS >>> support. I don't know why it doesn't make the same endpoint >>> distinctions as for video. >>> >>> I think simply referencing these documents isn't sufficient. Seems >>> like we need a more nuanced specification of what is required, though >>> we may still reference these docs with qualifications. >>> >>>     Thanks, >>>     Paul >>> >>> > > From nobody Wed Aug 28 07:38:15 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81C29120043 for ; Wed, 28 Aug 2019 07:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwopoZkhhGXa for ; Wed, 28 Aug 2019 07:38:11 -0700 (PDT) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A254F1200E3 for ; Wed, 28 Aug 2019 07:38:11 -0700 (PDT) Received: by mail-qt1-x830.google.com with SMTP id y26so3265912qto.4 for ; Wed, 28 Aug 2019 07:38:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=f/N6OiPUc/Ia94Wx9WQRsX+vLHHju3cPBwxIdDyxSJg=; b=MKMv6C+aUES0Y58QJR4oRPK7M+jGG7aMeHAWodIYgdNIF486WuZKB3TEj4Mtp72vXD YvpE1l+cxToy547Tx5i0f0Dd+611Pg6QWU3BqMdy7nTWma2JykiOgTFI1puWEck4GTIW E0WyVnwE1MBhBC+WqX7DSoVPdKHZA1xV1+qyuDNWeC3n+WZGDGMj1nTPDTMh0ZXrMpZe 5NxMbRP+ttGtHdFeAI6MgF3MD3+LSj0IGy40nA2fxKduvfqppJPE281JibFBgEEFQ+Bw RglKl8AnGs7iCzm9hIG8GFgVdHVsn4/iqEOoaEmcQeotzc54L3EblzFks2huVN0crZ+V reJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=f/N6OiPUc/Ia94Wx9WQRsX+vLHHju3cPBwxIdDyxSJg=; b=DoC3QhRKCWxeAFa9Mf5vaEfz0AI6zyoeCNWYNexmJgMJVFqT7dkNNUJ7dhnmPtHVoN en4lNS7Rwn3/9lKnxglprJ8SOp2NMtbcfC5cKRPikjsqbuF7FiScoSHxGWn0fyiR2Iit U72mXHjmQQWZjIagVTDm/MBXmel168bsH+6s6l73wlGdUZBGGzL0alfRVf+NDd5Orxq1 HZBV9AzY1IpDxaPhD/2QgaBb7ohAwmOrzmQO5m+kQLENkyGC40TXKeIEctf+IBL0CDSy HanaLj8qgdp47ZYBwkAakm8Q3YRc6QXaZj4l4kk3eGnniMk2aAMALQz8BjEgnKOxK7fI 9swA== X-Gm-Message-State: APjAAAUcHihkCHhuIbvbrKsdxrinKp6hKUW4BYdPfeEbFA5Mb4eORXUm eY5WWPEQs63NXQ+GgZcVdYydJULWEgE= X-Google-Smtp-Source: APXvYqxIcMhYlb4niF534mq8E95LWVBZQb8gDuiUYhbc55o6n8LtUOanGz6zcyHvTpyizpWGEScnkA== X-Received: by 2002:ac8:6bca:: with SMTP id b10mr4401663qtt.254.1567003090666; Wed, 28 Aug 2019 07:38:10 -0700 (PDT) Received: from brians-mbp-2369.lan ([24.154.122.195]) by smtp.gmail.com with ESMTPSA id x5sm1517963qka.7.2019.08.28.07.38.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Aug 2019 07:38:09 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Brian Rosen In-Reply-To: <3fdefa0c-3a64-3445-8ceb-d293fe4b4831@alum.mit.edu> Date: Wed, 28 Aug 2019 10:38:08 -0400 Cc: Adam Roach , rum@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <60DFA478-5042-41FD-87CD-DD2154D6B1E6@brianrosen.net> References: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net> <64B406DC-4171-41EB-9171-A2AF7B78B409@brianrosen.net> <69F15B2A-0158-4D23-B090-642497E3BDC7@brianrosen.net> <3fdefa0c-3a64-3445-8ceb-d293fe4b4831@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 14:38:14 -0000 If we require OPUS and G.711 as MTI and we require both H.264 and VP8 as = MTI, then we get backwards compatibility without transcoding and = forwards compatibility with WebRTC. Isn=E2=80=99t that what we want? Brian > On Aug 28, 2019, at 10:15 AM, Paul Kyzivat = wrote: >=20 > Inline... >=20 > On 8/27/19 5:57 PM, Adam Roach wrote: >> I certainly have thoughts. The executive summary is that I personally = believe RUM should specify Opus as the one audio codec MTI, and match = RFC 7742's "Non-Browser" requirements for the video codec MTI. Rationale = below. >> =46rom an interop perspective, the important thing is that any given = profile has (at least) one MTI video codec and (at least) one MTI audio = codec. I know there is a strong desire -- one that I share -- that these = endpoints can talk to/be implemented in web browsers without the need = for media transcoding. >> For audio: WebRTC selected G.711 and Opus as both MTI; the former = because it works without transcoding to landline PSTN destinations, and = the latter because it sounds much, much better. RUM could make the same = decision; or it could decide to move away from a codec that is as old as = I am and opt to designate Opus as the only MTI. Given that RUM = inherently needs to deploy into audio/video environments, backwards = compatibility with the PSTN seems to be unnecessary baggage. >=20 > Please keep in mind where we are coming from. The RUM will be a new = interface to the *existing* VRS infrastructure. That infrastructure = currently has proprietary devices that serve the RUE function, deployed = to VRS users and to Communications Assistants (CAs, Interpreters). These = have G.711 MTI, and also *recommend* G.722.2. >=20 > Making OPUS the only MTI audio codec would be problematic. >=20 >> For video: While specifying either VP8 or H.264 would be sufficient = for system interop, and for interop with compliant WebRTC endpoints, I'd = really prefer not to re-live the WebRTC video codec wars. Concretely, = what I would propose is that RUM indicate that the video codec = requirements are defined to be identical to those defined for "WebRTC = Non-Browsers" in Section 5 of RFC 7742. It should be made clear that RUM = endpoints *are* *not* WebRTC Non-Browsers per se; merely that they = comply with the same video codec requirements as WebRTC Non-Browsers. >=20 > Continuing my comment above, existing devices have H.264 Constrained = Baseline Profile, Level 1.3, packetization mode 1 as the MTI codec. Odds = are many of these devices aren't capable of VP8. >=20 > We can't realistically require a wholesale swap out of existing = devices before the RUE defined by RUM can work. We can *discuss* whether = forcing the providers to transcode is a practical way forward. I'm = dubious. >=20 > Thanks, > Paul >=20 >> /a >> On 8/27/19 2:34 PM, Brian Rosen wrote: >>> Well, we certainly want interoperability, and I think we can only = get that with MTI codecs. >>>=20 >>> I think we really are talking about a WebRTC-compatible endpoint, = but we want interoperability with a WebRTC browser endpoint. >>>=20 >>> Not sure how to say this. Maybe Adam can help. >>>=20 >>> Brian >>>=20 >>>> On Aug 12, 2019, at 4:20 PM, Paul Kyzivat = wrote: >>>>=20 >>>> draft-rosen-rue-01 changes the video codec requirements. It now = simply references webrtc RFC7742. >>>>=20 >>>> RFC7742 distinguishes three types of endpoints: "WebRTC browser", = "WebRTC non-browser", and "WebRTC-compatible endpoint". AFAIK it assumes = that each end is one of these. >>>>=20 >>>> Is the expectation here that both the RUE and the provider comply = with one of these? In particular, that the provider may simply be a = "WebRTC-compatible endpoint? Notably: >>>>=20 >>>> "WebRTC-compatible endpoints" are free to implement any video = codecs >>>> they see fit. This follows logically from the definition of = "WebRTC- >>>> compatible endpoint". It is, of course, advisable to implement = at >>>> least one of the video codecs that is mandated for WebRTC = browsers, >>>> and implementors are encouraged to do so. >>>>=20 >>>> Similarly, the audio requirements have been changed to reference = webrtc RFC7874. That one doesn't have the distinction between "WebRTC = browser", "WebRTC non-browser", and "WebRTC-compatible endpoint". It = applies the same requirements to all. In particular, it requires OPUS = support. I don't know why it doesn't make the same endpoint distinctions = as for video. >>>>=20 >>>> I think simply referencing these documents isn't sufficient. Seems = like we need a more nuanced specification of what is required, though we = may still reference these docs with qualifications. >>>>=20 >>>> Thanks, >>>> Paul >>>>=20 >>>>=20 >=20 From nobody Wed Aug 28 07:41:14 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B277120043 for ; Wed, 28 Aug 2019 07:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCj3YHRXHCTG for ; Wed, 28 Aug 2019 07:41:11 -0700 (PDT) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59A0412001E for ; Wed, 28 Aug 2019 07:41:11 -0700 (PDT) Received: by mail-qt1-x82a.google.com with SMTP id u34so3277280qte.2 for ; Wed, 28 Aug 2019 07:41:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vu6fEkgJmu2xJenq0CC1JB9Ui8V9fClaMhPlCNCOnUc=; b=LMptgLCGSf4kJZOCiGsPNuucEi8mUQgIn5Xdw9rCKKxXPs5mFbFsNGLpnvxesBaUAU okTNxaaN49Js641eCasoe2QkwR83UHR6EJ1IbW8H2azfQ6NiED9V9J6M83Wjg3EWD6Ed iGpeP11YZUB7ORbEwyGZsERwaR0DoAa5Z+kTxA0W96JSpXYhoOH4NB8ng01JAVa/1fxU //jDqdTo9KlDT1Jx/XnzdWhE0vXxm3EFWH2kplx6uY6MdbES3fFY+BP4Vlz5go56O3Zy UvnIIA5cmSL1FBW+VwFT6Gqayc2USHxlQoLn2OHk28KVsyHXkfv45Wm26+DNUaHGYrel xZoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vu6fEkgJmu2xJenq0CC1JB9Ui8V9fClaMhPlCNCOnUc=; b=fZC5rPgfSH8l976W6C7l7wP8SyckSRGQBLC2l/xgQGctOmWVYdZglEmUA6CJzgxapC HdNs1PArASiFuCgP2Wbt4vgQ7+uvkC1UT+VJ58k/T9NaBwe0BK4IxAxFe4RxkmtxB0OJ UrW5kYULsTspGux8fExnxQ2+HhyEne4qMnSvPEY1HhW7+vLTnboIW3IYYbiNUKMuv6Z5 Q5PYHFTvH3tXiD/uSFwmDkM5G27KYdKmOuyTksW/h4UOJpcD6a++CE9meCEtkAOuCxUL 9bzynhs5RuR6qT5S7ppcKmMD3bgMu2vsUnNBFF7xR74+126g0m9VHEox//LUNaTf46xn xV+A== X-Gm-Message-State: APjAAAXigwKAnq2A6WRIT+r45g09D+8c4t43nvG71jyN/eonzURa3Slb jsyrOWBB/+OOA22sVrI57653veJnHbA= X-Google-Smtp-Source: APXvYqzWr5VItMiiwrZg/nYUlaSoRaIkupaisTiAzO9Seg9cqtU+1KkiQz0+y4SlW1MnSBZShvsd7g== X-Received: by 2002:aed:31c2:: with SMTP id 60mr4198032qth.331.1567003270274; Wed, 28 Aug 2019 07:41:10 -0700 (PDT) Received: from brians-mbp-2369.lan ([24.154.122.195]) by smtp.gmail.com with ESMTPSA id o43sm1524606qto.63.2019.08.28.07.41.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Aug 2019 07:41:09 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Brian Rosen In-Reply-To: <30a05d55-3aee-3195-3e2e-9ac1d92b886d@alum.mit.edu> Date: Wed, 28 Aug 2019 10:41:08 -0400 Cc: rum@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <797A336B-0D32-4D4F-AF16-C5D8A4648D22@brianrosen.net> References: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net> <64B406DC-4171-41EB-9171-A2AF7B78B409@brianrosen.net> <054dde2a-7fa1-9941-986c-f3b3d8c0f76e@alum.mit.edu> <831AD5BE-0D8F-4968-ABC7-B8D52BB8D4B0@brianrosen.net> <30a05d55-3aee-3195-3e2e-9ac1d92b886d@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Rum] RUE client credentials X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 14:41:13 -0000 Ever since I=E2=80=99ve been working on this doc, the cert was for = mutual auth of the user, instead of username and password. =20 We get to use the IETF=E2=80=99s best practice here. Do we require a = RUM device to support mutual auth, or not? We=E2=80=99re always going = to support username and password for authentication. We get to decide what else. Brian > On Aug 28, 2019, at 9:47 AM, Paul Kyzivat = wrote: >=20 > On 8/27/19 3:32 PM, Brian Rosen wrote: >> Getting back to this, sorry for the delay. >>> On Aug 12, 2019, at 3:40 PM, Paul Kyzivat = wrote: >>>=20 >>> On 8/7/19 5:14 PM, Brian Rosen wrote: >>>> Working on these comments. I submitted a new version (-01) >>>> I edited the doc to say the client cert is provisioned. Given that = it=E2=80=99s provisioned by the entity that the provides the server, do = I need to say anything else about validating the cert? >>>=20 >>> I think we need to examine what the goal is here, and whether it is = being achieved. I don't think enough is said to decide. >>>=20 >>> This client cert mechanism was first added way back when (2015 I = think). IIRC, the motivation was because the providers wanted to = restrict access to RUE *implementations* that have passed = interoperability testing, in order to reduce the problems of dealing = with buggy implementations or attackers. >> I think you are confusing validating an implementation from = authenticating a user. The notion of mutual auth with a per-device cert = is completely separate from some notion of =E2=80=9Csigning=E2=80=9D an = implementations code. >=20 > No. You can argue that the client cert mechanism in not an appropriate = mechanism for this, but it was the intent when the mechanism was = proposed. >=20 > I can see how this might be confused if you weren't there at the time. = And perhaps the thinking about it has evolved since it was first = included. I wasn't party to what happened during 2016-18. >=20 > IIUC the providers still want this - a way to screen out RUE = *implementations* that have not passed their testing. However, I don't = know how to achieve that goal. And I'm inclined to think that it is an = unreasonable expectation. It is akin to web site operators asking for a = way to screen out any browser implementations that they haven't already = tested against. >=20 >> We can decide we don=E2=80=99t want the option of having mutual auth. >=20 > Clearly there is need for some mechanism to securely associate a RUE = with an account at the provider and a phone number. And this needs to = work with devices that are persistently connected. If a RUE suffers a = power or network outage that is restored in the middle of the night then = it should be able to reconnect without a user login so that it can be = available for incoming calls. >=20 > That was intended to be covered by passwords. But care must be taken = to secure those. >=20 > Thanks, > Paul From nobody Wed Aug 28 08:15:05 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD30120043 for ; Wed, 28 Aug 2019 08:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnS5ikTv8K99 for ; Wed, 28 Aug 2019 08:15:00 -0700 (PDT) Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 935A212000F for ; Wed, 28 Aug 2019 08:15:00 -0700 (PDT) Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x7SFEvD1008021 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 28 Aug 2019 11:14:58 -0400 To: Brian Rosen Cc: rum@ietf.org References: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net> <64B406DC-4171-41EB-9171-A2AF7B78B409@brianrosen.net> <054dde2a-7fa1-9941-986c-f3b3d8c0f76e@alum.mit.edu> <831AD5BE-0D8F-4968-ABC7-B8D52BB8D4B0@brianrosen.net> <30a05d55-3aee-3195-3e2e-9ac1d92b886d@alum.mit.edu> <797A336B-0D32-4D4F-AF16-C5D8A4648D22@brianrosen.net> From: Paul Kyzivat Message-ID: <414e3fa5-ae0f-a632-af75-f34f2842d85c@alum.mit.edu> Date: Wed, 28 Aug 2019 11:14:57 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <797A336B-0D32-4D4F-AF16-C5D8A4648D22@brianrosen.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rum] RUE client credentials X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 15:15:03 -0000 On 8/28/19 10:41 AM, Brian Rosen wrote: > Ever since I’ve been working on this doc, the cert was for mutual auth of the user, instead of username and password. OK. As long as we are clear that is what it is about. > We get to use the IETF’s best practice here. Do we require a RUM device to support mutual auth, or not? We’re always going to support username and password for authentication. > We get to decide what else. We've already been dinged about passing passwords around in configuration. Is it better if we use a password to fetch an initial device configuration that includes certs? I think we need to have a new discussion of the overall security setup, including access to address book and video mail. Are they all under a single credential, or separate. Also how passwords expire and are refreshed/updated, etc. IIRC there were concerns about all of these. Thanks, Paul > Brian > >> On Aug 28, 2019, at 9:47 AM, Paul Kyzivat wrote: >> >> On 8/27/19 3:32 PM, Brian Rosen wrote: >>> Getting back to this, sorry for the delay. >>>> On Aug 12, 2019, at 3:40 PM, Paul Kyzivat wrote: >>>> >>>> On 8/7/19 5:14 PM, Brian Rosen wrote: >>>>> Working on these comments. I submitted a new version (-01) >>>>> I edited the doc to say the client cert is provisioned. Given that it’s provisioned by the entity that the provides the server, do I need to say anything else about validating the cert? >>>> >>>> I think we need to examine what the goal is here, and whether it is being achieved. I don't think enough is said to decide. >>>> >>>> This client cert mechanism was first added way back when (2015 I think). IIRC, the motivation was because the providers wanted to restrict access to RUE *implementations* that have passed interoperability testing, in order to reduce the problems of dealing with buggy implementations or attackers. >>> I think you are confusing validating an implementation from authenticating a user. The notion of mutual auth with a per-device cert is completely separate from some notion of “signing” an implementations code. >> >> No. You can argue that the client cert mechanism in not an appropriate mechanism for this, but it was the intent when the mechanism was proposed. >> >> I can see how this might be confused if you weren't there at the time. And perhaps the thinking about it has evolved since it was first included. I wasn't party to what happened during 2016-18. >> >> IIUC the providers still want this - a way to screen out RUE *implementations* that have not passed their testing. However, I don't know how to achieve that goal. And I'm inclined to think that it is an unreasonable expectation. It is akin to web site operators asking for a way to screen out any browser implementations that they haven't already tested against. >> >>> We can decide we don’t want the option of having mutual auth. >> >> Clearly there is need for some mechanism to securely associate a RUE with an account at the provider and a phone number. And this needs to work with devices that are persistently connected. If a RUE suffers a power or network outage that is restored in the middle of the night then it should be able to reconnect without a user login so that it can be available for incoming calls. >> >> That was intended to be covered by passwords. But care must be taken to secure those. >> >> Thanks, >> Paul > > From nobody Wed Aug 28 08:25:56 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77DDC1200E3 for ; Wed, 28 Aug 2019 08:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOsyFrNXgTqh for ; Wed, 28 Aug 2019 08:25:52 -0700 (PDT) Received: from biz221.inmotionhosting.com (biz221.inmotionhosting.com [144.208.71.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7B4812000F for ; Wed, 28 Aug 2019 08:25:52 -0700 (PDT) Received: from [104.129.194.185] (port=25714 helo=[172.20.17.144]) by biz221.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1i2zpM-000YA0-HN for rum@ietf.org; Wed, 28 Aug 2019 08:25:50 -0700 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_5C2E0DC2-46CA-4638-A504-AB5D302A6DFF"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 28 Aug 2019 11:25:38 -0400 References: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net> <64B406DC-4171-41EB-9171-A2AF7B78B409@brianrosen.net> <69F15B2A-0158-4D23-B090-642497E3BDC7@brianrosen.net> <3fdefa0c-3a64-3445-8ceb-d293fe4b4831@alum.mit.edu> <60DFA478-5042-41FD-87CD-DD2154D6B1E6@brianrosen.net> To: rum@ietf.org In-Reply-To: <60DFA478-5042-41FD-87CD-DD2154D6B1E6@brianrosen.net> Message-Id: X-Mailer: Apple Mail (2.3445.104.11) X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz221.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz221.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Authenticated-Sender: biz221.inmotionhosting.com: eburger@standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 15:25:56 -0000 --Apple-Mail=_5C2E0DC2-46CA-4638-A504-AB5D302A6DFF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I guess the question is whether we want today=E2=80=99s devices to have = a chance of being RUM compatible. I don=E2=80=99t think anyone will be = surprised if a five-year-old device is history. Is it realistic for = current devices to get VP8 upgrade? [Would be nice for some = manufacturers or others building such devices to pipe in here.] > On Aug 28, 2019, at 10:38 AM, Brian Rosen wrote: >=20 > If we require OPUS and G.711 as MTI and we require both H.264 and VP8 = as MTI, then we get backwards compatibility without transcoding and = forwards compatibility with WebRTC. Isn=E2=80=99t that what we want? >=20 > Brian >=20 >> On Aug 28, 2019, at 10:15 AM, Paul Kyzivat = wrote: >>=20 >> Inline... >>=20 >> On 8/27/19 5:57 PM, Adam Roach wrote: >>> I certainly have thoughts. The executive summary is that I = personally believe RUM should specify Opus as the one audio codec MTI, = and match RFC 7742's "Non-Browser" requirements for the video codec MTI. = Rationale below. >>> =46rom an interop perspective, the important thing is that any given = profile has (at least) one MTI video codec and (at least) one MTI audio = codec. I know there is a strong desire -- one that I share -- that these = endpoints can talk to/be implemented in web browsers without the need = for media transcoding. >>> For audio: WebRTC selected G.711 and Opus as both MTI; the former = because it works without transcoding to landline PSTN destinations, and = the latter because it sounds much, much better. RUM could make the same = decision; or it could decide to move away from a codec that is as old as = I am and opt to designate Opus as the only MTI. Given that RUM = inherently needs to deploy into audio/video environments, backwards = compatibility with the PSTN seems to be unnecessary baggage. >>=20 >> Please keep in mind where we are coming from. The RUM will be a new = interface to the *existing* VRS infrastructure. That infrastructure = currently has proprietary devices that serve the RUE function, deployed = to VRS users and to Communications Assistants (CAs, Interpreters). These = have G.711 MTI, and also *recommend* G.722.2. >>=20 >> Making OPUS the only MTI audio codec would be problematic. >>=20 >>> For video: While specifying either VP8 or H.264 would be sufficient = for system interop, and for interop with compliant WebRTC endpoints, I'd = really prefer not to re-live the WebRTC video codec wars. Concretely, = what I would propose is that RUM indicate that the video codec = requirements are defined to be identical to those defined for "WebRTC = Non-Browsers" in Section 5 of RFC 7742. It should be made clear that RUM = endpoints *are* *not* WebRTC Non-Browsers per se; merely that they = comply with the same video codec requirements as WebRTC Non-Browsers. >>=20 >> Continuing my comment above, existing devices have H.264 Constrained = Baseline Profile, Level 1.3, packetization mode 1 as the MTI codec. Odds = are many of these devices aren't capable of VP8. >>=20 >> We can't realistically require a wholesale swap out of existing = devices before the RUE defined by RUM can work. We can *discuss* whether = forcing the providers to transcode is a practical way forward. I'm = dubious. >>=20 >> Thanks, >> Paul >>=20 >>> /a >>> On 8/27/19 2:34 PM, Brian Rosen wrote: >>>> Well, we certainly want interoperability, and I think we can only = get that with MTI codecs. >>>>=20 >>>> I think we really are talking about a WebRTC-compatible endpoint, = but we want interoperability with a WebRTC browser endpoint. >>>>=20 >>>> Not sure how to say this. Maybe Adam can help. >>>>=20 >>>> Brian >>>>=20 >>>>> On Aug 12, 2019, at 4:20 PM, Paul Kyzivat = wrote: >>>>>=20 >>>>> draft-rosen-rue-01 changes the video codec requirements. It now = simply references webrtc RFC7742. >>>>>=20 >>>>> RFC7742 distinguishes three types of endpoints: "WebRTC browser", = "WebRTC non-browser", and "WebRTC-compatible endpoint". AFAIK it assumes = that each end is one of these. >>>>>=20 >>>>> Is the expectation here that both the RUE and the provider comply = with one of these? In particular, that the provider may simply be a = "WebRTC-compatible endpoint? Notably: >>>>>=20 >>>>> "WebRTC-compatible endpoints" are free to implement any video = codecs >>>>> they see fit. This follows logically from the definition of = "WebRTC- >>>>> compatible endpoint". It is, of course, advisable to implement = at >>>>> least one of the video codecs that is mandated for WebRTC = browsers, >>>>> and implementors are encouraged to do so. >>>>>=20 >>>>> Similarly, the audio requirements have been changed to reference = webrtc RFC7874. That one doesn't have the distinction between "WebRTC = browser", "WebRTC non-browser", and "WebRTC-compatible endpoint". It = applies the same requirements to all. In particular, it requires OPUS = support. I don't know why it doesn't make the same endpoint distinctions = as for video. >>>>>=20 >>>>> I think simply referencing these documents isn't sufficient. Seems = like we need a more nuanced specification of what is required, though we = may still reference these docs with qualifications. >>>>>=20 >>>>> Thanks, >>>>> Paul >>>>>=20 >>>>>=20 >>=20 >=20 > -- > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum --Apple-Mail=_5C2E0DC2-46CA-4638-A504-AB5D302A6DFF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEfEc/N7T7IfiAuDEHDDCGh758rskFAl1mnPIACgkQDDCGh758 rsn8ZA/9FHMis0JGdKy6sDFKhgbyEcwn+vWWcbEbf2w0Z0N3uU9nVTVbR8p5TlFI 06AtCZvSZcLyrsoU0aj5vG34bWN3l2x6pFlXmF68vUkE8CjOf9AilS1NhZuUYFEo UuglswoNQjOZJHKAqYfahk3lTJZ4jC483c3F5V9UcbYpFTjtJeoTm+Q2+LKMNczZ vL6gXQnOsnCPtW7xOthpk7bVk+uzNvkE3NgAYGt6aiV0Y7r22dn1elBB/tmRaCT4 xECXhIm+aK3jq3KasU8/GJ+58UZdC6qFQGomAfGj8mzPodQoCbZi0ABzJbA6tA4E lMHPgVtterMScPU5ZISm9v3Nv7qoZaNkKDpiXVyadriXjbcIYaBQhKCF01U8itut oOEAdLnchO3u9ZHcEbY0JloJTbiZYtGjuXhEMEgN8FE/8JK03DumQx58vXerrrUV Xxwxl1j9xcPxFsDWfoH2VSkkY4G/BtNXKNTdvjUIhlFFfJmZ9Cc3r5DUv+sowMUf SgQutJmWcIufk2DTeh5FFEL0RLFoZNJ6yWO1uPszT3AgXF5lLG6Xypfe9ETzOX+8 RrQFYPLw1tnBTCWWN0c1mlDEIviBrpDVSujPowSLO8JBX+/9OTTE7QcTe9D4l4vD IhGMyX8Kh4xDqpGua5AiglXDdeJcVzYDDC7ejQYJAuYX3T33fXk= =E6u5 -----END PGP SIGNATURE----- --Apple-Mail=_5C2E0DC2-46CA-4638-A504-AB5D302A6DFF-- From nobody Wed Aug 28 08:34:33 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D04E120059 for ; Wed, 28 Aug 2019 08:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCh2ai9FeRDQ for ; Wed, 28 Aug 2019 08:34:29 -0700 (PDT) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57A4012000F for ; Wed, 28 Aug 2019 08:34:29 -0700 (PDT) Received: by mail-qt1-x835.google.com with SMTP id v38so32180qtb.0 for ; Wed, 28 Aug 2019 08:34:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ifVq4NTFOnjHPBSrA58hhAfcIq4H5vBvILs8Q117iJg=; b=PE4sUyQ292KjBddPFR6H+YGWlOXXBK4SqdGTOZvUWB55mGTanu1ElASROxlvCJ/I/w KCcA1cHBIfVS0q05NLja1IIF8A/2C4U6qAeMqAO531jhPIFeXyc5qk1QKt8amC+y/eCb bmGPJjDrHbga+q006966xDARwVB1QzkjfNMHYjQjhqeckPHVEezcLkiqm4iizn5/V9qe Bh858HxKz2czvUReUnuL17n6q0hIADom5w9lILtLoOMlegv4R+QMI79jSnXqndHWPFsu vw5z+TTjPhgEP37MfAeKTPwyjMg0MqnwCAEl2g5Tecctr6oyAbWTAhbgcbG/1Aq7Hp34 dJjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ifVq4NTFOnjHPBSrA58hhAfcIq4H5vBvILs8Q117iJg=; b=XjzLs3aAIp4tdyMgTkm9tYQQE2ygJgPI6Z4fMNGDquL1yGF/CnMo3smWQJC8GGvkn0 2JYmBeshAsLDMAGIDGS02tK4Yk0ALgYL3Ji4HI7N1gKSv/BovhnRuj62ODPyrIbBR3Ke eLY2hSBYDE9v8i9ZRI1GQMLfYeHN5c9XWaM1FAN0chZf00Vhj7ahDP69UtzgaKzp4W5Y n8xL3JbuJStCe91bo7qB5WLQ8OIEwYMB0oco0T66NV/O7Gb6jKmBttLNPLpfxEhScifV CgxDD9oDH/kZ137HScNm1unPu6fktTkrxYSdYMBPCwNXvTBLsMsneLYf2xUIAXrVQMdx VBNA== X-Gm-Message-State: APjAAAU4LqkbiDl/n0I7UbVjbnFsfjjXFCHEIzMzZ+4W6q55FnyFeKTd kw9K2t6VxQ1egwa/KiraSDbHjb2D9z0= X-Google-Smtp-Source: APXvYqwzoE6iVijSMdf70FPSr4YH56WU8fsLUaVf0vib1t7AqMIfPn1s4pUyv0w/w9aPe0Eoaq8Wig== X-Received: by 2002:ac8:4789:: with SMTP id k9mr4833476qtq.41.1567006468056; Wed, 28 Aug 2019 08:34:28 -0700 (PDT) Received: from brians-mbp-2369.lan ([24.154.122.195]) by smtp.gmail.com with ESMTPSA id w15sm1377551qkj.23.2019.08.28.08.34.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Aug 2019 08:34:27 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Brian Rosen In-Reply-To: <414e3fa5-ae0f-a632-af75-f34f2842d85c@alum.mit.edu> Date: Wed, 28 Aug 2019 11:34:25 -0400 Cc: rum@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <26090EC8-51D7-4BBA-BA37-838328226DD6@brianrosen.net> References: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net> <64B406DC-4171-41EB-9171-A2AF7B78B409@brianrosen.net> <054dde2a-7fa1-9941-986c-f3b3d8c0f76e@alum.mit.edu> <831AD5BE-0D8F-4968-ABC7-B8D52BB8D4B0@brianrosen.net> <30a05d55-3aee-3195-3e2e-9ac1d92b886d@alum.mit.edu> <797A336B-0D32-4D4F-AF16-C5D8A4648D22@brianrosen.net> <414e3fa5-ae0f-a632-af75-f34f2842d85c@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Rum] RUE client credentials X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 15:34:31 -0000 Good discussion to have. A cert is public, so no real privacy issues other than what is in the = identity (which a username gives you also). How the private key = associated with the cert is handled is of concern, but I imagine it=E2=80=99= s the usual CSR thing which never reveals the key. But we do need some = kind of security on the provisioning information itself. If there was a = cert, then the provisioning could be signed by or for the rue. I kind = of like that. It=E2=80=99s all new mechanism, but maybe worthwhile. = You run code on the device that creates the CSR, upload it, and download = the cert. Then the rue can sign the provisioning file (which really = doesn=E2=80=99t need the cert, so it could do that any time). There are two contact maintenance mechanisms in the draft now - file = upload/download and CardDAV. CardDAV is okay security-wise. File = upload and download is from a provider, so we could have providers sign = the file with the cert so only that user could verify it. Brian > On Aug 28, 2019, at 11:14 AM, Paul Kyzivat = wrote: >=20 > On 8/28/19 10:41 AM, Brian Rosen wrote: >> Ever since I=E2=80=99ve been working on this doc, the cert was for = mutual auth of the user, instead of username and password. >=20 > OK. As long as we are clear that is what it is about. >=20 >> We get to use the IETF=E2=80=99s best practice here. Do we require a = RUM device to support mutual auth, or not? We=E2=80=99re always going = to support username and password for authentication. >> We get to decide what else. >=20 > We've already been dinged about passing passwords around in = configuration. Is it better if we use a password to fetch an initial = device configuration that includes certs? >=20 > I think we need to have a new discussion of the overall security = setup, including access to address book and video mail. Are they all = under a single credential, or separate. Also how passwords expire and = are refreshed/updated, etc. IIRC there were concerns about all of these. >=20 > Thanks, > Paul >=20 >> Brian >>> On Aug 28, 2019, at 9:47 AM, Paul Kyzivat = wrote: >>>=20 >>> On 8/27/19 3:32 PM, Brian Rosen wrote: >>>> Getting back to this, sorry for the delay. >>>>> On Aug 12, 2019, at 3:40 PM, Paul Kyzivat = wrote: >>>>>=20 >>>>> On 8/7/19 5:14 PM, Brian Rosen wrote: >>>>>> Working on these comments. I submitted a new version (-01) >>>>>> I edited the doc to say the client cert is provisioned. Given = that it=E2=80=99s provisioned by the entity that the provides the = server, do I need to say anything else about validating the cert? >>>>>=20 >>>>> I think we need to examine what the goal is here, and whether it = is being achieved. I don't think enough is said to decide. >>>>>=20 >>>>> This client cert mechanism was first added way back when (2015 I = think). IIRC, the motivation was because the providers wanted to = restrict access to RUE *implementations* that have passed = interoperability testing, in order to reduce the problems of dealing = with buggy implementations or attackers. >>>> I think you are confusing validating an implementation from = authenticating a user. The notion of mutual auth with a per-device cert = is completely separate from some notion of =E2=80=9Csigning=E2=80=9D an = implementations code. >>>=20 >>> No. You can argue that the client cert mechanism in not an = appropriate mechanism for this, but it was the intent when the mechanism = was proposed. >>>=20 >>> I can see how this might be confused if you weren't there at the = time. And perhaps the thinking about it has evolved since it was first = included. I wasn't party to what happened during 2016-18. >>>=20 >>> IIUC the providers still want this - a way to screen out RUE = *implementations* that have not passed their testing. However, I don't = know how to achieve that goal. And I'm inclined to think that it is an = unreasonable expectation. It is akin to web site operators asking for a = way to screen out any browser implementations that they haven't already = tested against. >>>=20 >>>> We can decide we don=E2=80=99t want the option of having mutual = auth. >>>=20 >>> Clearly there is need for some mechanism to securely associate a RUE = with an account at the provider and a phone number. And this needs to = work with devices that are persistently connected. If a RUE suffers a = power or network outage that is restored in the middle of the night then = it should be able to reconnect without a user login so that it can be = available for incoming calls. >>>=20 >>> That was intended to be covered by passwords. But care must be taken = to secure those. >>>=20 >>> Thanks, >>> Paul >=20 From nobody Wed Aug 28 08:37:02 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E35CA1200E3 for ; Wed, 28 Aug 2019 08:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5RJH48ozdUY for ; Wed, 28 Aug 2019 08:36:57 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 414CA120059 for ; Wed, 28 Aug 2019 08:36:57 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id t12so3472383qtp.9 for ; Wed, 28 Aug 2019 08:36:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ce9KflWj9gq/A6MMHab4K5MjEIPSMHJTnMmNn0wdZK0=; b=gm4uxDsG6jaxwpsr3e89Ss86C4vsKWVKxWQaHt1S0EeszsfEjTRo/dHR113DPocvh0 HstGT8XPChFms7phWldd+/Dec2por9kZK84gMgpG9Tm1wD3zZH3ydaEeq2i1fKHbLQk9 BBuydz4ZYITPGzcCf4Do58VV2kkKTdzkiTiU3jyPp3IlNtpXwsJ5wHN7sU8WwkelpzQa cxUNP3FQxj32dnEHnYfGxPtzQYtD2XdoTqv3i/R9798yGaZKJThutlWXl3tG1cfmdaOT QKllf8gm0/F4m51LvJFtFDhXOw+6UPlre/7BlK5gcVvWg1ku+ch79ngF2xCMnH3FYnd7 SdjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ce9KflWj9gq/A6MMHab4K5MjEIPSMHJTnMmNn0wdZK0=; b=diSdOkb1f9zQfDadxr3JkZdyRAJpgW+P4jpx9Qyjv8TLvDk+2AwWI8ObMwawNsqVx2 eR7DtOtV7P5q37gXwWfqiNl35IX1jmTrwslncNb6Lz2TzkfwUcGKi3c4/gna6sAOpvlG KNjvghzL+UbofciCCqzF1+aOOUBs3wC4AqEGNa+Yp5SgcbGoRbAM5Tk8Y0YkncmnzLWE FOGjA3ozRJJZnlWqO1qkv7MPUxG1oxqIqowcB2bG4ZAGek3ccPQnVk02f7vkIgs4oTYr 5URQWICkRCjaXdiy2sH6aKsmAsS4wnSeEBJM4VAgqJJ68jT4IllXFR9nB98c6w3L+FQs v7DQ== X-Gm-Message-State: APjAAAV5yaY1DdD9FKnW1a8WFgxuAEACapRD8IJngD/rG9iGnzcPTZTW po5YLH6yxVhdsa0/9tFXtcXPGrfbNQQ= X-Google-Smtp-Source: APXvYqwel1hCWLWPHLF99z0efQscK9acodx8xjMTLqoddD862DU55uklh5mycs9AVtaqEtXUAtAwMw== X-Received: by 2002:ac8:4292:: with SMTP id o18mr4931810qtl.336.1567006616122; Wed, 28 Aug 2019 08:36:56 -0700 (PDT) Received: from brians-mbp-2369.lan ([24.154.122.195]) by smtp.gmail.com with ESMTPSA id y23sm1394494qki.118.2019.08.28.08.36.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Aug 2019 08:36:55 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Brian Rosen In-Reply-To: Date: Wed, 28 Aug 2019 11:36:51 -0400 Cc: rum@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <960A8AE9-156C-4C9A-BE5A-BA021A0F159E@brianrosen.net> References: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net> <64B406DC-4171-41EB-9171-A2AF7B78B409@brianrosen.net> <69F15B2A-0158-4D23-B090-642497E3BDC7@brianrosen.net> <3fdefa0c-3a64-3445-8ceb-d293fe4b4831@alum.mit.edu> <60DFA478-5042-41FD-87CD-DD2154D6B1E6@brianrosen.net> To: Eric Burger X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 15:37:00 -0000 That wouldn=E2=80=99t be needed, right? If rum devices implemented both = H.264 and VP8, and existing devices only implemented H.264, then we have = backwards compatibility. There are some details (profile, = packetization, ..) > On Aug 28, 2019, at 11:25 AM, Eric Burger = wrote: >=20 > I guess the question is whether we want today=E2=80=99s devices to = have a chance of being RUM compatible. I don=E2=80=99t think anyone will = be surprised if a five-year-old device is history. Is it realistic for = current devices to get VP8 upgrade? [Would be nice for some = manufacturers or others building such devices to pipe in here.] >=20 >> On Aug 28, 2019, at 10:38 AM, Brian Rosen wrote: >>=20 >> If we require OPUS and G.711 as MTI and we require both H.264 and VP8 = as MTI, then we get backwards compatibility without transcoding and = forwards compatibility with WebRTC. Isn=E2=80=99t that what we want? >>=20 >> Brian >>=20 >>> On Aug 28, 2019, at 10:15 AM, Paul Kyzivat = wrote: >>>=20 >>> Inline... >>>=20 >>> On 8/27/19 5:57 PM, Adam Roach wrote: >>>> I certainly have thoughts. The executive summary is that I = personally believe RUM should specify Opus as the one audio codec MTI, = and match RFC 7742's "Non-Browser" requirements for the video codec MTI. = Rationale below. >>>> =46rom an interop perspective, the important thing is that any = given profile has (at least) one MTI video codec and (at least) one MTI = audio codec. I know there is a strong desire -- one that I share -- that = these endpoints can talk to/be implemented in web browsers without the = need for media transcoding. >>>> For audio: WebRTC selected G.711 and Opus as both MTI; the former = because it works without transcoding to landline PSTN destinations, and = the latter because it sounds much, much better. RUM could make the same = decision; or it could decide to move away from a codec that is as old as = I am and opt to designate Opus as the only MTI. Given that RUM = inherently needs to deploy into audio/video environments, backwards = compatibility with the PSTN seems to be unnecessary baggage. >>>=20 >>> Please keep in mind where we are coming from. The RUM will be a new = interface to the *existing* VRS infrastructure. That infrastructure = currently has proprietary devices that serve the RUE function, deployed = to VRS users and to Communications Assistants (CAs, Interpreters). These = have G.711 MTI, and also *recommend* G.722.2. >>>=20 >>> Making OPUS the only MTI audio codec would be problematic. >>>=20 >>>> For video: While specifying either VP8 or H.264 would be sufficient = for system interop, and for interop with compliant WebRTC endpoints, I'd = really prefer not to re-live the WebRTC video codec wars. Concretely, = what I would propose is that RUM indicate that the video codec = requirements are defined to be identical to those defined for "WebRTC = Non-Browsers" in Section 5 of RFC 7742. It should be made clear that RUM = endpoints *are* *not* WebRTC Non-Browsers per se; merely that they = comply with the same video codec requirements as WebRTC Non-Browsers. >>>=20 >>> Continuing my comment above, existing devices have H.264 Constrained = Baseline Profile, Level 1.3, packetization mode 1 as the MTI codec. Odds = are many of these devices aren't capable of VP8. >>>=20 >>> We can't realistically require a wholesale swap out of existing = devices before the RUE defined by RUM can work. We can *discuss* whether = forcing the providers to transcode is a practical way forward. I'm = dubious. >>>=20 >>> Thanks, >>> Paul >>>=20 >>>> /a >>>> On 8/27/19 2:34 PM, Brian Rosen wrote: >>>>> Well, we certainly want interoperability, and I think we can only = get that with MTI codecs. >>>>>=20 >>>>> I think we really are talking about a WebRTC-compatible endpoint, = but we want interoperability with a WebRTC browser endpoint. >>>>>=20 >>>>> Not sure how to say this. Maybe Adam can help. >>>>>=20 >>>>> Brian >>>>>=20 >>>>>> On Aug 12, 2019, at 4:20 PM, Paul Kyzivat = wrote: >>>>>>=20 >>>>>> draft-rosen-rue-01 changes the video codec requirements. It now = simply references webrtc RFC7742. >>>>>>=20 >>>>>> RFC7742 distinguishes three types of endpoints: "WebRTC browser", = "WebRTC non-browser", and "WebRTC-compatible endpoint". AFAIK it assumes = that each end is one of these. >>>>>>=20 >>>>>> Is the expectation here that both the RUE and the provider comply = with one of these? In particular, that the provider may simply be a = "WebRTC-compatible endpoint? Notably: >>>>>>=20 >>>>>> "WebRTC-compatible endpoints" are free to implement any video = codecs >>>>>> they see fit. This follows logically from the definition of = "WebRTC- >>>>>> compatible endpoint". It is, of course, advisable to implement = at >>>>>> least one of the video codecs that is mandated for WebRTC = browsers, >>>>>> and implementors are encouraged to do so. >>>>>>=20 >>>>>> Similarly, the audio requirements have been changed to reference = webrtc RFC7874. That one doesn't have the distinction between "WebRTC = browser", "WebRTC non-browser", and "WebRTC-compatible endpoint". It = applies the same requirements to all. In particular, it requires OPUS = support. I don't know why it doesn't make the same endpoint distinctions = as for video. >>>>>>=20 >>>>>> I think simply referencing these documents isn't sufficient. = Seems like we need a more nuanced specification of what is required, = though we may still reference these docs with qualifications. >>>>>>=20 >>>>>> Thanks, >>>>>> Paul >>>>>>=20 >>>>>>=20 >>>=20 >>=20 >> -- >> Rum mailing list >> Rum@ietf.org >> https://www.ietf.org/mailman/listinfo/rum >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum From nobody Wed Aug 28 08:48:26 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C4F1200E3 for ; Wed, 28 Aug 2019 08:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDEtRDFdyRU8 for ; Wed, 28 Aug 2019 08:48:21 -0700 (PDT) Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02A211200B3 for ; Wed, 28 Aug 2019 08:48:20 -0700 (PDT) Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x7SFmIXL010053 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 28 Aug 2019 11:48:19 -0400 To: rum@ietf.org References: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net> <64B406DC-4171-41EB-9171-A2AF7B78B409@brianrosen.net> <69F15B2A-0158-4D23-B090-642497E3BDC7@brianrosen.net> <3fdefa0c-3a64-3445-8ceb-d293fe4b4831@alum.mit.edu> <60DFA478-5042-41FD-87CD-DD2154D6B1E6@brianrosen.net> From: Paul Kyzivat Message-ID: <1fed09ae-8a03-2d82-3784-c4b47095cff0@alum.mit.edu> Date: Wed, 28 Aug 2019 11:48:18 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 15:48:23 -0000 On 8/28/19 11:25 AM, Eric Burger wrote: > I guess the question is whether we want today’s devices to have a chance of being RUM compatible. I don’t think anyone will be surprised if a five-year-old device is history. Is it realistic for current devices to get VP8 upgrade? [Would be nice for some manufacturers or others building such devices to pipe in here.] Lets be clear about what we mean by "RUM compatible". When Henning and I were working on this with the providers in 2014 and 2015 there was an expectation that the providers would be required to support the defined RUE devices, but they would also be permitted to support their existing proprietary devices. The RUE devices could have requirements that their existing devices don't meet. But calls between the two were expected to work. There was great consternation when subsequently the FCC issued a proposed order that said only VRS calls involving RUE-compatible devices would be compensated. (But that was in 2015. I presume it has not happened.) If there is an intent to exclude non-RUM-compliant devices from use in VRS calls then there needs to be a migration plan to get from here to there. Thanks, Paul >> On Aug 28, 2019, at 10:38 AM, Brian Rosen wrote: >> >> If we require OPUS and G.711 as MTI and we require both H.264 and VP8 as MTI, then we get backwards compatibility without transcoding and forwards compatibility with WebRTC. Isn’t that what we want? >> >> Brian >> >>> On Aug 28, 2019, at 10:15 AM, Paul Kyzivat wrote: >>> >>> Inline... >>> >>> On 8/27/19 5:57 PM, Adam Roach wrote: >>>> I certainly have thoughts. The executive summary is that I personally believe RUM should specify Opus as the one audio codec MTI, and match RFC 7742's "Non-Browser" requirements for the video codec MTI. Rationale below. >>>> From an interop perspective, the important thing is that any given profile has (at least) one MTI video codec and (at least) one MTI audio codec. I know there is a strong desire -- one that I share -- that these endpoints can talk to/be implemented in web browsers without the need for media transcoding. >>>> For audio: WebRTC selected G.711 and Opus as both MTI; the former because it works without transcoding to landline PSTN destinations, and the latter because it sounds much, much better. RUM could make the same decision; or it could decide to move away from a codec that is as old as I am and opt to designate Opus as the only MTI. Given that RUM inherently needs to deploy into audio/video environments, backwards compatibility with the PSTN seems to be unnecessary baggage. >>> >>> Please keep in mind where we are coming from. The RUM will be a new interface to the *existing* VRS infrastructure. That infrastructure currently has proprietary devices that serve the RUE function, deployed to VRS users and to Communications Assistants (CAs, Interpreters). These have G.711 MTI, and also *recommend* G.722.2. >>> >>> Making OPUS the only MTI audio codec would be problematic. >>> >>>> For video: While specifying either VP8 or H.264 would be sufficient for system interop, and for interop with compliant WebRTC endpoints, I'd really prefer not to re-live the WebRTC video codec wars. Concretely, what I would propose is that RUM indicate that the video codec requirements are defined to be identical to those defined for "WebRTC Non-Browsers" in Section 5 of RFC 7742. It should be made clear that RUM endpoints *are* *not* WebRTC Non-Browsers per se; merely that they comply with the same video codec requirements as WebRTC Non-Browsers. >>> >>> Continuing my comment above, existing devices have H.264 Constrained Baseline Profile, Level 1.3, packetization mode 1 as the MTI codec. Odds are many of these devices aren't capable of VP8. >>> >>> We can't realistically require a wholesale swap out of existing devices before the RUE defined by RUM can work. We can *discuss* whether forcing the providers to transcode is a practical way forward. I'm dubious. >>> >>> Thanks, >>> Paul >>> >>>> /a >>>> On 8/27/19 2:34 PM, Brian Rosen wrote: >>>>> Well, we certainly want interoperability, and I think we can only get that with MTI codecs. >>>>> >>>>> I think we really are talking about a WebRTC-compatible endpoint, but we want interoperability with a WebRTC browser endpoint. >>>>> >>>>> Not sure how to say this. Maybe Adam can help. >>>>> >>>>> Brian >>>>> >>>>>> On Aug 12, 2019, at 4:20 PM, Paul Kyzivat wrote: >>>>>> >>>>>> draft-rosen-rue-01 changes the video codec requirements. It now simply references webrtc RFC7742. >>>>>> >>>>>> RFC7742 distinguishes three types of endpoints: "WebRTC browser", "WebRTC non-browser", and "WebRTC-compatible endpoint". AFAIK it assumes that each end is one of these. >>>>>> >>>>>> Is the expectation here that both the RUE and the provider comply with one of these? In particular, that the provider may simply be a "WebRTC-compatible endpoint? Notably: >>>>>> >>>>>> "WebRTC-compatible endpoints" are free to implement any video codecs >>>>>> they see fit. This follows logically from the definition of "WebRTC- >>>>>> compatible endpoint". It is, of course, advisable to implement at >>>>>> least one of the video codecs that is mandated for WebRTC browsers, >>>>>> and implementors are encouraged to do so. >>>>>> >>>>>> Similarly, the audio requirements have been changed to reference webrtc RFC7874. That one doesn't have the distinction between "WebRTC browser", "WebRTC non-browser", and "WebRTC-compatible endpoint". It applies the same requirements to all. In particular, it requires OPUS support. I don't know why it doesn't make the same endpoint distinctions as for video. >>>>>> >>>>>> I think simply referencing these documents isn't sufficient. Seems like we need a more nuanced specification of what is required, though we may still reference these docs with qualifications. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> >>> >> >> -- >> Rum mailing list >> Rum@ietf.org >> https://www.ietf.org/mailman/listinfo/rum > > From nobody Wed Aug 28 09:13:11 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54FE612023E for ; Wed, 28 Aug 2019 09:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJ82KXimjVQY for ; Wed, 28 Aug 2019 09:13:07 -0700 (PDT) Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC554120232 for ; Wed, 28 Aug 2019 09:13:07 -0700 (PDT) Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x7SGD4mb011719 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 28 Aug 2019 12:13:05 -0400 To: Brian Rosen Cc: rum@ietf.org References: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net> <64B406DC-4171-41EB-9171-A2AF7B78B409@brianrosen.net> <054dde2a-7fa1-9941-986c-f3b3d8c0f76e@alum.mit.edu> <831AD5BE-0D8F-4968-ABC7-B8D52BB8D4B0@brianrosen.net> <30a05d55-3aee-3195-3e2e-9ac1d92b886d@alum.mit.edu> <797A336B-0D32-4D4F-AF16-C5D8A4648D22@brianrosen.net> <414e3fa5-ae0f-a632-af75-f34f2842d85c@alum.mit.edu> <26090EC8-51D7-4BBA-BA37-838328226DD6@brianrosen.net> From: Paul Kyzivat Message-ID: <2a81f060-cf20-3ab1-b2ee-582e94bf84f2@alum.mit.edu> Date: Wed, 28 Aug 2019 12:13:04 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <26090EC8-51D7-4BBA-BA37-838328226DD6@brianrosen.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rum] RUE client credentials X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 16:13:09 -0000 On 8/28/19 11:34 AM, Brian Rosen wrote: > Good discussion to have. > > A cert is public, so no real privacy issues other than what is in the identity (which a username gives you also). How the private key associated with the cert is handled is of concern, but I imagine it’s the usual CSR thing which never reveals the key. > But we do need some kind of security on the provisioning information itself. If there was a cert, then the provisioning could be signed by or for the rue. I kind of like that. It’s all new mechanism, but maybe worthwhile. You run code on the device that creates the CSR, upload it, and download the cert. Then the rue can sign the provisioning file (which really doesn’t need the cert, so it could do that any time). It could be that the RUE creates a self signed cert and then uploads it to the provider during initial configuration of the RUE on the provider. But, is there something we can reference on how to do it? Could the initial connection to the provisioning server include this cert as a client. The server won't know this cert and so will challenge for a password. Server would then save the cert for the user. In subsequent connections with the same client cert a password wouldn't be required. IIRC, the providers wanted to be able separate credentials that a user used to log into his provider account from those used by the RUE when registering. (So that they could be changed independently.) What I sketched above might solve that. > There are two contact maintenance mechanisms in the draft now - file upload/download and CardDAV. CardDAV is okay security-wise. Again the question is whether this can be accessed with the same credentials as used for registering. If not, then how does the RUE get them, since it will probably want to sync automatically. > File upload and download is from a provider, so we could have providers sign the file with the cert so only that user could verify it. I think there is a question here of how this is intended to be used. I have the impression that there is an expectation that the result can be used "manually", and so should be in clear text in a human readable format. But I think we also had an expectation that a RUE could use this automatically to update its own address book if CardDAV wasn't available. Clearly this is a degraded mechanism compared to CardDAV. For automated use by the RUE we need to again deal with what credentials are required to retrieve these. Unlike registering the device to receive calls, updating the address book is only needed when a person is present. So this could potentially require prompting the user for a password. Thanks, Paul > Brian > >> On Aug 28, 2019, at 11:14 AM, Paul Kyzivat wrote: >> >> On 8/28/19 10:41 AM, Brian Rosen wrote: >>> Ever since I’ve been working on this doc, the cert was for mutual auth of the user, instead of username and password. >> >> OK. As long as we are clear that is what it is about. >> >>> We get to use the IETF’s best practice here. Do we require a RUM device to support mutual auth, or not? We’re always going to support username and password for authentication. >>> We get to decide what else. >> >> We've already been dinged about passing passwords around in configuration. Is it better if we use a password to fetch an initial device configuration that includes certs? >> >> I think we need to have a new discussion of the overall security setup, including access to address book and video mail. Are they all under a single credential, or separate. Also how passwords expire and are refreshed/updated, etc. IIRC there were concerns about all of these. >> >> Thanks, >> Paul >> >>> Brian >>>> On Aug 28, 2019, at 9:47 AM, Paul Kyzivat wrote: >>>> >>>> On 8/27/19 3:32 PM, Brian Rosen wrote: >>>>> Getting back to this, sorry for the delay. >>>>>> On Aug 12, 2019, at 3:40 PM, Paul Kyzivat wrote: >>>>>> >>>>>> On 8/7/19 5:14 PM, Brian Rosen wrote: >>>>>>> Working on these comments. I submitted a new version (-01) >>>>>>> I edited the doc to say the client cert is provisioned. Given that it’s provisioned by the entity that the provides the server, do I need to say anything else about validating the cert? >>>>>> >>>>>> I think we need to examine what the goal is here, and whether it is being achieved. I don't think enough is said to decide. >>>>>> >>>>>> This client cert mechanism was first added way back when (2015 I think). IIRC, the motivation was because the providers wanted to restrict access to RUE *implementations* that have passed interoperability testing, in order to reduce the problems of dealing with buggy implementations or attackers. >>>>> I think you are confusing validating an implementation from authenticating a user. The notion of mutual auth with a per-device cert is completely separate from some notion of “signing” an implementations code. >>>> >>>> No. You can argue that the client cert mechanism in not an appropriate mechanism for this, but it was the intent when the mechanism was proposed. >>>> >>>> I can see how this might be confused if you weren't there at the time. And perhaps the thinking about it has evolved since it was first included. I wasn't party to what happened during 2016-18. >>>> >>>> IIUC the providers still want this - a way to screen out RUE *implementations* that have not passed their testing. However, I don't know how to achieve that goal. And I'm inclined to think that it is an unreasonable expectation. It is akin to web site operators asking for a way to screen out any browser implementations that they haven't already tested against. >>>> >>>>> We can decide we don’t want the option of having mutual auth. >>>> >>>> Clearly there is need for some mechanism to securely associate a RUE with an account at the provider and a phone number. And this needs to work with devices that are persistently connected. If a RUE suffers a power or network outage that is restored in the middle of the night then it should be able to reconnect without a user login so that it can be available for incoming calls. >>>> >>>> That was intended to be covered by passwords. But care must be taken to secure those. >>>> >>>> Thanks, >>>> Paul >> > > From nobody Wed Aug 28 11:12:40 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62E66120074 for ; Wed, 28 Aug 2019 11:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOT21HXCA47I for ; Wed, 28 Aug 2019 11:12:36 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD996120059 for ; Wed, 28 Aug 2019 11:12:36 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x7SICSuN033672 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 28 Aug 2019 13:12:29 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1567015950; bh=dHcrIBWs2y1ZHek7sqf2nFYziWAIpr4Zw/F1Y7oHwlQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=eiJN6CedLPxWPmNXW1Dx+hnc9AczhvPdSZuK1vClpeodexUgJcihZ0IFyQA0DZsGY ySgNF9iHonyfFUiRjIg8pbgXkQakkF8+AGayztQiymyQ4UCDmFoKufsAHZXiYiD5PH ehMI0n12cF0Kc980RllQLBaGlF5suVRJHElfp1TI= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Brian Rosen , Paul Kyzivat Cc: rum@ietf.org References: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net> <64B406DC-4171-41EB-9171-A2AF7B78B409@brianrosen.net> <69F15B2A-0158-4D23-B090-642497E3BDC7@brianrosen.net> <3fdefa0c-3a64-3445-8ceb-d293fe4b4831@alum.mit.edu> <60DFA478-5042-41FD-87CD-DD2154D6B1E6@brianrosen.net> From: Adam Roach Message-ID: <1474dbd1-5806-1e92-4e96-8568307b6a00@nostrum.com> Date: Wed, 28 Aug 2019 13:12:22 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <60DFA478-5042-41FD-87CD-DD2154D6B1E6@brianrosen.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 18:12:38 -0000 The deployed base of H.264 changes the calculus a bit. Given that fact, I'm not sure VP8 support gains very much. Constrained baseline and packetzation mode 1 are both MTI in WebRTC. It's notable that WebRTC only requires level 1.2, although it recommends 1.3. I *think* most browsers support 1.3, so specifying H.264 constrained baseline level 1.3 with packetization mode 1 as the single video MTI seems reasonable. /a On 8/28/19 9:38 AM, Brian Rosen wrote: > If we require OPUS and G.711 as MTI and we require both H.264 and VP8 as MTI, then we get backwards compatibility without transcoding and forwards compatibility with WebRTC. Isn’t that what we want? > > Brian > >> On Aug 28, 2019, at 10:15 AM, Paul Kyzivat wrote: >> >> Inline... >> >> On 8/27/19 5:57 PM, Adam Roach wrote: >>> I certainly have thoughts. The executive summary is that I personally believe RUM should specify Opus as the one audio codec MTI, and match RFC 7742's "Non-Browser" requirements for the video codec MTI. Rationale below. >>> From an interop perspective, the important thing is that any given profile has (at least) one MTI video codec and (at least) one MTI audio codec. I know there is a strong desire -- one that I share -- that these endpoints can talk to/be implemented in web browsers without the need for media transcoding. >>> For audio: WebRTC selected G.711 and Opus as both MTI; the former because it works without transcoding to landline PSTN destinations, and the latter because it sounds much, much better. RUM could make the same decision; or it could decide to move away from a codec that is as old as I am and opt to designate Opus as the only MTI. Given that RUM inherently needs to deploy into audio/video environments, backwards compatibility with the PSTN seems to be unnecessary baggage. >> Please keep in mind where we are coming from. The RUM will be a new interface to the *existing* VRS infrastructure. That infrastructure currently has proprietary devices that serve the RUE function, deployed to VRS users and to Communications Assistants (CAs, Interpreters). These have G.711 MTI, and also *recommend* G.722.2. >> >> Making OPUS the only MTI audio codec would be problematic. >> >>> For video: While specifying either VP8 or H.264 would be sufficient for system interop, and for interop with compliant WebRTC endpoints, I'd really prefer not to re-live the WebRTC video codec wars. Concretely, what I would propose is that RUM indicate that the video codec requirements are defined to be identical to those defined for "WebRTC Non-Browsers" in Section 5 of RFC 7742. It should be made clear that RUM endpoints *are* *not* WebRTC Non-Browsers per se; merely that they comply with the same video codec requirements as WebRTC Non-Browsers. >> Continuing my comment above, existing devices have H.264 Constrained Baseline Profile, Level 1.3, packetization mode 1 as the MTI codec. Odds are many of these devices aren't capable of VP8. >> >> We can't realistically require a wholesale swap out of existing devices before the RUE defined by RUM can work. We can *discuss* whether forcing the providers to transcode is a practical way forward. I'm dubious. >> >> Thanks, >> Paul >> >>> /a >>> On 8/27/19 2:34 PM, Brian Rosen wrote: >>>> Well, we certainly want interoperability, and I think we can only get that with MTI codecs. >>>> >>>> I think we really are talking about a WebRTC-compatible endpoint, but we want interoperability with a WebRTC browser endpoint. >>>> >>>> Not sure how to say this. Maybe Adam can help. >>>> >>>> Brian >>>> >>>>> On Aug 12, 2019, at 4:20 PM, Paul Kyzivat wrote: >>>>> >>>>> draft-rosen-rue-01 changes the video codec requirements. It now simply references webrtc RFC7742. >>>>> >>>>> RFC7742 distinguishes three types of endpoints: "WebRTC browser", "WebRTC non-browser", and "WebRTC-compatible endpoint". AFAIK it assumes that each end is one of these. >>>>> >>>>> Is the expectation here that both the RUE and the provider comply with one of these? In particular, that the provider may simply be a "WebRTC-compatible endpoint? Notably: >>>>> >>>>> "WebRTC-compatible endpoints" are free to implement any video codecs >>>>> they see fit. This follows logically from the definition of "WebRTC- >>>>> compatible endpoint". It is, of course, advisable to implement at >>>>> least one of the video codecs that is mandated for WebRTC browsers, >>>>> and implementors are encouraged to do so. >>>>> >>>>> Similarly, the audio requirements have been changed to reference webrtc RFC7874. That one doesn't have the distinction between "WebRTC browser", "WebRTC non-browser", and "WebRTC-compatible endpoint". It applies the same requirements to all. In particular, it requires OPUS support. I don't know why it doesn't make the same endpoint distinctions as for video. >>>>> >>>>> I think simply referencing these documents isn't sufficient. Seems like we need a more nuanced specification of what is required, though we may still reference these docs with qualifications. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> From nobody Thu Aug 29 06:50:58 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B86AA12007C for ; Thu, 29 Aug 2019 06:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7tJqiz63fd4 for ; Thu, 29 Aug 2019 06:50:55 -0700 (PDT) Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1386912004A for ; Thu, 29 Aug 2019 06:50:54 -0700 (PDT) Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x7TDorLd018711 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 29 Aug 2019 09:50:53 -0400 To: rum@ietf.org From: Paul Kyzivat Message-ID: Date: Thu, 29 Aug 2019 09:50:53 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Rum] Call for WG adoption of: draft-rosen-rue-01 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 13:50:57 -0000 This is a call for the adoption of draft-rosen-rue-01 as a RUM wg document. This is intended to evolve into the document our charter calls for. Comments, pro or con, on this proposal are due by Sunday September 15. Thanks, Paul Kyzivat, as RUM co-chair From nobody Thu Aug 29 07:08:58 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91CB11200C3 for ; Thu, 29 Aug 2019 07:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMQnRkQe6xSP for ; Thu, 29 Aug 2019 07:08:54 -0700 (PDT) Received: from vsp-unauthed02.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB169120071 for ; Thu, 29 Aug 2019 07:08:53 -0700 (PDT) X-Halon-ID: 856acc7d-ca66-11e9-903a-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [88.129.173.120]) by bin-vsp-out-02.atm.binero.net (Halon) with ESMTPSA id 856acc7d-ca66-11e9-903a-005056917f90; Thu, 29 Aug 2019 16:08:48 +0200 (CEST) To: Paul Kyzivat , rum@ietf.org References: From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <4cb1e36e-3b9d-49f9-a755-c80c8e354dcf@omnitor.se> Date: Thu, 29 Aug 2019 16:08:48 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 14:08:57 -0000 +1 /Gunnar Hellstrm Den 2019-08-29 kl. 15:50, skrev Paul Kyzivat: > This is a call for the adoption of draft-rosen-rue-01 as a RUM wg > document. This is intended to evolve into the document our charter > calls for. > > Comments, pro or con, on this proposal are due by Sunday September 15. > > Thanks, > Paul Kyzivat, as RUM co-chair > From nobody Thu Aug 29 07:13:58 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D97120071 for ; Thu, 29 Aug 2019 07:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2AAgpbN-xlZv for ; Thu, 29 Aug 2019 07:13:54 -0700 (PDT) Received: from outprodmail01.cc.columbia.edu (outprodmail01.cc.columbia.edu [128.59.72.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B43912004A for ; Thu, 29 Aug 2019 07:13:53 -0700 (PDT) Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by outprodmail01.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id x7TEDcS0054281 for ; Thu, 29 Aug 2019 10:13:53 -0400 Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id 12F6E7E for ; Thu, 29 Aug 2019 10:13:53 -0400 (EDT) Received: from sendprodmail01.cc.columbia.edu (sendprodmail01.cc.columbia.edu [128.59.72.13]) by hazelnut (Postfix) with ESMTP id BDC036D for ; Thu, 29 Aug 2019 10:13:52 -0400 (EDT) Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) by sendprodmail01.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id x7TEDqAI026949 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 29 Aug 2019 10:13:52 -0400 Received: by mail-qt1-f200.google.com with SMTP id 38so3513451qtx.3 for ; Thu, 29 Aug 2019 07:13:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2p6YUpeCM3OxNqsFrpvaQ8ojI+hfxjdTQCp3aWGDXzo=; b=LpeFmB62f/BdtBPfm1JePgQqshbxF0d3AKcap0GgzOUQhYReRRC/q/f7ZngCVBI8yk f1GqQQ6LljdpUlluV/U6mSWT2N9eGe4U8BhZrhb7EOxfFxjmWZ4+oGQH574N7QaO5bOR kRZSKrx4kUhd53ryllFUSbPMTpPJ0gZPVmcnFF/9Zrngbe3dGQ3V5W+Vt9nMo2CmI5cs mhbDr5jKPmST3ZCp1PsBkEbw6jEWoRONu+KVN93Zj7j12sGSL1dCiN29x/qISuQ5z0pg Rrzh7PVv918p7kaXBstVS3EyjodXY9llYA6LD0gOARz2v54tj9T3qO7GUoV4c9ksmjff Nrhg== X-Gm-Message-State: APjAAAXFhRO8eV6kkpjf1nUe/wrsW3qyj9wSSA5aGim4sxsfEd9Kz1ue raEvJeL5bFXlrf3nPxbRupns79PEjO0AGgtKtyqqPZtrX29/17oJhSe+UXZVR3b7TM9uTJlJ2u3 wr5M2IrMaOhPMeabJTJFt+OPh/Vg= X-Received: by 2002:a0c:ea8d:: with SMTP id d13mr6380280qvp.222.1567088032219; Thu, 29 Aug 2019 07:13:52 -0700 (PDT) X-Google-Smtp-Source: APXvYqwDirxjSabIg3tAbN4uq91S/Lt9kvggjViSlFUhi3XJ5DC+aoYOK0u/elKbb3HuK8Nxx9kJI6Twi5/ZcvqE2Mk= X-Received: by 2002:a0c:ea8d:: with SMTP id d13mr6380255qvp.222.1567088031844; Thu, 29 Aug 2019 07:13:51 -0700 (PDT) MIME-Version: 1.0 References: <4cb1e36e-3b9d-49f9-a755-c80c8e354dcf@omnitor.se> In-Reply-To: <4cb1e36e-3b9d-49f9-a755-c80c8e354dcf@omnitor.se> From: Henning Schulzrinne Date: Thu, 29 Aug 2019 10:13:26 -0400 Message-ID: To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= Cc: Paul Kyzivat , rum@ietf.org Content-Type: multipart/alternative; boundary="0000000000007854db0591421d08" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.84 on 128.59.72.13 Archived-At: Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 14:13:56 -0000 --0000000000007854db0591421d08 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ++ On Thu, Aug 29, 2019 at 10:09 AM Gunnar Hellstr=C3=B6m < gunnar.hellstrom@omnitor.se> wrote: > +1 > > /Gunnar Hellstr=C3=B6m > > > --0000000000007854db0591421d08 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
++

On Thu, Aug 29, 2019 at 10:09 AM Gu= nnar Hellstr=C3=B6m <gunn= ar.hellstrom@omnitor.se> wrote:
+1

/Gunnar Hellstr=C3=B6m


--0000000000007854db0591421d08-- From nobody Thu Aug 29 07:45:27 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10EA1120100 for ; Thu, 29 Aug 2019 07:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7571zaSASw0S for ; Thu, 29 Aug 2019 07:45:23 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C755D1200C3 for ; Thu, 29 Aug 2019 07:45:22 -0700 (PDT) Received: from [192.168.1.83] (unknown [212.247.19.62]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id CA1FB10F8; Thu, 29 Aug 2019 16:45:18 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: "Olle E. Johansson" In-Reply-To: <4cb1e36e-3b9d-49f9-a755-c80c8e354dcf@omnitor.se> Date: Thu, 29 Aug 2019 16:45:17 +0200 Cc: Olle E Johansson , Paul Kyzivat , rum@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6434EE3B-0A2F-43A7-A02D-F5949FAD116B@edvina.net> References: <4cb1e36e-3b9d-49f9-a755-c80c8e354dcf@omnitor.se> To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 14:45:25 -0000 +1 /Olle Johansson > On 29 Aug 2019, at 16:08, Gunnar Hellstr=C3=B6m = wrote: >=20 > +1 >=20 > /Gunnar Hellstr=C3=B6m >=20 > Den 2019-08-29 kl. 15:50, skrev Paul Kyzivat: >> This is a call for the adoption of draft-rosen-rue-01 as a RUM wg = document. This is intended to evolve into the document our charter calls = for. >>=20 >> Comments, pro or con, on this proposal are due by Sunday September = 15. >>=20 >> Thanks, >> Paul Kyzivat, as RUM co-chair >>=20 >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum From nobody Thu Aug 29 07:51:02 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 117DD1201DC for ; Thu, 29 Aug 2019 07:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mitre.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JE8MZQcJYJP1 for ; Thu, 29 Aug 2019 07:50:55 -0700 (PDT) Received: from smtpvmsrv1.mitre.org (smtpvmsrv1.mitre.org [192.52.194.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 126AE12026E for ; Thu, 29 Aug 2019 07:50:55 -0700 (PDT) Received: from smtpvmsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 226E86C00D9; Thu, 29 Aug 2019 10:50:54 -0400 (EDT) Received: from smtprhmv1.mitre.org (unknown [128.29.154.203]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtpvmsrv1.mitre.org (Postfix) with ESMTPS id 3B6566C0141; Thu, 29 Aug 2019 10:50:41 -0400 (EDT) Received: from mwfesmtp-mgt.mitre.org (unknown [192.52.194.235]) by smtprhmv1.mitre.org (Postfix) with ESMTP id 300A480B591; Thu, 29 Aug 2019 10:50:41 -0400 (EDT) Received: by mwfesmtp-mgt.mitre.org (Postfix, from userid 600) id 46K5Bn1D7Kz3DY94; Thu, 29 Aug 2019 14:50:15 +0000 (UTC) Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02lp2101.outbound.protection.outlook.com [104.47.65.101]) by mwfesmtp-mgt.mitre.org (Postfix) with ESMTPS id 46K5BG02CMz3DYBh; Thu, 29 Aug 2019 14:50:14 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ahsbY0WZ0R/KzM1jBtjoNo+9Ai8dmqLNZ5KKiBEfwJlHQNF8Y6gu47MTZ8VoPJ1C84J+v+k2EYmiT1AskHnrsX/8kG0EdhyHsB8KE10syIuQ+uoJoCKZWAe/4PBbqEkmq2y34AMm+Q9YbfIaWHfnoMNX++cT8ronw/hsh1nXW+bF9kF3nWxjQclnpdMJWQyJoP7WOZYKUeUTc4+efY4F2/TNuLkJVM8M+v47VMHwhs2UmUbIp1qsQgDYB/aPs+QFoUEaF5DQxpAz5/P94ume4gElK1Fr3hMRzp683CkTPzhjH5MDEuzT92a3rf4t4Y5fvokZQMqwlNm0Jwir9MKqHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=o07tHwkg/pdw5zld19ZT1JN7coikFiF2RK5xirynnWE=; b=nLgPf47Wr+7v+r0CMw6jr5FIRmP3OQrUaxRG/ZhJbRz7Z6Z2cayWzLyPEZWfWGLa4JnZvUWARnn6FNMQW8CI3v4Ne/24zGkxF1FIlvNt4s34qM+FGKpaW2y7EtyZDKse3yR70ucp+ZiD73AjMa0JiqgslH1g+cIoeOeRLhfgJS6c7P4no2XJax2jdy49oOEh25czFVQihUuOxMCmOpOSOi7iapRou2BynNyN4jNDngdKPvybz5NNaNQZ/5XyKjvMqp9bGmzpFW1PYG8g84iEdcVIZiNyU8C0GxbTRbXwShbPAsie2W1MVtJfkCT6qnoihGhoE6TAfHrVdoza9hNdeg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mitre.org; dmarc=pass action=none header.from=mitre.org; dkim=pass header.d=mitre.org; arc=none Received: from BL0PR0901MB2386.namprd09.prod.outlook.com (52.132.25.22) by BL0PR0901MB4564.namprd09.prod.outlook.com (52.135.46.80) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2220.19; Thu, 29 Aug 2019 14:50:12 +0000 Received: from BL0PR0901MB2386.namprd09.prod.outlook.com ([fe80::cc1d:b5b5:bea2:9d5]) by BL0PR0901MB2386.namprd09.prod.outlook.com ([fe80::cc1d:b5b5:bea2:9d5%7]) with mapi id 15.20.2199.021; Thu, 29 Aug 2019 14:50:12 +0000 From: "Malloy, Jim" To: "Kyzivat, Paul" , "rum@ietf.org" Thread-Topic: [EXT] Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 Thread-Index: AQHVXnNXZcfllR7w+kKMlxfYZW5wg6cSNRkA Date: Thu, 29 Aug 2019 14:50:12 +0000 Message-ID: References: <6418_1567087740_5D67DC7C_6418_608_9_4cb1e36e-3b9d-49f9-a755-c80c8e354dcf@omnitor.se> In-Reply-To: <6418_1567087740_5D67DC7C_6418_608_9_4cb1e36e-3b9d-49f9-a755-c80c8e354dcf@omnitor.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jmalloy@mitre.org; x-originating-ip: [192.160.51.89] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ccb0747a-d054-4e0e-1495-08d72c90325e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:BL0PR0901MB4564; x-ms-traffictypediagnostic: BL0PR0901MB4564: x-ms-exchange-purlcount: 1 x-ld-processed: c620dc48-1d50-4952-8b39-df4d54d74d82,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3513; x-forefront-prvs: 0144B30E41 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(346002)(366004)(39860400002)(396003)(13464003)(199004)(189003)(6246003)(7696005)(11346002)(76176011)(86362001)(99286004)(3846002)(6116002)(476003)(229853002)(6436002)(26005)(2171002)(81156014)(33656002)(561944003)(102836004)(446003)(8676002)(53936002)(81166006)(14454004)(25786009)(110136005)(9686003)(186003)(53546011)(6306002)(55016002)(71190400001)(71200400001)(2906002)(2501003)(52536014)(6506007)(4744005)(256004)(305945005)(7736002)(966005)(5660300002)(478600001)(316002)(76116006)(66574012)(66476007)(66556008)(64756008)(66446008)(66066001)(74316002)(486006)(66946007)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL0PR0901MB4564; H:BL0PR0901MB2386.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: mitre.org does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: JLWU8IKEnTSGqV8BpN5Z9nLMfSHo5L7KMdNBbUQOWJ5n7x89phFF2OviwLgKs4FG9aRV9fsZq9P/8dgi5m5Ycb2E0ZMPtTcYWCHf0jHUNNtdQ0B1qs7nS4ZXcDE9GVGoVaqEpK8IMAWO9TX9IY7eyVaumejBZskPLxrKhxpJwoaku8wKPl+aNNKY8brb57tnHmKdrsvQkl3UF6m5nol6QwL6uc/QDvrkaBQb0RdBgAqS6/LFpgD0PHGQzap4ucO8qp1133eg7MrAm/tdw9T52/vABcf6DFvJCCuQiFvF1Us5hLr5SWE1dcwD/+Rl/5woB7LfNv3C9HdWvfJtKX4c4osZU2lvlz3V4RvPYUJ/EXNfsLPvdcTTkQgTr7rQVSq0nYhPtV95Fb+NnPWHHgJ5yg6OK/yJ8Z9lAZAFdCsdHMA= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: mitre.org X-MS-Exchange-CrossTenant-Network-Message-Id: ccb0747a-d054-4e0e-1495-08d72c90325e X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2019 14:50:12.6114 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 7m6qswMJZXi8E+cmjXY0SSB+PwszdZCtZ4D1iNutRw7/n/safg816foVQg4yk2q+nVcNV1wJSKWbGAQqyovw9w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR0901MB4564 X-MITRE: 8GQsMWxq66rxk57w DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mitre.org; h=from:to:subject:date:message-id:references:in-reply-to:content-type:content-transfer-encoding:mime-version; s=selector1; bh=o07tHwkg/pdw5zld19ZT1JN7coikFiF2RK5xirynnWE=; b=hPIrMDvxliH2acw38ObMvLuK/395Buq8YbY+ct7eFoLPnYpyVNjALYqfhUub/bgrNL+rWwUd+S7gmIzNNVSPXn9CjOLEhzROo0nvtruZ6gWEM+JmT96qOxx5ujiUs5dc+gjAOMmM+2XJrd148Q1xl3PCAIIFQvPVN+oo/G2Hkug= Archived-At: Subject: Re: [Rum] [EXT] Re: Call for WG adoption of: draft-rosen-rue-01 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 14:51:01 -0000 +1 --Jim Malloy -----Original Message----- From: Rum On Behalf Of Gunnar Hellstr=F6m Sent: Thursday, August 29, 2019 10:09 AM To: Kyzivat, Paul ; rum@ietf.org Subject: [EXT] Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 +1 /Gunnar Hellstr=F6m Den 2019-08-29 kl. 15:50, skrev Paul Kyzivat: > This is a call for the adoption of draft-rosen-rue-01 as a RUM wg=20 > document. This is intended to evolve into the document our charter=20 > calls for. > > Comments, pro or con, on this proposal are due by Sunday September 15. > > =A0=A0=A0=A0Thanks, > =A0=A0=A0=A0Paul Kyzivat, as RUM co-chair > -- Rum mailing list Rum@ietf.org https://www.ietf.org/mailman/listinfo/rum From nobody Thu Aug 29 09:05:20 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95555120989 for ; Thu, 29 Aug 2019 09:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7dw-L4hZKbc for ; Thu, 29 Aug 2019 09:05:12 -0700 (PDT) Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A705012097C for ; Thu, 29 Aug 2019 09:05:12 -0700 (PDT) Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x7TG5A6l027249 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 29 Aug 2019 12:05:11 -0400 To: rum@ietf.org References: <9a14addd-9a1c-6130-3880-a814be717323@omnitor.se> <59F6B4E5-16DF-42EB-A654-1749BC9487B5@brianrosen.net> From: Paul Kyzivat Message-ID: <48c0bc62-0f75-4f83-6d9c-f763982dd000@alum.mit.edu> Date: Thu, 29 Aug 2019 12:05:10 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rum] Real-time text in WebRTC is discussed in mmusic - a topic closely telated to rum X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 16:05:19 -0000 I question how well RTT text is suited to multiparty conferences. If you have messages on your screen from multiple parties, and many of them are updating in real-time, are you going to be able to perceive what is going on? And while you can have a column per person for two-party and maybe 3-party conversations, that doesn't scale up. With many parties, some typing may scroll off the screen before it is complete. Perhaps for conferences it is better to just use line-at-a-time chat. If necessary, I presume there could be gateways between RTT and chat. A RUE could have the capability to negotiate down from RTT to chat. Thanks, Paul On 8/28/19 2:15 AM, Gunnar Hellström wrote: > Den 2019-08-27 kl. 23:15, skrev Brian Rosen: >> At least by centralizing the problem at a “mixer”, Alice and Bob will >> see the same thing. >> >> You don’t have the problem in Instant Messaging, because you can’t >> backspace or delete a sent message.  Of course if multiple people are >> typing simultaneously in such systems, message order will be confusing >> in that instant. > Right, it is a similar kind of problem that text appears in an > unexpected order. There is also at least one instant messaging service > that allows modification in already sent message. But I think it has > limitations to only accept that in the last message sent. it is > convenient anyway. >> >> Anyway, we need to specify the mixer for RTT so it receives each of >> the RTT streams and produces a single composite stream for each >> participant. > > Yes, right, and there is an effort in that direction in: > > http://www.realtimetext.org/sites/default/files/Files_and_Documents/Specifications/multiparty-real-time-text-mixer-2011-04-30.pdf > > It is written for conference-unaware user devices. > > The goals are specified as follows: > > The procedures are intended to make best efforts to present a > multi-party text conversation on a terminal that has no awareness of > multi-party calls. There are some obvious drawbacks, and a terminal > designed with multi-party awareness will be able to present multi-party > call contents in a more flexible way. Only two parties at a time will be > allowed to display added text in real-time, while the other parties’ > produced text will need to be stored in the multi-party server for a > moment awaiting a suitable occasion to be displayed. There are also some > cases of erasure that will not be performed on the target text but only > indicated in another way. Even with these drawbacks, the procedure > provides an opportunity to display text from more than two parties in a > smooth and readable way. > > --------------------------------------------------------------------------------------------------- > > I see such mixer procedures as a fall-back for cases without conference > awareness, but want to see support for conference-aware terminals, where > text from more than two parties can be presented in real-time, and the > end user or app can have influence over the presentation style - e.g. > select between the multiple column view and the one-column-with-labels > view.  A mixer for that case would only need to assure that the receiver > has the right kind of multi-party awareness and send RTT text with > source information attached, and let the receiving terminal sort out the > presentation. This is already possible with CSRC and CNAME when using > RTP, but we lose that possibility natively when using the WebRTC data > channel to transport RTT, and would need to specify a way to include the > source also for that case. > > ------------------------------------------------------ > > By the way, what is your current view of how to transport RTT for RUM, > now when you say that you will use WebRTC transports for media? > > Regards > > Gunnar > >> >>> On Aug 27, 2019, at 4:43 PM, Gunnar Hellström >>> > wrote: >>> >>> Den 2019-08-27 kl. 21:48, skrev Brian Rosen: >>>> The problem of conference 4103 RTT is high on my list of work I need >>>> to get done.  So, I’m motivated to help out. >>> Thanks, great. >>>> The basic problem is that we’re going to get very inconsistent UI >>>> doing it that way, because of how systems will handle backspace of >>>> one party that extends beyond responses from other parties: >>> (well, for me the currently most basic problem is to have a reliable >>> way to append received text to the already presented text of the >>> right participant. And that is getting worse in WebRTC than it was in >>> RFC 4103. But we will sort it out.) >>>> >>>> Alice: I waited for you >>>> Bob: I didn’t see you >>>> Alice: sorry >>>> >>>> And then Alice types 12 backspaces. >>>> >>>> What should happen? >>> >>> You are right that there are a number of ways to handle the RTT UI. >>> And just as inconsistencies are common with a message oriented UI, >>> where messages show up in a confusing order because two users >>> completed messages in an unexpected time order, it is possible that >>> RTT text gets displayed in a strange order after erasure and >>> retyping. It is better for RTT than for message oriented >>> presentation, and user get used to it in both cases.  With the >>> labelled style in one column you have in the example, I would >>> recommend that first 5 backspaces erase "sorry", next backspace >>> erases the line separator, and pulls down "I waited for you" to be >>> shown last, as an uncompleted text. Then the next 6 backspaces erase >>> so that only "I waited f" is displayed. When Alice adds text and end >>> with a new line, the corrected sentence is allowed to flow up when >>> new text is added from any participant.  That causes a bit strange >>> order, but it is just as manageable as when text in messaging >>> applications appear in an unexpected order so that one message seems >>> to be a respone on something totally else than what was intended. >>> >>> A sophisticated UI may mark text that is moved and modified. >>> >>> We want to keep sentences or at least phrases from each participant >>> together in a readable unit. Already that causes a design decision on >>> where to place the completed chunk of text once the user has >>> completed it. The start of the chunk may be older than completed text >>> from other participants which would motivate to move it up a bit in >>> the presentation. But the end of it is at that moment the latest text >>> to present. I think it is best to let the finished text be presented >>> last on the display, but let others' newer text push everything up >>> and be displayed last. >>> >>> >>> T.140 has information on how to handle erasure: >>> >>> -------------------From T.140--------------------------- >>> >>> 8.2 Erase last character >>> Purpose: Erase the last character sent from the display at the >>> receiving end. >>> Code: BS: 0008. >>> Procedure: On the receiving end: Move the insertion point to the last >>> character and erase it. >>> Combined characters are erased as a unit, with one BS erasing the >>> whole character even if it is >>> combined from more than one component. >>> Control sequences (like CR LF) are erased in one operation. >>> NOTE – The same action shall be taken on the local display. >>> >>> ------------------------------------------------------------ >>> >>>   /Gunnar >>> >>>> >>>> Brian >>>> >>>>> On Aug 27, 2019, at 9:52 AM, Gunnar Hellström >>>>> > >>>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> A topic is currently discussed in mmusic that is closely related to >>>>> rum. it is WebRTC transport of real-time text. >>>>> >>>>> The draft is draft-holmberg-mmusic-t140-usage-data-channel . >>>>> >>>>> A good point to start reading could be: >>>>> >>>>> https://mailarchive.ietf.org/arch/browse/mmusic/?gbt=1&q=draft-holmberg-mmusic-t140-usage-data-channel >>>>> >>>>> Please check if the current state of the discussion suits rum! >>>>> >>>>> The only issue that seems to be remaining is how to transport RTT >>>>> data to and from a conference server that combines all traffic per >>>>> media in a meeting in one data stream. That is not very elegantly >>>>> specified for RFC 4103 transport of RTT in RTP either, so we might >>>>> want to do a rapid action together to solve the multi-party RTT MCU >>>>> case in a general and consistent way. >>>>> >>>>> Regards >>>>> >>>>> Gunnar >>>>> >>>>> -- >>>>> ----------------------------------------- >>>>> Gunnar Hellström >>>>> Omnitor >>>>> gunnar.hellstrom@omnitor.se >>>>> +46 708 204 288 >>>>> >>>>> >>> -- >>> ----------------------------------------- >>> Gunnar Hellström >>> Omnitor >>> gunnar.hellstrom@omnitor.se >>> +46 708 204 288 >> >> > -- > ----------------------------------------- > Gunnar Hellström > Omnitor > gunnar.hellstrom@omnitor.se > +46 708 204 288 > > From nobody Thu Aug 29 09:21:11 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8444A12096C for ; Thu, 29 Aug 2019 09:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mitre.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYZgtEoTfrKh for ; Thu, 29 Aug 2019 09:21:07 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 587441200B8 for ; Thu, 29 Aug 2019 09:21:07 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8DFE533205D; Thu, 29 Aug 2019 12:21:06 -0400 (EDT) Received: from smtprhbv1.mitre.org (unknown [129.83.19.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtpvbsrv1.mitre.org (Postfix) with ESMTPS id 831F1332047; Thu, 29 Aug 2019 12:21:06 -0400 (EDT) Received: from mbfesmtp-mgt.mitre.org (unknown [198.49.146.235]) by smtprhbv1.mitre.org (Postfix) with ESMTP id 7F04D80A9A1; Thu, 29 Aug 2019 12:21:06 -0400 (EDT) Received: by mbfesmtp-mgt.mitre.org (Postfix, from userid 600) id 46K7C63cPyzk1S; Thu, 29 Aug 2019 16:20:29 +0000 (UTC) Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02lp2108.outbound.protection.outlook.com [104.47.64.108]) by mbfesmtp-mgt.mitre.org (Postfix) with ESMTPS id 46K7BN2Xk0zk1Y; Thu, 29 Aug 2019 16:20:28 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PNujldlY3ZqhULK2AJwsW2hBLPrQTrMIujSz3Op71B84GnYJ4K6eUyluPchUs3HVcOk7oZqw384pp+6YBCxGxL44cPNxBQicQXsFDcY7bFMiEEKpmiSUeATTu5Ea+tvNPnwJirYQ5ukv5gQGQVtxLjqFFyAn2zL2P4M/bl2FK9nXAAF7mb9P/oMqQ1yqYOTXQVYawC8zIkbNB7cdssNxvqPqo6sahR4zbPqrpjx1uP40HTRZVRqSjJnciE0iYcl5oIx2i5qMbvwVqLvNAOdPAIc3XWotVHmWgPdLyi5X7I3dvK6VmdUWrZ4m6xa2lfdhL+wq6U018Rs9Y0O0D0naRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BTgI9h+xD3WrTOtFE20yO27T5IepN4kewyqoIwIRpgA=; b=LzEPa4XO+YCqIR3bJ8ybgQ95vEsBASRT33ZupmeW0YJAG31vbiu9Q3cwiWXTsmf4PnNbxtSdfk+lEXQKuipY2ain12mCQkZq0TIRoKllxHAgyqLrJWzOVefvBEuxwti1Nl3PvinDYWFYPjd4Z+3gP3K5ftRC4FtInB+9qEV4jPK1JNSp4tdS+BTdImpaAOT+CqWTyqbXLq+qqM2IWt/sAcRqCxwQzxrULI3qG5jmxZKbkZ1Rl1tQqvBgSK+H6NRd47agVbpW4PFtUTvQTV9WubNLKvzwWXV0VNj5tvvCv4kD9MYgRTz82o+BwvmVlAPENvJAccEeBM1w3js/xRHoGA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mitre.org; dmarc=pass action=none header.from=mitre.org; dkim=pass header.d=mitre.org; arc=none Received: from BL0PR0901MB2386.namprd09.prod.outlook.com (52.132.25.22) by BL0PR0901MB3058.namprd09.prod.outlook.com (20.177.243.80) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.21; Thu, 29 Aug 2019 16:20:24 +0000 Received: from BL0PR0901MB2386.namprd09.prod.outlook.com ([fe80::cc1d:b5b5:bea2:9d5]) by BL0PR0901MB2386.namprd09.prod.outlook.com ([fe80::cc1d:b5b5:bea2:9d5%7]) with mapi id 15.20.2199.021; Thu, 29 Aug 2019 16:20:24 +0000 From: "Malloy, Jim" To: "Kyzivat, Paul" , "rum@ietf.org" Thread-Topic: [EXT] Re: [Rum] Real-time text in WebRTC is discussed in mmusic - a topic closely telated to rum Thread-Index: AQHVXoOIlwW+HFW4sUKgOzE77Y/c0KcSTbSA Date: Thu, 29 Aug 2019 16:20:24 +0000 Message-ID: References: <9a14addd-9a1c-6130-3880-a814be717323@omnitor.se> <59F6B4E5-16DF-42EB-A654-1749BC9487B5@brianrosen.net> <25517_1567094729_5D67F7C4_25517_54_4_48c0bc62-0f75-4f83-6d9c-f763982dd000@alum.mit.edu> In-Reply-To: <25517_1567094729_5D67F7C4_25517_54_4_48c0bc62-0f75-4f83-6d9c-f763982dd000@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jmalloy@mitre.org; x-originating-ip: [192.160.51.89] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2cb45722-1e0a-4634-5a90-08d72c9ccc0d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:BL0PR0901MB3058; x-ms-traffictypediagnostic: BL0PR0901MB3058: x-ms-exchange-purlcount: 3 x-ld-processed: c620dc48-1d50-4952-8b39-df4d54d74d82,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0144B30E41 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(136003)(366004)(346002)(396003)(39860400002)(13464003)(52314003)(199004)(189003)(76116006)(186003)(66946007)(33656002)(2906002)(52536014)(25786009)(71190400001)(71200400001)(64756008)(66556008)(66476007)(14454004)(2501003)(86362001)(66446008)(66574012)(8676002)(8936002)(81156014)(81166006)(229853002)(53936002)(6436002)(6306002)(55016002)(2171002)(6246003)(74316002)(476003)(486006)(7736002)(966005)(14444005)(256004)(19625735003)(5024004)(305945005)(446003)(478600001)(5660300002)(26005)(11346002)(110136005)(102836004)(66066001)(99286004)(316002)(53546011)(76176011)(3846002)(7696005)(9686003)(6116002)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:BL0PR0901MB3058; H:BL0PR0901MB2386.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: mitre.org does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: E/KFeWz2C0W0vd0ZZ3Lz4bL0IC2I7TaFmrPjMWPfsCpfPojqZOK91hZ/n0g3MviXQ0QqYUnxfKxOX52ENKpQgZ/dYUVdgVcS0SxFDWi5Mza518sFA4Rij8NyINO/r5muzGfv5oNBT2cP4OlabjUOR/CPAD0ntPSLwE+0xXNiP26pRMP9vMnA8eEdPkGzQC1m+3xymU+aJZMsBR4xy1189D4NK1eU8t9g9FJDzoo27A7b+/ktHAGis2zTwNRkp5qKi+hhwzSibpuVM3rZB5i+bJeTGDoxFnfbCmmEK7X3LO0AmsEvkjhCCG+sgr8RyRDC0lb0XcuDoy5FgGmTpcqS0jy3O4HK7lDoSjDPS4UoeGQ6DRiUJ/+R1WTtkkAohW+dy8pvPZTu8pdLv10C1vchrctl3rF2NCjWDNuF+4pt5Z4= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: mitre.org X-MS-Exchange-CrossTenant-Network-Message-Id: 2cb45722-1e0a-4634-5a90-08d72c9ccc0d X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2019 16:20:24.4493 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: npuDcR2dS4/tKX7OGfmwxsqb7yDiucdPzcOmGMtZW4xaTqAW5g+SsEbO40YaHdTKOUeaMG+COqtORSnGVMY/2w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR0901MB3058 X-MITRE: 8GQsMWxq66rxk57w DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mitre.org; h=from:to:subject:date:message-id:references:in-reply-to:content-type:content-transfer-encoding:mime-version; s=selector1; bh=BTgI9h+xD3WrTOtFE20yO27T5IepN4kewyqoIwIRpgA=; b=zRC9EK9jji1f0s+wMbvUqSpeBGIsjZVJWr6iKuaMv1cfMThru99KGeYqhUg9X9HNtWs1sSlptZpUoKBzoBaHyPUPa0LcEXQurzg9NIwQuUkPqCdblKMImAth2FMiJl0W+HkzKRhtDAeS27gIeKyir/2y5o7zLLNTYJdLKh6GH9w= Archived-At: Subject: Re: [Rum] [EXT] Re: Real-time text in WebRTC is discussed in mmusic - a topic closely telated to rum X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 16:21:09 -0000 RG8gd2UgaW50ZW5kIGZvciB0aGUgUlVFIHRvIGFjY29tbW9kYXRlIG11bHRpcGxlIHBhcnR5IGNh bGxzIChtb3JlIHRoYW4gdGhyZWUpPyBJIGRvbid0IHJlY2FsbCBhbnkgbGFuZ3VhZ2UgcmVsYXRl ZCB0byBhbnl0aGluZyBidXQgYSBwb2ludCB0byBwb2ludCBjYWxsLiAgRm9yIGVtZXJnZW5jeSBj YWxscywgY29uZmVyZW5jaW5nIGluIHRoZSBQU0FQICh0aHJlZSBwYXJ0aWVzKSBtYXkgYmUgYXBw cm9wcmlhdGUuICBBcmUgd2UgbG9va2luZyBmb3IgbW9yZSB0aGFuIHRoYXQ/DQoNCi0tSmltIE1h bGxveQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUnVtIDxydW0tYm91bmNl c0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIFBhdWwgS3l6aXZhdA0KU2VudDogVGh1cnNkYXksIEF1 Z3VzdCAyOSwgMjAxOSAxMjowNSBQTQ0KVG86IHJ1bUBpZXRmLm9yZw0KU3ViamVjdDogW0VYVF0g UmU6IFtSdW1dIFJlYWwtdGltZSB0ZXh0IGluIFdlYlJUQyBpcyBkaXNjdXNzZWQgaW4gbW11c2lj IC0gYSB0b3BpYyBjbG9zZWx5IHRlbGF0ZWQgdG8gcnVtDQoNCkkgcXVlc3Rpb24gaG93IHdlbGwg UlRUIHRleHQgaXMgc3VpdGVkIHRvIG11bHRpcGFydHkgY29uZmVyZW5jZXMuDQoNCklmIHlvdSBo YXZlIG1lc3NhZ2VzIG9uIHlvdXIgc2NyZWVuIGZyb20gbXVsdGlwbGUgcGFydGllcywgYW5kIG1h bnkgb2YgdGhlbSBhcmUgdXBkYXRpbmcgaW4gcmVhbC10aW1lLCBhcmUgeW91IGdvaW5nIHRvIGJl IGFibGUgdG8gcGVyY2VpdmUgd2hhdCBpcyBnb2luZyBvbj8NCg0KQW5kIHdoaWxlIHlvdSBjYW4g aGF2ZSBhIGNvbHVtbiBwZXIgcGVyc29uIGZvciB0d28tcGFydHkgYW5kIG1heWJlIDMtcGFydHkg Y29udmVyc2F0aW9ucywgdGhhdCBkb2Vzbid0IHNjYWxlIHVwLiBXaXRoIG1hbnkgcGFydGllcywg c29tZSB0eXBpbmcgbWF5IHNjcm9sbCBvZmYgdGhlIHNjcmVlbiBiZWZvcmUgaXQgaXMgY29tcGxl dGUuDQoNClBlcmhhcHMgZm9yIGNvbmZlcmVuY2VzIGl0IGlzIGJldHRlciB0byBqdXN0IHVzZSBs aW5lLWF0LWEtdGltZSBjaGF0LiBJZiBuZWNlc3NhcnksIEkgcHJlc3VtZSB0aGVyZSBjb3VsZCBi ZSBnYXRld2F5cyBiZXR3ZWVuIFJUVCBhbmQgY2hhdC4gQSBSVUUgY291bGQgaGF2ZSB0aGUgY2Fw YWJpbGl0eSB0byBuZWdvdGlhdGUgZG93biBmcm9tIFJUVCB0byBjaGF0Lg0KDQoJVGhhbmtzLA0K CVBhdWwNCg0KT24gOC8yOC8xOSAyOjE1IEFNLCBHdW5uYXIgSGVsbHN0csO2bSB3cm90ZToNCj4g RGVuIDIwMTktMDgtMjcga2wuIDIzOjE1LCBza3JldiBCcmlhbiBSb3NlbjoNCj4+IEF0IGxlYXN0 IGJ5IGNlbnRyYWxpemluZyB0aGUgcHJvYmxlbSBhdCBhIOKAnG1peGVy4oCdLCBBbGljZSBhbmQg Qm9iIHdpbGwgDQo+PiBzZWUgdGhlIHNhbWUgdGhpbmcuDQo+Pg0KPj4gWW91IGRvbuKAmXQgaGF2 ZSB0aGUgcHJvYmxlbSBpbiBJbnN0YW50IE1lc3NhZ2luZywgYmVjYXVzZSB5b3UgY2Fu4oCZdCAN Cj4+IGJhY2tzcGFjZSBvciBkZWxldGUgYSBzZW50IG1lc3NhZ2UuIMKgT2YgY291cnNlIGlmIG11 bHRpcGxlIHBlb3BsZSBhcmUgDQo+PiB0eXBpbmcgc2ltdWx0YW5lb3VzbHkgaW4gc3VjaCBzeXN0 ZW1zLCBtZXNzYWdlIG9yZGVyIHdpbGwgYmUgDQo+PiBjb25mdXNpbmcgaW4gdGhhdCBpbnN0YW50 Lg0KPiBSaWdodCwgaXQgaXMgYSBzaW1pbGFyIGtpbmQgb2YgcHJvYmxlbSB0aGF0IHRleHQgYXBw ZWFycyBpbiBhbiANCj4gdW5leHBlY3RlZCBvcmRlci4gVGhlcmUgaXMgYWxzbyBhdCBsZWFzdCBv bmUgaW5zdGFudCBtZXNzYWdpbmcgc2VydmljZSANCj4gdGhhdCBhbGxvd3MgbW9kaWZpY2F0aW9u IGluIGFscmVhZHkgc2VudCBtZXNzYWdlLiBCdXQgSSB0aGluayBpdCBoYXMgDQo+IGxpbWl0YXRp b25zIHRvIG9ubHkgYWNjZXB0IHRoYXQgaW4gdGhlIGxhc3QgbWVzc2FnZSBzZW50LiBpdCBpcyAN Cj4gY29udmVuaWVudCBhbnl3YXkuDQo+Pg0KPj4gQW55d2F5LCB3ZSBuZWVkIHRvIHNwZWNpZnkg dGhlIG1peGVyIGZvciBSVFQgc28gaXQgcmVjZWl2ZXMgZWFjaCBvZiANCj4+IHRoZSBSVFQgc3Ry ZWFtcyBhbmQgcHJvZHVjZXMgYSBzaW5nbGUgY29tcG9zaXRlIHN0cmVhbSBmb3IgZWFjaCANCj4+ IHBhcnRpY2lwYW50Lg0KPiANCj4gWWVzLCByaWdodCwgYW5kIHRoZXJlIGlzIGFuIGVmZm9ydCBp biB0aGF0IGRpcmVjdGlvbiBpbjoNCj4gDQo+IGh0dHA6Ly93d3cucmVhbHRpbWV0ZXh0Lm9yZy9z aXRlcy9kZWZhdWx0L2ZpbGVzL0ZpbGVzX2FuZF9Eb2N1bWVudHMvU3ANCj4gZWNpZmljYXRpb25z L211bHRpcGFydHktcmVhbC10aW1lLXRleHQtbWl4ZXItMjAxMS0wNC0zMC5wZGYNCj4gDQo+IEl0 IGlzIHdyaXR0ZW4gZm9yIGNvbmZlcmVuY2UtdW5hd2FyZSB1c2VyIGRldmljZXMuDQo+IA0KPiBU aGUgZ29hbHMgYXJlIHNwZWNpZmllZCBhcyBmb2xsb3dzOg0KPiANCj4gVGhlIHByb2NlZHVyZXMg YXJlIGludGVuZGVkIHRvIG1ha2UgYmVzdCBlZmZvcnRzIHRvIHByZXNlbnQgYSANCj4gbXVsdGkt cGFydHkgdGV4dCBjb252ZXJzYXRpb24gb24gYSB0ZXJtaW5hbCB0aGF0IGhhcyBubyBhd2FyZW5l c3Mgb2YgDQo+IG11bHRpLXBhcnR5IGNhbGxzLiBUaGVyZSBhcmUgc29tZSBvYnZpb3VzIGRyYXdi YWNrcywgYW5kIGEgdGVybWluYWwgDQo+IGRlc2lnbmVkIHdpdGggbXVsdGktcGFydHkgYXdhcmVu ZXNzIHdpbGwgYmUgYWJsZSB0byBwcmVzZW50IA0KPiBtdWx0aS1wYXJ0eSBjYWxsIGNvbnRlbnRz IGluIGEgbW9yZSBmbGV4aWJsZSB3YXkuIE9ubHkgdHdvIHBhcnRpZXMgYXQgDQo+IGEgdGltZSB3 aWxsIGJlIGFsbG93ZWQgdG8gZGlzcGxheSBhZGRlZCB0ZXh0IGluIHJlYWwtdGltZSwgd2hpbGUg dGhlIG90aGVyIHBhcnRpZXPigJkNCj4gcHJvZHVjZWQgdGV4dCB3aWxsIG5lZWQgdG8gYmUgc3Rv cmVkIGluIHRoZSBtdWx0aS1wYXJ0eSBzZXJ2ZXIgZm9yIGEgDQo+IG1vbWVudCBhd2FpdGluZyBh IHN1aXRhYmxlIG9jY2FzaW9uIHRvIGJlIGRpc3BsYXllZC4gVGhlcmUgYXJlIGFsc28gDQo+IHNv bWUgY2FzZXMgb2YgZXJhc3VyZSB0aGF0IHdpbGwgbm90IGJlIHBlcmZvcm1lZCBvbiB0aGUgdGFy Z2V0IHRleHQgDQo+IGJ1dCBvbmx5IGluZGljYXRlZCBpbiBhbm90aGVyIHdheS4gRXZlbiB3aXRo IHRoZXNlIGRyYXdiYWNrcywgdGhlIA0KPiBwcm9jZWR1cmUgcHJvdmlkZXMgYW4gb3Bwb3J0dW5p dHkgdG8gZGlzcGxheSB0ZXh0IGZyb20gbW9yZSB0aGFuIHR3byANCj4gcGFydGllcyBpbiBhIHNt b290aCBhbmQgcmVhZGFibGUgd2F5Lg0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gSSBzZWUgc3VjaCBtaXhlciBwcm9jZWR1cmVzIGFz IGEgZmFsbC1iYWNrIGZvciBjYXNlcyB3aXRob3V0IA0KPiBjb25mZXJlbmNlIGF3YXJlbmVzcywg YnV0IHdhbnQgdG8gc2VlIHN1cHBvcnQgZm9yIGNvbmZlcmVuY2UtYXdhcmUgDQo+IHRlcm1pbmFs cywgd2hlcmUgdGV4dCBmcm9tIG1vcmUgdGhhbiB0d28gcGFydGllcyBjYW4gYmUgcHJlc2VudGVk IGluIA0KPiByZWFsLXRpbWUsIGFuZCB0aGUgZW5kIHVzZXIgb3IgYXBwIGNhbiBoYXZlIGluZmx1 ZW5jZSBvdmVyIHRoZSBwcmVzZW50YXRpb24gc3R5bGUgLSBlLmcuDQo+IHNlbGVjdCBiZXR3ZWVu IHRoZSBtdWx0aXBsZSBjb2x1bW4gdmlldyBhbmQgdGhlIG9uZS1jb2x1bW4td2l0aC1sYWJlbHMg DQo+IHZpZXcuwqAgQSBtaXhlciBmb3IgdGhhdCBjYXNlIHdvdWxkIG9ubHkgbmVlZCB0byBhc3N1 cmUgdGhhdCB0aGUgDQo+IHJlY2VpdmVyIGhhcyB0aGUgcmlnaHQga2luZCBvZiBtdWx0aS1wYXJ0 eSBhd2FyZW5lc3MgYW5kIHNlbmQgUlRUIHRleHQgDQo+IHdpdGggc291cmNlIGluZm9ybWF0aW9u IGF0dGFjaGVkLCBhbmQgbGV0IHRoZSByZWNlaXZpbmcgdGVybWluYWwgc29ydCANCj4gb3V0IHRo ZSBwcmVzZW50YXRpb24uIFRoaXMgaXMgYWxyZWFkeSBwb3NzaWJsZSB3aXRoIENTUkMgYW5kIENO QU1FIA0KPiB3aGVuIHVzaW5nIFJUUCwgYnV0IHdlIGxvc2UgdGhhdCBwb3NzaWJpbGl0eSBuYXRp dmVseSB3aGVuIHVzaW5nIHRoZSANCj4gV2ViUlRDIGRhdGEgY2hhbm5lbCB0byB0cmFuc3BvcnQg UlRULCBhbmQgd291bGQgbmVlZCB0byBzcGVjaWZ5IGEgd2F5IA0KPiB0byBpbmNsdWRlIHRoZSBz b3VyY2UgYWxzbyBmb3IgdGhhdCBjYXNlLg0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBCeSB0aGUgd2F5LCB3aGF0IGlz IHlvdXIgY3VycmVudCB2aWV3IG9mIGhvdyB0byB0cmFuc3BvcnQgUlRUIGZvciBSVU0sIA0KPiBu b3cgd2hlbiB5b3Ugc2F5IHRoYXQgeW91IHdpbGwgdXNlIFdlYlJUQyB0cmFuc3BvcnRzIGZvciBt ZWRpYT8NCj4gDQo+IFJlZ2FyZHMNCj4gDQo+IEd1bm5hcg0KPiANCj4+DQo+Pj4gT24gQXVnIDI3 LCAyMDE5LCBhdCA0OjQzIFBNLCBHdW5uYXIgSGVsbHN0csO2bSANCj4+PiA8Z3VubmFyLmhlbGxz dHJvbUBvbW5pdG9yLnNlIDxtYWlsdG86Z3VubmFyLmhlbGxzdHJvbUBvbW5pdG9yLnNlPj4gd3Jv dGU6DQo+Pj4NCj4+PiBEZW4gMjAxOS0wOC0yNyBrbC4gMjE6NDgsIHNrcmV2IEJyaWFuIFJvc2Vu Og0KPj4+PiBUaGUgcHJvYmxlbSBvZiBjb25mZXJlbmNlIDQxMDMgUlRUIGlzIGhpZ2ggb24gbXkg bGlzdCBvZiB3b3JrIEkgDQo+Pj4+IG5lZWQgdG8gZ2V0IGRvbmUuIMKgU28sIEnigJltIG1vdGl2 YXRlZCB0byBoZWxwIG91dC4NCj4+PiBUaGFua3MsIGdyZWF0Lg0KPj4+PiBUaGUgYmFzaWMgcHJv YmxlbSBpcyB0aGF0IHdl4oCZcmUgZ29pbmcgdG8gZ2V0IHZlcnkgaW5jb25zaXN0ZW50IFVJIA0K Pj4+PiBkb2luZyBpdCB0aGF0IHdheSwgYmVjYXVzZSBvZiBob3cgc3lzdGVtcyB3aWxsIGhhbmRs ZSBiYWNrc3BhY2Ugb2YgDQo+Pj4+IG9uZSBwYXJ0eSB0aGF0IGV4dGVuZHMgYmV5b25kIHJlc3Bv bnNlcyBmcm9tIG90aGVyIHBhcnRpZXM6DQo+Pj4gKHdlbGwsIGZvciBtZSB0aGUgY3VycmVudGx5 IG1vc3QgYmFzaWMgcHJvYmxlbSBpcyB0byBoYXZlIGEgcmVsaWFibGUgDQo+Pj4gd2F5IHRvIGFw cGVuZCByZWNlaXZlZCB0ZXh0IHRvIHRoZSBhbHJlYWR5IHByZXNlbnRlZCB0ZXh0IG9mIHRoZSAN Cj4+PiByaWdodCBwYXJ0aWNpcGFudC4gQW5kIHRoYXQgaXMgZ2V0dGluZyB3b3JzZSBpbiBXZWJS VEMgdGhhbiBpdCB3YXMgDQo+Pj4gaW4gUkZDIDQxMDMuIEJ1dCB3ZSB3aWxsIHNvcnQgaXQgb3V0 LikNCj4+Pj4NCj4+Pj4gQWxpY2U6IEkgd2FpdGVkIGZvciB5b3UNCj4+Pj4gQm9iOiBJIGRpZG7i gJl0IHNlZSB5b3UNCj4+Pj4gQWxpY2U6IHNvcnJ5DQo+Pj4+DQo+Pj4+IEFuZCB0aGVuIEFsaWNl IHR5cGVzIDEyIGJhY2tzcGFjZXMuDQo+Pj4+DQo+Pj4+IFdoYXQgc2hvdWxkIGhhcHBlbj8NCj4+ Pg0KPj4+IFlvdSBhcmUgcmlnaHQgdGhhdCB0aGVyZSBhcmUgYSBudW1iZXIgb2Ygd2F5cyB0byBo YW5kbGUgdGhlIFJUVCBVSS4gDQo+Pj4gQW5kIGp1c3QgYXMgaW5jb25zaXN0ZW5jaWVzIGFyZSBj b21tb24gd2l0aCBhIG1lc3NhZ2Ugb3JpZW50ZWQgVUksIA0KPj4+IHdoZXJlIG1lc3NhZ2VzIHNo b3cgdXAgaW4gYSBjb25mdXNpbmcgb3JkZXIgYmVjYXVzZSB0d28gdXNlcnMgDQo+Pj4gY29tcGxl dGVkIG1lc3NhZ2VzIGluIGFuIHVuZXhwZWN0ZWQgdGltZSBvcmRlciwgaXQgaXMgcG9zc2libGUg dGhhdCANCj4+PiBSVFQgdGV4dCBnZXRzIGRpc3BsYXllZCBpbiBhIHN0cmFuZ2Ugb3JkZXIgYWZ0 ZXIgZXJhc3VyZSBhbmQgDQo+Pj4gcmV0eXBpbmcuIEl0IGlzIGJldHRlciBmb3IgUlRUIHRoYW4g Zm9yIG1lc3NhZ2Ugb3JpZW50ZWQgDQo+Pj4gcHJlc2VudGF0aW9uLCBhbmQgdXNlciBnZXQgdXNl ZCB0byBpdCBpbiBib3RoIGNhc2VzLsKgIFdpdGggdGhlIA0KPj4+IGxhYmVsbGVkIHN0eWxlIGlu IG9uZSBjb2x1bW4geW91IGhhdmUgaW4gdGhlIGV4YW1wbGUsIEkgd291bGQgDQo+Pj4gcmVjb21t ZW5kIHRoYXQgZmlyc3QgNSBiYWNrc3BhY2VzIGVyYXNlICJzb3JyeSIsIG5leHQgYmFja3NwYWNl IA0KPj4+IGVyYXNlcyB0aGUgbGluZSBzZXBhcmF0b3IsIGFuZCBwdWxscyBkb3duICJJIHdhaXRl ZCBmb3IgeW91IiB0byBiZSANCj4+PiBzaG93biBsYXN0LCBhcyBhbiB1bmNvbXBsZXRlZCB0ZXh0 LiBUaGVuIHRoZSBuZXh0IDYgYmFja3NwYWNlcyBlcmFzZSANCj4+PiBzbyB0aGF0IG9ubHkgIkkg d2FpdGVkIGYiIGlzIGRpc3BsYXllZC4gV2hlbiBBbGljZSBhZGRzIHRleHQgYW5kIGVuZCANCj4+ PiB3aXRoIGEgbmV3IGxpbmUsIHRoZSBjb3JyZWN0ZWQgc2VudGVuY2UgaXMgYWxsb3dlZCB0byBm bG93IHVwIHdoZW4gDQo+Pj4gbmV3IHRleHQgaXMgYWRkZWQgZnJvbSBhbnkgcGFydGljaXBhbnQu wqAgVGhhdCBjYXVzZXMgYSBiaXQgc3RyYW5nZSANCj4+PiBvcmRlciwgYnV0IGl0IGlzIGp1c3Qg YXMgbWFuYWdlYWJsZSBhcyB3aGVuIHRleHQgaW4gbWVzc2FnaW5nIA0KPj4+IGFwcGxpY2F0aW9u cyBhcHBlYXIgaW4gYW4gdW5leHBlY3RlZCBvcmRlciBzbyB0aGF0IG9uZSBtZXNzYWdlIHNlZW1z IA0KPj4+IHRvIGJlIGEgcmVzcG9uZSBvbiBzb21ldGhpbmcgdG90YWxseSBlbHNlIHRoYW4gd2hh dCB3YXMgaW50ZW5kZWQuDQo+Pj4NCj4+PiBBIHNvcGhpc3RpY2F0ZWQgVUkgbWF5IG1hcmsgdGV4 dCB0aGF0IGlzIG1vdmVkIGFuZCBtb2RpZmllZC4NCj4+Pg0KPj4+IFdlIHdhbnQgdG8ga2VlcCBz ZW50ZW5jZXMgb3IgYXQgbGVhc3QgcGhyYXNlcyBmcm9tIGVhY2ggcGFydGljaXBhbnQgDQo+Pj4g dG9nZXRoZXIgaW4gYSByZWFkYWJsZSB1bml0LiBBbHJlYWR5IHRoYXQgY2F1c2VzIGEgZGVzaWdu IGRlY2lzaW9uIA0KPj4+IG9uIHdoZXJlIHRvIHBsYWNlIHRoZSBjb21wbGV0ZWQgY2h1bmsgb2Yg dGV4dCBvbmNlIHRoZSB1c2VyIGhhcyANCj4+PiBjb21wbGV0ZWQgaXQuIFRoZSBzdGFydCBvZiB0 aGUgY2h1bmsgbWF5IGJlIG9sZGVyIHRoYW4gY29tcGxldGVkIA0KPj4+IHRleHQgZnJvbSBvdGhl ciBwYXJ0aWNpcGFudHMgd2hpY2ggd291bGQgbW90aXZhdGUgdG8gbW92ZSBpdCB1cCBhIA0KPj4+ IGJpdCBpbiB0aGUgcHJlc2VudGF0aW9uLiBCdXQgdGhlIGVuZCBvZiBpdCBpcyBhdCB0aGF0IG1v bWVudCB0aGUgDQo+Pj4gbGF0ZXN0IHRleHQgdG8gcHJlc2VudC4gSSB0aGluayBpdCBpcyBiZXN0 IHRvIGxldCB0aGUgZmluaXNoZWQgdGV4dCANCj4+PiBiZSBwcmVzZW50ZWQgbGFzdCBvbiB0aGUg ZGlzcGxheSwgYnV0IGxldCBvdGhlcnMnIG5ld2VyIHRleHQgcHVzaCANCj4+PiBldmVyeXRoaW5n IHVwIGFuZCBiZSBkaXNwbGF5ZWQgbGFzdC4NCj4+Pg0KPj4+DQo+Pj4gVC4xNDAgaGFzIGluZm9y bWF0aW9uIG9uIGhvdyB0byBoYW5kbGUgZXJhc3VyZToNCj4+Pg0KPj4+IC0tLS0tLS0tLS0tLS0t LS0tLS1Gcm9tIFQuMTQwLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4NCj4+PiA4LjIg RXJhc2UgbGFzdCBjaGFyYWN0ZXINCj4+PiBQdXJwb3NlOiBFcmFzZSB0aGUgbGFzdCBjaGFyYWN0 ZXIgc2VudCBmcm9tIHRoZSBkaXNwbGF5IGF0IHRoZSANCj4+PiByZWNlaXZpbmcgZW5kLg0KPj4+ IENvZGU6IEJTOiAwMDA4Lg0KPj4+IFByb2NlZHVyZTogT24gdGhlIHJlY2VpdmluZyBlbmQ6IE1v dmUgdGhlIGluc2VydGlvbiBwb2ludCB0byB0aGUgDQo+Pj4gbGFzdCBjaGFyYWN0ZXIgYW5kIGVy YXNlIGl0Lg0KPj4+IENvbWJpbmVkIGNoYXJhY3RlcnMgYXJlIGVyYXNlZCBhcyBhIHVuaXQsIHdp dGggb25lIEJTIGVyYXNpbmcgdGhlIA0KPj4+IHdob2xlIGNoYXJhY3RlciBldmVuIGlmIGl0IGlz IGNvbWJpbmVkIGZyb20gbW9yZSB0aGFuIG9uZSBjb21wb25lbnQuDQo+Pj4gQ29udHJvbCBzZXF1 ZW5jZXMgKGxpa2UgQ1IgTEYpIGFyZSBlcmFzZWQgaW4gb25lIG9wZXJhdGlvbi4NCj4+PiBOT1RF IOKAkyBUaGUgc2FtZSBhY3Rpb24gc2hhbGwgYmUgdGFrZW4gb24gdGhlIGxvY2FsIGRpc3BsYXku DQo+Pj4NCj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4+Pg0KPj4+IMKgIC9HdW5uYXINCj4+Pg0KPj4+Pg0KPj4+PiBCcmlh bg0KPj4+Pg0KPj4+Pj4gT24gQXVnIDI3LCAyMDE5LCBhdCA5OjUyIEFNLCBHdW5uYXIgSGVsbHN0 csO2bSANCj4+Pj4+IDxndW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iuc2UgPG1haWx0bzpndW5uYXIu aGVsbHN0cm9tQG9tbml0b3Iuc2U+Pg0KPj4+Pj4gd3JvdGU6DQo+Pj4+Pg0KPj4+Pj4gSGksDQo+ Pj4+Pg0KPj4+Pj4gQSB0b3BpYyBpcyBjdXJyZW50bHkgZGlzY3Vzc2VkIGluIG1tdXNpYyB0aGF0 IGlzIGNsb3NlbHkgcmVsYXRlZCANCj4+Pj4+IHRvIHJ1bS4gaXQgaXMgV2ViUlRDIHRyYW5zcG9y dCBvZiByZWFsLXRpbWUgdGV4dC4NCj4+Pj4+DQo+Pj4+PiBUaGUgZHJhZnQgaXMgZHJhZnQtaG9s bWJlcmctbW11c2ljLXQxNDAtdXNhZ2UtZGF0YS1jaGFubmVsIC4NCj4+Pj4+DQo+Pj4+PiBBIGdv b2QgcG9pbnQgdG8gc3RhcnQgcmVhZGluZyBjb3VsZCBiZToNCj4+Pj4+DQo+Pj4+PiBodHRwczov L21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvYnJvd3NlL21tdXNpYy8/Z2J0PTEmcT1kcmFmdC1o b2wNCj4+Pj4+IG1iZXJnLW1tdXNpYy10MTQwLXVzYWdlLWRhdGEtY2hhbm5lbA0KPj4+Pj4NCj4+ Pj4+IFBsZWFzZSBjaGVjayBpZiB0aGUgY3VycmVudCBzdGF0ZSBvZiB0aGUgZGlzY3Vzc2lvbiBz dWl0cyBydW0hDQo+Pj4+Pg0KPj4+Pj4gVGhlIG9ubHkgaXNzdWUgdGhhdCBzZWVtcyB0byBiZSBy ZW1haW5pbmcgaXMgaG93IHRvIHRyYW5zcG9ydCBSVFQgDQo+Pj4+PiBkYXRhIHRvIGFuZCBmcm9t IGEgY29uZmVyZW5jZSBzZXJ2ZXIgdGhhdCBjb21iaW5lcyBhbGwgdHJhZmZpYyBwZXIgDQo+Pj4+ PiBtZWRpYSBpbiBhIG1lZXRpbmcgaW4gb25lIGRhdGEgc3RyZWFtLiBUaGF0IGlzIG5vdCB2ZXJ5 IGVsZWdhbnRseSANCj4+Pj4+IHNwZWNpZmllZCBmb3IgUkZDIDQxMDMgdHJhbnNwb3J0IG9mIFJU VCBpbiBSVFAgZWl0aGVyLCBzbyB3ZSBtaWdodCANCj4+Pj4+IHdhbnQgdG8gZG8gYSByYXBpZCBh Y3Rpb24gdG9nZXRoZXIgdG8gc29sdmUgdGhlIG11bHRpLXBhcnR5IFJUVCANCj4+Pj4+IE1DVSBj YXNlIGluIGEgZ2VuZXJhbCBhbmQgY29uc2lzdGVudCB3YXkuDQo+Pj4+Pg0KPj4+Pj4gUmVnYXJk cw0KPj4+Pj4NCj4+Pj4+IEd1bm5hcg0KPj4+Pj4NCj4+Pj4+IC0tDQo+Pj4+PiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+Pj4gR3VubmFyIEhlbGxzdHLDtm0N Cj4+Pj4+IE9tbml0b3INCj4+Pj4+IGd1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5zZQ0KPj4+Pj4g KzQ2IDcwOCAyMDQgMjg4DQo+Pj4+Pg0KPj4+Pj4NCj4+PiAtLQ0KPj4+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4gR3VubmFyIEhlbGxzdHLDtm0NCj4+PiBP bW5pdG9yDQo+Pj4gZ3VubmFyLmhlbGxzdHJvbUBvbW5pdG9yLnNlIDxtYWlsdG86Z3VubmFyLmhl bGxzdHJvbUBvbW5pdG9yLnNlPg0KPj4+ICs0NiA3MDggMjA0IDI4OA0KPj4NCj4+DQo+IC0tDQo+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IEd1bm5hciBIZWxs c3Ryw7ZtDQo+IE9tbml0b3INCj4gZ3VubmFyLmhlbGxzdHJvbUBvbW5pdG9yLnNlDQo+ICs0NiA3 MDggMjA0IDI4OA0KPiANCj4gDQoNCi0tDQpSdW0gbWFpbGluZyBsaXN0DQpSdW1AaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnVtDQo= From nobody Thu Aug 29 09:58:06 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF579120A2F for ; Thu, 29 Aug 2019 09:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRFBPGKxQEYm for ; Thu, 29 Aug 2019 09:58:00 -0700 (PDT) Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EC26120A1C for ; Thu, 29 Aug 2019 09:58:00 -0700 (PDT) Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x7TGvw3k030568 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 29 Aug 2019 12:57:59 -0400 To: rum@ietf.org References: <9a14addd-9a1c-6130-3880-a814be717323@omnitor.se> <59F6B4E5-16DF-42EB-A654-1749BC9487B5@brianrosen.net> <25517_1567094729_5D67F7C4_25517_54_4_48c0bc62-0f75-4f83-6d9c-f763982dd000@alum.mit.edu> From: Paul Kyzivat Message-ID: <861073bb-d431-0069-adbf-69a3c11a9125@alum.mit.edu> Date: Thu, 29 Aug 2019 12:57:58 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rum] [EXT] Re: Real-time text in WebRTC is discussed in mmusic - a topic closely telated to rum X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 16:58:04 -0000 Hi Jim, On 8/29/19 12:20 PM, Malloy, Jim wrote: > Do we intend for the RUE to accommodate multiple party calls (more than three)? I don't recall any language related to anything but a point to point call. For emergency calls, conferencing in the PSAP (three parties) may be appropriate. Are we looking for more than that? Good question. Speaking as an individual, not chair: IIUC, VRS service (with a CA) explicitly excludes conference calls. But I don't think that extends to P2P video calls. Though there is no mechanism provided for establishing a conference, it should be acceptable using mechanisms outside of the VRS infrastructure. Since a P2P call can only be established between two parties that have entries in iTRS, it would seem to require something that has qualified to get a number in there, that can properly interface. Perhaps something that totally meets the specs for a RUE. So it is all hypothetical at the moment. How deep we want to get into this hypothetical case remains to be determined. I'm inclined to think it should be out of scope for now. What do others think? Thanks, Paul > --Jim Malloy > > -----Original Message----- > From: Rum On Behalf Of Paul Kyzivat > Sent: Thursday, August 29, 2019 12:05 PM > To: rum@ietf.org > Subject: [EXT] Re: [Rum] Real-time text in WebRTC is discussed in mmusic - a topic closely telated to rum > > I question how well RTT text is suited to multiparty conferences. > > If you have messages on your screen from multiple parties, and many of them are updating in real-time, are you going to be able to perceive what is going on? > > And while you can have a column per person for two-party and maybe 3-party conversations, that doesn't scale up. With many parties, some typing may scroll off the screen before it is complete. > > Perhaps for conferences it is better to just use line-at-a-time chat. If necessary, I presume there could be gateways between RTT and chat. A RUE could have the capability to negotiate down from RTT to chat. > > Thanks, > Paul > > On 8/28/19 2:15 AM, Gunnar Hellström wrote: >> Den 2019-08-27 kl. 23:15, skrev Brian Rosen: >>> At least by centralizing the problem at a “mixer”, Alice and Bob will >>> see the same thing. >>> >>> You don’t have the problem in Instant Messaging, because you can’t >>> backspace or delete a sent message.  Of course if multiple people are >>> typing simultaneously in such systems, message order will be >>> confusing in that instant. >> Right, it is a similar kind of problem that text appears in an >> unexpected order. There is also at least one instant messaging service >> that allows modification in already sent message. But I think it has >> limitations to only accept that in the last message sent. it is >> convenient anyway. >>> >>> Anyway, we need to specify the mixer for RTT so it receives each of >>> the RTT streams and produces a single composite stream for each >>> participant. >> >> Yes, right, and there is an effort in that direction in: >> >> http://www.realtimetext.org/sites/default/files/Files_and_Documents/Sp >> ecifications/multiparty-real-time-text-mixer-2011-04-30.pdf >> >> It is written for conference-unaware user devices. >> >> The goals are specified as follows: >> >> The procedures are intended to make best efforts to present a >> multi-party text conversation on a terminal that has no awareness of >> multi-party calls. There are some obvious drawbacks, and a terminal >> designed with multi-party awareness will be able to present >> multi-party call contents in a more flexible way. Only two parties at >> a time will be allowed to display added text in real-time, while the other parties’ >> produced text will need to be stored in the multi-party server for a >> moment awaiting a suitable occasion to be displayed. There are also >> some cases of erasure that will not be performed on the target text >> but only indicated in another way. Even with these drawbacks, the >> procedure provides an opportunity to display text from more than two >> parties in a smooth and readable way. >> >> ---------------------------------------------------------------------- >> ----------------------------- >> >> I see such mixer procedures as a fall-back for cases without >> conference awareness, but want to see support for conference-aware >> terminals, where text from more than two parties can be presented in >> real-time, and the end user or app can have influence over the presentation style - e.g. >> select between the multiple column view and the one-column-with-labels >> view.  A mixer for that case would only need to assure that the >> receiver has the right kind of multi-party awareness and send RTT text >> with source information attached, and let the receiving terminal sort >> out the presentation. This is already possible with CSRC and CNAME >> when using RTP, but we lose that possibility natively when using the >> WebRTC data channel to transport RTT, and would need to specify a way >> to include the source also for that case. >> >> ------------------------------------------------------ >> >> By the way, what is your current view of how to transport RTT for RUM, >> now when you say that you will use WebRTC transports for media? >> >> Regards >> >> Gunnar >> >>> >>>> On Aug 27, 2019, at 4:43 PM, Gunnar Hellström >>>> > wrote: >>>> >>>> Den 2019-08-27 kl. 21:48, skrev Brian Rosen: >>>>> The problem of conference 4103 RTT is high on my list of work I >>>>> need to get done.  So, I’m motivated to help out. >>>> Thanks, great. >>>>> The basic problem is that we’re going to get very inconsistent UI >>>>> doing it that way, because of how systems will handle backspace of >>>>> one party that extends beyond responses from other parties: >>>> (well, for me the currently most basic problem is to have a reliable >>>> way to append received text to the already presented text of the >>>> right participant. And that is getting worse in WebRTC than it was >>>> in RFC 4103. But we will sort it out.) >>>>> >>>>> Alice: I waited for you >>>>> Bob: I didn’t see you >>>>> Alice: sorry >>>>> >>>>> And then Alice types 12 backspaces. >>>>> >>>>> What should happen? >>>> >>>> You are right that there are a number of ways to handle the RTT UI. >>>> And just as inconsistencies are common with a message oriented UI, >>>> where messages show up in a confusing order because two users >>>> completed messages in an unexpected time order, it is possible that >>>> RTT text gets displayed in a strange order after erasure and >>>> retyping. It is better for RTT than for message oriented >>>> presentation, and user get used to it in both cases.  With the >>>> labelled style in one column you have in the example, I would >>>> recommend that first 5 backspaces erase "sorry", next backspace >>>> erases the line separator, and pulls down "I waited for you" to be >>>> shown last, as an uncompleted text. Then the next 6 backspaces erase >>>> so that only "I waited f" is displayed. When Alice adds text and end >>>> with a new line, the corrected sentence is allowed to flow up when >>>> new text is added from any participant.  That causes a bit strange >>>> order, but it is just as manageable as when text in messaging >>>> applications appear in an unexpected order so that one message seems >>>> to be a respone on something totally else than what was intended. >>>> >>>> A sophisticated UI may mark text that is moved and modified. >>>> >>>> We want to keep sentences or at least phrases from each participant >>>> together in a readable unit. Already that causes a design decision >>>> on where to place the completed chunk of text once the user has >>>> completed it. The start of the chunk may be older than completed >>>> text from other participants which would motivate to move it up a >>>> bit in the presentation. But the end of it is at that moment the >>>> latest text to present. I think it is best to let the finished text >>>> be presented last on the display, but let others' newer text push >>>> everything up and be displayed last. >>>> >>>> >>>> T.140 has information on how to handle erasure: >>>> >>>> -------------------From T.140--------------------------- >>>> >>>> 8.2 Erase last character >>>> Purpose: Erase the last character sent from the display at the >>>> receiving end. >>>> Code: BS: 0008. >>>> Procedure: On the receiving end: Move the insertion point to the >>>> last character and erase it. >>>> Combined characters are erased as a unit, with one BS erasing the >>>> whole character even if it is combined from more than one component. >>>> Control sequences (like CR LF) are erased in one operation. >>>> NOTE – The same action shall be taken on the local display. >>>> >>>> ------------------------------------------------------------ >>>> >>>>   /Gunnar >>>> >>>>> >>>>> Brian >>>>> >>>>>> On Aug 27, 2019, at 9:52 AM, Gunnar Hellström >>>>>> > >>>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> A topic is currently discussed in mmusic that is closely related >>>>>> to rum. it is WebRTC transport of real-time text. >>>>>> >>>>>> The draft is draft-holmberg-mmusic-t140-usage-data-channel . >>>>>> >>>>>> A good point to start reading could be: >>>>>> >>>>>> https://mailarchive.ietf.org/arch/browse/mmusic/?gbt=1&q=draft-hol >>>>>> mberg-mmusic-t140-usage-data-channel >>>>>> >>>>>> Please check if the current state of the discussion suits rum! >>>>>> >>>>>> The only issue that seems to be remaining is how to transport RTT >>>>>> data to and from a conference server that combines all traffic per >>>>>> media in a meeting in one data stream. That is not very elegantly >>>>>> specified for RFC 4103 transport of RTT in RTP either, so we might >>>>>> want to do a rapid action together to solve the multi-party RTT >>>>>> MCU case in a general and consistent way. >>>>>> >>>>>> Regards >>>>>> >>>>>> Gunnar >>>>>> >>>>>> -- >>>>>> ----------------------------------------- >>>>>> Gunnar Hellström >>>>>> Omnitor >>>>>> gunnar.hellstrom@omnitor.se >>>>>> +46 708 204 288 >>>>>> >>>>>> >>>> -- >>>> ----------------------------------------- >>>> Gunnar Hellström >>>> Omnitor >>>> gunnar.hellstrom@omnitor.se >>>> +46 708 204 288 >>> >>> >> -- >> ----------------------------------------- >> Gunnar Hellström >> Omnitor >> gunnar.hellstrom@omnitor.se >> +46 708 204 288 >> >> > > -- > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum > From nobody Thu Aug 29 10:15:08 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28BB8120A4A for ; Thu, 29 Aug 2019 10:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPWrUiR7jUmi for ; Thu, 29 Aug 2019 10:14:55 -0700 (PDT) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D87D120A60 for ; Thu, 29 Aug 2019 10:14:55 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id j15so4455675qtl.13 for ; Thu, 29 Aug 2019 10:14:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=5cCAkens0TJOSzhNGVAZyFfvRnstcsNVkUcMt5RTOyg=; b=2HkRr9fOpBLmUyUxEfNfO71HaZEZXf+73KYHpLoiaLNwSRDWunwijBWN6WNI3kLIWN nDPdvdF+TL1NSQbTVjBGHjRk5f0lJTq493BLsMAQreAY4COddz+40iPMx6nFP0wpcMj2 bhK1OyjxG52Sl65a48PJvyeZTxd1/GlrCER5jfZ5BhcMxfkwGo7nKytz8LfThmtpsOzn XudbFQPI8J/3RMvtEPFW9mxms63dvJWTIFWvJ7WWmrkeBZmOfOIAEnphX0JpEPxVBwy+ XAGO/gksq4PyzbDgWHN0JtiuY144vWALH0xv/XkmxZIx5hQeN7LFmaISShoO8Cj6t2WA nR7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=5cCAkens0TJOSzhNGVAZyFfvRnstcsNVkUcMt5RTOyg=; b=XbsxR9O6JjQUlhiaQhYUMdYFxgSjtTFOwsE8XaA+6UkgC6HEYiXxFH+MRVsgOZEs+L hTZGxZhXXTET/Uihk7cbipN8AnC1Z9VXj9SqYOcm7r1Bhb+u5fK/pIO9xz0AIJkC+DMc F6JVQVpv3xPgv0DZmfRLqZUql2g/QZpYFPhC1sWq8NGglK7IAF+xk1saoB2YWI2FOqiG GPHfiGJd91nN7kfTs9sZaMrZl3EKbvsqOlEzAGA8Yhm93qnjkism3eKiQ1IegdD1T9KM m6iW7D7kcnNNz5sexNNo3XyCgCzQLbi0Dy/jbYIQ0q5gO/VBSyOlPh4A4S7NRRmDjZ2t 2y+Q== X-Gm-Message-State: APjAAAW+QpcmecBHxwSM8qy+Jbz77xT5+bgp30+8xexa+991A77ia9/B CtbkeP7Q7R8GywXNNtMGNKHi+A== X-Google-Smtp-Source: APXvYqxgaBtW6ixQIRZYqQJTsrr3bx0RCBUd9kDxQAQtLpBoaUGPu8RBLQhE5u0qhaY/Tcw1ZM1n6A== X-Received: by 2002:ac8:4705:: with SMTP id f5mr4556426qtp.126.1567098894032; Thu, 29 Aug 2019 10:14:54 -0700 (PDT) Received: from brians-mbp-2388.lan ([24.154.122.195]) by smtp.gmail.com with ESMTPSA id w5sm1352620qki.13.2019.08.29.10.14.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Aug 2019 10:14:53 -0700 (PDT) From: Brian Rosen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B34D5AEC-1D19-4E31-86B8-708532CB1AC8" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 29 Aug 2019 13:14:52 -0400 In-Reply-To: <48c0bc62-0f75-4f83-6d9c-f763982dd000@alum.mit.edu> Cc: rum@ietf.org To: Paul Kyzivat References: <9a14addd-9a1c-6130-3880-a814be717323@omnitor.se> <59F6B4E5-16DF-42EB-A654-1749BC9487B5@brianrosen.net> <48c0bc62-0f75-4f83-6d9c-f763982dd000@alum.mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Rum] Real-time text in WebRTC is discussed in mmusic - a topic closely telated to rum X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 17:15:06 -0000 --Apple-Mail=_B34D5AEC-1D19-4E31-86B8-708532CB1AC8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 =E2=80=9CLine at a time=E2=80=9D could be an implementation option. The = protocol mechanism is all streams head to a mixer and the mixer sends a = single stream to each participant. Gunnar, we agreed we were using 4103 in RUM. Brian > On Aug 29, 2019, at 12:05 PM, Paul Kyzivat = wrote: >=20 > I question how well RTT text is suited to multiparty conferences. >=20 > If you have messages on your screen from multiple parties, and many of = them are updating in real-time, are you going to be able to perceive = what is going on? >=20 > And while you can have a column per person for two-party and maybe = 3-party conversations, that doesn't scale up. With many parties, some = typing may scroll off the screen before it is complete. >=20 > Perhaps for conferences it is better to just use line-at-a-time chat. = If necessary, I presume there could be gateways between RTT and chat. A = RUE could have the capability to negotiate down from RTT to chat. >=20 > Thanks, > Paul >=20 > On 8/28/19 2:15 AM, Gunnar Hellstr=C3=B6m wrote: >> Den 2019-08-27 kl. 23:15, skrev Brian Rosen: >>> At least by centralizing the problem at a =E2=80=9Cmixer=E2=80=9D, = Alice and Bob will see the same thing. >>>=20 >>> You don=E2=80=99t have the problem in Instant Messaging, because you = can=E2=80=99t backspace or delete a sent message. Of course if multiple = people are typing simultaneously in such systems, message order will be = confusing in that instant. >> Right, it is a similar kind of problem that text appears in an = unexpected order. There is also at least one instant messaging service = that allows modification in already sent message. But I think it has = limitations to only accept that in the last message sent. it is = convenient anyway. >>>=20 >>> Anyway, we need to specify the mixer for RTT so it receives each of = the RTT streams and produces a single composite stream for each = participant. >> Yes, right, and there is an effort in that direction in: >> = http://www.realtimetext.org/sites/default/files/Files_and_Documents/Specif= ications/multiparty-real-time-text-mixer-2011-04-30.pdf >> It is written for conference-unaware user devices. >> The goals are specified as follows: >> The procedures are intended to make best efforts to present a = multi-party text conversation on a terminal that has no awareness of = multi-party calls. There are some obvious drawbacks, and a terminal = designed with multi-party awareness will be able to present multi-party = call contents in a more flexible way. Only two parties at a time will be = allowed to display added text in real-time, while the other parties=E2=80=99= produced text will need to be stored in the multi-party server for a = moment awaiting a suitable occasion to be displayed. There are also some = cases of erasure that will not be performed on the target text but only = indicated in another way. Even with these drawbacks, the procedure = provides an opportunity to display text from more than two parties in a = smooth and readable way. >> = --------------------------------------------------------------------------= ------------------------- >> I see such mixer procedures as a fall-back for cases without = conference awareness, but want to see support for conference-aware = terminals, where text from more than two parties can be presented in = real-time, and the end user or app can have influence over the = presentation style - e.g. select between the multiple column view and = the one-column-with-labels view. A mixer for that case would only need = to assure that the receiver has the right kind of multi-party awareness = and send RTT text with source information attached, and let the = receiving terminal sort out the presentation. This is already possible = with CSRC and CNAME when using RTP, but we lose that possibility = natively when using the WebRTC data channel to transport RTT, and would = need to specify a way to include the source also for that case. >> ------------------------------------------------------ >> By the way, what is your current view of how to transport RTT for = RUM, now when you say that you will use WebRTC transports for media? >> Regards >> Gunnar >>>=20 >>>> On Aug 27, 2019, at 4:43 PM, Gunnar Hellstr=C3=B6m = = >> wrote: >>>>=20 >>>> Den 2019-08-27 kl. 21:48, skrev Brian Rosen: >>>>> The problem of conference 4103 RTT is high on my list of work I = need to get done. So, I=E2=80=99m motivated to help out. >>>> Thanks, great. >>>>> The basic problem is that we=E2=80=99re going to get very = inconsistent UI doing it that way, because of how systems will handle = backspace of one party that extends beyond responses from other parties: >>>> (well, for me the currently most basic problem is to have a = reliable way to append received text to the already presented text of = the right participant. And that is getting worse in WebRTC than it was = in RFC 4103. But we will sort it out.) >>>>>=20 >>>>> Alice: I waited for you >>>>> Bob: I didn=E2=80=99t see you >>>>> Alice: sorry >>>>>=20 >>>>> And then Alice types 12 backspaces. >>>>>=20 >>>>> What should happen? >>>>=20 >>>> You are right that there are a number of ways to handle the RTT UI. = And just as inconsistencies are common with a message oriented UI, where = messages show up in a confusing order because two users completed = messages in an unexpected time order, it is possible that RTT text gets = displayed in a strange order after erasure and retyping. It is better = for RTT than for message oriented presentation, and user get used to it = in both cases. With the labelled style in one column you have in the = example, I would recommend that first 5 backspaces erase "sorry", next = backspace erases the line separator, and pulls down "I waited for you" = to be shown last, as an uncompleted text. Then the next 6 backspaces = erase so that only "I waited f" is displayed. When Alice adds text and = end with a new line, the corrected sentence is allowed to flow up when = new text is added from any participant. That causes a bit strange = order, but it is just as manageable as when text in messaging = applications appear in an unexpected order so that one message seems to = be a respone on something totally else than what was intended. >>>>=20 >>>> A sophisticated UI may mark text that is moved and modified. >>>>=20 >>>> We want to keep sentences or at least phrases from each participant = together in a readable unit. Already that causes a design decision on = where to place the completed chunk of text once the user has completed = it. The start of the chunk may be older than completed text from other = participants which would motivate to move it up a bit in the = presentation. But the end of it is at that moment the latest text to = present. I think it is best to let the finished text be presented last = on the display, but let others' newer text push everything up and be = displayed last. >>>>=20 >>>>=20 >>>> T.140 has information on how to handle erasure: >>>>=20 >>>> -------------------=46rom T.140--------------------------- >>>>=20 >>>> 8.2 Erase last character >>>> Purpose: Erase the last character sent from the display at the = receiving end. >>>> Code: BS: 0008. >>>> Procedure: On the receiving end: Move the insertion point to the = last character and erase it. >>>> Combined characters are erased as a unit, with one BS erasing the = whole character even if it is >>>> combined from more than one component. >>>> Control sequences (like CR LF) are erased in one operation. >>>> NOTE =E2=80=93 The same action shall be taken on the local display. >>>>=20 >>>> ------------------------------------------------------------ >>>>=20 >>>> /Gunnar >>>>=20 >>>>>=20 >>>>> Brian >>>>>=20 >>>>>> On Aug 27, 2019, at 9:52 AM, Gunnar Hellstr=C3=B6m = = >> wrote: >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> A topic is currently discussed in mmusic that is closely related = to rum. it is WebRTC transport of real-time text. >>>>>>=20 >>>>>> The draft is draft-holmberg-mmusic-t140-usage-data-channel . >>>>>>=20 >>>>>> A good point to start reading could be: >>>>>>=20 >>>>>> = https://mailarchive.ietf.org/arch/browse/mmusic/?gbt=3D1&q=3Ddraft-holmber= g-mmusic-t140-usage-data-channel = >>>>>>=20 >>>>>> Please check if the current state of the discussion suits rum! >>>>>>=20 >>>>>> The only issue that seems to be remaining is how to transport RTT = data to and from a conference server that combines all traffic per media = in a meeting in one data stream. That is not very elegantly specified = for RFC 4103 transport of RTT in RTP either, so we might want to do a = rapid action together to solve the multi-party RTT MCU case in a general = and consistent way. >>>>>>=20 >>>>>> Regards >>>>>>=20 >>>>>> Gunnar >>>>>>=20 >>>>>> -- >>>>>> ----------------------------------------- >>>>>> Gunnar Hellstr=C3=B6m >>>>>> Omnitor >>>>>> gunnar.hellstrom@omnitor.se >>>>>> +46 708 204 288 >>>>>>=20 >>>>>>=20 >>>> -- >>>> ----------------------------------------- >>>> Gunnar Hellstr=C3=B6m >>>> Omnitor >>>> gunnar.hellstrom@omnitor.se = > >>>> +46 708 204 288 >>>=20 >>>=20 >> --=20 >> ----------------------------------------- >> Gunnar Hellstr=C3=B6m >> Omnitor >> gunnar.hellstrom@omnitor.se >> +46 708 204 288 >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum = --Apple-Mail=_B34D5AEC-1D19-4E31-86B8-708532CB1AC8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 =E2=80=9CLine at a time=E2=80=9D could be an implementation = option.  The protocol mechanism is all streams head to a mixer and = the mixer sends a single stream to each participant.

Gunnar, we agreed we were using 4103 in = RUM.

Brian

On Aug 29, 2019, at 12:05 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

I question how well RTT text is = suited to multiparty conferences.

If you have messages on your screen from multiple parties, = and many of them are updating in real-time, are you going to be able to = perceive what is going on?

And while you can have a column per person for two-party and = maybe 3-party conversations, that doesn't scale up. With many parties, = some typing may scroll off the screen before it is complete.

Perhaps for conferences it is = better to just use line-at-a-time chat. If necessary, I presume there = could be gateways between RTT and chat. A RUE could have the capability = to negotiate down from RTT to chat.

= Thanks,
= Paul

On 8/28/19 2:15 AM, Gunnar = Hellstr=C3=B6m wrote:
Den 2019-08-27 kl. 23:15, skrev Brian = Rosen:
At least by = centralizing the problem at a =E2=80=9Cmixer=E2=80=9D, Alice and Bob = will see the same thing.

You don=E2=80=99t = have the problem in Instant Messaging, because you can=E2=80=99t = backspace or delete a sent message.  Of course if multiple people = are typing simultaneously in such systems, message order will be = confusing in that instant.
Right, it is a = similar kind of problem that text appears in an unexpected order. There = is also at least one instant messaging service that allows modification = in already sent message. But I think it has limitations to only accept = that in the last message sent. it is convenient anyway.

Anyway, = we need to specify the mixer for RTT so it receives each of the RTT = streams and produces a single composite stream for each participant.
Yes, right, and there is an effort in that = direction in:
http://www.realtimetext.org/sites/default/files/Files_and_Docum= ents/Specifications/multiparty-real-time-text-mixer-2011-04-30.pdf
It is written for conference-unaware user devices.
The goals are specified as follows:
The = procedures are intended to make best efforts to present a multi-party = text conversation on a terminal that has no awareness of multi-party = calls. There are some obvious drawbacks, and a terminal designed with = multi-party awareness will be able to present multi-party call contents = in a more flexible way. Only two parties at a time will be allowed to = display added text in real-time, while the other parties=E2=80=99 = produced text will need to be stored in the multi-party server for a = moment awaiting a suitable occasion to be displayed. There are also some = cases of erasure that will not be performed on the target text but only = indicated in another way. Even with these drawbacks, the procedure = provides an opportunity to display text from more than two parties in a = smooth and readable way.
---------------------------------------------------------------= ------------------------------------
I see such mixer = procedures as a fall-back for cases without conference awareness, but = want to see support for conference-aware terminals, where text from more = than two parties can be presented in real-time, and the end user or app = can have influence over the presentation style - e.g. select between the = multiple column view and the one-column-with-labels view.  A mixer = for that case would only need to assure that the receiver has the right = kind of multi-party awareness and send RTT text with source information = attached, and let the receiving terminal sort out the presentation. This = is already possible with CSRC and CNAME when using RTP, but we lose that = possibility natively when using the WebRTC data channel to transport = RTT, and would need to specify a way to include the source also for that = case.
------------------------------------------------------
By the way, what is your current view of how to transport RTT = for RUM, now when you say that you will use WebRTC transports for = media?
Regards
Gunnar

On Aug 27, 2019, at 4:43 PM, Gunnar Hellstr=C3=B6= m <gunnar.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se>> wrote:

Den 2019-08-27 kl. 21:48, skrev Brian = Rosen:
The problem of = conference 4103 RTT is high on my list of work I need to get done. =  So, I=E2=80=99m motivated to help out.
Thanks, great.
The basic problem is that we=E2=80=99re going = to get very inconsistent UI doing it that way, because of how systems = will handle backspace of one party that extends beyond responses from = other parties:
(well, for me the currently = most basic problem is to have a reliable way to append received text to = the already presented text of the right participant. And that is getting = worse in WebRTC than it was in RFC 4103. But we will sort it out.)

Alice: I = waited for you
Bob: I didn=E2=80=99t see you
Alice: sorry

And then Alice = types 12 backspaces.

What should happen?

You are right that there are a = number of ways to handle the RTT UI. And just as inconsistencies are = common with a message oriented UI, where messages show up in a confusing = order because two users completed messages in an unexpected time order, = it is possible that RTT text gets displayed in a strange order after = erasure and retyping. It is better for RTT than for message oriented = presentation, and user get used to it in both cases.  With the = labelled style in one column you have in the example, I would recommend = that first 5 backspaces erase "sorry", next backspace erases the line = separator, and pulls down "I waited for you" to be shown last, as an = uncompleted text. Then the next 6 backspaces erase so that only "I = waited f" is displayed. When Alice adds text and end with a new line, = the corrected sentence is allowed to flow up when new text is added from = any participant.  That causes a bit strange order, but it is just = as manageable as when text in messaging applications appear in an = unexpected order so that one message seems to be a respone on something = totally else than what was intended.

A = sophisticated UI may mark text that is moved and modified.

We want to keep sentences or at least phrases = from each participant together in a readable unit. Already that causes a = design decision on where to place the completed chunk of text once the = user has completed it. The start of the chunk may be older than = completed text from other participants which would motivate to move it = up a bit in the presentation. But the end of it is at that moment the = latest text to present. I think it is best to let the finished text be = presented last on the display, but let others' newer text push = everything up and be displayed last.


T.140 has information on how to handle erasure:

-------------------=46rom = T.140---------------------------

8.2 Erase = last character
Purpose: Erase the last character sent from = the display at the receiving end.
Code: BS: 0008.
Procedure: On the receiving end: Move the insertion point to = the last character and erase it.
Combined characters are = erased as a unit, with one BS erasing the whole character even if it = is
combined from more than one component.
Control sequences (like CR LF) are erased in one = operation.
NOTE =E2=80=93 The same action shall be taken = on the local display.

------------------------------------------------------------
  /Gunnar


Brian

On Aug = 27, 2019, at 9:52 AM, Gunnar Hellstr=C3=B6m <gunnar.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se>> wrote:

Hi,

A topic is = currently discussed in mmusic that is closely related to rum. it is = WebRTC transport of real-time text.

The = draft is draft-holmberg-mmusic-t140-usage-data-channel .
A good point to start reading could be:

https://mailarchive.ietf.org/arch/browse/mmusic/?gbt=3D1&q=3D= draft-holmberg-mmusic-t140-usage-data-channel

Please check if the current state of the discussion suits = rum!

The only issue that seems to be = remaining is how to transport RTT data to and from a conference server = that combines all traffic per media in a meeting in one data stream. = That is not very elegantly specified for RFC 4103 transport of RTT in = RTP either, so we might want to do a rapid action together to solve the = multi-party RTT MCU case in a general and consistent way.

Regards

Gunnar

--
-----------------------------------------
Gunnar = Hellstr=C3=B6m
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 = 288


--
-----------------------------------------
Gunnar = Hellstr=C3=B6m
Omnitor
gunnar.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se>
+46 = 708 204 288


-- 
-----------------------------------------
Gunnar = Hellstr=C3=B6m
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 = 288

-- Rum mailing list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum

= --Apple-Mail=_B34D5AEC-1D19-4E31-86B8-708532CB1AC8-- From nobody Thu Aug 29 10:15:36 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11AE5120A6C for ; Thu, 29 Aug 2019 10:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gC72UnC-l6D for ; Thu, 29 Aug 2019 10:15:26 -0700 (PDT) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAFB5120AB7 for ; Thu, 29 Aug 2019 10:15:25 -0700 (PDT) Received: by mail-qt1-x830.google.com with SMTP id z4so4541289qtc.3 for ; Thu, 29 Aug 2019 10:15:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bbIIo9oD6nZnOXqvvrvDlFDoUq6ekvJMY1Haff26DnY=; b=FWVzo6CHh3j6HwiZkiwG2BrRqXQNtOxdO41k9lk/OrFSV6QE5DEfHw1RrnL1f60bgh CysfADqF+Dl6ivaZyHJ5Rkm84HyDaUnAWDu7sRbWwNgytuvKwUAzEExJOc4Djxoun03M UizJbD4EQUpydzWXgKrDzjsTSOb1fY0h1X7/wzyYkq0Z7CEniLV+Zwi8ACL+VmjgEjyx pQT0Hjsr6F5CVZ9YOZdRZ9XbwdFFBJPVicWL64AedjjSlEix6LqXhIvgG01I0aLUYGtj TByLTv+dMQetQ8fSK4t8EnElzJK7FQ/DxNsMgtw533AS7rG6BG4LERbiQXyphdsLQjFa L+wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bbIIo9oD6nZnOXqvvrvDlFDoUq6ekvJMY1Haff26DnY=; b=Frli+uDsuh+OGFk0HWc3861p0qXxtDvyRIL1f3YGvDfT6vIKzjiB8Psjz00DRha7Bt g2zb4Kbxt86ieiAXL3tw5kGbioVGUf+z1wGGkInnxf934cLRFM7Tih+YO3iHrYSu/l4D wwFn7beqsgxBzxnog7JdXLKJPUhwSnh1RnTAWtyGjEorzUM1tb8OSLXOIyXwQaCt4EYn PjM6tujNx999Q6icbOZJLFmna0yU5/HkXhckdM74a/3uj729PZ3aLNB5feUFOXdWgAqC I3unLNlmVW/bPnxLonjukHo63GXxYyhGi9cHVua/nlVZYM/T5opSWxhlblAwiBllaXA9 F6Ng== X-Gm-Message-State: APjAAAW26ME0/bUy5/uLAYqB9hCsVV+IfYkACgkGrMNlFbWR1N0vrhGL YS11eP6ho5KzRAnHRuVyfuHGFxTVJUA= X-Google-Smtp-Source: APXvYqwC1hbKjVlTufLVog/8XvERTVQQQ1INYmdNzwUbaj/LeO+7xPLfXWkci8YYcI0stsiNAykgmg== X-Received: by 2002:ac8:94a:: with SMTP id z10mr10008380qth.283.1567098924876; Thu, 29 Aug 2019 10:15:24 -0700 (PDT) Received: from brians-mbp-2388.lan ([24.154.122.195]) by smtp.gmail.com with ESMTPSA id w5sm1352620qki.13.2019.08.29.10.15.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Aug 2019 10:15:24 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Brian Rosen In-Reply-To: Date: Thu, 29 Aug 2019 13:15:24 -0400 Cc: rum@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <51761A85-4DEB-4BC2-9D75-38708894E2DE@brianrosen.net> References: To: Paul Kyzivat X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 17:15:34 -0000 +1 > On Aug 29, 2019, at 9:50 AM, Paul Kyzivat = wrote: >=20 > This is a call for the adoption of draft-rosen-rue-01 as a RUM wg = document. This is intended to evolve into the document our charter calls = for. >=20 > Comments, pro or con, on this proposal are due by Sunday September 15. >=20 > Thanks, > Paul Kyzivat, as RUM co-chair >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum From nobody Thu Aug 29 10:17:53 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 740A3120A48 for ; Thu, 29 Aug 2019 10:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVKXgqlNf2Lu for ; Thu, 29 Aug 2019 10:17:47 -0700 (PDT) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99D011209A8 for ; Thu, 29 Aug 2019 10:17:47 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id s14so3659558qkm.4 for ; Thu, 29 Aug 2019 10:17:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=czAza/XU37NxYjMrMmqijNcWei7pUt9s+Y9iYZbSiPE=; b=G/bxowDrY/Uo+Bh6LloxNiOqkhIJczgN8YtERLj4G2k3cQYny2s3YDB3L0m7fsVNdV WI/0gsPWa4AEXgD67a9X7dWYKQ3DzSDuh1gBWWM7ntF34Y1Z0lUZXDtzMUluvqXM5biB jl6bhFs6/hQICZWYSi+IcEAGmRyL6/S0IfveGhHc4/rDqX6bkKvKeKnLTfDCtjbv2+2N Ji/ckSjsW88CAka1VvFgXn/LausNM/ExSGbC67Cg4Xv3v0RzuVOh9Ydgd7O0qZjAMFFo aM+hBuEnpZ4eG17/OvNptI3NkssDXOba3vb4Qpe8SRB0c1sH24uA4tM/3LKZkWqgXkGm WYIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=czAza/XU37NxYjMrMmqijNcWei7pUt9s+Y9iYZbSiPE=; b=R8QsyWNSaFzGfWYAzL61beFEZ6TszLTKujI1B4LD7b1w8N1BAMPNAlnyAJVEir+RdC 7ZEs19HFoAYXVtwTCw78Qv5AdRgj3qHn1VDmAqIAzLVZN/WH1LHou3BELaHYG33cHQ9Q 2UXl7UoopJHnXDatp1T0bTixNatyrtalEu0FQKIaKKODfEpt2dlPbZrAuGuryWXVfzg+ JcdY/BUdZOXL+vgzOJZnWSPYe0BKTODiIayQ8AQgNpYOFkr3vE0olLZPZW2l2dxr3ZHJ y6oGWGBCvdYu/9HOImE9UlZ0gch7ud/6f4lRC8GG4+XPkNM0/2KJlHybm5rKRWm+1kec ORYQ== X-Gm-Message-State: APjAAAUnh5AyIkEEEA0yQLxBO9dwhlskxhagSV2W5YZGLxzREiDvQNIe 2L/OEXAonKCkW7lazCRCZrhFKA== X-Google-Smtp-Source: APXvYqy2Z86T3T59+hNbTbjcw7sWKV7RRbIh44LiODroaNaKHv2KVvxOxpKdZIvkFw4GcbT0Ksh3Hw== X-Received: by 2002:a37:a68e:: with SMTP id p136mr3596955qke.49.1567099066612; Thu, 29 Aug 2019 10:17:46 -0700 (PDT) Received: from brians-mbp-2388.lan ([24.154.122.195]) by smtp.gmail.com with ESMTPSA id b50sm689010qte.48.2019.08.29.10.17.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Aug 2019 10:17:46 -0700 (PDT) From: Brian Rosen Message-Id: <272ED564-10A7-40C9-90BC-587A81C6B68C@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_92FB00AD-783A-41D2-B1D5-7912FF57965C" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 29 Aug 2019 13:17:45 -0400 In-Reply-To: Cc: Paul Kyzivat , "rum@ietf.org" To: Jim Malloy References: <9a14addd-9a1c-6130-3880-a814be717323@omnitor.se> <59F6B4E5-16DF-42EB-A654-1749BC9487B5@brianrosen.net> <25517_1567094729_5D67F7C4_25517_54_4_48c0bc62-0f75-4f83-6d9c-f763982dd000@alum.mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Rum] [EXT] Re: Real-time text in WebRTC is discussed in mmusic - a topic closely telated to rum X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 17:17:52 -0000 --Apple-Mail=_92FB00AD-783A-41D2-B1D5-7912FF57965C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think we want a rum device to be able to be a good conference = participant, but like nearly all conference participants, they only see = a 2 party call and the bridge does the magic. I don=E2=80=99t think we need to require anything else. I think we want = a bridge to be able to host a rum-compliant endpoint. Brian > On Aug 29, 2019, at 12:20 PM, Malloy, Jim wrote: >=20 > Do we intend for the RUE to accommodate multiple party calls (more = than three)? I don't recall any language related to anything but a point = to point call. For emergency calls, conferencing in the PSAP (three = parties) may be appropriate. Are we looking for more than that? >=20 > --Jim Malloy >=20 > -----Original Message----- > From: Rum > On = Behalf Of Paul Kyzivat > Sent: Thursday, August 29, 2019 12:05 PM > To: rum@ietf.org > Subject: [EXT] Re: [Rum] Real-time text in WebRTC is discussed in = mmusic - a topic closely telated to rum >=20 > I question how well RTT text is suited to multiparty conferences. >=20 > If you have messages on your screen from multiple parties, and many of = them are updating in real-time, are you going to be able to perceive = what is going on? >=20 > And while you can have a column per person for two-party and maybe = 3-party conversations, that doesn't scale up. With many parties, some = typing may scroll off the screen before it is complete. >=20 > Perhaps for conferences it is better to just use line-at-a-time chat. = If necessary, I presume there could be gateways between RTT and chat. A = RUE could have the capability to negotiate down from RTT to chat. >=20 > Thanks, > Paul >=20 > On 8/28/19 2:15 AM, Gunnar Hellstr=C3=B6m wrote: >> Den 2019-08-27 kl. 23:15, skrev Brian Rosen: >>> At least by centralizing the problem at a =E2=80=9Cmixer=E2=80=9D, = Alice and Bob will=20 >>> see the same thing. >>>=20 >>> You don=E2=80=99t have the problem in Instant Messaging, because you = can=E2=80=99t=20 >>> backspace or delete a sent message. Of course if multiple people = are=20 >>> typing simultaneously in such systems, message order will be=20 >>> confusing in that instant. >> Right, it is a similar kind of problem that text appears in an=20 >> unexpected order. There is also at least one instant messaging = service=20 >> that allows modification in already sent message. But I think it has=20= >> limitations to only accept that in the last message sent. it is=20 >> convenient anyway. >>>=20 >>> Anyway, we need to specify the mixer for RTT so it receives each of=20= >>> the RTT streams and produces a single composite stream for each=20 >>> participant. >>=20 >> Yes, right, and there is an effort in that direction in: >>=20 >> = http://www.realtimetext.org/sites/default/files/Files_and_Documents/Sp >> ecifications/multiparty-real-time-text-mixer-2011-04-30.pdf >>=20 >> It is written for conference-unaware user devices. >>=20 >> The goals are specified as follows: >>=20 >> The procedures are intended to make best efforts to present a=20 >> multi-party text conversation on a terminal that has no awareness of=20= >> multi-party calls. There are some obvious drawbacks, and a terminal=20= >> designed with multi-party awareness will be able to present=20 >> multi-party call contents in a more flexible way. Only two parties at=20= >> a time will be allowed to display added text in real-time, while the = other parties=E2=80=99 >> produced text will need to be stored in the multi-party server for a=20= >> moment awaiting a suitable occasion to be displayed. There are also=20= >> some cases of erasure that will not be performed on the target text=20= >> but only indicated in another way. Even with these drawbacks, the=20 >> procedure provides an opportunity to display text from more than two=20= >> parties in a smooth and readable way. >>=20 >> = ---------------------------------------------------------------------- >> ----------------------------- >>=20 >> I see such mixer procedures as a fall-back for cases without=20 >> conference awareness, but want to see support for conference-aware=20 >> terminals, where text from more than two parties can be presented in=20= >> real-time, and the end user or app can have influence over the = presentation style - e.g. >> select between the multiple column view and the = one-column-with-labels=20 >> view. A mixer for that case would only need to assure that the=20 >> receiver has the right kind of multi-party awareness and send RTT = text=20 >> with source information attached, and let the receiving terminal sort=20= >> out the presentation. This is already possible with CSRC and CNAME=20 >> when using RTP, but we lose that possibility natively when using the=20= >> WebRTC data channel to transport RTT, and would need to specify a way=20= >> to include the source also for that case. >>=20 >> ------------------------------------------------------ >>=20 >> By the way, what is your current view of how to transport RTT for = RUM,=20 >> now when you say that you will use WebRTC transports for media? >>=20 >> Regards >>=20 >> Gunnar >>=20 >>>=20 >>>> On Aug 27, 2019, at 4:43 PM, Gunnar Hellstr=C3=B6m=20 >>>> = >> wrote: >>>>=20 >>>> Den 2019-08-27 kl. 21:48, skrev Brian Rosen: >>>>> The problem of conference 4103 RTT is high on my list of work I=20 >>>>> need to get done. So, I=E2=80=99m motivated to help out. >>>> Thanks, great. >>>>> The basic problem is that we=E2=80=99re going to get very = inconsistent UI=20 >>>>> doing it that way, because of how systems will handle backspace of=20= >>>>> one party that extends beyond responses from other parties: >>>> (well, for me the currently most basic problem is to have a = reliable=20 >>>> way to append received text to the already presented text of the=20 >>>> right participant. And that is getting worse in WebRTC than it was=20= >>>> in RFC 4103. But we will sort it out.) >>>>>=20 >>>>> Alice: I waited for you >>>>> Bob: I didn=E2=80=99t see you >>>>> Alice: sorry >>>>>=20 >>>>> And then Alice types 12 backspaces. >>>>>=20 >>>>> What should happen? >>>>=20 >>>> You are right that there are a number of ways to handle the RTT UI.=20= >>>> And just as inconsistencies are common with a message oriented UI,=20= >>>> where messages show up in a confusing order because two users=20 >>>> completed messages in an unexpected time order, it is possible that=20= >>>> RTT text gets displayed in a strange order after erasure and=20 >>>> retyping. It is better for RTT than for message oriented=20 >>>> presentation, and user get used to it in both cases. With the=20 >>>> labelled style in one column you have in the example, I would=20 >>>> recommend that first 5 backspaces erase "sorry", next backspace=20 >>>> erases the line separator, and pulls down "I waited for you" to be=20= >>>> shown last, as an uncompleted text. Then the next 6 backspaces = erase=20 >>>> so that only "I waited f" is displayed. When Alice adds text and = end=20 >>>> with a new line, the corrected sentence is allowed to flow up when=20= >>>> new text is added from any participant. That causes a bit strange=20= >>>> order, but it is just as manageable as when text in messaging=20 >>>> applications appear in an unexpected order so that one message = seems=20 >>>> to be a respone on something totally else than what was intended. >>>>=20 >>>> A sophisticated UI may mark text that is moved and modified. >>>>=20 >>>> We want to keep sentences or at least phrases from each participant=20= >>>> together in a readable unit. Already that causes a design decision=20= >>>> on where to place the completed chunk of text once the user has=20 >>>> completed it. The start of the chunk may be older than completed=20 >>>> text from other participants which would motivate to move it up a=20= >>>> bit in the presentation. But the end of it is at that moment the=20 >>>> latest text to present. I think it is best to let the finished text=20= >>>> be presented last on the display, but let others' newer text push=20= >>>> everything up and be displayed last. >>>>=20 >>>>=20 >>>> T.140 has information on how to handle erasure: >>>>=20 >>>> -------------------=46rom T.140--------------------------- >>>>=20 >>>> 8.2 Erase last character >>>> Purpose: Erase the last character sent from the display at the=20 >>>> receiving end. >>>> Code: BS: 0008. >>>> Procedure: On the receiving end: Move the insertion point to the=20 >>>> last character and erase it. >>>> Combined characters are erased as a unit, with one BS erasing the=20= >>>> whole character even if it is combined from more than one = component. >>>> Control sequences (like CR LF) are erased in one operation. >>>> NOTE =E2=80=93 The same action shall be taken on the local display. >>>>=20 >>>> ------------------------------------------------------------ >>>>=20 >>>> /Gunnar >>>>=20 >>>>>=20 >>>>> Brian >>>>>=20 >>>>>> On Aug 27, 2019, at 9:52 AM, Gunnar Hellstr=C3=B6m=20 >>>>>> = >> >>>>>> wrote: >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> A topic is currently discussed in mmusic that is closely related=20= >>>>>> to rum. it is WebRTC transport of real-time text. >>>>>>=20 >>>>>> The draft is draft-holmberg-mmusic-t140-usage-data-channel . >>>>>>=20 >>>>>> A good point to start reading could be: >>>>>>=20 >>>>>> = https://mailarchive.ietf.org/arch/browse/mmusic/?gbt=3D1&q=3Ddraft-hol = >>>>>> mberg-mmusic-t140-usage-data-channel >>>>>>=20 >>>>>> Please check if the current state of the discussion suits rum! >>>>>>=20 >>>>>> The only issue that seems to be remaining is how to transport RTT=20= >>>>>> data to and from a conference server that combines all traffic = per=20 >>>>>> media in a meeting in one data stream. That is not very elegantly=20= >>>>>> specified for RFC 4103 transport of RTT in RTP either, so we = might=20 >>>>>> want to do a rapid action together to solve the multi-party RTT=20= >>>>>> MCU case in a general and consistent way. >>>>>>=20 >>>>>> Regards >>>>>>=20 >>>>>> Gunnar >>>>>>=20 >>>>>> -- >>>>>> ----------------------------------------- >>>>>> Gunnar Hellstr=C3=B6m >>>>>> Omnitor >>>>>> gunnar.hellstrom@omnitor.se >>>>>> +46 708 204 288 >>>>>>=20 >>>>>>=20 >>>> -- >>>> ----------------------------------------- >>>> Gunnar Hellstr=C3=B6m >>>> Omnitor >>>> gunnar.hellstrom@omnitor.se = > >>>> +46 708 204 288 >>>=20 >>>=20 >> -- >> ----------------------------------------- >> Gunnar Hellstr=C3=B6m >> Omnitor >> gunnar.hellstrom@omnitor.se >> +46 708 204 288 >>=20 >>=20 >=20 > -- > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum = > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum = --Apple-Mail=_92FB00AD-783A-41D2-B1D5-7912FF57965C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = think we want a rum device to be able to be a good conference = participant, but like nearly all conference participants, they only see = a 2 party call and the bridge does the magic.
I don=E2=80=99= t think we need to require anything else.  I think we want a bridge = to be able to host a rum-compliant endpoint.

Brian

On Aug = 29, 2019, at 12:20 PM, Malloy, Jim <jmalloy@mitre.org> = wrote:

Do we intend for the RUE to = accommodate multiple party calls (more than three)? I don't recall any = language related to anything but a point to point call.  For = emergency calls, conferencing in the PSAP (three parties) may be = appropriate.  Are we looking for more than that?

--Jim Malloy

-----Original = Message-----
From: Rum = <rum-bounces@ietf.org> On Behalf Of Paul = Kyzivat
Sent: = Thursday, August 29, 2019 12:05 PM
To: rum@ietf.org
Subject: [EXT] Re: [Rum] = Real-time text in WebRTC is discussed in mmusic - a topic closely = telated to rum

I question how well RTT text is suited to multiparty = conferences.

If you have = messages on your screen from multiple parties, and many of them are = updating in real-time, are you going to be able to perceive what is = going on?

And while you = can have a column per person for two-party and maybe 3-party = conversations, that doesn't scale up. With many parties, some typing may = scroll off the screen before it is complete.

Perhaps for conferences it is = better to just use line-at-a-time chat. If necessary, I presume there = could be gateways between RTT and chat. A RUE could have the capability = to negotiate down from RTT to chat.

= Thanks,
= Paul

On 8/28/19 2:15 AM, Gunnar = Hellstr=C3=B6m wrote:
Den 2019-08-27 kl. 23:15, skrev Brian = Rosen:
At least by = centralizing the problem at a =E2=80=9Cmixer=E2=80=9D, Alice and Bob = will 
see = the same thing.

You don=E2=80=99t have the = problem in Instant Messaging, because you can=E2=80=99t 
backspace or = delete a sent message.  Of course if multiple people are 
typing = simultaneously in such systems, message order will be 
confusing in = that instant.
Right, it is a similar kind of = problem that text appears in an 
unexpected = order. There is also at least one instant messaging service 
that allows = modification in already sent message. But I think it has 
limitations = to only accept that in the last message sent. it is 
convenient = anyway.

Anyway, we need to specify the mixer for RTT so it receives = each of 
the RTT streams and produces a single composite stream for = each 
participant.

Yes, = right, and there is an effort in that direction in:

http://www.realtimetext.org/sites/default/files/Files_and_Docum= ents/Sp
ecifications/multiparty-real-time-text-mixer-2011-04-30.pdf

It is written for conference-unaware user = devices.

The goals are specified as = follows:

The procedures are intended to = make best efforts to present a 
multi-party = text conversation on a terminal that has no awareness of 
multi-party = calls. There are some obvious drawbacks, and a terminal 
designed = with multi-party awareness will be able to present 
multi-party = call contents in a more flexible way. Only two parties at 
a time will = be allowed to display added text in real-time, while the other = parties=E2=80=99
produced text will need to be stored in = the multi-party server for a 
moment = awaiting a suitable occasion to be displayed. There are also 
some cases = of erasure that will not be performed on the target text 
but only = indicated in another way. Even with these drawbacks, the 
procedure = provides an opportunity to display text from more than two 
parties in a = smooth and readable way.

---------------------------------------------------------------= -------
-----------------------------

I see such mixer procedures as a fall-back for cases = without 
conference awareness, but want to see support for = conference-aware 
terminals, where text from more than two parties can be = presented in 
real-time, and the end user or app can have influence over = the presentation style - e.g.
select between the multiple = column view and the one-column-with-labels 
view.  = A mixer for that case would only need to assure that the 
receiver has = the right kind of multi-party awareness and send RTT text 
with source = information attached, and let the receiving terminal sort 
out the = presentation. This is already possible with CSRC and CNAME 
when using = RTP, but we lose that possibility natively when using the 
WebRTC data = channel to transport RTT, and would need to specify a way 
to include = the source also for that case.

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

By the way, what is your current view of how = to transport RTT for RUM, 
now when you = say that you will use WebRTC transports for media?

Regards

Gunnar


On Aug 27, 2019, at 4:43 PM, Gunnar = Hellstr=C3=B6m 
<gunnar.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se>> wrote:

Den 2019-08-27 kl. 21:48, skrev Brian = Rosen:
The problem of = conference 4103 RTT is high on my list of work I 
need to get = done.  So, I=E2=80=99m motivated to help out.
Thanks, great.
The basic problem is that we=E2=80=99re going = to get very inconsistent UI 
doing it = that way, because of how systems will handle backspace of 
one party = that extends beyond responses from other parties:
(well, for me the currently most basic problem = is to have a reliable 
way to = append received text to the already presented text of the 
right = participant. And that is getting worse in WebRTC than it was 
in RFC 4103. = But we will sort it out.)

Alice: I waited for you
Bob: I = didn=E2=80=99t see you
Alice: sorry

And then Alice types 12 backspaces.

What should happen?

You are right that there are a number of ways to handle the = RTT UI. 
And just as inconsistencies are common with a message = oriented UI, 
where messages show up in a confusing order because two = users 
completed messages in an unexpected time order, it is = possible that 
RTT text gets displayed in a strange order after erasure = and 
retyping. It is better for RTT than for message oriented 
presentation, = and user get used to it in both cases.  With the 
labelled = style in one column you have in the example, I would 
recommend = that first 5 backspaces erase "sorry", next backspace 
erases the = line separator, and pulls down "I waited for you" to be 
shown last, = as an uncompleted text. Then the next 6 backspaces erase 
so that only = "I waited f" is displayed. When Alice adds text and end 
with a new = line, the corrected sentence is allowed to flow up when 
new text is = added from any participant.  That causes a bit strange 
order, but = it is just as manageable as when text in messaging 
applications = appear in an unexpected order so that one message seems 
to be a = respone on something totally else than what was intended.

A sophisticated UI may mark text that is moved = and modified.

We want to keep sentences or = at least phrases from each participant 
together in = a readable unit. Already that causes a design decision 
on where to = place the completed chunk of text once the user has 
completed = it. The start of the chunk may be older than completed 
text from = other participants which would motivate to move it up a 
bit in the = presentation. But the end of it is at that moment the 
latest text = to present. I think it is best to let the finished text 
be presented = last on the display, but let others' newer text push 
everything = up and be displayed last.


T.140 has information on how to handle erasure:

-------------------=46rom = T.140---------------------------

8.2 Erase = last character
Purpose: Erase the last character sent from = the display at the 
receiving end.
Code: BS: 0008.
Procedure: On the receiving end: Move the insertion point to = the 
last = character and erase it.
Combined characters are erased as = a unit, with one BS erasing the 
whole = character even if it is combined from more than one component.
Control sequences (like CR LF) are erased in one = operation.
NOTE =E2=80=93 The same action shall be taken = on the local display.

------------------------------------------------------------
  /Gunnar


Brian

On Aug = 27, 2019, at 9:52 AM, Gunnar Hellstr=C3=B6m 
<gunnar.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se>>
wrote:

Hi,

A topic is currently discussed in mmusic that is closely = related 
to rum. it is WebRTC transport of real-time text.

The draft is = draft-holmberg-mmusic-t140-usage-data-channel .

A good point to start reading could be:

https://mailarchive.ietf.org/arch/browse/mmusic/?gbt=3D1&q=3D= draft-hol
mberg-mmusic-t140-usage-data-channel

Please check if the current state of the = discussion suits rum!

The only issue that = seems to be remaining is how to transport RTT 
data to and = from a conference server that combines all traffic per 
media in a = meeting in one data stream. That is not very elegantly 
specified = for RFC 4103 transport of RTT in RTP either, so we might 
want to do a = rapid action together to solve the multi-party RTT 
MCU case in = a general and consistent way.

Regards

Gunnar

--
-----------------------------------------
Gunnar = Hellstr=C3=B6m
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 = 288


--
-----------------------------------------
Gunnar = Hellstr=C3=B6m
Omnitor
gunnar.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se>
+46 = 708 204 288


--
-----------------------------------------
Gunnar = Hellstr=C3=B6m
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 = 288



--
Rum mailing list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum
-- 
Rum mailing list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum

= --Apple-Mail=_92FB00AD-783A-41D2-B1D5-7912FF57965C-- From nobody Thu Aug 29 10:25:11 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D53E120A19 for ; Thu, 29 Aug 2019 10:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mitre.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6w6HVj79o-Iq for ; Thu, 29 Aug 2019 10:25:07 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A61221208B9 for ; Thu, 29 Aug 2019 10:25:07 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5662433206F; Thu, 29 Aug 2019 13:25:06 -0400 (EDT) Received: from smtprhbv1.mitre.org (unknown [129.83.19.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtpvbsrv1.mitre.org (Postfix) with ESMTPS id 4ABCE33206B; Thu, 29 Aug 2019 13:25:06 -0400 (EDT) Received: from mbfesmtp-mgt.mitre.org (unknown [198.49.146.235]) by smtprhbv1.mitre.org (Postfix) with ESMTP id 4541880EC99; Thu, 29 Aug 2019 13:25:06 -0400 (EDT) Received: by mbfesmtp-mgt.mitre.org (Postfix, from userid 600) id 46K8cy1xCnzkFQ; Thu, 29 Aug 2019 17:24:11 +0000 (UTC) Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02lp2108.outbound.protection.outlook.com [104.47.64.108]) by mbfesmtp-mgt.mitre.org (Postfix) with ESMTPS id 46K8bn2Wh8zkHv; Thu, 29 Aug 2019 17:24:05 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FY+L3sH+Wem0Qj2U9jNn7G6tk0kZ1oabgDxe0MNE1Zg4qcdW4LSrgn+WmkVbIhKLVafhIakcBkOmEdmNoktzRtgIdgly17YvIqyxRmGnyBV/jYg6BgPZBK/8aSNsN86N6UJK48nEpvUaPIkMUKsp7vBM1g++3bkRr1J6UfawBvfAfUFGjhxBZ9S/HF0Z2okj0x3MtQmPAyO3v0jH6r6rK/mID6iIneYzu2uMlH6cIGmIKR0qewbsbKLYbEjLFu6A3xMqGSQXEqCW0EQIdsM13pY3dmo96sL6otJ1/fiLK/XOqC2kP8I4xyFTBwzMEhIwGttaz7vowkTgRRHGgTxGlw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Xs6gkED/91LU3TjHGx4AACInLPAysA1VBZisHZXpw5I=; b=inA3UJjv14Qmrj+jpGCdRXb5y7MR/r6I0iqKkW76EWrkn/M7aNB8EcWK7z9uzaezLZaXqukPxPBQD1KiF13UHFqeR23yaNRazS2I1mV9nMGJwTm/tZ0Tw2WOS2tBat0EWiAYPeeAOMdoZLJIS2CffOIS6qtbLHDxc3j3WXpLHqZhymOzCsyuZTgU2buxp/L1dZUlVZMo+tUnkIRwvsZeWOIE39Kwl+KM7FazJM0aJoZLfG1zwKSir9EwXYjEwEW797bkFz15BSJOaIEYbqSTs02U0GxnWHh/VZiDiX14I68Dg5X/LO8icwGN3+R9Rfhl1OHpfQ8bHbIr8D+qm7VO5g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mitre.org; dmarc=pass action=none header.from=mitre.org; dkim=pass header.d=mitre.org; arc=none Received: from CY4PR09MB1367.namprd09.prod.outlook.com (10.172.67.13) by CY4PR09MB1253.namprd09.prod.outlook.com (10.172.68.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2220.18; Thu, 29 Aug 2019 17:24:04 +0000 Received: from CY4PR09MB1367.namprd09.prod.outlook.com ([fe80::8805:6147:53cf:8eab]) by CY4PR09MB1367.namprd09.prod.outlook.com ([fe80::8805:6147:53cf:8eab%3]) with mapi id 15.20.2199.021; Thu, 29 Aug 2019 17:24:04 +0000 From: "Janett, Amy E." To: Brian Rosen , "Kyzivat, Paul" CC: "rum@ietf.org" Thread-Topic: [EXT] Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 Thread-Index: AQHVXo1YGRbt75am5EGVfFnM8B3LuqcSXh5g Date: Thu, 29 Aug 2019 17:24:04 +0000 Message-ID: References: <18769_1567098950_5D680845_18769_367_49_51761A85-4DEB-4BC2-9D75-38708894E2DE@brianrosen.net> In-Reply-To: <18769_1567098950_5D680845_18769_367_49_51761A85-4DEB-4BC2-9D75-38708894E2DE@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ajanett@mitre.org; x-originating-ip: [192.80.55.89] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9916cadf-18c3-4254-b0a1-08d72ca5b0dc x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:CY4PR09MB1253; x-ms-traffictypediagnostic: CY4PR09MB1253: x-ms-exchange-purlcount: 1 x-ld-processed: c620dc48-1d50-4952-8b39-df4d54d74d82,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4303; x-forefront-prvs: 0144B30E41 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(136003)(376002)(396003)(39860400002)(366004)(199004)(13464003)(189003)(110136005)(316002)(2171002)(71200400001)(8676002)(6246003)(66476007)(81156014)(53936002)(81166006)(52536014)(6116002)(3846002)(561944003)(8936002)(33656002)(71190400001)(476003)(4326008)(66066001)(11346002)(446003)(256004)(86362001)(186003)(25786009)(229853002)(5660300002)(14454004)(7736002)(76176011)(66446008)(6506007)(53546011)(478600001)(7696005)(4744005)(486006)(966005)(26005)(99286004)(102836004)(9686003)(66556008)(2906002)(66946007)(74316002)(64756008)(6436002)(6306002)(76116006)(55016002)(305945005); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR09MB1253; H:CY4PR09MB1367.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: mitre.org does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: eE/0vmDtMPlZdaFO8x7dzQwpe2lJhNlOUXAh7fEsf+0sleaUZsNU5TdK7+8Dsh/t4bOAJV6TjKy4lMdXfipZ0JYzcnzKkZbTFleYnVzcb6t51XuVLpsSAsX+LUkD2Qn/WJHdyAWSTgh69vQgkgp5hVkaIPksdl/LGPntdhuab9qpkWOWkINizz/lbWSBK5KRseiar7D1lX2frSSG+baW+IZMtm7yeVweVLaDZ7Qs15g5RGsowe7jlY++TzrSdOCQ8F3u1uHIj0w4n46eZHogyrFFZtakajG4TLOIq6ajBhDEtc6gUk1AtSoi51UTI4Wrw0gUtvIm3piYKu4tn83lD/LJHDzpTD1dN5eNcCBUOJqG+O7szV2wVDVQjAhCwiDsSDlcZEKCqJEF5sRTLWB6JvksGSVmfTAvieJSCSwP6sM= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: mitre.org X-MS-Exchange-CrossTenant-Network-Message-Id: 9916cadf-18c3-4254-b0a1-08d72ca5b0dc X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2019 17:24:04.3474 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: WnfN5hOnpyf1JlTdG0llKvcY1mrISeI86mqPQZFTB8TvUS6Q6D6/KwrGlP8e7t9NBsrb1veA6HiAbARUCrYiGg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1253 X-MITRE: 8GQsMWxq66rxk57w DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mitre.org; h=from:to:cc:subject:date:message-id:references:in-reply-to:content-type:content-transfer-encoding:mime-version; s=selector1; bh=Xs6gkED/91LU3TjHGx4AACInLPAysA1VBZisHZXpw5I=; b=sCk3aB5gRZeLr2pLlWlh0Qcu2Bwcc1Qzo7X6mcaIijm0qxByjoHmOCXuxpyTCSDXi6sn71GDwVshRnqkeWw5f1nAGHzYPGIblX3lj1SlFciU3cU9MSM6LBeXkxcCuJTPFX7bWAV9BqaIAYpu4AmIuY7M9El7eZh6+/SIKunFwks= Archived-At: Subject: Re: [Rum] [EXT] Re: Call for WG adoption of: draft-rosen-rue-01 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 17:25:10 -0000 +1 -----Original Message----- From: Rum On Behalf Of Brian Rosen Sent: Thursday, August 29, 2019 13:15 To: Kyzivat, Paul Cc: rum@ietf.org Subject: [EXT] Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 +1 > On Aug 29, 2019, at 9:50 AM, Paul Kyzivat wrote: >=20 > This is a call for the adoption of draft-rosen-rue-01 as a RUM wg documen= t. This is intended to evolve into the document our charter calls for. >=20 > Comments, pro or con, on this proposal are due by Sunday September 15. >=20 > Thanks, > Paul Kyzivat, as RUM co-chair >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum --=20 Rum mailing list Rum@ietf.org https://www.ietf.org/mailman/listinfo/rum From nobody Thu Aug 29 11:07:07 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4C11208E5 for ; Thu, 29 Aug 2019 11:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65wtj4bOXZzv for ; Thu, 29 Aug 2019 11:07:02 -0700 (PDT) Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D6BA120A86 for ; Thu, 29 Aug 2019 11:07:02 -0700 (PDT) Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x7TI6xFT002445 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 29 Aug 2019 14:06:59 -0400 To: Brian Rosen , Jim Malloy Cc: "rum@ietf.org" References: <9a14addd-9a1c-6130-3880-a814be717323@omnitor.se> <59F6B4E5-16DF-42EB-A654-1749BC9487B5@brianrosen.net> <25517_1567094729_5D67F7C4_25517_54_4_48c0bc62-0f75-4f83-6d9c-f763982dd000@alum.mit.edu> <272ED564-10A7-40C9-90BC-587A81C6B68C@brianrosen.net> From: Paul Kyzivat Message-ID: Date: Thu, 29 Aug 2019 14:06:58 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <272ED564-10A7-40C9-90BC-587A81C6B68C@brianrosen.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rum] [EXT] Re: Real-time text in WebRTC is discussed in mmusic - a topic closely telated to rum X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 18:07:05 -0000 On 8/29/19 1:17 PM, Brian Rosen wrote: > I think we want a rum device to be able to be a good conference > participant, but like nearly all conference participants, they only see > a 2 party call and the bridge does the magic. > I don’t think we need to require anything else.  I think we want a > bridge to be able to host a rum-compliant endpoint. I agree conceptually. But we need to recognize that we are out ahead of VRS. Near term there is no way to get an audio/video/RTT bridge into a call with a VRS user. Because the bridge is not in the VRS iTRS it will only be able to get connected as an audio call with and interpreter. The first form of conference is likely to be for emergency calls. But there isn't yet a specification of how to connect VRS to ng911 to get an audio/video/RTT emergency call. The other possibility is via Direct Video Calling using the VATRP system from Mitre. I guess in theory that is possible now. But it will currently have VRS users that use VRS Provider proprietary devices. Anything to support conferencing that requires extra signaling won't work until VRS users can actually use RUM-compliant RUEs. But that could work with vanilla RTT as long as the DVC device sets up the conferencing. Thanks, Paul > Brian > >> On Aug 29, 2019, at 12:20 PM, Malloy, Jim > > wrote: >> >> Do we intend for the RUE to accommodate multiple party calls (more >> than three)? I don't recall any language related to anything but a >> point to point call.  For emergency calls, conferencing in the PSAP >> (three parties) may be appropriate.  Are we looking for more than that? >> >> --Jim Malloy >> >> -----Original Message----- >> From: Rum > On >> Behalf Of Paul Kyzivat >> Sent: Thursday, August 29, 2019 12:05 PM >> To:rum@ietf.org >> Subject: [EXT] Re: [Rum] Real-time text in WebRTC is discussed in >> mmusic - a topic closely telated to rum >> >> I question how well RTT text is suited to multiparty conferences. >> >> If you have messages on your screen from multiple parties, and many of >> them are updating in real-time, are you going to be able to perceive >> what is going on? >> >> And while you can have a column per person for two-party and maybe >> 3-party conversations, that doesn't scale up. With many parties, some >> typing may scroll off the screen before it is complete. >> >> Perhaps for conferences it is better to just use line-at-a-time chat. >> If necessary, I presume there could be gateways between RTT and chat. >> A RUE could have the capability to negotiate down from RTT to chat. >> >> Thanks, >> Paul >> >> On 8/28/19 2:15 AM, Gunnar Hellström wrote: >>> Den 2019-08-27 kl. 23:15, skrev Brian Rosen: >>>> At least by centralizing the problem at a “mixer”, Alice and Bob will >>>> see the same thing. >>>> >>>> You don’t have the problem in Instant Messaging, because you can’t >>>> backspace or delete a sent message.  Of course if multiple people are >>>> typing simultaneously in such systems, message order will be >>>> confusing in that instant. >>> Right, it is a similar kind of problem that text appears in an >>> unexpected order. There is also at least one instant messaging service >>> that allows modification in already sent message. But I think it has >>> limitations to only accept that in the last message sent. it is >>> convenient anyway. >>>> >>>> Anyway, we need to specify the mixer for RTT so it receives each of >>>> the RTT streams and produces a single composite stream for each >>>> participant. >>> >>> Yes, right, and there is an effort in that direction in: >>> >>> http://www.realtimetext.org/sites/default/files/Files_and_Documents/Sp >>> ecifications/multiparty-real-time-text-mixer-2011-04-30.pdf >>> >>> It is written for conference-unaware user devices. >>> >>> The goals are specified as follows: >>> >>> The procedures are intended to make best efforts to present a >>> multi-party text conversation on a terminal that has no awareness of >>> multi-party calls. There are some obvious drawbacks, and a terminal >>> designed with multi-party awareness will be able to present >>> multi-party call contents in a more flexible way. Only two parties at >>> a time will be allowed to display added text in real-time, while the >>> other parties’ >>> produced text will need to be stored in the multi-party server for a >>> moment awaiting a suitable occasion to be displayed. There are also >>> some cases of erasure that will not be performed on the target text >>> but only indicated in another way. Even with these drawbacks, the >>> procedure provides an opportunity to display text from more than two >>> parties in a smooth and readable way. >>> >>> ---------------------------------------------------------------------- >>> ----------------------------- >>> >>> I see such mixer procedures as a fall-back for cases without >>> conference awareness, but want to see support for conference-aware >>> terminals, where text from more than two parties can be presented in >>> real-time, and the end user or app can have influence over the >>> presentation style - e.g. >>> select between the multiple column view and the one-column-with-labels >>> view.  A mixer for that case would only need to assure that the >>> receiver has the right kind of multi-party awareness and send RTT text >>> with source information attached, and let the receiving terminal sort >>> out the presentation. This is already possible with CSRC and CNAME >>> when using RTP, but we lose that possibility natively when using the >>> WebRTC data channel to transport RTT, and would need to specify a way >>> to include the source also for that case. >>> >>> ------------------------------------------------------ >>> >>> By the way, what is your current view of how to transport RTT for RUM, >>> now when you say that you will use WebRTC transports for media? >>> >>> Regards >>> >>> Gunnar >>> >>>> >>>>> On Aug 27, 2019, at 4:43 PM, Gunnar Hellström >>>>> >>>> > >>>>> wrote: >>>>> >>>>> Den 2019-08-27 kl. 21:48, skrev Brian Rosen: >>>>>> The problem of conference 4103 RTT is high on my list of work I >>>>>> need to get done.  So, I’m motivated to help out. >>>>> Thanks, great. >>>>>> The basic problem is that we’re going to get very inconsistent UI >>>>>> doing it that way, because of how systems will handle backspace of >>>>>> one party that extends beyond responses from other parties: >>>>> (well, for me the currently most basic problem is to have a reliable >>>>> way to append received text to the already presented text of the >>>>> right participant. And that is getting worse in WebRTC than it was >>>>> in RFC 4103. But we will sort it out.) >>>>>> >>>>>> Alice: I waited for you >>>>>> Bob: I didn’t see you >>>>>> Alice: sorry >>>>>> >>>>>> And then Alice types 12 backspaces. >>>>>> >>>>>> What should happen? >>>>> >>>>> You are right that there are a number of ways to handle the RTT UI. >>>>> And just as inconsistencies are common with a message oriented UI, >>>>> where messages show up in a confusing order because two users >>>>> completed messages in an unexpected time order, it is possible that >>>>> RTT text gets displayed in a strange order after erasure and >>>>> retyping. It is better for RTT than for message oriented >>>>> presentation, and user get used to it in both cases.  With the >>>>> labelled style in one column you have in the example, I would >>>>> recommend that first 5 backspaces erase "sorry", next backspace >>>>> erases the line separator, and pulls down "I waited for you" to be >>>>> shown last, as an uncompleted text. Then the next 6 backspaces erase >>>>> so that only "I waited f" is displayed. When Alice adds text and end >>>>> with a new line, the corrected sentence is allowed to flow up when >>>>> new text is added from any participant.  That causes a bit strange >>>>> order, but it is just as manageable as when text in messaging >>>>> applications appear in an unexpected order so that one message seems >>>>> to be a respone on something totally else than what was intended. >>>>> >>>>> A sophisticated UI may mark text that is moved and modified. >>>>> >>>>> We want to keep sentences or at least phrases from each participant >>>>> together in a readable unit. Already that causes a design decision >>>>> on where to place the completed chunk of text once the user has >>>>> completed it. The start of the chunk may be older than completed >>>>> text from other participants which would motivate to move it up a >>>>> bit in the presentation. But the end of it is at that moment the >>>>> latest text to present. I think it is best to let the finished text >>>>> be presented last on the display, but let others' newer text push >>>>> everything up and be displayed last. >>>>> >>>>> >>>>> T.140 has information on how to handle erasure: >>>>> >>>>> -------------------From T.140--------------------------- >>>>> >>>>> 8.2 Erase last character >>>>> Purpose: Erase the last character sent from the display at the >>>>> receiving end. >>>>> Code: BS: 0008. >>>>> Procedure: On the receiving end: Move the insertion point to the >>>>> last character and erase it. >>>>> Combined characters are erased as a unit, with one BS erasing the >>>>> whole character even if it is combined from more than one component. >>>>> Control sequences (like CR LF) are erased in one operation. >>>>> NOTE – The same action shall be taken on the local display. >>>>> >>>>> ------------------------------------------------------------ >>>>> >>>>> /Gunnar >>>>> >>>>>> >>>>>> Brian >>>>>> >>>>>>> On Aug 27, 2019, at 9:52 AM, Gunnar Hellström >>>>>>> >>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> A topic is currently discussed in mmusic that is closely related >>>>>>> to rum. it is WebRTC transport of real-time text. >>>>>>> >>>>>>> The draft is draft-holmberg-mmusic-t140-usage-data-channel . >>>>>>> >>>>>>> A good point to start reading could be: >>>>>>> >>>>>>> https://mailarchive.ietf.org/arch/browse/mmusic/?gbt=1&q=draft-hol >>>>>>> mberg-mmusic-t140-usage-data-channel >>>>>>> >>>>>>> Please check if the current state of the discussion suits rum! >>>>>>> >>>>>>> The only issue that seems to be remaining is how to transport RTT >>>>>>> data to and from a conference server that combines all traffic per >>>>>>> media in a meeting in one data stream. That is not very elegantly >>>>>>> specified for RFC 4103 transport of RTT in RTP either, so we might >>>>>>> want to do a rapid action together to solve the multi-party RTT >>>>>>> MCU case in a general and consistent way. >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Gunnar >>>>>>> >>>>>>> -- >>>>>>> ----------------------------------------- >>>>>>> Gunnar Hellström >>>>>>> Omnitor >>>>>>> gunnar.hellstrom@omnitor.se >>>>>>> +46 708 204 288 >>>>>>> >>>>>>> >>>>> -- >>>>> ----------------------------------------- >>>>> Gunnar Hellström >>>>> Omnitor >>>>> gunnar.hellstrom@omnitor.se >>>>> >>>>> +46 708 204 288 >>>> >>>> >>> -- >>> ----------------------------------------- >>> Gunnar Hellström >>> Omnitor >>> gunnar.hellstrom@omnitor.se >>> +46 708 204 288 >>> >>> >> >> -- >> Rum mailing list >> Rum@ietf.org >> https://www.ietf.org/mailman/listinfo/rum >> -- >> Rum mailing list >> Rum@ietf.org >> https://www.ietf.org/mailman/listinfo/rum > From nobody Thu Aug 29 11:12:53 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 139CB120AE7 for ; Thu, 29 Aug 2019 11:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzvhaO-T0Wbw for ; Thu, 29 Aug 2019 11:12:48 -0700 (PDT) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 664BF120ADE for ; Thu, 29 Aug 2019 11:12:48 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id p13so3756309qkg.13 for ; Thu, 29 Aug 2019 11:12:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XdixAFdLv2FIw6ZcVaQpPK3icEy+RlrdA9LQYTLdH8k=; b=Pk/o/EPoADpxCuF6u0PuLMCR2j+gDkCsPCrdxF7garnf4DHYVHt90+k9OsbWV+EdYi C/2NdwE6072CNhleSPtvtJD+0KkqnavKddiFpR18kcJkM9PayqlFGOqr8qY7xqGpAGX4 TMoSZwDlqBHyT7bNvMr6TrK/gL5h8yBb3KaMVYwCbzom+IbzIjAt8ZGps04aPYdRUyOQ N3O65/OrFlMYlSIC0PDOQzmuv9uON/HcgcEI/P1KVEj26i2ID1DTdPknGdFZ3Jd/ymuO 2uxlta+ulSi6d0Xn4AqSpa6lo8LZC5q8qB3LiRRdMiXKygLNnn8KSrSH/8Wb5R2rxphv Njvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XdixAFdLv2FIw6ZcVaQpPK3icEy+RlrdA9LQYTLdH8k=; b=BMBzp074e4LUxlKW3c+g0onve+5DWmrUyyk5NLbxG0GS6d8jSFmFEyMNw+/DAVH7eM DeFmk57ZUvx5zUC3H539w33qSGR8/gwjyaLIqYim0yi16cyJxnwDFalW4BKI05kw37GA unQ90nX8EKUTgINR9AoueKVqd/mNkwbJbTKL76LPxWQT0IWKZbyVB5bNMrAfe9l6FuDA e1avqen0El/0sXNMH0mq+efAMyk6KozvHmYQVXCftSvddRtoZ/MkNNNqOdl1IXaazBI/ TVymS+rkWWtBfj87lX2Ck0lxXlg0JMfPKb+hKjiqKBbNaAujk5Rn/H0+inTO5H4Ufy3Z UZEw== X-Gm-Message-State: APjAAAXvqEyuy8fFnKmkaW3y+Bpo1L77F15sfmlJv5iJuFButYJXOebg oEQnIH1ItbTLs6WuBt9hCM1ilw== X-Google-Smtp-Source: APXvYqyburp8bROLR2/BwCTfYkkzZDFUhS686tlLUVGbxifjgUzwQLRQssq3ZJfMvWFffu3qjeJS2w== X-Received: by 2002:a05:620a:1503:: with SMTP id i3mr11227044qkk.168.1567102367419; Thu, 29 Aug 2019 11:12:47 -0700 (PDT) Received: from brians-mbp-2388.lan ([24.154.122.195]) by smtp.gmail.com with ESMTPSA id e2sm1478294qkg.38.2019.08.29.11.12.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Aug 2019 11:12:47 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Brian Rosen In-Reply-To: Date: Thu, 29 Aug 2019 14:12:45 -0400 Cc: Jim Malloy , "rum@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <9a14addd-9a1c-6130-3880-a814be717323@omnitor.se> <59F6B4E5-16DF-42EB-A654-1749BC9487B5@brianrosen.net> <25517_1567094729_5D67F7C4_25517_54_4_48c0bc62-0f75-4f83-6d9c-f763982dd000@alum.mit.edu> <272ED564-10A7-40C9-90BC-587A81C6B68C@brianrosen.net> To: Paul Kyzivat X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Rum] [EXT] Re: Real-time text in WebRTC is discussed in mmusic - a topic closely telated to rum X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 18:12:51 -0000 Inline > On Aug 29, 2019, at 2:06 PM, Paul Kyzivat = wrote: >=20 > On 8/29/19 1:17 PM, Brian Rosen wrote: >> I think we want a rum device to be able to be a good conference = participant, but like nearly all conference participants, they only see = a 2 party call and the bridge does the magic. >> I don=E2=80=99t think we need to require anything else. I think we = want a bridge to be able to host a rum-compliant endpoint. >=20 > I agree conceptually. But we need to recognize that we are out ahead = of VRS. Near term there is no way to get an audio/video/RTT bridge into = a call with a VRS user. Because the bridge is not in the VRS iTRS it = will only be able to get connected as an audio call with and interpreter Both the user and the VRS CA become members of the conference, and they = arrange for the user to see the CA in the =E2=80=9Cbig window=E2=80=9D. = We did this in the IVC work although the FCC provided the interpreters = instead of a VRS service. The bridge they used had a few issues but = mostly it worked. >=20 > The first form of conference is likely to be for emergency calls. But = there isn't yet a specification of how to connect VRS to ng911 to get an = audio/video/RTT emergency call. That is incorrect. It=E2=80=99s completely specified in NENA-STA-010 >=20 > The other possibility is via Direct Video Calling using the VATRP = system from Mitre. I guess in theory that is possible now. But it will = currently have VRS users that use VRS Provider proprietary devices. = Anything to support conferencing that requires extra signaling won't = work until VRS users can actually use RUM-compliant RUEs. But that could = work with vanilla RTT as long as the DVC device sets up the = conferencing. I still don=E2=80=99t think that surfaces any additional requirements = for the rum-compatible device. >=20 > Thanks, > Paul >=20 >> Brian >>> On Aug 29, 2019, at 12:20 PM, Malloy, Jim > wrote: >>>=20 >>> Do we intend for the RUE to accommodate multiple party calls (more = than three)? I don't recall any language related to anything but a point = to point call. For emergency calls, conferencing in the PSAP (three = parties) may be appropriate. Are we looking for more than that? >>>=20 >>> --Jim Malloy >>>=20 >>> -----Original Message----- >>> From: Rum > On = Behalf Of Paul Kyzivat >>> Sent: Thursday, August 29, 2019 12:05 PM >>> To:rum@ietf.org >>> Subject: [EXT] Re: [Rum] Real-time text in WebRTC is discussed in = mmusic - a topic closely telated to rum >>>=20 >>> I question how well RTT text is suited to multiparty conferences. >>>=20 >>> If you have messages on your screen from multiple parties, and many = of them are updating in real-time, are you going to be able to perceive = what is going on? >>>=20 >>> And while you can have a column per person for two-party and maybe = 3-party conversations, that doesn't scale up. With many parties, some = typing may scroll off the screen before it is complete. >>>=20 >>> Perhaps for conferences it is better to just use line-at-a-time = chat. If necessary, I presume there could be gateways between RTT and = chat. A RUE could have the capability to negotiate down from RTT to = chat. >>>=20 >>> Thanks, >>> Paul >>>=20 >>> On 8/28/19 2:15 AM, Gunnar Hellstr=C3=B6m wrote: >>>> Den 2019-08-27 kl. 23:15, skrev Brian Rosen: >>>>> At least by centralizing the problem at a =E2=80=9Cmixer=E2=80=9D, = Alice and Bob will >>>>> see the same thing. >>>>>=20 >>>>> You don=E2=80=99t have the problem in Instant Messaging, because = you can=E2=80=99t >>>>> backspace or delete a sent message. Of course if multiple people = are >>>>> typing simultaneously in such systems, message order will be >>>>> confusing in that instant. >>>> Right, it is a similar kind of problem that text appears in an >>>> unexpected order. There is also at least one instant messaging = service >>>> that allows modification in already sent message. But I think it = has >>>> limitations to only accept that in the last message sent. it is >>>> convenient anyway. >>>>>=20 >>>>> Anyway, we need to specify the mixer for RTT so it receives each = of >>>>> the RTT streams and produces a single composite stream for each >>>>> participant. >>>>=20 >>>> Yes, right, and there is an effort in that direction in: >>>>=20 >>>> = http://www.realtimetext.org/sites/default/files/Files_and_Documents/Sp >>>> ecifications/multiparty-real-time-text-mixer-2011-04-30.pdf >>>>=20 >>>> It is written for conference-unaware user devices. >>>>=20 >>>> The goals are specified as follows: >>>>=20 >>>> The procedures are intended to make best efforts to present a >>>> multi-party text conversation on a terminal that has no awareness = of >>>> multi-party calls. There are some obvious drawbacks, and a terminal >>>> designed with multi-party awareness will be able to present >>>> multi-party call contents in a more flexible way. Only two parties = at >>>> a time will be allowed to display added text in real-time, while = the other parties=E2=80=99 >>>> produced text will need to be stored in the multi-party server for = a >>>> moment awaiting a suitable occasion to be displayed. There are also >>>> some cases of erasure that will not be performed on the target text >>>> but only indicated in another way. Even with these drawbacks, the >>>> procedure provides an opportunity to display text from more than = two >>>> parties in a smooth and readable way. >>>>=20 >>>> = ---------------------------------------------------------------------- >>>> ----------------------------- >>>>=20 >>>> I see such mixer procedures as a fall-back for cases without >>>> conference awareness, but want to see support for conference-aware >>>> terminals, where text from more than two parties can be presented = in >>>> real-time, and the end user or app can have influence over the = presentation style - e.g. >>>> select between the multiple column view and the = one-column-with-labels >>>> view. A mixer for that case would only need to assure that the >>>> receiver has the right kind of multi-party awareness and send RTT = text >>>> with source information attached, and let the receiving terminal = sort >>>> out the presentation. This is already possible with CSRC and CNAME >>>> when using RTP, but we lose that possibility natively when using = the >>>> WebRTC data channel to transport RTT, and would need to specify a = way >>>> to include the source also for that case. >>>>=20 >>>> ------------------------------------------------------ >>>>=20 >>>> By the way, what is your current view of how to transport RTT for = RUM, >>>> now when you say that you will use WebRTC transports for media? >>>>=20 >>>> Regards >>>>=20 >>>> Gunnar >>>>=20 >>>>>=20 >>>>>> On Aug 27, 2019, at 4:43 PM, Gunnar Hellstr=C3=B6m >>>>>> > = wrote: >>>>>>=20 >>>>>> Den 2019-08-27 kl. 21:48, skrev Brian Rosen: >>>>>>> The problem of conference 4103 RTT is high on my list of work I >>>>>>> need to get done. So, I=E2=80=99m motivated to help out. >>>>>> Thanks, great. >>>>>>> The basic problem is that we=E2=80=99re going to get very = inconsistent UI >>>>>>> doing it that way, because of how systems will handle backspace = of >>>>>>> one party that extends beyond responses from other parties: >>>>>> (well, for me the currently most basic problem is to have a = reliable >>>>>> way to append received text to the already presented text of the >>>>>> right participant. And that is getting worse in WebRTC than it = was >>>>>> in RFC 4103. But we will sort it out.) >>>>>>>=20 >>>>>>> Alice: I waited for you >>>>>>> Bob: I didn=E2=80=99t see you >>>>>>> Alice: sorry >>>>>>>=20 >>>>>>> And then Alice types 12 backspaces. >>>>>>>=20 >>>>>>> What should happen? >>>>>>=20 >>>>>> You are right that there are a number of ways to handle the RTT = UI. >>>>>> And just as inconsistencies are common with a message oriented = UI, >>>>>> where messages show up in a confusing order because two users >>>>>> completed messages in an unexpected time order, it is possible = that >>>>>> RTT text gets displayed in a strange order after erasure and >>>>>> retyping. It is better for RTT than for message oriented >>>>>> presentation, and user get used to it in both cases. With the >>>>>> labelled style in one column you have in the example, I would >>>>>> recommend that first 5 backspaces erase "sorry", next backspace >>>>>> erases the line separator, and pulls down "I waited for you" to = be >>>>>> shown last, as an uncompleted text. Then the next 6 backspaces = erase >>>>>> so that only "I waited f" is displayed. When Alice adds text and = end >>>>>> with a new line, the corrected sentence is allowed to flow up = when >>>>>> new text is added from any participant. That causes a bit = strange >>>>>> order, but it is just as manageable as when text in messaging >>>>>> applications appear in an unexpected order so that one message = seems >>>>>> to be a respone on something totally else than what was intended. >>>>>>=20 >>>>>> A sophisticated UI may mark text that is moved and modified. >>>>>>=20 >>>>>> We want to keep sentences or at least phrases from each = participant >>>>>> together in a readable unit. Already that causes a design = decision >>>>>> on where to place the completed chunk of text once the user has >>>>>> completed it. The start of the chunk may be older than completed >>>>>> text from other participants which would motivate to move it up a >>>>>> bit in the presentation. But the end of it is at that moment the >>>>>> latest text to present. I think it is best to let the finished = text >>>>>> be presented last on the display, but let others' newer text push >>>>>> everything up and be displayed last. >>>>>>=20 >>>>>>=20 >>>>>> T.140 has information on how to handle erasure: >>>>>>=20 >>>>>> -------------------=46rom T.140--------------------------- >>>>>>=20 >>>>>> 8.2 Erase last character >>>>>> Purpose: Erase the last character sent from the display at the >>>>>> receiving end. >>>>>> Code: BS: 0008. >>>>>> Procedure: On the receiving end: Move the insertion point to the >>>>>> last character and erase it. >>>>>> Combined characters are erased as a unit, with one BS erasing the >>>>>> whole character even if it is combined from more than one = component. >>>>>> Control sequences (like CR LF) are erased in one operation. >>>>>> NOTE =E2=80=93 The same action shall be taken on the local = display. >>>>>>=20 >>>>>> ------------------------------------------------------------ >>>>>>=20 >>>>>> /Gunnar >>>>>>=20 >>>>>>>=20 >>>>>>> Brian >>>>>>>=20 >>>>>>>> On Aug 27, 2019, at 9:52 AM, Gunnar Hellstr=C3=B6m >>>>>>>> > >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>> A topic is currently discussed in mmusic that is closely = related >>>>>>>> to rum. it is WebRTC transport of real-time text. >>>>>>>>=20 >>>>>>>> The draft is draft-holmberg-mmusic-t140-usage-data-channel . >>>>>>>>=20 >>>>>>>> A good point to start reading could be: >>>>>>>>=20 >>>>>>>> = https://mailarchive.ietf.org/arch/browse/mmusic/?gbt=3D1&q=3Ddraft-hol >>>>>>>> mberg-mmusic-t140-usage-data-channel >>>>>>>>=20 >>>>>>>> Please check if the current state of the discussion suits rum! >>>>>>>>=20 >>>>>>>> The only issue that seems to be remaining is how to transport = RTT >>>>>>>> data to and from a conference server that combines all traffic = per >>>>>>>> media in a meeting in one data stream. That is not very = elegantly >>>>>>>> specified for RFC 4103 transport of RTT in RTP either, so we = might >>>>>>>> want to do a rapid action together to solve the multi-party RTT >>>>>>>> MCU case in a general and consistent way. >>>>>>>>=20 >>>>>>>> Regards >>>>>>>>=20 >>>>>>>> Gunnar >>>>>>>>=20 >>>>>>>> -- >>>>>>>> ----------------------------------------- >>>>>>>> Gunnar Hellstr=C3=B6m >>>>>>>> Omnitor >>>>>>>> gunnar.hellstrom@omnitor.se = >>>>>>>> +46 708 204 288 >>>>>>>>=20 >>>>>>>>=20 >>>>>> -- >>>>>> ----------------------------------------- >>>>>> Gunnar Hellstr=C3=B6m >>>>>> Omnitor >>>>>> gunnar.hellstrom@omnitor.se = >>>>>> +46 708 204 288 >>>>>=20 >>>>>=20 >>>> -- >>>> ----------------------------------------- >>>> Gunnar Hellstr=C3=B6m >>>> Omnitor >>>> gunnar.hellstrom@omnitor.se >>>> +46 708 204 288 >>>>=20 >>>>=20 >>>=20 >>> -- >>> Rum mailing list >>> Rum@ietf.org >>> https://www.ietf.org/mailman/listinfo/rum >>> -- >>> Rum mailing list >>> Rum@ietf.org >>> https://www.ietf.org/mailman/listinfo/rum >=20 From nobody Thu Aug 29 12:02:12 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 035C1120BB4 for ; Thu, 29 Aug 2019 12:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGiMjFTjrV1g for ; Thu, 29 Aug 2019 12:02:09 -0700 (PDT) Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3C91120BC0 for ; Thu, 29 Aug 2019 12:02:08 -0700 (PDT) Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x7TJ25O8005924 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 29 Aug 2019 15:02:06 -0400 To: Brian Rosen Cc: Jim Malloy , "rum@ietf.org" References: <9a14addd-9a1c-6130-3880-a814be717323@omnitor.se> <59F6B4E5-16DF-42EB-A654-1749BC9487B5@brianrosen.net> <25517_1567094729_5D67F7C4_25517_54_4_48c0bc62-0f75-4f83-6d9c-f763982dd000@alum.mit.edu> <272ED564-10A7-40C9-90BC-587A81C6B68C@brianrosen.net> From: Paul Kyzivat Message-ID: Date: Thu, 29 Aug 2019 15:02:05 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rum] [EXT] Re: Real-time text in WebRTC is discussed in mmusic - a topic closely telated to rum X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 19:02:11 -0000 On 8/29/19 2:12 PM, Brian Rosen wrote: > Inline > >> On Aug 29, 2019, at 2:06 PM, Paul Kyzivat wrote: >> >> On 8/29/19 1:17 PM, Brian Rosen wrote: >>> I think we want a rum device to be able to be a good conference participant, but like nearly all conference participants, they only see a 2 party call and the bridge does the magic. >>> I don’t think we need to require anything else. I think we want a bridge to be able to host a rum-compliant endpoint. >> >> I agree conceptually. But we need to recognize that we are out ahead of VRS. Near term there is no way to get an audio/video/RTT bridge into a call with a VRS user. Because the bridge is not in the VRS iTRS it will only be able to get connected as an audio call with and interpreter > Both the user and the VRS CA become members of the conference, and they arrange for the user to see the CA in the “big window”. We did this in the IVC work although the FCC provided the interpreters instead of a VRS service. The bridge they used had a few issues but mostly it worked. Is this deployed and in use with actual providers on real VRS calls? >> The first form of conference is likely to be for emergency calls. But there isn't yet a specification of how to connect VRS to ng911 to get an audio/video/RTT emergency call. > That is incorrect. It’s completely specified in NENA-STA-010 I haven't heard anything about this when working with providers on the VRS provider profile. But it doesn't show up on an interface between providers, so I guess there hasn't been any need for it to come up. But because this is limited to a private interface between the providers and NENA it isn't applicable to any other cases. >> The other possibility is via Direct Video Calling using the VATRP system from Mitre. I guess in theory that is possible now. But it will currently have VRS users that use VRS Provider proprietary devices. Anything to support conferencing that requires extra signaling won't work until VRS users can actually use RUM-compliant RUEs. But that could work with vanilla RTT as long as the DVC device sets up the conferencing. > I still don’t think that surfaces any additional requirements for the rum-compatible device. As long as no extra signaling is required. For instance, multiple RTT data channels signaled in SDP. Thanks, Paul From nobody Thu Aug 29 12:11:09 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3CEA1208F7 for ; Thu, 29 Aug 2019 12:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPwXIUlgkIEh for ; Thu, 29 Aug 2019 12:11:04 -0700 (PDT) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B372F120BCC for ; Thu, 29 Aug 2019 12:11:04 -0700 (PDT) Received: by mail-qk1-x729.google.com with SMTP id m2so3933359qki.12 for ; Thu, 29 Aug 2019 12:11:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KXN6+DakqsiCtNZu3sYB6IzOD1tnXmCn6VQNVzJE1/8=; b=RAOL+U6YTNKBQEMoIwwg2fgOAeRdOTSmJ5KqNVHgPhYjcz0b4QvtqZ7leXof/g4pF9 DxLAf5J/E+l1PN/wyLp3kp0flOX7G6a1Gzp4j2jzkM+fPDWxcIhGzHJCLjJHRgBIKIc2 7tjo0hx1uZK1515DUM9NEyCJc0Ll+YBPQ2eruu7ELONaRmKrL7A5+JsHfC3Wcp73W9L2 qYdA2EIrZUOTybf150b6iTl9F4ghagSkO5QluIupfLGWA4159eXtR/OzgJj0s2OkhFW2 NA4qZViNSZdOmLf1UduE1SM1hokjpKMZIqp9bpBl62ylheBhOXZcYwHussPMPrmIbd3y ogSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KXN6+DakqsiCtNZu3sYB6IzOD1tnXmCn6VQNVzJE1/8=; b=Y6mbrFyX6P23wPKpNuGKJqqbOrvRMIE5oWC7JsWyVlEB/h42OP3UEPB6I0bAFfdKuQ tFh7jFd8YtZlWIfFmWR5W6O2b6i8MmogJnngndwWExRUzIyHo2x0NMAKNqWEY7TBVan8 pZhGJ4QBVzPakrnJD9BLLLKcpQEmqjwcUi5sq9aCfgJwZ9//vPAXvUqTcaC4uZKf9qup w/PQujS+HlkWzIUAm1UL0MCaF2MdQpBf7GrgTBupszwlsTxRCRdwoLaSk+bAVOAtlHxJ sHYForVgXG+but1yW8F0SyGGDRM+EwmHVfz/4np7+0BY1LrIzeQCSEzK5J6smWkTybph hmzA== X-Gm-Message-State: APjAAAXGtwnVIDRUlaM8AdtQVORftLu9RLZa19iLnTDLw+l2xhSpXgLo uKcwPgejkexbQiplZ/3nblQ2XQ== X-Google-Smtp-Source: APXvYqwhPPeMjCmIOZAw5JhD/j7HsCGUMf6WV7e6tebw6GKyjqgOTlFLN6Ph64HGHBVVv4QndLZcog== X-Received: by 2002:a37:8607:: with SMTP id i7mr11401739qkd.455.1567105862447; Thu, 29 Aug 2019 12:11:02 -0700 (PDT) Received: from brians-mbp-2388.lan ([24.154.122.195]) by smtp.gmail.com with ESMTPSA id c26sm2029304qtk.93.2019.08.29.12.11.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Aug 2019 12:11:02 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Brian Rosen In-Reply-To: Date: Thu, 29 Aug 2019 15:11:00 -0400 Cc: Jim Malloy , "rum@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <9a14addd-9a1c-6130-3880-a814be717323@omnitor.se> <59F6B4E5-16DF-42EB-A654-1749BC9487B5@brianrosen.net> <25517_1567094729_5D67F7C4_25517_54_4_48c0bc62-0f75-4f83-6d9c-f763982dd000@alum.mit.edu> <272ED564-10A7-40C9-90BC-587A81C6B68C@brianrosen.net> To: Paul Kyzivat X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Rum] [EXT] Re: Real-time text in WebRTC is discussed in mmusic - a topic closely telated to rum X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 19:11:07 -0000 > On Aug 29, 2019, at 3:02 PM, Paul Kyzivat = wrote: >=20 > On 8/29/19 2:12 PM, Brian Rosen wrote: >> Inline >>> On Aug 29, 2019, at 2:06 PM, Paul Kyzivat = wrote: >>>=20 >>> On 8/29/19 1:17 PM, Brian Rosen wrote: >>>> I think we want a rum device to be able to be a good conference = participant, but like nearly all conference participants, they only see = a 2 party call and the bridge does the magic. >>>> I don=E2=80=99t think we need to require anything else. I think we = want a bridge to be able to host a rum-compliant endpoint. >>>=20 >>> I agree conceptually. But we need to recognize that we are out ahead = of VRS. Near term there is no way to get an audio/video/RTT bridge into = a call with a VRS user. Because the bridge is not in the VRS iTRS it = will only be able to get connected as an audio call with and interpreter >> Both the user and the VRS CA become members of the conference, and = they arrange for the user to see the CA in the =E2=80=9Cbig window=E2=80=9D= . We did this in the IVC work although the FCC provided the = interpreters instead of a VRS service. The bridge they used had a few = issues but mostly it worked. >=20 > Is this deployed and in use with actual providers on real VRS calls? Not that I know of. It would require regulatory action dealing with = compensation because the VRS CA isn=E2=80=99t in a 2 way call with the = deaf/HoH person. I=E2=80=99ve been in conferences where this was = finessed by the deaf user. He had two video devices. He was in a VRS = call with a CA who was audio dialed into the conference. The same deaf = participant was a video (and screen share) participant in the same = conference. I still don=E2=80=99t see any rum requirement. >=20 >>> The first form of conference is likely to be for emergency calls. = But there isn't yet a specification of how to connect VRS to ng911 to = get an audio/video/RTT emergency call. >> That is incorrect. It=E2=80=99s completely specified in NENA-STA-010 >=20 > I haven't heard anything about this when working with providers on the = VRS provider profile. But it doesn't show up on an interface between = providers, so I guess there hasn't been any need for it to come up. That is correct >=20 > But because this is limited to a private interface between the = providers and NENA it isn't applicable to any other cases. It directly affects the rum device. The rue spec says the right thing = (support RFC6881 and support REFER). >=20 >>> The other possibility is via Direct Video Calling using the VATRP = system from Mitre. I guess in theory that is possible now. But it will = currently have VRS users that use VRS Provider proprietary devices. = Anything to support conferencing that requires extra signaling won't = work until VRS users can actually use RUM-compliant RUEs. But that could = work with vanilla RTT as long as the DVC device sets up the = conferencing. >> I still don=E2=80=99t think that surfaces any additional requirements = for the rum-compatible device. >=20 > As long as no extra signaling is required. For instance, multiple RTT = data channels signaled in SDP. I don=E2=80=99t think so. I think we=E2=80=99re headed towards a single = RTT channel per participant using RFC4103. A conference would need an = RTT mixer. Every participant has a single two way RTT channel to the = bridge. =20 Brian >=20 > Thanks, > Paul From nobody Thu Aug 29 12:46:13 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 580AF1200E9 for ; Thu, 29 Aug 2019 12:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uzm6EmmIxRIq for ; Thu, 29 Aug 2019 12:46:10 -0700 (PDT) Received: from biz221.inmotionhosting.com (biz221.inmotionhosting.com [144.208.71.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ED55120A08 for ; Thu, 29 Aug 2019 12:46:10 -0700 (PDT) Received: from [104.129.194.133] (port=41397 helo=[172.20.26.12]) by biz221.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1i3QMl-000BHK-97 for rum@ietf.org; Thu, 29 Aug 2019 12:46:06 -0700 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_EC7E0805-5615-4B89-8ECE-18BC40F37879"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 29 Aug 2019 15:45:52 -0400 References: <18769_1567098950_5D680845_18769_367_49_51761A85-4DEB-4BC2-9D75-38708894E2DE@brianrosen.net> To: "rum@ietf.org" In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.104.11) X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz221.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz221.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Authenticated-Sender: biz221.inmotionhosting.com: eburger@standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Rum] [EXT] Re: Call for WG adoption of: draft-rosen-rue-01 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 19:46:13 -0000 --Apple-Mail=_EC7E0805-5615-4B89-8ECE-18BC40F37879 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 1++ (old school) > On Aug 29, 2019, at 1:24 PM, Janett, Amy E. wrote: >=20 > +1 >=20 > -----Original Message----- > From: Rum On Behalf Of Brian Rosen > Sent: Thursday, August 29, 2019 13:15 > To: Kyzivat, Paul > Cc: rum@ietf.org > Subject: [EXT] Re: [Rum] Call for WG adoption of: draft-rosen-rue-01 >=20 > +1 >=20 >> On Aug 29, 2019, at 9:50 AM, Paul Kyzivat = wrote: >>=20 >> This is a call for the adoption of draft-rosen-rue-01 as a RUM wg = document. This is intended to evolve into the document our charter calls = for. >>=20 >> Comments, pro or con, on this proposal are due by Sunday September = 15. >>=20 >> Thanks, >> Paul Kyzivat, as RUM co-chair >>=20 >> --=20 >> Rum mailing list >> Rum@ietf.org >> https://www.ietf.org/mailman/listinfo/rum >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum --Apple-Mail=_EC7E0805-5615-4B89-8ECE-18BC40F37879 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCy0w ggU/MIIEJ6ADAgECAhBHt+RkNqp99J88XTZXC5dSMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD VQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMTAwMDAwMDBaFw0yMDAxMTAyMzU5 NTlaMCsxKTAnBgkqhkiG9w0BCQEWGmVidXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0zzhr7ryFNByhrdpzJ8h13eulCFr7saD11JNhXxSKseG d300uPfY1n6hyBoVilzjj9rj338u1psRxYLdj5c8Dj0ySnaYRLw7opC2E0Ao7nOpZpjdrNz6CmPk 1+OnbQ3Y/bMEz8usYmv1iGD5FdOsiitMyUeuVogeGzs4JMdV24ta4gQlD+I1gpFNg35QFmkqFIvw e70nTE3dXE++nd5j7FTjixf78m33l586I9ggAHtmamzLezUIXRrA6qvPYXLFXRMm8O15T5EYERm2 6cefLJfTvb93/zhzGeCk3UesCcRc8PpuX5tp9Zj0rpElAVZa07WcPkC4cRbpTYN3GWePjwIDAQAB o4IB8DCCAewwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFMMaVWYH HTtL2BSEzeD9k5vNXY4nMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcG CCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7Bgwr BgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw WgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50 QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsG AQUFBzAChklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNh dGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9j YS5jb20wJQYDVR0RBB4wHIEaZWJ1cmdlckBzdGFuZGFyZHN0cmFjay5jb20wDQYJKoZIhvcNAQEL BQADggEBAAGGOzAxXHMmb+VL+VBPKyYLhDb+pDMxrz0VkZDKc871MJSVoevaM+ULGW1G1hlORFkU 1KgNt1xbSWIfICDLHBAJRpAUaMgT8/p0I1PJZdeP17/roFYI4mXUa7+mwB1CZuNlOY5dO+5nhS4p f7qosSTzvd+WP1YagPdIoHjjYgxz2nHVURz7sIsgR88XaYH3nsqZM4cqWx5yl0xf6c15F3b9c3DH KG5XlR5Q0m45ERzE7gFxtrLTv/icMpY1qelNsPAYl7wo9ML949MjGpKD0iA22vM0Pjq69YNokd4P jBbGlrYTXK7pQdjVQAhsk0mLSTYwagXJnFWPdUSQZmcRgvwwggXmMIIDzqADAgECAhBqm+E4O/8r a58B1dm4p1JWMA0GCSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDErMCkGA1UEAxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xMzAxMTAw MDAwMDBaFw0yODAxMDkyMzU5NTlaMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9 MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ 8yV5C0y1oNF9Olg+nKcxLqf2NHbZhGra0D00SOTq9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKM pjL+qUByRjXCA6RQyDMqVaVUkbIr5SU0RDX/kSsKwer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLB rZBlgvnkCos+KQWWCo63OTTqRvaq8aWccm+KOMjTcE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtV V4/Vwdax720YpMPJQaDaElmOupyTf1Qib+cpukNJnQmwygjD8m046DQkLnpXNCAGjuJy1F5NATks UsbfJAr7FLUCAwEAAaOCATwwggE4MB8GA1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0G A1UdDgQWBBSCr2yM+MX+lmF86B89K3FIXsSLwDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgw BgEB/wIBADARBgNVHSAECjAIMAYGBFUdIAAwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5j b21vZG9jYS5jb20vQ09NT0RPUlNBQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUH AQEEZTBjMDsGCCsGAQUFBzAChi9odHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRU cnVzdENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3 DQEBDAUAA4ICAQB4XLKBKDRPPO5fVs6fl1bsj6JrF/bz9kkIBtTYLzXN30D+03Hj6OxCDBEaIeNm sBhrJmuubvyE7HtoSmR809AgcYboW+rcTNZ/8u/Hv+GTrNI/AhqX2/kiQNxmgUPt/eJPs92Qclj0 HnVyy9TnSvGkSDU7I5Px+TbO+88G4zipA2psZaWeEykgzClZlPz1FjTCkk77ZXp5cQYYexE6zeeN 4/0OqqoAloFrjAF4o50YJafX8mnahjp3I2Y2mkjhk0xQfhNqbzlLWPoT3m7j7U26u7zg6swjOq8h ITYc3/np5tM5aVyu6t99p17bTbY7+1RTWBviN9YJzK8HxzObXYWBf/L+VGOYNsQDTxAk0Hbvb1j6 KjUhg7fO294F29QIhhmiNOr84JHoy+fNLpfvYc/Q9EtFOI5ISYgOxLk3nD/whbUe9rmEQXLp8MB9 33Ij474gwwCPUpwv9mj2PMnXoc7mbrS22XUSeTwxCTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/Yn IHOwsGsaTUgj7fIvxqith7DoJC91WJ8Lce3CVJqb1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1 c5noaDKH9Oq9cbm/vOYRUM1cWcef20Wkyk5S/GFyyPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3 RGTqH0pWR8p6EjGCA8cwggPDAgEBMIGsMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBF bWFpbCBDQQIQR7fkZDaqffSfPF02VwuXUjANBglghkgBZQMEAgEFAKCCAeswGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwODI5MTk0NTUyWjAvBgkqhkiG9w0BCQQx IgQgdk9/WHn0MA5S+oH71ugzayY5lGch/MwDjKgRtbPUzKQwgb0GCSsGAQQBgjcQBDGBrzCBrDCB lzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEEe35GQ2qn30nzxdNlcLl1Iw gb8GCyqGSIb3DQEJEAILMYGvoIGsMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9 MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIQR7fkZDaqffSfPF02VwuXUjANBgkqhkiG9w0BAQEFAASCAQCCllw12jBbUZOsTH2IK5cw jJTifClHtgmMh3u8JodRrg/qRcITz/OuftLe8+FguoE3oQIdz4diqoydeBaS8mWQXnFvTlQQD8Pl whut/6d9M9TX1TSC58SLW2S5GQ+GBb8oRjjB1EI/6XeRkUcCnT5MR8ofgd7LzTe/CPyUVZeTgzdd 7+gZMktvS0P7u0Lw0wwFIWoJkB0QJIDly9NFBBdRmXRlBQbghpfXjRlP/fAOuVBufQj4wtjDuCNx bI9TCOp5cTatA22xuCkO2ghaEXmg73ggSN8V+QfXSa1Mwqtw7c0eHuQ/0l0wDrx2/R6csltwfQjM 7z8p5LMqkMCVNVavAAAAAAAA --Apple-Mail=_EC7E0805-5615-4B89-8ECE-18BC40F37879-- From nobody Thu Aug 29 13:00:21 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B03DA120C7F for ; Thu, 29 Aug 2019 13:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mitre.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hiAt7xrbI_pP for ; Thu, 29 Aug 2019 13:00:09 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB182120C61 for ; Thu, 29 Aug 2019 13:00:08 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2D625332069; Thu, 29 Aug 2019 16:00:08 -0400 (EDT) Received: from smtprhbv1.mitre.org (unknown [129.83.19.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtpvbsrv1.mitre.org (Postfix) with ESMTPS id 13B6333206B; Thu, 29 Aug 2019 16:00:08 -0400 (EDT) Received: from mbfesmtp-mgt.mitre.org (unknown [198.49.146.235]) by smtprhbv1.mitre.org (Postfix) with ESMTP id 0D14B9269C2; Thu, 29 Aug 2019 16:00:08 -0400 (EDT) Received: by mbfesmtp-mgt.mitre.org (Postfix, from userid 600) id 46KD3r0GgYzk1b; Thu, 29 Aug 2019 19:59:37 +0000 (UTC) Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02lp2106.outbound.protection.outlook.com [104.47.64.106]) by mbfesmtp-mgt.mitre.org (Postfix) with ESMTPS id 46KD3871lDzk17; Thu, 29 Aug 2019 19:59:32 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bYgwsqjqcggirxrIqV+y6Fh0lcxb8wPt8VyYEgZn3GmMMxYmaziUyZOPZmInMRuQLvBnSB91V7SNKVGfzN8HX6SHdQN6VTAid0SI7YwQBE6OqeadufOatF7LL3L+9BF2N1mtr7Wvu3OnNPl8hQ+CagVq0AUP3UXSq4bsyITxnmUeIQg4Uad+lK0H9295BPTNptt/LQmc4R4+sHKF/SmsU0OF6BFqNEY+JcFlX5SKC3P1tiP/Is0v6NhL0INBkFCmV6HyonN7r1XhjQH2zNN+msHI2iWEd5URofzw0dSH9q+F4CyhZwxtSDM9foIWVTzp0e55YeyxVl0gv/eAIac73Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9f812FUHPFn8bCEBxx/jQTiD6mtEZ/wJ/aLEAJLFBa8=; b=jUNirhf1AIUwdGvvAHCZHkA9Y0KjsxXrIJRMOP4qfBd68CEGOvOFfS1rjFJUh8O6uEO43qtbCocjVseuWVOkDWHvCzLl0CLq9WSF3x80eeDbETtOldXKnClyeWbXfYkR3QjLSqHOTIZiemwmM40G0Yj0PKBeHX7bgpYsLqETwUvMWK11YaZUh0TRwboUCf2eck1RQVvS7uolZqJrKbIyBtlJ80PRujSg3NaViEddNiQ9EFCsAkBy98c/uWLzPoPcGVSl+/JLn/KFi11j1xGr6jvt/5N5/N3UF2dyNg0f9PyWmwyWqiNexTnwr9B/UCz5fThzrZHXjklRLoNDQBNl1Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mitre.org; dmarc=pass action=none header.from=mitre.org; dkim=pass header.d=mitre.org; arc=none Received: from BL0PR0901MB2386.namprd09.prod.outlook.com (52.132.25.22) by BL0PR0901MB3058.namprd09.prod.outlook.com (20.177.243.80) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.21; Thu, 29 Aug 2019 19:59:31 +0000 Received: from BL0PR0901MB2386.namprd09.prod.outlook.com ([fe80::cc1d:b5b5:bea2:9d5]) by BL0PR0901MB2386.namprd09.prod.outlook.com ([fe80::cc1d:b5b5:bea2:9d5%7]) with mapi id 15.20.2199.021; Thu, 29 Aug 2019 19:59:31 +0000 From: "Malloy, Jim" To: Brian Rosen , "Kyzivat, Paul" CC: "rum@ietf.org" Thread-Topic: [EXT] Re: [Rum] Real-time text in WebRTC is discussed in mmusic - a topic closely telated to rum Thread-Index: AQHVXo1FlwW+HFW4sUKgOzE77Y/c0KcSivaA Date: Thu, 29 Aug 2019 19:59:31 +0000 Message-ID: References: <9a14addd-9a1c-6130-3880-a814be717323@omnitor.se> <59F6B4E5-16DF-42EB-A654-1749BC9487B5@brianrosen.net> <48c0bc62-0f75-4f83-6d9c-f763982dd000@alum.mit.edu> <1388_1567098914_5D680821_1388_680_16_CE25682F-6A84-4033-BAFD-5D40ED6A0B09@brianrosen.net> In-Reply-To: <1388_1567098914_5D680821_1388_680_16_CE25682F-6A84-4033-BAFD-5D40ED6A0B09@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jmalloy@mitre.org; x-originating-ip: [192.160.51.88] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ecff167a-b0fc-4113-b38c-08d72cbb6816 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:BL0PR0901MB3058; x-ms-traffictypediagnostic: BL0PR0901MB3058: x-ms-exchange-purlcount: 5 x-ld-processed: c620dc48-1d50-4952-8b39-df4d54d74d82,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0144B30E41 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(39860400002)(396003)(136003)(366004)(346002)(376002)(52314003)(199004)(189003)(66946007)(186003)(76116006)(33656002)(2906002)(52536014)(25786009)(71190400001)(71200400001)(64756008)(66556008)(66476007)(14454004)(66446008)(86362001)(66574012)(606006)(8936002)(81156014)(81166006)(229853002)(236005)(53936002)(6436002)(8676002)(54896002)(6306002)(4326008)(6246003)(74316002)(2171002)(476003)(486006)(7736002)(966005)(14444005)(256004)(446003)(5024004)(478600001)(5660300002)(11346002)(102836004)(66066001)(99286004)(316002)(53546011)(76176011)(3846002)(26005)(110136005)(9686003)(7696005)(6116002)(790700001)(6506007)(55016002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:BL0PR0901MB3058; H:BL0PR0901MB2386.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: mitre.org does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: WO36uYKncOpl5mv5A3m81DZrS+9sS7o0hCYToSWpOi22CJAMr9ukwwZmeN6cOFusHv/SDUwVPVL8pdiDBAKMT43bFM6UXB3BZfhVVUhbeOufq5lj/qGNNAu0hA8JLic1O4nizbuZhEYNQCoQtZ0OlYFvGV7InMhQSTseiQYb72kXhsaIbF7rLXyEc21tkXy8wfHIg+Rc3YV3Tp08HfkueEk+g/xdLdXxt/UU4iiO9s0RJSbnpg8kYmDIHFXz3dGHdV7wGAqE4uR9aeqfWDqaHXzuCaFi1ODQ7xC9r0sHqQUINQA0CtBBPJZ0KUI9aOY/E68W0rhmvEe0lfMEYQdGEoNB5PtHkwRTYD1JRfjqgc9t7XlhAch5/1wc5qPidHfIkkOb5QjEWOs8i/+5P/ncvUTh4t/gxvd1XnKtmzOritM= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BL0PR0901MB23862F432B1A40B42C8C41E5B9A20BL0PR0901MB2386_" MIME-Version: 1.0 X-OriginatorOrg: mitre.org X-MS-Exchange-CrossTenant-Network-Message-Id: ecff167a-b0fc-4113-b38c-08d72cbb6816 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2019 19:59:31.2199 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: uml+ee1UIYrxCp6bkcvvqzLppMQnD3jVjY15syZvz9r9Pzj+TDa2OqXPdN1H982FCxULrmuPfqermb5aqy6XeA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR0901MB3058 X-MITRE: 8GQsMWxq66rxk57w DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mitre.org; h=from:to:cc:subject:date:message-id:references:in-reply-to:content-type:mime-version; s=selector1; bh=9f812FUHPFn8bCEBxx/jQTiD6mtEZ/wJ/aLEAJLFBa8=; b=YZT+SDlNPjkpPBl/8aIw75hk6ST5TY1XTdLuau6iGrKATpwdZBHU+sP6iEqXPuAuvr7z3gIyeWQ2PKRurr4tZ7JYI672jG8ggN7mIz688wohEYSdlbm3hPlNJc86ZNSjQzFspL31nbfKKQpAUWTuZa03VF22zwSzsUWYN1V6+Og= Archived-At: Subject: Re: [Rum] [EXT] Re: Real-time text in WebRTC is discussed in mmusic - a topic closely telated to rum X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 20:00:20 -0000 --_000_BL0PR0901MB23862F432B1A40B42C8C41E5B9A20BL0PR0901MB2386_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 4oCcbGluZSBhdCBhIHRpbWXigJ0gaXMgYSB1c2VyIGludGVyZmFjZSBpc3N1ZSDigJMgUlVNIGlz IGRlZmluaW5nIGEgbWFjaGluZSBpbnRlcmZhY2UuICBIb3cgaXTigJlzIHByZXNlbnRlZCB0byB0 aGUgdXNlciBpcyBvdXQgb2Ygc2NvcGUuDQoNCi0tSmltDQoNCg0KRnJvbTogUnVtIDxydW0tYm91 bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEJyaWFuIFJvc2VuDQpTZW50OiBUaHVyc2RheSwg QXVndXN0IDI5LCAyMDE5IDE6MTUgUE0NClRvOiBLeXppdmF0LCBQYXVsIDxwa3l6aXZhdEBhbHVt Lm1pdC5lZHU+DQpDYzogcnVtQGlldGYub3JnDQpTdWJqZWN0OiBbRVhUXSBSZTogW1J1bV0gUmVh bC10aW1lIHRleHQgaW4gV2ViUlRDIGlzIGRpc2N1c3NlZCBpbiBtbXVzaWMgLSBhIHRvcGljIGNs b3NlbHkgdGVsYXRlZCB0byBydW0NCg0K4oCcTGluZSBhdCBhIHRpbWXigJ0gY291bGQgYmUgYW4g aW1wbGVtZW50YXRpb24gb3B0aW9uLiAgVGhlIHByb3RvY29sIG1lY2hhbmlzbSBpcyBhbGwgc3Ry ZWFtcyBoZWFkIHRvIGEgbWl4ZXIgYW5kIHRoZSBtaXhlciBzZW5kcyBhIHNpbmdsZSBzdHJlYW0g dG8gZWFjaCBwYXJ0aWNpcGFudC4NCg0KR3VubmFyLCB3ZSBhZ3JlZWQgd2Ugd2VyZSB1c2luZyA0 MTAzIGluIFJVTS4NCg0KQnJpYW4NCg0KDQpPbiBBdWcgMjksIDIwMTksIGF0IDEyOjA1IFBNLCBQ YXVsIEt5eml2YXQgPHBreXppdmF0QGFsdW0ubWl0LmVkdTxtYWlsdG86cGt5eml2YXRAYWx1bS5t aXQuZWR1Pj4gd3JvdGU6DQoNCkkgcXVlc3Rpb24gaG93IHdlbGwgUlRUIHRleHQgaXMgc3VpdGVk IHRvIG11bHRpcGFydHkgY29uZmVyZW5jZXMuDQoNCklmIHlvdSBoYXZlIG1lc3NhZ2VzIG9uIHlv dXIgc2NyZWVuIGZyb20gbXVsdGlwbGUgcGFydGllcywgYW5kIG1hbnkgb2YgdGhlbSBhcmUgdXBk YXRpbmcgaW4gcmVhbC10aW1lLCBhcmUgeW91IGdvaW5nIHRvIGJlIGFibGUgdG8gcGVyY2VpdmUg d2hhdCBpcyBnb2luZyBvbj8NCg0KQW5kIHdoaWxlIHlvdSBjYW4gaGF2ZSBhIGNvbHVtbiBwZXIg cGVyc29uIGZvciB0d28tcGFydHkgYW5kIG1heWJlIDMtcGFydHkgY29udmVyc2F0aW9ucywgdGhh dCBkb2Vzbid0IHNjYWxlIHVwLiBXaXRoIG1hbnkgcGFydGllcywgc29tZSB0eXBpbmcgbWF5IHNj cm9sbCBvZmYgdGhlIHNjcmVlbiBiZWZvcmUgaXQgaXMgY29tcGxldGUuDQoNClBlcmhhcHMgZm9y IGNvbmZlcmVuY2VzIGl0IGlzIGJldHRlciB0byBqdXN0IHVzZSBsaW5lLWF0LWEtdGltZSBjaGF0 LiBJZiBuZWNlc3NhcnksIEkgcHJlc3VtZSB0aGVyZSBjb3VsZCBiZSBnYXRld2F5cyBiZXR3ZWVu IFJUVCBhbmQgY2hhdC4gQSBSVUUgY291bGQgaGF2ZSB0aGUgY2FwYWJpbGl0eSB0byBuZWdvdGlh dGUgZG93biBmcm9tIFJUVCB0byBjaGF0Lg0KDQogICAgICAgICAgICAgICBUaGFua3MsDQogICAg ICAgICAgICAgICBQYXVsDQoNCk9uIDgvMjgvMTkgMjoxNSBBTSwgR3VubmFyIEhlbGxzdHLDtm0g d3JvdGU6DQoNCkRlbiAyMDE5LTA4LTI3IGtsLiAyMzoxNSwgc2tyZXYgQnJpYW4gUm9zZW46DQoN CkF0IGxlYXN0IGJ5IGNlbnRyYWxpemluZyB0aGUgcHJvYmxlbSBhdCBhIOKAnG1peGVy4oCdLCBB bGljZSBhbmQgQm9iIHdpbGwgc2VlIHRoZSBzYW1lIHRoaW5nLg0KDQpZb3UgZG9u4oCZdCBoYXZl IHRoZSBwcm9ibGVtIGluIEluc3RhbnQgTWVzc2FnaW5nLCBiZWNhdXNlIHlvdSBjYW7igJl0IGJh Y2tzcGFjZSBvciBkZWxldGUgYSBzZW50IG1lc3NhZ2UuICBPZiBjb3Vyc2UgaWYgbXVsdGlwbGUg cGVvcGxlIGFyZSB0eXBpbmcgc2ltdWx0YW5lb3VzbHkgaW4gc3VjaCBzeXN0ZW1zLCBtZXNzYWdl IG9yZGVyIHdpbGwgYmUgY29uZnVzaW5nIGluIHRoYXQgaW5zdGFudC4NClJpZ2h0LCBpdCBpcyBh IHNpbWlsYXIga2luZCBvZiBwcm9ibGVtIHRoYXQgdGV4dCBhcHBlYXJzIGluIGFuIHVuZXhwZWN0 ZWQgb3JkZXIuIFRoZXJlIGlzIGFsc28gYXQgbGVhc3Qgb25lIGluc3RhbnQgbWVzc2FnaW5nIHNl cnZpY2UgdGhhdCBhbGxvd3MgbW9kaWZpY2F0aW9uIGluIGFscmVhZHkgc2VudCBtZXNzYWdlLiBC dXQgSSB0aGluayBpdCBoYXMgbGltaXRhdGlvbnMgdG8gb25seSBhY2NlcHQgdGhhdCBpbiB0aGUg bGFzdCBtZXNzYWdlIHNlbnQuIGl0IGlzIGNvbnZlbmllbnQgYW55d2F5Lg0KDQoNCkFueXdheSwg d2UgbmVlZCB0byBzcGVjaWZ5IHRoZSBtaXhlciBmb3IgUlRUIHNvIGl0IHJlY2VpdmVzIGVhY2gg b2YgdGhlIFJUVCBzdHJlYW1zIGFuZCBwcm9kdWNlcyBhIHNpbmdsZSBjb21wb3NpdGUgc3RyZWFt IGZvciBlYWNoIHBhcnRpY2lwYW50Lg0KWWVzLCByaWdodCwgYW5kIHRoZXJlIGlzIGFuIGVmZm9y dCBpbiB0aGF0IGRpcmVjdGlvbiBpbjoNCmh0dHA6Ly93d3cucmVhbHRpbWV0ZXh0Lm9yZy9zaXRl cy9kZWZhdWx0L2ZpbGVzL0ZpbGVzX2FuZF9Eb2N1bWVudHMvU3BlY2lmaWNhdGlvbnMvbXVsdGlw YXJ0eS1yZWFsLXRpbWUtdGV4dC1taXhlci0yMDExLTA0LTMwLnBkZg0KSXQgaXMgd3JpdHRlbiBm b3IgY29uZmVyZW5jZS11bmF3YXJlIHVzZXIgZGV2aWNlcy4NClRoZSBnb2FscyBhcmUgc3BlY2lm aWVkIGFzIGZvbGxvd3M6DQpUaGUgcHJvY2VkdXJlcyBhcmUgaW50ZW5kZWQgdG8gbWFrZSBiZXN0 IGVmZm9ydHMgdG8gcHJlc2VudCBhIG11bHRpLXBhcnR5IHRleHQgY29udmVyc2F0aW9uIG9uIGEg dGVybWluYWwgdGhhdCBoYXMgbm8gYXdhcmVuZXNzIG9mIG11bHRpLXBhcnR5IGNhbGxzLiBUaGVy ZSBhcmUgc29tZSBvYnZpb3VzIGRyYXdiYWNrcywgYW5kIGEgdGVybWluYWwgZGVzaWduZWQgd2l0 aCBtdWx0aS1wYXJ0eSBhd2FyZW5lc3Mgd2lsbCBiZSBhYmxlIHRvIHByZXNlbnQgbXVsdGktcGFy dHkgY2FsbCBjb250ZW50cyBpbiBhIG1vcmUgZmxleGlibGUgd2F5LiBPbmx5IHR3byBwYXJ0aWVz IGF0IGEgdGltZSB3aWxsIGJlIGFsbG93ZWQgdG8gZGlzcGxheSBhZGRlZCB0ZXh0IGluIHJlYWwt dGltZSwgd2hpbGUgdGhlIG90aGVyIHBhcnRpZXPigJkgcHJvZHVjZWQgdGV4dCB3aWxsIG5lZWQg dG8gYmUgc3RvcmVkIGluIHRoZSBtdWx0aS1wYXJ0eSBzZXJ2ZXIgZm9yIGEgbW9tZW50IGF3YWl0 aW5nIGEgc3VpdGFibGUgb2NjYXNpb24gdG8gYmUgZGlzcGxheWVkLiBUaGVyZSBhcmUgYWxzbyBz b21lIGNhc2VzIG9mIGVyYXN1cmUgdGhhdCB3aWxsIG5vdCBiZSBwZXJmb3JtZWQgb24gdGhlIHRh cmdldCB0ZXh0IGJ1dCBvbmx5IGluZGljYXRlZCBpbiBhbm90aGVyIHdheS4gRXZlbiB3aXRoIHRo ZXNlIGRyYXdiYWNrcywgdGhlIHByb2NlZHVyZSBwcm92aWRlcyBhbiBvcHBvcnR1bml0eSB0byBk aXNwbGF5IHRleHQgZnJvbSBtb3JlIHRoYW4gdHdvIHBhcnRpZXMgaW4gYSBzbW9vdGggYW5kIHJl YWRhYmxlIHdheS4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K SSBzZWUgc3VjaCBtaXhlciBwcm9jZWR1cmVzIGFzIGEgZmFsbC1iYWNrIGZvciBjYXNlcyB3aXRo b3V0IGNvbmZlcmVuY2UgYXdhcmVuZXNzLCBidXQgd2FudCB0byBzZWUgc3VwcG9ydCBmb3IgY29u ZmVyZW5jZS1hd2FyZSB0ZXJtaW5hbHMsIHdoZXJlIHRleHQgZnJvbSBtb3JlIHRoYW4gdHdvIHBh cnRpZXMgY2FuIGJlIHByZXNlbnRlZCBpbiByZWFsLXRpbWUsIGFuZCB0aGUgZW5kIHVzZXIgb3Ig YXBwIGNhbiBoYXZlIGluZmx1ZW5jZSBvdmVyIHRoZSBwcmVzZW50YXRpb24gc3R5bGUgLSBlLmcu IHNlbGVjdCBiZXR3ZWVuIHRoZSBtdWx0aXBsZSBjb2x1bW4gdmlldyBhbmQgdGhlIG9uZS1jb2x1 bW4td2l0aC1sYWJlbHMgdmlldy4gIEEgbWl4ZXIgZm9yIHRoYXQgY2FzZSB3b3VsZCBvbmx5IG5l ZWQgdG8gYXNzdXJlIHRoYXQgdGhlIHJlY2VpdmVyIGhhcyB0aGUgcmlnaHQga2luZCBvZiBtdWx0 aS1wYXJ0eSBhd2FyZW5lc3MgYW5kIHNlbmQgUlRUIHRleHQgd2l0aCBzb3VyY2UgaW5mb3JtYXRp b24gYXR0YWNoZWQsIGFuZCBsZXQgdGhlIHJlY2VpdmluZyB0ZXJtaW5hbCBzb3J0IG91dCB0aGUg cHJlc2VudGF0aW9uLiBUaGlzIGlzIGFscmVhZHkgcG9zc2libGUgd2l0aCBDU1JDIGFuZCBDTkFN RSB3aGVuIHVzaW5nIFJUUCwgYnV0IHdlIGxvc2UgdGhhdCBwb3NzaWJpbGl0eSBuYXRpdmVseSB3 aGVuIHVzaW5nIHRoZSBXZWJSVEMgZGF0YSBjaGFubmVsIHRvIHRyYW5zcG9ydCBSVFQsIGFuZCB3 b3VsZCBuZWVkIHRvIHNwZWNpZnkgYSB3YXkgdG8gaW5jbHVkZSB0aGUgc291cmNlIGFsc28gZm9y IHRoYXQgY2FzZS4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KQnkgdGhlIHdheSwgd2hhdCBpcyB5b3VyIGN1cnJlbnQgdmlldyBvZiBob3cg dG8gdHJhbnNwb3J0IFJUVCBmb3IgUlVNLCBub3cgd2hlbiB5b3Ugc2F5IHRoYXQgeW91IHdpbGwg dXNlIFdlYlJUQyB0cmFuc3BvcnRzIGZvciBtZWRpYT8NClJlZ2FyZHMNCkd1bm5hcg0KDQoNCg0K T24gQXVnIDI3LCAyMDE5LCBhdCA0OjQzIFBNLCBHdW5uYXIgSGVsbHN0csO2bSA8Z3VubmFyLmhl bGxzdHJvbUBvbW5pdG9yLnNlPG1haWx0bzpndW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iuc2U+IDxt YWlsdG86Z3VubmFyLmhlbGxzdHJvbUBvbW5pdG9yLnNlPj4gd3JvdGU6DQoNCkRlbiAyMDE5LTA4 LTI3IGtsLiAyMTo0OCwgc2tyZXYgQnJpYW4gUm9zZW46DQoNClRoZSBwcm9ibGVtIG9mIGNvbmZl cmVuY2UgNDEwMyBSVFQgaXMgaGlnaCBvbiBteSBsaXN0IG9mIHdvcmsgSSBuZWVkIHRvIGdldCBk b25lLiAgU28sIEnigJltIG1vdGl2YXRlZCB0byBoZWxwIG91dC4NClRoYW5rcywgZ3JlYXQuDQoN ClRoZSBiYXNpYyBwcm9ibGVtIGlzIHRoYXQgd2XigJlyZSBnb2luZyB0byBnZXQgdmVyeSBpbmNv bnNpc3RlbnQgVUkgZG9pbmcgaXQgdGhhdCB3YXksIGJlY2F1c2Ugb2YgaG93IHN5c3RlbXMgd2ls bCBoYW5kbGUgYmFja3NwYWNlIG9mIG9uZSBwYXJ0eSB0aGF0IGV4dGVuZHMgYmV5b25kIHJlc3Bv bnNlcyBmcm9tIG90aGVyIHBhcnRpZXM6DQood2VsbCwgZm9yIG1lIHRoZSBjdXJyZW50bHkgbW9z dCBiYXNpYyBwcm9ibGVtIGlzIHRvIGhhdmUgYSByZWxpYWJsZSB3YXkgdG8gYXBwZW5kIHJlY2Vp dmVkIHRleHQgdG8gdGhlIGFscmVhZHkgcHJlc2VudGVkIHRleHQgb2YgdGhlIHJpZ2h0IHBhcnRp Y2lwYW50LiBBbmQgdGhhdCBpcyBnZXR0aW5nIHdvcnNlIGluIFdlYlJUQyB0aGFuIGl0IHdhcyBp biBSRkMgNDEwMy4gQnV0IHdlIHdpbGwgc29ydCBpdCBvdXQuKQ0KDQoNCkFsaWNlOiBJIHdhaXRl ZCBmb3IgeW91DQpCb2I6IEkgZGlkbuKAmXQgc2VlIHlvdQ0KQWxpY2U6IHNvcnJ5DQoNCkFuZCB0 aGVuIEFsaWNlIHR5cGVzIDEyIGJhY2tzcGFjZXMuDQoNCldoYXQgc2hvdWxkIGhhcHBlbj8NCg0K WW91IGFyZSByaWdodCB0aGF0IHRoZXJlIGFyZSBhIG51bWJlciBvZiB3YXlzIHRvIGhhbmRsZSB0 aGUgUlRUIFVJLiBBbmQganVzdCBhcyBpbmNvbnNpc3RlbmNpZXMgYXJlIGNvbW1vbiB3aXRoIGEg bWVzc2FnZSBvcmllbnRlZCBVSSwgd2hlcmUgbWVzc2FnZXMgc2hvdyB1cCBpbiBhIGNvbmZ1c2lu ZyBvcmRlciBiZWNhdXNlIHR3byB1c2VycyBjb21wbGV0ZWQgbWVzc2FnZXMgaW4gYW4gdW5leHBl Y3RlZCB0aW1lIG9yZGVyLCBpdCBpcyBwb3NzaWJsZSB0aGF0IFJUVCB0ZXh0IGdldHMgZGlzcGxh eWVkIGluIGEgc3RyYW5nZSBvcmRlciBhZnRlciBlcmFzdXJlIGFuZCByZXR5cGluZy4gSXQgaXMg YmV0dGVyIGZvciBSVFQgdGhhbiBmb3IgbWVzc2FnZSBvcmllbnRlZCBwcmVzZW50YXRpb24sIGFu ZCB1c2VyIGdldCB1c2VkIHRvIGl0IGluIGJvdGggY2FzZXMuICBXaXRoIHRoZSBsYWJlbGxlZCBz dHlsZSBpbiBvbmUgY29sdW1uIHlvdSBoYXZlIGluIHRoZSBleGFtcGxlLCBJIHdvdWxkIHJlY29t bWVuZCB0aGF0IGZpcnN0IDUgYmFja3NwYWNlcyBlcmFzZSAic29ycnkiLCBuZXh0IGJhY2tzcGFj ZSBlcmFzZXMgdGhlIGxpbmUgc2VwYXJhdG9yLCBhbmQgcHVsbHMgZG93biAiSSB3YWl0ZWQgZm9y IHlvdSIgdG8gYmUgc2hvd24gbGFzdCwgYXMgYW4gdW5jb21wbGV0ZWQgdGV4dC4gVGhlbiB0aGUg bmV4dCA2IGJhY2tzcGFjZXMgZXJhc2Ugc28gdGhhdCBvbmx5ICJJIHdhaXRlZCBmIiBpcyBkaXNw bGF5ZWQuIFdoZW4gQWxpY2UgYWRkcyB0ZXh0IGFuZCBlbmQgd2l0aCBhIG5ldyBsaW5lLCB0aGUg Y29ycmVjdGVkIHNlbnRlbmNlIGlzIGFsbG93ZWQgdG8gZmxvdyB1cCB3aGVuIG5ldyB0ZXh0IGlz IGFkZGVkIGZyb20gYW55IHBhcnRpY2lwYW50LiAgVGhhdCBjYXVzZXMgYSBiaXQgc3RyYW5nZSBv cmRlciwgYnV0IGl0IGlzIGp1c3QgYXMgbWFuYWdlYWJsZSBhcyB3aGVuIHRleHQgaW4gbWVzc2Fn aW5nIGFwcGxpY2F0aW9ucyBhcHBlYXIgaW4gYW4gdW5leHBlY3RlZCBvcmRlciBzbyB0aGF0IG9u ZSBtZXNzYWdlIHNlZW1zIHRvIGJlIGEgcmVzcG9uZSBvbiBzb21ldGhpbmcgdG90YWxseSBlbHNl IHRoYW4gd2hhdCB3YXMgaW50ZW5kZWQuDQoNCkEgc29waGlzdGljYXRlZCBVSSBtYXkgbWFyayB0 ZXh0IHRoYXQgaXMgbW92ZWQgYW5kIG1vZGlmaWVkLg0KDQpXZSB3YW50IHRvIGtlZXAgc2VudGVu Y2VzIG9yIGF0IGxlYXN0IHBocmFzZXMgZnJvbSBlYWNoIHBhcnRpY2lwYW50IHRvZ2V0aGVyIGlu IGEgcmVhZGFibGUgdW5pdC4gQWxyZWFkeSB0aGF0IGNhdXNlcyBhIGRlc2lnbiBkZWNpc2lvbiBv biB3aGVyZSB0byBwbGFjZSB0aGUgY29tcGxldGVkIGNodW5rIG9mIHRleHQgb25jZSB0aGUgdXNl ciBoYXMgY29tcGxldGVkIGl0LiBUaGUgc3RhcnQgb2YgdGhlIGNodW5rIG1heSBiZSBvbGRlciB0 aGFuIGNvbXBsZXRlZCB0ZXh0IGZyb20gb3RoZXIgcGFydGljaXBhbnRzIHdoaWNoIHdvdWxkIG1v dGl2YXRlIHRvIG1vdmUgaXQgdXAgYSBiaXQgaW4gdGhlIHByZXNlbnRhdGlvbi4gQnV0IHRoZSBl bmQgb2YgaXQgaXMgYXQgdGhhdCBtb21lbnQgdGhlIGxhdGVzdCB0ZXh0IHRvIHByZXNlbnQuIEkg dGhpbmsgaXQgaXMgYmVzdCB0byBsZXQgdGhlIGZpbmlzaGVkIHRleHQgYmUgcHJlc2VudGVkIGxh c3Qgb24gdGhlIGRpc3BsYXksIGJ1dCBsZXQgb3RoZXJzJyBuZXdlciB0ZXh0IHB1c2ggZXZlcnl0 aGluZyB1cCBhbmQgYmUgZGlzcGxheWVkIGxhc3QuDQoNCg0KVC4xNDAgaGFzIGluZm9ybWF0aW9u IG9uIGhvdyB0byBoYW5kbGUgZXJhc3VyZToNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLUZyb20gVC4x NDAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KOC4yIEVyYXNlIGxhc3QgY2hhcmFjdGVy DQpQdXJwb3NlOiBFcmFzZSB0aGUgbGFzdCBjaGFyYWN0ZXIgc2VudCBmcm9tIHRoZSBkaXNwbGF5 IGF0IHRoZSByZWNlaXZpbmcgZW5kLg0KQ29kZTogQlM6IDAwMDguDQpQcm9jZWR1cmU6IE9uIHRo ZSByZWNlaXZpbmcgZW5kOiBNb3ZlIHRoZSBpbnNlcnRpb24gcG9pbnQgdG8gdGhlIGxhc3QgY2hh cmFjdGVyIGFuZCBlcmFzZSBpdC4NCkNvbWJpbmVkIGNoYXJhY3RlcnMgYXJlIGVyYXNlZCBhcyBh IHVuaXQsIHdpdGggb25lIEJTIGVyYXNpbmcgdGhlIHdob2xlIGNoYXJhY3RlciBldmVuIGlmIGl0 IGlzDQpjb21iaW5lZCBmcm9tIG1vcmUgdGhhbiBvbmUgY29tcG9uZW50Lg0KQ29udHJvbCBzZXF1 ZW5jZXMgKGxpa2UgQ1IgTEYpIGFyZSBlcmFzZWQgaW4gb25lIG9wZXJhdGlvbi4NCk5PVEUg4oCT IFRoZSBzYW1lIGFjdGlvbiBzaGFsbCBiZSB0YWtlbiBvbiB0aGUgbG9jYWwgZGlzcGxheS4NCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQoNCiAgL0d1bm5hcg0KDQoNCg0KQnJpYW4NCg0KDQpPbiBBdWcgMjcsIDIwMTksIGF0IDk6 NTIgQU0sIEd1bm5hciBIZWxsc3Ryw7ZtIDxndW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iuc2U8bWFp bHRvOmd1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5zZT4gPG1haWx0bzpndW5uYXIuaGVsbHN0cm9t QG9tbml0b3Iuc2U+PiB3cm90ZToNCg0KSGksDQoNCkEgdG9waWMgaXMgY3VycmVudGx5IGRpc2N1 c3NlZCBpbiBtbXVzaWMgdGhhdCBpcyBjbG9zZWx5IHJlbGF0ZWQgdG8gcnVtLiBpdCBpcyBXZWJS VEMgdHJhbnNwb3J0IG9mIHJlYWwtdGltZSB0ZXh0Lg0KDQpUaGUgZHJhZnQgaXMgZHJhZnQtaG9s bWJlcmctbW11c2ljLXQxNDAtdXNhZ2UtZGF0YS1jaGFubmVsIC4NCg0KQSBnb29kIHBvaW50IHRv IHN0YXJ0IHJlYWRpbmcgY291bGQgYmU6DQoNCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcv YXJjaC9icm93c2UvbW11c2ljLz9nYnQ9MSZxPWRyYWZ0LWhvbG1iZXJnLW1tdXNpYy10MTQwLXVz YWdlLWRhdGEtY2hhbm5lbA0KDQpQbGVhc2UgY2hlY2sgaWYgdGhlIGN1cnJlbnQgc3RhdGUgb2Yg dGhlIGRpc2N1c3Npb24gc3VpdHMgcnVtIQ0KDQpUaGUgb25seSBpc3N1ZSB0aGF0IHNlZW1zIHRv IGJlIHJlbWFpbmluZyBpcyBob3cgdG8gdHJhbnNwb3J0IFJUVCBkYXRhIHRvIGFuZCBmcm9tIGEg Y29uZmVyZW5jZSBzZXJ2ZXIgdGhhdCBjb21iaW5lcyBhbGwgdHJhZmZpYyBwZXIgbWVkaWEgaW4g YSBtZWV0aW5nIGluIG9uZSBkYXRhIHN0cmVhbS4gVGhhdCBpcyBub3QgdmVyeSBlbGVnYW50bHkg c3BlY2lmaWVkIGZvciBSRkMgNDEwMyB0cmFuc3BvcnQgb2YgUlRUIGluIFJUUCBlaXRoZXIsIHNv IHdlIG1pZ2h0IHdhbnQgdG8gZG8gYSByYXBpZCBhY3Rpb24gdG9nZXRoZXIgdG8gc29sdmUgdGhl IG11bHRpLXBhcnR5IFJUVCBNQ1UgY2FzZSBpbiBhIGdlbmVyYWwgYW5kIGNvbnNpc3RlbnQgd2F5 Lg0KDQpSZWdhcmRzDQoNCkd1bm5hcg0KDQotLQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCkd1bm5hciBIZWxsc3Ryw7ZtDQpPbW5pdG9yDQpndW5uYXIuaGVsbHN0 cm9tQG9tbml0b3Iuc2U8bWFpbHRvOmd1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5zZT4NCis0NiA3 MDggMjA0IDI4OA0KDQotLQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCkd1bm5hciBIZWxsc3Ryw7ZtDQpPbW5pdG9yDQpndW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iu c2U8bWFpbHRvOmd1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5zZT4gPG1haWx0bzpndW5uYXIuaGVs bHN0cm9tQG9tbml0b3Iuc2U+DQorNDYgNzA4IDIwNCAyODgNCg0KLS0NCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpHdW5uYXIgSGVsbHN0csO2bQ0KT21uaXRvcg0K Z3VubmFyLmhlbGxzdHJvbUBvbW5pdG9yLnNlPG1haWx0bzpndW5uYXIuaGVsbHN0cm9tQG9tbml0 b3Iuc2U+DQorNDYgNzA4IDIwNCAyODgNCg0KLS0NClJ1bSBtYWlsaW5nIGxpc3QNClJ1bUBpZXRm Lm9yZzxtYWlsdG86UnVtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9ydW0NCg0K --_000_BL0PR0901MB23862F432B1A40B42C8C41E5B9A20BL0PR0901MB2386_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25v cm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1z b25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uYXBw bGUtdGFiLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtdGFiLXNwYW47fQ0Kc3Bhbi5hcHBs ZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNl O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPuKAnGxpbmUgYXQgYSB0aW1l4oCdIGlzIGEgdXNlciBpbnRlcmZhY2UgaXNzdWUg 4oCTIFJVTSBpcyBkZWZpbmluZyBhIG1hY2hpbmUgaW50ZXJmYWNlLiZuYnNwOyBIb3cgaXTigJlz IHByZXNlbnRlZCB0byB0aGUgdXNlciBpcyBvdXQgb2Ygc2NvcGUuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPi0tSmltPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPkZyb206PC9iPiBSdW0gJmx0O3J1bS1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhh bGYgT2YgPC9iPg0KQnJpYW4gUm9zZW48YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEF1Z3Vz dCAyOSwgMjAxOSAxOjE1IFBNPGJyPg0KPGI+VG86PC9iPiBLeXppdmF0LCBQYXVsICZsdDtwa3l6 aXZhdEBhbHVtLm1pdC5lZHUmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBydW1AaWV0Zi5vcmc8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gW0VYVF0gUmU6IFtSdW1dIFJlYWwtdGltZSB0ZXh0IGluIFdlYlJUQyBp cyBkaXNjdXNzZWQgaW4gbW11c2ljIC0gYSB0b3BpYyBjbG9zZWx5IHRlbGF0ZWQgdG8gcnVtPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7igJxMaW5lIGF0IGEgdGltZeKA nSBjb3VsZCBiZSBhbiBpbXBsZW1lbnRhdGlvbiBvcHRpb24uICZuYnNwO1RoZSBwcm90b2NvbCBt ZWNoYW5pc20gaXMgYWxsIHN0cmVhbXMgaGVhZCB0byBhIG1peGVyIGFuZCB0aGUgbWl4ZXIgc2Vu ZHMgYSBzaW5nbGUgc3RyZWFtIHRvIGVhY2ggcGFydGljaXBhbnQuPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HdW5uYXIsIHdlIGFncmVlZCB3ZSB3ZXJlIHVz aW5nIDQxMDMgaW4gUlVNLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5CcmlhbjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gQXVnIDI5LCAyMDE5LCBhdCAxMjowNSBQTSwgUGF1bCBLeXppdmF0ICZsdDs8 YSBocmVmPSJtYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1Ij5wa3l6aXZhdEBhbHVtLm1pdC5l ZHU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+SSBxdWVzdGlvbiBob3cgd2VsbCBSVFQgdGV4dCBpcyBzdWl0ZWQg dG8gbXVsdGlwYXJ0eSBjb25mZXJlbmNlcy48YnI+DQo8YnI+DQpJZiB5b3UgaGF2ZSBtZXNzYWdl cyBvbiB5b3VyIHNjcmVlbiBmcm9tIG11bHRpcGxlIHBhcnRpZXMsIGFuZCBtYW55IG9mIHRoZW0g YXJlIHVwZGF0aW5nIGluIHJlYWwtdGltZSwgYXJlIHlvdSBnb2luZyB0byBiZSBhYmxlIHRvIHBl cmNlaXZlIHdoYXQgaXMgZ29pbmcgb24/PGJyPg0KPGJyPg0KQW5kIHdoaWxlIHlvdSBjYW4gaGF2 ZSBhIGNvbHVtbiBwZXIgcGVyc29uIGZvciB0d28tcGFydHkgYW5kIG1heWJlIDMtcGFydHkgY29u dmVyc2F0aW9ucywgdGhhdCBkb2Vzbid0IHNjYWxlIHVwLiBXaXRoIG1hbnkgcGFydGllcywgc29t ZSB0eXBpbmcgbWF5IHNjcm9sbCBvZmYgdGhlIHNjcmVlbiBiZWZvcmUgaXQgaXMgY29tcGxldGUu PGJyPg0KPGJyPg0KUGVyaGFwcyBmb3IgY29uZmVyZW5jZXMgaXQgaXMgYmV0dGVyIHRvIGp1c3Qg dXNlIGxpbmUtYXQtYS10aW1lIGNoYXQuIElmIG5lY2Vzc2FyeSwgSSBwcmVzdW1lIHRoZXJlIGNv dWxkIGJlIGdhdGV3YXlzIGJldHdlZW4gUlRUIGFuZCBjaGF0LiBBIFJVRSBjb3VsZCBoYXZlIHRo ZSBjYXBhYmlsaXR5IHRvIG5lZ290aWF0ZSBkb3duIGZyb20gUlRUIHRvIGNoYXQuPGJyPg0KPGJy Pg0KPHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgPC9zcGFuPlRoYW5rcyw8YnI+DQo8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+UGF1bDxicj4NCjxicj4NCk9uIDgvMjgvMTkg MjoxNSBBTSwgR3VubmFyIEhlbGxzdHLDtm0gd3JvdGU6PGJyIHN0eWxlPSJjYXJldC1jb2xvcjog cmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7dGV4dC1hbGlnbjpzdGFydDst d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8YnI+DQo8 L3NwYW4+PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPkRlbiAyMDE5LTA4LTI3IGtsLiAyMzoxNSwgc2tyZXYgQnJpYW4gUm9zZW46PGJyPg0K PGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj5BdCBsZWFzdCBieSBjZW50cmFsaXppbmcgdGhlIHByb2JsZW0gYXQgYSDi gJxtaXhlcuKAnSwgQWxpY2UgYW5kIEJvYiB3aWxsIHNlZSB0aGUgc2FtZSB0aGluZy48YnI+DQo8 YnI+DQpZb3UgZG9u4oCZdCBoYXZlIHRoZSBwcm9ibGVtIGluIEluc3RhbnQgTWVzc2FnaW5nLCBi ZWNhdXNlIHlvdSBjYW7igJl0IGJhY2tzcGFjZSBvciBkZWxldGUgYSBzZW50IG1lc3NhZ2UuICZu YnNwO09mIGNvdXJzZSBpZiBtdWx0aXBsZSBwZW9wbGUgYXJlIHR5cGluZyBzaW11bHRhbmVvdXNs eSBpbiBzdWNoIHN5c3RlbXMsIG1lc3NhZ2Ugb3JkZXIgd2lsbCBiZSBjb25mdXNpbmcgaW4gdGhh dCBpbnN0YW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlJpZ2h0LCBpdCBpcyBhIHNpbWlsYXIga2lu ZCBvZiBwcm9ibGVtIHRoYXQgdGV4dCBhcHBlYXJzIGluIGFuIHVuZXhwZWN0ZWQgb3JkZXIuIFRo ZXJlIGlzIGFsc28gYXQgbGVhc3Qgb25lIGluc3RhbnQgbWVzc2FnaW5nIHNlcnZpY2UgdGhhdCBh bGxvd3MgbW9kaWZpY2F0aW9uIGluIGFscmVhZHkgc2VudA0KIG1lc3NhZ2UuIEJ1dCBJIHRoaW5r IGl0IGhhcyBsaW1pdGF0aW9ucyB0byBvbmx5IGFjY2VwdCB0aGF0IGluIHRoZSBsYXN0IG1lc3Nh Z2Ugc2VudC4gaXQgaXMgY29udmVuaWVudCBhbnl3YXkuPGJyPg0KPGJyPg0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+ DQpBbnl3YXksIHdlIG5lZWQgdG8gc3BlY2lmeSB0aGUgbWl4ZXIgZm9yIFJUVCBzbyBpdCByZWNl aXZlcyBlYWNoIG9mIHRoZSBSVFQgc3RyZWFtcyBhbmQgcHJvZHVjZXMgYSBzaW5nbGUgY29tcG9z aXRlIHN0cmVhbSBmb3IgZWFjaCBwYXJ0aWNpcGFudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5ZZXMs IHJpZ2h0LCBhbmQgdGhlcmUgaXMgYW4gZWZmb3J0IGluIHRoYXQgZGlyZWN0aW9uIGluOjxicj4N CjxhIGhyZWY9Imh0dHA6Ly93d3cucmVhbHRpbWV0ZXh0Lm9yZy9zaXRlcy9kZWZhdWx0L2ZpbGVz L0ZpbGVzX2FuZF9Eb2N1bWVudHMvU3BlY2lmaWNhdGlvbnMvbXVsdGlwYXJ0eS1yZWFsLXRpbWUt dGV4dC1taXhlci0yMDExLTA0LTMwLnBkZiI+aHR0cDovL3d3dy5yZWFsdGltZXRleHQub3JnL3Np dGVzL2RlZmF1bHQvZmlsZXMvRmlsZXNfYW5kX0RvY3VtZW50cy9TcGVjaWZpY2F0aW9ucy9tdWx0 aXBhcnR5LXJlYWwtdGltZS10ZXh0LW1peGVyLTIwMTEtMDQtMzAucGRmPC9hPjxicj4NCkl0IGlz IHdyaXR0ZW4gZm9yIGNvbmZlcmVuY2UtdW5hd2FyZSB1c2VyIGRldmljZXMuPGJyPg0KVGhlIGdv YWxzIGFyZSBzcGVjaWZpZWQgYXMgZm9sbG93czo8YnI+DQpUaGUgcHJvY2VkdXJlcyBhcmUgaW50 ZW5kZWQgdG8gbWFrZSBiZXN0IGVmZm9ydHMgdG8gcHJlc2VudCBhIG11bHRpLXBhcnR5IHRleHQg Y29udmVyc2F0aW9uIG9uIGEgdGVybWluYWwgdGhhdCBoYXMgbm8gYXdhcmVuZXNzIG9mIG11bHRp LXBhcnR5IGNhbGxzLiBUaGVyZSBhcmUgc29tZSBvYnZpb3VzIGRyYXdiYWNrcywgYW5kIGEgdGVy bWluYWwgZGVzaWduZWQgd2l0aCBtdWx0aS1wYXJ0eSBhd2FyZW5lc3Mgd2lsbCBiZSBhYmxlIHRv IHByZXNlbnQNCiBtdWx0aS1wYXJ0eSBjYWxsIGNvbnRlbnRzIGluIGEgbW9yZSBmbGV4aWJsZSB3 YXkuIE9ubHkgdHdvIHBhcnRpZXMgYXQgYSB0aW1lIHdpbGwgYmUgYWxsb3dlZCB0byBkaXNwbGF5 IGFkZGVkIHRleHQgaW4gcmVhbC10aW1lLCB3aGlsZSB0aGUgb3RoZXIgcGFydGllc+KAmSBwcm9k dWNlZCB0ZXh0IHdpbGwgbmVlZCB0byBiZSBzdG9yZWQgaW4gdGhlIG11bHRpLXBhcnR5IHNlcnZl ciBmb3IgYSBtb21lbnQgYXdhaXRpbmcgYSBzdWl0YWJsZSBvY2Nhc2lvbg0KIHRvIGJlIGRpc3Bs YXllZC4gVGhlcmUgYXJlIGFsc28gc29tZSBjYXNlcyBvZiBlcmFzdXJlIHRoYXQgd2lsbCBub3Qg YmUgcGVyZm9ybWVkIG9uIHRoZSB0YXJnZXQgdGV4dCBidXQgb25seSBpbmRpY2F0ZWQgaW4gYW5v dGhlciB3YXkuIEV2ZW4gd2l0aCB0aGVzZSBkcmF3YmFja3MsIHRoZSBwcm9jZWR1cmUgcHJvdmlk ZXMgYW4gb3Bwb3J0dW5pdHkgdG8gZGlzcGxheSB0ZXh0IGZyb20gbW9yZSB0aGFuIHR3byBwYXJ0 aWVzIGluIGEgc21vb3RoIGFuZA0KIHJlYWRhYmxlIHdheS48YnI+DQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpJIHNlZSBzdWNoIG1peGVyIHByb2NlZHVy ZXMgYXMgYSBmYWxsLWJhY2sgZm9yIGNhc2VzIHdpdGhvdXQgY29uZmVyZW5jZSBhd2FyZW5lc3Ms IGJ1dCB3YW50IHRvIHNlZSBzdXBwb3J0IGZvciBjb25mZXJlbmNlLWF3YXJlIHRlcm1pbmFscywg d2hlcmUgdGV4dCBmcm9tIG1vcmUgdGhhbiB0d28gcGFydGllcyBjYW4gYmUgcHJlc2VudGVkIGlu IHJlYWwtdGltZSwgYW5kIHRoZSBlbmQgdXNlciBvciBhcHAgY2FuIGhhdmUgaW5mbHVlbmNlIG92 ZXIgdGhlDQogcHJlc2VudGF0aW9uIHN0eWxlIC0gZS5nLiBzZWxlY3QgYmV0d2VlbiB0aGUgbXVs dGlwbGUgY29sdW1uIHZpZXcgYW5kIHRoZSBvbmUtY29sdW1uLXdpdGgtbGFiZWxzIHZpZXcuJm5i c3A7IEEgbWl4ZXIgZm9yIHRoYXQgY2FzZSB3b3VsZCBvbmx5IG5lZWQgdG8gYXNzdXJlIHRoYXQg dGhlIHJlY2VpdmVyIGhhcyB0aGUgcmlnaHQga2luZCBvZiBtdWx0aS1wYXJ0eSBhd2FyZW5lc3Mg YW5kIHNlbmQgUlRUIHRleHQgd2l0aCBzb3VyY2UgaW5mb3JtYXRpb24NCiBhdHRhY2hlZCwgYW5k IGxldCB0aGUgcmVjZWl2aW5nIHRlcm1pbmFsIHNvcnQgb3V0IHRoZSBwcmVzZW50YXRpb24uIFRo aXMgaXMgYWxyZWFkeSBwb3NzaWJsZSB3aXRoIENTUkMgYW5kIENOQU1FIHdoZW4gdXNpbmcgUlRQ LCBidXQgd2UgbG9zZSB0aGF0IHBvc3NpYmlsaXR5IG5hdGl2ZWx5IHdoZW4gdXNpbmcgdGhlIFdl YlJUQyBkYXRhIGNoYW5uZWwgdG8gdHJhbnNwb3J0IFJUVCwgYW5kIHdvdWxkIG5lZWQgdG8gc3Bl Y2lmeSBhIHdheSB0byBpbmNsdWRlDQogdGhlIHNvdXJjZSBhbHNvIGZvciB0aGF0IGNhc2UuPGJy Pg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t PGJyPg0KQnkgdGhlIHdheSwgd2hhdCBpcyB5b3VyIGN1cnJlbnQgdmlldyBvZiBob3cgdG8gdHJh bnNwb3J0IFJUVCBmb3IgUlVNLCBub3cgd2hlbiB5b3Ugc2F5IHRoYXQgeW91IHdpbGwgdXNlIFdl YlJUQyB0cmFuc3BvcnRzIGZvciBtZWRpYT88YnI+DQpSZWdhcmRzPGJyPg0KR3VubmFyPGJyPg0K PGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIEF1ZyAyNywgMjAxOSwgYXQgNDo0 MyBQTSwgR3VubmFyIEhlbGxzdHLDtm0gJmx0OzxhIGhyZWY9Im1haWx0bzpndW5uYXIuaGVsbHN0 cm9tQG9tbml0b3Iuc2UiPmd1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5zZTwvYT48c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Jmx0OzxhIGhyZWY9Im1haWx0 bzpndW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iuc2UiPm1haWx0bzpndW5uYXIuaGVsbHN0cm9tQG9t bml0b3Iuc2U8L2E+Jmd0OyZndDsNCiB3cm90ZTo8YnI+DQo8YnI+DQpEZW4gMjAxOS0wOC0yNyBr bC4gMjE6NDgsIHNrcmV2IEJyaWFuIFJvc2VuOjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhlIHByb2Js ZW0gb2YgY29uZmVyZW5jZSA0MTAzIFJUVCBpcyBoaWdoIG9uIG15IGxpc3Qgb2Ygd29yayBJIG5l ZWQgdG8gZ2V0IGRvbmUuICZuYnNwO1NvLCBJ4oCZbSBtb3RpdmF0ZWQgdG8gaGVscCBvdXQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+VGhhbmtzLCBncmVhdC48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBi YXNpYyBwcm9ibGVtIGlzIHRoYXQgd2XigJlyZSBnb2luZyB0byBnZXQgdmVyeSBpbmNvbnNpc3Rl bnQgVUkgZG9pbmcgaXQgdGhhdCB3YXksIGJlY2F1c2Ugb2YgaG93IHN5c3RlbXMgd2lsbCBoYW5k bGUgYmFja3NwYWNlIG9mIG9uZSBwYXJ0eSB0aGF0IGV4dGVuZHMgYmV5b25kIHJlc3BvbnNlcw0K IGZyb20gb3RoZXIgcGFydGllczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4od2VsbCwgZm9yIG1lIHRo ZSBjdXJyZW50bHkgbW9zdCBiYXNpYyBwcm9ibGVtIGlzIHRvIGhhdmUgYSByZWxpYWJsZSB3YXkg dG8gYXBwZW5kIHJlY2VpdmVkIHRleHQgdG8gdGhlIGFscmVhZHkgcHJlc2VudGVkIHRleHQgb2Yg dGhlIHJpZ2h0IHBhcnRpY2lwYW50LiBBbmQgdGhhdCBpcyBnZXR0aW5nDQogd29yc2UgaW4gV2Vi UlRDIHRoYW4gaXQgd2FzIGluIFJGQyA0MTAzLiBCdXQgd2Ugd2lsbCBzb3J0IGl0IG91dC4pPGJy Pg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj48YnI+DQpBbGljZTogSSB3YWl0ZWQgZm9yIHlvdTxicj4NCkJvYjog SSBkaWRu4oCZdCBzZWUgeW91PGJyPg0KQWxpY2U6IHNvcnJ5PGJyPg0KPGJyPg0KQW5kIHRoZW4g QWxpY2UgdHlwZXMgMTIgYmFja3NwYWNlcy48YnI+DQo8YnI+DQpXaGF0IHNob3VsZCBoYXBwZW4/ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KWW91IGFyZSByaWdodCB0aGF0IHRoZXJlIGFyZSBh IG51bWJlciBvZiB3YXlzIHRvIGhhbmRsZSB0aGUgUlRUIFVJLiBBbmQganVzdCBhcyBpbmNvbnNp c3RlbmNpZXMgYXJlIGNvbW1vbiB3aXRoIGEgbWVzc2FnZSBvcmllbnRlZCBVSSwgd2hlcmUgbWVz c2FnZXMgc2hvdyB1cCBpbiBhIGNvbmZ1c2luZyBvcmRlciBiZWNhdXNlIHR3byB1c2VycyBjb21w bGV0ZWQgbWVzc2FnZXMgaW4gYW4gdW5leHBlY3RlZCB0aW1lIG9yZGVyLCBpdCBpcyBwb3NzaWJs ZQ0KIHRoYXQgUlRUIHRleHQgZ2V0cyBkaXNwbGF5ZWQgaW4gYSBzdHJhbmdlIG9yZGVyIGFmdGVy IGVyYXN1cmUgYW5kIHJldHlwaW5nLiBJdCBpcyBiZXR0ZXIgZm9yIFJUVCB0aGFuIGZvciBtZXNz YWdlIG9yaWVudGVkIHByZXNlbnRhdGlvbiwgYW5kIHVzZXIgZ2V0IHVzZWQgdG8gaXQgaW4gYm90 aCBjYXNlcy4mbmJzcDsgV2l0aCB0aGUgbGFiZWxsZWQgc3R5bGUgaW4gb25lIGNvbHVtbiB5b3Ug aGF2ZSBpbiB0aGUgZXhhbXBsZSwgSSB3b3VsZCByZWNvbW1lbmQNCiB0aGF0IGZpcnN0IDUgYmFj a3NwYWNlcyBlcmFzZSAmcXVvdDtzb3JyeSZxdW90OywgbmV4dCBiYWNrc3BhY2UgZXJhc2VzIHRo ZSBsaW5lIHNlcGFyYXRvciwgYW5kIHB1bGxzIGRvd24gJnF1b3Q7SSB3YWl0ZWQgZm9yIHlvdSZx dW90OyB0byBiZSBzaG93biBsYXN0LCBhcyBhbiB1bmNvbXBsZXRlZCB0ZXh0LiBUaGVuIHRoZSBu ZXh0IDYgYmFja3NwYWNlcyBlcmFzZSBzbyB0aGF0IG9ubHkgJnF1b3Q7SSB3YWl0ZWQgZiZxdW90 OyBpcyBkaXNwbGF5ZWQuIFdoZW4gQWxpY2UgYWRkcyB0ZXh0IGFuZCBlbmQNCiB3aXRoIGEgbmV3 IGxpbmUsIHRoZSBjb3JyZWN0ZWQgc2VudGVuY2UgaXMgYWxsb3dlZCB0byBmbG93IHVwIHdoZW4g bmV3IHRleHQgaXMgYWRkZWQgZnJvbSBhbnkgcGFydGljaXBhbnQuJm5ic3A7IFRoYXQgY2F1c2Vz IGEgYml0IHN0cmFuZ2Ugb3JkZXIsIGJ1dCBpdCBpcyBqdXN0IGFzIG1hbmFnZWFibGUgYXMgd2hl biB0ZXh0IGluIG1lc3NhZ2luZyBhcHBsaWNhdGlvbnMgYXBwZWFyIGluIGFuIHVuZXhwZWN0ZWQg b3JkZXIgc28gdGhhdCBvbmUgbWVzc2FnZQ0KIHNlZW1zIHRvIGJlIGEgcmVzcG9uZSBvbiBzb21l dGhpbmcgdG90YWxseSBlbHNlIHRoYW4gd2hhdCB3YXMgaW50ZW5kZWQuPGJyPg0KPGJyPg0KQSBz b3BoaXN0aWNhdGVkIFVJIG1heSBtYXJrIHRleHQgdGhhdCBpcyBtb3ZlZCBhbmQgbW9kaWZpZWQu PGJyPg0KPGJyPg0KV2Ugd2FudCB0byBrZWVwIHNlbnRlbmNlcyBvciBhdCBsZWFzdCBwaHJhc2Vz IGZyb20gZWFjaCBwYXJ0aWNpcGFudCB0b2dldGhlciBpbiBhIHJlYWRhYmxlIHVuaXQuIEFscmVh ZHkgdGhhdCBjYXVzZXMgYSBkZXNpZ24gZGVjaXNpb24gb24gd2hlcmUgdG8gcGxhY2UgdGhlIGNv bXBsZXRlZCBjaHVuayBvZiB0ZXh0IG9uY2UgdGhlIHVzZXIgaGFzIGNvbXBsZXRlZCBpdC4gVGhl IHN0YXJ0IG9mIHRoZSBjaHVuayBtYXkgYmUgb2xkZXIgdGhhbiBjb21wbGV0ZWQNCiB0ZXh0IGZy b20gb3RoZXIgcGFydGljaXBhbnRzIHdoaWNoIHdvdWxkIG1vdGl2YXRlIHRvIG1vdmUgaXQgdXAg YSBiaXQgaW4gdGhlIHByZXNlbnRhdGlvbi4gQnV0IHRoZSBlbmQgb2YgaXQgaXMgYXQgdGhhdCBt b21lbnQgdGhlIGxhdGVzdCB0ZXh0IHRvIHByZXNlbnQuIEkgdGhpbmsgaXQgaXMgYmVzdCB0byBs ZXQgdGhlIGZpbmlzaGVkIHRleHQgYmUgcHJlc2VudGVkIGxhc3Qgb24gdGhlIGRpc3BsYXksIGJ1 dCBsZXQgb3RoZXJzJyBuZXdlciB0ZXh0DQogcHVzaCBldmVyeXRoaW5nIHVwIGFuZCBiZSBkaXNw bGF5ZWQgbGFzdC48YnI+DQo8YnI+DQo8YnI+DQpULjE0MCBoYXMgaW5mb3JtYXRpb24gb24gaG93 IHRvIGhhbmRsZSBlcmFzdXJlOjxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS1Gcm9tIFQu MTQwLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0KOC4yIEVyYXNlIGxhc3Qg Y2hhcmFjdGVyPGJyPg0KUHVycG9zZTogRXJhc2UgdGhlIGxhc3QgY2hhcmFjdGVyIHNlbnQgZnJv bSB0aGUgZGlzcGxheSBhdCB0aGUgcmVjZWl2aW5nIGVuZC48YnI+DQpDb2RlOiBCUzogMDAwOC48 YnI+DQpQcm9jZWR1cmU6IE9uIHRoZSByZWNlaXZpbmcgZW5kOiBNb3ZlIHRoZSBpbnNlcnRpb24g cG9pbnQgdG8gdGhlIGxhc3QgY2hhcmFjdGVyIGFuZCBlcmFzZSBpdC48YnI+DQpDb21iaW5lZCBj aGFyYWN0ZXJzIGFyZSBlcmFzZWQgYXMgYSB1bml0LCB3aXRoIG9uZSBCUyBlcmFzaW5nIHRoZSB3 aG9sZSBjaGFyYWN0ZXIgZXZlbiBpZiBpdCBpczxicj4NCmNvbWJpbmVkIGZyb20gbW9yZSB0aGFu IG9uZSBjb21wb25lbnQuPGJyPg0KQ29udHJvbCBzZXF1ZW5jZXMgKGxpa2UgQ1IgTEYpIGFyZSBl cmFzZWQgaW4gb25lIG9wZXJhdGlvbi48YnI+DQpOT1RFIOKAkyBUaGUgc2FtZSBhY3Rpb24gc2hh bGwgYmUgdGFrZW4gb24gdGhlIGxvY2FsIGRpc3BsYXkuPGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJy Pg0KJm5ic3A7IC9HdW5uYXI8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCkJyaWFuPGJy Pg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIEF1 ZyAyNywgMjAxOSwgYXQgOTo1MiBBTSwgR3VubmFyIEhlbGxzdHLDtm0gJmx0OzxhIGhyZWY9Im1h aWx0bzpndW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iuc2UiPmd1bm5hci5oZWxsc3Ryb21Ab21uaXRv ci5zZTwvYT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ Jmx0OzxhIGhyZWY9Im1haWx0bzpndW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iuc2UiPm1haWx0bzpn dW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iuc2U8L2E+Jmd0OyZndDsNCiB3cm90ZTo8YnI+DQo8YnI+ DQpIaSw8YnI+DQo8YnI+DQpBIHRvcGljIGlzIGN1cnJlbnRseSBkaXNjdXNzZWQgaW4gbW11c2lj IHRoYXQgaXMgY2xvc2VseSByZWxhdGVkIHRvIHJ1bS4gaXQgaXMgV2ViUlRDIHRyYW5zcG9ydCBv ZiByZWFsLXRpbWUgdGV4dC48YnI+DQo8YnI+DQpUaGUgZHJhZnQgaXMgZHJhZnQtaG9sbWJlcmct bW11c2ljLXQxNDAtdXNhZ2UtZGF0YS1jaGFubmVsIC48YnI+DQo8YnI+DQpBIGdvb2QgcG9pbnQg dG8gc3RhcnQgcmVhZGluZyBjb3VsZCBiZTo8YnI+DQo8YnI+DQo8YSBocmVmPSJodHRwczovL21h aWxhcmNoaXZlLmlldGYub3JnL2FyY2gvYnJvd3NlL21tdXNpYy8/Z2J0PTEmYW1wO3E9ZHJhZnQt aG9sbWJlcmctbW11c2ljLXQxNDAtdXNhZ2UtZGF0YS1jaGFubmVsIj5odHRwczovL21haWxhcmNo aXZlLmlldGYub3JnL2FyY2gvYnJvd3NlL21tdXNpYy8/Z2J0PTEmYW1wO3E9ZHJhZnQtaG9sbWJl cmctbW11c2ljLXQxNDAtdXNhZ2UtZGF0YS1jaGFubmVsPC9hPjxicj4NCjxicj4NClBsZWFzZSBj aGVjayBpZiB0aGUgY3VycmVudCBzdGF0ZSBvZiB0aGUgZGlzY3Vzc2lvbiBzdWl0cyBydW0hPGJy Pg0KPGJyPg0KVGhlIG9ubHkgaXNzdWUgdGhhdCBzZWVtcyB0byBiZSByZW1haW5pbmcgaXMgaG93 IHRvIHRyYW5zcG9ydCBSVFQgZGF0YSB0byBhbmQgZnJvbSBhIGNvbmZlcmVuY2Ugc2VydmVyIHRo YXQgY29tYmluZXMgYWxsIHRyYWZmaWMgcGVyIG1lZGlhIGluIGEgbWVldGluZyBpbiBvbmUgZGF0 YSBzdHJlYW0uIFRoYXQgaXMgbm90IHZlcnkgZWxlZ2FudGx5IHNwZWNpZmllZCBmb3IgUkZDIDQx MDMgdHJhbnNwb3J0IG9mIFJUVCBpbiBSVFAgZWl0aGVyLCBzbw0KIHdlIG1pZ2h0IHdhbnQgdG8g ZG8gYSByYXBpZCBhY3Rpb24gdG9nZXRoZXIgdG8gc29sdmUgdGhlIG11bHRpLXBhcnR5IFJUVCBN Q1UgY2FzZSBpbiBhIGdlbmVyYWwgYW5kIGNvbnNpc3RlbnQgd2F5Ljxicj4NCjxicj4NClJlZ2Fy ZHM8YnI+DQo8YnI+DQpHdW5uYXI8YnI+DQo8YnI+DQotLTxicj4NCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KR3VubmFyIEhlbGxzdHLDtm08YnI+DQpPbW5p dG9yPGJyPg0KPGEgaHJlZj0ibWFpbHRvOmd1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5zZSI+Z3Vu bmFyLmhlbGxzdHJvbUBvbW5pdG9yLnNlPC9hPjxicj4NCiYjNDM7NDYgNzA4IDIwNCAyODg8YnI+ DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4tLTxicj4NCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KR3VubmFyIEhlbGxzdHLD tm08YnI+DQpPbW5pdG9yPGJyPg0KPGEgaHJlZj0ibWFpbHRvOmd1bm5hci5oZWxsc3Ryb21Ab21u aXRvci5zZSI+Z3VubmFyLmhlbGxzdHJvbUBvbW5pdG9yLnNlPC9hPjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmd1bm5h ci5oZWxsc3Ryb21Ab21uaXRvci5zZSI+bWFpbHRvOmd1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5z ZTwvYT4mZ3Q7PGJyPg0KJiM0Mzs0NiA3MDggMjA0IDI4ODxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+LS08 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpHdW5uYXIgSGVsbHN0 csO2bTxicj4NCk9tbml0b3I8YnI+DQo8YSBocmVmPSJtYWlsdG86Z3VubmFyLmhlbGxzdHJvbUBv bW5pdG9yLnNlIj5ndW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iuc2U8L2E+PGJyPg0KJiM0Mzs0NiA3 MDggMjA0IDI4ODxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCi0tPHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NClJ1bSBtYWlsaW5nIGxpc3Q8YnI+ DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOlJ1bUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ UnVtQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8L3NwYW4+PGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydW0iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnVtPC9zcGFu PjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_BL0PR0901MB23862F432B1A40B42C8C41E5B9A20BL0PR0901MB2386_-- From nobody Thu Aug 29 13:57:50 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99E591208DD for ; Thu, 29 Aug 2019 13:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aS9Fuos6_ZJo for ; Thu, 29 Aug 2019 13:57:44 -0700 (PDT) Received: from bin-mail-out-05.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BB9D120073 for ; Thu, 29 Aug 2019 13:57:43 -0700 (PDT) X-Halon-ID: a165df01-ca9f-11e9-903a-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [88.129.173.120]) by bin-vsp-out-02.atm.binero.net (Halon) with ESMTPSA id a165df01-ca9f-11e9-903a-005056917f90; Thu, 29 Aug 2019 22:57:37 +0200 (CEST) To: "Malloy, Jim" , Brian Rosen , "Kyzivat, Paul" Cc: "rum@ietf.org" References: <9a14addd-9a1c-6130-3880-a814be717323@omnitor.se> <59F6B4E5-16DF-42EB-A654-1749BC9487B5@brianrosen.net> <48c0bc62-0f75-4f83-6d9c-f763982dd000@alum.mit.edu> <1388_1567098914_5D680821_1388_680_16_CE25682F-6A84-4033-BAFD-5D40ED6A0B09@brianrosen.net> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <04222b68-e23f-9cc7-7c12-71747ad75a34@omnitor.se> Date: Thu, 29 Aug 2019 22:57:37 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------71C53EBCE16ED69C8FBACF7A" Content-Language: en-US Archived-At: Subject: Re: [Rum] [EXT] Re: Real-time text in WebRTC is discussed in mmusic - a topic closely telated to rum X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 20:57:49 -0000 This is a multi-part message in MIME format. --------------71C53EBCE16ED69C8FBACF7A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Brian said: we agreed we were using 4103 in RUM. Good toknow. But is there not a hope to be able to even use browser technology for the implementation. The browsers only support RTP for audio and video. Can you make RTP-based RTT work in that environment and encrypted with the security method specified for WebRTC? See a bit more below: Den 2019-08-29 kl. 21:59, skrev Malloy, Jim: > “line at a time” is a user interface issue – RUM is defining a machine > interface.  How it’s presented to the user is out of scope. > Well, the control and coding must be made so that it is possible to make a good presentation. Transmission only line-by-line would not suit the intention of RTT. It is hard to make a good RTT presentation with a client that is only expecting text from one other participant and a mixer that has the task to send text from many sources combined in one stream. The best result is usable but not nice. And it will be aimed at just one way to present RTT. No freedom to plan the presentation according to user preferences. A receiver may, if there is a desire for such functionality, store received text until a received message is complete. I do not think that it is to prefer in any situation. Regards Gunnar > --Jim > > *From:* Rum *On Behalf Of * Brian Rosen > *Sent:* Thursday, August 29, 2019 1:15 PM > *To:* Kyzivat, Paul > *Cc:* rum@ietf.org > *Subject:* [EXT] Re: [Rum] Real-time text in WebRTC is discussed in > mmusic - a topic closely telated to rum > > “Line at a time” could be an implementation option.  The protocol > mechanism is all streams head to a mixer and the mixer sends a single > stream to each participant. > > Gunnar, we agreed we were using 4103 in RUM. > > Brian > > > > On Aug 29, 2019, at 12:05 PM, Paul Kyzivat > wrote: > > I question how well RTT text is suited to multiparty conferences. > > If you have messages on your screen from multiple parties, and > many of them are updating in real-time, are you going to be able > to perceive what is going on? > > And while you can have a column per person for two-party and maybe > 3-party conversations, that doesn't scale up. With many parties, > some typing may scroll off the screen before it is complete. > > Perhaps for conferences it is better to just use line-at-a-time > chat. If necessary, I presume there could be gateways between RTT > and chat. A RUE could have the capability to negotiate down from > RTT to chat. > > Thanks, > Paul > > On 8/28/19 2:15 AM, Gunnar Hellström wrote: > > Den 2019-08-27 kl. 23:15, skrev Brian Rosen: > > At least by centralizing the problem at a “mixer”, Alice > and Bob will see the same thing. > > You don’t have the problem in Instant Messaging, because > you can’t backspace or delete a sent message.  Of course > if multiple people are typing simultaneously in such > systems, message order will be confusing in that instant. > > Right, it is a similar kind of problem that text appears in an > unexpected order. There is also at least one instant messaging > service that allows modification in already sent message. But > I think it has limitations to only accept that in the last > message sent. it is convenient anyway. > > > Anyway, we need to specify the mixer for RTT so it > receives each of the RTT streams and produces a single > composite stream for each participant. > > Yes, right, and there is an effort in that direction in: > http://www.realtimetext.org/sites/default/files/Files_and_Documents/Specifications/multiparty-real-time-text-mixer-2011-04-30.pdf > It is written for conference-unaware user devices. > The goals are specified as follows: > The procedures are intended to make best efforts to present a > multi-party text conversation on a terminal that has no > awareness of multi-party calls. There are some obvious > drawbacks, and a terminal designed with multi-party awareness > will be able to present multi-party call contents in a more > flexible way. Only two parties at a time will be allowed to > display added text in real-time, while the other parties’ > produced text will need to be stored in the multi-party server > for a moment awaiting a suitable occasion to be displayed. > There are also some cases of erasure that will not be > performed on the target text but only indicated in another > way. Even with these drawbacks, the procedure provides an > opportunity to display text from more than two parties in a > smooth and readable way. > --------------------------------------------------------------------------------------------------- > I see such mixer procedures as a fall-back for cases without > conference awareness, but want to see support for > conference-aware terminals, where text from more than two > parties can be presented in real-time, and the end user or app > can have influence over the presentation style - e.g. select > between the multiple column view and the > one-column-with-labels view.  A mixer for that case would only > need to assure that the receiver has the right kind of > multi-party awareness and send RTT text with source > information attached, and let the receiving terminal sort out > the presentation. This is already possible with CSRC and CNAME > when using RTP, but we lose that possibility natively when > using the WebRTC data channel to transport RTT, and would need > to specify a way to include the source also for that case. > ------------------------------------------------------ > By the way, what is your current view of how to transport RTT > for RUM, now when you say that you will use WebRTC transports > for media? > Regards > Gunnar > > > > On Aug 27, 2019, at 4:43 PM, Gunnar Hellström > > > wrote: > > Den 2019-08-27 kl. 21:48, skrev Brian Rosen: > > The problem of conference 4103 RTT is high on my > list of work I need to get done.  So, I’m > motivated to help out. > > Thanks, great. > > The basic problem is that we’re going to get very > inconsistent UI doing it that way, because of how > systems will handle backspace of one party that > extends beyond responses from other parties: > > (well, for me the currently most basic problem is to > have a reliable way to append received text to the > already presented text of the right participant. And > that is getting worse in WebRTC than it was in RFC > 4103. But we will sort it out.) > > > Alice: I waited for you > Bob: I didn’t see you > Alice: sorry > > And then Alice types 12 backspaces. > > What should happen? > > > You are right that there are a number of ways to > handle the RTT UI. And just as inconsistencies are > common with a message oriented UI, where messages show > up in a confusing order because two users completed > messages in an unexpected time order, it is possible > that RTT text gets displayed in a strange order after > erasure and retyping. It is better for RTT than for > message oriented presentation, and user get used to it > in both cases.  With the labelled style in one column > you have in the example, I would recommend that first > 5 backspaces erase "sorry", next backspace erases the > line separator, and pulls down "I waited for you" to > be shown last, as an uncompleted text. Then the next 6 > backspaces erase so that only "I waited f" is > displayed. When Alice adds text and end with a new > line, the corrected sentence is allowed to flow up > when new text is added from any participant.  That > causes a bit strange order, but it is just as > manageable as when text in messaging applications > appear in an unexpected order so that one message > seems to be a respone on something totally else than > what was intended. > > A sophisticated UI may mark text that is moved and > modified. > > We want to keep sentences or at least phrases from > each participant together in a readable unit. Already > that causes a design decision on where to place the > completed chunk of text once the user has completed > it. The start of the chunk may be older than completed > text from other participants which would motivate to > move it up a bit in the presentation. But the end of > it is at that moment the latest text to present. I > think it is best to let the finished text be presented > last on the display, but let others' newer text push > everything up and be displayed last. > > > T.140 has information on how to handle erasure: > > -------------------From T.140--------------------------- > > 8.2 Erase last character > Purpose: Erase the last character sent from the > display at the receiving end. > Code: BS: 0008. > Procedure: On the receiving end: Move the insertion > point to the last character and erase it. > Combined characters are erased as a unit, with one BS > erasing the whole character even if it is > combined from more than one component. > Control sequences (like CR LF) are erased in one > operation. > NOTE – The same action shall be taken on the local > display. > > ------------------------------------------------------------ > >   /Gunnar > > > > Brian > > > On Aug 27, 2019, at 9:52 AM, Gunnar Hellström > > > wrote: > > Hi, > > A topic is currently discussed in mmusic that > is closely related to rum. it is WebRTC > transport of real-time text. > > The draft is > draft-holmberg-mmusic-t140-usage-data-channel . > > A good point to start reading could be: > > https://mailarchive.ietf.org/arch/browse/mmusic/?gbt=1&q=draft-holmberg-mmusic-t140-usage-data-channel > > Please check if the current state of the > discussion suits rum! > > The only issue that seems to be remaining is > how to transport RTT data to and from a > conference server that combines all traffic > per media in a meeting in one data stream. > That is not very elegantly specified for RFC > 4103 transport of RTT in RTP either, so we > might want to do a rapid action together to > solve the multi-party RTT MCU case in a > general and consistent way. > > Regards > > Gunnar > > -- > ----------------------------------------- > Gunnar Hellström > Omnitor > gunnar.hellstrom@omnitor.se > > +46 708 204 288 > > -- > ----------------------------------------- > Gunnar Hellström > Omnitor > gunnar.hellstrom@omnitor.se > > +46 708 204 288 > > -- > ----------------------------------------- > Gunnar Hellström > Omnitor > gunnar.hellstrom@omnitor.se > +46 708 204 288 > > > -- > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum > > -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------71C53EBCE16ED69C8FBACF7A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Brian said: we agreed we were using 4103 in RUM.

Good toknow. But is there not a hope to be able to even use browser technology for the implementation. The browsers only support RTP for audio and video. Can you make RTP-based RTT work in that environment and encrypted with the security method specified for WebRTC?

See a bit more below: 

Den 2019-08-29 kl. 21:59, skrev Malloy, Jim:

“line at a time” is a user interface issue – RUM is defining a machine interface.  How it’s presented to the user is out of scope.

Well, the control and coding must be made so that it is possible to make a good presentation. Transmission only line-by-line would not suit the intention of RTT. It is hard to make a good RTT presentation with a client that is only expecting text from one other participant and a mixer that has the task to send text from many sources combined in one stream. The best result is usable but not nice. And it will be aimed at just one way to present RTT. No freedom to plan the presentation according to user preferences.

A receiver may, if there is a desire for such functionality, store received text until a received message is complete. I do not think that it is to prefer in any situation.

Regards

Gunnar

 

--Jim

 

 

From: Rum <rum-bounces@ietf.org> On Behalf Of Brian Rosen
Sent: Thursday, August 29, 2019 1:15 PM
To: Kyzivat, Paul <pkyzivat@alum.mit.edu>
Cc: rum@ietf.org
Subject: [EXT] Re: [Rum] Real-time text in WebRTC is discussed in mmusic - a topic closely telated to rum

 

“Line at a time” could be an implementation option.  The protocol mechanism is all streams head to a mixer and the mixer sends a single stream to each participant.

 

Gunnar, we agreed we were using 4103 in RUM.

 

Brian



On Aug 29, 2019, at 12:05 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

 

I question how well RTT text is suited to multiparty conferences.

If you have messages on your screen from multiple parties, and many of them are updating in real-time, are you going to be able to perceive what is going on?

And while you can have a column per person for two-party and maybe 3-party conversations, that doesn't scale up. With many parties, some typing may scroll off the screen before it is complete.

Perhaps for conferences it is better to just use line-at-a-time chat. If necessary, I presume there could be gateways between RTT and chat. A RUE could have the capability to negotiate down from RTT to chat.

               Thanks,
               Paul

On 8/28/19 2:15 AM, Gunnar Hellström wrote:

Den 2019-08-27 kl. 23:15, skrev Brian Rosen:

At least by centralizing the problem at a “mixer”, Alice and Bob will see the same thing.

You don’t have the problem in Instant Messaging, because you can’t backspace or delete a sent message.  Of course if multiple people are typing simultaneously in such systems, message order will be confusing in that instant.

Right, it is a similar kind of problem that text appears in an unexpected order. There is also at least one instant messaging service that allows modification in already sent message. But I think it has limitations to only accept that in the last message sent. it is convenient anyway.


Anyway, we need to specify the mixer for RTT so it receives each of the RTT streams and produces a single composite stream for each participant.

Yes, right, and there is an effort in that direction in:
http://www.realtimetext.org/sites/default/files/Files_and_Documents/Specifications/multiparty-real-time-text-mixer-2011-04-30.pdf
It is written for conference-unaware user devices.
The goals are specified as follows:
The procedures are intended to make best efforts to present a multi-party text conversation on a terminal that has no awareness of multi-party calls. There are some obvious drawbacks, and a terminal designed with multi-party awareness will be able to present multi-party call contents in a more flexible way. Only two parties at a time will be allowed to display added text in real-time, while the other parties’ produced text will need to be stored in the multi-party server for a moment awaiting a suitable occasion to be displayed. There are also some cases of erasure that will not be performed on the target text but only indicated in another way. Even with these drawbacks, the procedure provides an opportunity to display text from more than two parties in a smooth and readable way.
---------------------------------------------------------------------------------------------------
I see such mixer procedures as a fall-back for cases without conference awareness, but want to see support for conference-aware terminals, where text from more than two parties can be presented in real-time, and the end user or app can have influence over the presentation style - e.g. select between the multiple column view and the one-column-with-labels view.  A mixer for that case would only need to assure that the receiver has the right kind of multi-party awareness and send RTT text with source information attached, and let the receiving terminal sort out the presentation. This is already possible with CSRC and CNAME when using RTP, but we lose that possibility natively when using the WebRTC data channel to transport RTT, and would need to specify a way to include the source also for that case.
------------------------------------------------------
By the way, what is your current view of how to transport RTT for RUM, now when you say that you will use WebRTC transports for media?
Regards
Gunnar



On Aug 27, 2019, at 4:43 PM, Gunnar Hellström <gunnar.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se>> wrote:

Den 2019-08-27 kl. 21:48, skrev Brian Rosen:

The problem of conference 4103 RTT is high on my list of work I need to get done.  So, I’m motivated to help out.

Thanks, great.

The basic problem is that we’re going to get very inconsistent UI doing it that way, because of how systems will handle backspace of one party that extends beyond responses from other parties:

(well, for me the currently most basic problem is to have a reliable way to append received text to the already presented text of the right participant. And that is getting worse in WebRTC than it was in RFC 4103. But we will sort it out.)


Alice: I waited for you
Bob: I didn’t see you
Alice: sorry

And then Alice types 12 backspaces.

What should happen?


You are right that there are a number of ways to handle the RTT UI. And just as inconsistencies are common with a message oriented UI, where messages show up in a confusing order because two users completed messages in an unexpected time order, it is possible that RTT text gets displayed in a strange order after erasure and retyping. It is better for RTT than for message oriented presentation, and user get used to it in both cases.  With the labelled style in one column you have in the example, I would recommend that first 5 backspaces erase "sorry", next backspace erases the line separator, and pulls down "I waited for you" to be shown last, as an uncompleted text. Then the next 6 backspaces erase so that only "I waited f" is displayed. When Alice adds text and end with a new line, the corrected sentence is allowed to flow up when new text is added from any participant.  That causes a bit strange order, but it is just as manageable as when text in messaging applications appear in an unexpected order so that one message seems to be a respone on something totally else than what was intended.

A sophisticated UI may mark text that is moved and modified.

We want to keep sentences or at least phrases from each participant together in a readable unit. Already that causes a design decision on where to place the completed chunk of text once the user has completed it. The start of the chunk may be older than completed text from other participants which would motivate to move it up a bit in the presentation. But the end of it is at that moment the latest text to present. I think it is best to let the finished text be presented last on the display, but let others' newer text push everything up and be displayed last.


T.140 has information on how to handle erasure:

-------------------From T.140---------------------------

8.2 Erase last character
Purpose: Erase the last character sent from the display at the receiving end.
Code: BS: 0008.
Procedure: On the receiving end: Move the insertion point to the last character and erase it.
Combined characters are erased as a unit, with one BS erasing the whole character even if it is
combined from more than one component.
Control sequences (like CR LF) are erased in one operation.
NOTE – The same action shall be taken on the local display.

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

  /Gunnar



Brian


On Aug 27, 2019, at 9:52 AM, Gunnar Hellström <gunnar.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se>> wrote:

Hi,

A topic is currently discussed in mmusic that is closely related to rum. it is WebRTC transport of real-time text.

The draft is draft-holmberg-mmusic-t140-usage-data-channel .

A good point to start reading could be:

https://mailarchive.ietf.org/arch/browse/mmusic/?gbt=1&q=draft-holmberg-mmusic-t140-usage-data-channel

Please check if the current state of the discussion suits rum!

The only issue that seems to be remaining is how to transport RTT data to and from a conference server that combines all traffic per media in a meeting in one data stream. That is not very elegantly specified for RFC 4103 transport of RTT in RTP either, so we might want to do a rapid action together to solve the multi-party RTT MCU case in a general and consistent way.

Regards

Gunnar

--
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288

--
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se>
+46 708 204 288

 

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288


-- 
Rum mailing list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum

 


-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------71C53EBCE16ED69C8FBACF7A-- From nobody Fri Aug 30 04:32:38 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A22D012080B for ; Fri, 30 Aug 2019 04:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=purplenetwork.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DApBrDGT_CsV for ; Fri, 30 Aug 2019 04:32:32 -0700 (PDT) Received: from NAM05-BY2-obe.outbound.protection.outlook.com (mail-eopbgr710118.outbound.protection.outlook.com [40.107.71.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B69D12022A for ; Fri, 30 Aug 2019 04:32:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SUMHT2mEjyjamLPwbmeFI17JZ5ZUgCRWdrYVuxQpgFYIo/qk5RofOgvyIUz8hRY4GYT+c0qpY4UI9BEeWzixKDkXCagV51s8gMyF/pm59xW8E3k3lNrF6OaXVsS0/gohN00Jq0Y3ZvgL+OXEEM5Oe3GJhhV369ym0TvyTGACOikTObIk6O/NLzvr/Ziw7yffZSwk+mKJ6v5EaYZsRhGLKqTQH+Uc6S2oefwvNs6wd2bYZlYIi27jC76mHPKLqZuHQHDgAz41K741OYjuqg3ytCgdaL+LVdzQWw5UGN8faxRjmcUwW5PrGNH2PxwdrZsUPs0A1JjaG3MXjItlOWUiRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BT/TjeqpS0a/GIVPljDbcA7jl01PQKXBOx8ixw9Y8zw=; b=HF6I9hctj9DfFTc1S/RKJNkuRF1rYkqs5ilQGNrwumh4ICSgKtshw9ah/xvdDst5O2TFj/IKp8+3gC89Pt0b7dcX+YcJ1bmYJdoAu+pf5NpXt3CjE2kdV0jSyvqjbUZiR+uKDyRIE7ru5yk7mD3KTEONVXsRCOmyvXgBbAWnqCVmPgi+T+OSjVWrlGPGky/0iwjgwHmSZQDdpWsIfcqD1vW9jeB68eh55kwbpSorywZzqL9SWR2aD0k2sVHpl/3OQwN6tjqNkfR7lCt1FKyaqPG9vsBmfvqtIcUbHVugVyOXoZjZ7cuP6uwV6bnr+dvdPEC4+nz2a5Gb51FQZ+ff3Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=purple.us; dmarc=pass action=none header.from=purple.us; dkim=pass header.d=purple.us; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=PurpleNetwork.onmicrosoft.com; s=selector2-PurpleNetwork-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BT/TjeqpS0a/GIVPljDbcA7jl01PQKXBOx8ixw9Y8zw=; b=Kb4OQXA6cDrjVlXinX/G7Tn8W6oHH0udKL4iDagFy20LEdaSuTm4KlW1yldZUTFpnwXy5a96Nxwvp9YuCKEyjIWYA2o3oJosGS01Y7hdYLcLaDSlHD/1UVDQGpBrjlmXLR1H08lPiayKUGgVP128LvFhZNqIVj0gNihQ218iXWA= Received: from DM6PR19MB3276.namprd19.prod.outlook.com (20.176.127.149) by DM6PR19MB3929.namprd19.prod.outlook.com (10.141.107.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.21; Fri, 30 Aug 2019 11:32:29 +0000 Received: from DM6PR19MB3276.namprd19.prod.outlook.com ([fe80::d1be:567f:f7ca:2098]) by DM6PR19MB3276.namprd19.prod.outlook.com ([fe80::d1be:567f:f7ca:2098%6]) with mapi id 15.20.2199.021; Fri, 30 Aug 2019 11:32:28 +0000 From: John Martin To: "rum@ietf.org" Thread-Topic: [Rum] [EXT] Re: Real-time text in WebRTC is discussed in mmusic - a topic closely telated to rum Thread-Index: AQHVXyaaRJXiaUWdJE6oN5+/lVgC9Q== Date: Fri, 30 Aug 2019 11:32:28 +0000 Message-ID: <3C2BF11C-2A0D-4C3B-BE71-7E40FB2677E9@contoso.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1c.0.190812 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.martin@purple.us; x-originating-ip: [87.242.170.206] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0c29a99d-825f-4e28-c8e0-08d72d3dbd5e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM6PR19MB3929; x-ms-traffictypediagnostic: DM6PR19MB3929: x-ms-exchange-purlcount: 21 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0145758B1D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39830400003)(346002)(136003)(396003)(366004)(376002)(189003)(199004)(52314003)(91956017)(5660300002)(76116006)(256004)(6246003)(186003)(486006)(476003)(7736002)(606006)(71190400001)(25786009)(71200400001)(6436002)(14454004)(6916009)(86362001)(44832011)(58126008)(966005)(316002)(478600001)(33656002)(2351001)(229853002)(236005)(53946003)(5024004)(5640700003)(2906002)(66066001)(66446008)(66556008)(66476007)(66946007)(64756008)(99286004)(6486002)(26005)(36756003)(81156014)(1730700003)(2501003)(8676002)(81166006)(6116002)(3846002)(54896002)(6512007)(66574012)(53936002)(102836004)(9686003)(6506007)(30864003)(6306002)(53546011)(8936002)(14444005)(79990200002)(80162005)(80862006)(579004)(559001)(569006); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR19MB3929; H:DM6PR19MB3276.namprd19.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: purple.us does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ZIkvgv2a6jVVu/couYKU6W1fS/Epn5cJauUze7taTXA95AkQe1urJBN3hA2M+ILOp9qS4DeAxFXkxbJdxrfOqoksAApFDEGWPTeZr4NoiuRcqJA2iy0Ui91wVp5ij5biANHyuVqZTr0z+cjcX4xzbW6/tNdozRUMKwgtiqPYLN6YeTPCEXRouIIHnev9Ob+GJWfjP4wRn7fhMp5p0Zt28AcavabAxp/g/aCiREkATMsOftkyJ+DxkiiKofiv2vvIcTTCZMF+c2eMY8h0GajY5kzjJjmYc8i4p2DQFXOkYAMovRmQCqLOB7v+SA8fzYou5AbVPC5VLCvom/1wxZ0/cWcc4jQbq9GcPm0dmskkWAszn5cH1iSJPr/y1qNjliDrWGXv7YqB1CM+MgaDQecU0Zz0gNkr+oEhuc/lPu4SoXWHQGJrAxAfPt0wDDsm0KmmmJw7nV8eb4Xbtvxrds8RhQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_3C2BF11C2A0D4C3BBE717E40FB2677E9contosocom_" MIME-Version: 1.0 X-OriginatorOrg: purple.us X-MS-Exchange-CrossTenant-Network-Message-Id: 0c29a99d-825f-4e28-c8e0-08d72d3dbd5e X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2019 11:32:28.3958 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0041a4e6-62ee-427c-beeb-e6aa18257d91 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: UVlT915rpn1KwrYM0U0afwU7TquIAhiLyNq+99qZZj2+nw0Puj/CAWMDPkpODCyaLrOu+bbNtOhnlZVqSm0C7Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR19MB3929 Archived-At: Subject: Re: [Rum] [EXT] Re: Real-time text in WebRTC is discussed in mmusic - a topic closely telated to rum X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 11:32:37 -0000 --_000_3C2BF11C2A0D4C3BBE717E40FB2677E9contosocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxsLA0KDQogICQwLjAyIG9uIFJUVDoNCg0KDQoNClJUVCBpbiBHZW5lcmFsDQoNCi0tLS0tLS0t LS0tLS0tDQoNCklTVE0gdGhlcmUgYXJlIGEgZmV3IG9wdGlvbnMgZm9yIFJUVCBpbiBSVU0sIGFz c3VtaW5nIHRoZSBXZWJSVEMgbWVkaWEgZnJhbWV3b3JrIGlzIGFkb3B0ZWQgKGFzIHNlZW1zIGxp a2VseSk6DQoNCjEuICBVc2UgZXhpc3RpbmcgYnJvd3NlciBzdXBwb3J0IGZvciBTQ1RQIGFzIHJl Y29tbWVuZGVkIGJ5IHRoZSBzb21lIG9mIHRoZSBXZWJSVEMgSUVURiBXRyBwYXJ0aWNpcGFudHMu IFRoaXMgd2FzIGRpc2N1c3NlZCBhcyBwYXJ0IG9mIHRoZSBJVkMgV0cgYW5kIHdvdWxkIHJlcXVp cmUgYW5kIFNDVFAgZGF0YSBjaGFubmVsIHRvIGJlIG5lZ290aWF0ZWQgYW5kIHRvIGVuY2Fwc3Vs YXRlIHRoZSBSVFAgKDQxMDMpIHdoaWNoIHRoZW4gaW4gdHVybiBlbmNhcHN1bGF0ZSBULjE0MCBS VFQuIFRoaXMgc29sdXRpb24gd291bGQgcmVxdWlyZSBnYXRld2F5cyBpbiB0aGUgVlJTIHByb3Zp ZGVyIG5ldHdvcmtzLCBSVFAvUlRDUCB1c2Vyc3BhY2UgKEphdmFzY3JpcHQpIGxheWVycyBpbiB0 aGUgYnJvd3NlciBhbmQgYSBULjE0MCBSVFQgbGF5ZXIvVUkgYWxzbyB3cml0dGVuIGluIHVzZXJz cGFjZSBpbiB0aGUgYnJvd3Nlci4NCg0KMi4gIFdhaXQgZm9yIFdlYlJUQyB0byBzdXBwb3J0IGxv d2VyIGxldmVsIGRhdGEgY2hhbm5lbHMuIFRoaXMgd29yayBpcyBiZWluZyBkaXNjdXNzZWQgaW4g dGhlIFdlYlJUQyBjb21tdW5pdHksIGJ1dCBtaWdodCBiZSBhIGNhc2Ugb2Yg4oCcbm90IGhvbGRp bmcgb3VyIGJyZWF0aOKAnS4gQSBsb3dlciBsZXZlbCBkYXRhIGNoYW5uZWwgd291bGQgYWxsb3cg UlRQL1JUQ1AgdGhlbiBULjE0MCB0byBiZSBuZWdvdGlhdGVkIGluIHRoZSBTRFAgd2l0aG91dCB0 aGUgbmVlZCBmb3IgU0NUUCBhbmQgYXNzb2NpYXRlZCBnYXRld2F5IG5lZWRzLg0KDQozLiAgQXMg YSBzdG9wLWdhcCBhbmQgc2ltcGxpZmljYXRpb24sIHN1cHBvcnQgU0lQIE1FU1NBR0UgYXMgYWxy ZWFkeSBwcm92aWRlZCBmb3IgYnkgdGhlIGJyb3dzZXJzIGFuZCBtYW55IGVuZHBvaW50cywgaW5j bHVkaW5nIFdlYlJUQyBlbmRwb2ludHMNCg0KDQoNCldlIHNob3VsZCBub3QgZm9yZ2V0IHRoYXQg UlRDUCBtdXN0IGJlIGltcGxlbWVudGVkIGFsb25nIHdpdGggUlRQLg0KDQoNCg0KQ29uZmVyZW5j aW5nIGFuZCBSVFQNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQoNClJUVCBpbiBhIGNvbmZl cmVuY2UgaXMgbm90IGN1cnJlbnRseSBkZWZpbmVkIGFuZCBkb2VzIG5vdCB3b3JrIHVzaW5nIGN1 cnJlbnRseSBkZWZpbmVkIHN0YW5kYXJkcyAoSSBtdXN0IGFkbWl0IHRvIGJlaW5nIGJlaW5nIG9u IG1tdXNpYyBzbyBwZXJoYXBzIHRoZXJlIGFyZSBzb2x1dGlvbnMgYmVpbmcgcmVjb21tZW5kZWQg dGhlcmUpLiBEaXNjdXNzaW9ucyBvbiB0aGlzIGhhdmUgYmVlbiBvbmdvaW5nIGZvciBuZWFybHkg MTAgeWVhcnMgKHdlIGRpZG7igJl0IHNvbHZlIGl0IHRoZW4gR3VubmFyIGFuZCBJIHRoaW5rIHRo ZSBwcm9ibGVtcyBhcmUgc3RpbGwgdGhlIHNhbWUpLiBGb3IgUlRUIHRvIGJlIHVzZWZ1bCBpbiBh IGNvbmZlcmVuY2UgdGhlcmUgbmVlZHMgdG8gYmUgYSBmZXcgcHJvYmxlbXMgc29sdmVkLg0KDQox LiAgTXVsdGktc3RyZWFtIHN1cHBvcnQ6IEJyaWFuLCB3aGlsc3QgeW914oCZcmUgcmlnaHQgdGhh dCBtb3N0IGNvbmZlcmVuY2Ugc3lzdGVtcyBhcmUgcG9pbnQtdG8tcG9pbnQgZm9yIHNpZ25hbGxp bmcgdGhleSBhcmUgbW9yZSB0eXBpY2FsbHkgcG9pbnQtdG8tbXVsdGktcG9pbnQgZm9yIG1lZGlh LiBUaGUgY29uZmVyZW5jZSBicmlkZ2UgdXN1YWxseSBoYW5kbGVzIHRoZSBtdWx0aXBsZXhpbmcg b2YgdGhlIHN0cmVhbXMsIGJ1dCB0aGV5IGFyZSB1c3VhbGx5IG5vdyBtdWx0aXBsZSBzdHJlYW1z LiBSVFQgY29uZmVyZW5jaW5nIG5lZWRzIHRvIGhhdmUgdGhlIHNhbWUgc3VwcG9ydC4gV2Ugc2hv dWxkIGFzc3VtZSBjb25mZXJlbmNpbmcgaXMgc3VwcG9ydGVkIGJ5IHdheSBvZiBTRlUgbm90IE1D VSDigJMgdGhhdOKAmXMgaG93IFdlYlJUQyBoYW5kbGVzIGNvbmZlcmVuY2luZyBhbmQgd2Ugc2hv dWxkIGFzc3VtZSB0aGUgc2FtZSBmb3IgUlRULg0KDQoyLiAgUGFydGljaXBhbnQgaWRlbnRpZmlj YXRpb246IHN0cmVhbXMgZnJvbSB0aGUgY29uZmVyZW5jZSBicmlkZ2UgKE1DVS9TRlUpIG11c3Qg YmUgdGFnZ2VkIHdpdGggdGhlIHNlbmRlciBzbyB0aGUgVUkgY2FuIHNpZ25hbCB0byB0aGUgdXNl ciB3aG8gc2VudCB0aGF0IHRleHQgKGFuZCByZWNvbnN0cnVjdCB0aGUgc3RyZWFtIGNvcnJlY3Rs eSkuDQoNCjMuICBVSSBhZGFwdGlvbnM6IE1vZGVybiBXZWJSVEMgYmFzZWQgbXVsdGktcGFydHkg Y29uZmVyZW5jZXMgaGF2ZSBhZGFwdGVkIFVJcyB0byBkaXNwbGF5IG11bHRpcGxlIHZpZGVvIHN0 cmVhbXMuIFVJ4oCZcyBhcmUgYWRhcHRlZCB0byBzaG93IHRoZSB2aWRlbyBwYXJ0aWNpcGFudHMg aG93ZXZlciB0aGUgdXNlciB3YW50cyB0aGVtIHRvIGJlIGRpc3BsYXllZCAoc2luZ2xlIGZ1bGwg c2NyZWVuLCB0aWxlZCwgdm9pY2UgYWN0aXZhdGVkIGV0YykuIFdlIHNob3VsZCBleHBlY3Qgbm8g bGVzcyBmcm9tIFJUVCBjb25mZXJlbmNlIGVuYWJsZWQgZW5kcG9pbnRzLiBJdCBzaG91bGQgYmUg YSB1c2VyIGRlY2lzaW9uIChpZiB0aGVpciBVSSBzdXBwb3J0cyBpdCkgYXMgdG8gd2hldGhlciB0 aGV5IHNlZSBsaW5lLWJ5LWxpbmUgb3IgUlRUIHJlbmRlcmluZyBvZiB0aGUgdGV4dCBjb252ZXJz YXRpb24uDQoNCjQuICBDb250cm9sIG9mIGhvdyBtYW55IHNpbXVsdGFuZW91cyBwYXJ0aWNpcGFu dHMgY2FuIHRleHQgYW5kIGhvdyB0aGF0IGlzIHByZXNlbnRlZCB0byB0aGUgdXNlciBuZWVkcyB0 byBiZSBleHBsb3JlZC4gTXVsdGlwbGUgaW5zZXJ0aW9uIHBvaW50cyBpbiB0aGUgVUkgaXMgb25l IGFwcHJvYWNoICh0aG91Z2ggcmFwaWRseSBicmVha3MgZG93biBhcyB0aGUgbnVtYmVyIG9mIHVz ZXJzIGluY3JlYXNlcykuIExpbmUtYnktbGluZSBpcyBhbm90aGVyLiBGYWNpbGl0YXRlZCBHQSBp cyBhbm90aGVyICh0aGUgR28gQWhlYWQgY29uY2VwdCBoYXMgYmVlbiB1c2VkIGZvciBhIGxvbmcg dGltZSBpbiB0ZXh0IGNvbnZlcnNhdGlvbnMgYW5kIG1heSBiZSBhcHByb3ByaWF0ZSBpbiBsYXJn ZSBSVFQgY29uZmVyZW5jZXMgdG8gY29udHJvbCBvdmVybG9hZCkuDQoNCg0KDQpBbmQgYSBmaW5h bCBGV0lXOiBJIHRoaW5rIHRoZSB1dGlsaXR5IG9mIFJUVCBpbiBhIGNvbmZlcmVuY2UgcXVpY2ts eSBicmVha3MgZG93biBhcyB0aGUgbnVtYmVyIG9mIHBhcnRpY2lwYW50cyBpbmNyZWFzZXMuIEl0 IGlzIGNvbXBsZXRlbHkgdW5hY2NlcHRhYmxlIHRvIGhhdmUgYSBzaW5nbGUgUlRUIHN0cmVhbSBw cmVzZW50ZWQgdG8gdGhlIHVzZXIgYW5kIGFuIHVubW9kaWZpZWQgVUkuIFlvdSBtaWdodCBhcyB3 ZWxsIHJldmVydCB0byBTSVAgTUVTU0FHRSBhbmQgc29tZXRoaW5nIGxpa2UgWE1QUCwgYW5kIHRo YXQgY291bGQgYWxzbyBiZSBhbiBvcHRpb24gZm9yIGVpdGhlciB0aGUgc2hvcnQgdGVybSBvciBm b3IgZW5kcG9pbnRzIHRoYXQgZG8gbm90IHN1cHBvcnQgbXVsdGktc3RyZWFtIFJUVC4NCg0KDQoN CkpvaG4NCg0KDQoNCg0KDQoNCg0KQnJpYW4gc2FpZDogd2UgYWdyZWVkIHdlIHdlcmUgdXNpbmcg NDEwMyBpbiBSVU0uDQoNCg0KDQpHb29kIHRva25vdy4gQnV0IGlzIHRoZXJlIG5vdCBhIGhvcGUg dG8gYmUgYWJsZSB0byBldmVuIHVzZSBicm93c2VyDQoNCnRlY2hub2xvZ3kgZm9yIHRoZSBpbXBs ZW1lbnRhdGlvbi4gVGhlIGJyb3dzZXJzIG9ubHkgc3VwcG9ydCBSVFAgZm9yDQoNCmF1ZGlvIGFu ZCB2aWRlby4gQ2FuIHlvdSBtYWtlIFJUUC1iYXNlZCBSVFQgd29yayBpbiB0aGF0IGVudmlyb25t ZW50IGFuZA0KDQplbmNyeXB0ZWQgd2l0aCB0aGUgc2VjdXJpdHkgbWV0aG9kIHNwZWNpZmllZCBm b3IgV2ViUlRDPw0KDQoNCg0KU2VlIGEgYml0IG1vcmUgYmVsb3c6DQoNCg0KDQpEZW4gMjAxOS0w OC0yOSBrbC4gMjE6NTksIHNrcmV2IE1hbGxveSwgSmltOg0KDQoNCg0KPiDigJxsaW5lIGF0IGEg dGltZeKAnSBpcyBhIHVzZXIgaW50ZXJmYWNlIGlzc3VlIOKAkyBSVU0gaXMgZGVmaW5pbmcgYSBt YWNoaW5lDQoNCj4gaW50ZXJmYWNlLiAgSG93IGl04oCZcyBwcmVzZW50ZWQgdG8gdGhlIHVzZXIg aXMgb3V0IG9mIHNjb3BlLg0KDQo+DQoNCldlbGwsIHRoZSBjb250cm9sIGFuZCBjb2RpbmcgbXVz dCBiZSBtYWRlIHNvIHRoYXQgaXQgaXMgcG9zc2libGUgdG8gbWFrZQ0KDQphIGdvb2QgcHJlc2Vu dGF0aW9uLiBUcmFuc21pc3Npb24gb25seSBsaW5lLWJ5LWxpbmUgd291bGQgbm90IHN1aXQgdGhl DQoNCmludGVudGlvbiBvZiBSVFQuIEl0IGlzIGhhcmQgdG8gbWFrZSBhIGdvb2QgUlRUIHByZXNl bnRhdGlvbiB3aXRoIGENCg0KY2xpZW50IHRoYXQgaXMgb25seSBleHBlY3RpbmcgdGV4dCBmcm9t IG9uZSBvdGhlciBwYXJ0aWNpcGFudCBhbmQgYQ0KDQptaXhlciB0aGF0IGhhcyB0aGUgdGFzayB0 byBzZW5kIHRleHQgZnJvbSBtYW55IHNvdXJjZXMgY29tYmluZWQgaW4gb25lDQoNCnN0cmVhbS4g VGhlIGJlc3QgcmVzdWx0IGlzIHVzYWJsZSBidXQgbm90IG5pY2UuIEFuZCBpdCB3aWxsIGJlIGFp bWVkIGF0DQoNCmp1c3Qgb25lIHdheSB0byBwcmVzZW50IFJUVC4gTm8gZnJlZWRvbSB0byBwbGFu IHRoZSBwcmVzZW50YXRpb24NCg0KYWNjb3JkaW5nIHRvIHVzZXIgcHJlZmVyZW5jZXMuDQoNCg0K DQpBIHJlY2VpdmVyIG1heSwgaWYgdGhlcmUgaXMgYSBkZXNpcmUgZm9yIHN1Y2ggZnVuY3Rpb25h bGl0eSwgc3RvcmUNCg0KcmVjZWl2ZWQgdGV4dCB1bnRpbCBhIHJlY2VpdmVkIG1lc3NhZ2UgaXMg Y29tcGxldGUuIEkgZG8gbm90IHRoaW5rIHRoYXQNCg0KaXQgaXMgdG8gcHJlZmVyIGluIGFueSBz aXR1YXRpb24uDQoNCg0KDQpSZWdhcmRzDQoNCg0KDQpHdW5uYXINCg0KDQoNCj4gLS1KaW0NCg0K Pg0KDQo+ICpGcm9tOiogUnVtIDxydW0tYm91bmNlc0BpZXRmLm9yZz48bWFpbHRvOnJ1bS1ib3Vu Y2VzQGlldGYub3JnJmd0PjsgKk9uIEJlaGFsZiBPZiAqIEJyaWFuIFJvc2VuDQoNCj4gKlNlbnQ6 KiBUaHVyc2RheSwgQXVndXN0IDI5LCAyMDE5IDE6MTUgUE0NCg0KPiAqVG86KiBLeXppdmF0LCBQ YXVsIDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU+PG1haWx0bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHUm Z3Q+Ow0KDQo+ICpDYzoqIHJ1bUBpZXRmLm9yZzxtYWlsdG86cnVtQGlldGYub3JnPg0KDQo+ICpT dWJqZWN0OiogW0VYVF0gUmU6IFtSdW1dIFJlYWwtdGltZSB0ZXh0IGluIFdlYlJUQyBpcyBkaXNj dXNzZWQgaW4NCg0KPiBtbXVzaWMgLSBhIHRvcGljIGNsb3NlbHkgdGVsYXRlZCB0byBydW0NCg0K Pg0KDQo+IOKAnExpbmUgYXQgYSB0aW1l4oCdIGNvdWxkIGJlIGFuIGltcGxlbWVudGF0aW9uIG9w dGlvbi4gIFRoZSBwcm90b2NvbA0KDQo+IG1lY2hhbmlzbSBpcyBhbGwgc3RyZWFtcyBoZWFkIHRv IGEgbWl4ZXIgYW5kIHRoZSBtaXhlciBzZW5kcyBhIHNpbmdsZQ0KDQo+IHN0cmVhbSB0byBlYWNo IHBhcnRpY2lwYW50Lg0KDQo+DQoNCj4gR3VubmFyLCB3ZSBhZ3JlZWQgd2Ugd2VyZSB1c2luZyA0 MTAzIGluIFJVTS4NCg0KPg0KDQo+IEJyaWFuDQoNCj4NCg0KPg0KDQo+DQoNCj4gICAgIE9uIEF1 ZyAyOSwgMjAxOSwgYXQgMTI6MDUgUE0sIFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAYWx1bS5taXQu ZWR1PG1haWx0bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHU+DQoNCj4gICAgIDxtYWlsdG86cGt5eml2 YXRAYWx1bS5taXQuZWR1Pj4gd3JvdGU6DQoNCj4NCg0KPiAgICAgSSBxdWVzdGlvbiBob3cgd2Vs bCBSVFQgdGV4dCBpcyBzdWl0ZWQgdG8gbXVsdGlwYXJ0eSBjb25mZXJlbmNlcy4NCg0KPg0KDQo+ ICAgICBJZiB5b3UgaGF2ZSBtZXNzYWdlcyBvbiB5b3VyIHNjcmVlbiBmcm9tIG11bHRpcGxlIHBh cnRpZXMsIGFuZA0KDQo+ICAgICBtYW55IG9mIHRoZW0gYXJlIHVwZGF0aW5nIGluIHJlYWwtdGlt ZSwgYXJlIHlvdSBnb2luZyB0byBiZSBhYmxlDQoNCj4gICAgIHRvIHBlcmNlaXZlIHdoYXQgaXMg Z29pbmcgb24/DQoNCj4NCg0KPiAgICAgQW5kIHdoaWxlIHlvdSBjYW4gaGF2ZSBhIGNvbHVtbiBw ZXIgcGVyc29uIGZvciB0d28tcGFydHkgYW5kIG1heWJlDQoNCj4gICAgIDMtcGFydHkgY29udmVy c2F0aW9ucywgdGhhdCBkb2Vzbid0IHNjYWxlIHVwLiBXaXRoIG1hbnkgcGFydGllcywNCg0KPiAg ICAgc29tZSB0eXBpbmcgbWF5IHNjcm9sbCBvZmYgdGhlIHNjcmVlbiBiZWZvcmUgaXQgaXMgY29t cGxldGUuDQoNCj4NCg0KPiAgICAgUGVyaGFwcyBmb3IgY29uZmVyZW5jZXMgaXQgaXMgYmV0dGVy IHRvIGp1c3QgdXNlIGxpbmUtYXQtYS10aW1lDQoNCj4gICAgIGNoYXQuIElmIG5lY2Vzc2FyeSwg SSBwcmVzdW1lIHRoZXJlIGNvdWxkIGJlIGdhdGV3YXlzIGJldHdlZW4gUlRUDQoNCj4gICAgIGFu ZCBjaGF0LiBBIFJVRSBjb3VsZCBoYXZlIHRoZSBjYXBhYmlsaXR5IHRvIG5lZ290aWF0ZSBkb3du IGZyb20NCg0KPiAgICAgUlRUIHRvIGNoYXQuDQoNCj4NCg0KPiAgICAgVGhhbmtzLA0KDQo+ICAg ICBQYXVsDQoNCj4NCg0KPiAgICAgT24gOC8yOC8xOSAyOjE1IEFNLCBHdW5uYXIgSGVsbHN0csO2 bSB3cm90ZToNCg0KPg0KDQo+ICAgICAgICAgRGVuIDIwMTktMDgtMjcga2wuIDIzOjE1LCBza3Jl diBCcmlhbiBSb3NlbjoNCg0KPg0KDQo+ICAgICAgICAgICAgIEF0IGxlYXN0IGJ5IGNlbnRyYWxp emluZyB0aGUgcHJvYmxlbSBhdCBhIOKAnG1peGVy4oCdLCBBbGljZQ0KDQo+ICAgICAgICAgICAg IGFuZCBCb2Igd2lsbCBzZWUgdGhlIHNhbWUgdGhpbmcuDQoNCj4NCg0KPiAgICAgICAgICAgICBZ b3UgZG9u4oCZdCBoYXZlIHRoZSBwcm9ibGVtIGluIEluc3RhbnQgTWVzc2FnaW5nLCBiZWNhdXNl DQoNCj4gICAgICAgICAgICAgeW91IGNhbuKAmXQgYmFja3NwYWNlIG9yIGRlbGV0ZSBhIHNlbnQg bWVzc2FnZS4gIE9mIGNvdXJzZQ0KDQo+ICAgICAgICAgICAgIGlmIG11bHRpcGxlIHBlb3BsZSBh cmUgdHlwaW5nIHNpbXVsdGFuZW91c2x5IGluIHN1Y2gNCg0KPiAgICAgICAgICAgICBzeXN0ZW1z LCBtZXNzYWdlIG9yZGVyIHdpbGwgYmUgY29uZnVzaW5nIGluIHRoYXQgaW5zdGFudC4NCg0KPg0K DQo+ICAgICAgICAgUmlnaHQsIGl0IGlzIGEgc2ltaWxhciBraW5kIG9mIHByb2JsZW0gdGhhdCB0 ZXh0IGFwcGVhcnMgaW4gYW4NCg0KPiAgICAgICAgIHVuZXhwZWN0ZWQgb3JkZXIuIFRoZXJlIGlz IGFsc28gYXQgbGVhc3Qgb25lIGluc3RhbnQgbWVzc2FnaW5nDQoNCj4gICAgICAgICBzZXJ2aWNl IHRoYXQgYWxsb3dzIG1vZGlmaWNhdGlvbiBpbiBhbHJlYWR5IHNlbnQgbWVzc2FnZS4gQnV0DQoN Cj4gICAgICAgICBJIHRoaW5rIGl0IGhhcyBsaW1pdGF0aW9ucyB0byBvbmx5IGFjY2VwdCB0aGF0 IGluIHRoZSBsYXN0DQoNCj4gICAgICAgICBtZXNzYWdlIHNlbnQuIGl0IGlzIGNvbnZlbmllbnQg YW55d2F5Lg0KDQo+DQoNCj4NCg0KPiAgICAgICAgICAgICBBbnl3YXksIHdlIG5lZWQgdG8gc3Bl Y2lmeSB0aGUgbWl4ZXIgZm9yIFJUVCBzbyBpdA0KDQo+ICAgICAgICAgICAgIHJlY2VpdmVzIGVh Y2ggb2YgdGhlIFJUVCBzdHJlYW1zIGFuZCBwcm9kdWNlcyBhIHNpbmdsZQ0KDQo+ICAgICAgICAg ICAgIGNvbXBvc2l0ZSBzdHJlYW0gZm9yIGVhY2ggcGFydGljaXBhbnQuDQoNCj4NCg0KPiAgICAg ICAgIFllcywgcmlnaHQsIGFuZCB0aGVyZSBpcyBhbiBlZmZvcnQgaW4gdGhhdCBkaXJlY3Rpb24g aW46DQoNCj4gICAgICAgICBodHRwOi8vd3d3LnJlYWx0aW1ldGV4dC5vcmcvc2l0ZXMvZGVmYXVs dC9maWxlcy9GaWxlc19hbmRfRG9jdW1lbnRzL1NwZWNpZmljYXRpb25zL211bHRpcGFydHktcmVh bC10aW1lLXRleHQtbWl4ZXItMjAxMS0wNC0zMC5wZGYNCg0KPiAgICAgICAgIEl0IGlzIHdyaXR0 ZW4gZm9yIGNvbmZlcmVuY2UtdW5hd2FyZSB1c2VyIGRldmljZXMuDQoNCj4gICAgICAgICBUaGUg Z29hbHMgYXJlIHNwZWNpZmllZCBhcyBmb2xsb3dzOg0KDQo+ICAgICAgICAgVGhlIHByb2NlZHVy ZXMgYXJlIGludGVuZGVkIHRvIG1ha2UgYmVzdCBlZmZvcnRzIHRvIHByZXNlbnQgYQ0KDQo+ICAg ICAgICAgbXVsdGktcGFydHkgdGV4dCBjb252ZXJzYXRpb24gb24gYSB0ZXJtaW5hbCB0aGF0IGhh cyBubw0KDQo+ICAgICAgICAgYXdhcmVuZXNzIG9mIG11bHRpLXBhcnR5IGNhbGxzLiBUaGVyZSBh cmUgc29tZSBvYnZpb3VzDQoNCj4gICAgICAgICBkcmF3YmFja3MsIGFuZCBhIHRlcm1pbmFsIGRl c2lnbmVkIHdpdGggbXVsdGktcGFydHkgYXdhcmVuZXNzDQoNCj4gICAgICAgICB3aWxsIGJlIGFi bGUgdG8gcHJlc2VudCBtdWx0aS1wYXJ0eSBjYWxsIGNvbnRlbnRzIGluIGEgbW9yZQ0KDQo+ICAg ICAgICAgZmxleGlibGUgd2F5LiBPbmx5IHR3byBwYXJ0aWVzIGF0IGEgdGltZSB3aWxsIGJlIGFs bG93ZWQgdG8NCg0KPiAgICAgICAgIGRpc3BsYXkgYWRkZWQgdGV4dCBpbiByZWFsLXRpbWUsIHdo aWxlIHRoZSBvdGhlciBwYXJ0aWVz4oCZDQoNCj4gICAgICAgICBwcm9kdWNlZCB0ZXh0IHdpbGwg bmVlZCB0byBiZSBzdG9yZWQgaW4gdGhlIG11bHRpLXBhcnR5IHNlcnZlcg0KDQo+ICAgICAgICAg Zm9yIGEgbW9tZW50IGF3YWl0aW5nIGEgc3VpdGFibGUgb2NjYXNpb24gdG8gYmUgZGlzcGxheWVk Lg0KDQo+ICAgICAgICAgVGhlcmUgYXJlIGFsc28gc29tZSBjYXNlcyBvZiBlcmFzdXJlIHRoYXQg d2lsbCBub3QgYmUNCg0KPiAgICAgICAgIHBlcmZvcm1lZCBvbiB0aGUgdGFyZ2V0IHRleHQgYnV0 IG9ubHkgaW5kaWNhdGVkIGluIGFub3RoZXINCg0KPiAgICAgICAgIHdheS4gRXZlbiB3aXRoIHRo ZXNlIGRyYXdiYWNrcywgdGhlIHByb2NlZHVyZSBwcm92aWRlcyBhbg0KDQo+ICAgICAgICAgb3Bw b3J0dW5pdHkgdG8gZGlzcGxheSB0ZXh0IGZyb20gbW9yZSB0aGFuIHR3byBwYXJ0aWVzIGluIGEN Cg0KPiAgICAgICAgIHNtb290aCBhbmQgcmVhZGFibGUgd2F5Lg0KDQo+ICAgICAgICAgLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCj4gICAgICAgICBJIHNlZSBz dWNoIG1peGVyIHByb2NlZHVyZXMgYXMgYSBmYWxsLWJhY2sgZm9yIGNhc2VzIHdpdGhvdXQNCg0K PiAgICAgICAgIGNvbmZlcmVuY2UgYXdhcmVuZXNzLCBidXQgd2FudCB0byBzZWUgc3VwcG9ydCBm b3INCg0KPiAgICAgICAgIGNvbmZlcmVuY2UtYXdhcmUgdGVybWluYWxzLCB3aGVyZSB0ZXh0IGZy b20gbW9yZSB0aGFuIHR3bw0KDQo+ICAgICAgICAgcGFydGllcyBjYW4gYmUgcHJlc2VudGVkIGlu IHJlYWwtdGltZSwgYW5kIHRoZSBlbmQgdXNlciBvciBhcHANCg0KPiAgICAgICAgIGNhbiBoYXZl IGluZmx1ZW5jZSBvdmVyIHRoZSBwcmVzZW50YXRpb24gc3R5bGUgLSBlLmcuIHNlbGVjdA0KDQo+ ICAgICAgICAgYmV0d2VlbiB0aGUgbXVsdGlwbGUgY29sdW1uIHZpZXcgYW5kIHRoZQ0KDQo+ICAg ICAgICAgb25lLWNvbHVtbi13aXRoLWxhYmVscyB2aWV3LiAgQSBtaXhlciBmb3IgdGhhdCBjYXNl IHdvdWxkIG9ubHkNCg0KPiAgICAgICAgIG5lZWQgdG8gYXNzdXJlIHRoYXQgdGhlIHJlY2VpdmVy IGhhcyB0aGUgcmlnaHQga2luZCBvZg0KDQo+ICAgICAgICAgbXVsdGktcGFydHkgYXdhcmVuZXNz IGFuZCBzZW5kIFJUVCB0ZXh0IHdpdGggc291cmNlDQoNCj4gICAgICAgICBpbmZvcm1hdGlvbiBh dHRhY2hlZCwgYW5kIGxldCB0aGUgcmVjZWl2aW5nIHRlcm1pbmFsIHNvcnQgb3V0DQoNCj4gICAg ICAgICB0aGUgcHJlc2VudGF0aW9uLiBUaGlzIGlzIGFscmVhZHkgcG9zc2libGUgd2l0aCBDU1JD IGFuZCBDTkFNRQ0KDQo+ICAgICAgICAgd2hlbiB1c2luZyBSVFAsIGJ1dCB3ZSBsb3NlIHRoYXQg cG9zc2liaWxpdHkgbmF0aXZlbHkgd2hlbg0KDQo+ICAgICAgICAgdXNpbmcgdGhlIFdlYlJUQyBk YXRhIGNoYW5uZWwgdG8gdHJhbnNwb3J0IFJUVCwgYW5kIHdvdWxkIG5lZWQNCg0KPiAgICAgICAg IHRvIHNwZWNpZnkgYSB3YXkgdG8gaW5jbHVkZSB0aGUgc291cmNlIGFsc28gZm9yIHRoYXQgY2Fz ZS4NCg0KPiAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KDQo+ICAgICAgICAgQnkgdGhlIHdheSwgd2hhdCBpcyB5b3VyIGN1cnJl bnQgdmlldyBvZiBob3cgdG8gdHJhbnNwb3J0IFJUVA0KDQo+ICAgICAgICAgZm9yIFJVTSwgbm93 IHdoZW4geW91IHNheSB0aGF0IHlvdSB3aWxsIHVzZSBXZWJSVEMgdHJhbnNwb3J0cw0KDQo+ICAg ICAgICAgZm9yIG1lZGlhPw0KDQo+ICAgICAgICAgUmVnYXJkcw0KDQo+ICAgICAgICAgR3VubmFy DQoNCj4NCg0KPg0KDQo+DQoNCj4gICAgICAgICAgICAgICAgIE9uIEF1ZyAyNywgMjAxOSwgYXQg NDo0MyBQTSwgR3VubmFyIEhlbGxzdHLDtm0NCg0KPiAgICAgICAgICAgICAgICAgPGd1bm5hci5o ZWxsc3Ryb21Ab21uaXRvci5zZTxtYWlsdG86Z3VubmFyLmhlbGxzdHJvbUBvbW5pdG9yLnNlPg0K DQo+ICAgICAgICAgICAgICAgICA8bWFpbHRvOmd1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5zZT48 bWFpbHRvOmd1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5zZT4+DQoNCj4gICAgICAgICAgICAgICAg IHdyb3RlOg0KDQo+DQoNCj4gICAgICAgICAgICAgICAgIERlbiAyMDE5LTA4LTI3IGtsLiAyMTo0 OCwgc2tyZXYgQnJpYW4gUm9zZW46DQoNCj4NCg0KPiAgICAgICAgICAgICAgICAgICAgIFRoZSBw cm9ibGVtIG9mIGNvbmZlcmVuY2UgNDEwMyBSVFQgaXMgaGlnaCBvbiBteQ0KDQo+ICAgICAgICAg ICAgICAgICAgICAgbGlzdCBvZiB3b3JrIEkgbmVlZCB0byBnZXQgZG9uZS4gIFNvLCBJ4oCZbQ0K DQo+ICAgICAgICAgICAgICAgICAgICAgbW90aXZhdGVkIHRvIGhlbHAgb3V0Lg0KDQo+DQoNCj4g ICAgICAgICAgICAgICAgIFRoYW5rcywgZ3JlYXQuDQoNCj4NCg0KPiAgICAgICAgICAgICAgICAg ICAgIFRoZSBiYXNpYyBwcm9ibGVtIGlzIHRoYXQgd2XigJlyZSBnb2luZyB0byBnZXQgdmVyeQ0K DQo+ICAgICAgICAgICAgICAgICAgICAgaW5jb25zaXN0ZW50IFVJIGRvaW5nIGl0IHRoYXQgd2F5 LCBiZWNhdXNlIG9mIGhvdw0KDQo+ICAgICAgICAgICAgICAgICAgICAgc3lzdGVtcyB3aWxsIGhh bmRsZSBiYWNrc3BhY2Ugb2Ygb25lIHBhcnR5IHRoYXQNCg0KPiAgICAgICAgICAgICAgICAgICAg IGV4dGVuZHMgYmV5b25kIHJlc3BvbnNlcyBmcm9tIG90aGVyIHBhcnRpZXM6DQoNCj4NCg0KPiAg ICAgICAgICAgICAgICAgKHdlbGwsIGZvciBtZSB0aGUgY3VycmVudGx5IG1vc3QgYmFzaWMgcHJv YmxlbSBpcyB0bw0KDQo+ICAgICAgICAgICAgICAgICBoYXZlIGEgcmVsaWFibGUgd2F5IHRvIGFw cGVuZCByZWNlaXZlZCB0ZXh0IHRvIHRoZQ0KDQo+ICAgICAgICAgICAgICAgICBhbHJlYWR5IHBy ZXNlbnRlZCB0ZXh0IG9mIHRoZSByaWdodCBwYXJ0aWNpcGFudC4gQW5kDQoNCj4gICAgICAgICAg ICAgICAgIHRoYXQgaXMgZ2V0dGluZyB3b3JzZSBpbiBXZWJSVEMgdGhhbiBpdCB3YXMgaW4gUkZD DQoNCj4gICAgICAgICAgICAgICAgIDQxMDMuIEJ1dCB3ZSB3aWxsIHNvcnQgaXQgb3V0LikNCg0K Pg0KDQo+DQoNCj4gICAgICAgICAgICAgICAgICAgICBBbGljZTogSSB3YWl0ZWQgZm9yIHlvdQ0K DQo+ICAgICAgICAgICAgICAgICAgICAgQm9iOiBJIGRpZG7igJl0IHNlZSB5b3UNCg0KPiAgICAg ICAgICAgICAgICAgICAgIEFsaWNlOiBzb3JyeQ0KDQo+DQoNCj4gICAgICAgICAgICAgICAgICAg ICBBbmQgdGhlbiBBbGljZSB0eXBlcyAxMiBiYWNrc3BhY2VzLg0KDQo+DQoNCj4gICAgICAgICAg ICAgICAgICAgICBXaGF0IHNob3VsZCBoYXBwZW4/DQoNCj4NCg0KPg0KDQo+ICAgICAgICAgICAg ICAgICBZb3UgYXJlIHJpZ2h0IHRoYXQgdGhlcmUgYXJlIGEgbnVtYmVyIG9mIHdheXMgdG8NCg0K PiAgICAgICAgICAgICAgICAgaGFuZGxlIHRoZSBSVFQgVUkuIEFuZCBqdXN0IGFzIGluY29uc2lz dGVuY2llcyBhcmUNCg0KPiAgICAgICAgICAgICAgICAgY29tbW9uIHdpdGggYSBtZXNzYWdlIG9y aWVudGVkIFVJLCB3aGVyZSBtZXNzYWdlcyBzaG93DQoNCj4gICAgICAgICAgICAgICAgIHVwIGlu IGEgY29uZnVzaW5nIG9yZGVyIGJlY2F1c2UgdHdvIHVzZXJzIGNvbXBsZXRlZA0KDQo+ICAgICAg ICAgICAgICAgICBtZXNzYWdlcyBpbiBhbiB1bmV4cGVjdGVkIHRpbWUgb3JkZXIsIGl0IGlzIHBv c3NpYmxlDQoNCj4gICAgICAgICAgICAgICAgIHRoYXQgUlRUIHRleHQgZ2V0cyBkaXNwbGF5ZWQg aW4gYSBzdHJhbmdlIG9yZGVyIGFmdGVyDQoNCj4gICAgICAgICAgICAgICAgIGVyYXN1cmUgYW5k IHJldHlwaW5nLiBJdCBpcyBiZXR0ZXIgZm9yIFJUVCB0aGFuIGZvcg0KDQo+ICAgICAgICAgICAg ICAgICBtZXNzYWdlIG9yaWVudGVkIHByZXNlbnRhdGlvbiwgYW5kIHVzZXIgZ2V0IHVzZWQgdG8g aXQNCg0KPiAgICAgICAgICAgICAgICAgaW4gYm90aCBjYXNlcy4gIFdpdGggdGhlIGxhYmVsbGVk IHN0eWxlIGluIG9uZSBjb2x1bW4NCg0KPiAgICAgICAgICAgICAgICAgeW91IGhhdmUgaW4gdGhl IGV4YW1wbGUsIEkgd291bGQgcmVjb21tZW5kIHRoYXQgZmlyc3QNCg0KPiAgICAgICAgICAgICAg ICAgNSBiYWNrc3BhY2VzIGVyYXNlICJzb3JyeSIsIG5leHQgYmFja3NwYWNlIGVyYXNlcyB0aGUN Cg0KPiAgICAgICAgICAgICAgICAgbGluZSBzZXBhcmF0b3IsIGFuZCBwdWxscyBkb3duICJJIHdh aXRlZCBmb3IgeW91IiB0bw0KDQo+ICAgICAgICAgICAgICAgICBiZSBzaG93biBsYXN0LCBhcyBh biB1bmNvbXBsZXRlZCB0ZXh0LiBUaGVuIHRoZSBuZXh0IDYNCg0KPiAgICAgICAgICAgICAgICAg YmFja3NwYWNlcyBlcmFzZSBzbyB0aGF0IG9ubHkgIkkgd2FpdGVkIGYiIGlzDQoNCj4gICAgICAg ICAgICAgICAgIGRpc3BsYXllZC4gV2hlbiBBbGljZSBhZGRzIHRleHQgYW5kIGVuZCB3aXRoIGEg bmV3DQoNCj4gICAgICAgICAgICAgICAgIGxpbmUsIHRoZSBjb3JyZWN0ZWQgc2VudGVuY2UgaXMg YWxsb3dlZCB0byBmbG93IHVwDQoNCj4gICAgICAgICAgICAgICAgIHdoZW4gbmV3IHRleHQgaXMg YWRkZWQgZnJvbSBhbnkgcGFydGljaXBhbnQuICBUaGF0DQoNCj4gICAgICAgICAgICAgICAgIGNh dXNlcyBhIGJpdCBzdHJhbmdlIG9yZGVyLCBidXQgaXQgaXMganVzdCBhcw0KDQo+ICAgICAgICAg ICAgICAgICBtYW5hZ2VhYmxlIGFzIHdoZW4gdGV4dCBpbiBtZXNzYWdpbmcgYXBwbGljYXRpb25z DQoNCj4gICAgICAgICAgICAgICAgIGFwcGVhciBpbiBhbiB1bmV4cGVjdGVkIG9yZGVyIHNvIHRo YXQgb25lIG1lc3NhZ2UNCg0KPiAgICAgICAgICAgICAgICAgc2VlbXMgdG8gYmUgYSByZXNwb25l IG9uIHNvbWV0aGluZyB0b3RhbGx5IGVsc2UgdGhhbg0KDQo+ICAgICAgICAgICAgICAgICB3aGF0 IHdhcyBpbnRlbmRlZC4NCg0KPg0KDQo+ICAgICAgICAgICAgICAgICBBIHNvcGhpc3RpY2F0ZWQg VUkgbWF5IG1hcmsgdGV4dCB0aGF0IGlzIG1vdmVkIGFuZA0KDQo+ICAgICAgICAgICAgICAgICBt b2RpZmllZC4NCg0KPg0KDQo+ICAgICAgICAgICAgICAgICBXZSB3YW50IHRvIGtlZXAgc2VudGVu Y2VzIG9yIGF0IGxlYXN0IHBocmFzZXMgZnJvbQ0KDQo+ICAgICAgICAgICAgICAgICBlYWNoIHBh cnRpY2lwYW50IHRvZ2V0aGVyIGluIGEgcmVhZGFibGUgdW5pdC4gQWxyZWFkeQ0KDQo+ICAgICAg ICAgICAgICAgICB0aGF0IGNhdXNlcyBhIGRlc2lnbiBkZWNpc2lvbiBvbiB3aGVyZSB0byBwbGFj ZSB0aGUNCg0KPiAgICAgICAgICAgICAgICAgY29tcGxldGVkIGNodW5rIG9mIHRleHQgb25jZSB0 aGUgdXNlciBoYXMgY29tcGxldGVkDQoNCj4gICAgICAgICAgICAgICAgIGl0LiBUaGUgc3RhcnQg b2YgdGhlIGNodW5rIG1heSBiZSBvbGRlciB0aGFuIGNvbXBsZXRlZA0KDQo+ICAgICAgICAgICAg ICAgICB0ZXh0IGZyb20gb3RoZXIgcGFydGljaXBhbnRzIHdoaWNoIHdvdWxkIG1vdGl2YXRlIHRv DQoNCj4gICAgICAgICAgICAgICAgIG1vdmUgaXQgdXAgYSBiaXQgaW4gdGhlIHByZXNlbnRhdGlv bi4gQnV0IHRoZSBlbmQgb2YNCg0KPiAgICAgICAgICAgICAgICAgaXQgaXMgYXQgdGhhdCBtb21l bnQgdGhlIGxhdGVzdCB0ZXh0IHRvIHByZXNlbnQuIEkNCg0KPiAgICAgICAgICAgICAgICAgdGhp bmsgaXQgaXMgYmVzdCB0byBsZXQgdGhlIGZpbmlzaGVkIHRleHQgYmUgcHJlc2VudGVkDQoNCj4g ICAgICAgICAgICAgICAgIGxhc3Qgb24gdGhlIGRpc3BsYXksIGJ1dCBsZXQgb3RoZXJzJyBuZXdl ciB0ZXh0IHB1c2gNCg0KPiAgICAgICAgICAgICAgICAgZXZlcnl0aGluZyB1cCBhbmQgYmUgZGlz cGxheWVkIGxhc3QuDQoNCj4NCg0KPg0KDQo+ICAgICAgICAgICAgICAgICBULjE0MCBoYXMgaW5m b3JtYXRpb24gb24gaG93IHRvIGhhbmRsZSBlcmFzdXJlOg0KDQo+DQoNCj4gICAgICAgICAgICAg ICAgIC0tLS0tLS0tLS0tLS0tLS0tLS1Gcm9tIFQuMTQwLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQoNCj4NCg0KPiAgICAgICAgICAgICAgICAgOC4yIEVyYXNlIGxhc3QgY2hhcmFjdGVyDQoN Cj4gICAgICAgICAgICAgICAgIFB1cnBvc2U6IEVyYXNlIHRoZSBsYXN0IGNoYXJhY3RlciBzZW50 IGZyb20gdGhlDQoNCj4gICAgICAgICAgICAgICAgIGRpc3BsYXkgYXQgdGhlIHJlY2VpdmluZyBl bmQuDQoNCj4gICAgICAgICAgICAgICAgIENvZGU6IEJTOiAwMDA4Lg0KDQo+ICAgICAgICAgICAg ICAgICBQcm9jZWR1cmU6IE9uIHRoZSByZWNlaXZpbmcgZW5kOiBNb3ZlIHRoZSBpbnNlcnRpb24N Cg0KPiAgICAgICAgICAgICAgICAgcG9pbnQgdG8gdGhlIGxhc3QgY2hhcmFjdGVyIGFuZCBlcmFz ZSBpdC4NCg0KPiAgICAgICAgICAgICAgICAgQ29tYmluZWQgY2hhcmFjdGVycyBhcmUgZXJhc2Vk IGFzIGEgdW5pdCwgd2l0aCBvbmUgQlMNCg0KPiAgICAgICAgICAgICAgICAgZXJhc2luZyB0aGUg d2hvbGUgY2hhcmFjdGVyIGV2ZW4gaWYgaXQgaXMNCg0KPiAgICAgICAgICAgICAgICAgY29tYmlu ZWQgZnJvbSBtb3JlIHRoYW4gb25lIGNvbXBvbmVudC4NCg0KPiAgICAgICAgICAgICAgICAgQ29u dHJvbCBzZXF1ZW5jZXMgKGxpa2UgQ1IgTEYpIGFyZSBlcmFzZWQgaW4gb25lDQoNCj4gICAgICAg ICAgICAgICAgIG9wZXJhdGlvbi4NCg0KPiAgICAgICAgICAgICAgICAgTk9URSDigJMgVGhlIHNh bWUgYWN0aW9uIHNoYWxsIGJlIHRha2VuIG9uIHRoZSBsb2NhbA0KDQo+ICAgICAgICAgICAgICAg ICBkaXNwbGF5Lg0KDQo+DQoNCj4gICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo+DQoNCj4gICAgICAg ICAgICAgICAgICAgL0d1bm5hcg0KDQo+DQoNCj4NCg0KPg0KDQo+ICAgICAgICAgICAgICAgICAg ICAgQnJpYW4NCg0KPg0KDQo+DQoNCj4gICAgICAgICAgICAgICAgICAgICAgICAgT24gQXVnIDI3 LCAyMDE5LCBhdCA5OjUyIEFNLCBHdW5uYXIgSGVsbHN0csO2bQ0KDQo+ICAgICAgICAgICAgICAg ICAgICAgICAgIDxndW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iuc2U8bWFpbHRvOmd1bm5hci5oZWxs c3Ryb21Ab21uaXRvci5zZT4NCg0KPiAgICAgICAgICAgICAgICAgICAgICAgICA8bWFpbHRvOmd1 bm5hci5oZWxsc3Ryb21Ab21uaXRvci5zZT48bWFpbHRvOmd1bm5hci5oZWxsc3Ryb21Ab21uaXRv ci5zZT4+DQoNCj4gICAgICAgICAgICAgICAgICAgICAgICAgd3JvdGU6DQoNCj4NCg0KPiAgICAg ICAgICAgICAgICAgICAgICAgICBIaSwNCg0KPg0KDQo+ICAgICAgICAgICAgICAgICAgICAgICAg IEEgdG9waWMgaXMgY3VycmVudGx5IGRpc2N1c3NlZCBpbiBtbXVzaWMgdGhhdA0KDQo+ICAgICAg ICAgICAgICAgICAgICAgICAgIGlzIGNsb3NlbHkgcmVsYXRlZCB0byBydW0uIGl0IGlzIFdlYlJU Qw0KDQo+ICAgICAgICAgICAgICAgICAgICAgICAgIHRyYW5zcG9ydCBvZiByZWFsLXRpbWUgdGV4 dC4NCg0KPg0KDQo+ICAgICAgICAgICAgICAgICAgICAgICAgIFRoZSBkcmFmdCBpcw0KDQo+ICAg ICAgICAgICAgICAgICAgICAgICAgIGRyYWZ0LWhvbG1iZXJnLW1tdXNpYy10MTQwLXVzYWdlLWRh dGEtY2hhbm5lbCAuDQoNCj4NCg0KPiAgICAgICAgICAgICAgICAgICAgICAgICBBIGdvb2QgcG9p bnQgdG8gc3RhcnQgcmVhZGluZyBjb3VsZCBiZToNCg0KPg0KDQo+ICAgICAgICAgICAgICAgICAg ICAgICAgIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9icm93c2UvbW11c2ljLz9n YnQ9MSZxPWRyYWZ0LWhvbG1iZXJnLW1tdXNpYy10MTQwLXVzYWdlLWRhdGEtY2hhbm5lbA0KDQo+ DQoNCj4gICAgICAgICAgICAgICAgICAgICAgICAgUGxlYXNlIGNoZWNrIGlmIHRoZSBjdXJyZW50 IHN0YXRlIG9mIHRoZQ0KDQo+ICAgICAgICAgICAgICAgICAgICAgICAgIGRpc2N1c3Npb24gc3Vp dHMgcnVtIQ0KDQo+DQoNCj4gICAgICAgICAgICAgICAgICAgICAgICAgVGhlIG9ubHkgaXNzdWUg dGhhdCBzZWVtcyB0byBiZSByZW1haW5pbmcgaXMNCg0KPiAgICAgICAgICAgICAgICAgICAgICAg ICBob3cgdG8gdHJhbnNwb3J0IFJUVCBkYXRhIHRvIGFuZCBmcm9tIGENCg0KPiAgICAgICAgICAg ICAgICAgICAgICAgICBjb25mZXJlbmNlIHNlcnZlciB0aGF0IGNvbWJpbmVzIGFsbCB0cmFmZmlj DQoNCj4gICAgICAgICAgICAgICAgICAgICAgICAgcGVyIG1lZGlhIGluIGEgbWVldGluZyBpbiBv bmUgZGF0YSBzdHJlYW0uDQoNCj4gICAgICAgICAgICAgICAgICAgICAgICAgVGhhdCBpcyBub3Qg dmVyeSBlbGVnYW50bHkgc3BlY2lmaWVkIGZvciBSRkMNCg0KPiAgICAgICAgICAgICAgICAgICAg ICAgICA0MTAzIHRyYW5zcG9ydCBvZiBSVFQgaW4gUlRQIGVpdGhlciwgc28gd2UNCg0KPiAgICAg ICAgICAgICAgICAgICAgICAgICBtaWdodCB3YW50IHRvIGRvIGEgcmFwaWQgYWN0aW9uIHRvZ2V0 aGVyIHRvDQoNCj4gICAgICAgICAgICAgICAgICAgICAgICAgc29sdmUgdGhlIG11bHRpLXBhcnR5 IFJUVCBNQ1UgY2FzZSBpbiBhDQoNCj4gICAgICAgICAgICAgICAgICAgICAgICAgZ2VuZXJhbCBh bmQgY29uc2lzdGVudCB3YXkuDQoNCj4NCg0KPiAgICAgICAgICAgICAgICAgICAgICAgICBSZWdh cmRzDQoNCj4NCg0KPiAgICAgICAgICAgICAgICAgICAgICAgICBHdW5uYXINCg0KPg0KDQo+ICAg ICAgICAgICAgICAgICAgICAgICAgIC0tDQoNCj4gICAgICAgICAgICAgICAgICAgICAgICAgLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KPiAgICAgICAgICAgICAg ICAgICAgICAgICBHdW5uYXIgSGVsbHN0csO2bQ0KDQo+ICAgICAgICAgICAgICAgICAgICAgICAg IE9tbml0b3INCg0KPiAgICAgICAgICAgICAgICAgICAgICAgICBndW5uYXIuaGVsbHN0cm9tQG9t bml0b3Iuc2U8bWFpbHRvOmd1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5zZT4NCg0KPiAgICAgICAg ICAgICAgICAgICAgICAgICA8bWFpbHRvOmd1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5zZT4NCg0K PiAgICAgICAgICAgICAgICAgICAgICAgICArNDYgNzA4IDIwNCAyODgNCg0KPg0KDQo+ICAgICAg ICAgICAgICAgICAtLQ0KDQo+ICAgICAgICAgICAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo+ICAgICAgICAgICAgICAgICBHdW5uYXIgSGVsbHN0csO2 bQ0KDQo+ICAgICAgICAgICAgICAgICBPbW5pdG9yDQoNCj4gICAgICAgICAgICAgICAgIGd1bm5h ci5oZWxsc3Ryb21Ab21uaXRvci5zZTxtYWlsdG86Z3VubmFyLmhlbGxzdHJvbUBvbW5pdG9yLnNl Pg0KDQo+ICAgICAgICAgICAgICAgICA8bWFpbHRvOmd1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5z ZT48bWFpbHRvOmd1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5zZT4NCg0KPiAgICAgICAgICAgICAg ICAgKzQ2IDcwOCAyMDQgMjg4DQoNCj4NCg0KPiAgICAgICAgIC0tDQoNCj4gICAgICAgICAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo+ICAgICAgICAgR3VubmFy IEhlbGxzdHLDtm0NCg0KPiAgICAgICAgIE9tbml0b3INCg0KPiAgICAgICAgIGd1bm5hci5oZWxs c3Ryb21Ab21uaXRvci5zZTxtYWlsdG86Z3VubmFyLmhlbGxzdHJvbUBvbW5pdG9yLnNlPiA8bWFp bHRvOmd1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5zZT4NCg0KPiAgICAgICAgICs0NiA3MDggMjA0 IDI4OA0KDQo+DQoNCj4NCg0KPiAgICAgLS0NCg0KPiAgICAgUnVtIG1haWxpbmcgbGlzdA0KDQo+ ICAgICBSdW1AaWV0Zi5vcmc8bWFpbHRvOlJ1bUBpZXRmLm9yZz4gPG1haWx0bzpSdW1AaWV0Zi5v cmc+DQoNCj4gICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnVtDQoN Cj4NCg0KPg0KDQotLQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQpHdW5uYXIgSGVsbHN0csO2bQ0KDQpPbW5pdG9yDQoNCmd1bm5hci5oZWxsc3Ryb21Ab21u aXRvci5zZTxtYWlsdG86Z3VubmFyLmhlbGxzdHJvbUBvbW5pdG9yLnNlPg0KDQorNDYgNzA4IDIw NCAyODgNCg0KDQoNCiAgKiAgIFtSdW1dIFJlYWwtdGltZSB0ZXh0IGluIFdlYlJUQyBpcyBkaXNj dXNzZWQgaW4gLi4uPGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvcnVtL2h6 WDMwTG80RFk0SjNSR2J0Z3hvQzV3cEUxcz4gIEd1bm5hciBIZWxsc3Ryw7ZtDQogICogICBSZTog W1J1bV0gUmVhbC10aW1lIHRleHQgaW4gV2ViUlRDIGlzIGRpc2N1c3NlZC4uLjxodHRwczovL21h aWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3J1bS9MazkwdzBxU3RtaUFtSG9Jd19tV0ZUT0Uz cFk+ICBCcmlhbiBSb3Nlbg0KICAqICAgUmU6IFtSdW1dIFJlYWwtdGltZSB0ZXh0IGluIFdlYlJU QyBpcyBkaXNjdXNzZWQuLi48aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9y dW0vb3B0N3VoZTNqY0NBR0VYaXBYQ2VmVk45N1BFPiAgR3VubmFyIEhlbGxzdHLDtm0NCiAgKiAg IFJlOiBbUnVtXSBSZWFsLXRpbWUgdGV4dCBpbiBXZWJSVEMgaXMgZGlzY3Vzc2VkLi4uPGh0dHBz Oi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvcnVtL3VGODNibjlHbUVrUjJGekU0cnZI LURpSm4xST4gIEJyaWFuIFJvc2VuDQogICogICBSZTogW1J1bV0gUmVhbC10aW1lIHRleHQgaW4g V2ViUlRDIGlzIGRpc2N1c3NlZC4uLjxodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gv bXNnL3J1bS82NDAycTlIektCTnF2a3dLYWpTbG80RVltTVU+ICBHdW5uYXIgSGVsbHN0csO2bQ0K ICAqICAgUmU6IFtSdW1dIFJlYWwtdGltZSB0ZXh0IGluIFdlYlJUQyBpcyBkaXNjdXNzZWQuLi48 aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9ydW0vWUcwMlR5S29uMXRSdGN0 WjFCd2UwQm5JN0N3PiAgUGF1bCBLeXppdmF0DQogICogICBSZTogW1J1bV0gW0VYVF0gUmU6IFJl YWwtdGltZSB0ZXh0IGluIFdlYlJUQyBpcy4uLjxodHRwczovL21haWxhcmNoaXZlLmlldGYub3Jn L2FyY2gvbXNnL3J1bS9VRHowSkN6eXFRMHV0OFJKeldGNTRLak1VWFk+ICBNYWxsb3ksIEppbQ0K ICAqICAgUmU6IFtSdW1dIFtFWFRdIFJlOiBSZWFsLXRpbWUgdGV4dCBpbiBXZWJSVEMgaXMuLi48 aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9ydW0vV1dla2ZBYlhDODFHRm1P ZFVsZDFZT3ZWNDUwPiAgUGF1bCBLeXppdmF0DQogICogICBSZTogW1J1bV0gUmVhbC10aW1lIHRl eHQgaW4gV2ViUlRDIGlzIGRpc2N1c3NlZC4uLjxodHRwczovL21haWxhcmNoaXZlLmlldGYub3Jn L2FyY2gvbXNnL3J1bS84TjVzV0p2cUItSjRYZ0M1eHFNQ1YybkwwZ2M+ICBCcmlhbiBSb3Nlbg0K ICAqICAgUmU6IFtSdW1dIFtFWFRdIFJlOiBSZWFsLXRpbWUgdGV4dCBpbiBXZWJSVEMgaXMuLi48 aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9ydW0vSG9EOE5pMXIwZjhTMTFI Mks0aHA2U3M1TkIwPiAgQnJpYW4gUm9zZW4NCiAgKiAgIFJlOiBbUnVtXSBbRVhUXSBSZTogUmVh bC10aW1lIHRleHQgaW4gV2ViUlRDIGlzLi4uPGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcv YXJjaC9tc2cvcnVtL2VJLWRYNEhyTVV1cjMyNEdFdC1DRm1wdjRtWT4gIFBhdWwgS3l6aXZhdA0K ICAqICAgUmU6IFtSdW1dIFtFWFRdIFJlOiBSZWFsLXRpbWUgdGV4dCBpbiBXZWJSVEMgaXMuLi48 aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9ydW0vQWFvS29nLUhodEJVU19h LUJLckI1QnB3aUY0PiAgQnJpYW4gUm9zZW4NCiAgKiAgIFJlOiBbUnVtXSBbRVhUXSBSZTogUmVh bC10aW1lIHRleHQgaW4gV2ViUlRDIGlzLi4uPGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcv YXJjaC9tc2cvcnVtLzFKb2pPdGl0Qi1GbGNtQ0hRZDlMTWw0UFdNND4gIFBhdWwgS3l6aXZhdA0K ICAqICAgUmU6IFtSdW1dIFtFWFRdIFJlOiBSZWFsLXRpbWUgdGV4dCBpbiBXZWJSVEMgaXMuLi48 aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9ydW0vMk5ERDJrTVNHbmduaDZH eW9MRDlUaF9VWXJNPiAgQnJpYW4gUm9zZW4NCiAgKiAgIFJlOiBbUnVtXSBbRVhUXSBSZTogUmVh bC10aW1lIHRleHQgaW4gV2ViUlRDIGlzLi4uPGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcv YXJjaC9tc2cvcnVtL1VaRHlLcmZPdy1iamticWpOOEUzTUhYcnNlbz4gIE1hbGxveSwgSmltDQog ICogICBSZTogW1J1bV0gW0VYVF0gUmU6IFJlYWwtdGltZSB0ZXh0IGluIFdlYlJUQyBpcy4uLjxo dHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3J1bS9hdkFTZkNjeENBWTE4Z09G c1RHRTNQNW9UT3M+ICBHdW5uYXIgSGVsbHN0csO2bQ0KDQoNCi0tDQpKb2huIE1hcnRpbg0KRW1h aWw6IEpvaG4uTWFydGluQFB1cnBsZS51czxtYWlsdG86Sm9obi5NYXJ0aW5AUHVycGxlLnVzPg0K DQo= --_000_3C2BF11C2A0D4C3BBE717E40FB2677E9contosocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6TWVubG87DQoJcGFub3NlLTE6MiAxMSA2IDkgMyA4IDQgMiAyIDQ7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJl DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt YXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uRW1haWxT dHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLUdCO30NCnAuZGVwdGgtMCwgbGkuZGVwdGgtMCwgZGl2LmRlcHRoLTANCgl7bXNvLXN0eWxl LW5hbWU6ZGVwdGgtMDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAu ZGVwdGgtMSwgbGkuZGVwdGgtMSwgZGl2LmRlcHRoLTENCgl7bXNvLXN0eWxlLW5hbWU6ZGVwdGgt MTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuZGVwdGgtMiwgbGku ZGVwdGgtMiwgZGl2LmRlcHRoLTINCgl7bXNvLXN0eWxlLW5hbWU6ZGVwdGgtMjsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuZGVwdGgtMywgbGkuZGVwdGgtMywgZGl2 LmRlcHRoLTMNCgl7bXNvLXN0eWxlLW5hbWU6ZGVwdGgtMzsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCnAuZGVwdGgtNCwgbGkuZGVwdGgtNCwgZGl2LmRlcHRoLTQNCgl7 bXNvLXN0eWxlLW5hbWU6ZGVwdGgtNDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnAuZGVwdGgtNSwgbGkuZGVwdGgtNSwgZGl2LmRlcHRoLTUNCgl7bXNvLXN0eWxlLW5h bWU6ZGVwdGgtNTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNt Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuZGVw dGgtNiwgbGkuZGVwdGgtNiwgZGl2LmRlcHRoLTYNCgl7bXNvLXN0eWxlLW5hbWU6ZGVwdGgtNjsN Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQg NzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlz dCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6OTYxNDU5Mjg7DQoJbXNv LWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE2NjQyMjIyMjYgMTM0 ODA3NTY3IDEzNDgwNzU3NyAxMzQ4MDc1NzkgMTM0ODA3NTY3IDEzNDgwNzU3NyAxMzQ4MDc1Nzkg MTM0ODA3NTY3IDEzNDgwNzU3NyAxMzQ4MDc1Nzk7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBs MDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0 ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBo YS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDot OS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBs aXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxp c3QgbDENCgl7bXNvLWxpc3QtaWQ6OTg1NTQ1NDgyOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczox ODQxNTg0MDA4O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwx OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0 Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjE3NTM3NDM1MTk7DQoJbXNvLWxpc3QtdHlwZTpoeWJy aWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNzkwMDMwMzA4IDEzNDgwNzU2NyAxMzQ4MDc1 NzcgMTM0ODA3NTc5IDEzNDgwNzU2NyAxMzQ4MDc1NzcgMTM0ODA3NTc5IDEzNDgwNzU2NyAxMzQ4 MDc1NzcgMTM0ODA3NTc5O30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEt bG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTku MHB0O30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlz dCBsMjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0 IGwyOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDgN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJv bWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0 b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij5BbGwsPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVu bG87Y29sb3I6IzIxMjUyOSI+ICZuYnNwOyQwLjAyIG9uIFJUVDo8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5s bztjb2xvcjojMjEyNTI5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5 Ij5SVFQgaW4gR2VuZXJhbDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPi0tLS0t LS0tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+SVNUTSB0aGVyZSBh cmUgYSBmZXcgb3B0aW9ucyBmb3IgUlRUIGluIFJVTSwgYXNzdW1pbmcgdGhlIFdlYlJUQyBtZWRp YSBmcmFtZXdvcmsgaXMgYWRvcHRlZCAoYXMgc2VlbXMgbGlrZWx5KTo8bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDt0ZXh0LWluZGVudDotMTgu MHB0O21zby1saXN0OmwyIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFb ZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29s b3I6IzIxMjUyOSI+VXNlIGV4aXN0aW5nIGJyb3dzZXIgc3VwcG9ydCBmb3IgU0NUUCBhcyByZWNv bW1lbmRlZCBieSB0aGUgc29tZSBvZiB0aGUgV2ViUlRDIElFVEYgV0cgcGFydGljaXBhbnRzLiBU aGlzIHdhcyBkaXNjdXNzZWQgYXMgcGFydCBvZiB0aGUgSVZDIFdHIGFuZCB3b3VsZCByZXF1aXJl IGFuZCBTQ1RQIGRhdGEgY2hhbm5lbCB0byBiZSBuZWdvdGlhdGVkIGFuZCB0byBlbmNhcHN1bGF0 ZSB0aGUgUlRQICg0MTAzKSB3aGljaCB0aGVuIGluIHR1cm4gZW5jYXBzdWxhdGUgVC4xNDAgUlRU LiBUaGlzIHNvbHV0aW9uIHdvdWxkIHJlcXVpcmUgZ2F0ZXdheXMgaW4gdGhlIFZSUyBwcm92aWRl ciBuZXR3b3JrcywgUlRQL1JUQ1AgdXNlcnNwYWNlIChKYXZhc2NyaXB0KSBsYXllcnMgaW4gdGhl IGJyb3dzZXIgYW5kIGEgVC4xNDAgUlRUIGxheWVyL1VJIGFsc28gd3JpdHRlbiBpbiB1c2Vyc3Bh Y2UgaW4gdGhlIGJyb3dzZXIuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMiBsZXZlbDEg bGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu b3JlIj4yLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPldhaXQgZm9yIFdl YlJUQyB0byBzdXBwb3J0IGxvd2VyIGxldmVsIGRhdGEgY2hhbm5lbHMuIFRoaXMgd29yayBpcyBi ZWluZyBkaXNjdXNzZWQgaW4gdGhlIFdlYlJUQyBjb21tdW5pdHksIGJ1dCBtaWdodCBiZSBhIGNh c2Ugb2Yg4oCcbm90IGhvbGRpbmcgb3VyIGJyZWF0aOKAnS4gQSBsb3dlciBsZXZlbCBkYXRhIGNo YW5uZWwgd291bGQgYWxsb3cgUlRQL1JUQ1AgdGhlbiBULjE0MCB0byBiZSBuZWdvdGlhdGVkIGlu IHRoZSBTRFAgd2l0aG91dCB0aGUgbmVlZCBmb3IgU0NUUCBhbmQgYXNzb2NpYXRlZCBnYXRld2F5 IG5lZWRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzIiPjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 TWVubG87Y29sb3I6IzIxMjUyOSI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+My48c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyA8 L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij5BcyBhIHN0b3AtZ2FwIGFuZCBzaW1w bGlmaWNhdGlvbiwgc3VwcG9ydCBTSVAgTUVTU0FHRSBhcyBhbHJlYWR5IHByb3ZpZGVkIGZvciBi eSB0aGUgYnJvd3NlcnMgYW5kIG1hbnkgZW5kcG9pbnRzLCBpbmNsdWRpbmcgV2ViUlRDIGVuZHBv aW50czxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPldlIHNob3VsZCBub3QgZm9yZ2V0IHRoYXQgUlRDUCBt dXN0IGJlIGltcGxlbWVudGVkIGFsb25nIHdpdGggUlRQLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2Nv bG9yOiMyMTI1MjkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPkNv bmZlcmVuY2luZyBhbmQgUlRUPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+LS0t LS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij5SVFQgaW4gYSBjb25mZXJlbmNl IGlzIG5vdCBjdXJyZW50bHkgZGVmaW5lZCBhbmQgZG9lcyBub3Qgd29yayB1c2luZyBjdXJyZW50 bHkgZGVmaW5lZCBzdGFuZGFyZHMgKEkgbXVzdCBhZG1pdCB0byBiZWluZyBiZWluZyBvbiBtbXVz aWMgc28gcGVyaGFwcyB0aGVyZSBhcmUgc29sdXRpb25zIGJlaW5nIHJlY29tbWVuZGVkIHRoZXJl KS4gRGlzY3Vzc2lvbnMgb24gdGhpcyBoYXZlIGJlZW4gb25nb2luZyBmb3IgbmVhcmx5IDEwIHll YXJzICh3ZSBkaWRu4oCZdCBzb2x2ZSBpdCB0aGVuIEd1bm5hciBhbmQgSSB0aGluayB0aGUgcHJv YmxlbXMgYXJlIHN0aWxsIHRoZSBzYW1lKS4gRm9yIFJUVCB0byBiZSB1c2VmdWwgaW4gYSBjb25m ZXJlbmNlIHRoZXJlIG5lZWRzIHRvIGJlIGEgZmV3IHByb2JsZW1zIHNvbHZlZC4gPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7dGV4dC1pbmRl bnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMyI+PCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEy NTI5Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xLjxzcGFuIHN0eWxlPSJmb250Ojcu MHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9z cGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1l bmxvO2NvbG9yOiMyMTI1MjkiPk11bHRpLXN0cmVhbSBzdXBwb3J0OiBCcmlhbiwgd2hpbHN0IHlv deKAmXJlIHJpZ2h0IHRoYXQgbW9zdCBjb25mZXJlbmNlIHN5c3RlbXMgYXJlIHBvaW50LXRvLXBv aW50IGZvciBzaWduYWxsaW5nIHRoZXkgYXJlIG1vcmUgdHlwaWNhbGx5IHBvaW50LXRvLW11bHRp LXBvaW50IGZvciBtZWRpYS4gVGhlIGNvbmZlcmVuY2UgYnJpZGdlIHVzdWFsbHkgaGFuZGxlcyB0 aGUgbXVsdGlwbGV4aW5nIG9mIHRoZSBzdHJlYW1zLCBidXQgdGhleSBhcmUgdXN1YWxseSBub3cg bXVsdGlwbGUgc3RyZWFtcy4gUlRUIGNvbmZlcmVuY2luZyBuZWVkcyB0byBoYXZlIHRoZSBzYW1l IHN1cHBvcnQuIFdlIHNob3VsZCBhc3N1bWUgY29uZmVyZW5jaW5nIGlzIHN1cHBvcnRlZCBieSB3 YXkgb2YgU0ZVIG5vdCBNQ1Ug4oCTIHRoYXTigJlzIGhvdyBXZWJSVEMgaGFuZGxlcyBjb25mZXJl bmNpbmcgYW5kIHdlIHNob3VsZCBhc3N1bWUgdGhlIHNhbWUgZm9yIFJUVC48bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDt0ZXh0LWluZGVudDot MTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8zIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1Mjki PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+ PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87 Y29sb3I6IzIxMjUyOSI+UGFydGljaXBhbnQgaWRlbnRpZmljYXRpb246IHN0cmVhbXMgZnJvbSB0 aGUgY29uZmVyZW5jZSBicmlkZ2UgKE1DVS9TRlUpIG11c3QgYmUgdGFnZ2VkIHdpdGggdGhlIHNl bmRlciBzbyB0aGUgVUkgY2FuIHNpZ25hbCB0byB0aGUgdXNlciB3aG8gc2VudCB0aGF0IHRleHQg KGFuZCByZWNvbnN0cnVjdCB0aGUgc3RyZWFtIGNvcnJlY3RseSkuPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBw dDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMyI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij48c3Bh biBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4zLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9y OiMyMTI1MjkiPlVJIGFkYXB0aW9uczogTW9kZXJuIFdlYlJUQyBiYXNlZCBtdWx0aS1wYXJ0eSBj b25mZXJlbmNlcyBoYXZlIGFkYXB0ZWQgVUlzIHRvIGRpc3BsYXkgbXVsdGlwbGUgdmlkZW8gc3Ry ZWFtcy4gVUnigJlzIGFyZSBhZGFwdGVkIHRvIHNob3cgdGhlIHZpZGVvIHBhcnRpY2lwYW50cyBo b3dldmVyIHRoZSB1c2VyIHdhbnRzIHRoZW0gdG8gYmUgZGlzcGxheWVkIChzaW5nbGUgZnVsbCBz Y3JlZW4sIHRpbGVkLCB2b2ljZSBhY3RpdmF0ZWQgZXRjKS4gV2Ugc2hvdWxkIGV4cGVjdCBubyBs ZXNzIGZyb20gUlRUIGNvbmZlcmVuY2UgZW5hYmxlZCBlbmRwb2ludHMuIEl0IHNob3VsZCBiZSBh IHVzZXIgZGVjaXNpb24gKGlmIHRoZWlyIFVJIHN1cHBvcnRzIGl0KSBhcyB0byB3aGV0aGVyIHRo ZXkgc2VlIGxpbmUtYnktbGluZSBvciBSVFQgcmVuZGVyaW5nIG9mIHRoZSB0ZXh0IGNvbnZlcnNh dGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8zIj48IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1l bmxvO2NvbG9yOiMyMTI1MjkiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjQuPHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsgPC9z cGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Q29udHJvbCBvZiBob3cgbWFueSBzaW11 bHRhbmVvdXMgcGFydGljaXBhbnRzIGNhbiB0ZXh0IGFuZCBob3cgdGhhdCBpcyBwcmVzZW50ZWQg dG8gdGhlIHVzZXIgbmVlZHMgdG8gYmUgZXhwbG9yZWQuIE11bHRpcGxlIGluc2VydGlvbiBwb2lu dHMgaW4gdGhlIFVJIGlzIG9uZSBhcHByb2FjaCAodGhvdWdoIHJhcGlkbHkgYnJlYWtzIGRvd24g YXMgdGhlIG51bWJlciBvZiB1c2VycyBpbmNyZWFzZXMpLiBMaW5lLWJ5LWxpbmUgaXMgYW5vdGhl ci4gRmFjaWxpdGF0ZWQgR0EgaXMgYW5vdGhlciAodGhlIEdvIEFoZWFkIGNvbmNlcHQgaGFzIGJl ZW4gdXNlZCBmb3IgYSBsb25nIHRpbWUgaW4gdGV4dCBjb252ZXJzYXRpb25zIGFuZCBtYXkgYmUg YXBwcm9wcmlhdGUgaW4gbGFyZ2UgUlRUIGNvbmZlcmVuY2VzIHRvIGNvbnRyb2wgb3ZlcmxvYWQp LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPkFuZCBhIGZpbmFsIEZXSVc6IEkgdGhpbmsgdGhlIHV0aWxp dHkgb2YgUlRUIGluIGEgY29uZmVyZW5jZSBxdWlja2x5IGJyZWFrcyBkb3duIGFzIHRoZSBudW1i ZXIgb2YgcGFydGljaXBhbnRzIGluY3JlYXNlcy4gSXQgaXMgY29tcGxldGVseSB1bmFjY2VwdGFi bGUgdG8gaGF2ZSBhIHNpbmdsZSBSVFQgc3RyZWFtIHByZXNlbnRlZCB0byB0aGUgdXNlciBhbmQg YW4gdW5tb2RpZmllZCBVSS4gWW91IG1pZ2h0IGFzIHdlbGwgcmV2ZXJ0IHRvIFNJUCBNRVNTQUdF IGFuZCBzb21ldGhpbmcgbGlrZSBYTVBQLCBhbmQgdGhhdCBjb3VsZCBhbHNvIGJlIGFuIG9wdGlv biBmb3IgZWl0aGVyIHRoZSBzaG9ydCB0ZXJtIG9yIGZvciBlbmRwb2ludHMgdGhhdCBkbyBub3Qg c3VwcG9ydCBtdWx0aS1zdHJlYW0gUlRULjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1 MjkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPkpvaG48bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztj b2xvcjojMjEyNTI5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij5CcmlhbiBzYWlkOiB3ZSBh Z3JlZWQgd2Ugd2VyZSB1c2luZyA0MTAzIGluIFJVTS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xv cjojMjEyNTI5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij5Hb29k IHRva25vdy4gQnV0IGlzIHRoZXJlIG5vdCBhIGhvcGUgdG8gYmUgYWJsZSB0byBldmVuIHVzZSBi cm93c2VyIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPnRlY2hub2xvZ3kgZm9y IHRoZSBpbXBsZW1lbnRhdGlvbi4gVGhlIGJyb3dzZXJzIG9ubHkgc3VwcG9ydCBSVFAgZm9yIDxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPmF1ZGlvIGFuZCB2aWRlby4gQ2FuIHlv dSBtYWtlIFJUUC1iYXNlZCBSVFQgd29yayBpbiB0aGF0IGVudmlyb25tZW50IGFuZCA8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij5lbmNyeXB0ZWQgd2l0aCB0aGUgc2VjdXJpdHkg bWV0aG9kIHNwZWNpZmllZCBmb3IgV2ViUlRDPzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMy MTI1MjkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPlNlZSBhIGJp dCBtb3JlIGJlbG93OjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPkRlbiAyMDE5LTA4LTI5IGtsLiAyMTo1 OSwgc2tyZXYgTWFsbG95LCBKaW06PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyDigJxsaW5lIGF0 IGEgdGltZeKAnSBpcyBhIHVzZXIgaW50ZXJmYWNlIGlzc3VlIOKAkyBSVU0gaXMgZGVmaW5pbmcg YSBtYWNoaW5lIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsgaW50ZXJm YWNlLiZuYnNwOyBIb3cgaXTigJlzIHByZXNlbnRlZCB0byB0aGUgdXNlciBpcyBvdXQgb2Ygc2Nv cGUuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OzxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPldlbGwsIHRoZSBjb250cm9sIGFuZCBjb2Rpbmcg bXVzdCBiZSBtYWRlIHNvIHRoYXQgaXQgaXMgcG9zc2libGUgdG8gbWFrZSA8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTpNZW5sbztjb2xvcjojMjEyNTI5Ij5hIGdvb2QgcHJlc2VudGF0aW9uLiBUcmFuc21pc3Npb24g b25seSBsaW5lLWJ5LWxpbmUgd291bGQgbm90IHN1aXQgdGhlIDxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxv O2NvbG9yOiMyMTI1MjkiPmludGVudGlvbiBvZiBSVFQuIEl0IGlzIGhhcmQgdG8gbWFrZSBhIGdv b2QgUlRUIHByZXNlbnRhdGlvbiB3aXRoIGEgPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIx MjUyOSI+Y2xpZW50IHRoYXQgaXMgb25seSBleHBlY3RpbmcgdGV4dCBmcm9tIG9uZSBvdGhlciBw YXJ0aWNpcGFudCBhbmQgYSA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij5taXhl ciB0aGF0IGhhcyB0aGUgdGFzayB0byBzZW5kIHRleHQgZnJvbSBtYW55IHNvdXJjZXMgY29tYmlu ZWQgaW4gb25lIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPnN0cmVhbS4gVGhl IGJlc3QgcmVzdWx0IGlzIHVzYWJsZSBidXQgbm90IG5pY2UuIEFuZCBpdCB3aWxsIGJlIGFpbWVk IGF0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPmp1c3Qgb25lIHdheSB0byBw cmVzZW50IFJUVC4gTm8gZnJlZWRvbSB0byBwbGFuIHRoZSBwcmVzZW50YXRpb24gPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+YWNjb3JkaW5nIHRvIHVzZXIgcHJlZmVyZW5jZXMu PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 TWVubG87Y29sb3I6IzIxMjUyOSI+QSByZWNlaXZlciBtYXksIGlmIHRoZXJlIGlzIGEgZGVzaXJl IGZvciBzdWNoIGZ1bmN0aW9uYWxpdHksIHN0b3JlIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9y OiMyMTI1MjkiPnJlY2VpdmVkIHRleHQgdW50aWwgYSByZWNlaXZlZCBtZXNzYWdlIGlzIGNvbXBs ZXRlLiBJIGRvIG5vdCB0aGluayB0aGF0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1 MjkiPml0IGlzIHRvIHByZWZlciBpbiBhbnkgc2l0dWF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxv O2NvbG9yOiMyMTI1MjkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1Mjki PlJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij5HdW5uYXI8bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztj b2xvcjojMjEyNTI5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4m Z3Q7IC0tSmltPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OzxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsgKkZyb206KiBSdW0gJmx0Ozxh IGhyZWY9Im1haWx0bzpydW0tYm91bmNlc0BpZXRmLm9yZyZhbXA7Z3QiPjxzcGFuIHN0eWxlPSJj b2xvcjojMzM3QUI3Ij5ydW0tYm91bmNlc0BpZXRmLm9yZyZndDs8L3NwYW4+PC9hPjsgKk9uIEJl aGFsZiBPZiAqIEJyaWFuIFJvc2VuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+ Jmd0OyAqU2VudDoqIFRodXJzZGF5LCBBdWd1c3QgMjksIDIwMTkgMToxNSBQTTxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsgKlRvOiogS3l6aXZhdCwgUGF1bCAmbHQ7PGEg aHJlZj0ibWFpbHRvOnBreXppdmF0QGFsdW0ubWl0LmVkdSZhbXA7Z3QiPjxzcGFuIHN0eWxlPSJj b2xvcjojMzM3QUI3Ij5wa3l6aXZhdEBhbHVtLm1pdC5lZHUmZ3Q7PC9zcGFuPjwvYT47PG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyAqQ2M6KiA8YSBocmVmPSJtYWlsdG86 cnVtQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6IzMzN0FCNyI+cnVtQGlldGYub3JnPC9z cGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7ICpTdWJqZWN0 OiogW0VYVF0gUmU6IFtSdW1dIFJlYWwtdGltZSB0ZXh0IGluIFdlYlJUQyBpcyBkaXNjdXNzZWQg aW4gPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyBtbXVzaWMgLSBhIHRv cGljIGNsb3NlbHkgdGVsYXRlZCB0byBydW08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEy NTI5Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyDi gJxMaW5lIGF0IGEgdGltZeKAnSBjb3VsZCBiZSBhbiBpbXBsZW1lbnRhdGlvbiBvcHRpb24uICZu YnNwO1RoZSBwcm90b2NvbCA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7 IG1lY2hhbmlzbSBpcyBhbGwgc3RyZWFtcyBoZWFkIHRvIGEgbWl4ZXIgYW5kIHRoZSBtaXhlciBz ZW5kcyBhIHNpbmdsZSA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7IHN0 cmVhbSB0byBlYWNoIHBhcnRpY2lwYW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1 MjkiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7IEd1 bm5hciwgd2UgYWdyZWVkIHdlIHdlcmUgdXNpbmcgNDEwMyBpbiBSVU0uPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9y OiMyMTI1MjkiPiZndDsgQnJpYW48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4m Z3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OzxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9uIEF1 ZyAyOSwgMjAxOSwgYXQgMTI6MDUgUE0sIFBhdWwgS3l6aXZhdCAmbHQ7PGEgaHJlZj0ibWFpbHRv OnBreXppdmF0QGFsdW0ubWl0LmVkdSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMzMzdBQjciPnBreXpp dmF0QGFsdW0ubWl0LmVkdTwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIx MjUyOSI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbHQ7bWFpbHRvOnBreXppdmF0QGFs dW0ubWl0LmVkdSZndDsmZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1 MjkiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgcXVlc3Rpb24gaG93IHdlbGwgUlRUIHRleHQgaXMgc3Vp dGVkIHRvIG11bHRpcGFydHkgY29uZmVyZW5jZXMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6 IzIxMjUyOSI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSWYgeW91IGhhdmUgbWVzc2FnZXMgb24geW91ciBz Y3JlZW4gZnJvbSBtdWx0aXBsZSBwYXJ0aWVzLCBhbmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xv cjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1hbnkgb2YgdGhlbSBhcmUg dXBkYXRpbmcgaW4gcmVhbC10aW1lLCBhcmUgeW91IGdvaW5nIHRvIGJlIGFibGU8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRv IHBlcmNlaXZlIHdoYXQgaXMgZ29pbmcgb24/PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIx MjUyOSI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQW5kIHdoaWxlIHlvdSBjYW4gaGF2ZSBhIGNvbHVtbiBw ZXIgcGVyc29uIGZvciB0d28tcGFydHkgYW5kIG1heWJlPG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29s b3I6IzIxMjUyOSI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAzLXBhcnR5IGNvbnZlcnNh dGlvbnMsIHRoYXQgZG9lc24ndCBzY2FsZSB1cC4gV2l0aCBtYW55IHBhcnRpZXMsPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBz b21lIHR5cGluZyBtYXkgc2Nyb2xsIG9mZiB0aGUgc2NyZWVuIGJlZm9yZSBpdCBpcyBjb21wbGV0 ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQ ZXJoYXBzIGZvciBjb25mZXJlbmNlcyBpdCBpcyBiZXR0ZXIgdG8ganVzdCB1c2UgbGluZS1hdC1h LXRpbWU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGNoYXQuIElmIG5lY2Vzc2FyeSwgSSBwcmVzdW1lIHRoZXJlIGNvdWxkIGJl IGdhdGV3YXlzIGJldHdlZW4gUlRUPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+ Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhbmQgY2hhdC4gQSBSVUUgY291bGQgaGF2ZSB0 aGUgY2FwYWJpbGl0eSB0byBuZWdvdGlhdGUgZG93biBmcm9tPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87 Y29sb3I6IzIxMjUyOSI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSVFQgdG8gY2hhdC48 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGFu a3MsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBQYXVsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0Ozxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgT24gOC8yOC8xOSAyOjE1IEFNLCBHdW5uYXIgSGVsbHN0csO2bSB3cm90ZTo8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBEZW4gMjAxOS0wOC0yNyBrbC4gMjM6MTUsIHNrcmV2IEJyaWFu IFJvc2VuOjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDs8bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEF0IGxl YXN0IGJ5IGNlbnRyYWxpemluZyB0aGUgcHJvYmxlbSBhdCBhIOKAnG1peGVy4oCdLCBBbGljZTxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YW5k IEJvYiB3aWxsIHNlZSB0aGUgc2FtZSB0aGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjoj MjEyNTI5Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBZb3UgZG9u4oCZdCBoYXZlIHRoZSBwcm9ibGVtIGluIEluc3RhbnQg TWVzc2FnaW5nLCBiZWNhdXNlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB5b3UgY2Fu4oCZdCBiYWNrc3BhY2Ugb3IgZGVsZXRlIGEgc2VudCBt ZXNzYWdlLiAmbmJzcDtPZiBjb3Vyc2U8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5 Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlmIG11bHRpcGxlIHBlb3BsZSBhcmUgdHlwaW5nIHNpbXVs dGFuZW91c2x5IGluIHN1Y2g8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO3N5c3RlbXMsIG1lc3NhZ2Ugb3JkZXIgd2lsbCBiZSBjb25mdXNpbmcg aW4gdGhhdCBpbnN0YW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDs8 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJpZ2h0LCBpdCBpcyBhIHNpbWls YXIga2luZCBvZiBwcm9ibGVtIHRoYXQgdGV4dCBhcHBlYXJzIGluIGFuPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB1bmV4cGVjdGVkIG9yZGVyLiBUaGVyZSBpcyBhbHNvIGF0IGxlYXN0 IG9uZSBpbnN0YW50IG1lc3NhZ2luZzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1Mjki PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2Vy dmljZSB0aGF0IGFsbG93cyBtb2RpZmljYXRpb24gaW4gYWxyZWFkeSBzZW50IG1lc3NhZ2UuIEJ1 dDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSSB0aGluayBpdCBoYXMgbGltaXRhdGlv bnMgdG8gb25seSBhY2NlcHQgdGhhdCBpbiB0aGUgbGFzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2Nv bG9yOiMyMTI1MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgbWVzc2FnZSBzZW50LiBpdCBpcyBjb252ZW5pZW50IGFueXdheS48bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87 Y29sb3I6IzIxMjUyOSI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1 MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQW55d2F5LCB3ZSBuZWVkIHRvIHNwZWNpZnkgdGhlIG1p eGVyIGZvciBSVFQgc28gaXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHJlY2VpdmVzIGVhY2ggb2YgdGhlIFJUVCBzdHJlYW1zIGFuZCBwcm9k dWNlcyBhIHNpbmdsZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgY29tcG9zaXRlIHN0cmVhbSBmb3IgZWFjaCBwYXJ0aWNpcGFudC48bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVu bG87Y29sb3I6IzIxMjUyOSI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBZZXMsIHJpZ2h0LCBhbmQgdGhlcmUgaXMgYW4gZWZmb3J0IGluIHRoYXQg ZGlyZWN0aW9uIGluOjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0 cDovL3d3dy5yZWFsdGltZXRleHQub3JnL3NpdGVzL2RlZmF1bHQvZmlsZXMvRmlsZXNfYW5kX0Rv Y3VtZW50cy9TcGVjaWZpY2F0aW9ucy9tdWx0aXBhcnR5LXJlYWwtdGltZS10ZXh0LW1peGVyLTIw MTEtMDQtMzAucGRmIj48c3BhbiBzdHlsZT0iY29sb3I6IzMzN0FCNyI+aHR0cDovL3d3dy5yZWFs dGltZXRleHQub3JnL3NpdGVzL2RlZmF1bHQvZmlsZXMvRmlsZXNfYW5kX0RvY3VtZW50cy9TcGVj aWZpY2F0aW9ucy9tdWx0aXBhcnR5LXJlYWwtdGltZS10ZXh0LW1peGVyLTIwMTEtMDQtMzAucGRm PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEl0IGlzIHdyaXR0ZW4g Zm9yIGNvbmZlcmVuY2UtdW5hd2FyZSB1c2VyIGRldmljZXMuPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87 Y29sb3I6IzIxMjUyOSI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBUaGUgZ29hbHMgYXJlIHNwZWNpZmllZCBhcyBmb2xsb3dzOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIHByb2NlZHVyZXMgYXJlIGludGVuZGVkIHRvIG1ha2Ug YmVzdCBlZmZvcnRzIHRvIHByZXNlbnQgYTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1 MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg bXVsdGktcGFydHkgdGV4dCBjb252ZXJzYXRpb24gb24gYSB0ZXJtaW5hbCB0aGF0IGhhcyBubzxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXdhcmVuZXNzIG9mIG11bHRpLXBhcnR5IGNh bGxzLiBUaGVyZSBhcmUgc29tZSBvYnZpb3VzPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIx MjUyOSI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBkcmF3YmFja3MsIGFuZCBhIHRlcm1pbmFsIGRlc2lnbmVkIHdpdGggbXVsdGktcGFydHkgYXdh cmVuZXNzPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB3aWxsIGJlIGFibGUgdG8gcHJl c2VudCBtdWx0aS1wYXJ0eSBjYWxsIGNvbnRlbnRzIGluIGEgbW9yZTxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1l bmxvO2NvbG9yOiMyMTI1MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgZmxleGlibGUgd2F5LiBPbmx5IHR3byBwYXJ0aWVzIGF0IGEgdGltZSB3 aWxsIGJlIGFsbG93ZWQgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRpc3BsYXkg YWRkZWQgdGV4dCBpbiByZWFsLXRpbWUsIHdoaWxlIHRoZSBvdGhlciBwYXJ0aWVz4oCZPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwcm9kdWNlZCB0ZXh0IHdpbGwgbmVlZCB0byBiZSBz dG9yZWQgaW4gdGhlIG11bHRpLXBhcnR5IHNlcnZlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9y OiMyMTI1MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgZm9yIGEgbW9tZW50IGF3YWl0aW5nIGEgc3VpdGFibGUgb2NjYXNpb24gdG8gYmUgZGlz cGxheWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlcmUgYXJlIGFsc28gc29t ZSBjYXNlcyBvZiBlcmFzdXJlIHRoYXQgd2lsbCBub3QgYmU8bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztj b2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHBlcmZvcm1lZCBvbiB0aGUgdGFyZ2V0IHRleHQgYnV0IG9ubHkgaW5kaWNhdGVk IGluIGFub3RoZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdheS4gRXZlbiB3aXRo IHRoZXNlIGRyYXdiYWNrcywgdGhlIHByb2NlZHVyZSBwcm92aWRlcyBhbjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgb3Bwb3J0dW5pdHkgdG8gZGlzcGxheSB0ZXh0IGZyb20gbW9yZSB0 aGFuIHR3byBwYXJ0aWVzIGluIGE8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4m Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3Ntb290 aCBhbmQgcmVhZGFibGUgd2F5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87 Y29sb3I6IzIxMjUyOSI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBJIHNlZSBzdWNoIG1peGVyIHByb2NlZHVyZXMgYXMgYSBmYWxsLWJhY2sgZm9y IGNhc2VzIHdpdGhvdXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbmZlcmVuY2Ug YXdhcmVuZXNzLCBidXQgd2FudCB0byBzZWUgc3VwcG9ydCBmb3I8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5s bztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGNvbmZlcmVuY2UtYXdhcmUgdGVybWluYWxzLCB3aGVyZSB0ZXh0IGZyb20g bW9yZSB0aGFuIHR3bzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcGFydGllcyBjYW4g YmUgcHJlc2VudGVkIGluIHJlYWwtdGltZSwgYW5kIHRoZSBlbmQgdXNlciBvciBhcHA8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNhbiBoYXZlIGluZmx1ZW5jZSBvdmVyIHRoZSBwcmVz ZW50YXRpb24gc3R5bGUgLSBlLmcuIHNlbGVjdDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMy MTI1MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgYmV0d2VlbiB0aGUgbXVsdGlwbGUgY29sdW1uIHZpZXcgYW5kIHRoZTxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgb25lLWNvbHVtbi13aXRoLWxhYmVscyB2aWV3LiZuYnNwOyBBIG1p eGVyIGZvciB0aGF0IGNhc2Ugd291bGQgb25seTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMy MTI1MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgbmVlZCB0byBhc3N1cmUgdGhhdCB0aGUgcmVjZWl2ZXIgaGFzIHRoZSByaWdodCBraW5kIG9m PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDttdWx0aS1wYXJ0eSBhd2FyZW5lc3MgYW5k IHNlbmQgUlRUIHRleHQgd2l0aCBzb3VyY2U8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEy NTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGluZm9ybWF0aW9uIGF0dGFjaGVkLCBhbmQgbGV0IHRoZSByZWNlaXZpbmcgdGVybWluYWwgc29y dCBvdXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBwcmVzZW50YXRpb24uIFRo aXMgaXMgYWxyZWFkeSBwb3NzaWJsZSB3aXRoIENTUkMgYW5kIENOQU1FPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB3aGVuIHVzaW5nIFJUUCwgYnV0IHdlIGxvc2UgdGhhdCBwb3NzaWJp bGl0eSBuYXRpdmVseSB3aGVuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1c2luZyB0 aGUgV2ViUlRDIGRhdGEgY2hhbm5lbCB0byB0cmFuc3BvcnQgUlRULCBhbmQgd291bGQgbmVlZDxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdG8gc3BlY2lmeSBhIHdheSB0byBpbmNsdWRl IHRoZSBzb3VyY2UgYWxzbyBmb3IgdGhhdCBjYXNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9y OiMyMTI1MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBCeSB0aGUgd2F5LCB3aGF0IGlzIHlv dXIgY3VycmVudCB2aWV3IG9mIGhvdyB0byB0cmFuc3BvcnQgUlRUPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVu bG87Y29sb3I6IzIxMjUyOSI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBmb3IgUlVNLCBub3cgd2hlbiB5b3Ugc2F5IHRoYXQgeW91IHdpbGwgdXNl IFdlYlJUQyB0cmFuc3BvcnRzPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBmb3IgbWVk aWE/PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZWdhcmRzPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBHdW5uYXI8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5 Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OzxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDs8bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IE9uIEF1ZyAyNywgMjAxOSwgYXQgNDo0MyBQTSwgR3VubmFyIEhlbGxzdHLD tm08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJtYWlsdG86Z3VubmFyLmhlbGxz dHJvbUBvbW5pdG9yLnNlIj48c3BhbiBzdHlsZT0iY29sb3I6IzMzN0FCNyI+Z3VubmFyLmhlbGxz dHJvbUBvbW5pdG9yLnNlPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEy NTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDttYWls dG86Z3VubmFyLmhlbGxzdHJvbUBvbW5pdG9yLnNlJmd0OyZsdDttYWlsdG86Z3VubmFyLmhlbGxz dHJvbUBvbW5pdG9yLnNlJmd0OyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5 Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdyb3RlOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpN ZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IERlbiAyMDE5LTA4LTI3IGtsLiAyMTo0OCwgc2tyZXYgQnJpYW4gUm9zZW46PG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1l bmxvO2NvbG9yOiMyMTI1MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIHByb2JsZW0gb2YgY29uZmVyZW5jZSA0 MTAzIFJUVCBpcyBoaWdoIG9uIG15PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+ Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBsaXN0IG9mIHdvcmsgSSBuZWVkIHRvIGdldCBkb25lLiAmbmJzcDtTbywgSeKA mW08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1vdGl2YXRl ZCB0byBoZWxwIG91dC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGFua3MsIGdyZWF0LjxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1l bmxvO2NvbG9yOiMyMTI1MjkiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjoj MjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBiYXNpYyBwcm9ibGVtIGlzIHRoYXQgd2XigJlyZSBnb2lu ZyB0byBnZXQgdmVyeTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgaW5jb25zaXN0ZW50IFVJIGRvaW5nIGl0IHRoYXQgd2F5LCBiZWNhdXNlIG9mIGhvdzxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3lzdGVtcyB3aWxsIGhh bmRsZSBiYWNrc3BhY2Ugb2Ygb25lIHBhcnR5IHRoYXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xv cjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGV4dGVuZHMgYmV5b25kIHJlc3BvbnNlcyBmcm9tIG90aGVy IHBhcnRpZXM6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OzxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgKHdlbGwsIGZvciBtZSB0aGUgY3VycmVudGx5IG1vc3QgYmFz aWMgcHJvYmxlbSBpcyB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaGF2ZSBhIHJlbGlhYmxlIHdh eSB0byBhcHBlbmQgcmVjZWl2ZWQgdGV4dCB0byB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xv cjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFs cmVhZHkgcHJlc2VudGVkIHRleHQgb2YgdGhlIHJpZ2h0IHBhcnRpY2lwYW50LiBBbmQ8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHRoYXQgaXMgZ2V0dGluZyB3b3JzZSBpbiBXZWJSVEMgdGhhbiBpdCB3 YXMgaW4gUkZDPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA0MTAzLiBCdXQgd2Ugd2lsbCBzb3J0IGl0 IG91dC4pPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OzxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpN ZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFsaWNlOiBJIHdhaXRlZCBmb3IgeW91PG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBCb2I6IEkgZGlkbuKA mXQgc2VlIHlvdTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg QWxpY2U6IHNvcnJ5PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OzxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQW5kIHRoZW4g QWxpY2UgdHlwZXMgMTIgYmFja3NwYWNlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEy NTI5Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBXaGF0IHNob3VsZCBoYXBwZW4/PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUy OSI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDs8bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFlvdSBhcmUgcmlnaHQgdGhhdCB0aGVyZSBhcmUgYSBu dW1iZXIgb2Ygd2F5cyB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaGFuZGxlIHRoZSBSVFQgVUku IEFuZCBqdXN0IGFzIGluY29uc2lzdGVuY2llcyBhcmU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xv cjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNv bW1vbiB3aXRoIGEgbWVzc2FnZSBvcmllbnRlZCBVSSwgd2hlcmUgbWVzc2FnZXMgc2hvdzxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgdXAgaW4gYSBjb25mdXNpbmcgb3JkZXIgYmVjYXVzZSB0d28gdXNl cnMgY29tcGxldGVkPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtZXNzYWdlcyBpbiBhbiB1bmV4cGVj dGVkIHRpbWUgb3JkZXIsIGl0IGlzIHBvc3NpYmxlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6 IzIxMjUyOSI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGF0 IFJUVCB0ZXh0IGdldHMgZGlzcGxheWVkIGluIGEgc3RyYW5nZSBvcmRlciBhZnRlcjxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgZXJhc3VyZSBhbmQgcmV0eXBpbmcuIEl0IGlzIGJldHRlciBmb3IgUlRU IHRoYW4gZm9yPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtZXNzYWdlIG9yaWVudGVkIHByZXNlbnRh dGlvbiwgYW5kIHVzZXIgZ2V0IHVzZWQgdG8gaXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjoj MjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluIGJv dGggY2FzZXMuJm5ic3A7IFdpdGggdGhlIGxhYmVsbGVkIHN0eWxlIGluIG9uZSBjb2x1bW48bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHlvdSBoYXZlIGluIHRoZSBleGFtcGxlLCBJIHdvdWxkIHJlY29t bWVuZCB0aGF0IGZpcnN0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA1IGJhY2tzcGFjZXMgZXJhc2Ug JnF1b3Q7c29ycnkmcXVvdDssIG5leHQgYmFja3NwYWNlIGVyYXNlcyB0aGU8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGxpbmUgc2VwYXJhdG9yLCBhbmQgcHVsbHMgZG93biAmcXVvdDtJIHdhaXRlZCBm b3IgeW91JnF1b3Q7IHRvPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBiZSBzaG93biBsYXN0LCBhcyBh biB1bmNvbXBsZXRlZCB0ZXh0LiBUaGVuIHRoZSBuZXh0IDY8bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztj b2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGJhY2tzcGFjZXMgZXJhc2Ugc28gdGhhdCBvbmx5ICZxdW90O0kgd2FpdGVkIGYmcXVvdDsgaXM8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRpc3BsYXllZC4gV2hlbiBBbGljZSBhZGRzIHRleHQgYW5k IGVuZCB3aXRoIGEgbmV3PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBsaW5lLCB0aGUgY29ycmVjdGVk IHNlbnRlbmNlIGlzIGFsbG93ZWQgdG8gZmxvdyB1cDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9y OiMyMTI1MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7d2hl biBuZXcgdGV4dCBpcyBhZGRlZCBmcm9tIGFueSBwYXJ0aWNpcGFudC4mbmJzcDsgVGhhdDxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgY2F1c2VzIGEgYml0IHN0cmFuZ2Ugb3JkZXIsIGJ1dCBpdCBpcyBq dXN0IGFzPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtYW5hZ2VhYmxlIGFzIHdoZW4gdGV4dCBpbiBt ZXNzYWdpbmcgYXBwbGljYXRpb25zPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+ Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhcHBlYXIgaW4gYW4g dW5leHBlY3RlZCBvcmRlciBzbyB0aGF0IG9uZSBtZXNzYWdlPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87 Y29sb3I6IzIxMjUyOSI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBzZWVtcyB0byBiZSBhIHJlc3BvbmUgb24gc29tZXRoaW5nIHRvdGFsbHkgZWxzZSB0aGFuPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB3aGF0IHdhcyBpbnRlbmRlZC48bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5s bztjb2xvcjojMjEyNTI5Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIx MjUyOSI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBIHNvcGhp c3RpY2F0ZWQgVUkgbWF5IG1hcmsgdGV4dCB0aGF0IGlzIG1vdmVkIGFuZDxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgbW9kaWZpZWQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0 OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgV2Ugd2FudCB0byBrZWVwIHNlbnRlbmNlcyBv ciBhdCBsZWFzdCBwaHJhc2VzIGZyb208bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5 Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVhY2ggcGFydGlj aXBhbnQgdG9nZXRoZXIgaW4gYSByZWFkYWJsZSB1bml0LiBBbHJlYWR5PG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB0aGF0IGNhdXNlcyBhIGRlc2lnbiBkZWNpc2lvbiBvbiB3aGVyZSB0byBwbGFjZSB0 aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbXBsZXRlZCBjaHVuayBvZiB0ZXh0IG9uY2UgdGhl IHVzZXIgaGFzIGNvbXBsZXRlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaXQuIFRoZSBzdGFydCBv ZiB0aGUgY2h1bmsgbWF5IGJlIG9sZGVyIHRoYW4gY29tcGxldGVkPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVu bG87Y29sb3I6IzIxMjUyOSI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB0ZXh0IGZyb20gb3RoZXIgcGFydGljaXBhbnRzIHdoaWNoIHdvdWxkIG1vdGl2YXRlIHRv PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtb3ZlIGl0IHVwIGEgYml0IGluIHRoZSBwcmVzZW50YXRp b24uIEJ1dCB0aGUgZW5kIG9mPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpdCBpcyBhdCB0aGF0IG1v bWVudCB0aGUgbGF0ZXN0IHRleHQgdG8gcHJlc2VudC4gSTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2Nv bG9yOiMyMTI1MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg dGhpbmsgaXQgaXMgYmVzdCB0byBsZXQgdGhlIGZpbmlzaGVkIHRleHQgYmUgcHJlc2VudGVkPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBsYXN0IG9uIHRoZSBkaXNwbGF5LCBidXQgbGV0IG90aGVycycg bmV3ZXIgdGV4dCBwdXNoPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBldmVyeXRoaW5nIHVwIGFuZCBi ZSBkaXNwbGF5ZWQgbGFzdC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7 PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OzxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7VC4xNDAgaGFzIGluZm9ybWF0aW9uIG9uIGhvdyB0byBoYW5kbGUg ZXJhc3VyZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAtLS0tLS0tLS0tLS0tLS0tLS0tRnJvbSBULjE0MC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZn dDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDguMiBFcmFzZSBsYXN0IGNoYXJhY3Rlcjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgUHVycG9zZTogRXJhc2UgdGhlIGxhc3QgY2hhcmFjdGVyIHNl bnQgZnJvbSB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7 Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2Rpc3BsYXkgYXQgdGhlIHJlY2Vpdmlu ZyBlbmQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBDb2RlOiBCUzogMDAwOC48bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFByb2NlZHVyZTogT24gdGhlIHJlY2VpdmluZyBlbmQ6IE1vdmUgdGhlIGluc2Vy dGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcG9pbnQgdG8gdGhlIGxhc3QgY2hhcmFjdGVyIGFu ZCBlcmFzZSBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENvbWJpbmVkIGNoYXJhY3RlcnMgYXJl IGVyYXNlZCBhcyBhIHVuaXQsIHdpdGggb25lIEJTPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6 IzIxMjUyOSI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlcmFz aW5nIHRoZSB3aG9sZSBjaGFyYWN0ZXIgZXZlbiBpZiBpdCBpczxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxv O2NvbG9yOiMyMTI1MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgY29tYmluZWQgZnJvbSBtb3JlIHRoYW4gb25lIGNvbXBvbmVudC48bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpN ZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IENvbnRyb2wgc2VxdWVuY2VzIChsaWtlIENSIExGKSBhcmUgZXJhc2VkIGluIG9uZTxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgb3BlcmF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9y OiMyMTI1MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTk9U RSDigJMgVGhlIHNhbWUgYWN0aW9uIHNoYWxsIGJlIHRha2VuIG9uIHRoZSBsb2NhbDxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgZGlzcGxheS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5 Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5s bztjb2xvcjojMjEyNTI5Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIx MjUyOSI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsg L0d1bm5hcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDs8bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9y OiMyMTI1MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgQnJpYW48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEy NTI5Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0Ozxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgT24gQXVnIDI3LCAyMDE5LCBhdCA5OjUyIEFNLCBHdW5uYXIgSGVs bHN0csO2bTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Im1haWx0bzpndW5uYXIuaGVsbHN0cm9t QG9tbml0b3Iuc2UiPjxzcGFuIHN0eWxlPSJjb2xvcjojMzM3QUI3Ij5ndW5uYXIuaGVsbHN0cm9t QG9tbml0b3Iuc2U8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1Mjki PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O21haWx0bzpndW5uYXIuaGVs bHN0cm9tQG9tbml0b3Iuc2UmZ3Q7Jmx0O21haWx0bzpndW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iu c2UmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsmbmJzcDsm bmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7d3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6 IzIxMjUyOSI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSGksPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87 Y29sb3I6IzIxMjUyOSI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1 MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQSB0b3BpYyBpcyBjdXJyZW50 bHkgZGlzY3Vzc2VkIGluIG1tdXNpYyB0aGF0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIx MjUyOSI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpcyBjbG9zZWx5IHJlbGF0 ZWQgdG8gcnVtLiBpdCBpcyBXZWJSVEM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5 Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRyYW5zcG9ydCBvZiByZWFsLXRp bWUgdGV4dC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBUaGUgZHJhZnQgaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5 Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRyYWZ0LWhvbG1iZXJnLW1tdXNp Yy10MTQwLXVzYWdlLWRhdGEtY2hhbm5lbCAuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIx MjUyOSI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQSBnb29kIHBvaW50IHRvIHN0YXJ0IHJlYWRp bmcgY291bGQgYmU6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OzxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNo L2Jyb3dzZS9tbXVzaWMvP2didD0xJmFtcDtxPWRyYWZ0LWhvbG1iZXJnLW1tdXNpYy10MTQwLXVz YWdlLWRhdGEtY2hhbm5lbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMzMzdBQjciPmh0dHBzOi8vbWFp bGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9icm93c2UvbW11c2ljLz9nYnQ9MSZhbXA7cT1kcmFmdC1o b2xtYmVyZy1tbXVzaWMtdDE0MC11c2FnZS1kYXRhLWNoYW5uZWw8L3NwYW4+PC9hPjxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5s bztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFBsZWFz ZSBjaGVjayBpZiB0aGUgY3VycmVudCBzdGF0ZSBvZiB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztj b2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2Rpc2N1c3Np b24gc3VpdHMgcnVtITxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDs8bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFRoZSBvbmx5IGlzc3VlIHRoYXQgc2VlbXMgdG8gYmUgcmVtYWluaW5n IGlzPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBob3cgdG8gdHJhbnNwb3J0IFJUVCBkYXRhIHRvIGFuZCBmcm9tIGE8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGNvbmZlcmVuY2Ugc2VydmVyIHRoYXQgY29tYmluZXMgYWxsIHRyYWZmaWM8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwO3BlciBtZWRpYSBpbiBhIG1lZXRpbmcgaW4gb25lIGRhdGEgc3RyZWFtLjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgVGhhdCBpcyBub3QgdmVyeSBlbGVnYW50bHkgc3BlY2lmaWVkIGZvciBSRkM8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDQxMDMgdHJhbnNwb3J0IG9mIFJUVCBpbiBSVFAgZWl0aGVyLCBzbyB3ZTxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgbWlnaHQgd2FudCB0byBkbyBhIHJhcGlkIGFjdGlvbiB0b2dldGhlciB0bzxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgc29sdmUgdGhlIG11bHRpLXBhcnR5IFJUVCBNQ1UgY2FzZSBpbiBhPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBnZW5lcmFsIGFuZCBjb25zaXN0ZW50IHdheS48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztj b2xvcjojMjEyNTI5Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUy OSI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZWdhcmRzPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2Nv bG9yOiMyMTI1MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgR3VubmFyPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 LS08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBHdW5uYXIgSGVsbHN0csO2bTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9y OiMyMTI1MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT21uaXRvcjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJm5ic3A7PGEgaHJlZj0ibWFpbHRvOmd1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5zZSI+PHNw YW4gc3R5bGU9ImNvbG9yOiMzMzdBQjciPmd1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5zZTwvc3Bh bj48L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7bWFpbHRvOmd1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5z ZSZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7NDYgNzA4IDIwNCAyODg8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5s bztjb2xvcjojMjEyNTI5Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIx MjUyOSI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLTxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEd1bm5hciBIZWxsc3Ryw7ZtPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBPbW5pdG9yPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+Jmd0OyZu YnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJtYWlsdG86Z3Vu bmFyLmhlbGxzdHJvbUBvbW5pdG9yLnNlIj48c3BhbiBzdHlsZT0iY29sb3I6IzMzN0FCNyI+Z3Vu bmFyLmhlbGxzdHJvbUBvbW5pdG9yLnNlPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztj b2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZsdDttYWlsdG86Z3VubmFyLmhlbGxzdHJvbUBvbW5pdG9yLnNlJmd0OyZsdDttYWlsdG86Z3Vu bmFyLmhlbGxzdHJvbUBvbW5pdG9yLnNlJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMy MTI1MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0Mzs0 NiA3MDggMjA0IDI4ODxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDs8bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87 Y29sb3I6IzIxMjUyOSI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgR3VubmFyIEhlbGxzdHLDtm08bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9tbml0b3I8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEy NTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNw OzxhIGhyZWY9Im1haWx0bzpndW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iuc2UiPjxzcGFuIHN0eWxl PSJjb2xvcjojMzM3QUI3Ij5ndW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iuc2U8L3NwYW4+PC9hPiAm bHQ7bWFpbHRvOmd1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5zZSZndDs8bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpN ZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICYjNDM7NDYgNzA4IDIwNCAyODg8bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztj b2xvcjojMjEyNTI5Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUy OSI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgLS08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5 Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJ1bSBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOzxh IGhyZWY9Im1haWx0bzpSdW1AaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjojMzM3QUI3Ij5S dW1AaWV0Zi5vcmc8L3NwYW4+PC9hPiAmbHQ7bWFpbHRvOlJ1bUBpZXRmLm9yZyZndDs8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNw OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnVtIj48c3Bh biBzdHlsZT0iY29sb3I6IzMzN0FCNyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9ydW08L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPiZn dDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mZ3Q7PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+LS0gPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87 Y29sb3I6IzIxMjUyOSI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij5HdW5uYXIgSGVsbHN0csO2bTxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPk9tbml0b3I8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5s bztjb2xvcjojMjEyNTI5Ij48YSBocmVmPSJtYWlsdG86Z3VubmFyLmhlbGxzdHJvbUBvbW5pdG9y LnNlIj48c3BhbiBzdHlsZT0iY29sb3I6IzMzN0FCNyI+Z3VubmFyLmhlbGxzdHJvbUBvbW5pdG9y LnNlPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5Ij4mIzQzOzQ2 IDcwOCAyMDQgMjg4PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wcmU+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9ImRlcHRo LTAiIHN0eWxlPSJjb2xvcjojMjEyNTI5O21zby1saXN0OmwxIGxldmVsMSBsZm8xO2JveC1zaXpp bmc6IGJvcmRlci1ib3giPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6TWVubG8iPjxhIGhyZWY9Imh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cv cnVtL2h6WDMwTG80RFk0SjNSR2J0Z3hvQzV3cEUxcyI+PHNwYW4gc3R5bGU9ImNvbG9yOiMzMzdB QjciPltSdW1dIFJlYWwtdGltZSB0ZXh0IGluIFdlYlJUQyBpcyBkaXNjdXNzZWQgaW4gLi4uPC9z cGFuPjwvYT4mbmJzcDsmbmJzcDtHdW5uYXIgSGVsbHN0csO2bTxvOnA+PC9vOnA+PC9zcGFuPjwv bGk+PGxpIGNsYXNzPSJkZXB0aC0xIiBzdHlsZT0iY29sb3I6IzIxMjUyOTttc28tbGlzdDpsMSBs ZXZlbDEgbGZvMTtib3gtc2l6aW5nOiBib3JkZXItYm94Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvIj48YSBocmVmPSJodHRwczovL21haWxhcmNoaXZl LmlldGYub3JnL2FyY2gvbXNnL3J1bS9MazkwdzBxU3RtaUFtSG9Jd19tV0ZUT0UzcFkiPjxzcGFu IHN0eWxlPSJjb2xvcjojMzM3QUI3Ij5SZTogW1J1bV0gUmVhbC10aW1lIHRleHQgaW4gV2ViUlRD IGlzIGRpc2N1c3NlZC4uLjwvc3Bhbj48L2E+Jm5ic3A7Jm5ic3A7QnJpYW4gUm9zZW48bzpwPjwv bzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iZGVwdGgtMiIgc3R5bGU9ImNvbG9yOiMyMTI1Mjk7 bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzE7Ym94LXNpemluZzogYm9yZGVyLWJveCI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpNZW5sbyI+PGEgaHJlZj0iaHR0cHM6 Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9ydW0vb3B0N3VoZTNqY0NBR0VYaXBYQ2Vm Vk45N1BFIj48c3BhbiBzdHlsZT0iY29sb3I6IzMzN0FCNyI+UmU6IFtSdW1dIFJlYWwtdGltZSB0 ZXh0IGluIFdlYlJUQyBpcyBkaXNjdXNzZWQuLi48L3NwYW4+PC9hPiZuYnNwOyZuYnNwO0d1bm5h ciBIZWxsc3Ryw7ZtPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9ImRlcHRoLTMiIHN0 eWxlPSJjb2xvcjojMjEyNTI5O21zby1saXN0OmwxIGxldmVsMSBsZm8xO2JveC1zaXppbmc6IGJv cmRlci1ib3giPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6TWVu bG8iPjxhIGhyZWY9Imh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvcnVtL3VG ODNibjlHbUVrUjJGekU0cnZILURpSm4xSSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMzMzdBQjciPlJl OiBbUnVtXSBSZWFsLXRpbWUgdGV4dCBpbiBXZWJSVEMgaXMgZGlzY3Vzc2VkLi4uPC9zcGFuPjwv YT4mbmJzcDsmbmJzcDtCcmlhbiBSb3NlbjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNz PSJkZXB0aC00IiBzdHlsZT0iY29sb3I6IzIxMjUyOTttc28tbGlzdDpsMSBsZXZlbDEgbGZvMTti b3gtc2l6aW5nOiBib3JkZXItYm94Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5Ok1lbmxvIj48YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2Fy Y2gvbXNnL3J1bS82NDAycTlIektCTnF2a3dLYWpTbG80RVltTVUiPjxzcGFuIHN0eWxlPSJjb2xv cjojMzM3QUI3Ij5SZTogW1J1bV0gUmVhbC10aW1lIHRleHQgaW4gV2ViUlRDIGlzIGRpc2N1c3Nl ZC4uLjwvc3Bhbj48L2E+Jm5ic3A7Jm5ic3A7R3VubmFyIEhlbGxzdHLDtm08bzpwPjwvbzpwPjwv c3Bhbj48L2xpPjxsaSBjbGFzcz0iZGVwdGgtNSIgc3R5bGU9ImNvbG9yOiMyMTI1Mjk7bXNvLWxp c3Q6bDEgbGV2ZWwxIGxmbzE7Ym94LXNpemluZzogYm9yZGVyLWJveCI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpNZW5sbyI+PGEgaHJlZj0iaHR0cHM6Ly9tYWls YXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9ydW0vWUcwMlR5S29uMXRSdGN0WjFCd2UwQm5JN0N3 Ij48c3BhbiBzdHlsZT0iY29sb3I6IzMzN0FCNyI+UmU6IFtSdW1dIFJlYWwtdGltZSB0ZXh0IGlu IFdlYlJUQyBpcyBkaXNjdXNzZWQuLi48L3NwYW4+PC9hPiZuYnNwOyZuYnNwO1BhdWwgS3l6aXZh dDxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJkZXB0aC01IiBzdHlsZT0iY29sb3I6 IzIxMjUyOTttc28tbGlzdDpsMSBsZXZlbDEgbGZvMTtib3gtc2l6aW5nOiBib3JkZXItYm94Ij4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvIj48YSBocmVm PSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3J1bS9VRHowSkN6eXFRMHV0 OFJKeldGNTRLak1VWFkiPjxzcGFuIHN0eWxlPSJjb2xvcjojMzM3QUI3Ij5SZTogW1J1bV0gW0VY VF0gUmU6IFJlYWwtdGltZSB0ZXh0IGluIFdlYlJUQyBpcy4uLjwvc3Bhbj48L2E+Jm5ic3A7Jm5i c3A7TWFsbG95LCBKaW08bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iZGVwdGgtNiIg c3R5bGU9ImNvbG9yOiMyMTI1Mjk7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzE7Ym94LXNpemluZzog Ym9yZGVyLWJveCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpN ZW5sbyI+PGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9ydW0v V1dla2ZBYlhDODFHRm1PZFVsZDFZT3ZWNDUwIj48c3BhbiBzdHlsZT0iY29sb3I6IzMzN0FCNyI+ UmU6IFtSdW1dIFtFWFRdIFJlOiBSZWFsLXRpbWUgdGV4dCBpbiBXZWJSVEMgaXMuLi48L3NwYW4+ PC9hPiZuYnNwOyZuYnNwO1BhdWwgS3l6aXZhdDxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNs YXNzPSJkZXB0aC02IiBzdHlsZT0iY29sb3I6IzIxMjUyOTttc28tbGlzdDpsMSBsZXZlbDEgbGZv MTtib3gtc2l6aW5nOiBib3JkZXItYm94Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5Ok1lbmxvIj48YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3Jn L2FyY2gvbXNnL3J1bS84TjVzV0p2cUItSjRYZ0M1eHFNQ1YybkwwZ2MiPjxzcGFuIHN0eWxlPSJj b2xvcjojMzM3QUI3Ij5SZTogW1J1bV0gUmVhbC10aW1lIHRleHQgaW4gV2ViUlRDIGlzIGRpc2N1 c3NlZC4uLjwvc3Bhbj48L2E+Jm5ic3A7Jm5ic3A7QnJpYW4gUm9zZW48bzpwPjwvbzpwPjwvc3Bh bj48L2xpPjxsaSBjbGFzcz0iZGVwdGgtNiIgc3R5bGU9ImNvbG9yOiMyMTI1Mjk7bXNvLWxpc3Q6 bDEgbGV2ZWwxIGxmbzE7Ym94LXNpemluZzogYm9yZGVyLWJveCI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpNZW5sbyI+PGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJj aGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9ydW0vSG9EOE5pMXIwZjhTMTFIMks0aHA2U3M1TkIwIj48 c3BhbiBzdHlsZT0iY29sb3I6IzMzN0FCNyI+UmU6IFtSdW1dIFtFWFRdIFJlOiBSZWFsLXRpbWUg dGV4dCBpbiBXZWJSVEMgaXMuLi48L3NwYW4+PC9hPiZuYnNwOyZuYnNwO0JyaWFuIFJvc2VuPG86 cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9ImRlcHRoLTYiIHN0eWxlPSJjb2xvcjojMjEy NTI5O21zby1saXN0OmwxIGxldmVsMSBsZm8xO2JveC1zaXppbmc6IGJvcmRlci1ib3giPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6TWVubG8iPjxhIGhyZWY9Imh0 dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvcnVtL2VJLWRYNEhyTVV1cjMyNEdF dC1DRm1wdjRtWSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMzMzdBQjciPlJlOiBbUnVtXSBbRVhUXSBS ZTogUmVhbC10aW1lIHRleHQgaW4gV2ViUlRDIGlzLi4uPC9zcGFuPjwvYT4mbmJzcDsmbmJzcDtQ YXVsIEt5eml2YXQ8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iZGVwdGgtNiIgc3R5 bGU9ImNvbG9yOiMyMTI1Mjk7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzE7Ym94LXNpemluZzogYm9y ZGVyLWJveCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpNZW5s byI+PGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9ydW0vQWFv S29nLUhodEJVU19hLUJLckI1QnB3aUY0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzMzN0FCNyI+UmU6 IFtSdW1dIFtFWFRdIFJlOiBSZWFsLXRpbWUgdGV4dCBpbiBXZWJSVEMgaXMuLi48L3NwYW4+PC9h PiZuYnNwOyZuYnNwO0JyaWFuIFJvc2VuPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9 ImRlcHRoLTYiIHN0eWxlPSJjb2xvcjojMjEyNTI5O21zby1saXN0OmwxIGxldmVsMSBsZm8xO2Jv eC1zaXppbmc6IGJvcmRlci1ib3giPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6TWVubG8iPjxhIGhyZWY9Imh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJj aC9tc2cvcnVtLzFKb2pPdGl0Qi1GbGNtQ0hRZDlMTWw0UFdNNCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMzMzdBQjciPlJlOiBbUnVtXSBbRVhUXSBSZTogUmVhbC10aW1lIHRleHQgaW4gV2ViUlRDIGlz Li4uPC9zcGFuPjwvYT4mbmJzcDsmbmJzcDtQYXVsIEt5eml2YXQ8bzpwPjwvbzpwPjwvc3Bhbj48 L2xpPjxsaSBjbGFzcz0iZGVwdGgtNiIgc3R5bGU9ImNvbG9yOiMyMTI1Mjk7bXNvLWxpc3Q6bDEg bGV2ZWwxIGxmbzE7Ym94LXNpemluZzogYm9yZGVyLWJveCI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTpNZW5sbyI+PGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2 ZS5pZXRmLm9yZy9hcmNoL21zZy9ydW0vMk5ERDJrTVNHbmduaDZHeW9MRDlUaF9VWXJNIj48c3Bh biBzdHlsZT0iY29sb3I6IzMzN0FCNyI+UmU6IFtSdW1dIFtFWFRdIFJlOiBSZWFsLXRpbWUgdGV4 dCBpbiBXZWJSVEMgaXMuLi48L3NwYW4+PC9hPiZuYnNwOyZuYnNwO0JyaWFuIFJvc2VuPG86cD48 L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9ImRlcHRoLTYiIHN0eWxlPSJjb2xvcjojMjEyNTI5 O21zby1saXN0OmwxIGxldmVsMSBsZm8xO2JveC1zaXppbmc6IGJvcmRlci1ib3giPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6TWVubG8iPjxhIGhyZWY9Imh0dHBz Oi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvcnVtL1VaRHlLcmZPdy1iamticWpOOEUz TUhYcnNlbyI+PHNwYW4gc3R5bGU9ImNvbG9yOiMzMzdBQjciPlJlOiBbUnVtXSBbRVhUXSBSZTog UmVhbC10aW1lIHRleHQgaW4gV2ViUlRDIGlzLi4uPC9zcGFuPjwvYT4mbmJzcDsmbmJzcDtNYWxs b3ksIEppbTxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJkZXB0aC02IiBzdHlsZT0i Y29sb3I6IzIxMjUyOTttc28tbGlzdDpsMSBsZXZlbDEgbGZvMTtiYWNrZ3JvdW5kOiNGNEY1RjU7 Ym94LXNpemluZzogYm9yZGVyLWJveDtiYWNrZ3JvdW5kLXBvc2l0aW9uOmluaXRpYWwgaW5pdGlh bDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFsIGluaXRpYWwiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6TWVubG8iPjxhIGhyZWY9Imh0dHBzOi8vbWFpbGFyY2hp dmUuaWV0Zi5vcmcvYXJjaC9tc2cvcnVtL2F2QVNmQ2N4Q0FZMThnT0ZzVEdFM1A1b1RPcyI+PHNw YW4gc3R5bGU9ImNvbG9yOiMzMzdBQjciPlJlOiBbUnVtXSBbRVhUXSBSZTogUmVhbC10aW1lIHRl eHQgaW4gV2ViUlRDIGlzLi4uPC9zcGFuPjwvYT4mbmJzcDsmbmJzcDtHdW5uYXIgSGVsbHN0csO2 bTxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPi0tJm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0Ii PkpvaG4gTWFydGluPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLUdCIj5FbWFpbDombmJzcDs8YSBocmVmPSJtYWlsdG86Sm9obi5NYXJ0 aW5AUHVycGxlLnVzIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5Kb2huLk1hcnRpbkBQdXJw bGUudXM8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_3C2BF11C2A0D4C3BBE717E40FB2677E9contosocom_-- From nobody Fri Aug 30 08:12:56 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE770120982 for ; Fri, 30 Aug 2019 08:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I_gInVODmIOl for ; Fri, 30 Aug 2019 08:12:50 -0700 (PDT) Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88BBB12087B for ; Fri, 30 Aug 2019 08:12:50 -0700 (PDT) Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x7UFClIc007561 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 30 Aug 2019 11:12:47 -0400 To: John Martin , "rum@ietf.org" References: <3C2BF11C-2A0D-4C3B-BE71-7E40FB2677E9@contoso.com> From: Paul Kyzivat Message-ID: Date: Fri, 30 Aug 2019 11:12:47 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <3C2BF11C-2A0D-4C3B-BE71-7E40FB2677E9@contoso.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rum] [EXT] Re: Real-time text in WebRTC is discussed in mmusic - a topic closely telated to rum X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 15:12:55 -0000 John, On 8/30/19 7:32 AM, John Martin wrote: > All, > >  $0.02 on RTT: Thanks for joining in! I don't have much knowledge of (and no experience using) RTT so I will mostly watch from the sidelines as long as others join in. Thanks, Paul (BTW, I don't know how you formatted your message, but in my mail reader (Thunderbird) none of your lines wrapped, requiring horizontal scrolling to read them.) > RTT in General > > -------------- > > ISTM there are a few options for RTT in RUM, assuming the WebRTC media > framework is adopted (as seems likely): > > 1.Use existing browser support for SCTP as recommended by the some of > the WebRTC IETF WG participants. This was discussed as part of the IVC > WG and would require and SCTP data channel to be negotiated and to > encapsulate the RTP (4103) which then in turn encapsulate T.140 RTT. > This solution would require gateways in the VRS provider networks, > RTP/RTCP userspace (Javascript) layers in the browser and a T.140 RTT > layer/UI also written in userspace in the browser. > > 2.Wait for WebRTC to support lower level data channels. This work is > being discussed in the WebRTC community, but might be a case of “not > holding our breath”. A lower level data channel would allow RTP/RTCP > then T.140 to be negotiated in the SDP without the need for SCTP and > associated gateway needs. > > 3.As a stop-gap and simplification, support SIP MESSAGE as already > provided for by the browsers and many endpoints, including WebRTC endpoints > > We should not forget that RTCP must be implemented along with RTP. > > Conferencing and RTT > > -------------------- > > RTT in a conference is not currently defined and does not work using > currently defined standards (I must admit to being being on mmusic so > perhaps there are solutions being recommended there). Discussions on > this have been ongoing for nearly 10 years (we didn’t solve it then > Gunnar and I think the problems are still the same). For RTT to be > useful in a conference there needs to be a few problems solved. > > 1.Multi-stream support: Brian, whilst you’re right that most conference > systems are point-to-point for signalling they are more typically > point-to-multi-point for media. The conference bridge usually handles > the multiplexing of the streams, but they are usually now multiple > streams. RTT conferencing needs to have the same support. We should > assume conferencing is supported by way of SFU not MCU – that’s how > WebRTC handles conferencing and we should assume the same for RTT. > > 2.Participant identification: streams from the conference bridge > (MCU/SFU) must be tagged with the sender so the UI can signal to the > user who sent that text (and reconstruct the stream correctly). > > 3.UI adaptions: Modern WebRTC based multi-party conferences have adapted > UIs to display multiple video streams. UI’s are adapted to show the > video participants however the user wants them to be displayed (single > full screen, tiled, voice activated etc). We should expect no less from > RTT conference enabled endpoints. It should be a user decision (if their > UI supports it) as to whether they see line-by-line or RTT rendering of > the text conversation. > > 4.Control of how many simultaneous participants can text and how that is > presented to the user needs to be explored. Multiple insertion points in > the UI is one approach (though rapidly breaks down as the number of > users increases). Line-by-line is another. Facilitated GA is another > (the Go Ahead concept has been used for a long time in text > conversations and may be appropriate in large RTT conferences to control > overload). > > And a final FWIW: I think the utility of RTT in a conference quickly > breaks down as the number of participants increases. It is completely > unacceptable to have a single RTT stream presented to the user and an > unmodified UI. You might as well revert to SIP MESSAGE and something > like XMPP, and that could also be an option for either the short term or > for endpoints that do not support multi-stream RTT. > > John > > Brian said: we agreed we were using 4103 in RUM. > > Good toknow. But is there not a hope to be able to even use browser > > technology for the implementation. The browsers only support RTP for > > audio and video. Can you make RTP-based RTT work in that environment and > > encrypted with the security method specified for WebRTC? > > See a bit more below: > > Den 2019-08-29 kl. 21:59, skrev Malloy, Jim: > >> “line at a time” is a user interface issue – RUM is defining a machine > >> interface.  How it’s presented to the user is out of scope. > >> > > Well, the control and coding must be made so that it is possible to make > > a good presentation. Transmission only line-by-line would not suit the > > intention of RTT. It is hard to make a good RTT presentation with a > > client that is only expecting text from one other participant and a > > mixer that has the task to send text from many sources combined in one > > stream. The best result is usable but not nice. And it will be aimed at > > just one way to present RTT. No freedom to plan the presentation > > according to user preferences. > > A receiver may, if there is a desire for such functionality, store > > received text until a received message is complete. I do not think that > > it is to prefer in any situation. > > Regards > > Gunnar > >> --Jim > >> > >> *From:* Rum ; *On Behalf Of * > Brian Rosen > >> *Sent:* Thursday, August 29, 2019 1:15 PM > >> *To:* Kyzivat, Paul ; > >> *Cc:* rum@ietf.org > >> *Subject:* [EXT] Re: [Rum] Real-time text in WebRTC is discussed in > >> mmusic - a topic closely telated to rum > >> > >> “Line at a time” could be an implementation option.  The protocol > >> mechanism is all streams head to a mixer and the mixer sends a single > >> stream to each participant. > >> > >> Gunnar, we agreed we were using 4103 in RUM. > >> > >> Brian > >> > >> > >> > >>     On Aug 29, 2019, at 12:05 PM, Paul Kyzivat > >>     > wrote: > >> > >>     I question how well RTT text is suited to multiparty conferences. > >> > >>     If you have messages on your screen from multiple parties, and > >>     many of them are updating in real-time, are you going to be able > >>     to perceive what is going on? > >> > >>     And while you can have a column per person for two-party and maybe > >>     3-party conversations, that doesn't scale up. With many parties, > >>     some typing may scroll off the screen before it is complete. > >> > >>     Perhaps for conferences it is better to just use line-at-a-time > >>     chat. If necessary, I presume there could be gateways between RTT > >>     and chat. A RUE could have the capability to negotiate down from > >>     RTT to chat. > >> > >>     Thanks, > >>     Paul > >> > >>     On 8/28/19 2:15 AM, Gunnar Hellström wrote: > >> > >>         Den 2019-08-27 kl. 23:15, skrev Brian Rosen: > >> > >>             At least by centralizing the problem at a “mixer”, Alice > >>             and Bob will see the same thing. > >> > >>             You don’t have the problem in Instant Messaging, because > >>             you can’t backspace or delete a sent message.  Of course > >>             if multiple people are typing simultaneously in such > >>             systems, message order will be confusing in that instant. > >> > >>         Right, it is a similar kind of problem that text appears in an > >>         unexpected order. There is also at least one instant messaging > >>         service that allows modification in already sent message. But > >>         I think it has limitations to only accept that in the last > >>         message sent. it is convenient anyway. > >> > >> > >>             Anyway, we need to specify the mixer for RTT so it > >>             receives each of the RTT streams and produces a single > >>             composite stream for each participant. > >> > >>         Yes, right, and there is an effort in that direction in: > >> http://www.realtimetext.org/sites/default/files/Files_and_Documents/Specifications/multiparty-real-time-text-mixer-2011-04-30.pdf > >>         It is written for conference-unaware user devices. > >>         The goals are specified as follows: > >>         The procedures are intended to make best efforts to present a > >>         multi-party text conversation on a terminal that has no > >>         awareness of multi-party calls. There are some obvious > >>         drawbacks, and a terminal designed with multi-party awareness > >>         will be able to present multi-party call contents in a more > >>         flexible way. Only two parties at a time will be allowed to > >>         display added text in real-time, while the other parties’ > >>         produced text will need to be stored in the multi-party server > >>         for a moment awaiting a suitable occasion to be displayed. > >>         There are also some cases of erasure that will not be > >>         performed on the target text but only indicated in another > >>         way. Even with these drawbacks, the procedure provides an > >>         opportunity to display text from more than two parties in a > >>         smooth and readable way. > >>         --------------------------------------------------------------------------------------------------- > >>         I see such mixer procedures as a fall-back for cases without > >>         conference awareness, but want to see support for > >>         conference-aware terminals, where text from more than two > >>         parties can be presented in real-time, and the end user or app > >>         can have influence over the presentation style - e.g. select > >>         between the multiple column view and the > >>         one-column-with-labels view.  A mixer for that case would only > >>         need to assure that the receiver has the right kind of > >>         multi-party awareness and send RTT text with source > >>         information attached, and let the receiving terminal sort out > >>         the presentation. This is already possible with CSRC and CNAME > >>         when using RTP, but we lose that possibility natively when > >>         using the WebRTC data channel to transport RTT, and would need > >>         to specify a way to include the source also for that case. > >>         ------------------------------------------------------ > >>         By the way, what is your current view of how to transport RTT > >>         for RUM, now when you say that you will use WebRTC transports > >>         for media? > >>         Regards > >>         Gunnar > >> > >> > >> > >>                 On Aug 27, 2019, at 4:43 PM, Gunnar Hellström > >>                 > >>                 > > >>                 wrote: > >> > >>                 Den 2019-08-27 kl. 21:48, skrev Brian Rosen: > >> > >>                     The problem of conference 4103 RTT is high on my > >>                     list of work I need to get done.  So, I’m > >>                     motivated to help out. > >> > >>                 Thanks, great. > >> > >>                     The basic problem is that we’re going to get very > >>                     inconsistent UI doing it that way, because of how > >>                     systems will handle backspace of one party that > >>                     extends beyond responses from other parties: > >> > >>                 (well, for me the currently most basic problem is to > >>                 have a reliable way to append received text to the > >>                 already presented text of the right participant. And > >>                 that is getting worse in WebRTC than it was in RFC > >>                 4103. But we will sort it out.) > >> > >> > >>                     Alice: I waited for you > >>                     Bob: I didn’t see you > >>                     Alice: sorry > >> > >>                     And then Alice types 12 backspaces. > >> > >>                     What should happen? > >> > >> > >>                 You are right that there are a number of ways to > >>                 handle the RTT UI. And just as inconsistencies are > >>                 common with a message oriented UI, where messages show > >>                 up in a confusing order because two users completed > >>                 messages in an unexpected time order, it is possible > >>                 that RTT text gets displayed in a strange order after > >>                 erasure and retyping. It is better for RTT than for > >>                 message oriented presentation, and user get used to it > >>                 in both cases.  With the labelled style in one column > >>                 you have in the example, I would recommend that first > >>                 5 backspaces erase "sorry", next backspace erases the > >>                 line separator, and pulls down "I waited for you" to > >>                 be shown last, as an uncompleted text. Then the next 6 > >>                 backspaces erase so that only "I waited f" is > >>                 displayed. When Alice adds text and end with a new > >>                 line, the corrected sentence is allowed to flow up > >>                 when new text is added from any participant.  That > >>                 causes a bit strange order, but it is just as > >>                 manageable as when text in messaging applications > >>                 appear in an unexpected order so that one message > >>                 seems to be a respone on something totally else than > >>                 what was intended. > >> > >>                 A sophisticated UI may mark text that is moved and > >>                 modified. > >> > >>                 We want to keep sentences or at least phrases from > >>                 each participant together in a readable unit. Already > >>                 that causes a design decision on where to place the > >>                 completed chunk of text once the user has completed > >>                 it. The start of the chunk may be older than completed > >>                 text from other participants which would motivate to > >>                 move it up a bit in the presentation. But the end of > >>                 it is at that moment the latest text to present. I > >>                 think it is best to let the finished text be presented > >>                 last on the display, but let others' newer text push > >>                 everything up and be displayed last. > >> > >> > >>                 T.140 has information on how to handle erasure: > >> > >>                 -------------------From T.140--------------------------- > >> > >>                 8.2 Erase last character > >>                 Purpose: Erase the last character sent from the > >>                 display at the receiving end. > >>                 Code: BS: 0008. > >>                 Procedure: On the receiving end: Move the insertion > >>                 point to the last character and erase it. > >>                 Combined characters are erased as a unit, with one BS > >>                 erasing the whole character even if it is > >>                 combined from more than one component. > >>                 Control sequences (like CR LF) are erased in one > >>                 operation. > >>                 NOTE – The same action shall be taken on the local > >>                 display. > >> > >>                 ------------------------------------------------------------ > >> > >>                   /Gunnar > >> > >> > >> > >>                     Brian > >> > >> > >>                         On Aug 27, 2019, at 9:52 AM, Gunnar Hellström > >>                         > >>                         > > >>                         wrote: > >> > >>                         Hi, > >> > >>                         A topic is currently discussed in mmusic that > >>                         is closely related to rum. it is WebRTC > >>                         transport of real-time text. > >> > >>                         The draft is > >>                         draft-holmberg-mmusic-t140-usage-data-channel . > >> > >>                         A good point to start reading could be: > >> > >> https://mailarchive.ietf.org/arch/browse/mmusic/?gbt=1&q=draft-holmberg-mmusic-t140-usage-data-channel > >> > >>                         Please check if the current state of the > >>                         discussion suits rum! > >> > >>                         The only issue that seems to be remaining is > >>                         how to transport RTT data to and from a > >>                         conference server that combines all traffic > >>                         per media in a meeting in one data stream. > >>                         That is not very elegantly specified for RFC > >>                         4103 transport of RTT in RTP either, so we > >>                         might want to do a rapid action together to > >>                         solve the multi-party RTT MCU case in a > >>                         general and consistent way. > >> > >>                         Regards > >> > >>                         Gunnar > >> > >>                         -- > >>                         ----------------------------------------- > >>                         Gunnar Hellström > >>                         Omnitor > >> gunnar.hellstrom@omnitor.se > >>                         > >>                         +46 708 204 288 > >> > >>                 -- > >>                 ----------------------------------------- > >>                 Gunnar Hellström > >>                 Omnitor > >> gunnar.hellstrom@omnitor.se > >>                 > >>                 +46 708 204 288 > >> > >>         -- > >>         ----------------------------------------- > >>         Gunnar Hellström > >>         Omnitor > >> gunnar.hellstrom@omnitor.se > > >>         +46 708 204 288 > >> > >> > >>     -- > >>     Rum mailing list > >> Rum@ietf.org > >> https://www.ietf.org/mailman/listinfo/rum > >> > >> > > -- > > ----------------------------------------- > > Gunnar Hellström > > Omnitor > > gunnar.hellstrom@omnitor.se > > +46 708 204 288 > > * [Rum] Real-time text in WebRTC is discussed in ... >   Gunnar > Hellström > * Re: [Rum] Real-time text in WebRTC is discussed... >   Brian > Rosen > * Re: [Rum] Real-time text in WebRTC is discussed... >   Gunnar > Hellström > * Re: [Rum] Real-time text in WebRTC is discussed... >   Brian > Rosen > * Re: [Rum] Real-time text in WebRTC is discussed... >   Gunnar > Hellström > * Re: [Rum] Real-time text in WebRTC is discussed... >   Paul > Kyzivat > * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >   Malloy, > Jim > * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >   Paul > Kyzivat > * Re: [Rum] Real-time text in WebRTC is discussed... >   Brian > Rosen > * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >   Brian > Rosen > * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >   Paul > Kyzivat > * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >   Brian > Rosen > * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >   Paul > Kyzivat > * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >   Brian > Rosen > * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >   Malloy, > Jim > * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >   Gunnar > Hellström > > -- > > *John Martin* > > Email: John.Martin@Purple.us > > From nobody Sat Aug 31 13:48:04 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED90120110 for ; Sat, 31 Aug 2019 13:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2g2Z0HclVb1 for ; Sat, 31 Aug 2019 13:47:57 -0700 (PDT) Received: from bin-mail-out-06.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 395C012010C for ; Sat, 31 Aug 2019 13:47:56 -0700 (PDT) X-Halon-ID: 92c540f9-cc30-11e9-837a-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.43.70] (unknown [94.234.35.142]) by bin-vsp-out-03.atm.binero.net (Halon) with ESMTPSA id 92c540f9-cc30-11e9-837a-0050569116f7; Sat, 31 Aug 2019 22:47:41 +0200 (CEST) To: Paul Kyzivat , John Martin , "rum@ietf.org" References: <3C2BF11C-2A0D-4C3B-BE71-7E40FB2677E9@contoso.com> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <5142d3b2-da81-25f0-8859-694cd6126f0b@omnitor.se> Date: Sat, 31 Aug 2019 22:47:50 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rum] [EXT] Re: Real-time text in WebRTC is discussed in mmusic - a topic closely telated to rum X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2019 20:48:03 -0000 Hi John, Thanks for a good base for discussion. See inline, Den 2019-08-30 kl. 17:12, skrev Paul Kyzivat: > John, > > On 8/30/19 7:32 AM, John Martin wrote: >> All, >> >>   $0.02 on RTT: > > Thanks for joining in! I don't have much knowledge of (and no > experience using) RTT so I will mostly watch from the sidelines as > long as others join in. > >     Thanks, >     Paul > > (BTW, I don't know how you formatted your message, but in my mail > reader (Thunderbird) none of your lines wrapped, requiring horizontal > scrolling to read them.) > >> RTT in General >> >> -------------- >> >> ISTM there are a few options for RTT in RUM, assuming the WebRTC >> media framework is adopted (as seems likely): >> >> 1.Use existing browser support for SCTP as recommended by the some of >> the WebRTC IETF WG participants. This was discussed as part of the >> IVC WG and would require and SCTP data channel to be negotiated and >> to encapsulate the RTP (4103) which then in turn encapsulate T.140 >> RTT. This solution would require gateways in the VRS provider >> networks, RTP/RTCP userspace (Javascript) layers in the browser and a >> T.140 RTT layer/UI also written in userspace in the browser. The current work discussed in mmusic  about draft-holmberg-mmusic-t140-usage-data-channel  specifies T.140 real-time text transported directly in a "reliable" WebRTC data channel, identified with subprotocol "t140". Would that not be suitable for a WebRTC based RUM? The data payload will be the same as carried in RFC 4103 if used without redundancy. You mention that embedded RTP with RFC 4103 would be used as data also in the data channel. That sounds complicated. What would you gain? I hope you also follow the discussion in mmusic. >> >> 2.Wait for WebRTC to support lower level data channels. This work is >> being discussed in the WebRTC community, but might be a case of “not >> holding our breath”. A lower level data channel would allow RTP/RTCP >> then T.140 to be negotiated in the SDP without the need for SCTP and >> associated gateway needs. Since the RTCWEB WG is closed now in IETF, this sounds as a 7 year uncertain plan. >> >> >> 3.As a stop-gap and simplification, support SIP MESSAGE as already >> provided for by the browsers and many endpoints, including WebRTC >> endpoints. SCTP data channels are supported as well, and you can just agree to start using it with a private subprotocol temporarily among RUMs until there is a standard. So why use SIP MESSAGE? >> >> >> We should not forget that RTCP must be implemented along with RTP. >> >> Conferencing and RTT >> >> -------------------- >> >> RTT in a conference is not currently defined and does not work using >> currently defined standards (I must admit to being being on mmusic so >> perhaps there are solutions being recommended there). Discussions on >> this have been ongoing for nearly 10 years (we didn’t solve it then >> Gunnar and I think the problems are still the same). For RTT to be >> useful in a conference there needs to be a few problems solved. If you do it with multiple streams sent to the clients, then there are no problems. Therefore there was hesitation when we discussed to bring up the topic in IETF. For mixing into one stream, there are problems. You can do it with normal RTP and conferencing specifications but get some limitations. You can select between a presentation planned by the mixer, or use CSRC in RTP to indicate the source of primary data in each packet and let the client plan the presentation. Both work and do not really need any further standardisation, but would benefit from good best practice specifications or even a standard for solving some problems. Planning and formatting the presentation in the mixer has the limitation that only the local user and one at a time of the remote users text can be presented in real-time. Text from the others need to be buffered until the currently presenting remote participant makes something so that giving turn to next in queue is suitable. Switching turn can be made automatically, based on completed phrase or sentence or message or inactivity or allowed maximum time by the presenting party. Identification about who is sending which text needs to be formatted by the mixer and is likely best in form of an IRC style label when the source is switched. This works for a call where users are reasonably well-behaved in taking turns. There are cases where the presentation in one column with sources in labels is not what the user wants. Using just one stream, and mark by CSRC who contributed to primary data in each packet works as long as no packet was lost. The receiver can make a better adapted presentation for presentation preferences by the user. And text can be presented in real-time from more than two users at the same time. But in order to use the redundant RFC 4103 data to recover text in case of packet loss, then also the redundant data needs to be marked with source. And for that, a convention is needed and standardised. A couple of variants are possible with different pros and cons. Losing so many packets that a missing text marker needs to be inserted also has its problems that needs a specified solution. >> >> 1.Multi-stream support: Brian, whilst you’re right that most >> conference systems are point-to-point for signalling they are more >> typically point-to-multi-point for media. The conference bridge >> usually handles the multiplexing of the streams, but they are usually >> now multiple streams. RTT conferencing needs to have the same >> support. We should assume conferencing is supported by way of SFU not >> MCU – that’s how WebRTC handles conferencing and we should assume the >> same for RTT. Yes, that is now the main path for draft-holmberg-mmusic-t140-usage-data-channel, and I think that is good. That is also possible without any further standardization for RTP based RTT. >> >> 2.Participant identification: streams from the conference bridge >> (MCU/SFU) must be tagged with the sender so the UI can signal to the >> user who sent that text (and reconstruct the stream correctly). Yes. Use CSRC / CNAME for RTP and  stream ID / label / session information for WebRTC data channel. >> >> 3.UI adaptions: Modern WebRTC based multi-party conferences have >> adapted UIs to display multiple video streams. UI’s are adapted to >> show the video participants however the user wants them to be >> displayed (single full screen, tiled, voice activated etc). We should >> expect no less from RTT conference enabled endpoints. It should be a >> user decision (if their UI supports it) as to whether they see >> line-by-line or RTT rendering of the text conversation. Yes. If you want a one column presentation, a reasonable presentation is to automatically assign one remote party at a time to be presented in real-time and present the others phrase by phrase, and automatically switch who is presented in real-time based on suitable criteria. >> >> 4.Control of how many simultaneous participants can text and how that >> is presented to the user needs to be explored. Multiple insertion >> points in the UI is one approach (though rapidly breaks down as the >> number of users increases). Line-by-line is another. Facilitated GA >> is another (the Go Ahead concept has been used for a long time in >> text conversations and may be appropriate in large RTT conferences to >> control overload). >> >> And a final FWIW: I think the utility of RTT in a conference quickly >> breaks down as the number of participants increases. It is completely >> unacceptable to have a single RTT stream presented to the user and an >> unmodified UI. You might as well revert to SIP MESSAGE and something >> like XMPP, and that could also be an option for either the short term >> or for endpoints that do not support multi-stream RTT. In some conferences it might be desirable with one dominating RTT source: a written interpretation of what is said, and then occasionally another participant gets the floor and types something . It is very valuable if that mode of conferencing is available without hazzle in general multi-party conference systems. The utility does not break down in that situation. It seems to me that aiming at multi-stream RTT support is to prefer. Regards Gunnar >> >> John >> >> Brian said: we agreed we were using 4103 in RUM. >> >> Good toknow. But is there not a hope to be able to even use browser >> >> technology for the implementation. The browsers only support RTP for >> >> audio and video. Can you make RTP-based RTT work in that environment and >> >> encrypted with the security method specified for WebRTC? >> >> See a bit more below: >> >> Den 2019-08-29 kl. 21:59, skrev Malloy, Jim: >> >>> “line at a time” is a user interface issue – RUM is defining a machine >> >>> interface.  How it’s presented to the user is out of scope. >> >>> >> >> Well, the control and coding must be made so that it is possible to make >> >> a good presentation. Transmission only line-by-line would not suit the >> >> intention of RTT. It is hard to make a good RTT presentation with a >> >> client that is only expecting text from one other participant and a >> >> mixer that has the task to send text from many sources combined in one >> >> stream. The best result is usable but not nice. And it will be aimed at >> >> just one way to present RTT. No freedom to plan the presentation >> >> according to user preferences. >> >> A receiver may, if there is a desire for such functionality, store >> >> received text until a received message is complete. I do not think that >> >> it is to prefer in any situation. >> >> Regards >> >> Gunnar >> >>> --Jim >> >>> >> >>> *From:* Rum ; >>> *On Behalf Of * >> Brian Rosen >> >>> *Sent:* Thursday, August 29, 2019 1:15 PM >> >>> *To:* Kyzivat, Paul >>> ; >> >>> *Cc:* rum@ietf.org >> >>> *Subject:* [EXT] Re: [Rum] Real-time text in WebRTC is discussed in >> >>> mmusic - a topic closely telated to rum >> >>> >> >>> “Line at a time” could be an implementation option.  The protocol >> >>> mechanism is all streams head to a mixer and the mixer sends a single >> >>> stream to each participant. >> >>> >> >>> Gunnar, we agreed we were using 4103 in RUM. >> >>> >> >>> Brian >> >>> >> >>> >> >>> >> >>>      On Aug 29, 2019, at 12:05 PM, Paul Kyzivat >>> >> >>>  > wrote: >> >>> >> >>>      I question how well RTT text is suited to multiparty conferences. >> >>> >> >>>      If you have messages on your screen from multiple parties, and >> >>>      many of them are updating in real-time, are you going to be able >> >>>      to perceive what is going on? >> >>> >> >>>      And while you can have a column per person for two-party and maybe >> >>>      3-party conversations, that doesn't scale up. With many parties, >> >>>      some typing may scroll off the screen before it is complete. >> >>> >> >>>      Perhaps for conferences it is better to just use line-at-a-time >> >>>      chat. If necessary, I presume there could be gateways between RTT >> >>>      and chat. A RUE could have the capability to negotiate down from >> >>>      RTT to chat. >> >>> >> >>>      Thanks, >> >>>      Paul >> >>> >> >>>      On 8/28/19 2:15 AM, Gunnar Hellström wrote: >> >>> >> >>>          Den 2019-08-27 kl. 23:15, skrev Brian Rosen: >> >>> >> >>>              At least by centralizing the problem at a “mixer”, Alice >> >>>              and Bob will see the same thing. >> >>> >> >>>              You don’t have the problem in Instant Messaging, because >> >>>              you can’t backspace or delete a sent message.  Of course >> >>>              if multiple people are typing simultaneously in such >> >>>              systems, message order will be confusing in that instant. >> >>> >> >>>          Right, it is a similar kind of problem that text appears in an >> >>>          unexpected order. There is also at least one instant messaging >> >>>          service that allows modification in already sent message. But >> >>>          I think it has limitations to only accept that in the last >> >>>          message sent. it is convenient anyway. >> >>> >> >>> >> >>>              Anyway, we need to specify the mixer for RTT so it >> >>>              receives each of the RTT streams and produces a single >> >>>              composite stream for each participant. >> >>> >> >>>          Yes, right, and there is an effort in that direction in: >> >>> http://www.realtimetext.org/sites/default/files/Files_and_Documents/Specifications/multiparty-real-time-text-mixer-2011-04-30.pdf >> >>>          It is written for conference-unaware user devices. >> >>>          The goals are specified as follows: >> >>>          The procedures are intended to make best efforts to present a >> >>>          multi-party text conversation on a terminal that has no >> >>>          awareness of multi-party calls. There are some obvious >> >>>          drawbacks, and a terminal designed with multi-party awareness >> >>>          will be able to present multi-party call contents in a more >> >>>          flexible way. Only two parties at a time will be allowed to >> >>>          display added text in real-time, while the other parties’ >> >>>          produced text will need to be stored in the multi-party server >> >>>          for a moment awaiting a suitable occasion to be displayed. >> >>>          There are also some cases of erasure that will not be >> >>>          performed on the target text but only indicated in another >> >>>          way. Even with these drawbacks, the procedure provides an >> >>>          opportunity to display text from more than two parties in a >> >>>          smooth and readable way. >> >>> --------------------------------------------------------------------------------------------------- >> >>>          I see such mixer procedures as a fall-back for cases without >> >>>          conference awareness, but want to see support for >> >>>          conference-aware terminals, where text from more than two >> >>>          parties can be presented in real-time, and the end user or app >> >>>          can have influence over the presentation style - e.g. select >> >>>          between the multiple column view and the >> >>>          one-column-with-labels view.  A mixer for that case would only >> >>>          need to assure that the receiver has the right kind of >> >>>          multi-party awareness and send RTT text with source >> >>>          information attached, and let the receiving terminal sort out >> >>>          the presentation. This is already possible with CSRC and CNAME >> >>>          when using RTP, but we lose that possibility natively when >> >>>          using the WebRTC data channel to transport RTT, and would need >> >>>          to specify a way to include the source also for that case. >> >>> ------------------------------------------------------ >> >>>          By the way, what is your current view of how to transport RTT >> >>>          for RUM, now when you say that you will use WebRTC transports >> >>>          for media? >> >>>          Regards >> >>>          Gunnar >> >>> >> >>> >> >>> >> >>>                  On Aug 27, 2019, at 4:43 PM, Gunnar Hellström >> >>> >> >>> > >> >>>                  wrote: >> >>> >> >>>                  Den 2019-08-27 kl. 21:48, skrev Brian Rosen: >> >>> >> >>>                      The problem of conference 4103 RTT is high on my >> >>>                      list of work I need to get done.  So, I’m >> >>>                      motivated to help out. >> >>> >> >>>                  Thanks, great. >> >>> >> >>>                      The basic problem is that we’re going to get very >> >>>                      inconsistent UI doing it that way, because of how >> >>>                      systems will handle backspace of one party that >> >>>                      extends beyond responses from other parties: >> >>> >> >>>                  (well, for me the currently most basic problem is to >> >>>                  have a reliable way to append received text to the >> >>>                  already presented text of the right participant. And >> >>>                  that is getting worse in WebRTC than it was in RFC >> >>>                  4103. But we will sort it out.) >> >>> >> >>> >> >>>                      Alice: I waited for you >> >>>                      Bob: I didn’t see you >> >>>                      Alice: sorry >> >>> >> >>>                      And then Alice types 12 backspaces. >> >>> >> >>>                      What should happen? >> >>> >> >>> >> >>>                  You are right that there are a number of ways to >> >>>                  handle the RTT UI. And just as inconsistencies are >> >>>                  common with a message oriented UI, where messages show >> >>>                  up in a confusing order because two users completed >> >>>                  messages in an unexpected time order, it is possible >> >>>                  that RTT text gets displayed in a strange order after >> >>>                  erasure and retyping. It is better for RTT than for >> >>>                  message oriented presentation, and user get used to it >> >>>                  in both cases.  With the labelled style in one column >> >>>                  you have in the example, I would recommend that first >> >>>                  5 backspaces erase "sorry", next backspace erases the >> >>>                  line separator, and pulls down "I waited for you" to >> >>>                  be shown last, as an uncompleted text. Then the next 6 >> >>>                  backspaces erase so that only "I waited f" is >> >>>                  displayed. When Alice adds text and end with a new >> >>>                  line, the corrected sentence is allowed to flow up >> >>>                  when new text is added from any participant.  That >> >>>                  causes a bit strange order, but it is just as >> >>>                  manageable as when text in messaging applications >> >>>                  appear in an unexpected order so that one message >> >>>                  seems to be a respone on something totally else than >> >>>                  what was intended. >> >>> >> >>>                  A sophisticated UI may mark text that is moved and >> >>>                  modified. >> >>> >> >>>                  We want to keep sentences or at least phrases from >> >>>                  each participant together in a readable unit. Already >> >>>                  that causes a design decision on where to place the >> >>>                  completed chunk of text once the user has completed >> >>>                  it. The start of the chunk may be older than completed >> >>>                  text from other participants which would motivate to >> >>>                  move it up a bit in the presentation. But the end of >> >>>                  it is at that moment the latest text to present. I >> >>>                  think it is best to let the finished text be presented >> >>>                  last on the display, but let others' newer text push >> >>>                  everything up and be displayed last. >> >>> >> >>> >> >>>                 T.140 has information on how to handle erasure: >> >>> >> >>>                  -------------------From >>> T.140--------------------------- >> >>> >> >>>                  8.2 Erase last character >> >>>                  Purpose: Erase the last character sent from the >> >>>                  display at the receiving end. >> >>>                  Code: BS: 0008. >> >>>                  Procedure: On the receiving end: Move the insertion >> >>>                  point to the last character and erase it. >> >>>                  Combined characters are erased as a unit, with one BS >> >>>                  erasing the whole character even if it is >> >>>                  combined from more than one component. >> >>>                  Control sequences (like CR LF) are erased in one >> >>>                  operation. >> >>>                  NOTE – The same action shall be taken on the local >> >>>                  display. >> >>> >> >>> ------------------------------------------------------------ >> >>> >> >>>                    /Gunnar >> >>> >> >>> >> >>> >> >>>                      Brian >> >>> >> >>> >> >>>                          On Aug 27, 2019, at 9:52 AM, Gunnar Hellström >> >>> >> >>> > >> >>>                          wrote: >> >>> >> >>>                          Hi, >> >>> >> >>>                          A topic is currently discussed in mmusic that >> >>>                          is closely related to rum. it is WebRTC >> >>>                          transport of real-time text. >> >>> >> >>>                          The draft is >> >>> draft-holmberg-mmusic-t140-usage-data-channel . >> >>> >> >>>                          A good point to start reading could be: >> >>> >> >>> https://mailarchive.ietf.org/arch/browse/mmusic/?gbt=1&q=draft-holmberg-mmusic-t140-usage-data-channel >> >>> >> >>>                          Please check if the current state of the >> >>>                          discussion suits rum! >> >>> >> >>>                          The only issue that seems to be remaining is >> >>>                          how to transport RTT data to and from a >> >>>                          conference server that combines all traffic >> >>>                          per media in a meeting in one data stream. >> >>>                          That is not very elegantly specified for RFC >> >>>                          4103 transport of RTT in RTP either, so we >> >>>                          might want to do a rapid action together to >> >>>                          solve the multi-party RTT MCU case in a >> >>>                          general and consistent way. >> >>> >> >>>                          Regards >> >>> >> >>>                          Gunnar >> >>> >> >>>                          -- >> >>> ----------------------------------------- >> >>>                          Gunnar Hellström >> >>>                          Omnitor >> >>> gunnar.hellstrom@omnitor.se >> >>> >> >>>                          +46 708 204 288 >> >>> >> >>>                  -- >> >>> ----------------------------------------- >> >>>                  Gunnar Hellström >> >>>                  Omnitor >> >>> gunnar.hellstrom@omnitor.se >> >>> >> >>>                  +46 708 204 288 >> >>> >> >>>          -- >> >>> ----------------------------------------- >> >>>          Gunnar Hellström >> >>>          Omnitor >> >>>         gunnar.hellstrom@omnitor.se >>> >> >> >>>          +46 708 204 288 >> >>> >> >>> >> >>>      -- >> >>>      Rum mailing list >> >>>     Rum@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/rum >> >>> >> >>> >> >> -- >> >> ----------------------------------------- >> >> Gunnar Hellström >> >> Omnitor >> >> gunnar.hellstrom@omnitor.se >> >> +46 708 204 288 >> >>   * [Rum] Real-time text in WebRTC is discussed in ... >>   Gunnar >>     Hellström >>   * Re: [Rum] Real-time text in WebRTC is discussed... >>   Brian >>     Rosen >>   * Re: [Rum] Real-time text in WebRTC is discussed... >>   Gunnar >>     Hellström >>   * Re: [Rum] Real-time text in WebRTC is discussed... >>   Brian >>     Rosen >>   * Re: [Rum] Real-time text in WebRTC is discussed... >>   Gunnar >>     Hellström >>   * Re: [Rum] Real-time text in WebRTC is discussed... >>   Paul >>     Kyzivat >>   * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >>   Malloy, >>     Jim >>   * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >>   Paul >>     Kyzivat >>   * Re: [Rum] Real-time text in WebRTC is discussed... >>   Brian >>     Rosen >>   * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >>   Brian >>     Rosen >>   * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >>   Paul >>     Kyzivat >>   * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >>   Brian >>     Rosen >>   * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >>   Paul >>     Kyzivat >>   * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >>   Brian >>     Rosen >>   * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >>   Malloy, >>     Jim >>   * Re: [Rum] [EXT] Re: Real-time text in WebRTC is... >>   Gunnar >>     Hellström >> >> -- >> >> *John Martin* >> >> Email: John.Martin@Purple.us >> >> > -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288