From nobody Thu Jul 2 15:09:35 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7471A8F3C for ; Thu, 2 Jul 2015 15:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 tN3n4I3sLXdG for ; Thu, 2 Jul 2015 15:09:32 -0700 (PDT) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (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 4F3911A8F37 for ; Thu, 2 Jul 2015 15:09:31 -0700 (PDT) Received: by ykdy1 with SMTP id y1so81147838ykd.2 for ; Thu, 02 Jul 2015 15:09:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=gFCVLDkoIkcn+SEfimyCUeA4tqlK6+m2zRVg0lV1qUs=; b=UxqPVvH0vqQIjjXQUc91yJQpJE4SJyQuuzCr2vGozxylUBS/s51tcdM7kj27q+MOvu DMAcnLxHNroIsx/diMF/w58bvbIxIOavOLwtLRtqBr4KtKjbGvgurNonHwnpCzyka6v5 lF4cowoM/8cIzghYYQHTZQcQPFU2Jo0aFzjut//RhPcIk0KPvHs+1Gun2n69ZCXrjDDo U8FC8LweLhkHEw7FHlGf2hiDvcVf98Vz+Zm1I6cFH9So/5n6PjanzA7hm5D2Ay75SQLB c3MJMUSRTbzT9ORzZ3a+fFY0VmrJKdhDuRs1cEQN6cEPDnu+Ac9JTZpHriq6byKNWNML k7hQ== MIME-Version: 1.0 X-Received: by 10.170.216.135 with SMTP id i129mr41055016ykf.116.1435874970702; Thu, 02 Jul 2015 15:09:30 -0700 (PDT) Received: by 10.37.112.7 with HTTP; Thu, 2 Jul 2015 15:09:30 -0700 (PDT) Date: Thu, 2 Jul 2015 23:09:30 +0100 Message-ID: From: Nik Tomkinson To: slim@ietf.org Content-Type: multipart/alternative; boundary=001a1139eb8e9217bd0519ebb105 Archived-At: Subject: [Slim] Translation Quality or type X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 22:09:34 -0000 --001a1139eb8e9217bd0519ebb105 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable All, in the November IETF last year, there was a suggestion from one participant (St=C3=A9phane Bortzmeyer) about including some identification of translati= on quality. The question is at: https://www.ietf.org/audio/ietf91/ietf91-coral2-20141110-0900-am1.mp3 move ahead to 1h 56m 00s (you may need to download it first). The reason for this is principally because a lot of internet sites are written in English and anyone who choses a non-english language as their preferred language for the internet often receives bad machine-translated pages. He suggests that with an indication of the type (original/translation) and the translation quality (human/machine) then a much better selection of translation can be made. We have this opportunity now for multilingual email to avoid the mistake that multilingual internet has made. To accommodate this, I am just about to add this new field to the I-D for Multipart-multilingual email: translation-type :=3D type-token type-token :=3D "original" / "human" / "automated" so for example: Translation-Type: original Translation-Type: human This would be for each language translation, so that 'original' is untranslated content, 'human' is human-translated content and 'automated' is machine-translated content. Obviously there is trust on the part of the sender to properly classify the origin, but that is unavoidable. Please let me know what you think, but bear in mind that the cut-off date for I-D updates before Prague is 06-July 23:59 UTC so we have to be quick to get this discussed and agreed by then. The current I-D version has expired and I am keen to get a non-expired version available for people to discuss in Prague. Thanks in advance, Nik. --=20 ----------------------------------------------------------------- Multiple Language Content Type Internet Draft: http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/ ----------------------------------------------------------------- --001a1139eb8e9217bd0519ebb105 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

in the November IETF la= st year, there was a suggestion from one participant (St=C3=A9phane Bortzme= yer) about including some identification of translation quality.=C2=A0

The question is at:

move ahead to 1h 56m 00s (you may need to download it first).
<= div>
The reason for this is principally because a lot of inte= rnet sites are written in English and anyone who choses a non-english langu= age as their preferred language for the internet often receives bad machine= -translated pages. He suggests that with an indication of the type (origina= l/translation) and the translation quality (human/machine) then a much bett= er selection of translation can be made. We have this opportunity now for m= ultilingual email to avoid the mistake that multilingual internet has made.=

To accommodate this, I am just about to add this = new field to the I-D for Multipart-multilingual email:

=
translation-type :=3D type-token
type-token :=3D "origi= nal" / "human" / "automated"

<= div>so for example:

Translation-Type: original

Translation-Type: human

This= would be for each language translation, so that 'original' is untr= anslated content, 'human' is human-translated content and 'auto= mated' is machine-translated content. Obviously there is trust on the p= art of the sender to properly classify the origin, but that is unavoidable.=

Please let me know what you think, but bear in mi= nd that the cut-off date for I-D updates before Prague is 06-July 23:59 UTC= so we have to be quick to get this discussed and agreed by then. The curre= nt I-D version has expired and I am keen to get a non-expired version avail= able for people to discuss in Prague.

Thanks in ad= vance,

Nik.

-- 
-------------------------=
----------------------------------------
Multiple Language Content Type =
Internet Draft:
http://datatracker.ietf.org= /doc/draft-tomkinson-slim-multilangcontent/
----------------------------------=
-------------------------------
--001a1139eb8e9217bd0519ebb105-- From nobody Thu Jul 2 23:53:10 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 384041B2DD2 for ; Thu, 2 Jul 2015 23:53:10 -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] autolearn=ham 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 5JFg4PswCeCo for ; Thu, 2 Jul 2015 23:53:08 -0700 (PDT) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 788161B2DCD for ; Thu, 2 Jul 2015 23:53:08 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id C9FAC3AA70; Fri, 3 Jul 2015 08:53:06 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 3A1A919072C; Fri, 3 Jul 2015 08:49:08 +0200 (CEST) Date: Fri, 3 Jul 2015 08:49:08 +0200 From: Stephane Bortzmeyer To: Nik Tomkinson Message-ID: <20150703064908.GA14666@sources.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 8.1 X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] Translation Quality or type X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 06:53:10 -0000 On Thu, Jul 02, 2015 at 11:09:30PM +0100, Nik Tomkinson wrote a message of 109 lines which said: > type-token := "original" / "human" / "automated" In many IETF working groups, when there is such a proposal, there is a big discussion between the registryfull and the registryless people. The first ones say there must be an authoritative list of values (in the RFC or, better because more evolving, in an IANA registry) so we can be sure of the interpretation of values. The second ones say we can never capture all the nuances and subtleties of the world in a fixed list. Here, I am not sure that the only meaningful distinction is between "human" and "automated". Some humans do a very poor job, too. One could suggest: type-token := "original" / "professional-human" / "amateur-human" / "automated-first-generation" / "automated-artificial-intelligence" / "automated-the-robot-in-hollywood-movies" Or decide that it will be too complicated and we should instead accept: > type-token := "original" / Toughts? From nobody Fri Jul 3 02:43:34 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0141B2B60 for ; Fri, 3 Jul 2015 02:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 Lw8ktq02D0qE for ; Fri, 3 Jul 2015 02:43:32 -0700 (PDT) Received: from bin-vsp-out-05.atm.binero.net (vsp-unauthed01.binero.net [195.74.38.225]) (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 798B31B2B5F for ; Fri, 3 Jul 2015 02:43:31 -0700 (PDT) X-Halon-ID: fb59e699-2167-11e5-8d5f-005056916f53 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.50.52] (unknown [217.13.240.130]) by bin-vsp-out-05.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Fri, 3 Jul 2015 11:43:38 +0200 (CEST) Message-ID: <55964BED.1080905@omnitor.se> Date: Fri, 03 Jul 2015 10:46:37 +0200 From: =?windows-1252?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: slim@ietf.org References: <20150703064908.GA14666@sources.org> In-Reply-To: <20150703064908.GA14666@sources.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Slim] Translation Quality or type X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 09:43:33 -0000 I see some value of this kind of parameter also for the real-time case. The time is here when it can be possible in some situations to select between using a low-cost automatic speech-to-text generation and a higher cost captioned telephony or text-relay service (higher cost for someone, not always the end-user). But I agree that it is very hard to set good understandable values on a parameter expressing the type or quality of this kind of service. Gunnar Stephane Bortzmeyer skrev den 2015-07-03 08:49: > On Thu, Jul 02, 2015 at 11:09:30PM +0100, > Nik Tomkinson wrote > a message of 109 lines which said: > >> type-token := "original" / "human" / "automated" > In many IETF working groups, when there is such a proposal, there is a > big discussion between the registryfull and the registryless > people. The first ones say there must be an authoritative list of > values (in the RFC or, better because more evolving, in an IANA > registry) so we can be sure of the interpretation of values. The > second ones say we can never capture all the nuances and subtleties of > the world in a fixed list. > > Here, I am not sure that the only meaningful distinction is between > "human" and "automated". Some humans do a very poor job, too. One > could suggest: > > type-token := "original" / "professional-human" / "amateur-human" / > "automated-first-generation" / "automated-artificial-intelligence" / > "automated-the-robot-in-hollywood-movies" > > Or decide that it will be too complicated and we should instead > accept: > >> type-token := "original" / > Toughts? > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim From nobody Fri Jul 3 08:30:01 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 094081B2C06 for ; Fri, 3 Jul 2015 08:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 C_NjfDhmulLw for ; Fri, 3 Jul 2015 08:29:56 -0700 (PDT) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (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 C9CAC1B2C1C for ; Fri, 3 Jul 2015 08:29:55 -0700 (PDT) Received: by ykdr198 with SMTP id r198so98157176ykd.3 for ; Fri, 03 Jul 2015 08:29:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5o4OFJUlquJjP6TbH4eP7Z0HQPFdR5JLpNAZhTogGpk=; b=IxtngYb++V5KF1WXqoZeRIVyqrX17QBaayaeWzSIPeyRL9mGKkaRbvByuKZAgKc3Np jQOhsogSjll3l2ddxopcbCrzFv7awJMrPHnZPU3vvIQqyiX2CaH9pV/TvfEex3MfnA/e HIH6YHnaxa6ryWq4nTbAqpAOdcRVpxy/tptdDXrtoJtOvWwJbAg/NTAqvDQC7ttwJTEM aIwWy+M86zuzjUUbnbXQ2zVWHrbwf+jtber5SX43Zr3rxchWRHVRIvAGMSgNuzvTPNbO AxU5RcPxF0eFPcg4RFIFGTQr+gLYg4+mF9IXvelCGKdnxFM/xq+6J/AGr3xuNCiRPv6e 6z8w== MIME-Version: 1.0 X-Received: by 10.170.35.196 with SMTP id 187mr41629377ykd.121.1435937395068; Fri, 03 Jul 2015 08:29:55 -0700 (PDT) Received: by 10.37.112.7 with HTTP; Fri, 3 Jul 2015 08:29:55 -0700 (PDT) In-Reply-To: <55964BED.1080905@omnitor.se> References: <20150703064908.GA14666@sources.org> <55964BED.1080905@omnitor.se> Date: Fri, 3 Jul 2015 16:29:55 +0100 Message-ID: From: Nik Tomkinson To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= Content-Type: multipart/alternative; boundary=001a1137850e5a7c9d0519fa3a5b Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] Translation Quality or type X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 15:29:58 -0000 --001a1137850e5a7c9d0519fa3a5b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the responses. To deal with the issue with having only original/human/automated, what about the following?: translation-type :=3D type-token[ ";" "q" "=3D" qvalue ] type-token :=3D"human" / "automated" where qvalue is a value between 0 and 1 with a default of 0.5 if missing for example: Translation-Type: human;q=3D0.8 Translation-Type: automated;q=3D0.4 Translation-Type: human The Translation-Type SHOULD NOT appear in the original (untranslated) part but it SHOULD appear in translated content. Having this missing from the original text helps identify which is the source to be translated into further languages if the user mail client allows. This enables us to dispose of the 'original' value which didn't lend itself well to being graded on quality. The qvalue can be set by the sender or provided by the translation service. The draft suggests that: "Additionally, interactive implementations MAY offer the user a choice from among the available languages." so the qvalue may not need to be bulletproof. Comments? Nik. On 3 July 2015 at 09:46, Gunnar Hellstr=C3=B6m wrote: > I see some value of this kind of parameter also for the real-time case. > The time is here when it can be possible in some situations to select > between using a low-cost automatic speech-to-text generation and a higher > cost captioned telephony or text-relay service (higher cost for someone, > not always the end-user). > > But I agree that it is very hard to set good understandable values on a > parameter expressing the type or quality of this kind of service. > > Gunnar > > > > Stephane Bortzmeyer skrev den 2015-07-03 08:49: > >> On Thu, Jul 02, 2015 at 11:09:30PM +0100, >> Nik Tomkinson wrote >> a message of 109 lines which said: >> >> type-token :=3D "original" / "human" / "automated" >>> >> In many IETF working groups, when there is such a proposal, there is a >> big discussion between the registryfull and the registryless >> people. The first ones say there must be an authoritative list of >> values (in the RFC or, better because more evolving, in an IANA >> registry) so we can be sure of the interpretation of values. The >> second ones say we can never capture all the nuances and subtleties of >> the world in a fixed list. >> >> Here, I am not sure that the only meaningful distinction is between >> "human" and "automated". Some humans do a very poor job, too. One >> could suggest: >> >> type-token :=3D "original" / "professional-human" / "amateur-human" / >> "automated-first-generation" / "automated-artificial-intelligence" / >> "automated-the-robot-in-hollywood-movies" >> >> Or decide that it will be too complicated and we should instead >> accept: >> >> type-token :=3D "original" / >>> >> Toughts? >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim >> > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim > --=20 ----------------------------------------------------------------- Multiple Language Content Type Internet Draft: http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/ ----------------------------------------------------------------- --001a1137850e5a7c9d0519fa3a5b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the responses.

To deal with = the issue with having only original/human/automated, what about the followi= ng?:


translation-type :=3D typ= e-token[ ";" "q" "=3D" qvalue ]
typ= e-token :=3D"human" / "automated"

<= div>where qvalue is a value between 0 and 1 with a default of 0.5 if missin= g

for example:

Translatio= n-Type: human;q=3D0.8
Translation-Type: automated;q=3D0.4
Translation-Type: human

The Translation-Type SH= OULD NOT appear in the original (untranslated) part but it SHOULD appear in= translated content.

Having this missing fro= m the original text helps identify which is the source to be translated int= o further languages if the user mail client allows.

This enables us to dispose of the 'original' value which didn'= ;t lend itself well to being graded on quality.

Th= e qvalue can be set by the sender or provided by the translation service.

The draft suggests that:

&= quot;Additionally, in= teractive implementations MAY offer the user a choice from among the available languages.= " so the qvalue may not need to be bulletproof.

<= /div>
Comments?

Nik.

On 3 July 2015 at 09:46, Gunnar= Hellstr=C3=B6m <gunnar.hellstrom@omnitor.se> wrot= e:
I see some value of this kind of param= eter also for the real-time case.
The time is here when it can be possible in some situations to select betwe= en using a low-cost automatic speech-to-text generation and a higher cost c= aptioned telephony or text-relay service (higher cost for someone, not alwa= ys the end-user).

But I agree that it is very hard to set good understandable values on a par= ameter expressing the type or quality of this kind of service.

Gunnar



Stephane Bortzmeyer skrev den 2015-07-03 08:49:
On Thu, Jul 02, 2015 at 11:09:30PM +0100,
=C2=A0 Nik Tomkinson <rfc.nik.tomkinson@gmail.com> wrote
=C2=A0 a message of 109 lines which said:

type-token :=3D "original" / "human" / "automated&= quot;
In many IETF working groups, when there is such a proposal, there is a
big discussion between the registryfull and the registryless
people. The first ones say there must be an authoritative list of
values (in the RFC or, better because more evolving, in an IANA
registry) so we can be sure of the interpretation of values. The
second ones say we can never capture all the nuances and subtleties of
the world in a fixed list.

Here, I am not sure that the only meaningful distinction is between
"human" and "automated". Some humans do a very poor job= , too. One
could suggest:

type-token :=3D "original" / "professional-human" / &qu= ot;amateur-human" /
"automated-first-generation" / "automated-artificial-intelli= gence" /
"automated-the-robot-in-hollywood-movies"

Or decide that it will be too complicated and we should instead
accept:

type-token :=3D "original" / <free text>
Toughts?

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

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



-- 
-----------------------------------=
------------------------------
Multiple Language Content Type Internet D=
raft:
http://datatracker.ietf.org/doc/draft-tomkinson= -slim-multilangcontent/
----------------------------------------------------------------=
-
--001a1137850e5a7c9d0519fa3a5b-- From nobody Fri Jul 3 09:00:10 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1341B3047 for ; Fri, 3 Jul 2015 09:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 YX2oleAM63Pv for ; Fri, 3 Jul 2015 09:00:07 -0700 (PDT) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECFFD1B3059 for ; Fri, 3 Jul 2015 09:00:06 -0700 (PDT) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-10v.sys.comcast.net with comcast id nrzw1q00326dK1R01s051l; Fri, 03 Jul 2015 16:00:05 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-01v.sys.comcast.net with comcast id ns051q00F3Ge9ey01s05Cb; Fri, 03 Jul 2015 16:00:05 +0000 Message-ID: <5596B184.2020908@alum.mit.edu> Date: Fri, 03 Jul 2015 12:00:04 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: slim@ietf.org References: <20150703064908.GA14666@sources.org> <55964BED.1080905@omnitor.se> In-Reply-To: <55964BED.1080905@omnitor.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1435939205; bh=8hsqm7oTMPRJ7MKn6y+85qX0KE1Ru7xa+rY7RUMFc9w=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=dSksgk/2LAqzdSqek0XkqDLICsUcNzotp1Espn3tzO+hhAEj/XfOPnKj/a/7p7ZIh qMJvk8puDa8oscOUW99q7PJLV6MdBI3h9dhXjFdRBRZjFBIkADtaQQimxesiVCtDbH jzlg/jFCJeaAj7wWCDHoCmZB/iVNzPR8axWTVM+9ItIwBbr9hb30A0j4ZdlHrp8O+m NUkeq+LaLehHPaBcFHLCN+skl8FtMqv+hnytRIfqD40pg8p5oWRmVcJYIn8M3SKud/ 7k2uM6adKtFAY/wdyca+wAdKHzrixzUoR5k+jOfpvqQ4Ip3v721VTyuMwljezW1sqT d/t8dazMb616g== Archived-At: Subject: Re: [Slim] Translation Quality or type X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 16:00:08 -0000 On 7/3/15 4:46 AM, Gunnar Hellström wrote: > I see some value of this kind of parameter also for the real-time case. > The time is here when it can be possible in some situations to select > between using a low-cost automatic speech-to-text generation and a > higher cost captioned telephony or text-relay service (higher cost for > someone, not always the end-user). > > But I agree that it is very hard to set good understandable values on a > parameter expressing the type or quality of this kind of service. Yes. It is my understanding (2nd hand) there there are subjective decisions (preferences) when choosing a translation service. While I can see how having a rating attached might be conceptually appealing, it is hard to imagine how it would be deployed in a way that is useful. And it seems likely to be subject to endless haggling. Seems like a rat hole. Thanks, Paul > Gunnar > > > Stephane Bortzmeyer skrev den 2015-07-03 08:49: >> On Thu, Jul 02, 2015 at 11:09:30PM +0100, >> Nik Tomkinson wrote >> a message of 109 lines which said: >> >>> type-token := "original" / "human" / "automated" >> In many IETF working groups, when there is such a proposal, there is a >> big discussion between the registryfull and the registryless >> people. The first ones say there must be an authoritative list of >> values (in the RFC or, better because more evolving, in an IANA >> registry) so we can be sure of the interpretation of values. The >> second ones say we can never capture all the nuances and subtleties of >> the world in a fixed list. >> >> Here, I am not sure that the only meaningful distinction is between >> "human" and "automated". Some humans do a very poor job, too. One >> could suggest: >> >> type-token := "original" / "professional-human" / "amateur-human" / >> "automated-first-generation" / "automated-artificial-intelligence" / >> "automated-the-robot-in-hollywood-movies" >> >> Or decide that it will be too complicated and we should instead >> accept: >> >>> type-token := "original" / >> Toughts? >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim > From nobody Sat Jul 4 18:49:48 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E837E1A8869 for ; Sat, 4 Jul 2015 18:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.011 X-Spam-Level: X-Spam-Status: No, score=-4.011 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 iUjs9nW0cA1D for ; Sat, 4 Jul 2015 18:49:44 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 526D21A8857 for ; Sat, 4 Jul 2015 18:49:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1436060984; x=1467596984; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version:content-transfer-encoding; bh=4AYu+yAJ8WeaE0qAuGlw9SY89NgG7c6xhqF9L882BrM=; b=mnjxRfwb0nsVhL1IGQoqqcOe0mx99apvmWf3WdpXRXKJYCeAQqkdBuq8 nHyUVzfW0LJXdx5137dMVJdvrK+/RZm1xACVYUM1LRq3dV9R7whnWqyiS du8DsuVVp/dKFpJl7QxfaSeaoHBDRnIPZBBPtgk+9FwEBXAi8CwAA2cKQ Q=; X-IronPort-AV: E=McAfee;i="5700,7163,7852"; a="218897433" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Jul 2015 18:49:43 -0700 X-IronPort-AV: E=Sophos;i="5.15,408,1432623600"; d="scan'208";a="953877515" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 04 Jul 2015 18:49:44 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Sat, 4 Jul 2015 18:49:41 -0700 Message-ID: In-Reply-To: References: <20150703064908.GA14666@sources.org> <55964BED.1080905@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Sat, 4 Jul 2015 18:49:38 -0700 To: Nik Tomkinson , Gunnar =?iso-8859-1?Q?Hellstr=F6m?= From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01C.na.qualcomm.com (10.85.0.83) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] Translation Quality or type X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2015 01:49:47 -0000 My recollection is that this was discussed in=20 email prior to Dallas, but that's not important. I am a strong proponent of keeping things as=20 simple as possible, provided there is a way to=20 extend them if experience shows that it is=20 needed. So, I think we should stick with the=20 original suggestion of three values ("original",=20 "human", "automated"). This is simple enough to=20 be implementable and functional enough to be=20 useful in providing a hint that may help the=20 client choose the best version for the user. If=20 we try and capture the various nuances of quality=20 we will end up with a very complex mechanism that=20 is unlikely to be any more useful in real life.=20 Let's go with the simple approach now. If, after=20 some deployment experience we realize that we=20 really do need extra complexity, we can extend=20 the mechanism then. At 4:29 PM +0100 7/3/15, Nik Tomkinson wrote: > Thanks for the responses. > > To deal with the issue with having only=20 > original/human/automated, what about the=20 > following?: > > > translation-type :=3D type-token[ ";" "q" "=3D" qvalue ] > type-token :=3D"human" / "automated" > > where qvalue is a value between 0 and 1 with a default of 0.5 if missing > > for example: > > Translation-Type: human;q=3D0.8 > Translation-Type: automated;q=3D0.4 > Translation-Type: human > > The Translation-Type SHOULD NOT appear in the=20 > original (untranslated) part but it SHOULD=20 > appear in translated content. > > Having this missing from the original text=20 > helps identify which is the source to be=20 > translated into further languages if the user=20 > mail client allows. > > This enables us to dispose of the 'original'=20 > value which didn't lend itself well to being=20 > graded on quality. > > The qvalue can be set by the sender or provided by the translation servic= e. > > The draft suggests that: > > "Additionally, interactive implementations MAY=20 > offer the user a choice from among the=20 > available languages." so the qvalue may not=20 > need to be bulletproof. > > Comments? > > Nik. > > On 3 July 2015 at 09:46, Gunnar Hellstr=F6m=20 > <gunnar.hellstrom@omnitor.se>=20 > wrote: > > I see some value of this kind of parameter also for the real-time case. > The time is here when it can be possible in=20 > some situations to select between using a=20 > low-cost automatic speech-to-text generation=20 > and a higher cost captioned telephony or=20 > text-relay service (higher cost for someone,=20 > not always the end-user). > > But I agree that it is very hard to set good=20 > understandable values on a parameter expressing=20 > the type or quality of this kind of service. > > Gunnar > > > > Stephane Bortzmeyer skrev den 2015-07-03 08:49: > > On Thu, Jul 02, 2015 at 11:09:30PM +0100, > Nik Tomkinson=20 > <rfc.nik.tomkinson@gmail.com>=20 > wrote > a message of 109 lines which said: > > type-token :=3D "original" / "human" / "automated" > > In many IETF working groups, when there is such a proposal, there is a > big discussion between the registryfull and the registryless > people. The first ones say there must be an authoritative list of > values (in the RFC or, better because more evolving, in an IANA > registry) so we can be sure of the interpretation of values. The > second ones say we can never capture all the nuances and subtleties of > the world in a fixed list. > > Here, I am not sure that the only meaningful distinction is between > "human" and "automated". Some humans do a very poor job, too. One > could suggest: > > type-token :=3D "original" / "professional-human" / "amateur-human" / > "automated-first-generation" / "automated-artificial-intelligence" / > "automated-the-robot-in-hollywood-movies" > > Or decide that it will be too complicated and we should instead > accept: > > type-token :=3D "original" / > > Toughts? > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org >=20 > https://www.ietf.org/mailman/l= istinfo/slim > > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org >=20 > https://www.ietf.org/mailman/l= istinfo/slim > > > > > -- > > ----------------------------------------------------------------- > Multiple Language Content Type Internet Draft: >=20 > http://= datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/ > ----------------------------------------------------------------- > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Experience should teach us to be most on our guard to protect liberty when the government's purposes are beneficent. Men born to freedom are naturally alert to repel invasion of their liberty by evil-minded rulers. The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well-meaning but without understanding. --Louis D. Brandeis From nobody Sat Jul 4 23:48:51 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E17F1B2BCE for ; Sat, 4 Jul 2015 23:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 lNuP_j5xiqbw for ; Sat, 4 Jul 2015 23:48:48 -0700 (PDT) Received: from bin-vsp-out-05.atm.binero.net (vsp-authed02.binero.net [195.74.38.226]) (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 D6C691B2BCB for ; Sat, 4 Jul 2015 23:48:47 -0700 (PDT) X-Halon-ID: e71116ec-22e1-11e5-8d68-005056916f53 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.43.70] (unknown [2.67.14.16]) by bin-vsp-out-05.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Sun, 5 Jul 2015 08:48:53 +0200 (CEST) Message-ID: <5598D34A.6070001@omnitor.se> Date: Sun, 05 Jul 2015 08:48:42 +0200 From: =?windows-1252?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Randall Gellens References: <20150703064908.GA14666@sources.org> <55964BED.1080905@omnitor.se> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] Translation Quality or type - or service provider X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2015 06:48:50 -0000 Another opportunity would be to convey a URI to the service provider who did (for mail) or can do(for real-time) the translation. Then experience with different service provider's production could give some idea of the expected quality. I can see great value in that for the real-time case, when the calling user has a favourite translator (e.g. relay service), and provides that as a hint if languages or modalities in the call does not match. Then the callee do not need to just take a service provider by chance that seem to match the language/modality profile but can take the one proposed by the caller. After working with the needs for emergency services to work across Europe for some time now, I think this is one of the few workable solutions. The user expresses both the language/modality needs and provides a URI to a favourite translation service provider, and the callee tries to fulfill the language/modality needs either by a matching original call taker or by invoking the proposed translation provider. /Gunnar Randall Gellens skrev den 2015-07-05 03:49: > My recollection is that this was discussed in email prior to Dallas, > but that's not important. > > I am a strong proponent of keeping things as simple as possible, > provided there is a way to extend them if experience shows that it is > needed. So, I think we should stick with the original suggestion of > three values ("original", "human", "automated"). This is simple enough > to be implementable and functional enough to be useful in providing a > hint that may help the client choose the best version for the user. > If we try and capture the various nuances of quality we will end up > with a very complex mechanism that is unlikely to be any more useful > in real life. Let's go with the simple approach now. If, after some > deployment experience we realize that we really do need extra > complexity, we can extend the mechanism then. > > At 4:29 PM +0100 7/3/15, Nik Tomkinson wrote: > >> Thanks for the responses. >> >> To deal with the issue with having only original/human/automated, >> what about the following?: >> >> >> translation-type := type-token[ ";" "q" "=" qvalue ] >> type-token :="human" / "automated" >> >> where qvalue is a value between 0 and 1 with a default of 0.5 if >> missing >> >> for example: >> >> Translation-Type: human;q=0.8 >> Translation-Type: automated;q=0.4 >> Translation-Type: human >> >> The Translation-Type SHOULD NOT appear in the original >> (untranslated) part but it SHOULD appear in translated content. >> >> Having this missing from the original text helps identify which is >> the source to be translated into further languages if the user mail >> client allows. >> >> This enables us to dispose of the 'original' value which didn't lend >> itself well to being graded on quality. >> >> The qvalue can be set by the sender or provided by the translation >> service. >> >> The draft suggests that: >> >> "Additionally, interactive implementations MAY offer the user a >> choice from among the available languages." so the qvalue may not >> need to be bulletproof. >> >> Comments? >> >> Nik. >> >> On 3 July 2015 at 09:46, Gunnar Hellström >> <gunnar.hellstrom@omnitor.se> wrote: >> >> I see some value of this kind of parameter also for the real-time case. >> The time is here when it can be possible in some situations to >> select between using a low-cost automatic speech-to-text generation >> and a higher cost captioned telephony or text-relay service (higher >> cost for someone, not always the end-user). >> >> But I agree that it is very hard to set good understandable values >> on a parameter expressing the type or quality of this kind of service. >> >> Gunnar >> >> >> >> Stephane Bortzmeyer skrev den 2015-07-03 08:49: >> >> On Thu, Jul 02, 2015 at 11:09:30PM +0100, >> Nik Tomkinson >> <rfc.nik.tomkinson@gmail.com> wrote >> a message of 109 lines which said: >> >> type-token := "original" / "human" / "automated" >> >> In many IETF working groups, when there is such a proposal, there is a >> big discussion between the registryfull and the registryless >> people. The first ones say there must be an authoritative list of >> values (in the RFC or, better because more evolving, in an IANA >> registry) so we can be sure of the interpretation of values. The >> second ones say we can never capture all the nuances and subtleties of >> the world in a fixed list. >> >> Here, I am not sure that the only meaningful distinction is between >> "human" and "automated". Some humans do a very poor job, too. One >> could suggest: >> >> type-token := "original" / "professional-human" / "amateur-human" / >> "automated-first-generation" / "automated-artificial-intelligence" / >> "automated-the-robot-in-hollywood-movies" >> >> Or decide that it will be too complicated and we should instead >> accept: >> >> type-token := "original" / >> >> Toughts? >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> >> https://www.ietf.org/mailman/listinfo/slim >> >> >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> >> https://www.ietf.org/mailman/listinfo/slim >> >> >> >> >> >> -- >> >> ----------------------------------------------------------------- >> Multiple Language Content Type Internet Draft: >> >> http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/ >> >> ----------------------------------------------------------------- >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim > > > -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Sun Jul 5 00:17:30 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8399C1B2BFF for ; Sun, 5 Jul 2015 00:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.011 X-Spam-Level: X-Spam-Status: No, score=-1.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=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 twsETp2ppx8D for ; Sun, 5 Jul 2015 00:17:29 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 069471B2BFC for ; Sun, 5 Jul 2015 00:17:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=In-Reply-To:To:References:Date:Subject:Mime-Version:Message-Id:Content-Type:From; bh=lNEWkGrb8Bz/TL+aHtpnbk8Y26q7aUe9/ssoNGLJ7+k=; b=Z+LfO9iDtqp/58kh9QMJs4GG+IguQ9Ah5DdOyg/JTAvO0Aym9tigJs21KeizLaKEF9J/3nytDK/zITet+InFyllNvcBfTMhHBcMXJ4XaYlq3oBwHDhTX1CsQU/pmackKLowyVF1f5s3HqRQCVcSdWcp4ks7gRF5/NkNzUVwXzJs=; Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:64093 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZBeB4-0000Ch-N0 for slim@ietf.org; Sun, 05 Jul 2015 00:17:28 -0700 From: Eric Burger Content-Type: multipart/alternative; boundary="Apple-Mail=_94DC6DED-4E7C-49DA-AA5D-25840C6AAE7E" Message-Id: <0A0D0CE1-01AC-411B-86B6-176A92C223A8@standardstrack.com> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Date: Sun, 5 Jul 2015 03:17:23 -0400 References: <20150703064908.GA14666@sources.org> <55964BED.1080905@omnitor.se> <5596B184.2020908@alum.mit.edu> To: slim@ietf.org In-Reply-To: <5596B184.2020908@alum.mit.edu> X-Mailer: Apple Mail (2.2098) X-OutGoing-Spam-Status: No, score=-0.4 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.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: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [Slim] Translation Quality or type X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2015 07:17:30 -0000 --Apple-Mail=_94DC6DED-4E7C-49DA-AA5D-25840C6AAE7E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I=92m agreeing here with Paul. /Maybe/ we could annotate something that = was machine translated. However, My justification is not to say how good = the translation is, but to let the user know they are NOT seeing the = original content. =20 > On Jul 3, 2015, at 12:00 PM, Paul Kyzivat = wrote: >=20 > On 7/3/15 4:46 AM, Gunnar Hellstr=F6m wrote: >> I see some value of this kind of parameter also for the real-time = case. >> The time is here when it can be possible in some situations to select >> between using a low-cost automatic speech-to-text generation and a >> higher cost captioned telephony or text-relay service (higher cost = for >> someone, not always the end-user). >>=20 >> But I agree that it is very hard to set good understandable values on = a >> parameter expressing the type or quality of this kind of service. >=20 > Yes. It is my understanding (2nd hand) there there are subjective = decisions (preferences) when choosing a translation service. >=20 > While I can see how having a rating attached might be conceptually = appealing, it is hard to imagine how it would be deployed in a way that = is useful. And it seems likely to be subject to endless haggling. >=20 > Seems like a rat hole. >=20 > Thanks, > Paul >=20 >> Gunnar >>=20 >>=20 >> Stephane Bortzmeyer skrev den 2015-07-03 08:49: >>> On Thu, Jul 02, 2015 at 11:09:30PM +0100, >>> Nik Tomkinson wrote >>> a message of 109 lines which said: >>>=20 >>>> type-token :=3D "original" / "human" / "automated" >>> In many IETF working groups, when there is such a proposal, there is = a >>> big discussion between the registryfull and the registryless >>> people. The first ones say there must be an authoritative list of >>> values (in the RFC or, better because more evolving, in an IANA >>> registry) so we can be sure of the interpretation of values. The >>> second ones say we can never capture all the nuances and subtleties = of >>> the world in a fixed list. >>>=20 >>> Here, I am not sure that the only meaningful distinction is between >>> "human" and "automated". Some humans do a very poor job, too. One >>> could suggest: >>>=20 >>> type-token :=3D "original" / "professional-human" / "amateur-human" = / >>> "automated-first-generation" / "automated-artificial-intelligence" / >>> "automated-the-robot-in-hollywood-movies" >>>=20 >>> Or decide that it will be too complicated and we should instead >>> accept: >>>=20 >>>> type-token :=3D "original" / >>> Toughts? >>>=20 >>> _______________________________________________ >>> SLIM mailing list >>> SLIM@ietf.org >>> https://www.ietf.org/mailman/listinfo/slim >>=20 >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim >>=20 >=20 > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim --Apple-Mail=_94DC6DED-4E7C-49DA-AA5D-25840C6AAE7E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I=92m agreeing here with Paul. /Maybe/ we could annotate = something that was machine translated. However, My justification is not = to say how good the translation is, but to let the user know they are = NOT seeing the original content.
 
On Jul 3, 2015, at 12:00 = PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

On 7/3/15 4:46 AM, Gunnar Hellstr=F6m wrote:
I see some value of this kind of parameter also for the = real-time case.
The time is here when it can be possible = in some situations to select
between using a low-cost = automatic speech-to-text generation and a
higher cost = captioned telephony or text-relay service (higher cost for
someone, not always the end-user).

But I agree that it is very hard to set good understandable = values on a
parameter expressing the type or quality of = this kind of service.

Yes. It = is my understanding (2nd hand) there there are subjective decisions = (preferences) when choosing a translation service.

While I can see how having a rating attached might be = conceptually appealing, it is hard to imagine how it would be deployed = in a way that is useful. And it seems likely to be subject to = endless haggling.

Seems like a rat hole.

Thanks,
Paul

Gunnar


Stephane Bortzmeyer skrev den 2015-07-03 = 08:49:
On Thu, Jul = 02, 2015 at 11:09:30PM +0100,
 Nik Tomkinson <rfc.nik.tomkinson@gmail.com> wrote
 a= message of 109 lines which said:

type-token :=3D "original" / "human" / = "automated"
In many IETF working groups, when = there is such a proposal, there is a
big discussion = between the registryfull and the registryless
people. The = first ones say there must be an authoritative list of
values= (in the RFC or, better because more evolving, in an IANA
registry) so we can be sure of the interpretation of values. = The
second ones say we can never capture all the nuances = and subtleties of
the world in a fixed list.

Here, I am not sure that the only meaningful = distinction is between
"human" and "automated". Some = humans do a very poor job, too. One
could suggest:

type-token :=3D "original" / = "professional-human" / "amateur-human" /
"automated-first-generation" / = "automated-artificial-intelligence" /
"automated-the-robot-in-hollywood-movies"

Or decide that it will be too complicated and we should = instead
accept:

type-token :=3D "original" / <free = text>
Toughts?

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

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


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

= --Apple-Mail=_94DC6DED-4E7C-49DA-AA5D-25840C6AAE7E-- From nobody Sun Jul 5 09:20:47 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007991ACD13 for ; Sun, 5 Jul 2015 09:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 Ws2s7uAMkCt1 for ; Sun, 5 Jul 2015 09:20:44 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D86DA1ACD11 for ; Sun, 5 Jul 2015 09:20:42 -0700 (PDT) Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-07v.sys.comcast.net with comcast id ogLH1q00427uzMh01gLhHH; Sun, 05 Jul 2015 16:20:41 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-02v.sys.comcast.net with comcast id ogLh1q00D3Ge9ey01gLhJ1; Sun, 05 Jul 2015 16:20:41 +0000 Message-ID: <55995958.5050109@alum.mit.edu> Date: Sun, 05 Jul 2015 12:20:40 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: slim@ietf.org References: <20150703064908.GA14666@sources.org> <55964BED.1080905@omnitor.se> <5598D34A.6070001@omnitor.se> In-Reply-To: <5598D34A.6070001@omnitor.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1436113241; bh=3xr7oWCTJyF3DW0TupqkveTJQzuxP26H8UQmS8BKzSc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=uD5WyG7V/+5sVY1AE3oGRFFBNrjog+L7yWQEplLZsztTbzHPZUHNp+hXMcgWM0FWi E3SVimKShd5gzvACv04AM+SlIQPSDnwXv3uvuOwoi+29ZFWUi7v9qDGxCZRHYOHGhJ 0MkU61x7lxm4G3zWEy3nZzNLA+9bqb1s6JsoqZFZ2zdB+fK0hu2abXyJ5vWvabkH1O 1PcdpQjAbuie9vBZ4bfel252o1y9koLhLZbVCpH4mDomPGNXtIKg89D4xG8Z5Eqc75 YyZeIdKpKW9hKcHmQnA4/pHi+zaf0Kw2dBPJyaHO4/RuvCq4gQjlIFG5PulT5CYUPW qub4Q1rkUlx+Q== Archived-At: Subject: Re: [Slim] Translation Quality or type - or service provider X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2015 16:20:46 -0000 Gunnar, I understand what you are suggesting, but I don't believe it is workable. This seems to mean that the caller would select the service while the callee would engage the service in the call if needed. Yet it is likely to be the caller who has a business relationship with the service, while the callee does not. Gets complicated quickly. ISTM it makes more sense to first figure out what is/isn't possible without translation, and then for a party that finds a translation service beneficial to engage one. Then the only concern is that both parties don't independently try to introduce equivalent translation services. For instance, a deaf caller might offer video media marked for sign language, and audio media on hold. If the answer doesn't accept the video, or doesn't indicate support for sign language, the caller could then conference in translation service, using the 3pcc transcoding model specified in rfc5369. (If that will take time, the deaf caller's UA could stream recorded media over the audio channel in the meantime.) Or, to get fancier, it would be possible to use preconditions to defer alerting the callee until this is all sorted out. My point is to let the participant who wants translation handle to setup of translation rather than depending on the other party to do something. Thanks, Paul On 7/5/15 2:48 AM, Gunnar Hellström wrote: > Another opportunity would be to convey a URI to the service provider who > did (for mail) or can do(for real-time) the translation. > Then experience with different service provider's production could give > some idea of the expected quality. > I can see great value in that for the real-time case, when the calling > user has a favourite translator (e.g. relay service), and provides that > as a hint if languages or modalities in the call does not match. Then > the callee do not need to just take a service provider by chance that > seem to match the language/modality profile but can take the one > proposed by the caller. > > After working with the needs for emergency services to work across > Europe for some time now, I think this is one of the few workable > solutions. The user expresses both the language/modality needs and > provides a URI to a favourite translation service provider, and the > callee tries to fulfill the language/modality needs either by a matching > original call taker or by invoking the proposed translation provider. > > /Gunnar > > > Randall Gellens skrev den 2015-07-05 03:49: >> My recollection is that this was discussed in email prior to Dallas, >> but that's not important. >> >> I am a strong proponent of keeping things as simple as possible, >> provided there is a way to extend them if experience shows that it is >> needed. So, I think we should stick with the original suggestion of >> three values ("original", "human", "automated"). This is simple enough >> to be implementable and functional enough to be useful in providing a >> hint that may help the client choose the best version for the user. If >> we try and capture the various nuances of quality we will end up with >> a very complex mechanism that is unlikely to be any more useful in >> real life. Let's go with the simple approach now. If, after some >> deployment experience we realize that we really do need extra >> complexity, we can extend the mechanism then. >> >> At 4:29 PM +0100 7/3/15, Nik Tomkinson wrote: >> >>> Thanks for the responses. >>> >>> To deal with the issue with having only original/human/automated, >>> what about the following?: >>> >>> >>> translation-type := type-token[ ";" "q" "=" qvalue ] >>> type-token :="human" / "automated" >>> >>> where qvalue is a value between 0 and 1 with a default of 0.5 if >>> missing >>> >>> for example: >>> >>> Translation-Type: human;q=0.8 >>> Translation-Type: automated;q=0.4 >>> Translation-Type: human >>> >>> The Translation-Type SHOULD NOT appear in the original >>> (untranslated) part but it SHOULD appear in translated content. >>> >>> Having this missing from the original text helps identify which is >>> the source to be translated into further languages if the user mail >>> client allows. >>> >>> This enables us to dispose of the 'original' value which didn't lend >>> itself well to being graded on quality. >>> >>> The qvalue can be set by the sender or provided by the translation >>> service. >>> >>> The draft suggests that: >>> >>> "Additionally, interactive implementations MAY offer the user a >>> choice from among the available languages." so the qvalue may not >>> need to be bulletproof. >>> >>> Comments? >>> >>> Nik. >>> >>> On 3 July 2015 at 09:46, Gunnar Hellström >>> <gunnar.hellstrom@omnitor.se> wrote: >>> >>> I see some value of this kind of parameter also for the real-time case. >>> The time is here when it can be possible in some situations to >>> select between using a low-cost automatic speech-to-text generation >>> and a higher cost captioned telephony or text-relay service (higher >>> cost for someone, not always the end-user). >>> >>> But I agree that it is very hard to set good understandable values >>> on a parameter expressing the type or quality of this kind of service. >>> >>> Gunnar >>> >>> >>> >>> Stephane Bortzmeyer skrev den 2015-07-03 08:49: >>> >>> On Thu, Jul 02, 2015 at 11:09:30PM +0100, >>> Nik Tomkinson >>> <rfc.nik.tomkinson@gmail.com> wrote >>> a message of 109 lines which said: >>> >>> type-token := "original" / "human" / "automated" >>> >>> In many IETF working groups, when there is such a proposal, there is a >>> big discussion between the registryfull and the registryless >>> people. The first ones say there must be an authoritative list of >>> values (in the RFC or, better because more evolving, in an IANA >>> registry) so we can be sure of the interpretation of values. The >>> second ones say we can never capture all the nuances and subtleties of >>> the world in a fixed list. >>> >>> Here, I am not sure that the only meaningful distinction is between >>> "human" and "automated". Some humans do a very poor job, too. One >>> could suggest: >>> >>> type-token := "original" / "professional-human" / "amateur-human" / >>> "automated-first-generation" / "automated-artificial-intelligence" / >>> "automated-the-robot-in-hollywood-movies" >>> >>> Or decide that it will be too complicated and we should instead >>> accept: >>> >>> type-token := "original" / >>> >>> Toughts? >>> >>> _______________________________________________ >>> SLIM mailing list >>> SLIM@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/slim >>> >>> >>> >>> _______________________________________________ >>> SLIM mailing list >>> SLIM@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/slim >>> >>> >>> >>> >>> >>> -- >>> >>> ----------------------------------------------------------------- >>> Multiple Language Content Type Internet Draft: >>> >>> http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/ >>> >>> ----------------------------------------------------------------- >>> >>> _______________________________________________ >>> SLIM mailing list >>> SLIM@ietf.org >>> https://www.ietf.org/mailman/listinfo/slim >> >> >> > From nobody Sun Jul 5 12:43:33 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E831A890A for ; Sun, 5 Jul 2015 12:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.711 X-Spam-Level: X-Spam-Status: No, score=-6.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 RQq5OgfEvzCo for ; Sun, 5 Jul 2015 12:43:29 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 329851A8904 for ; Sun, 5 Jul 2015 12:43:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1436125409; x=1467661409; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version:content-transfer-encoding; bh=FDotMdH1ZOsIyfllzHGP7GKEeMhsSZ044Wi5q45xdgQ=; b=qwP9K7KuQ7el+FqoLlPxQLRwfelJfSFTDb/PK0AHjGFJj8rsUNoFQY6U CBrXZjItW7LD9EGb4g1X+pBLDg64bJkYajjXoVH0lEuFlC6i5oMxPt5Pq tkwotkbMU3+cFXcPV+zaGEUjXsXub7KLABDJvryuLbV1BN8pYzzx/c/j+ s=; X-IronPort-AV: E=McAfee;i="5700,7163,7853"; a="218948225" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Jul 2015 12:43:28 -0700 X-IronPort-AV: E=Sophos;i="5.15,410,1432623600"; d="scan'208";a="1007129852" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 05 Jul 2015 12:43:27 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Sun, 5 Jul 2015 12:43:27 -0700 Message-ID: In-Reply-To: <5598D34A.6070001@omnitor.se> References: <20150703064908.GA14666@sources.org> <55964BED.1080905@omnitor.se> <5598D34A.6070001@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Sun, 5 Jul 2015 12:43:25 -0700 To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , Randall Gellens From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01F.na.qualcomm.com (10.85.0.32) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] Translation Quality or type - or service provider X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2015 19:43:32 -0000 Having the caller provide a URI to the caller's=20 preferred service might possibly work for=20 person-to-person calling, but seems completely=20 unworkable for the call center and emergency=20 services cases. At 8:48 AM +0200 7/5/15, Gunnar Hellstr=F6m wrote: > Another opportunity would be to convey a URI to=20 > the service provider who did (for mail) or can=20 > do(for real-time) the translation. > Then experience with different service=20 > provider's production could give some idea of=20 > the expected quality. > I can see great value in that for the real-time=20 > case, when the calling user has a favourite=20 > translator (e.g. relay service), and provides=20 > that as a hint if languages or modalities in=20 > the call does not match. Then the callee do not=20 > need to just take a service provider by chance=20 > that seem to match the language/modality=20 > profile but can take the one proposed by the=20 > caller. > > After working with the needs for emergency=20 > services to work across Europe for some time=20 > now, I think this is one of the few workable=20 > solutions. The user expresses both the=20 > language/modality needs and provides a URI to a=20 > favourite translation service provider, and the=20 > callee tries to fulfill the language/modality=20 > needs either by a matching original call taker=20 > or by invoking the proposed translation=20 > provider. > > /Gunnar > > > Randall Gellens skrev den 2015-07-05 03:49: >> My recollection is that this was discussed in=20 >> email prior to Dallas, but that's not=20 >> important. >> >> I am a strong proponent of keeping things as=20 >> simple as possible, provided there is a way to=20 >> extend them if experience shows that it is=20 >> needed. So, I think we should stick with the=20 >> original suggestion of three values=20 >> ("original", "human", "automated"). This is=20 >> simple enough to be implementable and=20 >> functional enough to be useful in providing a=20 >> hint that may help the client choose the best=20 >> version for the user. If we try and capture=20 >> the various nuances of quality we will end up=20 >> with a very complex mechanism that is unlikely=20 >> to be any more useful in real life. Let's go=20 >> with the simple approach now. If, after some=20 >> deployment experience we realize that we=20 >> really do need extra complexity, we can extend=20 >> the mechanism then. >> >> At 4:29 PM +0100 7/3/15, Nik Tomkinson wrote: >> >>> Thanks for the responses. >>> >>> To deal with the issue with having only=20 >>> original/human/automated, what about the=20 >>> following?: >>> >>> >>> translation-type :=3D type-token[ ";" "q" "=3D" qvalue ] >>> type-token :=3D"human" / "automated" >>> >>> where qvalue is a value between 0 and 1 with a default of 0.5 if missi= ng >>> >>> for example: >>> >>> Translation-Type: human;q=3D0.8 >>> Translation-Type: automated;q=3D0.4 >>> Translation-Type: human >>> >>> The Translation-Type SHOULD NOT appear in=20 >>> the original (untranslated) part but it=20 >>> SHOULD appear in translated content. >>> >>> Having this missing from the original text=20 >>> helps identify which is the source to be=20 >>> translated into further languages if the user=20 >>> mail client allows. >>> >>> This enables us to dispose of the 'original'=20 >>> value which didn't lend itself well to being=20 >>> graded on quality. >>> >>> The qvalue can be set by the sender or=20 >>> provided by the translation service. >>> >>> The draft suggests that: >>> >>> "Additionally, interactive implementations=20 >>> MAY offer the user a choice from among the=20 >>> available languages." so the qvalue may not=20 >>> need to be bulletproof. >>> >>> Comments? >>> >>> Nik. >>> >>> On 3 July 2015 at 09:46, Gunnar Hellstr=F6m=20 >>> <gunnar.hellstrom@omnitor.se>=20 >>> wrote: >>> >>> I see some value of this kind of parameter also for the real-time case= =2E >>> The time is here when it can be possible in=20 >>> some situations to select between using a=20 >>> low-cost automatic speech-to-text generation=20 >>> and a higher cost captioned telephony or=20 >>> text-relay service (higher cost for someone,=20 >>> not always the end-user). >>> >>> But I agree that it is very hard to set good=20 >>> understandable values on a parameter=20 >>> expressing the type or quality of this kind=20 >>> of service. >>> >>> Gunnar >>> >>> >>> >>> Stephane Bortzmeyer skrev den 2015-07-03 08:49: >>> >>> On Thu, Jul 02, 2015 at 11:09:30PM +0100, >>> Nik Tomkinson=20 >>> <rfc.nik.tomkinson@gmail.com>=20 >>> wrote >>> a message of 109 lines which said: >>> >>> type-token :=3D "original" / "human" / "automated" >>> >>> In many IETF working groups, when there is such a proposal, there is a >>> big discussion between the registryfull and the registryless >>> people. The first ones say there must be an authoritative list of >>> values (in the RFC or, better because more evolving, in an IANA >>> registry) so we can be sure of the interpretation of values. The >>> second ones say we can never capture all the nuances and subtleties of >>> the world in a fixed list. >>> >>> Here, I am not sure that the only meaningful distinction is between >>> "human" and "automated". Some humans do a very poor job, too. One >>> could suggest: >>> >>> type-token :=3D "original" / "professional-human" / "amateur-human" / >>> "automated-first-generation" / "automated-artificial-intelligence" / >>> "automated-the-robot-in-hollywood-movies" >>> >>> Or decide that it will be too complicated and we should instead >>> accept: >>> >>> type-token :=3D "original" / >>> >>> Toughts? >>> >>> _______________________________________________ >>> SLIM mailing list >>> SLIM@ietf.org >>> >>>=20 >>> https://www.ietf.org/mailman= /listinfo/slim >>> >>> >>> _______________________________________________ >>> SLIM mailing list >>> SLIM@ietf.org >>> >>>=20 >>> https://www.ietf.org/mailman= /listinfo/slim >>> >>> >>> >>> >>> -- >>> >>> ----------------------------------------------------------------- >>> Multiple Language Content Type Internet Draft: >>> >>>=20 >>> http:= //datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/ >>> ----------------------------------------------------------------- >>> >>> _______________________________________________ >>> SLIM mailing list >>> SLIM@ietf.org >>> https://www.ietf.org/mailman/listinfo/slim >> >> >> > > -- > ----------------------------------------- > Gunnar Hellstr=F6m > Omnitor > gunnar.hellstrom@omnitor.se > +46 708 204 288 > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Surstrommingspremier (SEUR-stomins-prem-ya; Swedish; noun): The first day of the year when it is acceptable eat Surstromming, extremely foul-smelling fermented herring (banned in some apartment complexes, airplanes, etc.) -- literally, "sour fish premier." From nobody Sun Jul 5 13:36:01 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D641A6F17 for ; Sun, 5 Jul 2015 13:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 F6sKvJ0fZZlC for ; Sun, 5 Jul 2015 13:35:58 -0700 (PDT) Received: from bin-vsp-out-03.atm.binero.net (vsp-unauthed01.binero.net [195.74.38.225]) (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 873C61ACEA5 for ; Sun, 5 Jul 2015 13:35:57 -0700 (PDT) X-Halon-ID: 6c35ce72-2355-11e5-8f5b-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.43.70] (unknown [2.65.89.236]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Sun, 5 Jul 2015 22:35:49 +0200 (CEST) Message-ID: <55999526.7030006@omnitor.se> Date: Sun, 05 Jul 2015 22:35:50 +0200 From: =?windows-1252?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Paul Kyzivat , slim@ietf.org References: <20150703064908.GA14666@sources.org> <55964BED.1080905@omnitor.se> <5598D34A.6070001@omnitor.se> <55995958.5050109@alum.mit.edu> In-Reply-To: <55995958.5050109@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] Translation Quality or type - or service provider X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2015 20:36:00 -0000 Paul, Yes, I agree that for most cases it is best that the party, who knows a service that will do the translation, does the invocation. And, yes ,in that scenario the 3PCC method seems suitable. My proposal to send the service provider URI together with the modality indications was for the case when there are strong policy reasons why one party would do the invocation, but little chance that that party would have access to an up-to-date information on available translation providers. That could be the case for the emergency service calling in a multi-language environment, also including support for sign language users. Since both you and Randall think it is not doable, we can try to use the principle that the party, who knows a service that will do the translation, does the invocation. That brings us back to a need for more stringent language/modality negotiation in order to avoid both double invocation of services when one or none is required, and also avoid no invocation when one is needed. Paul Kyzivat skrev den 2015-07-05 18:20: > Gunnar, > > I understand what you are suggesting, but I don't believe it is > workable. This seems to mean that the caller would select the service > while the callee would engage the service in the call if needed. Yet > it is likely to be the caller who has a business relationship with the > service, while the callee does not. Gets complicated quickly. > > ISTM it makes more sense to first figure out what is/isn't possible > without translation, and then for a party that finds a translation > service beneficial to engage one. Then the only concern is that both > parties don't independently try to introduce equivalent translation > services. > > For instance, a deaf caller might offer video media marked for sign > language, and audio media on hold. If the answer doesn't accept the > video, or doesn't indicate support for sign language, the caller could > then conference in translation service, using the 3pcc transcoding > model specified in rfc5369. (If that will take time, the deaf caller's > UA could stream recorded media over the audio channel in the meantime.) > > Or, to get fancier, it would be possible to use preconditions to defer > alerting the callee until this is all sorted out. > > My point is to let the participant who wants translation handle to > setup of translation rather than depending on the other party to do > something. OK, it might be likely that both parties "want" translation, but one has better knowledge about how to get the required service and has business relations with the service. So then it is preferred that that party invokes. Good /Gunnar > > Thanks, > Paul > > On 7/5/15 2:48 AM, Gunnar Hellström wrote: >> Another opportunity would be to convey a URI to the service provider who >> did (for mail) or can do(for real-time) the translation. >> Then experience with different service provider's production could give >> some idea of the expected quality. >> I can see great value in that for the real-time case, when the calling >> user has a favourite translator (e.g. relay service), and provides that >> as a hint if languages or modalities in the call does not match. Then >> the callee do not need to just take a service provider by chance that >> seem to match the language/modality profile but can take the one >> proposed by the caller. >> >> After working with the needs for emergency services to work across >> Europe for some time now, I think this is one of the few workable >> solutions. The user expresses both the language/modality needs and >> provides a URI to a favourite translation service provider, and the >> callee tries to fulfill the language/modality needs either by a matching >> original call taker or by invoking the proposed translation provider. >> >> /Gunnar >> >> >> Randall Gellens skrev den 2015-07-05 03:49: >>> My recollection is that this was discussed in email prior to Dallas, >>> but that's not important. >>> >>> I am a strong proponent of keeping things as simple as possible, >>> provided there is a way to extend them if experience shows that it is >>> needed. So, I think we should stick with the original suggestion of >>> three values ("original", "human", "automated"). This is simple enough >>> to be implementable and functional enough to be useful in providing a >>> hint that may help the client choose the best version for the user. If >>> we try and capture the various nuances of quality we will end up with >>> a very complex mechanism that is unlikely to be any more useful in >>> real life. Let's go with the simple approach now. If, after some >>> deployment experience we realize that we really do need extra >>> complexity, we can extend the mechanism then. >>> >>> At 4:29 PM +0100 7/3/15, Nik Tomkinson wrote: >>> >>>> Thanks for the responses. >>>> >>>> To deal with the issue with having only original/human/automated, >>>> what about the following?: >>>> >>>> >>>> translation-type := type-token[ ";" "q" "=" qvalue ] >>>> type-token :="human" / "automated" >>>> >>>> where qvalue is a value between 0 and 1 with a default of 0.5 if >>>> missing >>>> >>>> for example: >>>> >>>> Translation-Type: human;q=0.8 >>>> Translation-Type: automated;q=0.4 >>>> Translation-Type: human >>>> >>>> The Translation-Type SHOULD NOT appear in the original >>>> (untranslated) part but it SHOULD appear in translated content. >>>> >>>> Having this missing from the original text helps identify which is >>>> the source to be translated into further languages if the user mail >>>> client allows. >>>> >>>> This enables us to dispose of the 'original' value which didn't lend >>>> itself well to being graded on quality. >>>> >>>> The qvalue can be set by the sender or provided by the translation >>>> service. >>>> >>>> The draft suggests that: >>>> >>>> "Additionally, interactive implementations MAY offer the user a >>>> choice from among the available languages." so the qvalue may not >>>> need to be bulletproof. >>>> >>>> Comments? >>>> >>>> Nik. >>>> >>>> On 3 July 2015 at 09:46, Gunnar Hellström >>>> <gunnar.hellstrom@omnitor.se> >>>> wrote: >>>> >>>> I see some value of this kind of parameter also for the real-time >>>> case. >>>> The time is here when it can be possible in some situations to >>>> select between using a low-cost automatic speech-to-text generation >>>> and a higher cost captioned telephony or text-relay service (higher >>>> cost for someone, not always the end-user). >>>> >>>> But I agree that it is very hard to set good understandable values >>>> on a parameter expressing the type or quality of this kind of service. >>>> >>>> Gunnar >>>> >>>> >>>> >>>> Stephane Bortzmeyer skrev den 2015-07-03 08:49: >>>> >>>> On Thu, Jul 02, 2015 at 11:09:30PM +0100, >>>> Nik Tomkinson >>>> <rfc.nik.tomkinson@gmail.com> >>>> wrote >>>> a message of 109 lines which said: >>>> >>>> type-token := "original" / "human" / "automated" >>>> >>>> In many IETF working groups, when there is such a proposal, there >>>> is a >>>> big discussion between the registryfull and the registryless >>>> people. The first ones say there must be an authoritative list of >>>> values (in the RFC or, better because more evolving, in an IANA >>>> registry) so we can be sure of the interpretation of values. The >>>> second ones say we can never capture all the nuances and >>>> subtleties of >>>> the world in a fixed list. >>>> >>>> Here, I am not sure that the only meaningful distinction is between >>>> "human" and "automated". Some humans do a very poor job, too. One >>>> could suggest: >>>> >>>> type-token := "original" / "professional-human" / "amateur-human" / >>>> "automated-first-generation" / "automated-artificial-intelligence" / >>>> "automated-the-robot-in-hollywood-movies" >>>> >>>> Or decide that it will be too complicated and we should instead >>>> accept: >>>> >>>> type-token := "original" / >>>> >>>> Toughts? >>>> >>>> _______________________________________________ >>>> SLIM mailing list >>>> SLIM@ietf.org >>>> >>>> https://www.ietf.org/mailman/listinfo/slim >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> SLIM mailing list >>>> SLIM@ietf.org >>>> >>>> https://www.ietf.org/mailman/listinfo/slim >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> ----------------------------------------------------------------- >>>> Multiple Language Content Type Internet Draft: >>>> >>>> http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/ >>>> >>>> >>>> ----------------------------------------------------------------- >>>> >>>> _______________________________________________ >>>> SLIM mailing list >>>> SLIM@ietf.org >>>> https://www.ietf.org/mailman/listinfo/slim >>> >>> >>> >> > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Sun Jul 5 14:10:47 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A11141A00C6 for ; Sun, 5 Jul 2015 14:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 wjha89pRdflQ for ; Sun, 5 Jul 2015 14:10:43 -0700 (PDT) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (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 2FFC61A00C1 for ; Sun, 5 Jul 2015 14:10:43 -0700 (PDT) Received: by ykeo3 with SMTP id o3so12408339yke.0 for ; Sun, 05 Jul 2015 14:10:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HtQdbzYm7aQQ1AF4nzRsjnXf9Bb1eoLcJH+3G4BwvM0=; b=lv9x8O6OLfKZAV0cD2omxlPu7eGmXVjRs8ggKzqr7O9H0HJgw2aJ8bwIqyJkhlGu4Y 3HBaXV9qXY9LJTMDpvSCcP3H3LofWFFOIT/1+Abm+Lvb1+xAjuX2YguMdVc22fooAufi ZXNK/4ZEB/UaiZ3gqwiRjI/HbefITStC/15ufDpnYOPyM/hitBRp64BGMXZQsz4W2KWy wfURlWlSWxBNEiJa7794B0C80NQpugGIaVtde+Kc88JywRFWKvRESl5rGyw2n+9HwrBh 2Hph7IxxQGeluQbB8YMPwdhvE38k6VPiVJs6mE2TNm8vqSIoll6zGwIu5aclCKfza81B nPjA== MIME-Version: 1.0 X-Received: by 10.13.226.203 with SMTP id l194mr52859364ywe.103.1436130642550; Sun, 05 Jul 2015 14:10:42 -0700 (PDT) Received: by 10.37.112.7 with HTTP; Sun, 5 Jul 2015 14:10:42 -0700 (PDT) In-Reply-To: <0A0D0CE1-01AC-411B-86B6-176A92C223A8@standardstrack.com> References: <20150703064908.GA14666@sources.org> <55964BED.1080905@omnitor.se> <5596B184.2020908@alum.mit.edu> <0A0D0CE1-01AC-411B-86B6-176A92C223A8@standardstrack.com> Date: Sun, 5 Jul 2015 22:10:42 +0100 Message-ID: From: Nik Tomkinson To: Eric Burger Content-Type: multipart/alternative; boundary=001a114fbcb6cce500051a273841 Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] Translation Quality or type X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2015 21:10:45 -0000 --001a114fbcb6cce500051a273841 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks again for the responses. I think that I will add the original suggestion of: translation-type :=3D type-token type-token :=3D "original" / "human" / "automated" into the next version of the non-real-time I-D and (as Randall suggests) if during some deployment trials we find that making the distinction between 'automated' and 'human' is not granular enough (or there are other changes required) we can update it further. I will start on this update now and have it ready to submit before the cut-off deadline tomorrow night (23:59 UTC Monday). Nik. On 5 July 2015 at 08:17, Eric Burger wrote: > I=E2=80=99m agreeing here with Paul. /Maybe/ we could annotate something = that was > machine translated. However, My justification is not to say how good the > translation is, but to let the user know they are NOT seeing the original > content. > > > On Jul 3, 2015, at 12:00 PM, Paul Kyzivat wrote: > > On 7/3/15 4:46 AM, Gunnar Hellstr=C3=B6m wrote: > > I see some value of this kind of parameter also for the real-time case. > The time is here when it can be possible in some situations to select > between using a low-cost automatic speech-to-text generation and a > higher cost captioned telephony or text-relay service (higher cost for > someone, not always the end-user). > > But I agree that it is very hard to set good understandable values on a > parameter expressing the type or quality of this kind of service. > > > Yes. It is my understanding (2nd hand) there there are subjective > decisions (preferences) when choosing a translation service. > > While I can see how having a rating attached might be conceptually > appealing, it is hard to imagine how it would be deployed in a way that i= s > useful. And it seems likely to be subject to endless haggling. > > Seems like a rat hole. > > Thanks, > Paul > > Gunnar > > > Stephane Bortzmeyer skrev den 2015-07-03 08:49: > > On Thu, Jul 02, 2015 at 11:09:30PM +0100, > Nik Tomkinson wrote > a message of 109 lines which said: > > type-token :=3D "original" / "human" / "automated" > > In many IETF working groups, when there is such a proposal, there is a > big discussion between the registryfull and the registryless > people. The first ones say there must be an authoritative list of > values (in the RFC or, better because more evolving, in an IANA > registry) so we can be sure of the interpretation of values. The > second ones say we can never capture all the nuances and subtleties of > the world in a fixed list. > > Here, I am not sure that the only meaningful distinction is between > "human" and "automated". Some humans do a very poor job, too. One > could suggest: > > type-token :=3D "original" / "professional-human" / "amateur-human" / > "automated-first-generation" / "automated-artificial-intelligence" / > "automated-the-robot-in-hollywood-movies" > > Or decide that it will be too complicated and we should instead > accept: > > type-token :=3D "original" / > > Toughts? > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim > > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim > > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim > > > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim > > --=20 ----------------------------------------------------------------- Multiple Language Content Type Internet Draft: http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/ ----------------------------------------------------------------- --001a114fbcb6cce500051a273841 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks again for the responses.

I think= that I will add the original suggestion of:

translation-type := =3D type-token
type-token :=3D "original" / "human= " / "automated"

into the next= version of the non-real-time I-D and (as Randall suggests) if during some = deployment trials we find that making the distinction between 'automate= d' and 'human' is not granular enough (or there are other chang= es required) we can update it further.=C2=A0

I wil= l start on this update now and have it ready to submit before the cut-off d= eadline tomorrow night (23:59 UTC Monday).

Nik.

On 5 Jul= y 2015 at 08:17, Eric Burger <eburger@standardstrack.com><= /span> wrote:
I=E2=80=99m agreeing here with Paul. /Maybe/ we could annotate som= ething that was machine translated. However, My justification is not to say= how good the translation is, but to let the user know they are NOT seeing = the original content.
=C2=A0
On Jul 3, 2015, at 12:00 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote= :

On 7/3/15 4:46 AM, Gunnar Hellstr=C3=B6m wrote:
I see some value of this kind of parameter also for the= real-time case.
The time is here when it can be possible in some situat= ions to select
between using a low-cost automatic speech-to-text generat= ion and a
higher cost captioned telephony or text-relay service (higher = cost for
someone, not always the end-user).

But I agree that it i= s very hard to set good understandable values on a
parameter expressing = the type or quality of this kind of service.

Yes. It is= my understanding (2nd hand) there there are subjective decisions (preferen= ces) when choosing a translation service.

While I can see how having= a rating attached might be conceptually appealing, it is hard to imagine h= ow it would be deployed in a way that is useful. And it seems likely to=C2= =A0be subject to endless haggling.

Seems like a rat hole.

Thanks,
Paul

Gunna= r


Stephane Bortzmeyer skrev den 2015-07-03 08:49:
On Thu, Jul 02, 2015 at 11:09:30PM +0100,
=C2=A0Nik Tomki= nson <r= fc.nik.tomkinson@gmail.com> wrote
=C2=A0a message of 109 lines wh= ich said:

type-token :=3D "original&q= uot; / "human" / "automated"
In many IE= TF working groups, when there is such a proposal, there is a
big discuss= ion between the registryfull and the registryless
people. The first ones= say there must be an authoritative list of
values (in the RFC or, bette= r because more evolving, in an IANA
registry) so we can be sure of the i= nterpretation of values. The
second ones say we can never capture all th= e nuances and subtleties of
the world in a fixed list.

Here, I am= not sure that the only meaningful distinction is between
"human&qu= ot; and "automated". Some humans do a very poor job, too. One
= could suggest:

type-token :=3D "original" / "professi= onal-human" / "amateur-human" /
"automated-first-gen= eration" / "automated-artificial-intelligence" /
"au= tomated-the-robot-in-hollywood-movies"

Or decide that it will b= e too complicated and we should instead
accept:

type-token :=3D "original" / <free text>
Toughts?

_______________________________________________
= SLIM mailing list
SLI= M@ietf.org
https://www.ietf.org/mailman/listinfo/slim

_______________________________________________
SLIM mailing lis= t
SLIM@ietf.org= https://www.ietf.org/mailman/listinfo/slim


____= ___________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.= ietf.org/mailman/listinfo/slim


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




-- 
---------------------------------=
--------------------------------
Multiple Language Content Type Internet=
 Draft:
http://datatracker.ietf.org/doc/draft-tomkins= on-slim-multilangcontent/
--------------------------------------------------------------=
---
--001a114fbcb6cce500051a273841-- From nobody Sun Jul 5 15:04:51 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02811A8A72 for ; Sun, 5 Jul 2015 15:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 sRQVtIBl6fQK for ; Sun, 5 Jul 2015 15:04:48 -0700 (PDT) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62E261A8A6D for ; Sun, 5 Jul 2015 15:04:48 -0700 (PDT) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-04v.sys.comcast.net with comcast id om3k1q0022S2Q5R01m4n8P; Sun, 05 Jul 2015 22:04:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-16v.sys.comcast.net with comcast id om4n1q0053Ge9ey01m4nP1; Sun, 05 Jul 2015 22:04:47 +0000 Message-ID: <5599A9FE.60401@alum.mit.edu> Date: Sun, 05 Jul 2015 18:04:46 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: slim@ietf.org References: <20150703064908.GA14666@sources.org> <55964BED.1080905@omnitor.se> <5596B184.2020908@alum.mit.edu> <0A0D0CE1-01AC-411B-86B6-176A92C223A8@standardstrack.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1436133887; bh=Ns8ODWwhToaxJu5A9QUzuB2FJx0YIpAflT7+LRMN23w=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=AuWE1WMY5WBzi2dQq+zL+gSUT7YcDJRRVjxosredy2tE3UilZS0Im2AShomzITwnz oNFCRPPsKGArhNzx4QNNfjRh962b8aVoRs3ddBzWkBjU+NQ5/4C3q84qouEWRqVpEG HDoTi2t2CjChVqrLqs3R6xAqOmCR3G7SEUlH0PMv2MMCjg7bjH0sKTTmTkaOczEDOR AIsSji5ACio0xhClw57CPQGvObDr2WrU5sEpm4ByxDo9lQQZbcs/ToKcScvvDZ+Zr3 KLC+cPy03lBZjalgBvDvKuGAbu27xiBwkQr5/8uUn20VrAziF4mlEVrRA7qPFgrQZr wcQu9rQNYJR0w== Archived-At: Subject: Re: [Slim] Translation Quality or type X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2015 22:04:50 -0000 On 7/5/15 5:10 PM, Nik Tomkinson wrote: > Thanks again for the responses. > > I think that I will add the original suggestion of: > > translation-type := type-token > type-token := "original" / "human" / "automated" This seems "ok" - more or less harmless and possibly helpful in some cases. But I'm concerned that it will lead to an assumption that "human" is *better* than "automated". That is probably true in most practical cases today. But surely there are *some* automated translations that are better than *some* human translations. And that will become the case more often in the future. Thanks, Paul > into the next version of the non-real-time I-D and (as Randall suggests) > if during some deployment trials we find that making the distinction > between 'automated' and 'human' is not granular enough (or there are > other changes required) we can update it further. > > I will start on this update now and have it ready to submit before the > cut-off deadline tomorrow night (23:59 UTC Monday). > > Nik. > > On 5 July 2015 at 08:17, Eric Burger > wrote: > > I’m agreeing here with Paul. /Maybe/ we could annotate something > that was machine translated. However, My justification is not to say > how good the translation is, but to let the user know they are NOT > seeing the original content. > >> On Jul 3, 2015, at 12:00 PM, Paul Kyzivat > > wrote: >> >> On 7/3/15 4:46 AM, Gunnar Hellström wrote: >>> I see some value of this kind of parameter also for the real-time >>> case. >>> The time is here when it can be possible in some situations to select >>> between using a low-cost automatic speech-to-text generation and a >>> higher cost captioned telephony or text-relay service (higher >>> cost for >>> someone, not always the end-user). >>> >>> But I agree that it is very hard to set good understandable >>> values on a >>> parameter expressing the type or quality of this kind of service. >> >> Yes. It is my understanding (2nd hand) there there are subjective >> decisions (preferences) when choosing a translation service. >> >> While I can see how having a rating attached might be conceptually >> appealing, it is hard to imagine how it would be deployed in a way >> that is useful. And it seems likely to be subject to endless haggling. >> >> Seems like a rat hole. >> >> Thanks, >> Paul >> >>> Gunnar >>> >>> >>> Stephane Bortzmeyer skrev den 2015-07-03 08:49: >>>> On Thu, Jul 02, 2015 at 11:09:30PM +0100, >>>> Nik Tomkinson >>> > wrote >>>> a message of 109 lines which said: >>>> >>>>> type-token := "original" / "human" / "automated" >>>> In many IETF working groups, when there is such a proposal, >>>> there is a >>>> big discussion between the registryfull and the registryless >>>> people. The first ones say there must be an authoritative list of >>>> values (in the RFC or, better because more evolving, in an IANA >>>> registry) so we can be sure of the interpretation of values. The >>>> second ones say we can never capture all the nuances and >>>> subtleties of >>>> the world in a fixed list. >>>> >>>> Here, I am not sure that the only meaningful distinction is between >>>> "human" and "automated". Some humans do a very poor job, too. One >>>> could suggest: >>>> >>>> type-token := "original" / "professional-human" / "amateur-human" / >>>> "automated-first-generation" / "automated-artificial-intelligence" / >>>> "automated-the-robot-in-hollywood-movies" >>>> >>>> Or decide that it will be too complicated and we should instead >>>> accept: >>>> >>>>> type-token := "original" / >>>> Toughts? >>>> >>>> _______________________________________________ >>>> SLIM mailing list >>>> SLIM@ietf.org >>>> https://www.ietf.org/mailman/listinfo/slim >>> >>> _______________________________________________ >>> SLIM mailing list >>> SLIM@ietf.org >>> https://www.ietf.org/mailman/listinfo/slim >>> >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim > > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim > > > > > -- > > ----------------------------------------------------------------- > Multiple Language Content Type Internet Draft: > > http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/ > > ----------------------------------------------------------------- > > > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim > From nobody Sun Jul 5 15:18:49 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D52661A90AE for ; Sun, 5 Jul 2015 15:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 rcqeuFtgRfBt for ; Sun, 5 Jul 2015 15:18:46 -0700 (PDT) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (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 E4C781A8AE9 for ; Sun, 5 Jul 2015 15:18:45 -0700 (PDT) Received: by ykeo3 with SMTP id o3so13109228yke.0 for ; Sun, 05 Jul 2015 15:18:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WZJB+7uct+0zLTnaG+JOIf/0a8McLwWT73jhARWNNHs=; b=jXwHjWPk6Kw7kRULcyflmAUPPrYTkGo7w7Yw46Aig1lFVGzqP/pLyS0sbkCxR52tLM uw+JJFJJuhd83BlqBvESnLHF2QPVK8cMJfB2HReHiO1H+utcOwUFPAgQlxvf4Mr0cMTd bO10bq6oNnYEJFllGbQHbr5dtUIXHnGhAnQXt5siCs5cFW40HUdhuMXF1I86h0CFkych BtzUw+9vhxvGiLY4T60FUhRFhFeFFYOaJiz34y/AbdGY7BSlOpp2j9rltnFkX3zlKr/M kYyH003gs/ZhNNZwrY7DJ7BvfwIEynDbistil6a8cCQVnlNqoBwuP3bnTvYhItyQ9czo WG3Q== MIME-Version: 1.0 X-Received: by 10.170.80.5 with SMTP id w5mr572665ykw.121.1436134725302; Sun, 05 Jul 2015 15:18:45 -0700 (PDT) Received: by 10.37.112.7 with HTTP; Sun, 5 Jul 2015 15:18:45 -0700 (PDT) In-Reply-To: <5599A9FE.60401@alum.mit.edu> References: <20150703064908.GA14666@sources.org> <55964BED.1080905@omnitor.se> <5596B184.2020908@alum.mit.edu> <0A0D0CE1-01AC-411B-86B6-176A92C223A8@standardstrack.com> <5599A9FE.60401@alum.mit.edu> Date: Sun, 5 Jul 2015 23:18:45 +0100 Message-ID: From: Nik Tomkinson To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a113995ec26bcd2051a282c59 Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] Translation Quality or type X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2015 22:18:49 -0000 --001a113995ec26bcd2051a282c59 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Paul, yes, they were my thoughts behind suggesting the qvalue to identify the quality of the translation and to avoid the implication that a machine translation is always worse than a human one. But I think I would prefer to start off simply and add complexity if it is required in a later version of the draft. The qvalue parameter could be added retrospectively to the Translation-Type field. I think this will be an area to discuss in Prague and also explore/test when doing some trial implementations. Thanks, Nik. On 5 July 2015 at 23:04, Paul Kyzivat wrote: > On 7/5/15 5:10 PM, Nik Tomkinson wrote: > >> Thanks again for the responses. >> >> I think that I will add the original suggestion of: >> >> translation-type :=3D type-token >> type-token :=3D "original" / "human" / "automated" >> > > This seems "ok" - more or less harmless and possibly helpful in some case= s. > > But I'm concerned that it will lead to an assumption that "human" is > *better* than "automated". That is probably true in most practical cases > today. But surely there are *some* automated translations that are better > than *some* human translations. And that will become the case more often = in > the future. > > Thanks, > Paul > > into the next version of the non-real-time I-D and (as Randall suggests) >> if during some deployment trials we find that making the distinction >> between 'automated' and 'human' is not granular enough (or there are >> other changes required) we can update it further. >> >> I will start on this update now and have it ready to submit before the >> cut-off deadline tomorrow night (23:59 UTC Monday). >> >> Nik. >> >> On 5 July 2015 at 08:17, Eric Burger > > wrote: >> >> I=E2=80=99m agreeing here with Paul. /Maybe/ we could annotate somet= hing >> that was machine translated. However, My justification is not to say >> how good the translation is, but to let the user know they are NOT >> seeing the original content. >> >> On Jul 3, 2015, at 12:00 PM, Paul Kyzivat >> > wrote: >>> >>> On 7/3/15 4:46 AM, Gunnar Hellstr=C3=B6m wrote: >>> >>>> I see some value of this kind of parameter also for the real-time >>>> case. >>>> The time is here when it can be possible in some situations to >>>> select >>>> between using a low-cost automatic speech-to-text generation and a >>>> higher cost captioned telephony or text-relay service (higher >>>> cost for >>>> someone, not always the end-user). >>>> >>>> But I agree that it is very hard to set good understandable >>>> values on a >>>> parameter expressing the type or quality of this kind of service. >>>> >>> >>> Yes. It is my understanding (2nd hand) there there are subjective >>> decisions (preferences) when choosing a translation service. >>> >>> While I can see how having a rating attached might be conceptually >>> appealing, it is hard to imagine how it would be deployed in a way >>> that is useful. And it seems likely to be subject to endless >>> haggling. >>> >>> Seems like a rat hole. >>> >>> Thanks, >>> Paul >>> >>> Gunnar >>>> >>>> >>>> Stephane Bortzmeyer skrev den 2015-07-03 08:49: >>>> >>>>> On Thu, Jul 02, 2015 at 11:09:30PM +0100, >>>>> Nik Tomkinson >>>> > wrote >>>>> a message of 109 lines which said: >>>>> >>>>> type-token :=3D "original" / "human" / "automated" >>>>>> >>>>> In many IETF working groups, when there is such a proposal, >>>>> there is a >>>>> big discussion between the registryfull and the registryless >>>>> people. The first ones say there must be an authoritative list of >>>>> values (in the RFC or, better because more evolving, in an IANA >>>>> registry) so we can be sure of the interpretation of values. The >>>>> second ones say we can never capture all the nuances and >>>>> subtleties of >>>>> the world in a fixed list. >>>>> >>>>> Here, I am not sure that the only meaningful distinction is betwe= en >>>>> "human" and "automated". Some humans do a very poor job, too. One >>>>> could suggest: >>>>> >>>>> type-token :=3D "original" / "professional-human" / "amateur-huma= n" / >>>>> "automated-first-generation" / "automated-artificial-intelligence= " >>>>> / >>>>> "automated-the-robot-in-hollywood-movies" >>>>> >>>>> Or decide that it will be too complicated and we should instead >>>>> accept: >>>>> >>>>> type-token :=3D "original" / >>>>>> >>>>> Toughts? >>>>> >>>>> _______________________________________________ >>>>> SLIM mailing list >>>>> SLIM@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/slim >>>>> >>>> >>>> _______________________________________________ >>>> SLIM mailing list >>>> SLIM@ietf.org >>>> https://www.ietf.org/mailman/listinfo/slim >>>> >>>> >>> _______________________________________________ >>> SLIM mailing list >>> SLIM@ietf.org >>> https://www.ietf.org/mailman/listinfo/slim >>> >> >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim >> >> >> >> >> -- >> >> ----------------------------------------------------------------- >> Multiple Language Content Type Internet Draft: >> >> >> http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/ >> >> ----------------------------------------------------------------- >> >> >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim >> >> > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim > --=20 ----------------------------------------------------------------- Multiple Language Content Type Internet Draft: http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/ ----------------------------------------------------------------- --001a113995ec26bcd2051a282c59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Paul,

yes, they were my thoughts beh= ind suggesting the qvalue to identify the quality of the translation and to= avoid the implication that a machine translation is always worse than a hu= man one. But I think I would prefer to start off simply and add complexity = if it is required in a later version of the draft. The qvalue parameter cou= ld be added retrospectively to the Translation-Type field.

I think this will be an area to discuss in Prague and also explore= /test when doing some trial implementations.

Thank= s,

Nik.

=
On 5 July 2015 at 23:04, Paul Kyzivat <pky= zivat@alum.mit.edu> wrote:
= On 7/5/15 5:10 PM, Nik Tomkinson wrote:
Thanks again for the responses.

I think that I will add the original suggestion of:

translation-type :=3D type-token
type-token :=3D "original" / "human" / "automated&= quot;

 This seems "ok" - more or less harmless and possibly helpful in s= ome cases.

But I'm concerned that it will lead to an assumption that "human&q= uot; is *better* than "automated". That is probably true in most = practical cases today. But surely there are *some* automated translations t= hat are better than *some* human translations. And that will become the cas= e more often in the future.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

into the next version of the non-real-time I-D and (as Randall suggests) if during some deployment trials we find that making the distinction
between 'automated' and 'human' is not granular enough (or = there are
other changes required) we can update it further.

I will start on this update now and have it ready to submit before the
cut-off deadline tomorrow night (23:59 UTC Monday).

Nik.

On 5 July 2015 at 08:17, Eric Burger <eburger@standardstrack.com
 <mailto:= eburger@standardstrack.com>> wrote:

=C2=A0 =C2=A0 I=E2=80=99m agreeing here with Paul. /Maybe/ we could annotat= e something
=C2=A0 =C2=A0 that was machine translated. However, My justification is not= to say
=C2=A0 =C2=A0 how good the translation is, but to let the user know they ar= e NOT
=C2=A0 =C2=A0 seeing the original content.

=C2=A0 =C2=A0 On Jul 3, 2015, at 12:00 PM, Paul Kyzivat <pkyzivat@alum.mit.edu
=C2=A0 =C2=A0 <mailto:pkyzivat@alum.mit.edu>> wrote:

=C2=A0 =C2=A0 On 7/3/15 4:46 AM, Gunnar Hellstr=C3=B6m wrote:
=C2=A0 =C2=A0 I see some value of this kind of parameter also for the real-= time
=C2=A0 =C2=A0 case.
=C2=A0 =C2=A0 The time is here when it can be possible in some situations t= o select
=C2=A0 =C2=A0 between using a low-cost automatic speech-to-text generation = and a
=C2=A0 =C2=A0 higher cost captioned telephony or text-relay service (higher=
=C2=A0 =C2=A0 cost for
=C2=A0 =C2=A0 someone, not always the end-user).

=C2=A0 =C2=A0 But I agree that it is very hard to set good understandable =C2=A0 =C2=A0 values on a
=C2=A0 =C2=A0 parameter expressing the type or quality of this kind of serv= ice.

=C2=A0 =C2=A0 Yes. It is my understanding (2nd hand) there there are subjec= tive
=C2=A0 =C2=A0 decisions (preferences) when choosing a translation service.<= br>
=C2=A0 =C2=A0 While I can see how having a rating attached might be concept= ually
=C2=A0 =C2=A0 appealing, it is hard to imagine how it would be deployed in = a way
=C2=A0 =C2=A0 that is useful. And it seems likely to be subject to endless = haggling.

=C2=A0 =C2=A0 Seems like a rat hole.

=C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 Paul

=C2=A0 =C2=A0 Gunnar


=C2=A0 =C2=A0 Stephane Bortzmeyer skrev den 2015-07-03 08:49:
=C2=A0 =C2=A0 On Thu, Jul 02, 2015 at 11:09:30PM +0100,
=C2=A0 =C2=A0 =C2=A0Nik Tomkinson <rfc.nik.tomkinson@gmail.com
 =C2=A0 =C2=A0 <mailto:rfc.nik.tomkinson@gmail.com>> wrote
=C2=A0 =C2=A0 =C2=A0a message of 109 lines which said:

=C2=A0 =C2=A0 type-token :=3D "original" / "human" / &q= uot;automated"
=C2=A0 =C2=A0 In many IETF working groups, when there is such a proposal, =C2=A0 =C2=A0 there is a
=C2=A0 =C2=A0 big discussion between the registryfull and the registryless<= br> =C2=A0 =C2=A0 people. The first ones say there must be an authoritative lis= t of
=C2=A0 =C2=A0 values (in the RFC or, better because more evolving, in an IA= NA
=C2=A0 =C2=A0 registry) so we can be sure of the interpretation of values. = The
=C2=A0 =C2=A0 second ones say we can never capture all the nuances and
=C2=A0 =C2=A0 subtleties of
=C2=A0 =C2=A0 the world in a fixed list.

=C2=A0 =C2=A0 Here, I am not sure that the only meaningful distinction is b= etween
=C2=A0 =C2=A0 "human" and "automated". Some humans do a= very poor job, too. One
=C2=A0 =C2=A0 could suggest:

=C2=A0 =C2=A0 type-token :=3D "original" / "professional-hum= an" / "amateur-human" /
=C2=A0 =C2=A0 "automated-first-generation" / "automated-arti= ficial-intelligence" /
=C2=A0 =C2=A0 "automated-the-robot-in-hollywood-movies"

=C2=A0 =C2=A0 Or decide that it will be too complicated and we should inste= ad
=C2=A0 =C2=A0 accept:

=C2=A0 =C2=A0 type-token :=3D "original" / <free text>
=C2=A0 =C2=A0 Toughts?

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 SLIM mailing list
 =C2=A0 =C2=A0 SLIM@ietf.= org <mailto:SLIM@= ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/slim

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 SLIM mailing list
=C2=A0 =C2=A0 SLIM@ietf.= org <mailto:SLIM@= ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/slim


=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 SLIM mailing list
=C2=A0 =C2=A0 SLIM@ietf.= org <mailto:SLIM@= ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/slim


=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 SLIM mailing list
=C2=A0 =C2=A0 SLIM@ietf.= org <mailto:SLIM@= ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/slim




--

-----------------------------------------------------------------
Multiple Language Content Type Internet Draft:

 <http://datatracker.ietf.org/doc= /draft-tomkinson-multilangcontent/>http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangc= ontent/

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



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


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



--
= 
----------------------------------------------------=
-------------
Multiple Language Content Type Internet Draft:http://datatracker.ietf.org/doc/draft-tomkinson-slim-multil=
angcontent/
-=
----------------------------------------------------------------
=
--001a113995ec26bcd2051a282c59-- From nobody Sun Jul 5 18:05:11 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84CB01B29C6 for ; Sun, 5 Jul 2015 18:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 xbl4O9E3Pib4 for ; Sun, 5 Jul 2015 18:05:07 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D44991B29B4 for ; Sun, 5 Jul 2015 18:05:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1436144707; x=1467680707; h=message-id:in-reply-to:references:date:to:from:subject: mime-version; bh=i3+puCFf3rCaXzh6v2sRpHx34VC+cRDGffTtyrNIwts=; b=ZobXM9Dm03apZ8idBEK3oX2+JuLIXyQa5+r2o1m9oA+Xuo2gkeVAEpqX WRphgfnGCyUPMxXenmtNlKRCdhyjA85mAEiZhAA2g/mjMeT9f/rXa75el 5+cyotG79cXyxuC98xsE2aI0Q3kh+HafGn3yjUuG40rnrgewM3+xICEuU I=; X-IronPort-AV: E=McAfee;i="5700,7163,7853"; a="126335066" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Jul 2015 18:05:06 -0700 X-IronPort-AV: E=Sophos;i="5.15,412,1432623600"; d="scan'208";a="954354065" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 05 Jul 2015 18:05:02 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Sun, 5 Jul 2015 18:05:01 -0700 Message-ID: In-Reply-To: <5599A9FE.60401@alum.mit.edu> References: <20150703064908.GA14666@sources.org> <55964BED.1080905@omnitor.se> <5596B184.2020908@alum.mit.edu> <0A0D0CE1-01AC-411B-86B6-176A92C223A8@standardstrack.com> <5599A9FE.60401@alum.mit.edu> X-Mailer: Eudora for Mac OS X Date: Sun, 5 Jul 2015 18:05:00 -0700 To: Paul Kyzivat , From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01F.na.qualcomm.com (10.85.0.32) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Subject: Re: [Slim] Translation Quality or type X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 01:05:09 -0000 At 6:04 PM -0400 7/5/15, Paul Kyzivat wrote: > On 7/5/15 5:10 PM, Nik Tomkinson wrote: >> translation-type := type-token >> type-token := "original" / "human" / "automated" > > This seems "ok" - more or less harmless and possibly helpful in some cases. > > But I'm concerned that it will lead to an assumption that "human" > is *better* than "automated". That is probably true in most > practical cases today. But surely there are *some* automated > translations that are better than *some* human translations. And > that will become the case more often in the future. Keep in mind that the only use for the attribute will be at the receiving client. If, over time and on average, automated translations become on par or better than human translations, the end user and/or client can stop preferring human and go with the more preferred language rather than the more preferred translation method. In the meantime, it might be useful. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- In the United States the majority undertakes to supply a multitude of ready-made opinions for the use of individuals, who are thus relieved from the necessity of forming opinions of their own --Alexis de Tocqueville From nobody Mon Jul 6 00:01:39 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B72A1A1B48 for ; Mon, 6 Jul 2015 00:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 NPnkDzsYpWxR for ; Mon, 6 Jul 2015 00:01:36 -0700 (PDT) Received: from bin-vsp-out-02.atm.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 D29881A03E1 for ; Mon, 6 Jul 2015 00:01:35 -0700 (PDT) X-Halon-ID: d3ffe47c-23ac-11e5-bc2d-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.43.70] (unknown [2.65.89.236]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Mon, 6 Jul 2015 09:01:29 +0200 (CEST) Message-ID: <559A27CA.1060800@omnitor.se> Date: Mon, 06 Jul 2015 09:01:30 +0200 From: =?windows-1252?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: slim@ietf.org References: <20150703064908.GA14666@sources.org> <55964BED.1080905@omnitor.se> <5596B184.2020908@alum.mit.edu> <0A0D0CE1-01AC-411B-86B6-176A92C223A8@standardstrack.com> <5599A9FE.60401@alum.mit.edu> In-Reply-To: <5599A9FE.60401@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] Translation Quality or type X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 07:01:38 -0000 Follow-up questions: 1. What will be the default? Just unspecified I assume. 2. Would there be a need for a value representing all translation types except original? (=translated but unknown how) I can imagine some use of that, but I think it is acceptable to ignore that need. The user with that need would need to just take one of the other values. 3. Is there a need to describe how the coding can be extended? 4. Will this be a media level parameter or a session level parameter or both? I assume it makes most sense on the media level, so that it can be described e.g. that the audio carries original speech, while the text carries automated captions. /Gunnar Paul Kyzivat skrev den 2015-07-06 00:04: > On 7/5/15 5:10 PM, Nik Tomkinson wrote: >> Thanks again for the responses. >> >> I think that I will add the original suggestion of: >> >> translation-type := type-token >> type-token := "original" / "human" / "automated" > > This seems "ok" - more or less harmless and possibly helpful in some > cases. > > But I'm concerned that it will lead to an assumption that "human" is > *better* than "automated". That is probably true in most practical > cases today. But surely there are *some* automated translations that > are better than *some* human translations. And that will become the > case more often in the future. > > Thanks, > Paul > >> into the next version of the non-real-time I-D and (as Randall suggests) >> if during some deployment trials we find that making the distinction >> between 'automated' and 'human' is not granular enough (or there are >> other changes required) we can update it further. >> >> I will start on this update now and have it ready to submit before the >> cut-off deadline tomorrow night (23:59 UTC Monday). >> >> Nik. >> >> On 5 July 2015 at 08:17, Eric Burger > > wrote: >> >> I’m agreeing here with Paul. /Maybe/ we could annotate something >> that was machine translated. However, My justification is not to say >> how good the translation is, but to let the user know they are NOT >> seeing the original content. >> >>> On Jul 3, 2015, at 12:00 PM, Paul Kyzivat >> > wrote: >>> >>> On 7/3/15 4:46 AM, Gunnar Hellström wrote: >>>> I see some value of this kind of parameter also for the real-time >>>> case. >>>> The time is here when it can be possible in some situations to >>>> select >>>> between using a low-cost automatic speech-to-text generation and a >>>> higher cost captioned telephony or text-relay service (higher >>>> cost for >>>> someone, not always the end-user). >>>> >>>> But I agree that it is very hard to set good understandable >>>> values on a >>>> parameter expressing the type or quality of this kind of service. >>> >>> Yes. It is my understanding (2nd hand) there there are subjective >>> decisions (preferences) when choosing a translation service. >>> >>> While I can see how having a rating attached might be conceptually >>> appealing, it is hard to imagine how it would be deployed in a way >>> that is useful. And it seems likely to be subject to endless >>> haggling. >>> >>> Seems like a rat hole. >>> >>> Thanks, >>> Paul >>> >>>> Gunnar >>>> >>>> >>>> Stephane Bortzmeyer skrev den 2015-07-03 08:49: >>>>> On Thu, Jul 02, 2015 at 11:09:30PM +0100, >>>>> Nik Tomkinson >>>> > wrote >>>>> a message of 109 lines which said: >>>>> >>>>>> type-token := "original" / "human" / "automated" >>>>> In many IETF working groups, when there is such a proposal, >>>>> there is a >>>>> big discussion between the registryfull and the registryless >>>>> people. The first ones say there must be an authoritative list of >>>>> values (in the RFC or, better because more evolving, in an IANA >>>>> registry) so we can be sure of the interpretation of values. The >>>>> second ones say we can never capture all the nuances and >>>>> subtleties of >>>>> the world in a fixed list. >>>>> >>>>> Here, I am not sure that the only meaningful distinction is >>>>> between >>>>> "human" and "automated". Some humans do a very poor job, too. One >>>>> could suggest: >>>>> >>>>> type-token := "original" / "professional-human" / >>>>> "amateur-human" / >>>>> "automated-first-generation" / >>>>> "automated-artificial-intelligence" / >>>>> "automated-the-robot-in-hollywood-movies" >>>>> >>>>> Or decide that it will be too complicated and we should instead >>>>> accept: >>>>> >>>>>> type-token := "original" / >>>>> Toughts? >>>>> >>>>> _______________________________________________ >>>>> SLIM mailing list >>>>> SLIM@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/slim >>>> >>>> _______________________________________________ >>>> SLIM mailing list >>>> SLIM@ietf.org >>>> https://www.ietf.org/mailman/listinfo/slim >>>> >>> >>> _______________________________________________ >>> SLIM mailing list >>> SLIM@ietf.org >>> https://www.ietf.org/mailman/listinfo/slim >> >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim >> >> >> >> >> -- >> >> ----------------------------------------------------------------- >> Multiple Language Content Type Internet Draft: >> >> http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/ >> >> >> ----------------------------------------------------------------- >> >> >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim >> > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Mon Jul 6 00:25:03 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28CBB1A0141 for ; Mon, 6 Jul 2015 00:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 Uj_jnTwT0MJ4 for ; Mon, 6 Jul 2015 00:24:59 -0700 (PDT) Received: from bin-vsp-out-01.atm.binero.net (vsp-unauthed01.binero.net [195.74.38.225]) (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 175C01A8A9C for ; Mon, 6 Jul 2015 00:24:58 -0700 (PDT) X-Halon-ID: 23db3886-23b0-11e5-8486-005056917a89 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.43.70] (unknown [2.65.89.236]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Mon, 6 Jul 2015 09:25:12 +0200 (CEST) Message-ID: <559A2D44.1010308@omnitor.se> Date: Mon, 06 Jul 2015 09:24:52 +0200 From: =?windows-1252?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: slim@ietf.org References: <20150703064908.GA14666@sources.org> <55964BED.1080905@omnitor.se> <5598D34A.6070001@omnitor.se> <55995958.5050109@alum.mit.edu> <55999526.7030006@omnitor.se> In-Reply-To: <55999526.7030006@omnitor.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] Translation Quality or type - or service provider X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 07:25:02 -0000 One reason for the need to convey a translation service provider URI is that the emergency service RFCs 6443 and 6881 forbids the calling user to invoke three-party calling. For example RFC 6443, chapter 13 says "Services such as call waiting, call transfer, three-way calling, and hold should be disabled." If then the user is in a foreign language environment where the PSAP barely can have a clue on how to find the right relay service, and the user has a good relay service URI configured, well capable of handling the user's language and modality, what is then best? 1) Break against RFC 6881 and 6443 and have the user terminal invoke the three-party call? The wording in these RFCs may be interpreted to have some room for such deviations. 2) Or convey the relay service URI to the PSAP for invocation. The discussion so far leads towards conclusion 1. It is ok for me, I just wanted it confirmed by showing the whole situation. (there will always be complementing slow manual procedures, when the PSAP needs to figure out a reasonable way to handle the call, but this discussion is for the rapid automated way that should handle most cases.) /Gunnar Gunnar Hellström skrev den 2015-07-05 22:35: > Paul, > Yes, I agree that for most cases it is best that the party, who knows > a service that will do the translation, does the invocation. > > And, yes ,in that scenario the 3PCC method seems suitable. > > My proposal to send the service provider URI together with the > modality indications was for the case when there are strong policy > reasons why one party would do the invocation, but little chance that > that party would have access to an up-to-date information on available > translation providers. > That could be the case for the emergency service calling in a > multi-language environment, also including support for sign language > users. > > Since both you and Randall think it is not doable, we can try to use > the principle that the party, who knows a service that will do the > translation, does the invocation. > > That brings us back to a need for more stringent language/modality > negotiation in order to avoid both double invocation of services when > one or none is required, and also avoid no invocation when one is needed. > > Paul Kyzivat skrev den 2015-07-05 18:20: >> Gunnar, >> >> I understand what you are suggesting, but I don't believe it is >> workable. This seems to mean that the caller would select the service >> while the callee would engage the service in the call if needed. Yet >> it is likely to be the caller who has a business relationship with >> the service, while the callee does not. Gets complicated quickly. >> >> ISTM it makes more sense to first figure out what is/isn't possible >> without translation, and then for a party that finds a translation >> service beneficial to engage one. Then the only concern is that both >> parties don't independently try to introduce equivalent translation >> services. >> >> For instance, a deaf caller might offer video media marked for sign >> language, and audio media on hold. If the answer doesn't accept the >> video, or doesn't indicate support for sign language, the caller >> could then conference in translation service, using the 3pcc >> transcoding model specified in rfc5369. (If that will take time, the >> deaf caller's UA could stream recorded media over the audio channel >> in the meantime.) >> >> Or, to get fancier, it would be possible to use preconditions to >> defer alerting the callee until this is all sorted out. >> >> My point is to let the participant who wants translation handle to >> setup of translation rather than depending on the other party to do >> something. > OK, it might be likely that both parties "want" translation, but one > has better knowledge about how to get the required service and has > business relations with the service. So then it is preferred that that > party invokes. > > Good > /Gunnar >> >> Thanks, >> Paul >> >> On 7/5/15 2:48 AM, Gunnar Hellström wrote: >>> Another opportunity would be to convey a URI to the service provider >>> who >>> did (for mail) or can do(for real-time) the translation. >>> Then experience with different service provider's production could give >>> some idea of the expected quality. >>> I can see great value in that for the real-time case, when the calling >>> user has a favourite translator (e.g. relay service), and provides that >>> as a hint if languages or modalities in the call does not match. Then >>> the callee do not need to just take a service provider by chance that >>> seem to match the language/modality profile but can take the one >>> proposed by the caller. >>> >>> After working with the needs for emergency services to work across >>> Europe for some time now, I think this is one of the few workable >>> solutions. The user expresses both the language/modality needs and >>> provides a URI to a favourite translation service provider, and the >>> callee tries to fulfill the language/modality needs either by a >>> matching >>> original call taker or by invoking the proposed translation provider. >>> >>> /Gunnar >>> >>> >>> Randall Gellens skrev den 2015-07-05 03:49: >>>> My recollection is that this was discussed in email prior to Dallas, >>>> but that's not important. >>>> >>>> I am a strong proponent of keeping things as simple as possible, >>>> provided there is a way to extend them if experience shows that it is >>>> needed. So, I think we should stick with the original suggestion of >>>> three values ("original", "human", "automated"). This is simple enough >>>> to be implementable and functional enough to be useful in providing a >>>> hint that may help the client choose the best version for the user. If >>>> we try and capture the various nuances of quality we will end up with >>>> a very complex mechanism that is unlikely to be any more useful in >>>> real life. Let's go with the simple approach now. If, after some >>>> deployment experience we realize that we really do need extra >>>> complexity, we can extend the mechanism then. >>>> >>>> At 4:29 PM +0100 7/3/15, Nik Tomkinson wrote: >>>> >>>>> Thanks for the responses. >>>>> >>>>> To deal with the issue with having only original/human/automated, >>>>> what about the following?: >>>>> >>>>> >>>>> translation-type := type-token[ ";" "q" "=" qvalue ] >>>>> type-token :="human" / "automated" >>>>> >>>>> where qvalue is a value between 0 and 1 with a default of 0.5 if >>>>> missing >>>>> >>>>> for example: >>>>> >>>>> Translation-Type: human;q=0.8 >>>>> Translation-Type: automated;q=0.4 >>>>> Translation-Type: human >>>>> >>>>> The Translation-Type SHOULD NOT appear in the original >>>>> (untranslated) part but it SHOULD appear in translated content. >>>>> >>>>> Having this missing from the original text helps identify which is >>>>> the source to be translated into further languages if the user mail >>>>> client allows. >>>>> >>>>> This enables us to dispose of the 'original' value which didn't lend >>>>> itself well to being graded on quality. >>>>> >>>>> The qvalue can be set by the sender or provided by the translation >>>>> service. >>>>> >>>>> The draft suggests that: >>>>> >>>>> "Additionally, interactive implementations MAY offer the user a >>>>> choice from among the available languages." so the qvalue may not >>>>> need to be bulletproof. >>>>> >>>>> Comments? >>>>> >>>>> Nik. >>>>> >>>>> On 3 July 2015 at 09:46, Gunnar Hellström >>>>> <gunnar.hellstrom@omnitor.se> >>>>> wrote: >>>>> >>>>> I see some value of this kind of parameter also for the real-time >>>>> case. >>>>> The time is here when it can be possible in some situations to >>>>> select between using a low-cost automatic speech-to-text generation >>>>> and a higher cost captioned telephony or text-relay service (higher >>>>> cost for someone, not always the end-user). >>>>> >>>>> But I agree that it is very hard to set good understandable values >>>>> on a parameter expressing the type or quality of this kind of >>>>> service. >>>>> >>>>> Gunnar >>>>> >>>>> >>>>> >>>>> Stephane Bortzmeyer skrev den 2015-07-03 08:49: >>>>> >>>>> On Thu, Jul 02, 2015 at 11:09:30PM +0100, >>>>> Nik Tomkinson >>>>> <rfc.nik.tomkinson@gmail.com> >>>>> wrote >>>>> a message of 109 lines which said: >>>>> >>>>> type-token := "original" / "human" / "automated" >>>>> >>>>> In many IETF working groups, when there is such a proposal, there >>>>> is a >>>>> big discussion between the registryfull and the registryless >>>>> people. The first ones say there must be an authoritative list of >>>>> values (in the RFC or, better because more evolving, in an IANA >>>>> registry) so we can be sure of the interpretation of values. The >>>>> second ones say we can never capture all the nuances and >>>>> subtleties of >>>>> the world in a fixed list. >>>>> >>>>> Here, I am not sure that the only meaningful distinction is between >>>>> "human" and "automated". Some humans do a very poor job, too. One >>>>> could suggest: >>>>> >>>>> type-token := "original" / "professional-human" / "amateur-human" / >>>>> "automated-first-generation" / "automated-artificial-intelligence" / >>>>> "automated-the-robot-in-hollywood-movies" >>>>> >>>>> Or decide that it will be too complicated and we should instead >>>>> accept: >>>>> >>>>> type-token := "original" / >>>>> >>>>> Toughts? >>>>> >>>>> _______________________________________________ >>>>> SLIM mailing list >>>>> SLIM@ietf.org >>>>> >>>>> https://www.ietf.org/mailman/listinfo/slim >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> SLIM mailing list >>>>> SLIM@ietf.org >>>>> >>>>> https://www.ietf.org/mailman/listinfo/slim >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> ----------------------------------------------------------------- >>>>> Multiple Language Content Type Internet Draft: >>>>> >>>>> http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/ >>>>> >>>>> >>>>> ----------------------------------------------------------------- >>>>> >>>>> _______________________________________________ >>>>> SLIM mailing list >>>>> SLIM@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/slim >>>> >>>> >>>> >>> >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim > -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Mon Jul 6 01:43:52 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A31041A90D4 for ; Mon, 6 Jul 2015 01:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.012 X-Spam-Level: X-Spam-Status: No, score=-1.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=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 AN8uEQMgYedb for ; Mon, 6 Jul 2015 01:43:48 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DDAB1A90A5 for ; Mon, 6 Jul 2015 01:43:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=EZ/vUtCxP8h6AzZeqopYywFbBHEemGOp32bIgT1DVNY=; b=Rca5lCfqBrpGF8qddCr9MWP7bue7fc7yPF0xELHa+W9nmYg93PJSojhm/09/q7GSwO2TbpDDouyYCcXOeLDygIxL2FB2z2OULgZrOQz9dzabtYyApt2XSIicDC/2+rpVPb6biMxT1hPcXuXW0qykDXSqJKjhSvMCzqmReJJgGMg=; Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:62820 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZC209-000783-UX for slim@ietf.org; Mon, 06 Jul 2015 01:43:47 -0700 Content-Type: multipart/signed; boundary="Apple-Mail=_5D41C7F9-C655-4B8C-9C4E-68DC1C65786E"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Pgp-Agent: GPGMail 2.5 From: Eric Burger In-Reply-To: <559A2D44.1010308@omnitor.se> Date: Mon, 6 Jul 2015 04:43:43 -0400 Message-Id: References: <20150703064908.GA14666@sources.org> <55964BED.1080905@omnitor.se> <5598D34A.6070001@omnitor.se> <55995958.5050109@alum.mit.edu> <55999526.7030006@omnitor.se> <559A2D44.1010308@omnitor.se> To: slim@ietf.org X-Mailer: Apple Mail (2.2098) X-OutGoing-Spam-Status: No, score=-0.4 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.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: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [Slim] Translation Quality or type - or service provider X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 08:43:50 -0000 --Apple-Mail=_5D41C7F9-C655-4B8C-9C4E-68DC1C65786E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Jul 6, 2015, at 3:24 AM, Gunnar Hellstr=F6m = wrote: >=20 > One reason for the need to convey a translation service provider URI = is that the emergency service RFCs 6443 and 6881 forbids the calling = user to invoke three-party calling. 6443 is informational and 6881 is a BCP. No problem to do something that = works that is =91forbidden.=92 > For example RFC 6443, chapter 13 says "Services such as call waiting, = call transfer, three-way calling, and hold should be disabled.=94 Note the use of =91should.=92 I do not think anyone will complain if = one interprets this as, =93Should be disabled, unless the user will die = if she does not setup a three-way call with her translation service.=94 > If then the user is in a foreign language environment where the PSAP = barely can have a clue on how to find the right relay service, and the = user has a good relay service URI configured, well capable of handling = the user's language and modality, what is then best? >=20 > 1) Break against RFC 6881 and 6443 and have the user terminal invoke = the three-party call? The wording in these RFCs may be interpreted to = have some room for such deviations. Beyond the wording in the RFCs, there is a reason the IETF is not the = protocol police. In retrospect, it may be safe to say the RFCs=92 = suggestions are wrong. > 2) Or convey the relay service URI to the PSAP for invocation. Why not? >=20 > The discussion so far leads towards conclusion 1. It is ok for me, I = just wanted it confirmed by showing the whole situation. >=20 > (there will always be complementing slow manual procedures, when the = PSAP needs to figure out a reasonable way to handle the call, but this = discussion is for the rapid automated way that should handle most = cases.) >=20 > /Gunnar >=20 > Gunnar Hellstr=F6m skrev den 2015-07-05 22:35: >> Paul, >> Yes, I agree that for most cases it is best that the party, who knows = a service that will do the translation, does the invocation. >>=20 >> And, yes ,in that scenario the 3PCC method seems suitable. >>=20 >> My proposal to send the service provider URI together with the = modality indications was for the case when there are strong policy = reasons why one party would do the invocation, but little chance that = that party would have access to an up-to-date information on available = translation providers. >> That could be the case for the emergency service calling in a = multi-language environment, also including support for sign language = users. >>=20 >> Since both you and Randall think it is not doable, we can try to use = the principle that the party, who knows a service that will do the = translation, does the invocation. >>=20 >> That brings us back to a need for more stringent language/modality = negotiation in order to avoid both double invocation of services when = one or none is required, and also avoid no invocation when one is = needed. >>=20 >> Paul Kyzivat skrev den 2015-07-05 18:20: >>> Gunnar, >>>=20 >>> I understand what you are suggesting, but I don't believe it is = workable. This seems to mean that the caller would select the service = while the callee would engage the service in the call if needed. Yet it = is likely to be the caller who has a business relationship with the = service, while the callee does not. Gets complicated quickly. >>>=20 >>> ISTM it makes more sense to first figure out what is/isn't possible = without translation, and then for a party that finds a translation = service beneficial to engage one. Then the only concern is that both = parties don't independently try to introduce equivalent translation = services. >>>=20 >>> For instance, a deaf caller might offer video media marked for sign = language, and audio media on hold. If the answer doesn't accept the = video, or doesn't indicate support for sign language, the caller could = then conference in translation service, using the 3pcc transcoding model = specified in rfc5369. (If that will take time, the deaf caller's UA = could stream recorded media over the audio channel in the meantime.) >>>=20 >>> Or, to get fancier, it would be possible to use preconditions to = defer alerting the callee until this is all sorted out. >>>=20 >>> My point is to let the participant who wants translation handle to = setup of translation rather than depending on the other party to do = something. >> OK, it might be likely that both parties "want" translation, but one = has better knowledge about how to get the required service and has = business relations with the service. So then it is preferred that that = party invokes. >>=20 >> Good >> /Gunnar >>>=20 >>> Thanks, >>> Paul >>>=20 >>> On 7/5/15 2:48 AM, Gunnar Hellstr=F6m wrote: >>>> Another opportunity would be to convey a URI to the service = provider who >>>> did (for mail) or can do(for real-time) the translation. >>>> Then experience with different service provider's production could = give >>>> some idea of the expected quality. >>>> I can see great value in that for the real-time case, when the = calling >>>> user has a favourite translator (e.g. relay service), and provides = that >>>> as a hint if languages or modalities in the call does not match. = Then >>>> the callee do not need to just take a service provider by chance = that >>>> seem to match the language/modality profile but can take the one >>>> proposed by the caller. >>>>=20 >>>> After working with the needs for emergency services to work across >>>> Europe for some time now, I think this is one of the few workable >>>> solutions. The user expresses both the language/modality needs and >>>> provides a URI to a favourite translation service provider, and the >>>> callee tries to fulfill the language/modality needs either by a = matching >>>> original call taker or by invoking the proposed translation = provider. >>>>=20 >>>> /Gunnar >>>>=20 >>>>=20 >>>> Randall Gellens skrev den 2015-07-05 03:49: >>>>> My recollection is that this was discussed in email prior to = Dallas, >>>>> but that's not important. >>>>>=20 >>>>> I am a strong proponent of keeping things as simple as possible, >>>>> provided there is a way to extend them if experience shows that it = is >>>>> needed. So, I think we should stick with the original suggestion = of >>>>> three values ("original", "human", "automated"). This is simple = enough >>>>> to be implementable and functional enough to be useful in = providing a >>>>> hint that may help the client choose the best version for the = user. If >>>>> we try and capture the various nuances of quality we will end up = with >>>>> a very complex mechanism that is unlikely to be any more useful in >>>>> real life. Let's go with the simple approach now. If, after some >>>>> deployment experience we realize that we really do need extra >>>>> complexity, we can extend the mechanism then. >>>>>=20 >>>>> At 4:29 PM +0100 7/3/15, Nik Tomkinson wrote: >>>>>=20 >>>>>> Thanks for the responses. >>>>>>=20 >>>>>> To deal with the issue with having only original/human/automated, >>>>>> what about the following?: >>>>>>=20 >>>>>>=20 >>>>>> translation-type :=3D type-token[ ";" "q" "=3D" qvalue ] >>>>>> type-token :=3D"human" / "automated" >>>>>>=20 >>>>>> where qvalue is a value between 0 and 1 with a default of 0.5 if >>>>>> missing >>>>>>=20 >>>>>> for example: >>>>>>=20 >>>>>> Translation-Type: human;q=3D0.8 >>>>>> Translation-Type: automated;q=3D0.4 >>>>>> Translation-Type: human >>>>>>=20 >>>>>> The Translation-Type SHOULD NOT appear in the original >>>>>> (untranslated) part but it SHOULD appear in translated content. >>>>>>=20 >>>>>> Having this missing from the original text helps identify which = is >>>>>> the source to be translated into further languages if the user = mail >>>>>> client allows. >>>>>>=20 >>>>>> This enables us to dispose of the 'original' value which didn't = lend >>>>>> itself well to being graded on quality. >>>>>>=20 >>>>>> The qvalue can be set by the sender or provided by the = translation >>>>>> service. >>>>>>=20 >>>>>> The draft suggests that: >>>>>>=20 >>>>>> "Additionally, interactive implementations MAY offer the user a >>>>>> choice from among the available languages." so the qvalue may not >>>>>> need to be bulletproof. >>>>>>=20 >>>>>> Comments? >>>>>>=20 >>>>>> Nik. >>>>>>=20 >>>>>> On 3 July 2015 at 09:46, Gunnar Hellstr=F6m >>>>>> <gunnar.hellstrom@omnitor.se> = wrote: >>>>>>=20 >>>>>> I see some value of this kind of parameter also for the real-time = case. >>>>>> The time is here when it can be possible in some situations to >>>>>> select between using a low-cost automatic speech-to-text = generation >>>>>> and a higher cost captioned telephony or text-relay service = (higher >>>>>> cost for someone, not always the end-user). >>>>>>=20 >>>>>> But I agree that it is very hard to set good understandable = values >>>>>> on a parameter expressing the type or quality of this kind of = service. >>>>>>=20 >>>>>> Gunnar >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Stephane Bortzmeyer skrev den 2015-07-03 08:49: >>>>>>=20 >>>>>> On Thu, Jul 02, 2015 at 11:09:30PM +0100, >>>>>> Nik Tomkinson >>>>>> <rfc.nik.tomkinson@gmail.com> = wrote >>>>>> a message of 109 lines which said: >>>>>>=20 >>>>>> type-token :=3D "original" / "human" / "automated" >>>>>>=20 >>>>>> In many IETF working groups, when there is such a proposal, there = is a >>>>>> big discussion between the registryfull and the registryless >>>>>> people. The first ones say there must be an authoritative list of >>>>>> values (in the RFC or, better because more evolving, in an IANA >>>>>> registry) so we can be sure of the interpretation of values. The >>>>>> second ones say we can never capture all the nuances and = subtleties of >>>>>> the world in a fixed list. >>>>>>=20 >>>>>> Here, I am not sure that the only meaningful distinction is = between >>>>>> "human" and "automated". Some humans do a very poor job, too. One >>>>>> could suggest: >>>>>>=20 >>>>>> type-token :=3D "original" / "professional-human" / = "amateur-human" / >>>>>> "automated-first-generation" / = "automated-artificial-intelligence" / >>>>>> "automated-the-robot-in-hollywood-movies" >>>>>>=20 >>>>>> Or decide that it will be too complicated and we should instead >>>>>> accept: >>>>>>=20 >>>>>> type-token :=3D "original" / >>>>>>=20 >>>>>> Toughts? >>>>>>=20 >>>>>> _______________________________________________ >>>>>> SLIM mailing list >>>>>> SLIM@ietf.org >>>>>>=20 >>>>>> = https://www.ietf.org/mailman/l= istinfo/slim >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> SLIM mailing list >>>>>> SLIM@ietf.org >>>>>>=20 >>>>>> = https://www.ietf.org/mailman/l= istinfo/slim >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>>=20 >>>>>> ----------------------------------------------------------------- >>>>>> Multiple Language Content Type Internet Draft: >>>>>>=20 >>>>>> = http://= datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/ >>>>>>=20 >>>>>> ----------------------------------------------------------------- >>>>>>=20 >>>>>> _______________________________________________ >>>>>> SLIM mailing list >>>>>> SLIM@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/slim >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> SLIM mailing list >>> SLIM@ietf.org >>> https://www.ietf.org/mailman/listinfo/slim >>=20 >=20 > -- > ----------------------------------------- > Gunnar Hellstr=F6m > Omnitor > gunnar.hellstrom@omnitor.se > +46 708 204 288 >=20 > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim --Apple-Mail=_5D41C7F9-C655-4B8C-9C4E-68DC1C65786E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVmj/AAAoJEORoZaSQsc1I0mgP/AsGtpEM6GL4orO7UL/ZMC/8 TTMmo/J3tu0MdVTbPqdMJ9bsxA8XpmQjZdSY6UH4+KVGEXfrC8yKKYFs+kCuRDdh xShG3xxq+8Z69v39YVyXKzZtndYG9YPltu/iRH53Khrhp6Vo72NWDqa5GOmuqQA5 e+BWNQiVRw9ulNE237Zn6jt9tM/1jnhOiRtPksbyyzK1j8WfrcVNiyMShY5LsQ2v GbWZAOyV4U+K60/ju7sZgWT3iKuqP3hH3XelkcopqFXxhHEf69C1QxXMm3gTss3X trO3ItR6AtIds3cpl5A4ZDXIVReTRah9IDvz4mwf6yAKA3o8SA3/CslFvY/uBE+f 6NY1ienztK9LGvenwPHOcMoJ6v13NVCX5EbXtM+WLaJ05JgJa0riSFTqpPKgtlRY F3tQs4q2NaDIFqVFS3YUO8/7hH2zfOsqbMCqw/4V3bs0n4zdryfEqohGU5AASNtd mClVrG3eUEAv4F+kvOJdABqjFrrN78Yowbh2a3Lg/qc8FEhWOANHMIkoPukW/QIi o8mCqSbYEYd/yrT+ppCG5S8LnbwuTlno7Y8z+pJsolJJWj1IMBNfe6eyoQvrFJe3 MI6klgUxslJb8bxBRFRo3v/YWKtHKiTsS8cXEMrtSupghsqdWgPHHSJr+4bHmV5d quzJooSFMVEuVV7QHx5O =pvZ0 -----END PGP SIGNATURE----- --Apple-Mail=_5D41C7F9-C655-4B8C-9C4E-68DC1C65786E-- From nobody Mon Jul 6 02:22:36 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94C4F1A923A for ; Mon, 6 Jul 2015 02:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 0lHIOvt3FblC for ; Mon, 6 Jul 2015 02:22:31 -0700 (PDT) Received: from bin-vsp-out-05.atm.binero.net (vsp-unauthed01.binero.net [195.74.38.225]) (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 AA6B01A9238 for ; Mon, 6 Jul 2015 02:22:30 -0700 (PDT) X-Halon-ID: 8a5132d7-23c0-11e5-8d68-005056916f53 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.43.70] (unknown [2.65.89.236]) by bin-vsp-out-05.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Mon, 6 Jul 2015 11:22:36 +0200 (CEST) Message-ID: <559A48CF.7060703@omnitor.se> Date: Mon, 06 Jul 2015 11:22:23 +0200 From: =?windows-1252?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: slim@ietf.org References: <20150703064908.GA14666@sources.org> <55964BED.1080905@omnitor.se> <5598D34A.6070001@omnitor.se> <55995958.5050109@alum.mit.edu> <55999526.7030006@omnitor.se> <559A2D44.1010308@omnitor.se> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090601010102040505030600" Archived-At: Subject: Re: [Slim] Translation Quality or type - or service provider X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 09:22:35 -0000 This is a multi-part message in MIME format. --------------090601010102040505030600 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Thanks Eric for sensible answers. Eric Burger skrev den 2015-07-06 10:43: >> On Jul 6, 2015, at 3:24 AM, Gunnar Hellström wrote: >> >> One reason for the need to convey a translation service provider URI is that the emergency service RFCs 6443 and 6881 forbids the calling user to invoke three-party calling. > 6443 is informational and 6881 is a BCP. No problem to do something that works that is ‘forbidden.’ > >> For example RFC 6443, chapter 13 says "Services such as call waiting, call transfer, three-way calling, and hold should be disabled.” > Note the use of ‘should.’ I do not think anyone will complain if one interprets this as, “Should be disabled, unless the user will die if she does not setup a three-way call with her translation service.” > >> If then the user is in a foreign language environment where the PSAP barely can have a clue on how to find the right relay service, and the user has a good relay service URI configured, well capable of handling the user's language and modality, what is then best? >> >> 1) Break against RFC 6881 and 6443 and have the user terminal invoke the three-party call? The wording in these RFCs may be interpreted to have some room for such deviations. > Beyond the wording in the RFCs, there is a reason the IETF is not the protocol police. In retrospect, it may be safe to say the RFCs’ suggestions are wrong. > >> 2) Or convey the relay service URI to the PSAP for invocation. > Why not? One example of a procedure for such invocation is in EENA NG112 LTD and NENA NG9-1-1 i3 08-003 procedure for third party invocation, (chapter 9) where the third party service, who happens to get the emergency call first, refers back to the emergency caller to make the call to urn:service:sos with the third party URI in the Referred-by field. The PSAP is then supposed to conference-in the third party. ( I have not seen how they deduce that the third party shall be conferenced-in, but their address is anyway conveyed to the PSAP. ) > >> The discussion so far leads towards conclusion 1. It is ok for me, I just wanted it confirmed by showing the whole situation. >> >> (there will always be complementing slow manual procedures, when the PSAP needs to figure out a reasonable way to handle the call, but this discussion is for the rapid automated way that should handle most cases.) >> >> /Gunnar >> >> Gunnar Hellström skrev den 2015-07-05 22:35: >>> Paul, >>> Yes, I agree that for most cases it is best that the party, who knows a service that will do the translation, does the invocation. >>> >>> And, yes ,in that scenario the 3PCC method seems suitable. >>> >>> My proposal to send the service provider URI together with the modality indications was for the case when there are strong policy reasons why one party would do the invocation, but little chance that that party would have access to an up-to-date information on available translation providers. >>> That could be the case for the emergency service calling in a multi-language environment, also including support for sign language users. >>> >>> Since both you and Randall think it is not doable, we can try to use the principle that the party, who knows a service that will do the translation, does the invocation. >>> >>> That brings us back to a need for more stringent language/modality negotiation in order to avoid both double invocation of services when one or none is required, and also avoid no invocation when one is needed. >>> >>> Paul Kyzivat skrev den 2015-07-05 18:20: >>>> Gunnar, >>>> >>>> I understand what you are suggesting, but I don't believe it is workable. This seems to mean that the caller would select the service while the callee would engage the service in the call if needed. Yet it is likely to be the caller who has a business relationship with the service, while the callee does not. Gets complicated quickly. >>>> >>>> ISTM it makes more sense to first figure out what is/isn't possible without translation, and then for a party that finds a translation service beneficial to engage one. Then the only concern is that both parties don't independently try to introduce equivalent translation services. >>>> >>>> For instance, a deaf caller might offer video media marked for sign language, and audio media on hold. If the answer doesn't accept the video, or doesn't indicate support for sign language, the caller could then conference in translation service, using the 3pcc transcoding model specified in rfc5369. (If that will take time, the deaf caller's UA could stream recorded media over the audio channel in the meantime.) >>>> >>>> Or, to get fancier, it would be possible to use preconditions to defer alerting the callee until this is all sorted out. >>>> >>>> My point is to let the participant who wants translation handle to setup of translation rather than depending on the other party to do something. >>> OK, it might be likely that both parties "want" translation, but one has better knowledge about how to get the required service and has business relations with the service. So then it is preferred that that party invokes. >>> >>> Good >>> /Gunnar >>>> Thanks, >>>> Paul >>>> >>>> On 7/5/15 2:48 AM, Gunnar Hellström wrote: >>>>> Another opportunity would be to convey a URI to the service provider who >>>>> did (for mail) or can do(for real-time) the translation. >>>>> Then experience with different service provider's production could give >>>>> some idea of the expected quality. >>>>> I can see great value in that for the real-time case, when the calling >>>>> user has a favourite translator (e.g. relay service), and provides that >>>>> as a hint if languages or modalities in the call does not match. Then >>>>> the callee do not need to just take a service provider by chance that >>>>> seem to match the language/modality profile but can take the one >>>>> proposed by the caller. >>>>> >>>>> After working with the needs for emergency services to work across >>>>> Europe for some time now, I think this is one of the few workable >>>>> solutions. The user expresses both the language/modality needs and >>>>> provides a URI to a favourite translation service provider, and the >>>>> callee tries to fulfill the language/modality needs either by a matching >>>>> original call taker or by invoking the proposed translation provider. >>>>> >>>>> /Gunnar >>>>> >>>>> >>>>> Randall Gellens skrev den 2015-07-05 03:49: >>>>>> My recollection is that this was discussed in email prior to Dallas, >>>>>> but that's not important. >>>>>> >>>>>> I am a strong proponent of keeping things as simple as possible, >>>>>> provided there is a way to extend them if experience shows that it is >>>>>> needed. So, I think we should stick with the original suggestion of >>>>>> three values ("original", "human", "automated"). This is simple enough >>>>>> to be implementable and functional enough to be useful in providing a >>>>>> hint that may help the client choose the best version for the user. If >>>>>> we try and capture the various nuances of quality we will end up with >>>>>> a very complex mechanism that is unlikely to be any more useful in >>>>>> real life. Let's go with the simple approach now. If, after some >>>>>> deployment experience we realize that we really do need extra >>>>>> complexity, we can extend the mechanism then. >>>>>> >>>>>> At 4:29 PM +0100 7/3/15, Nik Tomkinson wrote: >>>>>> >>>>>>> Thanks for the responses. >>>>>>> >>>>>>> To deal with the issue with having only original/human/automated, >>>>>>> what about the following?: >>>>>>> >>>>>>> >>>>>>> translation-type := type-token[ ";" "q" "=" qvalue ] >>>>>>> type-token :="human" / "automated" >>>>>>> >>>>>>> where qvalue is a value between 0 and 1 with a default of 0.5 if >>>>>>> missing >>>>>>> >>>>>>> for example: >>>>>>> >>>>>>> Translation-Type: human;q=0.8 >>>>>>> Translation-Type: automated;q=0.4 >>>>>>> Translation-Type: human >>>>>>> >>>>>>> The Translation-Type SHOULD NOT appear in the original >>>>>>> (untranslated) part but it SHOULD appear in translated content. >>>>>>> >>>>>>> Having this missing from the original text helps identify which is >>>>>>> the source to be translated into further languages if the user mail >>>>>>> client allows. >>>>>>> >>>>>>> This enables us to dispose of the 'original' value which didn't lend >>>>>>> itself well to being graded on quality. >>>>>>> >>>>>>> The qvalue can be set by the sender or provided by the translation >>>>>>> service. >>>>>>> >>>>>>> The draft suggests that: >>>>>>> >>>>>>> "Additionally, interactive implementations MAY offer the user a >>>>>>> choice from among the available languages." so the qvalue may not >>>>>>> need to be bulletproof. >>>>>>> >>>>>>> Comments? >>>>>>> >>>>>>> Nik. >>>>>>> >>>>>>> On 3 July 2015 at 09:46, Gunnar Hellström >>>>>>> <gunnar.hellstrom@omnitor.se> wrote: >>>>>>> >>>>>>> I see some value of this kind of parameter also for the real-time case. >>>>>>> The time is here when it can be possible in some situations to >>>>>>> select between using a low-cost automatic speech-to-text generation >>>>>>> and a higher cost captioned telephony or text-relay service (higher >>>>>>> cost for someone, not always the end-user). >>>>>>> >>>>>>> But I agree that it is very hard to set good understandable values >>>>>>> on a parameter expressing the type or quality of this kind of service. >>>>>>> >>>>>>> Gunnar >>>>>>> >>>>>>> >>>>>>> >>>>>>> Stephane Bortzmeyer skrev den 2015-07-03 08:49: >>>>>>> >>>>>>> On Thu, Jul 02, 2015 at 11:09:30PM +0100, >>>>>>> Nik Tomkinson >>>>>>> <rfc.nik.tomkinson@gmail.com> wrote >>>>>>> a message of 109 lines which said: >>>>>>> >>>>>>> type-token := "original" / "human" / "automated" >>>>>>> >>>>>>> In many IETF working groups, when there is such a proposal, there is a >>>>>>> big discussion between the registryfull and the registryless >>>>>>> people. The first ones say there must be an authoritative list of >>>>>>> values (in the RFC or, better because more evolving, in an IANA >>>>>>> registry) so we can be sure of the interpretation of values. The >>>>>>> second ones say we can never capture all the nuances and subtleties of >>>>>>> the world in a fixed list. >>>>>>> >>>>>>> Here, I am not sure that the only meaningful distinction is between >>>>>>> "human" and "automated". Some humans do a very poor job, too. One >>>>>>> could suggest: >>>>>>> >>>>>>> type-token := "original" / "professional-human" / "amateur-human" / >>>>>>> "automated-first-generation" / "automated-artificial-intelligence" / >>>>>>> "automated-the-robot-in-hollywood-movies" >>>>>>> >>>>>>> Or decide that it will be too complicated and we should instead >>>>>>> accept: >>>>>>> >>>>>>> type-token := "original" / >>>>>>> >>>>>>> Toughts? >>>>>>> >>>>>>> _______________________________________________ >>>>>>> SLIM mailing list >>>>>>> SLIM@ietf.org >>>>>>> >>>>>>> https://www.ietf.org/mailman/listinfo/slim >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> SLIM mailing list >>>>>>> SLIM@ietf.org >>>>>>> >>>>>>> https://www.ietf.org/mailman/listinfo/slim >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> ----------------------------------------------------------------- >>>>>>> Multiple Language Content Type Internet Draft: >>>>>>> >>>>>>> http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/ >>>>>>> >>>>>>> ----------------------------------------------------------------- >>>>>>> >>>>>>> _______________________________________________ >>>>>>> SLIM mailing list >>>>>>> SLIM@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/slim >>>>>> >>>>>> >>>> _______________________________________________ >>>> SLIM mailing list >>>> SLIM@ietf.org >>>> https://www.ietf.org/mailman/listinfo/slim >> -- >> ----------------------------------------- >> Gunnar Hellström >> Omnitor >> gunnar.hellstrom@omnitor.se >> +46 708 204 288 >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim > > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------090601010102040505030600 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Thanks Eric for sensible answers.

Eric Burger skrev den 2015-07-06 10:43:

      

        
On Jul 6, 2015, at 3:24 AM, Gunnar Hellström <gunnar.hellstrom@omnitor.se> wrote:

One reason for the need to convey a translation service provider URI is that the emergency service RFCs 6443 and 6881 forbids the calling user to invoke three-party calling.


      

      
6443 is informational and 6881 is a BCP. No problem to do something that works that is ‘forbidden.’



      

        
For example RFC 6443, chapter 13 says "Services such as call waiting, call transfer, three-way calling, and hold should be disabled.”


      

      
Note the use of ‘should.’  I do not think anyone will complain if one interprets this as, “Should be disabled, unless the user will die if she does not setup a three-way call with her translation service.”



      

        
If then the user is in a foreign language environment where the PSAP barely can have a clue on how to find the right relay service, and the user has a good relay service URI configured, well capable of handling the user's language and modality, what is then best?

1) Break against RFC 6881 and 6443 and have the user terminal invoke the three-party call? The wording in these RFCs may be interpreted to have some room for such deviations.


      

      
Beyond the wording in the RFCs, there is a reason the IETF is not the protocol police. In retrospect, it may be safe to say the RFCs’ suggestions are wrong.



      

        
2) Or convey the relay service URI to the PSAP for invocation.


      

      
Why not?

    

    One example of a procedure for such invocation is in EENA NG112 LTD
    and NENA NG9-1-1 i3 08-003 procedure for third party invocation,
    (chapter 9) where the third party service, who happens to get the
    emergency call first, refers back to the emergency caller to make
    the call to urn:service:sos with the third party URI in the
    Referred-by  field. The PSAP is then supposed to conference-in the
    third party. ( I have not seen how they deduce that the third party
    shall be conferenced-in, but their address is anyway conveyed to the
    PSAP. )

    

      



      

        
The discussion so far leads towards conclusion 1. It is ok for me, I just wanted it confirmed by showing the whole situation.

(there will always be complementing slow manual procedures, when the PSAP needs to figure out a reasonable way to handle the call, but this discussion is for the rapid automated way that should handle most cases.)

/Gunnar

Gunnar Hellström skrev den 2015-07-05 22:35:


        

          
Paul,
Yes, I agree that for most cases it is best that the party, who knows a service that will do the translation, does the invocation.

And, yes ,in that scenario the 3PCC method seems suitable.

My proposal to send the service provider URI together with the modality indications was for the case when there are strong policy reasons why one party would do the invocation, but little chance that that party would have access to an up-to-date information on available translation providers.
That could be the case for the emergency service calling in a multi-language environment, also including support for sign language users.

Since both you and Randall think it is not doable, we can try to use the principle that the party, who knows a service that will do the translation, does the invocation.

That brings us back to a need for more stringent language/modality negotiation in order to avoid both double invocation of services when one or none is required, and also avoid no invocation when one is needed.

Paul Kyzivat skrev den 2015-07-05 18:20:


          

            
Gunnar,

I understand what you are suggesting, but I don't believe it is workable. This seems to mean that the caller would select the service while the callee would engage the service in the call if needed. Yet it is likely to be the caller who has a business relationship with the service, while the callee does not. Gets complicated quickly.

ISTM it makes more sense to first figure out what is/isn't possible without translation, and then for a party that finds a translation service beneficial to engage one. Then the only concern is that both parties don't independently try to introduce equivalent translation services.

For instance, a deaf caller might offer video media marked for sign language, and audio media on hold. If the answer doesn't accept the video, or doesn't indicate support for sign language, the caller could then conference in translation service, using the 3pcc transcoding model specified in rfc5369. (If that will take time, the deaf caller's UA could stream recorded media over the audio channel in the meantime.)

Or, to get fancier, it would be possible to use preconditions to defer alerting the callee until this is all sorted out.

My point is to let the participant who wants translation handle to setup of translation rather than depending on the other party to do something.


          

          
OK, it might be likely that both parties "want" translation, but one has better knowledge about how to get the required service and has business relations with the service. So then it is preferred that that party invokes.

Good
/Gunnar


          

            
   Thanks,
   Paul

On 7/5/15 2:48 AM, Gunnar Hellström wrote:


            

              
Another opportunity would be to convey a URI to the service provider who
did (for mail) or can do(for real-time) the translation.
Then experience with different service provider's production could give
some idea of the expected quality.
I can see great value in that for the real-time case, when the calling
user has a favourite translator (e.g. relay service), and provides that
as a hint if languages or modalities in the call does not match. Then
the callee do not need to just take a service provider by chance that
seem to match the language/modality profile but can take the one
proposed by the caller.

After working with the needs for emergency services to work across
Europe for some time now, I think this is one of the few workable
solutions. The user expresses both the language/modality needs and
provides a URI to a favourite translation service provider, and the
callee tries to fulfill the language/modality needs either by a matching
original call taker or by invoking the proposed translation provider.

/Gunnar


Randall Gellens skrev den 2015-07-05 03:49:


              

                
My recollection is that this was discussed in email prior to Dallas,
but that's not important.

I am a strong proponent of keeping things as simple as possible,
provided there is a way to extend them if experience shows that it is
needed.  So, I think we should stick with the original suggestion of
three values ("original", "human", "automated"). This is simple enough
to be implementable and functional enough to be useful in providing a
hint that may help the client choose the best version for the user. If
we try and capture the various nuances of quality we will end up with
a very complex mechanism that is unlikely to be any more useful in
real life. Let's go with the simple approach now.  If, after some
deployment experience we realize that we really do need extra
complexity, we can extend the mechanism then.

At 4:29 PM +0100 7/3/15, Nik Tomkinson wrote:



                

                  
Thanks for the responses.

To deal with the issue with having only original/human/automated,
what about the following?:


translation-type := type-token[ ";" "q" "=" qvalue ]
type-token :="human" / "automated"

where qvalue is a value between 0 and 1 with a default of 0.5 if
missing

for example:

Translation-Type: human;q=0.8
Translation-Type: automated;q=0.4
Translation-Type: human

The Translation-Type SHOULD NOT appear in the original
(untranslated) part but it SHOULD appear in translated content.

Having this missing from the original text helps identify which is
the source to be translated into further languages if the user mail
client allows.

This enables us to dispose of the 'original' value which didn't lend
itself well to being graded on quality.

The qvalue can be set by the sender or provided by the translation
service.

The draft suggests that:

"Additionally, interactive implementations MAY offer the user a
choice from among the available languages." so the qvalue may not
need to be bulletproof.

Comments?

Nik.

On 3 July 2015 at 09:46, Gunnar Hellström
<<mailto:gunnar.hellstrom@omnitor.se>gunnar.hellstrom@omnitor.se> wrote:

I see some value of this kind of parameter also for the real-time case.
The time is here when it can be possible in some situations to
select between using a low-cost automatic speech-to-text generation
and a higher cost captioned telephony or text-relay service (higher
cost for someone, not always the end-user).

But I agree that it is very hard to set good understandable values
on a parameter expressing the type or quality of this kind of service.

Gunnar



Stephane Bortzmeyer skrev den 2015-07-03 08:49:

On Thu, Jul 02, 2015 at 11:09:30PM +0100,
  Nik Tomkinson
<<mailto:rfc.nik.tomkinson@gmail.com>rfc.nik.tomkinson@gmail.com> wrote
  a message of 109 lines which said:

type-token := "original" / "human" / "automated"

In many IETF working groups, when there is such a proposal, there is a
big discussion between the registryfull and the registryless
people. The first ones say there must be an authoritative list of
values (in the RFC or, better because more evolving, in an IANA
registry) so we can be sure of the interpretation of values. The
second ones say we can never capture all the nuances and subtleties of
the world in a fixed list.

Here, I am not sure that the only meaningful distinction is between
"human" and "automated". Some humans do a very poor job, too. One
could suggest:

type-token := "original" / "professional-human" / "amateur-human" /
"automated-first-generation" / "automated-artificial-intelligence" /
"automated-the-robot-in-hollywood-movies"

Or decide that it will be too complicated and we should instead
accept:

type-token := "original" / <free text>

Toughts?

_______________________________________________
SLIM mailing list
<mailto:SLIM@ietf.org>SLIM@ietf.org

<https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim



_______________________________________________
SLIM mailing list
<mailto:SLIM@ietf.org>SLIM@ietf.org

<https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim





--

-----------------------------------------------------------------
Multiple Language Content Type Internet Draft:

<http://datatracker.ietf.org/doc/draft-tomkinson-multilangcontent/>http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/

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

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


                

                




              

              

            

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


          

          

        

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

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


      

      

      

      

      

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


    

    

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

  


--------------090601010102040505030600--


From nobody Mon Jul  6 02:53:45 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0721AC42D for ; Mon,  6 Jul 2015 02:53:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.012
X-Spam-Level: 
X-Spam-Status: No, score=-1.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=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 hDA2SPAkMfdQ for ; Mon,  6 Jul 2015 02:53:43 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AA341AC408 for ; Mon,  6 Jul 2015 02:53:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default;  h=In-Reply-To:To:References:Date:Subject:Mime-Version:Message-Id:Content-Type:From; bh=yg/TMiJXUFGyzb3xYEDAegqXBTZ0szcvi0Irq5V/C5g=;  b=YeEZxreGwSsiDyvlCpn4YSuEyiV3R+lZcqv0LDX3Lpf707z4Obkt0XJcKKcJfDHAk0rM0KLOOCe5KOktl5pdTzqZTUYv1NVYMqPlLPLGJMc4FRe57/JhhWf0xCue4fOwpXWUsiLDCESdjBhkXbf/4UnLD1BnLIVOu3zoHy3qmUg=;
Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:49709 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZC35p-0002jp-Jk for slim@ietf.org; Mon, 06 Jul 2015 02:53:43 -0700
From: Eric Burger 
Content-Type: multipart/signed; boundary="Apple-Mail=_44AAAA30-7197-4EEE-BA82-00667B8F71C4"; protocol="application/pkcs7-signature"; micalg=sha1
Message-Id: <09BFFC5C-C738-40F0-845C-A3C4B3029BF4@standardstrack.com>
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Date: Mon, 6 Jul 2015 05:53:40 -0400
References:  <20150703064908.GA14666@sources.org> <55964BED.1080905@omnitor.se>   <5598D34A.6070001@omnitor.se> <55995958.5050109@alum.mit.edu> <55999526.7030006@omnitor.se> <559A2D44.1010308@omnitor.se>  <559A48CF.7060703@omnitor.se> <5B0808A6-776E-4751-A398-AB36F9DC93DC@georgetown.edu>
To: slim@ietf.org
In-Reply-To: <5B0808A6-776E-4751-A398-AB36F9DC93DC@georgetown.edu>
X-Mailer: Apple Mail (2.2098)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.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: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
Archived-At: 
Subject: Re: [Slim] Translation Quality or type - or service provider
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Jul 2015 09:53:44 -0000

--Apple-Mail=_44AAAA30-7197-4EEE-BA82-00667B8F71C4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

> On Jul 6, 2015, at 5:22 AM, Gunnar Hellstr=F6m =
 wrote:
>=20
>>> 2) Or convey the relay service URI to the PSAP for invocation.
>>>=20
>> Why not?
> One example of a procedure for such invocation is in EENA NG112 LTD =
and NENA NG9-1-1 i3 08-003 procedure for third party invocation, =
(chapter 9) where the third party service, who happens to get the =
emergency call first, refers back to the emergency caller to make the =
call to urn:service:sos with the third party URI in the Referred-by  =
field. The PSAP is then supposed to conference-in the third party. ( I =
have not seen how they deduce that the third party shall be =
conferenced-in, but their address is anyway conveyed to the PSAP. )

I was thinking of one of Paul=92s comments. I suppose the problem can be =
that an attacker can put =91interesting=92 URI=92s in for =93conference =
services=94 that actually are DDoS attack victims. We could make it =
impossible for a caller to put in their preferred translation service or =
we can point out the vulnerability and say the PSAP needs to have =
policies in place such that it is clear the translation service URI is a =
suggestion, not a request.

We have a similar (but not quite the same) problem with today=92s VRS in =
the U.S. with respect to fraud. One could imagine a PSAP has contracted =
with economical, experienced, and very good translation services. An =
indigent individual may have been coerced to sign up with a very =
expensive, poor quality sham of a translation service. We need to make =
clear in the =93how to use SLIM=94 section of the document that it is up =
to the PSAP (? my guess here) to decide whether or not to take the =
caller=92s suggestion (note I am not calling it a request) for a =
particular translation service provider.


--Apple-Mail=_44AAAA30-7197-4EEE-BA82-00667B8F71C4
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQpjCCBUAw
ggQooAMCAQICEQCuNx1clInO3pDdx/tx5ymMMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH
QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK
ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj
YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNDEwMDgwMDAwMDBaFw0xNTEwMDgyMzU5NTla
MCsxKTAnBgkqhkiG9w0BCQEWGmVidXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0HJR1ciLrHT/CjRECPUsdCrORWwHwf9AA9jE6tX8y8sqqrnY
jPw4YtahKkLP+3VLXEjTWLi9nl0ISFtrZ+sq27HUuPmaiNtjqWgCjyPjfUi5PEDiJE3CSR8CK8Z6
iLO09oNTlSLY6qmKxVB4MEp8rRvOYTDk4nC2wCgMRzpUXE8q44d8LPYSe1V1o4eSSRXby2gxrTMw
F/RLKGeSyB2ekee0c68FMZmfPR8kp43jM0SlZqgXLkf8ATTF9BxeznwqTC7GxXRJJi30d9dNQIl1
4M7J0c3kY7VpAHFXCh/KuNki0e6LKnhJrMXzVvou1OqCgI0xbCQJbMkjm8hXXxYU7wIDAQABo4IB
8DCCAewwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFK1jQ8667Bo+
kfpdpUC1bTmlMzGLMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG
AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEE
AbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYD
VR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0
aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUF
BzAChklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlv
bmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j
b20wJQYDVR0RBB4wHIEaZWJ1cmdlckBzdGFuZGFyZHN0cmFjay5jb20wDQYJKoZIhvcNAQELBQAD
ggEBAGYB/MbhzXClCc4fPctp4HBusRbgGt05ngOvKLih3vUY4xSG6FV+5BaRt5/MvnnIATlf/dxt
GBmeX3X124irtI2EIkd7xEStZlrSzDm3eIv0wW3DeKY8V9BlTKSmPO6sXl1qU8WJoNZvXOhs52do
Y4CTURs4uuttjbuEH3PQ32lO8M5lPqMnvj/qhGxh2Sg7mRop2kGitqLB6HHqGyh1t32SY16wWvPT
ovhq/38sPFamVK0FOC68LGxeKYD4KOf6GQkteQkQG+uqCEdpi4k2EwTtK43bVbeZ1rSzPMC5HRln
m+qPgE7ZWxBQlvdd5sQtBUz5Dl5lqj9kQ3YQz6XFNAMwggV0MIIEXKADAgECAhAnZu5W60nzjqvX
cKL8hN4iMA0GCSqGSIb3DQEBDAUAMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBB
QjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRy
dXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMDAwNTMwMTA0ODM4WhcNMjAwNTMwMTA0ODM4WjCBhTEL
MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlm
aWNhdGlvbiBBdXRob3JpdHkwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCR6FSS0gpW
sawNJN3Fz0RndJkrN6N9I3AAcbxT38T6KhKPS38QVr2fcHK3YX/JSw8Xpz3jsARh7v8Rl8f0hj4K
+j5c+ZPmNHrZFGvnnLOFoIJ6dq9xkNfs/Q36nGz637CC9BR++b7Epi9Pf5l/tfxnQ3K9DADWietr
LNPtj5gcFKt+5eNu/Nio5JIk2kNrYrhV/erBvGy2i/MOjZrkm2xpmfh4SDBF1a3hDTxFYPwyllEn
vGfDyi62a+pGx8cgoLEfZd5ICLqkTqnyg0Y3hOvozIFIQ2dOciqbXL1MGyiKXCJ7tKuY2e7gUYPD
CUZObT6Z+pUX2nwzV0E8jVHtC7ZcryxjGt9XyD+86V3Em69FmeKjWiS0uqlWPc9vqv9JWL7wqP/0
uK3pN/u6uPQLOvnoQ0IeidiEyxPx2bvhiWC4jChWrBQdnArncevPDt09qZahSL0896+1DSJMwBGB
7FY79tOi4lu3sgQiUpWAk2nojkxl8ZEDLXB0AuqLZxUpaVICu9ffUGpVRr+goyhhf3DQw6KqLCGq
R84onAZFdr+CGCe01a60y1Dma/RMhnEw6abfFobg2P9A3fvQQoh/ozM6LlweQRGBY84YcWsr7KaK
tzFcOmpH4MN5WdYgGq/yapiqcrxXStJLnbsQ/LBMQeXtHT1eKJ2czL+zUdqnR+WEUwIDAQABo4H0
MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBS7r34CPfqm8TyE
jq3uOJjs2TIy1DAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAIMAYG
BFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0
RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29j
c3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0BAQwFAAOCAQEAZL+D8V+ahdDNuKEpVw3oWvfR6T7y
dgRu8VJwux48/00NdGrMgYIl08OgKl1M9bqLoW3EVAl1x+MnDl2EeTdAE3f1tKwc0DurFxLW7zQY
fivpedOrV0UMryj60NvlUJWIu9+FV2l9kthSynOBvxzz5rhuZhEFsx6ULX+RlZJZ8UzOo5FxTHxH
DDsLGfahsWyGPlyqxC6Cy/kHlrpITZDylMipc6LrBnsjnd6i801Vn3phRZgYaMdeQGsj9Xl674y1
a4u3b0b0e/E9SwTYk4BZWuBBJB2yjxVgWEfb725G/RX12V+as9vYuORAs82XOa6Fux2OvNyHm9Gm
7/E7bxA4bzCCBeYwggPOoAMCAQICEGqb4Tg7/ytrnwHV2binUlYwDQYJKoZIhvcNAQEMBQAwgYUx
CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv
cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMSswKQYDVQQDEyJDT01PRE8gUlNBIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MB4XDTEzMDExMDAwMDAwMFoXDTI4MDEwOTIzNTk1OVowgZcxCzAJ
BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx
GjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBB
dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEAvrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6cpzEup/Y0dtmEatrQPTRI
5Or1u6zf+bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDIMypVpVSRsivlJTRENf+R
KwrB6vcfWlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYKjrc5NOpG9qrxpZxyb4o4
yNNwTqzaaPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRikw8lBoNoSWY66nJN/VCJv5ym6
Q0mdCbDKCMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsUtQIDAQABo4IBPDCCATgwHwYDVR0j
BBgwFoAUu69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0OBBYEFIKvbIz4xf6WYXzoHz0rcUhexIvA
MA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBM
BgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDZXJ0aWZp
Y2F0aW9uQXV0aG9yaXR5LmNybDBxBggrBgEFBQcBAQRlMGMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9j
cnQuY29tb2RvY2EuY29tL0NPTU9ET1JTQUFkZFRydXN0Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRw
Oi8vb2NzcC5jb21vZG9jYS5jb20wDQYJKoZIhvcNAQEMBQADggIBAHhcsoEoNE887l9Wzp+XVuyP
omsX9vP2SQgG1NgvNc3fQP7TcePo7EIMERoh42awGGsma65u/ITse2hKZHzT0CBxhuhb6txM1n/y
78e/4ZOs0j8CGpfb+SJA3GaBQ+394k+z3ZByWPQedXLL1OdK8aRINTsjk/H5Ns77zwbjOKkDamxl
pZ4TKSDMKVmU/PUWNMKSTvtlenlxBhh7ETrN543j/Q6qqgCWgWuMAXijnRglp9fyadqGOncjZjaa
SOGTTFB+E2pvOUtY+hPebuPtTbq7vODqzCM6ryEhNhzf+enm0zlpXK7q332nXttNtjv7VFNYG+I3
1gnMrwfHM5tdhYF/8v5UY5g2xANPECTQdu9vWPoqNSGDt87b3gXb1AiGGaI06vzgkejL580ul+9h
z9D0S0U4jkhJiA7EuTecP/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2aPY8ydehzuZutLbZdRJ5
PDEJM/1tyZR2niOYihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/GqK2HsOgkL3VYnwtx7cJU
mpvVdZ4ognzgXtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+85hFQzVxZx5/bRaTKTlL8
YXLI8nAbR9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYIDujCCA7YCAQEwga0wgZcx
CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv
cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEArjcdXJSJzt6Q3cf7cecpjDAJ
BgUrDgMCGgUAoIIB4TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0x
NTA3MDYwOTUzNDBaMCMGCSqGSIb3DQEJBDEWBBSHDM1oT6F7R3fMA5Vo3gBYP7XGkzCBvgYJKwYB
BAGCNxAEMYGwMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy
MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0
Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAK43
HVyUic7ekN3H+3HnKYwwgcAGCyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkG
A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P
RE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24g
YW5kIFNlY3VyZSBFbWFpbCBDQQIRAK43HVyUic7ekN3H+3HnKYwwDQYJKoZIhvcNAQEBBQAEggEA
fV5OV5WJzzvIR1AWRqpe2Gsf+qADkEYAjL78z7DcaBr5x8zdRheI+DZ57oCapsZsdQbgkx7WfenZ
/pW40Iwjr99BXmsu4gYSdQrHV0DJQhRQ+b1wTiEI5HQQ3f9geT0xv/pF7nS1xX0WWX6ysWM6+HXP
hel0O1hyT+U8kZtTKGbx+FiTWMKmI+5APRl8N8xFWN+Icug2QhxLVGcAaiB+tLqaKU9T3cSjCagF
2mOnPwYP3cDnsch1s448yGwbEsH9OQ8oTuVwsuXulLMup/RC2Mxed0vVAfr3AWmxdoke8CShnjVe
ukM02dcntGYPbCT0emSjOA3cTRE01Z68EuuOLgAAAAAAAA==
--Apple-Mail=_44AAAA30-7197-4EEE-BA82-00667B8F71C4--


From nobody Mon Jul  6 03:28:43 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A34861ACD36 for ; Mon,  6 Jul 2015 03:28:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 I4S1iclgbq9z for ; Mon,  6 Jul 2015 03:28:39 -0700 (PDT)
Received: from bin-vsp-out-04.atm.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 CDB351ACD35 for ; Mon,  6 Jul 2015 03:28:38 -0700 (PDT)
X-Halon-ID: bf87acc7-23c9-11e5-b1dc-005056917c0c
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.43.70] (unknown [2.65.89.236]) by bin-vsp-out-04.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Mon,  6 Jul 2015 12:28:30 +0200 (CEST)
Message-ID: <559A5850.3090600@omnitor.se>
Date: Mon, 06 Jul 2015 12:28:32 +0200
From: =?windows-1252?Q?Gunnar_Hellstr=F6m?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: slim@ietf.org
References: <20150706054737.12312.647.idtracker@ietfa.amsl.com>
In-Reply-To: <20150706054737.12312.647.idtracker@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------020205000708090103070209"
Archived-At: 
Subject: [Slim] Expected use - relative to SIP and specific service requests in draft-gellens-slim-negotiating-human-language-02
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Jul 2015 10:28:42 -0000

This is a multi-part message in MIME format.
--------------020205000708090103070209
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

I saw that -02 is out. Good!

A couple of comments:

1. Expected use relative to SIP.

It seems decided now that the mechanism will be adapted to use in SDP.

The use of the Accept-Language media tag is already described for 
negotiation of language in emergency calls in RFC 6443, e.g. in section 9.2:
"

    SIP caller preferences [RFC3841  ] can be used to signal how the PSAP
    should handle the call.  For example, a language preference expressed
    in an Accept-Language header may be used as a hint to cause the PSAP
    to route the call to a call taker who speaks the requested language.
    SIP caller preferences may also be used to indicate a need to invoke
    a relay service for communication with people with disabilities in
    the call."


Since this recommendation already is there, it seems that we need to 
describe how the humintlang parameter in SDP relates to it.

I suggest to add to chapter 3, Expected use, the following paragraph:

"Basic preferencs and capabilities for languages modalities and media 
can be expressed by media tags in SIP. These indications may be used in 
parallell with the indications specified in this document. Some aspects 
such as directionality, and exact order of preference are not possible 
to specify at SIP level. Therefore, parties who have such detailed 
preferences or capabilities are recommended to use the coding specified 
in this document. Parties performing negotiation and routing should take 
both sets of indications into consideration. In cases when the 
indication seem to be contradicting, the indications specified in this 
document should be used. "

2. Service requests instead of language and modality indications.
There are two kinds of common relay services that I cannot see how we 
can indicate need for using the coding we have specified so far.
I see a need to either extend the coding or recognize the limitation in 
scope to not cover these two relay service types.

The two cases are:

A) A person with hearing loss, being accustomed to have the captioned 
telephony service.
This service provides:
1) voice through from the primary user to the  other user.
2) voice through from the other user to the primary user.
3) rapidly added real-time text transcription of the speech to the 
primary user sent for presentation to the primary user. Ideally all 
words the other user says is converted to text and the delay from being 
said to being displayed should only be a few seconds.

The users might have some use of seeing each other in video, and the 
primary user may as a last resort accept to have text typed with normal 
typing speed if that is the only available replacement.

Expressing this in SLIM terms would require that the primary user expresses:
( I do not include the language here, but just the modality in order to 
not complicate it further )
1. preference for speech transmission,
2. capability but no specific preference for video transmission
3. strong preference for speech reception AND strong preference for 
rapid captioning of received speech to real-time text reception
4. some acceptance of real-time text reception as alternative to 
captioning.
5. capability but no specific preference for video reception

Since no other user can be expected to both talk and type the same thing 
at the rate of talking.  Maybe it can be solved in some cases by 
automated captioning.
Do we want to introduce two types or qualities of text translation; 
rapid vs "normal"?  I see some similarity with the translation type and 
quality discussion. Note that this is only of interest for translated 
media. Shall we create a coding that clearly requests rapid caption, or 
shall we say that for this need, the user should make a service request 
instad?

B) A person with weak or otherwise hard-to-understand speech or 
cognitive problems with spoken conversations.
This primary user is normally a user of a Speech-to-speech relay service.
That service offers:

1. Speech through from the primary user to the other user.
2. Speech through from the other user to the primary user
3. A communication agent in a full 3-party voice bridge connection, 
supporting the primary user with the communication needs, consisting of 
e.g. : a) repeating in clear speech what the primary user expresses in 
weak or hard-to-understand speech. b) noting what has been said in the 
call in order to refresh the memory of the primary user during or after 
the call. c) Reminding the primary user of the purpose and plan for the 
call when needed.
4. Optionally two way video between the primary user and the 
communications agent. This can ease understanding.
5. Optionally two way text between the primary user and the 
communications agent. This can be an alternative in case of problems.

Some speech-to-speech service users might be prepared to as a last 
resort conduct calls where the primary user types real-time text and the 
other user uses speech.

We have not even talked about the modalities of "weak or 
hard-to-understand speech" and "needs for memory refresh and other 
cognitive support" in SLIM, and it causes severe frustration and 
inefficiency for both parties if a speech-to-speech user is left in a 
call without support from the service,  so I think this need is better 
served by a service need expression for the specch-to-speech service.

That would call for an addition in section 3:

"Some needs of services to enable real-time conversational interaction 
cannot easily be described as language and modality preferences and 
capabilities. Other mechanisms for invoking suitable assisting services 
may be used for such cases."


/Gunnar
internet-drafts@ietf.org skrev den 2015-07-06 07:47:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>          Title           : Negotiating Human Language in Real-Time Communications
>          Author          : Randall Gellens
> 	Filename        : draft-gellens-slim-negotiating-human-language-02.txt
> 	Pages           : 19
> 	Date            : 2015-07-05
>
> Abstract:
>     Users have various human (natural) language needs, abilities, and
>     preferences regarding spoken, written, and signed languages.  When
>     establishing interactive communication ("calls") there needs to be a
>     way to negotiate (communicate and match) the caller's language and
>     media needs with the capabilities of the called party.  This is
>     especially important with emergency calls, where a call can be routed
>     to a Public Safety Answering Point (PSAP) or call taker capable of
>     communicating with the user, or a translator or relay operator can be
>     bridged into the call during setup, but this applies to non-emergency
>     calls as well (as an example, when calling a company call center).
>
>     This document describes the need and expected use, and describes a
>     solution using new SDP stream attributes.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-gellens-slim-negotiating-human-language/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-gellens-slim-negotiating-human-language-02
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-gellens-slim-negotiating-human-language-02
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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


--------------020205000708090103070209
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    I saw that -02 is out. Good!

    

    A couple of comments:

    

    1. Expected use relative to SIP.

    

    It seems decided now that the mechanism will be adapted to use in
    SDP.

    

    The use of the Accept-Language media tag is already described for
    negotiation of language in emergency calls in RFC 6443, e.g. in
    section 9.2:

    "

    
   SIP caller preferences [RFC3841] can be used to signal how the PSAP
   should handle the call.  For example, a language preference expressed
   in an Accept-Language header may be used as a hint to cause the PSAP
   to route the call to a call taker who speaks the requested language.
   SIP caller preferences may also be used to indicate a need to invoke
   a relay service for communication with people with disabilities in
   the call."

    

    Since this recommendation already is there, it seems that we need to
    describe how the humintlang parameter in SDP relates to it.

    

    I suggest to add to chapter 3, Expected use, the following
    paragraph:

    

    "Basic preferencs and capabilities for languages modalities and
    media can be expressed by media tags in SIP. These indications may
    be used in parallell with the indications specified in this
    document. Some aspects such as directionality, and exact order of
    preference are not possible to specify at SIP level. Therefore,
    parties who have such detailed preferences or capabilities are
    recommended to use the coding specified in this document. Parties
    performing negotiation and routing should take both sets of
    indications into consideration. In cases when the indication seem to
    be contradicting, the indications specified in this document should
    be used. "

    

    2. Service requests instead of language and modality indications.

    There are two kinds of common relay services that I cannot see how
    we can indicate need for using the coding we have specified so far.
    

    I see a need to either extend the coding or recognize the limitation
    in scope to not cover these two relay service types. 

    

    The two cases are:

    

    A) A person with hearing loss, being accustomed to have the
    captioned telephony service. 

    This service provides: 

    1) voice through from the primary user to the  other user.

    2) voice through from the other user to the primary user.

    3) rapidly added real-time text transcription of the speech to the
    primary user sent for presentation to the primary user. Ideally all
    words the other user says is converted to text and the delay from
    being said to being displayed should only be a few seconds.

    

    The users might have some use of seeing each other in video, and the
    primary user may as a last resort accept to have text typed with
    normal typing speed if that is the only available replacement.

    

    Expressing this in SLIM terms would require that the primary user
    expresses:

    ( I do not include the language here, but just the modality in order
    to not complicate it further )

    1. preference for speech transmission, 

    2. capability but no specific preference for video transmission

    3. strong preference for speech reception AND strong preference for
    rapid captioning of received speech to real-time text reception

    4. some acceptance of real-time text reception as alternative to
    captioning.   

    5. capability but no specific preference for video reception

    

    Since no other user can be expected to both talk and type the same
    thing at the rate of talking.  Maybe it can be solved in some cases
    by automated captioning. 

    Do we want to introduce two types or qualities of text translation;
    rapid vs "normal"?  I see some similarity with the translation type
    and quality discussion. Note that this is only of interest for
    translated media. Shall we create a coding that clearly requests
    rapid caption, or shall we say that for this need, the user should
    make a service request instad? 

    

    B) A person with weak or otherwise hard-to-understand speech or
    cognitive problems with spoken conversations. 

    This primary user is normally a user of a Speech-to-speech relay
    service.

    That service offers:

    

    1. Speech through from the primary user to the other user.

    2. Speech through from the other user to the primary user

    3. A communication agent in a full 3-party voice bridge connection,
    supporting the primary user with the communication needs, consisting
    of e.g. : a) repeating in clear speech what the primary user
    expresses in weak or hard-to-understand speech. b) noting what has
    been said in the call in order to refresh the memory of the primary
    user during or after the call. c) Reminding the primary user of the
    purpose and plan for the call when needed.  

    4. Optionally two way video between the primary user and the
    communications agent. This can ease understanding.

    5. Optionally two way text between the primary user and the
    communications agent. This can be an alternative in case of
    problems.

    

    Some speech-to-speech service users might be prepared to as a last
    resort conduct calls where the primary user types real-time text and
    the other user uses speech.

    

    We have not even talked about the modalities of "weak or
    hard-to-understand speech" and "needs for memory refresh and other
    cognitive support" in SLIM, and it causes severe frustration and
    inefficiency for both parties if a speech-to-speech user is left in
    a call without support from the service,  so I think this need is
    better served by a service need expression for the specch-to-speech
    service. 

    

    That would call for an addition in section 3:

    

    "Some needs of services to enable real-time conversational
    interaction cannot easily be described as language and modality
    preferences and capabilities. Other mechanisms for invoking suitable
    assisting services may be used for such cases."

    

    

    /Gunnar

    
internet-drafts@ietf.org skrev den
      2015-07-06 07:47:

    

    

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


        Title           : Negotiating Human Language in Real-Time Communications
        Author          : Randall Gellens
	Filename        : draft-gellens-slim-negotiating-human-language-02.txt
	Pages           : 19
	Date            : 2015-07-05

Abstract:
   Users have various human (natural) language needs, abilities, and
   preferences regarding spoken, written, and signed languages.  When
   establishing interactive communication ("calls") there needs to be a
   way to negotiate (communicate and match) the caller's language and
   media needs with the capabilities of the called party.  This is
   especially important with emergency calls, where a call can be routed
   to a Public Safety Answering Point (PSAP) or call taker capable of
   communicating with the user, or a translator or relay operator can be
   bridged into the call during setup, but this applies to non-emergency
   calls as well (as an example, when calling a company call center).

   This document describes the need and expected use, and describes a
   solution using new SDP stream attributes.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-gellens-slim-negotiating-human-language/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-gellens-slim-negotiating-human-language-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-gellens-slim-negotiating-human-language-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


    

    

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

  


--------------020205000708090103070209--


From nobody Mon Jul  6 04:18:54 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 682DB1A883C for ; Mon,  6 Jul 2015 04:18:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level: 
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 rRl9fh3JwPvX for ; Mon,  6 Jul 2015 04:18:50 -0700 (PDT)
Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8091F1A8876 for ; Mon,  6 Jul 2015 04:18:50 -0700 (PDT)
Received: by ykdr198 with SMTP id r198so144634778ykd.3 for ; Mon, 06 Jul 2015 04:18:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dmQTVmRO6y6JJvB5gxEsdz+rBHuedDmgW58EnNws2I0=; b=HsCgETkuIMhdMwyrfjsa/RJr9AkKvKhCKQGkNmgBCzI+JRhcdY//0IrafvD1E+ZKy9 jE8fSDgjY4GKe7QdDp0nB9l3q5sJWqsoFvVlrlWfVUyKmS7qp2FTJc+DqooJ+aNgVQoG fPUx66O9SV61kTf+vYdvR5e++Xun2nUz55mVx/47/sq2HIBXNoy6Ny6l3WnwuFNLG9kj B6pPIhun+C2ZXyUJFKPMAcSeqfJWAEvlUtapN5jJKeijtA2bPp2Fs0MaYnuH61JMk21S wgiZyGRBa2TdyDCT3NLYtJyEaKjBjxzPdBqzO5nSl+UxaaUcTRCAoIUzTU7POOhO2Vpm XskQ==
MIME-Version: 1.0
X-Received: by 10.170.46.14 with SMTP id 14mr14667292yko.120.1436181529886; Mon, 06 Jul 2015 04:18:49 -0700 (PDT)
Received: by 10.37.112.7 with HTTP; Mon, 6 Jul 2015 04:18:49 -0700 (PDT)
In-Reply-To: <559A27CA.1060800@omnitor.se>
References:  <20150703064908.GA14666@sources.org> <55964BED.1080905@omnitor.se> <5596B184.2020908@alum.mit.edu> <0A0D0CE1-01AC-411B-86B6-176A92C223A8@standardstrack.com>  <5599A9FE.60401@alum.mit.edu> <559A27CA.1060800@omnitor.se>
Date: Mon, 6 Jul 2015 12:18:49 +0100
Message-ID: 
From: Nik Tomkinson 
To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= 
Content-Type: multipart/alternative; boundary=001a11379d60ec04be051a331168
Archived-At: 
Cc: slim@ietf.org
Subject: Re: [Slim] Translation Quality or type
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Jul 2015 11:18:53 -0000

--001a11379d60ec04be051a331168
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

1 - Yes, and if the Translation-Type value is missing then the recipient's
email client will have to select the translation based just on the
preferred language only and ignore any user type preference.
2 - I think for now the simplicity outweighs any use case for that. At the
moment, I can't think of any case where the recipient would make use of a
translated-method-unknown value
3 - Not at this early stage but maybe in the next version of the draft
4 - I think this question is for the real-time implementation (if I
understand it correctly)

Thanks,

Nik.

On 6 July 2015 at 08:01, Gunnar Hellstr=C3=B6m 
wrote:

> Follow-up questions:
> 1. What will be the default? Just unspecified I assume.
>
> 2. Would there be a need for a value representing all translation types
> except original?  (=3Dtranslated but unknown how) I can imagine some use =
of
> that, but I think it is acceptable to ignore that need. The user with tha=
t
> need would need to just take one of the other values.
>
> 3. Is there a need to describe how the coding can be extended?
>
> 4. Will this be a media level parameter or a session level parameter or
> both? I assume it makes most sense on the media level, so that it can be
> described e.g. that the audio carries original speech, while the text
> carries automated captions.
>
> /Gunnar
>
>
> Paul Kyzivat skrev den 2015-07-06 00:04:
>
>> On 7/5/15 5:10 PM, Nik Tomkinson wrote:
>>
>>> Thanks again for the responses.
>>>
>>> I think that I will add the original suggestion of:
>>>
>>> translation-type :=3D type-token
>>> type-token :=3D "original" / "human" / "automated"
>>>
>>
>> This seems "ok" - more or less harmless and possibly helpful in some
>> cases.
>>
>> But I'm concerned that it will lead to an assumption that "human" is
>> *better* than "automated". That is probably true in most practical cases
>> today. But surely there are *some* automated translations that are bette=
r
>> than *some* human translations. And that will become the case more often=
 in
>> the future.
>>
>>     Thanks,
>>     Paul
>>
>>  into the next version of the non-real-time I-D and (as Randall suggests=
)
>>> if during some deployment trials we find that making the distinction
>>> between 'automated' and 'human' is not granular enough (or there are
>>> other changes required) we can update it further.
>>>
>>> I will start on this update now and have it ready to submit before the
>>> cut-off deadline tomorrow night (23:59 UTC Monday).
>>>
>>> Nik.
>>>
>>> On 5 July 2015 at 08:17, Eric Burger >> > wrote:
>>>
>>>     I=E2=80=99m agreeing here with Paul. /Maybe/ we could annotate some=
thing
>>>     that was machine translated. However, My justification is not to sa=
y
>>>     how good the translation is, but to let the user know they are NOT
>>>     seeing the original content.
>>>
>>>      On Jul 3, 2015, at 12:00 PM, Paul Kyzivat >>>     > wrote:
>>>>
>>>>     On 7/3/15 4:46 AM, Gunnar Hellstr=C3=B6m wrote:
>>>>
>>>>>     I see some value of this kind of parameter also for the real-time
>>>>>     case.
>>>>>     The time is here when it can be possible in some situations to
>>>>> select
>>>>>     between using a low-cost automatic speech-to-text generation and =
a
>>>>>     higher cost captioned telephony or text-relay service (higher
>>>>>     cost for
>>>>>     someone, not always the end-user).
>>>>>
>>>>>     But I agree that it is very hard to set good understandable
>>>>>     values on a
>>>>>     parameter expressing the type or quality of this kind of service.
>>>>>
>>>>
>>>>     Yes. It is my understanding (2nd hand) there there are subjective
>>>>     decisions (preferences) when choosing a translation service.
>>>>
>>>>     While I can see how having a rating attached might be conceptually
>>>>     appealing, it is hard to imagine how it would be deployed in a way
>>>>     that is useful. And it seems likely to be subject to endless
>>>> haggling.
>>>>
>>>>     Seems like a rat hole.
>>>>
>>>>     Thanks,
>>>>     Paul
>>>>
>>>>      Gunnar
>>>>>
>>>>>
>>>>>     Stephane Bortzmeyer skrev den 2015-07-03 08:49:
>>>>>
>>>>>>     On Thu, Jul 02, 2015 at 11:09:30PM +0100,
>>>>>>      Nik Tomkinson >>>>>     > wrote
>>>>>>      a message of 109 lines which said:
>>>>>>
>>>>>>      type-token :=3D "original" / "human" / "automated"
>>>>>>>
>>>>>>     In many IETF working groups, when there is such a proposal,
>>>>>>     there is a
>>>>>>     big discussion between the registryfull and the registryless
>>>>>>     people. The first ones say there must be an authoritative list o=
f
>>>>>>     values (in the RFC or, better because more evolving, in an IANA
>>>>>>     registry) so we can be sure of the interpretation of values. The
>>>>>>     second ones say we can never capture all the nuances and
>>>>>>     subtleties of
>>>>>>     the world in a fixed list.
>>>>>>
>>>>>>     Here, I am not sure that the only meaningful distinction is
>>>>>> between
>>>>>>     "human" and "automated". Some humans do a very poor job, too. On=
e
>>>>>>     could suggest:
>>>>>>
>>>>>>     type-token :=3D "original" / "professional-human" / "amateur-hum=
an"
>>>>>> /
>>>>>>     "automated-first-generation" /
>>>>>> "automated-artificial-intelligence" /
>>>>>>     "automated-the-robot-in-hollywood-movies"
>>>>>>
>>>>>>     Or decide that it will be too complicated and we should instead
>>>>>>     accept:
>>>>>>
>>>>>>      type-token :=3D "original" / 
>>>>>>>
>>>>>>     Toughts?
>>>>>>
>>>>>>     _______________________________________________
>>>>>>     SLIM mailing list
>>>>>>     SLIM@ietf.org 
>>>>>>     https://www.ietf.org/mailman/listinfo/slim
>>>>>>
>>>>>
>>>>>     _______________________________________________
>>>>>     SLIM mailing list
>>>>>     SLIM@ietf.org 
>>>>>     https://www.ietf.org/mailman/listinfo/slim
>>>>>
>>>>>
>>>>     _______________________________________________
>>>>     SLIM mailing list
>>>>     SLIM@ietf.org 
>>>>     https://www.ietf.org/mailman/listinfo/slim
>>>>
>>>
>>>
>>>     _______________________________________________
>>>     SLIM mailing list
>>>     SLIM@ietf.org 
>>>     https://www.ietf.org/mailman/listinfo/slim
>>>
>>>
>>>
>>>
>>> --
>>>
>>> -----------------------------------------------------------------
>>> Multiple Language Content Type Internet Draft:
>>>
>>> 
>>> http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/
>>>
>>> -----------------------------------------------------------------
>>>
>>>
>>>
>>> _______________________________________________
>>> SLIM mailing list
>>> SLIM@ietf.org
>>> https://www.ietf.org/mailman/listinfo/slim
>>>
>>>
>> _______________________________________________
>> SLIM mailing list
>> SLIM@ietf.org
>> https://www.ietf.org/mailman/listinfo/slim
>>
>
> --
> -----------------------------------------
> Gunnar Hellstr=C3=B6m
> Omnitor
> gunnar.hellstrom@omnitor.se
> +46 708 204 288
>
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim
>



--=20

-----------------------------------------------------------------
Multiple Language Content Type Internet Draft:


http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/

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

--001a11379d60ec04be051a331168
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


1 - Yes, and if the Translation-Type value is missing then=
 the recipient's email client will have to select the translation based=
 just on the preferred language only and ignore any user type preference.2 - I think for now the simplicity outweighs any use case for that. At t=
he moment, I can't think of any case where the recipient would make use=
 of a translated-method-unknown value
3 - Not at this early stage=
 but maybe in the next version of the draft
4 - I think this ques=
tion is for the real-time implementation (if I understand it correctly)=C2=
=A0

Thanks,

Nik.

On 6 July 2015=
 at 08:01, Gunnar Hellstr=C3=B6m <gunnar.hellstrom@omnitor.se> wrote:
Follow-up questions:<=
br>
1. What will be the default? Just unspecified I assume.



2. Would there be a need for a value representing all translation types exc=
ept original?=C2=A0 (=3Dtranslated but unknown how) I can imagine some use =
of that, but I think it is acceptable to ignore that need. The user with th=
at need would need to just take one of the other values.



3. Is there a need to describe how the coding can be extended?



4. Will this be a media level parameter or a session level parameter or bot=
h? I assume it makes most sense on the media level, so that it can be descr=
ibed e.g. that the audio carries original speech, while the text carries au=
tomated captions.



/Gunnar




Paul Kyzivat skrev den 2015-07-06 00:04:



On 7/5/15 5:10 PM, Nik Tomkinson wrote:



Thanks again for the responses.



I think that I will add the original suggestion of:



translation-type :=3D type-token

type-token :=3D "original" / "human" / "automated&=
quot;





This seems "ok" - more or less harmless and possibly helpful in s=
ome cases.



But I'm concerned that it will lead to an assumption that "human&q=
uot; is *better* than "automated". That is probably true in most =
practical cases today. But surely there are *some* automated translations t=
hat are better than *some* human translations. And that will become the cas=
e more often in the future.



=C2=A0 =C2=A0 Thanks,

=C2=A0 =C2=A0 Paul





into the next version of the non-real-time I-D and (as Randall suggests)
if during some deployment trials we find that making the distinction

between 'automated' and 'human' is not granular enough (or =
there are

other changes required) we can update it further.



I will start on this update now and have it ready to submit before the

cut-off deadline tomorrow night (23:59 UTC Monday).



Nik.



On 5 July 2015 at 08:17, Eric Burger <eburger@standardstrack.com

<mailto:=
eburger@standardstrack.com>> wrote:



=C2=A0 =C2=A0 I=E2=80=99m agreeing here with Paul. /Maybe/ we could annotat=
e something

=C2=A0 =C2=A0 that was machine translated. However, My justification is not=
 to say

=C2=A0 =C2=A0 how good the translation is, but to let the user know they ar=
e NOT

=C2=A0 =C2=A0 seeing the original content.





=C2=A0 =C2=A0 On Jul 3, 2015, at 12:00 PM, Paul Kyzivat <pkyzivat@alum.mit.edu

=C2=A0 =C2=A0 <mailto:pkyzivat@alum.mit.edu>> wrote:



=C2=A0 =C2=A0 On 7/3/15 4:46 AM, Gunnar Hellstr=C3=B6m wrote:



=C2=A0 =C2=A0 I see some value of this kind of parameter also for the real-=
time

=C2=A0 =C2=A0 case.

=C2=A0 =C2=A0 The time is here when it can be possible in some situations t=
o select

=C2=A0 =C2=A0 between using a low-cost automatic speech-to-text generation =
and a

=C2=A0 =C2=A0 higher cost captioned telephony or text-relay service (higher=


=C2=A0 =C2=A0 cost for

=C2=A0 =C2=A0 someone, not always the end-user).



=C2=A0 =C2=A0 But I agree that it is very hard to set good understandable
=C2=A0 =C2=A0 values on a

=C2=A0 =C2=A0 parameter expressing the type or quality of this kind of serv=
ice.





=C2=A0 =C2=A0 Yes. It is my understanding (2nd hand) there there are subjec=
tive

=C2=A0 =C2=A0 decisions (preferences) when choosing a translation service.<=
br>


=C2=A0 =C2=A0 While I can see how having a rating attached might be concept=
ually

=C2=A0 =C2=A0 appealing, it is hard to imagine how it would be deployed in =
a way

=C2=A0 =C2=A0 that is useful. And it seems likely to be subject to endless =
haggling.



=C2=A0 =C2=A0 Seems like a rat hole.



=C2=A0 =C2=A0 Thanks,

=C2=A0 =C2=A0 Paul





=C2=A0 =C2=A0 Gunnar





=C2=A0 =C2=A0 Stephane Bortzmeyer skrev den 2015-07-03 08:49:



=C2=A0 =C2=A0 On Thu, Jul 02, 2015 at 11:09:30PM +0100,

=C2=A0 =C2=A0 =C2=A0Nik Tomkinson <rfc.nik.tomkinson@gmail.com

=C2=A0 =C2=A0 <mailto:rfc.nik.tomkinson@gmail.com>> wrote

=C2=A0 =C2=A0 =C2=A0a message of 109 lines which said:





=C2=A0 =C2=A0 type-token :=3D "original" / "human" / &q=
uot;automated"



=C2=A0 =C2=A0 In many IETF working groups, when there is such a proposal,
=C2=A0 =C2=A0 there is a

=C2=A0 =C2=A0 big discussion between the registryfull and the registryless<=
br>
=C2=A0 =C2=A0 people. The first ones say there must be an authoritative lis=
t of

=C2=A0 =C2=A0 values (in the RFC or, better because more evolving, in an IA=
NA

=C2=A0 =C2=A0 registry) so we can be sure of the interpretation of values. =
The

=C2=A0 =C2=A0 second ones say we can never capture all the nuances and

=C2=A0 =C2=A0 subtleties of

=C2=A0 =C2=A0 the world in a fixed list.



=C2=A0 =C2=A0 Here, I am not sure that the only meaningful distinction is b=
etween

=C2=A0 =C2=A0 "human" and "automated". Some humans do a=
 very poor job, too. One

=C2=A0 =C2=A0 could suggest:



=C2=A0 =C2=A0 type-token :=3D "original" / "professional-hum=
an" / "amateur-human" /

=C2=A0 =C2=A0 "automated-first-generation" / "automated-arti=
ficial-intelligence" /

=C2=A0 =C2=A0 "automated-the-robot-in-hollywood-movies"



=C2=A0 =C2=A0 Or decide that it will be too complicated and we should inste=
ad

=C2=A0 =C2=A0 accept:





=C2=A0 =C2=A0 type-token :=3D "original" / <free text>



=C2=A0 =C2=A0 Toughts?



=C2=A0 =C2=A0 _______________________________________________

=C2=A0 =C2=A0 SLIM mailing list

=C2=A0 =C2=A0 SLIM@ietf.=
org <mailto:SLIM@=
ietf.org>

=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/slim





=C2=A0 =C2=A0 _______________________________________________

=C2=A0 =C2=A0 SLIM mailing list

=C2=A0 =C2=A0 SLIM@ietf.=
org <mailto:SLIM@=
ietf.org>

=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/slim







=C2=A0 =C2=A0 _______________________________________________

=C2=A0 =C2=A0 SLIM mailing list

=C2=A0 =C2=A0 SLIM@ietf.=
org <mailto:SLIM@=
ietf.org>

=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/slim







=C2=A0 =C2=A0 _______________________________________________

=C2=A0 =C2=A0 SLIM mailing list

=C2=A0 =C2=A0 SLIM@ietf.=
org <mailto:SLIM@=
ietf.org>

=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/slim









-- 



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

Multiple Language Content Type Internet Draft:



<http://datatracker.ietf.org/doc=
/draft-tomkinson-multilangcontent/>http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangc=
ontent/ 



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







_______________________________________________

SLIM mailing list

SLIM@ietf.org

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







_______________________________________________

SLIM mailing list

SLIM@ietf.org

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





-- 

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

Gunnar Hellstr=C3=B6m

Omnitor

gunnar.hel=
lstrom@omnitor.se

+46 708 204 288




_______________________________________________

SLIM mailing list

SLIM@ietf.org

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





-- 
=

=

---=
--------------------------------------------------------------
Multiple =
Language Content Type Internet Draft:
http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangconte=
nt/
---------=
--------------------------------------------------------




--001a11379d60ec04be051a331168--


From nobody Mon Jul  6 05:40:32 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8830E1ACECB for ; Mon,  6 Jul 2015 05:40:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 nBiVlTqfd8v5 for ; Mon,  6 Jul 2015 05:40:28 -0700 (PDT)
Received: from bin-vsp-out-05.atm.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 7499E1ACEBE for ; Mon,  6 Jul 2015 05:40:27 -0700 (PDT)
X-Halon-ID: 31d62081-23dc-11e5-8d69-005056916f53
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.43.70] (unknown [2.65.89.236]) by bin-vsp-out-05.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Mon,  6 Jul 2015 14:40:33 +0200 (CEST)
Message-ID: <559A7734.9060809@omnitor.se>
Date: Mon, 06 Jul 2015 14:40:20 +0200
From: =?windows-1252?Q?Gunnar_Hellstr=F6m?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: slim@ietf.org
References:  <20150703064908.GA14666@sources.org> <55964BED.1080905@omnitor.se> <5596B184.2020908@alum.mit.edu> <0A0D0CE1-01AC-411B-86B6-176A92C223A8@standardstrack.com>  <5599A9FE.60401@alum.mit.edu> <559A27CA.1060800@omnitor.se> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------010105050209090605040804"
Archived-At: 
Subject: Re: [Slim] Translation Quality or type
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Jul 2015 12:40:31 -0000

This is a multi-part message in MIME format.
--------------010105050209090605040804
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Nik Tomkinson skrev den 2015-07-06 13:18:
> 1 - Yes, and if the Translation-Type value is missing then the 
> recipient's email client will have to select the translation based 
> just on the preferred language only and ignore any user type preference.
Good.
> 2 - I think for now the simplicity outweighs any use case for that. At 
> the moment, I can't think of any case where the recipient would make 
> use of a translated-method-unknown value
Good
> 3 - Not at this early stage but maybe in the next version of the draft
A thought on extension possibilities is always good to have initially. 
If not briefly thought of initially, extensions are commonly causing 
interop problems when introduced later.
But here it might be a simple statement: "other values may be added in 
the future."  The usual rule that implementations finding another value 
should ignore it.

By the way, how about multiple values? A video containing both the 
original sign language user and interpreter translating to speech 
visible in the same video would need both specified.
> 4 - I think this question is for the real-time implementation (if I 
> understand it correctly)
The video example above with both signed original and spoken translation 
in the video medium would be valid for the stored case as well, carrying 
original and translated in the same medium. Will you have separate 
specifications per medium in the stored case, or one single session 
declaration? If just session declaration, there will be a need for 
multiple specifications of translation, with at least one per medium.

/Gunnar
>
> Thanks,
>
> Nik.
>
> On 6 July 2015 at 08:01, Gunnar Hellström  > wrote:
>
>     Follow-up questions:
>     1. What will be the default? Just unspecified I assume.
>
>     2. Would there be a need for a value representing all translation
>     types except original?  (=translated but unknown how) I can
>     imagine some use of that, but I think it is acceptable to ignore
>     that need. The user with that need would need to just take one of
>     the other values.
>
>     3. Is there a need to describe how the coding can be extended?
>
>     4. Will this be a media level parameter or a session level
>     parameter or both? I assume it makes most sense on the media
>     level, so that it can be described e.g. that the audio carries
>     original speech, while the text carries automated captions.
>
>     /Gunnar
>
>
>     Paul Kyzivat skrev den 2015-07-06 00:04:
>
>         On 7/5/15 5:10 PM, Nik Tomkinson wrote:
>
>             Thanks again for the responses.
>
>             I think that I will add the original suggestion of:
>
>             translation-type := type-token
>             type-token := "original" / "human" / "automated"
>
>
>         This seems "ok" - more or less harmless and possibly helpful
>         in some cases.
>
>         But I'm concerned that it will lead to an assumption that
>         "human" is *better* than "automated". That is probably true in
>         most practical cases today. But surely there are *some*
>         automated translations that are better than *some* human
>         translations. And that will become the case more often in the
>         future.
>
>             Thanks,
>             Paul
>
>             into the next version of the non-real-time I-D and (as
>             Randall suggests)
>             if during some deployment trials we find that making the
>             distinction
>             between 'automated' and 'human' is not granular enough (or
>             there are
>             other changes required) we can update it further.
>
>             I will start on this update now and have it ready to
>             submit before the
>             cut-off deadline tomorrow night (23:59 UTC Monday).
>
>             Nik.
>
>             On 5 July 2015 at 08:17, Eric Burger
>                          
>                          >> wrote:
>
>                 I’m agreeing here with Paul. /Maybe/ we could annotate
>             something
>                 that was machine translated. However, My justification
>             is not to say
>                 how good the translation is, but to let the user know
>             they are NOT
>                 seeing the original content.
>
>                     On Jul 3, 2015, at 12:00 PM, Paul Kyzivat
>                 
>                                      >> wrote:
>
>                     On 7/3/15 4:46 AM, Gunnar Hellström wrote:
>
>                         I see some value of this kind of parameter
>                     also for the real-time
>                         case.
>                         The time is here when it can be possible in
>                     some situations to select
>                         between using a low-cost automatic
>                     speech-to-text generation and a
>                         higher cost captioned telephony or text-relay
>                     service (higher
>                         cost for
>                         someone, not always the end-user).
>
>                         But I agree that it is very hard to set good
>                     understandable
>                         values on a
>                         parameter expressing the type or quality of
>                     this kind of service.
>
>
>                     Yes. It is my understanding (2nd hand) there there
>                 are subjective
>                     decisions (preferences) when choosing a
>                 translation service.
>
>                     While I can see how having a rating attached might
>                 be conceptually
>                     appealing, it is hard to imagine how it would be
>                 deployed in a way
>                     that is useful. And it seems likely to be subject
>                 to endless haggling.
>
>                     Seems like a rat hole.
>
>                     Thanks,
>                     Paul
>
>                         Gunnar
>
>
>                         Stephane Bortzmeyer skrev den 2015-07-03 08:49:
>
>                             On Thu, Jul 02, 2015 at 11:09:30PM +0100,
>                              Nik Tomkinson
>                                                  
>                                                      >> wrote
>                              a message of 109 lines which said:
>
>                                 type-token := "original" / "human" /
>                             "automated"
>
>                             In many IETF working groups, when there is
>                         such a proposal,
>                             there is a
>                             big discussion between the registryfull
>                         and the registryless
>                             people. The first ones say there must be
>                         an authoritative list of
>                             values (in the RFC or, better because more
>                         evolving, in an IANA
>                             registry) so we can be sure of the
>                         interpretation of values. The
>                             second ones say we can never capture all
>                         the nuances and
>                             subtleties of
>                             the world in a fixed list.
>
>                             Here, I am not sure that the only
>                         meaningful distinction is between
>                             "human" and "automated". Some humans do a
>                         very poor job, too. One
>                             could suggest:
>
>                             type-token := "original" /
>                         "professional-human" / "amateur-human" /
>                             "automated-first-generation" /
>                         "automated-artificial-intelligence" /
>                             "automated-the-robot-in-hollywood-movies"
>
>                             Or decide that it will be too complicated
>                         and we should instead
>                             accept:
>
>                                 type-token := "original" / 
>
>                             Toughts?
>
>                         _______________________________________________
>                             SLIM mailing list
>                         SLIM@ietf.org 
>                         >
>                         https://www.ietf.org/mailman/listinfo/slim
>
>
>                     _______________________________________________
>                         SLIM mailing list
>                     SLIM@ietf.org 
>                     >
>                     https://www.ietf.org/mailman/listinfo/slim
>
>
>                 _______________________________________________
>                     SLIM mailing list
>                 SLIM@ietf.org 
>                 >
>                 https://www.ietf.org/mailman/listinfo/slim
>
>
>
>                 _______________________________________________
>                 SLIM mailing list
>             SLIM@ietf.org               >
>             https://www.ietf.org/mailman/listinfo/slim
>
>
>
>
>             -- 
>
>             -----------------------------------------------------------------
>             Multiple Language Content Type Internet Draft:
>
>             http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/
>
>
>             -----------------------------------------------------------------
>
>
>
>             _______________________________________________
>             SLIM mailing list
>             SLIM@ietf.org 
>             https://www.ietf.org/mailman/listinfo/slim
>
>
>         _______________________________________________
>         SLIM mailing list
>         SLIM@ietf.org 
>         https://www.ietf.org/mailman/listinfo/slim
>
>
>     -- 
>     -----------------------------------------
>     Gunnar Hellström
>     Omnitor
>     gunnar.hellstrom@omnitor.se 
>     +46 708 204 288 
>
>
>     _______________________________________________
>     SLIM mailing list
>     SLIM@ietf.org 
>     https://www.ietf.org/mailman/listinfo/slim
>
>
>
>
> -- 
> -----------------------------------------------------------------
> Multiple Language Content Type Internet Draft:
> http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/
> -----------------------------------------------------------------
>
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim

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


--------------010105050209090605040804
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    Nik Tomkinson skrev den 2015-07-06 13:18:

    

      
1 - Yes, and if the Translation-Type value is
        missing then the recipient's email client will have to select
        the translation based just on the preferred language only and
        ignore any user type preference.

    

    Good.

    

      

        
2 - I think for now the simplicity outweighs any use case
          for that. At the moment, I can't think of any case where the
          recipient would make use of a translated-method-unknown value

      

    

    Good

    

      

        
3 - Not at this early stage but maybe in the next version
          of the draft

      

    

    A thought on extension possibilities is always good to have
    initially. If not briefly thought of initially, extensions are
    commonly causing interop problems when introduced later. 

    But here it might be a simple statement: "other values may be added
    in the future."  The usual rule that implementations finding another
    value should ignore it. 

    

    By the way, how about multiple values? A video containing both the
    original sign language user and interpreter translating to speech
    visible in the same video would need both specified. 

    

      

        
4 - I think this question is for the real-time
          implementation (if I understand it correctly) 

        

      

    

    The video example above with both signed original and spoken
    translation in the video medium would be valid for the stored case
    as well, carrying original and translated in the same medium. Will
    you have separate specifications per medium in the stored case, or
    one single session declaration? If just session declaration, there
    will be a need for multiple specifications of translation, with at
    least one per medium.

    

    /Gunnar

    

      

        


        

        
Thanks,

        


        

        
Nik.

      

      


        
On 6 July 2015 at 08:01, Gunnar
          Hellström <gunnar.hellstrom@omnitor.se>
          wrote:

          
Follow-up
            questions:

            1. What will be the default? Just unspecified I assume.

            

            2. Would there be a need for a value representing all
            translation types except original?  (=translated but unknown
            how) I can imagine some use of that, but I think it is
            acceptable to ignore that need. The user with that need
            would need to just take one of the other values.

            

            3. Is there a need to describe how the coding can be
            extended?

            

            4. Will this be a media level parameter or a session level
            parameter or both? I assume it makes most sense on the media
            level, so that it can be described e.g. that the audio
            carries original speech, while the text carries automated
            captions.

            

            /Gunnar
            

              


                

                Paul Kyzivat skrev den 2015-07-06 00:04:

                

                  On 7/5/15 5:10 PM, Nik Tomkinson wrote:

                  

                    Thanks again for the responses.

                    

                    I think that I will add the original suggestion of:

                    

                    translation-type := type-token

                    type-token := "original" / "human" / "automated"

                  

                  

                  This seems "ok" - more or less harmless and possibly
                  helpful in some cases.

                  

                  But I'm concerned that it will lead to an assumption
                  that "human" is *better* than "automated". That is
                  probably true in most practical cases today. But
                  surely there are *some* automated translations that
                  are better than *some* human translations. And that
                  will become the case more often in the future.

                  

                      Thanks,

                      Paul

                  

                  

                    into the next version of the non-real-time I-D and
                    (as Randall suggests)

                    if during some deployment trials we find that making
                    the distinction

                    between 'automated' and 'human' is not granular
                    enough (or there are

                    other changes required) we can update it further.

                    

                    I will start on this update now and have it ready to
                    submit before the

                    cut-off deadline tomorrow night (23:59 UTC Monday).

                    

                    Nik.

                    

                    On 5 July 2015 at 08:17, Eric Burger <eburger@standardstrack.com

                    <mailto:eburger@standardstrack.com>>
                    wrote:

                    

                        I’m agreeing here with Paul. /Maybe/ we could
                    annotate something

                        that was machine translated. However, My
                    justification is not to say

                        how good the translation is, but to let the user
                    know they are NOT

                        seeing the original content.

                    

                    

                          On Jul 3, 2015, at 12:00 PM, Paul Kyzivat <pkyzivat@alum.mit.edu

                          <mailto:pkyzivat@alum.mit.edu>>
                      wrote:

                      

                          On 7/3/15 4:46 AM, Gunnar Hellström wrote:

                      

                            I see some value of this kind of parameter
                        also for the real-time

                            case.

                            The time is here when it can be possible in
                        some situations to select

                            between using a low-cost automatic
                        speech-to-text generation and a

                            higher cost captioned telephony or
                        text-relay service (higher

                            cost for

                            someone, not always the end-user).

                        

                            But I agree that it is very hard to set good
                        understandable

                            values on a

                            parameter expressing the type or quality of
                        this kind of service.

                      

                      

                          Yes. It is my understanding (2nd hand) there
                      there are subjective

                          decisions (preferences) when choosing a
                      translation service.

                      

                          While I can see how having a rating attached
                      might be conceptually

                          appealing, it is hard to imagine how it would
                      be deployed in a way

                          that is useful. And it seems likely to be
                      subject to endless haggling.

                      

                          Seems like a rat hole.

                      

                          Thanks,

                          Paul

                      

                      

                            Gunnar

                        

                        

                            Stephane Bortzmeyer skrev den 2015-07-03
                        08:49:

                        

                              On Thu, Jul 02, 2015 at 11:09:30PM +0100,

                               Nik Tomkinson <rfc.nik.tomkinson@gmail.com

                              <mailto:rfc.nik.tomkinson@gmail.com>>
                          wrote

                               a message of 109 lines which said:

                          

                          

                                type-token := "original" / "human" /
                            "automated"

                          

                              In many IETF working groups, when there is
                          such a proposal,

                              there is a

                              big discussion between the registryfull
                          and the registryless

                              people. The first ones say there must be
                          an authoritative list of

                              values (in the RFC or, better because more
                          evolving, in an IANA

                              registry) so we can be sure of the
                          interpretation of values. The

                              second ones say we can never capture all
                          the nuances and

                              subtleties of

                              the world in a fixed list.

                          

                              Here, I am not sure that the only
                          meaningful distinction is between

                              "human" and "automated". Some humans do a
                          very poor job, too. One

                              could suggest:

                          

                              type-token := "original" /
                          "professional-human" / "amateur-human" /

                              "automated-first-generation" /
                          "automated-artificial-intelligence" /

                              "automated-the-robot-in-hollywood-movies"

                          

                              Or decide that it will be too complicated
                          and we should instead

                              accept:

                          

                          

                                type-token := "original" / <free
                            text>

                          

                              Toughts?

                          

                             
                          _______________________________________________

                              SLIM mailing list

                              SLIM@ietf.org
                          <mailto:SLIM@ietf.org>

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

                        

                        

                           
                        _______________________________________________

                            SLIM mailing list

                            SLIM@ietf.org
                        <mailto:SLIM@ietf.org>

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

                        

                      

                      

                         
                      _______________________________________________

                          SLIM mailing list

                          SLIM@ietf.org
                      <mailto:SLIM@ietf.org>

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

                    

                    

                    

                        _______________________________________________

                        SLIM mailing list

                        SLIM@ietf.org
                    <mailto:SLIM@ietf.org>

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

                    

                    

                    

                    

                    -- 

                    

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

                    Multiple Language Content Type Internet Draft:

                    

                    <http://datatracker.ietf.org/doc/draft-tomkinson-multilangcontent/>http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/
                    

                    

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

                    

                    

                    

                    _______________________________________________

                    SLIM mailing list

                    SLIM@ietf.org

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

                    

                  

                  

                  _______________________________________________

                  SLIM mailing list

                  SLIM@ietf.org

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

                

                

              

            

            
                -- 

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

                Gunnar Hellström

                Omnitor

                gunnar.hellstrom@omnitor.se

                +46 708 204 288
            

              


                

                _______________________________________________

                SLIM mailing list

                SLIM@ietf.org

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

              

            

          

        

        

        

        


        

        -- 

        

          

            

              

                

                  

                    
-----------------------------------------------------------------
Multiple Language Content Type Internet Draft:

                    http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/

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


                  

                

              

            

          

        

      

      

      

      

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


    

    

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

  


--------------010105050209090605040804--


From nobody Mon Jul  6 07:02:13 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E8E1A8792 for ; Mon,  6 Jul 2015 07:02:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 XrNA7qDI9k2O for ; Mon,  6 Jul 2015 07:02:08 -0700 (PDT)
Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ADC21A1B4B for ; Mon,  6 Jul 2015 07:02:07 -0700 (PDT)
Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-11v.sys.comcast.net with comcast id p2221q0032Ka2Q501226nu; Mon, 06 Jul 2015 14:02:06 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-11v.sys.comcast.net with comcast id p2251q00T3Ge9ey01226gj; Mon, 06 Jul 2015 14:02:06 +0000
Message-ID: <559A8A5C.1000409@alum.mit.edu>
Date: Mon, 06 Jul 2015 10:02:04 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: slim@ietf.org
References:  <20150703064908.GA14666@sources.org> <55964BED.1080905@omnitor.se>   <5598D34A.6070001@omnitor.se> <55995958.5050109@alum.mit.edu> <55999526.7030006@omnitor.se> <559A2D44.1010308@omnitor.se>
In-Reply-To: <559A2D44.1010308@omnitor.se>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1436191326; bh=fcsZihSo5pc20+kr02MTTBCArd46Mp7buoOWFOlhEow=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=RDp6pVG/rlvVBmjaRXRtt6yHIERgOSPzMKLaXnLCoiPTEN5fnkjGFXKTGBVWOHrpg 5a3VUcT7W9H3WGIGBdvfWba0J9I+NY33E0vgGtK0ABvftzqUCWrkg+QeAeRJwCD+/f gl0FScYP7O3wDOFVGyYFN20cdFuCtdkBa1mQghbkl01puKBbhONYk9/B44rghSMXxp +UZZPFhPseBOSoK3QRhE5OrFZPrcd9J3Mi7BgWLDPKp1/OZCWNLrQMnL2cyq4ciLzs UQzekRJSukrlLL4X7/bWrNfaEcIGjlpQ3mVYF69BFhPAHcSed09Xv4jTWhQ8liwi1t TMciqlpJSMfIA==
Archived-At: 
Subject: Re: [Slim] Translation Quality or type - or service provider
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Jul 2015 14:02:11 -0000

On 7/6/15 3:24 AM, Gunnar Hellström wrote:
> One reason for the need to convey a translation service provider URI is
> that the emergency service RFCs 6443 and 6881 forbids the calling user
> to invoke three-party calling.
>
> For example RFC 6443, chapter 13 says "Services such as call waiting,
> call transfer, three-way calling, and hold should be disabled."
>
> If then the user is in a foreign language environment where the PSAP
> barely can have a clue on how to find the right relay service, and the
> user has a good relay service URI configured, well capable of handling
> the user's language and modality, what is then best?
>
> 1) Break against RFC 6881 and 6443 and have the user terminal invoke the
> three-party call? The wording in these RFCs may be interpreted to have
> some room for such deviations.
> 2) Or convey the relay service URI to the PSAP for invocation.
>
> The discussion so far leads towards conclusion 1. It is ok for me, I
> just wanted it confirmed by showing the whole situation.
>
> (there will always be complementing slow manual procedures, when the
> PSAP needs to figure out a reasonable way to handle the call, but this
> discussion is for the rapid automated way that should handle most cases.)

(1) makes more sense to me than the alternatives.

OTOH, I can see the rationale for not *waiting* for the relay setup 
before putting the call through to the PSAP. So some signaling that 
indicates early that relay service is "on the way" might be helpful to 
allow the PSAP to make good decisions about whether to seek translation 
services on its own.

	Thanks,
	Paul

> /Gunnar
>
> Gunnar Hellström skrev den 2015-07-05 22:35:
>> Paul,
>> Yes, I agree that for most cases it is best that the party, who knows
>> a service that will do the translation, does the invocation.
>>
>> And, yes ,in that scenario the 3PCC method seems suitable.
>>
>> My proposal to send the service provider URI together with the
>> modality indications was for the case when there are strong policy
>> reasons why one party would do the invocation, but little chance that
>> that party would have access to an up-to-date information on available
>> translation providers.
>> That could be the case for the emergency service calling in a
>> multi-language environment, also including support for sign language
>> users.
>>
>> Since both you and Randall think it is not doable, we can try to use
>> the principle that the party, who knows a service that will do the
>> translation, does the invocation.
>>
>> That brings us back to a need for more stringent language/modality
>> negotiation in order to avoid both double invocation of services when
>> one or none is required, and also avoid no invocation when one is needed.
>>
>> Paul Kyzivat skrev den 2015-07-05 18:20:
>>> Gunnar,
>>>
>>> I understand what you are suggesting, but I don't believe it is
>>> workable. This seems to mean that the caller would select the service
>>> while the callee would engage the service in the call if needed. Yet
>>> it is likely to be the caller who has a business relationship with
>>> the service, while the callee does not. Gets complicated quickly.
>>>
>>> ISTM it makes more sense to first figure out what is/isn't possible
>>> without translation, and then for a party that finds a translation
>>> service beneficial to engage one. Then the only concern is that both
>>> parties don't independently try to introduce equivalent translation
>>> services.
>>>
>>> For instance, a deaf caller might offer video media marked for sign
>>> language, and audio media on hold. If the answer doesn't accept the
>>> video, or doesn't indicate support for sign language, the caller
>>> could then conference in translation service, using the 3pcc
>>> transcoding model specified in rfc5369. (If that will take time, the
>>> deaf caller's UA could stream recorded media over the audio channel
>>> in the meantime.)
>>>
>>> Or, to get fancier, it would be possible to use preconditions to
>>> defer alerting the callee until this is all sorted out.
>>>
>>> My point is to let the participant who wants translation handle to
>>> setup of translation rather than depending on the other party to do
>>> something.
>> OK, it might be likely that both parties "want" translation, but one
>> has better knowledge about how to get the required service and has
>> business relations with the service. So then it is preferred that that
>> party invokes.
>>
>> Good
>> /Gunnar
>>>
>>>     Thanks,
>>>     Paul
>>>
>>> On 7/5/15 2:48 AM, Gunnar Hellström wrote:
>>>> Another opportunity would be to convey a URI to the service provider
>>>> who
>>>> did (for mail) or can do(for real-time) the translation.
>>>> Then experience with different service provider's production could give
>>>> some idea of the expected quality.
>>>> I can see great value in that for the real-time case, when the calling
>>>> user has a favourite translator (e.g. relay service), and provides that
>>>> as a hint if languages or modalities in the call does not match. Then
>>>> the callee do not need to just take a service provider by chance that
>>>> seem to match the language/modality profile but can take the one
>>>> proposed by the caller.
>>>>
>>>> After working with the needs for emergency services to work across
>>>> Europe for some time now, I think this is one of the few workable
>>>> solutions. The user expresses both the language/modality needs and
>>>> provides a URI to a favourite translation service provider, and the
>>>> callee tries to fulfill the language/modality needs either by a
>>>> matching
>>>> original call taker or by invoking the proposed translation provider.
>>>>
>>>> /Gunnar
>>>>
>>>>
>>>> Randall Gellens skrev den 2015-07-05 03:49:
>>>>> My recollection is that this was discussed in email prior to Dallas,
>>>>> but that's not important.
>>>>>
>>>>> I am a strong proponent of keeping things as simple as possible,
>>>>> provided there is a way to extend them if experience shows that it is
>>>>> needed.  So, I think we should stick with the original suggestion of
>>>>> three values ("original", "human", "automated"). This is simple enough
>>>>> to be implementable and functional enough to be useful in providing a
>>>>> hint that may help the client choose the best version for the user. If
>>>>> we try and capture the various nuances of quality we will end up with
>>>>> a very complex mechanism that is unlikely to be any more useful in
>>>>> real life. Let's go with the simple approach now.  If, after some
>>>>> deployment experience we realize that we really do need extra
>>>>> complexity, we can extend the mechanism then.
>>>>>
>>>>> At 4:29 PM +0100 7/3/15, Nik Tomkinson wrote:
>>>>>
>>>>>>  Thanks for the responses.
>>>>>>
>>>>>>  To deal with the issue with having only original/human/automated,
>>>>>> what about the following?:
>>>>>>
>>>>>>
>>>>>>  translation-type := type-token[ ";" "q" "=" qvalue ]
>>>>>>  type-token :="human" / "automated"
>>>>>>
>>>>>>  where qvalue is a value between 0 and 1 with a default of 0.5 if
>>>>>> missing
>>>>>>
>>>>>>  for example:
>>>>>>
>>>>>>  Translation-Type: human;q=0.8
>>>>>>  Translation-Type: automated;q=0.4
>>>>>>  Translation-Type: human
>>>>>>
>>>>>>  The Translation-Type SHOULD NOT appear in the original
>>>>>> (untranslated) part but it SHOULD appear in translated content.
>>>>>>
>>>>>>  Having this missing from the original text helps identify which is
>>>>>> the source to be translated into further languages if the user mail
>>>>>> client allows.
>>>>>>
>>>>>>  This enables us to dispose of the 'original' value which didn't lend
>>>>>> itself well to being graded on quality.
>>>>>>
>>>>>>  The qvalue can be set by the sender or provided by the translation
>>>>>> service.
>>>>>>
>>>>>>  The draft suggests that:
>>>>>>
>>>>>>  "Additionally, interactive implementations MAY offer the user a
>>>>>> choice from among the available languages." so the qvalue may not
>>>>>> need to be bulletproof.
>>>>>>
>>>>>>  Comments?
>>>>>>
>>>>>>  Nik.
>>>>>>
>>>>>>  On 3 July 2015 at 09:46, Gunnar Hellström
>>>>>> <gunnar.hellstrom@omnitor.se>
>>>>>> wrote:
>>>>>>
>>>>>>  I see some value of this kind of parameter also for the real-time
>>>>>> case.
>>>>>>  The time is here when it can be possible in some situations to
>>>>>> select between using a low-cost automatic speech-to-text generation
>>>>>> and a higher cost captioned telephony or text-relay service (higher
>>>>>> cost for someone, not always the end-user).
>>>>>>
>>>>>>  But I agree that it is very hard to set good understandable values
>>>>>> on a parameter expressing the type or quality of this kind of
>>>>>> service.
>>>>>>
>>>>>>  Gunnar
>>>>>>
>>>>>>
>>>>>>
>>>>>>  Stephane Bortzmeyer skrev den 2015-07-03 08:49:
>>>>>>
>>>>>>  On Thu, Jul 02, 2015 at 11:09:30PM +0100,
>>>>>>    Nik Tomkinson
>>>>>> <rfc.nik.tomkinson@gmail.com>
>>>>>> wrote
>>>>>>    a message of 109 lines which said:
>>>>>>
>>>>>>  type-token := "original" / "human" / "automated"
>>>>>>
>>>>>>  In many IETF working groups, when there is such a proposal, there
>>>>>> is a
>>>>>>  big discussion between the registryfull and the registryless
>>>>>>  people. The first ones say there must be an authoritative list of
>>>>>>  values (in the RFC or, better because more evolving, in an IANA
>>>>>>  registry) so we can be sure of the interpretation of values. The
>>>>>>  second ones say we can never capture all the nuances and
>>>>>> subtleties of
>>>>>>  the world in a fixed list.
>>>>>>
>>>>>>  Here, I am not sure that the only meaningful distinction is between
>>>>>>  "human" and "automated". Some humans do a very poor job, too. One
>>>>>>  could suggest:
>>>>>>
>>>>>>  type-token := "original" / "professional-human" / "amateur-human" /
>>>>>>  "automated-first-generation" / "automated-artificial-intelligence" /
>>>>>>  "automated-the-robot-in-hollywood-movies"
>>>>>>
>>>>>>  Or decide that it will be too complicated and we should instead
>>>>>>  accept:
>>>>>>
>>>>>>  type-token := "original" / 
>>>>>>
>>>>>>  Toughts?
>>>>>>
>>>>>>  _______________________________________________
>>>>>>  SLIM mailing list
>>>>>>  SLIM@ietf.org
>>>>>>
>>>>>> https://www.ietf.org/mailman/listinfo/slim
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>  _______________________________________________
>>>>>>  SLIM mailing list
>>>>>>  SLIM@ietf.org
>>>>>>
>>>>>> https://www.ietf.org/mailman/listinfo/slim
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>  --
>>>>>>
>>>>>>  -----------------------------------------------------------------
>>>>>>  Multiple Language Content Type Internet Draft:
>>>>>>
>>>>>> http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/
>>>>>>
>>>>>>
>>>>>>  -----------------------------------------------------------------
>>>>>>
>>>>>>  _______________________________________________
>>>>>>  SLIM mailing list
>>>>>>  SLIM@ietf.org
>>>>>>  https://www.ietf.org/mailman/listinfo/slim
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> SLIM mailing list
>>> SLIM@ietf.org
>>> https://www.ietf.org/mailman/listinfo/slim
>>
>


From nobody Mon Jul  6 07:21:49 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C241A882C for ; Mon,  6 Jul 2015 07:21:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 biJyiww6bbxY for ; Mon,  6 Jul 2015 07:21:46 -0700 (PDT)
Received: from bin-vsp-out-02.atm.binero.net (vsp-authed02.binero.net [195.74.38.226]) (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 AF4B61A87C5 for ; Mon,  6 Jul 2015 07:21:45 -0700 (PDT)
X-Halon-ID: 518bda91-23ea-11e5-bc2e-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.43.70] (unknown [2.65.89.236]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Mon,  6 Jul 2015 16:21:39 +0200 (CEST)
Message-ID: <559A8EF4.3070805@omnitor.se>
Date: Mon, 06 Jul 2015 16:21:40 +0200
From: =?windows-1252?Q?Gunnar_Hellstr=F6m?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: slim@ietf.org
References:  <20150703064908.GA14666@sources.org> <55964BED.1080905@omnitor.se>   <5598D34A.6070001@omnitor.se> <55995958.5050109@alum.mit.edu> <55999526.7030006@omnitor.se> <559A2D44.1010308@omnitor.se> <559A8A5C.1000409@alum.mit.edu>
In-Reply-To: <559A8A5C.1000409@alum.mit.edu>
Content-Type: multipart/alternative; boundary="------------040403050709020900030100"
Archived-At: 
Subject: Re: [Slim] Translation Quality or type - or service provider
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Jul 2015 14:21:48 -0000

This is a multi-part message in MIME format.
--------------040403050709020900030100
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Paul Kyzivat skrev den 2015-07-06 16:02:
>
> (1) makes more sense to me than the alternatives.
>
> OTOH, I can see the rationale for not *waiting* for the relay setup 
> before putting the call through to the PSAP. So some signaling that 
> indicates early that relay service is "on the way" might be helpful to 
> allow the PSAP to make good decisions about whether to seek 
> translation services on its own.
Yes, that is what we have said in ETSI TS 101 470:
" The call establishment procedure shall enable call setup requests to 
go to both the emergency service and the relay service in parallel."

That can lead to some frustration if the emergency service answers 
first, but that frustration can be reduced by using real-time text 
between the PSAP and the user until full modality support is available 
by the relay.

But it will likely provide a better total result than connecting the 
services in series with relay first.

Thanks,
Gunnar

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


--------------040403050709020900030100
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    Paul Kyzivat skrev den 2015-07-06 16:02:

    


      (1) makes more sense to me than the alternatives.
      

      

      OTOH, I can see the rationale for not *waiting*
      for the relay setup before putting the call through to the PSAP.
      So some signaling that indicates early that relay service is "on
      the way" might be helpful to allow the PSAP to make good decisions
      about whether to seek translation services on its own.
      

    

    Yes, that is what we have said in ETSI TS 101 470:

    "
    
    The call
      establishment procedure shall enable call setup requests to go to
      both the
      emergency service and the relay service in parallel."

      

      That can lead to some frustration if the emergency service answers
      first, but that frustration can be reduced by using real-time text
      between the PSAP and the user until full modality support is
      available by the relay.

      

      But it will likely provide a better total result than connecting
      the services in series with relay first.

      

      Thanks,

      Gunnar 

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

  


--------------040403050709020900030100--


From nobody Mon Jul  6 07:26:18 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 190F41A21B9 for ; Mon,  6 Jul 2015 07:26:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.588
X-Spam-Level: 
X-Spam-Status: No, score=-3.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 XmSiMOg-Im_0 for ; Mon,  6 Jul 2015 07:26:11 -0700 (PDT)
Received: from buckwheat.cc.columbia.edu (buckwheat.cc.columbia.edu [128.59.72.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BB1B1A88C3 for ; Mon,  6 Jul 2015 07:25:57 -0700 (PDT)
Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by buckwheat.cc.columbia.edu (8.13.8/8.13.8) with ESMTP id t66EMw0K015150 for ; Mon, 6 Jul 2015 10:25:56 -0400
Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id 628EC83 for ; Mon,  6 Jul 2015 10:25:56 -0400 (EDT)
Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by hazelnut (Postfix) with ESMTP id 4C7C684 for ; Mon,  6 Jul 2015 10:25:56 -0400 (EDT)
Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id t66EPtCC022384 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 6 Jul 2015 10:25:56 -0400 (EDT)
Received: by iecvh10 with SMTP id vh10so114373178iec.3 for ; Mon, 06 Jul 2015 07:25:55 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CIrJ+Dt25Keg2mYIfKw4cti40qgxKUNghycISqCF7UQ=; b=mx4cbQYQhXXDRrkzLh3n1XMOTdbRGL5+iff/SgP2mbxnKJkGwYYJKnDz6JD8jlgcFV 6DVtsm+1v8+e+il3lXWJG2dbYOxb+t7Qi4uoM6ufndTCmAC4zJlW8E2ahl/wuo3L8MKY 9SYxGuP6gWshXG9Oh2dXdhzTrgBI/my6VUbbBBiXm8fSvWcWC0EFrHvGdYNK+sVBWyGZ oS7J1Ux91PsAJBenDThCTiLo3oxe5VrBQoNuJGnoda8Cr8pROBtewnbKyWQEDum539KN 5aX3v40m1LCmGcCzfOZQxi6YXBO9Ngrte0JnCMDMCCtQO7PT8EOHtVnw8Ay5O7m4OkWw S/qw==
X-Gm-Message-State: ALoCoQnZczg851yfqj7oSUiwXgo1JsX5O1kkfB0NVbBdMhqqnK6icXtR3pJbtIzrdIPOdjSH4ew9voO5gUZelJUbN096QcXxcV1gjSs7gUhpXf/yMvTFkC9rE0fgwNRWomaYW4stYdnd
X-Received: by 10.50.13.98 with SMTP id g2mr42347038igc.16.1436192755709; Mon, 06 Jul 2015 07:25:55 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.13.98 with SMTP id g2mr42347025igc.16.1436192755608; Mon, 06 Jul 2015 07:25:55 -0700 (PDT)
Received: by 10.36.121.131 with HTTP; Mon, 6 Jul 2015 07:25:55 -0700 (PDT)
In-Reply-To: <5599A9FE.60401@alum.mit.edu>
References:  <20150703064908.GA14666@sources.org> <55964BED.1080905@omnitor.se> <5596B184.2020908@alum.mit.edu> <0A0D0CE1-01AC-411B-86B6-176A92C223A8@standardstrack.com>  <5599A9FE.60401@alum.mit.edu>
Date: Mon, 6 Jul 2015 10:25:55 -0400
Message-ID: 
From: Henning Schulzrinne 
To: Paul Kyzivat 
Content-Type: multipart/alternative; boundary=089e0129464c070810051a35af8f
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7
Archived-At: 
Cc: slim@ietf.org
Subject: Re: [Slim] Translation Quality or type
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Jul 2015 14:26:13 -0000

--089e0129464c070810051a35af8f
Content-Type: text/plain; charset=UTF-8

Plus, increasingly, there are hybrids (automated followed by human editing
and maybe vice versa, such as a grammar checker), which are apparently
quite common for routine (business and technical, rather than literature)
translations.

On Sun, Jul 5, 2015 at 6:04 PM, Paul Kyzivat  wrote:

> On 7/5/15 5:10 PM, Nik Tomkinson wrote:
>
>> Thanks again for the responses.
>>
>> I think that I will add the original suggestion of:
>>
>> translation-type := type-token
>> type-token := "original" / "human" / "automated"
>>
>
> This seems "ok" - more or less harmless and possibly helpful in some cases.
>
> But I'm concerned that it will lead to an assumption that "human" is
> *better* than "automated". That is probably true in most practical cases
> today. But surely there are *some* automated translations that are better
> than *some* human translations. And that will become the case more often in
> the future.
>
>         Thanks,
>         Paul
>

--089e0129464c070810051a35af8f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Plus, increasingly, there are hybrids (automated followed =
by human editing and maybe vice versa, such as a grammar checker), which ar=
e apparently quite common for routine (business and technical, rather than =
literature) translations.

On Sun, Jul 5, 2015 at 6:04 PM, Paul Kyzivat <=
pkyzivat@alum.mi=
t.edu> wrote:
On 7/5/15 5:1=
0 PM, Nik Tomkinson wrote:



Thanks again for the responses.



I think that I will add the original suggestion of:



translation-type :=3D type-token

type-token :=3D "original" / "human" / "automated&=
quot;





This seems "ok" - more or less harmless and possibly helpful in s=
ome cases.



But I'm concerned that it will lead to an assumption that "human&q=
uot; is *better* than "automated". That is probably true in most =
practical cases today. But surely there are *some* automated translations t=
hat are better than *some* human translations. And that will become the cas=
e more often in the future.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul


--089e0129464c070810051a35af8f--


From nobody Mon Jul  6 07:54:03 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D311A891C for ; Mon,  6 Jul 2015 07:54:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 8Psg-bSytKbD for ; Mon,  6 Jul 2015 07:54:00 -0700 (PDT)
Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2227D1A891A for ; Mon,  6 Jul 2015 07:54:00 -0700 (PDT)
Received: by ykfs198 with SMTP id s198so45506576ykf.2 for ; Mon, 06 Jul 2015 07:53:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gNMt4j2PmqMmnReOdFNVnfwzOrJL4We5EEtFiWEOOLA=; b=vSdkjVA1bhmIie7pT3rt+7RTz/GpWgPlH9EAuMXEER81woe/6MFm9GOrlXdokSXZpK bPnVE/UUzkGEkHK3fUKS5J7p3WSpB9e1tYoe7BdzQPVE7cULHGQXOmj8vfqnLjN36VkA X0AnJRWwlaNsRZK0FjoHW2ixUoVM0Uq4xZZnSdOxfeABKEyl42udj4SwO6E97b7VJUNY 6Dm19ZVumNnYqpqKWym4voXilI2r0i/qxKVQ9hUfSx/VbsMLqmDsWTbam3ZyqkU7Luds J5CyZi+jPJ0qxXUJy/o6n9VPztKB+iLV083tYgO0jLQ2Hv0OQoyXiRW/hOSeqAcXa3Ot 6rEg==
MIME-Version: 1.0
X-Received: by 10.13.253.5 with SMTP id n5mr21498743ywf.24.1436194439538; Mon, 06 Jul 2015 07:53:59 -0700 (PDT)
Received: by 10.37.112.7 with HTTP; Mon, 6 Jul 2015 07:53:59 -0700 (PDT)
In-Reply-To: 
References:  <20150703064908.GA14666@sources.org> <55964BED.1080905@omnitor.se> <5596B184.2020908@alum.mit.edu> <0A0D0CE1-01AC-411B-86B6-176A92C223A8@standardstrack.com>  <5599A9FE.60401@alum.mit.edu> 
Date: Mon, 6 Jul 2015 15:53:59 +0100
Message-ID: 
From: Nik Tomkinson 
To: Henning Schulzrinne 
Content-Type: multipart/alternative; boundary=94eb2c06b83a65ad9f051a361365
Archived-At: 
Cc: slim@ietf.org, Paul Kyzivat 
Subject: Re: [Slim] Translation Quality or type
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Jul 2015 14:54:02 -0000

--94eb2c06b83a65ad9f051a361365
Content-Type: text/plain; charset=UTF-8

In the latest I-D I use the statement:

"A value of 'automated' is used when a language message part has been
translated by an electronic agent without proofreading or subsequent
correction."

I should have clarified this earlier. I have considered that any
translation/interpretation step where a human has taken a role is
considered 'human'.

Nik.

On 6 July 2015 at 15:25, Henning Schulzrinne  wrote:

> Plus, increasingly, there are hybrids (automated followed by human editing
> and maybe vice versa, such as a grammar checker), which are apparently
> quite common for routine (business and technical, rather than literature)
> translations.
>
> On Sun, Jul 5, 2015 at 6:04 PM, Paul Kyzivat 
> wrote:
>
>> On 7/5/15 5:10 PM, Nik Tomkinson wrote:
>>
>>> Thanks again for the responses.
>>>
>>> I think that I will add the original suggestion of:
>>>
>>> translation-type := type-token
>>> type-token := "original" / "human" / "automated"
>>>
>>
>> This seems "ok" - more or less harmless and possibly helpful in some
>> cases.
>>
>> But I'm concerned that it will lead to an assumption that "human" is
>> *better* than "automated". That is probably true in most practical cases
>> today. But surely there are *some* automated translations that are better
>> than *some* human translations. And that will become the case more often in
>> the future.
>>
>>         Thanks,
>>         Paul
>>
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim
>
>


-- 

-----------------------------------------------------------------
Multiple Language Content Type Internet Draft:


http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/

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

--94eb2c06b83a65ad9f051a361365
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


In the latest I-D I use the statement:

=

"A value of 'automated' is used when a language message p=
art has been translated by an electronic agent without proofreading or subs=
equent correction."

I should have clari=
fied this earlier. I have considered that any translation/interpretation st=
ep where a human has taken a role is considered 'human'.
=

Nik.

On 6 July 2015 at 15:25, Henning Schulzrinne <hgs@cs.colum=
bia.edu> wrote:
Plus, increasingly, there are hybrids (automated followed by human ed=
iting and maybe vice versa, such as a grammar checker), which are apparentl=
y quite common for routine (business and technical, rather than literature)=
 translations.

On Sun, Jul 5, 2015 at 6:04 PM, Paul Kyzivat <pkyzivat@a=
lum.mit.edu> wrote:
On 7/5/=
15 5:10 PM, Nik Tomkinson wrote:



Thanks again for the responses.



I think that I will add the original suggestion of:



translation-type :=3D type-token

type-token :=3D "original" / "human" / "automated&=
quot;





This seems "ok" - more or less harmless and possibly helpful in s=
ome cases.



But I'm concerned that it will lead to an assumption that "human&q=
uot; is *better* than "automated". That is probably true in most =
practical cases today. But surely there are *some* automated translations t=
hat are better than *some* human translations. And that will become the cas=
e more often in the future.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul


_______________________________________________

SLIM mailing list

SLIM@ietf.org

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





-- 
-----------=
------------------------------------------------------
Multiple Language=
 Content Type Internet Draft:
http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/=

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




--94eb2c06b83a65ad9f051a361365--


From nobody Mon Jul  6 08:32:13 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3481B2B76 for ; Mon,  6 Jul 2015 08:32:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level: 
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 oe0Xlfja_1-B for ; Mon,  6 Jul 2015 08:32:09 -0700 (PDT)
Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CB331B2BCD for ; Mon,  6 Jul 2015 08:30:24 -0700 (PDT)
Received: by ykdr198 with SMTP id r198so151217948ykd.3 for ; Mon, 06 Jul 2015 08:30:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=D7gTZI/tr/C6P8SpG+vtlr90/N73Dx7A7erIJje+OcM=; b=A9KyDz4pKPQyeKLx1t3pY0CW9ezSYZCVZ+y8OyCMwhcKhIsWLUl9sBEk3SUIN7Rq0R kt92u2e9NDR7weeymCHcf5c1UuFOZJAsN4Nm6dycINWHJkyQNBpPSuymeJP4AI1bsa8F mJ8fIuBmkved4zg98x5OOo03kEHU9rIi9ERjH/PNxZlRYUepOv8WKweivopFPpSNZtVe Mtz/lEw7FEAT9kO4XuB3AhdakvE+yQJA0E9sG4alaMuccN/ekFCk8axdZrrSIgJ8cayy RmxncoiAVHOTtJ+H8BlkHeO6ybV6oBbSTTa7W7z4uDdmaZusiba+yn89mqpqC+ggs8j6 5I3g==
MIME-Version: 1.0
X-Received: by 10.170.191.66 with SMTP id i63mr101307yke.40.1436196623864; Mon, 06 Jul 2015 08:30:23 -0700 (PDT)
Received: by 10.37.112.7 with HTTP; Mon, 6 Jul 2015 08:30:23 -0700 (PDT)
In-Reply-To: <559A7734.9060809@omnitor.se>
References:  <20150703064908.GA14666@sources.org> <55964BED.1080905@omnitor.se> <5596B184.2020908@alum.mit.edu> <0A0D0CE1-01AC-411B-86B6-176A92C223A8@standardstrack.com>  <5599A9FE.60401@alum.mit.edu> <559A27CA.1060800@omnitor.se>  <559A7734.9060809@omnitor.se>
Date: Mon, 6 Jul 2015 16:30:23 +0100
Message-ID: 
From: Nik Tomkinson 
To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= 
Content-Type: multipart/alternative; boundary=001a113923fa97fa13051a3695ec
Archived-At: 
Cc: slim@ietf.org
Subject: Re: [Slim] Translation Quality or type
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Jul 2015 15:32:12 -0000

--001a113923fa97fa13051a3695ec
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thanks for the comments:
3 - I will add 'other values may be added in the future' in today's draft
version - thanks.

I see, for the video example it would be human x 2 (original human signing
and human interpreting) but I can see there may be the case of some media
that has an automated translated/interpreted content alongside human text,
speech or signing. This is something that I will put on my list for further
thought and discussion for the next version of the draft but in order to
get a new version submitted before the cut-off time this evening, I will
stick to just one value.

Can you expand on your last question? I'm not sure what you mean by
'session' in a non-real-time single email scenario. The intention is to
have the Translation-Type specified once per 'language message part' (eg.
original, text translation or media translation).

Nik.

On 6 July 2015 at 13:40, Gunnar Hellstr=C3=B6m 
wrote:

>  Nik Tomkinson skrev den 2015-07-06 13:18:
>
> 1 - Yes, and if the Translation-Type value is missing then the recipient'=
s
> email client will have to select the translation based just on the
> preferred language only and ignore any user type preference.
>
> Good.
>
>  2 - I think for now the simplicity outweighs any use case for that. At
> the moment, I can't think of any case where the recipient would make use =
of
> a translated-method-unknown value
>
> Good
>
>  3 - Not at this early stage but maybe in the next version of the draft
>
> A thought on extension possibilities is always good to have initially. If
> not briefly thought of initially, extensions are commonly causing interop
> problems when introduced later.
> But here it might be a simple statement: "other values may be added in th=
e
> future."  The usual rule that implementations finding another value shoul=
d
> ignore it.
>
> By the way, how about multiple values? A video containing both the
> original sign language user and interpreter translating to speech visible
> in the same video would need both specified.
>
>  4 - I think this question is for the real-time implementation (if I
> understand it correctly)
>
> The video example above with both signed original and spoken translation
> in the video medium would be valid for the stored case as well, carrying
> original and translated in the same medium. Will you have separate
> specifications per medium in the stored case, or one single session
> declaration? If just session declaration, there will be a need for multip=
le
> specifications of translation, with at least one per medium.
>
> /Gunnar
>
>
>  Thanks,
>
>  Nik.
>
> On 6 July 2015 at 08:01, Gunnar Hellstr=C3=B6m 
> wrote:
>
>> Follow-up questions:
>> 1. What will be the default? Just unspecified I assume.
>>
>> 2. Would there be a need for a value representing all translation types
>> except original?  (=3Dtranslated but unknown how) I can imagine some use=
 of
>> that, but I think it is acceptable to ignore that need. The user with th=
at
>> need would need to just take one of the other values.
>>
>> 3. Is there a need to describe how the coding can be extended?
>>
>> 4. Will this be a media level parameter or a session level parameter or
>> both? I assume it makes most sense on the media level, so that it can be
>> described e.g. that the audio carries original speech, while the text
>> carries automated captions.
>>
>> /Gunnar
>>
>>
>> Paul Kyzivat skrev den 2015-07-06 00:04:
>>
>>> On 7/5/15 5:10 PM, Nik Tomkinson wrote:
>>>
>>>> Thanks again for the responses.
>>>>
>>>> I think that I will add the original suggestion of:
>>>>
>>>> translation-type :=3D type-token
>>>> type-token :=3D "original" / "human" / "automated"
>>>>
>>>
>>> This seems "ok" - more or less harmless and possibly helpful in some
>>> cases.
>>>
>>> But I'm concerned that it will lead to an assumption that "human" is
>>> *better* than "automated". That is probably true in most practical case=
s
>>> today. But surely there are *some* automated translations that are bett=
er
>>> than *some* human translations. And that will become the case more ofte=
n in
>>> the future.
>>>
>>>     Thanks,
>>>     Paul
>>>
>>>  into the next version of the non-real-time I-D and (as Randall suggest=
s)
>>>> if during some deployment trials we find that making the distinction
>>>> between 'automated' and 'human' is not granular enough (or there are
>>>> other changes required) we can update it further.
>>>>
>>>> I will start on this update now and have it ready to submit before the
>>>> cut-off deadline tomorrow night (23:59 UTC Monday).
>>>>
>>>> Nik.
>>>>
>>>> On 5 July 2015 at 08:17, Eric Burger >>> > wrote:
>>>>
>>>>     I=E2=80=99m agreeing here with Paul. /Maybe/ we could annotate som=
ething
>>>>     that was machine translated. However, My justification is not to s=
ay
>>>>     how good the translation is, but to let the user know they are NOT
>>>>     seeing the original content.
>>>>
>>>>      On Jul 3, 2015, at 12:00 PM, Paul Kyzivat >>>>     > wrote:
>>>>>
>>>>>     On 7/3/15 4:46 AM, Gunnar Hellstr=C3=B6m wrote:
>>>>>
>>>>>>     I see some value of this kind of parameter also for the real-tim=
e
>>>>>>     case.
>>>>>>     The time is here when it can be possible in some situations to
>>>>>> select
>>>>>>     between using a low-cost automatic speech-to-text generation and=
 a
>>>>>>     higher cost captioned telephony or text-relay service (higher
>>>>>>     cost for
>>>>>>     someone, not always the end-user).
>>>>>>
>>>>>>     But I agree that it is very hard to set good understandable
>>>>>>     values on a
>>>>>>     parameter expressing the type or quality of this kind of service=
.
>>>>>>
>>>>>
>>>>>     Yes. It is my understanding (2nd hand) there there are subjective
>>>>>     decisions (preferences) when choosing a translation service.
>>>>>
>>>>>     While I can see how having a rating attached might be conceptuall=
y
>>>>>     appealing, it is hard to imagine how it would be deployed in a wa=
y
>>>>>     that is useful. And it seems likely to be subject to endless
>>>>> haggling.
>>>>>
>>>>>     Seems like a rat hole.
>>>>>
>>>>>     Thanks,
>>>>>     Paul
>>>>>
>>>>>      Gunnar
>>>>>>
>>>>>>
>>>>>>     Stephane Bortzmeyer skrev den 2015-07-03 08:49:
>>>>>>
>>>>>>>     On Thu, Jul 02, 2015 at 11:09:30PM +0100,
>>>>>>>      Nik Tomkinson >>>>>>     > wrote
>>>>>>>      a message of 109 lines which said:
>>>>>>>
>>>>>>>      type-token :=3D "original" / "human" / "automated"
>>>>>>>>
>>>>>>>     In many IETF working groups, when there is such a proposal,
>>>>>>>     there is a
>>>>>>>     big discussion between the registryfull and the registryless
>>>>>>>     people. The first ones say there must be an authoritative list =
of
>>>>>>>     values (in the RFC or, better because more evolving, in an IANA
>>>>>>>     registry) so we can be sure of the interpretation of values. Th=
e
>>>>>>>     second ones say we can never capture all the nuances and
>>>>>>>     subtleties of
>>>>>>>     the world in a fixed list.
>>>>>>>
>>>>>>>     Here, I am not sure that the only meaningful distinction is
>>>>>>> between
>>>>>>>     "human" and "automated". Some humans do a very poor job, too. O=
ne
>>>>>>>     could suggest:
>>>>>>>
>>>>>>>     type-token :=3D "original" / "professional-human" /
>>>>>>> "amateur-human" /
>>>>>>>     "automated-first-generation" /
>>>>>>> "automated-artificial-intelligence" /
>>>>>>>     "automated-the-robot-in-hollywood-movies"
>>>>>>>
>>>>>>>     Or decide that it will be too complicated and we should instead
>>>>>>>     accept:
>>>>>>>
>>>>>>>      type-token :=3D "original" / 
>>>>>>>>
>>>>>>>     Toughts?
>>>>>>>
>>>>>>>     _______________________________________________
>>>>>>>     SLIM mailing list
>>>>>>>     SLIM@ietf.org 
>>>>>>>     https://www.ietf.org/mailman/listinfo/slim
>>>>>>>
>>>>>>
>>>>>>     _______________________________________________
>>>>>>     SLIM mailing list
>>>>>>     SLIM@ietf.org 
>>>>>>     https://www.ietf.org/mailman/listinfo/slim
>>>>>>
>>>>>>
>>>>>     _______________________________________________
>>>>>     SLIM mailing list
>>>>>     SLIM@ietf.org 
>>>>>     https://www.ietf.org/mailman/listinfo/slim
>>>>>
>>>>
>>>>
>>>>     _______________________________________________
>>>>     SLIM mailing list
>>>>     SLIM@ietf.org 
>>>>     https://www.ietf.org/mailman/listinfo/slim
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> -----------------------------------------------------------------
>>>> Multiple Language Content Type Internet Draft:
>>>>
>>>> 
>>>> http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/
>>>>
>>>> -----------------------------------------------------------------
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> SLIM mailing list
>>>> SLIM@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/slim
>>>>
>>>>
>>> _______________________________________________
>>> SLIM mailing list
>>> SLIM@ietf.org
>>> https://www.ietf.org/mailman/listinfo/slim
>>>
>>
>>   --
>> -----------------------------------------
>> Gunnar Hellstr=C3=B6m
>> Omnitor
>> gunnar.hellstrom@omnitor.se
>> +46 708 204 288
>>
>>
>> _______________________________________________
>> SLIM mailing list
>> SLIM@ietf.org
>> https://www.ietf.org/mailman/listinfo/slim
>>
>
>
>
>  --
>
> -----------------------------------------------------------------
> Multiple Language Content Type Internet Draft:
>
>  
> http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/
>
> -----------------------------------------------------------------
>
>
>
> _______________________________________________
> SLIM mailing listSLIM@ietf.orghttps://www.ietf.org/mailman/listinfo/slim
>
>
> --
> -----------------------------------------
> Gunnar Hellstr=C3=B6m
> Omnitorgunnar.hellstrom@omnitor.se
> +46 708 204 288
>
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim
>
>


--=20

-----------------------------------------------------------------
Multiple Language Content Type Internet Draft:


http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/

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

--001a113923fa97fa13051a3695ec
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Thanks for the comments:
3 - I will add 'other values may be added in the future=
' in today's draft version - thanks.

I see, for the video example it would be human x 2 (original human signin=
g and human interpreting) but I can see there may be the case of some media=
 that has an automated translated/interpreted content alongside human text,=
 speech or signing. This is something that I will put on my list for furthe=
r thought and discussion for the next version of the draft but in order to =
get a new version submitted before the cut-off time this evening, I will st=
ick to just one value.

Can you expand on your last=
 question? I'm not sure what you mean by 'session' in a non-rea=
l-time single email scenario. The intention is to have the Translation-Type=
 specified once per 'language message part' (eg. original, text tra=
nslation or media translation).

Nik.

On 6 July 2015 at 1=
3:40, Gunnar Hellstr=C3=B6m <gunnar.hellstrom@omnitor.se>=
 wrote:

 =20
   =20
 =20
  

    Nik Tomkinson skrev den 2015-07-06 13:18:

    

      
1 - Yes, and if the Translation-Type value is
        missing then the recipient's email client will have to select
        the translation based just on the preferred language only and
        ignore any user type preference.

    

    Good.

    

      

        
2 - I think for now the simplicity outweighs any use case
          for that. At the moment, I can't think of any case where the
          recipient would make use of a translated-method-unknown value
      

    

    Good

    

      

        
3 - Not at this early stage but maybe in the next version
          of the draft

      

    

    A thought on extension possibilities is always good to have
    initially. If not briefly thought of initially, extensions are
    commonly causing interop problems when introduced later. 

    But here it might be a simple statement: "other values may be adde=
d
    in the future."=C2=A0 The usual rule that implementations finding =
another
    value should ignore it. 

    

    By the way, how about multiple values? A video containing both the
    original sign language user and interpreter translating to speech
    visible in the same video would need both specified. 

    

      

        
4 - I think this question is for the real-time
          implementation (if I understand it correctly) 

        

      

    

    The video example above with both signed original and spoken
    translation in the video medium would be valid for the stored case
    as well, carrying original and translated in the same medium. Will
    you have separate specifications per medium in the stored case, or
    one single session declaration? If just session declaration, there
    will be a need for multiple specifications of translation, with at
    least one per medium.
    

    /Gunnar


    

      

        


        

        
Thanks,

        


        

        
Nik.

      

      


        
On 6 July 2015 at 08:01, Gunnar
          Hellstr=C3=B6m <gunnar.hellstrom@omnitor.se>
          wrote:

          
Follow-up
            questions:

            1. What will be the default? Just unspecified I assume.

            

            2. Would there be a need for a value representing all
            translation types except original?=C2=A0 (=3Dtranslated but unk=
nown
            how) I can imagine some use of that, but I think it is
            acceptable to ignore that need. The user with that need
            would need to just take one of the other values.

            

            3. Is there a need to describe how the coding can be
            extended?

            

            4. Will this be a media level parameter or a session level
            parameter or both? I assume it makes most sense on the media
            level, so that it can be described e.g. that the audio
            carries original speech, while the text carries automated
            captions.

            

            /Gunnar
            

              


                

                Paul Kyzivat skrev den 2015-07-06 00:04:

                

                  On 7/5/15 5:10 PM, Nik Tomkinson wrote:

                  

                    Thanks again for the responses.

                    

                    I think that I will add the original suggestion of:

                    

                    translation-type :=3D type-token

                    type-token :=3D "original" / "human"=
; / "automated"

                  

                  

                  This seems "ok" - more or less harmless and pos=
sibly
                  helpful in some cases.

                  

                  But I'm concerned that it will lead to an assumption
                  that "human" is *better* than "automated&q=
uot;. That is
                  probably true in most practical cases today. But
                  surely there are *some* automated translations that
                  are better than *some* human translations. And that
                  will become the case more often in the future.

                  

                  =C2=A0 =C2=A0 Thanks,

                  =C2=A0 =C2=A0 Paul

                  

                  

                    into the next version of the non-real-time I-D and
                    (as Randall suggests)

                    if during some deployment trials we find that making
                    the distinction

                    between 'automated' and 'human' is not =
granular
                    enough (or there are

                    other changes required) we can update it further.

                    

                    I will start on this update now and have it ready to
                    submit before the

                    cut-off deadline tomorrow night (23:59 UTC Monday).

                    

                    Nik.

                    

                    On 5 July 2015 at 08:17, Eric Burger <eburger@standardstrack.co=
m

                    <mailto:eburger@standardstrack.com>>
                    wrote:

                    

                    =C2=A0 =C2=A0 I=E2=80=99m agreeing here with Paul. /May=
be/ we could
                    annotate something

                    =C2=A0 =C2=A0 that was machine translated. However, My
                    justification is not to say

                    =C2=A0 =C2=A0 how good the translation is, but to let t=
he user
                    know they are NOT

                    =C2=A0 =C2=A0 seeing the original content.

                    

                    

                      =C2=A0 =C2=A0 On Jul 3, 2015, at 12:00 PM, Paul Kyziv=
at <pkyzivat@=
alum.mit.edu

                      =C2=A0 =C2=A0 <mailto:pkyzivat@alum.mit.edu>>
                      wrote:

                      

                      =C2=A0 =C2=A0 On 7/3/15 4:46 AM, Gunnar Hellstr=C3=B6=
m wrote:

                      

                        =C2=A0 =C2=A0 I see some value of this kind of para=
meter
                        also for the real-time

                        =C2=A0 =C2=A0 case.

                        =C2=A0 =C2=A0 The time is here when it can be possi=
ble in
                        some situations to select

                        =C2=A0 =C2=A0 between using a low-cost automatic
                        speech-to-text generation and a

                        =C2=A0 =C2=A0 higher cost captioned telephony or
                        text-relay service (higher

                        =C2=A0 =C2=A0 cost for

                        =C2=A0 =C2=A0 someone, not always the end-user).
                        

                        =C2=A0 =C2=A0 But I agree that it is very hard to s=
et good
                        understandable

                        =C2=A0 =C2=A0 values on a

                        =C2=A0 =C2=A0 parameter expressing the type or qual=
ity of
                        this kind of service.

                      

                      

                      =C2=A0 =C2=A0 Yes. It is my understanding (2nd hand) =
there
                      there are subjective

                      =C2=A0 =C2=A0 decisions (preferences) when choosing a
                      translation service.

                      

                      =C2=A0 =C2=A0 While I can see how having a rating att=
ached
                      might be conceptually

                      =C2=A0 =C2=A0 appealing, it is hard to imagine how it=
 would
                      be deployed in a way

                      =C2=A0 =C2=A0 that is useful. And it seems likely to =
be
                      subject to endless haggling.

                      

                      =C2=A0 =C2=A0 Seems like a rat hole.

                      

                      =C2=A0 =C2=A0 Thanks,

                      =C2=A0 =C2=A0 Paul

                      

                      

                        =C2=A0 =C2=A0 Gunnar

                        

                        

                        =C2=A0 =C2=A0 Stephane Bortzmeyer skrev den 2015-07=
-03
                        08:49:

                        

                          =C2=A0 =C2=A0 On Thu, Jul 02, 2015 at 11:09:30PM =
+0100,

                          =C2=A0 =C2=A0 =C2=A0Nik Tomkinson <rfc.nik.tomkinson@gma=
il.com

                          =C2=A0 =C2=A0 <mailto:rfc.nik.tomkinson@gmail.com>=
;>
                          wrote

                          =C2=A0 =C2=A0 =C2=A0a message of 109 lines which =
said:

                          

                          

                            =C2=A0 =C2=A0 type-token :=3D "original&qu=
ot; / "human" /
                            "automated"

                          

                          =C2=A0 =C2=A0 In many IETF working groups, when t=
here is
                          such a proposal,

                          =C2=A0 =C2=A0 there is a

                          =C2=A0 =C2=A0 big discussion between the registry=
full
                          and the registryless

                          =C2=A0 =C2=A0 people. The first ones say there mu=
st be
                          an authoritative list of

                          =C2=A0 =C2=A0 values (in the RFC or, better becau=
se more
                          evolving, in an IANA

                          =C2=A0 =C2=A0 registry) so we can be sure of the
                          interpretation of values. The

                          =C2=A0 =C2=A0 second ones say we can never captur=
e all
                          the nuances and

                          =C2=A0 =C2=A0 subtleties of

                          =C2=A0 =C2=A0 the world in a fixed list.

                          

                          =C2=A0 =C2=A0 Here, I am not sure that the only
                          meaningful distinction is between

                          =C2=A0 =C2=A0 "human" and "automat=
ed". Some humans do a
                          very poor job, too. One

                          =C2=A0 =C2=A0 could suggest:

                          

                          =C2=A0 =C2=A0 type-token :=3D "original"=
; /
                          "professional-human" / "amateur-hu=
man" /

                          =C2=A0 =C2=A0 "automated-first-generation&qu=
ot; /
                          "automated-artificial-intelligence" /
                          =C2=A0 =C2=A0 "automated-the-robot-in-hollyw=
ood-movies"

                          

                          =C2=A0 =C2=A0 Or decide that it will be too compl=
icated
                          and we should instead

                          =C2=A0 =C2=A0 accept:

                          

                          

                            =C2=A0 =C2=A0 type-token :=3D "original&qu=
ot; / <free
                            text>

                          

                          =C2=A0 =C2=A0 Toughts?

                          

                          =C2=A0 =C2=A0
                          _______________________________________________
                          =C2=A0 =C2=A0 SLIM mailing list

                          =C2=A0 =C2=A0 SLIM@ietf.org
                          <mailto:SLIM@ietf.org>

                          =C2=A0 =C2=A0 https://www.ietf.o=
rg/mailman/listinfo/slim

                        

                        

                        =C2=A0 =C2=A0
                        _______________________________________________

                        =C2=A0 =C2=A0 SLIM mailing list

                        =C2=A0 =C2=A0 SLIM@ietf.org
                        <mailto:SLIM@ietf.org>

                        =C2=A0 =C2=A0 https://www.ietf.org=
/mailman/listinfo/slim

                        

                      

                      

                      =C2=A0 =C2=A0
                      _______________________________________________

                      =C2=A0 =C2=A0 SLIM mailing list

                      =C2=A0 =C2=A0 SLIM@ietf.org
                      <mailto:SLIM@ietf.org>

                      =C2=A0 =C2=A0 https://www.ietf.org/m=
ailman/listinfo/slim

                    

                    

                    

                    =C2=A0 =C2=A0 _________________________________________=
______

                    =C2=A0 =C2=A0 SLIM mailing list

                    =C2=A0 =C2=A0 SLIM@ietf.org
                    <mailto:SLIM@ietf.org>

                    =C2=A0 =C2=A0 https://www.ietf.org/mai=
lman/listinfo/slim

                    

                    

                    

                    

                    -- 

                    

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

                    Multiple Language Content Type Internet Draft:

                    

                    <http://data=
tracker.ietf.org/doc/draft-tomkinson-multilangcontent/>http://datatracker.ietf.org/doc/draft-tom=
kinson-slim-multilangcontent/
                    

                    

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

                    

                    

                    

                    _______________________________________________

                    SLIM mailing list

                    SLIM=
@ietf.org

                    https://www.ietf.org/mailman/listinfo/=
slim

                    

                  

                  

                  _______________________________________________

                  SLIM mailing list

                  SLIM@i=
etf.org

                  https://www.ietf.org/mailman/listinfo/sl=
im

                

                

              

            

            
                -- 

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

                Gunnar Hellstr=C3=B6m

                Omnitor

                gunnar.hellstrom@omnitor.se

                +46 708 204 288
            

              


                

                _______________________________________________

                SLIM mailing list

                SLIM@iet=
f.org

                https://www.ietf.org/mailman/listinfo/sli=
m

              

            

          

        

        

        

        


        

        -- 

        

          

            

              

                

                  

                    
=
-----------------------------------------------------------------
Multiple Language Content Type Internet Draft:

                    http://datatracker.iet=
f.org/doc/draft-tomkinson-slim-multilangcontent/

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


                  

                

              

            

          

        

      

      

      

      

      
_______________________________________________
SLIM mailing list
SLIM@ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/slim


    

    

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

  



_______________________________________________

SLIM mailing list

SLIM@ietf.org

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





-- 
-----------=
------------------------------------------------------
Multiple Language=
 Content Type Internet Draft:
http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/=

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




--001a113923fa97fa13051a3695ec--


From nobody Mon Jul  6 08:42:03 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E0A1B2D16 for ; Mon,  6 Jul 2015 08:42:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level: 
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 fvL1l7ZiGfZF for ; Mon,  6 Jul 2015 08:42:01 -0700 (PDT)
Received: from bin-vsp-out-02.atm.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 819791B2D14 for ; Mon,  6 Jul 2015 08:42:00 -0700 (PDT)
X-Halon-ID: 878661b2-23f5-11e5-bc2e-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.43.70] (unknown [2.65.89.236]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Mon,  6 Jul 2015 17:41:54 +0200 (CEST)
Message-ID: <559AA1C3.6070906@omnitor.se>
Date: Mon, 06 Jul 2015 17:41:55 +0200
From: =?UTF-8?B?R3VubmFyIEhlbGxzdHLDtm0=?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Nik Tomkinson 
References: 	<20150703064908.GA14666@sources.org>	<55964BED.1080905@omnitor.se>	<5596B184.2020908@alum.mit.edu>	<0A0D0CE1-01AC-411B-86B6-176A92C223A8@standardstrack.com>		<5599A9FE.60401@alum.mit.edu>	<559A27CA.1060800@omnitor.se>		<559A7734.9060809@omnitor.se> 
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: slim@ietf.org
Subject: Re: [Slim] Translation Quality or type
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Jul 2015 15:42:02 -0000

Nik Tomkinson skrev den 2015-07-06 17:30:
>
> Can you expand on your last question? I'm not sure what you mean by 
> 'session' in a non-real-time single email scenario. The intention is 
> to have the Translation-Type specified once per 'language message 
> part' (eg. original, text translation or media translation).
Well, say media description or what term you use for the declaration.

A simple example would be a video file with audio track and timed text, 
with the video containing an original sign language presentation, 
interpreted to speech by a human interpreter in the audio track, and the 
interpreter talking into a speech-to-text generator, creating the 
automated timed-text track.

What would the translation declaration(s) look like for this creation so 
that all interested parties can judge if they get what they want?

Thanks

Gunnar



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


From nobody Mon Jul  6 10:11:05 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 827451ACCFF for ; Mon,  6 Jul 2015 10:11:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 ltwcPqNIEjyU for ; Mon,  6 Jul 2015 10:11:02 -0700 (PDT)
Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (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 AFC381A8A7A for ; Mon,  6 Jul 2015 10:11:02 -0700 (PDT)
Received: by ykfs198 with SMTP id s198so49502375ykf.2 for ; Mon, 06 Jul 2015 10:11:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to:content-type; bh=Uayh8+o/SXhGHBeo8itclhkIL2yNZVV/g/adKSuUij4=; b=XfSJY9X8ZRg/XTUOS4bo4n1fSXupb8tSDKCNQJxVUPeOT7bofEtvGQEj9/uvL8Sxn9 6RoY8SG/sml9rHI+mSq9MaEoTCa38T2p1Q8vMrSIuG9IC5jM1UbpDOQoQrDxEDRk6VfJ jAtKShD2Ec/LJPtC3+WAUeCJhT6AydCd76Q2ne/0YK+0UOP8SpoVLF86RkujdLkbw7Hs s4BfwOuh4uRDNJKfwAkHNq9pEv2gnVD77Nep8o4eYLridi8D3YONj/ffb2SpSzuITvSE w7d7PM08l3cf31JqDobqXk2sEtdaCT9LRBlRrCrQze85LWhTGP4lDz2cFFnjC79TNwoh N5vg==
MIME-Version: 1.0
X-Received: by 10.13.199.195 with SMTP id j186mr59095003ywd.112.1436202662075;  Mon, 06 Jul 2015 10:11:02 -0700 (PDT)
Received: by 10.37.112.7 with HTTP; Mon, 6 Jul 2015 10:11:02 -0700 (PDT)
Date: Mon, 6 Jul 2015 18:11:02 +0100
Message-ID: 
From: Nik Tomkinson 
To: slim@ietf.org
Content-Type: multipart/alternative; boundary=001a114e61ae7fa2ed051a37fdc6
Archived-At: 
Subject: [Slim] New I-D version draft-tomkinson-slim-multilangcontent-01
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Jul 2015 17:11:04 -0000

--001a114e61ae7fa2ed051a37fdc6
Content-Type: text/plain; charset=UTF-8

FYI

A new version of I-D, draft-tomkinson-slim-multilangcontent-01.txt
has been successfully submitted by Nik Tomkinson and posted to the
IETF repository.

Name:           draft-tomkinson-slim-multilangcontent
Revision:       01
Title:          Multiple Language Content Type
Document date:  2015-07-06
Group:          Individual Submission
Pages:          11
URL:
https://www.ietf.org/internet-drafts/draft-tomkinson-slim-multilangcontent-01.txt
Status:
https://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/
Htmlized:
https://tools.ietf.org/html/draft-tomkinson-slim-multilangcontent-01
Diff:
https://www.ietf.org/rfcdiff?url2=draft-tomkinson-slim-multilangcontent-01

Abstract:
   This document defines an addition to the Multipurpose Internet Mail
   Extensions (MIME) standard to make it possible to send one message
   that contains multiple language versions of the same information.
   The translations would be identified by a language code and selected
   by the email client based on a user's language settings or locale.

--001a114e61ae7fa2ed051a37fdc6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


FYI
A new version of I-D, draft-tomkinson-slim-multilangcontent-01.txt
has been successfully submitted by Nik Tomkinson and posted to the
IETF repository.
<=
br style=3D"font-family:arial,sans-serif;font-size:12.8000001907349px;white=
-space:normal">Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0draft-tomkinson-slim-multilangcontent=

Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 Multiple Language Content Type
=
Document date:=C2=A0 2015-07-06
Gro=
up:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 11=

URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0=C2=A0https://www.ietf.org/internet-drafts/draft-tomkinson-slim-multi=
langcontent-01.txt
Status:=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-tomkinson-slim-multila=
ngcontent/
Htmlized:=C2=A0 =C2=A0 =C2=
=A0 =C2=A0htt=
ps://tools.ietf.org/html/draft-tomkinson-slim-multilangcontent-01
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<=
/span>https:=
//www.ietf.org/rfcdiff?url2=3Ddraft-tomkinson-slim-multilangcontent-01<=
br style=3D"font-family:arial,sans-serif;font-size:12.8000001907349px;white=
-space:normal">
Abstract:
=C2=A0 =C2=A0This document defines an addition to =
the Multipurpose Internet Mail
=C2=
=A0 =C2=A0Extensions (MIME) standard to make it possible to send one messag=
e
=C2=A0 =C2=A0that contains multip=
le language versions of the same information.
=C2=A0 =C2=A0The translations would be identified by a language =
code and selected
=C2=A0 =C2=A0by t=
he email client based on a user's language settings or locale.




--001a114e61ae7fa2ed051a37fdc6--


From nobody Mon Jul  6 13:53:14 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62CF1B3240 for ; Mon,  6 Jul 2015 13:53:12 -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] autolearn=ham
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 60NQT9jE99eT for ; Mon,  6 Jul 2015 13:53:11 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9331B3223 for ; Mon,  6 Jul 2015 13:53:00 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.4.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150706205300.11289.26802.idtracker@ietfa.amsl.com>
Date: Mon, 06 Jul 2015 13:53:00 -0700
From: IETF Secretariat 
Archived-At: 
Subject: [Slim] State changed: charter-ietf-slim-00-02
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Jul 2015 20:53:12 -0000

State changed to IESG review.

URL: https://datatracker.ietf.org/doc/charter-ietf-slim/


From nobody Mon Jul  6 13:54:03 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C771B3257; Mon,  6 Jul 2015 13:54:01 -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] autolearn=ham
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 kwiuWL9_UQre; Mon,  6 Jul 2015 13:54:00 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 397AE1B3223; Mon,  6 Jul 2015 13:54:00 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Barry Leiba" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.4.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150706205400.16719.53469.idtracker@ietfa.amsl.com>
Date: Mon, 06 Jul 2015 13:54:00 -0700
Archived-At: 
Cc: slim@ietf.org
Subject: [Slim] Barry Leiba's No Record on charter-ietf-slim-00-02: (with COMMENT)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Jul 2015 20:54:01 -0000

Barry Leiba has entered the following ballot position for
charter-ietf-slim-00-02: No Record

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-slim/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

We should go ahead and ballot on this, but I think we're going to hold
off on approval until we have a bit more discussion about whether keeping
email/web and SIP use cases together makes sense.



From nobody Mon Jul  6 16:46:45 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A7C1A1B6F for ; Mon,  6 Jul 2015 16:46:44 -0700 (PDT)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -7.011
X-Spam-Level: 
X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 vFRpzBK9lfjO for ; Mon,  6 Jul 2015 16:46:41 -0700 (PDT)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 798271A1B1B for ; Mon,  6 Jul 2015 16:46:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1436226401; x=1467762401; h=message-id:date:to:from:subject; bh=KnkAhFx3b25rxNcj5fca5IljG1yQjEWTALguu603jyc=; b=HCM6Xpdzr0FJjdDTvCnku49MLNdzc7DhmbkAaMVcVouvzYQ8pMzdTHMz i/ublTbqjlYnTodwFR0hez++Vh7Bhveo9XKVcW+1ciAuw0jFKGqdFlt3f NAwO7juV8gn6k/UvPYJoWZBl/J6FHJ9mmXRV7OGz0d3C2eauqkyPyXw9V Y=;
X-IronPort-AV: E=McAfee;i="5700,7163,7854"; a="93213991"
Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Jul 2015 16:46:40 -0700
X-IronPort-AV: E=Sophos;i="5.15,418,1432623600"; d="scan'208";a="954161335"
Received: from plus.qualcomm.com ([10.52.255.8]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Jul 2015 16:46:16 -0700
Received: from ironmsg02-L.qualcomm.com (ironmsg02-L.qualcomm.com [172.30.48.16]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id t66NkFT2028252; Mon, 6 Jul 2015 16:46:15 -0700
X-IronPort-AV: E=Sophos;i="5.15,418,1432623600"; d="scan'208";a="471298982"
X-ojodefuego: yes
Received: from unknown (HELO [99.111.97.136]) ([10.64.161.227]) by ironmsg02-L.qualcomm.com with ESMTP; 06 Jul 2015 16:46:16 -0700
Mime-Version: 1.0
Message-Id: 
X-Mailer: Eudora for Mac OS X
Date: Mon, 6 Jul 2015 16:38:39 -0700
To: slim@ietf.org
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Subject: [Slim] New Version Notification for draft-gellens-slim-negotiating-human-language-02.txt
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Jul 2015 23:46:44 -0000

--- begin forwarded text



A new version of I-D, draft-gellens-slim-negotiating-human-language-02.txt
has been successfully submitted by Randall Gellens and posted to the
IETF repository.

Name:		draft-gellens-slim-negotiating-human-language
Revision:	02
Title:		Negotiating Human Language in Real-Time Communications
Document date:	2015-07-04
Group:		Individual Submission
Pages:		19
URL: 
https://www.ietf.org/internet-drafts/draft-gellens-slim-negotiating-human-language-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-gellens-slim-negotiating-human-language/
Htmlized: 
https://tools.ietf.org/html/draft-gellens-slim-negotiating-human-language-02
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-gellens-slim-negotiating-human-language-02

Abstract:
    Users have various human (natural) language needs, abilities, and
    preferences regarding spoken, written, and signed languages.  When
    establishing interactive communication ("calls") there needs to be a
    way to negotiate (communicate and match) the caller's language and
    media needs with the capabilities of the called party.  This is
    especially important with emergency calls, where a call can be routed
    to a Public Safety Answering Point (PSAP) or call taker capable of
    communicating with the user, or a translator or relay operator can be
    bridged into the call during setup, but this applies to non-emergency
    calls as well (as an example, when calling a company call center).

    This document describes the need and expected use, and describes a
    solution using new SDP stream attributes.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--- end forwarded text




-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
I must have a prodigious quantity of mind; it takes me as much as a
week sometimes to make it up.   --Mark Twain, _The Innocents Abroad_


From nobody Tue Jul  7 08:00:13 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 462641ACD7C for ; Tue,  7 Jul 2015 08:00:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level: 
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 DTuSQho5u4Ht for ; Tue,  7 Jul 2015 08:00:05 -0700 (PDT)
Received: from bin-vsp-out-04.atm.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 08D881A1B23 for ; Tue,  7 Jul 2015 08:00:04 -0700 (PDT)
X-Halon-ID: d451fb72-24b8-11e5-b1dc-005056917c0c
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.43.70] (unknown [2.64.158.13]) by bin-vsp-out-04.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Tue,  7 Jul 2015 16:59:55 +0200 (CEST)
Message-ID: <559BE96D.2030502@omnitor.se>
Date: Tue, 07 Jul 2015 16:59:57 +0200
From: =?UTF-8?B?R3VubmFyIEhlbGxzdHLDtm0=?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: "Rosen, Brian" ,  Bernard Aboba 
References: <20150626153605.18943.13946.idtracker@ietfa.amsl.com>     
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: slim@ietf.org, Randall Gellens , "ecrit@ietf.org" 
Subject: Re: [Slim] [Ecrit] [new-work] WG Review: Selection of Language for Internet Media (slim)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Jul 2015 15:00:10 -0000

I deleted ietf and iesg from the addresses and added slim. But you are 
right that this is a general sip topic as well.
Just tell where we shall continue the discussion.

About work items: I think slim can continue to create its planned media 
and modality indications.
But work is needed on the routing mechanisms using SLIM and other 
indications to decide on connection of users and optionally assisting 
services (such as relay).

It is better if the mechanisms are general, and not emergency service 
specific. One reason is that users will then have much higher tendency 
to keep their preference settings in order. Another reason is that large 
parts of the mechanisms will be used and verified to work. The emergency 
service specific mechanisms have the risk of not being thoroughly tested 
for every kind of terminal/service provider/modality combination.

IN ETSI STF 489 we are right now intensively discussing the topics in 
this thread, and have a need to come to conclusions on realistic 
mechanisms that optimise user benefits in the emergency call scenarios.

One risk we have seen is what Brian also describes. A call with e.g. 
total conversation being routed to an ESInet entry of a country at the 
moment only supporting speech in the PSAPs. If it is a call requiring 
sign language translation, it is true that the ESInet or PSAP bridge 
could support video and real-time text even if no PSAP in that network 
does so. Then we can get a proper video relay invoked and accept to have 
the communication with the PSAP in speech with the interpreter.

But how can we handle the situation that there is a gap in NG112 
implementation. The user is in a country still on PSTN for 112. The 
search for an ESInet entry for that country will fail and the SIP 
service provider need to convert to PSTN emergency calling. Then it can 
not be expected that the 112 network can bridge the multimedia call.  It 
seems to me that for that case, the user terminal or sip service 
provider needs to have the bridge for that case.

That means that we end up with recommendations to have bridges in 
various places to be able to handle the different call scenarios 
optimally. Do you agree?

I just sent to SLIM also the view that SIP media and language tags as 
they are defined today can be used to detect need for sign language 
support ( as indicated in RFC 6443), while the asymmetric needs of 
deaf-blind communication or hard-of hearing communication will require 
slim-style indications and yet relay service users of speech-to-speech 
and captioned telephony services cannot describe their needs with the 
current proposed coding of slim, and woulld likely be better off to have 
a possibility to just request an assisting service by a URI and a sip 
operation.

Thus slim is only part of the solution. It would be good to have 
somewhere to discuss the whole picture and set slim and the other 
mechanisms in their context.
Where?

Gunnar

Rosen, Brian skrev den 2015-07-07 14:51:
> But the draft doesn’t suggest that the direct model should replace the
> current emergency call routing, it merely allows new capability.  If there
> is any language you find that makes it seem like direct routing should be
> preferred over the current location based routing, we can address that.
>
> On your specific point about not being able to deal with non-video
> equipped PSAPs, we have plenty of mechanisms available to readily
> accommodate that situation.  Devices are required to follow existing
> practice of forwarding calls to their normal outbound proxy, and this
> draft doesn’t change that at all.  What happens after that is confined to
> what the services that provide routing for VRS, and we can handle location
> sensitive handling of such calls.  All 9-1-1 calls are “direct” routed, in
> that they route to the outbound proxy, which routes based on the LoST
> query result, and that is not media sensitive.  That delivers the call to
> the right inbound proxy server, which then is able to route based on
> media, if desired.
>
> The way we handle VRS, and still get calls routed by the location of the
> caller is to have the VRS service route the call like any other 9-1-1 call
> would be routed, but they add a header that informs the PSAP that a CA is
> available.  The PSAP then creates a 3 way video/audio call among the PSAP,
> the caller and the CA.  If the PSAP wishes to use its own CA, it can do
> so, but it needs to know this is a VRS call.  The PSAP doesn’t need to
> handle video, since if it’s not sending/receiving video, it’s a 2 way
> video, 3 way audio call, and even its bridge doesn’t really need to be in
> the video path.
>
> We certainly can have ecrit review drafts coming out of this work.  NENA
> and EENA will also review.
>
> I don’t believe there is a need to have an entirely separate document to
> handle the emergency call flows.  We just need appropriate review, which
> I’m sure we can arrange.
>
> Brian
>
> On 7/6/15, 11:30 PM, "Bernard Aboba"  wrote:
>
>> I agree that the "direct" model described in the draft is very
>> problematic.  One of the guiding principles of accessibility is that
>> services need to be available as widely as possible given PSAP
>> capabilities. Attempting to route VRS emergency calls directly will
>> actually dramatically reduce the ability of disabled users to reach
>> emergency services since video could not be accepted until the PSAP is
>> equipped to handle it, even if the interpretation service were able to do
>> so, and a call routed via the interpreting service could succeed with
>> full functionality.
>>
>> These are exactly the kinds of issues that would be debated and addressed
>> within a WG with appropriate RAI focus, but which are likely to be
>> neglected in a WG whose Charter covers both emergency service
>> accessibility issues and email language selection.
>>
>> At a minimum, I would like to see another work item relating to use of
>> the proposed language specification, including call flows, within a group
>> with emergency services or SIP expertise (such as ECRIT).
>>
>>
>>
>>
>>
>>> On Jul 6, 2015, at 7:13 PM, Rosen, Brian 
>>> wrote:
>>>
>>> While I think the “direct model” is actually very problematic, I think
>>> that draft is quite appropriate for the basic purpose of making sure a
>>> trained call taker gets the call.  And, of course, it’s also very useful
>>> for generic routing of calls for which a VRS as a “transcoder” would be
>>> a
>>> much better way to make a generic video call look differently from a VRS
>>> video call, and invoke proper treatment.
>>>
>>> It’s also a better way to announce a VRS call to the call taker.  Today,
>>> we don’t know it from any other 3rd party initiated video call.
>>>
>>> As Randy says, we’ve discussed these issues with the NENA Accessibility
>>> groups as well as the FCC accessibility committee folks.  We’ve also
>>> been
>>> discussing the issues with PSAPs who have some multi-lingual call
>>> takers,
>>> and would very much appreciate being able to route to the right queue.
>>> And, of course, improving how PSAPs handle “Language Line” services is
>>> one
>>> of the basic goals of this work.  The direct model would make VRS look
>>> exactly like Language Line.
>>>
>>> Brian
>>>
>>>
>>>
>>>
>>>
>>>> On 7/6/15, 8:35 PM, "Randall Gellens"  wrote:
>>>>
>>>> Hi Bernard,
>>>>
>>>> I'd like to discuss your concerns a bit.  I've added Brian Rosen to
>>>> the email as he is chair of the NG (i3) architecture group in NENA.
>>>>
>>>> I'm trying to understand why you believe that the call flow in 4.5
>>>> would result in rejection of the video stream, rather than the PSAP
>>>> engaging an interpretation service.  As you say, we are trying to
>>>> move from today's model in which the caller first calls the relay
>>>> service, and then the relay service bridges in the PSAP, to a direct
>>>> model where the caller calls 911 directly, and the PSAP bridges in
>>>> the relay service.  Obviously, there are funding issues that would
>>>> need to be handled in order for PSAPs to be able to invoke relay
>>>> services, but both the next-gen and accessibility groups in NENA want
>>>> a direct model (which offers many advantages, including priority
>>>> treatment and location delivery).  The NENA Policy-Based Routing
>>>> (PBR) functionality within an ESInet has the ability to use the SDP
>>>> when making routing decisions (in case PSAPs have cooperation
>>>> agreements where some PSAPs handle some types of calls or some
>>>> languages or media).
>>>>
>>>> The draft and the issues have been discussed with the co-chairs of
>>>> the NENA accessibility WG, and they are strongly in favor of a direct
>>>> model for next-gen.
>>>>
>>>> In the U.S., emergency call routing is first by location, and then by
>>>> local rules (if any).  For example, if a call requires text, there
>>>> might be some PSAPs in a cooperating group that take text calls on
>>>> behalf of others.  Likewise if the call requests audio or textual
>>>> Spanish.  In Europe, various models are under discussion, including
>>>> some in which a call might be routed to a PSAP in a country where the
>>>> caller's language is native.  The draft allows this flexibility: the
>>>> call can be routed to a specific PSAP (and even call taker) or the
>>>> PSAP can bridge in translation or relay services at the start of the
>>>> call.
>>>>
>>>> At 5:15 PM -0700 7/1/15, Bernard Aboba wrote:
>>>>
>>>>> I believe that this Charter is poorly suited to developing
>>>>> solutions to the problem faced by disabled users of realtime
>>>>> emergency services.
>>>>>
>>>>> In the case of access to emergency services by the disabled, the
>>>>> goal is not "selection of the best-fit language", but rather,
>>>>> routing of the call and media so as to pull together the services
>>>>> best fitting the emergency situation and the disabilities of the
>>>>> caller, as well as the capabilities of the device and
>>>>> intermediaries which may sit between the caller and the PSAP.  Not
>>>>> only are media and language intrinsically linked, but also, the
>>>>> ways in which calls are routed is influenced and in some cases
>>>>> prescribed by regulation and national standards.
>>>>>
>>>>> Simply put, draft-gellens-slim-negotiating-human-language lacks
>>>>> appropriate consideration of the problem context.  Specifying it as
>>>>> the starting point is therefore inappropriate. As an example, today
>>>>> the call flow described in Section 4.5 would most likely result in
>>>>> rejection of the video portion of the call by the PSAP, leaving the
>>>>> dispatcher with no means of communicating with the hearing-impaired
>>>>> caller, thus leaving the caller worse off than they are today
>>>>> attempting to make an emergency call within the (cumbersome and
>>>>> error/delay-prone) Video Relay Service.   A fuller consideration of
>>>>> the problem context would involve consideration of current
>>>>> operation of relay services and proposals for their evolution.
>>>>> Attempting to develop this problem context within a WG that is
>>>>> also attempting to deal with language-selection in email would be
>>>>> frustrating at best.
>>>>>
>>>>> A sensible Charter would also probably include liaisons with
>>>>> disability rights organizations, groups specifying the operation of
>>>>> relay services, and groups considering next steps for access to
>>>>> emergency services.
>>>>>
>>>>>> From: iesg@ietf.org
>>>>>> To: new-work@ietf.org
>>>>>> Date: Fri, 26 Jun 2015 08:36:05 -0700
>>>>>> Subject: [new-work] WG Review: Selection of Language for Internet
>>>>>> Media (slim)
>>>>>>
>>>>>> A new IETF working group has been proposed in the Applications and
>>>>>> Real-Time Area. The IESG has not made any determination yet. The
>>>>>> following draft charter was submitted, and is provided for
>>>>>> informational
>>>>>> purposes only. Please send your comments to the IESG mailing list
>>>>>> (iesg
>>>>>> at ietf.org) by 2015-07-06.
>>>>>>
>>>>>> Selection of Language for Internet Media (slim)
>>>>>> ------------------------------------------------
>>>>>> Current Status: Proposed WG
>>>>>>
>>>>>> Assigned Area Director:
>>>>>> Barry Leiba 
>>>>>>
>>>>>> Mailing list
>>>>>> Address: slim@ietf.org
>>>>>> To Subscribe: https://www.ietf.org/mailman/listinfo/slim
>>>>>> Archive: https://mailarchive.ietf.org/arch/browse/slim/
>>>>>>
>>>>>> Charter:
>>>>>>
>>>>>> Description of Working Group:
>>>>>>
>>>>>> A mutually comprehensible language is helpful for human
>>>>>> communication.
>>>>>> This is true across a range of circumstances and environments. In
>>>>>> general, the problem is most acute in situations where there is not a
>>>>>> clear choice for a single language, such as environments lacking
>>>>>> contextual or out-of-band information regarding the identity of the
>>>>>> parties and the language to be used.
>>>>>>
>>>>>> The group will address two specific cases that most urgently need a
>>>>>> technical solution: One problem space is non-real-time communication,
>>>>>> specifically email for one-to-many or where the set of recipients is
>>>>>> dynamic or different recipients require different languages; the
>>>>>> other is
>>>>>> real-time communication, specifically emergency calling, preferably
>>>>>> also
>>>>>> useful for other cases where the parties may not know each other
>>>>>> personally or where one party wishes to accommodate people with
>>>>>> varying
>>>>>> language and media needs.
>>>>>>
>>>>>> In the real-time communication case, language and media are
>>>>>> intrinsically
>>>>>> linked, for example, signed languages require a video media.
>>>>>>
>>>>>> While the two use cases are in different contexts (real time and
>>>>>> non-real-time), the fundamental goal is the same: to enable selection
>>>>>> of
>>>>>> the best-fit language(s) for a specific situation. Some of the
>>>>>> details
>>>>>> will also be in common across the cases, e.g., the language tags.
>>>>>> Having
>>>>>> a single WG address both cases makes it clear that these are two
>>>>>> aspects
>>>>>> of the same basic problem. A single WG also makes it easier to
>>>>>> maximize
>>>>>> similarities and avoid unnecessary fragmentation of the solutions,
>>>>>> and
>>>>>> facilitates broader review.
>>>>>>
>>>>>> The group will produce two documents, one for email, and one for
>>>>>> real-time communications.
>>>>>>
>>>>>> In the email case, the group will determine a MIME based solution
>>>>>> that
>>>>>> enables a single email message to contain multiple language versions
>>>>>> of
>>>>>> the content, with provisions to help clients select a best fit
>>>>>> version.
>>>>>>
>>>>>> In the real-time communication case, the group will produce a
>>>>>> specification based on draft-gellens-slim-negotiating-human-language,
>>>>>> enabling negotiation of a human language per media stream. The
>>>>>> specification must be suitable for use in emergency communications as
>>>>>> specified in RFC 6443 and RFC 6881 (which use SIP and SDP to
>>>>>> negotiate
>>>>>> media); it is desirable to also be suitable for use in non-emergency
>>>>>> real-time communications that share the same call set-up and media
>>>>>> negotiation protocols. The mechanism will permit the caller's media
>>>>>> and
>>>>>> language needs and preferences to be matched against what the called
>>>>>> party is able to provide. The mechanism will permit resources (e.g.,
>>>>>> translation, relay, media) to be allocated or engaged as early as
>>>>>> possible in the call set-up or for the call to be routed or handled
>>>>>> specially (e.g., routed to a resource able to provide a needed
>>>>>> language
>>>>>> and/or media). Alternatives such as doing the negotiation in SIP have
>>>>>> been thoroughly explored in the past and are out of scope (although
>>>>>> the
>>>>>> scope might be extended after the SDP mechanism has been advanced).
>>>>>>
>>>>>> By adding language to the existing media negotiation mechanism as
>>>>>> used in
>>>>>> RFC 6443 and RFC 6881, the group can meet the basic use cases with
>>>>>> minimal added complexity and be able to enhance later for additional
>>>>>> use
>>>>>> cases as needed.
>>>>>>
>>>>>> Milestones:
>>>>>> Oct 2015 - Submit "Multiple Language Content Type" to the IESG (based
>>>>>> on draft-tomkinson-slim-multilangcontent)
>>>>>> Feb 2016 - Submit "Negotiating Human Language in Real-Time
>>>>>> Communications" to the IESG (based on
>>>>>> draft-gellens-slim-negotiating-human-language)
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> new-work mailing list
>>>>>> new-work@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/new-work
>>>>>>
>>>>>
>>>>
>>>>
>>>> -- 
>>>> Randall Gellens
>>>> Opinions are personal;    facts are suspect;    I speak for myself only
>>>> -------------- Randomly selected tag: ---------------
>>>> Just because you do not take an interest in politics doesn't mean
>>>> politics won't take and interest in you.  --Pericles (495-425 BC)
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit

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


From nobody Tue Jul  7 10:42:27 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB0BD1A88EC; Tue,  7 Jul 2015 08:31:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.967
X-Spam-Level: 
X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 JRpaIqFMiep5; Tue,  7 Jul 2015 08:31:31 -0700 (PDT)
Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 BD2DF1A8863; Tue,  7 Jul 2015 08:31:31 -0700 (PDT)
Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t67FVSCk029622;  Tue, 7 Jul 2015 11:31:29 -0400
Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1vg17us4pr-4 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 07 Jul 2015 11:31:29 -0400
Received: from STNTEXMB13.cis.neustar.com ([169.254.3.249]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Tue, 7 Jul 2015 11:31:22 -0400
From: "Rosen, Brian" 
To: =?utf-8?B?R3VubmFyIEhlbGxzdHLDtm0=?= 
Thread-Topic: [Ecrit] [new-work] WG Review: Selection of Language for Internet Media (slim)
Thread-Index: AQHQuMn6N/Xj9KjTdEOczlQHvDygLQ==
Date: Tue, 7 Jul 2015 15:31:22 +0000
Message-ID: <97EB2758-1BD6-41EF-95C1-5A557AB9718E@neustar.biz>
References: <20150626153605.18943.13946.idtracker@ietfa.amsl.com>      <559BE96D.2030502@omnitor.se>
In-Reply-To: <559BE96D.2030502@omnitor.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.33.193.32]
Content-Type: text/plain; charset="utf-8"
Content-ID: <9A57A67A34194B418A47331B5FB888EA@neustar.biz>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33,  0.0.0000 definitions=2015-07-07_05:2015-07-07,2015-07-07,1970-01-01 signatures=0
X-Proofpoint-Spam-Reason: safe
Archived-At: 
X-Mailman-Approved-At: Tue, 07 Jul 2015 10:42:24 -0700
Cc: Bernard Aboba , "slim@ietf.org" , Randall Gellens , "ecrit@ietf.org" 
Subject: Re: [Slim] [Ecrit] [new-work] WG Review: Selection of Language for Internet Media (slim)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Jul 2015 15:31:36 -0000

DQpTZWUgaW5saW5lDQo+IE9uIEp1bCA3LCAyMDE1LCBhdCAxMDo1OSBBTSwgR3VubmFyIEhlbGxz
dHLDtm0gPGd1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5zZT4gd3JvdGU6DQo+IA0KPiBJIGRlbGV0
ZWQgaWV0ZiBhbmQgaWVzZyBmcm9tIHRoZSBhZGRyZXNzZXMgYW5kIGFkZGVkIHNsaW0uIEJ1dCB5
b3UgYXJlIHJpZ2h0IHRoYXQgdGhpcyBpcyBhIGdlbmVyYWwgc2lwIHRvcGljIGFzIHdlbGwuDQo+
IEp1c3QgdGVsbCB3aGVyZSB3ZSBzaGFsbCBjb250aW51ZSB0aGUgZGlzY3Vzc2lvbi4NCkkgdGhp
bmsgdGhpcyBkaXNjdXNzaW9uIHNob3VsZCBiZSBoZWxkIG9uIHRoZSBzbGltLCBidXQgSSBsZWZ0
IGVjcml0IGluLg0KDQo+IA0KPiBBYm91dCB3b3JrIGl0ZW1zOiBJIHRoaW5rIHNsaW0gY2FuIGNv
bnRpbnVlIHRvIGNyZWF0ZSBpdHMgcGxhbm5lZCBtZWRpYSBhbmQgbW9kYWxpdHkgaW5kaWNhdGlv
bnMuDQo+IEJ1dCB3b3JrIGlzIG5lZWRlZCBvbiB0aGUgcm91dGluZyBtZWNoYW5pc21zIHVzaW5n
IFNMSU0gYW5kIG90aGVyIGluZGljYXRpb25zIHRvIGRlY2lkZSBvbiBjb25uZWN0aW9uIG9mIHVz
ZXJzIGFuZCBvcHRpb25hbGx5IGFzc2lzdGluZyBzZXJ2aWNlcyAoc3VjaCBhcyByZWxheSkuDQpJ
RVRGIGhhcyBubyB3b3JrIGdyb3VwIHRoYXQgaGFuZGxlcyByZWxheSBvciBhbnkgb3RoZXIgYXNz
aXN0ZWQgc2VydmljZS4gIFdl4oCZbGwgaGF2ZSB0byBkbyBpdCBpbiBkaXNwYXRjaCBJIHRoaW5r
LCBvciBzaXBjb3JlLg0KPiANCj4gSXQgaXMgYmV0dGVyIGlmIHRoZSBtZWNoYW5pc21zIGFyZSBn
ZW5lcmFsLCBhbmQgbm90IGVtZXJnZW5jeSBzZXJ2aWNlIHNwZWNpZmljLiBPbmUgcmVhc29uIGlz
IHRoYXQgdXNlcnMgd2lsbCB0aGVuIGhhdmUgbXVjaCBoaWdoZXIgdGVuZGVuY3kgdG8ga2VlcCB0
aGVpciBwcmVmZXJlbmNlIHNldHRpbmdzIGluIG9yZGVyLiBBbm90aGVyIHJlYXNvbiBpcyB0aGF0
IGxhcmdlIHBhcnRzIG9mIHRoZSBtZWNoYW5pc21zIHdpbGwgYmUgdXNlZCBhbmQgdmVyaWZpZWQg
dG8gd29yay4gVGhlIGVtZXJnZW5jeSBzZXJ2aWNlIHNwZWNpZmljIG1lY2hhbmlzbXMgaGF2ZSB0
aGUgcmlzayBvZiBub3QgYmVpbmcgdGhvcm91Z2hseSB0ZXN0ZWQgZm9yIGV2ZXJ5IGtpbmQgb2Yg
dGVybWluYWwvc2VydmljZSBwcm92aWRlci9tb2RhbGl0eSBjb21iaW5hdGlvbi4NCkkgYWdyZWUg
Y29tcGxldGVseS4gIFdlIHJlYWxseSB3YW50IHRoZSBzbGltIG1lY2hhbmlzbSB0byBiZSBUSEUg
d2F5IHdlIGhhbmRsZSBhIHJlcXVlc3QgZm9yIHJlbGF5LCBqdXN0IGxpa2Ugd2Ugd2FudCBpdCB0
byBiZSB0aGUgd2F5IHdlIHJlcXVlc3QgbGFuZ3VhZ2Ugcm91dGluZyBvciB0cmFuc2xhdGlvbiBm
b3IgYW55IG90aGVyIGxhbmd1YWdlDQo+IA0KPiBJTiBFVFNJIFNURiA0ODkgd2UgYXJlIHJpZ2h0
IG5vdyBpbnRlbnNpdmVseSBkaXNjdXNzaW5nIHRoZSB0b3BpY3MgaW4gdGhpcyB0aHJlYWQsIGFu
ZCBoYXZlIGEgbmVlZCB0byBjb21lIHRvIGNvbmNsdXNpb25zIG9uIHJlYWxpc3RpYyBtZWNoYW5p
c21zIHRoYXQgb3B0aW1pc2UgdXNlciBiZW5lZml0cyBpbiB0aGUgZW1lcmdlbmN5IGNhbGwgc2Nl
bmFyaW9zLg0KV2UgY2FuIHdvcmsgb24gdGhlIGVtZXJnZW5jeSBjYWxsIHNjZW5hcmlvIGluIHNs
aW0gd2l0aCBlY3JpdCBwYXJ0aWNpcGF0aW9uLiAgSSBkb27igJl0IHRoaW5rIHRoZXJlIGlzIGVu
b3VnaCB0ZXh0IHRvIGp1c3RpZnkgYSBzZXBhcmF0ZSBkb2N1bWVudC4NCj4gDQo+IE9uZSByaXNr
IHdlIGhhdmUgc2VlbiBpcyB3aGF0IEJyaWFuIGFsc28gZGVzY3JpYmVzLiBBIGNhbGwgd2l0aCBl
LmcuIHRvdGFsIGNvbnZlcnNhdGlvbiBiZWluZyByb3V0ZWQgdG8gYW4gRVNJbmV0IGVudHJ5IG9m
IGEgY291bnRyeSBhdCB0aGUgbW9tZW50IG9ubHkgc3VwcG9ydGluZyBzcGVlY2ggaW4gdGhlIFBT
QVBzLiBJZiBpdCBpcyBhIGNhbGwgcmVxdWlyaW5nIHNpZ24gbGFuZ3VhZ2UgdHJhbnNsYXRpb24s
IGl0IGlzIHRydWUgdGhhdCB0aGUgRVNJbmV0IG9yIFBTQVAgYnJpZGdlIGNvdWxkIHN1cHBvcnQg
dmlkZW8gYW5kIHJlYWwtdGltZSB0ZXh0IGV2ZW4gaWYgbm8gUFNBUCBpbiB0aGF0IG5ldHdvcmsg
ZG9lcyBzby4gVGhlbiB3ZSBjYW4gZ2V0IGEgcHJvcGVyIHZpZGVvIHJlbGF5IGludm9rZWQgYW5k
IGFjY2VwdCB0byBoYXZlIHRoZSBjb21tdW5pY2F0aW9uIHdpdGggdGhlIFBTQVAgaW4gc3BlZWNo
IHdpdGggdGhlIGludGVycHJldGVyLg0KUmlnaHQNCj4gDQo+IEJ1dCBob3cgY2FuIHdlIGhhbmRs
ZSB0aGUgc2l0dWF0aW9uIHRoYXQgdGhlcmUgaXMgYSBnYXAgaW4gTkcxMTIgaW1wbGVtZW50YXRp
b24uIFRoZSB1c2VyIGlzIGluIGEgY291bnRyeSBzdGlsbCBvbiBQU1ROIGZvciAxMTIuIFRoZSBz
ZWFyY2ggZm9yIGFuIEVTSW5ldCBlbnRyeSBmb3IgdGhhdCBjb3VudHJ5IHdpbGwgZmFpbCBhbmQg
dGhlIFNJUCBzZXJ2aWNlIHByb3ZpZGVyIG5lZWQgdG8gY29udmVydCB0byBQU1ROIGVtZXJnZW5j
eSBjYWxsaW5nLiBUaGVuIGl0IGNhbiBub3QgYmUgZXhwZWN0ZWQgdGhhdCB0aGUgMTEyIG5ldHdv
cmsgY2FuIGJyaWRnZSB0aGUgbXVsdGltZWRpYSBjYWxsLiAgSXQgc2VlbXMgdG8gbWUgdGhhdCBm
b3IgdGhhdCBjYXNlLCB0aGUgdXNlciB0ZXJtaW5hbCBvciBzaXAgc2VydmljZSBwcm92aWRlciBu
ZWVkcyB0byBoYXZlIHRoZSBicmlkZ2UgZm9yIHRoYXQgY2FzZS4NCldl4oCZdmUgZGlzY3Vzc2Vk
IHRoZSBnZW5lcmFsIHByb2JsZW0gb2YgaG93IGRvZXMgYW4gb3JpZ2luYXRpb24gY2FycmllciBr
bm93IHRoYXQgYSBjYWxsIGZyb20gYSBwYXJ0aWN1bGFyIGxvY2F0aW9uIGlzIGRlc3RpbmVkIGZv
ciBhIGNvbnZlcnRlZCAoaS5lLiBORzktMS0xL1JGQzY4ODEpIFBTQVAsIG9yIG5vdC4gIFdl4oCZ
cmUgaGVhZGluZyB0b3dhcmRzIGhhdmluZyBzb21lIExvU1QgcmVzcG9uc2UgdGhhdCBpbmRpY2F0
ZWQgdGhhdCBmYWN0LiAgIFRoYXQgY291bGQgYmUgdXNlZCBieSB0aGUgc2lwIHNlcnZpY2UgcHJv
dmlkZXIgdG8gZGVjaWRlIHdoYXQgdG8gZG8uICANCj4gDQo+IFRoYXQgbWVhbnMgdGhhdCB3ZSBl
bmQgdXAgd2l0aCByZWNvbW1lbmRhdGlvbnMgdG8gaGF2ZSBicmlkZ2VzIGluIHZhcmlvdXMgcGxh
Y2VzIHRvIGJlIGFibGUgdG8gaGFuZGxlIHRoZSBkaWZmZXJlbnQgY2FsbCBzY2VuYXJpb3Mgb3B0
aW1hbGx5LiBEbyB5b3UgYWdyZWU/DQpZZXMsIGJ1dCBJIHRoaW5rIHRoZXJlIGFyZSBleGFjdGx5
IHR3byBwbGFjZXMgLSB0aGUgcmVsYXkgcHJvdmlkZXIgYW5kIHRoZSBQU0FQLg0KPiANCj4gSSBq
dXN0IHNlbnQgdG8gU0xJTSBhbHNvIHRoZSB2aWV3IHRoYXQgU0lQIG1lZGlhIGFuZCBsYW5ndWFn
ZSB0YWdzIGFzIHRoZXkgYXJlIGRlZmluZWQgdG9kYXkgY2FuIGJlIHVzZWQgdG8gZGV0ZWN0IG5l
ZWQgZm9yIHNpZ24gbGFuZ3VhZ2Ugc3VwcG9ydCAoIGFzIGluZGljYXRlZCBpbiBSRkMgNjQ0Myks
IHdoaWxlIHRoZSBhc3ltbWV0cmljIG5lZWRzIG9mIGRlYWYtYmxpbmQgY29tbXVuaWNhdGlvbiBv
ciBoYXJkLW9mIGhlYXJpbmcgY29tbXVuaWNhdGlvbiB3aWxsIHJlcXVpcmUgc2xpbS1zdHlsZSBp
bmRpY2F0aW9ucyBhbmQgeWV0IHJlbGF5IHNlcnZpY2UgdXNlcnMgb2Ygc3BlZWNoLXRvLXNwZWVj
aCBhbmQgY2FwdGlvbmVkIHRlbGVwaG9ueSBzZXJ2aWNlcyBjYW5ub3QgZGVzY3JpYmUgdGhlaXIg
bmVlZHMgd2l0aCB0aGUgY3VycmVudCBwcm9wb3NlZCBjb2Rpbmcgb2Ygc2xpbSwgYW5kIHdvdWxs
ZCBsaWtlbHkgYmUgYmV0dGVyIG9mZiB0byBoYXZlIGEgcG9zc2liaWxpdHkgdG8ganVzdCByZXF1
ZXN0IGFuIGFzc2lzdGluZyBzZXJ2aWNlIGJ5IGEgVVJJIGFuZCBhIHNpcCBvcGVyYXRpb24uDQpJ
IHdvdWxkIHRoaW5rIHdlIGFkZCBsYW5ndWFnZSB0YWdzIGZvciB0aGVzZSBjYXNlcy4gIA0KDQo+
IA0KPiBUaHVzIHNsaW0gaXMgb25seSBwYXJ0IG9mIHRoZSBzb2x1dGlvbi4gSXQgd291bGQgYmUg
Z29vZCB0byBoYXZlIHNvbWV3aGVyZSB0byBkaXNjdXNzIHRoZSB3aG9sZSBwaWN0dXJlIGFuZCBz
ZXQgc2xpbSBhbmQgdGhlIG90aGVyIG1lY2hhbmlzbXMgaW4gdGhlaXIgY29udGV4dC4NCj4gV2hl
cmU/DQpEaXNwYXRjaCB0byBzdGFydC4gIFRoZW4gd2UgY2FuIGRlY2lkZSB3aGVyZSB0byBkbyBh
bnkgd29yayB3ZSB0aGluayB3ZSBuZWVkLg0KDQo+IA0KPiBHdW5uYXINCj4gDQo+IFJvc2VuLCBC
cmlhbiBza3JldiBkZW4gMjAxNS0wNy0wNyAxNDo1MToNCj4+IEJ1dCB0aGUgZHJhZnQgZG9lc27i
gJl0IHN1Z2dlc3QgdGhhdCB0aGUgZGlyZWN0IG1vZGVsIHNob3VsZCByZXBsYWNlIHRoZQ0KPj4g
Y3VycmVudCBlbWVyZ2VuY3kgY2FsbCByb3V0aW5nLCBpdCBtZXJlbHkgYWxsb3dzIG5ldyBjYXBh
YmlsaXR5LiAgSWYgdGhlcmUNCj4+IGlzIGFueSBsYW5ndWFnZSB5b3UgZmluZCB0aGF0IG1ha2Vz
IGl0IHNlZW0gbGlrZSBkaXJlY3Qgcm91dGluZyBzaG91bGQgYmUNCj4+IHByZWZlcnJlZCBvdmVy
IHRoZSBjdXJyZW50IGxvY2F0aW9uIGJhc2VkIHJvdXRpbmcsIHdlIGNhbiBhZGRyZXNzIHRoYXQu
DQo+PiANCj4+IE9uIHlvdXIgc3BlY2lmaWMgcG9pbnQgYWJvdXQgbm90IGJlaW5nIGFibGUgdG8g
ZGVhbCB3aXRoIG5vbi12aWRlbw0KPj4gZXF1aXBwZWQgUFNBUHMsIHdlIGhhdmUgcGxlbnR5IG9m
IG1lY2hhbmlzbXMgYXZhaWxhYmxlIHRvIHJlYWRpbHkNCj4+IGFjY29tbW9kYXRlIHRoYXQgc2l0
dWF0aW9uLiAgRGV2aWNlcyBhcmUgcmVxdWlyZWQgdG8gZm9sbG93IGV4aXN0aW5nDQo+PiBwcmFj
dGljZSBvZiBmb3J3YXJkaW5nIGNhbGxzIHRvIHRoZWlyIG5vcm1hbCBvdXRib3VuZCBwcm94eSwg
YW5kIHRoaXMNCj4+IGRyYWZ0IGRvZXNu4oCZdCBjaGFuZ2UgdGhhdCBhdCBhbGwuICBXaGF0IGhh
cHBlbnMgYWZ0ZXIgdGhhdCBpcyBjb25maW5lZCB0bw0KPj4gd2hhdCB0aGUgc2VydmljZXMgdGhh
dCBwcm92aWRlIHJvdXRpbmcgZm9yIFZSUywgYW5kIHdlIGNhbiBoYW5kbGUgbG9jYXRpb24NCj4+
IHNlbnNpdGl2ZSBoYW5kbGluZyBvZiBzdWNoIGNhbGxzLiAgQWxsIDktMS0xIGNhbGxzIGFyZSDi
gJxkaXJlY3TigJ0gcm91dGVkLCBpbg0KPj4gdGhhdCB0aGV5IHJvdXRlIHRvIHRoZSBvdXRib3Vu
ZCBwcm94eSwgd2hpY2ggcm91dGVzIGJhc2VkIG9uIHRoZSBMb1NUDQo+PiBxdWVyeSByZXN1bHQs
IGFuZCB0aGF0IGlzIG5vdCBtZWRpYSBzZW5zaXRpdmUuICBUaGF0IGRlbGl2ZXJzIHRoZSBjYWxs
IHRvDQo+PiB0aGUgcmlnaHQgaW5ib3VuZCBwcm94eSBzZXJ2ZXIsIHdoaWNoIHRoZW4gaXMgYWJs
ZSB0byByb3V0ZSBiYXNlZCBvbg0KPj4gbWVkaWEsIGlmIGRlc2lyZWQuDQo+PiANCj4+IFRoZSB3
YXkgd2UgaGFuZGxlIFZSUywgYW5kIHN0aWxsIGdldCBjYWxscyByb3V0ZWQgYnkgdGhlIGxvY2F0
aW9uIG9mIHRoZQ0KPj4gY2FsbGVyIGlzIHRvIGhhdmUgdGhlIFZSUyBzZXJ2aWNlIHJvdXRlIHRo
ZSBjYWxsIGxpa2UgYW55IG90aGVyIDktMS0xIGNhbGwNCj4+IHdvdWxkIGJlIHJvdXRlZCwgYnV0
IHRoZXkgYWRkIGEgaGVhZGVyIHRoYXQgaW5mb3JtcyB0aGUgUFNBUCB0aGF0IGEgQ0EgaXMNCj4+
IGF2YWlsYWJsZS4gIFRoZSBQU0FQIHRoZW4gY3JlYXRlcyBhIDMgd2F5IHZpZGVvL2F1ZGlvIGNh
bGwgYW1vbmcgdGhlIFBTQVAsDQo+PiB0aGUgY2FsbGVyIGFuZCB0aGUgQ0EuICBJZiB0aGUgUFNB
UCB3aXNoZXMgdG8gdXNlIGl0cyBvd24gQ0EsIGl0IGNhbiBkbw0KPj4gc28sIGJ1dCBpdCBuZWVk
cyB0byBrbm93IHRoaXMgaXMgYSBWUlMgY2FsbC4gIFRoZSBQU0FQIGRvZXNu4oCZdCBuZWVkIHRv
DQo+PiBoYW5kbGUgdmlkZW8sIHNpbmNlIGlmIGl04oCZcyBub3Qgc2VuZGluZy9yZWNlaXZpbmcg
dmlkZW8sIGl04oCZcyBhIDIgd2F5DQo+PiB2aWRlbywgMyB3YXkgYXVkaW8gY2FsbCwgYW5kIGV2
ZW4gaXRzIGJyaWRnZSBkb2VzbuKAmXQgcmVhbGx5IG5lZWQgdG8gYmUgaW4NCj4+IHRoZSB2aWRl
byBwYXRoLg0KPj4gDQo+PiBXZSBjZXJ0YWlubHkgY2FuIGhhdmUgZWNyaXQgcmV2aWV3IGRyYWZ0
cyBjb21pbmcgb3V0IG9mIHRoaXMgd29yay4gIE5FTkENCj4+IGFuZCBFRU5BIHdpbGwgYWxzbyBy
ZXZpZXcuDQo+PiANCj4+IEkgZG9u4oCZdCBiZWxpZXZlIHRoZXJlIGlzIGEgbmVlZCB0byBoYXZl
IGFuIGVudGlyZWx5IHNlcGFyYXRlIGRvY3VtZW50IHRvDQo+PiBoYW5kbGUgdGhlIGVtZXJnZW5j
eSBjYWxsIGZsb3dzLiAgV2UganVzdCBuZWVkIGFwcHJvcHJpYXRlIHJldmlldywgd2hpY2gNCj4+
IEnigJltIHN1cmUgd2UgY2FuIGFycmFuZ2UuDQo+PiANCj4+IEJyaWFuDQo+PiANCj4+IE9uIDcv
Ni8xNSwgMTE6MzAgUE0sICJCZXJuYXJkIEFib2JhIiA8YmVybmFyZF9hYm9iYUBob3RtYWlsLmNv
bT4gd3JvdGU6DQo+PiANCj4+PiBJIGFncmVlIHRoYXQgdGhlICJkaXJlY3QiIG1vZGVsIGRlc2Ny
aWJlZCBpbiB0aGUgZHJhZnQgaXMgdmVyeQ0KPj4+IHByb2JsZW1hdGljLiAgT25lIG9mIHRoZSBn
dWlkaW5nIHByaW5jaXBsZXMgb2YgYWNjZXNzaWJpbGl0eSBpcyB0aGF0DQo+Pj4gc2VydmljZXMg
bmVlZCB0byBiZSBhdmFpbGFibGUgYXMgd2lkZWx5IGFzIHBvc3NpYmxlIGdpdmVuIFBTQVANCj4+
PiBjYXBhYmlsaXRpZXMuIEF0dGVtcHRpbmcgdG8gcm91dGUgVlJTIGVtZXJnZW5jeSBjYWxscyBk
aXJlY3RseSB3aWxsDQo+Pj4gYWN0dWFsbHkgZHJhbWF0aWNhbGx5IHJlZHVjZSB0aGUgYWJpbGl0
eSBvZiBkaXNhYmxlZCB1c2VycyB0byByZWFjaA0KPj4+IGVtZXJnZW5jeSBzZXJ2aWNlcyBzaW5j
ZSB2aWRlbyBjb3VsZCBub3QgYmUgYWNjZXB0ZWQgdW50aWwgdGhlIFBTQVAgaXMNCj4+PiBlcXVp
cHBlZCB0byBoYW5kbGUgaXQsIGV2ZW4gaWYgdGhlIGludGVycHJldGF0aW9uIHNlcnZpY2Ugd2Vy
ZSBhYmxlIHRvIGRvDQo+Pj4gc28sIGFuZCBhIGNhbGwgcm91dGVkIHZpYSB0aGUgaW50ZXJwcmV0
aW5nIHNlcnZpY2UgY291bGQgc3VjY2VlZCB3aXRoDQo+Pj4gZnVsbCBmdW5jdGlvbmFsaXR5Lg0K
Pj4+IA0KPj4+IFRoZXNlIGFyZSBleGFjdGx5IHRoZSBraW5kcyBvZiBpc3N1ZXMgdGhhdCB3b3Vs
ZCBiZSBkZWJhdGVkIGFuZCBhZGRyZXNzZWQNCj4+PiB3aXRoaW4gYSBXRyB3aXRoIGFwcHJvcHJp
YXRlIFJBSSBmb2N1cywgYnV0IHdoaWNoIGFyZSBsaWtlbHkgdG8gYmUNCj4+PiBuZWdsZWN0ZWQg
aW4gYSBXRyB3aG9zZSBDaGFydGVyIGNvdmVycyBib3RoIGVtZXJnZW5jeSBzZXJ2aWNlDQo+Pj4g
YWNjZXNzaWJpbGl0eSBpc3N1ZXMgYW5kIGVtYWlsIGxhbmd1YWdlIHNlbGVjdGlvbi4NCj4+PiAN
Cj4+PiBBdCBhIG1pbmltdW0sIEkgd291bGQgbGlrZSB0byBzZWUgYW5vdGhlciB3b3JrIGl0ZW0g
cmVsYXRpbmcgdG8gdXNlIG9mDQo+Pj4gdGhlIHByb3Bvc2VkIGxhbmd1YWdlIHNwZWNpZmljYXRp
b24sIGluY2x1ZGluZyBjYWxsIGZsb3dzLCB3aXRoaW4gYSBncm91cA0KPj4+IHdpdGggZW1lcmdl
bmN5IHNlcnZpY2VzIG9yIFNJUCBleHBlcnRpc2UgKHN1Y2ggYXMgRUNSSVQpLg0KPj4+IA0KPj4+
IA0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+PiBPbiBKdWwgNiwgMjAxNSwgYXQgNzoxMyBQTSwgUm9z
ZW4sIEJyaWFuIDxCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpej4NCj4+Pj4gd3JvdGU6DQo+Pj4+IA0K
Pj4+PiBXaGlsZSBJIHRoaW5rIHRoZSDigJxkaXJlY3QgbW9kZWzigJ0gaXMgYWN0dWFsbHkgdmVy
eSBwcm9ibGVtYXRpYywgSSB0aGluaw0KPj4+PiB0aGF0IGRyYWZ0IGlzIHF1aXRlIGFwcHJvcHJp
YXRlIGZvciB0aGUgYmFzaWMgcHVycG9zZSBvZiBtYWtpbmcgc3VyZSBhDQo+Pj4+IHRyYWluZWQg
Y2FsbCB0YWtlciBnZXRzIHRoZSBjYWxsLiAgQW5kLCBvZiBjb3Vyc2UsIGl04oCZcyBhbHNvIHZl
cnkgdXNlZnVsDQo+Pj4+IGZvciBnZW5lcmljIHJvdXRpbmcgb2YgY2FsbHMgZm9yIHdoaWNoIGEg
VlJTIGFzIGEg4oCcdHJhbnNjb2RlcuKAnSB3b3VsZCBiZQ0KPj4+PiBhDQo+Pj4+IG11Y2ggYmV0
dGVyIHdheSB0byBtYWtlIGEgZ2VuZXJpYyB2aWRlbyBjYWxsIGxvb2sgZGlmZmVyZW50bHkgZnJv
bSBhIFZSUw0KPj4+PiB2aWRlbyBjYWxsLCBhbmQgaW52b2tlIHByb3BlciB0cmVhdG1lbnQuDQo+
Pj4+IA0KPj4+PiBJdOKAmXMgYWxzbyBhIGJldHRlciB3YXkgdG8gYW5ub3VuY2UgYSBWUlMgY2Fs
bCB0byB0aGUgY2FsbCB0YWtlci4gIFRvZGF5LA0KPj4+PiB3ZSBkb27igJl0IGtub3cgaXQgZnJv
bSBhbnkgb3RoZXIgM3JkIHBhcnR5IGluaXRpYXRlZCB2aWRlbyBjYWxsLg0KPj4+PiANCj4+Pj4g
QXMgUmFuZHkgc2F5cywgd2XigJl2ZSBkaXNjdXNzZWQgdGhlc2UgaXNzdWVzIHdpdGggdGhlIE5F
TkEgQWNjZXNzaWJpbGl0eQ0KPj4+PiBncm91cHMgYXMgd2VsbCBhcyB0aGUgRkNDIGFjY2Vzc2li
aWxpdHkgY29tbWl0dGVlIGZvbGtzLiAgV2XigJl2ZSBhbHNvDQo+Pj4+IGJlZW4NCj4+Pj4gZGlz
Y3Vzc2luZyB0aGUgaXNzdWVzIHdpdGggUFNBUHMgd2hvIGhhdmUgc29tZSBtdWx0aS1saW5ndWFs
IGNhbGwNCj4+Pj4gdGFrZXJzLA0KPj4+PiBhbmQgd291bGQgdmVyeSBtdWNoIGFwcHJlY2lhdGUg
YmVpbmcgYWJsZSB0byByb3V0ZSB0byB0aGUgcmlnaHQgcXVldWUuDQo+Pj4+IEFuZCwgb2YgY291
cnNlLCBpbXByb3ZpbmcgaG93IFBTQVBzIGhhbmRsZSDigJxMYW5ndWFnZSBMaW5l4oCdIHNlcnZp
Y2VzIGlzDQo+Pj4+IG9uZQ0KPj4+PiBvZiB0aGUgYmFzaWMgZ29hbHMgb2YgdGhpcyB3b3JrLiAg
VGhlIGRpcmVjdCBtb2RlbCB3b3VsZCBtYWtlIFZSUyBsb29rDQo+Pj4+IGV4YWN0bHkgbGlrZSBM
YW5ndWFnZSBMaW5lLg0KPj4+PiANCj4+Pj4gQnJpYW4NCj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+
Pj4gDQo+Pj4+IA0KPj4+Pj4gT24gNy82LzE1LCA4OjM1IFBNLCAiUmFuZGFsbCBHZWxsZW5zIiA8
cmFuZHlAcXRpLnF1YWxjb21tLmNvbT4gd3JvdGU6DQo+Pj4+PiANCj4+Pj4+IEhpIEJlcm5hcmQs
DQo+Pj4+PiANCj4+Pj4+IEknZCBsaWtlIHRvIGRpc2N1c3MgeW91ciBjb25jZXJucyBhIGJpdC4g
IEkndmUgYWRkZWQgQnJpYW4gUm9zZW4gdG8NCj4+Pj4+IHRoZSBlbWFpbCBhcyBoZSBpcyBjaGFp
ciBvZiB0aGUgTkcgKGkzKSBhcmNoaXRlY3R1cmUgZ3JvdXAgaW4gTkVOQS4NCj4+Pj4+IA0KPj4+
Pj4gSSdtIHRyeWluZyB0byB1bmRlcnN0YW5kIHdoeSB5b3UgYmVsaWV2ZSB0aGF0IHRoZSBjYWxs
IGZsb3cgaW4gNC41DQo+Pj4+PiB3b3VsZCByZXN1bHQgaW4gcmVqZWN0aW9uIG9mIHRoZSB2aWRl
byBzdHJlYW0sIHJhdGhlciB0aGFuIHRoZSBQU0FQDQo+Pj4+PiBlbmdhZ2luZyBhbiBpbnRlcnBy
ZXRhdGlvbiBzZXJ2aWNlLiAgQXMgeW91IHNheSwgd2UgYXJlIHRyeWluZyB0bw0KPj4+Pj4gbW92
ZSBmcm9tIHRvZGF5J3MgbW9kZWwgaW4gd2hpY2ggdGhlIGNhbGxlciBmaXJzdCBjYWxscyB0aGUg
cmVsYXkNCj4+Pj4+IHNlcnZpY2UsIGFuZCB0aGVuIHRoZSByZWxheSBzZXJ2aWNlIGJyaWRnZXMg
aW4gdGhlIFBTQVAsIHRvIGEgZGlyZWN0DQo+Pj4+PiBtb2RlbCB3aGVyZSB0aGUgY2FsbGVyIGNh
bGxzIDkxMSBkaXJlY3RseSwgYW5kIHRoZSBQU0FQIGJyaWRnZXMgaW4NCj4+Pj4+IHRoZSByZWxh
eSBzZXJ2aWNlLiAgT2J2aW91c2x5LCB0aGVyZSBhcmUgZnVuZGluZyBpc3N1ZXMgdGhhdCB3b3Vs
ZA0KPj4+Pj4gbmVlZCB0byBiZSBoYW5kbGVkIGluIG9yZGVyIGZvciBQU0FQcyB0byBiZSBhYmxl
IHRvIGludm9rZSByZWxheQ0KPj4+Pj4gc2VydmljZXMsIGJ1dCBib3RoIHRoZSBuZXh0LWdlbiBh
bmQgYWNjZXNzaWJpbGl0eSBncm91cHMgaW4gTkVOQSB3YW50DQo+Pj4+PiBhIGRpcmVjdCBtb2Rl
bCAod2hpY2ggb2ZmZXJzIG1hbnkgYWR2YW50YWdlcywgaW5jbHVkaW5nIHByaW9yaXR5DQo+Pj4+
PiB0cmVhdG1lbnQgYW5kIGxvY2F0aW9uIGRlbGl2ZXJ5KS4gIFRoZSBORU5BIFBvbGljeS1CYXNl
ZCBSb3V0aW5nDQo+Pj4+PiAoUEJSKSBmdW5jdGlvbmFsaXR5IHdpdGhpbiBhbiBFU0luZXQgaGFz
IHRoZSBhYmlsaXR5IHRvIHVzZSB0aGUgU0RQDQo+Pj4+PiB3aGVuIG1ha2luZyByb3V0aW5nIGRl
Y2lzaW9ucyAoaW4gY2FzZSBQU0FQcyBoYXZlIGNvb3BlcmF0aW9uDQo+Pj4+PiBhZ3JlZW1lbnRz
IHdoZXJlIHNvbWUgUFNBUHMgaGFuZGxlIHNvbWUgdHlwZXMgb2YgY2FsbHMgb3Igc29tZQ0KPj4+
Pj4gbGFuZ3VhZ2VzIG9yIG1lZGlhKS4NCj4+Pj4+IA0KPj4+Pj4gVGhlIGRyYWZ0IGFuZCB0aGUg
aXNzdWVzIGhhdmUgYmVlbiBkaXNjdXNzZWQgd2l0aCB0aGUgY28tY2hhaXJzIG9mDQo+Pj4+PiB0
aGUgTkVOQSBhY2Nlc3NpYmlsaXR5IFdHLCBhbmQgdGhleSBhcmUgc3Ryb25nbHkgaW4gZmF2b3Ig
b2YgYSBkaXJlY3QNCj4+Pj4+IG1vZGVsIGZvciBuZXh0LWdlbi4NCj4+Pj4+IA0KPj4+Pj4gSW4g
dGhlIFUuUy4sIGVtZXJnZW5jeSBjYWxsIHJvdXRpbmcgaXMgZmlyc3QgYnkgbG9jYXRpb24sIGFu
ZCB0aGVuIGJ5DQo+Pj4+PiBsb2NhbCBydWxlcyAoaWYgYW55KS4gIEZvciBleGFtcGxlLCBpZiBh
IGNhbGwgcmVxdWlyZXMgdGV4dCwgdGhlcmUNCj4+Pj4+IG1pZ2h0IGJlIHNvbWUgUFNBUHMgaW4g
YSBjb29wZXJhdGluZyBncm91cCB0aGF0IHRha2UgdGV4dCBjYWxscyBvbg0KPj4+Pj4gYmVoYWxm
IG9mIG90aGVycy4gIExpa2V3aXNlIGlmIHRoZSBjYWxsIHJlcXVlc3RzIGF1ZGlvIG9yIHRleHR1
YWwNCj4+Pj4+IFNwYW5pc2guICBJbiBFdXJvcGUsIHZhcmlvdXMgbW9kZWxzIGFyZSB1bmRlciBk
aXNjdXNzaW9uLCBpbmNsdWRpbmcNCj4+Pj4+IHNvbWUgaW4gd2hpY2ggYSBjYWxsIG1pZ2h0IGJl
IHJvdXRlZCB0byBhIFBTQVAgaW4gYSBjb3VudHJ5IHdoZXJlIHRoZQ0KPj4+Pj4gY2FsbGVyJ3Mg
bGFuZ3VhZ2UgaXMgbmF0aXZlLiAgVGhlIGRyYWZ0IGFsbG93cyB0aGlzIGZsZXhpYmlsaXR5OiB0
aGUNCj4+Pj4+IGNhbGwgY2FuIGJlIHJvdXRlZCB0byBhIHNwZWNpZmljIFBTQVAgKGFuZCBldmVu
IGNhbGwgdGFrZXIpIG9yIHRoZQ0KPj4+Pj4gUFNBUCBjYW4gYnJpZGdlIGluIHRyYW5zbGF0aW9u
IG9yIHJlbGF5IHNlcnZpY2VzIGF0IHRoZSBzdGFydCBvZiB0aGUNCj4+Pj4+IGNhbGwuDQo+Pj4+
PiANCj4+Pj4+IEF0IDU6MTUgUE0gLTA3MDAgNy8xLzE1LCBCZXJuYXJkIEFib2JhIHdyb3RlOg0K
Pj4+Pj4gDQo+Pj4+Pj4gSSBiZWxpZXZlIHRoYXQgdGhpcyBDaGFydGVyIGlzIHBvb3JseSBzdWl0
ZWQgdG8gZGV2ZWxvcGluZw0KPj4+Pj4+IHNvbHV0aW9ucyB0byB0aGUgcHJvYmxlbSBmYWNlZCBi
eSBkaXNhYmxlZCB1c2VycyBvZiByZWFsdGltZQ0KPj4+Pj4+IGVtZXJnZW5jeSBzZXJ2aWNlcy4N
Cj4+Pj4+PiANCj4+Pj4+PiBJbiB0aGUgY2FzZSBvZiBhY2Nlc3MgdG8gZW1lcmdlbmN5IHNlcnZp
Y2VzIGJ5IHRoZSBkaXNhYmxlZCwgdGhlDQo+Pj4+Pj4gZ29hbCBpcyBub3QgInNlbGVjdGlvbiBv
ZiB0aGUgYmVzdC1maXQgbGFuZ3VhZ2UiLCBidXQgcmF0aGVyLA0KPj4+Pj4+IHJvdXRpbmcgb2Yg
dGhlIGNhbGwgYW5kIG1lZGlhIHNvIGFzIHRvIHB1bGwgdG9nZXRoZXIgdGhlIHNlcnZpY2VzDQo+
Pj4+Pj4gYmVzdCBmaXR0aW5nIHRoZSBlbWVyZ2VuY3kgc2l0dWF0aW9uIGFuZCB0aGUgZGlzYWJp
bGl0aWVzIG9mIHRoZQ0KPj4+Pj4+IGNhbGxlciwgYXMgd2VsbCBhcyB0aGUgY2FwYWJpbGl0aWVz
IG9mIHRoZSBkZXZpY2UgYW5kDQo+Pj4+Pj4gaW50ZXJtZWRpYXJpZXMgd2hpY2ggbWF5IHNpdCBi
ZXR3ZWVuIHRoZSBjYWxsZXIgYW5kIHRoZSBQU0FQLiAgTm90DQo+Pj4+Pj4gb25seSBhcmUgbWVk
aWEgYW5kIGxhbmd1YWdlIGludHJpbnNpY2FsbHkgbGlua2VkLCBidXQgYWxzbywgdGhlDQo+Pj4+
Pj4gd2F5cyBpbiB3aGljaCBjYWxscyBhcmUgcm91dGVkIGlzIGluZmx1ZW5jZWQgYW5kIGluIHNv
bWUgY2FzZXMNCj4+Pj4+PiBwcmVzY3JpYmVkIGJ5IHJlZ3VsYXRpb24gYW5kIG5hdGlvbmFsIHN0
YW5kYXJkcy4NCj4+Pj4+PiANCj4+Pj4+PiBTaW1wbHkgcHV0LCBkcmFmdC1nZWxsZW5zLXNsaW0t
bmVnb3RpYXRpbmctaHVtYW4tbGFuZ3VhZ2UgbGFja3MNCj4+Pj4+PiBhcHByb3ByaWF0ZSBjb25z
aWRlcmF0aW9uIG9mIHRoZSBwcm9ibGVtIGNvbnRleHQuICBTcGVjaWZ5aW5nIGl0IGFzDQo+Pj4+
Pj4gdGhlIHN0YXJ0aW5nIHBvaW50IGlzIHRoZXJlZm9yZSBpbmFwcHJvcHJpYXRlLiBBcyBhbiBl
eGFtcGxlLCB0b2RheQ0KPj4+Pj4+IHRoZSBjYWxsIGZsb3cgZGVzY3JpYmVkIGluIFNlY3Rpb24g
NC41IHdvdWxkIG1vc3QgbGlrZWx5IHJlc3VsdCBpbg0KPj4+Pj4+IHJlamVjdGlvbiBvZiB0aGUg
dmlkZW8gcG9ydGlvbiBvZiB0aGUgY2FsbCBieSB0aGUgUFNBUCwgbGVhdmluZyB0aGUNCj4+Pj4+
PiBkaXNwYXRjaGVyIHdpdGggbm8gbWVhbnMgb2YgY29tbXVuaWNhdGluZyB3aXRoIHRoZSBoZWFy
aW5nLWltcGFpcmVkDQo+Pj4+Pj4gY2FsbGVyLCB0aHVzIGxlYXZpbmcgdGhlIGNhbGxlciB3b3Jz
ZSBvZmYgdGhhbiB0aGV5IGFyZSB0b2RheQ0KPj4+Pj4+IGF0dGVtcHRpbmcgdG8gbWFrZSBhbiBl
bWVyZ2VuY3kgY2FsbCB3aXRoaW4gdGhlIChjdW1iZXJzb21lIGFuZA0KPj4+Pj4+IGVycm9yL2Rl
bGF5LXByb25lKSBWaWRlbyBSZWxheSBTZXJ2aWNlLiAgIEEgZnVsbGVyIGNvbnNpZGVyYXRpb24g
b2YNCj4+Pj4+PiB0aGUgcHJvYmxlbSBjb250ZXh0IHdvdWxkIGludm9sdmUgY29uc2lkZXJhdGlv
biBvZiBjdXJyZW50DQo+Pj4+Pj4gb3BlcmF0aW9uIG9mIHJlbGF5IHNlcnZpY2VzIGFuZCBwcm9w
b3NhbHMgZm9yIHRoZWlyIGV2b2x1dGlvbi4NCj4+Pj4+PiBBdHRlbXB0aW5nIHRvIGRldmVsb3Ag
dGhpcyBwcm9ibGVtIGNvbnRleHQgd2l0aGluIGEgV0cgdGhhdCBpcw0KPj4+Pj4+IGFsc28gYXR0
ZW1wdGluZyB0byBkZWFsIHdpdGggbGFuZ3VhZ2Utc2VsZWN0aW9uIGluIGVtYWlsIHdvdWxkIGJl
DQo+Pj4+Pj4gZnJ1c3RyYXRpbmcgYXQgYmVzdC4NCj4+Pj4+PiANCj4+Pj4+PiBBIHNlbnNpYmxl
IENoYXJ0ZXIgd291bGQgYWxzbyBwcm9iYWJseSBpbmNsdWRlIGxpYWlzb25zIHdpdGgNCj4+Pj4+
PiBkaXNhYmlsaXR5IHJpZ2h0cyBvcmdhbml6YXRpb25zLCBncm91cHMgc3BlY2lmeWluZyB0aGUg
b3BlcmF0aW9uIG9mDQo+Pj4+Pj4gcmVsYXkgc2VydmljZXMsIGFuZCBncm91cHMgY29uc2lkZXJp
bmcgbmV4dCBzdGVwcyBmb3IgYWNjZXNzIHRvDQo+Pj4+Pj4gZW1lcmdlbmN5IHNlcnZpY2VzLg0K
Pj4+Pj4+IA0KPj4+Pj4+PiBGcm9tOiBpZXNnQGlldGYub3JnDQo+Pj4+Pj4+IFRvOiBuZXctd29y
a0BpZXRmLm9yZw0KPj4+Pj4+PiBEYXRlOiBGcmksIDI2IEp1biAyMDE1IDA4OjM2OjA1IC0wNzAw
DQo+Pj4+Pj4+IFN1YmplY3Q6IFtuZXctd29ya10gV0cgUmV2aWV3OiBTZWxlY3Rpb24gb2YgTGFu
Z3VhZ2UgZm9yIEludGVybmV0DQo+Pj4+Pj4+IE1lZGlhIChzbGltKQ0KPj4+Pj4+PiANCj4+Pj4+
Pj4gQSBuZXcgSUVURiB3b3JraW5nIGdyb3VwIGhhcyBiZWVuIHByb3Bvc2VkIGluIHRoZSBBcHBs
aWNhdGlvbnMgYW5kDQo+Pj4+Pj4+IFJlYWwtVGltZSBBcmVhLiBUaGUgSUVTRyBoYXMgbm90IG1h
ZGUgYW55IGRldGVybWluYXRpb24geWV0LiBUaGUNCj4+Pj4+Pj4gZm9sbG93aW5nIGRyYWZ0IGNo
YXJ0ZXIgd2FzIHN1Ym1pdHRlZCwgYW5kIGlzIHByb3ZpZGVkIGZvcg0KPj4+Pj4+PiBpbmZvcm1h
dGlvbmFsDQo+Pj4+Pj4+IHB1cnBvc2VzIG9ubHkuIFBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMg
dG8gdGhlIElFU0cgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+IChpZXNnDQo+Pj4+Pj4+IGF0IGlldGYu
b3JnKSBieSAyMDE1LTA3LTA2Lg0KPj4+Pj4+PiANCj4+Pj4+Pj4gU2VsZWN0aW9uIG9mIExhbmd1
YWdlIGZvciBJbnRlcm5ldCBNZWRpYSAoc2xpbSkNCj4+Pj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+Pj4+IEN1cnJlbnQgU3RhdHVzOiBQ
cm9wb3NlZCBXRw0KPj4+Pj4+PiANCj4+Pj4+Pj4gQXNzaWduZWQgQXJlYSBEaXJlY3RvcjoNCj4+
Pj4+Pj4gQmFycnkgTGVpYmEgPGJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnPg0KPj4+Pj4+PiANCj4+
Pj4+Pj4gTWFpbGluZyBsaXN0DQo+Pj4+Pj4+IEFkZHJlc3M6IHNsaW1AaWV0Zi5vcmcNCj4+Pj4+
Pj4gVG8gU3Vic2NyaWJlOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Ns
aW0NCj4+Pj4+Pj4gQXJjaGl2ZTogaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL2Jy
b3dzZS9zbGltLw0KPj4+Pj4+PiANCj4+Pj4+Pj4gQ2hhcnRlcjoNCj4+Pj4+Pj4gDQo+Pj4+Pj4+
IERlc2NyaXB0aW9uIG9mIFdvcmtpbmcgR3JvdXA6DQo+Pj4+Pj4+IA0KPj4+Pj4+PiBBIG11dHVh
bGx5IGNvbXByZWhlbnNpYmxlIGxhbmd1YWdlIGlzIGhlbHBmdWwgZm9yIGh1bWFuDQo+Pj4+Pj4+
IGNvbW11bmljYXRpb24uDQo+Pj4+Pj4+IFRoaXMgaXMgdHJ1ZSBhY3Jvc3MgYSByYW5nZSBvZiBj
aXJjdW1zdGFuY2VzIGFuZCBlbnZpcm9ubWVudHMuIEluDQo+Pj4+Pj4+IGdlbmVyYWwsIHRoZSBw
cm9ibGVtIGlzIG1vc3QgYWN1dGUgaW4gc2l0dWF0aW9ucyB3aGVyZSB0aGVyZSBpcyBub3QgYQ0K
Pj4+Pj4+PiBjbGVhciBjaG9pY2UgZm9yIGEgc2luZ2xlIGxhbmd1YWdlLCBzdWNoIGFzIGVudmly
b25tZW50cyBsYWNraW5nDQo+Pj4+Pj4+IGNvbnRleHR1YWwgb3Igb3V0LW9mLWJhbmQgaW5mb3Jt
YXRpb24gcmVnYXJkaW5nIHRoZSBpZGVudGl0eSBvZiB0aGUNCj4+Pj4+Pj4gcGFydGllcyBhbmQg
dGhlIGxhbmd1YWdlIHRvIGJlIHVzZWQuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBUaGUgZ3JvdXAgd2ls
bCBhZGRyZXNzIHR3byBzcGVjaWZpYyBjYXNlcyB0aGF0IG1vc3QgdXJnZW50bHkgbmVlZCBhDQo+
Pj4+Pj4+IHRlY2huaWNhbCBzb2x1dGlvbjogT25lIHByb2JsZW0gc3BhY2UgaXMgbm9uLXJlYWwt
dGltZSBjb21tdW5pY2F0aW9uLA0KPj4+Pj4+PiBzcGVjaWZpY2FsbHkgZW1haWwgZm9yIG9uZS10
by1tYW55IG9yIHdoZXJlIHRoZSBzZXQgb2YgcmVjaXBpZW50cyBpcw0KPj4+Pj4+PiBkeW5hbWlj
IG9yIGRpZmZlcmVudCByZWNpcGllbnRzIHJlcXVpcmUgZGlmZmVyZW50IGxhbmd1YWdlczsgdGhl
DQo+Pj4+Pj4+IG90aGVyIGlzDQo+Pj4+Pj4+IHJlYWwtdGltZSBjb21tdW5pY2F0aW9uLCBzcGVj
aWZpY2FsbHkgZW1lcmdlbmN5IGNhbGxpbmcsIHByZWZlcmFibHkNCj4+Pj4+Pj4gYWxzbw0KPj4+
Pj4+PiB1c2VmdWwgZm9yIG90aGVyIGNhc2VzIHdoZXJlIHRoZSBwYXJ0aWVzIG1heSBub3Qga25v
dyBlYWNoIG90aGVyDQo+Pj4+Pj4+IHBlcnNvbmFsbHkgb3Igd2hlcmUgb25lIHBhcnR5IHdpc2hl
cyB0byBhY2NvbW1vZGF0ZSBwZW9wbGUgd2l0aA0KPj4+Pj4+PiB2YXJ5aW5nDQo+Pj4+Pj4+IGxh
bmd1YWdlIGFuZCBtZWRpYSBuZWVkcy4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IEluIHRoZSByZWFsLXRp
bWUgY29tbXVuaWNhdGlvbiBjYXNlLCBsYW5ndWFnZSBhbmQgbWVkaWEgYXJlDQo+Pj4+Pj4+IGlu
dHJpbnNpY2FsbHkNCj4+Pj4+Pj4gbGlua2VkLCBmb3IgZXhhbXBsZSwgc2lnbmVkIGxhbmd1YWdl
cyByZXF1aXJlIGEgdmlkZW8gbWVkaWEuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBXaGlsZSB0aGUgdHdv
IHVzZSBjYXNlcyBhcmUgaW4gZGlmZmVyZW50IGNvbnRleHRzIChyZWFsIHRpbWUgYW5kDQo+Pj4+
Pj4+IG5vbi1yZWFsLXRpbWUpLCB0aGUgZnVuZGFtZW50YWwgZ29hbCBpcyB0aGUgc2FtZTogdG8g
ZW5hYmxlIHNlbGVjdGlvbg0KPj4+Pj4+PiBvZg0KPj4+Pj4+PiB0aGUgYmVzdC1maXQgbGFuZ3Vh
Z2UocykgZm9yIGEgc3BlY2lmaWMgc2l0dWF0aW9uLiBTb21lIG9mIHRoZQ0KPj4+Pj4+PiBkZXRh
aWxzDQo+Pj4+Pj4+IHdpbGwgYWxzbyBiZSBpbiBjb21tb24gYWNyb3NzIHRoZSBjYXNlcywgZS5n
LiwgdGhlIGxhbmd1YWdlIHRhZ3MuDQo+Pj4+Pj4+IEhhdmluZw0KPj4+Pj4+PiBhIHNpbmdsZSBX
RyBhZGRyZXNzIGJvdGggY2FzZXMgbWFrZXMgaXQgY2xlYXIgdGhhdCB0aGVzZSBhcmUgdHdvDQo+
Pj4+Pj4+IGFzcGVjdHMNCj4+Pj4+Pj4gb2YgdGhlIHNhbWUgYmFzaWMgcHJvYmxlbS4gQSBzaW5n
bGUgV0cgYWxzbyBtYWtlcyBpdCBlYXNpZXIgdG8NCj4+Pj4+Pj4gbWF4aW1pemUNCj4+Pj4+Pj4g
c2ltaWxhcml0aWVzIGFuZCBhdm9pZCB1bm5lY2Vzc2FyeSBmcmFnbWVudGF0aW9uIG9mIHRoZSBz
b2x1dGlvbnMsDQo+Pj4+Pj4+IGFuZA0KPj4+Pj4+PiBmYWNpbGl0YXRlcyBicm9hZGVyIHJldmll
dy4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IFRoZSBncm91cCB3aWxsIHByb2R1Y2UgdHdvIGRvY3VtZW50
cywgb25lIGZvciBlbWFpbCwgYW5kIG9uZSBmb3INCj4+Pj4+Pj4gcmVhbC10aW1lIGNvbW11bmlj
YXRpb25zLg0KPj4+Pj4+PiANCj4+Pj4+Pj4gSW4gdGhlIGVtYWlsIGNhc2UsIHRoZSBncm91cCB3
aWxsIGRldGVybWluZSBhIE1JTUUgYmFzZWQgc29sdXRpb24NCj4+Pj4+Pj4gdGhhdA0KPj4+Pj4+
PiBlbmFibGVzIGEgc2luZ2xlIGVtYWlsIG1lc3NhZ2UgdG8gY29udGFpbiBtdWx0aXBsZSBsYW5n
dWFnZSB2ZXJzaW9ucw0KPj4+Pj4+PiBvZg0KPj4+Pj4+PiB0aGUgY29udGVudCwgd2l0aCBwcm92
aXNpb25zIHRvIGhlbHAgY2xpZW50cyBzZWxlY3QgYSBiZXN0IGZpdA0KPj4+Pj4+PiB2ZXJzaW9u
Lg0KPj4+Pj4+PiANCj4+Pj4+Pj4gSW4gdGhlIHJlYWwtdGltZSBjb21tdW5pY2F0aW9uIGNhc2Us
IHRoZSBncm91cCB3aWxsIHByb2R1Y2UgYQ0KPj4+Pj4+PiBzcGVjaWZpY2F0aW9uIGJhc2VkIG9u
IGRyYWZ0LWdlbGxlbnMtc2xpbS1uZWdvdGlhdGluZy1odW1hbi1sYW5ndWFnZSwNCj4+Pj4+Pj4g
ZW5hYmxpbmcgbmVnb3RpYXRpb24gb2YgYSBodW1hbiBsYW5ndWFnZSBwZXIgbWVkaWEgc3RyZWFt
LiBUaGUNCj4+Pj4+Pj4gc3BlY2lmaWNhdGlvbiBtdXN0IGJlIHN1aXRhYmxlIGZvciB1c2UgaW4g
ZW1lcmdlbmN5IGNvbW11bmljYXRpb25zIGFzDQo+Pj4+Pj4+IHNwZWNpZmllZCBpbiBSRkMgNjQ0
MyBhbmQgUkZDIDY4ODEgKHdoaWNoIHVzZSBTSVAgYW5kIFNEUCB0bw0KPj4+Pj4+PiBuZWdvdGlh
dGUNCj4+Pj4+Pj4gbWVkaWEpOyBpdCBpcyBkZXNpcmFibGUgdG8gYWxzbyBiZSBzdWl0YWJsZSBm
b3IgdXNlIGluIG5vbi1lbWVyZ2VuY3kNCj4+Pj4+Pj4gcmVhbC10aW1lIGNvbW11bmljYXRpb25z
IHRoYXQgc2hhcmUgdGhlIHNhbWUgY2FsbCBzZXQtdXAgYW5kIG1lZGlhDQo+Pj4+Pj4+IG5lZ290
aWF0aW9uIHByb3RvY29scy4gVGhlIG1lY2hhbmlzbSB3aWxsIHBlcm1pdCB0aGUgY2FsbGVyJ3Mg
bWVkaWENCj4+Pj4+Pj4gYW5kDQo+Pj4+Pj4+IGxhbmd1YWdlIG5lZWRzIGFuZCBwcmVmZXJlbmNl
cyB0byBiZSBtYXRjaGVkIGFnYWluc3Qgd2hhdCB0aGUgY2FsbGVkDQo+Pj4+Pj4+IHBhcnR5IGlz
IGFibGUgdG8gcHJvdmlkZS4gVGhlIG1lY2hhbmlzbSB3aWxsIHBlcm1pdCByZXNvdXJjZXMgKGUu
Zy4sDQo+Pj4+Pj4+IHRyYW5zbGF0aW9uLCByZWxheSwgbWVkaWEpIHRvIGJlIGFsbG9jYXRlZCBv
ciBlbmdhZ2VkIGFzIGVhcmx5IGFzDQo+Pj4+Pj4+IHBvc3NpYmxlIGluIHRoZSBjYWxsIHNldC11
cCBvciBmb3IgdGhlIGNhbGwgdG8gYmUgcm91dGVkIG9yIGhhbmRsZWQNCj4+Pj4+Pj4gc3BlY2lh
bGx5IChlLmcuLCByb3V0ZWQgdG8gYSByZXNvdXJjZSBhYmxlIHRvIHByb3ZpZGUgYSBuZWVkZWQN
Cj4+Pj4+Pj4gbGFuZ3VhZ2UNCj4+Pj4+Pj4gYW5kL29yIG1lZGlhKS4gQWx0ZXJuYXRpdmVzIHN1
Y2ggYXMgZG9pbmcgdGhlIG5lZ290aWF0aW9uIGluIFNJUCBoYXZlDQo+Pj4+Pj4+IGJlZW4gdGhv
cm91Z2hseSBleHBsb3JlZCBpbiB0aGUgcGFzdCBhbmQgYXJlIG91dCBvZiBzY29wZSAoYWx0aG91
Z2gNCj4+Pj4+Pj4gdGhlDQo+Pj4+Pj4+IHNjb3BlIG1pZ2h0IGJlIGV4dGVuZGVkIGFmdGVyIHRo
ZSBTRFAgbWVjaGFuaXNtIGhhcyBiZWVuIGFkdmFuY2VkKS4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IEJ5
IGFkZGluZyBsYW5ndWFnZSB0byB0aGUgZXhpc3RpbmcgbWVkaWEgbmVnb3RpYXRpb24gbWVjaGFu
aXNtIGFzDQo+Pj4+Pj4+IHVzZWQgaW4NCj4+Pj4+Pj4gUkZDIDY0NDMgYW5kIFJGQyA2ODgxLCB0
aGUgZ3JvdXAgY2FuIG1lZXQgdGhlIGJhc2ljIHVzZSBjYXNlcyB3aXRoDQo+Pj4+Pj4+IG1pbmlt
YWwgYWRkZWQgY29tcGxleGl0eSBhbmQgYmUgYWJsZSB0byBlbmhhbmNlIGxhdGVyIGZvciBhZGRp
dGlvbmFsDQo+Pj4+Pj4+IHVzZQ0KPj4+Pj4+PiBjYXNlcyBhcyBuZWVkZWQuDQo+Pj4+Pj4+IA0K
Pj4+Pj4+PiBNaWxlc3RvbmVzOg0KPj4+Pj4+PiBPY3QgMjAxNSAtIFN1Ym1pdCAiTXVsdGlwbGUg
TGFuZ3VhZ2UgQ29udGVudCBUeXBlIiB0byB0aGUgSUVTRyAoYmFzZWQNCj4+Pj4+Pj4gb24gZHJh
ZnQtdG9ta2luc29uLXNsaW0tbXVsdGlsYW5nY29udGVudCkNCj4+Pj4+Pj4gRmViIDIwMTYgLSBT
dWJtaXQgIk5lZ290aWF0aW5nIEh1bWFuIExhbmd1YWdlIGluIFJlYWwtVGltZQ0KPj4+Pj4+PiBD
b21tdW5pY2F0aW9ucyIgdG8gdGhlIElFU0cgKGJhc2VkIG9uDQo+Pj4+Pj4+IGRyYWZ0LWdlbGxl
bnMtc2xpbS1uZWdvdGlhdGluZy1odW1hbi1sYW5ndWFnZSkNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IA0K
Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K
Pj4+Pj4+PiBuZXctd29yayBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4gbmV3LXdvcmtAaWV0Zi5vcmcN
Cj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXctd29yaw0K
Pj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiAtLSANCj4+Pj4+IFJhbmRh
bGwgR2VsbGVucw0KPj4+Pj4gT3BpbmlvbnMgYXJlIHBlcnNvbmFsOyAgICBmYWN0cyBhcmUgc3Vz
cGVjdDsgICAgSSBzcGVhayBmb3IgbXlzZWxmIG9ubHkNCj4+Pj4+IC0tLS0tLS0tLS0tLS0tIFJh
bmRvbWx5IHNlbGVjdGVkIHRhZzogLS0tLS0tLS0tLS0tLS0tDQo+Pj4+PiBKdXN0IGJlY2F1c2Ug
eW91IGRvIG5vdCB0YWtlIGFuIGludGVyZXN0IGluIHBvbGl0aWNzIGRvZXNuJ3QgbWVhbg0KPj4+
Pj4gcG9saXRpY3Mgd29uJ3QgdGFrZSBhbmQgaW50ZXJlc3QgaW4geW91LiAgLS1QZXJpY2xlcyAo
NDk1LTQyNSBCQykNCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQo+PiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4+IEVjcml0QGlldGYub3JnDQo+PiBodHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo+IA0KPiAtLSANCj4gLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gR3VubmFyIEhlbGxzdHLD
tm0NCj4gT21uaXRvcg0KPiBndW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iuc2UNCj4gKzQ2IDcwOCAy
MDQgMjg4DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KPiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4gRWNyaXRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KDQo=


From nobody Tue Jul  7 10:42:28 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1467A1ACEE0; Tue,  7 Jul 2015 10:32:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.61
X-Spam-Level: 
X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 IxorGEcAkGPy; Tue,  7 Jul 2015 10:32:02 -0700 (PDT)
Received: from BLU004-OMC2S34.hotmail.com (blu004-omc2s34.hotmail.com [65.55.111.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7189D1ACEDB; Tue,  7 Jul 2015 10:32:01 -0700 (PDT)
Received: from BLU406-EAS330 ([65.55.111.71]) by BLU004-OMC2S34.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008);  Tue, 7 Jul 2015 10:32:00 -0700
X-TMN: [Gon0jczVh2eoeQ6UlOj63UqDF4QAC9cv]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
References: <20150626153605.18943.13946.idtracker@ietfa.amsl.com>      <559BE96D.2030502@omnitor.se>
From: Bernard Aboba 
MIME-Version: 1.0 (1.0)
In-Reply-To: <559BE96D.2030502@omnitor.se>
Date: Tue, 7 Jul 2015 10:31:55 -0700
To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= 
X-OriginalArrivalTime: 07 Jul 2015 17:32:00.0342 (UTC) FILETIME=[D4A09760:01D0B8DA]
Archived-At: 
X-Mailman-Approved-At: Tue, 07 Jul 2015 10:42:24 -0700
Cc: "slim@ietf.org" , "ecrit@ietf.org" , "iesg@ietf.org" , "Rosen, Brian" , Randall Gellens , ietf@ietf.org
Subject: Re: [Slim] [Ecrit] [new-work] WG Review: Selection of Language for Internet Media (slim)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Jul 2015 17:32:05 -0000

DQpPbiBKdWwgNywgMjAxNSwgYXQgODowMCBBTSwgR3VubmFyIEhlbGxzdHLDtm0gPGd1bm5hci5o
ZWxsc3Ryb21Ab21uaXRvci5zZT4gd3JvdGU6DQo+IA0KPiBJIGRlbGV0ZWQgaWV0ZiBhbmQgaWVz
ZyBmcm9tIHRoZSBhZGRyZXNzZXMgYW5kIGFkZGVkIHNsaW0uIEJ1dCB5b3UgYXJlIHJpZ2h0IHRo
YXQgdGhpcyBpcyBhIGdlbmVyYWwgc2lwIHRvcGljIGFzIHdlbGwuDQo+IEp1c3QgdGVsbCB3aGVy
ZSB3ZSBzaGFsbCBjb250aW51ZSB0aGUgZGlzY3Vzc2lvbi4NCg0KW0JBXSBTaW5jZSBtdWNoIG9m
IHRoZSByZXF1aXJlZCBkaXNjdXNzaW9uIHdpbGwgbmVlZCB0byBiZSBhYm91dCB0b3BpY3Mgc3Vj
aCBhcyByb3V0aW5nIGFuZCBub3QgbGFuZ3VhZ2UgcHJlZmVyZW5jZXMgaXQgc2VlbXMgdG8gbWUg
dGhhdCB0aGVyZSBpcyBhIG5lZWQgZm9yIGFub3RoZXIgdmVudWUgb3RoZXIgdGhhbiBTTElNLg0K
DQo+IEFib3V0IHdvcmsgaXRlbXM6IEkgdGhpbmsgc2xpbSBjYW4gY29udGludWUgdG8gY3JlYXRl
IGl0cyBwbGFubmVkIG1lZGlhIGFuZCBtb2RhbGl0eSBpbmRpY2F0aW9ucy4NCj4gQnV0IHdvcmsg
aXMgbmVlZGVkIG9uIHRoZSByb3V0aW5nIG1lY2hhbmlzbXMgdXNpbmcgU0xJTSBhbmQgb3RoZXIg
aW5kaWNhdGlvbnMgdG8gZGVjaWRlIG9uIGNvbm5lY3Rpb24gb2YgdXNlcnMgYW5kIG9wdGlvbmFs
bHkgYXNzaXN0aW5nIHNlcnZpY2VzIChzdWNoIGFzIHJlbGF5KS4NCg0KW0JBXSBJIGFncmVlLg0K
DQo+IEl0IGlzIGJldHRlciBpZiB0aGUgbWVjaGFuaXNtcyBhcmUgZ2VuZXJhbCwgYW5kIG5vdCBl
bWVyZ2VuY3kgc2VydmljZSBzcGVjaWZpYy4NCg0KW0JBXSBJIGFsc28gYWdyZWUgd2l0aCB0aGlz
IC0gd2hpY2ggaXMgd2h5IEkgYW0gY29uY2VybmVkIGFib3V0IGZvY3Vzc2luZyBzb2xlbHkgb24g
ZW1lcmdlbmN5IHNjZW5hcmlvcy4gVGhlIHNhbWUgaXNzdWUgYXJvc2Ugd2l0aCBsb2NhdGlvbiBy
b3V0aW5nIC0gU0lQIGNvbnZleWFuY2Ugd2FzIG5vdCBvbmx5IGFib3V0IGVtZXJnZW5jeSB1c2Vz
IGFsdGhvdWdoIHRoYXQgd2FzIGNlcnRhaW5seSBhIGtleSB1c2UgY2FzZS4NCg0KDQo+IEFub3Ro
ZXIgcmVhc29uIGlzIHRoYXQgbGFyZ2UgcGFydHMgb2YgdGhlIG1lY2hhbmlzbXMgd2lsbCBiZSB1
c2VkIGFuZCB2ZXJpZmllZCB0byB3b3JrLg0KDQpbQkFdIEluZGVlZCAtIGEgY2FsbCBjZW50ZXIg
dXNlIGNhc2UgaXMgcGxhdXNpYmxlIGFzIHdlbGwgLSBhbmQgbWlnaHQgYmUgbW9yZSBsaWtlbHkg
dG8gbW90aXZhdGUgYWRkaXRpb24gb2YgdGhlIHJlcXVpcmVkIHJvdXRpbmcgZnVuY3Rpb25hbGl0
eSB0byBjb21wb25lbnRzIHN1Y2ggYXMgU0lQIHByb3hpZXMuDQo+IA0KPiBUaGF0IG1lYW5zIHRo
YXQgd2UgZW5kIHVwIHdpdGggcmVjb21tZW5kYXRpb25zIHRvIGhhdmUgYnJpZGdlcyBpbiB2YXJp
b3VzIHBsYWNlcyB0byBiZSBhYmxlIHRvIGhhbmRsZSB0aGUgZGlmZmVyZW50IGNhbGwgc2NlbmFy
aW9zIG9wdGltYWxseS4gRG8geW91IGFncmVlPw0KDQpbQkFdIFllcywgSSBhZ3JlZSAtIGFuZCBp
dCBzZWVtcyBpbXBvcnRhbnQgdG8gZG9jdW1lbnQgdGhlc2UgcHJvYmxlbXMgYW5kIHBvdGVudGlh
bCBzb2x1dGlvbnMgc28gdGhhdCB0aGVzZSBwcm9ibGVtcyBkbyBub3Qgc2xpcCB0aHJvdWdoIHRo
ZSBjcmFja3MuIA0KDQoNCj4gcmVsYXkgc2VydmljZSB1c2VycyBvZiBzcGVlY2gtdG8tc3BlZWNo
IGFuZCBjYXB0aW9uZWQgdGVsZXBob255IHNlcnZpY2VzIGNhbm5vdCBkZXNjcmliZSB0aGVpciBu
ZWVkcyB3aXRoIHRoZSBjdXJyZW50IHByb3Bvc2VkIGNvZGluZyBvZiBzbGltLCBhbmQgd291bGQg
bGlrZWx5IGJlIGJldHRlciBvZmYgdG8gaGF2ZSBhIHBvc3NpYmlsaXR5IHRvIGp1c3QgcmVxdWVz
dCBhbiBhc3Npc3Rpbmcgc2VydmljZSBieSBhIFVSSSBhbmQgYSBzaXAgb3BlcmF0aW9uLg0KDQpb
QkFdIEluZGVlZC4gSWYgdGhlIElFVEYgaXMgZ29pbmcgdG8gdGFrZSBvbiB0aGVzZSBraW5kIG9m
IHByb2JsZW1zLCBpdCBuZWVkcyB0byB0YWtlIGFjdGlvbnMgdGhhdCB3aWxsIGNvbnRyaWJ1dGUg
dG8gc29sdmluZyB0aGVtIGluIHRoZWlyIGVudGlyZXR5LiBUaGF0IG1lYW5zIGNoYXJ0ZXJpbmcg
dGhlIHdvcmsgaW4gdGhlIHJpZ2h0IHBsYWNlcyB3aXRoIHRoZSByaWdodCBleHBlcnRpc2UuIFdo
aWxlIHRoZSBwcm9wb3NlZCBTTElNIFdHIENoYXJ0ZXIgZG9lcyBhZGRyZXNzIG9uZSBhc3BlY3Qg
b2YgdGhlIHByb2JsZW0sIGl0IGxlYXZlcyBtb3N0IG9mIGl0IHVucmVzb2x2ZWQgYW5kIHRoZSBw
cm9wb3NlZCBXRyBpcyBub3QgdGhlIHJpZ2h0IHZlbnVlIHRvIGNsb3NlIG9uIHRoZSByZW1haW5k
ZXIuDQoNCg0KPiANCj4gVGh1cyBzbGltIGlzIG9ubHkgcGFydCBvZiB0aGUgc29sdXRpb24uIEl0
IHdvdWxkIGJlIGdvb2QgdG8gaGF2ZSBzb21ld2hlcmUgdG8gZGlzY3VzcyB0aGUgd2hvbGUgcGlj
dHVyZSBhbmQgc2V0IHNsaW0gYW5kIHRoZSBvdGhlciBtZWNoYW5pc21zIGluIHRoZWlyIGNvbnRl
eHQuDQo+IFdoZXJlPw0KPiANCj4gR3VubmFyDQo+IA0KPiBSb3NlbiwgQnJpYW4gc2tyZXYgZGVu
IDIwMTUtMDctMDcgMTQ6NTE6DQo+PiBCdXQgdGhlIGRyYWZ0IGRvZXNu4oCZdCBzdWdnZXN0IHRo
YXQgdGhlIGRpcmVjdCBtb2RlbCBzaG91bGQgcmVwbGFjZSB0aGUNCj4+IGN1cnJlbnQgZW1lcmdl
bmN5IGNhbGwgcm91dGluZywgaXQgbWVyZWx5IGFsbG93cyBuZXcgY2FwYWJpbGl0eS4gIElmIHRo
ZXJlDQo+PiBpcyBhbnkgbGFuZ3VhZ2UgeW91IGZpbmQgdGhhdCBtYWtlcyBpdCBzZWVtIGxpa2Ug
ZGlyZWN0IHJvdXRpbmcgc2hvdWxkIGJlDQo+PiBwcmVmZXJyZWQgb3ZlciB0aGUgY3VycmVudCBs
b2NhdGlvbiBiYXNlZCByb3V0aW5nLCB3ZSBjYW4gYWRkcmVzcyB0aGF0Lg0KPj4gDQo+PiBPbiB5
b3VyIHNwZWNpZmljIHBvaW50IGFib3V0IG5vdCBiZWluZyBhYmxlIHRvIGRlYWwgd2l0aCBub24t
dmlkZW8NCj4+IGVxdWlwcGVkIFBTQVBzLCB3ZSBoYXZlIHBsZW50eSBvZiBtZWNoYW5pc21zIGF2
YWlsYWJsZSB0byByZWFkaWx5DQo+PiBhY2NvbW1vZGF0ZSB0aGF0IHNpdHVhdGlvbi4gIERldmlj
ZXMgYXJlIHJlcXVpcmVkIHRvIGZvbGxvdyBleGlzdGluZw0KPj4gcHJhY3RpY2Ugb2YgZm9yd2Fy
ZGluZyBjYWxscyB0byB0aGVpciBub3JtYWwgb3V0Ym91bmQgcHJveHksIGFuZCB0aGlzDQo+PiBk
cmFmdCBkb2VzbuKAmXQgY2hhbmdlIHRoYXQgYXQgYWxsLiAgV2hhdCBoYXBwZW5zIGFmdGVyIHRo
YXQgaXMgY29uZmluZWQgdG8NCj4+IHdoYXQgdGhlIHNlcnZpY2VzIHRoYXQgcHJvdmlkZSByb3V0
aW5nIGZvciBWUlMsIGFuZCB3ZSBjYW4gaGFuZGxlIGxvY2F0aW9uDQo+PiBzZW5zaXRpdmUgaGFu
ZGxpbmcgb2Ygc3VjaCBjYWxscy4gIEFsbCA5LTEtMSBjYWxscyBhcmUg4oCcZGlyZWN04oCdIHJv
dXRlZCwgaW4NCj4+IHRoYXQgdGhleSByb3V0ZSB0byB0aGUgb3V0Ym91bmQgcHJveHksIHdoaWNo
IHJvdXRlcyBiYXNlZCBvbiB0aGUgTG9TVA0KPj4gcXVlcnkgcmVzdWx0LCBhbmQgdGhhdCBpcyBu
b3QgbWVkaWEgc2Vuc2l0aXZlLiAgVGhhdCBkZWxpdmVycyB0aGUgY2FsbCB0bw0KPj4gdGhlIHJp
Z2h0IGluYm91bmQgcHJveHkgc2VydmVyLCB3aGljaCB0aGVuIGlzIGFibGUgdG8gcm91dGUgYmFz
ZWQgb24NCj4+IG1lZGlhLCBpZiBkZXNpcmVkLg0KPj4gDQo+PiBUaGUgd2F5IHdlIGhhbmRsZSBW
UlMsIGFuZCBzdGlsbCBnZXQgY2FsbHMgcm91dGVkIGJ5IHRoZSBsb2NhdGlvbiBvZiB0aGUNCj4+
IGNhbGxlciBpcyB0byBoYXZlIHRoZSBWUlMgc2VydmljZSByb3V0ZSB0aGUgY2FsbCBsaWtlIGFu
eSBvdGhlciA5LTEtMSBjYWxsDQo+PiB3b3VsZCBiZSByb3V0ZWQsIGJ1dCB0aGV5IGFkZCBhIGhl
YWRlciB0aGF0IGluZm9ybXMgdGhlIFBTQVAgdGhhdCBhIENBIGlzDQo+PiBhdmFpbGFibGUuICBU
aGUgUFNBUCB0aGVuIGNyZWF0ZXMgYSAzIHdheSB2aWRlby9hdWRpbyBjYWxsIGFtb25nIHRoZSBQ
U0FQLA0KPj4gdGhlIGNhbGxlciBhbmQgdGhlIENBLiAgSWYgdGhlIFBTQVAgd2lzaGVzIHRvIHVz
ZSBpdHMgb3duIENBLCBpdCBjYW4gZG8NCj4+IHNvLCBidXQgaXQgbmVlZHMgdG8ga25vdyB0aGlz
IGlzIGEgVlJTIGNhbGwuICBUaGUgUFNBUCBkb2VzbuKAmXQgbmVlZCB0bw0KPj4gaGFuZGxlIHZp
ZGVvLCBzaW5jZSBpZiBpdOKAmXMgbm90IHNlbmRpbmcvcmVjZWl2aW5nIHZpZGVvLCBpdOKAmXMg
YSAyIHdheQ0KPj4gdmlkZW8sIDMgd2F5IGF1ZGlvIGNhbGwsIGFuZCBldmVuIGl0cyBicmlkZ2Ug
ZG9lc27igJl0IHJlYWxseSBuZWVkIHRvIGJlIGluDQo+PiB0aGUgdmlkZW8gcGF0aC4NCj4+IA0K
Pj4gV2UgY2VydGFpbmx5IGNhbiBoYXZlIGVjcml0IHJldmlldyBkcmFmdHMgY29taW5nIG91dCBv
ZiB0aGlzIHdvcmsuICBORU5BDQo+PiBhbmQgRUVOQSB3aWxsIGFsc28gcmV2aWV3Lg0KPj4gDQo+
PiBJIGRvbuKAmXQgYmVsaWV2ZSB0aGVyZSBpcyBhIG5lZWQgdG8gaGF2ZSBhbiBlbnRpcmVseSBz
ZXBhcmF0ZSBkb2N1bWVudCB0bw0KPj4gaGFuZGxlIHRoZSBlbWVyZ2VuY3kgY2FsbCBmbG93cy4g
IFdlIGp1c3QgbmVlZCBhcHByb3ByaWF0ZSByZXZpZXcsIHdoaWNoDQo+PiBJ4oCZbSBzdXJlIHdl
IGNhbiBhcnJhbmdlLg0KPj4gDQo+PiBCcmlhbg0KPj4gDQo+Pj4gT24gNy82LzE1LCAxMTozMCBQ
TSwgIkJlcm5hcmQgQWJvYmEiIDxiZXJuYXJkX2Fib2JhQGhvdG1haWwuY29tPiB3cm90ZToNCj4+
PiANCj4+PiBJIGFncmVlIHRoYXQgdGhlICJkaXJlY3QiIG1vZGVsIGRlc2NyaWJlZCBpbiB0aGUg
ZHJhZnQgaXMgdmVyeQ0KPj4+IHByb2JsZW1hdGljLiAgT25lIG9mIHRoZSBndWlkaW5nIHByaW5j
aXBsZXMgb2YgYWNjZXNzaWJpbGl0eSBpcyB0aGF0DQo+Pj4gc2VydmljZXMgbmVlZCB0byBiZSBh
dmFpbGFibGUgYXMgd2lkZWx5IGFzIHBvc3NpYmxlIGdpdmVuIFBTQVANCj4+PiBjYXBhYmlsaXRp
ZXMuIEF0dGVtcHRpbmcgdG8gcm91dGUgVlJTIGVtZXJnZW5jeSBjYWxscyBkaXJlY3RseSB3aWxs
DQo+Pj4gYWN0dWFsbHkgZHJhbWF0aWNhbGx5IHJlZHVjZSB0aGUgYWJpbGl0eSBvZiBkaXNhYmxl
ZCB1c2VycyB0byByZWFjaA0KPj4+IGVtZXJnZW5jeSBzZXJ2aWNlcyBzaW5jZSB2aWRlbyBjb3Vs
ZCBub3QgYmUgYWNjZXB0ZWQgdW50aWwgdGhlIFBTQVAgaXMNCj4+PiBlcXVpcHBlZCB0byBoYW5k
bGUgaXQsIGV2ZW4gaWYgdGhlIGludGVycHJldGF0aW9uIHNlcnZpY2Ugd2VyZSBhYmxlIHRvIGRv
DQo+Pj4gc28sIGFuZCBhIGNhbGwgcm91dGVkIHZpYSB0aGUgaW50ZXJwcmV0aW5nIHNlcnZpY2Ug
Y291bGQgc3VjY2VlZCB3aXRoDQo+Pj4gZnVsbCBmdW5jdGlvbmFsaXR5Lg0KPj4+IA0KPj4+IFRo
ZXNlIGFyZSBleGFjdGx5IHRoZSBraW5kcyBvZiBpc3N1ZXMgdGhhdCB3b3VsZCBiZSBkZWJhdGVk
IGFuZCBhZGRyZXNzZWQNCj4+PiB3aXRoaW4gYSBXRyB3aXRoIGFwcHJvcHJpYXRlIFJBSSBmb2N1
cywgYnV0IHdoaWNoIGFyZSBsaWtlbHkgdG8gYmUNCj4+PiBuZWdsZWN0ZWQgaW4gYSBXRyB3aG9z
ZSBDaGFydGVyIGNvdmVycyBib3RoIGVtZXJnZW5jeSBzZXJ2aWNlDQo+Pj4gYWNjZXNzaWJpbGl0
eSBpc3N1ZXMgYW5kIGVtYWlsIGxhbmd1YWdlIHNlbGVjdGlvbi4NCj4+PiANCj4+PiBBdCBhIG1p
bmltdW0sIEkgd291bGQgbGlrZSB0byBzZWUgYW5vdGhlciB3b3JrIGl0ZW0gcmVsYXRpbmcgdG8g
dXNlIG9mDQo+Pj4gdGhlIHByb3Bvc2VkIGxhbmd1YWdlIHNwZWNpZmljYXRpb24sIGluY2x1ZGlu
ZyBjYWxsIGZsb3dzLCB3aXRoaW4gYSBncm91cA0KPj4+IHdpdGggZW1lcmdlbmN5IHNlcnZpY2Vz
IG9yIFNJUCBleHBlcnRpc2UgKHN1Y2ggYXMgRUNSSVQpLg0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+
IA0KPj4+IA0KPj4+PiBPbiBKdWwgNiwgMjAxNSwgYXQgNzoxMyBQTSwgUm9zZW4sIEJyaWFuIDxC
cmlhbi5Sb3NlbkBuZXVzdGFyLmJpej4NCj4+Pj4gd3JvdGU6DQo+Pj4+IA0KPj4+PiBXaGlsZSBJ
IHRoaW5rIHRoZSDigJxkaXJlY3QgbW9kZWzigJ0gaXMgYWN0dWFsbHkgdmVyeSBwcm9ibGVtYXRp
YywgSSB0aGluaw0KPj4+PiB0aGF0IGRyYWZ0IGlzIHF1aXRlIGFwcHJvcHJpYXRlIGZvciB0aGUg
YmFzaWMgcHVycG9zZSBvZiBtYWtpbmcgc3VyZSBhDQo+Pj4+IHRyYWluZWQgY2FsbCB0YWtlciBn
ZXRzIHRoZSBjYWxsLiAgQW5kLCBvZiBjb3Vyc2UsIGl04oCZcyBhbHNvIHZlcnkgdXNlZnVsDQo+
Pj4+IGZvciBnZW5lcmljIHJvdXRpbmcgb2YgY2FsbHMgZm9yIHdoaWNoIGEgVlJTIGFzIGEg4oCc
dHJhbnNjb2RlcuKAnSB3b3VsZCBiZQ0KPj4+PiBhDQo+Pj4+IG11Y2ggYmV0dGVyIHdheSB0byBt
YWtlIGEgZ2VuZXJpYyB2aWRlbyBjYWxsIGxvb2sgZGlmZmVyZW50bHkgZnJvbSBhIFZSUw0KPj4+
PiB2aWRlbyBjYWxsLCBhbmQgaW52b2tlIHByb3BlciB0cmVhdG1lbnQuDQo+Pj4+IA0KPj4+PiBJ
dOKAmXMgYWxzbyBhIGJldHRlciB3YXkgdG8gYW5ub3VuY2UgYSBWUlMgY2FsbCB0byB0aGUgY2Fs
bCB0YWtlci4gIFRvZGF5LA0KPj4+PiB3ZSBkb27igJl0IGtub3cgaXQgZnJvbSBhbnkgb3RoZXIg
M3JkIHBhcnR5IGluaXRpYXRlZCB2aWRlbyBjYWxsLg0KPj4+PiANCj4+Pj4gQXMgUmFuZHkgc2F5
cywgd2XigJl2ZSBkaXNjdXNzZWQgdGhlc2UgaXNzdWVzIHdpdGggdGhlIE5FTkEgQWNjZXNzaWJp
bGl0eQ0KPj4+PiBncm91cHMgYXMgd2VsbCBhcyB0aGUgRkNDIGFjY2Vzc2liaWxpdHkgY29tbWl0
dGVlIGZvbGtzLiAgV2XigJl2ZSBhbHNvDQo+Pj4+IGJlZW4NCj4+Pj4gZGlzY3Vzc2luZyB0aGUg
aXNzdWVzIHdpdGggUFNBUHMgd2hvIGhhdmUgc29tZSBtdWx0aS1saW5ndWFsIGNhbGwNCj4+Pj4g
dGFrZXJzLA0KPj4+PiBhbmQgd291bGQgdmVyeSBtdWNoIGFwcHJlY2lhdGUgYmVpbmcgYWJsZSB0
byByb3V0ZSB0byB0aGUgcmlnaHQgcXVldWUuDQo+Pj4+IEFuZCwgb2YgY291cnNlLCBpbXByb3Zp
bmcgaG93IFBTQVBzIGhhbmRsZSDigJxMYW5ndWFnZSBMaW5l4oCdIHNlcnZpY2VzIGlzDQo+Pj4+
IG9uZQ0KPj4+PiBvZiB0aGUgYmFzaWMgZ29hbHMgb2YgdGhpcyB3b3JrLiAgVGhlIGRpcmVjdCBt
b2RlbCB3b3VsZCBtYWtlIFZSUyBsb29rDQo+Pj4+IGV4YWN0bHkgbGlrZSBMYW5ndWFnZSBMaW5l
Lg0KPj4+PiANCj4+Pj4gQnJpYW4NCj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4+IA0K
Pj4+Pj4gT24gNy82LzE1LCA4OjM1IFBNLCAiUmFuZGFsbCBHZWxsZW5zIiA8cmFuZHlAcXRpLnF1
YWxjb21tLmNvbT4gd3JvdGU6DQo+Pj4+PiANCj4+Pj4+IEhpIEJlcm5hcmQsDQo+Pj4+PiANCj4+
Pj4+IEknZCBsaWtlIHRvIGRpc2N1c3MgeW91ciBjb25jZXJucyBhIGJpdC4gIEkndmUgYWRkZWQg
QnJpYW4gUm9zZW4gdG8NCj4+Pj4+IHRoZSBlbWFpbCBhcyBoZSBpcyBjaGFpciBvZiB0aGUgTkcg
KGkzKSBhcmNoaXRlY3R1cmUgZ3JvdXAgaW4gTkVOQS4NCj4+Pj4+IA0KPj4+Pj4gSSdtIHRyeWlu
ZyB0byB1bmRlcnN0YW5kIHdoeSB5b3UgYmVsaWV2ZSB0aGF0IHRoZSBjYWxsIGZsb3cgaW4gNC41
DQo+Pj4+PiB3b3VsZCByZXN1bHQgaW4gcmVqZWN0aW9uIG9mIHRoZSB2aWRlbyBzdHJlYW0sIHJh
dGhlciB0aGFuIHRoZSBQU0FQDQo+Pj4+PiBlbmdhZ2luZyBhbiBpbnRlcnByZXRhdGlvbiBzZXJ2
aWNlLiAgQXMgeW91IHNheSwgd2UgYXJlIHRyeWluZyB0bw0KPj4+Pj4gbW92ZSBmcm9tIHRvZGF5
J3MgbW9kZWwgaW4gd2hpY2ggdGhlIGNhbGxlciBmaXJzdCBjYWxscyB0aGUgcmVsYXkNCj4+Pj4+
IHNlcnZpY2UsIGFuZCB0aGVuIHRoZSByZWxheSBzZXJ2aWNlIGJyaWRnZXMgaW4gdGhlIFBTQVAs
IHRvIGEgZGlyZWN0DQo+Pj4+PiBtb2RlbCB3aGVyZSB0aGUgY2FsbGVyIGNhbGxzIDkxMSBkaXJl
Y3RseSwgYW5kIHRoZSBQU0FQIGJyaWRnZXMgaW4NCj4+Pj4+IHRoZSByZWxheSBzZXJ2aWNlLiAg
T2J2aW91c2x5LCB0aGVyZSBhcmUgZnVuZGluZyBpc3N1ZXMgdGhhdCB3b3VsZA0KPj4+Pj4gbmVl
ZCB0byBiZSBoYW5kbGVkIGluIG9yZGVyIGZvciBQU0FQcyB0byBiZSBhYmxlIHRvIGludm9rZSBy
ZWxheQ0KPj4+Pj4gc2VydmljZXMsIGJ1dCBib3RoIHRoZSBuZXh0LWdlbiBhbmQgYWNjZXNzaWJp
bGl0eSBncm91cHMgaW4gTkVOQSB3YW50DQo+Pj4+PiBhIGRpcmVjdCBtb2RlbCAod2hpY2ggb2Zm
ZXJzIG1hbnkgYWR2YW50YWdlcywgaW5jbHVkaW5nIHByaW9yaXR5DQo+Pj4+PiB0cmVhdG1lbnQg
YW5kIGxvY2F0aW9uIGRlbGl2ZXJ5KS4gIFRoZSBORU5BIFBvbGljeS1CYXNlZCBSb3V0aW5nDQo+
Pj4+PiAoUEJSKSBmdW5jdGlvbmFsaXR5IHdpdGhpbiBhbiBFU0luZXQgaGFzIHRoZSBhYmlsaXR5
IHRvIHVzZSB0aGUgU0RQDQo+Pj4+PiB3aGVuIG1ha2luZyByb3V0aW5nIGRlY2lzaW9ucyAoaW4g
Y2FzZSBQU0FQcyBoYXZlIGNvb3BlcmF0aW9uDQo+Pj4+PiBhZ3JlZW1lbnRzIHdoZXJlIHNvbWUg
UFNBUHMgaGFuZGxlIHNvbWUgdHlwZXMgb2YgY2FsbHMgb3Igc29tZQ0KPj4+Pj4gbGFuZ3VhZ2Vz
IG9yIG1lZGlhKS4NCj4+Pj4+IA0KPj4+Pj4gVGhlIGRyYWZ0IGFuZCB0aGUgaXNzdWVzIGhhdmUg
YmVlbiBkaXNjdXNzZWQgd2l0aCB0aGUgY28tY2hhaXJzIG9mDQo+Pj4+PiB0aGUgTkVOQSBhY2Nl
c3NpYmlsaXR5IFdHLCBhbmQgdGhleSBhcmUgc3Ryb25nbHkgaW4gZmF2b3Igb2YgYSBkaXJlY3QN
Cj4+Pj4+IG1vZGVsIGZvciBuZXh0LWdlbi4NCj4+Pj4+IA0KPj4+Pj4gSW4gdGhlIFUuUy4sIGVt
ZXJnZW5jeSBjYWxsIHJvdXRpbmcgaXMgZmlyc3QgYnkgbG9jYXRpb24sIGFuZCB0aGVuIGJ5DQo+
Pj4+PiBsb2NhbCBydWxlcyAoaWYgYW55KS4gIEZvciBleGFtcGxlLCBpZiBhIGNhbGwgcmVxdWly
ZXMgdGV4dCwgdGhlcmUNCj4+Pj4+IG1pZ2h0IGJlIHNvbWUgUFNBUHMgaW4gYSBjb29wZXJhdGlu
ZyBncm91cCB0aGF0IHRha2UgdGV4dCBjYWxscyBvbg0KPj4+Pj4gYmVoYWxmIG9mIG90aGVycy4g
IExpa2V3aXNlIGlmIHRoZSBjYWxsIHJlcXVlc3RzIGF1ZGlvIG9yIHRleHR1YWwNCj4+Pj4+IFNw
YW5pc2guICBJbiBFdXJvcGUsIHZhcmlvdXMgbW9kZWxzIGFyZSB1bmRlciBkaXNjdXNzaW9uLCBp
bmNsdWRpbmcNCj4+Pj4+IHNvbWUgaW4gd2hpY2ggYSBjYWxsIG1pZ2h0IGJlIHJvdXRlZCB0byBh
IFBTQVAgaW4gYSBjb3VudHJ5IHdoZXJlIHRoZQ0KPj4+Pj4gY2FsbGVyJ3MgbGFuZ3VhZ2UgaXMg
bmF0aXZlLiAgVGhlIGRyYWZ0IGFsbG93cyB0aGlzIGZsZXhpYmlsaXR5OiB0aGUNCj4+Pj4+IGNh
bGwgY2FuIGJlIHJvdXRlZCB0byBhIHNwZWNpZmljIFBTQVAgKGFuZCBldmVuIGNhbGwgdGFrZXIp
IG9yIHRoZQ0KPj4+Pj4gUFNBUCBjYW4gYnJpZGdlIGluIHRyYW5zbGF0aW9uIG9yIHJlbGF5IHNl
cnZpY2VzIGF0IHRoZSBzdGFydCBvZiB0aGUNCj4+Pj4+IGNhbGwuDQo+Pj4+PiANCj4+Pj4+IEF0
IDU6MTUgUE0gLTA3MDAgNy8xLzE1LCBCZXJuYXJkIEFib2JhIHdyb3RlOg0KPj4+Pj4gDQo+Pj4+
Pj4gSSBiZWxpZXZlIHRoYXQgdGhpcyBDaGFydGVyIGlzIHBvb3JseSBzdWl0ZWQgdG8gZGV2ZWxv
cGluZw0KPj4+Pj4+IHNvbHV0aW9ucyB0byB0aGUgcHJvYmxlbSBmYWNlZCBieSBkaXNhYmxlZCB1
c2VycyBvZiByZWFsdGltZQ0KPj4+Pj4+IGVtZXJnZW5jeSBzZXJ2aWNlcy4NCj4+Pj4+PiANCj4+
Pj4+PiBJbiB0aGUgY2FzZSBvZiBhY2Nlc3MgdG8gZW1lcmdlbmN5IHNlcnZpY2VzIGJ5IHRoZSBk
aXNhYmxlZCwgdGhlDQo+Pj4+Pj4gZ29hbCBpcyBub3QgInNlbGVjdGlvbiBvZiB0aGUgYmVzdC1m
aXQgbGFuZ3VhZ2UiLCBidXQgcmF0aGVyLA0KPj4+Pj4+IHJvdXRpbmcgb2YgdGhlIGNhbGwgYW5k
IG1lZGlhIHNvIGFzIHRvIHB1bGwgdG9nZXRoZXIgdGhlIHNlcnZpY2VzDQo+Pj4+Pj4gYmVzdCBm
aXR0aW5nIHRoZSBlbWVyZ2VuY3kgc2l0dWF0aW9uIGFuZCB0aGUgZGlzYWJpbGl0aWVzIG9mIHRo
ZQ0KPj4+Pj4+IGNhbGxlciwgYXMgd2VsbCBhcyB0aGUgY2FwYWJpbGl0aWVzIG9mIHRoZSBkZXZp
Y2UgYW5kDQo+Pj4+Pj4gaW50ZXJtZWRpYXJpZXMgd2hpY2ggbWF5IHNpdCBiZXR3ZWVuIHRoZSBj
YWxsZXIgYW5kIHRoZSBQU0FQLiAgTm90DQo+Pj4+Pj4gb25seSBhcmUgbWVkaWEgYW5kIGxhbmd1
YWdlIGludHJpbnNpY2FsbHkgbGlua2VkLCBidXQgYWxzbywgdGhlDQo+Pj4+Pj4gd2F5cyBpbiB3
aGljaCBjYWxscyBhcmUgcm91dGVkIGlzIGluZmx1ZW5jZWQgYW5kIGluIHNvbWUgY2FzZXMNCj4+
Pj4+PiBwcmVzY3JpYmVkIGJ5IHJlZ3VsYXRpb24gYW5kIG5hdGlvbmFsIHN0YW5kYXJkcy4NCj4+
Pj4+PiANCj4+Pj4+PiBTaW1wbHkgcHV0LCBkcmFmdC1nZWxsZW5zLXNsaW0tbmVnb3RpYXRpbmct
aHVtYW4tbGFuZ3VhZ2UgbGFja3MNCj4+Pj4+PiBhcHByb3ByaWF0ZSBjb25zaWRlcmF0aW9uIG9m
IHRoZSBwcm9ibGVtIGNvbnRleHQuICBTcGVjaWZ5aW5nIGl0IGFzDQo+Pj4+Pj4gdGhlIHN0YXJ0
aW5nIHBvaW50IGlzIHRoZXJlZm9yZSBpbmFwcHJvcHJpYXRlLiBBcyBhbiBleGFtcGxlLCB0b2Rh
eQ0KPj4+Pj4+IHRoZSBjYWxsIGZsb3cgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC41IHdvdWxkIG1v
c3QgbGlrZWx5IHJlc3VsdCBpbg0KPj4+Pj4+IHJlamVjdGlvbiBvZiB0aGUgdmlkZW8gcG9ydGlv
biBvZiB0aGUgY2FsbCBieSB0aGUgUFNBUCwgbGVhdmluZyB0aGUNCj4+Pj4+PiBkaXNwYXRjaGVy
IHdpdGggbm8gbWVhbnMgb2YgY29tbXVuaWNhdGluZyB3aXRoIHRoZSBoZWFyaW5nLWltcGFpcmVk
DQo+Pj4+Pj4gY2FsbGVyLCB0aHVzIGxlYXZpbmcgdGhlIGNhbGxlciB3b3JzZSBvZmYgdGhhbiB0
aGV5IGFyZSB0b2RheQ0KPj4+Pj4+IGF0dGVtcHRpbmcgdG8gbWFrZSBhbiBlbWVyZ2VuY3kgY2Fs
bCB3aXRoaW4gdGhlIChjdW1iZXJzb21lIGFuZA0KPj4+Pj4+IGVycm9yL2RlbGF5LXByb25lKSBW
aWRlbyBSZWxheSBTZXJ2aWNlLiAgIEEgZnVsbGVyIGNvbnNpZGVyYXRpb24gb2YNCj4+Pj4+PiB0
aGUgcHJvYmxlbSBjb250ZXh0IHdvdWxkIGludm9sdmUgY29uc2lkZXJhdGlvbiBvZiBjdXJyZW50
DQo+Pj4+Pj4gb3BlcmF0aW9uIG9mIHJlbGF5IHNlcnZpY2VzIGFuZCBwcm9wb3NhbHMgZm9yIHRo
ZWlyIGV2b2x1dGlvbi4NCj4+Pj4+PiBBdHRlbXB0aW5nIHRvIGRldmVsb3AgdGhpcyBwcm9ibGVt
IGNvbnRleHQgd2l0aGluIGEgV0cgdGhhdCBpcw0KPj4+Pj4+IGFsc28gYXR0ZW1wdGluZyB0byBk
ZWFsIHdpdGggbGFuZ3VhZ2Utc2VsZWN0aW9uIGluIGVtYWlsIHdvdWxkIGJlDQo+Pj4+Pj4gZnJ1
c3RyYXRpbmcgYXQgYmVzdC4NCj4+Pj4+PiANCj4+Pj4+PiBBIHNlbnNpYmxlIENoYXJ0ZXIgd291
bGQgYWxzbyBwcm9iYWJseSBpbmNsdWRlIGxpYWlzb25zIHdpdGgNCj4+Pj4+PiBkaXNhYmlsaXR5
IHJpZ2h0cyBvcmdhbml6YXRpb25zLCBncm91cHMgc3BlY2lmeWluZyB0aGUgb3BlcmF0aW9uIG9m
DQo+Pj4+Pj4gcmVsYXkgc2VydmljZXMsIGFuZCBncm91cHMgY29uc2lkZXJpbmcgbmV4dCBzdGVw
cyBmb3IgYWNjZXNzIHRvDQo+Pj4+Pj4gZW1lcmdlbmN5IHNlcnZpY2VzLg0KPj4+Pj4+IA0KPj4+
Pj4+PiBGcm9tOiBpZXNnQGlldGYub3JnDQo+Pj4+Pj4+IFRvOiBuZXctd29ya0BpZXRmLm9yZw0K
Pj4+Pj4+PiBEYXRlOiBGcmksIDI2IEp1biAyMDE1IDA4OjM2OjA1IC0wNzAwDQo+Pj4+Pj4+IFN1
YmplY3Q6IFtuZXctd29ya10gV0cgUmV2aWV3OiBTZWxlY3Rpb24gb2YgTGFuZ3VhZ2UgZm9yIElu
dGVybmV0DQo+Pj4+Pj4+IE1lZGlhIChzbGltKQ0KPj4+Pj4+PiANCj4+Pj4+Pj4gQSBuZXcgSUVU
RiB3b3JraW5nIGdyb3VwIGhhcyBiZWVuIHByb3Bvc2VkIGluIHRoZSBBcHBsaWNhdGlvbnMgYW5k
DQo+Pj4+Pj4+IFJlYWwtVGltZSBBcmVhLiBUaGUgSUVTRyBoYXMgbm90IG1hZGUgYW55IGRldGVy
bWluYXRpb24geWV0LiBUaGUNCj4+Pj4+Pj4gZm9sbG93aW5nIGRyYWZ0IGNoYXJ0ZXIgd2FzIHN1
Ym1pdHRlZCwgYW5kIGlzIHByb3ZpZGVkIGZvcg0KPj4+Pj4+PiBpbmZvcm1hdGlvbmFsDQo+Pj4+
Pj4+IHB1cnBvc2VzIG9ubHkuIFBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIElFU0cg
bWFpbGluZyBsaXN0DQo+Pj4+Pj4+IChpZXNnDQo+Pj4+Pj4+IGF0IGlldGYub3JnKSBieSAyMDE1
LTA3LTA2Lg0KPj4+Pj4+PiANCj4+Pj4+Pj4gU2VsZWN0aW9uIG9mIExhbmd1YWdlIGZvciBJbnRl
cm5ldCBNZWRpYSAoc2xpbSkNCj4+Pj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+Pj4+IEN1cnJlbnQgU3RhdHVzOiBQcm9wb3NlZCBXRw0K
Pj4+Pj4+PiANCj4+Pj4+Pj4gQXNzaWduZWQgQXJlYSBEaXJlY3RvcjoNCj4+Pj4+Pj4gQmFycnkg
TGVpYmEgPGJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnPg0KPj4+Pj4+PiANCj4+Pj4+Pj4gTWFpbGlu
ZyBsaXN0DQo+Pj4+Pj4+IEFkZHJlc3M6IHNsaW1AaWV0Zi5vcmcNCj4+Pj4+Pj4gVG8gU3Vic2Ny
aWJlOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NsaW0NCj4+Pj4+Pj4g
QXJjaGl2ZTogaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL2Jyb3dzZS9zbGltLw0K
Pj4+Pj4+PiANCj4+Pj4+Pj4gQ2hhcnRlcjoNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IERlc2NyaXB0aW9u
IG9mIFdvcmtpbmcgR3JvdXA6DQo+Pj4+Pj4+IA0KPj4+Pj4+PiBBIG11dHVhbGx5IGNvbXByZWhl
bnNpYmxlIGxhbmd1YWdlIGlzIGhlbHBmdWwgZm9yIGh1bWFuDQo+Pj4+Pj4+IGNvbW11bmljYXRp
b24uDQo+Pj4+Pj4+IFRoaXMgaXMgdHJ1ZSBhY3Jvc3MgYSByYW5nZSBvZiBjaXJjdW1zdGFuY2Vz
IGFuZCBlbnZpcm9ubWVudHMuIEluDQo+Pj4+Pj4+IGdlbmVyYWwsIHRoZSBwcm9ibGVtIGlzIG1v
c3QgYWN1dGUgaW4gc2l0dWF0aW9ucyB3aGVyZSB0aGVyZSBpcyBub3QgYQ0KPj4+Pj4+PiBjbGVh
ciBjaG9pY2UgZm9yIGEgc2luZ2xlIGxhbmd1YWdlLCBzdWNoIGFzIGVudmlyb25tZW50cyBsYWNr
aW5nDQo+Pj4+Pj4+IGNvbnRleHR1YWwgb3Igb3V0LW9mLWJhbmQgaW5mb3JtYXRpb24gcmVnYXJk
aW5nIHRoZSBpZGVudGl0eSBvZiB0aGUNCj4+Pj4+Pj4gcGFydGllcyBhbmQgdGhlIGxhbmd1YWdl
IHRvIGJlIHVzZWQuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBUaGUgZ3JvdXAgd2lsbCBhZGRyZXNzIHR3
byBzcGVjaWZpYyBjYXNlcyB0aGF0IG1vc3QgdXJnZW50bHkgbmVlZCBhDQo+Pj4+Pj4+IHRlY2hu
aWNhbCBzb2x1dGlvbjogT25lIHByb2JsZW0gc3BhY2UgaXMgbm9uLXJlYWwtdGltZSBjb21tdW5p
Y2F0aW9uLA0KPj4+Pj4+PiBzcGVjaWZpY2FsbHkgZW1haWwgZm9yIG9uZS10by1tYW55IG9yIHdo
ZXJlIHRoZSBzZXQgb2YgcmVjaXBpZW50cyBpcw0KPj4+Pj4+PiBkeW5hbWljIG9yIGRpZmZlcmVu
dCByZWNpcGllbnRzIHJlcXVpcmUgZGlmZmVyZW50IGxhbmd1YWdlczsgdGhlDQo+Pj4+Pj4+IG90
aGVyIGlzDQo+Pj4+Pj4+IHJlYWwtdGltZSBjb21tdW5pY2F0aW9uLCBzcGVjaWZpY2FsbHkgZW1l
cmdlbmN5IGNhbGxpbmcsIHByZWZlcmFibHkNCj4+Pj4+Pj4gYWxzbw0KPj4+Pj4+PiB1c2VmdWwg
Zm9yIG90aGVyIGNhc2VzIHdoZXJlIHRoZSBwYXJ0aWVzIG1heSBub3Qga25vdyBlYWNoIG90aGVy
DQo+Pj4+Pj4+IHBlcnNvbmFsbHkgb3Igd2hlcmUgb25lIHBhcnR5IHdpc2hlcyB0byBhY2NvbW1v
ZGF0ZSBwZW9wbGUgd2l0aA0KPj4+Pj4+PiB2YXJ5aW5nDQo+Pj4+Pj4+IGxhbmd1YWdlIGFuZCBt
ZWRpYSBuZWVkcy4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IEluIHRoZSByZWFsLXRpbWUgY29tbXVuaWNh
dGlvbiBjYXNlLCBsYW5ndWFnZSBhbmQgbWVkaWEgYXJlDQo+Pj4+Pj4+IGludHJpbnNpY2FsbHkN
Cj4+Pj4+Pj4gbGlua2VkLCBmb3IgZXhhbXBsZSwgc2lnbmVkIGxhbmd1YWdlcyByZXF1aXJlIGEg
dmlkZW8gbWVkaWEuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBXaGlsZSB0aGUgdHdvIHVzZSBjYXNlcyBh
cmUgaW4gZGlmZmVyZW50IGNvbnRleHRzIChyZWFsIHRpbWUgYW5kDQo+Pj4+Pj4+IG5vbi1yZWFs
LXRpbWUpLCB0aGUgZnVuZGFtZW50YWwgZ29hbCBpcyB0aGUgc2FtZTogdG8gZW5hYmxlIHNlbGVj
dGlvbg0KPj4+Pj4+PiBvZg0KPj4+Pj4+PiB0aGUgYmVzdC1maXQgbGFuZ3VhZ2UocykgZm9yIGEg
c3BlY2lmaWMgc2l0dWF0aW9uLiBTb21lIG9mIHRoZQ0KPj4+Pj4+PiBkZXRhaWxzDQo+Pj4+Pj4+
IHdpbGwgYWxzbyBiZSBpbiBjb21tb24gYWNyb3NzIHRoZSBjYXNlcywgZS5nLiwgdGhlIGxhbmd1
YWdlIHRhZ3MuDQo+Pj4+Pj4+IEhhdmluZw0KPj4+Pj4+PiBhIHNpbmdsZSBXRyBhZGRyZXNzIGJv
dGggY2FzZXMgbWFrZXMgaXQgY2xlYXIgdGhhdCB0aGVzZSBhcmUgdHdvDQo+Pj4+Pj4+IGFzcGVj
dHMNCj4+Pj4+Pj4gb2YgdGhlIHNhbWUgYmFzaWMgcHJvYmxlbS4gQSBzaW5nbGUgV0cgYWxzbyBt
YWtlcyBpdCBlYXNpZXIgdG8NCj4+Pj4+Pj4gbWF4aW1pemUNCj4+Pj4+Pj4gc2ltaWxhcml0aWVz
IGFuZCBhdm9pZCB1bm5lY2Vzc2FyeSBmcmFnbWVudGF0aW9uIG9mIHRoZSBzb2x1dGlvbnMsDQo+
Pj4+Pj4+IGFuZA0KPj4+Pj4+PiBmYWNpbGl0YXRlcyBicm9hZGVyIHJldmlldy4NCj4+Pj4+Pj4g
DQo+Pj4+Pj4+IFRoZSBncm91cCB3aWxsIHByb2R1Y2UgdHdvIGRvY3VtZW50cywgb25lIGZvciBl
bWFpbCwgYW5kIG9uZSBmb3INCj4+Pj4+Pj4gcmVhbC10aW1lIGNvbW11bmljYXRpb25zLg0KPj4+
Pj4+PiANCj4+Pj4+Pj4gSW4gdGhlIGVtYWlsIGNhc2UsIHRoZSBncm91cCB3aWxsIGRldGVybWlu
ZSBhIE1JTUUgYmFzZWQgc29sdXRpb24NCj4+Pj4+Pj4gdGhhdA0KPj4+Pj4+PiBlbmFibGVzIGEg
c2luZ2xlIGVtYWlsIG1lc3NhZ2UgdG8gY29udGFpbiBtdWx0aXBsZSBsYW5ndWFnZSB2ZXJzaW9u
cw0KPj4+Pj4+PiBvZg0KPj4+Pj4+PiB0aGUgY29udGVudCwgd2l0aCBwcm92aXNpb25zIHRvIGhl
bHAgY2xpZW50cyBzZWxlY3QgYSBiZXN0IGZpdA0KPj4+Pj4+PiB2ZXJzaW9uLg0KPj4+Pj4+PiAN
Cj4+Pj4+Pj4gSW4gdGhlIHJlYWwtdGltZSBjb21tdW5pY2F0aW9uIGNhc2UsIHRoZSBncm91cCB3
aWxsIHByb2R1Y2UgYQ0KPj4+Pj4+PiBzcGVjaWZpY2F0aW9uIGJhc2VkIG9uIGRyYWZ0LWdlbGxl
bnMtc2xpbS1uZWdvdGlhdGluZy1odW1hbi1sYW5ndWFnZSwNCj4+Pj4+Pj4gZW5hYmxpbmcgbmVn
b3RpYXRpb24gb2YgYSBodW1hbiBsYW5ndWFnZSBwZXIgbWVkaWEgc3RyZWFtLiBUaGUNCj4+Pj4+
Pj4gc3BlY2lmaWNhdGlvbiBtdXN0IGJlIHN1aXRhYmxlIGZvciB1c2UgaW4gZW1lcmdlbmN5IGNv
bW11bmljYXRpb25zIGFzDQo+Pj4+Pj4+IHNwZWNpZmllZCBpbiBSRkMgNjQ0MyBhbmQgUkZDIDY4
ODEgKHdoaWNoIHVzZSBTSVAgYW5kIFNEUCB0bw0KPj4+Pj4+PiBuZWdvdGlhdGUNCj4+Pj4+Pj4g
bWVkaWEpOyBpdCBpcyBkZXNpcmFibGUgdG8gYWxzbyBiZSBzdWl0YWJsZSBmb3IgdXNlIGluIG5v
bi1lbWVyZ2VuY3kNCj4+Pj4+Pj4gcmVhbC10aW1lIGNvbW11bmljYXRpb25zIHRoYXQgc2hhcmUg
dGhlIHNhbWUgY2FsbCBzZXQtdXAgYW5kIG1lZGlhDQo+Pj4+Pj4+IG5lZ290aWF0aW9uIHByb3Rv
Y29scy4gVGhlIG1lY2hhbmlzbSB3aWxsIHBlcm1pdCB0aGUgY2FsbGVyJ3MgbWVkaWENCj4+Pj4+
Pj4gYW5kDQo+Pj4+Pj4+IGxhbmd1YWdlIG5lZWRzIGFuZCBwcmVmZXJlbmNlcyB0byBiZSBtYXRj
aGVkIGFnYWluc3Qgd2hhdCB0aGUgY2FsbGVkDQo+Pj4+Pj4+IHBhcnR5IGlzIGFibGUgdG8gcHJv
dmlkZS4gVGhlIG1lY2hhbmlzbSB3aWxsIHBlcm1pdCByZXNvdXJjZXMgKGUuZy4sDQo+Pj4+Pj4+
IHRyYW5zbGF0aW9uLCByZWxheSwgbWVkaWEpIHRvIGJlIGFsbG9jYXRlZCBvciBlbmdhZ2VkIGFz
IGVhcmx5IGFzDQo+Pj4+Pj4+IHBvc3NpYmxlIGluIHRoZSBjYWxsIHNldC11cCBvciBmb3IgdGhl
IGNhbGwgdG8gYmUgcm91dGVkIG9yIGhhbmRsZWQNCj4+Pj4+Pj4gc3BlY2lhbGx5IChlLmcuLCBy
b3V0ZWQgdG8gYSByZXNvdXJjZSBhYmxlIHRvIHByb3ZpZGUgYSBuZWVkZWQNCj4+Pj4+Pj4gbGFu
Z3VhZ2UNCj4+Pj4+Pj4gYW5kL29yIG1lZGlhKS4gQWx0ZXJuYXRpdmVzIHN1Y2ggYXMgZG9pbmcg
dGhlIG5lZ290aWF0aW9uIGluIFNJUCBoYXZlDQo+Pj4+Pj4+IGJlZW4gdGhvcm91Z2hseSBleHBs
b3JlZCBpbiB0aGUgcGFzdCBhbmQgYXJlIG91dCBvZiBzY29wZSAoYWx0aG91Z2gNCj4+Pj4+Pj4g
dGhlDQo+Pj4+Pj4+IHNjb3BlIG1pZ2h0IGJlIGV4dGVuZGVkIGFmdGVyIHRoZSBTRFAgbWVjaGFu
aXNtIGhhcyBiZWVuIGFkdmFuY2VkKS4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IEJ5IGFkZGluZyBsYW5n
dWFnZSB0byB0aGUgZXhpc3RpbmcgbWVkaWEgbmVnb3RpYXRpb24gbWVjaGFuaXNtIGFzDQo+Pj4+
Pj4+IHVzZWQgaW4NCj4+Pj4+Pj4gUkZDIDY0NDMgYW5kIFJGQyA2ODgxLCB0aGUgZ3JvdXAgY2Fu
IG1lZXQgdGhlIGJhc2ljIHVzZSBjYXNlcyB3aXRoDQo+Pj4+Pj4+IG1pbmltYWwgYWRkZWQgY29t
cGxleGl0eSBhbmQgYmUgYWJsZSB0byBlbmhhbmNlIGxhdGVyIGZvciBhZGRpdGlvbmFsDQo+Pj4+
Pj4+IHVzZQ0KPj4+Pj4+PiBjYXNlcyBhcyBuZWVkZWQuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBNaWxl
c3RvbmVzOg0KPj4+Pj4+PiBPY3QgMjAxNSAtIFN1Ym1pdCAiTXVsdGlwbGUgTGFuZ3VhZ2UgQ29u
dGVudCBUeXBlIiB0byB0aGUgSUVTRyAoYmFzZWQNCj4+Pj4+Pj4gb24gZHJhZnQtdG9ta2luc29u
LXNsaW0tbXVsdGlsYW5nY29udGVudCkNCj4+Pj4+Pj4gRmViIDIwMTYgLSBTdWJtaXQgIk5lZ290
aWF0aW5nIEh1bWFuIExhbmd1YWdlIGluIFJlYWwtVGltZQ0KPj4+Pj4+PiBDb21tdW5pY2F0aW9u
cyIgdG8gdGhlIElFU0cgKGJhc2VkIG9uDQo+Pj4+Pj4+IGRyYWZ0LWdlbGxlbnMtc2xpbS1uZWdv
dGlhdGluZy1odW1hbi1sYW5ndWFnZSkNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+PiBuZXct
d29yayBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4gbmV3LXdvcmtAaWV0Zi5vcmcNCj4+Pj4+Pj4gaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXctd29yaw0KPj4+Pj4gDQo+Pj4+
PiANCj4+Pj4+IC0tIA0KPj4+Pj4gUmFuZGFsbCBHZWxsZW5zDQo+Pj4+PiBPcGluaW9ucyBhcmUg
cGVyc29uYWw7ICAgIGZhY3RzIGFyZSBzdXNwZWN0OyAgICBJIHNwZWFrIGZvciBteXNlbGYgb25s
eQ0KPj4+Pj4gLS0tLS0tLS0tLS0tLS0gUmFuZG9tbHkgc2VsZWN0ZWQgdGFnOiAtLS0tLS0tLS0t
LS0tLS0NCj4+Pj4+IEp1c3QgYmVjYXVzZSB5b3UgZG8gbm90IHRha2UgYW4gaW50ZXJlc3QgaW4g
cG9saXRpY3MgZG9lc24ndCBtZWFuDQo+Pj4+PiBwb2xpdGljcyB3b24ndCB0YWtlIGFuZCBpbnRl
cmVzdCBpbiB5b3UuICAtLVBlcmljbGVzICg0OTUtNDI1IEJDKQ0KPj4gX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IEVjcml0IG1haWxpbmcgbGlzdA0K
Pj4gRWNyaXRAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vZWNyaXQNCj4gDQo+IC0tIA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLQ0KPiBHdW5uYXIgSGVsbHN0csO2bQ0KPiBPbW5pdG9yDQo+IGd1bm5hci5oZWxsc3Ry
b21Ab21uaXRvci5zZQ0KPiArNDYgNzA4IDIwNCAyODgNCj4gDQo=


From nobody Tue Jul  7 10:56:44 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 636041ACF19 for ; Tue,  7 Jul 2015 10:56:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.011
X-Spam-Level: 
X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 ZI3sLCO1-K6E for ; Tue,  7 Jul 2015 10:56:39 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96E3D1ACF18 for ; Tue,  7 Jul 2015 10:56:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1436291800; x=1467827800; h=message-id:in-reply-to:references:date:to:from:subject: mime-version:content-transfer-encoding; bh=fMYp4kQD6vWzOMh2XFeIJC03oe8zAUIzCP/FgjM1XgA=; b=LFJlVyPQv+kaNz7EcB1wbB0g/wbPJpsy5EQH497jdHlr3kepOX7ILPyE DSKByctPTY2rIwJZBLDlVd6rHJqIkCkb1RGqsvS38k7Vokvi5fYIJi1MM svzotvQRl5CKbMf43lQsmeUXVJ6fqsGTULholWriOzeNe+vORG9XnAJN+ c=;
X-IronPort-AV: E=McAfee;i="5700,7163,7855"; a="219285448"
Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Jul 2015 10:56:39 -0700
X-IronPort-AV: E=Sophos;i="5.15,425,1432623600"; d="scan'208";a="955692595"
Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 07 Jul 2015 10:56:38 -0700
Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 7 Jul 2015 10:56:37 -0700
Message-ID: 
In-Reply-To: 
References:  <20150703064908.GA14666@sources.org> <55964BED.1080905@omnitor.se>   <5598D34A.6070001@omnitor.se> <55995958.5050109@alum.mit.edu> <55999526.7030006@omnitor.se> <559A2D44.1010308@omnitor.se> 
X-Mailer: Eudora for Mac OS X
Date: Tue, 7 Jul 2015 10:56:35 -0700
To: Eric Burger , 
From: Randall Gellens 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Originating-IP: [10.80.80.8]
X-ClientProxiedBy: NASANEXM01C.na.qualcomm.com (10.85.0.83) To nasanexm02f.na.qualcomm.com (10.85.0.87)
Archived-At: 
Subject: Re: [Slim] Translation Quality or type - or service provider
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Jul 2015 17:56:43 -0000

At 4:43 AM -0400 7/6/15, Eric Burger wrote:

>   > On Jul 6, 2015, at 3:24 AM, Gunnar Hellstr=F6m=20
>  wrote:
>>
>>  One reason for the need to convey a=20
>> translation service provider URI is that the=20
>> emergency service RFCs 6443 and 6881 forbids=20
>> the calling user to invoke three-party calling.

The text there is saying that the best practice=20
for a device initiating an emergency call is to=20
disable services that could interrupt the call,=20
such as call waiting and third-party calling.  If=20
the third-party call is initiated before or in=20
parallel with the emergency call, the text=20
wouldn't apply anyway, and if the third-party=20
call is initiated during the emergency call in=20
order to better serve the user's needs, then this=20
is exactly why the text uses "SHOULD" instead of=20
"MUST."  The word "SHOULD" means that a client is=20
supposed to follow the direction unless there is=20
an overriding reason not to, and the consequences=20
of doing so are understood.  Both of those apply=20
in the case under discussion.


>
>  6443 is informational and 6881 is a BCP. No=20
> problem to do something that works that is=20
> 'forbidden.'
>
>>  For example RFC 6443, chapter 13 says=20
>> "Services such as call waiting, call transfer,=20
>> three-way calling, and hold should be=20
>> disabled."
>
>  Note the use of 'should.'  I do not think=20
> anyone will complain if one interprets this as,=20
> "Should be disabled, unless the user will die=20
> if she does not setup a three-way call with her=20
> translation service."
>
>>  If then the user is in a foreign language=20
>> environment where the PSAP barely can have a=20
>> clue on how to find the right relay service,=20
>> and the user has a good relay service URI=20
>> configured, well capable of handling the=20
>> user's language and modality, what is then=20
>> best?
>>
>>  1) Break against RFC 6881 and 6443 and have=20
>> the user terminal invoke the three-party call?=20
>> The wording in these RFCs may be interpreted=20
>> to have some room for such deviations.
>
>  Beyond the wording in the RFCs, there is a=20
> reason the IETF is not the protocol police. In=20
> retrospect, it may be safe to say the RFCs'=20
> suggestions are wrong.
>
>>  2) Or convey the relay service URI to the PSAP for invocation.
>
>  Why not?
>
>>
>>  The discussion so far leads towards conclusion=20
>> 1. It is ok for me, I just wanted it confirmed=20
>> by showing the whole situation.
>>
>>  (there will always be complementing slow=20
>> manual procedures, when the PSAP needs to=20
>> figure out a reasonable way to handle the=20
>> call, but this discussion is for the rapid=20
>> automated way that should handle most cases.)
>>
>>  /Gunnar
>>
>>  Gunnar Hellstr=F6m skrev den 2015-07-05 22:35:
>>>  Paul,
>>>  Yes, I agree that for most cases it is best=20
>>> that the party, who knows a service that will=20
>>> do the translation, does the invocation.
>>>
>>>  And, yes ,in that scenario the 3PCC method seems suitable.
>>>
>>>  My proposal to send the service provider URI=20
>>> together with the modality indications was=20
>>> for the case when there are strong policy=20
>>> reasons why one party would do the=20
>>> invocation, but little chance that that party=20
>>> would have access to an up-to-date=20
>>> information on available translation=20
>>> providers.
>>>  That could be the case for the emergency=20
>>> service calling in a multi-language=20
>>> environment, also including support for sign=20
>>> language users.
>>>
>>>  Since both you and Randall think it is not=20
>>> doable, we can try to use the principle that=20
>>> the party, who knows a service that will do=20
>>> the translation, does the invocation.
>   >>
>>>  That brings us back to a need for more=20
>>> stringent language/modality negotiation in=20
>>> order to avoid both double invocation of=20
>>> services when one or none is required, and=20
>>> also avoid no invocation when one is needed.
>>>
>>>  Paul Kyzivat skrev den 2015-07-05 18:20:
>>>>  Gunnar,
>>>>
>>>>  I understand what you are suggesting, but I=20
>>>> don't believe it is workable. This seems to=20
>>>> mean that the caller would select the=20
>>>> service while the callee would engage the=20
>>>> service in the call if needed. Yet it is=20
>>>> likely to be the caller who has a business=20
>>>> relationship with the service, while the=20
>>>> callee does not. Gets complicated quickly.
>   >>>
>>>>  ISTM it makes more sense to first figure out=20
>>>> what is/isn't possible without translation,=20
>>>> and then for a party that finds a=20
>>>> translation service beneficial to engage=20
>>>> one. Then the only concern is that both=20
>>>> parties don't independently try to introduce=20
>>>> equivalent translation services.
>>>>
>>>>  For instance, a deaf caller might offer=20
>>>> video media marked for sign language, and=20
>>>> audio media on hold. If the answer doesn't=20
>>>> accept the video, or doesn't indicate=20
>>>> support for sign language, the caller could=20
>>>> then conference in translation service,=20
>>>> using the 3pcc transcoding model specified=20
>>>> in rfc5369. (If that will take time, the=20
>>>> deaf caller's UA could stream recorded media=20
>>>> over the audio channel in the meantime.)
>>>>
>>>>  Or, to get fancier, it would be possible to=20
>>>> use preconditions to defer alerting the=20
>>>> callee until this is all sorted out.
>>>>
>>>>  My point is to let the participant who wants=20
>>>> translation handle to setup of translation=20
>>>> rather than depending on the other party to=20
>>>> do something.
>>>  OK, it might be likely that both parties=20
>>> "want" translation, but one has better=20
>>> knowledge about how to get the required=20
>>> service and has business relations with the=20
>>> service. So then it is preferred that that=20
>>> party invokes.
>>>
>>>  Good
>>>  /Gunnar
>>>>
>>>>     Thanks,
>>>>     Paul
>>>>
>>>>  On 7/5/15 2:48 AM, Gunnar Hellstr=F6m wrote:
>>>>>  Another opportunity would be to convey a URI to the service provider =
who
>>>>>  did (for mail) or can do(for real-time) the translation.
>>>>>  Then experience with different service provider's production could gi=
ve
>>>>>  some idea of the expected quality.
>>>>>  I can see great value in that for the real-time case, when the callin=
g
>>>>>  user has a favourite translator (e.g. relay service), and provides th=
at
>>>>>  as a hint if languages or modalities in the call does not match. Then
>>>>>  the callee do not need to just take a service provider by chance that
>>>>>  seem to match the language/modality profile but can take the one
>>>>>  proposed by the caller.
>>>>>
>>>>>  After working with the needs for emergency services to work across
>>>>>  Europe for some time now, I think this is one of the few workable
>>>>>  solutions. The user expresses both the language/modality needs and
>>>>>  provides a URI to a favourite translation service provider, and the
>>>>>  callee tries to fulfill the language/modality needs either by a match=
ing
>>>>>  original call taker or by invoking the proposed translation provider.
>>>>>
>>>>>  /Gunnar
>>>>>
>>>>>
>>>>>  Randall Gellens skrev den 2015-07-05 03:49:
>>>>>>  My recollection is that this was discussed in email prior to Dallas,
>>>>>>  but that's not important.
>>>>>>
>>>>>>  I am a strong proponent of keeping things as simple as possible,
>>>>>>  provided there is a way to extend them if experience shows that it i=
s
>>>>>>  needed.  So, I think we should stick with the original suggestion of
>>>>>>  three values ("original", "human", "automated"). This is simple enou=
gh
>>>>>>  to be implementable and functional enough to be useful in providing =
a
>>>>>>  hint that may help the client choose the best version for the user. =
If
>>>>>>  we try and capture the various nuances of quality we will end up wit=
h
>>>>>>  a very complex mechanism that is unlikely to be any more useful in
>>>>>>  real life. Let's go with the simple approach now.  If, after some
>>>>>>  deployment experience we realize that we really do need extra
>>>>>>  complexity, we can extend the mechanism then.
>>>>>>
>>>>>>  At 4:29 PM +0100 7/3/15, Nik Tomkinson wrote:
>   >>>>>
>>>>>>>  Thanks for the responses.
>>>>>>>
>>>>>>>  To deal with the issue with having only original/human/automated,
>>>>>>>  what about the following?:
>>>>>>>
>>>>>>>
>>>>>>>  translation-type :=3D type-token[ ";" "q" "=3D" qvalue ]
>>>>>>>  type-token :=3D"human" / "automated"
>>>>>>>
>>>>>>>  where qvalue is a value between 0 and 1 with a default of 0.5 if
>>>>>>>  missing
>>>>>>>
>>>>>>>  for example:
>>>>>>>
>>>>>>>  Translation-Type: human;q=3D0.8
>>>>>>>  Translation-Type: automated;q=3D0.4
>>>>>>>  Translation-Type: human
>>>>>>>
>>>>>>>  The Translation-Type SHOULD NOT appear in the original
>>>>>>>  (untranslated) part but it SHOULD appear in translated content.
>   >>>>>>
>>>>>>>  Having this missing from the original text helps identify which is
>>>>>>>  the source to be translated into further languages if the user mail
>>>>>>>  client allows.
>>>>>>>
>>>>>>>  This enables us to dispose of the 'original' value which didn't len=
d
>>>>>>>  itself well to being graded on quality.
>>>>>>>
>>>>>>>  The qvalue can be set by the sender or provided by the translation
>>>>>>>  service.
>>>>>>>
>>>>>>>  The draft suggests that:
>>>>>>>
>>>>>>>  "Additionally, interactive implementations MAY offer the user a
>>>>>>>  choice from among the available languages." so the qvalue may not
>>>>>>>  need to be bulletproof.
>>>>>>>
>>>>>>>  Comments?
>>>>>>>
>>>>>>>  Nik.
>>>>>>>
>>>>>>>  On 3 July 2015 at 09:46, Gunnar Hellstr=F6m
>>>>>>>=20
>>>>>>> <gunnar.hellstrom@omnitor.se>=20
>>>>>>> wrote:
>>>>>>>
>>>>>>>  I see some value of this kind of parameter also for the real-time c=
ase.
>>>>>>>  The time is here when it can be possible in some situations to
>>>>>>>  select between using a low-cost automatic speech-to-text generation
>>>>>>>  and a higher cost captioned telephony or text-relay service (higher
>>>>>>>  cost for someone, not always the end-user).
>>>>>>>
>>>>>>>  But I agree that it is very hard to set good understandable values
>>>>>>>  on a parameter expressing the type or quality of this kind of servi=
ce.
>>>>>>>
>>>>>>>  Gunnar
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>  Stephane Bortzmeyer skrev den 2015-07-03 08:49:
>>>>>>>
>>>>>>>  On Thu, Jul 02, 2015 at 11:09:30PM +0100,
>>>>>>>    Nik Tomkinson
>>>>>>>  <rfc.nik.tomkinson@gmail.com> w=
rote
>>>>>>>    a message of 109 lines which said:
>>>>>>>
>>>>>>>  type-token :=3D "original" / "human" / "automated"
>>>>>>>
>>>>>>>  In many IETF working groups, when there is such a proposal, there=
 is a
>>>>>>>  big discussion between the registryfull and the registryless
>>>>>>>  people. The first ones say there must be an authoritative list of
>>>>>>>  values (in the RFC or, better because more evolving, in an IANA
>>>>>>>  registry) so we can be sure of the interpretation of values. The
>>>>>>>  second ones say we can never capture all the nuances and subtleties=
 of
>>>>>>>  the world in a fixed list.
>>>>>>>
>>>>>>>  Here, I am not sure that the only meaningful distinction is between
>>>>>>>  "human" and "automated". Some humans do a very poor job, too. One
>>>>>>>  could suggest:
>>>>>>>
>>>>>>>  type-token :=3D "original" / "professional-human" / "amateur-human"=
 /
>>>>>>>  "automated-first-generation" / "automated-artificial-intelligence" =
/
>>>>>>>  "automated-the-robot-in-hollywood-movies"
>>>>>>>
>>>>>>>  Or decide that it will be too complicated and we should instead
>>>>>>>  accept:
>>>>>>>
>>>>>>>  type-token :=3D "original" / 
>>>>>>>
>>>>>>>  Toughts?
>>>>>>>
>>>>>>>  _______________________________________________
>>>>>>>  SLIM mailing list
>>>>>>>  SLIM@ietf.org
>>>>>>>
>>>>>>>=20
>>>>>>> https://www.ietf.org/mai=
lman/listinfo/slim
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>  _______________________________________________
>>>>>>>  SLIM mailing list
>>>>>>>  SLIM@ietf.org
>>>>>>>
>>>>>>>=20
>>>>>>> https://www.ietf.org/mai=
lman/listinfo/slim
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>  --
>>>>>>>
>>>>>>>  -----------------------------------------------------------------
>>>>>>>  Multiple Language Content Type Internet Draft:
>>>>>>>
>>>>>>>=20
>>>>>>> h=
ttp://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/
>   >>>>>>
>>>>>>>  -----------------------------------------------------------------
>>>>>>>
>>>>>>>  _______________________________________________
>>>>>>>  SLIM mailing list
>>>>>>>  SLIM@ietf.org
>>>>>>>  https://www.ietf.org/mailman/listinfo/slim
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>  _______________________________________________
>>>>  SLIM mailing list
>>>>  SLIM@ietf.org
>>>>  https://www.ietf.org/mailman/listinfo/slim
>>>
>>
>>  --
>>  -----------------------------------------
>>  Gunnar Hellstr=F6m
>>  Omnitor
>>  gunnar.hellstrom@omnitor.se
>>  +46 708 204 288
>>
>>  _______________________________________________
>   > SLIM mailing list
>>  SLIM@ietf.org
>>  https://www.ietf.org/mailman/listinfo/slim
>
>
>  Content-Transfer-Encoding: 7bit
>  Content-Disposition: attachment; filename=3D"signature.asc"
>  Content-Type: application/pgp-signature;
>  	name=3Dsignature.asc
>  Content-Description: Message signed with OpenPGP using GPGMail
>
>  Attachment converted: TiLand:signature 415.asc (    /    ) (028C4061)
>  _______________________________________________
>  SLIM mailing list
>  SLIM@ietf.org
>  https://www.ietf.org/mailman/listinfo/slim



-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Progress is made on alternate Fridays.


From nobody Tue Jul  7 10:58:30 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 938F91ACF24 for ; Tue,  7 Jul 2015 10:58:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.011
X-Spam-Level: 
X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 mLdl9UEYnpNo for ; Tue,  7 Jul 2015 10:58:25 -0700 (PDT)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A31121ACF54 for ; Tue,  7 Jul 2015 10:58:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1436291905; x=1467827905; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=2gaNuX2YT0KkXJu0oB0M0nY25tEXdmq3rB/Cwobj0NM=; b=t2Se7xYt9PPihH1drbR3r+6YVw6O3oEVJFXM1W9/Odnlk73z24IrRTVE 1bwyV/nvo0j/dpazqNqXtxdVPAhOISbN69rvNUjDuADBse0WA4zX/lm/J UG31yFPNdIp62S5Brha4U4uQEwRYvFeKv+d2FnS8Y/5uVuHXd03VCLTQI E=;
X-IronPort-AV: E=McAfee;i="5700,7163,7855"; a="93263924"
Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Jul 2015 10:58:15 -0700
X-IronPort-AV: E=Sophos;i="5.15,424,1432623600"; d="scan'208";a="1008668843"
Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 07 Jul 2015 10:58:15 -0700
Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 7 Jul 2015 10:58:14 -0700
Message-ID: 
In-Reply-To: 
References:  <20150703064908.GA14666@sources.org> <55964BED.1080905@omnitor.se> <5596B184.2020908@alum.mit.edu> <0A0D0CE1-01AC-411B-86B6-176A92C223A8@standardstrack.com>  <5599A9FE.60401@alum.mit.edu> 
X-Mailer: Eudora for Mac OS X
Date: Tue, 7 Jul 2015 10:58:10 -0700
To: Henning Schulzrinne , Paul Kyzivat 
From: Randall Gellens 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Originating-IP: [10.80.80.8]
X-ClientProxiedBy: NASANEXM01B.na.qualcomm.com (10.85.0.82) To nasanexm02f.na.qualcomm.com (10.85.0.87)
Archived-At: 
Cc: slim@ietf.org
Subject: Re: [Slim] Translation Quality or type
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Jul 2015 17:58:27 -0000

At 10:25 AM -0400 7/6/15, Henning Schulzrinne wrote:

>  Plus, increasingly, there are hybrids (automated followed by human 
> editing and maybe vice versa, such as a grammar checker), which are 
> apparently quite common for routine (business and technical, rather 
> than literature) translations.

I think we should keep the mechanism simple, and say that any human 
involvement means the "human" tag should be used.

>
>  On Sun, Jul 5, 2015 at 6:04 PM, Paul Kyzivat 
> <pkyzivat@alum.mit.edu> wrote:
>
>  On 7/5/15 5:10 PM, Nik Tomkinson wrote:
>
>  Thanks again for the responses.
>
>  I think that I will add the original suggestion of:
>
>  translation-type := type-token
>  type-token := "original" / "human" / "automated"
>
>
>  This seems "ok" - more or less harmless and possibly helpful in some cases.
>
>  But I'm concerned that it will lead to an assumption that "human" 
> is *better* than "automated". That is probably true in most 
> practical cases today. But surely there are *some* automated 
> translations that are better than *some* human translations. And 
> that will become the case more often in the future.
>
>          Thanks,
>          Paul
>
>
>  _______________________________________________
>  SLIM mailing list
>  SLIM@ietf.org
>  https://www.ietf.org/mailman/listinfo/slim



-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
It has always seemed to me that the most difficult part of building
a bridge would be the start.                      --Robert Benchley


From nobody Tue Jul  7 11:05:03 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 595521ACF5E for ; Tue,  7 Jul 2015 11:05:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.711
X-Spam-Level: 
X-Spam-Status: No, score=-6.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 1UH6IwR8jchF for ; Tue,  7 Jul 2015 11:05:00 -0700 (PDT)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2701C1A92FB for ; Tue,  7 Jul 2015 11:04:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1436292300; x=1467828300; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=7YFArsDFEtBo84Y9REoRyxB6XPInWd21Yql7T8c9h+M=; b=mnFiiLhJg4ok0Q/aFKBOrgbzwdG4+qfrjRGtVRmyDURAuI6gaTI0HXp3 Pv9aVSnx1GFvdZUM1QszkgTmKjygdcEHffb8KlH0fjnjeaCrhZBdtwnW/ XJAObYxInkeutOaH2KyxNEK2CczBn6Dy9efDpQRrxnmocD8C34Li3DB0t Q=;
X-IronPort-AV: E=McAfee;i="5700,7163,7855"; a="93264353"
Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Jul 2015 11:04:59 -0700
X-IronPort-AV: E=Sophos;i="5.15,424,1432623600"; d="scan'208";a="954952748"
Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 07 Jul 2015 11:04:56 -0700
Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 7 Jul 2015 11:04:53 -0700
Message-ID: 
In-Reply-To: 
References:  <20150703064908.GA14666@sources.org> <55964BED.1080905@omnitor.se> <5596B184.2020908@alum.mit.edu> <0A0D0CE1-01AC-411B-86B6-176A92C223A8@standardstrack.com>  <5599A9FE.60401@alum.mit.edu> <559A27CA.1060800@omnitor.se>  <559A7734.9060809@omnitor.se> 
X-Mailer: Eudora for Mac OS X
Date: Tue, 7 Jul 2015 11:04:52 -0700
To: Nik Tomkinson , Gunnar =?iso-8859-1?Q?Hellstr=F6m?= 
From: Randall Gellens 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Originating-IP: [10.80.80.8]
X-ClientProxiedBy: NASANEXM01F.na.qualcomm.com (10.85.0.32) To nasanexm02f.na.qualcomm.com (10.85.0.87)
Archived-At: 
Cc: slim@ietf.org
Subject: Re: [Slim] Translation Quality or type
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Jul 2015 18:05:02 -0000

At 4:30 PM +0100 7/6/15, Nik Tomkinson wrote:

>  Thanks for the comments:
>  3 - I will add 'other values may be added in the future' in today's 
> draft version - thanks.

To clarify, I don't think we need an IANA registry for the values.  I 
think we will be fine saying that the only values are "original", 
"human", and "automated," and perhaps a parenthetical note that 
additional values could be defined in a future extension of the 
document.  It's probably more likely that any future extension would 
add modifiers rather than new values.

>
>  I see, for the video example it would be human x 2 (original human 
> signing and human interpreting) but I can see there may be the case 
> of some media that has an automated translated/interpreted content 
> alongside human text, speech or signing. This is something that I 
> will put on my list for further thought and discussion for the next 
> version of the draft but in order to get a new version submitted 
> before the cut-off time this evening, I will stick to just one 
> value.

We should keep things simple until we have deployment experience that 
shows we need something more complex.  If a video is sent as an email 
attachment, the most appropriate value can be used (e.g., "human" if 
there is some human involvement).



-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
A state which owns but one language and one habit is feeble and fragile.
    --King Stephen, founder of the Hungarian state (and a saint).


From nobody Tue Jul  7 11:08:28 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF041A00EC for ; Tue,  7 Jul 2015 11:08:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.711
X-Spam-Level: 
X-Spam-Status: No, score=-6.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 H6vPs2vQ6tWz for ; Tue,  7 Jul 2015 11:08:26 -0700 (PDT)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF40E1A009C for ; Tue,  7 Jul 2015 11:08:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1436292505; x=1467828505; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version:content-transfer-encoding; bh=Omtv7CXAGIAeHBfCnIQ38nXyFGVrlRkTif3y03sO+HI=; b=hwvxB8i+a4mf+oaINtfIpNir2UJqk+JRT3lxooZ33bgV2bgQgsiBQ2kV WuSh8nlRx+x9cPolrmAVVRimAHvjrlT1K6tujmYy8zbgX0CTKEaEM48dk +rAUNYM3fSBD+jcoyEu2EgGzmWko/OwNnn+IdZocQPm0rzeYWbjx2tLFy M=;
X-IronPort-AV: E=McAfee;i="5700,7163,7855"; a="93264596"
Received: from unknown (HELO Ironmsg04-L.qualcomm.com) ([172.30.48.19]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Jul 2015 11:08:05 -0700
X-IronPort-AV: E=Sophos;i="5.15,425,1432623600"; d="scan'208";a="929689449"
Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 07 Jul 2015 11:07:52 -0700
Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 7 Jul 2015 11:07:51 -0700
Message-ID: 
In-Reply-To: <559AA1C3.6070906@omnitor.se>
References:  <20150703064908.GA14666@sources.org>	<55964BED.1080905@omnitor.se> <5596B184.2020908@alum.mit.edu> <0A0D0CE1-01AC-411B-86B6-176A92C223A8@standardstrack.com>  <5599A9FE.60401@alum.mit.edu>	<559A27CA.1060800@omnitor.se>  <559A7734.9060809@omnitor.se>  <559AA1C3.6070906@omnitor.se>
X-Mailer: Eudora for Mac OS X
Date: Tue, 7 Jul 2015 11:07:50 -0700
To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , Nik Tomkinson 
From: Randall Gellens 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Originating-IP: [10.80.80.8]
X-ClientProxiedBy: NASANEXM01B.na.qualcomm.com (10.85.0.82) To nasanexm02f.na.qualcomm.com (10.85.0.87)
Archived-At: 
Cc: slim@ietf.org
Subject: Re: [Slim] Translation Quality or type
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Jul 2015 18:08:27 -0000

At 5:41 PM +0200 7/6/15, Gunnar Hellstr=F6m wrote:

>  Nik Tomkinson skrev den 2015-07-06 17:30:
>>
>>  Can you expand on your last question? I'm not=20
>> sure what you mean by 'session' in a=20
>> non-real-time single email scenario. The=20
>> intention is to have the Translation-Type=20
>> specified once per 'language message part'=20
>> (eg. original, text translation or media=20
>> translation).
>  Well, say media description or what term you use for the declaration.
>
>  A simple example would be a video file with=20
> audio track and timed text, with the video=20
> containing an original sign language=20
> presentation, interpreted to speech by a human=20
> interpreter in the audio track, and the=20
> interpreter talking into a speech-to-text=20
> generator, creating the automated timed-text=20
> track.
>
>  What would the translation declaration(s) look=20
> like for this creation so that all interested=20
> parties can judge if they get what they want?

Unless you expect there to be several video files=20
sent in the same email, some with timed text and=20
some without, and some with an audio track and=20
some without, and hence a need for the receiving=20
client to choose one, I don't think we need to=20
express the nuances of the video object.  If=20
there is some original content, use "original",=20
otherwise if there is some human involvement, use=20
"human", otherwise use "automated".

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
It is the business of the future to be dangerous.


From nobody Tue Jul  7 11:20:57 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2EAB1A1A68 for ; Tue,  7 Jul 2015 11:20:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.821
X-Spam-Level: 
X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham
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 byQvZwedNHWx for ; Tue,  7 Jul 2015 11:20:53 -0700 (PDT)
Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) (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 5E0391A0430 for ; Tue,  7 Jul 2015 11:20:53 -0700 (PDT)
Received: by igrv9 with SMTP id v9so147692749igr.1 for ; Tue, 07 Jul 2015 11:20:52 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=PhcjxIL0pvIZUTVZm8Y0YvC7XcMkrzh9Sd5VcaRFTxs=; b=gR5xbFl/zus89m6EYYxvYer0/zhT5PV0qDnT+LCE1tQ3g2gp7uyMYKT1UjD1H0h538 mX85QKbvHg6k1tKWCUEsWVOTYyvdHbaJT8DoDp04m55CfNavhMFinozB/vMCzcsKJTeu hXolNAEDU3oqPM86Rs7Zjung0vBjbYOdIhZuYbw/eq13iBF0jIi0XECpniMO0p5GK3/V LPLBY+4x2JcisREvMxqDSQh2L+FuFjC+BmOo7EdiR2l20LjDDMBu4FVssAGITbW6Eu2O 1AKESd/wNakGOBoeyTeCLIMgA0BgqnU2hxX/X/uJpTDYs4kvZzma190RrdART/7DjlA7 dAiQ==
X-Gm-Message-State: ALoCoQmuXPAujui3TnXwscTwh257xdVAvaEMBAKrhpQDQUh26kXReuGof7+znhqP+Gv7aaQUU5aw
X-Received: by 10.107.151.75 with SMTP id z72mr8425113iod.46.1436293252792; Tue, 07 Jul 2015 11:20:52 -0700 (PDT)
Received: from [10.33.193.32] (neustargw.va.neustar.com. [209.173.53.233]) by smtp.gmail.com with ESMTPSA id p8sm69380iga.13.2015.07.07.11.20.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Jul 2015 11:20:52 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: Brian Rosen 
In-Reply-To: 
Date: Tue, 7 Jul 2015 14:20:49 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <3032AEFE-75BD-48CE-9C4A-9526EEB85FDA@brianrosen.net>
References:  <20150703064908.GA14666@sources.org> <55964BED.1080905@omnitor.se>   <5598D34A.6070001@omnitor.se> <55995958.5050109@alum.mit.edu> <55999526.7030006@omnitor.se> <559A2D44.1010308@omnitor.se>  
To: Randall Gellens 
X-Mailer: Apple Mail (2.2102)
Archived-At: 
Cc: slim@ietf.org
Subject: Re: [Slim] Translation Quality or type - or service provider
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Jul 2015 18:20:57 -0000

In general, the PSAP wants to use it=92s bridge, and NOT have the =
translation service use its bridge.  There are clearly circumstances =
where the PSAP bridge cannot be used and we need a way to make sure the =
translation service=92s bridge can be used.

Brian

> On Jul 7, 2015, at 1:56 PM, Randall Gellens  =
wrote:
>=20
> At 4:43 AM -0400 7/6/15, Eric Burger wrote:
>=20
>>  > On Jul 6, 2015, at 3:24 AM, Gunnar Hellstr=F6m =
 wrote:
>>>=20
>>> One reason for the need to convey a translation service provider URI =
is that the emergency service RFCs 6443 and 6881 forbids the calling =
user to invoke three-party calling.
>=20
> The text there is saying that the best practice for a device =
initiating an emergency call is to disable services that could interrupt =
the call, such as call waiting and third-party calling.  If the =
third-party call is initiated before or in parallel with the emergency =
call, the text wouldn't apply anyway, and if the third-party call is =
initiated during the emergency call in order to better serve the user's =
needs, then this is exactly why the text uses "SHOULD" instead of =
"MUST."  The word "SHOULD" means that a client is supposed to follow the =
direction unless there is an overriding reason not to, and the =
consequences of doing so are understood.  Both of those apply in the =
case under discussion.
>=20
>=20
>>=20
>> 6443 is informational and 6881 is a BCP. No problem to do something =
that works that is 'forbidden.'
>>=20
>>> For example RFC 6443, chapter 13 says "Services such as call =
waiting, call transfer, three-way calling, and hold should be disabled."
>>=20
>> Note the use of 'should.'  I do not think anyone will complain if one =
interprets this as, "Should be disabled, unless the user will die if she =
does not setup a three-way call with her translation service."
>>=20
>>> If then the user is in a foreign language environment where the PSAP =
barely can have a clue on how to find the right relay service, and the =
user has a good relay service URI configured, well capable of handling =
the user's language and modality, what is then best?
>>>=20
>>> 1) Break against RFC 6881 and 6443 and have the user terminal invoke =
the three-party call? The wording in these RFCs may be interpreted to =
have some room for such deviations.
>>=20
>> Beyond the wording in the RFCs, there is a reason the IETF is not the =
protocol police. In retrospect, it may be safe to say the RFCs' =
suggestions are wrong.
>>=20
>>> 2) Or convey the relay service URI to the PSAP for invocation.
>>=20
>> Why not?
>>=20
>>>=20
>>> The discussion so far leads towards conclusion 1. It is ok for me, I =
just wanted it confirmed by showing the whole situation.
>>>=20
>>> (there will always be complementing slow manual procedures, when the =
PSAP needs to figure out a reasonable way to handle the call, but this =
discussion is for the rapid automated way that should handle most =
cases.)
>>>=20
>>> /Gunnar
>>>=20
>>> Gunnar Hellstr=F6m skrev den 2015-07-05 22:35:
>>>> Paul,
>>>> Yes, I agree that for most cases it is best that the party, who =
knows a service that will do the translation, does the invocation.
>>>>=20
>>>> And, yes ,in that scenario the 3PCC method seems suitable.
>>>>=20
>>>> My proposal to send the service provider URI together with the =
modality indications was for the case when there are strong policy =
reasons why one party would do the invocation, but little chance that =
that party would have access to an up-to-date information on available =
translation providers.
>>>> That could be the case for the emergency service calling in a =
multi-language environment, also including support for sign language =
users.
>>>>=20
>>>> Since both you and Randall think it is not doable, we can try to =
use the principle that the party, who knows a service that will do the =
translation, does the invocation.
>>  >>
>>>> That brings us back to a need for more stringent language/modality =
negotiation in order to avoid both double invocation of services when =
one or none is required, and also avoid no invocation when one is =
needed.
>>>>=20
>>>> Paul Kyzivat skrev den 2015-07-05 18:20:
>>>>> Gunnar,
>>>>>=20
>>>>> I understand what you are suggesting, but I don't believe it is =
workable. This seems to mean that the caller would select the service =
while the callee would engage the service in the call if needed. Yet it =
is likely to be the caller who has a business relationship with the =
service, while the callee does not. Gets complicated quickly.
>>  >>>
>>>>> ISTM it makes more sense to first figure out what is/isn't =
possible without translation, and then for a party that finds a =
translation service beneficial to engage one. Then the only concern is =
that both parties don't independently try to introduce equivalent =
translation services.
>>>>>=20
>>>>> For instance, a deaf caller might offer video media marked for =
sign language, and audio media on hold. If the answer doesn't accept the =
video, or doesn't indicate support for sign language, the caller could =
then conference in translation service, using the 3pcc transcoding model =
specified in rfc5369. (If that will take time, the deaf caller's UA =
could stream recorded media over the audio channel in the meantime.)
>>>>>=20
>>>>> Or, to get fancier, it would be possible to use preconditions to =
defer alerting the callee until this is all sorted out.
>>>>>=20
>>>>> My point is to let the participant who wants translation handle to =
setup of translation rather than depending on the other party to do =
something.
>>>> OK, it might be likely that both parties "want" translation, but =
one has better knowledge about how to get the required service and has =
business relations with the service. So then it is preferred that that =
party invokes.
>>>>=20
>>>> Good
>>>> /Gunnar
>>>>>=20
>>>>>    Thanks,
>>>>>    Paul
>>>>>=20
>>>>> On 7/5/15 2:48 AM, Gunnar Hellstr=F6m wrote:
>>>>>> Another opportunity would be to convey a URI to the service =
provider who
>>>>>> did (for mail) or can do(for real-time) the translation.
>>>>>> Then experience with different service provider's production =
could give
>>>>>> some idea of the expected quality.
>>>>>> I can see great value in that for the real-time case, when the =
calling
>>>>>> user has a favourite translator (e.g. relay service), and =
provides that
>>>>>> as a hint if languages or modalities in the call does not match. =
Then
>>>>>> the callee do not need to just take a service provider by chance =
that
>>>>>> seem to match the language/modality profile but can take the one
>>>>>> proposed by the caller.
>>>>>>=20
>>>>>> After working with the needs for emergency services to work =
across
>>>>>> Europe for some time now, I think this is one of the few workable
>>>>>> solutions. The user expresses both the language/modality needs =
and
>>>>>> provides a URI to a favourite translation service provider, and =
the
>>>>>> callee tries to fulfill the language/modality needs either by a =
matching
>>>>>> original call taker or by invoking the proposed translation =
provider.
>>>>>>=20
>>>>>> /Gunnar
>>>>>>=20
>>>>>>=20
>>>>>> Randall Gellens skrev den 2015-07-05 03:49:
>>>>>>> My recollection is that this was discussed in email prior to =
Dallas,
>>>>>>> but that's not important.
>>>>>>>=20
>>>>>>> I am a strong proponent of keeping things as simple as possible,
>>>>>>> provided there is a way to extend them if experience shows that =
it is
>>>>>>> needed.  So, I think we should stick with the original =
suggestion of
>>>>>>> three values ("original", "human", "automated"). This is simple =
enough
>>>>>>> to be implementable and functional enough to be useful in =
providing a
>>>>>>> hint that may help the client choose the best version for the =
user. If
>>>>>>> we try and capture the various nuances of quality we will end up =
with
>>>>>>> a very complex mechanism that is unlikely to be any more useful =
in
>>>>>>> real life. Let's go with the simple approach now.  If, after =
some
>>>>>>> deployment experience we realize that we really do need extra
>>>>>>> complexity, we can extend the mechanism then.
>>>>>>>=20
>>>>>>> At 4:29 PM +0100 7/3/15, Nik Tomkinson wrote:
>>  >>>>>
>>>>>>>> Thanks for the responses.
>>>>>>>>=20
>>>>>>>> To deal with the issue with having only =
original/human/automated,
>>>>>>>> what about the following?:
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> translation-type :=3D type-token[ ";" "q" "=3D" qvalue ]
>>>>>>>> type-token :=3D"human" / "automated"
>>>>>>>>=20
>>>>>>>> where qvalue is a value between 0 and 1 with a default of 0.5 =
if
>>>>>>>> missing
>>>>>>>>=20
>>>>>>>> for example:
>>>>>>>>=20
>>>>>>>> Translation-Type: human;q=3D0.8
>>>>>>>> Translation-Type: automated;q=3D0.4
>>>>>>>> Translation-Type: human
>>>>>>>>=20
>>>>>>>> The Translation-Type SHOULD NOT appear in the original
>>>>>>>> (untranslated) part but it SHOULD appear in translated content.
>>  >>>>>>
>>>>>>>> Having this missing from the original text helps identify which =
is
>>>>>>>> the source to be translated into further languages if the user =
mail
>>>>>>>> client allows.
>>>>>>>>=20
>>>>>>>> This enables us to dispose of the 'original' value which didn't =
lend
>>>>>>>> itself well to being graded on quality.
>>>>>>>>=20
>>>>>>>> The qvalue can be set by the sender or provided by the =
translation
>>>>>>>> service.
>>>>>>>>=20
>>>>>>>> The draft suggests that:
>>>>>>>>=20
>>>>>>>> "Additionally, interactive implementations MAY offer the user a
>>>>>>>> choice from among the available languages." so the qvalue may =
not
>>>>>>>> need to be bulletproof.
>>>>>>>>=20
>>>>>>>> Comments?
>>>>>>>>=20
>>>>>>>> Nik.
>>>>>>>>=20
>>>>>>>> On 3 July 2015 at 09:46, Gunnar Hellstr=F6m
>>>>>>>> =
<gunnar.hellstrom@omnitor.se> wrote:
>>>>>>>>=20
>>>>>>>> I see some value of this kind of parameter also for the =
real-time case.
>>>>>>>> The time is here when it can be possible in some situations to
>>>>>>>> select between using a low-cost automatic speech-to-text =
generation
>>>>>>>> and a higher cost captioned telephony or text-relay service =
(higher
>>>>>>>> cost for someone, not always the end-user).
>>>>>>>>=20
>>>>>>>> But I agree that it is very hard to set good understandable =
values
>>>>>>>> on a parameter expressing the type or quality of this kind of =
service.
>>>>>>>>=20
>>>>>>>> Gunnar
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> Stephane Bortzmeyer skrev den 2015-07-03 08:49:
>>>>>>>>=20
>>>>>>>> On Thu, Jul 02, 2015 at 11:09:30PM +0100,
>>>>>>>>   Nik Tomkinson
>>>>>>>> =
<rfc.nik.tomkinson@gmail.com> wrote
>>>>>>>>   a message of 109 lines which said:
>>>>>>>>=20
>>>>>>>> type-token :=3D "original" / "human" / "automated"
>>>>>>>>=20
>>>>>>>> In many IETF working groups, when there is such a proposal, =
there is a
>>>>>>>> big discussion between the registryfull and the registryless
>>>>>>>> people. The first ones say there must be an authoritative list =
of
>>>>>>>> values (in the RFC or, better because more evolving, in an IANA
>>>>>>>> registry) so we can be sure of the interpretation of values. =
The
>>>>>>>> second ones say we can never capture all the nuances and =
subtleties of
>>>>>>>> the world in a fixed list.
>>>>>>>>=20
>>>>>>>> Here, I am not sure that the only meaningful distinction is =
between
>>>>>>>> "human" and "automated". Some humans do a very poor job, too. =
One
>>>>>>>> could suggest:
>>>>>>>>=20
>>>>>>>> type-token :=3D "original" / "professional-human" / =
"amateur-human" /
>>>>>>>> "automated-first-generation" / =
"automated-artificial-intelligence" /
>>>>>>>> "automated-the-robot-in-hollywood-movies"
>>>>>>>>=20
>>>>>>>> Or decide that it will be too complicated and we should instead
>>>>>>>> accept:
>>>>>>>>=20
>>>>>>>> type-token :=3D "original" / 
>>>>>>>>=20
>>>>>>>> Toughts?
>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> SLIM mailing list
>>>>>>>> SLIM@ietf.org
>>>>>>>>=20
>>>>>>>> =
https://www.ietf.org/mailman/l=
istinfo/slim
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> SLIM mailing list
>>>>>>>> SLIM@ietf.org
>>>>>>>>=20
>>>>>>>> =
https://www.ietf.org/mailman/l=
istinfo/slim
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> --
>>>>>>>>=20
>>>>>>>> =
-----------------------------------------------------------------
>>>>>>>> Multiple Language Content Type Internet Draft:
>>>>>>>>=20
>>>>>>>> =
http://=
datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/
>>  >>>>>>
>>>>>>>> =
-----------------------------------------------------------------
>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> SLIM mailing list
>>>>>>>> SLIM@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/slim
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> SLIM mailing list
>>>>> SLIM@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/slim
>>>>=20
>>>=20
>>> --
>>> -----------------------------------------
>>> Gunnar Hellstr=F6m
>>> Omnitor
>>> gunnar.hellstrom@omnitor.se
>>> +46 708 204 288
>>>=20
>>> _______________________________________________
>>  > SLIM mailing list
>>> SLIM@ietf.org
>>> https://www.ietf.org/mailman/listinfo/slim
>>=20
>>=20
>> Content-Transfer-Encoding: 7bit
>> Content-Disposition: attachment; filename=3D"signature.asc"
>> Content-Type: application/pgp-signature;
>> 	name=3Dsignature.asc
>> Content-Description: Message signed with OpenPGP using GPGMail
>>=20
>> Attachment converted: TiLand:signature 415.asc (    /    ) (028C4061)
>> _______________________________________________
>> SLIM mailing list
>> SLIM@ietf.org
>> https://www.ietf.org/mailman/listinfo/slim
>=20
>=20
>=20
> --=20
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for myself =
only
> -------------- Randomly selected tag: ---------------
> Progress is made on alternate Fridays.
>=20
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim


From nobody Tue Jul  7 13:20:45 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D14EE1A8AB1 for ; Tue,  7 Jul 2015 13:20:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.011
X-Spam-Level: 
X-Spam-Status: No, score=-1.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=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 Sgj-KtoxZYBv for ; Tue,  7 Jul 2015 13:20:38 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36E4C1A8AA9 for ; Tue,  7 Jul 2015 13:20:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default;  h=Content-Type:MIME-Version:To:From:Message-ID:Subject:Date; bh=GZCcrJ5qpu4gnqWx4IoZHE/Unni0KyMw3VZy93jC8J0=;  b=NeUyVDFulaeBjQ+awa3KH0z4077SUBeApI/lhIdVPt3HsdzdjSP6qPccZe6qNSYdxEmx5vNvi9va91i/7CPjNDihFQuNyfAzo+4TJ7tP4mga8gvi3rQKJarUyfjOARrjIJr0aJLkaLGmDTZ9Exp0xYRbqAKEr7u+hIG6pX/Npf8=;
Received: from 242.sub-70-192-217.myvzw.com ([70.192.217.242]:12091 helo=[100.86.59.11]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZCZM2-0001jJ-AO for slim@ietf.org; Tue, 07 Jul 2015 13:20:37 -0700
Date: Tue, 07 Jul 2015 16:20:31 -0400
Message-ID: 
Importance: normal
From: Eric Burger 
To: "slim@ietf.org" 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--_com.android.email_216422982804850"
X-OutGoing-Spam-Status: No, score=-0.4
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.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: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
Archived-At: 
Subject: Re: [Slim] Translation Quality or type - or service provider
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Jul 2015 20:20:43 -0000

----_com.android.email_216422982804850
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64

CiAgICAKSSBkb24ndCBzZWUgaG93IGVpdGhlciB3YXkgaXMgZW5mb3JjZWFibGUuIElmIHdlIHNh
eSB0aGUgUFNBUCBoYXMgdG8gdGFrZSB0aGUgY2FsbGVyJ3MgdHJhbnNsYXRpb24gc2VydmljZSwg
YW55IHNlbnNpYmxlIFBTQVAgd2lsbCBmZWVsIGZyZWUgdG8gaWdub3JlIGl0LCB3aGV0aGVyIGR1
ZSB0byBjb3N0LCBsaWFiaWxpdHksIG9yIHByb3RlY3RpbmcgYWdhaW5zdCB0aGUgUFNBUCBiZWlu
ZyB0aGUgc291cmNlIG9mIGEgRG9TIGF0dGFjay4gQ29udmVyc2VseSwgaWYgYSBwYXJ0aWN1bGFy
IFBTQVAgY291bGQgdXNlIGEgaGludCBmb3IgYSB0cmFuc2xhdGlvbiBzZXJ2aWNlLCBpdCB3b3Vs
ZCBiZSBoYW5keSBmb3IgdGhlIGNhbGxlciB0byBwcm92aWRlIG9uZS7CoAoKClNlbnQgZnJvbSBt
eSBtb2JpbGUgZGV2aWNlLiBUaGFua3MgYmUgdG8gTEVNT05BREU6IGh0dHA6Ly93d3cuc3RhbmRh
cmRzdHJhY2suY29tL2lldGYvbGVtb25hZGUKCi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0t
LS0tLS0KRnJvbTogQnJpYW4gUm9zZW4gPGJyQGJyaWFucm9zZW4ubmV0PiAKRGF0ZTogMDcvMDcv
MjAxNSAgMjoyMCBQTSAgKEdNVC0wNTowMCkgClRvOiBSYW5kYWxsIEdlbGxlbnMgPHJhbmR5QHF0
aS5xdWFsY29tbS5jb20+IApDYzogRXJpYyBCdXJnZXIgPGVidXJnZXJAc3RhbmRhcmRzdHJhY2su
Y29tPiwgc2xpbUBpZXRmLm9yZyAKU3ViamVjdDogUmU6IFtTbGltXSBUcmFuc2xhdGlvbiBRdWFs
aXR5IG9yIHR5cGUgLSBvciBzZXJ2aWNlIHByb3ZpZGVyIAoKSW4gZ2VuZXJhbCwgdGhlIFBTQVAg
d2FudHMgdG8gdXNlIGl04oCZcyBicmlkZ2UsIGFuZCBOT1QgaGF2ZSB0aGUgdHJhbnNsYXRpb24g
c2VydmljZSB1c2UgaXRzIGJyaWRnZS7CoCBUaGVyZSBhcmUgY2xlYXJseSBjaXJjdW1zdGFuY2Vz
IHdoZXJlIHRoZSBQU0FQIGJyaWRnZSBjYW5ub3QgYmUgdXNlZCBhbmQgd2UgbmVlZCBhIHdheSB0
byBtYWtlIHN1cmUgdGhlIHRyYW5zbGF0aW9uIHNlcnZpY2XigJlzIGJyaWRnZSBjYW4gYmUgdXNl
ZC4KCkJyaWFuCgo+IE9uIEp1bCA3LCAyMDE1LCBhdCAxOjU2IFBNLCBSYW5kYWxsIEdlbGxlbnMg
PHJhbmR5QHF0aS5xdWFsY29tbS5jb20+IHdyb3RlOgo+IAo+IEF0IDQ6NDMgQU0gLTA0MDAgNy82
LzE1LCBFcmljIEJ1cmdlciB3cm90ZToKPiAKPj7CoCA+IE9uIEp1bCA2LCAyMDE1LCBhdCAzOjI0
IEFNLCBHdW5uYXIgSGVsbHN0csO2bSA8Z3VubmFyLmhlbGxzdHJvbUBvbW5pdG9yLnNlPiB3cm90
ZToKPj4+IAo+Pj4gT25lIHJlYXNvbiBmb3IgdGhlIG5lZWQgdG8gY29udmV5IGEgdHJhbnNsYXRp
b24gc2VydmljZSBwcm92aWRlciBVUkkgaXMgdGhhdCB0aGUgZW1lcmdlbmN5IHNlcnZpY2UgUkZD
cyA2NDQzIGFuZCA2ODgxIGZvcmJpZHMgdGhlIGNhbGxpbmcgdXNlciB0byBpbnZva2UgdGhyZWUt
cGFydHkgY2FsbGluZy4KPiAKPiBUaGUgdGV4dCB0aGVyZSBpcyBzYXlpbmcgdGhhdCB0aGUgYmVz
dCBwcmFjdGljZSBmb3IgYSBkZXZpY2UgaW5pdGlhdGluZyBhbiBlbWVyZ2VuY3kgY2FsbCBpcyB0
byBkaXNhYmxlIHNlcnZpY2VzIHRoYXQgY291bGQgaW50ZXJydXB0IHRoZSBjYWxsLCBzdWNoIGFz
IGNhbGwgd2FpdGluZyBhbmQgdGhpcmQtcGFydHkgY2FsbGluZy7CoCBJZiB0aGUgdGhpcmQtcGFy
dHkgY2FsbCBpcyBpbml0aWF0ZWQgYmVmb3JlIG9yIGluIHBhcmFsbGVsIHdpdGggdGhlIGVtZXJn
ZW5jeSBjYWxsLCB0aGUgdGV4dCB3b3VsZG4ndCBhcHBseSBhbnl3YXksIGFuZCBpZiB0aGUgdGhp
cmQtcGFydHkgY2FsbCBpcyBpbml0aWF0ZWQgZHVyaW5nIHRoZSBlbWVyZ2VuY3kgY2FsbCBpbiBv
cmRlciB0byBiZXR0ZXIgc2VydmUgdGhlIHVzZXIncyBuZWVkcywgdGhlbiB0aGlzIGlzIGV4YWN0
bHkgd2h5IHRoZSB0ZXh0IHVzZXMgIlNIT1VMRCIgaW5zdGVhZCBvZiAiTVVTVC4iwqAgVGhlIHdv
cmQgIlNIT1VMRCIgbWVhbnMgdGhhdCBhIGNsaWVudCBpcyBzdXBwb3NlZCB0byBmb2xsb3cgdGhl
IGRpcmVjdGlvbiB1bmxlc3MgdGhlcmUgaXMgYW4gb3ZlcnJpZGluZyByZWFzb24gbm90IHRvLCBh
bmQgdGhlIGNvbnNlcXVlbmNlcyBvZiBkb2luZyBzbyBhcmUgdW5kZXJzdG9vZC7CoCBCb3RoIG9m
IHRob3NlIGFwcGx5IGluIHRoZSBjYXNlIHVuZGVyIGRpc2N1c3Npb24uCj4gCj4gCj4+IAo+PiA2
NDQzIGlzIGluZm9ybWF0aW9uYWwgYW5kIDY4ODEgaXMgYSBCQ1AuIE5vIHByb2JsZW0gdG8gZG8g
c29tZXRoaW5nIHRoYXQgd29ya3MgdGhhdCBpcyAnZm9yYmlkZGVuLicKPj4gCj4+PiBGb3IgZXhh
bXBsZSBSRkMgNjQ0MywgY2hhcHRlciAxMyBzYXlzICJTZXJ2aWNlcyBzdWNoIGFzIGNhbGwgd2Fp
dGluZywgY2FsbCB0cmFuc2ZlciwgdGhyZWUtd2F5IGNhbGxpbmcsIGFuZCBob2xkIHNob3VsZCBi
ZSBkaXNhYmxlZC4iCj4+IAo+PiBOb3RlIHRoZSB1c2Ugb2YgJ3Nob3VsZC4nwqAgSSBkbyBub3Qg
dGhpbmsgYW55b25lIHdpbGwgY29tcGxhaW4gaWYgb25lIGludGVycHJldHMgdGhpcyBhcywgIlNo
b3VsZCBiZSBkaXNhYmxlZCwgdW5sZXNzIHRoZSB1c2VyIHdpbGwgZGllIGlmIHNoZSBkb2VzIG5v
dCBzZXR1cCBhIHRocmVlLXdheSBjYWxsIHdpdGggaGVyIHRyYW5zbGF0aW9uIHNlcnZpY2UuIgo+
PiAKPj4+IElmIHRoZW4gdGhlIHVzZXIgaXMgaW4gYSBmb3JlaWduIGxhbmd1YWdlIGVudmlyb25t
ZW50IHdoZXJlIHRoZSBQU0FQIGJhcmVseSBjYW4gaGF2ZSBhIGNsdWUgb24gaG93IHRvIGZpbmQg
dGhlIHJpZ2h0IHJlbGF5IHNlcnZpY2UsIGFuZCB0aGUgdXNlciBoYXMgYSBnb29kIHJlbGF5IHNl
cnZpY2UgVVJJIGNvbmZpZ3VyZWQsIHdlbGwgY2FwYWJsZSBvZiBoYW5kbGluZyB0aGUgdXNlcidz
IGxhbmd1YWdlIGFuZCBtb2RhbGl0eSwgd2hhdCBpcyB0aGVuIGJlc3Q/Cj4+PiAKPj4+IDEpIEJy
ZWFrIGFnYWluc3QgUkZDIDY4ODEgYW5kIDY0NDMgYW5kIGhhdmUgdGhlIHVzZXIgdGVybWluYWwg
aW52b2tlIHRoZSB0aHJlZS1wYXJ0eSBjYWxsPyBUaGUgd29yZGluZyBpbiB0aGVzZSBSRkNzIG1h
eSBiZSBpbnRlcnByZXRlZCB0byBoYXZlIHNvbWUgcm9vbSBmb3Igc3VjaCBkZXZpYXRpb25zLgo+
PiAKPj4gQmV5b25kIHRoZSB3b3JkaW5nIGluIHRoZSBSRkNzLCB0aGVyZSBpcyBhIHJlYXNvbiB0
aGUgSUVURiBpcyBub3QgdGhlIHByb3RvY29sIHBvbGljZS4gSW4gcmV0cm9zcGVjdCwgaXQgbWF5
IGJlIHNhZmUgdG8gc2F5IHRoZSBSRkNzJyBzdWdnZXN0aW9ucyBhcmUgd3JvbmcuCj4+IAo+Pj4g
MikgT3IgY29udmV5IHRoZSByZWxheSBzZXJ2aWNlIFVSSSB0byB0aGUgUFNBUCBmb3IgaW52b2Nh
dGlvbi4KPj4gCj4+IFdoeSBub3Q/Cj4+IAo+Pj4gCj4+PiBUaGUgZGlzY3Vzc2lvbiBzbyBmYXIg
bGVhZHMgdG93YXJkcyBjb25jbHVzaW9uIDEuIEl0IGlzIG9rIGZvciBtZSwgSSBqdXN0IHdhbnRl
ZCBpdCBjb25maXJtZWQgYnkgc2hvd2luZyB0aGUgd2hvbGUgc2l0dWF0aW9uLgo+Pj4gCj4+PiAo
dGhlcmUgd2lsbCBhbHdheXMgYmUgY29tcGxlbWVudGluZyBzbG93IG1hbnVhbCBwcm9jZWR1cmVz
LCB3aGVuIHRoZSBQU0FQIG5lZWRzIHRvIGZpZ3VyZSBvdXQgYSByZWFzb25hYmxlIHdheSB0byBo
YW5kbGUgdGhlIGNhbGwsIGJ1dCB0aGlzIGRpc2N1c3Npb24gaXMgZm9yIHRoZSByYXBpZCBhdXRv
bWF0ZWQgd2F5IHRoYXQgc2hvdWxkIGhhbmRsZSBtb3N0IGNhc2VzLikKPj4+IAo+Pj4gL0d1bm5h
cgo+Pj4gCj4+PiBHdW5uYXIgSGVsbHN0csO2bSBza3JldiBkZW4gMjAxNS0wNy0wNSAyMjozNToK
Pj4+PiBQYXVsLAo+Pj4+IFllcywgSSBhZ3JlZSB0aGF0IGZvciBtb3N0IGNhc2VzIGl0IGlzIGJl
c3QgdGhhdCB0aGUgcGFydHksIHdobyBrbm93cyBhIHNlcnZpY2UgdGhhdCB3aWxsIGRvIHRoZSB0
cmFuc2xhdGlvbiwgZG9lcyB0aGUgaW52b2NhdGlvbi4KPj4+PiAKPj4+PiBBbmQsIHllcyAsaW4g
dGhhdCBzY2VuYXJpbyB0aGUgM1BDQyBtZXRob2Qgc2VlbXMgc3VpdGFibGUuCj4+Pj4gCj4+Pj4g
TXkgcHJvcG9zYWwgdG8gc2VuZCB0aGUgc2VydmljZSBwcm92aWRlciBVUkkgdG9nZXRoZXIgd2l0
aCB0aGUgbW9kYWxpdHkgaW5kaWNhdGlvbnMgd2FzIGZvciB0aGUgY2FzZSB3aGVuIHRoZXJlIGFy
ZSBzdHJvbmcgcG9saWN5IHJlYXNvbnMgd2h5IG9uZSBwYXJ0eSB3b3VsZCBkbyB0aGUgaW52b2Nh
dGlvbiwgYnV0IGxpdHRsZSBjaGFuY2UgdGhhdCB0aGF0IHBhcnR5IHdvdWxkIGhhdmUgYWNjZXNz
IHRvIGFuIHVwLXRvLWRhdGUgaW5mb3JtYXRpb24gb24gYXZhaWxhYmxlIHRyYW5zbGF0aW9uIHBy
b3ZpZGVycy4KPj4+PiBUaGF0IGNvdWxkIGJlIHRoZSBjYXNlIGZvciB0aGUgZW1lcmdlbmN5IHNl
cnZpY2UgY2FsbGluZyBpbiBhIG11bHRpLWxhbmd1YWdlIGVudmlyb25tZW50LCBhbHNvIGluY2x1
ZGluZyBzdXBwb3J0IGZvciBzaWduIGxhbmd1YWdlIHVzZXJzLgo+Pj4+IAo+Pj4+IFNpbmNlIGJv
dGggeW91IGFuZCBSYW5kYWxsIHRoaW5rIGl0IGlzIG5vdCBkb2FibGUsIHdlIGNhbiB0cnkgdG8g
dXNlIHRoZSBwcmluY2lwbGUgdGhhdCB0aGUgcGFydHksIHdobyBrbm93cyBhIHNlcnZpY2UgdGhh
dCB3aWxsIGRvIHRoZSB0cmFuc2xhdGlvbiwgZG9lcyB0aGUgaW52b2NhdGlvbi4KPj7CoCA+Pgo+
Pj4+IFRoYXQgYnJpbmdzIHVzIGJhY2sgdG8gYSBuZWVkIGZvciBtb3JlIHN0cmluZ2VudCBsYW5n
dWFnZS9tb2RhbGl0eSBuZWdvdGlhdGlvbiBpbiBvcmRlciB0byBhdm9pZCBib3RoIGRvdWJsZSBp
bnZvY2F0aW9uIG9mIHNlcnZpY2VzIHdoZW4gb25lIG9yIG5vbmUgaXMgcmVxdWlyZWQsIGFuZCBh
bHNvIGF2b2lkIG5vIGludm9jYXRpb24gd2hlbiBvbmUgaXMgbmVlZGVkLgo+Pj4+IAo+Pj4+IFBh
dWwgS3l6aXZhdCBza3JldiBkZW4gMjAxNS0wNy0wNSAxODoyMDoKPj4+Pj4gR3VubmFyLAo+Pj4+
PiAKPj4+Pj4gSSB1bmRlcnN0YW5kIHdoYXQgeW91IGFyZSBzdWdnZXN0aW5nLCBidXQgSSBkb24n
dCBiZWxpZXZlIGl0IGlzIHdvcmthYmxlLiBUaGlzIHNlZW1zIHRvIG1lYW4gdGhhdCB0aGUgY2Fs
bGVyIHdvdWxkIHNlbGVjdCB0aGUgc2VydmljZSB3aGlsZSB0aGUgY2FsbGVlIHdvdWxkIGVuZ2Fn
ZSB0aGUgc2VydmljZSBpbiB0aGUgY2FsbCBpZiBuZWVkZWQuIFlldCBpdCBpcyBsaWtlbHkgdG8g
YmUgdGhlIGNhbGxlciB3aG8gaGFzIGEgYnVzaW5lc3MgcmVsYXRpb25zaGlwIHdpdGggdGhlIHNl
cnZpY2UsIHdoaWxlIHRoZSBjYWxsZWUgZG9lcyBub3QuIEdldHMgY29tcGxpY2F0ZWQgcXVpY2ts
eS4KPj7CoCA+Pj4KPj4+Pj4gSVNUTSBpdCBtYWtlcyBtb3JlIHNlbnNlIHRvIGZpcnN0IGZpZ3Vy
ZSBvdXQgd2hhdCBpcy9pc24ndCBwb3NzaWJsZSB3aXRob3V0IHRyYW5zbGF0aW9uLCBhbmQgdGhl
biBmb3IgYSBwYXJ0eSB0aGF0IGZpbmRzIGEgdHJhbnNsYXRpb24gc2VydmljZSBiZW5lZmljaWFs
IHRvIGVuZ2FnZSBvbmUuIFRoZW4gdGhlIG9ubHkgY29uY2VybiBpcyB0aGF0IGJvdGggcGFydGll
cyBkb24ndCBpbmRlcGVuZGVudGx5IHRyeSB0byBpbnRyb2R1Y2UgZXF1aXZhbGVudCB0cmFuc2xh
dGlvbiBzZXJ2aWNlcy4KPj4+Pj4gCj4+Pj4+IEZvciBpbnN0YW5jZSwgYSBkZWFmIGNhbGxlciBt
aWdodCBvZmZlciB2aWRlbyBtZWRpYSBtYXJrZWQgZm9yIHNpZ24gbGFuZ3VhZ2UsIGFuZCBhdWRp
byBtZWRpYSBvbiBob2xkLiBJZiB0aGUgYW5zd2VyIGRvZXNuJ3QgYWNjZXB0IHRoZSB2aWRlbywg
b3IgZG9lc24ndCBpbmRpY2F0ZSBzdXBwb3J0IGZvciBzaWduIGxhbmd1YWdlLCB0aGUgY2FsbGVy
IGNvdWxkIHRoZW4gY29uZmVyZW5jZSBpbiB0cmFuc2xhdGlvbiBzZXJ2aWNlLCB1c2luZyB0aGUg
M3BjYyB0cmFuc2NvZGluZyBtb2RlbCBzcGVjaWZpZWQgaW4gcmZjNTM2OS4gKElmIHRoYXQgd2ls
bCB0YWtlIHRpbWUsIHRoZSBkZWFmIGNhbGxlcidzIFVBIGNvdWxkIHN0cmVhbSByZWNvcmRlZCBt
ZWRpYSBvdmVyIHRoZSBhdWRpbyBjaGFubmVsIGluIHRoZSBtZWFudGltZS4pCj4+Pj4+IAo+Pj4+
PiBPciwgdG8gZ2V0IGZhbmNpZXIsIGl0IHdvdWxkIGJlIHBvc3NpYmxlIHRvIHVzZSBwcmVjb25k
aXRpb25zIHRvIGRlZmVyIGFsZXJ0aW5nIHRoZSBjYWxsZWUgdW50aWwgdGhpcyBpcyBhbGwgc29y
dGVkIG91dC4KPj4+Pj4gCj4+Pj4+IE15IHBvaW50IGlzIHRvIGxldCB0aGUgcGFydGljaXBhbnQg
d2hvIHdhbnRzIHRyYW5zbGF0aW9uIGhhbmRsZSB0byBzZXR1cCBvZiB0cmFuc2xhdGlvbiByYXRo
ZXIgdGhhbiBkZXBlbmRpbmcgb24gdGhlIG90aGVyIHBhcnR5IHRvIGRvIHNvbWV0aGluZy4KPj4+
PiBPSywgaXQgbWlnaHQgYmUgbGlrZWx5IHRoYXQgYm90aCBwYXJ0aWVzICJ3YW50IiB0cmFuc2xh
dGlvbiwgYnV0IG9uZSBoYXMgYmV0dGVyIGtub3dsZWRnZSBhYm91dCBob3cgdG8gZ2V0IHRoZSBy
ZXF1aXJlZCBzZXJ2aWNlIGFuZCBoYXMgYnVzaW5lc3MgcmVsYXRpb25zIHdpdGggdGhlIHNlcnZp
Y2UuIFNvIHRoZW4gaXQgaXMgcHJlZmVycmVkIHRoYXQgdGhhdCBwYXJ0eSBpbnZva2VzLgo+Pj4+
IAo+Pj4+IEdvb2QKPj4+PiAvR3VubmFyCj4+Pj4+IAo+Pj4+PsKgwqDCoCBUaGFua3MsCj4+Pj4+
wqDCoMKgIFBhdWwKPj4+Pj4gCj4+Pj4+IE9uIDcvNS8xNSAyOjQ4IEFNLCBHdW5uYXIgSGVsbHN0
csO2bSB3cm90ZToKPj4+Pj4+IEFub3RoZXIgb3Bwb3J0dW5pdHkgd291bGQgYmUgdG8gY29udmV5
IGEgVVJJIHRvIHRoZSBzZXJ2aWNlIHByb3ZpZGVyIHdobwo+Pj4+Pj4gZGlkIChmb3IgbWFpbCkg
b3IgY2FuIGRvKGZvciByZWFsLXRpbWUpIHRoZSB0cmFuc2xhdGlvbi4KPj4+Pj4+IFRoZW4gZXhw
ZXJpZW5jZSB3aXRoIGRpZmZlcmVudCBzZXJ2aWNlIHByb3ZpZGVyJ3MgcHJvZHVjdGlvbiBjb3Vs
ZCBnaXZlCj4+Pj4+PiBzb21lIGlkZWEgb2YgdGhlIGV4cGVjdGVkIHF1YWxpdHkuCj4+Pj4+PiBJ
IGNhbiBzZWUgZ3JlYXQgdmFsdWUgaW4gdGhhdCBmb3IgdGhlIHJlYWwtdGltZSBjYXNlLCB3aGVu
IHRoZSBjYWxsaW5nCj4+Pj4+PiB1c2VyIGhhcyBhIGZhdm91cml0ZSB0cmFuc2xhdG9yIChlLmcu
IHJlbGF5IHNlcnZpY2UpLCBhbmQgcHJvdmlkZXMgdGhhdAo+Pj4+Pj4gYXMgYSBoaW50IGlmIGxh
bmd1YWdlcyBvciBtb2RhbGl0aWVzIGluIHRoZSBjYWxsIGRvZXMgbm90IG1hdGNoLiBUaGVuCj4+
Pj4+PiB0aGUgY2FsbGVlIGRvIG5vdCBuZWVkIHRvIGp1c3QgdGFrZSBhIHNlcnZpY2UgcHJvdmlk
ZXIgYnkgY2hhbmNlIHRoYXQKPj4+Pj4+IHNlZW0gdG8gbWF0Y2ggdGhlIGxhbmd1YWdlL21vZGFs
aXR5IHByb2ZpbGUgYnV0IGNhbiB0YWtlIHRoZSBvbmUKPj4+Pj4+IHByb3Bvc2VkIGJ5IHRoZSBj
YWxsZXIuCj4+Pj4+PiAKPj4+Pj4+IEFmdGVyIHdvcmtpbmcgd2l0aCB0aGUgbmVlZHMgZm9yIGVt
ZXJnZW5jeSBzZXJ2aWNlcyB0byB3b3JrIGFjcm9zcwo+Pj4+Pj4gRXVyb3BlIGZvciBzb21lIHRp
bWUgbm93LCBJIHRoaW5rIHRoaXMgaXMgb25lIG9mIHRoZSBmZXcgd29ya2FibGUKPj4+Pj4+IHNv
bHV0aW9ucy4gVGhlIHVzZXIgZXhwcmVzc2VzIGJvdGggdGhlIGxhbmd1YWdlL21vZGFsaXR5IG5l
ZWRzIGFuZAo+Pj4+Pj4gcHJvdmlkZXMgYSBVUkkgdG8gYSBmYXZvdXJpdGUgdHJhbnNsYXRpb24g
c2VydmljZSBwcm92aWRlciwgYW5kIHRoZQo+Pj4+Pj4gY2FsbGVlIHRyaWVzIHRvIGZ1bGZpbGwg
dGhlIGxhbmd1YWdlL21vZGFsaXR5IG5lZWRzIGVpdGhlciBieSBhIG1hdGNoaW5nCj4+Pj4+PiBv
cmlnaW5hbCBjYWxsIHRha2VyIG9yIGJ5IGludm9raW5nIHRoZSBwcm9wb3NlZCB0cmFuc2xhdGlv
biBwcm92aWRlci4KPj4+Pj4+IAo+Pj4+Pj4gL0d1bm5hcgo+Pj4+Pj4gCj4+Pj4+PiAKPj4+Pj4+
IFJhbmRhbGwgR2VsbGVucyBza3JldiBkZW4gMjAxNS0wNy0wNSAwMzo0OToKPj4+Pj4+PiBNeSBy
ZWNvbGxlY3Rpb24gaXMgdGhhdCB0aGlzIHdhcyBkaXNjdXNzZWQgaW4gZW1haWwgcHJpb3IgdG8g
RGFsbGFzLAo+Pj4+Pj4+IGJ1dCB0aGF0J3Mgbm90IGltcG9ydGFudC4KPj4+Pj4+PiAKPj4+Pj4+
PiBJIGFtIGEgc3Ryb25nIHByb3BvbmVudCBvZiBrZWVwaW5nIHRoaW5ncyBhcyBzaW1wbGUgYXMg
cG9zc2libGUsCj4+Pj4+Pj4gcHJvdmlkZWQgdGhlcmUgaXMgYSB3YXkgdG8gZXh0ZW5kIHRoZW0g
aWYgZXhwZXJpZW5jZSBzaG93cyB0aGF0IGl0IGlzCj4+Pj4+Pj4gbmVlZGVkLsKgIFNvLCBJIHRo
aW5rIHdlIHNob3VsZCBzdGljayB3aXRoIHRoZSBvcmlnaW5hbCBzdWdnZXN0aW9uIG9mCj4+Pj4+
Pj4gdGhyZWUgdmFsdWVzICgib3JpZ2luYWwiLCAiaHVtYW4iLCAiYXV0b21hdGVkIikuIFRoaXMg
aXMgc2ltcGxlIGVub3VnaAo+Pj4+Pj4+IHRvIGJlIGltcGxlbWVudGFibGUgYW5kIGZ1bmN0aW9u
YWwgZW5vdWdoIHRvIGJlIHVzZWZ1bCBpbiBwcm92aWRpbmcgYQo+Pj4+Pj4+IGhpbnQgdGhhdCBt
YXkgaGVscCB0aGUgY2xpZW50IGNob29zZSB0aGUgYmVzdCB2ZXJzaW9uIGZvciB0aGUgdXNlci4g
SWYKPj4+Pj4+PiB3ZSB0cnkgYW5kIGNhcHR1cmUgdGhlIHZhcmlvdXMgbnVhbmNlcyBvZiBxdWFs
aXR5IHdlIHdpbGwgZW5kIHVwIHdpdGgKPj4+Pj4+PiBhIHZlcnkgY29tcGxleCBtZWNoYW5pc20g
dGhhdCBpcyB1bmxpa2VseSB0byBiZSBhbnkgbW9yZSB1c2VmdWwgaW4KPj4+Pj4+PiByZWFsIGxp
ZmUuIExldCdzIGdvIHdpdGggdGhlIHNpbXBsZSBhcHByb2FjaCBub3cuwqAgSWYsIGFmdGVyIHNv
bWUKPj4+Pj4+PiBkZXBsb3ltZW50IGV4cGVyaWVuY2Ugd2UgcmVhbGl6ZSB0aGF0IHdlIHJlYWxs
eSBkbyBuZWVkIGV4dHJhCj4+Pj4+Pj4gY29tcGxleGl0eSwgd2UgY2FuIGV4dGVuZCB0aGUgbWVj
aGFuaXNtIHRoZW4uCj4+Pj4+Pj4gCj4+Pj4+Pj4gQXQgNDoyOSBQTSArMDEwMCA3LzMvMTUsIE5p
ayBUb21raW5zb24gd3JvdGU6Cj4+wqAgPj4+Pj4KPj4+Pj4+Pj4gVGhhbmtzIGZvciB0aGUgcmVz
cG9uc2VzLgo+Pj4+Pj4+PiAKPj4+Pj4+Pj4gVG8gZGVhbCB3aXRoIHRoZSBpc3N1ZSB3aXRoIGhh
dmluZyBvbmx5IG9yaWdpbmFsL2h1bWFuL2F1dG9tYXRlZCwKPj4+Pj4+Pj4gd2hhdCBhYm91dCB0
aGUgZm9sbG93aW5nPzoKPj4+Pj4+Pj4gCj4+Pj4+Pj4+IAo+Pj4+Pj4+PiB0cmFuc2xhdGlvbi10
eXBlIDo9IHR5cGUtdG9rZW5bICI7IiAicSIgIj0iIHF2YWx1ZSBdCj4+Pj4+Pj4+IHR5cGUtdG9r
ZW4gOj0iaHVtYW4iIC8gImF1dG9tYXRlZCIKPj4+Pj4+Pj4gCj4+Pj4+Pj4+IHdoZXJlIHF2YWx1
ZSBpcyBhIHZhbHVlIGJldHdlZW4gMCBhbmQgMSB3aXRoIGEgZGVmYXVsdCBvZiAwLjUgaWYKPj4+
Pj4+Pj4gbWlzc2luZwo+Pj4+Pj4+PiAKPj4+Pj4+Pj4gZm9yIGV4YW1wbGU6Cj4+Pj4+Pj4+IAo+
Pj4+Pj4+PiBUcmFuc2xhdGlvbi1UeXBlOiBodW1hbjtxPTAuOAo+Pj4+Pj4+PiBUcmFuc2xhdGlv
bi1UeXBlOiBhdXRvbWF0ZWQ7cT0wLjQKPj4+Pj4+Pj4gVHJhbnNsYXRpb24tVHlwZTogaHVtYW4K
Pj4+Pj4+Pj4gCj4+Pj4+Pj4+IFRoZSBUcmFuc2xhdGlvbi1UeXBlIFNIT1VMRCBOT1QgYXBwZWFy
IGluIHRoZSBvcmlnaW5hbAo+Pj4+Pj4+PiAodW50cmFuc2xhdGVkKSBwYXJ0IGJ1dCBpdCBTSE9V
TEQgYXBwZWFyIGluIHRyYW5zbGF0ZWQgY29udGVudC4KPj7CoCA+Pj4+Pj4KPj4+Pj4+Pj4gSGF2
aW5nIHRoaXMgbWlzc2luZyBmcm9tIHRoZSBvcmlnaW5hbCB0ZXh0IGhlbHBzIGlkZW50aWZ5IHdo
aWNoIGlzCj4+Pj4+Pj4+IHRoZSBzb3VyY2UgdG8gYmUgdHJhbnNsYXRlZCBpbnRvIGZ1cnRoZXIg
bGFuZ3VhZ2VzIGlmIHRoZSB1c2VyIG1haWwKPj4+Pj4+Pj4gY2xpZW50IGFsbG93cy4KPj4+Pj4+
Pj4gCj4+Pj4+Pj4+IFRoaXMgZW5hYmxlcyB1cyB0byBkaXNwb3NlIG9mIHRoZSAnb3JpZ2luYWwn
IHZhbHVlIHdoaWNoIGRpZG4ndCBsZW5kCj4+Pj4+Pj4+IGl0c2VsZiB3ZWxsIHRvIGJlaW5nIGdy
YWRlZCBvbiBxdWFsaXR5Lgo+Pj4+Pj4+PiAKPj4+Pj4+Pj4gVGhlIHF2YWx1ZSBjYW4gYmUgc2V0
IGJ5IHRoZSBzZW5kZXIgb3IgcHJvdmlkZWQgYnkgdGhlIHRyYW5zbGF0aW9uCj4+Pj4+Pj4+IHNl
cnZpY2UuCj4+Pj4+Pj4+IAo+Pj4+Pj4+PiBUaGUgZHJhZnQgc3VnZ2VzdHMgdGhhdDoKPj4+Pj4+
Pj4gCj4+Pj4+Pj4+ICJBZGRpdGlvbmFsbHksIGludGVyYWN0aXZlIGltcGxlbWVudGF0aW9ucyBN
QVkgb2ZmZXIgdGhlIHVzZXIgYQo+Pj4+Pj4+PiBjaG9pY2UgZnJvbSBhbW9uZyB0aGUgYXZhaWxh
YmxlIGxhbmd1YWdlcy4iIHNvIHRoZSBxdmFsdWUgbWF5IG5vdAo+Pj4+Pj4+PiBuZWVkIHRvIGJl
IGJ1bGxldHByb29mLgo+Pj4+Pj4+PiAKPj4+Pj4+Pj4gQ29tbWVudHM/Cj4+Pj4+Pj4+IAo+Pj4+
Pj4+PiBOaWsuCj4+Pj4+Pj4+IAo+Pj4+Pj4+PiBPbiAzIEp1bHkgMjAxNSBhdCAwOTo0NiwgR3Vu
bmFyIEhlbGxzdHLDtm0KPj4+Pj4+Pj4gPDxtYWlsdG86Z3VubmFyLmhlbGxzdHJvbUBvbW5pdG9y
LnNlPmd1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5zZT4gd3JvdGU6Cj4+Pj4+Pj4+IAo+Pj4+Pj4+
PiBJIHNlZSBzb21lIHZhbHVlIG9mIHRoaXMga2luZCBvZiBwYXJhbWV0ZXIgYWxzbyBmb3IgdGhl
IHJlYWwtdGltZSBjYXNlLgo+Pj4+Pj4+PiBUaGUgdGltZSBpcyBoZXJlIHdoZW4gaXQgY2FuIGJl
IHBvc3NpYmxlIGluIHNvbWUgc2l0dWF0aW9ucyB0bwo+Pj4+Pj4+PiBzZWxlY3QgYmV0d2VlbiB1
c2luZyBhIGxvdy1jb3N0IGF1dG9tYXRpYyBzcGVlY2gtdG8tdGV4dCBnZW5lcmF0aW9uCj4+Pj4+
Pj4+IGFuZCBhIGhpZ2hlciBjb3N0IGNhcHRpb25lZCB0ZWxlcGhvbnkgb3IgdGV4dC1yZWxheSBz
ZXJ2aWNlIChoaWdoZXIKPj4+Pj4+Pj4gY29zdCBmb3Igc29tZW9uZSwgbm90IGFsd2F5cyB0aGUg
ZW5kLXVzZXIpLgo+Pj4+Pj4+PiAKPj4+Pj4+Pj4gQnV0IEkgYWdyZWUgdGhhdCBpdCBpcyB2ZXJ5
IGhhcmQgdG8gc2V0IGdvb2QgdW5kZXJzdGFuZGFibGUgdmFsdWVzCj4+Pj4+Pj4+IG9uIGEgcGFy
YW1ldGVyIGV4cHJlc3NpbmcgdGhlIHR5cGUgb3IgcXVhbGl0eSBvZiB0aGlzIGtpbmQgb2Ygc2Vy
dmljZS4KPj4+Pj4+Pj4gCj4+Pj4+Pj4+IEd1bm5hcgo+Pj4+Pj4+PiAKPj4+Pj4+Pj4gCj4+Pj4+
Pj4+IAo+Pj4+Pj4+PiBTdGVwaGFuZSBCb3J0em1leWVyIHNrcmV2IGRlbiAyMDE1LTA3LTAzIDA4
OjQ5Ogo+Pj4+Pj4+PiAKPj4+Pj4+Pj4gT24gVGh1LCBKdWwgMDIsIDIwMTUgYXQgMTE6MDk6MzBQ
TSArMDEwMCwKPj4+Pj4+Pj7CoMKgIE5payBUb21raW5zb24KPj4+Pj4+Pj4gPDxtYWlsdG86cmZj
Lm5pay50b21raW5zb25AZ21haWwuY29tPnJmYy5uaWsudG9ta2luc29uQGdtYWlsLmNvbT4gd3Jv
dGUKPj4+Pj4+Pj7CoMKgIGEgbWVzc2FnZSBvZiAxMDkgbGluZXMgd2hpY2ggc2FpZDoKPj4+Pj4+
Pj4gCj4+Pj4+Pj4+IHR5cGUtdG9rZW4gOj0gIm9yaWdpbmFsIiAvICJodW1hbiIgLyAiYXV0b21h
dGVkIgo+Pj4+Pj4+PiAKPj4+Pj4+Pj4gSW4gbWFueSBJRVRGIHdvcmtpbmcgZ3JvdXBzLCB3aGVu
IHRoZXJlIGlzIHN1Y2ggYSBwcm9wb3NhbCwgdGhlcmUgaXMgYQo+Pj4+Pj4+PiBiaWcgZGlzY3Vz
c2lvbiBiZXR3ZWVuIHRoZSByZWdpc3RyeWZ1bGwgYW5kIHRoZSByZWdpc3RyeWxlc3MKPj4+Pj4+
Pj4gcGVvcGxlLiBUaGUgZmlyc3Qgb25lcyBzYXkgdGhlcmUgbXVzdCBiZSBhbiBhdXRob3JpdGF0
aXZlIGxpc3Qgb2YKPj4+Pj4+Pj4gdmFsdWVzIChpbiB0aGUgUkZDIG9yLCBiZXR0ZXIgYmVjYXVz
ZSBtb3JlIGV2b2x2aW5nLCBpbiBhbiBJQU5BCj4+Pj4+Pj4+IHJlZ2lzdHJ5KSBzbyB3ZSBjYW4g
YmUgc3VyZSBvZiB0aGUgaW50ZXJwcmV0YXRpb24gb2YgdmFsdWVzLiBUaGUKPj4+Pj4+Pj4gc2Vj
b25kIG9uZXMgc2F5IHdlIGNhbiBuZXZlciBjYXB0dXJlIGFsbCB0aGUgbnVhbmNlcyBhbmQgc3Vi
dGxldGllcyBvZgo+Pj4+Pj4+PiB0aGUgd29ybGQgaW4gYSBmaXhlZCBsaXN0Lgo+Pj4+Pj4+PiAK
Pj4+Pj4+Pj4gSGVyZSwgSSBhbSBub3Qgc3VyZSB0aGF0IHRoZSBvbmx5IG1lYW5pbmdmdWwgZGlz
dGluY3Rpb24gaXMgYmV0d2Vlbgo+Pj4+Pj4+PiAiaHVtYW4iIGFuZCAiYXV0b21hdGVkIi4gU29t
ZSBodW1hbnMgZG8gYSB2ZXJ5IHBvb3Igam9iLCB0b28uIE9uZQo+Pj4+Pj4+PiBjb3VsZCBzdWdn
ZXN0Ogo+Pj4+Pj4+PiAKPj4+Pj4+Pj4gdHlwZS10b2tlbiA6PSAib3JpZ2luYWwiIC8gInByb2Zl
c3Npb25hbC1odW1hbiIgLyAiYW1hdGV1ci1odW1hbiIgLwo+Pj4+Pj4+PiAiYXV0b21hdGVkLWZp
cnN0LWdlbmVyYXRpb24iIC8gImF1dG9tYXRlZC1hcnRpZmljaWFsLWludGVsbGlnZW5jZSIgLwo+
Pj4+Pj4+PiAiYXV0b21hdGVkLXRoZS1yb2JvdC1pbi1ob2xseXdvb2QtbW92aWVzIgo+Pj4+Pj4+
PiAKPj4+Pj4+Pj4gT3IgZGVjaWRlIHRoYXQgaXQgd2lsbCBiZSB0b28gY29tcGxpY2F0ZWQgYW5k
IHdlIHNob3VsZCBpbnN0ZWFkCj4+Pj4+Pj4+IGFjY2VwdDoKPj4+Pj4+Pj4gCj4+Pj4+Pj4+IHR5
cGUtdG9rZW4gOj0gIm9yaWdpbmFsIiAvIDxmcmVlIHRleHQ+Cj4+Pj4+Pj4+IAo+Pj4+Pj4+PiBU
b3VnaHRzPwo+Pj4+Pj4+PiAKPj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18KPj4+Pj4+Pj4gU0xJTSBtYWlsaW5nIGxpc3QKPj4+Pj4+Pj4gPG1h
aWx0bzpTTElNQGlldGYub3JnPlNMSU1AaWV0Zi5vcmcKPj4+Pj4+Pj4gCj4+Pj4+Pj4+IDxodHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NsaW0+aHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9zbGltCj4+Pj4+Pj4+IAo+Pj4+Pj4+PiAKPj4+Pj4+Pj4gCj4+
Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4+
Pj4+Pj4+IFNMSU0gbWFpbGluZyBsaXN0Cj4+Pj4+Pj4+IDxtYWlsdG86U0xJTUBpZXRmLm9yZz5T
TElNQGlldGYub3JnCj4+Pj4+Pj4+IAo+Pj4+Pj4+PiA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9zbGltPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
c2xpbQo+Pj4+Pj4+PiAKPj4+Pj4+Pj4gCj4+Pj4+Pj4+IAo+Pj4+Pj4+PiAKPj4+Pj4+Pj4gCj4+
Pj4+Pj4+IC0tCj4+Pj4+Pj4+IAo+Pj4+Pj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+Pj4+Pj4+PiBNdWx0aXBsZSBM
YW5ndWFnZSBDb250ZW50IFR5cGUgSW50ZXJuZXQgRHJhZnQ6Cj4+Pj4+Pj4+IAo+Pj4+Pj4+PiA8
aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10b21raW5zb24tbXVsdGlsYW5n
Y29udGVudC8+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10b21raW5zb24t
c2xpbS1tdWx0aWxhbmdjb250ZW50Lwo+PsKgID4+Pj4+Pgo+Pj4+Pj4+PiAtLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+Pj4+
Pj4+PiAKPj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KPj4+Pj4+Pj4gU0xJTSBtYWlsaW5nIGxpc3QKPj4+Pj4+Pj4gU0xJTUBpZXRmLm9yZwo+
Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NsaW0KPj4+Pj4+
PiAKPj4+Pj4+PiAKPj4+Pj4+PiAKPj4+Pj4+IAo+Pj4+PiAKPj4+Pj4gX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4+Pj4gU0xJTSBtYWlsaW5nIGxpc3QK
Pj4+Pj4gU0xJTUBpZXRmLm9yZwo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL3NsaW0KPj4+PiAKPj4+IAo+Pj4gLS0KPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tCj4+PiBHdW5uYXIgSGVsbHN0csO2bQo+Pj4gT21uaXRvcgo+Pj4g
Z3VubmFyLmhlbGxzdHJvbUBvbW5pdG9yLnNlCj4+PiArNDYgNzA4IDIwNCAyODgKPj4+IAo+Pj4g
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj7CoCA+IFNM
SU0gbWFpbGluZyBsaXN0Cj4+PiBTTElNQGlldGYub3JnCj4+PiBodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL3NsaW0KPj4gCj4+IAo+PiBDb250ZW50LVRyYW5zZmVyLUVuY29k
aW5nOiA3Yml0Cj4+IENvbnRlbnQtRGlzcG9zaXRpb246IGF0dGFjaG1lbnQ7IGZpbGVuYW1lPSJz
aWduYXR1cmUuYXNjIgo+PiBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3BncC1zaWduYXR1cmU7
Cj4+IAluYW1lPXNpZ25hdHVyZS5hc2MKPj4gQ29udGVudC1EZXNjcmlwdGlvbjogTWVzc2FnZSBz
aWduZWQgd2l0aCBPcGVuUEdQIHVzaW5nIEdQR01haWwKPj4gCj4+IEF0dGFjaG1lbnQgY29udmVy
dGVkOiBUaUxhbmQ6c2lnbmF0dXJlIDQxNS5hc2MgKMKgwqDCoCAvwqDCoMKgICkgKDAyOEM0MDYx
KQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+PiBT
TElNIG1haWxpbmcgbGlzdAo+PiBTTElNQGlldGYub3JnCj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vc2xpbQo+IAo+IAo+IAo+IC0tIAo+IFJhbmRhbGwgR2VsbGVucwo+
IE9waW5pb25zIGFyZSBwZXJzb25hbDvCoMKgwqAgZmFjdHMgYXJlIHN1c3BlY3Q7wqDCoMKgIEkg
c3BlYWsgZm9yIG15c2VsZiBvbmx5Cj4gLS0tLS0tLS0tLS0tLS0gUmFuZG9tbHkgc2VsZWN0ZWQg
dGFnOiAtLS0tLS0tLS0tLS0tLS0KPiBQcm9ncmVzcyBpcyBtYWRlIG9uIGFsdGVybmF0ZSBGcmlk
YXlzLgo+IAo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Cj4gU0xJTSBtYWlsaW5nIGxpc3QKPiBTTElNQGlldGYub3JnCj4gaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9zbGltCgo=

----_com.android.email_216422982804850
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64

PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0
L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT4KICAgIAo8ZGl2PkkgZG9uJ3Qgc2Vl
IGhvdyBlaXRoZXIgd2F5IGlzIGVuZm9yY2VhYmxlLiBJZiB3ZSBzYXkgdGhlIFBTQVAgaGFzIHRv
IHRha2UgdGhlIGNhbGxlcidzIHRyYW5zbGF0aW9uIHNlcnZpY2UsIGFueSBzZW5zaWJsZSBQU0FQ
IHdpbGwgZmVlbCBmcmVlIHRvIGlnbm9yZSBpdCwgd2hldGhlciBkdWUgdG8gY29zdCwgbGlhYmls
aXR5LCBvciBwcm90ZWN0aW5nIGFnYWluc3QgdGhlIFBTQVAgYmVpbmcgdGhlIHNvdXJjZSBvZiBh
IERvUyBhdHRhY2suIENvbnZlcnNlbHksIGlmIGEgcGFydGljdWxhciBQU0FQIGNvdWxkIHVzZSBh
IGhpbnQgZm9yIGEgdHJhbnNsYXRpb24gc2VydmljZSwgaXQgd291bGQgYmUgaGFuZHkgZm9yIHRo
ZSBjYWxsZXIgdG8gcHJvdmlkZSBvbmUuJm5ic3A7PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48
YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdiBpZD0iY29tcG9zZXJfc2lnbmF0dXJlIj5TZW50
IGZyb20gbXkgbW9iaWxlIGRldmljZS4gVGhhbmtzIGJlIHRvIExFTU9OQURFOiBodHRwOi8vd3d3
LnN0YW5kYXJkc3RyYWNrLmNvbS9pZXRmL2xlbW9uYWRlPC9kaXY+PGJyPjxicj4tLS0tLS0tLSBP
cmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tPGJyPkZyb206IEJyaWFuIFJvc2VuICZsdDtickBicmlh
bnJvc2VuLm5ldCZndDsgPGJyPkRhdGU6IDA3LzA3LzIwMTUgIDI6MjAgUE0gIChHTVQtMDU6MDAp
IDxicj5UbzogUmFuZGFsbCBHZWxsZW5zICZsdDtyYW5keUBxdGkucXVhbGNvbW0uY29tJmd0OyA8
YnI+Q2M6IEVyaWMgQnVyZ2VyICZsdDtlYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbSZndDssIHNs
aW1AaWV0Zi5vcmcgPGJyPlN1YmplY3Q6IFJlOiBbU2xpbV0gVHJhbnNsYXRpb24gUXVhbGl0eSBv
ciB0eXBlIC0gb3Igc2VydmljZSBwcm92aWRlciA8YnI+PGJyPkluIGdlbmVyYWwsIHRoZSBQU0FQ
IHdhbnRzIHRvIHVzZSBpdOKAmXMgYnJpZGdlLCBhbmQgTk9UIGhhdmUgdGhlIHRyYW5zbGF0aW9u
IHNlcnZpY2UgdXNlIGl0cyBicmlkZ2UuJm5ic3A7IFRoZXJlIGFyZSBjbGVhcmx5IGNpcmN1bXN0
YW5jZXMgd2hlcmUgdGhlIFBTQVAgYnJpZGdlIGNhbm5vdCBiZSB1c2VkIGFuZCB3ZSBuZWVkIGEg
d2F5IHRvIG1ha2Ugc3VyZSB0aGUgdHJhbnNsYXRpb24gc2VydmljZeKAmXMgYnJpZGdlIGNhbiBi
ZSB1c2VkLjxicj48YnI+QnJpYW48YnI+PGJyPiZndDsgT24gSnVsIDcsIDIwMTUsIGF0IDE6NTYg
UE0sIFJhbmRhbGwgR2VsbGVucyAmbHQ7cmFuZHlAcXRpLnF1YWxjb21tLmNvbSZndDsgd3JvdGU6
PGJyPiZndDsgPGJyPiZndDsgQXQgNDo0MyBBTSAtMDQwMCA3LzYvMTUsIEVyaWMgQnVyZ2VyIHdy
b3RlOjxicj4mZ3Q7IDxicj4mZ3Q7Jmd0OyZuYnNwOyAmZ3Q7IE9uIEp1bCA2LCAyMDE1LCBhdCAz
OjI0IEFNLCBHdW5uYXIgSGVsbHN0csO2bSAmbHQ7Z3VubmFyLmhlbGxzdHJvbUBvbW5pdG9yLnNl
Jmd0OyB3cm90ZTo8YnI+Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsgT25lIHJlYXNvbiBm
b3IgdGhlIG5lZWQgdG8gY29udmV5IGEgdHJhbnNsYXRpb24gc2VydmljZSBwcm92aWRlciBVUkkg
aXMgdGhhdCB0aGUgZW1lcmdlbmN5IHNlcnZpY2UgUkZDcyA2NDQzIGFuZCA2ODgxIGZvcmJpZHMg
dGhlIGNhbGxpbmcgdXNlciB0byBpbnZva2UgdGhyZWUtcGFydHkgY2FsbGluZy48YnI+Jmd0OyA8
YnI+Jmd0OyBUaGUgdGV4dCB0aGVyZSBpcyBzYXlpbmcgdGhhdCB0aGUgYmVzdCBwcmFjdGljZSBm
b3IgYSBkZXZpY2UgaW5pdGlhdGluZyBhbiBlbWVyZ2VuY3kgY2FsbCBpcyB0byBkaXNhYmxlIHNl
cnZpY2VzIHRoYXQgY291bGQgaW50ZXJydXB0IHRoZSBjYWxsLCBzdWNoIGFzIGNhbGwgd2FpdGlu
ZyBhbmQgdGhpcmQtcGFydHkgY2FsbGluZy4mbmJzcDsgSWYgdGhlIHRoaXJkLXBhcnR5IGNhbGwg
aXMgaW5pdGlhdGVkIGJlZm9yZSBvciBpbiBwYXJhbGxlbCB3aXRoIHRoZSBlbWVyZ2VuY3kgY2Fs
bCwgdGhlIHRleHQgd291bGRuJ3QgYXBwbHkgYW55d2F5LCBhbmQgaWYgdGhlIHRoaXJkLXBhcnR5
IGNhbGwgaXMgaW5pdGlhdGVkIGR1cmluZyB0aGUgZW1lcmdlbmN5IGNhbGwgaW4gb3JkZXIgdG8g
YmV0dGVyIHNlcnZlIHRoZSB1c2VyJ3MgbmVlZHMsIHRoZW4gdGhpcyBpcyBleGFjdGx5IHdoeSB0
aGUgdGV4dCB1c2VzICJTSE9VTEQiIGluc3RlYWQgb2YgIk1VU1QuIiZuYnNwOyBUaGUgd29yZCAi
U0hPVUxEIiBtZWFucyB0aGF0IGEgY2xpZW50IGlzIHN1cHBvc2VkIHRvIGZvbGxvdyB0aGUgZGly
ZWN0aW9uIHVubGVzcyB0aGVyZSBpcyBhbiBvdmVycmlkaW5nIHJlYXNvbiBub3QgdG8sIGFuZCB0
aGUgY29uc2VxdWVuY2VzIG9mIGRvaW5nIHNvIGFyZSB1bmRlcnN0b29kLiZuYnNwOyBCb3RoIG9m
IHRob3NlIGFwcGx5IGluIHRoZSBjYXNlIHVuZGVyIGRpc2N1c3Npb24uPGJyPiZndDsgPGJyPiZn
dDsgPGJyPiZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyA2NDQzIGlzIGluZm9ybWF0aW9uYWwgYW5kIDY4
ODEgaXMgYSBCQ1AuIE5vIHByb2JsZW0gdG8gZG8gc29tZXRoaW5nIHRoYXQgd29ya3MgdGhhdCBp
cyAnZm9yYmlkZGVuLic8YnI+Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyBGb3IgZXhhbXBsZSBS
RkMgNjQ0MywgY2hhcHRlciAxMyBzYXlzICJTZXJ2aWNlcyBzdWNoIGFzIGNhbGwgd2FpdGluZywg
Y2FsbCB0cmFuc2ZlciwgdGhyZWUtd2F5IGNhbGxpbmcsIGFuZCBob2xkIHNob3VsZCBiZSBkaXNh
YmxlZC4iPGJyPiZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyBOb3RlIHRoZSB1c2Ugb2YgJ3Nob3VsZC4n
Jm5ic3A7IEkgZG8gbm90IHRoaW5rIGFueW9uZSB3aWxsIGNvbXBsYWluIGlmIG9uZSBpbnRlcnBy
ZXRzIHRoaXMgYXMsICJTaG91bGQgYmUgZGlzYWJsZWQsIHVubGVzcyB0aGUgdXNlciB3aWxsIGRp
ZSBpZiBzaGUgZG9lcyBub3Qgc2V0dXAgYSB0aHJlZS13YXkgY2FsbCB3aXRoIGhlciB0cmFuc2xh
dGlvbiBzZXJ2aWNlLiI8YnI+Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyBJZiB0aGVuIHRoZSB1
c2VyIGlzIGluIGEgZm9yZWlnbiBsYW5ndWFnZSBlbnZpcm9ubWVudCB3aGVyZSB0aGUgUFNBUCBi
YXJlbHkgY2FuIGhhdmUgYSBjbHVlIG9uIGhvdyB0byBmaW5kIHRoZSByaWdodCByZWxheSBzZXJ2
aWNlLCBhbmQgdGhlIHVzZXIgaGFzIGEgZ29vZCByZWxheSBzZXJ2aWNlIFVSSSBjb25maWd1cmVk
LCB3ZWxsIGNhcGFibGUgb2YgaGFuZGxpbmcgdGhlIHVzZXIncyBsYW5ndWFnZSBhbmQgbW9kYWxp
dHksIHdoYXQgaXMgdGhlbiBiZXN0Pzxicj4mZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyAx
KSBCcmVhayBhZ2FpbnN0IFJGQyA2ODgxIGFuZCA2NDQzIGFuZCBoYXZlIHRoZSB1c2VyIHRlcm1p
bmFsIGludm9rZSB0aGUgdGhyZWUtcGFydHkgY2FsbD8gVGhlIHdvcmRpbmcgaW4gdGhlc2UgUkZD
cyBtYXkgYmUgaW50ZXJwcmV0ZWQgdG8gaGF2ZSBzb21lIHJvb20gZm9yIHN1Y2ggZGV2aWF0aW9u
cy48YnI+Jmd0OyZndDsgPGJyPiZndDsmZ3Q7IEJleW9uZCB0aGUgd29yZGluZyBpbiB0aGUgUkZD
cywgdGhlcmUgaXMgYSByZWFzb24gdGhlIElFVEYgaXMgbm90IHRoZSBwcm90b2NvbCBwb2xpY2Uu
IEluIHJldHJvc3BlY3QsIGl0IG1heSBiZSBzYWZlIHRvIHNheSB0aGUgUkZDcycgc3VnZ2VzdGlv
bnMgYXJlIHdyb25nLjxicj4mZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7IDIpIE9yIGNvbnZleSB0
aGUgcmVsYXkgc2VydmljZSBVUkkgdG8gdGhlIFBTQVAgZm9yIGludm9jYXRpb24uPGJyPiZndDsm
Z3Q7IDxicj4mZ3Q7Jmd0OyBXaHkgbm90Pzxicj4mZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7IDxi
cj4mZ3Q7Jmd0OyZndDsgVGhlIGRpc2N1c3Npb24gc28gZmFyIGxlYWRzIHRvd2FyZHMgY29uY2x1
c2lvbiAxLiBJdCBpcyBvayBmb3IgbWUsIEkganVzdCB3YW50ZWQgaXQgY29uZmlybWVkIGJ5IHNo
b3dpbmcgdGhlIHdob2xlIHNpdHVhdGlvbi48YnI+Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZn
dDsgKHRoZXJlIHdpbGwgYWx3YXlzIGJlIGNvbXBsZW1lbnRpbmcgc2xvdyBtYW51YWwgcHJvY2Vk
dXJlcywgd2hlbiB0aGUgUFNBUCBuZWVkcyB0byBmaWd1cmUgb3V0IGEgcmVhc29uYWJsZSB3YXkg
dG8gaGFuZGxlIHRoZSBjYWxsLCBidXQgdGhpcyBkaXNjdXNzaW9uIGlzIGZvciB0aGUgcmFwaWQg
YXV0b21hdGVkIHdheSB0aGF0IHNob3VsZCBoYW5kbGUgbW9zdCBjYXNlcy4pPGJyPiZndDsmZ3Q7
Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7IC9HdW5uYXI8YnI+Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0
OyZndDsgR3VubmFyIEhlbGxzdHLDtm0gc2tyZXYgZGVuIDIwMTUtMDctMDUgMjI6MzU6PGJyPiZn
dDsmZ3Q7Jmd0OyZndDsgUGF1bCw8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyBZZXMsIEkgYWdyZWUgdGhh
dCBmb3IgbW9zdCBjYXNlcyBpdCBpcyBiZXN0IHRoYXQgdGhlIHBhcnR5LCB3aG8ga25vd3MgYSBz
ZXJ2aWNlIHRoYXQgd2lsbCBkbyB0aGUgdHJhbnNsYXRpb24sIGRvZXMgdGhlIGludm9jYXRpb24u
PGJyPiZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsgQW5kLCB5ZXMgLGluIHRo
YXQgc2NlbmFyaW8gdGhlIDNQQ0MgbWV0aG9kIHNlZW1zIHN1aXRhYmxlLjxicj4mZ3Q7Jmd0OyZn
dDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IE15IHByb3Bvc2FsIHRvIHNlbmQgdGhlIHNlcnZp
Y2UgcHJvdmlkZXIgVVJJIHRvZ2V0aGVyIHdpdGggdGhlIG1vZGFsaXR5IGluZGljYXRpb25zIHdh
cyBmb3IgdGhlIGNhc2Ugd2hlbiB0aGVyZSBhcmUgc3Ryb25nIHBvbGljeSByZWFzb25zIHdoeSBv
bmUgcGFydHkgd291bGQgZG8gdGhlIGludm9jYXRpb24sIGJ1dCBsaXR0bGUgY2hhbmNlIHRoYXQg
dGhhdCBwYXJ0eSB3b3VsZCBoYXZlIGFjY2VzcyB0byBhbiB1cC10by1kYXRlIGluZm9ybWF0aW9u
IG9uIGF2YWlsYWJsZSB0cmFuc2xhdGlvbiBwcm92aWRlcnMuPGJyPiZndDsmZ3Q7Jmd0OyZndDsg
VGhhdCBjb3VsZCBiZSB0aGUgY2FzZSBmb3IgdGhlIGVtZXJnZW5jeSBzZXJ2aWNlIGNhbGxpbmcg
aW4gYSBtdWx0aS1sYW5ndWFnZSBlbnZpcm9ubWVudCwgYWxzbyBpbmNsdWRpbmcgc3VwcG9ydCBm
b3Igc2lnbiBsYW5ndWFnZSB1c2Vycy48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsm
Z3Q7Jmd0OyBTaW5jZSBib3RoIHlvdSBhbmQgUmFuZGFsbCB0aGluayBpdCBpcyBub3QgZG9hYmxl
LCB3ZSBjYW4gdHJ5IHRvIHVzZSB0aGUgcHJpbmNpcGxlIHRoYXQgdGhlIHBhcnR5LCB3aG8ga25v
d3MgYSBzZXJ2aWNlIHRoYXQgd2lsbCBkbyB0aGUgdHJhbnNsYXRpb24sIGRvZXMgdGhlIGludm9j
YXRpb24uPGJyPiZndDsmZ3Q7Jm5ic3A7ICZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsgVGhh
dCBicmluZ3MgdXMgYmFjayB0byBhIG5lZWQgZm9yIG1vcmUgc3RyaW5nZW50IGxhbmd1YWdlL21v
ZGFsaXR5IG5lZ290aWF0aW9uIGluIG9yZGVyIHRvIGF2b2lkIGJvdGggZG91YmxlIGludm9jYXRp
b24gb2Ygc2VydmljZXMgd2hlbiBvbmUgb3Igbm9uZSBpcyByZXF1aXJlZCwgYW5kIGFsc28gYXZv
aWQgbm8gaW52b2NhdGlvbiB3aGVuIG9uZSBpcyBuZWVkZWQuPGJyPiZndDsmZ3Q7Jmd0OyZndDsg
PGJyPiZndDsmZ3Q7Jmd0OyZndDsgUGF1bCBLeXppdmF0IHNrcmV2IGRlbiAyMDE1LTA3LTA1IDE4
OjIwOjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBHdW5uYXIsPGJyPiZndDsmZ3Q7Jmd0OyZndDsm
Z3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIHVuZGVyc3RhbmQgd2hhdCB5b3UgYXJlIHN1
Z2dlc3RpbmcsIGJ1dCBJIGRvbid0IGJlbGlldmUgaXQgaXMgd29ya2FibGUuIFRoaXMgc2VlbXMg
dG8gbWVhbiB0aGF0IHRoZSBjYWxsZXIgd291bGQgc2VsZWN0IHRoZSBzZXJ2aWNlIHdoaWxlIHRo
ZSBjYWxsZWUgd291bGQgZW5nYWdlIHRoZSBzZXJ2aWNlIGluIHRoZSBjYWxsIGlmIG5lZWRlZC4g
WWV0IGl0IGlzIGxpa2VseSB0byBiZSB0aGUgY2FsbGVyIHdobyBoYXMgYSBidXNpbmVzcyByZWxh
dGlvbnNoaXAgd2l0aCB0aGUgc2VydmljZSwgd2hpbGUgdGhlIGNhbGxlZSBkb2VzIG5vdC4gR2V0
cyBjb21wbGljYXRlZCBxdWlja2x5Ljxicj4mZ3Q7Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDs8YnI+
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSVNUTSBpdCBtYWtlcyBtb3JlIHNlbnNlIHRvIGZpcnN0IGZp
Z3VyZSBvdXQgd2hhdCBpcy9pc24ndCBwb3NzaWJsZSB3aXRob3V0IHRyYW5zbGF0aW9uLCBhbmQg
dGhlbiBmb3IgYSBwYXJ0eSB0aGF0IGZpbmRzIGEgdHJhbnNsYXRpb24gc2VydmljZSBiZW5lZmlj
aWFsIHRvIGVuZ2FnZSBvbmUuIFRoZW4gdGhlIG9ubHkgY29uY2VybiBpcyB0aGF0IGJvdGggcGFy
dGllcyBkb24ndCBpbmRlcGVuZGVudGx5IHRyeSB0byBpbnRyb2R1Y2UgZXF1aXZhbGVudCB0cmFu
c2xhdGlvbiBzZXJ2aWNlcy48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7IEZvciBpbnN0YW5jZSwgYSBkZWFmIGNhbGxlciBtaWdodCBvZmZlciB2aWRlbyBt
ZWRpYSBtYXJrZWQgZm9yIHNpZ24gbGFuZ3VhZ2UsIGFuZCBhdWRpbyBtZWRpYSBvbiBob2xkLiBJ
ZiB0aGUgYW5zd2VyIGRvZXNuJ3QgYWNjZXB0IHRoZSB2aWRlbywgb3IgZG9lc24ndCBpbmRpY2F0
ZSBzdXBwb3J0IGZvciBzaWduIGxhbmd1YWdlLCB0aGUgY2FsbGVyIGNvdWxkIHRoZW4gY29uZmVy
ZW5jZSBpbiB0cmFuc2xhdGlvbiBzZXJ2aWNlLCB1c2luZyB0aGUgM3BjYyB0cmFuc2NvZGluZyBt
b2RlbCBzcGVjaWZpZWQgaW4gcmZjNTM2OS4gKElmIHRoYXQgd2lsbCB0YWtlIHRpbWUsIHRoZSBk
ZWFmIGNhbGxlcidzIFVBIGNvdWxkIHN0cmVhbSByZWNvcmRlZCBtZWRpYSBvdmVyIHRoZSBhdWRp
byBjaGFubmVsIGluIHRoZSBtZWFudGltZS4pPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4m
Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPciwgdG8gZ2V0IGZhbmNpZXIsIGl0IHdvdWxkIGJlIHBvc3Np
YmxlIHRvIHVzZSBwcmVjb25kaXRpb25zIHRvIGRlZmVyIGFsZXJ0aW5nIHRoZSBjYWxsZWUgdW50
aWwgdGhpcyBpcyBhbGwgc29ydGVkIG91dC48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7IE15IHBvaW50IGlzIHRvIGxldCB0aGUgcGFydGljaXBhbnQgd2hv
IHdhbnRzIHRyYW5zbGF0aW9uIGhhbmRsZSB0byBzZXR1cCBvZiB0cmFuc2xhdGlvbiByYXRoZXIg
dGhhbiBkZXBlbmRpbmcgb24gdGhlIG90aGVyIHBhcnR5IHRvIGRvIHNvbWV0aGluZy48YnI+Jmd0
OyZndDsmZ3Q7Jmd0OyBPSywgaXQgbWlnaHQgYmUgbGlrZWx5IHRoYXQgYm90aCBwYXJ0aWVzICJ3
YW50IiB0cmFuc2xhdGlvbiwgYnV0IG9uZSBoYXMgYmV0dGVyIGtub3dsZWRnZSBhYm91dCBob3cg
dG8gZ2V0IHRoZSByZXF1aXJlZCBzZXJ2aWNlIGFuZCBoYXMgYnVzaW5lc3MgcmVsYXRpb25zIHdp
dGggdGhlIHNlcnZpY2UuIFNvIHRoZW4gaXQgaXMgcHJlZmVycmVkIHRoYXQgdGhhdCBwYXJ0eSBp
bnZva2VzLjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IEdvb2Q8YnI+
Jmd0OyZndDsmZ3Q7Jmd0OyAvR3VubmFyPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBUaGFua3MsPGJyPiZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFBhdWw8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg
PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIDcvNS8xNSAyOjQ4IEFNLCBHdW5uYXIgSGVsbHN0
csO2bSB3cm90ZTo8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEFub3RoZXIgb3Bwb3J0dW5p
dHkgd291bGQgYmUgdG8gY29udmV5IGEgVVJJIHRvIHRoZSBzZXJ2aWNlIHByb3ZpZGVyIHdobzxi
cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZGlkIChmb3IgbWFpbCkgb3IgY2FuIGRvKGZvciBy
ZWFsLXRpbWUpIHRoZSB0cmFuc2xhdGlvbi48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRo
ZW4gZXhwZXJpZW5jZSB3aXRoIGRpZmZlcmVudCBzZXJ2aWNlIHByb3ZpZGVyJ3MgcHJvZHVjdGlv
biBjb3VsZCBnaXZlPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzb21lIGlkZWEgb2YgdGhl
IGV4cGVjdGVkIHF1YWxpdHkuPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIGNhbiBzZWUg
Z3JlYXQgdmFsdWUgaW4gdGhhdCBmb3IgdGhlIHJlYWwtdGltZSBjYXNlLCB3aGVuIHRoZSBjYWxs
aW5nPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB1c2VyIGhhcyBhIGZhdm91cml0ZSB0cmFu
c2xhdG9yIChlLmcuIHJlbGF5IHNlcnZpY2UpLCBhbmQgcHJvdmlkZXMgdGhhdDxicj4mZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0OyZndDsgYXMgYSBoaW50IGlmIGxhbmd1YWdlcyBvciBtb2RhbGl0aWVzIGlu
IHRoZSBjYWxsIGRvZXMgbm90IG1hdGNoLiBUaGVuPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
OyB0aGUgY2FsbGVlIGRvIG5vdCBuZWVkIHRvIGp1c3QgdGFrZSBhIHNlcnZpY2UgcHJvdmlkZXIg
YnkgY2hhbmNlIHRoYXQ8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNlZW0gdG8gbWF0Y2gg
dGhlIGxhbmd1YWdlL21vZGFsaXR5IHByb2ZpbGUgYnV0IGNhbiB0YWtlIHRoZSBvbmU8YnI+Jmd0
OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHByb3Bvc2VkIGJ5IHRoZSBjYWxsZXIuPGJyPiZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEFmdGVyIHdvcmtp
bmcgd2l0aCB0aGUgbmVlZHMgZm9yIGVtZXJnZW5jeSBzZXJ2aWNlcyB0byB3b3JrIGFjcm9zczxi
cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgRXVyb3BlIGZvciBzb21lIHRpbWUgbm93LCBJIHRo
aW5rIHRoaXMgaXMgb25lIG9mIHRoZSBmZXcgd29ya2FibGU8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7IHNvbHV0aW9ucy4gVGhlIHVzZXIgZXhwcmVzc2VzIGJvdGggdGhlIGxhbmd1YWdlL21v
ZGFsaXR5IG5lZWRzIGFuZDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcHJvdmlkZXMgYSBV
UkkgdG8gYSBmYXZvdXJpdGUgdHJhbnNsYXRpb24gc2VydmljZSBwcm92aWRlciwgYW5kIHRoZTxi
cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY2FsbGVlIHRyaWVzIHRvIGZ1bGZpbGwgdGhlIGxh
bmd1YWdlL21vZGFsaXR5IG5lZWRzIGVpdGhlciBieSBhIG1hdGNoaW5nPGJyPiZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0OyBvcmlnaW5hbCBjYWxsIHRha2VyIG9yIGJ5IGludm9raW5nIHRoZSBwcm9w
b3NlZCB0cmFuc2xhdGlvbiBwcm92aWRlci48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxi
cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgL0d1bm5hcjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7IFJhbmRhbGwgR2VsbGVucyBza3JldiBkZW4gMjAxNS0wNy0wNSAwMzo0OTo8YnI+Jmd0
OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBNeSByZWNvbGxlY3Rpb24gaXMgdGhhdCB0aGlzIHdh
cyBkaXNjdXNzZWQgaW4gZW1haWwgcHJpb3IgdG8gRGFsbGFzLDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7IGJ1dCB0aGF0J3Mgbm90IGltcG9ydGFudC48YnI+Jmd0OyZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIGFtIGEgc3Ry
b25nIHByb3BvbmVudCBvZiBrZWVwaW5nIHRoaW5ncyBhcyBzaW1wbGUgYXMgcG9zc2libGUsPGJy
PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcHJvdmlkZWQgdGhlcmUgaXMgYSB3YXkgdG8g
ZXh0ZW5kIHRoZW0gaWYgZXhwZXJpZW5jZSBzaG93cyB0aGF0IGl0IGlzPGJyPiZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0OyZndDsgbmVlZGVkLiZuYnNwOyBTbywgSSB0aGluayB3ZSBzaG91bGQgc3Rp
Y2sgd2l0aCB0aGUgb3JpZ2luYWwgc3VnZ2VzdGlvbiBvZjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7IHRocmVlIHZhbHVlcyAoIm9yaWdpbmFsIiwgImh1bWFuIiwgImF1dG9tYXRlZCIp
LiBUaGlzIGlzIHNpbXBsZSBlbm91Z2g8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0
byBiZSBpbXBsZW1lbnRhYmxlIGFuZCBmdW5jdGlvbmFsIGVub3VnaCB0byBiZSB1c2VmdWwgaW4g
cHJvdmlkaW5nIGE8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBoaW50IHRoYXQgbWF5
IGhlbHAgdGhlIGNsaWVudCBjaG9vc2UgdGhlIGJlc3QgdmVyc2lvbiBmb3IgdGhlIHVzZXIuIElm
PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgd2UgdHJ5IGFuZCBjYXB0dXJlIHRoZSB2
YXJpb3VzIG51YW5jZXMgb2YgcXVhbGl0eSB3ZSB3aWxsIGVuZCB1cCB3aXRoPGJyPiZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYSB2ZXJ5IGNvbXBsZXggbWVjaGFuaXNtIHRoYXQgaXMgdW5s
aWtlbHkgdG8gYmUgYW55IG1vcmUgdXNlZnVsIGluPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
OyZndDsgcmVhbCBsaWZlLiBMZXQncyBnbyB3aXRoIHRoZSBzaW1wbGUgYXBwcm9hY2ggbm93LiZu
YnNwOyBJZiwgYWZ0ZXIgc29tZTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRlcGxv
eW1lbnQgZXhwZXJpZW5jZSB3ZSByZWFsaXplIHRoYXQgd2UgcmVhbGx5IGRvIG5lZWQgZXh0cmE8
YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjb21wbGV4aXR5LCB3ZSBjYW4gZXh0ZW5k
IHRoZSBtZWNoYW5pc20gdGhlbi48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBBdCA0OjI5IFBNICswMTAwIDcvMy8xNSwgTmlr
IFRvbWtpbnNvbiB3cm90ZTo8YnI+Jmd0OyZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8
YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhhbmtzIGZvciB0aGUgcmVzcG9u
c2VzLjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVG8gZGVhbCB3aXRoIHRoZSBpc3N1ZSB3aXRoIGhhdmluZyBv
bmx5IG9yaWdpbmFsL2h1bWFuL2F1dG9tYXRlZCw8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0OyZndDsgd2hhdCBhYm91dCB0aGUgZm9sbG93aW5nPzo8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4m
Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0cmFuc2xhdGlvbi10eXBlIDo9IHR5cGUt
dG9rZW5bICI7IiAicSIgIj0iIHF2YWx1ZSBdPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7IHR5cGUtdG9rZW4gOj0iaHVtYW4iIC8gImF1dG9tYXRlZCI8YnI+Jmd0OyZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
IHdoZXJlIHF2YWx1ZSBpcyBhIHZhbHVlIGJldHdlZW4gMCBhbmQgMSB3aXRoIGEgZGVmYXVsdCBv
ZiAwLjUgaWY8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbWlzc2luZzxicj4m
Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm
Z3Q7Jmd0OyZndDsgZm9yIGV4YW1wbGU6PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm
Z3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUcmFuc2xhdGlvbi1UeXBl
OiBodW1hbjtxPTAuODxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUcmFuc2xh
dGlvbi1UeXBlOiBhdXRvbWF0ZWQ7cT0wLjQ8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
OyZndDsgVHJhbnNsYXRpb24tVHlwZTogaHVtYW48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSBUcmFuc2xh
dGlvbi1UeXBlIFNIT1VMRCBOT1QgYXBwZWFyIGluIHRoZSBvcmlnaW5hbDxicj4mZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAodW50cmFuc2xhdGVkKSBwYXJ0IGJ1dCBpdCBTSE9VTEQg
YXBwZWFyIGluIHRyYW5zbGF0ZWQgY29udGVudC48YnI+Jmd0OyZndDsmbmJzcDsgJmd0OyZndDsm
Z3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEhhdmlu
ZyB0aGlzIG1pc3NpbmcgZnJvbSB0aGUgb3JpZ2luYWwgdGV4dCBoZWxwcyBpZGVudGlmeSB3aGlj
aCBpczxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGUgc291cmNlIHRvIGJl
IHRyYW5zbGF0ZWQgaW50byBmdXJ0aGVyIGxhbmd1YWdlcyBpZiB0aGUgdXNlciBtYWlsPGJyPiZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNsaWVudCBhbGxvd3MuPGJyPiZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0OyBUaGlzIGVuYWJsZXMgdXMgdG8gZGlzcG9zZSBvZiB0aGUgJ29yaWdpbmFsJyB2YWx1ZSB3
aGljaCBkaWRuJ3QgbGVuZDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpdHNl
bGYgd2VsbCB0byBiZWluZyBncmFkZWQgb24gcXVhbGl0eS48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSBx
dmFsdWUgY2FuIGJlIHNldCBieSB0aGUgc2VuZGVyIG9yIHByb3ZpZGVkIGJ5IHRoZSB0cmFuc2xh
dGlvbjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzZXJ2aWNlLjxicj4mZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0OyZndDsgVGhlIGRyYWZ0IHN1Z2dlc3RzIHRoYXQ6PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAiQWRkaXRp
b25hbGx5LCBpbnRlcmFjdGl2ZSBpbXBsZW1lbnRhdGlvbnMgTUFZIG9mZmVyIHRoZSB1c2VyIGE8
YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY2hvaWNlIGZyb20gYW1vbmcgdGhl
IGF2YWlsYWJsZSBsYW5ndWFnZXMuIiBzbyB0aGUgcXZhbHVlIG1heSBub3Q8YnI+Jmd0OyZndDsm
Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbmVlZCB0byBiZSBidWxsZXRwcm9vZi48YnI+Jmd0OyZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7IENvbW1lbnRzPzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgTmlrLjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT24g
MyBKdWx5IDIwMTUgYXQgMDk6NDYsIEd1bm5hciBIZWxsc3Ryw7ZtPGJyPiZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDsmbHQ7bWFpbHRvOmd1bm5hci5oZWxsc3Ryb21Ab21uaXRv
ci5zZSZndDtndW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iuc2UmZ3Q7IHdyb3RlOjxicj4mZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
OyZndDsgSSBzZWUgc29tZSB2YWx1ZSBvZiB0aGlzIGtpbmQgb2YgcGFyYW1ldGVyIGFsc28gZm9y
IHRoZSByZWFsLXRpbWUgY2FzZS48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg
VGhlIHRpbWUgaXMgaGVyZSB3aGVuIGl0IGNhbiBiZSBwb3NzaWJsZSBpbiBzb21lIHNpdHVhdGlv
bnMgdG88YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2VsZWN0IGJldHdlZW4g
dXNpbmcgYSBsb3ctY29zdCBhdXRvbWF0aWMgc3BlZWNoLXRvLXRleHQgZ2VuZXJhdGlvbjxicj4m
Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhbmQgYSBoaWdoZXIgY29zdCBjYXB0aW9u
ZWQgdGVsZXBob255IG9yIHRleHQtcmVsYXkgc2VydmljZSAoaGlnaGVyPGJyPiZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNvc3QgZm9yIHNvbWVvbmUsIG5vdCBhbHdheXMgdGhlIGVu
ZC11c2VyKS48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEJ1dCBJIGFncmVlIHRoYXQgaXQgaXMgdmVyeSBoYXJk
IHRvIHNldCBnb29kIHVuZGVyc3RhbmRhYmxlIHZhbHVlczxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0OyBvbiBhIHBhcmFtZXRlciBleHByZXNzaW5nIHRoZSB0eXBlIG9yIHF1YWxp
dHkgb2YgdGhpcyBraW5kIG9mIHNlcnZpY2UuPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBHdW5uYXI8YnI+Jmd0
OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU3RlcGhhbmUgQm9ydHptZXllciBza3JldiBkZW4g
MjAxNS0wNy0wMyAwODo0OTo8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJy
PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIFRodSwgSnVsIDAyLCAyMDE1IGF0
IDExOjA5OjMwUE0gKzAxMDAsPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5i
c3A7Jm5ic3A7IE5payBUb21raW5zb248YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn
dDsgJmx0OyZsdDttYWlsdG86cmZjLm5pay50b21raW5zb25AZ21haWwuY29tJmd0O3JmYy5uaWsu
dG9ta2luc29uQGdtYWlsLmNvbSZndDsgd3JvdGU8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0OyZndDsmbmJzcDsmbmJzcDsgYSBtZXNzYWdlIG9mIDEwOSBsaW5lcyB3aGljaCBzYWlkOjxi
cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0OyZndDsgdHlwZS10b2tlbiA6PSAib3JpZ2luYWwiIC8gImh1bWFuIiAvICJhdXRv
bWF0ZWQiPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJbiBtYW55IElFVEYgd29ya2luZyBncm91cHMsIHdoZW4g
dGhlcmUgaXMgc3VjaCBhIHByb3Bvc2FsLCB0aGVyZSBpcyBhPGJyPiZndDsmZ3Q7Jmd0OyZndDsm
Z3Q7Jmd0OyZndDsmZ3Q7IGJpZyBkaXNjdXNzaW9uIGJldHdlZW4gdGhlIHJlZ2lzdHJ5ZnVsbCBh
bmQgdGhlIHJlZ2lzdHJ5bGVzczxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBw
ZW9wbGUuIFRoZSBmaXJzdCBvbmVzIHNheSB0aGVyZSBtdXN0IGJlIGFuIGF1dGhvcml0YXRpdmUg
bGlzdCBvZjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB2YWx1ZXMgKGluIHRo
ZSBSRkMgb3IsIGJldHRlciBiZWNhdXNlIG1vcmUgZXZvbHZpbmcsIGluIGFuIElBTkE8YnI+Jmd0
OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVnaXN0cnkpIHNvIHdlIGNhbiBiZSBzdXJl
IG9mIHRoZSBpbnRlcnByZXRhdGlvbiBvZiB2YWx1ZXMuIFRoZTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyBzZWNvbmQgb25lcyBzYXkgd2UgY2FuIG5ldmVyIGNhcHR1cmUgYWxs
IHRoZSBudWFuY2VzIGFuZCBzdWJ0bGV0aWVzIG9mPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7IHRoZSB3b3JsZCBpbiBhIGZpeGVkIGxpc3QuPGJyPiZndDsmZ3Q7Jmd0OyZndDsm
Z3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBIZXJl
LCBJIGFtIG5vdCBzdXJlIHRoYXQgdGhlIG9ubHkgbWVhbmluZ2Z1bCBkaXN0aW5jdGlvbiBpcyBi
ZXR3ZWVuPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICJodW1hbiIgYW5kICJh
dXRvbWF0ZWQiLiBTb21lIGh1bWFucyBkbyBhIHZlcnkgcG9vciBqb2IsIHRvby4gT25lPGJyPiZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNvdWxkIHN1Z2dlc3Q6PGJyPiZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0OyB0eXBlLXRva2VuIDo9ICJvcmlnaW5hbCIgLyAicHJvZmVzc2lvbmFsLWh1bWFuIiAvICJh
bWF0ZXVyLWh1bWFuIiAvPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICJhdXRv
bWF0ZWQtZmlyc3QtZ2VuZXJhdGlvbiIgLyAiYXV0b21hdGVkLWFydGlmaWNpYWwtaW50ZWxsaWdl
bmNlIiAvPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICJhdXRvbWF0ZWQtdGhl
LXJvYm90LWluLWhvbGx5d29vZC1tb3ZpZXMiPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPciBkZWNpZGUgdGhh
dCBpdCB3aWxsIGJlIHRvbyBjb21wbGljYXRlZCBhbmQgd2Ugc2hvdWxkIGluc3RlYWQ8YnI+Jmd0
OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYWNjZXB0Ojxicj4mZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdHlw
ZS10b2tlbiA6PSAib3JpZ2luYWwiIC8gJmx0O2ZyZWUgdGV4dCZndDs8YnI+Jmd0OyZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
IFRvdWdodHM/PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTTElN
IG1haWxpbmcgbGlzdDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7bWFp
bHRvOlNMSU1AaWV0Zi5vcmcmZ3Q7U0xJTUBpZXRmLm9yZzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmx0O2h0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2xpbSZndDtodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NsaW08YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU0xJTSBtYWlsaW5nIGxpc3Q8YnI+Jmd0
OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmx0O21haWx0bzpTTElNQGlldGYub3JnJmd0
O1NMSU1AaWV0Zi5vcmc8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDtodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL3NsaW0mZ3Q7aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9zbGltPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn
dDsgLS08YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7IE11bHRpcGxlIExhbmd1YWdlIENvbnRlbnQgVHlwZSBJbnRlcm5ldCBEcmFmdDo8
YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsm
Z3Q7Jmd0OyZndDsmZ3Q7ICZsdDtodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0
LXRvbWtpbnNvbi1tdWx0aWxhbmdjb250ZW50LyZndDtodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5v
cmcvZG9jL2RyYWZ0LXRvbWtpbnNvbi1zbGltLW11bHRpbGFuZ2NvbnRlbnQvPGJyPiZndDsmZ3Q7
Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8
YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
OyZndDsgU0xJTSBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn
dDsgU0xJTUBpZXRmLm9yZzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBodHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NsaW08YnI+Jmd0OyZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4m
Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZn
dDsgU0xJTSBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU0xJTUBpZXRmLm9y
Zzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL3NsaW08YnI+Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7
Jmd0OyZndDsgLS08YnI+Jmd0OyZndDsmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tPGJyPiZndDsmZ3Q7Jmd0OyBHdW5uYXIgSGVsbHN0csO2bTxicj4mZ3Q7Jmd0
OyZndDsgT21uaXRvcjxicj4mZ3Q7Jmd0OyZndDsgZ3VubmFyLmhlbGxzdHJvbUBvbW5pdG9yLnNl
PGJyPiZndDsmZ3Q7Jmd0OyArNDYgNzA4IDIwNCAyODg8YnI+Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7
Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188
YnI+Jmd0OyZndDsmbmJzcDsgJmd0OyBTTElNIG1haWxpbmcgbGlzdDxicj4mZ3Q7Jmd0OyZndDsg
U0xJTUBpZXRmLm9yZzxicj4mZ3Q7Jmd0OyZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9zbGltPGJyPiZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsgQ29u
dGVudC1UcmFuc2Zlci1FbmNvZGluZzogN2JpdDxicj4mZ3Q7Jmd0OyBDb250ZW50LURpc3Bvc2l0
aW9uOiBhdHRhY2htZW50OyBmaWxlbmFtZT0ic2lnbmF0dXJlLmFzYyI8YnI+Jmd0OyZndDsgQ29u
dGVudC1UeXBlOiBhcHBsaWNhdGlvbi9wZ3Atc2lnbmF0dXJlOzxicj4mZ3Q7Jmd0OyAJbmFtZT1z
aWduYXR1cmUuYXNjPGJyPiZndDsmZ3Q7IENvbnRlbnQtRGVzY3JpcHRpb246IE1lc3NhZ2Ugc2ln
bmVkIHdpdGggT3BlblBHUCB1c2luZyBHUEdNYWlsPGJyPiZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyBB
dHRhY2htZW50IGNvbnZlcnRlZDogVGlMYW5kOnNpZ25hdHVyZSA0MTUuYXNjICgmbmJzcDsmbmJz
cDsmbmJzcDsgLyZuYnNwOyZuYnNwOyZuYnNwOyApICgwMjhDNDA2MSk8YnI+Jmd0OyZndDsgX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Jmd0OyZndDsg
U0xJTSBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyZndDsgU0xJTUBpZXRmLm9yZzxicj4mZ3Q7Jmd0OyBo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NsaW08YnI+Jmd0OyA8YnI+Jmd0
OyA8YnI+Jmd0OyA8YnI+Jmd0OyAtLSA8YnI+Jmd0OyBSYW5kYWxsIEdlbGxlbnM8YnI+Jmd0OyBP
cGluaW9ucyBhcmUgcGVyc29uYWw7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZhY3RzIGFyZSBzdXNwZWN0
OyZuYnNwOyZuYnNwOyZuYnNwOyBJIHNwZWFrIGZvciBteXNlbGYgb25seTxicj4mZ3Q7IC0tLS0t
LS0tLS0tLS0tIFJhbmRvbWx5IHNlbGVjdGVkIHRhZzogLS0tLS0tLS0tLS0tLS0tPGJyPiZndDsg
UHJvZ3Jlc3MgaXMgbWFkZSBvbiBhbHRlcm5hdGUgRnJpZGF5cy48YnI+Jmd0OyA8YnI+Jmd0OyBf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7IFNM
SU0gbWFpbGluZyBsaXN0PGJyPiZndDsgU0xJTUBpZXRmLm9yZzxicj4mZ3Q7IGh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2xpbTxicj48YnI+PC9ib2R5PjwvaHRtbD4=

----_com.android.email_216422982804850--



From nobody Tue Jul  7 14:00:44 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5841ACD03 for ; Tue,  7 Jul 2015 14:00:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.821
X-Spam-Level: 
X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham
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 XRDkF1hwiIqb for ; Tue,  7 Jul 2015 14:00:38 -0700 (PDT)
Received: from mail-qk0-f172.google.com (mail-qk0-f172.google.com [209.85.220.172]) (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 9FFD21ACCFF for ; Tue,  7 Jul 2015 14:00:38 -0700 (PDT)
Received: by qkhu186 with SMTP id u186so149591298qkh.0 for ; Tue, 07 Jul 2015 14:00:38 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=w5pkNIzl7Eg3kBx+BStY35Y9iV+HE8zXN3LFYd/bsCc=; b=BPk67g5haJ/yyAWep3Tkhaq+B4M/ovi8eEA2FA0eihob71Sc/Gry6dhB6L/iiw2Suw dnObI41Vb35i/IcCpRHJi/93L8vyMNCjAh4+8NU6RNAir/BqN0/zOTqVlkKh5HeXMwbR 0VX1JdrofGf+UDas5bvhnPpB71nMFHNJ2WPoHzpa2CScrMu3IOykspCnqbqLVTFJjP3v whU3WkiN64hsfRjny5mh5qAZxqNIY7pBorIsQPBOXO65Hp/Vrd+YZNFHklu4gKSPehEw fR+a19IZ0rMQmFMFOn4MYwr0N60xJ/bxNidSlpCztnPCKkza0Hpp6dkN0jgPxw7EXzKP qZDw==
X-Gm-Message-State: ALoCoQkK9V1urmjdFlRT6CNQwRWgYr4+YEX+Z7n9gZwaoT61ksDSmMV4kJMt202m/PFZuJHoB1JC
X-Received: by 10.55.22.5 with SMTP id g5mr9945219qkh.45.1436302837829; Tue, 07 Jul 2015 14:00:37 -0700 (PDT)
Received: from [10.33.193.32] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id d10sm11762793qhc.9.2015.07.07.14.00.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Jul 2015 14:00:37 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: Brian Rosen 
In-Reply-To: 
Date: Tue, 7 Jul 2015 17:00:34 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <5E0D2DE0-FC2F-4681-B05C-D924A44B43E8@brianrosen.net>
References: 
To: Eric Burger 
X-Mailer: Apple Mail (2.2102)
Archived-At: 
Cc: "slim@ietf.org" 
Subject: Re: [Slim] Translation Quality or type - or service provider
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Jul 2015 21:00:42 -0000

Of course it=E2=80=99s not enforceable, but since there are a finite =
number of VRS providers, the PSAP community can prevail upon them to do =
the right thing.  The worst case, where there are two bridges, is =
annoying but not fatal.

What we need is clear labeling of what is requested, something we =
don=E2=80=99t have now, but slim will provide.

The current NENA documents say that the outgoing proxy server adds a =
Referred-By header to the call.  The PSAP may use the URI of the =
Referred-by to bridge in the referring party, which is the CA at the =
outgoing proxy of the VRS provider.  This works exactly the way the =
current U.S. regulations say it should work, where first a two way is =
established between the CA and the caller and then the call is extended =
as a 9-1-1 call.  It wouldn=E2=80=99t work as well in Gunnar=E2=80=99s =
environment where the SIP service provider isn=E2=80=99t the relay =
provider, but something similar could work.

For =E2=80=9Cdirect routing=E2=80=9D, where you don=E2=80=99t get the =
2-way before a 3-way is established, the VRS provider (in the US) can =
still add the Referred-by, which would allow the PSAP to either use it, =
or it=E2=80=99s own choice of relay provider.  It=E2=80=99s a bit weird, =
in that there is no actual referral, it=E2=80=99s more of a =E2=80=9Cif =
you want me, here is how to get me=E2=80=9D, but it would clearly work.

We might be better off with another mechanism that expressly states =E2=80=
=9CA translation service is available at this URI=E2=80=9D, which is the =
idea Gunnar has.  I think that is additive, not replacing the current =
proposed language tag mechanism.  You could imagine various forms of =
that which would include the source and destination language tags.  An =
out of country visitor might request translation to French, but if he is =
in Brazil, his preferred English to French service might not be helpful.

Brian

> On Jul 7, 2015, at 4:20 PM, Eric Burger  =
wrote:
>=20
> I don't see how either way is enforceable. If we say the PSAP has to =
take the caller's translation service, any sensible PSAP will feel free =
to ignore it, whether due to cost, liability, or protecting against the =
PSAP being the source of a DoS attack. Conversely, if a particular PSAP =
could use a hint for a translation service, it would be handy for the =
caller to provide one.=20
>=20
>=20
>=20
> Sent from my mobile device. Thanks be to LEMONADE: =
http://www.standardstrack.com/ietf/lemonade
>=20
>=20
> -------- Original message --------
> From: Brian Rosen =20
> Date: 07/07/2015 2:20 PM (GMT-05:00)=20
> To: Randall Gellens =20
> Cc: Eric Burger , slim@ietf.org=20
> Subject: Re: [Slim] Translation Quality or type - or service provider=20=

>=20
> In general, the PSAP wants to use it=E2=80=99s bridge, and NOT have =
the translation service use its bridge.  There are clearly circumstances =
where the PSAP bridge cannot be used and we need a way to make sure the =
translation service=E2=80=99s bridge can be used.
>=20
> Brian
>=20
> > On Jul 7, 2015, at 1:56 PM, Randall Gellens  =
wrote:
> >=20
> > At 4:43 AM -0400 7/6/15, Eric Burger wrote:
> >=20
> >>  > On Jul 6, 2015, at 3:24 AM, Gunnar Hellstr=C3=B6m =
 wrote:
> >>>=20
> >>> One reason for the need to convey a translation service provider =
URI is that the emergency service RFCs 6443 and 6881 forbids the calling =
user to invoke three-party calling.
> >=20
> > The text there is saying that the best practice for a device =
initiating an emergency call is to disable services that could interrupt =
the call, such as call waiting and third-party calling.  If the =
third-party call is initiated before or in parallel with the emergency =
call, the text wouldn't apply anyway, and if the third-party call is =
initiated during the emergency call in order to better serve the user's =
needs, then this is exactly why the text uses "SHOULD" instead of =
"MUST."  The word "SHOULD" means that a client is supposed to follow the =
direction unless there is an overriding reason not to, and the =
consequences of doing so are understood.  Both of those apply in the =
case under discussion.
> >=20
> >=20
> >>=20
> >> 6443 is informational and 6881 is a BCP. No problem to do something =
that works that is 'forbidden.'
> >>=20
> >>> For example RFC 6443, chapter 13 says "Services such as call =
waiting, call transfer, three-way calling, and hold should be disabled."
> >>=20
> >> Note the use of 'should.'  I do not think anyone will complain if =
one interprets this as, "Should be disabled, unless the user will die if =
she does not setup a three-way call with her translation service."
> >>=20
> >>> If then the user is in a foreign language environment where the =
PSAP barely can have a clue on how to find the right relay service, and =
the user has a good relay service URI configured, well capable of =
handling the user's language and modality, what is then best?
> >>>=20
> >>> 1) Break against RFC 6881 and 6443 and have the user terminal =
invoke the three-party call? The wording in these RFCs may be =
interpreted to have some room for such deviations.
> >>=20
> >> Beyond the wording in the RFCs, there is a reason the IETF is not =
the protocol police. In retrospect, it may be safe to say the RFCs' =
suggestions are wrong.
> >>=20
> >>> 2) Or convey the relay service URI to the PSAP for invocation.
> >>=20
> >> Why not?
> >>=20
> >>>=20
> >>> The discussion so far leads towards conclusion 1. It is ok for me, =
I just wanted it confirmed by showing the whole situation.
> >>>=20
> >>> (there will always be complementing slow manual procedures, when =
the PSAP needs to figure out a reasonable way to handle the call, but =
this discussion is for the rapid automated way that should handle most =
cases.)
> >>>=20
> >>> /Gunnar
> >>>=20
> >>> Gunnar Hellstr=C3=B6m skrev den 2015-07-05 22:35:
> >>>> Paul,
> >>>> Yes, I agree that for most cases it is best that the party, who =
knows a service that will do the translation, does the invocation.
> >>>>=20
> >>>> And, yes ,in that scenario the 3PCC method seems suitable.
> >>>>=20
> >>>> My proposal to send the service provider URI together with the =
modality indications was for the case when there are strong policy =
reasons why one party would do the invocation, but little chance that =
that party would have access to an up-to-date information on available =
translation providers.
> >>>> That could be the case for the emergency service calling in a =
multi-language environment, also including support for sign language =
users.
> >>>>=20
> >>>> Since both you and Randall think it is not doable, we can try to =
use the principle that the party, who knows a service that will do the =
translation, does the invocation.
> >>  >>
> >>>> That brings us back to a need for more stringent =
language/modality negotiation in order to avoid both double invocation =
of services when one or none is required, and also avoid no invocation =
when one is needed.
> >>>>=20
> >>>> Paul Kyzivat skrev den 2015-07-05 18:20:
> >>>>> Gunnar,
> >>>>>=20
> >>>>> I understand what you are suggesting, but I don't believe it is =
workable. This seems to mean that the caller would select the service =
while the callee would engage the service in the call if needed. Yet it =
is likely to be the caller who has a business relationship with the =
service, while the callee does not. Gets complicated quickly.
> >>  >>>
> >>>>> ISTM it makes more sense to first figure out what is/isn't =
possible without translation, and then for a party that finds a =
translation service beneficial to engage one. Then the only concern is =
that both parties don't independently try to introduce equivalent =
translation services.
> >>>>>=20
> >>>>> For instance, a deaf caller might offer video media marked for =
sign language, and audio media on hold. If the answer doesn't accept the =
video, or doesn't indicate support for sign language, the caller could =
then conference in translation service, using the 3pcc transcoding model =
specified in rfc5369. (If that will take time, the deaf caller's UA =
could stream recorded media over the audio channel in the meantime.)
> >>>>>=20
> >>>>> Or, to get fancier, it would be possible to use preconditions to =
defer alerting the callee until this is all sorted out.
> >>>>>=20
> >>>>> My point is to let the participant who wants translation handle =
to setup of translation rather than depending on the other party to do =
something.
> >>>> OK, it might be likely that both parties "want" translation, but =
one has better knowledge about how to get the required service and has =
business relations with the service. So then it is preferred that that =
party invokes.
> >>>>=20
> >>>> Good
> >>>> /Gunnar
> >>>>>=20
> >>>>>    Thanks,
> >>>>>    Paul
> >>>>>=20
> >>>>> On 7/5/15 2:48 AM, Gunnar Hellstr=C3=B6m wrote:
> >>>>>> Another opportunity would be to convey a URI to the service =
provider who
> >>>>>> did (for mail) or can do(for real-time) the translation.
> >>>>>> Then experience with different service provider's production =
could give
> >>>>>> some idea of the expected quality.
> >>>>>> I can see great value in that for the real-time case, when the =
calling
> >>>>>> user has a favourite translator (e.g. relay service), and =
provides that
> >>>>>> as a hint if languages or modalities in the call does not =
match. Then
> >>>>>> the callee do not need to just take a service provider by =
chance that
> >>>>>> seem to match the language/modality profile but can take the =
one
> >>>>>> proposed by the caller.
> >>>>>>=20
> >>>>>> After working with the needs for emergency services to work =
across
> >>>>>> Europe for some time now, I think this is one of the few =
workable
> >>>>>> solutions. The user expresses both the language/modality needs =
and
> >>>>>> provides a URI to a favourite translation service provider, and =
the
> >>>>>> callee tries to fulfill the language/modality needs either by a =
matching
> >>>>>> original call taker or by invoking the proposed translation =
provider.
> >>>>>>=20
> >>>>>> /Gunnar
> >>>>>>=20
> >>>>>>=20
> >>>>>> Randall Gellens skrev den 2015-07-05 03:49:
> >>>>>>> My recollection is that this was discussed in email prior to =
Dallas,
> >>>>>>> but that's not important.
> >>>>>>>=20
> >>>>>>> I am a strong proponent of keeping things as simple as =
possible,
> >>>>>>> provided there is a way to extend them if experience shows =
that it is
> >>>>>>> needed.  So, I think we should stick with the original =
suggestion of
> >>>>>>> three values ("original", "human", "automated"). This is =
simple enough
> >>>>>>> to be implementable and functional enough to be useful in =
providing a
> >>>>>>> hint that may help the client choose the best version for the =
user. If
> >>>>>>> we try and capture the various nuances of quality we will end =
up with
> >>>>>>> a very complex mechanism that is unlikely to be any more =
useful in
> >>>>>>> real life. Let's go with the simple approach now.  If, after =
some
> >>>>>>> deployment experience we realize that we really do need extra
> >>>>>>> complexity, we can extend the mechanism then.
> >>>>>>>=20
> >>>>>>> At 4:29 PM +0100 7/3/15, Nik Tomkinson wrote:
> >>  >>>>>
> >>>>>>>> Thanks for the responses.
> >>>>>>>>=20
> >>>>>>>> To deal with the issue with having only =
original/human/automated,
> >>>>>>>> what about the following?:
> >>>>>>>>=20
> >>>>>>>>=20
> >>>>>>>> translation-type :=3D type-token[ ";" "q" "=3D" qvalue ]
> >>>>>>>> type-token :=3D"human" / "automated"
> >>>>>>>>=20
> >>>>>>>> where qvalue is a value between 0 and 1 with a default of 0.5 =
if
> >>>>>>>> missing
> >>>>>>>>=20
> >>>>>>>> for example:
> >>>>>>>>=20
> >>>>>>>> Translation-Type: human;q=3D0.8
> >>>>>>>> Translation-Type: automated;q=3D0.4
> >>>>>>>> Translation-Type: human
> >>>>>>>>=20
> >>>>>>>> The Translation-Type SHOULD NOT appear in the original
> >>>>>>>> (untranslated) part but it SHOULD appear in translated =
content.
> >>  >>>>>>
> >>>>>>>> Having this missing from the original text helps identify =
which is
> >>>>>>>> the source to be translated into further languages if the =
user mail
> >>>>>>>> client allows.
> >>>>>>>>=20
> >>>>>>>> This enables us to dispose of the 'original' value which =
didn't lend
> >>>>>>>> itself well to being graded on quality.
> >>>>>>>>=20
> >>>>>>>> The qvalue can be set by the sender or provided by the =
translation
> >>>>>>>> service.
> >>>>>>>>=20
> >>>>>>>> The draft suggests that:
> >>>>>>>>=20
> >>>>>>>> "Additionally, interactive implementations MAY offer the user =
a
> >>>>>>>> choice from among the available languages." so the qvalue may =
not
> >>>>>>>> need to be bulletproof.
> >>>>>>>>=20
> >>>>>>>> Comments?
> >>>>>>>>=20
> >>>>>>>> Nik.
> >>>>>>>>=20
> >>>>>>>> On 3 July 2015 at 09:46, Gunnar Hellstr=C3=B6m
> >>>>>>>> =
<gunnar.hellstrom@omnitor.se> wrote:
> >>>>>>>>=20
> >>>>>>>> I see some value of this kind of parameter also for the =
real-time case.
> >>>>>>>> The time is here when it can be possible in some situations =
to
> >>>>>>>> select between using a low-cost automatic speech-to-text =
generation
> >>>>>>>> and a higher cost captioned telephony or text-relay service =
(higher
> >>>>>>>> cost for someone, not always the end-user).
> >>>>>>>>=20
> >>>>>>>> But I agree that it is very hard to set good understandable =
values
> >>>>>>>> on a parameter expressing the type or quality of this kind of =
service.
> >>>>>>>>=20
> >>>>>>>> Gunnar
> >>>>>>>>=20
> >>>>>>>>=20
> >>>>>>>>=20
> >>>>>>>> Stephane Bortzmeyer skrev den 2015-07-03 08:49:
> >>>>>>>>=20
> >>>>>>>> On Thu, Jul 02, 2015 at 11:09:30PM +0100,
> >>>>>>>>   Nik Tomkinson
> >>>>>>>> =
<rfc.nik.tomkinson@gmail.com> wrote
> >>>>>>>>   a message of 109 lines which said:
> >>>>>>>>=20
> >>>>>>>> type-token :=3D "original" / "human" / "automated"
> >>>>>>>>=20
> >>>>>>>> In many IETF working groups, when there is such a proposal, =
there is a
> >>>>>>>> big discussion between the registryfull and the registryless
> >>>>>>>> people. The first ones say there must be an authoritative =
list of
> >>>>>>>> values (in the RFC or, better because more evolving, in an =
IANA
> >>>>>>>> registry) so we can be sure of the interpretation of values. =
The
> >>>>>>>> second ones say we can never capture all the nuances and =
subtleties of
> >>>>>>>> the world in a fixed list.
> >>>>>>>>=20
> >>>>>>>> Here, I am not sure that the only meaningful distinction is =
between
> >>>>>>>> "human" and "automated". Some humans do a very poor job, too. =
One
> >>>>>>>> could suggest:
> >>>>>>>>=20
> >>>>>>>> type-token :=3D "original" / "professional-human" / =
"amateur-human" /
> >>>>>>>> "automated-first-generation" / =
"automated-artificial-intelligence" /
> >>>>>>>> "automated-the-robot-in-hollywood-movies"
> >>>>>>>>=20
> >>>>>>>> Or decide that it will be too complicated and we should =
instead
> >>>>>>>> accept:
> >>>>>>>>=20
> >>>>>>>> type-token :=3D "original" / 
> >>>>>>>>=20
> >>>>>>>> Toughts?
> >>>>>>>>=20
> >>>>>>>> _______________________________________________
> >>>>>>>> SLIM mailing list
> >>>>>>>> SLIM@ietf.org
> >>>>>>>>=20
> >>>>>>>> =
https://www.ietf.org/mailman/l=
istinfo/slim
> >>>>>>>>=20
> >>>>>>>>=20
> >>>>>>>>=20
> >>>>>>>> _______________________________________________
> >>>>>>>> SLIM mailing list
> >>>>>>>> SLIM@ietf.org
> >>>>>>>>=20
> >>>>>>>> =
https://www.ietf.org/mailman/l=
istinfo/slim
> >>>>>>>>=20
> >>>>>>>>=20
> >>>>>>>>=20
> >>>>>>>>=20
> >>>>>>>>=20
> >>>>>>>> --
> >>>>>>>>=20
> >>>>>>>> =
-----------------------------------------------------------------
> >>>>>>>> Multiple Language Content Type Internet Draft:
> >>>>>>>>=20
> >>>>>>>> =
http://=
datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/
> >>  >>>>>>
> >>>>>>>> =
-----------------------------------------------------------------
> >>>>>>>>=20
> >>>>>>>> _______________________________________________
> >>>>>>>> SLIM mailing list
> >>>>>>>> SLIM@ietf.org
> >>>>>>>> https://www.ietf.org/mailman/listinfo/slim
> >>>>>>>=20
> >>>>>>>=20
> >>>>>>>=20
> >>>>>>=20
> >>>>>=20
> >>>>> _______________________________________________
> >>>>> SLIM mailing list
> >>>>> SLIM@ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/slim
> >>>>=20
> >>>=20
> >>> --
> >>> -----------------------------------------
> >>> Gunnar Hellstr=C3=B6m
> >>> Omnitor
> >>> gunnar.hellstrom@omnitor.se
> >>> +46 708 204 288
> >>>=20
> >>> _______________________________________________
> >>  > SLIM mailing list
> >>> SLIM@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/slim
> >>=20
> >>=20
> >> Content-Transfer-Encoding: 7bit
> >> Content-Disposition: attachment; filename=3D"signature.asc"
> >> Content-Type: application/pgp-signature;
> >> name=3Dsignature.asc
> >> Content-Description: Message signed with OpenPGP using GPGMail
> >>=20
> >> Attachment converted: TiLand:signature 415.asc (    /    ) =
(028C4061)
> >> _______________________________________________
> >> SLIM mailing list
> >> SLIM@ietf.org
> >> https://www.ietf.org/mailman/listinfo/slim
> >=20
> >=20
> >=20
> > --=20
> > Randall Gellens
> > Opinions are personal;    facts are suspect;    I speak for myself =
only
> > -------------- Randomly selected tag: ---------------
> > Progress is made on alternate Fridays.
> >=20
> > _______________________________________________
> > SLIM mailing list
> > SLIM@ietf.org
> > https://www.ietf.org/mailman/listinfo/slim
>=20
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim


From nobody Tue Jul  7 14:35:39 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D7A1AD324 for ; Tue,  7 Jul 2015 14:35:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 DQzBkJsMBbdH for ; Tue,  7 Jul 2015 14:35:33 -0700 (PDT)
Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A69BA1AD2EE for ; Tue,  7 Jul 2015 14:35:33 -0700 (PDT)
Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-02v.sys.comcast.net with comcast id pZZz1q0072LrikM01ZbYFH; Tue, 07 Jul 2015 21:35:32 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-12v.sys.comcast.net with comcast id pZbY1q0083Ge9ey01ZbYTY; Tue, 07 Jul 2015 21:35:32 +0000
Message-ID: <559C4623.6060900@alum.mit.edu>
Date: Tue, 07 Jul 2015 17:35:31 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: slim@ietf.org
References:  <5E0D2DE0-FC2F-4681-B05C-D924A44B43E8@brianrosen.net>
In-Reply-To: <5E0D2DE0-FC2F-4681-B05C-D924A44B43E8@brianrosen.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1436304932; bh=DuieITukrJtE9EHdU4GIaGB/mNFSYwgBcwlnbrWD2u0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ozWsWE5lJijF/PJJE8N7XLWAXyPoewaTrWF8hV0q1wSdrD6KlR7tpjNb7KQ3uqNIj kkNdx5m48cQo9We3eKIni5Xr0RW+VG4Z6kK00gGACd0hdVWDQH9S6FzE96A5puWu1A ym+J9YuN57MdK7MUZliYi6zvUTMRhOOfZz+3troovyaQpdNstOX+NzfUmP0RAcAyLr al3YxeW3Tl6BUHNWR+N2K8mjC6xPP4eOiR0+OwgnQM8awCFYi50hj7aGRwvFQiHKWx w7lDjKjw//g2asAj8Wz1S24F/qWUDQjcn/OS9lsAyPQHTMYgtuYWlkTsK4VEfNFzt1 WJt/UUYRqzTug==
Archived-At: 
Subject: Re: [Slim] Translation Quality or type - or service provider
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Jul 2015 21:35:37 -0000

On 7/7/15 5:00 PM, Brian Rosen wrote:
> Of course it’s not enforceable, but since there are a finite number of VRS providers, the PSAP community can prevail upon them to do the right thing.  The worst case, where there are two bridges, is annoying but not fatal.
>
> What we need is clear labeling of what is requested, something we don’t have now, but slim will provide.
>
> The current NENA documents say that the outgoing proxy server adds a Referred-By header to the call.  The PSAP may use the URI of the Referred-by to bridge in the referring party, which is the CA at the outgoing proxy of the VRS provider.  This works exactly the way the current U.S. regulations say it should work, where first a two way is established between the CA and the caller and then the call is extended as a 9-1-1 call.  It wouldn’t work as well in Gunnar’s environment where the SIP service provider isn’t the relay provider, but something similar could work.
>
> For “direct routing”, where you don’t get the 2-way before a 3-way is established, the VRS provider (in the US) can still add the Referred-by, which would allow the PSAP to either use it, or it’s own choice of relay provider.  It’s a bit weird, in that there is no actual referral, it’s more of a “if you want me, here is how to get me”, but it would clearly work.

ISTM that a problem with the NG911 approach is that the mechanism for 
setting up the relay call is entirely different from the way it is done 
for other relay calls. So it becomes a path-less-used and hence less 
tested. It would be nice if the same technique was used for everyday 
calls and emergency calls, so that it was a well tested path.

> We might be better off with another mechanism that expressly states “A translation service is available at this URI”, which is the idea Gunnar has.  I think that is additive, not replacing the current proposed language tag mechanism.  You could imagine various forms of that which would include the source and destination language tags.  An out of country visitor might request translation to French, but if he is in Brazil, his preferred English to French service might not be helpful.

I can see how that might work if limited to US VRS service, especially 
if only for emergency calls. In that case a common law/contract can be 
in place to ensure that the translation service will accept the call.

In the more general case, possibly where clients of the service have to 
establish a business relationship with each provider, it won't work very 
well.

It is also necessary that the invocation of the translation service be 
standardized so the entity invoking it knows how to do so. We hopefully 
will soon have something for VRS service in the US, but it doesn't work 
this way. And it is a long way from there to having a standard for all 
the different sorts of translation (relay) service.

	Thanks,
	Paul

> Brian
>
>> On Jul 7, 2015, at 4:20 PM, Eric Burger  wrote:
>>
>> I don't see how either way is enforceable. If we say the PSAP has to take the caller's translation service, any sensible PSAP will feel free to ignore it, whether due to cost, liability, or protecting against the PSAP being the source of a DoS attack. Conversely, if a particular PSAP could use a hint for a translation service, it would be handy for the caller to provide one.
>>
>>
>>
>> Sent from my mobile device. Thanks be to LEMONADE: http://www.standardstrack.com/ietf/lemonade
>>
>>
>> -------- Original message --------
>> From: Brian Rosen 
>> Date: 07/07/2015 2:20 PM (GMT-05:00)
>> To: Randall Gellens 
>> Cc: Eric Burger , slim@ietf.org
>> Subject: Re: [Slim] Translation Quality or type - or service provider
>>
>> In general, the PSAP wants to use it’s bridge, and NOT have the translation service use its bridge.  There are clearly circumstances where the PSAP bridge cannot be used and we need a way to make sure the translation service’s bridge can be used.
>>
>> Brian
>>
>>> On Jul 7, 2015, at 1:56 PM, Randall Gellens  wrote:
>>>
>>> At 4:43 AM -0400 7/6/15, Eric Burger wrote:
>>>
>>>>   > On Jul 6, 2015, at 3:24 AM, Gunnar Hellström  wrote:
>>>>>
>>>>> One reason for the need to convey a translation service provider URI is that the emergency service RFCs 6443 and 6881 forbids the calling user to invoke three-party calling.
>>>
>>> The text there is saying that the best practice for a device initiating an emergency call is to disable services that could interrupt the call, such as call waiting and third-party calling.  If the third-party call is initiated before or in parallel with the emergency call, the text wouldn't apply anyway, and if the third-party call is initiated during the emergency call in order to better serve the user's needs, then this is exactly why the text uses "SHOULD" instead of "MUST."  The word "SHOULD" means that a client is supposed to follow the direction unless there is an overriding reason not to, and the consequences of doing so are understood.  Both of those apply in the case under discussion.
>>>
>>>
>>>>
>>>> 6443 is informational and 6881 is a BCP. No problem to do something that works that is 'forbidden.'
>>>>
>>>>> For example RFC 6443, chapter 13 says "Services such as call waiting, call transfer, three-way calling, and hold should be disabled."
>>>>
>>>> Note the use of 'should.'  I do not think anyone will complain if one interprets this as, "Should be disabled, unless the user will die if she does not setup a three-way call with her translation service."
>>>>
>>>>> If then the user is in a foreign language environment where the PSAP barely can have a clue on how to find the right relay service, and the user has a good relay service URI configured, well capable of handling the user's language and modality, what is then best?
>>>>>
>>>>> 1) Break against RFC 6881 and 6443 and have the user terminal invoke the three-party call? The wording in these RFCs may be interpreted to have some room for such deviations.
>>>>
>>>> Beyond the wording in the RFCs, there is a reason the IETF is not the protocol police. In retrospect, it may be safe to say the RFCs' suggestions are wrong.
>>>>
>>>>> 2) Or convey the relay service URI to the PSAP for invocation.
>>>>
>>>> Why not?
>>>>
>>>>>
>>>>> The discussion so far leads towards conclusion 1. It is ok for me, I just wanted it confirmed by showing the whole situation.
>>>>>
>>>>> (there will always be complementing slow manual procedures, when the PSAP needs to figure out a reasonable way to handle the call, but this discussion is for the rapid automated way that should handle most cases.)
>>>>>
>>>>> /Gunnar
>>>>>
>>>>> Gunnar Hellström skrev den 2015-07-05 22:35:
>>>>>> Paul,
>>>>>> Yes, I agree that for most cases it is best that the party, who knows a service that will do the translation, does the invocation.
>>>>>>
>>>>>> And, yes ,in that scenario the 3PCC method seems suitable.
>>>>>>
>>>>>> My proposal to send the service provider URI together with the modality indications was for the case when there are strong policy reasons why one party would do the invocation, but little chance that that party would have access to an up-to-date information on available translation providers.
>>>>>> That could be the case for the emergency service calling in a multi-language environment, also including support for sign language users.
>>>>>>
>>>>>> Since both you and Randall think it is not doable, we can try to use the principle that the party, who knows a service that will do the translation, does the invocation.
>>>>   >>
>>>>>> That brings us back to a need for more stringent language/modality negotiation in order to avoid both double invocation of services when one or none is required, and also avoid no invocation when one is needed.
>>>>>>
>>>>>> Paul Kyzivat skrev den 2015-07-05 18:20:
>>>>>>> Gunnar,
>>>>>>>
>>>>>>> I understand what you are suggesting, but I don't believe it is workable. This seems to mean that the caller would select the service while the callee would engage the service in the call if needed. Yet it is likely to be the caller who has a business relationship with the service, while the callee does not. Gets complicated quickly.
>>>>   >>>
>>>>>>> ISTM it makes more sense to first figure out what is/isn't possible without translation, and then for a party that finds a translation service beneficial to engage one. Then the only concern is that both parties don't independently try to introduce equivalent translation services.
>>>>>>>
>>>>>>> For instance, a deaf caller might offer video media marked for sign language, and audio media on hold. If the answer doesn't accept the video, or doesn't indicate support for sign language, the caller could then conference in translation service, using the 3pcc transcoding model specified in rfc5369. (If that will take time, the deaf caller's UA could stream recorded media over the audio channel in the meantime.)
>>>>>>>
>>>>>>> Or, to get fancier, it would be possible to use preconditions to defer alerting the callee until this is all sorted out.
>>>>>>>
>>>>>>> My point is to let the participant who wants translation handle to setup of translation rather than depending on the other party to do something.
>>>>>> OK, it might be likely that both parties "want" translation, but one has better knowledge about how to get the required service and has business relations with the service. So then it is preferred that that party invokes.
>>>>>>
>>>>>> Good
>>>>>> /Gunnar
>>>>>>>
>>>>>>>     Thanks,
>>>>>>>     Paul
>>>>>>>
>>>>>>> On 7/5/15 2:48 AM, Gunnar Hellström wrote:
>>>>>>>> Another opportunity would be to convey a URI to the service provider who
>>>>>>>> did (for mail) or can do(for real-time) the translation.
>>>>>>>> Then experience with different service provider's production could give
>>>>>>>> some idea of the expected quality.
>>>>>>>> I can see great value in that for the real-time case, when the calling
>>>>>>>> user has a favourite translator (e.g. relay service), and provides that
>>>>>>>> as a hint if languages or modalities in the call does not match. Then
>>>>>>>> the callee do not need to just take a service provider by chance that
>>>>>>>> seem to match the language/modality profile but can take the one
>>>>>>>> proposed by the caller.
>>>>>>>>
>>>>>>>> After working with the needs for emergency services to work across
>>>>>>>> Europe for some time now, I think this is one of the few workable
>>>>>>>> solutions. The user expresses both the language/modality needs and
>>>>>>>> provides a URI to a favourite translation service provider, and the
>>>>>>>> callee tries to fulfill the language/modality needs either by a matching
>>>>>>>> original call taker or by invoking the proposed translation provider.
>>>>>>>>
>>>>>>>> /Gunnar
>>>>>>>>
>>>>>>>>
>>>>>>>> Randall Gellens skrev den 2015-07-05 03:49:
>>>>>>>>> My recollection is that this was discussed in email prior to Dallas,
>>>>>>>>> but that's not important.
>>>>>>>>>
>>>>>>>>> I am a strong proponent of keeping things as simple as possible,
>>>>>>>>> provided there is a way to extend them if experience shows that it is
>>>>>>>>> needed.  So, I think we should stick with the original suggestion of
>>>>>>>>> three values ("original", "human", "automated"). This is simple enough
>>>>>>>>> to be implementable and functional enough to be useful in providing a
>>>>>>>>> hint that may help the client choose the best version for the user. If
>>>>>>>>> we try and capture the various nuances of quality we will end up with
>>>>>>>>> a very complex mechanism that is unlikely to be any more useful in
>>>>>>>>> real life. Let's go with the simple approach now.  If, after some
>>>>>>>>> deployment experience we realize that we really do need extra
>>>>>>>>> complexity, we can extend the mechanism then.
>>>>>>>>>
>>>>>>>>> At 4:29 PM +0100 7/3/15, Nik Tomkinson wrote:
>>>>   >>>>>
>>>>>>>>>> Thanks for the responses.
>>>>>>>>>>
>>>>>>>>>> To deal with the issue with having only original/human/automated,
>>>>>>>>>> what about the following?:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> translation-type := type-token[ ";" "q" "=" qvalue ]
>>>>>>>>>> type-token :="human" / "automated"
>>>>>>>>>>
>>>>>>>>>> where qvalue is a value between 0 and 1 with a default of 0.5 if
>>>>>>>>>> missing
>>>>>>>>>>
>>>>>>>>>> for example:
>>>>>>>>>>
>>>>>>>>>> Translation-Type: human;q=0.8
>>>>>>>>>> Translation-Type: automated;q=0.4
>>>>>>>>>> Translation-Type: human
>>>>>>>>>>
>>>>>>>>>> The Translation-Type SHOULD NOT appear in the original
>>>>>>>>>> (untranslated) part but it SHOULD appear in translated content.
>>>>   >>>>>>
>>>>>>>>>> Having this missing from the original text helps identify which is
>>>>>>>>>> the source to be translated into further languages if the user mail
>>>>>>>>>> client allows.
>>>>>>>>>>
>>>>>>>>>> This enables us to dispose of the 'original' value which didn't lend
>>>>>>>>>> itself well to being graded on quality.
>>>>>>>>>>
>>>>>>>>>> The qvalue can be set by the sender or provided by the translation
>>>>>>>>>> service.
>>>>>>>>>>
>>>>>>>>>> The draft suggests that:
>>>>>>>>>>
>>>>>>>>>> "Additionally, interactive implementations MAY offer the user a
>>>>>>>>>> choice from among the available languages." so the qvalue may not
>>>>>>>>>> need to be bulletproof.
>>>>>>>>>>
>>>>>>>>>> Comments?
>>>>>>>>>>
>>>>>>>>>> Nik.
>>>>>>>>>>
>>>>>>>>>> On 3 July 2015 at 09:46, Gunnar Hellström
>>>>>>>>>> <gunnar.hellstrom@omnitor.se> wrote:
>>>>>>>>>>
>>>>>>>>>> I see some value of this kind of parameter also for the real-time case.
>>>>>>>>>> The time is here when it can be possible in some situations to
>>>>>>>>>> select between using a low-cost automatic speech-to-text generation
>>>>>>>>>> and a higher cost captioned telephony or text-relay service (higher
>>>>>>>>>> cost for someone, not always the end-user).
>>>>>>>>>>
>>>>>>>>>> But I agree that it is very hard to set good understandable values
>>>>>>>>>> on a parameter expressing the type or quality of this kind of service.
>>>>>>>>>>
>>>>>>>>>> Gunnar
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Stephane Bortzmeyer skrev den 2015-07-03 08:49:
>>>>>>>>>>
>>>>>>>>>> On Thu, Jul 02, 2015 at 11:09:30PM +0100,
>>>>>>>>>>    Nik Tomkinson
>>>>>>>>>> <rfc.nik.tomkinson@gmail.com> wrote
>>>>>>>>>>    a message of 109 lines which said:
>>>>>>>>>>
>>>>>>>>>> type-token := "original" / "human" / "automated"
>>>>>>>>>>
>>>>>>>>>> In many IETF working groups, when there is such a proposal, there is a
>>>>>>>>>> big discussion between the registryfull and the registryless
>>>>>>>>>> people. The first ones say there must be an authoritative list of
>>>>>>>>>> values (in the RFC or, better because more evolving, in an IANA
>>>>>>>>>> registry) so we can be sure of the interpretation of values. The
>>>>>>>>>> second ones say we can never capture all the nuances and subtleties of
>>>>>>>>>> the world in a fixed list.
>>>>>>>>>>
>>>>>>>>>> Here, I am not sure that the only meaningful distinction is between
>>>>>>>>>> "human" and "automated". Some humans do a very poor job, too. One
>>>>>>>>>> could suggest:
>>>>>>>>>>
>>>>>>>>>> type-token := "original" / "professional-human" / "amateur-human" /
>>>>>>>>>> "automated-first-generation" / "automated-artificial-intelligence" /
>>>>>>>>>> "automated-the-robot-in-hollywood-movies"
>>>>>>>>>>
>>>>>>>>>> Or decide that it will be too complicated and we should instead
>>>>>>>>>> accept:
>>>>>>>>>>
>>>>>>>>>> type-token := "original" / 
>>>>>>>>>>
>>>>>>>>>> Toughts?
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> SLIM mailing list
>>>>>>>>>> SLIM@ietf.org
>>>>>>>>>>
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/slim
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> SLIM mailing list
>>>>>>>>>> SLIM@ietf.org
>>>>>>>>>>
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/slim
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>
>>>>>>>>>> -----------------------------------------------------------------
>>>>>>>>>> Multiple Language Content Type Internet Draft:
>>>>>>>>>>
>>>>>>>>>> http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/
>>>>   >>>>>>
>>>>>>>>>> -----------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> SLIM mailing list
>>>>>>>>>> SLIM@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/slim
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> SLIM mailing list
>>>>>>> SLIM@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/slim
>>>>>>
>>>>>
>>>>> --
>>>>> -----------------------------------------
>>>>> Gunnar Hellström
>>>>> Omnitor
>>>>> gunnar.hellstrom@omnitor.se
>>>>> +46 708 204 288
>>>>>
>>>>> _______________________________________________
>>>>   > SLIM mailing list
>>>>> SLIM@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/slim
>>>>
>>>>
>>>> Content-Transfer-Encoding: 7bit
>>>> Content-Disposition: attachment; filename="signature.asc"
>>>> Content-Type: application/pgp-signature;
>>>> name=signature.asc
>>>> Content-Description: Message signed with OpenPGP using GPGMail
>>>>
>>>> Attachment converted: TiLand:signature 415.asc (    /    ) (028C4061)
>>>> _______________________________________________
>>>> SLIM mailing list
>>>> SLIM@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/slim
>>>
>>>
>>>
>>> --
>>> Randall Gellens
>>> Opinions are personal;    facts are suspect;    I speak for myself only
>>> -------------- Randomly selected tag: ---------------
>>> Progress is made on alternate Fridays.
>>>
>>> _______________________________________________
>>> SLIM mailing list
>>> SLIM@ietf.org
>>> https://www.ietf.org/mailman/listinfo/slim
>>
>> _______________________________________________
>> SLIM mailing list
>> SLIM@ietf.org
>> https://www.ietf.org/mailman/listinfo/slim
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim
>


From nobody Tue Jul  7 15:10:48 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D845C1AD49F for ; Tue,  7 Jul 2015 15:10:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.82
X-Spam-Level: 
X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham
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 H9qskBP5Unbk for ; Tue,  7 Jul 2015 15:10:41 -0700 (PDT)
Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) (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 F171F1AD49D for ; Tue,  7 Jul 2015 15:10:40 -0700 (PDT)
Received: by qget71 with SMTP id t71so91543144qge.2 for ; Tue, 07 Jul 2015 15:10:40 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=DgPyf0tqJVj6a3xsJCOSS00NpXVD/LyYp063pAotC9o=; b=b4v0ZRaIG6GKytHRyev20u8GMsEwiioLOixQ/V07JWS5Aq6VI4jdkJF+C1mhMZ+a6f uBVk+FVZYzlsaeqy2B93e0wMH6c0VhKNBkhFejbXS9L7f6VXSdP/+shGi1K5gSXIqNV+ usZcbTrsZcbGWZu8At/mnMAJl5ugYhBRal48ZzJZoFnEqldZU2kN61lfqnC3wB/kQpsW rbWvK3vRDoXrAafOMnYEl1/1/6fUmepKarT3VllwpGFiUknBFKkbM90NW2sVI0qmPoKK uki9AR0JxH5Ra3cMPd0HtdKNhOI2/zKz222m/T4iSnFphc32lBWCSqVbNmTn6WhewvLe 2V2A==
X-Gm-Message-State: ALoCoQkQQE72HOm8dGoU3BzR/9QA93cryvJe/JaBzlF/LqqUWrt+RYkAge+0XkZnOLAECJDV7v/P
X-Received: by 10.140.239.9 with SMTP id k9mr11305236qhc.38.1436307040171; Tue, 07 Jul 2015 15:10:40 -0700 (PDT)
Received: from [10.33.193.32] (neustargw.va.neustar.com. [209.173.53.233]) by smtp.gmail.com with ESMTPSA id 60sm143392qgy.11.2015.07.07.15.10.39 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Jul 2015 15:10:39 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_27BC3A2E-67F3-4332-A699-92D890AF4AB9"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: Brian Rosen 
In-Reply-To: <559C4623.6060900@alum.mit.edu>
Date: Tue, 7 Jul 2015 18:10:37 -0400
Message-Id: <93F3A1A6-954C-4D9B-83E9-7FA0637696A4@brianrosen.net>
References:  <5E0D2DE0-FC2F-4681-B05C-D924A44B43E8@brianrosen.net> <559C4623.6060900@alum.mit.edu>
To: Paul Kyzivat 
X-Mailer: Apple Mail (2.2102)
Archived-At: 
Cc: slim@ietf.org
Subject: Re: [Slim] Translation Quality or type - or service provider
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Jul 2015 22:10:48 -0000

--Apple-Mail=_27BC3A2E-67F3-4332-A699-92D890AF4AB9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

inline
> On Jul 7, 2015, at 5:35 PM, Paul Kyzivat  =
wrote:
>=20
> On 7/7/15 5:00 PM, Brian Rosen wrote:
>> Of course it=E2=80=99s not enforceable, but since there are a finite =
number of VRS providers, the PSAP community can prevail upon them to do =
the right thing.  The worst case, where there are two bridges, is =
annoying but not fatal.
>>=20
>> What we need is clear labeling of what is requested, something we =
don=E2=80=99t have now, but slim will provide.
>>=20
>> The current NENA documents say that the outgoing proxy server adds a =
Referred-By header to the call.  The PSAP may use the URI of the =
Referred-by to bridge in the referring party, which is the CA at the =
outgoing proxy of the VRS provider.  This works exactly the way the =
current U.S. regulations say it should work, where first a two way is =
established between the CA and the caller and then the call is extended =
as a 9-1-1 call.  It wouldn=E2=80=99t work as well in Gunnar=E2=80=99s =
environment where the SIP service provider isn=E2=80=99t the relay =
provider, but something similar could work.
>>=20
>> For =E2=80=9Cdirect routing=E2=80=9D, where you don=E2=80=99t get the =
2-way before a 3-way is established, the VRS provider (in the US) can =
still add the Referred-by, which would allow the PSAP to either use it, =
or it=E2=80=99s own choice of relay provider.  It=E2=80=99s a bit weird, =
in that there is no actual referral, it=E2=80=99s more of a =E2=80=9Cif =
you want me, here is how to get me=E2=80=9D, but it would clearly work.
>=20
> ISTM that a problem with the NG911 approach is that the mechanism for =
setting up the relay call is entirely different from the way it is done =
for other relay calls. So it becomes a path-less-used and hence less =
tested. It would be nice if the same technique was used for everyday =
calls and emergency calls, so that it was a well tested path.
Yeah, but it IS very special.  There is often a separate queue of call =
takers (trained for 9-1-1), and they have to route based on location of =
caller, not of CA, so they need to REFER the call to 9-1-1.

>=20
>> We might be better off with another mechanism that expressly states =
=E2=80=9CA translation service is available at this URI=E2=80=9D, which =
is the idea Gunnar has.  I think that is additive, not replacing the =
current proposed language tag mechanism.  You could imagine various =
forms of that which would include the source and destination language =
tags.  An out of country visitor might request translation to French, =
but if he is in Brazil, his preferred English to French service might =
not be helpful.
>=20
> I can see how that might work if limited to US VRS service, especially =
if only for emergency calls. In that case a common law/contract can be =
in place to ensure that the translation service will accept the call.
>=20
> In the more general case, possibly where clients of the service have =
to establish a business relationship with each provider, it won't work =
very well.
Why?  If you contract with Language Line, for example, they can handle n =
to m translation as long as English is either m or n for a significant =
number of n/ms.  I=E2=80=99m sure there are equivalents elsewhere.  So =
an English speaking caller could contract with LL to get what he needed, =
wherever he traveled.  If the caller supplies a URI, then it=E2=80=99s =
up to him to arrange contracts.  If the called party decides to use =
someone else, then it=E2=80=99s their contract.

>=20
> It is also necessary that the invocation of the translation service be =
standardized so the entity invoking it knows how to do so. We hopefully =
will soon have something for VRS service in the US, but it doesn't work =
this way. And it is a long way from there to having a standard for all =
the different sorts of translation (relay) service.
Yeah, I agree we should have some kind of signaling standard, but =
that=E2=80=99s beyond what our current goals for slim.
When we finish, we can either recharter, or form another group to handle =
generalized =E2=80=9Ctranscoder=E2=80=9D signaling

Brian
>=20
> 	Thanks,
> 	Paul
>=20
>> Brian
>>=20
>>> On Jul 7, 2015, at 4:20 PM, Eric Burger  =
wrote:
>>>=20
>>> I don't see how either way is enforceable. If we say the PSAP has to =
take the caller's translation service, any sensible PSAP will feel free =
to ignore it, whether due to cost, liability, or protecting against the =
PSAP being the source of a DoS attack. Conversely, if a particular PSAP =
could use a hint for a translation service, it would be handy for the =
caller to provide one.
>>>=20
>>>=20
>>>=20
>>> Sent from my mobile device. Thanks be to LEMONADE: =
http://www.standardstrack.com/ietf/lemonade
>>>=20
>>>=20
>>> -------- Original message --------
>>> From: Brian Rosen 
>>> Date: 07/07/2015 2:20 PM (GMT-05:00)
>>> To: Randall Gellens 
>>> Cc: Eric Burger , slim@ietf.org
>>> Subject: Re: [Slim] Translation Quality or type - or service =
provider
>>>=20
>>> In general, the PSAP wants to use it=E2=80=99s bridge, and NOT have =
the translation service use its bridge.  There are clearly circumstances =
where the PSAP bridge cannot be used and we need a way to make sure the =
translation service=E2=80=99s bridge can be used.
>>>=20
>>> Brian
>>>=20
>>>> On Jul 7, 2015, at 1:56 PM, Randall Gellens =
 wrote:
>>>>=20
>>>> At 4:43 AM -0400 7/6/15, Eric Burger wrote:
>>>>=20
>>>>>  > On Jul 6, 2015, at 3:24 AM, Gunnar Hellstr=C3=B6m =
 wrote:
>>>>>>=20
>>>>>> One reason for the need to convey a translation service provider =
URI is that the emergency service RFCs 6443 and 6881 forbids the calling =
user to invoke three-party calling.
>>>>=20
>>>> The text there is saying that the best practice for a device =
initiating an emergency call is to disable services that could interrupt =
the call, such as call waiting and third-party calling.  If the =
third-party call is initiated before or in parallel with the emergency =
call, the text wouldn't apply anyway, and if the third-party call is =
initiated during the emergency call in order to better serve the user's =
needs, then this is exactly why the text uses "SHOULD" instead of =
"MUST."  The word "SHOULD" means that a client is supposed to follow the =
direction unless there is an overriding reason not to, and the =
consequences of doing so are understood.  Both of those apply in the =
case under discussion.
>>>>=20
>>>>=20
>>>>>=20
>>>>> 6443 is informational and 6881 is a BCP. No problem to do =
something that works that is 'forbidden.'
>>>>>=20
>>>>>> For example RFC 6443, chapter 13 says "Services such as call =
waiting, call transfer, three-way calling, and hold should be disabled."
>>>>>=20
>>>>> Note the use of 'should.'  I do not think anyone will complain if =
one interprets this as, "Should be disabled, unless the user will die if =
she does not setup a three-way call with her translation service."
>>>>>=20
>>>>>> If then the user is in a foreign language environment where the =
PSAP barely can have a clue on how to find the right relay service, and =
the user has a good relay service URI configured, well capable of =
handling the user's language and modality, what is then best?
>>>>>>=20
>>>>>> 1) Break against RFC 6881 and 6443 and have the user terminal =
invoke the three-party call? The wording in these RFCs may be =
interpreted to have some room for such deviations.
>>>>>=20
>>>>> Beyond the wording in the RFCs, there is a reason the IETF is not =
the protocol police. In retrospect, it may be safe to say the RFCs' =
suggestions are wrong.
>>>>>=20
>>>>>> 2) Or convey the relay service URI to the PSAP for invocation.
>>>>>=20
>>>>> Why not?
>>>>>=20
>>>>>>=20
>>>>>> The discussion so far leads towards conclusion 1. It is ok for =
me, I just wanted it confirmed by showing the whole situation.
>>>>>>=20
>>>>>> (there will always be complementing slow manual procedures, when =
the PSAP needs to figure out a reasonable way to handle the call, but =
this discussion is for the rapid automated way that should handle most =
cases.)
>>>>>>=20
>>>>>> /Gunnar
>>>>>>=20
>>>>>> Gunnar Hellstr=C3=B6m skrev den 2015-07-05 22:35:
>>>>>>> Paul,
>>>>>>> Yes, I agree that for most cases it is best that the party, who =
knows a service that will do the translation, does the invocation.
>>>>>>>=20
>>>>>>> And, yes ,in that scenario the 3PCC method seems suitable.
>>>>>>>=20
>>>>>>> My proposal to send the service provider URI together with the =
modality indications was for the case when there are strong policy =
reasons why one party would do the invocation, but little chance that =
that party would have access to an up-to-date information on available =
translation providers.
>>>>>>> That could be the case for the emergency service calling in a =
multi-language environment, also including support for sign language =
users.
>>>>>>>=20
>>>>>>> Since both you and Randall think it is not doable, we can try to =
use the principle that the party, who knows a service that will do the =
translation, does the invocation.
>>>>>  >>
>>>>>>> That brings us back to a need for more stringent =
language/modality negotiation in order to avoid both double invocation =
of services when one or none is required, and also avoid no invocation =
when one is needed.
>>>>>>>=20
>>>>>>> Paul Kyzivat skrev den 2015-07-05 18:20:
>>>>>>>> Gunnar,
>>>>>>>>=20
>>>>>>>> I understand what you are suggesting, but I don't believe it is =
workable. This seems to mean that the caller would select the service =
while the callee would engage the service in the call if needed. Yet it =
is likely to be the caller who has a business relationship with the =
service, while the callee does not. Gets complicated quickly.
>>>>>  >>>
>>>>>>>> ISTM it makes more sense to first figure out what is/isn't =
possible without translation, and then for a party that finds a =
translation service beneficial to engage one. Then the only concern is =
that both parties don't independently try to introduce equivalent =
translation services.
>>>>>>>>=20
>>>>>>>> For instance, a deaf caller might offer video media marked for =
sign language, and audio media on hold. If the answer doesn't accept the =
video, or doesn't indicate support for sign language, the caller could =
then conference in translation service, using the 3pcc transcoding model =
specified in rfc5369. (If that will take time, the deaf caller's UA =
could stream recorded media over the audio channel in the meantime.)
>>>>>>>>=20
>>>>>>>> Or, to get fancier, it would be possible to use preconditions =
to defer alerting the callee until this is all sorted out.
>>>>>>>>=20
>>>>>>>> My point is to let the participant who wants translation handle =
to setup of translation rather than depending on the other party to do =
something.
>>>>>>> OK, it might be likely that both parties "want" translation, but =
one has better knowledge about how to get the required service and has =
business relations with the service. So then it is preferred that that =
party invokes.
>>>>>>>=20
>>>>>>> Good
>>>>>>> /Gunnar
>>>>>>>>=20
>>>>>>>>    Thanks,
>>>>>>>>    Paul
>>>>>>>>=20
>>>>>>>> On 7/5/15 2:48 AM, Gunnar Hellstr=C3=B6m wrote:
>>>>>>>>> Another opportunity would be to convey a URI to the service =
provider who
>>>>>>>>> did (for mail) or can do(for real-time) the translation.
>>>>>>>>> Then experience with different service provider's production =
could give
>>>>>>>>> some idea of the expected quality.
>>>>>>>>> I can see great value in that for the real-time case, when the =
calling
>>>>>>>>> user has a favourite translator (e.g. relay service), and =
provides that
>>>>>>>>> as a hint if languages or modalities in the call does not =
match. Then
>>>>>>>>> the callee do not need to just take a service provider by =
chance that
>>>>>>>>> seem to match the language/modality profile but can take the =
one
>>>>>>>>> proposed by the caller.
>>>>>>>>>=20
>>>>>>>>> After working with the needs for emergency services to work =
across
>>>>>>>>> Europe for some time now, I think this is one of the few =
workable
>>>>>>>>> solutions. The user expresses both the language/modality needs =
and
>>>>>>>>> provides a URI to a favourite translation service provider, =
and the
>>>>>>>>> callee tries to fulfill the language/modality needs either by =
a matching
>>>>>>>>> original call taker or by invoking the proposed translation =
provider.
>>>>>>>>>=20
>>>>>>>>> /Gunnar
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> Randall Gellens skrev den 2015-07-05 03:49:
>>>>>>>>>> My recollection is that this was discussed in email prior to =
Dallas,
>>>>>>>>>> but that's not important.
>>>>>>>>>>=20
>>>>>>>>>> I am a strong proponent of keeping things as simple as =
possible,
>>>>>>>>>> provided there is a way to extend them if experience shows =
that it is
>>>>>>>>>> needed.  So, I think we should stick with the original =
suggestion of
>>>>>>>>>> three values ("original", "human", "automated"). This is =
simple enough
>>>>>>>>>> to be implementable and functional enough to be useful in =
providing a
>>>>>>>>>> hint that may help the client choose the best version for the =
user. If
>>>>>>>>>> we try and capture the various nuances of quality we will end =
up with
>>>>>>>>>> a very complex mechanism that is unlikely to be any more =
useful in
>>>>>>>>>> real life. Let's go with the simple approach now.  If, after =
some
>>>>>>>>>> deployment experience we realize that we really do need extra
>>>>>>>>>> complexity, we can extend the mechanism then.
>>>>>>>>>>=20
>>>>>>>>>> At 4:29 PM +0100 7/3/15, Nik Tomkinson wrote:
>>>>>  >>>>>
>>>>>>>>>>> Thanks for the responses.
>>>>>>>>>>>=20
>>>>>>>>>>> To deal with the issue with having only =
original/human/automated,
>>>>>>>>>>> what about the following?:
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> translation-type :=3D type-token[ ";" "q" "=3D" qvalue ]
>>>>>>>>>>> type-token :=3D"human" / "automated"
>>>>>>>>>>>=20
>>>>>>>>>>> where qvalue is a value between 0 and 1 with a default of =
0.5 if
>>>>>>>>>>> missing
>>>>>>>>>>>=20
>>>>>>>>>>> for example:
>>>>>>>>>>>=20
>>>>>>>>>>> Translation-Type: human;q=3D0.8
>>>>>>>>>>> Translation-Type: automated;q=3D0.4
>>>>>>>>>>> Translation-Type: human
>>>>>>>>>>>=20
>>>>>>>>>>> The Translation-Type SHOULD NOT appear in the original
>>>>>>>>>>> (untranslated) part but it SHOULD appear in translated =
content.
>>>>>  >>>>>>
>>>>>>>>>>> Having this missing from the original text helps identify =
which is
>>>>>>>>>>> the source to be translated into further languages if the =
user mail
>>>>>>>>>>> client allows.
>>>>>>>>>>>=20
>>>>>>>>>>> This enables us to dispose of the 'original' value which =
didn't lend
>>>>>>>>>>> itself well to being graded on quality.
>>>>>>>>>>>=20
>>>>>>>>>>> The qvalue can be set by the sender or provided by the =
translation
>>>>>>>>>>> service.
>>>>>>>>>>>=20
>>>>>>>>>>> The draft suggests that:
>>>>>>>>>>>=20
>>>>>>>>>>> "Additionally, interactive implementations MAY offer the =
user a
>>>>>>>>>>> choice from among the available languages." so the qvalue =
may not
>>>>>>>>>>> need to be bulletproof.
>>>>>>>>>>>=20
>>>>>>>>>>> Comments?
>>>>>>>>>>>=20
>>>>>>>>>>> Nik.
>>>>>>>>>>>=20
>>>>>>>>>>> On 3 July 2015 at 09:46, Gunnar Hellstr=C3=B6m
>>>>>>>>>>> =
<gunnar.hellstrom@omnitor.se> wrote:
>>>>>>>>>>>=20
>>>>>>>>>>> I see some value of this kind of parameter also for the =
real-time case.
>>>>>>>>>>> The time is here when it can be possible in some situations =
to
>>>>>>>>>>> select between using a low-cost automatic speech-to-text =
generation
>>>>>>>>>>> and a higher cost captioned telephony or text-relay service =
(higher
>>>>>>>>>>> cost for someone, not always the end-user).
>>>>>>>>>>>=20
>>>>>>>>>>> But I agree that it is very hard to set good understandable =
values
>>>>>>>>>>> on a parameter expressing the type or quality of this kind =
of service.
>>>>>>>>>>>=20
>>>>>>>>>>> Gunnar
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> Stephane Bortzmeyer skrev den 2015-07-03 08:49:
>>>>>>>>>>>=20
>>>>>>>>>>> On Thu, Jul 02, 2015 at 11:09:30PM +0100,
>>>>>>>>>>>   Nik Tomkinson
>>>>>>>>>>> =
<rfc.nik.tomkinson@gmail.com> wrote
>>>>>>>>>>>   a message of 109 lines which said:
>>>>>>>>>>>=20
>>>>>>>>>>> type-token :=3D "original" / "human" / "automated"
>>>>>>>>>>>=20
>>>>>>>>>>> In many IETF working groups, when there is such a proposal, =
there is a
>>>>>>>>>>> big discussion between the registryfull and the registryless
>>>>>>>>>>> people. The first ones say there must be an authoritative =
list of
>>>>>>>>>>> values (in the RFC or, better because more evolving, in an =
IANA
>>>>>>>>>>> registry) so we can be sure of the interpretation of values. =
The
>>>>>>>>>>> second ones say we can never capture all the nuances and =
subtleties of
>>>>>>>>>>> the world in a fixed list.
>>>>>>>>>>>=20
>>>>>>>>>>> Here, I am not sure that the only meaningful distinction is =
between
>>>>>>>>>>> "human" and "automated". Some humans do a very poor job, =
too. One
>>>>>>>>>>> could suggest:
>>>>>>>>>>>=20
>>>>>>>>>>> type-token :=3D "original" / "professional-human" / =
"amateur-human" /
>>>>>>>>>>> "automated-first-generation" / =
"automated-artificial-intelligence" /
>>>>>>>>>>> "automated-the-robot-in-hollywood-movies"
>>>>>>>>>>>=20
>>>>>>>>>>> Or decide that it will be too complicated and we should =
instead
>>>>>>>>>>> accept:
>>>>>>>>>>>=20
>>>>>>>>>>> type-token :=3D "original" / 
>>>>>>>>>>>=20
>>>>>>>>>>> Toughts?
>>>>>>>>>>>=20
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> SLIM mailing list
>>>>>>>>>>> SLIM@ietf.org
>>>>>>>>>>>=20
>>>>>>>>>>> =
https://www.ietf.org/mailman/l=
istinfo/slim
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> SLIM mailing list
>>>>>>>>>>> SLIM@ietf.org
>>>>>>>>>>>=20
>>>>>>>>>>> =
https://www.ietf.org/mailman/l=
istinfo/slim
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> --
>>>>>>>>>>>=20
>>>>>>>>>>> =
-----------------------------------------------------------------
>>>>>>>>>>> Multiple Language Content Type Internet Draft:
>>>>>>>>>>>=20
>>>>>>>>>>> =
http://=
datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/
>>>>>  >>>>>>
>>>>>>>>>>> =
-----------------------------------------------------------------
>>>>>>>>>>>=20
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> SLIM mailing list
>>>>>>>>>>> SLIM@ietf.org
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/slim
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> SLIM mailing list
>>>>>>>> SLIM@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/slim
>>>>>>>=20
>>>>>>=20
>>>>>> --
>>>>>> -----------------------------------------
>>>>>> Gunnar Hellstr=C3=B6m
>>>>>> Omnitor
>>>>>> gunnar.hellstrom@omnitor.se
>>>>>> +46 708 204 288
>>>>>>=20
>>>>>> _______________________________________________
>>>>>  > SLIM mailing list
>>>>>> SLIM@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/slim
>>>>>=20
>>>>>=20
>>>>> Content-Transfer-Encoding: 7bit
>>>>> Content-Disposition: attachment; filename=3D"signature.asc"
>>>>> Content-Type: application/pgp-signature;
>>>>> name=3Dsignature.asc
>>>>> Content-Description: Message signed with OpenPGP using GPGMail
>>>>>=20
>>>>> Attachment converted: TiLand:signature 415.asc (    /    ) =
(028C4061)
>>>>> _______________________________________________
>>>>> SLIM mailing list
>>>>> SLIM@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/slim
>>>>=20
>>>>=20
>>>>=20
>>>> --
>>>> Randall Gellens
>>>> Opinions are personal;    facts are suspect;    I speak for myself =
only
>>>> -------------- Randomly selected tag: ---------------
>>>> Progress is made on alternate Fridays.
>>>>=20
>>>> _______________________________________________
>>>> SLIM mailing list
>>>> SLIM@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/slim
>>>=20
>>> _______________________________________________
>>> SLIM mailing list
>>> SLIM@ietf.org
>>> https://www.ietf.org/mailman/listinfo/slim
>>=20
>> _______________________________________________
>> SLIM mailing list
>> SLIM@ietf.org 
>> https://www.ietf.org/mailman/listinfo/slim =

>>=20
>=20
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org 
> https://www.ietf.org/mailman/listinfo/slim =


--Apple-Mail=_27BC3A2E-67F3-4332-A699-92D890AF4AB9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

inline
On Jul 7, 2015, at 5:35 PM, Paul Kyzivat =
<pkyzivat@alum.mit.edu> wrote:

On 7/7/15 5:00 PM, Brian Rosen wrote:
Of course it=E2=80=99s =
not enforceable, but since there are a finite number of VRS providers, =
the PSAP community can prevail upon them to do the right thing. =
 The worst case, where there are two bridges, is annoying but not =
fatal.

What we need is clear labeling of =
what is requested, something we don=E2=80=99t have now, but slim will =
provide.

The current NENA documents say =
that the outgoing proxy server adds a Referred-By header to the call. =
 The PSAP may use the URI of the Referred-by to bridge in the =
referring party, which is the CA at the outgoing proxy of the VRS =
provider.  This works exactly the way the current U.S. regulations =
say it should work, where first a two way is established between the CA =
and the caller and then the call is extended as a 9-1-1 call.  It =
wouldn=E2=80=99t work as well in Gunnar=E2=80=99s environment where the =
SIP service provider isn=E2=80=99t the relay provider, but something =
similar could work.

For =E2=80=9Cdirect =
routing=E2=80=9D, where you don=E2=80=99t get the 2-way before a 3-way =
is established, the VRS provider (in the US) can still add the =
Referred-by, which would allow the PSAP to either use it, or it=E2=80=99s =
own choice of relay provider.  It=E2=80=99s a bit weird, in that =
there is no actual referral, it=E2=80=99s more of a =E2=80=9Cif you want =
me, here is how to get me=E2=80=9D, but it would clearly work.

ISTM that a problem with =
the NG911 approach is that the mechanism for setting up the relay call =
is entirely different from the way it is done for other relay calls. So =
it becomes a path-less-used and hence less tested. It would be nice if =
the same technique was used for everyday calls and emergency calls, so =
that it was a well tested path.
Yeah, but =
it IS very special.  There is often a separate queue of call takers =
(trained for 9-1-1), and they have to route based on location of caller, =
not of CA, so they need to REFER the call to 9-1-1.


We might be better off =
with another mechanism that expressly states =E2=80=9CA translation =
service is available at this URI=E2=80=9D, which is the idea Gunnar has. =
 I think that is additive, not replacing the current proposed =
language tag mechanism.  You could imagine various forms of that =
which would include the source and destination language tags.  An =
out of country visitor might request translation to French, but if he is =
in Brazil, his preferred English to French service might not be =
helpful.

I can see how that might =
work if limited to US VRS service, especially if only for emergency =
calls. In that case a common law/contract can be in place to ensure that =
the translation service will accept the =
call.

In the more general case, =
possibly where clients of the service have to establish a business =
relationship with each provider, it won't work very well.
Why? =
 If you contract with Language Line, for example, they can handle n =
to m translation as long as English is either m or n for a significant =
number of n/ms.  I=E2=80=99m sure there are equivalents elsewhere. =
 So an English speaking caller could contract with LL to get what =
he needed, wherever he traveled.  If the caller supplies a URI, =
then it=E2=80=99s up to him to arrange contracts.  If the called =
party decides to use someone else, then it=E2=80=99s their =
contract.


It is also necessary that =
the invocation of the translation service be standardized so the entity =
invoking it knows how to do so. We hopefully will soon have something =
for VRS service in the US, but it doesn't work this way. And it is a =
long way from there to having a standard for all the different sorts of =
translation (relay) service.
Yeah, I agree we should have some =
kind of signaling standard, but that=E2=80=99s beyond what our current =
goals for slim.
When we finish, we can either recharter, or =
form another group to handle generalized =E2=80=9Ctranscoder=E2=80=9D =
signaling

Brian

	=
Thanks,
	=
Paul

Brian

On Jul 7, 2015, at 4:20 =
PM, Eric Burger <eburger@standardstrack.com> wrote:

I don't see how either way is enforceable. If we say the PSAP =
has to take the caller's translation service, any sensible PSAP will =
feel free to ignore it, whether due to cost, liability, or protecting =
against the PSAP being the source of a DoS attack. Conversely, if a =
particular PSAP could use a hint for a translation service, it would be =
handy for the caller to provide one.



Sent from my mobile device. Thanks be to =
LEMONADE: http://www.standardstrack.com/ietf/lemonade


-------- Original message =
--------
From: Brian Rosen <br@brianrosen.net>
Date: 07/07/2015 2:20 PM (GMT-05:00)
To: =
Randall Gellens <randy@qti.qualcomm.com>
Cc: Eric Burger =
<eburger@standardstrack.com>, slim@ietf.org
Subject: Re: [Slim] Translation Quality or type - or service =
provider

In general, the PSAP wants to use =
it=E2=80=99s bridge, and NOT have the translation service use its =
bridge.  There are clearly circumstances where the PSAP bridge =
cannot be used and we need a way to make sure the translation =
service=E2=80=99s bridge can be used.

Brian

On Jul 7, 2015, at 1:56 PM, Randall Gellens <randy@qti.qualcomm.com> wrote:

At 4:43 AM -0400 7/6/15, Eric Burger wrote:

 > On Jul 6, =
2015, at 3:24 AM, Gunnar Hellstr=C3=B6m <gunnar.hellstrom@omnitor.se> wrote:

One =
reason for the need to convey a translation service provider URI is that =
the emergency service RFCs 6443 and 6881 forbids the calling user to =
invoke three-party calling.

The text there is saying that the best practice for a device =
initiating an emergency call is to disable services that could interrupt =
the call, such as call waiting and third-party calling.  If the =
third-party call is initiated before or in parallel with the emergency =
call, the text wouldn't apply anyway, and if the third-party call is =
initiated during the emergency call in order to better serve the user's =
needs, then this is exactly why the text uses "SHOULD" instead of =
"MUST."  The word "SHOULD" means that a client is supposed to =
follow the direction unless there is an overriding reason not to, and =
the consequences of doing so are understood.  Both of those apply =
in the case under discussion.



6443 is =
informational and 6881 is a BCP. No problem to do something that works =
that is 'forbidden.'

For example RFC 6443, chapter 13 says "Services =
such as call waiting, call transfer, three-way calling, and hold should =
be disabled."

Note the use of =
'should.'  I do not think anyone will complain if one interprets =
this as, "Should be disabled, unless the user will die if she does not =
setup a three-way call with her translation service."

If then the user is in a =
foreign language environment where the PSAP barely can have a clue on =
how to find the right relay service, and the user has a good relay =
service URI configured, well capable of handling the user's language and =
modality, what is then best?

1) Break =
against RFC 6881 and 6443 and have the user terminal invoke the =
three-party call? The wording in these RFCs may be interpreted to have =
some room for such deviations.

Beyond the wording in the RFCs, there is a reason the IETF is =
not the protocol police. In retrospect, it may be safe to say the RFCs' =
suggestions are wrong.

2) Or convey the relay service URI to the PSAP =
for invocation.

Why not?


The discussion so far leads towards conclusion 1. It is ok =
for me, I just wanted it confirmed by showing the whole situation.

(there will always be complementing slow =
manual procedures, when the PSAP needs to figure out a reasonable way to =
handle the call, but this discussion is for the rapid automated way that =
should handle most cases.)

/Gunnar

Gunnar Hellstr=C3=B6m skrev den 2015-07-05 =
22:35:
Paul,
Yes, I agree that for most cases it is best that the party, =
who knows a service that will do the translation, does the =
invocation.

And, yes ,in that scenario the =
3PCC method seems suitable.

My proposal to =
send the service provider URI together with the modality indications was =
for the case when there are strong policy reasons why one party would do =
the invocation, but little chance that that party would have access to =
an up-to-date information on available translation providers.
That could be the case for the emergency service calling in a =
multi-language environment, also including support for sign language =
users.

Since both you and Randall think it =
is not doable, we can try to use the principle that the party, who knows =
a service that will do the translation, does the invocation.
 >>
That brings us back to a need for more stringent =
language/modality negotiation in order to avoid both double invocation =
of services when one or none is required, and also avoid no invocation =
when one is needed.

Paul Kyzivat skrev den =
2015-07-05 18:20:
Gunnar,

I understand what you =
are suggesting, but I don't believe it is workable. This seems to mean =
that the caller would select the service while the callee would engage =
the service in the call if needed. Yet it is likely to be the caller who =
has a business relationship with the service, while the callee does not. =
Gets complicated quickly.
 >>>
ISTM it makes more sense =
to first figure out what is/isn't possible without translation, and then =
for a party that finds a translation service beneficial to engage one. =
Then the only concern is that both parties don't independently try to =
introduce equivalent translation services.

For instance, a deaf caller might offer video media marked =
for sign language, and audio media on hold. If the answer doesn't accept =
the video, or doesn't indicate support for sign language, the caller =
could then conference in translation service, using the 3pcc transcoding =
model specified in rfc5369. (If that will take time, the deaf caller's =
UA could stream recorded media over the audio channel in the =
meantime.)

Or, to get fancier, it would be =
possible to use preconditions to defer alerting the callee until this is =
all sorted out.

My point is to let the =
participant who wants translation handle to setup of translation rather =
than depending on the other party to do something.
OK, it might be likely that both parties "want" =
translation, but one has better knowledge about how to get the required =
service and has business relations with the service. So then it is =
preferred that that party invokes.

Good
/Gunnar

   Thanks,
   Paul

On 7/5/15 =
2:48 AM, Gunnar Hellstr=C3=B6m wrote:
Another opportunity would be to convey a URI to =
the service provider who
did (for mail) or can do(for =
real-time) the translation.
Then experience with different =
service provider's production could give
some idea of the =
expected quality.
I can see great value in that for the =
real-time case, when the calling
user has a favourite =
translator (e.g. relay service), and provides that
as a =
hint if languages or modalities in the call does not match. Then
the callee do not need to just take a service provider by =
chance that
seem to match the language/modality profile =
but can take the one
proposed by the caller.

After working with the needs for emergency =
services to work across
Europe for some time now, I think =
this is one of the few workable
solutions. The user =
expresses both the language/modality needs and
provides a =
URI to a favourite translation service provider, and the
callee tries to fulfill the language/modality needs either by =
a matching
original call taker or by invoking the proposed =
translation provider.

/Gunnar


Randall Gellens skrev den =
2015-07-05 03:49:
My =
recollection is that this was discussed in email prior to Dallas,
but that's not important.

I am a =
strong proponent of keeping things as simple as possible,
provided there is a way to extend them if experience shows =
that it is
needed.  So, I think we should stick with =
the original suggestion of
three values ("original", =
"human", "automated"). This is simple enough
to be =
implementable and functional enough to be useful in providing a
hint that may help the client choose the best version for the =
user. If
we try and capture the various nuances of quality =
we will end up with
a very complex mechanism that is =
unlikely to be any more useful in
real life. Let's go with =
the simple approach now.  If, after some
deployment =
experience we realize that we really do need extra
complexity, we can extend the mechanism then.
At 4:29 PM +0100 7/3/15, Nik Tomkinson wrote:
 >>>>>
Thanks for the =
responses.

To deal with the issue with =
having only original/human/automated,
what about the =
following?:


translation-type =
:=3D type-token[ ";" "q" "=3D" qvalue ]
type-token =
:=3D"human" / "automated"

where qvalue is a =
value between 0 and 1 with a default of 0.5 if
missing

for example:

Translation-Type: human;q=3D0.8
Translation-Type:=
 automated;q=3D0.4
Translation-Type: human
The Translation-Type SHOULD NOT appear in the original
(untranslated) part but it SHOULD appear in translated =
content.
 >>>>>>
Having =
this missing from the original text helps identify which is
the source to be translated into further languages if the =
user mail
client allows.

This =
enables us to dispose of the 'original' value which didn't lend
itself well to being graded on quality.

The qvalue can be set by the sender or provided by the =
translation
service.

The =
draft suggests that:

"Additionally, =
interactive implementations MAY offer the user a
choice =
from among the available languages." so the qvalue may not
need to be bulletproof.

Comments?

Nik.

On 3 July 2015 at 09:46, Gunnar Hellstr=C3=B6m
<<mailto:gunnar.hellstrom@omnitor.se>gunnar.hellstrom@omnitor.se> wrote:

I see some value of this kind of parameter also for the =
real-time case.
The time is here when it can be possible =
in some situations to
select between using a low-cost =
automatic speech-to-text generation
and a higher cost =
captioned telephony or text-relay service (higher
cost for =
someone, not always the end-user).

But I =
agree that it is very hard to set good understandable values
on a parameter expressing the type or quality of this kind of =
service.

Gunnar



Stephane Bortzmeyer skrev den =
2015-07-03 08:49:

On Thu, Jul 02, 2015 at =
11:09:30PM +0100,
  Nik Tomkinson
<<mailto:rfc.nik.tomkinson@gmail.com>rfc.nik.tomkinson@gmail.com> wrote
  a message of 109 lines which said:

type-token :=3D "original" / "human" / =
"automated"

In many IETF working groups, =
when there is such a proposal, there is a
big discussion =
between the registryfull and the registryless
people. The =
first ones say there must be an authoritative list of
values=
 (in the RFC or, better because more evolving, in an IANA
registry) so we can be sure of the interpretation of values. =
The
second ones say we can never capture all the nuances =
and subtleties of
the world in a fixed list.

Here, I am not sure that the only meaningful =
distinction is between
"human" and "automated". Some =
humans do a very poor job, too. One
could suggest:

type-token :=3D "original" / =
"professional-human" / "amateur-human" /
"automated-first-generation" / =
"automated-artificial-intelligence" /
"automated-the-robot-in-hollywood-movies"

Or decide that it will be too complicated and we should =
instead
accept:

type-token :=3D=
 "original" / <free text>

Toughts?

_______________________________________________
SLIM mailing list
<mailto:SLIM@ietf.org>SLIM@ietf.org

<https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim



_______________________________________________
SLIM mailing list
<mailto:SLIM@ietf.org>SLIM@ietf.org

<https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim




--

---------------------------------------------------------------=
--
Multiple Language Content Type Internet Draft:

<http://datatracker.ietf.org/doc/draft-tomkinson-multilangconten=
t/>http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangc=
ontent/
 >>>>>>
---------------------------------------------------------------=
--

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





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


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

_______________________________________________
 > SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim


Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=3D"signature.asc"
Content-Type: application/pgp-signature;
name=3Dsignature.asc
Content-Description: =
Message signed with OpenPGP using GPGMail

Attachment converted: TiLand:signature 415.asc ( =
   /    ) (028C4061)
_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim



--Randall Gellens
Opinions are personal; =
   facts are suspect;    I speak for =
myself only
-------------- Randomly selected tag: =
---------------
Progress is made on alternate Fridays.

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

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

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


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

=

--Apple-Mail=_27BC3A2E-67F3-4332-A699-92D890AF4AB9--


From nobody Tue Jul  7 15:15:46 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD2C1AD37C for ; Tue,  7 Jul 2015 15:15:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level: 
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 CY7bKW8cTNOB for ; Tue,  7 Jul 2015 15:15:41 -0700 (PDT)
Received: from bin-vsp-out-01.atm.binero.net (vsp-authed02.binero.net [195.74.38.226]) (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 75D081B137B for ; Tue,  7 Jul 2015 15:15:40 -0700 (PDT)
X-Halon-ID: bbd4ee92-24f5-11e5-8487-005056917a89
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.43.70] (unknown [2.66.110.249]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Wed,  8 Jul 2015 00:15:53 +0200 (CEST)
Message-ID: <559C4F84.1070701@omnitor.se>
Date: Wed, 08 Jul 2015 00:15:32 +0200
From: =?UTF-8?B?R3VubmFyIEhlbGxzdHLDtm0=?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Brian Rosen 
References:  <5E0D2DE0-FC2F-4681-B05C-D924A44B43E8@brianrosen.net>
In-Reply-To: <5E0D2DE0-FC2F-4681-B05C-D924A44B43E8@brianrosen.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "slim@ietf.org" 
Subject: Re: [Slim] Translation Quality or type - or service provider
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Jul 2015 22:15:45 -0000

Brian Rosen skrev den 2015-07-07 23:00:
> Of course it’s not enforceable, but since there are a finite number of VRS providers, the PSAP community can prevail upon them to do the right thing.  The worst case, where there are two bridges, is annoying but not fatal.
We have a more complicated situation in Europe with all different sign 
languages and all different spoken languages, and usually, if there is 
any  VRS , they usually only translate between one sing language and one 
spoken language.
You are right, they are a finite number, but the correct selection must 
be done.
>
> What we need is clear labeling of what is requested, something we don’t have now, but slim will provide.
>
> The current NENA documents say that the outgoing proxy server adds a Referred-By header to the call.  The PSAP may use the URI of the Referred-by to bridge in the referring party, which is the CA at the outgoing proxy of the VRS provider.
Yes, I have seen that, and wondered how that step in the procedure 
works. Is it an application convention in NENA and EENA PSAPS to use the 
Referred-by information in that way, or is it a common SIP convention?
>    This works exactly the way the current U.S. regulations say it should work, where first a two way is established between the CA and the caller and then the call is extended as a 9-1-1 call.  It wouldn’t work as well in Gunnar’s environment where the SIP service provider isn’t the relay provider, but something similar could work.
The procedures should not assume that the user terminal is 
SIP-registered in the relay service. That makes it impossible to move to 
use of something that can be called mainstream terminals for users of 
relay services. There may be European services also, where the users 
seem to be SIP-registered in the relay service. We just must not 
document the proccedures as if that is a prerequisite. Rather view such 
relay services who also have registered terminals as if they are 
composed of a communications service part and a translation provider 
part. They are separate functions anyway.

The mechanism from chapter 9 in EENA/NENA specifications would work also 
for the separated architecture, with SIP provider and relay provider 
separate. The user might make a regular call that the SIP provider 
detects should go to the relay service. The relay servicedetects that it 
should be an emergency call and refers it back to the user to call 
urn:service:sos instead.

Hopefully, in most cases the terminal will instead be able to make the 
emergency call directly together with indications of languages and 
modalities and possibly the assisting service, so that that first Refer 
step is avoided.
>
> For “direct routing”, where you don’t get the 2-way before a 3-way is established, the VRS provider (in the US) can still add the Referred-by, which would allow the PSAP to either use it, or it’s own choice of relay provider.  It’s a bit weird, in that there is no actual referral, it’s more of a “if you want me, here is how to get me”, but it would clearly work.
>
> We might be better off with another mechanism that expressly states “A translation service is available at this URI”, which is the idea Gunnar has.  I think that is additive, not replacing the current proposed language tag mechanism.  You could imagine various forms of that which would include the source and destination language tags.  An out of country visitor might request translation to French, but if he is in Brazil, his preferred English to French service might not be helpful.
Right. The language tag is needed to try to match the live service in 
the PSAP, but if not successful, the service at the URI can at least 
help to get the call translated to a spoken language. In worst case 
there will also be a need for another translation between two spoken 
languages.

But I also had the other example of when I supposed that an URI would be 
needed, or that the call comes with a relay service ready invoked. That 
was for the cases when it is hard to express the needs in modality 
preferences. I think the speech-to-speech need is the most apparent. 
Someone said that we should develop tags for that kind of needs as well.
How can that be coded? Can we have a try to define it now?

Should it be an addition to the SLIM codes in SDP for audio? something 
like   humintlang-send=fr,type:sts   That should be interpreted as 
speaking french but with the type of speaking that usually requires a 
speech-to-speech service to support.
And the service would in its audio declaration  have something like 
humintlang-receive=fr,type:sts

Or should it go into a sip level field, including a URI to the service?

/Gunnar
>
> Brian
>
>> On Jul 7, 2015, at 4:20 PM, Eric Burger  wrote:
>>
>> I don't see how either way is enforceable. If we say the PSAP has to take the caller's translation service, any sensible PSAP will feel free to ignore it, whether due to cost, liability, or protecting against the PSAP being the source of a DoS attack. Conversely, if a particular PSAP could use a hint for a translation service, it would be handy for the caller to provide one.
>>
>>
>>
>> Sent from my mobile device. Thanks be to LEMONADE: http://www.standardstrack.com/ietf/lemonade
>>
>>
>> -------- Original message --------
>> From: Brian Rosen 
>> Date: 07/07/2015 2:20 PM (GMT-05:00)
>> To: Randall Gellens 
>> Cc: Eric Burger , slim@ietf.org
>> Subject: Re: [Slim] Translation Quality or type - or service provider
>>
>> In general, the PSAP wants to use it’s bridge, and NOT have the translation service use its bridge.  There are clearly circumstances where the PSAP bridge cannot be used and we need a way to make sure the translation service’s bridge can be used.
>>
>> Brian
>>
>>> On Jul 7, 2015, at 1:56 PM, Randall Gellens  wrote:
>>>
>>> At 4:43 AM -0400 7/6/15, Eric Burger wrote:
>>>
>>>>   > On Jul 6, 2015, at 3:24 AM, Gunnar Hellström  wrote:
>>>>> One reason for the need to convey a translation service provider URI is that the emergency service RFCs 6443 and 6881 forbids the calling user to invoke three-party calling.
>>> The text there is saying that the best practice for a device initiating an emergency call is to disable services that could interrupt the call, such as call waiting and third-party calling.  If the third-party call is initiated before or in parallel with the emergency call, the text wouldn't apply anyway, and if the third-party call is initiated during the emergency call in order to better serve the user's needs, then this is exactly why the text uses "SHOULD" instead of "MUST."  The word "SHOULD" means that a client is supposed to follow the direction unless there is an overriding reason not to, and the consequences of doing so are understood.  Both of those apply in the case under discussion.
>>>
>>>
>>>> 6443 is informational and 6881 is a BCP. No problem to do something that works that is 'forbidden.'
>>>>
>>>>> For example RFC 6443, chapter 13 says "Services such as call waiting, call transfer, three-way calling, and hold should be disabled."
>>>> Note the use of 'should.'  I do not think anyone will complain if one interprets this as, "Should be disabled, unless the user will die if she does not setup a three-way call with her translation service."
>>>>
>>>>> If then the user is in a foreign language environment where the PSAP barely can have a clue on how to find the right relay service, and the user has a good relay service URI configured, well capable of handling the user's language and modality, what is then best?
>>>>>
>>>>> 1) Break against RFC 6881 and 6443 and have the user terminal invoke the three-party call? The wording in these RFCs may be interpreted to have some room for such deviations.
>>>> Beyond the wording in the RFCs, there is a reason the IETF is not the protocol police. In retrospect, it may be safe to say the RFCs' suggestions are wrong.
>>>>
>>>>> 2) Or convey the relay service URI to the PSAP for invocation.
>>>> Why not?
>>>>
>>>>> The discussion so far leads towards conclusion 1. It is ok for me, I just wanted it confirmed by showing the whole situation.
>>>>>
>>>>> (there will always be complementing slow manual procedures, when the PSAP needs to figure out a reasonable way to handle the call, but this discussion is for the rapid automated way that should handle most cases.)
>>>>>
>>>>> /Gunnar
>>>>>
>>>>> Gunnar Hellström skrev den 2015-07-05 22:35:
>>>>>> Paul,
>>>>>> Yes, I agree that for most cases it is best that the party, who knows a service that will do the translation, does the invocation.
>>>>>>
>>>>>> And, yes ,in that scenario the 3PCC method seems suitable.
>>>>>>
>>>>>> My proposal to send the service provider URI together with the modality indications was for the case when there are strong policy reasons why one party would do the invocation, but little chance that that party would have access to an up-to-date information on available translation providers.
>>>>>> That could be the case for the emergency service calling in a multi-language environment, also including support for sign language users.
>>>>>>
>>>>>> Since both you and Randall think it is not doable, we can try to use the principle that the party, who knows a service that will do the translation, does the invocation.
>>>>   >>
>>>>>> That brings us back to a need for more stringent language/modality negotiation in order to avoid both double invocation of services when one or none is required, and also avoid no invocation when one is needed.
>>>>>>
>>>>>> Paul Kyzivat skrev den 2015-07-05 18:20:
>>>>>>> Gunnar,
>>>>>>>
>>>>>>> I understand what you are suggesting, but I don't believe it is workable. This seems to mean that the caller would select the service while the callee would engage the service in the call if needed. Yet it is likely to be the caller who has a business relationship with the service, while the callee does not. Gets complicated quickly.
>>>>   >>>
>>>>>>> ISTM it makes more sense to first figure out what is/isn't possible without translation, and then for a party that finds a translation service beneficial to engage one. Then the only concern is that both parties don't independently try to introduce equivalent translation services.
>>>>>>>
>>>>>>> For instance, a deaf caller might offer video media marked for sign language, and audio media on hold. If the answer doesn't accept the video, or doesn't indicate support for sign language, the caller could then conference in translation service, using the 3pcc transcoding model specified in rfc5369. (If that will take time, the deaf caller's UA could stream recorded media over the audio channel in the meantime.)
>>>>>>>
>>>>>>> Or, to get fancier, it would be possible to use preconditions to defer alerting the callee until this is all sorted out.
>>>>>>>
>>>>>>> My point is to let the participant who wants translation handle to setup of translation rather than depending on the other party to do something.
>>>>>> OK, it might be likely that both parties "want" translation, but one has better knowledge about how to get the required service and has business relations with the service. So then it is preferred that that party invokes.
>>>>>>
>>>>>> Good
>>>>>> /Gunnar
>>>>>>>     Thanks,
>>>>>>>     Paul
>>>>>>>
>>>>>>> On 7/5/15 2:48 AM, Gunnar Hellström wrote:
>>>>>>>> Another opportunity would be to convey a URI to the service provider who
>>>>>>>> did (for mail) or can do(for real-time) the translation.
>>>>>>>> Then experience with different service provider's production could give
>>>>>>>> some idea of the expected quality.
>>>>>>>> I can see great value in that for the real-time case, when the calling
>>>>>>>> user has a favourite translator (e.g. relay service), and provides that
>>>>>>>> as a hint if languages or modalities in the call does not match. Then
>>>>>>>> the callee do not need to just take a service provider by chance that
>>>>>>>> seem to match the language/modality profile but can take the one
>>>>>>>> proposed by the caller.
>>>>>>>>
>>>>>>>> After working with the needs for emergency services to work across
>>>>>>>> Europe for some time now, I think this is one of the few workable
>>>>>>>> solutions. The user expresses both the language/modality needs and
>>>>>>>> provides a URI to a favourite translation service provider, and the
>>>>>>>> callee tries to fulfill the language/modality needs either by a matching
>>>>>>>> original call taker or by invoking the proposed translation provider.
>>>>>>>>
>>>>>>>> /Gunnar
>>>>>>>>
>>>>>>>>
>>>>>>>> Randall Gellens skrev den 2015-07-05 03:49:
>>>>>>>>> My recollection is that this was discussed in email prior to Dallas,
>>>>>>>>> but that's not important.
>>>>>>>>>
>>>>>>>>> I am a strong proponent of keeping things as simple as possible,
>>>>>>>>> provided there is a way to extend them if experience shows that it is
>>>>>>>>> needed.  So, I think we should stick with the original suggestion of
>>>>>>>>> three values ("original", "human", "automated"). This is simple enough
>>>>>>>>> to be implementable and functional enough to be useful in providing a
>>>>>>>>> hint that may help the client choose the best version for the user. If
>>>>>>>>> we try and capture the various nuances of quality we will end up with
>>>>>>>>> a very complex mechanism that is unlikely to be any more useful in
>>>>>>>>> real life. Let's go with the simple approach now.  If, after some
>>>>>>>>> deployment experience we realize that we really do need extra
>>>>>>>>> complexity, we can extend the mechanism then.
>>>>>>>>>
>>>>>>>>> At 4:29 PM +0100 7/3/15, Nik Tomkinson wrote:
>>>>   >>>>>
>>>>>>>>>> Thanks for the responses.
>>>>>>>>>>
>>>>>>>>>> To deal with the issue with having only original/human/automated,
>>>>>>>>>> what about the following?:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> translation-type := type-token[ ";" "q" "=" qvalue ]
>>>>>>>>>> type-token :="human" / "automated"
>>>>>>>>>>
>>>>>>>>>> where qvalue is a value between 0 and 1 with a default of 0.5 if
>>>>>>>>>> missing
>>>>>>>>>>
>>>>>>>>>> for example:
>>>>>>>>>>
>>>>>>>>>> Translation-Type: human;q=0.8
>>>>>>>>>> Translation-Type: automated;q=0.4
>>>>>>>>>> Translation-Type: human
>>>>>>>>>>
>>>>>>>>>> The Translation-Type SHOULD NOT appear in the original
>>>>>>>>>> (untranslated) part but it SHOULD appear in translated content.
>>>>   >>>>>>
>>>>>>>>>> Having this missing from the original text helps identify which is
>>>>>>>>>> the source to be translated into further languages if the user mail
>>>>>>>>>> client allows.
>>>>>>>>>>
>>>>>>>>>> This enables us to dispose of the 'original' value which didn't lend
>>>>>>>>>> itself well to being graded on quality.
>>>>>>>>>>
>>>>>>>>>> The qvalue can be set by the sender or provided by the translation
>>>>>>>>>> service.
>>>>>>>>>>
>>>>>>>>>> The draft suggests that:
>>>>>>>>>>
>>>>>>>>>> "Additionally, interactive implementations MAY offer the user a
>>>>>>>>>> choice from among the available languages." so the qvalue may not
>>>>>>>>>> need to be bulletproof.
>>>>>>>>>>
>>>>>>>>>> Comments?
>>>>>>>>>>
>>>>>>>>>> Nik.
>>>>>>>>>>
>>>>>>>>>> On 3 July 2015 at 09:46, Gunnar Hellström
>>>>>>>>>> <gunnar.hellstrom@omnitor.se> wrote:
>>>>>>>>>>
>>>>>>>>>> I see some value of this kind of parameter also for the real-time case.
>>>>>>>>>> The time is here when it can be possible in some situations to
>>>>>>>>>> select between using a low-cost automatic speech-to-text generation
>>>>>>>>>> and a higher cost captioned telephony or text-relay service (higher
>>>>>>>>>> cost for someone, not always the end-user).
>>>>>>>>>>
>>>>>>>>>> But I agree that it is very hard to set good understandable values
>>>>>>>>>> on a parameter expressing the type or quality of this kind of service.
>>>>>>>>>>
>>>>>>>>>> Gunnar
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Stephane Bortzmeyer skrev den 2015-07-03 08:49:
>>>>>>>>>>
>>>>>>>>>> On Thu, Jul 02, 2015 at 11:09:30PM +0100,
>>>>>>>>>>    Nik Tomkinson
>>>>>>>>>> <rfc.nik.tomkinson@gmail.com> wrote
>>>>>>>>>>    a message of 109 lines which said:
>>>>>>>>>>
>>>>>>>>>> type-token := "original" / "human" / "automated"
>>>>>>>>>>
>>>>>>>>>> In many IETF working groups, when there is such a proposal, there is a
>>>>>>>>>> big discussion between the registryfull and the registryless
>>>>>>>>>> people. The first ones say there must be an authoritative list of
>>>>>>>>>> values (in the RFC or, better because more evolving, in an IANA
>>>>>>>>>> registry) so we can be sure of the interpretation of values. The
>>>>>>>>>> second ones say we can never capture all the nuances and subtleties of
>>>>>>>>>> the world in a fixed list.
>>>>>>>>>>
>>>>>>>>>> Here, I am not sure that the only meaningful distinction is between
>>>>>>>>>> "human" and "automated". Some humans do a very poor job, too. One
>>>>>>>>>> could suggest:
>>>>>>>>>>
>>>>>>>>>> type-token := "original" / "professional-human" / "amateur-human" /
>>>>>>>>>> "automated-first-generation" / "automated-artificial-intelligence" /
>>>>>>>>>> "automated-the-robot-in-hollywood-movies"
>>>>>>>>>>
>>>>>>>>>> Or decide that it will be too complicated and we should instead
>>>>>>>>>> accept:
>>>>>>>>>>
>>>>>>>>>> type-token := "original" / 
>>>>>>>>>>
>>>>>>>>>> Toughts?
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> SLIM mailing list
>>>>>>>>>> SLIM@ietf.org
>>>>>>>>>>
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/slim
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> SLIM mailing list
>>>>>>>>>> SLIM@ietf.org
>>>>>>>>>>
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/slim
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>
>>>>>>>>>> -----------------------------------------------------------------
>>>>>>>>>> Multiple Language Content Type Internet Draft:
>>>>>>>>>>
>>>>>>>>>> http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/
>>>>   >>>>>>
>>>>>>>>>> -----------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> SLIM mailing list
>>>>>>>>>> SLIM@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/slim
>>>>>>>>>
>>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> SLIM mailing list
>>>>>>> SLIM@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/slim
>>>>> --
>>>>> -----------------------------------------
>>>>> Gunnar Hellström
>>>>> Omnitor
>>>>> gunnar.hellstrom@omnitor.se
>>>>> +46 708 204 288
>>>>>
>>>>> _______________________________________________
>>>>   > SLIM mailing list
>>>>> SLIM@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/slim
>>>>
>>>> Content-Transfer-Encoding: 7bit
>>>> Content-Disposition: attachment; filename="signature.asc"
>>>> Content-Type: application/pgp-signature;
>>>> name=signature.asc
>>>> Content-Description: Message signed with OpenPGP using GPGMail
>>>>
>>>> Attachment converted: TiLand:signature 415.asc (    /    ) (028C4061)
>>>> _______________________________________________
>>>> SLIM mailing list
>>>> SLIM@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/slim
>>>
>>>
>>> -- 
>>> Randall Gellens
>>> Opinions are personal;    facts are suspect;    I speak for myself only
>>> -------------- Randomly selected tag: ---------------
>>> Progress is made on alternate Fridays.
>>>
>>> _______________________________________________
>>> SLIM mailing list
>>> SLIM@ietf.org
>>> https://www.ietf.org/mailman/listinfo/slim
>> _______________________________________________
>> SLIM mailing list
>> SLIM@ietf.org
>> https://www.ietf.org/mailman/listinfo/slim
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim

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


From nobody Wed Jul  8 07:18:28 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 040811B369B for ; Wed,  8 Jul 2015 07:18:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level: 
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 ySYKuNNkf5ch for ; Wed,  8 Jul 2015 07:18:24 -0700 (PDT)
Received: from bin-vsp-out-02.atm.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 E24AB1B3712 for ; Wed,  8 Jul 2015 07:11:17 -0700 (PDT)
X-Halon-ID: 2f617013-257b-11e5-bc2f-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.43.70] (unknown [2.66.110.249]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Wed,  8 Jul 2015 16:11:10 +0200 (CEST)
Message-ID: <559D2F7F.5060707@omnitor.se>
Date: Wed, 08 Jul 2015 16:11:11 +0200
From: =?windows-1252?Q?Gunnar_Hellstr=F6m?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: "slim@ietf.org" , Randall Gellens 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: [Slim] Use cases in draft-gellens-slim-negotiating-human-language-02
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Jul 2015 14:18:26 -0000

Hi Randall,
In March, around 5-7, I submitted a couple of use case text proposals 
indented for draft-gellens-slim-negotiating-human-language.
I did not see any rejection of them but I do not see them included in 
version -02.

Do you want me to resubmit them?

Regards

Gunnar

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


From nobody Wed Jul  8 10:30:43 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3561A1B79; Wed,  8 Jul 2015 10:30:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.011
X-Spam-Level: 
X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 HJGGtqe_2Ukn; Wed,  8 Jul 2015 10:30:40 -0700 (PDT)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBD341A1A87; Wed,  8 Jul 2015 10:30:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1436376640; x=1467912640; h=message-id:date:to:from:subject:cc:mime-version; bh=8/s+ng3AiLM6GjPtQMazDhVV/IrBrky/3ybRgI15w8I=; b=q+Xb+jPxZZjj6381xbyI9eNivnIbKksg9wVlch78qlbOtC/2yA6bOAj0 uAYu+Cc1qS5AzM7KS3xnbBPy5+18OMtLOi7zVE0Sm4lz/DvWrTtXimeee kd91BeNLIpT/7pcgxOub8bTHUd/g/+m3Z0pLhHQhZf+ykFpFz6WgXnqbJ M=;
X-IronPort-AV: E=McAfee;i="5700,7163,7856"; a="126852210"
Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Jul 2015 10:30:39 -0700
X-IronPort-AV: E=Sophos;i="5.15,432,1432623600"; d="scan'208";a="955982984"
Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 08 Jul 2015 10:30:32 -0700
Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 8 Jul 2015 10:30:31 -0700
Message-ID: 
X-Mailer: Eudora for Mac OS X
Date: Wed, 8 Jul 2015 10:30:30 -0700
To: Bernard Aboba , Brian Rosen , Gunnar Hellstrom , Hannes Tschofenig , Henning Schulzrinne , Ban Al-Bakri , Barry Leiba 
From: Randall Gellens 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Originating-IP: [10.80.80.8]
X-ClientProxiedBy: NASANEXM01F.na.qualcomm.com (10.85.0.32) To nasanexm02f.na.qualcomm.com (10.85.0.87)
Archived-At: 
Cc: slim@ietf.org, ecrit@ietf.org
Subject: [Slim] Time in Prague to discuss SLIM real-time draft
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Jul 2015 17:30:42 -0000

I'd like to set a time to meet in Prague so that Bernard, Brian, 
myself, and anyone else interested can talk in depth about the SLIM 
real-time draft.  Would Monday lunch work?  If not, please suggest 
some alternate times.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
You never finish a program, you just stop working on it.


From nobody Wed Jul  8 10:39:30 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86BC71A1BD9 for ; Wed,  8 Jul 2015 10:39:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.011
X-Spam-Level: 
X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 kQ9h6oBDORLZ for ; Wed,  8 Jul 2015 10:39:28 -0700 (PDT)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E9901A1BC8 for ; Wed,  8 Jul 2015 10:39:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1436377168; x=1467913168; h=message-id:date:to:from:subject:cc:mime-version; bh=yijH2BAmkyyayUzVk3VcoW/73UH0kd7chkNEf0y0jLc=; b=PflYNGU/zJO/SF1g5bdJykhypundWq+3t3MfHQI+5dWpRoDnUzm6DZ93 8pMQNRNTSgo9bdaTjX/Ev/IZ2BflZ2UqZrIg7db5HXL+7Ry855q9Q6f1p 6kKNpxu1W91MUuH23Jgz8jWRhgrAjlQX/siw2WSqWX71xJMFtBCboZUst w=;
X-IronPort-AV: E=McAfee;i="5700,7163,7856"; a="93348099"
Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Jul 2015 10:39:27 -0700
X-IronPort-AV: E=Sophos;i="5.15,432,1432623600"; d="scan'208";a="930659624"
Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 08 Jul 2015 10:38:48 -0700
Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 8 Jul 2015 10:37:09 -0700
Message-ID: 
X-Mailer: Eudora for Mac OS X
Date: Wed, 8 Jul 2015 10:37:08 -0700
To: Nik Tomkinson , Nathaniel Borenstein , Paul Kyzivat , Eric Burger 
From: Randall Gellens 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Originating-IP: [10.80.80.8]
X-ClientProxiedBy: NASANEXM01B.na.qualcomm.com (10.85.0.82) To nasanexm02f.na.qualcomm.com (10.85.0.87)
Archived-At: 
Cc: slim@ietf.org
Subject: [Slim] Meet in Prague to discuss email SLIM draft?
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Jul 2015 17:39:29 -0000

Would people like to meet in Prague to talk about the SLIM email 
draft?  How about Thursday lunch or Thursday first afternoon session 
or Thursday second after session?  Or, suggest alternate times.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
There are advantages to having a sane person run a government.
                            --Character in TV series "Wiseguy"


From nobody Wed Jul  8 10:49:30 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6197B1A1EFE for ; Wed,  8 Jul 2015 10:49:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.012
X-Spam-Level: 
X-Spam-Status: No, score=-1.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=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 aPSw87UP7XO3 for ; Wed,  8 Jul 2015 10:49:28 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A5161A1EF3 for ; Wed,  8 Jul 2015 10:49:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default;  h=To:References:Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=MjYB22rTF/qA+iddpHMhelmaPJrh6+7JIJpAkiZpDv8=;  b=VWsHSGTljSHkULtZne45mKrf0hWI++VLpjivJHlqWmAl5qt9PsTEhWVWAeeJCz9KAIh9JWghyTKesyRnQkddvhvE7al1cUHxQUv/Xl43v8QjdrgrqaXGMyGiEw3+LWFTF6mM556w/c4QZR1v46ZbtQYDfOT3bCuxTGmx2xSmnKw=;
Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:62503 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZCtTL-0003EV-A6 for slim@ietf.org; Wed, 08 Jul 2015 10:49:28 -0700
Content-Type: multipart/signed; boundary="Apple-Mail=_DDB3C4F6-A922-4EFD-BF03-4B48A7F7E3DE"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
X-Pgp-Agent: GPGMail 2.5
From: Eric Burger 
In-Reply-To: 
Date: Wed, 8 Jul 2015 13:49:25 -0400
Message-Id: 
References: 
To: slim@ietf.org
X-Mailer: Apple Mail (2.2098)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.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: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
Archived-At: 
Subject: Re: [Slim] Meet in Prague to discuss email SLIM draft?
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Jul 2015 17:49:29 -0000

--Apple-Mail=_DDB3C4F6-A922-4EFD-BF03-4B48A7F7E3DE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

It is looking very much like I will be remote for this IETF (unless one =
of your companies wants to sponsor a starving researcher :-). Thursday =
first or second afternoon session would be perfect for me. Would someone =
not mind running Skype, Zoom, Meetecho, Google Hangouts, or some such =
real-time communications system?

> On Jul 8, 2015, at 1:37 PM, Randall Gellens  =
wrote:
>=20
> Would people like to meet in Prague to talk about the SLIM email =
draft?  How about Thursday lunch or Thursday first afternoon session or =
Thursday second after session?  Or, suggest alternate times.
>=20
> --
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for myself =
only
> -------------- Randomly selected tag: ---------------
> There are advantages to having a sane person run a government.
>                           --Character in TV series "Wiseguy"


--Apple-Mail=_DDB3C4F6-A922-4EFD-BF03-4B48A7F7E3DE
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVnWKmAAoJEORoZaSQsc1IEfEP/3gucjKa57UHwVKdlX0OKUP3
a/upzR/YScxq5X2lzG7b23mubA4J798Zj84ekm9iZ+pAfmzMen9u7bBiMGIouPvn
GYUglgwNQ+7Ue7oHBBCuKTMZ8VPcrmRpG6xRnZzYrf7LC9JLHDsUAFopAyKV3/uX
BnxPEc7sleKLcDqANf+AgARzeUIYXk5esJ4IBKw3Tyf7mXas8Jpg9bcp+QGy9zWO
kYgsJ1N1MfkJfFMMlHM0TLKRuu1dnJkeG0U8X+/pmSnQDqHgjrBRP4jHDNhncmp9
5xPIo1bGmLryyFLJYQXCLjaa8mGtEWSKDDKjqIgG7fJJO4ZL/CreDbhHb2IZcZuO
6UwBpdnDx75ZflL07gsqcNePbDpHiytRMRGKKn2uk6AY+0eslIYl3vPqqxMz80oM
QYIiVoVXBn2NhDewfDHC+pocQQwf+N7LYmO1WcmiMhnSsN5gKrhvSk6Yf20s3P1K
wGk0LgbQO30XEdpXrRPK1YlcI16CGvwW3Y+/95GfQ/cINxaisrz8O/Tw2kuOS7/v
gMHmp4i+KGl2KxZ5NWVWFGQnd0tr76KgH0Wxz/OQO42aWZkWc0/pmNRqzEuNqyfh
mo147CNSeI5EhwHkZCeuysrhpw3+xNfUdD9+VBT+PaBR3WMxZUJIo8pWmn2KBLGk
iidL3EPvF7UWEQxObIfq
=YN5X
-----END PGP SIGNATURE-----

--Apple-Mail=_DDB3C4F6-A922-4EFD-BF03-4B48A7F7E3DE--


From nobody Wed Jul  8 12:04:02 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D65411A8547 for ; Wed,  8 Jul 2015 12:04:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 bYfyNKY4AvRe for ; Wed,  8 Jul 2015 12:04:00 -0700 (PDT)
Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CDAD1A86EF for ; Wed,  8 Jul 2015 12:03:47 -0700 (PDT)
Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-09v.sys.comcast.net with comcast id pv2C1q0032Qkjl901v3mbh; Wed, 08 Jul 2015 19:03:46 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-15v.sys.comcast.net with comcast id pv3m1q00A3Ge9ey01v3m45; Wed, 08 Jul 2015 19:03:46 +0000
Message-ID: <559D7411.3080706@alum.mit.edu>
Date: Wed, 08 Jul 2015 15:03:45 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: slim@ietf.org
References:  
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1436382226; bh=3zx3PzEtcB5I1xBBbLEsfb0fdfMRt0OsBAqEi6XSlfc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=QiJ3mwmQo3hc5Jua/1m2OyiqbRaikWaVod0vSUD+31Nl4ND6KsVPMZxlGuv3auKIL GY1zWqlJMlBZtN+QFZTeD/WeMfhWAbGLXJhML1DdVbbxnQEWKwQZ81HAXbalBpPlXN gbwsSS9nFKGRlMGJZ7yNkZ2ryV2MJDUXcEFz9lHsXsvFJBUzniWnzaJEKiu74/e8Bk utvGosMFHlJQy7J6mLjVYMIyGLhUm1Q6krkQ+m/z1ZqkLUDylQTOA1HveBT1G1fMAi LgNHt/rsZhr5l1y2H452QIXaar9Bdl6HgCGbxo7PcOzDC7EQoRVPJRA5ogw89zfmjf J4IyBjTsEF7Xg==
Archived-At: 
Subject: Re: [Slim] Meet in Prague to discuss email SLIM draft?
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Jul 2015 19:04:02 -0000

I also won't be in Prague. Could attend remotely.

	Thanks,
	Paul

On 7/8/15 1:49 PM, Eric Burger wrote:
> It is looking very much like I will be remote for this IETF (unless one of your companies wants to sponsor a starving researcher :-). Thursday first or second afternoon session would be perfect for me. Would someone not mind running Skype, Zoom, Meetecho, Google Hangouts, or some such real-time communications system?
>
>> On Jul 8, 2015, at 1:37 PM, Randall Gellens  wrote:
>>
>> Would people like to meet in Prague to talk about the SLIM email draft?  How about Thursday lunch or Thursday first afternoon session or Thursday second after session?  Or, suggest alternate times.
>>
>> --
>> Randall Gellens
>> Opinions are personal;    facts are suspect;    I speak for myself only
>> -------------- Randomly selected tag: ---------------
>> There are advantages to having a sane person run a government.
>>                            --Character in TV series "Wiseguy"
>
>
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim
>


From nobody Wed Jul  8 12:06:55 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD601A1BD1; Wed,  8 Jul 2015 10:39:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.267
X-Spam-Level: 
X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 lA4xKNw33o32; Wed,  8 Jul 2015 10:39:42 -0700 (PDT)
Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 1160C1A1BC8; Wed,  8 Jul 2015 10:39:42 -0700 (PDT)
Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t68HY5Et020063;  Wed, 8 Jul 2015 13:39:28 -0400
Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1vh5qf89e6-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 08 Jul 2015 13:39:28 -0400
Received: from STNTEXMB13.cis.neustar.com ([169.254.3.249]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Wed, 8 Jul 2015 13:39:27 -0400
From: "Rosen, Brian" 
To: Randall Gellens , Bernard Aboba , Gunnar Hellstrom , Hannes Tschofenig , Henning Schulzrinne , Ban Al-Bakri , Barry Leiba 
Thread-Topic: Time in Prague to discuss SLIM real-time draft
Thread-Index: AQHQuaPQLz9b6vQk6kqhL9Xrn4FEcJ3R1sOA
Date: Wed, 8 Jul 2015 17:39:26 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [10.33.193.32]
Content-Type: text/plain; charset="utf-8"
Content-ID: <52EE064A29C0604C88AE22E07BCFB333@neustar.biz>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33,  0.0.0000 definitions=2015-07-08_09:2015-07-08,2015-07-08,1970-01-01 signatures=0
X-Proofpoint-Spam-Reason: safe
Archived-At: 
X-Mailman-Approved-At: Wed, 08 Jul 2015 12:06:53 -0700
Cc: "slim@ietf.org" , "ecrit@ietf.org" 
Subject: Re: [Slim] Time in Prague to discuss SLIM real-time draft
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Jul 2015 17:39:43 -0000

SG1tbSwgSSB0aGluayBNb25kYXkgbHVuY2ggd29ya3MgZm9yIG1lIHRoaXMgbWVldGluZyAobm8g
bW9yZSBBcHBzIGNoYWlyDQpsdW5jaCkuDQoNCk9uIDcvOC8xNSwgMTozMCBQTSwgIlJhbmRhbGwg
R2VsbGVucyIgPHJhbmR5QHF0aS5xdWFsY29tbS5jb20+IHdyb3RlOg0KDQo+SSdkIGxpa2UgdG8g
c2V0IGEgdGltZSB0byBtZWV0IGluIFByYWd1ZSBzbyB0aGF0IEJlcm5hcmQsIEJyaWFuLA0KPm15
c2VsZiwgYW5kIGFueW9uZSBlbHNlIGludGVyZXN0ZWQgY2FuIHRhbGsgaW4gZGVwdGggYWJvdXQg
dGhlIFNMSU0NCj5yZWFsLXRpbWUgZHJhZnQuICBXb3VsZCBNb25kYXkgbHVuY2ggd29yaz8gIElm
IG5vdCwgcGxlYXNlIHN1Z2dlc3QNCj5zb21lIGFsdGVybmF0ZSB0aW1lcy4NCj4NCj4tLSANCj5S
YW5kYWxsIEdlbGxlbnMNCj5PcGluaW9ucyBhcmUgcGVyc29uYWw7ICAgIGZhY3RzIGFyZSBzdXNw
ZWN0OyAgICBJIHNwZWFrIGZvciBteXNlbGYgb25seQ0KPi0tLS0tLS0tLS0tLS0tIFJhbmRvbWx5
IHNlbGVjdGVkIHRhZzogLS0tLS0tLS0tLS0tLS0tDQo+WW91IG5ldmVyIGZpbmlzaCBhIHByb2dy
YW0sIHlvdSBqdXN0IHN0b3Agd29ya2luZyBvbiBpdC4NCg0K


From nobody Wed Jul  8 16:07:39 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D0E1A88FA; Wed,  8 Jul 2015 15:33:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.011
X-Spam-Level: 
X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 zp_2o13Vx06C; Wed,  8 Jul 2015 15:33:23 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BBF21A88AE; Wed,  8 Jul 2015 15:33:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1436394803; x=1467930803; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=x7/KUtBEEKjiyg6Zb2Z8/fzOuP0gZT8YDLTqTVRZYTw=; b=tP7Q7h4jN75a0T6JQ7N4gAPuGDusnh9e/Qts0wh6soHM+1NTMZzr+AfM eElgLTx0bKQAJuWrmXFsWVk6QeG7b+mkKnEfdZuDXGK3OLen0Qh9jDAuE Oy/GZtRAYdjYFpNxkjNODUK5InsGJhRCstb0NHdP6e9uTwfynu/SGh+oF I=;
X-IronPort-AV: E=McAfee;i="5700,7163,7856"; a="219530378"
Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Jul 2015 15:33:23 -0700
X-IronPort-AV: E=Sophos;i="5.15,434,1432623600"; d="scan'208";a="956225968"
Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 08 Jul 2015 15:33:21 -0700
Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 8 Jul 2015 15:33:20 -0700
Message-ID: 
In-Reply-To: 
References:  
X-Mailer: Eudora for Mac OS X
Date: Wed, 8 Jul 2015 15:33:18 -0700
To: "Rosen, Brian" , Randall Gellens , Bernard Aboba , Gunnar Hellstrom , Hannes Tschofenig , Henning Schulzrinne , Ban Al-Bakri , Barry Leiba 
From: Randall Gellens 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Originating-IP: [10.80.80.8]
X-ClientProxiedBy: NASANEXM01B.na.qualcomm.com (10.85.0.82) To nasanexm02f.na.qualcomm.com (10.85.0.87)
Archived-At: 
X-Mailman-Approved-At: Wed, 08 Jul 2015 16:07:38 -0700
Cc: "slim@ietf.org" , "ecrit@ietf.org" 
Subject: Re: [Slim] Time in Prague to discuss SLIM real-time draft
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Jul 2015 22:33:24 -0000

Would the first afternoon session (starts at 1:00) work?  Ban doesn't 
land until 11:00, so lunch would be cutting it close.


At 5:39 PM +0000 7/8/15, Brian Rosen wrote:

>  Hmmm, I think Monday lunch works for me this meeting (no more Apps chair
>  lunch).
>
>  On 7/8/15, 1:30 PM, "Randall Gellens"  wrote:
>
>>I'd like to set a time to meet in Prague so that Bernard, Brian,
>>myself, and anyone else interested can talk in depth about the SLIM
>>real-time draft.  Would Monday lunch work?  If not, please suggest
>>some alternate times.
>>
>>--
>>Randall Gellens
>>Opinions are personal;    facts are suspect;    I speak for myself only
>>-------------- Randomly selected tag: ---------------
>>You never finish a program, you just stop working on it.
>
>  _______________________________________________
>  SLIM mailing list
>  SLIM@ietf.org
>  https://www.ietf.org/mailman/listinfo/slim



-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
The spirit of this country is totally adverse to a large military force.
    --Thomas Jefferson


From nobody Wed Jul  8 17:02:51 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D171A886D for ; Wed,  8 Jul 2015 17:02:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.711
X-Spam-Level: 
X-Spam-Status: No, score=-6.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 5CQTDfCfY6UM for ; Wed,  8 Jul 2015 17:02:49 -0700 (PDT)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5DE61A8855 for ; Wed,  8 Jul 2015 17:02:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1436400155; x=1467936155; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version:content-transfer-encoding; bh=wtkH4sw/mGbt8mUr+nrVwwALXW7F6aff4bZgO5d+LpE=; b=jHUwY9zcK4782ITe3lC+S0R130lZ4txPHTXvNZf2wogkOQP4PurENVy7 HIjkBelVmugcsKf8Af/+LXJfW8uyJeMyVrfpvOjCv0m4FbAqirMo8KTIu LfQ4GwEbrmOECxwZJKSOAc3RXrmekdGFc8h8HYjYdLkcnSd5MYBQQ3Q7n E=;
X-IronPort-AV: E=McAfee;i="5700,7163,7856"; a="93373410"
Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Jul 2015 17:02:34 -0700
X-IronPort-AV: E=Sophos;i="5.15,435,1432623600"; d="scan'208";a="930955418"
Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 08 Jul 2015 17:02:33 -0700
Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 8 Jul 2015 17:02:29 -0700
Message-ID: 
In-Reply-To: <559C4F84.1070701@omnitor.se>
References:  <5E0D2DE0-FC2F-4681-B05C-D924A44B43E8@brianrosen.net> <559C4F84.1070701@omnitor.se>
X-Mailer: Eudora for Mac OS X
Date: Wed, 8 Jul 2015 17:02:20 -0700
To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , Brian Rosen 
From: Randall Gellens 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Originating-IP: [10.80.80.8]
X-ClientProxiedBy: NASANEXM01F.na.qualcomm.com (10.85.0.32) To nasanexm02f.na.qualcomm.com (10.85.0.87)
Archived-At: 
Cc: "slim@ietf.org" 
Subject: Re: [Slim] Translation Quality or type - or service provider
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Jul 2015 00:02:50 -0000

At 12:15 AM +0200 7/8/15, Gunnar Hellstr=F6m wrote:

>  The user might make a regular call that the SIP=20
> provider detects should go to the relay=20
> service. The relay servicedetects that it=20
> should be an emergency call and refers it back=20
> to the user to call urn:service:sos instead.

Ideally, the call from the user should be=20
initiated as an emergency call.  Depending on the=20
region, this provides priority call treatment,=20
permits calls to be placed without an=20
account/SIM, tells the originating client to=20
include the various forms of additional data, and=20
triggers various location functions.  If the call=20
from the user is initiated as a normal=20
(non-emergency) call, none of this happens in=20
most environments.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
To iterate is human; to recurse, divine.  --Robert Heller


From nobody Wed Jul  8 21:53:20 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB031A8F35 for ; Wed,  8 Jul 2015 21:53:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.298
X-Spam-Level: 
X-Spam-Status: No, score=0.298 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 nHRY2ZLsQpd9 for ; Wed,  8 Jul 2015 21:53:18 -0700 (PDT)
Received: from bin-vsp-out-01.atm.binero.net (vsp-unauthed01.binero.net [195.74.38.225]) (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 8FBEF1A8F39 for ; Wed,  8 Jul 2015 21:53:17 -0700 (PDT)
X-Halon-ID: 73b88620-25f6-11e5-8487-005056917a89
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.43.70] (unknown [2.64.81.248]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Thu,  9 Jul 2015 06:53:33 +0200 (CEST)
Message-ID: <559DFE36.6050404@omnitor.se>
Date: Thu, 09 Jul 2015 06:53:10 +0200
From: =?windows-1252?Q?Gunnar_Hellstr=F6m?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Randall Gellens , Brian Rosen 
References:  <5E0D2DE0-FC2F-4681-B05C-D924A44B43E8@brianrosen.net> <559C4F84.1070701@omnitor.se> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "slim@ietf.org" 
Subject: Re: [Slim] Translation Quality or type - or service provider
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Jul 2015 04:53:19 -0000

Randall Gellens skrev den 2015-07-09 02:02:
> At 12:15 AM +0200 7/8/15, Gunnar Hellström wrote:
>
>>  The user might make a regular call that the SIP provider detects 
>> should go to the relay service. The relay servicedetects that it 
>> should be an emergency call and refers it back to the user to call 
>> urn:service:sos instead.
>
> Ideally, the call from the user should be initiated as an emergency 
> call.  Depending on the region, this provides priority call treatment, 
> permits calls to be placed without an account/SIM, tells the 
> originating client to include the various forms of additional data, 
> and triggers various location functions.  If the call from the user is 
> initiated as a normal (non-emergency) call, none of this happens in 
> most environments.
Yes of course the direct calling when the terminal detects the emergency 
number from the beginning is the preferred method.

But many relay services today sadly work with two-step dialling. First 
the user calls a number or URI to reach the relay service and then 
discusses with the communication agent what the final destination of the 
call is. If that is the emergency number, then the described procedure 
can turn the call back to the user terminal and refer it to do the 
urn:service:sos call instead and prepare for the relay service to be 
reinvoked automatically from the PSAP.

This situation can happen also with relay services who support one-step 
dialling. The relay services usually have a number or URI of their own, 
so that users can call that address and make the two-step procedure 
anyway, maybe because they are used to it and have not yet learned that 
the one-step is possible. Or in the emergency situation they fall back 
into the way of calling with relay that they used so many years even if 
they were informed that they can now just dial 9-1-1 or 112. They can 
also think: "can they really communicate with me at 9-1-1, no, for 
safety sake I bring the relay into the call as well the usual way."

In USA, one step dialing with relay service is implemented, but still 
the procedure with the normal call turned into an emergency call after 
the refer from the relay service is specified by NENA (i3 chapter 9). I 
think the idea behind that is that the call gets an interpreter assigned 
and gets the AdditionalData already from the relay service, so that the 
connection can be made rapidly when the call converted to an emergency 
call gets to the PSAP.

I have many times said that that procedure looks too complicated and 
risky and that I want a direct method documented that invokes PSAP and 
relay rapidly, and also enables the PSAP to handle the call themselves 
for the case when they have the right capabilities.

Still there might be use of the procedure above for the reasons 
mentioned ( and others).

I think that the reason that the user does not behave as we hoped is the 
most important one. Even if we design good modern ways to do emergency 
and relay calling efficiently, there will be users who make it some 
other way, and we should try to have ways for them at least to not have 
the calls dropped.

Gunnar

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


From nobody Thu Jul  9 05:35:19 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 856EB1AD2F2 for ; Thu,  9 Jul 2015 05:35:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.511
X-Spam-Level: 
X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, T_FILL_THIS_FORM_SHORT=0.01] autolearn=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 g88n11wBiE9U for ; Thu,  9 Jul 2015 05:35:11 -0700 (PDT)
Received: from mail-qk0-f173.google.com (mail-qk0-f173.google.com [209.85.220.173]) (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 63FD61A89A5 for ; Thu,  9 Jul 2015 05:35:11 -0700 (PDT)
Received: by qkei195 with SMTP id i195so184559360qke.3 for ; Thu, 09 Jul 2015 05:35:10 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=gkehaTnoB5mfEkalWiQ7HY9VH6AHuayH4hH2C0UPhMg=; b=Uu68AVSui70jwek1zOX+24jzu7BPsEl4KwSF3zzF/8qT/VylyD/k3fQbVdVGx4DyL/ ruVW5J14QPxfnzJbOLX7fQEY94OU+JwErFAgy3Xo30I5QGXd6Ln+tFLqKsmgLCNRK6nk tBKUMZLLL3AWpd9i2LU4u3/5IJ6g9H894w7e2xeUEFB1N9U+Ct1/eCypBsbfdFroj/hq Q/YrY+8ZwdHl9vVjxJ3Bfv4gEnBHVOCZXidSXjc/VoKAXlAZHzfyA/GBRQy0MzTYRaFy 0FZHQMAAnR5RhDlXK8ZxrGdPo3tz8jxjl0nK+2fPuBhYeh9DZHJf6uLKh/pshOD0f7zo 78Tw==
X-Gm-Message-State: ALoCoQkU3NPtvDXIENl8GINbHxznsU1aXaxAWUIBTK7/8/l/6ubXhGvY79RRp7sNuOLcsdVo65gp
X-Received: by 10.55.40.34 with SMTP id o34mr13155578qkh.103.1436445310656; Thu, 09 Jul 2015 05:35:10 -0700 (PDT)
Received: from [10.33.193.32] (neustargw.va.neustar.com. [209.173.53.233]) by smtp.gmail.com with ESMTPSA id l11sm3538440qga.43.2015.07.09.05.35.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 Jul 2015 05:35:10 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: Brian Rosen 
In-Reply-To: <559DFE36.6050404@omnitor.se>
Date: Thu, 9 Jul 2015 08:35:07 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <5E0D2DE0-FC2F-4681-B05C-D924A44B43E8@brianrosen.net> <559C4F84.1070701@omnitor.se>  <559DFE36.6050404@omnitor.se>
To: =?windows-1252?Q?Gunnar_Hellstr=F6m?= 
X-Mailer: Apple Mail (2.2102)
Archived-At: 
Cc: "slim@ietf.org" , Randall Gellens 
Subject: Re: [Slim] Translation Quality or type - or service provider
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Jul 2015 12:35:13 -0000

The NENA mechanism is that the call is placed per 6881.  That says that =
the call urn:service:sos is sent to the normal outbound proxy service.  =
That would be the relay service=92s proxy.
It would add a Referred-By header, and forward the call per 6881.  Since =
it is an emergency call from the user device, it has location.  The LoST =
query can be done, as in 6881, by the device or the proxy.  The relay =
service can hold the call until a CA is available. or it can forward the =
call immediately.  The PSAP, when it gets the call, is going to REFER =
immediately to a bridge (assuming it will use the user=92s relay =
service.  It won=92t want to answer, then REFER, or it will delay the =
call.  Referred-By indicated 3rd party request, so the call should be =
set up on the PSAP bridge immediately.  The participants join as they =
can, in any order.   Of course, if there was a queue at the PSAP, the =
call would be held in queue before the bridge is established.

This is a direct call, it follows the same path any direct dialed =
emergency call would, and traverses the same path any emergency call =
would until it reaches the PSAP.  At the PSAP, it=92s slightly different =
in that a bridge is instantiated immediately.  In some NG9-1-1 =
implementations, all calls are answered at a bridge, and in those =
implementations, there is NO difference.

If you have ever seen a call handled with a translation service at a =
PSAP, you will know that you don=92t want that process.   Because there =
is cost involved, there is paperwork, and that delays the call.  Also, =
since the CA does not have access to any information, they have to learn =
everything from the caller via sign language.  When the caller supplies =
the relay service, they have the service information.  So they know =
name/address/telephone number, etc. =20

AFAIK, dial-around emergency service is not implemented in the U.S.  Not =
sure what would happen if you tried it, but the =93default=94 VRS =
provider must provide emergency calling service, and the dial around =
provider is not required to.  =93Two-step=94 dialing, in the U.S., means =
you are using a relay provider other than your default provider.  We =
call that =93dial-around=94, since it=92s similar to how long distance =
(LD) providers work on landline phones - if you direct dial, your =
default LD provider serves the call, but you can call an access number, =
dial a destination telephone number, and get service from another =
(=93dial-around=94) LD provider for any call.

Brian

> On Jul 9, 2015, at 12:53 AM, Gunnar Hellstr=F6m =
 wrote:
>=20
> Randall Gellens skrev den 2015-07-09 02:02:
>> At 12:15 AM +0200 7/8/15, Gunnar Hellstr=F6m wrote:
>>=20
>>> The user might make a regular call that the SIP provider detects =
should go to the relay service. The relay servicedetects that it should =
be an emergency call and refers it back to the user to call =
urn:service:sos instead.
>>=20
>> Ideally, the call from the user should be initiated as an emergency =
call.  Depending on the region, this provides priority call treatment, =
permits calls to be placed without an account/SIM, tells the originating =
client to include the various forms of additional data, and triggers =
various location functions.  If the call from the user is initiated as a =
normal (non-emergency) call, none of this happens in most environments.
> Yes of course the direct calling when the terminal detects the =
emergency number from the beginning is the preferred method.
>=20
> But many relay services today sadly work with two-step dialling. First =
the user calls a number or URI to reach the relay service and then =
discusses with the communication agent what the final destination of the =
call is. If that is the emergency number, then the described procedure =
can turn the call back to the user terminal and refer it to do the =
urn:service:sos call instead and prepare for the relay service to be =
reinvoked automatically from the PSAP.
>=20
> This situation can happen also with relay services who support =
one-step dialling. The relay services usually have a number or URI of =
their own, so that users can call that address and make the two-step =
procedure anyway, maybe because they are used to it and have not yet =
learned that the one-step is possible. Or in the emergency situation =
they fall back into the way of calling with relay that they used so many =
years even if they were informed that they can now just dial 9-1-1 or =
112. They can also think: "can they really communicate with me at 9-1-1, =
no, for safety sake I bring the relay into the call as well the usual =
way."
>=20
> In USA, one step dialing with relay service is implemented, but still =
the procedure with the normal call turned into an emergency call after =
the refer from the relay service is specified by NENA (i3 chapter 9). I =
think the idea behind that is that the call gets an interpreter assigned =
and gets the AdditionalData already from the relay service, so that the =
connection can be made rapidly when the call converted to an emergency =
call gets to the PSAP.
>=20
> I have many times said that that procedure looks too complicated and =
risky and that I want a direct method documented that invokes PSAP and =
relay rapidly, and also enables the PSAP to handle the call themselves =
for the case when they have the right capabilities.
>=20
> Still there might be use of the procedure above for the reasons =
mentioned ( and others).
>=20
> I think that the reason that the user does not behave as we hoped is =
the most important one. Even if we design good modern ways to do =
emergency and relay calling efficiently, there will be users who make it =
some other way, and we should try to have ways for them at least to not =
have the calls dropped.
>=20
> Gunnar
>=20
> --=20
> -----------------------------------------
> Gunnar Hellstr=F6m
> Omnitor
> gunnar.hellstrom@omnitor.se
> +46 708 204 288
>=20


From nobody Thu Jul  9 06:34:13 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED2BF1A9084 for ; Thu,  9 Jul 2015 06:34:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.191
X-Spam-Level: 
X-Spam-Status: No, score=-0.191 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=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 XWF_G_cHKCCI for ; Thu,  9 Jul 2015 06:34:09 -0700 (PDT)
Received: from bin-vsp-out-04.atm.binero.net (vsp-authed02.binero.net [195.74.38.226]) (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 42F411A9069 for ; Thu,  9 Jul 2015 06:34:09 -0700 (PDT)
X-Halon-ID: 290141a2-263f-11e5-b1de-005056917c0c
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.43.70] (unknown [2.64.81.248]) by bin-vsp-out-04.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Thu,  9 Jul 2015 15:34:01 +0200 (CEST)
Message-ID: <559E784A.1070607@omnitor.se>
Date: Thu, 09 Jul 2015 15:34:02 +0200
From: =?windows-1252?Q?Gunnar_Hellstr=F6m?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Brian Rosen 
References:  <5E0D2DE0-FC2F-4681-B05C-D924A44B43E8@brianrosen.net> <559C4F84.1070701@omnitor.se>  <559DFE36.6050404@omnitor.se> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "slim@ietf.org" , Randall Gellens 
Subject: Re: [Slim] Translation Quality or type - or service provider
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Jul 2015 13:34:12 -0000

Brian,
Right.

You say: "Referred-By indicated 3rd party request, so the call should be 
set up on the PSAP bridge immediately."
Is that a NENA convention, or is it specified in any RFC that getting a 
Referred-By means that I am supposed to set up a 3-party call?
Is there any more parameter accompanying the Referred-by and its address 
saying that the bridge shall reconnect to this address?

Brian Rosen skrev den 2015-07-09 14:35:
> The NENA mechanism is that the call is placed per 6881.  That says that the call urn:service:sos is sent to the normal outbound proxy service.  That would be the relay service’s proxy.
In NENA i3 chapter 9 it starts with a call that can be anything. It does 
not tell. Then there is a Refer back to the user terminal to call 
urn:service:sos
As I see it, and the procedure comments, the normal 9-1-1 calling starts 
with the user terminal acting on that Refer.
> It would add a Referred-By header, and forward the call per 6881.  Since it is an emergency call from the user device, it has location.  The LoST query can be done, as in 6881, by the device or the proxy.  The relay service can hold the call until a CA is available. or it can forward the call immediately.  The PSAP, when it gets the call, is going to REFER immediately to a bridge (assuming it will use the user’s relay service.  It won’t want to answer, then REFER, or it will delay the call.  Referred-By indicated 3rd party request, so the call should be set up on the PSAP bridge immediately.  The participants join as they can, in any order.   Of course, if there was a queue at the PSAP, the call would be held in queue before the bridge is established.
>
> This is a direct call, it follows the same path any direct dialed emergency call would, and traverses the same path any emergency call would until it reaches the PSAP.  At the PSAP, it’s slightly different in that a bridge is instantiated immediately.  In some NG9-1-1 implementations, all calls are answered at a bridge, and in those implementations, there is NO difference.
>
> If you have ever seen a call handled with a translation service at a PSAP, you will know that you don’t want that process.   Because there is cost involved, there is paperwork, and that delays the call.  Also, since the CA does not have access to any information, they have to learn everything from the caller via sign language.  When the caller supplies the relay service, they have the service information.  So they know name/address/telephone number, etc.
This is one reason why we need total conversation, and work on that in 
ETSI. If any procedure fails, then at least some dialogue can take place 
in real-time text to sort it out.
>    
>
> AFAIK, dial-around emergency service is not implemented in the U.S.  Not sure what would happen if you tried it, but the “default” VRS provider must provide emergency calling service, and the dial around provider is not required to.  “Two-step” dialing, in the U.S., means you are using a relay provider other than your default provider.  We call that “dial-around”, since it’s similar to how long distance (LD) providers work on landline phones - if you direct dial, your default LD provider serves the call, but you can call an access number, dial a destination telephone number, and get service from another (“dial-around”) LD provider for any call.
Maybe not important here, but can you not call your default VRS by their 
number, and discuss with them where you want to call, and then they make 
the call?   I think also serial calls are still possible in the US. 
After finishing one call, you keep the interpreter and request another 
call. That looks as two-step dialing with your default relay provider.
>
> Brian
>
>> On Jul 9, 2015, at 12:53 AM, Gunnar Hellström  wrote:
>>
>> Randall Gellens skrev den 2015-07-09 02:02:
>>> At 12:15 AM +0200 7/8/15, Gunnar Hellström wrote:
>>>
>>>> The user might make a regular call that the SIP provider detects should go to the relay service. The relay servicedetects that it should be an emergency call and refers it back to the user to call urn:service:sos instead.
>>> Ideally, the call from the user should be initiated as an emergency call.  Depending on the region, this provides priority call treatment, permits calls to be placed without an account/SIM, tells the originating client to include the various forms of additional data, and triggers various location functions.  If the call from the user is initiated as a normal (non-emergency) call, none of this happens in most environments.
>> Yes of course the direct calling when the terminal detects the emergency number from the beginning is the preferred method.
>>
>> But many relay services today sadly work with two-step dialling. First the user calls a number or URI to reach the relay service and then discusses with the communication agent what the final destination of the call is. If that is the emergency number, then the described procedure can turn the call back to the user terminal and refer it to do the urn:service:sos call instead and prepare for the relay service to be reinvoked automatically from the PSAP.
>>
>> This situation can happen also with relay services who support one-step dialling. The relay services usually have a number or URI of their own, so that users can call that address and make the two-step procedure anyway, maybe because they are used to it and have not yet learned that the one-step is possible. Or in the emergency situation they fall back into the way of calling with relay that they used so many years even if they were informed that they can now just dial 9-1-1 or 112. They can also think: "can they really communicate with me at 9-1-1, no, for safety sake I bring the relay into the call as well the usual way."
>>
>> In USA, one step dialing with relay service is implemented, but still the procedure with the normal call turned into an emergency call after the refer from the relay service is specified by NENA (i3 chapter 9). I think the idea behind that is that the call gets an interpreter assigned and gets the AdditionalData already from the relay service, so that the connection can be made rapidly when the call converted to an emergency call gets to the PSAP.
>>
>> I have many times said that that procedure looks too complicated and risky and that I want a direct method documented that invokes PSAP and relay rapidly, and also enables the PSAP to handle the call themselves for the case when they have the right capabilities.
>>
>> Still there might be use of the procedure above for the reasons mentioned ( and others).
>>
>> I think that the reason that the user does not behave as we hoped is the most important one. Even if we design good modern ways to do emergency and relay calling efficiently, there will be users who make it some other way, and we should try to have ways for them at least to not have the calls dropped.
>>
>> Gunnar
>>
>> -- 
>> -----------------------------------------
>> Gunnar Hellström
>> Omnitor
>> gunnar.hellstrom@omnitor.se
>> +46 708 204 288
>>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim

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


From nobody Thu Jul  9 07:08:12 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0731A9143 for ; Thu,  9 Jul 2015 07:08:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.175
X-Spam-Level: 
X-Spam-Status: No, score=0.175 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665, T_FILL_THIS_FORM_SHORT=0.01] autolearn=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 QfJrsi2G3csS for ; Thu,  9 Jul 2015 07:08:05 -0700 (PDT)
Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:160]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F6D31A9147 for ; Thu,  9 Jul 2015 07:08:04 -0700 (PDT)
Received: from resomta-po-15v.sys.comcast.net ([96.114.154.239]) by resqmta-po-01v.sys.comcast.net with comcast id qE801q0015AAYLo01E84AJ; Thu, 09 Jul 2015 14:08:04 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-15v.sys.comcast.net with comcast id qE831q00W3Ge9ey01E84Sm; Thu, 09 Jul 2015 14:08:04 +0000
Message-ID: <559E8041.9020609@alum.mit.edu>
Date: Thu, 09 Jul 2015 10:08:01 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: slim@ietf.org
References:  <5E0D2DE0-FC2F-4681-B05C-D924A44B43E8@brianrosen.net> <559C4F84.1070701@omnitor.se>  <559DFE36.6050404@omnitor.se> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1436450884; bh=hA6QvpqIp4HN0vALB1gCIFH+GU2WuZ1wPCPTPv9ZFZ0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=fuEWwRFGTawyI+++0vqRyBBPNsWAm/iS1rDqUypp9O7hDTzxY+Yxb9AO+T/Cfk+uN J9ykY5im7ZsBJHxrokdTsqEG9WqY9zF5TXLt5ow6gNtm29heIbUO7MQzZoClRtEzLK cu2uVrJX+roFDmOqphfYOYIY5AoWRS5EQqNmGCYPqSn/Q20G4IHffA0QEavQ8oeVTT bBV5GRxcq7osiumwIvOAtZn5/ZfCCjHEW7vpOgGqx/ZCa1g7H9ATbWveoGFkw8Y+7K LzNM05Bsliozuu3SObNIZd02DUWKFH50RuUfiKsb4Hu3/A9VL+4BBX+RsM+KLg44B/ RjdJtz/T4KzuA==
Archived-At: 
Subject: Re: [Slim] Translation Quality or type - or service provider
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Jul 2015 14:08:11 -0000

With the NENA mechanism the deaf user has first contacted the provider, 
and the provider has been able to validate that the user is eligible for 
service. I expect the Referred-By could be encoded some way so that it 
can be correlated with the user when a call is made to it by the PSAP.

That is different from a user making a call to somebody, simply 
inserting a URL of a preferred service, and the called user using that 
to request relay service. In *that* scenario there isn't an obvious way 
for the relay service to authorize the usage.

	Thanks,
	Paul

On 7/9/15 8:35 AM, Brian Rosen wrote:
> The NENA mechanism is that the call is placed per 6881.  That says that the call urn:service:sos is sent to the normal outbound proxy service.  That would be the relay service’s proxy.
> It would add a Referred-By header, and forward the call per 6881.  Since it is an emergency call from the user device, it has location.  The LoST query can be done, as in 6881, by the device or the proxy.  The relay service can hold the call until a CA is available. or it can forward the call immediately.  The PSAP, when it gets the call, is going to REFER immediately to a bridge (assuming it will use the user’s relay service.  It won’t want to answer, then REFER, or it will delay the call.  Referred-By indicated 3rd party request, so the call should be set up on the PSAP bridge immediately.  The participants join as they can, in any order.   Of course, if there was a queue at the PSAP, the call would be held in queue before the bridge is established.
>
> This is a direct call, it follows the same path any direct dialed emergency call would, and traverses the same path any emergency call would until it reaches the PSAP.  At the PSAP, it’s slightly different in that a bridge is instantiated immediately.  In some NG9-1-1 implementations, all calls are answered at a bridge, and in those implementations, there is NO difference.
>
> If you have ever seen a call handled with a translation service at a PSAP, you will know that you don’t want that process.   Because there is cost involved, there is paperwork, and that delays the call.  Also, since the CA does not have access to any information, they have to learn everything from the caller via sign language.  When the caller supplies the relay service, they have the service information.  So they know name/address/telephone number, etc.
>
> AFAIK, dial-around emergency service is not implemented in the U.S.  Not sure what would happen if you tried it, but the “default” VRS provider must provide emergency calling service, and the dial around provider is not required to.  “Two-step” dialing, in the U.S., means you are using a relay provider other than your default provider.  We call that “dial-around”, since it’s similar to how long distance (LD) providers work on landline phones - if you direct dial, your default LD provider serves the call, but you can call an access number, dial a destination telephone number, and get service from another (“dial-around”) LD provider for any call.
>
> Brian
>
>> On Jul 9, 2015, at 12:53 AM, Gunnar Hellström  wrote:
>>
>> Randall Gellens skrev den 2015-07-09 02:02:
>>> At 12:15 AM +0200 7/8/15, Gunnar Hellström wrote:
>>>
>>>> The user might make a regular call that the SIP provider detects should go to the relay service. The relay servicedetects that it should be an emergency call and refers it back to the user to call urn:service:sos instead.
>>>
>>> Ideally, the call from the user should be initiated as an emergency call.  Depending on the region, this provides priority call treatment, permits calls to be placed without an account/SIM, tells the originating client to include the various forms of additional data, and triggers various location functions.  If the call from the user is initiated as a normal (non-emergency) call, none of this happens in most environments.
>> Yes of course the direct calling when the terminal detects the emergency number from the beginning is the preferred method.
>>
>> But many relay services today sadly work with two-step dialling. First the user calls a number or URI to reach the relay service and then discusses with the communication agent what the final destination of the call is. If that is the emergency number, then the described procedure can turn the call back to the user terminal and refer it to do the urn:service:sos call instead and prepare for the relay service to be reinvoked automatically from the PSAP.
>>
>> This situation can happen also with relay services who support one-step dialling. The relay services usually have a number or URI of their own, so that users can call that address and make the two-step procedure anyway, maybe because they are used to it and have not yet learned that the one-step is possible. Or in the emergency situation they fall back into the way of calling with relay that they used so many years even if they were informed that they can now just dial 9-1-1 or 112. They can also think: "can they really communicate with me at 9-1-1, no, for safety sake I bring the relay into the call as well the usual way."
>>
>> In USA, one step dialing with relay service is implemented, but still the procedure with the normal call turned into an emergency call after the refer from the relay service is specified by NENA (i3 chapter 9). I think the idea behind that is that the call gets an interpreter assigned and gets the AdditionalData already from the relay service, so that the connection can be made rapidly when the call converted to an emergency call gets to the PSAP.
>>
>> I have many times said that that procedure looks too complicated and risky and that I want a direct method documented that invokes PSAP and relay rapidly, and also enables the PSAP to handle the call themselves for the case when they have the right capabilities.
>>
>> Still there might be use of the procedure above for the reasons mentioned ( and others).
>>
>> I think that the reason that the user does not behave as we hoped is the most important one. Even if we design good modern ways to do emergency and relay calling efficiently, there will be users who make it some other way, and we should try to have ways for them at least to not have the calls dropped.
>>
>> Gunnar
>>
>> --
>> -----------------------------------------
>> Gunnar Hellström
>> Omnitor
>> gunnar.hellstrom@omnitor.se
>> +46 708 204 288
>>
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim
>


From nobody Thu Jul  9 09:39:30 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F661B2AC2 for ; Thu,  9 Jul 2015 09:39:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.811
X-Spam-Level: 
X-Spam-Status: No, score=-1.811 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham
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 sb7mp_hViCkE for ; Thu,  9 Jul 2015 09:39:26 -0700 (PDT)
Received: from mail-qk0-f177.google.com (mail-qk0-f177.google.com [209.85.220.177]) (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 623651B2AC8 for ; Thu,  9 Jul 2015 09:39:26 -0700 (PDT)
Received: by qkei195 with SMTP id i195so189549290qke.3 for ; Thu, 09 Jul 2015 09:39:25 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=fcgk4JmOOYAgZqvohMBp92R1r5Ba4lfspgih4Ict/RU=; b=iNkFC43XVe8W/7h2tUVq3+XKsQ64uaZOXzwAeVTZegbsgEswSzz1VzASM8a/iD+UGn mThAVj+kvdpLMf/Q1+M4EOjjx7CzVonswy7hFzhUvFdZpyuMyLBlThTld8L2aX7JzD7e mUwI0lP3SUNHnTiW6I/jcLqGqxOcNIBdvVCIaFlJxAOpc+HUpY8LZ6h7Re21Cpkw5eyz xLqKQ6/kS01PGEJhPIYo9GE1Zg8lDR9lVK93t7FjshIWcqum9eERxnYMBYYm96ZcVZIC QGvan+Wp6FT+reQa77WVxyhjoSJcTUNq9ei9UC0nlnF2I1+a+YClzxtlwDGT45OnMmcL cNgw==
X-Gm-Message-State: ALoCoQmc/Af6xf7fxVQA6H+aWmD8rASZlwhrUByhH+ZhqY7Tzfi+z9y6QRmdTk9fJg4Sq8ME66lr
X-Received: by 10.55.23.17 with SMTP id i17mr26034765qkh.39.1436459965595; Thu, 09 Jul 2015 09:39:25 -0700 (PDT)
Received: from [10.33.193.32] (neustargw.va.neustar.com. [209.173.53.233]) by smtp.gmail.com with ESMTPSA id u96sm3954972qgd.14.2015.07.09.09.39.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 Jul 2015 09:39:25 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: Brian Rosen 
In-Reply-To: <559E8041.9020609@alum.mit.edu>
Date: Thu, 9 Jul 2015 12:39:23 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <60555B36-EE69-401A-B068-3E070731512A@brianrosen.net>
References:  <5E0D2DE0-FC2F-4681-B05C-D924A44B43E8@brianrosen.net> <559C4F84.1070701@omnitor.se>  <559DFE36.6050404@omnitor.se>  <559E8041.9020609@alum.mit.edu>
To: Paul Kyzivat 
X-Mailer: Apple Mail (2.2102)
Archived-At: 
Cc: slim@ietf.org
Subject: Re: [Slim] Translation Quality or type - or service provider
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Jul 2015 16:39:29 -0000

True.  We could invent some mechanism, but it would be a new mechanism.

Brian
=20
> On Jul 9, 2015, at 10:08 AM, Paul Kyzivat  =
wrote:
>=20
> With the NENA mechanism the deaf user has first contacted the =
provider, and the provider has been able to validate that the user is =
eligible for service. I expect the Referred-By could be encoded some way =
so that it can be correlated with the user when a call is made to it by =
the PSAP.
>=20
> That is different from a user making a call to somebody, simply =
inserting a URL of a preferred service, and the called user using that =
to request relay service. In *that* scenario there isn't an obvious way =
for the relay service to authorize the usage.
>=20
> 	Thanks,
> 	Paul
>=20
> On 7/9/15 8:35 AM, Brian Rosen wrote:
>> The NENA mechanism is that the call is placed per 6881.  That says =
that the call urn:service:sos is sent to the normal outbound proxy =
service.  That would be the relay service=92s proxy.
>> It would add a Referred-By header, and forward the call per 6881.  =
Since it is an emergency call from the user device, it has location.  =
The LoST query can be done, as in 6881, by the device or the proxy.  The =
relay service can hold the call until a CA is available. or it can =
forward the call immediately.  The PSAP, when it gets the call, is going =
to REFER immediately to a bridge (assuming it will use the user=92s =
relay service.  It won=92t want to answer, then REFER, or it will delay =
the call.  Referred-By indicated 3rd party request, so the call should =
be set up on the PSAP bridge immediately.  The participants join as they =
can, in any order.   Of course, if there was a queue at the PSAP, the =
call would be held in queue before the bridge is established.
>>=20
>> This is a direct call, it follows the same path any direct dialed =
emergency call would, and traverses the same path any emergency call =
would until it reaches the PSAP.  At the PSAP, it=92s slightly different =
in that a bridge is instantiated immediately.  In some NG9-1-1 =
implementations, all calls are answered at a bridge, and in those =
implementations, there is NO difference.
>>=20
>> If you have ever seen a call handled with a translation service at a =
PSAP, you will know that you don=92t want that process.   Because there =
is cost involved, there is paperwork, and that delays the call.  Also, =
since the CA does not have access to any information, they have to learn =
everything from the caller via sign language.  When the caller supplies =
the relay service, they have the service information.  So they know =
name/address/telephone number, etc.
>>=20
>> AFAIK, dial-around emergency service is not implemented in the U.S.  =
Not sure what would happen if you tried it, but the =93default=94 VRS =
provider must provide emergency calling service, and the dial around =
provider is not required to.  =93Two-step=94 dialing, in the U.S., means =
you are using a relay provider other than your default provider.  We =
call that =93dial-around=94, since it=92s similar to how long distance =
(LD) providers work on landline phones - if you direct dial, your =
default LD provider serves the call, but you can call an access number, =
dial a destination telephone number, and get service from another =
(=93dial-around=94) LD provider for any call.
>>=20
>> Brian
>>=20
>>> On Jul 9, 2015, at 12:53 AM, Gunnar Hellstr=F6m =
 wrote:
>>>=20
>>> Randall Gellens skrev den 2015-07-09 02:02:
>>>> At 12:15 AM +0200 7/8/15, Gunnar Hellstr=F6m wrote:
>>>>=20
>>>>> The user might make a regular call that the SIP provider detects =
should go to the relay service. The relay servicedetects that it should =
be an emergency call and refers it back to the user to call =
urn:service:sos instead.
>>>>=20
>>>> Ideally, the call from the user should be initiated as an emergency =
call.  Depending on the region, this provides priority call treatment, =
permits calls to be placed without an account/SIM, tells the originating =
client to include the various forms of additional data, and triggers =
various location functions.  If the call from the user is initiated as a =
normal (non-emergency) call, none of this happens in most environments.
>>> Yes of course the direct calling when the terminal detects the =
emergency number from the beginning is the preferred method.
>>>=20
>>> But many relay services today sadly work with two-step dialling. =
First the user calls a number or URI to reach the relay service and then =
discusses with the communication agent what the final destination of the =
call is. If that is the emergency number, then the described procedure =
can turn the call back to the user terminal and refer it to do the =
urn:service:sos call instead and prepare for the relay service to be =
reinvoked automatically from the PSAP.
>>>=20
>>> This situation can happen also with relay services who support =
one-step dialling. The relay services usually have a number or URI of =
their own, so that users can call that address and make the two-step =
procedure anyway, maybe because they are used to it and have not yet =
learned that the one-step is possible. Or in the emergency situation =
they fall back into the way of calling with relay that they used so many =
years even if they were informed that they can now just dial 9-1-1 or =
112. They can also think: "can they really communicate with me at 9-1-1, =
no, for safety sake I bring the relay into the call as well the usual =
way."
>>>=20
>>> In USA, one step dialing with relay service is implemented, but =
still the procedure with the normal call turned into an emergency call =
after the refer from the relay service is specified by NENA (i3 chapter =
9). I think the idea behind that is that the call gets an interpreter =
assigned and gets the AdditionalData already from the relay service, so =
that the connection can be made rapidly when the call converted to an =
emergency call gets to the PSAP.
>>>=20
>>> I have many times said that that procedure looks too complicated and =
risky and that I want a direct method documented that invokes PSAP and =
relay rapidly, and also enables the PSAP to handle the call themselves =
for the case when they have the right capabilities.
>>>=20
>>> Still there might be use of the procedure above for the reasons =
mentioned ( and others).
>>>=20
>>> I think that the reason that the user does not behave as we hoped is =
the most important one. Even if we design good modern ways to do =
emergency and relay calling efficiently, there will be users who make it =
some other way, and we should try to have ways for them at least to not =
have the calls dropped.
>>>=20
>>> Gunnar
>>>=20
>>> --
>>> -----------------------------------------
>>> Gunnar Hellstr=F6m
>>> Omnitor
>>> gunnar.hellstrom@omnitor.se
>>> +46 708 204 288
>>>=20
>>=20
>> _______________________________________________
>> SLIM mailing list
>> SLIM@ietf.org
>> https://www.ietf.org/mailman/listinfo/slim
>>=20
>=20
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim


From nobody Thu Jul  9 11:38:58 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 703F21AC3AE; Thu,  9 Jul 2015 02:53:33 -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] autolearn=ham
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 83-DNJdqAaZ3; Thu,  9 Jul 2015 02:53:32 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CEC6E1ABB1A; Thu,  9 Jul 2015 02:53:31 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Benoit Claise" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.4.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150709095331.7611.37788.idtracker@ietfa.amsl.com>
Date: Thu, 09 Jul 2015 02:53:31 -0700
Archived-At: 
X-Mailman-Approved-At: Thu, 09 Jul 2015 11:38:56 -0700
Cc: slim@ietf.org
Subject: [Slim] Benoit Claise's No Objection on charter-ietf-slim-00-02: (with COMMENT)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Jul 2015 09:53:33 -0000

Benoit Claise has entered the following ballot position for
charter-ietf-slim-00-02: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-slim/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

>From the milestones, I see that you want to submit "Multiple Language
Content Type" to the IESG (based on
draft-tomkinson-slim-multilangcontent)"
If this draft is a compulsory starting point, I would make it clear in
the charter, similarly to "In the real-time communication case, the group
will produce a specification
based on draft-gellens-slim-negotiating-human-language". Simply a
question of consistency.



From nobody Thu Jul  9 11:39:00 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00771AD36F; Thu,  9 Jul 2015 05:59:50 -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, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham
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 csY1scpvNHOK; Thu,  9 Jul 2015 05:59:48 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E77FC1AD369; Thu,  9 Jul 2015 05:59:48 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Spencer Dawkins" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.4.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150709125948.12429.54830.idtracker@ietfa.amsl.com>
Date: Thu, 09 Jul 2015 05:59:48 -0700
Archived-At: 
X-Mailman-Approved-At: Thu, 09 Jul 2015 11:38:57 -0700
Cc: slim@ietf.org
Subject: [Slim] Spencer Dawkins' No Objection on charter-ietf-slim-00-02: (with COMMENT)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Jul 2015 12:59:50 -0000

Spencer Dawkins has entered the following ballot position for
charter-ietf-slim-00-02: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-slim/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Agree on Barry's Block position ...



From nobody Thu Jul  9 11:39:01 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E9C1A905A; Thu,  9 Jul 2015 06:10:07 -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] autolearn=ham
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 hIilxu7VjZrt; Thu,  9 Jul 2015 06:10:06 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7334A1A904D; Thu,  9 Jul 2015 06:10:06 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Stephen Farrell" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.4.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150709131006.24791.80867.idtracker@ietfa.amsl.com>
Date: Thu, 09 Jul 2015 06:10:06 -0700
Archived-At: 
X-Mailman-Approved-At: Thu, 09 Jul 2015 11:38:57 -0700
Cc: slim@ietf.org
Subject: [Slim] Stephen Farrell's No Objection on charter-ietf-slim-00-02: (with COMMENT)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Jul 2015 13:10:07 -0000

Stephen Farrell has entered the following ballot position for
charter-ietf-slim-00-02: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-slim/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


I also concur with Barry's Block. However I'm not sure we want to ballot
on it before that issue is resolved as it's fairly fundamental so I'd be
more
comfortable if we punted on this for now until that scoping discussion
is
done. For example, I think the security and privacy considerations
associated 
with email and WebRTC are totally different so it might really be better
to
handle 'em separately.

Note that we do have the opportunity to put this on the Sunday agenda in
Prague, so punting on it for now doesn't have to mean waiting too long
for a WG to be formed. And if those interested cannot manage to reach
consensus on a WG scope before Prague, then that probably indicates that
there's a problem there such that forming a WG now would be a bad plan.

So, this isn't an additional block, but I'd prefer we not ballot today as
this
a fundamental scope issue is still being discussed. 

We can chat about it on the call.



From nobody Thu Jul  9 13:41:16 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA8651A01EA for ; Thu,  9 Jul 2015 13:41:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 VlvyjyiOzeKZ for ; Thu,  9 Jul 2015 13:41:05 -0700 (PDT)
Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEE571A0203 for ; Thu,  9 Jul 2015 13:40:58 -0700 (PDT)
Received: by ykcp133 with SMTP id p133so59614846ykc.1 for ; Thu, 09 Jul 2015 13:40:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=c/wbjpm9LEKUOe7+EW0LWrhOWH20nKaYFwNWjeMuvhk=; b=AnlvtIxkUzTmYRWibSsmJodyBiD9xgSehy4vLwUFuRaGubKVoK9xQRym7TGHU28eTk JAmv7O0hbCDrTCUD/8PvM6smJMeBj4hIwh7hbBjGBmtnRA6Zd4sVCzJy1G0njVXYZ0cp F0OjBkaSDA6a1cey59gBar87fCVVGN5lvOe9UIBmHj9PWEyh5VxQfKHvUuNfYX5BYGpd 0G9JMoRm968lZV7Y7y/VUhjh0M3fBEx5qNRLoIQD6DQKbPKkBNzuO+2uXfQ7SHIP/TBJ QwWTehNgud+ZZmdipA9WuJAtY9NUm2ptWLqmpZPLhT6YxKvllzNspVb6MMfYpa+GD9Dl GgjA==
MIME-Version: 1.0
X-Received: by 10.129.16.215 with SMTP id 206mr18673455ywq.13.1436474458106; Thu, 09 Jul 2015 13:40:58 -0700 (PDT)
Received: by 10.37.112.7 with HTTP; Thu, 9 Jul 2015 13:40:58 -0700 (PDT)
Received: by 10.37.112.7 with HTTP; Thu, 9 Jul 2015 13:40:58 -0700 (PDT)
In-Reply-To: 
References: 
Date: Thu, 9 Jul 2015 21:40:58 +0100
Message-ID: 
From: Nik Tomkinson 
To: Randall Gellens 
Content-Type: multipart/alternative; boundary=001a1142d786cdf347051a774552
Archived-At: 
Cc: slim@ietf.org, Nathaniel Borenstein , Paul Kyzivat 
Subject: Re: [Slim] Meet in Prague to discuss email SLIM draft?
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Jul 2015 20:41:14 -0000

--001a1142d786cdf347051a774552
Content-Type: text/plain; charset=UTF-8

I can only do monday-wednesday inclusive but I would like to meet up.
On Jul 8, 2015 6:39 PM, "Randall Gellens"  wrote:

> Would people like to meet in Prague to talk about the SLIM email draft?
> How about Thursday lunch or Thursday first afternoon session or Thursday
> second after session?  Or, suggest alternate times.
>
> --
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for myself only
> -------------- Randomly selected tag: ---------------
> There are advantages to having a sane person run a government.
>                            --Character in TV series "Wiseguy"
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim
>

--001a1142d786cdf347051a774552
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I can only do monday-wednesday inclusive but I would like to meet up.

On Jul 8, 2015 6:39 PM, "Randall Gellens&qu=
ot; <randy@qti.qualcomm.com> wrote:
Would p=
eople like to meet in Prague to talk about the SLIM email draft?=C2=A0 How =
about Thursday lunch or Thursday first afternoon session or Thursday second=
 after session?=C2=A0 Or, suggest alternate times.



-- 

Randall Gellens

Opinions are personal;=C2=A0 =C2=A0 facts are suspect;=C2=A0 =C2=A0 I speak=
 for myself only

-------------- Randomly selected tag: ---------------

There are advantages to having a sane person run a government.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0--Character in TV series "Wiseguy"



_______________________________________________

SLIM mailing list

SLIM@ietf.org

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




--001a1142d786cdf347051a774552--


From nobody Thu Jul  9 14:05:52 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEABB1A026E for ; Thu,  9 Jul 2015 14:05:50 -0700 (PDT)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -7.011
X-Spam-Level: 
X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 TMUFKdqFcXFI for ; Thu,  9 Jul 2015 14:05:48 -0700 (PDT)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0509D1A037B for ; Thu,  9 Jul 2015 14:05:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1436475940; x=1468011940; h=message-id:in-reply-to:references:date:to:from:subject: cc; bh=LsIXLF0D7y64qZ4EUzYevl78uPn1mRoaTLVrub9YFlE=; b=PM03G1KSxU2uqG+2QfV/hwxkQcv2Ve7n40td4bEUTvzqbhH3AR0rUx7T qaptwD3NvhinCqigl+el7q5jp7hnMjQMgcz8DclzTuw1UqgBg1negJn4k qea0xZ7Q6L5wMLi425hZUg8lFj7856UXy6HEW5qZDR9q27tAWQ00TbkiE g=;
X-IronPort-AV: E=McAfee;i="5700,7163,7857"; a="93453260"
Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Jul 2015 14:05:32 -0700
X-IronPort-AV: E=Sophos;i="5.15,441,1432623600"; d="scan'208";a="957186850"
Received: from plus.qualcomm.com ([10.52.255.8]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Jul 2015 14:05:32 -0700
Received: from Ironmsg03-L.qualcomm.com (ironmsg03-L.qualcomm.com [172.30.48.18]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id t69L5Pge015629; Thu, 9 Jul 2015 14:05:26 -0700
X-IronPort-AV: E=Sophos;i="5.15,441,1432623600"; d="scan'208";a="957186761"
X-ojodefuego: yes
Received: from unknown (HELO [99.111.97.136]) ([10.64.162.243]) by Ironmsg03-L.qualcomm.com with ESMTP; 09 Jul 2015 14:05:24 -0700
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References:  
X-Mailer: Eudora for Mac OS X
Date: Thu, 9 Jul 2015 14:05:20 -0700
To: Nik Tomkinson 
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Cc: slim@ietf.org, Chris Newman , Nathaniel Borenstein , Paul Kyzivat 
Subject: Re: [Slim] Meet in Prague to discuss email SLIM draft?
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Jul 2015 21:05:51 -0000

How about Tuesday lunch?

At 9:40 PM +0100 7/9/15, Nik Tomkinson wrote:

>  I can only do monday-wednesday inclusive but I would like to meet up.
>
>  On Jul 8, 2015 6:39 PM, "Randall Gellens" 
> <randy@qti.qualcomm.com> wrote:
>
>  Would people like to meet in Prague to talk about the SLIM email 
> draft?  How about Thursday lunch or Thursday first afternoon 
> session or Thursday second after session?  Or, suggest alternate 
> times.
>
>  --
>  Randall Gellens
>  Opinions are personal;    facts are suspect;    I speak for myself only
>  -------------- Randomly selected tag: ---------------
>  There are advantages to having a sane person run a government.
>                             --Character in TV series "Wiseguy"
>
>  _______________________________________________
>  SLIM mailing list
>  SLIM@ietf.org
> 
> https://www.ietf.org/mailman/listinfo/slim
>
>
>  _______________________________________________
>  SLIM mailing list
>  SLIM@ietf.org
>  https://www.ietf.org/mailman/listinfo/slim



-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Never underestimate the power of stupid people in large groups.
                         --George Carlin


From nobody Thu Jul  9 14:58:35 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB49D1A1A47 for ; Thu,  9 Jul 2015 14:58:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 qrECJNnnIe2h for ; Thu,  9 Jul 2015 14:58:31 -0700 (PDT)
Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DACA1A1A43 for ; Thu,  9 Jul 2015 14:58:31 -0700 (PDT)
Received: by ykax123 with SMTP id x123so450055yka.1 for ; Thu, 09 Jul 2015 14:58:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+8fQqe5cO1a3B6rhipsVrWOuZLCTbGOf+7+EM7flwhA=; b=Ido/3y/u+SqKQFDQXXpXjss0H9QxYopbfxTJV7ej7TfZFFFGdXHfQ9PfhAZbDoyK2t HN23Qnh5F1GvcUnJj40o8+j/DsHBmJvQ45Fx3b378nAVFFPkk9lkDgyjoR6M1o8XBugf oLMaBCIoKkvwcb8k8Dq0zl1nK12yX29x0ahX2IaEZi9IfPhKBI5GZZWYLSsVM6x0C8Ew BxyGVOHatRKEgPFK5FyjR4NASVtyQA/XwDljxJqiIQNH9+O6NAmrNRlJUn2Dx/Mmtj/3 hibWZzw42gifoYmR7i1QfKrEvEtUAm0lEO1epRABWVw3O8jHPx1RHFR8GVe8qQeZ5JRS Jc8g==
MIME-Version: 1.0
X-Received: by 10.13.228.71 with SMTP id n68mr19721365ywe.109.1436479110657; Thu, 09 Jul 2015 14:58:30 -0700 (PDT)
Received: by 10.37.112.7 with HTTP; Thu, 9 Jul 2015 14:58:30 -0700 (PDT)
In-Reply-To: 
References:   
Date: Thu, 9 Jul 2015 22:58:30 +0100
Message-ID: 
From: Nik Tomkinson 
To: Randall Gellens 
Content-Type: multipart/alternative; boundary=94eb2c034fc81e3d4f051a785baa
Archived-At: 
Cc: slim@ietf.org, Chris Newman , Nathaniel Borenstein , Paul Kyzivat 
Subject: Re: [Slim] Meet in Prague to discuss email SLIM draft?
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Jul 2015 21:58:33 -0000

--94eb2c034fc81e3d4f051a785baa
Content-Type: text/plain; charset=UTF-8

Hi,

yes, Tuesday lunchtime works well for me.

Nik.

On 9 July 2015 at 22:05, Randall Gellens  wrote:

> How about Tuesday lunch?
>
> At 9:40 PM +0100 7/9/15, Nik Tomkinson wrote:
>
>   I can only do monday-wednesday inclusive but I would like to meet up.
>>
>>  On Jul 8, 2015 6:39 PM, "Randall Gellens" <> randy@qti.qualcomm.com>randy@qti.qualcomm.com> wrote:
>>
>>  Would people like to meet in Prague to talk about the SLIM email draft?
>> How about Thursday lunch or Thursday first afternoon session or Thursday
>> second after session?  Or, suggest alternate times.
>>
>>  --
>>  Randall Gellens
>>  Opinions are personal;    facts are suspect;    I speak for myself only
>>  -------------- Randomly selected tag: ---------------
>>  There are advantages to having a sane person run a government.
>>                             --Character in TV series "Wiseguy"
>>
>>  _______________________________________________
>>  SLIM mailing list
>>  SLIM@ietf.org
>>
>> 
>> https://www.ietf.org/mailman/listinfo/slim
>>
>>
>>  _______________________________________________
>>  SLIM mailing list
>>  SLIM@ietf.org
>>  https://www.ietf.org/mailman/listinfo/slim
>>
>
>
>
> --
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for myself only
> -------------- Randomly selected tag: ---------------
> Never underestimate the power of stupid people in large groups.
>                         --George Carlin
>



-- 

-----------------------------------------------------------------
Multiple Language Content Type Internet Draft:


http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/

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

--94eb2c034fc81e3d4f051a785baa
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,=C2=A0

yes, Tuesday lunchtime works =
well for me.

Nik.

On 9 July 2015 at 22:05, Randall Gelle=
ns <rg+ietf@qti.qualcomm.com> wrote:
How about Tuesday lunch?



At 9:40 PM +0100 7/9/15, Nik Tomkinson wrote:





=C2=A0I can only do monday-wednesday inclusive but I would like to meet up.=




=C2=A0On Jul 8, 2015 6:39 PM, "Randall Gellens" <<mailto:randy@qti.qualcom=
m.com>ra=
ndy@qti.qualcomm.com> wrote:



=C2=A0Would people like to meet in Prague to talk about the SLIM email draf=
t?=C2=A0 How about Thursday lunch or Thursday first afternoon session or Th=
ursday second after session?=C2=A0 Or, suggest alternate times.



=C2=A0--

=C2=A0Randall Gellens

=C2=A0Opinions are personal;=C2=A0 =C2=A0 facts are suspect;=C2=A0 =C2=A0 I=
 speak for myself only

=C2=A0-------------- Randomly selected tag: ---------------

=C2=A0There are advantages to having a sane person run a government.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 --Character in TV series "Wiseguy"



=C2=A0_______________________________________________

=C2=A0SLIM mailing list

=C2=A0<mailto:SLIM@ie=
tf.org>SLIM@ietf.=
org



<https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim





=C2=A0_______________________________________________

=C2=A0SLIM mailing list

=C2=A0SLIM@ietf.org<=
br>
=C2=A0https://www.ietf.org/mailman/listinfo/slim









-- 

Randall Gellens

Opinions are personal;=C2=A0 =C2=A0 facts are suspect;=C2=A0 =C2=A0 I speak=
 for myself only

-------------- Randomly selected tag: ---------------

Never underestimate the power of stupid people in large groups.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 --George Carlin





-- 
-----------=
------------------------------------------------------
Multiple Language=
 Content Type Internet Draft:
http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/=

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




--94eb2c034fc81e3d4f051a785baa--


From nobody Thu Jul  9 19:01:55 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A38D1A6EDE for ; Thu,  9 Jul 2015 19:01:54 -0700 (PDT)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -6.711
X-Spam-Level: 
X-Spam-Status: No, score=-6.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 Uedv-ecMMMSm for ; Thu,  9 Jul 2015 19:01:52 -0700 (PDT)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F8D11A6F12 for ; Thu,  9 Jul 2015 19:01:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1436493712; x=1468029712; h=message-id:in-reply-to:references:date:to:from:subject: content-transfer-encoding; bh=pL9nUB/Jti7BG3XbiNXxz8t0ArafidUzSG39TSn7Lsc=; b=H0Ra1lQ16tp9CEK4h+m/t6hYvHy84PyoT3UVJeTpSNNbpCD+pTe1HQxy PqwMGf8F3bBuyTU5CYHTQuJhiFGWc1SYz37nkx/wG8MUWjgZKjieEyh+l kqsDWwqHIXm2HP0LQ1YEwTHtnZyEWxQX4pTPEFnUckQFJ0LGUpNrsxWKK M=;
X-IronPort-AV: E=McAfee;i="5700,7163,7857"; a="93472546"
Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Jul 2015 19:01:52 -0700
X-IronPort-AV: E=Sophos;i="5.15,443,1432623600"; d="scan'208";a="957425443"
Received: from plus.qualcomm.com ([10.52.255.8]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Jul 2015 19:01:51 -0700
Received: from ironmsg02-L.qualcomm.com (ironmsg02-L.qualcomm.com [172.30.48.16]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id t6A21jYj013793; Thu, 9 Jul 2015 19:01:50 -0700
X-IronPort-AV: E=Sophos;i="5.15,443,1432623600"; d="scan'208";a="473081711"
X-ojodefuego: yes
Received: from unknown (HELO [99.111.97.136]) ([10.64.162.243]) by ironmsg02-L.qualcomm.com with ESMTP; 09 Jul 2015 19:01:44 -0700
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <559D2F7F.5060707@omnitor.se>
References: <559D2F7F.5060707@omnitor.se>
X-Mailer: Eudora for Mac OS X
Date: Thu, 9 Jul 2015 19:01:42 -0700
To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?=  , "slim@ietf.org" 
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Subject: Re: [Slim] Use cases in draft-gellens-slim-negotiating-human-language-02
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jul 2015 02:01:54 -0000

At 4:11 PM +0200 7/8/15, Gunnar Hellstr=F6m wrote:

>  Hi Randall,
>  In March, around 5-7, I submitted a couple of=20
> use case text proposals indented for=20
> draft-gellens-slim-negotiating-human-language.
>  I did not see any rejection of them but I do=20
> not see them included in version -02.

Hi Gunnar,

Are you referring to the message where you=20
submitted a use case involving an Australian sign=20
language user?  There was some list discussion=20
back in March, but I didn't think we'd concluded=20
on adding it.  I think the case has too much=20
detail for the scope of the document, and I=20
didn't see how it added to the use cases already=20
in the draft.  I'm happy to work with you on=20
preparing a use case that more clearly shows=20
whatever aspects might be missing from what is in=20
the draft now, but I'd like to avoid duplicative=20
or excessively detailed cases because they can=20
make it harder to understand the document as a=20
whole.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Money is the root of all evil, and man needs roots


From nobody Thu Jul  9 19:26:20 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31CD31A8709 for ; Thu,  9 Jul 2015 19:26:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.588
X-Spam-Level: 
X-Spam-Status: No, score=-3.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 pS646NVv1pCa for ; Thu,  9 Jul 2015 19:26:15 -0700 (PDT)
Received: from millet.cc.columbia.edu (millet.cc.columbia.edu [128.59.72.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B32271A86FD for ; Thu,  9 Jul 2015 19:26:15 -0700 (PDT)
Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by millet.cc.columbia.edu (8.13.8/8.13.8) with ESMTP id t6A2PFZT021901 for ; Thu, 9 Jul 2015 22:26:14 -0400
Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id 87A0C81 for ; Thu,  9 Jul 2015 22:26:14 -0400 (EDT)
Received: from salak.cc.columbia.edu (salak.cc.columbia.edu [128.59.29.6]) by hazelnut (Postfix) with ESMTP id 6A3D480 for ; Thu,  9 Jul 2015 22:26:14 -0400 (EDT)
Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com [209.85.213.169]) by salak.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id t6A2QDYi028292 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 9 Jul 2015 22:26:14 -0400 (EDT)
Received: by igrv9 with SMTP id v9so3569311igr.1 for ; Thu, 09 Jul 2015 19:26:13 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nZ7y5ak0W7LGFTn0nNEL1lF/4tuW+5NvFJzgv4XN/Q8=; b=GlKkWJ2c1GBM0H6i0onsjC7Y0bF17GcteazcFOsfvS+EpLwHJYs26zjAHf5tZBlrxA vzzDIcfrT216q6LhY9r0m7HWPNI472ipxV7KVlkKjXgdv2ZbyyrpT3lsLMFKfWf//1QG sieGzoc5ik3P9AZhStUYfmS71ZftZuVHvQvy2172H9CEFLkS8orulKawAcHaw9+nEdI3 dpZSajZO/9/WOyCT/vGM/AIH5ryqSXtc+iwYMyJGfM+1Po5Es4oeSOSPuMFed0eUjwdf 0/NBJQqEjIko0kvjYsrovDoaE1Lpvv6V2AUEPqQqhJoQ/w6aHS9ukQ22oAdvGexwI/u2 XOIA==
X-Gm-Message-State: ALoCoQnbFp8fORIjsAUX1cdrl4cbvNxbORy+SmnEb4lzgMOTfMpqGloFn/NYwMGJsSrHDTcYj/dnLNH4KckHx696x+vdKszU+2hOMu0fOhMkQQDvZ7dZ8Kd1dybBXAJttiv8lQAHygw5
X-Received: by 10.107.154.196 with SMTP id c187mr19351707ioe.64.1436495173822;  Thu, 09 Jul 2015 19:26:13 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.107.154.196 with SMTP id c187mr19351701ioe.64.1436495173762;  Thu, 09 Jul 2015 19:26:13 -0700 (PDT)
Received: by 10.36.121.131 with HTTP; Thu, 9 Jul 2015 19:26:13 -0700 (PDT)
In-Reply-To: 
References: 
Date: Thu, 9 Jul 2015 22:26:13 -0400
Message-ID: 
From: Henning Schulzrinne 
To: Randall Gellens 
Content-Type: multipart/alternative; boundary=001a1140e81e8dc6a8051a7c18ca
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6
Archived-At: 
Cc: slim@ietf.org, ECRIT , Ban Al-Bakri , Bernard Aboba , Gunnar Hellstrom , Barry Leiba , Brian Rosen , Hannes Tschofenig 
Subject: Re: [Slim] Time in Prague to discuss SLIM real-time draft
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jul 2015 02:26:17 -0000

--001a1140e81e8dc6a8051a7c18ca
Content-Type: text/plain; charset=UTF-8

I'm in Prague Sunday afternoon through Thursday morning, and fairly
flexible. Thanks for organizing!

On Wed, Jul 8, 2015 at 1:30 PM, Randall Gellens 
wrote:

> I'd like to set a time to meet in Prague so that Bernard, Brian, myself,
> and anyone else interested can talk in depth about the SLIM real-time
> draft.  Would Monday lunch work?  If not, please suggest some alternate
> times.
>
> --
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for myself only
> -------------- Randomly selected tag: ---------------
> You never finish a program, you just stop working on it.
>

--001a1140e81e8dc6a8051a7c18ca
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I'm in Prague Sunday afternoon through Thursday mornin=
g, and fairly flexible. Thanks for organizing!

On Wed, Jul 8, 2015 at 1:30 PM, Randall =
Gellens <randy@qti.qualcomm.com> wrote:
I'd like to set a time to meet in Prague so that Ber=
nard, Brian, myself, and anyone else interested can talk in depth about the=
 SLIM real-time draft.=C2=A0 Would Monday lunch work?=C2=A0 If not, please =
suggest some alternate times.



-- 

Randall Gellens

Opinions are personal;=C2=A0 =C2=A0 facts are suspect;=C2=A0 =C2=A0 I speak=
 for myself only

-------------- Randomly selected tag: ---------------

You never finish a program, you just stop working on it.





--001a1140e81e8dc6a8051a7c18ca--


From nobody Fri Jul 10 01:13:04 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E84921A897D for ; Fri, 10 Jul 2015 01:12:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.699
X-Spam-Level: *
X-Spam-Status: No, score=1.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 f5IiudLIANyt for ; Fri, 10 Jul 2015 01:12:49 -0700 (PDT)
Received: from bin-vsp-out-04.atm.binero.net (vsp-authed02.binero.net [195.74.38.226]) (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 EE2F01A8980 for ; Fri, 10 Jul 2015 01:12:47 -0700 (PDT)
X-Halon-ID: 6da2ace0-26db-11e5-b1e0-005056917c0c
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.42] (unknown [87.96.160.92]) by bin-vsp-out-04.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Fri, 10 Jul 2015 10:12:38 +0200 (CEST)
Message-ID: <559F7E77.90802@omnitor.se>
Date: Fri, 10 Jul 2015 10:12:39 +0200
From: =?windows-1252?Q?Gunnar_Hellstr=F6m?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: slim@ietf.org
References:  <54F78072.5060206@alum.mit.edu> <54F7A836.6000307@nteczone.com> <54F7F951.5020109@omnitor.se>  <54F8CF6D.3010107@omnitor.se> <54F8D5BA.2050305@alum.mit.edu> <54F8DB06.5060905@omnitor.se> <54FB80CD.1010105@omnitor.se> <54FB985F.5040708@alum.mit.edu>
In-Reply-To: <54FB985F.5040708@alum.mit.edu>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: [Slim] Use cases - Multinational company with interpreter service
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jul 2015 08:12:57 -0000

This is resending of a use case proposed earlier. The intention of 
increasing the use case collection was to show or test where the 
borderlines for realistic use of the language/modality indications are, 
and make sure that we produce coding that covers the cases we want to cover.

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

4.x Multinational company with interpreter service

A person in an international company, has set the phone for indicating 
only spoken Spanish in the audio path and is calling a colleague who 
only talks Vietnamese, having the phone set to only spoken Vietnamese in 
the audio path.
The company has an interpreting service, but does not want that service 
to be engaged in waiting for calls that are not answered. Therefore the 
phones are set to compare the languages of incoming calls with its own 
language settings. In this case, the answering phone detects the 
discrepancy, and calls the interpreting service for a third leg with 
both spoken Spanish and spoken Vietnamese on high priority. The call 
center ACD looks at the language combination and finds the best match 
among the profiles of the logged in interpreters. The selected 
interpreter also gets the language combination displayed on the phone. 
The interpreter is connected and can start the interpretation in the 
expected languages. Before that moment, the Spanish caller has got a 
spoken message in the call, telling that the interpreting service is on 
its way to enter the call.

Note that in this example, the answering phone makes the decision on 
languages, so that the mechanism shall be possible to implement without 
collection of user profiles.  Another way to do this, would be to let 
the call be answered by the phone with the Vietnamese indication, and 
the SIP server connecting the call has extra functionality for detection 
of language mismatch in the established call, and doing the 
rearrangement of the established call into a three-party call with the 
interpreter service on the third leg.

/Gunnar



>     Thanks,
>     Paul
>
> On 3/7/15 5:50 PM, Gunnar Hellström wrote:
>> Let us continue to add to the use cases:
>>
>> A person in Spain with hearing loss who prefers to get both rapid text
>> and speech in the calls to combine to best perception declares strong
>> preference for speaking Spanish, and strong preference for hearing
>> Spanish and strong preference for reading Spanish text.
>> She is calling another person in Spain with hearing loss and the same
>> declaration of preferences:  strong preference for speaking Spanish, and
>> strong preference for hearing Spanish and strong preference for reading
>> Spanish text.
>> They have not indicated any capability for typing Spanish text.
>>
>> The evaluation needs to have the capabilities of both parties available
>> for assessment. The result will be that the calling party gets a
>> Captioned telephony service included in the call, that answers with
>> adding the written Spanish text capability towards the caller, and let
>> the called party's spoken Spanish capability indication pass on to the
>> caller.
>> On the route towards the called party, there is also a need to add rapid
>> typed Spanish text, so another captioned telephony service is added to
>> the call, adding Spanish Typed text capability to the indications,
>> together with the spoken Spanish indication from the caller, so that the
>> callee can be assured to be served well in the call.
>>
>> A problem for this case is how to indicate that both rapid typed Spanish
>> text is needed and also spoken Spanish, so they are not alternatives.
>> Another problem is what Paul brought up: The need to evaluate the
>> combination of preferences from the caller and callee, before the callee
>> is called.
>>
>>
>> Gunnar
>>
>> Gunnar Hellström skrev den 2015-03-05 23:39:
>>> Paul,
>>>
>>> Paul Kyzivat skrev den 2015-03-05 23:16:
>>>> The use case below is a good start.
>>>>
>>>> Are use cases for non-emergency real time communications also in
>>>> scope?
>>> Yes.
>>>>
>>>> I'll also observe that there is major interaction between the way the
>>>> language and media preferences are signaled and the architecture of
>>>> the systems that ensure there is a match of capabilities. Some of
>>>> today's relay services depend on being able to know the preferences
>>>> of the callee before communications are established to the callee.
>>>> They do this in order to queue the call until relay services are
>>>> available before contacting the callee. That is in conflict to
>>>> allowing the called device to signal its preferences without
>>>> pre-arrangement.
>>> Right.
>>> This is a problem with SDP-based preferences.
>>> We have discussed SIP Media tag based preferences. They can be
>>> conveyed at Register time and stored in SIP servers, and then compared
>>> for routing decisions with what the caller has.
>>> That approach is described in the draft Appendix A.
>>> I think the main problem with that approach was what we thought was a
>>> lack of way to describe spoken versus written language ( that we have
>>> learned a way around today ), and that the already specified ways for
>>> decision maing with RFC 3840 - 3841 did not seem to fit totally.
>>>
>>> A way in a closed environment would be to require support for OPTIONS,
>>> to get a preview of the SDP.  And in this case you might be able to
>>> require OPTIONS support if you want to have your calls properly
>>> routed,  and an assumption that if there is no resonse on OPTIONS,
>>> then that user is supposed to be a speech user with the default
>>> language of the area.
>>>
>>>
>>>
>>>>
>>>> In the use case below, the emergency operator takes the call before
>>>> the relay is included. This works out because there is *some* medium
>>>> in common that can be used before relaying comes online. There would
>>>> be a problem if the emergency operator only supported audio - the
>>>> call would be established but there would initially be no useful
>>>> media. That would be distressing for the caller. In emergency cases
>>>> it is plausible to expect the emergency operators to have extra
>>>> technology to help with these cases. But in non-emergency cases that
>>>> isn't necessarily true.
>>> Yes, I agree completely that answering a call and finding that you
>>> have no common language is distressing. The 2 minute wait for
>>> interpreter should of course also be avoided. But exsists in reality.
>>>>
>>>> My point is simply that the architecture(s) required to support these
>>>> features should be considered as part of the work. (This may not lead
>>>> to any normative requirements. It might only be examples or use
>>>> cases.)
>>> Yes.
>>>>
>>>>     Thanks,
>>>>     Paul
>>>>
>>>> On 3/5/15 4:49 PM, Gunnar Hellström wrote:
>>>>> In order to decide on what to support, I think we should now
>>>>> collect a
>>>>> long list of use cases and then decide which ones to support and
>>>>> which
>>>>> ones to not support.
>>>>>
>>>>> I can imagine two kinds of use cases:
>>>>> 1.  architectural cases outlining callers, callees and call
>>>>> distribution
>>>>> and routing functions and additional services.
>>>>> 2. call cases: callers with language and media preferences called
>>>>> parties with media and language capabilities and additional services
>>>>> with language capabilities.
>>>>>
>>>>> So, here is a use case:
>>>>>
>>>>> Emergency call from an Australian Sign language user
>>>>>
>>>>> A deaf person in Australia has prepared her phone with the following
>>>>> preferences:
>>>>> Prefer to use Australian Sign Language for both signing and
>>>>> perceiving
>>>>> sign in video.
>>>>> Can with less but fair preference do International Sign in both
>>>>> directions in video.
>>>>> Can but do not prefer to use real-time text in English in the text
>>>>> channel.
>>>>> Has a terminal with audio function both ways but has no interest
>>>>> to use
>>>>> that for language communication.
>>>>> She has an emergency in Australia and calls the Australian emergency
>>>>> number.
>>>>> The emergency service has no own sign language capability, but has a
>>>>> few
>>>>> terminals and operators who handle video, audio and real-time text
>>>>> (total conversation). They have an agreement to call for
>>>>> interpretation
>>>>> between Australian Sign Laguage and Spoken English, but that
>>>>> service is
>>>>> allowed to have up to two minutes answering time.
>>>>> The call is analyzed for language and media contents and the ACD
>>>>> offers
>>>>> it to the group of operators with total conversation terminals
>>>>> with an
>>>>> indication that the two sign languages are preferred but that English
>>>>> text is possible.
>>>>> The analysis also causes an outgoing call in all media to the sign
>>>>> language interpreting service because no operator in the emergency
>>>>> service know sign language.
>>>>> The emergency operator takes the call and establish all media, and
>>>>> see
>>>>> from the declaration that it is possible to start asking about the
>>>>> emergency by text. The deaf caller see all media being established
>>>>> but
>>>>> also see that at the moment the only common language is typed
>>>>> English.
>>>>> A minute later the sign  laguage interpreter answers. The call is
>>>>> modified to a three-party call, the capability indication changes so
>>>>> that it is evident to the caller that Australian sign language can be
>>>>> used now.
>>>>> The call can continue in convenient sign with the calling user and
>>>>> speech between the interpreter and the emergency operator. If
>>>>> anything
>>>>> needs exact spelling or remembered, then the text channel is still
>>>>> there
>>>>> for occasional use.
>>>>>
>>>>>
>>>>> Gunnar
>>>>>
>>>>>
>>>>>
>>>>> Randall Gellens skrev den 2015-03-05 21:10:
>>>>>> Hi Gunnar,
>>>>>>
>>>>>> At 7:36 AM +0100 3/5/15, Gunnar Hellström wrote:
>>>>>>
>>>>>>>  I also view the charter to be good and want to see the work
>>>>>>> started.
>>>>>>
>>>>>> Thank you.
>>>>>>
>>>>>>>
>>>>>>>  There are drafts to start with:
>>>>>>>  https://tools.ietf.org/html/draft-gellens-slim-negotiating-human-language-00
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>  https://tools.ietf.org/html/draft-tomkinson-slim-multilangcontent-00
>>>>>>>
>>>>>>>
>>>>>>>  Answering Christians question about what extensions might be
>>>>>>> needed,
>>>>>>> I want to answer relative towhat is in the realtime draft now.
>>>>>>>
>>>>>>>  I see some topics that may need discussion:
>>>>>>
>>>>>> The point of the group is to have discussion on what we need. One
>>>>>> thing that has been beaten into me by painful experience over many
>>>>>> years is that it's best to start with the simplest possible solution
>>>>>> that meets enough of the use cases to be useful, and build on that
>>>>>> after gaining experience.  I've seen this approach work, whereas
>>>>>> creating a more complex solution that tries to meet all or most
>>>>>> anticipated use cases often fails due to being too difficult to
>>>>>> implement.
>>>>>>
>>>>>>>
>>>>>>>  1. Coding of unspecified language but specific mode.
>>>>>>>  I expect that in many cases it is merely the modality that is of
>>>>>>> interest to negotiate, rather than the exact language. There is
>>>>>>> often
>>>>>>> a default language in a specific area, and as long as you use that,
>>>>>>> you will feel that it is a burden to specify that exactly, but
>>>>>>> rather
>>>>>>> indicate in what medium you want the language exchange. You may
>>>>>>> want
>>>>>>> to use text for language exchange and audio to convey the sound
>>>>>>> from
>>>>>>> a location.
>>>>>>>  So, you would like to specify your preference for spoken,
>>>>>>> listened,
>>>>>>> written, read, visualized and seen.  And for signed and perceiving
>>>>>>> sign languages. Regardless of exact language.
>>>>>>>  So, some codes to use in place of specific languages for these
>>>>>>> kinds
>>>>>>> of general modalities could be needed.
>>>>>>
>>>>>> We can discuss this in the group.  We already have the ability to
>>>>>> negotiate media with no language expression, which might be
>>>>>> sufficient
>>>>>> for the basic use cases.  Adding a new tag for the default language
>>>>>> wouldn't be a huge burden, but I'd like to see discussion on why
>>>>>> it's
>>>>>> needed before proceeding.
>>>>>>
>>>>>>>
>>>>>>>  2. Relative preference between media.
>>>>>>>  I think it can be important to have a coding for preference
>>>>>>> between
>>>>>>> media, to express for example if I prefer to speak but can
>>>>>>> accept to
>>>>>>> type.
>>>>>>>  We have an order of preference indication between languages in the
>>>>>>> same medium in the draft, but not between media.
>>>>>>
>>>>>> This would be worth discussing in the group as well.  My question
>>>>>> would be if the incremental value of being able to specify this
>>>>>> would
>>>>>> result in any real-world benefit, that is, would it change the
>>>>>> result
>>>>>> of the negotiation over what we have now?
>>>>>>
>>>>>>>
>>>>>>>  3. Absolute versus relative preference between languages.
>>>>>>>  We have a relative order of preference indication between
>>>>>>> languages
>>>>>>> in the same medium in the draft.
>>>>>>>  I can see cases when it is instead an absolute preference that
>>>>>>> would
>>>>>>> be of importance.
>>>>>>>  E.g. I am equally happy to get spoken German or spoken French in
>>>>>>> this call, but may as the last resort do with spoken English.
>>>>>>>  Or, same thing between media:
>>>>>>>  One case can be:  I strongly prefer to use spoken French, but
>>>>>>> can as
>>>>>>> the last resort accept to use written French.
>>>>>>>  Another can be: I must receive both spoken French and French text.
>>>>>>
>>>>>> I would expect that the called party would have a set of language
>>>>>> and
>>>>>> media capabilities (either in-house or by bridging in translation,
>>>>>> relay, or interpreter services) and would want to support the
>>>>>> caller's
>>>>>> needs.  I doubt that getting fancy with preferences would change the
>>>>>> result very much.
>>>>>>
>>>>>>>
>>>>>>>  4. Same media conveyed under different media types
>>>>>>>  The current draft specifies SDP as the base for the language
>>>>>>> declarations. How do we resolve the cases when the same language
>>>>>>> modality can be conveyed under different media types?
>>>>>>>  Text is conveyed in real time under the media type text. But it is
>>>>>>> possible to have some near real-time exchange of text under media
>>>>>>> type message (MSRP). How do we express that these might be
>>>>>>> alternatives for carrying the same written language?
>>>>>>>  That question also surfaces the problem that in the language
>>>>>>> register there are no good way to express if it is a spoken use of
>>>>>>> the language or a written use of the language we want to specify.
>>>>>>> There are separate language tags for sign languages but not for
>>>>>>> spoken varsus written. (there are some sub-tags for scripts, but
>>>>>>> they
>>>>>>> should only be used when it is important to select between script
>>>>>>> variants )(There is even an SDP-less way to carry text, in the SIP
>>>>>>> MESSAGE method. There will be no way to express that as an
>>>>>>> alternative way to convey language when we base the method on SDP.)
>>>>>>
>>>>>> I'm happy to look at non-SDP and/or non-SIP mechanisms once we have
>>>>>> the SDP-and-SIP one done. Since emergency calling is based on SDP
>>>>>> and
>>>>>> SIP, I think we need to start there.
>>>>>>
>>>>>>>
>>>>>>>  3. Slow start of SIP.
>>>>>>>  We can in SIP have INVITE without SDP offer, and let the
>>>>>>> responding
>>>>>>> party send the offer with SDP.
>>>>>>>  With the negotiation mechanism based on SDP, does this slow start
>>>>>>> cause any restrictions for us regarding the possiblilities to
>>>>>>> express
>>>>>>> and negotiate language?
>>>>>>
>>>>>> I think we need to focus initially on what's needed for emergency
>>>>>> calling and similar use cases.  We can expand after we get something
>>>>>> done.
>>>>>>
>>>>>>>
>>>>>>>  I do not want to cause eternal discussions about border cases,
>>>>>>> and I
>>>>>>> do not want to extend the method into unmanageable complexity. I
>>>>>>> just
>>>>>>> want us to take good decisions on the mechanism so that it
>>>>>>> covers the
>>>>>>> cases we want it to cover with a method that is not too complex.
>>>>>>
>>>>>> Thank you, that's good to hear.
>>>>>>
>>>>>>>
>>>>>>>  Christian, maybe in your question was also how the intended work
>>>>>>> differs from language negotiation methods already available in
>>>>>>> RFC:s?
>>>>>>>  The current draft, section 6 has a discussion about that. One
>>>>>>> difference is that there is today no way to indicate order of
>>>>>>> preference between languages.  Another is the one I described
>>>>>>> above;
>>>>>>> the Language tag as such does not indicate the difference between
>>>>>>> spoken and written.
>>>>>>>
>>>>>>>  /Gunnar
>>>>>>>
>>>>>>>
>>>>>>>  Christian Groves skrev den 2015-03-05 01:49:
>>>>>>>>  Hello Randall,
>>>>>>>>
>>>>>>>>  I agree with Paul that it does seem optimistic.
>>>>>>>>
>>>>>>>>  In the question text its mentions the caller's "media needs". I'm
>>>>>>>> pretty sure I under the scope of "language needs" but "media
>>>>>>>> needs"
>>>>>>>> could be a little open ended. What sort of enhancements do you see
>>>>>>>> to the existing negotiation methods?
>>>>>>>>
>>>>>>>>  Regards, Christian
>>>>>>>>
>>>>>>>>  On 5/03/2015 9:00 AM, Paul Kyzivat wrote:
>>>>>>>>>  I support this.
>>>>>>>>>
>>>>>>>>>  But I find the schedule vastly overoptimistic, especially for
>>>>>>>>> real-time. Add a year or two.
>>>>>>>>>
>>>>>>>>>      Thanks,
>>>>>>>>>      Paul
>>>>>>>>>
>>>>>>>>>  On 3/3/15 6:33 PM, Randall Gellens wrote:
>>>>>>>>>>  Hi SLIM people,
>>>>>>>>>>
>>>>>>>>>>  Here is a revised proposed charter.  The intent is to focus on
>>>>>>>>>> the two
>>>>>>>>>>  current drafts and get those completed.
>>>>>>>>>>
>>>>>>>>>>  ----------
>>>>>>>>>>
>>>>>>>>>>  SLIM: Selection of Language for Internet Media
>>>>>>>>>>
>>>>>>>>>>  Description of Working Group:
>>>>>>>>>>
>>>>>>>>>>  A mutually comprehensible language is helpful for human
>>>>>>>>>> communication.
>>>>>>>>>>  This is true across a range of circumstances and
>>>>>>>>>> environments. In
>>>>>>>>>>  general, the problem is most acute in situations where there is
>>>>>>>>>> not a
>>>>>>>>>>  clear choice for a single language, such as environments
>>>>>>>>>> lacking
>>>>>>>>>>  contextual or out-of-band information regarding the identity
>>>>>>>>>> of the
>>>>>>>>>>  parties and the language to be used.
>>>>>>>>>>
>>>>>>>>>>  The group will address two specific cases that most urgently
>>>>>>>>>> need a
>>>>>>>>>>  technical solution: One problem space is non-real-time
>>>>>>>>>> communication,
>>>>>>>>>>  specifically email for one-to-many or where the set of
>>>>>>>>>> recipients is
>>>>>>>>>>  dynamic or different recipients require different languages;
>>>>>>>>>> the
>>>>>>>>>> other
>>>>>>>>>>  is real-time communication, specifically emergency calling,
>>>>>>>>>> preferably
>>>>>>>>>>  also useful for other cases where the parties may not know each
>>>>>>>>>> other
>>>>>>>>>>  personally or where one party wishes to accommodate people with
>>>>>>>>>> varying
>>>>>>>>>>  language and media needs.
>>>>>>>>>>
>>>>>>>>>>  In the real-time communication case, language and media are
>>>>>>>>>>  intrinsically linked, for example, signed languages require a
>>>>>>>>>> video media.
>>>>>>>>>>
>>>>>>>>>>  While the two use cases are in different contexts (real time
>>>>>>>>>> and
>>>>>>>>>>  non-real-time), the fundamental goal is the same: to enable
>>>>>>>>>> selection of
>>>>>>>>>>  the best-fit language(s) for a specific situation. Some of the
>>>>>>>>>> details
>>>>>>>>>>  will also be in common across the cases. Having a single WG
>>>>>>>>>> address
>>>>>>>>>>  both cases makes it clear that these are two aspects of the
>>>>>>>>>> same
>>>>>>>>>> basic
>>>>>>>>>>  problem.  A single WG also makes it easier to maximize
>>>>>>>>>> similarities and
>>>>>>>>>>  avoid unnecessary fragmentation of the solutions.
>>>>>>>>>>
>>>>>>>>>>  The group will produce two documents, one for email, and one
>>>>>>>>>> for
>>>>>>>>>>  real-time communications.
>>>>>>>>>>
>>>>>>>>>>  In the email case, the group will produce a MIME content type
>>>>>>>>>>  specification that enables a single email message to contain
>>>>>>>>>> multiple
>>>>>>>>>>  language versions of the content, with provisions to help
>>>>>>>>>> clients
>>>>>>>>>> select
>>>>>>>>>>  a best fit version.
>>>>>>>>>>
>>>>>>>>>>  In the real-time communication case, the group will produce a
>>>>>>>>>>  specification enabling negotiation of a human language per
>>>>>>>>>> media
>>>>>>>>>>  stream.  The specification must be suitable for use in
>>>>>>>>>> emergency
>>>>>>>>>>  communications as specified in RFC 6443 and RFC 6881; it is
>>>>>>>>>> desirable to
>>>>>>>>>>  also be suitable for use in non-emergency real-time
>>>>>>>>>> communications that
>>>>>>>>>>  share the same call set-up and media negotiation protocols. The
>>>>>>>>>>  mechanism will permit the caller's media and language needs and
>>>>>>>>>>  preferences to be matched against what the called party is
>>>>>>>>>> able to
>>>>>>>>>>  provide.  The mechanism will permit resources (e.g.,
>>>>>>>>>> translation,
>>>>>>>>>> relay,
>>>>>>>>>>  media) to be allocated or engaged as early as possible in the
>>>>>>>>>> call
>>>>>>>>>>  set-up or for the call to be routed or handled specially (e.g.,
>>>>>>>>>> routed
>>>>>>>>>>  to a resource able to provide a needed language and/or media).
>>>>>>>>>>
>>>>>>>>>>  Goals and Milestones:
>>>>>>>>>>
>>>>>>>>>>  June 2015 -- Submit "Multiple Language Content Type" to the
>>>>>>>>>> IESG for
>>>>>>>>>>  consideration as a Standards Track RFC
>>>>>>>>>>  June 2015 -- Submit "Negotiating Human Language in Real-Time
>>>>>>>>>>  Communications" to the IESG for consideration as a Standards
>>>>>>>>>> Track RFC
>>>>>>>>>>
>>>>>>>>>>  ----------
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  _______________________________________________
>>>>>>>>>  SLIM mailing list
>>>>>>>>>  SLIM@ietf.org
>>>>>>>>>  https://www.ietf.org/mailman/listinfo/slim
>>>>>>>>>
>>>>>>>>
>>>>>>>>  _______________________________________________
>>>>>>>>  SLIM mailing list
>>>>>>>>  SLIM@ietf.org
>>>>>>>>  https://www.ietf.org/mailman/listinfo/slim
>>>>>>>
>>>>>>>  --
>>>>>>>  -----------------------------------------
>>>>>>>  Gunnar Hellström
>>>>>>>  Omnitor
>>>>>>>  gunnar.hellstrom@omnitor.se
>>>>>>>  +46 708 204 288
>>>>>>>
>>>>>>>  _______________________________________________
>>>>>>>  SLIM mailing list
>>>>>>>  SLIM@ietf.org
>>>>>>>  https://www.ietf.org/mailman/listinfo/slim
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> SLIM mailing list
>>>> SLIM@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/slim
>>>
>>
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim

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


From nobody Fri Jul 10 01:17:15 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C0F1A8987 for ; Fri, 10 Jul 2015 01:17:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.099
X-Spam-Level: *
X-Spam-Status: No, score=1.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 azy17Fjvaqga for ; Fri, 10 Jul 2015 01:17:13 -0700 (PDT)
Received: from bin-vsp-out-01.atm.binero.net (vsp-authed02.binero.net [195.74.38.226]) (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 B903B1A8986 for ; Fri, 10 Jul 2015 01:17:12 -0700 (PDT)
X-Halon-ID: 1c2c8ded-26dc-11e5-8487-005056917a89
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.42] (unknown [87.96.160.92]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Fri, 10 Jul 2015 10:17:31 +0200 (CEST)
Message-ID: <559F7F82.4010005@omnitor.se>
Date: Fri, 10 Jul 2015 10:17:06 +0200
From: =?windows-1252?Q?Gunnar_Hellstr=F6m?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: slim@ietf.org
References:  <54F78072.5060206@alum.mit.edu> <54F7A836.6000307@nteczone.com> <54F7F951.5020109@omnitor.se>  <54F8CF6D.3010107@omnitor.se> <54F8D5BA.2050305@alum.mit.edu> <54F8DB06.5060905@omnitor.se>
In-Reply-To: <54F8DB06.5060905@omnitor.se>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [Slim] Use cases  - Captioned telephony service need
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jul 2015 08:17:14 -0000

This is another use case sent earlier. We need to decide if we can 
extend the coding to express the need of simultaneous speech and 
texting, or if we need to divert this need to indicate a service request 
instead of a modality need.

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

4.x Captioned telephony user calling another captioned telephony user

A person in Spain with hearing loss who prefers to get both rapid text 
and speech in the calls to combine to best perception declares strong 
preference for speaking Spanish, and strong preference for hearing 
Spanish and strong preference for reading Spanish text.
She is calling another person in Spain with hearing loss and the same 
declaration of preferences:  strong preference for speaking Spanish, and 
strong preference for hearing Spanish and strong preference for reading 
Spanish text.
They have not indicated any capability for typing Spanish text.

The evaluation needs to have the capabilities of both parties available 
for assessment. The result will be that the calling party gets a 
Captioned telephony service included in the call, that answers with 
adding the written Spanish text capability towards the caller, and let 
the called party's spoken Spanish capability indication pass on to the 
caller.
On the route towards the called party, there is also a need to add rapid 
typed Spanish text, so another captioned telephony service is added to 
the call, adding Spanish Typed text capability to the indications, 
together with the spoken Spanish indication from the caller, so that the 
callee can be assured to be served well in the call.

A problem for this case is how to indicate that both rapid typed Spanish 
text is needed and also spoken Spanish, so they are not alternatives.
Another problem is what Paul brought up: The need to evaluate the 
combination of preferences from the caller and callee, before the callee 
is called.


Gunnar


From nobody Fri Jul 10 01:26:53 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979931A8992 for ; Fri, 10 Jul 2015 01:26:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.099
X-Spam-Level: *
X-Spam-Status: No, score=1.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 5ODmB3gKs_uh for ; Fri, 10 Jul 2015 01:26:50 -0700 (PDT)
Received: from bin-vsp-out-04.atm.binero.net (vsp-authed01.binero.net [195.74.38.224]) (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 33C511A8991 for ; Fri, 10 Jul 2015 01:26:50 -0700 (PDT)
X-Halon-ID: 6535ae39-26dd-11e5-b1e0-005056917c0c
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.42] (unknown [87.96.160.92]) by bin-vsp-out-04.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Fri, 10 Jul 2015 10:26:43 +0200 (CEST)
Message-ID: <559F81C3.1090203@omnitor.se>
Date: Fri, 10 Jul 2015 10:26:43 +0200
From: =?windows-1252?Q?Gunnar_Hellstr=F6m?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: slim@ietf.org
References:  <54F78072.5060206@alum.mit.edu> <54F7A836.6000307@nteczone.com> <54F7F951.5020109@omnitor.se> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: [Slim] Use cases - Complex combination of preferences
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jul 2015 08:26:51 -0000

Here is the use case that might seem to have too many details. So if 
that is so, let us reduce it, or separate it in more but less complex ones.
It tries to show the need for priority among the indications, and the 
priority between different media.

We do not have any requirement chapter.


---------
4.x Emergency call from an Australian Sign language user

A deaf person in Australia has prepared her phone with the following 
preferences:
Prefer to use Australian Sign Language for both signing and perceiving 
sign in video.
Can with less but fair preference do International Sign  in both 
directions in video.
Can but do not prefer to use real-time text in English in the text channel.
Has a terminal with audio function both ways but has no interest to use 
that for language communication.
She has an emergency in Australia and calls the Australian emergency number.
The emergency service has no own sign language capability, but has a few 
terminals and operators who handle video, audio and real-time text 
(total conversation). They have an agreement to call for interpretation 
between Australian Sign Laguage and Spoken English, but that service is 
allowed to have up to two minutes answering time.
The call is analyzed for language and media contents and the ACD offers 
it to the group of operators with total conversation terminals with an 
indication that the two sign languages are preferred but that English 
text is possible.
The analysis also causes an outgoing call in all media to the sign 
language interpreting service because no operator in the emergency 
service know sign language.
The emergency operator takes the call and establish all media, and see 
from the declaration that it is possible to start asking about the 
emergency by text. The deaf caller see all media being established but 
also see that at the moment the only common language is typed English.
A minute later the sign  laguage interpreter answers. The call is 
modified to a three-party call, the capability indication changes so 
that it is evident to the caller that Australian sign language can be 
used now.
The call can continue in convenient sign with the calling user and 
speech between the interpreter and the emergency operator. If anything 
needs exact spelling or remembered, then the text channel is still there 
for occasional use.


Gunnar

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


From nobody Fri Jul 10 06:09:54 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B241AC3B9; Fri, 10 Jul 2015 06:09:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 bcF_XetKruQE; Fri, 10 Jul 2015 06:09:47 -0700 (PDT)
Received: from BLU004-OMC4S16.hotmail.com (blu004-omc4s16.hotmail.com [65.55.111.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EE551AC3B8; Fri, 10 Jul 2015 06:09:47 -0700 (PDT)
Received: from BLU406-EAS19 ([65.55.111.135]) by BLU004-OMC4S16.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008);  Fri, 10 Jul 2015 06:09:46 -0700
X-TMN: [6JIU5O/m1vU612EeSuQvyITN+eAzLvqe]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
Content-Type: multipart/alternative; boundary="Apple-Mail-3F891650-5D6A-4853-BA24-2A4DB499E808"
Content-Transfer-Encoding: 7bit
From: Bernard Aboba 
MIME-Version: 1.0 (1.0)
Date: Fri, 10 Jul 2015 06:09:44 -0700
References:  
To: Henning Schulzrinne 
In-Reply-To: 
X-OriginalArrivalTime: 10 Jul 2015 13:09:46.0098 (UTC) FILETIME=[B186BD20:01D0BB11]
Archived-At: 
Cc: "slim@ietf.org" , ECRIT , Ban Al-Bakri , Gunnar Hellstrom , Barry Leiba , Brian Rosen , Randall Gellens , Hannes Tschofenig 
Subject: Re: [Slim] Time in Prague to discuss SLIM real-time draft
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jul 2015 13:09:49 -0000

--Apple-Mail-3F891650-5D6A-4853-BA24-2A4DB499E808
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I will be in Prague from Saturday through Friday. I cannot do Monday lunch b=
ut other days are OK.

> On Jul 9, 2015, at 7:26 PM, Henning Schulzrinne  wrot=
e:
>=20
> I'm in Prague Sunday afternoon through Thursday morning, and fairly flexib=
le. Thanks for organizing!
>=20
>> On Wed, Jul 8, 2015 at 1:30 PM, Randall Gellens  w=
rote:
>> I'd like to set a time to meet in Prague so that Bernard, Brian, myself, a=
nd anyone else interested can talk in depth about the SLIM real-time draft. =
 Would Monday lunch work?  If not, please suggest some alternate times.
>>=20
>> --=20
>> Randall Gellens
>> Opinions are personal;    facts are suspect;    I speak for myself only
>> -------------- Randomly selected tag: ---------------
>> You never finish a program, you just stop working on it.
>=20

--Apple-Mail-3F891650-5D6A-4853-BA24-2A4DB499E808
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0
L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+SSB3aWxs
IGJlIGluIFByYWd1ZSBmcm9tIFNhdHVyZGF5IHRocm91Z2ggRnJpZGF5LiBJIGNhbm5vdCBkbyBN
b25kYXkgbHVuY2ggYnV0IG90aGVyIGRheXMgYXJlIE9LLjxicj48L2Rpdj48ZGl2Pjxicj5PbiBK
dWwgOSwgMjAxNSwgYXQgNzoyNiBQTSwgSGVubmluZyBTY2h1bHpyaW5uZSAmbHQ7PGEgaHJlZj0i
bWFpbHRvOmhnc0Bjcy5jb2x1bWJpYS5lZHUiPmhnc0Bjcy5jb2x1bWJpYS5lZHU8L2E+Jmd0OyB3
cm90ZTo8YnI+PGJyPjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+PGRpdiBkaXI9
Imx0ciI+SSdtIGluIFByYWd1ZSBTdW5kYXkgYWZ0ZXJub29uIHRocm91Z2ggVGh1cnNkYXkgbW9y
bmluZywgYW5kIGZhaXJseSBmbGV4aWJsZS4gVGhhbmtzIGZvciBvcmdhbml6aW5nITwvZGl2Pjxk
aXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFdl
ZCwgSnVsIDgsIDIwMTUgYXQgMTozMCBQTSwgUmFuZGFsbCBHZWxsZW5zIDxzcGFuIGRpcj0ibHRy
Ij4mbHQ7PGEgaHJlZj0ibWFpbHRvOnJhbmR5QHF0aS5xdWFsY29tbS5jb20iIHRhcmdldD0iX2Js
YW5rIj5yYW5keUBxdGkucXVhbGNvbW0uY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj48Ymxv
Y2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3Jk
ZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij5JJ2QgbGlrZSB0byBzZXQg
YSB0aW1lIHRvIG1lZXQgaW4gUHJhZ3VlIHNvIHRoYXQgQmVybmFyZCwgQnJpYW4sIG15c2VsZiwg
YW5kIGFueW9uZSBlbHNlIGludGVyZXN0ZWQgY2FuIHRhbGsgaW4gZGVwdGggYWJvdXQgdGhlIFNM
SU0gcmVhbC10aW1lIGRyYWZ0LiZuYnNwOyBXb3VsZCBNb25kYXkgbHVuY2ggd29yaz8mbmJzcDsg
SWYgbm90LCBwbGVhc2Ugc3VnZ2VzdCBzb21lIGFsdGVybmF0ZSB0aW1lcy48c3BhbiBjbGFzcz0i
SE9FblpiIj48Zm9udCBjb2xvcj0iIzg4ODg4OCI+PGJyPg0KPGJyPg0KLS0gPGJyPg0KUmFuZGFs
bCBHZWxsZW5zPGJyPg0KT3BpbmlvbnMgYXJlIHBlcnNvbmFsOyZuYnNwOyAmbmJzcDsgZmFjdHMg
YXJlIHN1c3BlY3Q7Jm5ic3A7ICZuYnNwOyBJIHNwZWFrIGZvciBteXNlbGYgb25seTxicj4NCi0t
LS0tLS0tLS0tLS0tIFJhbmRvbWx5IHNlbGVjdGVkIHRhZzogLS0tLS0tLS0tLS0tLS0tPGJyPg0K
WW91IG5ldmVyIGZpbmlzaCBhIHByb2dyYW0sIHlvdSBqdXN0IHN0b3Agd29ya2luZyBvbiBpdC48
YnI+DQo8L2ZvbnQ+PC9zcGFuPjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PC9kaXY+DQo8L2Rpdj48
L2Jsb2NrcXVvdGU+PC9ib2R5PjwvaHRtbD4=

--Apple-Mail-3F891650-5D6A-4853-BA24-2A4DB499E808--


From nobody Fri Jul 10 06:16:58 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B560E1AC3BA for ; Fri, 10 Jul 2015 06:16:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level: 
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-dGyPOzBxmg for ; Fri, 10 Jul 2015 06:16:55 -0700 (PDT)
Received: from bin-vsp-out-03.atm.binero.net (vsp-authed01.binero.net [195.74.38.224]) (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 1775C1AC3A7 for ; Fri, 10 Jul 2015 06:16:54 -0700 (PDT)
X-Halon-ID: ea802a52-2705-11e5-8f61-0050569116f7
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.42] (unknown [87.96.160.92]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Fri, 10 Jul 2015 15:16:46 +0200 (CEST)
Message-ID: <559FC5C1.70905@omnitor.se>
Date: Fri, 10 Jul 2015 15:16:49 +0200
From: =?windows-1252?Q?Gunnar_Hellstr=F6m?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Randall Gellens ,  Bernard Aboba , Brian Rosen ,  Hannes Tschofenig , Henning Schulzrinne ,  Ban Al-Bakri , Barry Leiba 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: slim@ietf.org, ecrit@ietf.org
Subject: Re: [Slim] Time in Prague to discuss SLIM real-time draft
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jul 2015 13:16:57 -0000

I will sadly not be in Prague, but want to participate remotely. Any 
time will do.

/Gunnar

Randall Gellens skrev den 2015-07-08 19:30:
> I'd like to set a time to meet in Prague so that Bernard, Brian, 
> myself, and anyone else interested can talk in depth about the SLIM 
> real-time draft.  Would Monday lunch work? If not, please suggest some 
> alternate times.
>

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


From nobody Fri Jul 10 07:53:13 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1928A1B2C89; Fri, 10 Jul 2015 07:53:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.267
X-Spam-Level: 
X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 GPiGXxd5cdOA; Fri, 10 Jul 2015 07:53:10 -0700 (PDT)
Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 092171A9166; Fri, 10 Jul 2015 07:53:10 -0700 (PDT)
Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t6AEpfpd009277;  Fri, 10 Jul 2015 10:52:58 -0400
Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1vjduxg6qa-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 10 Jul 2015 10:52:58 -0400
Received: from STNTEXMB13.cis.neustar.com ([169.254.3.249]) by stntexhc10.cis.neustar.com ([169.254.4.214]) with mapi id 14.03.0158.001; Fri, 10 Jul 2015 10:52:57 -0400
From: "Rosen, Brian" 
To: Randall Gellens , Bernard Aboba , Henning Schulzrinne 
Thread-Topic: Time in Prague to discuss SLIM real-time draft
Thread-Index: AQHQurfKLz9b6vQk6kqhL9Xrn4FEcJ3U8P8AgAAcUgD//71wAA==
Date: Fri, 10 Jul 2015 14:52:57 +0000
Message-ID: 
References:    
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [10.33.193.32]
Content-Type: text/plain; charset="utf-8"
Content-ID: <834A66592C2F934B8B81E679CD37947E@neustar.biz>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33,  0.0.0000 definitions=2015-07-10_07:2015-07-10,2015-07-10,1970-01-01 signatures=0
X-Proofpoint-Spam-Reason: safe
Archived-At: 
Cc: "slim@ietf.org" , ECRIT , Ban Al-Bakri , Gunnar Hellstrom , Barry Leiba , Hannes Tschofenig 
Subject: Re: [Slim] Time in Prague to discuss SLIM real-time draft
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jul 2015 14:53:11 -0000

SeKAmWQgbGlrZSB0byBnbyB0byBjbHVlLCBidXQgSSBjYW4gc2tpcCBpdC4gIFR1ZXNkYXkgbHVu
Y2ggd291bGQgd29yay4NCg0KT24gNy8xMC8xNSwgMTA6NTEgQU0sICJSYW5kYWxsIEdlbGxlbnMi
IDxyYW5keUBxdGkucXVhbGNvbW0uY29tPiB3cm90ZToNCg0KPldvdWxkIHRoZSBmaXJzdCBhZnRl
cm5vb24gc2Vzc2lvbiAoc3RhcnRzIGF0IDE6MDApIG9uIE1vbmRheSB3b3JrPw0KPg0KPkF0IDY6
MDkgQU0gLTA3MDAgNy8xMC8xNSwgQmVybmFyZCBBYm9iYSB3cm90ZToNCj4NCj4+ICBJIHdpbGwg
YmUgaW4gUHJhZ3VlIGZyb20gU2F0dXJkYXkgdGhyb3VnaCBGcmlkYXkuIEkgY2Fubm90IGRvDQo+
PiBNb25kYXkgbHVuY2ggYnV0IG90aGVyIGRheXMgYXJlIE9LLg0KPj4NCj4+DQo+PiAgT24gSnVs
IDksIDIwMTUsIGF0IDc6MjYgUE0sIEhlbm5pbmcgU2NodWx6cmlubmUNCj4+IDw8bWFpbHRvOmhn
c0Bjcy5jb2x1bWJpYS5lZHU+aGdzQGNzLmNvbHVtYmlhLmVkdT4gd3JvdGU6DQo+Pg0KPj4+ICBJ
J20gaW4gUHJhZ3VlIFN1bmRheSBhZnRlcm5vb24gdGhyb3VnaCBUaHVyc2RheSBtb3JuaW5nLCBh
bmQNCj4+PiBmYWlybHkgZmxleGlibGUuIFRoYW5rcyBmb3Igb3JnYW5pemluZyENCj4+Pg0KPj4+
ICBPbiBXZWQsIEp1bCA4LCAyMDE1IGF0IDE6MzAgUE0sIFJhbmRhbGwgR2VsbGVucw0KPj4+IDw8
bWFpbHRvOnJhbmR5QHF0aS5xdWFsY29tbS5jb20+cmFuZHlAcXRpLnF1YWxjb21tLmNvbT4gd3Jv
dGU6DQo+Pj4NCj4+PiAgSSdkIGxpa2UgdG8gc2V0IGEgdGltZSB0byBtZWV0IGluIFByYWd1ZSBz
byB0aGF0IEJlcm5hcmQsIEJyaWFuLA0KPj4+IG15c2VsZiwgYW5kIGFueW9uZSBlbHNlIGludGVy
ZXN0ZWQgY2FuIHRhbGsgaW4gZGVwdGggYWJvdXQgdGhlDQo+Pj4gU0xJTSByZWFsLXRpbWUgZHJh
ZnQuICBXb3VsZCBNb25kYXkgbHVuY2ggd29yaz8gIElmIG5vdCwgcGxlYXNlDQo+Pj4gc3VnZ2Vz
dCBzb21lIGFsdGVybmF0ZSB0aW1lcy4NCj4+Pg0KPj4+ICAtLQ0KPj4+ICBSYW5kYWxsIEdlbGxl
bnMNCj4+PiAgT3BpbmlvbnMgYXJlIHBlcnNvbmFsOyAgICBmYWN0cyBhcmUgc3VzcGVjdDsgICAg
SSBzcGVhayBmb3IgbXlzZWxmDQo+Pj5vbmx5DQo+Pj4gIC0tLS0tLS0tLS0tLS0tIFJhbmRvbWx5
IHNlbGVjdGVkIHRhZzogLS0tLS0tLS0tLS0tLS0tDQo+Pj4gIFlvdSBuZXZlciBmaW5pc2ggYSBw
cm9ncmFtLCB5b3UganVzdCBzdG9wIHdvcmtpbmcgb24gaXQuDQo+DQo+DQo+DQo+LS0gDQo+UmFu
ZGFsbCBHZWxsZW5zDQo+T3BpbmlvbnMgYXJlIHBlcnNvbmFsOyAgICBmYWN0cyBhcmUgc3VzcGVj
dDsgICAgSSBzcGVhayBmb3IgbXlzZWxmIG9ubHkNCj4tLS0tLS0tLS0tLS0tLSBSYW5kb21seSBz
ZWxlY3RlZCB0YWc6IC0tLS0tLS0tLS0tLS0tLQ0KPkhvd2UncyBMYXc6DQo+ICAgIEV2ZXJ5b25l
IGhhcyBhIHNjaGVtZSB0aGF0IHdpbGwgbm90IHdvcmsuDQoNCg==


From nobody Fri Jul 10 08:06:51 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6EF1A9166; Fri, 10 Jul 2015 07:51:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.011
X-Spam-Level: 
X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 dwO0uisXErMv; Fri, 10 Jul 2015 07:51:16 -0700 (PDT)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3470F1A9151; Fri, 10 Jul 2015 07:51:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1436539876; x=1468075876; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=J/07/dQSuzIvw/3hgu2Ki3/bWV30PYxJPs8gGzuxeUM=; b=StO3SSgf1pkxpMeE2xQwXLaWFT2KzG5U5JlpoUV+9j8eHDa4umCdYLUU ux5yFeYgpk+Li/MR/eq3D/cShKEh+zZwfzAKgIyjUIlZ0QZMPiF4zT0sR osMTqXpODUSPAPWtigH2L73l6xQhlv8TVlACeSQ+JnlUA3DjlUK+XT1Wm A=;
X-IronPort-AV: E=McAfee;i="5700,7163,7857"; a="127223994"
Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by wolverine01.qualcomm.com with ESMTP; 10 Jul 2015 07:51:15 -0700
X-IronPort-AV: E=Sophos;i="5.15,447,1432623600"; d="scan'208";a="32960866"
Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 10 Jul 2015 07:51:14 -0700
Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 10 Jul 2015 07:51:13 -0700
Message-ID: 
In-Reply-To: 
References:   
X-Mailer: Eudora for Mac OS X
Date: Fri, 10 Jul 2015 07:51:06 -0700
To: Bernard Aboba , Henning Schulzrinne , Brian Rosen 
From: Randall Gellens 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Originating-IP: [10.80.80.8]
X-ClientProxiedBy: NASANEXM01B.na.qualcomm.com (10.85.0.82) To nasanexm02f.na.qualcomm.com (10.85.0.87)
Archived-At: 
X-Mailman-Approved-At: Fri, 10 Jul 2015 08:06:49 -0700
Cc: "slim@ietf.org" , ECRIT , Ban Al-Bakri , Gunnar Hellstrom , Barry Leiba , Brian Rosen , Randall Gellens , Hannes Tschofenig 
Subject: Re: [Slim] Time in Prague to discuss SLIM real-time draft
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jul 2015 14:51:17 -0000

Would the first afternoon session (starts at 1:00) on Monday work?

At 6:09 AM -0700 7/10/15, Bernard Aboba wrote:

>  I will be in Prague from Saturday through Friday. I cannot do 
> Monday lunch but other days are OK.
>
>
>  On Jul 9, 2015, at 7:26 PM, Henning Schulzrinne 
> <hgs@cs.columbia.edu> wrote:
>
>>  I'm in Prague Sunday afternoon through Thursday morning, and 
>> fairly flexible. Thanks for organizing!
>>
>>  On Wed, Jul 8, 2015 at 1:30 PM, Randall Gellens 
>> <randy@qti.qualcomm.com> wrote:
>>
>>  I'd like to set a time to meet in Prague so that Bernard, Brian, 
>> myself, and anyone else interested can talk in depth about the 
>> SLIM real-time draft.  Would Monday lunch work?  If not, please 
>> suggest some alternate times.
>>
>>  --
>>  Randall Gellens
>>  Opinions are personal;    facts are suspect;    I speak for myself only
>>  -------------- Randomly selected tag: ---------------
>>  You never finish a program, you just stop working on it.



-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Howe's Law:
    Everyone has a scheme that will not work.


From nobody Fri Jul 10 08:12:35 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67B3B1A9240; Fri, 10 Jul 2015 08:12:31 -0700 (PDT)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -7.011
X-Spam-Level: 
X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 Ub3WpNw52-su; Fri, 10 Jul 2015 08:12:29 -0700 (PDT)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 908501A923E; Fri, 10 Jul 2015 08:12:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1436541149; x=1468077149; h=message-id:in-reply-to:references:date:to:from:subject: cc; bh=aFqaMUCqwcQBWGUeyN6Xw+/6MHhFb8xv7XFW2mUK6mA=; b=l6HwZlBYzX5o/bcEsHuvY4/JJTx1eCCLmm4XpXhgAQBoul236siEhuCm bh99LKSn972raUWKVhFAKEyhhqhNoESYThJck5G52QP8SyDrBl1SdyBaI KbJIFJx4icaPTU5TLWPCfhB1qKwk/Qi/T7SR6/uKLOg8EC7eoXvX/F6cZ Q=;
X-IronPort-AV: E=McAfee;i="5700,7163,7857"; a="93512995"
Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Jul 2015 08:12:29 -0700
X-IronPort-AV: E=Sophos;i="5.15,447,1432623600"; d="scan'208";a="932479624"
Received: from plus.qualcomm.com ([10.52.255.8]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Jul 2015 08:11:48 -0700
Received: from Ironmsg04-L.qualcomm.com (ironmsg04-L.qualcomm.com [172.30.48.19]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id t6AFBkih030598; Fri, 10 Jul 2015 08:11:47 -0700
X-IronPort-AV: E=Sophos;i="5.15,447,1432623600"; d="scan'208";a="932479000"
X-ojodefuego: yes
Received: from unknown (HELO [99.111.97.136]) ([10.64.162.243]) by Ironmsg04-L.qualcomm.com with ESMTP; 10 Jul 2015 08:09:00 -0700
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References:     
X-Mailer: Eudora for Mac OS X
Date: Fri, 10 Jul 2015 08:08:59 -0700
To: "Rosen, Brian" , Bernard Aboba , Henning Schulzrinne 
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Cc: "slim@ietf.org" , ECRIT , Ban Al-Bakri , Gunnar Hellstrom , Barry Leiba , Hannes Tschofenig 
Subject: Re: [Slim] Time in Prague to discuss SLIM real-time draft
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jul 2015 15:12:31 -0000

Tuesday lunch is the email work.  If the others can make Monday first 
afternoon session, let's do that.

At 2:52 PM +0000 7/10/15, Brian Rosen wrote:

>  I'd like to go to clue, but I can skip it.  Tuesday lunch would work.
>
>  On 7/10/15, 10:51 AM, "Randall Gellens"  wrote:
>
>>Would the first afternoon session (starts at 1:00) on Monday work?
>>
>>At 6:09 AM -0700 7/10/15, Bernard Aboba wrote:
>>
>>>   I will be in Prague from Saturday through Friday. I cannot do
>>>  Monday lunch but other days are OK.
>>>
>>>
>>>   On Jul 9, 2015, at 7:26 PM, Henning Schulzrinne
>>>  <hgs@cs.columbia.edu> wrote:
>>>
>>>>   I'm in Prague Sunday afternoon through Thursday morning, and
>>>>  fairly flexible. Thanks for organizing!
>>>>
>>>>   On Wed, Jul 8, 2015 at 1:30 PM, Randall Gellens
>>>>  <randy@qti.qualcomm.com> wrote:
>>>>
>>>>   I'd like to set a time to meet in Prague so that Bernard, Brian,
>>>>  myself, and anyone else interested can talk in depth about the
>>>>  SLIM real-time draft.  Would Monday lunch work?  If not, please
>>>>  suggest some alternate times.
>>>>
>>>>   --
>>>>   Randall Gellens
>>>>   Opinions are personal;    facts are suspect;    I speak for myself
>>>>only
>>>>   -------------- Randomly selected tag: ---------------
>>>>   You never finish a program, you just stop working on it.
>>
>>
>>
>>--
>>Randall Gellens
>>Opinions are personal;    facts are suspect;    I speak for myself only
>>-------------- Randomly selected tag: ---------------
>>Howe's Law:
>>     Everyone has a scheme that will not work.
>
>  _______________________________________________
>  SLIM mailing list
>  SLIM@ietf.org
>  https://www.ietf.org/mailman/listinfo/slim



-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
A bird in the hand is safer than one overhead.


From nobody Fri Jul 10 08:12:59 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688271A9240; Fri, 10 Jul 2015 08:12:57 -0700 (PDT)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -7.011
X-Spam-Level: 
X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 Q-KQqpq8EqMg; Fri, 10 Jul 2015 08:12:56 -0700 (PDT)
Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E23951A923E; Fri, 10 Jul 2015 08:12:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1436541176; x=1468077176; h=message-id:in-reply-to:references:date:to:from:subject: cc; bh=vPaw4lTJiH0V0IiKSOBqnd38p4BHOZt8ct5JM2YR040=; b=pr+eF14j5Kl3fkjLuj0X/3WYd6sylHyFf4tQvEz+Uj5h0OlIQ1YO06sB 7XCtJXD11TWxfY/hxlLwQRltEb7JYNElGo9gmr643GCwRBrfC4qbL4VJ1 ViqKYZs4T6MQnacTYetpk93TdR6WOcNvoiCa8w5xmzRY8ZqMf5s5Mu3LU Q=;
X-IronPort-AV: E=McAfee;i="5700,7163,7857"; a="92441827"
Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Jul 2015 08:12:56 -0700
X-IronPort-AV: E=Sophos;i="5.15,447,1432623600"; d="scan'208";a="958148955"
Received: from plus.qualcomm.com ([10.52.255.8]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Jul 2015 08:12:55 -0700
Received: from Ironmsg03-R.qualcomm.com (ironmsg03-R.qualcomm.com [172.30.46.17]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id t6AFCsgN030674; Fri, 10 Jul 2015 08:12:54 -0700
X-IronPort-AV: E=Sophos;i="5.15,447,1432623600"; d="scan'208";a="958148928"
X-ojodefuego: yes
Received: from unknown (HELO [99.111.97.136]) ([10.64.162.243]) by Ironmsg03-R.qualcomm.com with ESMTP; 10 Jul 2015 08:12:53 -0700
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References:     
X-Mailer: Eudora for Mac OS X
Date: Fri, 10 Jul 2015 08:08:59 -0700
To: "Rosen, Brian" , Bernard Aboba , Henning Schulzrinne 
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Cc: "slim@ietf.org" , ECRIT , Ban Al-Bakri , Gunnar Hellstrom , Barry Leiba , Hannes Tschofenig 
Subject: Re: [Slim] Time in Prague to discuss SLIM real-time draft
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jul 2015 15:12:57 -0000

Tuesday lunch is the email work.  If the others can make Monday first 
afternoon session, let's do that.

At 2:52 PM +0000 7/10/15, Brian Rosen wrote:

>  I'd like to go to clue, but I can skip it.  Tuesday lunch would work.
>
>  On 7/10/15, 10:51 AM, "Randall Gellens"  wrote:
>
>>Would the first afternoon session (starts at 1:00) on Monday work?
>>
>>At 6:09 AM -0700 7/10/15, Bernard Aboba wrote:
>>
>>>   I will be in Prague from Saturday through Friday. I cannot do
>>>  Monday lunch but other days are OK.
>>>
>>>
>>>   On Jul 9, 2015, at 7:26 PM, Henning Schulzrinne
>>>  <hgs@cs.columbia.edu> wrote:
>>>
>>>>   I'm in Prague Sunday afternoon through Thursday morning, and
>>>>  fairly flexible. Thanks for organizing!
>>>>
>>>>   On Wed, Jul 8, 2015 at 1:30 PM, Randall Gellens
>>>>  <randy@qti.qualcomm.com> wrote:
>>>>
>>>>   I'd like to set a time to meet in Prague so that Bernard, Brian,
>>>>  myself, and anyone else interested can talk in depth about the
>>>>  SLIM real-time draft.  Would Monday lunch work?  If not, please
>>>>  suggest some alternate times.
>>>>
>>>>   --
>>>>   Randall Gellens
>>>>   Opinions are personal;    facts are suspect;    I speak for myself
>>>>only
>>>>   -------------- Randomly selected tag: ---------------
>>>>   You never finish a program, you just stop working on it.
>>
>>
>>
>>--
>>Randall Gellens
>>Opinions are personal;    facts are suspect;    I speak for myself only
>>-------------- Randomly selected tag: ---------------
>>Howe's Law:
>>     Everyone has a scheme that will not work.
>
>  _______________________________________________
>  SLIM mailing list
>  SLIM@ietf.org
>  https://www.ietf.org/mailman/listinfo/slim



-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Afternoon: That part of the day we spend worrying about how we wasted
the morning.


From nobody Fri Jul 10 08:41:26 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB5B1B2A2D for ; Fri, 10 Jul 2015 08:41:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 XF8zpFlZFUAB for ; Fri, 10 Jul 2015 08:41:24 -0700 (PDT)
Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A9DF1B2A0B for ; Fri, 10 Jul 2015 08:41:19 -0700 (PDT)
Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-11v.sys.comcast.net with comcast id qfg71q0092N9P4d01fhJXq; Fri, 10 Jul 2015 15:41:18 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-13v.sys.comcast.net with comcast id qfhJ1q00C3Ge9ey01fhJir; Fri, 10 Jul 2015 15:41:18 +0000
Message-ID: <559FE79D.2070603@alum.mit.edu>
Date: Fri, 10 Jul 2015 11:41:17 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: slim@ietf.org
References:    
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1436542878; bh=Dd5eU8a0M3dBknOK3t6ZH8zePll4taCnemIAgnhaXeA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DmkYL2+a7DgM61NBqHv5hA1wHVU340YMzyTpMT9TZw8Vb8bD01hXJxF6pY9uMsK+w 8q64/Az5M1iEOmH9eWUt3tpGppNM6IGplPF7Lsxbi8J7Z7b/vNfxSfDVwUyaBy7R+y hIpHvXD46supzjfEBXKeGmca9dzHn5YvXnwkPsBOO641NKIvhHdog50KZRm2SbsnID 2zqcSpCCBiXlQEb3XjHPDXK9il2ZfF1iWU//no72/B1cab/HtQZHIXz6th828cluo9 qO50fH/LZffs5t4HjmPj415EBDG1Q7DIoK8t2zMZk7wfGG5zNNuFVQvyYh+UjJBOWp N0Uml4cquaZ+w==
Archived-At: 
Subject: Re: [Slim] Time in Prague to discuss SLIM real-time draft
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jul 2015 15:41:25 -0000

On 7/10/15 10:51 AM, Randall Gellens wrote:
> Would the first afternoon session (starts at 1:00) on Monday work?

I'll be attending CLUE then, remotely.

> At 6:09 AM -0700 7/10/15, Bernard Aboba wrote:
>
>>  I will be in Prague from Saturday through Friday. I cannot do Monday
>> lunch but other days are OK.
>>
>>
>>  On Jul 9, 2015, at 7:26 PM, Henning Schulzrinne
>> <hgs@cs.columbia.edu> wrote:
>>
>>>  I'm in Prague Sunday afternoon through Thursday morning, and fairly
>>> flexible. Thanks for organizing!
>>>
>>>  On Wed, Jul 8, 2015 at 1:30 PM, Randall Gellens
>>> <randy@qti.qualcomm.com> wrote:
>>>
>>>  I'd like to set a time to meet in Prague so that Bernard, Brian,
>>> myself, and anyone else interested can talk in depth about the SLIM
>>> real-time draft.  Would Monday lunch work?  If not, please suggest
>>> some alternate times.
>>>
>>>  --
>>>  Randall Gellens
>>>  Opinions are personal;    facts are suspect;    I speak for myself only
>>>  -------------- Randomly selected tag: ---------------
>>>  You never finish a program, you just stop working on it.
>
>
>


From nobody Fri Jul 10 10:01:20 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 068C31A92F0; Fri, 10 Jul 2015 08:10:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 KpCOM74k_cR1; Fri, 10 Jul 2015 08:10:14 -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 29C951AD37B; Fri, 10 Jul 2015 08:10:14 -0700 (PDT)
Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t6AF9mLG016326 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 10 Jul 2015 10:09:59 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23]
From: "Ben Campbell" 
To: "Randall Gellens" 
Date: Fri, 10 Jul 2015 10:09:48 -0500
Message-ID: <6A6DE46B-F440-4CE6-8ACA-49CC7ECCFBDF@nostrum.com>
In-Reply-To: 
References:    
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.1r5084)
Archived-At: 
X-Mailman-Approved-At: Fri, 10 Jul 2015 10:01:18 -0700
Cc: "slim@ietf.org" , ECRIT , Ban Al-Bakri , Bernard Aboba , Gunnar Hellstrom , Barry Leiba , Brian Rosen , Hannes Tschofenig , Henning Schulzrinne 
Subject: Re: [Slim] Time in Prague to discuss SLIM real-time draft
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jul 2015 15:10:16 -0000

I personally need to be in clue at 1pm Monday. Of the other times 
mentioned, I think I could do Tuesday lunch.

With this many people, perhaps a doodle would be helpful?

On 10 Jul 2015, at 9:51, Randall Gellens wrote:

> Would the first afternoon session (starts at 1:00) on Monday work?
>
> At 6:09 AM -0700 7/10/15, Bernard Aboba wrote:
>
>> I will be in Prague from Saturday through Friday. I cannot do Monday 
>> lunch but other days are OK.
>>
>>
>> On Jul 9, 2015, at 7:26 PM, Henning Schulzrinne 
>> <hgs@cs.columbia.edu> wrote:
>>
>>> I'm in Prague Sunday afternoon through Thursday morning, and fairly 
>>> flexible. Thanks for organizing!
>>>
>>> On Wed, Jul 8, 2015 at 1:30 PM, Randall Gellens 
>>> <randy@qti.qualcomm.com> wrote:
>>>
>>> I'd like to set a time to meet in Prague so that Bernard, Brian, 
>>> myself, and anyone else interested can talk in depth about the SLIM 
>>> real-time draft.  Would Monday lunch work?  If not, please suggest 
>>> some alternate times.
>>>
>>> --
>>> Randall Gellens
>>> Opinions are personal;    facts are suspect;    I speak for myself 
>>> only
>>> -------------- Randomly selected tag: ---------------
>>> You never finish a program, you just stop working on it.
>
>
>
> -- 
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for myself 
> only
> -------------- Randomly selected tag: ---------------
> Howe's Law:
> Everyone has a scheme that will not work.
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim


From nobody Fri Jul 10 11:55:09 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F56F1A1AD3; Fri, 10 Jul 2015 11:39:51 -0700 (PDT)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -7.011
X-Spam-Level: 
X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 bBK1FNM5Hg9p; Fri, 10 Jul 2015 11:39:50 -0700 (PDT)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71E2B1A1ACC; Fri, 10 Jul 2015 11:39:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1436553590; x=1468089590; h=message-id:in-reply-to:references:date:to:from:subject: cc; bh=7a9Y3cMVo75dGCOuR+9YX9o7gJeZSY7jBVIInTZnH8I=; b=K190yXKS6xxuCubTPYhv9Cldu5yV4o3ovzwirLw383DcoJUU24xH01oY dV2tH8olqlCxwrR+GcoCGsHdMiYjM8jJuJLGZWhctTLpNk0woN06O0TV/ 6/Vi2p+8FaF3PSDMNPIqjkh2CIrFP8Hm3W26nytK5Lfa2k7GyGlOk4TGN Y=;
X-IronPort-AV: E=McAfee;i="5700,7163,7858"; a="127248699"
Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Jul 2015 11:39:43 -0700
X-IronPort-AV: E=Sophos;i="5.15,448,1432623600"; d="scan'208";a="932575150"
Received: from plus.qualcomm.com ([10.52.255.8]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Jul 2015 11:39:42 -0700
Received: from Ironmsg03-L.qualcomm.com (ironmsg03-L.qualcomm.com [172.30.48.18]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id t6AIdfAJ019723; Fri, 10 Jul 2015 11:39:42 -0700
X-IronPort-AV: E=Sophos;i="5.15,448,1432623600"; d="scan'208";a="957935261"
X-ojodefuego: yes
Received: from unknown (HELO [99.111.97.136]) ([10.64.162.243]) by Ironmsg03-L.qualcomm.com with ESMTP; 10 Jul 2015 11:39:39 -0700
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <6A6DE46B-F440-4CE6-8ACA-49CC7ECCFBDF@nostrum.com> 
References:     <6A6DE46B-F440-4CE6-8ACA-49CC7ECCFBDF@nostrum.com>    
X-Mailer: Eudora for Mac OS X
X-Priority: 2 (High)
Date: Fri, 10 Jul 2015 11:39:38 -0700
To: Bernard Aboba , Brian Rosen , Hannes Tschofenig , Henning Schulzrinne , Nik Tomkinson , "Ben Campbell" 
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
X-Mailman-Approved-At: Fri, 10 Jul 2015 11:55:09 -0700
Cc: slim@ietf.org, Nathaniel Borenstein , ECRIT , Ban Al-Bakri , Chris Newman , Gunnar Hellstrom , Paul Kyzivat , Barry Leiba 
Subject: [Slim] Tuesday Lunch in Prague to discuss SLIM real-time & email (both)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jul 2015 18:39:51 -0000

It seems that Tuesday lunch works for everyone interested in the SLIM 
real-time and email work, so let's settle on that for both.  Please 
confirm your attendance to me today if possible, and if we have 
enough I will reserve a room at a restaurant in the hotel, so we can 
talk and be heard.  If we can meet pretty quickly after the morning 
session ends, we can have time for both topics.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
I don't want to achieve immortality through my work....
I want to achieve immortality by not dying.-
                                          --Woody Allen


From nobody Fri Jul 10 14:52:55 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCB11B2D0A for ; Fri, 10 Jul 2015 14:52:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level: 
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 2evJb8EJakJU for ; Fri, 10 Jul 2015 14:52:53 -0700 (PDT)
Received: from bin-vsp-out-04.atm.binero.net (vsp-authed01.binero.net [195.74.38.224]) (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 AB2191B2D11 for ; Fri, 10 Jul 2015 14:52:52 -0700 (PDT)
X-Halon-ID: ffc53ca5-274d-11e5-b1e0-005056917c0c
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.42] (unknown [87.96.160.92]) by bin-vsp-out-04.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Fri, 10 Jul 2015 23:52:46 +0200 (CEST)
Message-ID: <55A03EAF.6040504@omnitor.se>
Date: Fri, 10 Jul 2015 23:52:47 +0200
From: =?windows-1252?Q?Gunnar_Hellstr=F6m?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Randall Gellens 
References:     <6A6DE46B-F440-4CE6-8ACA-49CC7ECCFBDF@nostrum.com>     
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "slim@ietf.org" , ECRIT 
Subject: Re: [Slim] Tuesday Lunch in Prague to discuss SLIM real-time & email (both)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jul 2015 21:52:54 -0000

Yes, I want to participate remotely, if you manage to arrange for 
calling in.

/Gunnar

Randall Gellens skrev den 2015-07-10 20:39:
> It seems that Tuesday lunch works for everyone interested in the SLIM
> real-time and email work, so let's settle on that for both.  Please
> confirm your attendance to me today if possible, and if we have enough
> I will reserve a room at a restaurant in the hotel, so we can talk and
> be heard.  If we can meet pretty quickly after the morning session
> ends, we can have time for both topics.
>

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


From nobody Sat Jul 11 01:53:24 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFB101A8856 for ; Sat, 11 Jul 2015 01:53:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.298
X-Spam-Level: 
X-Spam-Status: No, score=0.298 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 rvjf0YFP-f7u for ; Sat, 11 Jul 2015 01:53:20 -0700 (PDT)
Received: from bin-vsp-out-03.atm.binero.net (vsp-unauthed01.binero.net [195.74.38.225]) (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 0EEE91A8853 for ; Sat, 11 Jul 2015 01:53:19 -0700 (PDT)
X-Halon-ID: 41ec2de7-27aa-11e5-8f61-0050569116f7
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.42] (unknown [87.96.160.92]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Sat, 11 Jul 2015 10:53:10 +0200 (CEST)
Message-ID: <55A0D978.4000400@omnitor.se>
Date: Sat, 11 Jul 2015 10:53:12 +0200
From: =?windows-1252?Q?Gunnar_Hellstr=F6m?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: "slim@ietf.org" , Randall Gellens 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: [Slim] Requirements on a system for indication of preferences and capabilities of media, modalities and languages in real-time sessions
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Jul 2015 08:53:22 -0000

I suggest that we insert a requirements chapter in the real-time 
humintlang draft.

Here is an initial proposal.
My intention is that these requirements summarize what would be needed 
to cover both the needs of traditional relay service users and users of 
different languages. If that is seen to cover too much, I can see a need 
to split the work in a language part and a relay service invocation part.

I also see a need to specify a BCP for the procedures for assisting 
(e.g. =relay) service invocation so that a hint to another party to 
invoke a specific assisting service has an opportunity to be done in an 
interoperable way.

But this is how I see the requirements for the humintlang specification. 
It would be good to get initial reactions until or in the meeting on 
Tuesday.

X. Requirements.
------------------------
The system for indication of preferences and capabilities shall meet the 
following requirements:

It shall enable negotiation of media, modalities and languages for a SIP 
session.

It shall be possible to use it during initiation and modification of a 
session.

The system shall consist of a set of indications and usage rules 
specified in this specification and other specifications.

The system shall enable a caller to indicate the media, modalities, 
languages and assisting services that the caller prefers to use during a 
real-time session that is about to be established or modified.

Entities involved in selecting callees and callees shall be enabled to 
view the caller preferences in order to select a callee of many, or 
adjust the set of media, modalities, languages and services provided in 
the session.

The caller shall be provided with indication of the resulting media, 
modalities, languages and services enabled during the session.

X.1 General
------------
It shall be possible to express capabilities and preferences with its 
transmission direction, for transmission or reception or bidirectional 
from the viewpoint of the entity sending the indication.

The indications shall be suitable for setting in personal profiles, in 
service profiles, or in terminal settings, and possible to adjust at 
session initiation time.

It shall be possible to present the outcome of exchange of the 
indications to users in the session.

X.2 Media indications.
-------------------------

It shall be possible to use the indications for audio, video and 
real-time text media.  ( and text messages????)

X.3 Modality indications.
----------------------------
It shall be possible to use indications for speech and hearing in audio 
media.

It shall be possible to use indications for transmitting text and 
receiving text in real-time text media.

( ???  It shall be possible to use indications for transmitting text 
messages and receiving text messages in text messaging media. ???)

It shall be possible to use indications for expressing sign language and 
perceiving sign language in video media.

It shall be possible to use indications for showing a speaker and for 
seeing a speaker in video media.

X.4 Service indications.
--------------------------
It shall be possible to use indications of type of and address of and 
state of invocation of an assisting service available for supporting the 
communication.

X.5 Language indications.
-----------------------------
It shall be possible to indicate ability to express language in a number 
of languages from the ones listed in the language tags of RFC 5646.

It shall be possible to indicate ability to perceive language in a 
number of languages from the ones listed in the language tags of RFC 5646.

The language indication shall be associated with a specific media, 
modality and direction.

It shall be possible to indicate ability to express language in an 
unspecified language, meaning a default for a region in the associated 
modality.

It shall be possible to indicate ability to perceive language in an 
unspecified language, meaning a default for a region in the associated 
modality.

It shall be possible to indicate use of media without any specific 
intention to use the medium for language communication.

X.6 Indication of level of preference or capability
--------------------------------------------------------
It shall be possible to indicate an absolute level of preference or 
capability to use a language, modality, media and direction combination 
with a coarse grading.
For preference, the grading shall at least be able to indicate strong 
preference vs can use vs possible fall back usage.
For capability, the grading shall at least be able to indicate good 
capability vs some capability vs limited capability.
Capability and preference shall use the same coding, the difference is 
only in the role of the entity providing the indication. Call parties 
express preferences, service providers express capabilities.

More than one direction/media/modality/language preference or capability 
can be expressed per level.

It shall be possible for a caller to express if the session should be 
set up or not if no matching direction/media/modality/language 
indications are found.

X.7 Type and quality indications
-------------------------------------
It shall be possible to indicate preference and capability of different 
types of real-time text production: conversational type versus 
captioning type. Conversational type is generated by the transmitting 
party in the session, or by a communications agent with moderate 
requirements on delay. Captioning type is generated as captions to 
another modality in the same session with low delay from the expression 
in the other modality. The original modality for captions can be speech 
or sign language.

It shall be possible to indicate with language indications if it is 
original or interpreted or artificially created contents.

In order to enable communication with persons who have speech that is 
weak or hard to understand, the following quality indications can be used:
     -It shall be possible to indicate that the quality of the expressed 
speech makes it hard to understand.
     -It shall be possible to indicate a capability to undertand speech 
that is weak or hard to understand.

In order to enable communication with persons who need cognitive support 
in the form of reminders or notetaking, the following quality 
indications can be used:
     -It shall be possible to indicate need of reminders or notetaking 
during a session.
     -It shall be possible to indicate a capability to provide reminders 
or take notes during a session.


X.8 Details of service indications
----------------------------------------
The user expressing the indications may be a frequent user of an 
assisting service, that supports the commuication in some often 
occurring need for modality or language translation. By indicating this 
service, a receiver of the indication can judge if invocation of that 
service will support matching of preferences and capabilities. Common 
assiting service types are relay service and language translation service.

The services are specified with service type, service address, 
invocation state and languages.
Possible service types are:
     Spoken language translation service translating between different 
spoken languages.
     Video relay service translating between sign language in video and 
speech in audio.
     Text relay service translating between text in real-time text and 
speech in audio.  ( even between text messages and audio exist )
     Captioned telephony adding real-time text in one direction to speech.
     Speech-to-speech adding clear speech when needed to speech that is 
weak or hard to understand
     Cognitive support adding reminders or memory notes to speech 
conversation ususlly in combination with the speech-to-speech service.

Service address shall be a URI where the service can be reached with one 
session for provision of the service within the media of that session.
(note that this is different from how most current relay services today 
work. They often have two call legs, one with an audio call and one with 
a multimedia call. )

Invocation state shall indicate if the service is already included in 
the call, and if so, the media/modality/language indications show the 
joint capabilities.
Invocation state can also contain a request to the other party to invoke 
the service if needed to complement the capabilities to achieve a 
functioning communication. This indication can be provided either by the 
offering or answering party.

Languages shall be media/modality/language indications in pairs showing 
the capabilities of the service.


X.9 Use in session establishment and modification
-------------------------------------------------------------
The indications shall be included in session offer / answer exchange.

Already specified ways to express media/modality/language shall be 
possible to use to the extent that they are usable.
That includes media and language tags on SIP level and media 
specifications and language tags on SDP level. For cases when these 
existing means imply limitations, these limitations shall be explained.

The method for identification of language preferences and capabilities 
in this specification is intended mainly for rapid ad-hoc session 
establishment and not intended to have the same ambitions as CLUE has 
for planned telepresence sessions.

The indications included in the offer shall represent the preferences 
and capabilities of the offering party.

The indications included in the answer shall represent the preferences 
and capabilities of the answering party actually planned to be used in 
the session.



X.10 Security
-----------
It shall be possible to hide the preference and capability indications 
from unintended inspection.

X.11 Not covered characteristics
------------------------------------
Many aspects of a conversation are not covered by the indications 
specified here.
Examples are:
     Gender
     Expertize area



/Gunnar

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


From nobody Sat Jul 11 08:23:25 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 554621A1A11 for ; Fri, 10 Jul 2015 20:52:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.935
X-Spam-Level: 
X-Spam-Status: No, score=-0.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, SPF_SOFTFAIL=0.665] autolearn=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 AUOcfYMxfWtA for ; Fri, 10 Jul 2015 20:52:03 -0700 (PDT)
Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:160]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 441CA1A016A for ; Fri, 10 Jul 2015 20:52:01 -0700 (PDT)
Received: from resomta-po-09v.sys.comcast.net ([96.114.154.233]) by resqmta-po-01v.sys.comcast.net with comcast id qrru1q00152QWKC01rs1NX; Sat, 11 Jul 2015 03:52:01 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-09v.sys.comcast.net with comcast id qrrz1q0023Ge9ey01rrzyH; Sat, 11 Jul 2015 03:52:01 +0000
Message-ID: <55A092DE.3000706@alum.mit.edu>
Date: Fri, 10 Jul 2015 23:51:58 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: =?windows-1252?Q?Gunnar_Hellstr=F6m?= ,  Randall Gellens , Bernard Aboba ,  Brian Rosen , Hannes Tschofenig ,  Henning Schulzrinne , Nik Tomkinson ,  Ben Campbell 
References:     <6A6DE46B-F440-4CE6-8ACA-49CC7ECCFBDF@nostrum.com>      <55A03DAF.5000505@omnitor.se>
In-Reply-To: <55A03DAF.5000505@omnitor.se>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1436586721; bh=Sj/5Arv1rfpvhiDJZFdv21Bjd2Ub7QfdWfwfeNaCYHI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=TVWZmrRPMYV3U+Npz/CYTp4+zOM6kL4gOYJz6SLIt/xo0XSqQ1V/zxI9F0J0Eyckn 61uf/V3jT430SMS7nRSqWdav5b+rg8v0nYiukiFOa4SdFZYCdYnM/1/rW9QnvPGM7Y epDSLLEY2lxu+/gaz0nLOBs+YYOd/7ChclO3hq61TDIQi/lTT7DiK/vGdw6bZm+kdE Ctu8GzUMXHSrjVLCiRCBwZWThwwx7gYqLD9+IVLZ2fSLzW5iSnFi1eoGSmXfGy3oHO 7aYUA0+zRvIoWQL2P3rIv7sktmr8rlIHShs3ITgsF13aLvwaiJq3efXtPj5Ea1+83e +gfMuKzLH2ERA==
Archived-At: 
X-Mailman-Approved-At: Sat, 11 Jul 2015 08:23:23 -0700
Cc: slim@ietf.org, Nathaniel Borenstein , ECRIT , Ban Al-Bakri , Chris Newman , Barry Leiba 
Subject: Re: [Slim] Tuesday Lunch in Prague to discuss SLIM real-time & email (both)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Jul 2015 03:52:05 -0000

On 7/10/15 5:48 PM, Gunnar Hellström wrote:
> Yes, I want to participate remotely, if you manage to arrange for
> calling in.

I'd like to call in, but with a lunch meeting that may not be very 
feasible. Also, it is 6am for me. So I may just wait to hear how it 
went. But please let me know if there is a way to call in.

	Thanks,
	Paul

> /Gunnar
>
> Randall Gellens skrev den 2015-07-10 20:39:
>> It seems that Tuesday lunch works for everyone interested in the SLIM
>> real-time and email work, so let's settle on that for both.  Please
>> confirm your attendance to me today if possible, and if we have enough
>> I will reserve a room at a restaurant in the hotel, so we can talk and
>> be heard.  If we can meet pretty quickly after the morning session
>> ends, we can have time for both topics.
>>
>


From nobody Sat Jul 11 11:51:09 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC871AC3AD for ; Sat, 11 Jul 2015 11:51:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.688
X-Spam-Level: *
X-Spam-Status: No, score=1.688 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=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 G82OY4eGfgMP for ; Sat, 11 Jul 2015 11:51:07 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 389341AC39F for ; Sat, 11 Jul 2015 11:51:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default;  h=To:References:Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=+pv8/1wIQNcPhmSm/EKjj4Y4J3buyoHc96yLv2rajmw=;  b=Qcup62togZMVecBSYa3y3VzVpKh0VisSdVeFuRJYADHJNNxy5y+B4wDcQugl8vKPuo1gylDPZVdP9s3+M0rG3SYrBfF+gtfqXpgcfrNAoZhvMnvPoCKyIst+0oH4ngmURhoh7sAKAEsFbHGToC1g3ga2tGtNjujmyCGib+k/I9M=;
Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:50439 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZDzrd-0004Kh-TX for slim@ietf.org; Sat, 11 Jul 2015 11:51:06 -0700
Content-Type: multipart/signed; boundary="Apple-Mail=_FC27C222-9D62-41AA-8B2C-653D201D9FD0"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
X-Pgp-Agent: GPGMail 2.5
From: Eric Burger 
In-Reply-To: <55A092DE.3000706@alum.mit.edu>
Date: Sat, 11 Jul 2015 14:51:04 -0400
Message-Id: <9EDFD79F-5723-44BF-BCFE-F4C448FC102D@standardstrack.com>
References:     <6A6DE46B-F440-4CE6-8ACA-49CC7ECCFBDF@nostrum.com>      <55A03DAF.5000505@omnitor.se> <55A092DE.3000706@alum.mit.edu>
To: slim@ietf.org
X-Mailer: Apple Mail (2.2102)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.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: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
Archived-At: 
Subject: Re: [Slim] Tuesday Lunch in Prague to discuss SLIM real-time & email (both)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Jul 2015 18:51:08 -0000

--Apple-Mail=_FC27C222-9D62-41AA-8B2C-653D201D9FD0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Ditto. I=92m not likely to be on the call as I was using =91lunch=92 =
time Tuesday to fly to New York. Any other lunchtime date (I know, =
Monday does not work for others) would be better for me.

> On Jul 10, 2015, at 11:51 PM, Paul Kyzivat  =
wrote:
>=20
> On 7/10/15 5:48 PM, Gunnar Hellstr=F6m wrote:
>> Yes, I want to participate remotely, if you manage to arrange for
>> calling in.
>=20
> I'd like to call in, but with a lunch meeting that may not be very =
feasible. Also, it is 6am for me. So I may just wait to hear how it =
went. But please let me know if there is a way to call in.
>=20
> 	Thanks,
> 	Paul
>=20
>> /Gunnar
>>=20
>> Randall Gellens skrev den 2015-07-10 20:39:
>>> It seems that Tuesday lunch works for everyone interested in the =
SLIM
>>> real-time and email work, so let's settle on that for both.  Please
>>> confirm your attendance to me today if possible, and if we have =
enough
>>> I will reserve a room at a restaurant in the hotel, so we can talk =
and
>>> be heard.  If we can meet pretty quickly after the morning session
>>> ends, we can have time for both topics.
>>>=20
>>=20
>=20
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim


--Apple-Mail=_FC27C222-9D62-41AA-8B2C-653D201D9FD0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVoWWYAAoJEORoZaSQsc1IYqEP/iO1FU2x1gnHVyL3CafWH7A1
PWsk4zJz+2KHemu94kg4NddvlwyALm0IoHgHLdtj+0tShVBw5afHKFUdXvUIB8Rt
8fd2AvzpKsLUH7JlwMFAqUbUfCEjLKGqtj6LPzVY5dnbYaQ/t1QU5fHTeH5qtXZA
i56z8dvwx1I0k2bWsOtgRKo02RCeUlvCmAwxnrcCNoR8ufJ415TZZdQxXniM9eDy
Ppmsf+ep9lmoiKGBvLJeJCPaS0mJyLtVKzoR/BchtP+uad164I/juV6fAFC0J0je
Y/Zjks9S/gVkxbDXFp1eUE2+905L54FsWhX1QURW2l9yaI9yINa3xjo3qtoAPKFg
vBSW1YTAvYV91Z4jAoc5S7xymR2zCkFD62+Hcoav4E+XMKewNAsOoYo1YCNB/Fg9
Wh9YNwkl6ulcgYezt8mSk58eUbh7DBOQGXThi318IMtg7hjO1tUfcIb80i4RiCzc
sPd+MCJszA3CT+rPBQmlFRRcOmRBHkHlxcjEeEPDX+6gSdUGyp9KtoYiSIIg4Rvx
RfGh9Qcbq3tyu6VlOo/lRc6+k+mgwxBnSAZyaDXGkBdY0xYaAGagnlAA7uJbByHW
phmuuthUGJqfnLeMI/p1GJL2mVwchkVJUvQRFmkg0zmuOqlqTg7zUHwIR5RMVDBO
PV0tyBS9+aJ/5iDJCmGU
=7Rm2
-----END PGP SIGNATURE-----

--Apple-Mail=_FC27C222-9D62-41AA-8B2C-653D201D9FD0--


From nobody Sat Jul 11 14:22:10 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335241ACD0A for ; Sat, 11 Jul 2015 14:22:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.511
X-Spam-Level: 
X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 WvUfgEKKcRuC for ; Sat, 11 Jul 2015 14:22:07 -0700 (PDT)
Received: from alum-mailsec-scanner-4.mit.edu (alum-mailsec-scanner-4.mit.edu [18.7.68.15]) by ietfa.amsl.com (Postfix) with ESMTP id 2161E1ACCEA for ; Sat, 11 Jul 2015 14:22:05 -0700 (PDT)
X-AuditID: 1207440f-f79df6d000007c0f-de-55a188fdc14b
Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 8E.FC.31759.DF881A55; Sat, 11 Jul 2015 17:22:05 -0400 (EDT)
Received: from Paul-Kyzivats-MacBook-Pro.local (c-50-138-229-151.hsd1.ma.comcast.net [50.138.229.151]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id t6BLM4ld027342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sat, 11 Jul 2015 17:22:04 -0400
Message-ID: <55A188FA.3030408@alum.mit.edu>
Date: Sat, 11 Jul 2015 17:22:02 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: slim@ietf.org
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixO6iqPu3Y2GoQfd9NouZHzrZHBg9liz5 yRTAGMVtk5RYUhacmZ6nb5fAnbHoyBO2gre8FVsmfGduYPzF1cXIySEhYCLxesY6dghbTOLC vfVsXYxcHEIClxklOmd2M4IkhAR+M0m0r6sGsXkFtCW+PprBDGKzCKhKPFq+lQXEZhPQkphz 6D+YLSqQIvFsyW4miHpBiZMzn4DFRYDs7z0zwOLCAjYS919cYQWxmQXMJOZtfsgMYctLbH87 h3kCI+8sJO2zkJTNQlK2gJF5FaNcYk5prm5uYmZOcWqybnFyYl5eapGuiV5uZoleakrpJkZI OPHvYOxaL3OIUYCDUYmHd0bhglAh1sSy4srcQ4ySHExKoryVOQtDhfiS8lMqMxKLM+KLSnNS iw8xSnAwK4nwqtQA5XhTEiurUovyYVLSHCxK4rzqS9T9hATSE0tSs1NTC1KLYLIyHBxKErwz 24EaBYtS01Mr0jJzShDSTBycIMO5pESKU/NSUosSS0sy4kERFl8MjDGQFA/Q3k0g7bzFBYm5 QFGI1lOMxhxzJt1fy8Tx5eTDtUxCLHn5ealS4rz7QEoFQEozSvPgFsESyStGcaC/hXnvglTx AJMQ3LxXQKuYgFZFS88DWVWSiJCSamCc9f+i1Y+tHctei1pfKwmfsDJUKSSk7YAKv7qUUYzm RpldVxTEmcSMLx6Yw7Z+y0tbl2d++6cWr+X6m6DUsNUuxSj7/Aor9psvlh/bf/zM65BjE15w TF+9gsN1VsGffbrGznVPPn7bwzN/8zEd6dM93vYbDm3t3Kd2WdXYoV7zoNGDpO2th9YdUWIp zkg01GIuKk4EAEDlQZf/AgAA
Archived-At: 
Subject: [Slim] Correlating media streams / roles for media streams
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Jul 2015 21:22:09 -0000

I have a feeling there is still a missing part to this puzzle. I bring 
it up without having yet formed an opinion on how to solve it, or 
whether slim is the right place to do so.

In some cases there is a need to coordinate the content in multiple 
streams, in varying ways.

One case is already mentioned in the -negotiating- draft: when it is 
desired for the content of a video stream to represent the speaker in an 
audio stream.

Another one hasn't been discussed yet: it ought to be possible to 
initiate a session with a relay/translation service with the expectation 
that the service will relay/translate between two groups of streams, 
each group representing one party in a conversation. There are many 
variations on this. E.g.,

- two audio streams, each with a different natural language. The desire
   is for translation in both directions between them.

- one group has an audio stream with English, the other has audio with
   English and video with ASL. The desire is for translation in both
   directions between spoken English and ASL.

It *may* be that the desired relationship between the streams can be 
inferred from the media types, directionality, and humaninlang 
attributes. But I think this starts to become ambiguous in any but the 
most simple cases. For instance, in the ASL example above, which audio 
"belongs" to the video stream? And, should the audio be "passed through" 
with the translation mixed in, or not? As we add more modalities it will 
get more complex.

I think we could start by trying to define heuristics for figuring out 
what to do. Beyond that, we could come up with additional SDP syntax. Or 
perhaps an independent channel, such as used in CLUE, could be used.

	Thanks,
	Paul


From nobody Sun Jul 12 07:11:03 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D55F1ACECE for ; Sun, 12 Jul 2015 07:11:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.688
X-Spam-Level: *
X-Spam-Status: No, score=1.688 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=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 oaMFlowo4a_w for ; Sun, 12 Jul 2015 07:10:54 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DAB01ACECD for ; Sun, 12 Jul 2015 07:10:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default;  h=To:References:Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=mI+XFqQdmxmuuVAG576t07vLjEl+GP9f7ekDHsUEI/Q=;  b=Dp6QTcLvYzNHe4y/1LzmJyYxO33Aocekb/gIyGx0KKFJwJu6guGpoaVPTzX9NmKlL4d9nj5JuR5L/bawpnk79/b+YwAEg8zIDS7t6hzTZlkpQoeFpJUsG61OFe4A7+4MWXrxxlZcioa515/xe2zA9QD6I4bxLQC+eiUKzN1guyg=;
Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:64891 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZEHxy-0008H9-AX for slim@ietf.org; Sun, 12 Jul 2015 07:10:53 -0700
Content-Type: multipart/signed; boundary="Apple-Mail=_2F8FF229-D618-4294-9DDC-C43084CF6D52"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
X-Pgp-Agent: GPGMail 2.5
From: Eric Burger 
In-Reply-To: <55A188FA.3030408@alum.mit.edu>
Date: Sun, 12 Jul 2015 10:10:48 -0400
Message-Id: <83D4C689-2121-4007-A5E7-AC1398262191@standardstrack.com>
References: <55A188FA.3030408@alum.mit.edu>
To: slim@ietf.org
X-Mailer: Apple Mail (2.2102)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.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: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
Archived-At: 
Subject: Re: [Slim] Correlating media streams / roles for media streams
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 12 Jul 2015 14:11:01 -0000

--Apple-Mail=_2F8FF229-D618-4294-9DDC-C43084CF6D52
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I think this can be even more complex. Granted, my experience in =
simultaneous translation is 25 years old, but at the time, the European =
Commission had a rule that one could not have more than two serial =
simultaneous translations in a row. The constraint was providing =
simultaneous translations in (what today) is 24 languages, yet doing it =
with a finite number of interpreters. Scheduling was an =
=E2=80=98interesting=E2=80=99 task given the serial translation =
limitation.

I bring this up because one can envision someone from Malta visiting =
Latvia. Finding someone who speaks both Maltese and Latvian is unlikely, =
but finding one person who speaks one of Maltese and Italian or English, =
and someone who speaks one of Latvian and Italian or English is pretty =
good. If it is a bad day, you might be able to find someone who speaks =
Maltese and Arabic, someone who speaks Arabic and German, and someone =
who speaks German and Latvian.

I get the sense we are only looking at bilateral translations (e.g., =
English - ASL, Vietnamese - English, French - RTT, etc.). Given the =
likelihood of serial interpretations in language-dense regions of the =
world (Europe, India, and the US come immediately to mind), are we ready =
for it?

> On Jul 11, 2015, at 5:22 PM, Paul Kyzivat  =
wrote:
>=20
> I have a feeling there is still a missing part to this puzzle. I bring =
it up without having yet formed an opinion on how to solve it, or =
whether slim is the right place to do so.
>=20
> In some cases there is a need to coordinate the content in multiple =
streams, in varying ways.
>=20
> One case is already mentioned in the -negotiating- draft: when it is =
desired for the content of a video stream to represent the speaker in an =
audio stream.
>=20
> Another one hasn't been discussed yet: it ought to be possible to =
initiate a session with a relay/translation service with the expectation =
that the service will relay/translate between two groups of streams, =
each group representing one party in a conversation. There are many =
variations on this. E.g.,
>=20
> - two audio streams, each with a different natural language. The =
desire
>  is for translation in both directions between them.
>=20
> - one group has an audio stream with English, the other has audio with
>  English and video with ASL. The desire is for translation in both
>  directions between spoken English and ASL.
>=20
> It *may* be that the desired relationship between the streams can be =
inferred from the media types, directionality, and humaninlang =
attributes. But I think this starts to become ambiguous in any but the =
most simple cases. For instance, in the ASL example above, which audio =
"belongs" to the video stream? And, should the audio be "passed through" =
with the translation mixed in, or not? As we add more modalities it will =
get more complex.
>=20
> I think we could start by trying to define heuristics for figuring out =
what to do. Beyond that, we could come up with additional SDP syntax. Or =
perhaps an independent channel, such as used in CLUE, could be used.
>=20
> 	Thanks,
> 	Paul
>=20
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim


--Apple-Mail=_2F8FF229-D618-4294-9DDC-C43084CF6D52
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVonVoAAoJEORoZaSQsc1IE9wP/14pswE+K26+mIBaPQLcfIwi
NbwzftWbwqL6OKYzaFm2yW290dfKfAOAtUGIHTvxs2ENsOG3vpA2EIm/1cr9j78U
YT+VwCRX/JUXGi6uyfomEirHheeNdFP+4kHj1VGfjiEQikf82oy0jZCsK8FTIhMv
0E8aug0hUxYLzZMmTtJVVN+PZZOhsvmf5I+xlhfeCv/1uCjT9Ve2gAJUuBOlOCKi
Sz7zFZTpwngjMv7t9zrBIy4YiiO+mc6piRQ3my9gGdk97QKoWXRURSRjK68YoiuK
OpZUpEFpuKr7DqkeUNO1m1GEncVUqhU6oXVp0/4al5kkolsDdONAglU9xgRrGk+3
6cBpwCyE5pBFiO1s9r7bDqGAasmX8IzPpF3GAXeZ/0Ja/9G8gnoyjhatl62dfklu
HMXfvzk0gvaz9Z4NWGf+s0HWOsaS4jO3JCZAO2tz3U6LiUCs2b1qQV2ZpwTv+gYA
6OmZKXZadbx4rVsZdh+vD/BW1QsjMw3A7CaKKTtTKzcFjUXkQoPam6J0PtVggL2s
V8uQDO6zfBm26UWk75FEA2fmieWUSdX1kLAscSm4lGxiaJ3PB3JcVCJHx5RDgUKO
JriNvyIm4EVKB5e13DXW79QCeYrKMusfXHMJ6+sgaxR/Llnm+Nz20NGHAsuc3eO6
onrID5Wwn10Xn5gjT6QQ
=Z/5q
-----END PGP SIGNATURE-----

--Apple-Mail=_2F8FF229-D618-4294-9DDC-C43084CF6D52--


From nobody Sun Jul 12 08:00:56 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA871ACEE5 for ; Sun, 12 Jul 2015 08:00:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.701
X-Spam-Level: 
X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 GBOjXbbvBaEt for ; Sun, 12 Jul 2015 08:00:53 -0700 (PDT)
Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (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 66EC41ACEE4 for ; Sun, 12 Jul 2015 08:00:53 -0700 (PDT)
Received: by ykeo3 with SMTP id o3so176650677yke.0 for ; Sun, 12 Jul 2015 08:00:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=UL9tUfKg+KgNEY/qbw3tG2G96V6/jRn9izieYD04Mpw=; b=Hp+y+a0K+kl2xH6Jb9mBzyVOkGOUaFg0DOudTnUGZ1+ACfYr8ihma4QFfgTQuC3RT8 hLPu97W5XhX270q0sMAqglxwcRqF6gccdny5KjQQW1E+k4b9RB0v8YWj7Zj6ycNtQVkn 9K6g3bQd0j86/cT/K3p+GcR13diLYcSAgbdT65vM3V9Dh9CGZ0COE9V8kQRIZEiMOpyy 6IztHmvyEDZ6UQHXzIRKnrfFkJ8T+YnY3uLuZWty4gRamFySOhMBOq6hE/SzvBP+KsvT xsoikfD8uRGl47U9upYKtmZN+fldiFC0gMgd0K+uiEqsZV4hf6HJzhW2lZDuUNlJVNwR XmMA==
MIME-Version: 1.0
X-Received: by 10.13.194.198 with SMTP id e189mr33098421ywd.127.1436713252757;  Sun, 12 Jul 2015 08:00:52 -0700 (PDT)
Received: by 10.37.112.7 with HTTP; Sun, 12 Jul 2015 08:00:52 -0700 (PDT)
In-Reply-To: <9EDFD79F-5723-44BF-BCFE-F4C448FC102D@standardstrack.com>
References:     <6A6DE46B-F440-4CE6-8ACA-49CC7ECCFBDF@nostrum.com>      <55A03DAF.5000505@omnitor.se> <55A092DE.3000706@alum.mit.edu> <9EDFD79F-5723-44BF-BCFE-F4C448FC102D@standardstrack.com>
Date: Sun, 12 Jul 2015 16:00:52 +0100
Message-ID: 
From: Nik Tomkinson 
To: slim@ietf.org
Content-Type: multipart/alternative; boundary=001a114e799013271d051aaedf1d
Archived-At: 
Subject: Re: [Slim] Tuesday Lunch in Prague to discuss SLIM real-time & email (both)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 12 Jul 2015 15:00:55 -0000

--001a114e799013271d051aaedf1d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I will be there in person Tuesday lunchtime. Hopefully we can get a room
sorted out.

On 11 July 2015 at 19:51, Eric Burger  wrote:

> Ditto. I=E2=80=99m not likely to be on the call as I was using =E2=80=98l=
unch=E2=80=99 time
> Tuesday to fly to New York. Any other lunchtime date (I know, Monday does
> not work for others) would be better for me.
>
> > On Jul 10, 2015, at 11:51 PM, Paul Kyzivat 
> wrote:
> >
> > On 7/10/15 5:48 PM, Gunnar Hellstr=C3=B6m wrote:
> >> Yes, I want to participate remotely, if you manage to arrange for
> >> calling in.
> >
> > I'd like to call in, but with a lunch meeting that may not be very
> feasible. Also, it is 6am for me. So I may just wait to hear how it went.
> But please let me know if there is a way to call in.
> >
> >       Thanks,
> >       Paul
> >
> >> /Gunnar
> >>
> >> Randall Gellens skrev den 2015-07-10 20:39:
> >>> It seems that Tuesday lunch works for everyone interested in the SLIM
> >>> real-time and email work, so let's settle on that for both.  Please
> >>> confirm your attendance to me today if possible, and if we have enoug=
h
> >>> I will reserve a room at a restaurant in the hotel, so we can talk an=
d
> >>> be heard.  If we can meet pretty quickly after the morning session
> >>> ends, we can have time for both topics.
> >>>
> >>
> >
> > _______________________________________________
> > SLIM mailing list
> > SLIM@ietf.org
> > https://www.ietf.org/mailman/listinfo/slim
>
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim
>
>


--=20

-----------------------------------------------------------------
Multiple Language Content Type Internet Draft:


http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/

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

--001a114e799013271d051aaedf1d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I will be there in person Tuesday lunchtime. Hopefully we =
can get a room sorted out.

On 11 July 2015 at 19:51, Eric Burger &l=
t;eburger@s=
tandardstrack.com> wrote:
D=
itto. I=E2=80=99m not likely to be on the call as I was using =E2=80=98lunc=
h=E2=80=99 time Tuesday to fly to New York. Any other lunchtime date (I kno=
w, Monday does not work for others) would be better for me.




> On Jul 10, 2015, at 11:51 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

>

> On 7/10/15 5:48 PM, Gunnar Hellstr=C3=B6m wrote:

>> Yes, I want to participate remotely, if you manage to arrange for<=
br>
>> calling in.

>

> I'd like to call in, but with a lunch meeting that may not be very=
 feasible. Also, it is 6am for me. So I may just wait to hear how it went. =
But please let me know if there is a way to call in.

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks,

>=C2=A0 =C2=A0 =C2=A0 =C2=A0Paul

>

>> /Gunnar

>>

>> Randall Gellens skrev den 2015-07-10 20:39:

>>> It seems that Tuesday lunch works for everyone interested in t=
he SLIM

>>> real-time and email work, so let's settle on that for both=
.=C2=A0 Please

>>> confirm your attendance to me today if possible, and if we hav=
e enough

>>> I will reserve a room at a restaurant in the hotel, so we can =
talk and

>>> be heard.=C2=A0 If we can meet pretty quickly after the mornin=
g session

>>> ends, we can have time for both topics.

>>>

>>

>


> __________________=
_____________________________

> SLIM mailing list

> SLIM@ietf.org

> https://www.ietf.org/mailman/listinfo/slim





_______________________________________________

SLIM mailing list

SLIM@ietf.org

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





-- 
-----------=
------------------------------------------------------
Multiple Language=
 Content Type Internet Draft:
http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/=

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




--001a114e799013271d051aaedf1d--


From nobody Sun Jul 12 11:41:39 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4631A87C9 for ; Sun, 12 Jul 2015 11:41:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.879
X-Spam-Level: 
X-Spam-Status: No, score=0.879 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham
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 lbW_rABAiiYL for ; Sun, 12 Jul 2015 11:41:36 -0700 (PDT)
Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) (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 DBFDF1A87C6 for ; Sun, 12 Jul 2015 11:41:35 -0700 (PDT)
Received: by qgef3 with SMTP id f3so98496033qge.0 for ; Sun, 12 Jul 2015 11:41:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=+xuSq88F6PVT5NVExkYSWB9sgaKxTiVMX+6w9zVU+YQ=; b=jar+HwZwD5smTshdkv2Djy6z2vjpbtMABXccWfqBMLWCSp8Wr2NEKDEjWydDKu8+FB JZhYSFudPijQ1nalJ6KBKFauD8buXVrERW2egSGmHSnO7rbbGfWLg5s96pVVm+0LVV8u VSJc9Cs7b5Z/TcUAReRYVZINxLm+AUCF6no2pMyrTIDHP0chAneo8MNdPPZwJ0J20iZD grcjJbOol48Ov1q4I3Ll4Y9Oq8s36FuuW59GJbKHysgUHTGHwR25GhLPvqGeCcbmnyIg ONqoQG6jLBaOnWzyLJfKsS+fjyc1cxEsdfpBNHpASFeNNGZJFx3BcjNhly5HHmUXnrvb fOkw==
X-Gm-Message-State: ALoCoQnY/rienNy4AF56E9GIo9qPVO6A+C63ssY7p4l/NoDLZ6q70FFaSwoUXcdiqO/pVkLh4uLG
X-Received: by 10.55.25.35 with SMTP id k35mr10231593qkh.76.1436726494975; Sun, 12 Jul 2015 11:41:34 -0700 (PDT)
Received: from [10.33.193.32] (neustargw.va.neustar.com. [209.173.53.233]) by smtp.gmail.com with ESMTPSA id k135sm9531740qhc.31.2015.07.12.11.41.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 12 Jul 2015 11:41:34 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: Brian Rosen 
In-Reply-To: <83D4C689-2121-4007-A5E7-AC1398262191@standardstrack.com>
Date: Sun, 12 Jul 2015 14:41:32 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <55A188FA.3030408@alum.mit.edu> <83D4C689-2121-4007-A5E7-AC1398262191@standardstrack.com>
To: Eric Burger 
X-Mailer: Apple Mail (2.2102)
Archived-At: 
Cc: slim@ietf.org
Subject: Re: [Slim] Correlating media streams / roles for media streams
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 12 Jul 2015 18:41:38 -0000

I think the mechanism only needs to label the desires of the =
participants.  An intermediary can work out serial translation by B2BUA =
and modifying the language requests.  You can=E2=80=99t =E2=80=9Cescape=E2=
=80=9D an SDP block, so the media has to come back to the B2BUA before =
sending it to the second translator, but that isn=E2=80=99t a big deal.  =
It wouldn=E2=80=99t have to decode/encode.

Brian

> On Jul 12, 2015, at 10:10 AM, Eric Burger  =
wrote:
>=20
> I think this can be even more complex. Granted, my experience in =
simultaneous translation is 25 years old, but at the time, the European =
Commission had a rule that one could not have more than two serial =
simultaneous translations in a row. The constraint was providing =
simultaneous translations in (what today) is 24 languages, yet doing it =
with a finite number of interpreters. Scheduling was an =
=E2=80=98interesting=E2=80=99 task given the serial translation =
limitation.
>=20
> I bring this up because one can envision someone from Malta visiting =
Latvia. Finding someone who speaks both Maltese and Latvian is unlikely, =
but finding one person who speaks one of Maltese and Italian or English, =
and someone who speaks one of Latvian and Italian or English is pretty =
good. If it is a bad day, you might be able to find someone who speaks =
Maltese and Arabic, someone who speaks Arabic and German, and someone =
who speaks German and Latvian.
>=20
> I get the sense we are only looking at bilateral translations (e.g., =
English - ASL, Vietnamese - English, French - RTT, etc.). Given the =
likelihood of serial interpretations in language-dense regions of the =
world (Europe, India, and the US come immediately to mind), are we ready =
for it?
>=20
>> On Jul 11, 2015, at 5:22 PM, Paul Kyzivat  =
wrote:
>>=20
>> I have a feeling there is still a missing part to this puzzle. I =
bring it up without having yet formed an opinion on how to solve it, or =
whether slim is the right place to do so.
>>=20
>> In some cases there is a need to coordinate the content in multiple =
streams, in varying ways.
>>=20
>> One case is already mentioned in the -negotiating- draft: when it is =
desired for the content of a video stream to represent the speaker in an =
audio stream.
>>=20
>> Another one hasn't been discussed yet: it ought to be possible to =
initiate a session with a relay/translation service with the expectation =
that the service will relay/translate between two groups of streams, =
each group representing one party in a conversation. There are many =
variations on this. E.g.,
>>=20
>> - two audio streams, each with a different natural language. The =
desire
>> is for translation in both directions between them.
>>=20
>> - one group has an audio stream with English, the other has audio =
with
>> English and video with ASL. The desire is for translation in both
>> directions between spoken English and ASL.
>>=20
>> It *may* be that the desired relationship between the streams can be =
inferred from the media types, directionality, and humaninlang =
attributes. But I think this starts to become ambiguous in any but the =
most simple cases. For instance, in the ASL example above, which audio =
"belongs" to the video stream? And, should the audio be "passed through" =
with the translation mixed in, or not? As we add more modalities it will =
get more complex.
>>=20
>> I think we could start by trying to define heuristics for figuring =
out what to do. Beyond that, we could come up with additional SDP =
syntax. Or perhaps an independent channel, such as used in CLUE, could =
be used.
>>=20
>> 	Thanks,
>> 	Paul
>>=20
>> _______________________________________________
>> SLIM mailing list
>> SLIM@ietf.org
>> https://www.ietf.org/mailman/listinfo/slim
>=20
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim


From nobody Sun Jul 12 12:30:15 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C6E1A885F for ; Sun, 12 Jul 2015 12:30:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 vUBtublQtneQ for ; Sun, 12 Jul 2015 12:30:12 -0700 (PDT)
Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76C051A8843 for ; Sun, 12 Jul 2015 12:30:12 -0700 (PDT)
Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-12v.sys.comcast.net with comcast id rXVn1q00526dK1R01XWBHN; Sun, 12 Jul 2015 19:30:11 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-01v.sys.comcast.net with comcast id rXWB1q0013Ge9ey01XWBHE; Sun, 12 Jul 2015 19:30:11 +0000
Message-ID: <55A2C041.6070703@alum.mit.edu>
Date: Sun, 12 Jul 2015 15:30:09 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: slim@ietf.org
References: <55A188FA.3030408@alum.mit.edu> <83D4C689-2121-4007-A5E7-AC1398262191@standardstrack.com> 
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1436729411; bh=5Zw0rEWmkdO6IsaHOQo5pwQGmAXX3pAYVs8EwlyThYo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=TI+WPjxBDU9n6IAvUllXn/MXF7baEQI/eAQX8XJWUiqdJEi4Q/PNiD9BjlSQhDjD9 L5GTszuEcmyJeBKkrj2qUUjGZ3GkbOjZO5rEFFt+ViPD8o+qzknr7gjj/V2cTUZrlW qc8ErlmJ1q1gYx77Ull1dsSny5DjvioROCCDWNZ5fYgE07ZuTmPUXIJEUQamu2Pxak diztwE7fcAmd8/VoBXqDvPN3/82cn95OlpR3Mo+WfI4OhCgVCeuxvu5gWUhWXGTWxr Kx43v1KNdcDSDdpwWnugVb4AyJBU5iLxNA7fXr/utc2qZEaivbc6pUADcWepS40Y/p GvNM+oqMSzHJA==
Archived-At: 
Subject: Re: [Slim] Correlating media streams / roles for media streams
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 12 Jul 2015 19:30:14 -0000

On 7/12/15 2:41 PM, Brian Rosen wrote:
> I think the mechanism only needs to label the desires of the participants.  An intermediary can work out serial translation by B2BUA and modifying the language requests.  You can’t “escape” an SDP block, so the media has to come back to the B2BUA before sending it to the second translator, but that isn’t a big deal.  It wouldn’t have to decode/encode.

I agree. The algorithms could be "interesting" for choosing combinations 
of translators based on a particular pool of resources. But those need 
not be a subject for standardization.

But how to say "I want streams A+B translated to X+Y" does seem to be 
something we need.

	Thanks,
	Paul

> Brian
>
>> On Jul 12, 2015, at 10:10 AM, Eric Burger  wrote:
>>
>> I think this can be even more complex. Granted, my experience in simultaneous translation is 25 years old, but at the time, the European Commission had a rule that one could not have more than two serial simultaneous translations in a row. The constraint was providing simultaneous translations in (what today) is 24 languages, yet doing it with a finite number of interpreters. Scheduling was an â€interesting’ task given the serial translation limitation.
>>
>> I bring this up because one can envision someone from Malta visiting Latvia. Finding someone who speaks both Maltese and Latvian is unlikely, but finding one person who speaks one of Maltese and Italian or English, and someone who speaks one of Latvian and Italian or English is pretty good. If it is a bad day, you might be able to find someone who speaks Maltese and Arabic, someone who speaks Arabic and German, and someone who speaks German and Latvian.
>>
>> I get the sense we are only looking at bilateral translations (e.g., English - ASL, Vietnamese - English, French - RTT, etc.). Given the likelihood of serial interpretations in language-dense regions of the world (Europe, India, and the US come immediately to mind), are we ready for it?
>>
>>> On Jul 11, 2015, at 5:22 PM, Paul Kyzivat  wrote:
>>>
>>> I have a feeling there is still a missing part to this puzzle. I bring it up without having yet formed an opinion on how to solve it, or whether slim is the right place to do so.
>>>
>>> In some cases there is a need to coordinate the content in multiple streams, in varying ways.
>>>
>>> One case is already mentioned in the -negotiating- draft: when it is desired for the content of a video stream to represent the speaker in an audio stream.
>>>
>>> Another one hasn't been discussed yet: it ought to be possible to initiate a session with a relay/translation service with the expectation that the service will relay/translate between two groups of streams, each group representing one party in a conversation. There are many variations on this. E.g.,
>>>
>>> - two audio streams, each with a different natural language. The desire
>>> is for translation in both directions between them.
>>>
>>> - one group has an audio stream with English, the other has audio with
>>> English and video with ASL. The desire is for translation in both
>>> directions between spoken English and ASL.
>>>
>>> It *may* be that the desired relationship between the streams can be inferred from the media types, directionality, and humaninlang attributes. But I think this starts to become ambiguous in any but the most simple cases. For instance, in the ASL example above, which audio "belongs" to the video stream? And, should the audio be "passed through" with the translation mixed in, or not? As we add more modalities it will get more complex.
>>>
>>> I think we could start by trying to define heuristics for figuring out what to do. Beyond that, we could come up with additional SDP syntax. Or perhaps an independent channel, such as used in CLUE, could be used.
>>>
>>> 	Thanks,
>>> 	Paul
>>>
>>> _______________________________________________
>>> SLIM mailing list
>>> SLIM@ietf.org
>>> https://www.ietf.org/mailman/listinfo/slim
>>
>> _______________________________________________
>> SLIM mailing list
>> SLIM@ietf.org
>> https://www.ietf.org/mailman/listinfo/slim
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim
>


From nobody Sun Jul 12 14:44:30 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A7E1A874F for ; Sun, 12 Jul 2015 14:44:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level: 
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 SxIFalxeepEB for ; Sun, 12 Jul 2015 14:44:26 -0700 (PDT)
Received: from bin-vsp-out-05.atm.binero.net (vsp-authed01.binero.net [195.74.38.224]) (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 227CA1A01FC for ; Sun, 12 Jul 2015 14:44:25 -0700 (PDT)
X-Halon-ID: 2fe0e647-28df-11e5-8d7a-005056916f53
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.43.70] (unknown [2.67.176.153]) by bin-vsp-out-05.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Sun, 12 Jul 2015 23:44:34 +0200 (CEST)
Message-ID: <55A2DFB2.3090409@omnitor.se>
Date: Sun, 12 Jul 2015 23:44:18 +0200
From: =?UTF-8?B?R3VubmFyIEhlbGxzdHLDtm0=?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: slim@ietf.org
References: <55A188FA.3030408@alum.mit.edu> <83D4C689-2121-4007-A5E7-AC1398262191@standardstrack.com>  <55A2C041.6070703@alum.mit.edu>
In-Reply-To: <55A2C041.6070703@alum.mit.edu>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Slim] Correlating media streams / roles for media streams
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 12 Jul 2015 21:44:28 -0000

It seems that this requirement relates to the fuzzy line in the service 
indication section of the requirement chapter I just proposed.

There we have this vague requirement about the languages parameter a 
service shall declare or receive.
"Languages shall be media/modality/language indications in pairs showing 
the capabilities of the service."

  That language needs to be sharpened up to correspond to Paul's view 
that the translation service indication must specify input stream and 
output stream.

Would it be sufficient to change the requirements spec line to:

""Languages" shall be stream/media/modality/language indications in 
pairs showing the capabilities of the service."

?

Next issue is how that can be coded.

/Gunnar






Paul Kyzivat skrev den 2015-07-12 21:30:
> On 7/12/15 2:41 PM, Brian Rosen wrote:
>> I think the mechanism only needs to label the desires of the 
>> participants.  An intermediary can work out serial translation by 
>> B2BUA and modifying the language requests.  You can’t “escape” an SDP 
>> block, so the media has to come back to the B2BUA before sending it 
>> to the second translator, but that isn’t a big deal.  It wouldn’t 
>> have to decode/encode.
>
> I agree. The algorithms could be "interesting" for choosing 
> combinations of translators based on a particular pool of resources. 
> But those need not be a subject for standardization.
>
> But how to say "I want streams A+B translated to X+Y" does seem to be 
> something we need.
>
>     Thanks,
>     Paul
>
>> Brian
>>
>>> On Jul 12, 2015, at 10:10 AM, Eric Burger 
>>>  wrote:
>>>
>>> I think this can be even more complex. Granted, my experience in 
>>> simultaneous translation is 25 years old, but at the time, the 
>>> European Commission had a rule that one could not have more than two 
>>> serial simultaneous translations in a row. The constraint was 
>>> providing simultaneous translations in (what today) is 24 languages, 
>>> yet doing it with a finite number of interpreters. Scheduling was an 
>>> â€interesting’ task given the serial translation limitation.
>>>
>>> I bring this up because one can envision someone from Malta visiting 
>>> Latvia. Finding someone who speaks both Maltese and Latvian is 
>>> unlikely, but finding one person who speaks one of Maltese and 
>>> Italian or English, and someone who speaks one of Latvian and 
>>> Italian or English is pretty good. If it is a bad day, you might be 
>>> able to find someone who speaks Maltese and Arabic, someone who 
>>> speaks Arabic and German, and someone who speaks German and Latvian.
>>>
>>> I get the sense we are only looking at bilateral translations (e.g., 
>>> English - ASL, Vietnamese - English, French - RTT, etc.). Given the 
>>> likelihood of serial interpretations in language-dense regions of 
>>> the world (Europe, India, and the US come immediately to mind), are 
>>> we ready for it?
>>>
>>>> On Jul 11, 2015, at 5:22 PM, Paul Kyzivat  
>>>> wrote:
>>>>
>>>> I have a feeling there is still a missing part to this puzzle. I 
>>>> bring it up without having yet formed an opinion on how to solve 
>>>> it, or whether slim is the right place to do so.
>>>>
>>>> In some cases there is a need to coordinate the content in multiple 
>>>> streams, in varying ways.
>>>>
>>>> One case is already mentioned in the -negotiating- draft: when it 
>>>> is desired for the content of a video stream to represent the 
>>>> speaker in an audio stream.
>>>>
>>>> Another one hasn't been discussed yet: it ought to be possible to 
>>>> initiate a session with a relay/translation service with the 
>>>> expectation that the service will relay/translate between two 
>>>> groups of streams, each group representing one party in a 
>>>> conversation. There are many variations on this. E.g.,
>>>>
>>>> - two audio streams, each with a different natural language. The 
>>>> desire
>>>> is for translation in both directions between them.
>>>>
>>>> - one group has an audio stream with English, the other has audio with
>>>> English and video with ASL. The desire is for translation in both
>>>> directions between spoken English and ASL.
>>>>
>>>> It *may* be that the desired relationship between the streams can 
>>>> be inferred from the media types, directionality, and humaninlang 
>>>> attributes. But I think this starts to become ambiguous in any but 
>>>> the most simple cases. For instance, in the ASL example above, 
>>>> which audio "belongs" to the video stream? And, should the audio be 
>>>> "passed through" with the translation mixed in, or not? As we add 
>>>> more modalities it will get more complex.
>>>>
>>>> I think we could start by trying to define heuristics for figuring 
>>>> out what to do. Beyond that, we could come up with additional SDP 
>>>> syntax. Or perhaps an independent channel, such as used in CLUE, 
>>>> could be used.
>>>>
>>>>     Thanks,
>>>>     Paul
>>>>
>>>> _______________________________________________
>>>> SLIM mailing list
>>>> SLIM@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/slim
>>>
>>> _______________________________________________
>>> SLIM mailing list
>>> SLIM@ietf.org
>>> https://www.ietf.org/mailman/listinfo/slim
>>
>> _______________________________________________
>> SLIM mailing list
>> SLIM@ietf.org
>> https://www.ietf.org/mailman/listinfo/slim
>>
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim

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


From nobody Sun Jul 12 15:10:21 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8551A887B for ; Sun, 12 Jul 2015 15:10:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 WUjoSsfsQken for ; Sun, 12 Jul 2015 15:10:16 -0700 (PDT)
Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 789EA1A8877 for ; Sun, 12 Jul 2015 15:10:16 -0700 (PDT)
Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-06v.sys.comcast.net with comcast id raAF1q0042Bo0NV01aAFUH; Sun, 12 Jul 2015 22:10:15 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-05v.sys.comcast.net with comcast id raAE1q00h3Ge9ey01aAEV1; Sun, 12 Jul 2015 22:10:15 +0000
Message-ID: <55A2E5C5.1090606@alum.mit.edu>
Date: Sun, 12 Jul 2015 18:10:13 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: slim@ietf.org
References: <55A188FA.3030408@alum.mit.edu> <83D4C689-2121-4007-A5E7-AC1398262191@standardstrack.com>  <55A2C041.6070703@alum.mit.edu> <55A2DFB2.3090409@omnitor.se>
In-Reply-To: <55A2DFB2.3090409@omnitor.se>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1436739015; bh=2spNZ9+IsU2Tkeqpz8EYz+6iiXxYxiBcCHBCewzKayg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=lK2AlEJ3bYMg6m56PdU1eKf8ouDwxgLhLvbi8mWARY+VAPsP/lCu4gUgi0rxoBy7f gygZ3pOQMIQe4rNyOObAh/7zUb05szMOTSX3XVCQiCpH2WBVQcAM8R6fryX8ct5LEG ev50MxFWqBteMIKL4Nzbylz7COEtRYQjNAT2sxUlAERN2Xhic5BMwjrJCp5hAbLiB7 EjTaQOPlOX3lv1eCRLpjBeOCSBesF8iUVhS8aQvi3KxpV7O3PBEtWrGnM4J3OlJYLU kCoftSAnxofkBXxfkzMlZRUqplRsQaaBrd7v7Dod4SfsQGFtcYAUuKasC1J/cXQGEI mj9OYdOzvOfEw==
Archived-At: 
Subject: Re: [Slim] Correlating media streams / roles for media streams
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 12 Jul 2015 22:10:18 -0000

On 7/12/15 5:44 PM, Gunnar Hellström wrote:
> It seems that this requirement relates to the fuzzy line in the service
> indication section of the requirement chapter I just proposed.
>
> There we have this vague requirement about the languages parameter a
> service shall declare or receive.
> "Languages shall be media/modality/language indications in pairs showing
> the capabilities of the service."
>
>   That language needs to be sharpened up to correspond to Paul's view
> that the translation service indication must specify input stream and
> output stream.
>
> Would it be sufficient to change the requirements spec line to:
>
> ""Languages" shall be stream/media/modality/language indications in
> pairs showing the capabilities of the service."

ISTM that *normal* endpoints/users aren't intended to provide any 
translation/relay service. So they don't map inputs to outputs.

OTOH, relays provide this mapping. They also have the same need as other 
endpoints to express needs/capabilities of individual streams.

Perhaps it would help to adopt some of the terminology from the 
grouping-taxonomy draft to talk about this. I haven't gotten that into 
my head yet, so it will take some study to find proper terms. But I 
expect they are there.

This is only a problem if you want to invite a relay using an offer and 
count of the offer to convey all the needs to the relay. It isn't needed 
if a MiTM matches an offer and answer, selects a suitable relay, and 
inserts it in the call while configuring the relay using *private* means.

But inviting the relay that way fits well with the PSAP inviting the 
relay for emergency calls. And it has some attractive properties in the 
more general case.

	Thanks,
	Paul


> Next issue is how that can be coded.
>
> /Gunnar
>
>
>
>
>
>
> Paul Kyzivat skrev den 2015-07-12 21:30:
>> On 7/12/15 2:41 PM, Brian Rosen wrote:
>>> I think the mechanism only needs to label the desires of the
>>> participants.  An intermediary can work out serial translation by
>>> B2BUA and modifying the language requests.  You can’t “escape” an SDP
>>> block, so the media has to come back to the B2BUA before sending it
>>> to the second translator, but that isn’t a big deal.  It wouldn’t
>>> have to decode/encode.
>>
>> I agree. The algorithms could be "interesting" for choosing
>> combinations of translators based on a particular pool of resources.
>> But those need not be a subject for standardization.
>>
>> But how to say "I want streams A+B translated to X+Y" does seem to be
>> something we need.
>>
>>     Thanks,
>>     Paul
>>
>>> Brian
>>>
>>>> On Jul 12, 2015, at 10:10 AM, Eric Burger
>>>>  wrote:
>>>>
>>>> I think this can be even more complex. Granted, my experience in
>>>> simultaneous translation is 25 years old, but at the time, the
>>>> European Commission had a rule that one could not have more than two
>>>> serial simultaneous translations in a row. The constraint was
>>>> providing simultaneous translations in (what today) is 24 languages,
>>>> yet doing it with a finite number of interpreters. Scheduling was an
>>>> â€interesting’ task given the serial translation limitation.
>>>>
>>>> I bring this up because one can envision someone from Malta visiting
>>>> Latvia. Finding someone who speaks both Maltese and Latvian is
>>>> unlikely, but finding one person who speaks one of Maltese and
>>>> Italian or English, and someone who speaks one of Latvian and
>>>> Italian or English is pretty good. If it is a bad day, you might be
>>>> able to find someone who speaks Maltese and Arabic, someone who
>>>> speaks Arabic and German, and someone who speaks German and Latvian.
>>>>
>>>> I get the sense we are only looking at bilateral translations (e.g.,
>>>> English - ASL, Vietnamese - English, French - RTT, etc.). Given the
>>>> likelihood of serial interpretations in language-dense regions of
>>>> the world (Europe, India, and the US come immediately to mind), are
>>>> we ready for it?
>>>>
>>>>> On Jul 11, 2015, at 5:22 PM, Paul Kyzivat 
>>>>> wrote:
>>>>>
>>>>> I have a feeling there is still a missing part to this puzzle. I
>>>>> bring it up without having yet formed an opinion on how to solve
>>>>> it, or whether slim is the right place to do so.
>>>>>
>>>>> In some cases there is a need to coordinate the content in multiple
>>>>> streams, in varying ways.
>>>>>
>>>>> One case is already mentioned in the -negotiating- draft: when it
>>>>> is desired for the content of a video stream to represent the
>>>>> speaker in an audio stream.
>>>>>
>>>>> Another one hasn't been discussed yet: it ought to be possible to
>>>>> initiate a session with a relay/translation service with the
>>>>> expectation that the service will relay/translate between two
>>>>> groups of streams, each group representing one party in a
>>>>> conversation. There are many variations on this. E.g.,
>>>>>
>>>>> - two audio streams, each with a different natural language. The
>>>>> desire
>>>>> is for translation in both directions between them.
>>>>>
>>>>> - one group has an audio stream with English, the other has audio with
>>>>> English and video with ASL. The desire is for translation in both
>>>>> directions between spoken English and ASL.
>>>>>
>>>>> It *may* be that the desired relationship between the streams can
>>>>> be inferred from the media types, directionality, and humaninlang
>>>>> attributes. But I think this starts to become ambiguous in any but
>>>>> the most simple cases. For instance, in the ASL example above,
>>>>> which audio "belongs" to the video stream? And, should the audio be
>>>>> "passed through" with the translation mixed in, or not? As we add
>>>>> more modalities it will get more complex.
>>>>>
>>>>> I think we could start by trying to define heuristics for figuring
>>>>> out what to do. Beyond that, we could come up with additional SDP
>>>>> syntax. Or perhaps an independent channel, such as used in CLUE,
>>>>> could be used.
>>>>>
>>>>>     Thanks,
>>>>>     Paul
>>>>>
>>>>> _______________________________________________
>>>>> SLIM mailing list
>>>>> SLIM@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/slim
>>>>
>>>> _______________________________________________
>>>> SLIM mailing list
>>>> SLIM@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/slim
>>>
>>> _______________________________________________
>>> SLIM mailing list
>>> SLIM@ietf.org
>>> https://www.ietf.org/mailman/listinfo/slim
>>>
>>
>> _______________________________________________
>> SLIM mailing list
>> SLIM@ietf.org
>> https://www.ietf.org/mailman/listinfo/slim
>


From nobody Fri Jul 17 06:24:10 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 872801B33CE for ; Fri, 17 Jul 2015 06:24:03 -0700 (PDT)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -7.011
X-Spam-Level: 
X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 WSFGVlvudXwh for ; Fri, 17 Jul 2015 06:24:01 -0700 (PDT)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 484291B33BF for ; Fri, 17 Jul 2015 06:24:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1437139441; x=1468675441; h=message-id:date:to:from:subject: content-transfer-encoding; bh=BfCDSm3XGqwiT2ZOb3NqlXOqz8JDrXzhnZaI5bepatc=; b=NgEAsqSQpvQzwuCmQBI0mAPr7GOfqYhzxux8obeNPfJSLcEX5ysfIhIs A8IQJPvkZFjqllY+4yTo+zr/11Bk47lzpgGAw9yVLQMT6/cgB1JZvVPEs RkntP2mTVQBSLR96H/hRbHJlEWVqtjp3BawMSAWoQaZRa+74oOJwvGBej M=;
X-IronPort-AV: E=McAfee;i="5700,7163,7864"; a="94037114"
Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Jul 2015 06:23:38 -0700
X-IronPort-AV: E=Sophos;i="5.15,496,1432623600"; d="scan'208";a="963529625"
Received: from plus.qualcomm.com ([10.52.255.8]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Jul 2015 06:23:35 -0700
Received: from Ironmsg04-R.qualcomm.com (ironmsg04-R.qualcomm.com [172.30.46.18]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id t6HDNYHG014946; Fri, 17 Jul 2015 06:23:34 -0700
X-IronPort-AV: E=Sophos;i="5.15,496,1432623600"; d="scan'208";a="1016664894"
X-ojodefuego: yes
Received: from unknown (HELO [99.111.97.136]) ([10.64.226.181]) by Ironmsg04-R.qualcomm.com with ESMTP; 17 Jul 2015 06:23:30 -0700
Mime-Version: 1.0
Message-Id: 
X-Mailer: Eudora for Mac OS X
Date: Fri, 17 Jul 2015 06:23:27 -0700
To: slim@ietf.org
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Subject: Re: [Slim] Tuesday Lunch in Prague to discuss SLIM real-time & email (both)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Jul 2015 13:24:03 -0000

The concierge has made a reservation for us at=20
Caf=E9 imperial (5-6 min walk), which is 100%=20
non-smoking.

The is room for a few more people to join us.

Because this is not inside the hotel, I don't=20
know if there will be Wi-Fi and hence if it will=20
be possible for people to join remotely. The only=20
hotel restaurant open for lunch permits smoking=20
(although it's possible additional venues will be=20
opened).

At 11:39 AM -0700 7/10/15, Randall Gellens wrote:

>   It seems that Tuesday lunch works for everyone=20
> interested in the SLIM real-time and email=20
> work, so let's settle on that for both. Please=20
> confirm your attendance to me today if=20
> possible, and if we have enough I will reserve=20
> a room at a restaurant in the hotel, so we can=20
> talk and be heard.  If we can meet pretty=20
> quickly after the morning session ends, we can=20
> have time for both topics.
>
>   --
>   Randall Gellens
>   Opinions are personal;    facts are suspect;    I speak for myself only
>   -------------- Randomly selected tag: ---------------
>   I don't want to achieve immortality through my work....
>   I want to achieve immortality by not dying.-
>                                            --Woody Allen


--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
#Random Tag

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
In examinations the foolish ask questions that the wise cannot answer.
                                                        --Oscar Wilde


From nobody Fri Jul 17 07:29:17 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CAE31B345B for ; Fri, 17 Jul 2015 07:29:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 w3JnK7LUDEIz for ; Fri, 17 Jul 2015 07:29:06 -0700 (PDT)
Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3D0A1B3453 for ; Fri, 17 Jul 2015 07:28:58 -0700 (PDT)
Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-02v.sys.comcast.net with comcast id tSUF1q0092D5gil01SUxJQ; Fri, 17 Jul 2015 14:28:57 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-06v.sys.comcast.net with comcast id tSUx1q00G3Ge9ey01SUx0Z; Fri, 17 Jul 2015 14:28:57 +0000
Message-ID: <55A91127.1040804@alum.mit.edu>
Date: Fri, 17 Jul 2015 10:28:55 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: slim@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1437143337; bh=HFHp+VhvLXDT/KqKNjj98GFm895Uoi6f0iutLy3sGsM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=VkV8p+9ekLBHJAqdZAUrLSzsddmgZwAIVZJ5uudEJoWJ7JHqdqwQTs/DrcgHSYgPV bCd0///y3D5AqSqxai5JxAMQLbMxHq85kyiAlZh2xsU6L0mALcmN4AupV6+4FeGbHY iGs438eUkYfJL16IGCJmDZKTj6JK38HOzP0Aqzmnrkb43dh/Xis4IO7adtojkEqc5R HFjd6YQE1DyhAqKJCzZlKZD3Y780rKuQSKjydIHosWUBP/V5q8TfgQttPqxvq+q/xg uZL45R3c4smLY2bLfEUDGs4g3U3TDVyIhOgy/Anp8BcHt7bfp0gPfg+jEiiA/iqtRc ZfIxGcGhqW2Hw==
Archived-At: 
Subject: Re: [Slim] Tuesday Lunch in Prague to discuss SLIM real-time & email (both)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Jul 2015 14:29:07 -0000

That will be 5am for me. I'll look forward to hearing what you concluded.

	Thanks,
	Paul

On 7/17/15 9:23 AM, Randall Gellens wrote:
> The concierge has made a reservation for us at Café imperial (5-6 min
> walk), which is 100% non-smoking.
>
> The is room for a few more people to join us.
>
> Because this is not inside the hotel, I don't know if there will be
> Wi-Fi and hence if it will be possible for people to join remotely. The
> only hotel restaurant open for lunch permits smoking (although it's
> possible additional venues will be opened).
>
> At 11:39 AM -0700 7/10/15, Randall Gellens wrote:
>
>>   It seems that Tuesday lunch works for everyone interested in the
>> SLIM real-time and email work, so let's settle on that for both.
>> Please confirm your attendance to me today if possible, and if we have
>> enough I will reserve a room at a restaurant in the hotel, so we can
>> talk and be heard.  If we can meet pretty quickly after the morning
>> session ends, we can have time for both topics.
>>
>>   --
>>   Randall Gellens
>>   Opinions are personal;    facts are suspect;    I speak for myself only
>>   -------------- Randomly selected tag: ---------------
>>   I don't want to achieve immortality through my work....
>>   I want to achieve immortality by not dying.-
>>                                            --Woody Allen
>
>
> --
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for myself only
> -------------- Randomly selected tag: ---------------
> #Random Tag
>


From nobody Fri Jul 17 08:27:54 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7291A88B9 for ; Fri, 17 Jul 2015 08:27:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.465
X-Spam-Level: *
X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 fa8eWN67_LgA for ; Fri, 17 Jul 2015 08:27:50 -0700 (PDT)
Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 891201A887C for ; Fri, 17 Jul 2015 08:27:50 -0700 (PDT)
Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-10v.sys.comcast.net with comcast id tTTG1q00127uzMh01TTprr; Fri, 17 Jul 2015 15:27:49 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-02v.sys.comcast.net with comcast id tTTp1q00B3Ge9ey01TTpDc; Fri, 17 Jul 2015 15:27:49 +0000
Message-ID: <55A91EF4.7010505@alum.mit.edu>
Date: Fri, 17 Jul 2015 11:27:48 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: slim@ietf.org
References: <55A188FA.3030408@alum.mit.edu> <83D4C689-2121-4007-A5E7-AC1398262191@standardstrack.com>  <55A2C041.6070703@alum.mit.edu> <55A2DFB2.3090409@omnitor.se> <55A2E5C5.1090606@alum.mit.edu>
In-Reply-To: <55A2E5C5.1090606@alum.mit.edu>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1437146869; bh=22tVpH1CrLQMSzJpTWW7j4IPMXTa8WIP6ecg5Bqp1/U=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=PPZGBNxS+ew/zxqrPnRCqFCdfiurYnLy+Phsw2uXS/rD/kYKD6hOLQWq6cq0aHZJm X6hTeCGrKHsQqUkLrMSma6aYIyluDAhPmJoa4A0LFD+zTEDQ8aZEef8c7mnA+Fdwxg OyovOD0oHe9pmt+3c4WPR4MD5V/XmCReVql0y0J50+wjGs1nb6euj0n75XkzSoTD3M I0AciC4lyDyx3iwMVcF4REqoIjbGjeO9kRYTrSOh3bxWHkGO0kWAx7sTDXK4zIgsm7 bYzWiEmNdPS+1wFdSGwiE85QxmrfLK5eJfyDLVh6/c5ov7sjdzAParJx66ruBrjNST uHl/SV6dn8Z0g==
Archived-At: 
Subject: Re: [Slim] Correlating media streams / roles for media streams
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Jul 2015 15:27:52 -0000

I've been thinking more about how to indicate this correlation. There 
are some pieces of SDP machinery that could be adapted for this.

My first thought was the grouping framework (RFC5888). With a new group 
type it could be used to tie together the input and output streams for a 
relay. But that doesn't say which is the input and which is the output.

My next thought was the media loopback mechanism (RFC6849). But it only 
covers literal loopback, and does it on a single m-line.

But it would be possible to:
- define a new grouping type - loopback;
- reuse the a=loopback-source and a=loopback-miror from 6849
   to define the roles of the two ends.

E.g.,

offer:
   a=group:loopback:a1 v1
   m=audio:...
   a=mid:a1
   a=loopback-source
   m=video:...
   a=mid:v1
   a=loopback-source

answer:
   a=group:loopback:a1 v1
   m=audio:...
   a=mid:a1
   a=loopback-mirror
   m=video:...
   a=mid:v1
   a=loopback-mirror

In the above, relaying is symmetric. Data sent from source to mirror on 
any stream in the group is reflected back on the other stream of the 
group. If you wanted it to be asymmetric you could constrain it by 
making one stream sendonly and the other recvonly.

Note that this can be applied to any instance of 3pcc transcoding 
(RFC4117), not just a human relay service like VRS.

And I think it can work with groups that have more than two streams, 
such as audio+video+RTT.

These are just preliminary thoughts. I'm interested to hear what others 
think.

	Thanks,
	Paul

On 7/12/15 6:10 PM, Paul Kyzivat wrote:
> On 7/12/15 5:44 PM, Gunnar Hellström wrote:
>> It seems that this requirement relates to the fuzzy line in the service
>> indication section of the requirement chapter I just proposed.
>>
>> There we have this vague requirement about the languages parameter a
>> service shall declare or receive.
>> "Languages shall be media/modality/language indications in pairs showing
>> the capabilities of the service."
>>
>>   That language needs to be sharpened up to correspond to Paul's view
>> that the translation service indication must specify input stream and
>> output stream.
>>
>> Would it be sufficient to change the requirements spec line to:
>>
>> ""Languages" shall be stream/media/modality/language indications in
>> pairs showing the capabilities of the service."
>
> ISTM that *normal* endpoints/users aren't intended to provide any
> translation/relay service. So they don't map inputs to outputs.
>
> OTOH, relays provide this mapping. They also have the same need as other
> endpoints to express needs/capabilities of individual streams.
>
> Perhaps it would help to adopt some of the terminology from the
> grouping-taxonomy draft to talk about this. I haven't gotten that into
> my head yet, so it will take some study to find proper terms. But I
> expect they are there.
>
> This is only a problem if you want to invite a relay using an offer and
> count of the offer to convey all the needs to the relay. It isn't needed
> if a MiTM matches an offer and answer, selects a suitable relay, and
> inserts it in the call while configuring the relay using *private* means.
>
> But inviting the relay that way fits well with the PSAP inviting the
> relay for emergency calls. And it has some attractive properties in the
> more general case.
>
>      Thanks,
>      Paul
>
>
>> Next issue is how that can be coded.
>>
>> /Gunnar
>>
>>
>>
>>
>>
>>
>> Paul Kyzivat skrev den 2015-07-12 21:30:
>>> On 7/12/15 2:41 PM, Brian Rosen wrote:
>>>> I think the mechanism only needs to label the desires of the
>>>> participants.  An intermediary can work out serial translation by
>>>> B2BUA and modifying the language requests.  You can’t “escape” an SDP
>>>> block, so the media has to come back to the B2BUA before sending it
>>>> to the second translator, but that isn’t a big deal.  It wouldn’t
>>>> have to decode/encode.
>>>
>>> I agree. The algorithms could be "interesting" for choosing
>>> combinations of translators based on a particular pool of resources.
>>> But those need not be a subject for standardization.
>>>
>>> But how to say "I want streams A+B translated to X+Y" does seem to be
>>> something we need.
>>>
>>>     Thanks,
>>>     Paul
>>>
>>>> Brian
>>>>
>>>>> On Jul 12, 2015, at 10:10 AM, Eric Burger
>>>>>  wrote:
>>>>>
>>>>> I think this can be even more complex. Granted, my experience in
>>>>> simultaneous translation is 25 years old, but at the time, the
>>>>> European Commission had a rule that one could not have more than two
>>>>> serial simultaneous translations in a row. The constraint was
>>>>> providing simultaneous translations in (what today) is 24 languages,
>>>>> yet doing it with a finite number of interpreters. Scheduling was an
>>>>> â€interesting’ task given the serial translation limitation.
>>>>>
>>>>> I bring this up because one can envision someone from Malta visiting
>>>>> Latvia. Finding someone who speaks both Maltese and Latvian is
>>>>> unlikely, but finding one person who speaks one of Maltese and
>>>>> Italian or English, and someone who speaks one of Latvian and
>>>>> Italian or English is pretty good. If it is a bad day, you might be
>>>>> able to find someone who speaks Maltese and Arabic, someone who
>>>>> speaks Arabic and German, and someone who speaks German and Latvian.
>>>>>
>>>>> I get the sense we are only looking at bilateral translations (e.g.,
>>>>> English - ASL, Vietnamese - English, French - RTT, etc.). Given the
>>>>> likelihood of serial interpretations in language-dense regions of
>>>>> the world (Europe, India, and the US come immediately to mind), are
>>>>> we ready for it?
>>>>>
>>>>>> On Jul 11, 2015, at 5:22 PM, Paul Kyzivat 
>>>>>> wrote:
>>>>>>
>>>>>> I have a feeling there is still a missing part to this puzzle. I
>>>>>> bring it up without having yet formed an opinion on how to solve
>>>>>> it, or whether slim is the right place to do so.
>>>>>>
>>>>>> In some cases there is a need to coordinate the content in multiple
>>>>>> streams, in varying ways.
>>>>>>
>>>>>> One case is already mentioned in the -negotiating- draft: when it
>>>>>> is desired for the content of a video stream to represent the
>>>>>> speaker in an audio stream.
>>>>>>
>>>>>> Another one hasn't been discussed yet: it ought to be possible to
>>>>>> initiate a session with a relay/translation service with the
>>>>>> expectation that the service will relay/translate between two
>>>>>> groups of streams, each group representing one party in a
>>>>>> conversation. There are many variations on this. E.g.,
>>>>>>
>>>>>> - two audio streams, each with a different natural language. The
>>>>>> desire
>>>>>> is for translation in both directions between them.
>>>>>>
>>>>>> - one group has an audio stream with English, the other has audio
>>>>>> with
>>>>>> English and video with ASL. The desire is for translation in both
>>>>>> directions between spoken English and ASL.
>>>>>>
>>>>>> It *may* be that the desired relationship between the streams can
>>>>>> be inferred from the media types, directionality, and humaninlang
>>>>>> attributes. But I think this starts to become ambiguous in any but
>>>>>> the most simple cases. For instance, in the ASL example above,
>>>>>> which audio "belongs" to the video stream? And, should the audio be
>>>>>> "passed through" with the translation mixed in, or not? As we add
>>>>>> more modalities it will get more complex.
>>>>>>
>>>>>> I think we could start by trying to define heuristics for figuring
>>>>>> out what to do. Beyond that, we could come up with additional SDP
>>>>>> syntax. Or perhaps an independent channel, such as used in CLUE,
>>>>>> could be used.
>>>>>>
>>>>>>     Thanks,
>>>>>>     Paul
>>>>>>
>>>>>> _______________________________________________
>>>>>> SLIM mailing list
>>>>>> SLIM@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/slim
>>>>>
>>>>> _______________________________________________
>>>>> SLIM mailing list
>>>>> SLIM@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/slim
>>>>
>>>> _______________________________________________
>>>> SLIM mailing list
>>>> SLIM@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/slim
>>>>
>>>
>>> _______________________________________________
>>> SLIM mailing list
>>> SLIM@ietf.org
>>> https://www.ietf.org/mailman/listinfo/slim
>>
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim


From nobody Fri Jul 17 10:12:33 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB12F1AC3A7 for ; Fri, 17 Jul 2015 10:12:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.887
X-Spam-Level: 
X-Spam-Status: No, score=0.887 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=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 C3AVrNXeLKVT for ; Fri, 17 Jul 2015 10:12:31 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED2751AC39C for ; Fri, 17 Jul 2015 10:12:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default;  h=In-Reply-To:To:References:Date:Subject:Mime-Version:Message-Id:Content-Type:From; bh=5PLkHe5kanWn5AI7ipgL0eO/DylyUeHb3j6tTGZm8qk=;  b=hf9+F8O2Sq834q0/4tvxjWZpuYYbN3dk4thGTCczaVfGMCL6iuZJjrsn7h+X5qTucNaeNfIkQtRxghxQmwuvTtUE5TTQQ92K8cM/P2jZHGO6qhTVA3XjVx2r9b3EY4NG5HLyzYEIFfZSRywUlUHeeeqSruGthUqHGVzZuKw2sEg=;
Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:64548 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZG9BU-0001od-FZ for slim@ietf.org; Fri, 17 Jul 2015 10:12:30 -0700
From: Eric Burger 
Content-Type: multipart/signed; boundary="Apple-Mail=_5583D602-26B0-4C02-AA3D-1570623F16B4"; protocol="application/pkcs7-signature"; micalg=sha1
Message-Id: <52755783-04B1-4A4E-890F-CFDF8DD41A5E@standardstrack.com>
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
Date: Fri, 17 Jul 2015 13:12:25 -0400
References:  <55A91127.1040804@alum.mit.edu>
To: slim@ietf.org
In-Reply-To: <55A91127.1040804@alum.mit.edu>
X-Mailer: Apple Mail (2.2102)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.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: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
Archived-At: 
Subject: Re: [Slim] Tuesday Lunch in Prague to discuss SLIM real-time & email (both)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Jul 2015 17:12:32 -0000

--Apple-Mail=_5583D602-26B0-4C02-AA3D-1570623F16B4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

If it is just me remote, I might go for the Paul approach. I need to be =
wheels-up at 7am.

> On Jul 17, 2015, at 10:28 AM, Paul Kyzivat  =
wrote:
>=20
> That will be 5am for me. I'll look forward to hearing what you =
concluded.
>=20
> 	Thanks,
> 	Paul
>=20
> On 7/17/15 9:23 AM, Randall Gellens wrote:
>> The concierge has made a reservation for us at Caf=E9 imperial (5-6 =
min
>> walk), which is 100% non-smoking.
>>=20
>> The is room for a few more people to join us.
>>=20
>> Because this is not inside the hotel, I don't know if there will be
>> Wi-Fi and hence if it will be possible for people to join remotely. =
The
>> only hotel restaurant open for lunch permits smoking (although it's
>> possible additional venues will be opened).
>>=20
>> At 11:39 AM -0700 7/10/15, Randall Gellens wrote:
>>=20
>>>  It seems that Tuesday lunch works for everyone interested in the
>>> SLIM real-time and email work, so let's settle on that for both.
>>> Please confirm your attendance to me today if possible, and if we =
have
>>> enough I will reserve a room at a restaurant in the hotel, so we can
>>> talk and be heard.  If we can meet pretty quickly after the morning
>>> session ends, we can have time for both topics.
>>>=20
>>>  --
>>>  Randall Gellens
>>>  Opinions are personal;    facts are suspect;    I speak for myself =
only
>>>  -------------- Randomly selected tag: ---------------
>>>  I don't want to achieve immortality through my work....
>>>  I want to achieve immortality by not dying.-
>>>                                           --Woody Allen
>>=20
>>=20
>> --
>> Randall Gellens
>> Opinions are personal;    facts are suspect;    I speak for myself =
only
>> -------------- Randomly selected tag: ---------------
>> #Random Tag
>>=20
>=20
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim


--Apple-Mail=_5583D602-26B0-4C02-AA3D-1570623F16B4
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQpjCCBUAw
ggQooAMCAQICEQCuNx1clInO3pDdx/tx5ymMMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH
QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK
ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj
YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNDEwMDgwMDAwMDBaFw0xNTEwMDgyMzU5NTla
MCsxKTAnBgkqhkiG9w0BCQEWGmVidXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0HJR1ciLrHT/CjRECPUsdCrORWwHwf9AA9jE6tX8y8sqqrnY
jPw4YtahKkLP+3VLXEjTWLi9nl0ISFtrZ+sq27HUuPmaiNtjqWgCjyPjfUi5PEDiJE3CSR8CK8Z6
iLO09oNTlSLY6qmKxVB4MEp8rRvOYTDk4nC2wCgMRzpUXE8q44d8LPYSe1V1o4eSSRXby2gxrTMw
F/RLKGeSyB2ekee0c68FMZmfPR8kp43jM0SlZqgXLkf8ATTF9BxeznwqTC7GxXRJJi30d9dNQIl1
4M7J0c3kY7VpAHFXCh/KuNki0e6LKnhJrMXzVvou1OqCgI0xbCQJbMkjm8hXXxYU7wIDAQABo4IB
8DCCAewwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFK1jQ8667Bo+
kfpdpUC1bTmlMzGLMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG
AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEE
AbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYD
VR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0
aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUF
BzAChklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlv
bmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j
b20wJQYDVR0RBB4wHIEaZWJ1cmdlckBzdGFuZGFyZHN0cmFjay5jb20wDQYJKoZIhvcNAQELBQAD
ggEBAGYB/MbhzXClCc4fPctp4HBusRbgGt05ngOvKLih3vUY4xSG6FV+5BaRt5/MvnnIATlf/dxt
GBmeX3X124irtI2EIkd7xEStZlrSzDm3eIv0wW3DeKY8V9BlTKSmPO6sXl1qU8WJoNZvXOhs52do
Y4CTURs4uuttjbuEH3PQ32lO8M5lPqMnvj/qhGxh2Sg7mRop2kGitqLB6HHqGyh1t32SY16wWvPT
ovhq/38sPFamVK0FOC68LGxeKYD4KOf6GQkteQkQG+uqCEdpi4k2EwTtK43bVbeZ1rSzPMC5HRln
m+qPgE7ZWxBQlvdd5sQtBUz5Dl5lqj9kQ3YQz6XFNAMwggV0MIIEXKADAgECAhAnZu5W60nzjqvX
cKL8hN4iMA0GCSqGSIb3DQEBDAUAMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBB
QjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRy
dXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMDAwNTMwMTA0ODM4WhcNMjAwNTMwMTA0ODM4WjCBhTEL
MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlm
aWNhdGlvbiBBdXRob3JpdHkwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCR6FSS0gpW
sawNJN3Fz0RndJkrN6N9I3AAcbxT38T6KhKPS38QVr2fcHK3YX/JSw8Xpz3jsARh7v8Rl8f0hj4K
+j5c+ZPmNHrZFGvnnLOFoIJ6dq9xkNfs/Q36nGz637CC9BR++b7Epi9Pf5l/tfxnQ3K9DADWietr
LNPtj5gcFKt+5eNu/Nio5JIk2kNrYrhV/erBvGy2i/MOjZrkm2xpmfh4SDBF1a3hDTxFYPwyllEn
vGfDyi62a+pGx8cgoLEfZd5ICLqkTqnyg0Y3hOvozIFIQ2dOciqbXL1MGyiKXCJ7tKuY2e7gUYPD
CUZObT6Z+pUX2nwzV0E8jVHtC7ZcryxjGt9XyD+86V3Em69FmeKjWiS0uqlWPc9vqv9JWL7wqP/0
uK3pN/u6uPQLOvnoQ0IeidiEyxPx2bvhiWC4jChWrBQdnArncevPDt09qZahSL0896+1DSJMwBGB
7FY79tOi4lu3sgQiUpWAk2nojkxl8ZEDLXB0AuqLZxUpaVICu9ffUGpVRr+goyhhf3DQw6KqLCGq
R84onAZFdr+CGCe01a60y1Dma/RMhnEw6abfFobg2P9A3fvQQoh/ozM6LlweQRGBY84YcWsr7KaK
tzFcOmpH4MN5WdYgGq/yapiqcrxXStJLnbsQ/LBMQeXtHT1eKJ2czL+zUdqnR+WEUwIDAQABo4H0
MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBS7r34CPfqm8TyE
jq3uOJjs2TIy1DAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAIMAYG
BFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0
RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29j
c3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0BAQwFAAOCAQEAZL+D8V+ahdDNuKEpVw3oWvfR6T7y
dgRu8VJwux48/00NdGrMgYIl08OgKl1M9bqLoW3EVAl1x+MnDl2EeTdAE3f1tKwc0DurFxLW7zQY
fivpedOrV0UMryj60NvlUJWIu9+FV2l9kthSynOBvxzz5rhuZhEFsx6ULX+RlZJZ8UzOo5FxTHxH
DDsLGfahsWyGPlyqxC6Cy/kHlrpITZDylMipc6LrBnsjnd6i801Vn3phRZgYaMdeQGsj9Xl674y1
a4u3b0b0e/E9SwTYk4BZWuBBJB2yjxVgWEfb725G/RX12V+as9vYuORAs82XOa6Fux2OvNyHm9Gm
7/E7bxA4bzCCBeYwggPOoAMCAQICEGqb4Tg7/ytrnwHV2binUlYwDQYJKoZIhvcNAQEMBQAwgYUx
CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv
cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMSswKQYDVQQDEyJDT01PRE8gUlNBIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MB4XDTEzMDExMDAwMDAwMFoXDTI4MDEwOTIzNTk1OVowgZcxCzAJ
BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx
GjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBB
dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEAvrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6cpzEup/Y0dtmEatrQPTRI
5Or1u6zf+bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDIMypVpVSRsivlJTRENf+R
KwrB6vcfWlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYKjrc5NOpG9qrxpZxyb4o4
yNNwTqzaaPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRikw8lBoNoSWY66nJN/VCJv5ym6
Q0mdCbDKCMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsUtQIDAQABo4IBPDCCATgwHwYDVR0j
BBgwFoAUu69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0OBBYEFIKvbIz4xf6WYXzoHz0rcUhexIvA
MA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBM
BgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDZXJ0aWZp
Y2F0aW9uQXV0aG9yaXR5LmNybDBxBggrBgEFBQcBAQRlMGMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9j
cnQuY29tb2RvY2EuY29tL0NPTU9ET1JTQUFkZFRydXN0Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRw
Oi8vb2NzcC5jb21vZG9jYS5jb20wDQYJKoZIhvcNAQEMBQADggIBAHhcsoEoNE887l9Wzp+XVuyP
omsX9vP2SQgG1NgvNc3fQP7TcePo7EIMERoh42awGGsma65u/ITse2hKZHzT0CBxhuhb6txM1n/y
78e/4ZOs0j8CGpfb+SJA3GaBQ+394k+z3ZByWPQedXLL1OdK8aRINTsjk/H5Ns77zwbjOKkDamxl
pZ4TKSDMKVmU/PUWNMKSTvtlenlxBhh7ETrN543j/Q6qqgCWgWuMAXijnRglp9fyadqGOncjZjaa
SOGTTFB+E2pvOUtY+hPebuPtTbq7vODqzCM6ryEhNhzf+enm0zlpXK7q332nXttNtjv7VFNYG+I3
1gnMrwfHM5tdhYF/8v5UY5g2xANPECTQdu9vWPoqNSGDt87b3gXb1AiGGaI06vzgkejL580ul+9h
z9D0S0U4jkhJiA7EuTecP/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2aPY8ydehzuZutLbZdRJ5
PDEJM/1tyZR2niOYihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/GqK2HsOgkL3VYnwtx7cJU
mpvVdZ4ognzgXtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+85hFQzVxZx5/bRaTKTlL8
YXLI8nAbR9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYIDujCCA7YCAQEwga0wgZcx
CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv
cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEArjcdXJSJzt6Q3cf7cecpjDAJ
BgUrDgMCGgUAoIIB4TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0x
NTA3MTcxNzEyMjdaMCMGCSqGSIb3DQEJBDEWBBS+PtLpAZFvKPTMEBqhP7WeJnzSqjCBvgYJKwYB
BAGCNxAEMYGwMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy
MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0
Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAK43
HVyUic7ekN3H+3HnKYwwgcAGCyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkG
A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P
RE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24g
YW5kIFNlY3VyZSBFbWFpbCBDQQIRAK43HVyUic7ekN3H+3HnKYwwDQYJKoZIhvcNAQEBBQAEggEA
t/D2aqvkBFiOdiNysnfNfeXtxgZiNyoriIbkcBlY38t4vmNYv9rRMqrrGSvcqCFCXeXG8qmTi3Pe
3ODlmn+ajgntP5i+qhHlN0ClWuDxO5IkGH5TCcHl0f5PSM6ARzbUFy3tGMtWir5dHmiOwSfiLefn
oYY1hOkWgtVP3sgwHNXSMlCQCeQlp7wKa7bQm4ubZ16OHR2I7HOYm+tFiaNmVmq6afNFcp0V37Ul
3xgneuGY2RcKOYdqZdw8SHjNoxQMsvvVuXmik7g1N71zWjYuOeMo8z/AKFGiCAFMqmKK6he8wgKF
POhrIq1BRqG2vn7sKxCK92fGPsK9O7dodk4vJgAAAAAAAA==
--Apple-Mail=_5583D602-26B0-4C02-AA3D-1570623F16B4--


From nobody Sat Jul 18 13:07:18 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A951A009D for ; Sat, 18 Jul 2015 13:07:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.099
X-Spam-Level: *
X-Spam-Status: No, score=1.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 UwT0hzQJD8wC for ; Sat, 18 Jul 2015 13:07:13 -0700 (PDT)
Received: from bin-vsp-out-04.atm.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 15C011A00DB for ; Sat, 18 Jul 2015 13:07:12 -0700 (PDT)
X-Halon-ID: 909e5e99-2d88-11e5-b1e1-005056917c0c
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.43.70] (unknown [2.64.156.214]) by bin-vsp-out-04.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Sat, 18 Jul 2015 22:07:06 +0200 (CEST)
Message-ID: <55AAB1E9.9090202@omnitor.se>
Date: Sat, 18 Jul 2015 22:07:05 +0200
From: =?UTF-8?B?R3VubmFyIEhlbGxzdHLDtm0=?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: "slim@ietf.org" 
References: <55A188FA.3030408@alum.mit.edu> <83D4C689-2121-4007-A5E7-AC1398262191@standardstrack.com>  <55A2C041.6070703@alum.mit.edu> <55A2DFB2.3090409@omnitor.se> <55A2E5C5.1090606@alum.mit.edu> <55A91EF4.7010505@alum.mit.edu>
In-Reply-To: <55A91EF4.7010505@alum.mit.edu>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Slim] Correlating media streams / roles for media streams
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Jul 2015 20:07:16 -0000

There is an interesting difference between relay services and language 
translation services that infuences the requiremets on the functions you 
describe:

Relay services act between different modalities, and it is acceptable 
that the output from the relay in the medium it produces is either the 
only source in that medium that reaches the other party, or is mixed 
with the source.

Example: video relay, taking sign language input in video, producing 
spoken output in audio, and taking spoken input in audio producing sign 
language output in video. Real-time text might be used occasionally by 
any party to spell out something or type it for easier memorizing.
The medium that the relay service takes as input may also be received by 
theparty not producing it, making it realistic to use a regular 
multimedia three-party-bridge for the relay service.
The functionality can be worked out from language/modality preferences 
of the users.
The basic video relay primary user has high preference for receiving 
sign language and producing sign language.
The basic video relay speech user has high preference for receiving 
speech and producing speech.
Matching these, it is apparent that a service with the functionality of 
the traditional video relay functionality is needed.



Language translators on the other hand is taking as input the same 
medium as it produces, and the receiving part only wants to receive the 
output from the language translator in the medium that the translator 
acts on.

Example:  Spoken language interpreter between French and English. Taking 
spoken French as input replacing it with spoken English, and taking 
spoken English as input and replacing it with spoken French. For this 
service it is not feasible to just arrange a regular three-party bridged 
call, because then both the original speech and the translated speech 
will be heard mixed to the other user, and that is not desirable in most 
language translation situations.
This can also be worked out from SLIM language and modality indications 
from the users, but the resulting invocation of the translating service 
need to be a with a bridge with two audio streams between the bridge and 
the translating service. This can be done by using two coordinated 
calls, or one call with multiple streams of the language-carrying media.

I realize that this influences the interface between the bridge and the 
translating service to contain two media streams of the same kind, but 
it does not influence  the interfaces between the users and the bridge.
The task of correlating streames and roles would be between the bridge 
and the language translation service. I can see that done with the SLIM 
indications if they are inserted in SDP media descriptions as planned, 
but  there is a need for an out-of-band application agreement that they 
mean that translation is required. I guess that it is this out-of-band 
agreement you want to replace with signaling.


Paul Kyzivat skrev den 2015-07-17 17:27:
> I've been thinking more about how to indicate this correlation. There 
> are some pieces of SDP machinery that could be adapted for this.
>
> My first thought was the grouping framework (RFC5888). With a new 
> group type it could be used to tie together the input and output 
> streams for a relay. But that doesn't say which is the input and which 
> is the output.
>
> My next thought was the media loopback mechanism (RFC6849). But it 
> only covers literal loopback, and does it on a single m-line.
The words and the intentions from RFC 6849 are misleading. Only the 
coarse concept is reusable
>
> But it would be possible to:
> - define a new grouping type - loopback;
> - reuse the a=loopback-source and a=loopback-miror from 6849
>   to define the roles of the two ends.
>
> E.g.,
>
> offer:
>   a=group:loopback:a1 v1
>   m=audio:...
>   a=mid:a1
>   a=loopback-source
>   m=video:...
>   a=mid:v1
>   a=loopback-source
>
> answer:
>   a=group:loopback:a1 v1
>   m=audio:...
>   a=mid:a1
>   a=loopback-mirror
>   m=video:...
>   a=mid:v1
>   a=loopback-mirror
>
> In the above, relaying is symmetric. Data sent from source to mirror 
> on any stream in the group is reflected back on the other stream of 
> the group. 
GH: But to me it looks as if the media are only used one-way. In both 
translating services and relay services, the normal mode is two-way 
transmission of media. E.g.  two way sign language vs two-way speech. 
source and mirror seem to have the intention to be used as 
"send-original" and "send-translated" indications, and that is only half 
the required use.

GH: I am not totally sure about what use case you want to solve. Is it 
requesting suitable services from a relay or translating service 
connected by means of a bridge in a session between two users?

GH: With "reflected back", I assume you mean "sent after translation".


> If you wanted it to be asymmetric you could constrain it by making one 
> stream sendonly and the other recvonly.
GH:  Requesting translation to one direction is usually not the same as 
restricting media transmission to just one direction. The SLIM 
indications seem more appropriate.
>
> Note that this can be applied to any instance of 3pcc transcoding 
> (RFC4117), not just a human relay service like VRS.
>
> And I think it can work with groups that have more than two streams, 
> such as audio+video+RTT.
>
> These are just preliminary thoughts. I'm interested to hear what 
> others think.
GH: It it true that this is not for the endpoints to use, but only for a 
point where the need for relay or translation is evaluated and the 
assisting service invoked?

/Gunnar
>
>     Thanks,
>     Paul
>
> On 7/12/15 6:10 PM, Paul Kyzivat wrote:
>> On 7/12/15 5:44 PM, Gunnar Hellström wrote:
>>> It seems that this requirement relates to the fuzzy line in the service
>>> indication section of the requirement chapter I just proposed.
>>>
>>> There we have this vague requirement about the languages parameter a
>>> service shall declare or receive.
>>> "Languages shall be media/modality/language indications in pairs 
>>> showing
>>> the capabilities of the service."
>>>
>>>   That language needs to be sharpened up to correspond to Paul's view
>>> that the translation service indication must specify input stream and
>>> output stream.
>>>
>>> Would it be sufficient to change the requirements spec line to:
>>>
>>> ""Languages" shall be stream/media/modality/language indications in
>>> pairs showing the capabilities of the service."
>>
>> ISTM that *normal* endpoints/users aren't intended to provide any
>> translation/relay service. So they don't map inputs to outputs.
>>
>> OTOH, relays provide this mapping. They also have the same need as other
>> endpoints to express needs/capabilities of individual streams.
>>
>> Perhaps it would help to adopt some of the terminology from the
>> grouping-taxonomy draft to talk about this. I haven't gotten that into
>> my head yet, so it will take some study to find proper terms. But I
>> expect they are there.
>>
>> This is only a problem if you want to invite a relay using an offer and
>> count of the offer to convey all the needs to the relay. It isn't needed
>> if a MiTM matches an offer and answer, selects a suitable relay, and
>> inserts it in the call while configuring the relay using *private* 
>> means.
>>
>> But inviting the relay that way fits well with the PSAP inviting the
>> relay for emergency calls. And it has some attractive properties in the
>> more general case.
>>
>>      Thanks,
>>      Paul
>>
>>
>>> Next issue is how that can be coded.
>>>
>>> /Gunnar
>>>
>>>
>>>
>>>
>>>
>>>
>>> Paul Kyzivat skrev den 2015-07-12 21:30:
>>>> On 7/12/15 2:41 PM, Brian Rosen wrote:
>>>>> I think the mechanism only needs to label the desires of the
>>>>> participants.  An intermediary can work out serial translation by
>>>>> B2BUA and modifying the language requests.  You can’t “escape” an SDP
>>>>> block, so the media has to come back to the B2BUA before sending it
>>>>> to the second translator, but that isn’t a big deal.  It wouldn’t
>>>>> have to decode/encode.
>>>>
>>>> I agree. The algorithms could be "interesting" for choosing
>>>> combinations of translators based on a particular pool of resources.
>>>> But those need not be a subject for standardization.
>>>>
>>>> But how to say "I want streams A+B translated to X+Y" does seem to be
>>>> something we need.
>>>>
>>>>     Thanks,
>>>>     Paul
>>>>
>>>>> Brian
>>>>>
>>>>>> On Jul 12, 2015, at 10:10 AM, Eric Burger
>>>>>>  wrote:
>>>>>>
>>>>>> I think this can be even more complex. Granted, my experience in
>>>>>> simultaneous translation is 25 years old, but at the time, the
>>>>>> European Commission had a rule that one could not have more than two
>>>>>> serial simultaneous translations in a row. The constraint was
>>>>>> providing simultaneous translations in (what today) is 24 languages,
>>>>>> yet doing it with a finite number of interpreters. Scheduling was an
>>>>>> â€interesting’ task given the serial translation limitation.
>>>>>>
>>>>>> I bring this up because one can envision someone from Malta visiting
>>>>>> Latvia. Finding someone who speaks both Maltese and Latvian is
>>>>>> unlikely, but finding one person who speaks one of Maltese and
>>>>>> Italian or English, and someone who speaks one of Latvian and
>>>>>> Italian or English is pretty good. If it is a bad day, you might be
>>>>>> able to find someone who speaks Maltese and Arabic, someone who
>>>>>> speaks Arabic and German, and someone who speaks German and Latvian.
>>>>>>
>>>>>> I get the sense we are only looking at bilateral translations (e.g.,
>>>>>> English - ASL, Vietnamese - English, French - RTT, etc.). Given the
>>>>>> likelihood of serial interpretations in language-dense regions of
>>>>>> the world (Europe, India, and the US come immediately to mind), are
>>>>>> we ready for it?
>>>>>>
>>>>>>> On Jul 11, 2015, at 5:22 PM, Paul Kyzivat 
>>>>>>> wrote:
>>>>>>>
>>>>>>> I have a feeling there is still a missing part to this puzzle. I
>>>>>>> bring it up without having yet formed an opinion on how to solve
>>>>>>> it, or whether slim is the right place to do so.
>>>>>>>
>>>>>>> In some cases there is a need to coordinate the content in multiple
>>>>>>> streams, in varying ways.
>>>>>>>
>>>>>>> One case is already mentioned in the -negotiating- draft: when it
>>>>>>> is desired for the content of a video stream to represent the
>>>>>>> speaker in an audio stream.
>>>>>>>
>>>>>>> Another one hasn't been discussed yet: it ought to be possible to
>>>>>>> initiate a session with a relay/translation service with the
>>>>>>> expectation that the service will relay/translate between two
>>>>>>> groups of streams, each group representing one party in a
>>>>>>> conversation. There are many variations on this. E.g.,
>>>>>>>
>>>>>>> - two audio streams, each with a different natural language. The
>>>>>>> desire
>>>>>>> is for translation in both directions between them.
>>>>>>>
>>>>>>> - one group has an audio stream with English, the other has audio
>>>>>>> with
>>>>>>> English and video with ASL. The desire is for translation in both
>>>>>>> directions between spoken English and ASL.
>>>>>>>
>>>>>>> It *may* be that the desired relationship between the streams can
>>>>>>> be inferred from the media types, directionality, and humaninlang
>>>>>>> attributes. But I think this starts to become ambiguous in any but
>>>>>>> the most simple cases. For instance, in the ASL example above,
>>>>>>> which audio "belongs" to the video stream? And, should the audio be
>>>>>>> "passed through" with the translation mixed in, or not? As we add
>>>>>>> more modalities it will get more complex.
>>>>>>>
>>>>>>> I think we could start by trying to define heuristics for figuring
>>>>>>> out what to do. Beyond that, we could come up with additional SDP
>>>>>>> syntax. Or perhaps an independent channel, such as used in CLUE,
>>>>>>> could be used.
>>>>>>>
>>>>>>>     Thanks,
>>>>>>>     Paul
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> SLIM mailing list
>>>>>>> SLIM@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/slim
>>>>>>
>>>>>> _______________________________________________
>>>>>> SLIM mailing list
>>>>>> SLIM@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/slim
>>>>>
>>>>> _______________________________________________
>>>>> SLIM mailing list
>>>>> SLIM@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/slim
>>>>>
>>>>
>>>> _______________________________________________
>>>> SLIM mailing list
>>>> SLIM@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/slim
>>>
>>
>> _______________________________________________
>> SLIM mailing list
>> SLIM@ietf.org
>> https://www.ietf.org/mailman/listinfo/slim
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim

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


From nobody Sun Jul 19 10:43:37 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A19CE1B2AD3 for ; Sun, 19 Jul 2015 10:43:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.688
X-Spam-Level: *
X-Spam-Status: No, score=1.688 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=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 MRC8uhMu6GIT for ; Sun, 19 Jul 2015 10:43:31 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 547EF1B2ACF for ; Sun, 19 Jul 2015 10:43:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default;  h=In-Reply-To:To:References:Date:Subject:Mime-Version:Message-Id:Content-Type:From; bh=nMnKmO/r0AaoppuUdoBcrw+gSgSukRwBea/TZeRv8zE=;  b=DCoN3574AqndaUw+CvRg/G/X+4uhgvDwm2uH6ssnYInfEAfofVJuhyyEm7OHf/FgICZ7VnmkxdxgXS+YaxMSz9zOusmLKCDTRXa04Q0fkPmluQUKs2ieGWctLPoD8poOT2Vl+jfomLoyDwulcYaYeyg8FriMjO3frFH1PfZIoDY=;
Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:50508 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZGscV-0000FM-0W for slim@ietf.org; Sun, 19 Jul 2015 10:43:27 -0700
From: Eric Burger 
Content-Type: multipart/signed; boundary="Apple-Mail=_0242BEA3-D689-479E-809A-15284C71BB24"; protocol="application/pkcs7-signature"; micalg=sha1
Message-Id: 
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
Date: Sun, 19 Jul 2015 13:43:20 -0400
References: <55A188FA.3030408@alum.mit.edu> <83D4C689-2121-4007-A5E7-AC1398262191@standardstrack.com>  <55A2C041.6070703@alum.mit.edu> <55A2DFB2.3090409@omnitor.se> <55A2E5C5.1090606@alum.mit.edu> <55A91EF4.7010505@alum.mit.edu> <55AAB1E9.9090202@omnitor.se>
To: "slim@ietf.org" 
In-Reply-To: <55AAB1E9.9090202@omnitor.se>
X-Mailer: Apple Mail (2.2102)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.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: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
Archived-At: 
Subject: Re: [Slim] Correlating media streams / roles for media streams
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Jul 2015 17:43:32 -0000

--Apple-Mail=_0242BEA3-D689-479E-809A-15284C71BB24
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

What about business meetings? SLIM is for more than just emergency =
services. I can sort of follow French, so hearing the French before =
translation into English is of value to me.

> On Jul 18, 2015, at 4:07 PM, Gunnar Hellstr=C3=B6m =
 wrote:
>=20
> Example:  Spoken language interpreter between French and English. =
Taking spoken French as input replacing it with spoken English, and =
taking spoken English as input and replacing it with spoken French. For =
this service it is not feasible to just arrange a regular three-party =
bridged call, because then both the original speech and the translated =
speech will be heard mixed to the other user, and that is not desirable =
in most language translation situations.
> This can also be worked out from SLIM language and modality =
indications from the users, but the resulting invocation of the =
translating service need to be a with a bridge with two audio streams =
between the bridge and the translating service. This can be done by =
using two coordinated calls, or one call with multiple streams of the =
language-carrying media.


--Apple-Mail=_0242BEA3-D689-479E-809A-15284C71BB24
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQpjCCBUAw
ggQooAMCAQICEQCuNx1clInO3pDdx/tx5ymMMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH
QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK
ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj
YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNDEwMDgwMDAwMDBaFw0xNTEwMDgyMzU5NTla
MCsxKTAnBgkqhkiG9w0BCQEWGmVidXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0HJR1ciLrHT/CjRECPUsdCrORWwHwf9AA9jE6tX8y8sqqrnY
jPw4YtahKkLP+3VLXEjTWLi9nl0ISFtrZ+sq27HUuPmaiNtjqWgCjyPjfUi5PEDiJE3CSR8CK8Z6
iLO09oNTlSLY6qmKxVB4MEp8rRvOYTDk4nC2wCgMRzpUXE8q44d8LPYSe1V1o4eSSRXby2gxrTMw
F/RLKGeSyB2ekee0c68FMZmfPR8kp43jM0SlZqgXLkf8ATTF9BxeznwqTC7GxXRJJi30d9dNQIl1
4M7J0c3kY7VpAHFXCh/KuNki0e6LKnhJrMXzVvou1OqCgI0xbCQJbMkjm8hXXxYU7wIDAQABo4IB
8DCCAewwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFK1jQ8667Bo+
kfpdpUC1bTmlMzGLMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG
AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEE
AbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYD
VR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0
aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUF
BzAChklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlv
bmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j
b20wJQYDVR0RBB4wHIEaZWJ1cmdlckBzdGFuZGFyZHN0cmFjay5jb20wDQYJKoZIhvcNAQELBQAD
ggEBAGYB/MbhzXClCc4fPctp4HBusRbgGt05ngOvKLih3vUY4xSG6FV+5BaRt5/MvnnIATlf/dxt
GBmeX3X124irtI2EIkd7xEStZlrSzDm3eIv0wW3DeKY8V9BlTKSmPO6sXl1qU8WJoNZvXOhs52do
Y4CTURs4uuttjbuEH3PQ32lO8M5lPqMnvj/qhGxh2Sg7mRop2kGitqLB6HHqGyh1t32SY16wWvPT
ovhq/38sPFamVK0FOC68LGxeKYD4KOf6GQkteQkQG+uqCEdpi4k2EwTtK43bVbeZ1rSzPMC5HRln
m+qPgE7ZWxBQlvdd5sQtBUz5Dl5lqj9kQ3YQz6XFNAMwggV0MIIEXKADAgECAhAnZu5W60nzjqvX
cKL8hN4iMA0GCSqGSIb3DQEBDAUAMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBB
QjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRy
dXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMDAwNTMwMTA0ODM4WhcNMjAwNTMwMTA0ODM4WjCBhTEL
MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlm
aWNhdGlvbiBBdXRob3JpdHkwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCR6FSS0gpW
sawNJN3Fz0RndJkrN6N9I3AAcbxT38T6KhKPS38QVr2fcHK3YX/JSw8Xpz3jsARh7v8Rl8f0hj4K
+j5c+ZPmNHrZFGvnnLOFoIJ6dq9xkNfs/Q36nGz637CC9BR++b7Epi9Pf5l/tfxnQ3K9DADWietr
LNPtj5gcFKt+5eNu/Nio5JIk2kNrYrhV/erBvGy2i/MOjZrkm2xpmfh4SDBF1a3hDTxFYPwyllEn
vGfDyi62a+pGx8cgoLEfZd5ICLqkTqnyg0Y3hOvozIFIQ2dOciqbXL1MGyiKXCJ7tKuY2e7gUYPD
CUZObT6Z+pUX2nwzV0E8jVHtC7ZcryxjGt9XyD+86V3Em69FmeKjWiS0uqlWPc9vqv9JWL7wqP/0
uK3pN/u6uPQLOvnoQ0IeidiEyxPx2bvhiWC4jChWrBQdnArncevPDt09qZahSL0896+1DSJMwBGB
7FY79tOi4lu3sgQiUpWAk2nojkxl8ZEDLXB0AuqLZxUpaVICu9ffUGpVRr+goyhhf3DQw6KqLCGq
R84onAZFdr+CGCe01a60y1Dma/RMhnEw6abfFobg2P9A3fvQQoh/ozM6LlweQRGBY84YcWsr7KaK
tzFcOmpH4MN5WdYgGq/yapiqcrxXStJLnbsQ/LBMQeXtHT1eKJ2czL+zUdqnR+WEUwIDAQABo4H0
MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBS7r34CPfqm8TyE
jq3uOJjs2TIy1DAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAIMAYG
BFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0
RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29j
c3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0BAQwFAAOCAQEAZL+D8V+ahdDNuKEpVw3oWvfR6T7y
dgRu8VJwux48/00NdGrMgYIl08OgKl1M9bqLoW3EVAl1x+MnDl2EeTdAE3f1tKwc0DurFxLW7zQY
fivpedOrV0UMryj60NvlUJWIu9+FV2l9kthSynOBvxzz5rhuZhEFsx6ULX+RlZJZ8UzOo5FxTHxH
DDsLGfahsWyGPlyqxC6Cy/kHlrpITZDylMipc6LrBnsjnd6i801Vn3phRZgYaMdeQGsj9Xl674y1
a4u3b0b0e/E9SwTYk4BZWuBBJB2yjxVgWEfb725G/RX12V+as9vYuORAs82XOa6Fux2OvNyHm9Gm
7/E7bxA4bzCCBeYwggPOoAMCAQICEGqb4Tg7/ytrnwHV2binUlYwDQYJKoZIhvcNAQEMBQAwgYUx
CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv
cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMSswKQYDVQQDEyJDT01PRE8gUlNBIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MB4XDTEzMDExMDAwMDAwMFoXDTI4MDEwOTIzNTk1OVowgZcxCzAJ
BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx
GjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBB
dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEAvrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6cpzEup/Y0dtmEatrQPTRI
5Or1u6zf+bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDIMypVpVSRsivlJTRENf+R
KwrB6vcfWlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYKjrc5NOpG9qrxpZxyb4o4
yNNwTqzaaPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRikw8lBoNoSWY66nJN/VCJv5ym6
Q0mdCbDKCMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsUtQIDAQABo4IBPDCCATgwHwYDVR0j
BBgwFoAUu69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0OBBYEFIKvbIz4xf6WYXzoHz0rcUhexIvA
MA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBM
BgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDZXJ0aWZp
Y2F0aW9uQXV0aG9yaXR5LmNybDBxBggrBgEFBQcBAQRlMGMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9j
cnQuY29tb2RvY2EuY29tL0NPTU9ET1JTQUFkZFRydXN0Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRw
Oi8vb2NzcC5jb21vZG9jYS5jb20wDQYJKoZIhvcNAQEMBQADggIBAHhcsoEoNE887l9Wzp+XVuyP
omsX9vP2SQgG1NgvNc3fQP7TcePo7EIMERoh42awGGsma65u/ITse2hKZHzT0CBxhuhb6txM1n/y
78e/4ZOs0j8CGpfb+SJA3GaBQ+394k+z3ZByWPQedXLL1OdK8aRINTsjk/H5Ns77zwbjOKkDamxl
pZ4TKSDMKVmU/PUWNMKSTvtlenlxBhh7ETrN543j/Q6qqgCWgWuMAXijnRglp9fyadqGOncjZjaa
SOGTTFB+E2pvOUtY+hPebuPtTbq7vODqzCM6ryEhNhzf+enm0zlpXK7q332nXttNtjv7VFNYG+I3
1gnMrwfHM5tdhYF/8v5UY5g2xANPECTQdu9vWPoqNSGDt87b3gXb1AiGGaI06vzgkejL580ul+9h
z9D0S0U4jkhJiA7EuTecP/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2aPY8ydehzuZutLbZdRJ5
PDEJM/1tyZR2niOYihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/GqK2HsOgkL3VYnwtx7cJU
mpvVdZ4ognzgXtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+85hFQzVxZx5/bRaTKTlL8
YXLI8nAbR9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYIDujCCA7YCAQEwga0wgZcx
CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv
cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEArjcdXJSJzt6Q3cf7cecpjDAJ
BgUrDgMCGgUAoIIB4TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0x
NTA3MTkxNzQzMjJaMCMGCSqGSIb3DQEJBDEWBBRKYImZEBpQmp6N35fQyaZig8Iw1TCBvgYJKwYB
BAGCNxAEMYGwMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy
MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0
Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAK43
HVyUic7ekN3H+3HnKYwwgcAGCyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkG
A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P
RE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24g
YW5kIFNlY3VyZSBFbWFpbCBDQQIRAK43HVyUic7ekN3H+3HnKYwwDQYJKoZIhvcNAQEBBQAEggEA
xzZhvEDXl8yCcdkTv4H2/C5RVYym/enl5vurSuXfYYhCr6W6rzUmgsq5cMcfH9L7ENsSupxleNm3
9fvlxxIM1fI9AZkNcwY4CkQVcZAJqY5/jLPB/HRKZBRqe6EmCQu5dNQ1Qve1nkwaDEnvlRWW50pb
vy4d7at43OYbizUUvqjjDDRdKay83Sm/Jn+r5tRZKS70dHd249dBrphy0vDCawWYVAB06OVKHhDO
sRRspyL6F1KBs32uyBnSAaMMGNarF1GwJ4kjRr3+hIEal0U2qzyLJSX+P/2r9nvn2d3X0QHprYfN
XIz80oersdj0rxG77dNRPwts4wnB2t2gu5WWwAAAAAAAAA==
--Apple-Mail=_0242BEA3-D689-479E-809A-15284C71BB24--


From nobody Mon Jul 20 03:22:38 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B76F1A1B1F for ; Mon, 20 Jul 2015 03:22:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.099
X-Spam-Level: *
X-Spam-Status: No, score=1.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 90RmHuNT-aGB for ; Mon, 20 Jul 2015 03:22:34 -0700 (PDT)
Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-hk2apc01on0131.outbound.protection.outlook.com [104.47.124.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB0B11A1B15 for ; Mon, 20 Jul 2015 03:22:33 -0700 (PDT)
Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;
Received: from [133.2.210.64] (133.2.210.64) by KAWPR01MB0129.jpnprd01.prod.outlook.com (10.161.26.21) with Microsoft SMTP Server (TLS) id 15.1.219.17; Mon, 20 Jul 2015 10:22:31 +0000
To: Eric Burger , "slim@ietf.org" 
References: <55A188FA.3030408@alum.mit.edu> <83D4C689-2121-4007-A5E7-AC1398262191@standardstrack.com>  <55A2C041.6070703@alum.mit.edu> <55A2DFB2.3090409@omnitor.se> <55A2E5C5.1090606@alum.mit.edu> <55A91EF4.7010505@alum.mit.edu> <55AAB1E9.9090202@omnitor.se> 
From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= 
Organization: Aoyama Gakuin University
Message-ID: <55ACCBE0.6040305@it.aoyama.ac.jp>
Date: Mon, 20 Jul 2015 19:22:24 +0900
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Originating-IP: [133.2.210.64]
X-ClientProxiedBy: OS1PR01CA0037.jpnprd01.prod.outlook.com (25.164.162.21) To KAWPR01MB0129.jpnprd01.prod.outlook.com (25.161.26.21)
X-Microsoft-Exchange-Diagnostics: 1; KAWPR01MB0129; 2:GdvwaZAXjBkSjBB2nhYtUU7KvirVpEIe+2PyY5JfT7/G9FTrOj8FTNVrjX2HEqBs; 3:F8tMKuC6+2SEO0cb9lUPODpXOLShGPZLCZpaiMxlMn0xoqMArCW9q4Jg4Lq1h1+jzly98GQqch7WSef+jlnhibzB6MgC3So8/GeAgzp+vdAfJ424wg1ToQA6zsW6IGGdKBKULlB6rqW7VPn5DE5G9Q==; 25:FmHHWfs0sFAx+Zd+juBLsYziJeSVOk7U5tx2sGma+/U6AAUUc5DOE/SfuYqcGNpgdJhE+urB+bHqQhFdYm2JI2tLhnEo0pD2o69Y/KyAtycys2aw5+gSLgq4y9Hr0Ctw6yE8Lwwscv2jGtP2XXx6ceFxOZ+1eSSrIAWCgzFJMcDIiXjMqcRqoXfAXDRVW1IAK4HA+wmhzytD7sBki6AArEnDFL9KWhzqZ1mmUU5UZC9Ctzk/CAOToU4TUlDOUiLO1cQ28cc7eYPcqQKOlVG9Bw==; 4:LL5r9CodLaDcUl5TIoNkOQhSalkIuEBqL+WuuGv6ty6bE6jPu9RdSW1Sky5QSWCRO/snanSPp4L9zH33Eqs2I3R5nl6D57FYKBMLS7nqFVZmzVRchLkulKa+07fX5aCZ3eCdOA+oWQr+hFPi9pqsZv7G0pBJ8tGTks40sWEyupTFNnzhYsADjF4BdkFoaf0HcTrxzNtxIY9GL5UJY15F++gY7Qg6OkEJmLeiBdsoUcpmzJ4KLwWyQQNZkZ8KJmUH+wgP+hqQDIhWqEjDiNXf4A==
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:KAWPR01MB0129;
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(5005006)(3002001);  SRVR:KAWPR01MB0129; BCL:0; PCL:0; RULEID:; SRVR:KAWPR01MB0129; 
X-Forefront-PRVS: 0643BDA83C
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(24454002)(377454003)(479174004)(50986999)(76176999)(54356999)(87976001)(80316001)(19580405001)(23676002)(86362001)(64126003)(19580395003)(50466002)(4001350100001)(92566002)(40100003)(5001960100002)(107886002)(77096005)(15975445007)(122386002)(46102003)(62966003)(77156002)(2950100001)(74482002)(2501003)(5001920100001)(189998001)(5001770100001)(65816999)(83506001)(42186005)(33656002)(93886004)(47776003)(65956001)(66066001)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:KAWPR01MB0129; H:[133.2.210.64]; FPR:; SPF:None; MLV:sfv; LANG:en; 
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtLQVdQUjAxTUIwMTI5OzIzOnZCVlhNNGNVaWtuenZIMlJPOVNnYnl3Nlpq?= =?utf-8?B?QUNwaEJ1Qnlockp1Zkx3a2w5V0owTzBzZi9zYXVhV3hqT0ZJUDdQZ2xNeWhx?= =?utf-8?B?blNSV0xickNQbHVRNTdsSWprU0hGbFVVazNTYSs0Mlc2UWpIVFRSbTlCUGxz?= =?utf-8?B?bFNXSTNYRnQzTWVjUW90Nk1XWml5elhtdFlYbjhic1M0NDBiNCtlVXlXVHpC?= =?utf-8?B?RThsQlFOT0ozaWFybkNhOFBsb3hWQnBMOEFQTEdSTXZFUzFLM1Vucm5lWlVq?= =?utf-8?B?VE5uQks0NitQZ01Ya2RyN2tyWUJMY3d2VGlIVE02RjJydHhGL3hkcmRyWWhQ?= =?utf-8?B?U282Y09JOXFLcGlyMVBUb2VjVzRSbm00c2ZaeW1nZ3FWaVhZNy9UWGRXVStM?= =?utf-8?B?Tnk1akk3OHRMeHdRUHprYkt5TXJnUmRsK2FnQWtrZk4zeUU5Wlg1VEZET3M2?= =?utf-8?B?UzYxWDF2NFZ3Q1FJODJFaW1lMkp1VTB3NDFZOTg3Q1hzNUV0TGFqRXBEYXBX?= =?utf-8?B?RE1xQTR6bkVSU3B6dzNlS0djcTFjMENyYjI0a0RESEVYQm10cGUyMmU1Nllp?= =?utf-8?B?NFh2c25BUFozK29La2dkaUExVk52WmdkYlp3MUNxN3B6ZnJ3aVJDeTh0RU0r?= =?utf-8?B?S1NCN0xnVy80eU96bWduNk9XOGFNZHhnaWJMM2VSZUlWb1Nqc2FpaDhSSnlo?= =?utf-8?B?SEVUbUlUbDU3TFRhckhpUW1yQnRibDdlTE5kMHR6RkVZUFI5dHZ3eE5uYktL?= =?utf-8?B?M0EzUXViVTVVa2tzYVhORTM1UkZVVytqQi9Ebi9SOWtqci9LTm1XbXRPQUN5?= =?utf-8?B?aWNVbSthcGNhWStvUlhkTXVzTytVT21YeDZqWWQ5N3NEZVM2dThJMzR6alVi?= =?utf-8?B?ZHlIYVVxWVFNcXV2QkVraW1HQlEvbzNHbkZaZlhqWUJ3SVd1NDN4eVZxMzdv?= =?utf-8?B?d3k1am90L01EQnBiTnhZbkl6c2dEMXEwajVad01oWmhMeE9jT0lSUVVGZXZw?= =?utf-8?B?L3RjbUthU2FzdHo0MUpBSDk3cUZNM3RPeEFlR3BGMmFjZWRFYXhaTzlSUWUr?= =?utf-8?B?WWwyd1BMbWkzai9OWXkxdHVtUHRTWE0xWmEzenhkWDJ0b2lYTXA1RzN1bDli?= =?utf-8?B?TFZSa1oybFlUQ29qbnhpYVZEZ204OEtjQUpuUXJIWWRhTmhpUVR5b3lSUGdp?= =?utf-8?B?eDVkU1Qybnp5dnhEVUY1Z1F4MEpXQS9sQ0dvaHBDRXRVMGt2U1hjREtDa09p?= =?utf-8?B?SlpVR1dWYlpYeW1rWldtNWpyMXFvMk0vRHlTVFZtT1NobDVMekdMczZGUWlL?= =?utf-8?B?MkMvZ1FzQWE3MEhxRXRVWnU2UjVFbnUwTlpLcHQxU3pVczQwR3MvamQyVFZQ?= =?utf-8?B?MXNDdHBFbTJzNXA4L0UrUkFsVkVsdSt2SFZRYVZ3WEZ1bWZxYzRROUZkWlVn?= =?utf-8?B?dTJqcU9kV2N5aElWUThmbFlWQlQ0MnVWcXhGc2ZpY1FBU1ErYWxuYjFMemdy?= =?utf-8?Q?CMHjFdpKqsmoo5OQ+bsGdKD5s=3D?=
X-Microsoft-Exchange-Diagnostics: 1; KAWPR01MB0129; 5:y/wdNNhR9a3tfXIWFpdxYMoAAxL2RnmZurceqefgIZ1X2Qfr3eT9FbEJeg6K5e/tIrhW0WXjwAiooJEbrQFFlTCsGOm3hL77Lz1dJpgUiBc/fPxhg8JQyeMHL2lvvBBiV6Qd1opSUeG2Vi8emm7OpQ==; 24:t/N6QfsKT7QQgBTHrNbFdOIlmfbjerea2QL7sbm3ifsou0eV9ruu1PUL8tFBl4Za1ugu0HrKg4akXHR4VSxglQaNghfNwCSvIdhtQhOVeYQ=; 20:TYBz3QjXxYaNU/kqIXvJwONRRNBeXZgKFixBloBEMpzugp9Q7IRlGhYTcj1dtnH5ev0mXFUQYQwMOc+rotW/7A==
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: it.aoyama.ac.jp
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jul 2015 10:22:31.3937 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: KAWPR01MB0129
Archived-At: 
Subject: Re: [Slim] Correlating media streams / roles for media streams
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Jul 2015 10:22:36 -0000

On 2015/07/20 02:43, Eric Burger wrote:
> What about business meetings? SLIM is for more than just emergency services. I can sort of follow French, so hearing the French before translation into English is of value to me.

I have also been at events where I listened to both channels to be able 
to catch translation errors and be able to intervene if they created a 
misunderstanding.

(I would never have been able to do simultaneous translation as well as 
the professional interpreter, but I was fluent in both languages and 
much more familiar with the subject matter.)

Regards,   Martin.

>> On Jul 18, 2015, at 4:07 PM, Gunnar Hellström  wrote:
>>
>> Example:  Spoken language interpreter between French and English. Taking spoken French as input replacing it with spoken English, and taking spoken English as input and replacing it with spoken French. For this service it is not feasible to just arrange a regular three-party bridged call, because then both the original speech and the translated speech will be heard mixed to the other user, and that is not desirable in most language translation situations.
>> This can also be worked out from SLIM language and modality indications from the users, but the resulting invocation of the translating service need to be a with a bridge with two audio streams between the bridge and the translating service. This can be done by using two coordinated calls, or one call with multiple streams of the language-carrying media.
>
>
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim
>


From nobody Mon Jul 20 04:00:25 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393151A1BB0 for ; Mon, 20 Jul 2015 04:00:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.52
X-Spam-Level: 
X-Spam-Status: No, score=-1.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=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 RlimveZSXEfS for ; Mon, 20 Jul 2015 04:00:22 -0700 (PDT)
Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) (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 EA7401A1BAF for ; Mon, 20 Jul 2015 04:00:21 -0700 (PDT)
Received: by qgeu79 with SMTP id u79so14765768qge.1 for ; Mon, 20 Jul 2015 04:00:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=78TTuyfBX9Wgm10mwwVUZEAIz25vJ6+PPoFkz/+xHRU=; b=IN972tYR815/TghJmklD8CZjVp3EKiq4o/IWRVSrJAvWArt6hfsj3VNSe2FLCI8MUL TpMR4WOnOJ/D9zXXOi+NyBw2KuRa98YBd+qZAWs2bJZuNKoLZu9ZIU43ydTpFfUq2qdc oSUMU1zCC9NrzVR4hD5B/J4bR9KaJeovSp73OUoJxISsQqflRY1XGk4Bs1DUpcAMRD5n 05ygQfgL8LeVxz4SVzrQwrpwc8kTN1p4nlG9h/x+o2+Zq5+FiKKx5/BwZQWLXSJxsyjl CKXJw59QqZN36lsYS1hkA5g2fHMKPHPxfnZPYeoD8a6vEikAAdv6wfznZM1ZaDYKIcNw icKQ==
X-Gm-Message-State: ALoCoQkoTH7x/fbkH4t5okH5GM5kw9ngAIP4qEECCMZE51XnnIOD4JPXboMnczN6gI4NBXWl64jk
X-Received: by 10.140.94.100 with SMTP id f91mr44403136qge.101.1437390021159;  Mon, 20 Jul 2015 04:00:21 -0700 (PDT)
Received: from mrichards3-ltw7.cis.neustar.com (neustargw.va.neustar.com. [209.173.53.233]) by smtp.gmail.com with ESMTPSA id y10sm3072314qgd.32.2015.07.20.04.00.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 Jul 2015 04:00:20 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_B48A49C8-F7B4-4559-A396-BAD6C81540BC"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: Brian Rosen 
In-Reply-To: <55ACCBE0.6040305@it.aoyama.ac.jp>
Date: Mon, 20 Jul 2015 13:00:18 +0200
Message-Id: <55925CF6-0FC0-4397-A8DE-EBF2B0E9B2FA@brianrosen.net>
References: <55A188FA.3030408@alum.mit.edu> <83D4C689-2121-4007-A5E7-AC1398262191@standardstrack.com>  <55A2C041.6070703@alum.mit.edu> <55A2DFB2.3090409@omnitor.se> <55A2E5C5.1090606@alum.mit.edu> <55A91EF4.7010505@alum.mit.edu> <55AAB1E9.9090202@omnitor.se>  <55ACCBE0.6040305@it.aoyama.ac.jp>
To: =?utf-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= 
X-Mailer: Apple Mail (2.2102)
Archived-At: 
Cc: "slim@ietf.org" 
Subject: Re: [Slim] Correlating media streams / roles for media streams
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Jul 2015 11:00:24 -0000

--Apple-Mail=_B48A49C8-F7B4-4559-A396-BAD6C81540BC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

So, I think that our original intent was to label what was desired, and =
not to specify the signaling that would be used to create the =
connections.  There are many, maybe even most cases, where we don=E2=80=99=
t need a signaling specification to get interoperability.  Proxies can =
and sometimes do route on what is contained in the SDP. =20

There are some cases where we might need some more specification for =
signaling.  Paul has suggested some ideas for the case where a proxy or =
B2BUA needs to create a translation where the result is a loop back =
(translated media comes back to where it is originally sent from).  =
While the SDP addresses are easily specified, it isn=E2=80=99t clear how =
to signal the request to translate.  As long as proxies can route on =
SDP, we can get most of what we want from  labeling what is desired.  =
Even the case where you want to invoke a translation service based on =
the non-overlapping set of options in the offer/answer can be solved =
simply because the translation service knows that all calls it gets at =
specified URIs are requests for translation. =20

I suggest that we keep the charter limited to labeling for now, finish =
that work and then recharter for any signaling use cases we come up =
with.  The labeling is really useful, and I=E2=80=99m not sure what =
other signaling mechanisms we will need beyond that loopback case.

Brian

> On Jul 20, 2015, at 12:22 PM, Martin J. D=C3=BCrst =
 wrote:
>=20
> On 2015/07/20 02:43, Eric Burger wrote:
>> What about business meetings? SLIM is for more than just emergency =
services. I can sort of follow French, so hearing the French before =
translation into English is of value to me.
>=20
> I have also been at events where I listened to both channels to be =
able to catch translation errors and be able to intervene if they =
created a misunderstanding.
>=20
> (I would never have been able to do simultaneous translation as well =
as the professional interpreter, but I was fluent in both languages and =
much more familiar with the subject matter.)
>=20
> Regards,   Martin.
>=20
>>> On Jul 18, 2015, at 4:07 PM, Gunnar Hellstr=C3=B6m =
 wrote:
>>>=20
>>> Example:  Spoken language interpreter between French and English. =
Taking spoken French as input replacing it with spoken English, and =
taking spoken English as input and replacing it with spoken French. For =
this service it is not feasible to just arrange a regular three-party =
bridged call, because then both the original speech and the translated =
speech will be heard mixed to the other user, and that is not desirable =
in most language translation situations.
>>> This can also be worked out from SLIM language and modality =
indications from the users, but the resulting invocation of the =
translating service need to be a with a bridge with two audio streams =
between the bridge and the translating service. This can be done by =
using two coordinated calls, or one call with multiple streams of the =
language-carrying media.
>>=20
>>=20
>>=20
>> _______________________________________________
>> SLIM mailing list
>> SLIM@ietf.org
>> https://www.ietf.org/mailman/listinfo/slim
>>=20
>=20
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org 
> https://www.ietf.org/mailman/listinfo/slim =


--Apple-Mail=_B48A49C8-F7B4-4559-A396-BAD6C81540BC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

So, I think that our original intent was to label what was =
desired, and not to specify the signaling that would be used to create =
the connections.  There are many, maybe even most cases, where we =
don=E2=80=99t need a signaling specification to get interoperability. =
 Proxies can and sometimes do route on what is contained in the =
SDP.  

There =
are some cases where we might need some more specification for =
signaling.  Paul has suggested some ideas for the case where a =
proxy or B2BUA needs to create a translation where the result is a loop =
back (translated media comes back to where it is originally sent from). =
 While the SDP addresses are easily specified, it isn=E2=80=99t =
clear how to signal the request to translate.  As long as proxies =
can route on SDP, we can get most of what we want from  labeling =
what is desired.  Even the case where you want to invoke a =
translation service based on the non-overlapping set of options in the =
offer/answer can be solved simply because the translation service knows =
that all calls it gets at specified URIs are requests for translation. =
 

I =
suggest that we keep the charter limited to labeling for now, finish =
that work and then recharter for any signaling use cases we come up =
with.  The labeling is really useful, and I=E2=80=99m not sure what =
other signaling mechanisms we will need beyond that loopback =
case.

Brian

On Jul 20, 2015, at 12:22 PM, =
Martin J. D=C3=BCrst <duerst@it.aoyama.ac.jp> wrote:

On 2015/07/20 02:43, Eric Burger =
wrote:
What about business meetings? SLIM is for more than =
just emergency services. I can sort of follow French, so hearing the =
French before translation into English is of value to me.

I have also been at events =
where I listened to both channels to be able to catch translation errors =
and be able to intervene if they created a misunderstanding.

(I would never have been able to do simultaneous =
translation as well as the professional interpreter, but I was fluent in =
both languages and much more familiar with the subject =
matter.)

Regards, =
  Martin.

On Jul 18, 2015, =
at 4:07 PM, Gunnar Hellstr=C3=B6m <gunnar.hellstrom@omnitor.se> wrote:

Example:  Spoken language interpreter between French and =
English. Taking spoken French as input replacing it with spoken English, =
and taking spoken English as input and replacing it with spoken French. =
For this service it is not feasible to just arrange a regular =
three-party bridged call, because then both the original speech and the =
translated speech will be heard mixed to the other user, and that is not =
desirable in most language translation situations.
This =
can also be worked out from SLIM language and modality indications from =
the users, but the resulting invocation of the translating service need =
to be a with a bridge with two audio streams between the bridge and the =
translating service. This can be done by using two coordinated calls, or =
one call with multiple streams of the language-carrying media.



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


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

=

--Apple-Mail=_B48A49C8-F7B4-4559-A396-BAD6C81540BC--


From nobody Mon Jul 20 11:05:02 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECEC41A1A4F for ; Mon, 20 Jul 2015 11:04:54 -0700 (PDT)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -5.112
X-Spam-Level: 
X-Spam-Status: No, score=-5.112 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 YBi8GO-b0NRA for ; Mon, 20 Jul 2015 11:04:53 -0700 (PDT)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FB441B2A41 for ; Mon, 20 Jul 2015 11:04:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1437415492; x=1468951492; h=message-id:in-reply-to:references:date:to:from:subject: content-transfer-encoding; bh=Y+4jTFSVXV/UC9ddnNMczF8u7YGeuZBVwYkaeblmYkI=; b=kSckhBTMRjzNmnd0rKm63FEcvP6akDRylB8YdhQ0l7sRrhjRUkqlMOT9 Tmrfe5JZkEFY7InXgg723P8MlhN8fAt2CCFvuCBqSTZY7hwytkMJIG+Sn lRjVRuIqoQCQUPHF2xQUk+ZrGsa9eY45krfiDqQq/K3G21KOdSNEyDmYk g=;
X-IronPort-AV: E=McAfee;i="5700,7163,7867"; a="128773068"
Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jul 2015 11:04:52 -0700
X-IronPort-AV: E=Sophos;i="5.15,509,1432623600"; d="scan'208";a="516096478"
Received: from plus.qualcomm.com ([10.52.255.8]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jul 2015 11:04:13 -0700
Received: from Ironmsg03-R.qualcomm.com (ironmsg03-R.qualcomm.com [172.30.46.17]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id t6KI4BkK002223; Mon, 20 Jul 2015 11:04:12 -0700
X-IronPort-AV: E=Sophos;i="5.15,509,1432623600"; d="scan'208";a="965551376"
X-ojodefuego: yes
Received: from unknown (HELO [130.129.14.251]) ([10.64.225.35]) by Ironmsg03-R.qualcomm.com with ESMTP; 20 Jul 2015 11:04:07 -0700
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References: 
X-Mailer: Eudora for Mac OS X
Date: Mon, 20 Jul 2015 09:16:08 -0700
To: slim@ietf.org
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Subject: Re: [Slim] Tuesday Lunch in Prague to discuss SLIM real-time & email (both)
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Jul 2015 18:04:55 -0000

To get to Caf=8E Imperial, exit the hotel lobby,=20
turn left to follow the driveway down to the=20
street, cross the street and continue.  At the=20
next street, which is a fairly big street with=20
streetcars, turn right, walk under the underpass,=20
and keep going.  The restaurant is two blocks=20
down on the right.

https://www.google.cz/maps/dir/Hilton+Prague+Hotel,+Pob%C5%99e%C5%BEn%C3%AD+=
1,+186+00+Praha+8/Caf%C3%A9+Imperial,+Na+Po%C5%99%C3%AD%C4%8D%C3%AD+15,+110+=
00+Praha+1/@50.0915465,14.4319304,16z/data=3D!3m1!4b1!4m13!4m12!1m5!1m1!1s0x=
470b94bebc825d65:0x3c034881ea713b97!2m2!1d14.439794!2d50.093322!1m5!1m1!1s0x=
470b949558c1bf45:0x9fea082416e2f3e9!2m2!1d14.4328883!2d50.0899095

At 6:23 AM -0700 7/17/15, Randall Gellens wrote:

>  The concierge has made a reservation for us at=20
> Caf=8E imperial (5-6 min walk), which is 100%=20
> non-smoking.
>
>  The is room for a few more people to join us.
>
>  Because this is not inside the hotel, I don't=20
> know if there will be Wi-Fi and hence if it=20
> will be possible for people to join remotely.=20
> The only hotel restaurant open for lunch=20
> permits smoking (although it's possible=20
> additional venues will be opened).
>
>  At 11:39 AM -0700 7/10/15, Randall Gellens wrote:
>
>>    It seems that Tuesday lunch works for=20
>> everyone interested in the SLIM real-time and=20
>> email work, so let's settle on that for both.=20
>> Please confirm your attendance to me today if=20
>> possible, and if we have enough I will reserve=20
>> a room at a restaurant in the hotel, so we can=20
>> talk and be heard.  If we can meet pretty=20
>> quickly after the morning session ends, we can=20
>> have time for both topics.
>>
>>    --
>>    Randall Gellens
>>    Opinions are personal;    facts are suspect;    I speak for myself onl=
y
>>    -------------- Randomly selected tag: ---------------
>>    I don't want to achieve immortality through my work....
>>    I want to achieve immortality by not dying.-
>>                                             --Woody Allen
>
>
>  --
>  Randall Gellens
>  Opinions are personal;    facts are suspect;    I speak for myself only
>  -------------- Randomly selected tag: ---------------
>  #Random Tag
>
>  --
>  Randall Gellens
>  Opinions are personal;    facts are suspect;    I speak for myself only
>  -------------- Randomly selected tag: ---------------
>  In examinations the foolish ask questions that the wise cannot answer.
>                                                         --Oscar Wilde
>
>  _______________________________________________
>  SLIM mailing list
>  SLIM@ietf.org
>  https://www.ietf.org/mailman/listinfo/slim



-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Ours is a world where people don't know what they want and are willing
to go through hell to get it.


From nobody Tue Jul 21 10:45:19 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E841A884D for ; Tue, 21 Jul 2015 10:45:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.688
X-Spam-Level: *
X-Spam-Status: No, score=1.688 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=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 QGX1WbqD6XFi for ; Tue, 21 Jul 2015 10:45:18 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 135121A88A3 for ; Tue, 21 Jul 2015 10:44:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default;  h=Mime-Version:To:Date:Message-Id:Subject:Content-Type:From; bh=TbNU9iYFeXrCNstibsTSeKFtWDZLo/SiGAGJhzynFS4=;  b=dJlEIyE6BiDqeiYr8yoHRkouZowK63FFEmlwYmHMr0LRbIO4+SqpAMluh2Wu6DSyafYxjJCxWhrsIJQ4ljZkEkpkjekrV2n6dBSNGIks8shec+MqkY4POSgMJAXkKfLn8XPFb5VEz/bx2C7vux3ZIyZ7GoMW5N0On3C/fBoH4Mk=;
Received: from [38.117.178.5] (port=63527 helo=[10.202.201.105]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZHbb0-0007ex-Hf for slim@ietf.org; Tue, 21 Jul 2015 10:44:52 -0700
From: Eric Burger 
Content-Type: multipart/signed; boundary="Apple-Mail=_A054ED4E-1C5E-4B3D-8CC5-D23B9D0AD6E0"; protocol="application/pkcs7-signature"; micalg=sha1
Message-Id: <9874942B-DB5E-4092-8C2B-7E159437B491@standardstrack.com>
Date: Tue, 21 Jul 2015 13:44:50 -0400
To: slim@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
X-Mailer: Apple Mail (2.2102)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.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: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
Archived-At: 
Subject: [Slim] Notes from lunch?
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Jul 2015 17:45:18 -0000

--Apple-Mail=_A054ED4E-1C5E-4B3D-8CC5-D23B9D0AD6E0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

Inquiring minds want to know...
--Apple-Mail=_A054ED4E-1C5E-4B3D-8CC5-D23B9D0AD6E0
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQpjCCBUAw
ggQooAMCAQICEQCuNx1clInO3pDdx/tx5ymMMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH
QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK
ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj
YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNDEwMDgwMDAwMDBaFw0xNTEwMDgyMzU5NTla
MCsxKTAnBgkqhkiG9w0BCQEWGmVidXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0HJR1ciLrHT/CjRECPUsdCrORWwHwf9AA9jE6tX8y8sqqrnY
jPw4YtahKkLP+3VLXEjTWLi9nl0ISFtrZ+sq27HUuPmaiNtjqWgCjyPjfUi5PEDiJE3CSR8CK8Z6
iLO09oNTlSLY6qmKxVB4MEp8rRvOYTDk4nC2wCgMRzpUXE8q44d8LPYSe1V1o4eSSRXby2gxrTMw
F/RLKGeSyB2ekee0c68FMZmfPR8kp43jM0SlZqgXLkf8ATTF9BxeznwqTC7GxXRJJi30d9dNQIl1
4M7J0c3kY7VpAHFXCh/KuNki0e6LKnhJrMXzVvou1OqCgI0xbCQJbMkjm8hXXxYU7wIDAQABo4IB
8DCCAewwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFK1jQ8667Bo+
kfpdpUC1bTmlMzGLMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG
AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEE
AbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYD
VR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0
aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUF
BzAChklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlv
bmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j
b20wJQYDVR0RBB4wHIEaZWJ1cmdlckBzdGFuZGFyZHN0cmFjay5jb20wDQYJKoZIhvcNAQELBQAD
ggEBAGYB/MbhzXClCc4fPctp4HBusRbgGt05ngOvKLih3vUY4xSG6FV+5BaRt5/MvnnIATlf/dxt
GBmeX3X124irtI2EIkd7xEStZlrSzDm3eIv0wW3DeKY8V9BlTKSmPO6sXl1qU8WJoNZvXOhs52do
Y4CTURs4uuttjbuEH3PQ32lO8M5lPqMnvj/qhGxh2Sg7mRop2kGitqLB6HHqGyh1t32SY16wWvPT
ovhq/38sPFamVK0FOC68LGxeKYD4KOf6GQkteQkQG+uqCEdpi4k2EwTtK43bVbeZ1rSzPMC5HRln
m+qPgE7ZWxBQlvdd5sQtBUz5Dl5lqj9kQ3YQz6XFNAMwggV0MIIEXKADAgECAhAnZu5W60nzjqvX
cKL8hN4iMA0GCSqGSIb3DQEBDAUAMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBB
QjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRy
dXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMDAwNTMwMTA0ODM4WhcNMjAwNTMwMTA0ODM4WjCBhTEL
MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlm
aWNhdGlvbiBBdXRob3JpdHkwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCR6FSS0gpW
sawNJN3Fz0RndJkrN6N9I3AAcbxT38T6KhKPS38QVr2fcHK3YX/JSw8Xpz3jsARh7v8Rl8f0hj4K
+j5c+ZPmNHrZFGvnnLOFoIJ6dq9xkNfs/Q36nGz637CC9BR++b7Epi9Pf5l/tfxnQ3K9DADWietr
LNPtj5gcFKt+5eNu/Nio5JIk2kNrYrhV/erBvGy2i/MOjZrkm2xpmfh4SDBF1a3hDTxFYPwyllEn
vGfDyi62a+pGx8cgoLEfZd5ICLqkTqnyg0Y3hOvozIFIQ2dOciqbXL1MGyiKXCJ7tKuY2e7gUYPD
CUZObT6Z+pUX2nwzV0E8jVHtC7ZcryxjGt9XyD+86V3Em69FmeKjWiS0uqlWPc9vqv9JWL7wqP/0
uK3pN/u6uPQLOvnoQ0IeidiEyxPx2bvhiWC4jChWrBQdnArncevPDt09qZahSL0896+1DSJMwBGB
7FY79tOi4lu3sgQiUpWAk2nojkxl8ZEDLXB0AuqLZxUpaVICu9ffUGpVRr+goyhhf3DQw6KqLCGq
R84onAZFdr+CGCe01a60y1Dma/RMhnEw6abfFobg2P9A3fvQQoh/ozM6LlweQRGBY84YcWsr7KaK
tzFcOmpH4MN5WdYgGq/yapiqcrxXStJLnbsQ/LBMQeXtHT1eKJ2czL+zUdqnR+WEUwIDAQABo4H0
MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBS7r34CPfqm8TyE
jq3uOJjs2TIy1DAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAIMAYG
BFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0
RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29j
c3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0BAQwFAAOCAQEAZL+D8V+ahdDNuKEpVw3oWvfR6T7y
dgRu8VJwux48/00NdGrMgYIl08OgKl1M9bqLoW3EVAl1x+MnDl2EeTdAE3f1tKwc0DurFxLW7zQY
fivpedOrV0UMryj60NvlUJWIu9+FV2l9kthSynOBvxzz5rhuZhEFsx6ULX+RlZJZ8UzOo5FxTHxH
DDsLGfahsWyGPlyqxC6Cy/kHlrpITZDylMipc6LrBnsjnd6i801Vn3phRZgYaMdeQGsj9Xl674y1
a4u3b0b0e/E9SwTYk4BZWuBBJB2yjxVgWEfb725G/RX12V+as9vYuORAs82XOa6Fux2OvNyHm9Gm
7/E7bxA4bzCCBeYwggPOoAMCAQICEGqb4Tg7/ytrnwHV2binUlYwDQYJKoZIhvcNAQEMBQAwgYUx
CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv
cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMSswKQYDVQQDEyJDT01PRE8gUlNBIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MB4XDTEzMDExMDAwMDAwMFoXDTI4MDEwOTIzNTk1OVowgZcxCzAJ
BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx
GjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBB
dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEAvrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6cpzEup/Y0dtmEatrQPTRI
5Or1u6zf+bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDIMypVpVSRsivlJTRENf+R
KwrB6vcfWlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYKjrc5NOpG9qrxpZxyb4o4
yNNwTqzaaPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRikw8lBoNoSWY66nJN/VCJv5ym6
Q0mdCbDKCMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsUtQIDAQABo4IBPDCCATgwHwYDVR0j
BBgwFoAUu69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0OBBYEFIKvbIz4xf6WYXzoHz0rcUhexIvA
MA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBM
BgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDZXJ0aWZp
Y2F0aW9uQXV0aG9yaXR5LmNybDBxBggrBgEFBQcBAQRlMGMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9j
cnQuY29tb2RvY2EuY29tL0NPTU9ET1JTQUFkZFRydXN0Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRw
Oi8vb2NzcC5jb21vZG9jYS5jb20wDQYJKoZIhvcNAQEMBQADggIBAHhcsoEoNE887l9Wzp+XVuyP
omsX9vP2SQgG1NgvNc3fQP7TcePo7EIMERoh42awGGsma65u/ITse2hKZHzT0CBxhuhb6txM1n/y
78e/4ZOs0j8CGpfb+SJA3GaBQ+394k+z3ZByWPQedXLL1OdK8aRINTsjk/H5Ns77zwbjOKkDamxl
pZ4TKSDMKVmU/PUWNMKSTvtlenlxBhh7ETrN543j/Q6qqgCWgWuMAXijnRglp9fyadqGOncjZjaa
SOGTTFB+E2pvOUtY+hPebuPtTbq7vODqzCM6ryEhNhzf+enm0zlpXK7q332nXttNtjv7VFNYG+I3
1gnMrwfHM5tdhYF/8v5UY5g2xANPECTQdu9vWPoqNSGDt87b3gXb1AiGGaI06vzgkejL580ul+9h
z9D0S0U4jkhJiA7EuTecP/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2aPY8ydehzuZutLbZdRJ5
PDEJM/1tyZR2niOYihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/GqK2HsOgkL3VYnwtx7cJU
mpvVdZ4ognzgXtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+85hFQzVxZx5/bRaTKTlL8
YXLI8nAbR9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYIDujCCA7YCAQEwga0wgZcx
CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv
cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEArjcdXJSJzt6Q3cf7cecpjDAJ
BgUrDgMCGgUAoIIB4TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0x
NTA3MjExNzQ0NTJaMCMGCSqGSIb3DQEJBDEWBBQv1NKyrGb+1WcI0gHR1XnWD1xURDCBvgYJKwYB
BAGCNxAEMYGwMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy
MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0
Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAK43
HVyUic7ekN3H+3HnKYwwgcAGCyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkG
A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P
RE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24g
YW5kIFNlY3VyZSBFbWFpbCBDQQIRAK43HVyUic7ekN3H+3HnKYwwDQYJKoZIhvcNAQEBBQAEggEA
ZAPFYK2HyCbM3TmBxHmBgyGdsRmwQ5TkX1w6BtnIvM/AbaL7jwPRz2DQYvXWpgKWSMWmPYAOffbM
bbrsuXkORXB7hUCibUPN5ehZLh6tCew0C6l3qZZaG7k/dptypT67J6gZgwwzzLL/pGn1Q4ojP2mG
Y4E0OFEH5txCbpS4IPb0YLlCTS0qAzJcOtd/fpm64E8bgdf7nhXXJj8b+PF4OnqOO9ZLFyjYhkk/
DH2NWaU0/UMAq/5Ic3B4hr6lGn0z+kKH+Vw8Xi14xfu6eQ+PbeeLAESKW4QAajEqps+1xKBlZDxm
kzDlQ1XJOmLPVAsF71iZqsOfLPQWAvO5WjQbsQAAAAAAAA==
--Apple-Mail=_A054ED4E-1C5E-4B3D-8CC5-D23B9D0AD6E0--


From nobody Wed Jul 22 00:47:10 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 964981ACE3E for ; Wed, 22 Jul 2015 00:47:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.821
X-Spam-Level: 
X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham
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 d8tlUSvblg0z for ; Wed, 22 Jul 2015 00:47:07 -0700 (PDT)
Received: from mail-qk0-f180.google.com (mail-qk0-f180.google.com [209.85.220.180]) (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 D5C9A1ACE24 for ; Wed, 22 Jul 2015 00:47:06 -0700 (PDT)
Received: by qkfc129 with SMTP id c129so105656689qkf.1 for ; Wed, 22 Jul 2015 00:47:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=mv7zTtuviExphSUixLsIlOfcp9minGPDjROyLfS82DM=; b=g4ApXN+hs3LS6WdkJ5lDFpaXhdv3NwwZyRPBVOQOQyOZeC6Ifj8B66SRmPmrI0BXHN jluAwhodv/6GT6hVqarKRno/SbV3GBVRMDQvsmUe3+EUKG2CqFGSqbDehtN6fEhjIDc1 laBJlhuDB8qcvIpfk+ut6HFjbA1cC2Hpx6FVizQ6dGyTj1HOOga4/RQg3RCftfBsTvr3 E9BZs6Y9cEF0OUxQFXFEbHKllvx2po902YaTiEI1tbBaUAT/4Ei9j5UB1Bey4lRBTrmr 5CLarQzdZf7XwifE0151A3GpI2yiMbeC9ehPiSMkaIzgH76LWJnUGK3xSmfH9gR8QyKx +Jfg==
X-Gm-Message-State: ALoCoQmyBizR2ZDLWNRDffp877UjaDA4ayvHn6k1yYg42Tx6WEMhZTWHLZgTZRxp4A0e2ckRjLy1
X-Received: by 10.55.20.72 with SMTP id e69mr1510372qkh.63.1437551226170; Wed, 22 Jul 2015 00:47:06 -0700 (PDT)
Received: from mrichards3-ltw7.cis.neustar.com (neustargw.va.neustar.com. [209.173.53.233]) by smtp.gmail.com with ESMTPSA id p15sm313289qkh.10.2015.07.22.00.47.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Jul 2015 00:47:05 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: Brian Rosen 
In-Reply-To: <9874942B-DB5E-4092-8C2B-7E159437B491@standardstrack.com>
Date: Wed, 22 Jul 2015 09:46:54 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <43B9F9AD-52C2-451A-9A50-B206FFAE3568@brianrosen.net>
References: <9874942B-DB5E-4092-8C2B-7E159437B491@standardstrack.com>
To: Eric Burger 
X-Mailer: Apple Mail (2.2102)
Archived-At: 
Cc: slim@ietf.org
Subject: Re: [Slim] Notes from lunch?
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jul 2015 07:47:08 -0000

I can give you the bottom line, which is really a summary of what =
transpired in ecrit and in the meeting at lunch:

We=E2=80=99re going to do negotiation of media (=E2=80=9Clabeling=E2=80=9D=
) first, and recharter for signaling, with discussion of signaling =
allowed now.
We=E2=80=99ll pull all the routing text out of the real-time draft.
We will explicitly limit to the 80% cases, and we will document use =
cases in a work group wiki.  We=E2=80=99re not going to try to cover =
corner cases.

Brian

> On Jul 21, 2015, at 7:44 PM, Eric Burger  =
wrote:
>=20
> Inquiring minds want to =
know..._______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim


From nobody Wed Jul 22 01:04:05 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05C9C1B3028 for ; Wed, 22 Jul 2015 01:03:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 7rYfOLx5-Ccc for ; Wed, 22 Jul 2015 01:03:56 -0700 (PDT)
Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AA9B1B30C8 for ; Wed, 22 Jul 2015 01:03:56 -0700 (PDT)
Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-03v.sys.comcast.net with comcast id vL3v1q0012S2Q5R01L3vSd; Wed, 22 Jul 2015 08:03:55 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-16v.sys.comcast.net with comcast id vL3v1q0023Ge9ey01L3vju; Wed, 22 Jul 2015 08:03:55 +0000
Message-ID: <55AF4E6A.3060401@alum.mit.edu>
Date: Wed, 22 Jul 2015 04:03:54 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: slim@ietf.org
References: <9874942B-DB5E-4092-8C2B-7E159437B491@standardstrack.com> <43B9F9AD-52C2-451A-9A50-B206FFAE3568@brianrosen.net>
In-Reply-To: <43B9F9AD-52C2-451A-9A50-B206FFAE3568@brianrosen.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1437552235; bh=utaPoufv5TMs/AgpUre1v9t/jxsS/5AmsnQIfWe/P+4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=CDY+2CTpk42q3S08PHJ5DxRT3rdBaemGudZBJmZx5w/V9D+R5UoJf1JmqUJEspO7m NoQ/JF5NxAWDmaffGi4xT/e+SMYwwGc4LINFDj80XfJtzKhpiyaMTuY5cPY+tZZa3Z X3xzqBUtlwOJMj5RZv7f0HzYyCt80+VAJiNuQndYcJCd+ENQqgIVv9MhuxQ7Y5dw+/ j8gxJiGLereo+ETd9JV5VbLTdNcI+44YmXEp7bRoLxIx82/WowWS7wARgHj7sufAtw ZbspntpDCWVc1/qRDl/zzCBIgUdBtp3838YC6RiSjl466+eL4rw1qJYeTNtUw18X7U ruzg9A/FqKa3Q==
Archived-At: 
Subject: Re: [Slim] Notes from lunch?
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jul 2015 08:03:57 -0000

On 7/22/15 3:46 AM, Brian Rosen wrote:

> We will explicitly limit to the 80% cases, and we will document use cases in a work group wiki.  We’re not going to try to cover corner cases.

What does that mean? What is and isn't a corner case?

	Thanks,
	Paul


From nobody Wed Jul 22 01:22:38 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A22C91A0137 for ; Wed, 22 Jul 2015 01:22:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.821
X-Spam-Level: 
X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham
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 UHiSE2SMOerT for ; Wed, 22 Jul 2015 01:22:35 -0700 (PDT)
Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com [209.85.192.53]) (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 CA7361A009D for ; Wed, 22 Jul 2015 01:22:34 -0700 (PDT)
Received: by qgeu79 with SMTP id u79so43728562qge.1 for ; Wed, 22 Jul 2015 01:22:34 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=MFZGFOrPnSSbJOqtympRB5p5m5nR1mehv49Lk3+UJdg=; b=kmlmIluCC1kdE6nTfSQHnAXubtV+BCCpi/6XQUo03IMk+wSc7NM3hQnsPKyhjLr6EH hWy56zmDEZdvypOpoJfn+UeFn7PHcjXf+swxhP0L4/T5jh2ec/s78YtrqmU9kI1HiKsO 8q1iImcVau+qJEcU7cJkUVaHqMPHAkAZCYCwX+fIzqyFqZC0in/oJmNWaPFeIu9+AQhk mmshS1kFYnGMq8RpGb8lSF6rOEPKY22w7LWpCY91Y+a5LSqKrACzs7DdVwwOFoc9Xi+J S4Kt078h0jAq1+etyJ/eQThRmBxnbNaoDYj83RkLqRUHpLbvyQuVGJbLQgjgwoRr1onp 7KPQ==
X-Gm-Message-State: ALoCoQm2YIyCHxYMdUqKerRGqwzfGbirlxdcnG0IiMIMeSYxBFVNTZBjLtjQa/wPnPMtdSoSteiC
X-Received: by 10.55.22.5 with SMTP id g5mr1648284qkh.45.1437553354096; Wed, 22 Jul 2015 01:22:34 -0700 (PDT)
Received: from mrichards3-ltw7.cis.neustar.com (neustargw.va.neustar.com. [209.173.53.233]) by smtp.gmail.com with ESMTPSA id 100sm346737qky.5.2015.07.22.01.22.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Jul 2015 01:22:33 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: Brian Rosen 
In-Reply-To: <55AF4E6A.3060401@alum.mit.edu>
Date: Wed, 22 Jul 2015 10:22:28 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <876E1759-F61F-4052-A413-29D085D23A9E@brianrosen.net>
References: <9874942B-DB5E-4092-8C2B-7E159437B491@standardstrack.com> <43B9F9AD-52C2-451A-9A50-B206FFAE3568@brianrosen.net> <55AF4E6A.3060401@alum.mit.edu>
To: Paul Kyzivat 
X-Mailer: Apple Mail (2.2102)
Archived-At: 
Cc: slim@ietf.org
Subject: Re: [Slim] Notes from lunch?
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jul 2015 08:22:36 -0000

Two examples:
PSAPs engaging a French language translation service - in scope

I prefer ASL video, with english text, I could handle spanish text =
(only), but if all you can handle is French text + audio, then I need =
ASL to english audio translated to French, plus French text - corner =
case.

I assume work group consensus would determine if a given proposed use =
case is a corner case or not.

Brian

> On Jul 22, 2015, at 10:03 AM, Paul Kyzivat  =
wrote:
>=20
> On 7/22/15 3:46 AM, Brian Rosen wrote:
>=20
>> We will explicitly limit to the 80% cases, and we will document use =
cases in a work group wiki.  We=E2=80=99re not going to try to cover =
corner cases.
>=20
> What does that mean? What is and isn't a corner case?
>=20
> 	Thanks,
> 	Paul
>=20
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim


From nobody Wed Jul 22 01:24:35 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E251A0267 for ; Wed, 22 Jul 2015 01:24:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.588
X-Spam-Level: 
X-Spam-Status: No, score=-3.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 rsOjmAyq33xr for ; Wed, 22 Jul 2015 01:24:32 -0700 (PDT)
Received: from millet.cc.columbia.edu (millet.cc.columbia.edu [128.59.72.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 916981A009D for ; Wed, 22 Jul 2015 01:24:32 -0700 (PDT)
Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by millet.cc.columbia.edu (8.13.8/8.13.8) with ESMTP id t6M8NnBV009439 for ; Wed, 22 Jul 2015 04:24:31 -0400
Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id 8701E6D for ; Wed, 22 Jul 2015 04:24:31 -0400 (EDT)
Received: from rambutan.cc.columbia.edu (rambutan.cc.columbia.edu [128.59.29.5]) by hazelnut (Postfix) with ESMTP id 703216D for ; Wed, 22 Jul 2015 04:24:31 -0400 (EDT)
Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by rambutan.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id t6M8OUXc022342 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 22 Jul 2015 04:24:31 -0400 (EDT)
Received: by iecri3 with SMTP id ri3so66871072iec.2 for ; Wed, 22 Jul 2015 01:24:30 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MowFe7U/cqGOSP5wWp8av1YcQZ4CmjuVPnK375lwWy0=; b=PIPC6F54tQ+TcGPwqY0Wm9cIATHXaXOj6OTCcXaJDFu1u/9vkvkjcbLKEk9xUb+FJX cSES3ImeYnuYV6oLO//r8dpYIctNWAvLfYlBz9Z4HpdRMwbnWl8GSuj3wh1MwPtiYjmy cak62Wq+xAPpJn7YbqUCaYe5YlOHOVhIpGSgiXgu7XQfZGkUpjNAvI60FSvfcifXWT6o hLu93yon7jI25znvU5G5vlhHAP2vlGN44VPHV3pusdmWYQy+XYKpuevNiLmsQLi4HG/q X0LP7eVo1yfu3kNhTwxjnRw5/R5cqhe4OvB79UMIlaiXuwsGBsVl5h3n2o6vRToCOEpu cIFg==
X-Gm-Message-State: ALoCoQk74mmJY/ZTLE+7MgfmLebYm+6DTDBvUClu5NuUUPXdI3GZOjbnfJfEQIaWcNVbT+JVD3mfwGCRatwP3bJVECojt3lyQYg9h2conu938D7FKQIPyTUavesueWV3ldqg4ma5Dp9K
X-Received: by 10.50.17.104 with SMTP id n8mr32130380igd.21.1437553470867; Wed, 22 Jul 2015 01:24:30 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.17.104 with SMTP id n8mr32130368igd.21.1437553470742; Wed, 22 Jul 2015 01:24:30 -0700 (PDT)
Received: by 10.36.120.69 with HTTP; Wed, 22 Jul 2015 01:24:30 -0700 (PDT)
In-Reply-To: <55AF4E6A.3060401@alum.mit.edu>
References: <9874942B-DB5E-4092-8C2B-7E159437B491@standardstrack.com> <43B9F9AD-52C2-451A-9A50-B206FFAE3568@brianrosen.net> <55AF4E6A.3060401@alum.mit.edu>
Date: Wed, 22 Jul 2015 04:24:30 -0400
Message-ID: 
From: Henning Schulzrinne 
To: Paul Kyzivat 
Content-Type: multipart/alternative; boundary=089e0118398af84687051b727f53
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.68 on 128.59.29.5
Archived-At: 
Cc: slim@ietf.org
Subject: Re: [Slim] Notes from lunch?
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jul 2015 08:24:34 -0000

--089e0118398af84687051b727f53
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

We talked about some examples of cases as being "center" and "corner":

(1) "center": customer trying to indicate that they prefer to speak Spanish
when contacting call center;
caller indicating preference for ASL when calling an emergency number

(2) "corner": simultaneous interpretation case where somebody wants to
receive both Spanish and English; complex ordering of preferences ("I am a
native speaker of English; fluent in Spanish and can read a menu in
Swedish"; "I can understand (orally) Latin, but not speak it"; "I rate my
preference for English, Spanish and Swedish as 9, 7 and 3.5")

There's obviously no problem if the corner case happens to work, but no
extra effort (syntax, complexity) will be expended to make them work. The
center-corner cut-off may also differ for routing and intra-UAS (SDP) cases
since it seems reasonable to assume that routing is more coarse-grained and
has less information about the current (right now), precise capabilities of
the end point.

Henning

On Wed, Jul 22, 2015 at 4:03 AM, Paul Kyzivat  wrote=
:

> On 7/22/15 3:46 AM, Brian Rosen wrote:
>
>  We will explicitly limit to the 80% cases, and we will document use case=
s
>> in a work group wiki.  We=E2=80=99re not going to try to cover corner ca=
ses.
>>
>
> What does that mean? What is and isn't a corner case?
>
>         Thanks,
>         Paul
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim
>

--089e0118398af84687051b727f53
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


We talked about some examples of cases as being "cent=
er" and "corner":

(1) "center":=
 customer trying to indicate that they prefer to speak Spanish when contact=
ing call center;
caller indicating preference for ASL when callin=
g an emergency number

(2) "corner": simu=
ltaneous interpretation case where somebody wants to receive both Spanish a=
nd English; complex ordering of preferences ("I am a native speaker of=
 English; fluent in Spanish and can read a menu in Swedish"; "I c=
an understand (orally) Latin, but not speak it"; "I rate my prefe=
rence for English, Spanish and Swedish as 9, 7 and 3.5")
There's obviously no problem if the corner case happens to =
work, but no extra effort (syntax, complexity) will be expended to make the=
m work. The center-corner cut-off may also differ for routing and intra-UAS=
 (SDP) cases since it seems reasonable to assume that routing is more coars=
e-grained and has less information about the current (right now), precise c=
apabilities of the end point.

Henning
<=
div class=3D"gmail_extra">
On Wed, Jul 22, 20=
15 at 4:03 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrot=
e:
On 7/22/15 3:46 AM, Brian Rosen wrote:=






We will explicitly limit to the 80% cases, and we will document use cases i=
n a work group wiki.=C2=A0 We=E2=80=99re not going to try to cover corner c=
ases.





What does that mean? What is and isn't a corner case?



=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul



_______________________________________________

SLIM mailing list

SLIM@ietf.org

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





--089e0118398af84687051b727f53--


From nobody Wed Jul 22 01:52:36 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC4DC1ACEE0 for ; Wed, 22 Jul 2015 01:52:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.299
X-Spam-Level: 
X-Spam-Status: No, score=0.299 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 dSdzkFGYCcze for ; Wed, 22 Jul 2015 01:52:31 -0700 (PDT)
Received: from bin-vsp-out-02.atm.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 167421ACED3 for ; Wed, 22 Jul 2015 01:52:30 -0700 (PDT)
X-Halon-ID: f8e6c9b9-304e-11e5-bc2f-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.43.70] (unknown [2.67.176.197]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Wed, 22 Jul 2015 10:52:24 +0200 (CEST)
To: slim@ietf.org
References: <9874942B-DB5E-4092-8C2B-7E159437B491@standardstrack.com> <43B9F9AD-52C2-451A-9A50-B206FFAE3568@brianrosen.net> <55AF4E6A.3060401@alum.mit.edu> 
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <55AF59C7.605@omnitor.se>
Date: Wed, 22 Jul 2015 10:52:23 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------050708010505090301060507"
Archived-At: 
Subject: Re: [Slim] Notes from lunch? + Requirements
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jul 2015 08:52:36 -0000

This is a multi-part message in MIME format.
--------------050708010505090301060507
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Can we agree to include this proposed requirements chapter and from this 
proposal identify what should be added or deleted to get the center 
cases included and the corner cases either excluded or just enabled by 
chance? ( a few excluded corner cases are listed in the last subsection.)
I have not changed the chapter after the discussion about coordination 
of languages and modalities in different streams that Paul introduced. I 
am not sure about if that discussion belongs here or not.

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

X. Requirements.
------------------------
The system for indication of preferences and capabilities shall meet the 
following requirements:

It shall enable negotiation of media, modalities and languages for a SIP 
session.

It shall be possible to use it during initiation and modification of a 
session.

The system shall consist of a set of indications and usage rules 
specified in this specification and other specifications.

The system shall enable a caller to indicate the media, modalities, 
languages and assisting services that the caller prefers to use during a 
real-time session that is about to be established or modified.

Entities involved in selecting callees and callees shall be enabled to 
view the caller preferences in order to select a callee of many, or 
adjust the set of media, modalities, languages and services provided in 
the session.

The caller shall be provided with indication of the resulting media, 
modalities, languages and services enabled during the session.

X.1 General
------------
It shall be possible to express capabilities and preferences with its 
transmission direction, for transmission or reception or bidirectional 
from the viewpoint of the entity sending the indication.

The indications shall be suitable for setting in personal profiles, in 
service profiles, or in terminal settings, and possible to adjust at 
session initiation time.

It shall be possible to present the outcome of exchange of the 
indications to users in the session.

X.2 Media indications.
-------------------------

It shall be possible to use the indications for audio, video and 
real-time text media.  ( and text messages????)

X.3 Modality indications.
----------------------------
It shall be possible to use indications for speech and hearing in audio 
media.

It shall be possible to use indications for transmitting text and 
receiving text in real-time text media.

( ???  It shall be possible to use indications for transmitting text 
messages and receiving text messages in text messaging media. ???)

It shall be possible to use indications for expressing sign language and 
perceiving sign language in video media.

It shall be possible to use indications for showing a speaker and for 
seeing a speaker in video media.

X.4 Service indications.
--------------------------
It shall be possible to use indications of type of and address of and 
state of invocation of an assisting service available for supporting the 
communication.

X.5 Language indications.
-----------------------------
It shall be possible to indicate ability to express language in a number 
of languages from the ones listed in the language tags of RFC 5646.

It shall be possible to indicate ability to perceive language in a 
number of languages from the ones listed in the language tags of RFC 5646.

The language indication shall be associated with a specific media, 
modality and direction.

It shall be possible to indicate ability to express language in an 
unspecified language, meaning a default for a region in the associated 
modality.

It shall be possible to indicate ability to perceive language in an 
unspecified language, meaning a default for a region in the associated 
modality.

It shall be possible to indicate use of media without any specific 
intention to use the medium for language communication.

X.6 Indication of level of preference or capability
--------------------------------------------------------
It shall be possible to indicate an absolute level of preference or 
capability to use a language, modality, media and direction combination 
with a coarse grading.
For preference, the grading shall at least be able to indicate strong 
preference vs can use vs possible fall back usage.
For capability, the grading shall at least be able to indicate good 
capability vs some capability vs limited capability.
Capability and preference shall use the same coding, the difference is 
only in the role of the entity providing the indication. Call parties 
express preferences, service providers express capabilities.

More than one direction/media/modality/language preference or capability 
can be expressed per level.

It shall be possible for a caller to express if the session should be 
set up or not if no matching direction/media/modality/language 
indications are found.

X.7 Type and quality indications
-------------------------------------
It shall be possible to indicate preference and capability of different 
types of real-time text production: conversational type versus 
captioning type. Conversational type is generated by the transmitting 
party in the session, or by a communications agent with moderate 
requirements on delay. Captioning type is generated as captions to 
another modality in the same session with low delay from the expression 
in the other modality. The original modality for captions can be speech 
or sign language.

It shall be possible to indicate with language indications if it is 
original or interpreted or artificially created contents.

In order to enable communication with persons who have speech that is 
weak or hard to understand, the following quality indications can be used:
     -It shall be possible to indicate that the quality of the expressed 
speech makes it hard to understand.
     -It shall be possible to indicate a capability to undertand speech 
that is weak or hard to understand.

In order to enable communication with persons who need cognitive support 
in the form of reminders or notetaking, the following quality 
indications can be used:
     -It shall be possible to indicate need of reminders or notetaking 
during a session.
     -It shall be possible to indicate a capability to provide reminders 
or take notes during a session.


X.8 Details of service indications
----------------------------------------
The user expressing the indications may be a frequent user of an 
assisting service, that supports the commuication in some often 
occurring need for modality or language translation. By indicating this 
service, a receiver of the indication can judge if invocation of that 
service will support matching of preferences and capabilities. Common 
assiting service types are relay service and language translation service.

The services are specified with service type, service address, 
invocation state and languages.
Possible service types are:
     Spoken language translation service translating between different 
spoken languages.
     Video relay service translating between sign language in video and 
speech in audio.
     Text relay service translating between text in real-time text and 
speech in audio.  ( even between text messages and audio exist )
     Captioned telephony adding real-time text in one direction to speech.
     Speech-to-speech adding clear speech when needed to speech that is 
weak or hard to understand
     Cognitive support adding reminders or memory notes to speech 
conversation ususlly in combination with the speech-to-speech service.

Service address shall be a URI where the service can be reached with one 
session for provision of the service within the media of that session.
(note that this is different from how most current relay services today 
work. They often have two call legs, one with an audio call and one with 
a multimedia call. )

Invocation state shall indicate if the service is already included in 
the call, and if so, the media/modality/language indications show the 
joint capabilities.
Invocation state can also contain a request to the other party to invoke 
the service if needed to complement the capabilities to achieve a 
functioning communication. This indication can be provided either by the 
offering or answering party.

Languages shall be media/modality/language indications in pairs showing 
the capabilities of the service.


X.9 Use in session establishment and modification
-------------------------------------------------------------
The indications shall be included in session offer / answer exchange.

Already specified ways to express media/modality/language shall be 
possible to use to the extent that they are usable.
That includes media and language tags on SIP level and media 
specifications and language tags on SDP level. For cases when these 
existing means imply limitations, these limitations shall be explained.

The method for identification of language preferences and capabilities 
in this specification is intended mainly for rapid ad-hoc session 
establishment and not intended to have the same ambitions as CLUE has 
for planned telepresence sessions.

The indications included in the offer shall represent the preferences 
and capabilities of the offering party.

The indications included in the answer shall represent the preferences 
and capabilities of the answering party actually planned to be used in 
the session.



X.10 Security
-----------
It shall be possible to hide the preference and capability indications 
from unintended inspection.

X.11 Not covered characteristics
------------------------------------
Many aspects of a conversation are not covered by the indications 
specified here.
Examples are:
     Gender
     Expertize area

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

/Gunnar


Den 2015-07-22 kl. 10:24, skrev Henning Schulzrinne:
> We talked about some examples of cases as being "center" and "corner":
>
> (1) "center": customer trying to indicate that they prefer to speak 
> Spanish when contacting call center;
> caller indicating preference for ASL when calling an emergency number
>
> (2) "corner": simultaneous interpretation case where somebody wants to 
> receive both Spanish and English; complex ordering of preferences ("I 
> am a native speaker of English; fluent in Spanish and can read a menu 
> in Swedish"; "I can understand (orally) Latin, but not speak it"; "I 
> rate my preference for English, Spanish and Swedish as 9, 7 and 3.5")
>
> There's obviously no problem if the corner case happens to work, but 
> no extra effort (syntax, complexity) will be expended to make them 
> work. The center-corner cut-off may also differ for routing and 
> intra-UAS (SDP) cases since it seems reasonable to assume that routing 
> is more coarse-grained and has less information about the current 
> (right now), precise capabilities of the end point.
>
> Henning
>
> On Wed, Jul 22, 2015 at 4:03 AM, Paul Kyzivat  > wrote:
>
>     On 7/22/15 3:46 AM, Brian Rosen wrote:
>
>         We will explicitly limit to the 80% cases, and we will
>         document use cases in a work group wiki.  We’re not going to
>         try to cover corner cases.
>
>
>     What does that mean? What is and isn't a corner case?
>
>             Thanks,
>             Paul
>
>     _______________________________________________
>     SLIM mailing list
>     SLIM@ietf.org 
>     https://www.ietf.org/mailman/listinfo/slim
>
>
>
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim

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


--------------050708010505090301060507
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    Can we agree to include this proposed requirements chapter and from
    this proposal identify what should be added or deleted to get the
    center cases included and the corner cases either excluded or just
    enabled by chance? ( a few excluded corner cases are listed in the
    last subsection.)

    I have not changed the chapter after the discussion about
    coordination of languages and modalities in different streams that
    Paul introduced. I am not sure about if that discussion belongs here
    or not. 

    

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

    

    X. Requirements.
    

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

    The system for indication of preferences and capabilities shall meet
    the following requirements:
    

    

    It shall enable negotiation of media, modalities and languages for a
    SIP session.
    

    

    It shall be possible to use it during initiation and modification of
    a session.
    

    

    The system shall consist of a set of indications and usage rules
    specified in this specification and other specifications.
    

    

    The system shall enable a caller to indicate the media, modalities,
    languages and assisting services that the caller prefers to use
    during a real-time session that is about to be established or
    modified.
    

    

    Entities involved in selecting callees and callees shall be enabled
    to view the caller preferences in order to select a callee of many,
    or adjust the set of media, modalities, languages and services
    provided in the session.
    

    

    The caller shall be provided with indication of the resulting media,
    modalities, languages and services enabled during the session.
    

    

    X.1 General
    

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

    It shall be possible to express capabilities and preferences with
    its transmission direction, for transmission or reception or
    bidirectional from the viewpoint of the entity sending the
    indication.
    

    

    The indications shall be suitable for setting in personal profiles,
    in service profiles, or in terminal settings, and possible to adjust
    at session initiation time.
    

    

    It shall be possible to present the outcome of exchange of the
    indications to users in the session.
    

    

    X.2 Media indications.
    

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

    

    It shall be possible to use the indications for audio, video and
    real-time text media.  ( and text messages????)
    

    

    X.3 Modality indications.
    

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

    It shall be possible to use indications for speech and hearing in
    audio media.
    

    

    It shall be possible to use indications for transmitting text and
    receiving text in real-time text media.
    

    

    ( ???  It shall be possible to use indications for transmitting text
    messages and receiving text messages in text messaging media. ???)
    

    

    It shall be possible to use indications for expressing sign language
    and perceiving sign language in video media.
    

    

    It shall be possible to use indications for showing a speaker and
    for seeing a speaker in video media.
    

    

    X.4 Service indications.
    

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

    It shall be possible to use indications of type of and address of
    and state of invocation of an assisting service available for
    supporting the communication.
    

    

    X.5 Language indications.
    

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

    It shall be possible to indicate ability to express language in a
    number of languages from the ones listed in the language tags of RFC
    5646.
    

    

    It shall be possible to indicate ability to perceive language in a
    number of languages from the ones listed in the language tags of RFC
    5646.
    

    

    The language indication shall be associated with a specific media,
    modality and direction.
    

    

    It shall be possible to indicate ability to express language in an
    unspecified language, meaning a default for a region in the
    associated modality.
    

    

    It shall be possible to indicate ability to perceive language in an
    unspecified language, meaning a default for a region in the
    associated modality.
    

    

    It shall be possible to indicate use of media without any specific
    intention to use the medium for language communication.
    

    

    X.6 Indication of level of preference or capability
    

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

    It shall be possible to indicate an absolute level of preference or
    capability to use a language, modality, media and direction
    combination with a coarse grading.
    

    For preference, the grading shall at least be able to indicate
    strong preference vs can use vs possible fall back usage.
    

    For capability, the grading shall at least be able to indicate good
    capability vs some capability vs limited capability.
    

    Capability and preference shall use the same coding, the difference
    is only in the role of the entity providing the indication. Call
    parties express preferences, service providers express capabilities.
    

    

    More than one direction/media/modality/language preference or
    capability can be expressed per level.
    

    

    It shall be possible for a caller to express if the session should
    be set up or not if no matching direction/media/modality/language
    indications are found.
    

    

    X.7 Type and quality indications
    

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

    It shall be possible to indicate preference and capability of
    different types of real-time text production: conversational type
    versus captioning type. Conversational type is generated by the
    transmitting party in the session, or by a communications agent with
    moderate requirements on delay. Captioning type is generated as
    captions to another modality in the same session with low delay from
    the expression in the other modality. The original modality for
    captions can be speech or sign language.
    

    

    It shall be possible to indicate with language indications if it is
    original or interpreted or artificially created contents.
    

    

    In order to enable communication with persons who have speech that
    is weak or hard to understand, the following quality indications can
    be used:
    

        -It shall be possible to indicate that the quality of the
    expressed speech makes it hard to understand.
    

        -It shall be possible to indicate a capability to undertand
    speech that is weak or hard to understand.
    

    

    In order to enable communication with persons who need cognitive
    support in the form of reminders or notetaking, the following
    quality indications can be used:
    

        -It shall be possible to indicate need of reminders or
    notetaking during a session.
    

        -It shall be possible to indicate a capability to provide
    reminders or take notes during a session.
    

    

    

    X.8 Details of service indications
    

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

    The user expressing the indications may be a frequent user of an
    assisting service, that supports the commuication in some often
    occurring need for modality or language translation. By indicating
    this service, a receiver of the indication can judge if invocation
    of that service will support matching of preferences and
    capabilities. Common assiting service types are relay service and
    language translation service.
    

    

    The services are specified with service type, service address,
    invocation state and languages.
    

    Possible service types are:
    

        Spoken language translation service translating between
    different spoken languages.
    

        Video relay service translating between sign language in video
    and speech in audio.
    

        Text relay service translating between text in real-time text
    and speech in audio.  ( even between text messages and audio exist )
    

        Captioned telephony adding real-time text in one direction to
    speech.
    

        Speech-to-speech adding clear speech when needed to speech that
    is weak or hard to understand
    

        Cognitive support adding reminders or memory notes to speech
    conversation ususlly in combination with the speech-to-speech
    service.
    

    

    Service address shall be a URI where the service can be reached with
    one session for provision of the service within the media of that
    session.
    

    (note that this is different from how most current relay services
    today work. They often have two call legs, one with an audio call
    and one with a multimedia call. )
    

    

    Invocation state shall indicate if the service is already included
    in the call, and if so, the media/modality/language indications show
    the joint capabilities.
    

    Invocation state can also contain a request to the other party to
    invoke the service if needed to complement the capabilities to
    achieve a functioning communication. This indication can be provided
    either by the offering or answering party.
    

    

    Languages shall be media/modality/language indications in pairs
    showing the capabilities of the service.
    

    

    

    X.9 Use in session establishment and modification
    

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

    The indications shall be included in session offer / answer
    exchange.
    

    

    Already specified ways to express media/modality/language shall be
    possible to use to the extent that they are usable.
    

    That includes media and language tags on SIP level and media
    specifications and language tags on SDP level. For cases when these
    existing means imply limitations, these limitations shall be
    explained.
    

    

    The method for identification of language preferences and
    capabilities in this specification is intended mainly for rapid
    ad-hoc session establishment and not intended to have the same
    ambitions as CLUE has for planned telepresence sessions.
    

    

    The indications included in the offer shall represent the
    preferences and capabilities of the offering party.
    

    

    The indications included in the answer shall represent the
    preferences and capabilities of the answering party actually planned
    to be used in the session.
    

    

    

    

    X.10 Security
    

    -----------
    

    It shall be possible to hide the preference and capability
    indications from unintended inspection.
    

    

    X.11 Not covered characteristics
    

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

    Many aspects of a conversation are not covered by the indications
    specified here.
    

    Examples are:
    

        Gender
    

        Expertize area
    

    

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

    

    /Gunnar

    

    

    
Den 2015-07-22 kl. 10:24, skrev Henning
      Schulzrinne:

    

    

      
We talked about some examples of cases as being
        "center" and "corner":
        


        

        
(1) "center": customer trying to indicate that they prefer
          to speak Spanish when contacting call center;

        
caller indicating preference for ASL when calling an
          emergency number

        


        

        
(2) "corner": simultaneous interpretation case where
          somebody wants to receive both Spanish and English; complex
          ordering of preferences ("I am a native speaker of English;
          fluent in Spanish and can read a menu in Swedish"; "I can
          understand (orally) Latin, but not speak it"; "I rate my
          preference for English, Spanish and Swedish as 9, 7 and 3.5")

        


        

        
There's obviously no problem if the corner case happens to
          work, but no extra effort (syntax, complexity) will be
          expended to make them work. The center-corner cut-off may also
          differ for routing and intra-UAS (SDP) cases since it seems
          reasonable to assume that routing is more coarse-grained and
          has less information about the current (right now), precise
          capabilities of the end point.

        


        

        
Henning

      

      


        
On Wed, Jul 22, 2015 at 4:03 AM, Paul
          Kyzivat <pkyzivat@alum.mit.edu>
          wrote:

          
On 7/22/15
            3:46 AM, Brian Rosen wrote:

            

            

              We will explicitly limit to the 80% cases, and we will
              document use cases in a work group wiki.  We’re not going
              to try to cover corner cases.

            

            

            What does that mean? What is and isn't a corner case?

            

                    Thanks,

                    Paul

            

            _______________________________________________

            SLIM mailing list

            SLIM@ietf.org

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

          

        

        

      

      

      

      

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


    

    

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

  


--------------050708010505090301060507--


From nobody Wed Jul 22 01:59:17 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3691ACF55 for ; Wed, 22 Jul 2015 01:59:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.52
X-Spam-Level: 
X-Spam-Status: No, score=-1.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=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 4q66aOtB4ILv for ; Wed, 22 Jul 2015 01:59:11 -0700 (PDT)
Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) (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 874501ACD29 for ; Wed, 22 Jul 2015 01:59:11 -0700 (PDT)
Received: by qged69 with SMTP id d69so70407334qge.0 for ; Wed, 22 Jul 2015 01:59:10 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=ubJNBHZK7OxgFiLeoHUsBygmqblH/BS0w3gfXnnaqwg=; b=A3TDTdma8zVztmg4IuDgw2jQ6RSmWcQ/NrXRIiLcxm1pYA1InCcDeMtp3xmasYuzD5 yukpYz2H2Das3E3Sy3a1FrCaPNlxWu3lGRaEvX/C2CSvKkkU4XatmgZSFKJDgOOyXFsd r+3DrwtGkH62JWJT0c6VrK08cFBke9zQlaWd5NXEMHHGC0o7QsapcRQ3zWL2t9V/zHhH Lk0kkGxgfKAXymkzBOqAdCsqOnsYTV0CMhtGZhfyXn06kzntkiGTcuxzO10mgp1k866m EUGQk/Ryy2CBG61QQDGElqmbET9dxXAOjpb2JRRGfhS0ZY7ygeJk9F4wQQcKBRSr5Vd6 e4Ow==
X-Gm-Message-State: ALoCoQmgEfF6098K2Rd60ZDDuk1QRaqWTPQ9FnoZE2DAb3+ZYGyUNCD21DbO1ruHgL8ipJt8HHTp
X-Received: by 10.140.93.200 with SMTP id d66mr1870028qge.62.1437555550779; Wed, 22 Jul 2015 01:59:10 -0700 (PDT)
Received: from mrichards3-ltw7.cis.neustar.com (neustargw.va.neustar.com. [209.173.53.233]) by smtp.gmail.com with ESMTPSA id v44sm371292qgd.21.2015.07.22.01.59.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Jul 2015 01:59:10 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_7104D24F-9A2E-4983-BF50-BDF84A17BF6D"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: Brian Rosen 
In-Reply-To: <55AF59C7.605@omnitor.se>
Date: Wed, 22 Jul 2015 10:59:03 +0200
Message-Id: 
References: <9874942B-DB5E-4092-8C2B-7E159437B491@standardstrack.com> <43B9F9AD-52C2-451A-9A50-B206FFAE3568@brianrosen.net> <55AF4E6A.3060401@alum.mit.edu>  <55AF59C7.605@omnitor.se>
To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= 
X-Mailer: Apple Mail (2.2102)
Archived-At: 
Cc: slim@ietf.org
Subject: Re: [Slim] Notes from lunch? + Requirements
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jul 2015 08:59:16 -0000

--Apple-Mail=_7104D24F-9A2E-4983-BF50-BDF84A17BF6D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

I=92m not in favor of this.

I think it=92s too complex; way, way too complex.

Brian


> On Jul 22, 2015, at 10:52 AM, Gunnar Hellstr=F6m =
 wrote:
>=20
> Can we agree to include this proposed requirements chapter and from =
this proposal identify what should be added or deleted to get the center =
cases included and the corner cases either excluded or just enabled by =
chance? ( a few excluded corner cases are listed in the last =
subsection.)
> I have not changed the chapter after the discussion about coordination =
of languages and modalities in different streams that Paul introduced. I =
am not sure about if that discussion belongs here or not.=20
>=20
> -----------------------------------
>=20
> X. Requirements.=20
> ------------------------=20
> The system for indication of preferences and capabilities shall meet =
the following requirements:=20
>=20
> It shall enable negotiation of media, modalities and languages for a =
SIP session.=20
>=20
> It shall be possible to use it during initiation and modification of a =
session.=20
>=20
> The system shall consist of a set of indications and usage rules =
specified in this specification and other specifications.=20
>=20
> The system shall enable a caller to indicate the media, modalities, =
languages and assisting services that the caller prefers to use during a =
real-time session that is about to be established or modified.=20
>=20
> Entities involved in selecting callees and callees shall be enabled to =
view the caller preferences in order to select a callee of many, or =
adjust the set of media, modalities, languages and services provided in =
the session.=20
>=20
> The caller shall be provided with indication of the resulting media, =
modalities, languages and services enabled during the session.=20
>=20
> X.1 General=20
> ------------=20
> It shall be possible to express capabilities and preferences with its =
transmission direction, for transmission or reception or bidirectional =
from the viewpoint of the entity sending the indication.=20
>=20
> The indications shall be suitable for setting in personal profiles, in =
service profiles, or in terminal settings, and possible to adjust at =
session initiation time.=20
>=20
> It shall be possible to present the outcome of exchange of the =
indications to users in the session.=20
>=20
> X.2 Media indications.=20
> -------------------------=20
>=20
> It shall be possible to use the indications for audio, video and =
real-time text media.  ( and text messages????)=20
>=20
> X.3 Modality indications.=20
> ----------------------------=20
> It shall be possible to use indications for speech and hearing in =
audio media.=20
>=20
> It shall be possible to use indications for transmitting text and =
receiving text in real-time text media.=20
>=20
> ( ???  It shall be possible to use indications for transmitting text =
messages and receiving text messages in text messaging media. ???)=20
>=20
> It shall be possible to use indications for expressing sign language =
and perceiving sign language in video media.=20
>=20
> It shall be possible to use indications for showing a speaker and for =
seeing a speaker in video media.=20
>=20
> X.4 Service indications.=20
> --------------------------=20
> It shall be possible to use indications of type of and address of and =
state of invocation of an assisting service available for supporting the =
communication.=20
>=20
> X.5 Language indications.=20
> -----------------------------=20
> It shall be possible to indicate ability to express language in a =
number of languages from the ones listed in the language tags of RFC =
5646.=20
>=20
> It shall be possible to indicate ability to perceive language in a =
number of languages from the ones listed in the language tags of RFC =
5646.=20
>=20
> The language indication shall be associated with a specific media, =
modality and direction.=20
>=20
> It shall be possible to indicate ability to express language in an =
unspecified language, meaning a default for a region in the associated =
modality.=20
>=20
> It shall be possible to indicate ability to perceive language in an =
unspecified language, meaning a default for a region in the associated =
modality.=20
>=20
> It shall be possible to indicate use of media without any specific =
intention to use the medium for language communication.=20
>=20
> X.6 Indication of level of preference or capability=20
> --------------------------------------------------------=20
> It shall be possible to indicate an absolute level of preference or =
capability to use a language, modality, media and direction combination =
with a coarse grading.=20
> For preference, the grading shall at least be able to indicate strong =
preference vs can use vs possible fall back usage.=20
> For capability, the grading shall at least be able to indicate good =
capability vs some capability vs limited capability.=20
> Capability and preference shall use the same coding, the difference is =
only in the role of the entity providing the indication. Call parties =
express preferences, service providers express capabilities.    =20
>=20
> More than one direction/media/modality/language preference or =
capability can be expressed per level.=20
>=20
> It shall be possible for a caller to express if the session should be =
set up or not if no matching direction/media/modality/language =
indications are found.=20
>=20
> X.7 Type and quality indications=20
> -------------------------------------=20
> It shall be possible to indicate preference and capability of =
different types of real-time text production: conversational type versus =
captioning type. Conversational type is generated by the transmitting =
party in the session, or by a communications agent with moderate =
requirements on delay. Captioning type is generated as captions to =
another modality in the same session with low delay from the expression =
in the other modality. The original modality for captions can be speech =
or sign language.=20
>=20
> It shall be possible to indicate with language indications if it is =
original or interpreted or artificially created contents.=20
>=20
> In order to enable communication with persons who have speech that is =
weak or hard to understand, the following quality indications can be =
used:=20
>     -It shall be possible to indicate that the quality of the =
expressed speech makes it hard to understand.=20
>     -It shall be possible to indicate a capability to undertand speech =
that is weak or hard to understand.=20
>=20
> In order to enable communication with persons who need cognitive =
support in the form of reminders or notetaking, the following quality =
indications can be used:=20
>     -It shall be possible to indicate need of reminders or notetaking =
during a session.=20
>     -It shall be possible to indicate a capability to provide =
reminders or take notes during a session.=20
>=20
>=20
> X.8 Details of service indications=20
> ----------------------------------------=20
> The user expressing the indications may be a frequent user of an =
assisting service, that supports the commuication in some often =
occurring need for modality or language translation. By indicating this =
service, a receiver of the indication can judge if invocation of that =
service will support matching of preferences and capabilities. Common =
assiting service types are relay service and     language translation =
service.=20
>=20
> The services are specified with service type, service address, =
invocation state and languages.=20
> Possible service types are:=20
>     Spoken language translation service translating between different =
spoken languages.=20
>     Video relay service translating between sign language in video and =
speech in audio.=20
>     Text relay service translating between text in real-time text and =
speech in audio.  ( even between text messages and audio exist )=20
>     Captioned telephony adding real-time text in one direction to =
speech.=20
>     Speech-to-speech adding clear speech when needed to speech that is =
weak or hard to understand=20
>     Cognitive support adding reminders or memory notes to speech =
conversation ususlly in combination with the speech-to-speech service.=20=

>=20
> Service address shall be a URI where the service can be reached with =
one session for provision of the service within the media of that =
session.=20
> (note that this is different from how most current relay services =
today work. They often have two call legs, one with an audio call and =
one with a multimedia call. )=20
>=20
> Invocation state shall indicate if the service is already included in =
the call, and if so, the media/modality/language indications show the =
joint capabilities.=20
> Invocation state can also contain a request to the other party to =
invoke the service if needed to complement the capabilities to achieve a =
functioning communication. This indication can be provided either by the =
offering or answering party.=20
>=20
> Languages shall be media/modality/language indications in pairs =
showing the capabilities of the service.=20
>=20
>=20
> X.9 Use in session establishment and modification=20
> -------------------------------------------------------------=20
> The indications shall be included in session offer / answer exchange.=20=

>=20
> Already specified ways to express media/modality/language shall be =
possible to use to the extent that they are usable.=20
> That includes media and language tags on SIP level and media =
specifications and language tags on SDP level. For cases when these =
existing means imply limitations, these limitations shall be explained.=20=

>=20
> The method for identification of language preferences and capabilities =
in this specification is intended mainly for rapid ad-hoc session =
establishment and not intended to have the same ambitions as CLUE has =
for planned telepresence sessions.=20
>=20
> The indications included in the offer shall represent the preferences =
and capabilities of the offering party.=20
>=20
> The indications included in the answer shall represent the preferences =
and capabilities of the answering party actually planned to be used in =
the session.=20
>=20
>=20
>=20
> X.10 Security=20
> -----------=20
> It shall be possible to hide the preference and capability indications =
from unintended inspection.=20
>=20
> X.11 Not covered characteristics=20
> ------------------------------------=20
> Many aspects of a conversation are not covered by the indications =
specified here.=20
> Examples are:=20
>     Gender=20
>     Expertize area=20
>=20
> --------------------------------------
>=20
> /Gunnar
>=20
>=20
> Den 2015-07-22 kl. 10:24, skrev Henning Schulzrinne:
>> We talked about some examples of cases as being "center" and =
"corner":
>>=20
>> (1) "center": customer trying to indicate that they prefer to speak =
Spanish when contacting call center;
>> caller indicating preference for ASL when calling an emergency number
>>=20
>> (2) "corner": simultaneous interpretation case where somebody wants =
to receive both Spanish and English; complex ordering of preferences ("I =
am a native speaker of English; fluent in Spanish and can read a menu in =
Swedish"; "I can understand (orally) Latin, but not speak it"; "I rate =
my preference for English, Spanish and Swedish as 9, 7 and 3.5")
>>=20
>> There's obviously no problem if the corner case happens to work, but =
no extra effort (syntax, complexity) will be expended to make them work. =
The center-corner cut-off may also differ for routing and intra-UAS =
(SDP) cases since it seems reasonable to assume that routing is more =
coarse-grained and has less information about the current (right now), =
precise capabilities of the end point.
>>=20
>> Henning
>>=20
>> On Wed, Jul 22, 2015 at 4:03 AM, Paul Kyzivat > wrote:
>> On 7/22/15 3:46 AM, Brian Rosen wrote:
>>=20
>> We will explicitly limit to the 80% cases, and we will document use =
cases in a work group wiki.  We=92re not going to try to cover corner =
cases.
>>=20
>> What does that mean? What is and isn't a corner case?
>>=20
>>         Thanks,
>>         Paul
>>=20
>> _______________________________________________
>> SLIM mailing list
>> SLIM@ietf.org 
>> https://www.ietf.org/mailman/listinfo/slim =

>>=20
>>=20
>>=20
>> _______________________________________________
>> SLIM mailing list
>> SLIM@ietf.org 
>> https://www.ietf.org/mailman/listinfo/slim =

>=20
> --=20
> -----------------------------------------
> Gunnar Hellstr=F6m
> Omnitor
> gunnar.hellstrom@omnitor.se 
> +46 708 204 288
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim


--Apple-Mail=_7104D24F-9A2E-4983-BF50-BDF84A17BF6D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

I=92m not in favor of this.

I think it=92s too complex; way, way =
too complex.

Brian


On Jul 22, 2015, at 10:52 AM, Gunnar Hellstr=F6m <gunnar.hellstrom@omnitor.se> wrote:


 =20
    
 =20
  

    Can we agree to include this proposed requirements chapter and from
    this proposal identify what should be added or deleted to get the
    center cases included and the corner cases either excluded or just
    enabled by chance? ( a few excluded corner cases are listed in the
    last subsection.)

    I have not changed the chapter after the discussion about
    coordination of languages and modalities in different streams that
    Paul introduced. I am not sure about if that discussion belongs here
    or not. 

    

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

    

    X. Requirements.
    

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

    The system for indication of preferences and capabilities shall meet
    the following requirements:
    

    

    It shall enable negotiation of media, modalities and languages for a
    SIP session.
    

    

    It shall be possible to use it during initiation and modification of
    a session.
    

    

    The system shall consist of a set of indications and usage rules
    specified in this specification and other specifications.
    

    

    The system shall enable a caller to indicate the media, modalities,
    languages and assisting services that the caller prefers to use
    during a real-time session that is about to be established or
    modified.
    

    

    Entities involved in selecting callees and callees shall be enabled
    to view the caller preferences in order to select a callee of many,
    or adjust the set of media, modalities, languages and services
    provided in the session.
    

    

    The caller shall be provided with indication of the resulting media,
    modalities, languages and services enabled during the session.
    

    

    X.1 General
    

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

    It shall be possible to express capabilities and preferences with
    its transmission direction, for transmission or reception or
    bidirectional from the viewpoint of the entity sending the
    indication.
    

    

    The indications shall be suitable for setting in personal profiles,
    in service profiles, or in terminal settings, and possible to adjust
    at session initiation time.
    

    

    It shall be possible to present the outcome of exchange of the
    indications to users in the session.
    

    

    X.2 Media indications.
    

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

    

    It shall be possible to use the indications for audio, video and
    real-time text media.  ( and text messages????)
    

    

    X.3 Modality indications.
    

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

    It shall be possible to use indications for speech and hearing in
    audio media.
    

    

    It shall be possible to use indications for transmitting text and
    receiving text in real-time text media.
    

    

    ( ???  It shall be possible to use indications for transmitting =
text
    messages and receiving text messages in text messaging media. ???)
    

    

    It shall be possible to use indications for expressing sign language
    and perceiving sign language in video media.
    

    

    It shall be possible to use indications for showing a speaker and
    for seeing a speaker in video media.
    

    

    X.4 Service indications.
    

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

    It shall be possible to use indications of type of and address of
    and state of invocation of an assisting service available for
    supporting the communication.
    

    

    X.5 Language indications.
    

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

    It shall be possible to indicate ability to express language in a
    number of languages from the ones listed in the language tags of RFC
    5646.
    

    

    It shall be possible to indicate ability to perceive language in a
    number of languages from the ones listed in the language tags of RFC
    5646.
    

    

    The language indication shall be associated with a specific media,
    modality and direction.
    

    

    It shall be possible to indicate ability to express language in an
    unspecified language, meaning a default for a region in the
    associated modality.
    

    

    It shall be possible to indicate ability to perceive language in an
    unspecified language, meaning a default for a region in the
    associated modality.
    

    

    It shall be possible to indicate use of media without any specific
    intention to use the medium for language communication.
    

    

    X.6 Indication of level of preference or capability
    

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

    It shall be possible to indicate an absolute level of preference or
    capability to use a language, modality, media and direction
    combination with a coarse grading.
    

    For preference, the grading shall at least be able to indicate
    strong preference vs can use vs possible fall back usage.
    

    For capability, the grading shall at least be able to indicate good
    capability vs some capability vs limited capability.
    

    Capability and preference shall use the same coding, the difference
    is only in the role of the entity providing the indication. Call
    parties express preferences, service providers express capabilities.
    

    

    More than one direction/media/modality/language preference or
    capability can be expressed per level.
    

    

    It shall be possible for a caller to express if the session should
    be set up or not if no matching direction/media/modality/language
    indications are found.
    

    

    X.7 Type and quality indications
    

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

    It shall be possible to indicate preference and capability of
    different types of real-time text production: conversational type
    versus captioning type. Conversational type is generated by the
    transmitting party in the session, or by a communications agent with
    moderate requirements on delay. Captioning type is generated as
    captions to another modality in the same session with low delay from
    the expression in the other modality. The original modality for
    captions can be speech or sign language.
    

    

    It shall be possible to indicate with language indications if it is
    original or interpreted or artificially created contents.
    

    

    In order to enable communication with persons who have speech that
    is weak or hard to understand, the following quality indications can
    be used:
    

        -It shall be possible to indicate that the =
quality of the
    expressed speech makes it hard to understand.
    

        -It shall be possible to indicate a capability to =
undertand
    speech that is weak or hard to understand.
    

    

    In order to enable communication with persons who need cognitive
    support in the form of reminders or notetaking, the following
    quality indications can be used:
    

        -It shall be possible to indicate need of =
reminders or
    notetaking during a session.
    

        -It shall be possible to indicate a capability to =
provide
    reminders or take notes during a session.
    

    

    

    X.8 Details of service indications
    

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

    The user expressing the indications may be a frequent user of an
    assisting service, that supports the commuication in some often
    occurring need for modality or language translation. By indicating
    this service, a receiver of the indication can judge if invocation
    of that service will support matching of preferences and
    capabilities. Common assiting service types are relay service and
    language translation service.
    

    

    The services are specified with service type, service address,
    invocation state and languages.
    

    Possible service types are:
    

        Spoken language translation service translating =
between
    different spoken languages.
    

        Video relay service translating between sign =
language in video
    and speech in audio.
    

        Text relay service translating between text in =
real-time text
    and speech in audio.  ( even between text messages and audio =
exist )
    

        Captioned telephony adding real-time text in one =
direction to
    speech.
    

        Speech-to-speech adding clear speech when needed =
to speech that
    is weak or hard to understand
    

        Cognitive support adding reminders or memory =
notes to speech
    conversation ususlly in combination with the speech-to-speech
    service.
    

    

    Service address shall be a URI where the service can be reached with
    one session for provision of the service within the media of that
    session.
    

    (note that this is different from how most current relay services
    today work. They often have two call legs, one with an audio call
    and one with a multimedia call. )
    

    

    Invocation state shall indicate if the service is already included
    in the call, and if so, the media/modality/language indications show
    the joint capabilities.
    

    Invocation state can also contain a request to the other party to
    invoke the service if needed to complement the capabilities to
    achieve a functioning communication. This indication can be provided
    either by the offering or answering party.
    

    

    Languages shall be media/modality/language indications in pairs
    showing the capabilities of the service.
    

    

    

    X.9 Use in session establishment and modification
    

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

    The indications shall be included in session offer / answer
    exchange.
    

    

    Already specified ways to express media/modality/language shall be
    possible to use to the extent that they are usable.
    

    That includes media and language tags on SIP level and media
    specifications and language tags on SDP level. For cases when these
    existing means imply limitations, these limitations shall be
    explained.
    

    

    The method for identification of language preferences and
    capabilities in this specification is intended mainly for rapid
    ad-hoc session establishment and not intended to have the same
    ambitions as CLUE has for planned telepresence sessions.
    

    

    The indications included in the offer shall represent the
    preferences and capabilities of the offering party.
    

    

    The indications included in the answer shall represent the
    preferences and capabilities of the answering party actually planned
    to be used in the session.
    

    

    

    

    X.10 Security
    

    -----------
    

    It shall be possible to hide the preference and capability
    indications from unintended inspection.
    

    

    X.11 Not covered characteristics
    

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

    Many aspects of a conversation are not covered by the indications
    specified here.
    

    Examples are:
    

        Gender
    

        Expertize area
    

    

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

    

    /Gunnar

    

    

    
Den 2015-07-22 kl. 10:24, skrev =
Henning
      Schulzrinne:

    

    

      
We talked about some examples of cases =
as being
        "center" and "corner":
        


        

        
(1) "center": customer trying to indicate that =
they prefer
          to speak Spanish when contacting call center;

        
caller indicating preference for ASL when =
calling an
          emergency number

        


        

        
(2) "corner": simultaneous interpretation case =
where
          somebody wants to receive both Spanish and English; complex
          ordering of preferences ("I am a native speaker of English;
          fluent in Spanish and can read a menu in Swedish"; "I can
          understand (orally) Latin, but not speak it"; "I rate my
          preference for English, Spanish and Swedish as 9, 7 and =
3.5")

        


        

        
There's obviously no problem if the corner case =
happens to
          work, but no extra effort (syntax, complexity) will be
          expended to make them work. The center-corner cut-off may also
          differ for routing and intra-UAS (SDP) cases since it seems
          reasonable to assume that routing is more coarse-grained and
          has less information about the current (right now), precise
          capabilities of the end point.

        


        

        
Henning

      

      


        
On Wed, Jul 22, 2015 at 4:03 AM, Paul
          Kyzivat <pkyzivat@alum.mit.edu>
          wrote:

          
On 7/22/15
            3:46 AM, Brian Rosen wrote:

            

            

              We will explicitly limit to the 80% cases, and we will
              document use cases in a work group wiki.  We=92re not =
going
              to try to cover corner cases.

            

            

            What does that mean? What is and isn't a corner case?

            

                    Thanks,

                    Paul

            

            _______________________________________________
=

            SLIM mailing list

            SLIM@ietf.org

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

          

        

        

      

      

      

      

      
_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/m=
ailman/listinfo/slim


    

    

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

  


_______________________________________________
SLIM =
mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim

=

--Apple-Mail=_7104D24F-9A2E-4983-BF50-BDF84A17BF6D--


From nobody Wed Jul 22 02:33:03 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6E3D1ACE00 for ; Wed, 22 Jul 2015 02:33:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.588
X-Spam-Level: 
X-Spam-Status: No, score=-3.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 vKV1h8pjg4_x for ; Wed, 22 Jul 2015 02:32:57 -0700 (PDT)
Received: from buckwheat.cc.columbia.edu (buckwheat.cc.columbia.edu [128.59.72.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0B8A1AC3E8 for ; Wed, 22 Jul 2015 02:32:56 -0700 (PDT)
Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by buckwheat.cc.columbia.edu (8.13.8/8.13.8) with ESMTP id t6M9U3Oh005127 for ; Wed, 22 Jul 2015 05:32:55 -0400
Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id BB7417E for ; Wed, 22 Jul 2015 05:32:55 -0400 (EDT)
Received: from salak.cc.columbia.edu (salak.cc.columbia.edu [128.59.29.6]) by hazelnut (Postfix) with ESMTP id 8C4D87E for ; Wed, 22 Jul 2015 05:32:55 -0400 (EDT)
Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) by salak.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id t6M9WsVg008504 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 22 Jul 2015 05:32:55 -0400 (EDT)
Received: by igr7 with SMTP id 7so63246682igr.0 for ; Wed, 22 Jul 2015 02:32:54 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Dw5JGh2WkIoxZnMM5QhnCffmiBkJ60HiFiWZtoVpf50=; b=i/hCRU1dVQfy3whF8zncmzLOk5C2fLUIPmuR+t7yXW8wiGIcmi42E3V1v+0/JepPLG N19343zkqehcrYvT500GudgXLRk6kP6e0jBP7SwVqdgWreQ9bOJEOPVaeDIeRBbDu8M2 ux9v/rgVQOn0m097xbcel+oGV8qz2OdxF+F2nAgGhN7YoRuupOWOF0IWF6mZeYKvDuQo uSt4pap0OnVYGNc56cWpougS5+MUutHwuuLK5zgq5/RgDXtuD/OhOTXFdfI2izQfQSJq eapB+wfBw0bL2Zo7pAONjS2BT7IFTMtbn4MHopESZKV0V/hEpuw18kYuRPxE9osfQAvB PSyA==
X-Gm-Message-State: ALoCoQkujoiKGEyXeUPFFBwb5BuWQeOH2sPOlaeCthyLmx9gF0ST9CG+N+sDc4Ow5h9BHrQGISx3C+uM5Bb41qaS6sBPJiAHRmveN9ETlXHYgxNwhw+ygqeF46DqwKzr4WGyN/q44mwM
X-Received: by 10.50.8.68 with SMTP id p4mr4183079iga.4.1437557574741; Wed, 22 Jul 2015 02:32:54 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.8.68 with SMTP id p4mr4183055iga.4.1437557574575; Wed, 22 Jul 2015 02:32:54 -0700 (PDT)
Received: by 10.36.120.69 with HTTP; Wed, 22 Jul 2015 02:32:54 -0700 (PDT)
In-Reply-To: 
References: <9874942B-DB5E-4092-8C2B-7E159437B491@standardstrack.com> <43B9F9AD-52C2-451A-9A50-B206FFAE3568@brianrosen.net> <55AF4E6A.3060401@alum.mit.edu>  <55AF59C7.605@omnitor.se> 
Date: Wed, 22 Jul 2015 05:32:54 -0400
Message-ID: 
From: Henning Schulzrinne 
To: Brian Rosen 
Content-Type: multipart/alternative; boundary=089e0118483893c771051b7374ba
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6
Archived-At: 
Cc: slim@ietf.org, =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= 
Subject: Re: [Slim] Notes from lunch? + Requirements
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jul 2015 09:33:03 -0000

--089e0118483893c771051b7374ba
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I agree; I think this is too prescriptive. The goal is much simpler: Allow
the caller to provide enough information so that proxy/UA/SBC/PSAP etc. can
make good decisions on what to do. Generally, attempts to tell these
entities *how* to do things or exactly what to do is both likely to be
ignored and generate unbounded complexity. We went a small distance down
that path before, in caller preferences, and the result was not pretty.
That effort actually tried to come up with a formal logic, rather than a
compilation of ad-hoc cases, but even that led to too many cases to make
them practical to implement. Been there, done that, have the T-shirt.

We generally don't need to do this - we don't have generic components in
most of the cases of the interest (PSAP, call center, conferencing systems,
etc.), but components that, by their nature, have a fair amount of
domain-specific knowledge, such as policies about how to handle ASL calls,
when and how to bridge in interpreters, who gets what kind of language
assistance, etc.  (To be sure, the physical components such as SIP proxies
may be generic, but they have been programmed to operate in a specific
policy environment, i.e., they turn into an ESRP or PBX/ACD.)

These entities essentially need to know "which of my well-known
customer/caller classes is this" and then trigger one of a very small
number of behaviors that are programmed ahead of time. This is, among other
reasons, the only way that you can test systems. And all of our target
systems are high-reliability, can't-fail systems, even if they are not
life-safety systems.

Also, in many cases, they may define profiles for users out-of-band. For
example, they are likely to define special roles for call takers, language
interpreters, managers (who need to monitor calls for quality assurance),
loggers, etc. These roles trigger behavior, not the signaling or SDP.

We are not specifying a programming language here.

Henning

On Wed, Jul 22, 2015 at 4:59 AM, Brian Rosen  wrote:

> I=E2=80=99m not in favor of this.
>
> I think it=E2=80=99s too complex; way, way too complex.
>
> Brian
>
>
> On Jul 22, 2015, at 10:52 AM, Gunnar Hellstr=C3=B6m <
> gunnar.hellstrom@omnitor.se> wrote:
>
>  Can we agree to include this proposed requirements chapter and from this
> proposal identify what should be added or deleted to get the center cases
> included and the corner cases either excluded or just enabled by chance? =
(
> a few excluded corner cases are listed in the last subsection.)
> I have not changed the chapter after the discussion about coordination of
> languages and modalities in different streams that Paul introduced. I am
> not sure about if that discussion belongs here or not.
>
> -----------------------------------
>
> X. Requirements.
> ------------------------
> The system for indication of preferences and capabilities shall meet the
> following requirements:
>
> It shall enable negotiation of media, modalities and languages for a SIP
> session.
>
> It shall be possible to use it during initiation and modification of a
> session.
>
> The system shall consist of a set of indications and usage rules specifie=
d
> in this specification and other specifications.
>
> The system shall enable a caller to indicate the media, modalities,
> languages and assisting services that the caller prefers to use during a
> real-time session that is about to be established or modified.
>
> Entities involved in selecting callees and callees shall be enabled to
> view the caller preferences in order to select a callee of many, or adjus=
t
> the set of media, modalities, languages and services provided in the
> session.
>
> The caller shall be provided with indication of the resulting media,
> modalities, languages and services enabled during the session.
>
> X.1 General
> ------------
> It shall be possible to express capabilities and preferences with its
> transmission direction, for transmission or reception or bidirectional fr=
om
> the viewpoint of the entity sending the indication.
>
> The indications shall be suitable for setting in personal profiles, in
> service profiles, or in terminal settings, and possible to adjust at
> session initiation time.
>
> It shall be possible to present the outcome of exchange of the indication=
s
> to users in the session.
>
> X.2 Media indications.
> -------------------------
>
> It shall be possible to use the indications for audio, video and real-tim=
e
> text media.  ( and text messages????)
>
> X.3 Modality indications.
> ----------------------------
> It shall be possible to use indications for speech and hearing in audio
> media.
>
> It shall be possible to use indications for transmitting text and
> receiving text in real-time text media.
>
> ( ???  It shall be possible to use indications for transmitting text
> messages and receiving text messages in text messaging media. ???)
>
> It shall be possible to use indications for expressing sign language and
> perceiving sign language in video media.
>
> It shall be possible to use indications for showing a speaker and for
> seeing a speaker in video media.
>
> X.4 Service indications.
> --------------------------
> It shall be possible to use indications of type of and address of and
> state of invocation of an assisting service available for supporting the
> communication.
>
> X.5 Language indications.
> -----------------------------
> It shall be possible to indicate ability to express language in a number
> of languages from the ones listed in the language tags of RFC 5646.
>
> It shall be possible to indicate ability to perceive language in a number
> of languages from the ones listed in the language tags of RFC 5646.
>
> The language indication shall be associated with a specific media,
> modality and direction.
>
> It shall be possible to indicate ability to express language in an
> unspecified language, meaning a default for a region in the associated
> modality.
>
> It shall be possible to indicate ability to perceive language in an
> unspecified language, meaning a default for a region in the associated
> modality.
>
> It shall be possible to indicate use of media without any specific
> intention to use the medium for language communication.
>
> X.6 Indication of level of preference or capability
> --------------------------------------------------------
> It shall be possible to indicate an absolute level of preference or
> capability to use a language, modality, media and direction combination
> with a coarse grading.
> For preference, the grading shall at least be able to indicate strong
> preference vs can use vs possible fall back usage.
> For capability, the grading shall at least be able to indicate good
> capability vs some capability vs limited capability.
> Capability and preference shall use the same coding, the difference is
> only in the role of the entity providing the indication. Call parties
> express preferences, service providers express capabilities.
>
> More than one direction/media/modality/language preference or capability
> can be expressed per level.
>
> It shall be possible for a caller to express if the session should be set
> up or not if no matching direction/media/modality/language indications ar=
e
> found.
>
> X.7 Type and quality indications
> -------------------------------------
> It shall be possible to indicate preference and capability of different
> types of real-time text production: conversational type versus captioning
> type. Conversational type is generated by the transmitting party in the
> session, or by a communications agent with moderate requirements on delay=
.
> Captioning type is generated as captions to another modality in the same
> session with low delay from the expression in the other modality. The
> original modality for captions can be speech or sign language.
>
> It shall be possible to indicate with language indications if it is
> original or interpreted or artificially created contents.
>
> In order to enable communication with persons who have speech that is wea=
k
> or hard to understand, the following quality indications can be used:
>     -It shall be possible to indicate that the quality of the expressed
> speech makes it hard to understand.
>     -It shall be possible to indicate a capability to undertand speech
> that is weak or hard to understand.
>
> In order to enable communication with persons who need cognitive support
> in the form of reminders or notetaking, the following quality indications
> can be used:
>     -It shall be possible to indicate need of reminders or notetaking
> during a session.
>     -It shall be possible to indicate a capability to provide reminders o=
r
> take notes during a session.
>
>
> X.8 Details of service indications
> ----------------------------------------
> The user expressing the indications may be a frequent user of an assistin=
g
> service, that supports the commuication in some often occurring need for
> modality or language translation. By indicating this service, a receiver =
of
> the indication can judge if invocation of that service will support
> matching of preferences and capabilities. Common assiting service types a=
re
> relay service and language translation service.
>
> The services are specified with service type, service address, invocation
> state and languages.
> Possible service types are:
>     Spoken language translation service translating between different
> spoken languages.
>     Video relay service translating between sign language in video and
> speech in audio.
>     Text relay service translating between text in real-time text and
> speech in audio.  ( even between text messages and audio exist )
>     Captioned telephony adding real-time text in one direction to speech.
>     Speech-to-speech adding clear speech when needed to speech that is
> weak or hard to understand
>     Cognitive support adding reminders or memory notes to speech
> conversation ususlly in combination with the speech-to-speech service.
>
> Service address shall be a URI where the service can be reached with one
> session for provision of the service within the media of that session.
> (note that this is different from how most current relay services today
> work. They often have two call legs, one with an audio call and one with =
a
> multimedia call. )
>
> Invocation state shall indicate if the service is already included in the
> call, and if so, the media/modality/language indications show the joint
> capabilities.
> Invocation state can also contain a request to the other party to invoke
> the service if needed to complement the capabilities to achieve a
> functioning communication. This indication can be provided either by the
> offering or answering party.
>
> Languages shall be media/modality/language indications in pairs showing
> the capabilities of the service.
>
>
> X.9 Use in session establishment and modification
> -------------------------------------------------------------
> The indications shall be included in session offer / answer exchange.
>
> Already specified ways to express media/modality/language shall be
> possible to use to the extent that they are usable.
> That includes media and language tags on SIP level and media
> specifications and language tags on SDP level. For cases when these
> existing means imply limitations, these limitations shall be explained.
>
> The method for identification of language preferences and capabilities in
> this specification is intended mainly for rapid ad-hoc session
> establishment and not intended to have the same ambitions as CLUE has for
> planned telepresence sessions.
>
> The indications included in the offer shall represent the preferences and
> capabilities of the offering party.
>
> The indications included in the answer shall represent the preferences an=
d
> capabilities of the answering party actually planned to be used in the
> session.
>
>
>
> X.10 Security
> -----------
> It shall be possible to hide the preference and capability indications
> from unintended inspection.
>
> X.11 Not covered characteristics
> ------------------------------------
> Many aspects of a conversation are not covered by the indications
> specified here.
> Examples are:
>     Gender
>     Expertize area
>
> --------------------------------------
>
> /Gunnar
>
>
> Den 2015-07-22 kl. 10:24, skrev Henning Schulzrinne:
>
> We talked about some examples of cases as being "center" and "corner":
>
>  (1) "center": customer trying to indicate that they prefer to speak
> Spanish when contacting call center;
> caller indicating preference for ASL when calling an emergency number
>
>  (2) "corner": simultaneous interpretation case where somebody wants to
> receive both Spanish and English; complex ordering of preferences ("I am =
a
> native speaker of English; fluent in Spanish and can read a menu in
> Swedish"; "I can understand (orally) Latin, but not speak it"; "I rate my
> preference for English, Spanish and Swedish as 9, 7 and 3.5")
>
>  There's obviously no problem if the corner case happens to work, but no
> extra effort (syntax, complexity) will be expended to make them work. The
> center-corner cut-off may also differ for routing and intra-UAS (SDP) cas=
es
> since it seems reasonable to assume that routing is more coarse-grained a=
nd
> has less information about the current (right now), precise capabilities =
of
> the end point.
>
>  Henning
>
> On Wed, Jul 22, 2015 at 4:03 AM, Paul Kyzivat 
> wrote:
>
>> On 7/22/15 3:46 AM, Brian Rosen wrote:
>>
>>  We will explicitly limit to the 80% cases, and we will document use
>>> cases in a work group wiki.  We=E2=80=99re not going to try to cover co=
rner cases.
>>>
>>
>> What does that mean? What is and isn't a corner case?
>>
>>         Thanks,
>>         Paul
>>
>> _______________________________________________
>> SLIM mailing list
>> SLIM@ietf.org
>> https://www.ietf.org/mailman/listinfo/slim
>>
>
>
>
> _______________________________________________
> SLIM mailing listSLIM@ietf.orghttps://www.ietf.org/mailman/listinfo/slim
>
>
> --
> -----------------------------------------
> Gunnar Hellstr=C3=B6m
> Omnitorgunnar.hellstrom@omnitor.se
> +46 708 204 288
>
>  _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim
>
>
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim
>
>

--089e0118483893c771051b7374ba
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I agree; I think this is too prescriptive. The goal is muc=
h simpler: Allow the caller to provide enough information so that proxy/UA/=
SBC/PSAP etc. can make good decisions on what to do. Generally, attempts to=
 tell these entities *how* to do things or exactly what to do is both likel=
y to be ignored and generate unbounded complexity. We went a small distance=
 down that path before, in caller preferences, and the result was not prett=
y. That effort actually tried to come up with a formal logic, rather than a=
 compilation of ad-hoc cases, but even that led to too many cases to make t=
hem practical to implement. Been there, done that, have the T-shirt.
We generally don't need to do this - we don't have gen=
eric components in most of the cases of the interest (PSAP, call center, co=
nferencing systems, etc.), but components that, by their nature, have a fai=
r amount of domain-specific knowledge, such as policies about how to handle=
 ASL calls, when and how to bridge in interpreters, who gets what kind of l=
anguage assistance, etc. =C2=A0(To be sure, the physical components such as=
 SIP proxies may be generic, but they have been programmed to operate in a =
specific policy environment, i.e., they turn into an ESRP or PBX/ACD.)

These entities essentially need to know "which of=
 my well-known customer/caller classes is this" and then trigger one o=
f a very small number of behaviors that are programmed ahead of time. This =
is, among other reasons, the only way that you can test systems. And all of=
 our target systems are high-reliability, can't-fail systems, even if t=
hey are not life-safety systems.

Also, in many cas=
es, they may define profiles for users out-of-band. For example, they are l=
ikely to define special roles for call takers, language interpreters, manag=
ers (who need to monitor calls for quality assurance), loggers, etc. These =
roles trigger behavior, not the signaling or SDP.

=
We are not specifying a programming language here.

Henning

On Wed, Jul 22, 2015 at 4:59 AM, Brian Rosen <br@brianrosen.net>=
 wrote:
I=E2=80=99m not in favor of this.

I think it=
=E2=80=99s too complex; way, way too complex.

Bria=
n


On Jul 2=
2, 2015, at 10:52 AM, Gunnar Hellstr=C3=B6m <gunnar.hellstrom@omnitor.se> w=
rote:


 =20
   =20
 =20
  

    Can we agree to include this proposed requirements chapter and from
    this proposal identify what should be added or deleted to get the
    center cases included and the corner cases either excluded or just
    enabled by chance? ( a few excluded corner cases are listed in the
    last subsection.)

    I have not changed the chapter after the discussion about
    coordination of languages and modalities in different streams that
    Paul introduced. I am not sure about if that discussion belongs here
    or not. 

    

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

    

    X. Requirements.
    

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

    The system for indication of preferences and capabilities shall meet
    the following requirements:
    

    

    It shall enable negotiation of media, modalities and languages for a
    SIP session.
    

    

    It shall be possible to use it during initiation and modification of
    a session.
    

    

    The system shall consist of a set of indications and usage rules
    specified in this specification and other specifications.
    

    

    The system shall enable a caller to indicate the media, modalities,
    languages and assisting services that the caller prefers to use
    during a real-time session that is about to be established or
    modified.
    

    

    Entities involved in selecting callees and callees shall be enabled
    to view the caller preferences in order to select a callee of many,
    or adjust the set of media, modalities, languages and services
    provided in the session.
    

    

    The caller shall be provided with indication of the resulting media,
    modalities, languages and services enabled during the session.
    

    

    X.1 General
    

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

    It shall be possible to express capabilities and preferences with
    its transmission direction, for transmission or reception or
    bidirectional from the viewpoint of the entity sending the
    indication.
    

    

    The indications shall be suitable for setting in personal profiles,
    in service profiles, or in terminal settings, and possible to adjust
    at session initiation time.
    

    

    It shall be possible to present the outcome of exchange of the
    indications to users in the session.
    

    

    X.2 Media indications.
    

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

    

    It shall be possible to use the indications for audio, video and
    real-time text media.=C2=A0 ( and text messages????)
    

    

    X.3 Modality indications.
    

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

    It shall be possible to use indications for speech and hearing in
    audio media.
    

    

    It shall be possible to use indications for transmitting text and
    receiving text in real-time text media.
    

    

    ( ???=C2=A0 It shall be possible to use indications for transmitting te=
xt
    messages and receiving text messages in text messaging media. ???)
    

    

    It shall be possible to use indications for expressing sign language
    and perceiving sign language in video media.
    

    

    It shall be possible to use indications for showing a speaker and
    for seeing a speaker in video media.
    

    

    X.4 Service indications.
    

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

    It shall be possible to use indications of type of and address of
    and state of invocation of an assisting service available for
    supporting the communication.
    

    

    X.5 Language indications.
    

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

    It shall be possible to indicate ability to express language in a
    number of languages from the ones listed in the language tags of RFC
    5646.
    

    

    It shall be possible to indicate ability to perceive language in a
    number of languages from the ones listed in the language tags of RFC
    5646.
    

    

    The language indication shall be associated with a specific media,
    modality and direction.
    

    

    It shall be possible to indicate ability to express language in an
    unspecified language, meaning a default for a region in the
    associated modality.
    

    

    It shall be possible to indicate ability to perceive language in an
    unspecified language, meaning a default for a region in the
    associated modality.
    

    

    It shall be possible to indicate use of media without any specific
    intention to use the medium for language communication.
    

    

    X.6 Indication of level of preference or capability
    

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

    It shall be possible to indicate an absolute level of preference or
    capability to use a language, modality, media and direction
    combination with a coarse grading.
    

    For preference, the grading shall at least be able to indicate
    strong preference vs can use vs possible fall back usage.
    

    For capability, the grading shall at least be able to indicate good
    capability vs some capability vs limited capability.
    

    Capability and preference shall use the same coding, the difference
    is only in the role of the entity providing the indication. Call
    parties express preferences, service providers express capabilities.
    

    

    More than one direction/media/modality/language preference or
    capability can be expressed per level.
    

    

    It shall be possible for a caller to express if the session should
    be set up or not if no matching direction/media/modality/language
    indications are found.
    

    

    X.7 Type and quality indications
    

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

    It shall be possible to indicate preference and capability of
    different types of real-time text production: conversational type
    versus captioning type. Conversational type is generated by the
    transmitting party in the session, or by a communications agent with
    moderate requirements on delay. Captioning type is generated as
    captions to another modality in the same session with low delay from
    the expression in the other modality. The original modality for
    captions can be speech or sign language.
    

    

    It shall be possible to indicate with language indications if it is
    original or interpreted or artificially created contents.
    

    

    In order to enable communication with persons who have speech that
    is weak or hard to understand, the following quality indications can
    be used:
    

    =C2=A0=C2=A0=C2=A0 -It shall be possible to indicate that the quality o=
f the
    expressed speech makes it hard to understand.
    

    =C2=A0=C2=A0=C2=A0 -It shall be possible to indicate a capability to un=
dertand
    speech that is weak or hard to understand.
    

    

    In order to enable communication with persons who need cognitive
    support in the form of reminders or notetaking, the following
    quality indications can be used:
    

    =C2=A0=C2=A0=C2=A0 -It shall be possible to indicate need of reminders =
or
    notetaking during a session.
    

    =C2=A0=C2=A0=C2=A0 -It shall be possible to indicate a capability to pr=
ovide
    reminders or take notes during a session.
    

    

    

    X.8 Details of service indications
    

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

    The user expressing the indications may be a frequent user of an
    assisting service, that supports the commuication in some often
    occurring need for modality or language translation. By indicating
    this service, a receiver of the indication can judge if invocation
    of that service will support matching of preferences and
    capabilities. Common assiting service types are relay service and
    language translation service.
    

    

    The services are specified with service type, service address,
    invocation state and languages.
    

    Possible service types are:
    

    =C2=A0=C2=A0=C2=A0 Spoken language translation service translating betw=
een
    different spoken languages.
    

    =C2=A0=C2=A0=C2=A0 Video relay service translating between sign languag=
e in video
    and speech in audio.
    

    =C2=A0=C2=A0=C2=A0 Text relay service translating between text in real-=
time text
    and speech in audio.=C2=A0 ( even between text messages and audio exist=
 )
    

    =C2=A0=C2=A0=C2=A0 Captioned telephony adding real-time text in one dir=
ection to
    speech.
    

    =C2=A0=C2=A0=C2=A0 Speech-to-speech adding clear speech when needed to =
speech that
    is weak or hard to understand
    

    =C2=A0=C2=A0=C2=A0 Cognitive support adding reminders or memory notes t=
o speech
    conversation ususlly in combination with the speech-to-speech
    service.
    

    

    Service address shall be a URI where the service can be reached with
    one session for provision of the service within the media of that
    session.
    

    (note that this is different from how most current relay services
    today work. They often have two call legs, one with an audio call
    and one with a multimedia call. )
    

    

    Invocation state shall indicate if the service is already included
    in the call, and if so, the media/modality/language indications show
    the joint capabilities.
    

    Invocation state can also contain a request to the other party to
    invoke the service if needed to complement the capabilities to
    achieve a functioning communication. This indication can be provided
    either by the offering or answering party.
    

    

    Languages shall be media/modality/language indications in pairs
    showing the capabilities of the service.
    

    

    

    X.9 Use in session establishment and modification
    

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

    The indications shall be included in session offer / answer
    exchange.
    

    

    Already specified ways to express media/modality/language shall be
    possible to use to the extent that they are usable.
    

    That includes media and language tags on SIP level and media
    specifications and language tags on SDP level. For cases when these
    existing means imply limitations, these limitations shall be
    explained.
    

    

    The method for identification of language preferences and
    capabilities in this specification is intended mainly for rapid
    ad-hoc session establishment and not intended to have the same
    ambitions as CLUE has for planned telepresence sessions.
    

    

    The indications included in the offer shall represent the
    preferences and capabilities of the offering party.
    

    

    The indications included in the answer shall represent the
    preferences and capabilities of the answering party actually planned
    to be used in the session.
    

    

    

    

    X.10 Security
    

    -----------
    

    It shall be possible to hide the preference and capability
    indications from unintended inspection.
    

    

    X.11 Not covered characteristics
    

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

    Many aspects of a conversation are not covered by the indications
    specified here.
    

    Examples are:
    

    =C2=A0=C2=A0=C2=A0 Gender
    

    =C2=A0=C2=A0=C2=A0 Expertize area
    

    

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

    

    /Gunnar

    

    

    
Den 2015-07-22 kl. 10:24, skrev Henning
      Schulzrinne:

    

    

      
We talked about some examples of cases as being
        "center" and "corner":
        


        

        
(1) "center": customer trying to indicate that they =
prefer
          to speak Spanish when contacting call center;

        
caller indicating preference for ASL when calling an
          emergency number

        


        

        
(2) "corner": simultaneous interpretation case where
          somebody wants to receive both Spanish and English; complex
          ordering of preferences ("I am a native speaker of English;
          fluent in Spanish and can read a menu in Swedish"; "I c=
an
          understand (orally) Latin, but not speak it"; "I rate m=
y
          preference for English, Spanish and Swedish as 9, 7 and 3.5"=
)

        


        

        
There's obviously no problem if the corner case happens to
          work, but no extra effort (syntax, complexity) will be
          expended to make them work. The center-corner cut-off may also
          differ for routing and intra-UAS (SDP) cases since it seems
          reasonable to assume that routing is more coarse-grained and
          has less information about the current (right now), precise
          capabilities of the end point.

        


        

        
Henning

      

      


        
On Wed, Jul 22, 2015 at 4:03 AM, Paul
          Kyzivat <pkyzivat@alum.mit.edu>
          wrote:

          
On 7/22/15
            3:46 AM, Brian Rosen wrote:

            

            

              We will explicitly limit to the 80% cases, and we will
              document use cases in a work group wiki.=C2=A0 We=E2=80=99re =
not going
              to try to cover corner cases.

            

            

            What does that mean? What is and isn't a corner case?

            

            =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,

            =C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

            

            _______________________________________________

            SLIM mailing list

            SLIM@ietf.or=
g

            https://www.ietf.org/mailman/listinfo/slim=


          

        

        

      

      

      

      

      
_______________________________________________
SLIM mailing list
SLIM@ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/slim


    

    

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

  


_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://=
www.ietf.org/mailman/listinfo/slim
=



_______________________________________________
SLIM mailing list

SLIM@ietf.org

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





--089e0118483893c771051b7374ba--


From nobody Wed Jul 22 12:47:03 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 597361ACDE0 for ; Wed, 22 Jul 2015 12:46:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 3iXOp4GFMzrs for ; Wed, 22 Jul 2015 12:46:53 -0700 (PDT)
Received: from bin-vsp-out-02.atm.binero.net (vsp-authed02.binero.net [195.74.38.226]) (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 2D5F71ACE51 for ; Wed, 22 Jul 2015 12:46:51 -0700 (PDT)
X-Halon-ID: 6151b051-30aa-11e5-bc2f-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.43.70] (unknown [2.67.176.197]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Wed, 22 Jul 2015 21:46:43 +0200 (CEST)
To: Henning Schulzrinne , Brian Rosen 
References: <9874942B-DB5E-4092-8C2B-7E159437B491@standardstrack.com> <43B9F9AD-52C2-451A-9A50-B206FFAE3568@brianrosen.net> <55AF4E6A.3060401@alum.mit.edu>  <55AF59C7.605@omnitor.se>  
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <55AFF322.4040006@omnitor.se>
Date: Wed, 22 Jul 2015 21:46:42 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------070307050206030102060209"
Archived-At: 
Cc: slim@ietf.org
Subject: Re: [Slim] Notes from lunch? + Requirements
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jul 2015 19:46:59 -0000

This is a multi-part message in MIME format.
--------------070307050206030102060209
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

If the requirements I proposed were too complex, can we then get 
proposals for what to delete from them.

Compared to the current real-time SLIM draft, I can see the following 
differences:

X.4 Service indications is added. I did that because of two issues: 1. 
the problem of describing a couple of types of relay service users in 
language and modality preference terms, and therefore instead providing 
the opportunity to tell what kind of relay service the user is a regular 
user of. 2. The problem in a multi-national, multi-language situation 
for an answering part to know how to find a suitable assisting service 
to invoke, and therefore introducing a service hint in the coding.

X.6 Priority. I suggest another priority indication than the current 
draft. The current draft has just priority within each medium, while I 
see a need for priority levels between media. Instead I suggest only 
three priority levels instead of the draft now specifying an unlimited 
positional order of priority within each medium.

X.7 The type and quality indications were added, inspired by the 
discussion mainly from the e-mail draft discussion.

X.8 is details of the service indications, briefly introduced in X.4.

The requirements aim at allowing quite general terminals, e.g. using 
IMS, call services that may be located in other countries having no 
previous business agreement, such as an IMS user from one country 
visiting another country and calling emergency services there.

Is that to hope too much? Do you suggest that persons with specific 
other modality needs than two-way speech will always need to be 
registered with service providers who are devoted to their needs?

Or can you propose a subset of the requirements that correspond to the 
central cases?

Gunnar

Den 2015-07-22 kl. 11:32, skrev Henning Schulzrinne:
> I agree; I think this is too prescriptive. The goal is much simpler: 
> Allow the caller to provide enough information so that 
> proxy/UA/SBC/PSAP etc. can make good decisions on what to do. 
> Generally, attempts to tell these entities *how* to do things or 
> exactly what to do is both likely to be ignored and generate unbounded 
> complexity. We went a small distance down that path before, in caller 
> preferences, and the result was not pretty. That effort actually tried 
> to come up with a formal logic, rather than a compilation of ad-hoc 
> cases, but even that led to too many cases to make them practical to 
> implement. Been there, done that, have the T-shirt.
>
> We generally don't need to do this - we don't have generic components 
> in most of the cases of the interest (PSAP, call center, conferencing 
> systems, etc.), but components that, by their nature, have a fair 
> amount of domain-specific knowledge, such as policies about how to 
> handle ASL calls, when and how to bridge in interpreters, who gets 
> what kind of language assistance, etc.  (To be sure, the physical 
> components such as SIP proxies may be generic, but they have been 
> programmed to operate in a specific policy environment, i.e., they 
> turn into an ESRP or PBX/ACD.)
>
> These entities essentially need to know "which of my well-known 
> customer/caller classes is this" and then trigger one of a very small 
> number of behaviors that are programmed ahead of time. This is, among 
> other reasons, the only way that you can test systems. And all of our 
> target systems are high-reliability, can't-fail systems, even if they 
> are not life-safety systems.
>
> Also, in many cases, they may define profiles for users out-of-band. 
> For example, they are likely to define special roles for call takers, 
> language interpreters, managers (who need to monitor calls for quality 
> assurance), loggers, etc. These roles trigger behavior, not the 
> signaling or SDP.
>
> We are not specifying a programming language here.
>
> Henning
>
> On Wed, Jul 22, 2015 at 4:59 AM, Brian Rosen  > wrote:
>
>     I’m not in favor of this.
>
>     I think it’s too complex; way, way too complex.
>
>     Brian
>
>
>>     On Jul 22, 2015, at 10:52 AM, Gunnar Hellström
>>     >     > wrote:
>>
>>     Can we agree to include this proposed requirements chapter and
>>     from this proposal identify what should be added or deleted to
>>     get the center cases included and the corner cases either
>>     excluded or just enabled by chance? ( a few excluded corner cases
>>     are listed in the last subsection.)
>>     I have not changed the chapter after the discussion about
>>     coordination of languages and modalities in different streams
>>     that Paul introduced. I am not sure about if that discussion
>>     belongs here or not.
>>
>>     -----------------------------------
>>
>>     X. Requirements.
>>     ------------------------
>>     The system for indication of preferences and capabilities shall
>>     meet the following requirements:
>>
>>     It shall enable negotiation of media, modalities and languages
>>     for a SIP session.
>>
>>     It shall be possible to use it during initiation and modification
>>     of a session.
>>
>>     The system shall consist of a set of indications and usage rules
>>     specified in this specification and other specifications.
>>
>>     The system shall enable a caller to indicate the media,
>>     modalities, languages and assisting services that the caller
>>     prefers to use during a real-time session that is about to be
>>     established or modified.
>>
>>     Entities involved in selecting callees and callees shall be
>>     enabled to view the caller preferences in order to select a
>>     callee of many, or adjust the set of media, modalities, languages
>>     and services provided in the session.
>>
>>     The caller shall be provided with indication of the resulting
>>     media, modalities, languages and services enabled during the
>>     session.
>>
>>     X.1 General
>>     ------------
>>     It shall be possible to express capabilities and preferences with
>>     its transmission direction, for transmission or reception or
>>     bidirectional from the viewpoint of the entity sending the
>>     indication.
>>
>>     The indications shall be suitable for setting in personal
>>     profiles, in service profiles, or in terminal settings, and
>>     possible to adjust at session initiation time.
>>
>>     It shall be possible to present the outcome of exchange of the
>>     indications to users in the session.
>>
>>     X.2 Media indications.
>>     -------------------------
>>
>>     It shall be possible to use the indications for audio, video and
>>     real-time text media.  ( and text messages????)
>>
>>     X.3 Modality indications.
>>     ----------------------------
>>     It shall be possible to use indications for speech and hearing in
>>     audio media.
>>
>>     It shall be possible to use indications for transmitting text and
>>     receiving text in real-time text media.
>>
>>     ( ???  It shall be possible to use indications for transmitting
>>     text messages and receiving text messages in text messaging
>>     media. ???)
>>
>>     It shall be possible to use indications for expressing sign
>>     language and perceiving sign language in video media.
>>
>>     It shall be possible to use indications for showing a speaker and
>>     for seeing a speaker in video media.
>>
>>     X.4 Service indications.
>>     --------------------------
>>     It shall be possible to use indications of type of and address of
>>     and state of invocation of an assisting service available for
>>     supporting the communication.
>>
>>     X.5 Language indications.
>>     -----------------------------
>>     It shall be possible to indicate ability to express language in a
>>     number of languages from the ones listed in the language tags of
>>     RFC 5646.
>>
>>     It shall be possible to indicate ability to perceive language in
>>     a number of languages from the ones listed in the language tags
>>     of RFC 5646.
>>
>>     The language indication shall be associated with a specific
>>     media, modality and direction.
>>
>>     It shall be possible to indicate ability to express language in
>>     an unspecified language, meaning a default for a region in the
>>     associated modality.
>>
>>     It shall be possible to indicate ability to perceive language in
>>     an unspecified language, meaning a default for a region in the
>>     associated modality.
>>
>>     It shall be possible to indicate use of media without any
>>     specific intention to use the medium for language communication.
>>
>>     X.6 Indication of level of preference or capability
>>     --------------------------------------------------------
>>     It shall be possible to indicate an absolute level of preference
>>     or capability to use a language, modality, media and direction
>>     combination with a coarse grading.
>>     For preference, the grading shall at least be able to indicate
>>     strong preference vs can use vs possible fall back usage.
>>     For capability, the grading shall at least be able to indicate
>>     good capability vs some capability vs limited capability.
>>     Capability and preference shall use the same coding, the
>>     difference is only in the role of the entity providing the
>>     indication. Call parties express preferences, service providers
>>     express capabilities.
>>
>>     More than one direction/media/modality/language preference or
>>     capability can be expressed per level.
>>
>>     It shall be possible for a caller to express if the session
>>     should be set up or not if no matching
>>     direction/media/modality/language indications are found.
>>
>>     X.7 Type and quality indications
>>     -------------------------------------
>>     It shall be possible to indicate preference and capability of
>>     different types of real-time text production: conversational type
>>     versus captioning type. Conversational type is generated by the
>>     transmitting party in the session, or by a communications agent
>>     with moderate requirements on delay. Captioning type is generated
>>     as captions to another modality in the same session with low
>>     delay from the expression in the other modality. The original
>>     modality for captions can be speech or sign language.
>>
>>     It shall be possible to indicate with language indications if it
>>     is original or interpreted or artificially created contents.
>>
>>     In order to enable communication with persons who have speech
>>     that is weak or hard to understand, the following quality
>>     indications can be used:
>>         -It shall be possible to indicate that the quality of the
>>     expressed speech makes it hard to understand.
>>         -It shall be possible to indicate a capability to undertand
>>     speech that is weak or hard to understand.
>>
>>     In order to enable communication with persons who need cognitive
>>     support in the form of reminders or notetaking, the following
>>     quality indications can be used:
>>         -It shall be possible to indicate need of reminders or
>>     notetaking during a session.
>>         -It shall be possible to indicate a capability to provide
>>     reminders or take notes during a session.
>>
>>
>>     X.8 Details of service indications
>>     ----------------------------------------
>>     The user expressing the indications may be a frequent user of an
>>     assisting service, that supports the commuication in some often
>>     occurring need for modality or language translation. By
>>     indicating this service, a receiver of the indication can judge
>>     if invocation of that service will support matching of
>>     preferences and capabilities. Common assiting service types are
>>     relay service and language translation service.
>>
>>     The services are specified with service type, service address,
>>     invocation state and languages.
>>     Possible service types are:
>>         Spoken language translation service translating between
>>     different spoken languages.
>>         Video relay service translating between sign language in
>>     video and speech in audio.
>>         Text relay service translating between text in real-time text
>>     and speech in audio.  ( even between text messages and audio exist )
>>         Captioned telephony adding real-time text in one direction to
>>     speech.
>>         Speech-to-speech adding clear speech when needed to speech
>>     that is weak or hard to understand
>>         Cognitive support adding reminders or memory notes to speech
>>     conversation ususlly in combination with the speech-to-speech
>>     service.
>>
>>     Service address shall be a URI where the service can be reached
>>     with one session for provision of the service within the media of
>>     that session.
>>     (note that this is different from how most current relay services
>>     today work. They often have two call legs, one with an audio call
>>     and one with a multimedia call. )
>>
>>     Invocation state shall indicate if the service is already
>>     included in the call, and if so, the media/modality/language
>>     indications show the joint capabilities.
>>     Invocation state can also contain a request to the other party to
>>     invoke the service if needed to complement the capabilities to
>>     achieve a functioning communication. This indication can be
>>     provided either by the offering or answering party.
>>
>>     Languages shall be media/modality/language indications in pairs
>>     showing the capabilities of the service.
>>
>>
>>     X.9 Use in session establishment and modification
>>     -------------------------------------------------------------
>>     The indications shall be included in session offer / answer
>>     exchange.
>>
>>     Already specified ways to express media/modality/language shall
>>     be possible to use to the extent that they are usable.
>>     That includes media and language tags on SIP level and media
>>     specifications and language tags on SDP level. For cases when
>>     these existing means imply limitations, these limitations shall
>>     be explained.
>>
>>     The method for identification of language preferences and
>>     capabilities in this specification is intended mainly for rapid
>>     ad-hoc session establishment and not intended to have the same
>>     ambitions as CLUE has for planned telepresence sessions.
>>
>>     The indications included in the offer shall represent the
>>     preferences and capabilities of the offering party.
>>
>>     The indications included in the answer shall represent the
>>     preferences and capabilities of the answering party actually
>>     planned to be used in the session.
>>
>>
>>
>>     X.10 Security
>>     -----------
>>     It shall be possible to hide the preference and capability
>>     indications from unintended inspection.
>>
>>     X.11 Not covered characteristics
>>     ------------------------------------
>>     Many aspects of a conversation are not covered by the indications
>>     specified here.
>>     Examples are:
>>         Gender
>>         Expertize area
>>
>>     --------------------------------------
>>
>>     /Gunnar
>>
>>
>>     Den 2015-07-22 kl. 10:24, skrev Henning Schulzrinne:
>>>     We talked about some examples of cases as being "center" and
>>>     "corner":
>>>
>>>     (1) "center": customer trying to indicate that they prefer to
>>>     speak Spanish when contacting call center;
>>>     caller indicating preference for ASL when calling an emergency
>>>     number
>>>
>>>     (2) "corner": simultaneous interpretation case where somebody
>>>     wants to receive both Spanish and English; complex ordering of
>>>     preferences ("I am a native speaker of English; fluent in
>>>     Spanish and can read a menu in Swedish"; "I can understand
>>>     (orally) Latin, but not speak it"; "I rate my preference for
>>>     English, Spanish and Swedish as 9, 7 and 3.5")
>>>
>>>     There's obviously no problem if the corner case happens to work,
>>>     but no extra effort (syntax, complexity) will be expended to
>>>     make them work. The center-corner cut-off may also differ for
>>>     routing and intra-UAS (SDP) cases since it seems reasonable to
>>>     assume that routing is more coarse-grained and has less
>>>     information about the current (right now), precise capabilities
>>>     of the end point.
>>>
>>>     Henning
>>>
>>>     On Wed, Jul 22, 2015 at 4:03 AM, Paul Kyzivat
>>>     > wrote:
>>>
>>>         On 7/22/15 3:46 AM, Brian Rosen wrote:
>>>
>>>             We will explicitly limit to the 80% cases, and we will
>>>             document use cases in a work group wiki.  We’re not
>>>             going to try to cover corner cases.
>>>
>>>
>>>         What does that mean? What is and isn't a corner case?
>>>
>>>                 Thanks,
>>>                 Paul
>>>
>>>         _______________________________________________
>>>         SLIM mailing list
>>>         SLIM@ietf.org 
>>>         https://www.ietf.org/mailman/listinfo/slim
>>>
>>>
>>>
>>>
>>>     _______________________________________________
>>>     SLIM mailing list
>>>     SLIM@ietf.org 
>>>     https://www.ietf.org/mailman/listinfo/slim
>>
>>     -- 
>>     -----------------------------------------
>>     Gunnar Hellström
>>     Omnitor
>>     gunnar.hellstrom@omnitor.se 
>>     +46 708 204 288
>>     _______________________________________________
>>     SLIM mailing list
>>     SLIM@ietf.org 
>>     https://www.ietf.org/mailman/listinfo/slim
>
>
>     _______________________________________________
>     SLIM mailing list
>     SLIM@ietf.org 
>     https://www.ietf.org/mailman/listinfo/slim
>
>

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


--------------070307050206030102060209
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    If the requirements I proposed were too complex, can we then get
    proposals for what to delete from them.

    

    Compared to the current real-time SLIM draft, I can see the
    following differences:

    

    X.4 Service indications is added. I did that because of two issues:
    1. the problem of describing a couple of types of relay service
    users in language and modality preference terms, and therefore
    instead providing the opportunity to tell what kind of relay service
    the user is a regular user of. 2. The problem in a multi-national,
    multi-language situation for an answering part to know how to find a
    suitable assisting service to invoke, and therefore introducing a
    service hint in the coding. 

    

    X.6 Priority. I suggest another priority indication than the current
    draft. The current draft has just priority within each medium, while
    I see a need for priority levels between media. Instead I suggest
    only three priority levels instead of the draft now specifying an
    unlimited positional order of priority within each medium.  

    

    X.7 The type and quality indications were added, inspired by the
    discussion mainly from the e-mail draft discussion.

    

    X.8 is details of the service indications, briefly introduced in
    X.4.

    

    The requirements aim at allowing quite general terminals, e.g. using
    IMS, call services that may be located in other countries having no
    previous business agreement, such as an IMS user from one country
    visiting another country and calling emergency services there.

    

    Is that to hope too much? Do you suggest that persons with specific
    other modality needs than two-way speech will always need to be
    registered with service providers who are devoted to their needs?

    

    Or can you propose a subset of the requirements that correspond to
    the central cases?

    

    Gunnar

    

    
Den 2015-07-22 kl. 11:32, skrev Henning
      Schulzrinne:

    

    

      
I agree; I think this is too prescriptive. The goal
        is much simpler: Allow the caller to provide enough information
        so that proxy/UA/SBC/PSAP etc. can make good decisions on what
        to do. Generally, attempts to tell these entities *how* to do
        things or exactly what to do is both likely to be ignored and
        generate unbounded complexity. We went a small distance down
        that path before, in caller preferences, and the result was not
        pretty. That effort actually tried to come up with a formal
        logic, rather than a compilation of ad-hoc cases, but even that
        led to too many cases to make them practical to implement. Been
        there, done that, have the T-shirt.
        


        

        
We generally don't need to do this - we don't have generic
          components in most of the cases of the interest (PSAP, call
          center, conferencing systems, etc.), but components that, by
          their nature, have a fair amount of domain-specific knowledge,
          such as policies about how to handle ASL calls, when and how
          to bridge in interpreters, who gets what kind of language
          assistance, etc.  (To be sure, the physical components such as
          SIP proxies may be generic, but they have been programmed to
          operate in a specific policy environment, i.e., they turn into
          an ESRP or PBX/ACD.)

        


        

        
These entities essentially need to know "which of my
          well-known customer/caller classes is this" and then trigger
          one of a very small number of behaviors that are programmed
          ahead of time. This is, among other reasons, the only way that
          you can test systems. And all of our target systems are
          high-reliability, can't-fail systems, even if they are not
          life-safety systems.

        


        

        
Also, in many cases, they may define profiles for users
          out-of-band. For example, they are likely to define special
          roles for call takers, language interpreters, managers (who
          need to monitor calls for quality assurance), loggers, etc.
          These roles trigger behavior, not the signaling or SDP.

        


        

        
We are not specifying a programming language here.

        


        

        
Henning

      

      


        
On Wed, Jul 22, 2015 at 4:59 AM, Brian
          Rosen <br@brianrosen.net>
          wrote:

          

            
I’m not in favor of this.
              


              

              
I think it’s too complex; way, way too complex.

              


              

              
Brian

              


              

              


                

                  

                    
On Jul 22, 2015, at 10:52 AM, Gunnar Hellström
                      <gunnar.hellstrom@omnitor.se>
                      wrote:

                    

                    

                      
 Can we
                        agree to include this proposed requirements
                        chapter and from this proposal identify what
                        should be added or deleted to get the center
                        cases included and the corner cases either
                        excluded or just enabled by chance? ( a few
                        excluded corner cases are listed in the last
                        subsection.)

                        I have not changed the chapter after the
                        discussion about coordination of languages and
                        modalities in different streams that Paul
                        introduced. I am not sure about if that
                        discussion belongs here or not. 

                        

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

                        

                        X. Requirements. 

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

                        The system for indication of preferences and
                        capabilities shall meet the following
                        requirements: 

                        

                        It shall enable negotiation of media, modalities
                        and languages for a SIP session. 

                        

                        It shall be possible to use it during initiation
                        and modification of a session. 

                        

                        The system shall consist of a set of indications
                        and usage rules specified in this specification
                        and other specifications. 

                        

                        The system shall enable a caller to indicate the
                        media, modalities, languages and assisting
                        services that the caller prefers to use during a
                        real-time session that is about to be
                        established or modified. 

                        

                        Entities involved in selecting callees and
                        callees shall be enabled to view the caller
                        preferences in order to select a callee of many,
                        or adjust the set of media, modalities,
                        languages and services provided in the session.
                        

                        

                        The caller shall be provided with indication of
                        the resulting media, modalities, languages and
                        services enabled during the session. 

                        

                        X.1 General 

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

                        It shall be possible to express capabilities and
                        preferences with its transmission direction, for
                        transmission or reception or bidirectional from
                        the viewpoint of the entity sending the
                        indication. 

                        

                        The indications shall be suitable for setting in
                        personal profiles, in service profiles, or in
                        terminal settings, and possible to adjust at
                        session initiation time. 

                        

                        It shall be possible to present the outcome of
                        exchange of the indications to users in the
                        session. 

                        

                        X.2 Media indications. 

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

                        

                        It shall be possible to use the indications for
                        audio, video and real-time text media.  ( and
                        text messages????) 

                        

                        X.3 Modality indications. 

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

                        It shall be possible to use indications for
                        speech and hearing in audio media. 

                        

                        It shall be possible to use indications for
                        transmitting text and receiving text in
                        real-time text media. 

                        

                        ( ???  It shall be possible to use indications
                        for transmitting text messages and receiving
                        text messages in text messaging media. ???) 

                        

                        It shall be possible to use indications for
                        expressing sign language and perceiving sign
                        language in video media. 

                        

                        It shall be possible to use indications for
                        showing a speaker and for seeing a speaker in
                        video media. 

                        

                        X.4 Service indications. 

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

                        It shall be possible to use indications of type
                        of and address of and state of invocation of an
                        assisting service available for supporting the
                        communication. 

                        

                        X.5 Language indications. 

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

                        It shall be possible to indicate ability to
                        express language in a number of languages from
                        the ones listed in the language tags of RFC
                        5646. 

                        

                        It shall be possible to indicate ability to
                        perceive language in a number of languages from
                        the ones listed in the language tags of RFC
                        5646. 

                        

                        The language indication shall be associated with
                        a specific media, modality and direction. 

                        

                        It shall be possible to indicate ability to
                        express language in an unspecified language,
                        meaning a default for a region in the associated
                        modality. 

                        

                        It shall be possible to indicate ability to
                        perceive language in an unspecified language,
                        meaning a default for a region in the associated
                        modality. 

                        

                        It shall be possible to indicate use of media
                        without any specific intention to use the medium
                        for language communication. 

                        

                        X.6 Indication of level of preference or
                        capability 

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

                        

                        It shall be possible to indicate an absolute
                        level of preference or capability to use a
                        language, modality, media and direction
                        combination with a coarse grading. 

                        For preference, the grading shall at least be
                        able to indicate strong preference vs can use vs
                        possible fall back usage. 

                        For capability, the grading shall at least be
                        able to indicate good capability vs some
                        capability vs limited capability. 

                        Capability and preference shall use the same
                        coding, the difference is only in the role of
                        the entity providing the indication. Call
                        parties express preferences, service providers
                        express capabilities. 

                        

                        More than one direction/media/modality/language
                        preference or capability can be expressed per
                        level. 

                        

                        It shall be possible for a caller to express if
                        the session should be set up or not if no
                        matching direction/media/modality/language
                        indications are found. 

                        

                        X.7 Type and quality indications 

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

                        It shall be possible to indicate preference and
                        capability of different types of real-time text
                        production: conversational type versus
                        captioning type. Conversational type is
                        generated by the transmitting party in the
                        session, or by a communications agent with
                        moderate requirements on delay. Captioning type
                        is generated as captions to another modality in
                        the same session with low delay from the
                        expression in the other modality. The original
                        modality for captions can be speech or sign
                        language. 

                        

                        It shall be possible to indicate with language
                        indications if it is original or interpreted or
                        artificially created contents. 

                        

                        In order to enable communication with persons
                        who have speech that is weak or hard to
                        understand, the following quality indications
                        can be used: 

                            -It shall be possible to indicate that the
                        quality of the expressed speech makes it hard to
                        understand. 

                            -It shall be possible to indicate a
                        capability to undertand speech that is weak or
                        hard to understand. 

                        

                        In order to enable communication with persons
                        who need cognitive support in the form of
                        reminders or notetaking, the following quality
                        indications can be used: 

                            -It shall be possible to indicate need of
                        reminders or notetaking during a session. 

                            -It shall be possible to indicate a
                        capability to provide reminders or take notes
                        during a session. 

                        

                        

                        X.8 Details of service indications 

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

                        The user expressing the indications may be a
                        frequent user of an assisting service, that
                        supports the commuication in some often
                        occurring need for modality or language
                        translation. By indicating this service, a
                        receiver of the indication can judge if
                        invocation of that service will support matching
                        of preferences and capabilities. Common assiting
                        service types are relay service and language
                        translation service. 

                        

                        The services are specified with service type,
                        service address, invocation state and languages.
                        

                        Possible service types are: 

                            Spoken language translation service
                        translating between different spoken languages.
                        

                            Video relay service translating between sign
                        language in video and speech in audio. 

                            Text relay service translating between text
                        in real-time text and speech in audio.  ( even
                        between text messages and audio exist ) 

                            Captioned telephony adding real-time text in
                        one direction to speech. 

                            Speech-to-speech adding clear speech when
                        needed to speech that is weak or hard to
                        understand 

                            Cognitive support adding reminders or memory
                        notes to speech conversation ususlly in
                        combination with the speech-to-speech service. 

                        

                        Service address shall be a URI where the service
                        can be reached with one session for provision of
                        the service within the media of that session. 

                        (note that this is different from how most
                        current relay services today work. They often
                        have two call legs, one with an audio call and
                        one with a multimedia call. ) 

                        

                        Invocation state shall indicate if the service
                        is already included in the call, and if so, the
                        media/modality/language indications show the
                        joint capabilities. 

                        Invocation state can also contain a request to
                        the other party to invoke the service if needed
                        to complement the capabilities to achieve a
                        functioning communication. This indication can
                        be provided either by the offering or answering
                        party. 

                        

                        Languages shall be media/modality/language
                        indications in pairs showing the capabilities of
                        the service. 

                        

                        

                        X.9 Use in session establishment and
                        modification 

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

                        

                        The indications shall be included in session
                        offer / answer exchange. 

                        

                        Already specified ways to express
                        media/modality/language shall be possible to use
                        to the extent that they are usable. 

                        That includes media and language tags on SIP
                        level and media specifications and language tags
                        on SDP level. For cases when these existing
                        means imply limitations, these limitations shall
                        be explained. 

                        

                        The method for identification of language
                        preferences and capabilities in this
                        specification is intended mainly for rapid
                        ad-hoc session establishment and not intended to
                        have the same ambitions as CLUE has for planned
                        telepresence sessions. 

                        

                        The indications included in the offer shall
                        represent the preferences and capabilities of
                        the offering party. 

                        

                        The indications included in the answer shall
                        represent the preferences and capabilities of
                        the answering party actually planned to be used
                        in the session. 

                        

                        

                        

                        X.10 Security 

                        ----------- 

                        It shall be possible to hide the preference and
                        capability indications from unintended
                        inspection. 

                        

                        X.11 Not covered characteristics 

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

                        Many aspects of a conversation are not covered
                        by the indications specified here. 

                        Examples are: 

                            Gender 

                            Expertize area 

                        

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

                        

                        /Gunnar

                        

                        

                        
Den 2015-07-22 kl. 10:24, skrev Henning
                          Schulzrinne:

                        

                        

                          
We talked about some examples
                            of cases as being "center" and "corner":
                            


                            

                            
(1) "center": customer trying to
                              indicate that they prefer to speak Spanish
                              when contacting call center;

                            
caller indicating preference for ASL
                              when calling an emergency number

                            


                            

                            
(2) "corner": simultaneous
                              interpretation case where somebody wants
                              to receive both Spanish and English;
                              complex ordering of preferences ("I am a
                              native speaker of English; fluent in
                              Spanish and can read a menu in Swedish";
                              "I can understand (orally) Latin, but not
                              speak it"; "I rate my preference for
                              English, Spanish and Swedish as 9, 7 and
                              3.5")

                            


                            

                            
There's obviously no problem if the
                              corner case happens to work, but no extra
                              effort (syntax, complexity) will be
                              expended to make them work. The
                              center-corner cut-off may also differ for
                              routing and intra-UAS (SDP) cases since it
                              seems reasonable to assume that routing is
                              more coarse-grained and has less
                              information about the current (right now),
                              precise capabilities of the end point.

                            


                            

                            
Henning

                          

                          


                            
On Wed, Jul 22,
                              2015 at 4:03 AM, Paul Kyzivat <pkyzivat@alum.mit.edu>
                              wrote:

                              
On 7/22/15
                                3:46 AM, Brian Rosen wrote:

                                

                                
 We will
                                  explicitly limit to the 80% cases, and
                                  we will document use cases in a work
                                  group wiki.  We’re not going to try to
                                  cover corner cases.

                                

                                

                                What does that mean? What is and isn't a
                                corner case?

                                

                                        Thanks,

                                        Paul

                                

_______________________________________________

                                SLIM mailing list

                                SLIM@ietf.org

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

                              

                            

                            

                          

                          

                          

                          

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


                        

                        

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

                          

                      
_______________________________________________

                          SLIM mailing list

                          SLIM@ietf.org

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

                        

                  

                

                

              

            

            

            _______________________________________________

            SLIM mailing list

            SLIM@ietf.org

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

            

          

        

        

      

    

    

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

  


--------------070307050206030102060209--


From nobody Wed Jul 22 13:26:19 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64CA31A001C for ; Wed, 22 Jul 2015 13:26:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level: 
X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 djFG8wDbtPz1 for ; Wed, 22 Jul 2015 13:26:10 -0700 (PDT)
Received: from buckwheat.cc.columbia.edu (buckwheat.cc.columbia.edu [128.59.72.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 920DA1ACD63 for ; Wed, 22 Jul 2015 13:26:09 -0700 (PDT)
Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by buckwheat.cc.columbia.edu (8.13.8/8.13.8) with ESMTP id t6MKO4nB028544 for ; Wed, 22 Jul 2015 16:26:08 -0400
Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id 9F81F7E for ; Wed, 22 Jul 2015 16:26:08 -0400 (EDT)
Received: from paneer.cc.columbia.edu (paneer.cc.columbia.edu [128.59.29.4]) by hazelnut (Postfix) with ESMTP id 82F4D6D for ; Wed, 22 Jul 2015 16:26:08 -0400 (EDT)
Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com [209.85.213.179]) by paneer.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id t6MKQ7ZB009989 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 22 Jul 2015 16:26:08 -0400 (EDT)
Received: by iggf3 with SMTP id f3so142284786igg.1 for ; Wed, 22 Jul 2015 13:26:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XA7HOrDqHctIZLGXLl/lv5IDOcQDc2lNGVAHznPIyI0=; b=DV32e6GfI9L3EVJoTTPZaTA382yatqnilY8iyjkRDRekh2Tju7BH3vIU3gfoMH/FYt Q/w2RgTV6y3OCJwYIl+OWef+nXMrsyu8a61Xqqyj/Hing6wY/0XkmDl4OLj2ta4avycJ 8H0sATJKT8zKv++t0KOqd1Co1bup880RGW6AjreiG6sQaXkd7MXDW8htk5aj7FtUDWp8 rBSZMoI3EK9+cdVF1o4ifP7exiMGv+Aj/3xa7qg8wWgozyg0/JChkzwUpcDpdrIyw3RS A0T689Pd/oS3MtHCfppUYvLkLLgySU0AVbo36pchVMgLYNuBHOZao5OkUsgUMIcqENbC PI7Q==
X-Gm-Message-State: ALoCoQnUSLWPSV2/mLiz5Q8wSvO7U/EOqAr2uxVoVk/Wc6ZD+/xo+34OCU3xn1MoDv0u/o27E0g/47SuBUBZP9boXgHbSQzRLQmGEgw7CNxvTegFbcnGnvlsWeVPcck71+iprI/nSLb9
X-Received: by 10.107.134.78 with SMTP id i75mr6642496iod.88.1437596767624; Wed, 22 Jul 2015 13:26:07 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.107.134.78 with SMTP id i75mr6642468iod.88.1437596767414; Wed, 22 Jul 2015 13:26:07 -0700 (PDT)
Received: by 10.36.120.69 with HTTP; Wed, 22 Jul 2015 13:26:07 -0700 (PDT)
In-Reply-To: <55AFF322.4040006@omnitor.se>
References: <9874942B-DB5E-4092-8C2B-7E159437B491@standardstrack.com> <43B9F9AD-52C2-451A-9A50-B206FFAE3568@brianrosen.net> <55AF4E6A.3060401@alum.mit.edu>  <55AF59C7.605@omnitor.se>   <55AFF322.4040006@omnitor.se>
Date: Wed, 22 Jul 2015 16:26:07 -0400
Message-ID: 
From: Henning Schulzrinne 
To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= 
Content-Type: multipart/alternative; boundary=001a113ecbbaa70148051b7c94f6
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.68 on 128.59.29.4
Archived-At: 
Cc: slim@ietf.org, Brian Rosen 
Subject: Re: [Slim] Notes from lunch? + Requirements
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jul 2015 20:26:17 -0000

--001a113ecbbaa70148051b7c94f6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

The problem is not a list of requirements, it's the overall model. Your
model, if I understand this correctly, is that the signaling (in SDP, but
the same would apply in SIP) explicitly provides a list of options for the
receiver to choose from, with preferences. However, that's not how real
systems work - they are not Turing machines where you feed them inputs and
they produce predictable outputs, across a nearly infinite set of
behaviors. (They do, at the low level of SIP exchanges and some SDP
matching, but those behaviors are tightly constrained by the state machine
and "dumb". Even those cause a fair amount of interoperability problems if
implementations start exploring the corners of legal, but uncommon,
behavior.)

Generally, these systems have a very small set of operations ("invoke
LanguageLine", "bridge supervisor") that are invoked based on some small
number of triggers. These behaviors differs based on which system you are
reaching - an ACD for a bank will have a different set than a PSAP, even
though they are roughly similar (in the voice world, both are often based
on the same commercial ACD implementations), and a dial-in conferencing
system will have a rather different set.

Assume a PSAP expects three kinds of callers:
(1) voice callers, possibly with different spoken languages

(2) ASL-only caller (where the behavior depends on whether the PSAP has an
ASL call taker and the country/region-specific handling of relay)

(3) ASL+text caller, where local policy allows text-only

The PSAP just needs to know which of these cases it is dealing with, and it
will invoke a standard operating procedure for one of these. Any other
combinations will simply be "converted" into the least common denominator
(For example, ASL + Russian text may not be handled at all since it is so
uncommon, likely being treated as "ASL-only" or the language being ignored.
It won't magically invoke a text translator unless it has one for other
purposes.)

Within these categories, there might be variations. For example, (1) may
allow for multimedia, adding either text and/or video in addition to audio,
but that's low-level behavior in the UAs and standard SDP behavior that we
don't need to modify.

Complexity starts to creep when you are trying to do one of the following:

(1) Have cross-media dependencies ("only do X for media M1 if Y for media
M2")

(2) Preference orderings that are more than just plain "I like A best and
then B, C or D" (e.g., complex preferences like "I like A and B equally,
and then like C and D a little less, but barely put up with E")

(3) Telling the receiver of the call precisely what to do ("I want human
translation", "I want the PSAP, not the relay service, to invoke relay", "I
don't want to talk to you unless you can do at least 93.5% of what I asked
for")


Thus, I'd start the other way: For SDP, the draft, if I understand this
correctly, proposes starting with a simple language description for each
media (separate for each direction).

I will likely propose something simple like the following for SIP call
routing:

Call-Routing: text=3Den; video=3Dase

or

Call-Routing: en,fr (if the caller has a single set of language across all
language-dependent media; this example might be for a Canadian living in
Toronto)

[I may re-use a subset of caller preferences if that's easy, so ignore the
strawman syntax.]

If we start there, are there practical use cases where a receiving PSAP or
call center wouldn't know what to do and which kind of actually-existing
human they are communicating with (and thus invoke the appropriate
functionality)? If so, we should identify these cases and see whether they
can be addressed by minor extensions of the idea or fall in the "let's see
if we can solve this some other way" category.

Henning

On Wed, Jul 22, 2015 at 3:46 PM, Gunnar Hellstr=C3=B6m <
gunnar.hellstrom@omnitor.se> wrote:

>  If the requirements I proposed were too complex, can we then get
> proposals for what to delete from them.
>
> Compared to the current real-time SLIM draft, I can see the following
> differences:
>
> X.4 Service indications is added. I did that because of two issues: 1. th=
e
> problem of describing a couple of types of relay service users in languag=
e
> and modality preference terms, and therefore instead providing the
> opportunity to tell what kind of relay service the user is a regular user
> of. 2. The problem in a multi-national, multi-language situation for an
> answering part to know how to find a suitable assisting service to invoke=
,
> and therefore introducing a service hint in the coding.
>
> X.6 Priority. I suggest another priority indication than the current
> draft. The current draft has just priority within each medium, while I se=
e
> a need for priority levels between media. Instead I suggest only three
> priority levels instead of the draft now specifying an unlimited position=
al
> order of priority within each medium.
>
> X.7 The type and quality indications were added, inspired by the
> discussion mainly from the e-mail draft discussion.
>
> X.8 is details of the service indications, briefly introduced in X.4.
>
> The requirements aim at allowing quite general terminals, e.g. using IMS,
> call services that may be located in other countries having no previous
> business agreement, such as an IMS user from one country visiting another
> country and calling emergency services there.
>
> Is that to hope too much? Do you suggest that persons with specific other
> modality needs than two-way speech will always need to be registered with
> service providers who are devoted to their needs?
>
> Or can you propose a subset of the requirements that correspond to the
> central cases?
>
> Gunnar
>
> Den 2015-07-22 kl. 11:32, skrev Henning Schulzrinne:
>
> I agree; I think this is too prescriptive. The goal is much simpler: Allo=
w
> the caller to provide enough information so that proxy/UA/SBC/PSAP etc. c=
an
> make good decisions on what to do. Generally, attempts to tell these
> entities *how* to do things or exactly what to do is both likely to be
> ignored and generate unbounded complexity. We went a small distance down
> that path before, in caller preferences, and the result was not pretty.
> That effort actually tried to come up with a formal logic, rather than a
> compilation of ad-hoc cases, but even that led to too many cases to make
> them practical to implement. Been there, done that, have the T-shirt.
>
>  We generally don't need to do this - we don't have generic components in
> most of the cases of the interest (PSAP, call center, conferencing system=
s,
> etc.), but components that, by their nature, have a fair amount of
> domain-specific knowledge, such as policies about how to handle ASL calls=
,
> when and how to bridge in interpreters, who gets what kind of language
> assistance, etc.  (To be sure, the physical components such as SIP proxie=
s
> may be generic, but they have been programmed to operate in a specific
> policy environment, i.e., they turn into an ESRP or PBX/ACD.)
>
>  These entities essentially need to know "which of my well-known
> customer/caller classes is this" and then trigger one of a very small
> number of behaviors that are programmed ahead of time. This is, among oth=
er
> reasons, the only way that you can test systems. And all of our target
> systems are high-reliability, can't-fail systems, even if they are not
> life-safety systems.
>
>  Also, in many cases, they may define profiles for users out-of-band. For
> example, they are likely to define special roles for call takers, languag=
e
> interpreters, managers (who need to monitor calls for quality assurance),
> loggers, etc. These roles trigger behavior, not the signaling or SDP.
>
>  We are not specifying a programming language here.
>
>  Henning
>
> On Wed, Jul 22, 2015 at 4:59 AM, Brian Rosen  wrote:
>
>> I=E2=80=99m not in favor of this.
>>
>>  I think it=E2=80=99s too complex; way, way too complex.
>>
>>  Brian
>>
>>
>>  On Jul 22, 2015, at 10:52 AM, Gunnar Hellstr=C3=B6m <
>> gunnar.hellstrom@omnitor.se> wrote:
>>
>>  Can we agree to include this proposed requirements chapter and from
>> this proposal identify what should be added or deleted to get the center
>> cases included and the corner cases either excluded or just enabled by
>> chance? ( a few excluded corner cases are listed in the last subsection.=
)
>> I have not changed the chapter after the discussion about coordination o=
f
>> languages and modalities in different streams that Paul introduced. I am
>> not sure about if that discussion belongs here or not.
>>
>> -----------------------------------
>>
>> X. Requirements.
>> ------------------------
>> The system for indication of preferences and capabilities shall meet the
>> following requirements:
>>
>> It shall enable negotiation of media, modalities and languages for a SIP
>> session.
>>
>> It shall be possible to use it during initiation and modification of a
>> session.
>>
>> The system shall consist of a set of indications and usage rules
>> specified in this specification and other specifications.
>>
>> The system shall enable a caller to indicate the media, modalities,
>> languages and assisting services that the caller prefers to use during a
>> real-time session that is about to be established or modified.
>>
>> Entities involved in selecting callees and callees shall be enabled to
>> view the caller preferences in order to select a callee of many, or adju=
st
>> the set of media, modalities, languages and services provided in the
>> session.
>>
>> The caller shall be provided with indication of the resulting media,
>> modalities, languages and services enabled during the session.
>>
>> X.1 General
>> ------------
>> It shall be possible to express capabilities and preferences with its
>> transmission direction, for transmission or reception or bidirectional f=
rom
>> the viewpoint of the entity sending the indication.
>>
>> The indications shall be suitable for setting in personal profiles, in
>> service profiles, or in terminal settings, and possible to adjust at
>> session initiation time.
>>
>> It shall be possible to present the outcome of exchange of the
>> indications to users in the session.
>>
>> X.2 Media indications.
>> -------------------------
>>
>> It shall be possible to use the indications for audio, video and
>> real-time text media.  ( and text messages????)
>>
>> X.3 Modality indications.
>> ----------------------------
>> It shall be possible to use indications for speech and hearing in audio
>> media.
>>
>> It shall be possible to use indications for transmitting text and
>> receiving text in real-time text media.
>>
>> ( ???  It shall be possible to use indications for transmitting text
>> messages and receiving text messages in text messaging media. ???)
>>
>> It shall be possible to use indications for expressing sign language and
>> perceiving sign language in video media.
>>
>> It shall be possible to use indications for showing a speaker and for
>> seeing a speaker in video media.
>>
>> X.4 Service indications.
>> --------------------------
>> It shall be possible to use indications of type of and address of and
>> state of invocation of an assisting service available for supporting the
>> communication.
>>
>> X.5 Language indications.
>> -----------------------------
>> It shall be possible to indicate ability to express language in a number
>> of languages from the ones listed in the language tags of RFC 5646.
>>
>> It shall be possible to indicate ability to perceive language in a numbe=
r
>> of languages from the ones listed in the language tags of RFC 5646.
>>
>> The language indication shall be associated with a specific media,
>> modality and direction.
>>
>> It shall be possible to indicate ability to express language in an
>> unspecified language, meaning a default for a region in the associated
>> modality.
>>
>> It shall be possible to indicate ability to perceive language in an
>> unspecified language, meaning a default for a region in the associated
>> modality.
>>
>> It shall be possible to indicate use of media without any specific
>> intention to use the medium for language communication.
>>
>> X.6 Indication of level of preference or capability
>> --------------------------------------------------------
>> It shall be possible to indicate an absolute level of preference or
>> capability to use a language, modality, media and direction combination
>> with a coarse grading.
>> For preference, the grading shall at least be able to indicate strong
>> preference vs can use vs possible fall back usage.
>> For capability, the grading shall at least be able to indicate good
>> capability vs some capability vs limited capability.
>> Capability and preference shall use the same coding, the difference is
>> only in the role of the entity providing the indication. Call parties
>> express preferences, service providers express capabilities.
>>
>> More than one direction/media/modality/language preference or capability
>> can be expressed per level.
>>
>> It shall be possible for a caller to express if the session should be se=
t
>> up or not if no matching direction/media/modality/language indications a=
re
>> found.
>>
>> X.7 Type and quality indications
>> -------------------------------------
>> It shall be possible to indicate preference and capability of different
>> types of real-time text production: conversational type versus captionin=
g
>> type. Conversational type is generated by the transmitting party in the
>> session, or by a communications agent with moderate requirements on dela=
y.
>> Captioning type is generated as captions to another modality in the same
>> session with low delay from the expression in the other modality. The
>> original modality for captions can be speech or sign language.
>>
>> It shall be possible to indicate with language indications if it is
>> original or interpreted or artificially created contents.
>>
>> In order to enable communication with persons who have speech that is
>> weak or hard to understand, the following quality indications can be use=
d:
>>     -It shall be possible to indicate that the quality of the expressed
>> speech makes it hard to understand.
>>     -It shall be possible to indicate a capability to undertand speech
>> that is weak or hard to understand.
>>
>> In order to enable communication with persons who need cognitive support
>> in the form of reminders or notetaking, the following quality indication=
s
>> can be used:
>>     -It shall be possible to indicate need of reminders or notetaking
>> during a session.
>>     -It shall be possible to indicate a capability to provide reminders
>> or take notes during a session.
>>
>>
>> X.8 Details of service indications
>> ----------------------------------------
>> The user expressing the indications may be a frequent user of an
>> assisting service, that supports the commuication in some often occurrin=
g
>> need for modality or language translation. By indicating this service, a
>> receiver of the indication can judge if invocation of that service will
>> support matching of preferences and capabilities. Common assiting servic=
e
>> types are relay service and language translation service.
>>
>> The services are specified with service type, service address, invocatio=
n
>> state and languages.
>> Possible service types are:
>>     Spoken language translation service translating between different
>> spoken languages.
>>     Video relay service translating between sign language in video and
>> speech in audio.
>>     Text relay service translating between text in real-time text and
>> speech in audio.  ( even between text messages and audio exist )
>>     Captioned telephony adding real-time text in one direction to speech=
.
>>     Speech-to-speech adding clear speech when needed to speech that is
>> weak or hard to understand
>>     Cognitive support adding reminders or memory notes to speech
>> conversation ususlly in combination with the speech-to-speech service.
>>
>> Service address shall be a URI where the service can be reached with one
>> session for provision of the service within the media of that session.
>> (note that this is different from how most current relay services today
>> work. They often have two call legs, one with an audio call and one with=
 a
>> multimedia call. )
>>
>> Invocation state shall indicate if the service is already included in th=
e
>> call, and if so, the media/modality/language indications show the joint
>> capabilities.
>> Invocation state can also contain a request to the other party to invoke
>> the service if needed to complement the capabilities to achieve a
>> functioning communication. This indication can be provided either by the
>> offering or answering party.
>>
>> Languages shall be media/modality/language indications in pairs showing
>> the capabilities of the service.
>>
>>
>> X.9 Use in session establishment and modification
>> -------------------------------------------------------------
>> The indications shall be included in session offer / answer exchange.
>>
>> Already specified ways to express media/modality/language shall be
>> possible to use to the extent that they are usable.
>> That includes media and language tags on SIP level and media
>> specifications and language tags on SDP level. For cases when these
>> existing means imply limitations, these limitations shall be explained.
>>
>> The method for identification of language preferences and capabilities i=
n
>> this specification is intended mainly for rapid ad-hoc session
>> establishment and not intended to have the same ambitions as CLUE has fo=
r
>> planned telepresence sessions.
>>
>> The indications included in the offer shall represent the preferences an=
d
>> capabilities of the offering party.
>>
>> The indications included in the answer shall represent the preferences
>> and capabilities of the answering party actually planned to be used in t=
he
>> session.
>>
>>
>>
>> X.10 Security
>> -----------
>> It shall be possible to hide the preference and capability indications
>> from unintended inspection.
>>
>> X.11 Not covered characteristics
>> ------------------------------------
>> Many aspects of a conversation are not covered by the indications
>> specified here.
>> Examples are:
>>     Gender
>>     Expertize area
>>
>> --------------------------------------
>>
>> /Gunnar
>>
>>
>> Den 2015-07-22 kl. 10:24, skrev Henning Schulzrinne:
>>
>> We talked about some examples of cases as being "center" and "corner":
>>
>>  (1) "center": customer trying to indicate that they prefer to speak
>> Spanish when contacting call center;
>> caller indicating preference for ASL when calling an emergency number
>>
>>  (2) "corner": simultaneous interpretation case where somebody wants to
>> receive both Spanish and English; complex ordering of preferences ("I am=
 a
>> native speaker of English; fluent in Spanish and can read a menu in
>> Swedish"; "I can understand (orally) Latin, but not speak it"; "I rate m=
y
>> preference for English, Spanish and Swedish as 9, 7 and 3.5")
>>
>>  There's obviously no problem if the corner case happens to work, but no
>> extra effort (syntax, complexity) will be expended to make them work. Th=
e
>> center-corner cut-off may also differ for routing and intra-UAS (SDP) ca=
ses
>> since it seems reasonable to assume that routing is more coarse-grained =
and
>> has less information about the current (right now), precise capabilities=
 of
>> the end point.
>>
>>  Henning
>>
>> On Wed, Jul 22, 2015 at 4:03 AM, Paul Kyzivat 
>> wrote:
>>
>>> On 7/22/15 3:46 AM, Brian Rosen wrote:
>>>
>>>  We will explicitly limit to the 80% cases, and we will document use
>>>> cases in a work group wiki.  We=E2=80=99re not going to try to cover c=
orner cases.
>>>>
>>>
>>> What does that mean? What is and isn't a corner case?
>>>
>>>         Thanks,
>>>         Paul
>>>
>>> _______________________________________________
>>> SLIM mailing list
>>> SLIM@ietf.org
>>> https://www.ietf.org/mailman/listinfo/slim
>>>
>>
>>
>>
>> _______________________________________________
>> SLIM mailing listSLIM@ietf.orghttps://www.ietf.org/mailman/listinfo/slim
>>
>>
>>  --
>> -----------------------------------------
>> Gunnar Hellstr=C3=B6m
>> Omnitorgunnar.hellstrom@omnitor.se
>> +46 708 204 288
>>
>>  _______________________________________________
>> SLIM mailing list
>> SLIM@ietf.org
>> https://www.ietf.org/mailman/listinfo/slim
>>
>>
>>
>> _______________________________________________
>> SLIM mailing list
>> SLIM@ietf.org
>> https://www.ietf.org/mailman/listinfo/slim
>>
>>
>
> --
> -----------------------------------------
> Gunnar Hellstr=C3=B6m
> Omnitorgunnar.hellstrom@omnitor.se
> +46 708 204 288
>
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim
>
>

--001a113ecbbaa70148051b7c94f6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


The problem is not a list of requirements, it's the ov=
erall model. Your model, if I understand this correctly, is that the signal=
ing (in SDP, but the same would apply in SIP) explicitly provides a list of=
 options for the receiver to choose from, with preferences. However, that&#=
39;s not how real systems work - they are not Turing machines where you fee=
d them inputs and they produce predictable outputs, across a nearly infinit=
e set of behaviors. (They do, at the low level of SIP exchanges and some SD=
P matching, but those behaviors are tightly constrained by the state machin=
e and "dumb". Even those cause a fair amount of interoperability =
problems if implementations start exploring the corners of legal, but uncom=
mon, behavior.)

Generally, these systems have a very sma=
ll set of operations ("invoke LanguageLine", "bridge supervi=
sor") that are invoked based on some small number of triggers. These b=
ehaviors differs based on which system you are reaching - an ACD for a bank=
 will have a different set than a PSAP, even though they are roughly simila=
r (in the voice world, both are often based on the same commercial ACD impl=
ementations), and a dial-in conferencing system will have a rather differen=
t set.

Assume a PSAP expects three kinds of caller=
s:
(1) voice callers, possibly with different spoken languages

(2) ASL-only caller (where the behavior depends on w=
hether the PSAP has an ASL call taker and the country/region-specific handl=
ing of relay)

(3) ASL+text caller, where local pol=
icy allows text-only

The PSAP just needs to know w=
hich of these cases it is dealing with, and it will invoke a standard opera=
ting procedure for one of these. Any other combinations will simply be &quo=
t;converted" into the least common denominator (For example, ASL + Rus=
sian text may not be handled at all since it is so uncommon, likely being t=
reated as "ASL-only" or the language being ignored. It won't =
magically invoke a text translator unless it has one for other purposes.)

Within these categories, there might be variations.=
 For example, (1) may allow for multimedia, adding either text and/or video=
 in addition to audio, but that's low-level behavior in the UAs and sta=
ndard SDP behavior that we don't need to modify.

Complexity starts to creep when you are trying to do one of the followin=
g:

(1) Have cross-media dependencies ("only d=
o X for media M1 if Y for media M2")

(2) Pref=
erence orderings that are more than just plain "I like A best and then=
 B, C or D" (e.g., complex preferences like "I like A and B equal=
ly, and then like C and D a little less, but barely put up with E")

(3) Telling the receiver of the call precisely what =
to do ("I want human translation", "I want the PSAP, not the=
 relay service, to invoke relay", "I don't want to talk to yo=
u unless you can do at least 93.5% of what I asked for")

Thus, I'd start the other way: For SDP, the =
draft, if I understand this correctly, proposes starting with a simple lang=
uage description for each media (separate for each direction).=C2=A0
<=
div>
I will likely propose something simple like the followin=
g for SIP call routing:

Call-Routing: text=3Den; v=
ideo=3Dase

or

Call-Routin=
g: en,fr (if the caller has a single set of language across all language-de=
pendent media; this example might be for a Canadian living in Toronto)

[I may re-use a subset of caller preferences if that&#=
39;s easy, so ignore the strawman syntax.]

If we s=
tart there, are there practical use cases where a receiving PSAP or call ce=
nter wouldn't know what to do and which kind of actually-existing human=
 they are communicating with (and thus invoke the appropriate functionality=
)? If so, we should identify these cases and see whether they can be addres=
sed by minor extensions of the idea or fall in the "let's see if w=
e can solve this some other way" category.

He=
nning

=
On Wed, Jul 22, 2015 at 3:46 PM, Gunnar Hellstr=C3=B6m &l=
t;gunnar.h=
ellstrom@omnitor.se> wrote:

 =20
   =20
 =20
  

    If the requirements I proposed were too complex, can we then get
    proposals for what to delete from them.

    

    Compared to the current real-time SLIM draft, I can see the
    following differences:

    

    X.4 Service indications is added. I did that because of two issues:
    1. the problem of describing a couple of types of relay service
    users in language and modality preference terms, and therefore
    instead providing the opportunity to tell what kind of relay service
    the user is a regular user of. 2. The problem in a multi-national,
    multi-language situation for an answering part to know how to find a
    suitable assisting service to invoke, and therefore introducing a
    service hint in the coding. 

    

    X.6 Priority. I suggest another priority indication than the current
    draft. The current draft has just priority within each medium, while
    I see a need for priority levels between media. Instead I suggest
    only three priority levels instead of the draft now specifying an
    unlimited positional order of priority within each medium.=C2=A0 

    

    X.7 The type and quality indications were added, inspired by the
    discussion mainly from the e-mail draft discussion.

    

    X.8 is details of the service indications, briefly introduced in
    X.4.

    

    The requirements aim at allowing quite general terminals, e.g. using
    IMS, call services that may be located in other countries having no
    previous business agreement, such as an IMS user from one country
    visiting another country and calling emergency services there.

    

    Is that to hope too much? Do you suggest that persons with specific
    other modality needs than two-way speech will always need to be
    registered with service providers who are devoted to their needs?

    

    Or can you propose a subset of the requirements that correspond to
    the central cases?

    

    Gunnar

    

    
Den 2015-07-22 kl. 11:32, skrev Henning
      Schulzrinne:

    

    

      
I agree; I think this is too prescriptive. The goal
        is much simpler: Allow the caller to provide enough information
        so that proxy/UA/SBC/PSAP etc. can make good decisions on what
        to do. Generally, attempts to tell these entities *how* to do
        things or exactly what to do is both likely to be ignored and
        generate unbounded complexity. We went a small distance down
        that path before, in caller preferences, and the result was not
        pretty. That effort actually tried to come up with a formal
        logic, rather than a compilation of ad-hoc cases, but even that
        led to too many cases to make them practical to implement. Been
        there, done that, have the T-shirt.
        


        

        
We generally don't need to do this - we don't have gen=
eric
          components in most of the cases of the interest (PSAP, call
          center, conferencing systems, etc.), but components that, by
          their nature, have a fair amount of domain-specific knowledge,
          such as policies about how to handle ASL calls, when and how
          to bridge in interpreters, who gets what kind of language
          assistance, etc. =C2=A0(To be sure, the physical components such =
as
          SIP proxies may be generic, but they have been programmed to
          operate in a specific policy environment, i.e., they turn into
          an ESRP or PBX/ACD.)

        


        

        
These entities essentially need to know "which of my
          well-known customer/caller classes is this" and then trigger
          one of a very small number of behaviors that are programmed
          ahead of time. This is, among other reasons, the only way that
          you can test systems. And all of our target systems are
          high-reliability, can't-fail systems, even if they are not
          life-safety systems.

        


        

        
Also, in many cases, they may define profiles for users
          out-of-band. For example, they are likely to define special
          roles for call takers, language interpreters, managers (who
          need to monitor calls for quality assurance), loggers, etc.
          These roles trigger behavior, not the signaling or SDP.

        


        

        
We are not specifying a programming language here.

        


        

        
Henning

      

      


        
On Wed, Jul 22, 2015 at 4:59 AM, Brian
          Rosen <br@brianrosen.net>
          wrote:

          

            
I=E2=80=99m not in favor of=
 this.
              


              

              
I think it=E2=80=99s too complex; way, way too complex.<=
/div>
              


              

              
Brian

              


              

              


                

                  

                    
On Jul 22, 2015, at 10:52 AM, Gunnar Hellstr=C3=B6=
m
                      <gunnar.hellstrom@omnitor.se>
                      wrote:

                    

                    

                      
 Can we
                        agree to include this proposed requirements
                        chapter and from this proposal identify what
                        should be added or deleted to get the center
                        cases included and the corner cases either
                        excluded or just enabled by chance? ( a few
                        excluded corner cases are listed in the last
                        subsection.)

                        I have not changed the chapter after the
                        discussion about coordination of languages and
                        modalities in different streams that Paul
                        introduced. I am not sure about if that
                        discussion belongs here or not. 

                        

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

                        

                        X. Requirements. 

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

                        The system for indication of preferences and
                        capabilities shall meet the following
                        requirements: 

                        

                        It shall enable negotiation of media, modalities
                        and languages for a SIP session. 

                        

                        It shall be possible to use it during initiation
                        and modification of a session. 

                        

                        The system shall consist of a set of indications
                        and usage rules specified in this specification
                        and other specifications. 

                        

                        The system shall enable a caller to indicate the
                        media, modalities, languages and assisting
                        services that the caller prefers to use during a
                        real-time session that is about to be
                        established or modified. 

                        

                        Entities involved in selecting callees and
                        callees shall be enabled to view the caller
                        preferences in order to select a callee of many,
                        or adjust the set of media, modalities,
                        languages and services provided in the session.
                        

                        

                        The caller shall be provided with indication of
                        the resulting media, modalities, languages and
                        services enabled during the session. 

                        

                        X.1 General 

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

                        It shall be possible to express capabilities and
                        preferences with its transmission direction, for
                        transmission or reception or bidirectional from
                        the viewpoint of the entity sending the
                        indication. 

                        

                        The indications shall be suitable for setting in
                        personal profiles, in service profiles, or in
                        terminal settings, and possible to adjust at
                        session initiation time. 

                        

                        It shall be possible to present the outcome of
                        exchange of the indications to users in the
                        session. 

                        

                        X.2 Media indications. 

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

                        

                        It shall be possible to use the indications for
                        audio, video and real-time text media.=C2=A0 ( and
                        text messages????) 

                        

                        X.3 Modality indications. 

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

                        It shall be possible to use indications for
                        speech and hearing in audio media. 

                        

                        It shall be possible to use indications for
                        transmitting text and receiving text in
                        real-time text media. 

                        

                        ( ???=C2=A0 It shall be possible to use indications
                        for transmitting text messages and receiving
                        text messages in text messaging media. ???) 

                        

                        It shall be possible to use indications for
                        expressing sign language and perceiving sign
                        language in video media. 

                        

                        It shall be possible to use indications for
                        showing a speaker and for seeing a speaker in
                        video media. 

                        

                        X.4 Service indications. 

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

                        It shall be possible to use indications of type
                        of and address of and state of invocation of an
                        assisting service available for supporting the
                        communication. 

                        

                        X.5 Language indications. 

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

                        It shall be possible to indicate ability to
                        express language in a number of languages from
                        the ones listed in the language tags of RFC
                        5646. 

                        

                        It shall be possible to indicate ability to
                        perceive language in a number of languages from
                        the ones listed in the language tags of RFC
                        5646. 

                        

                        The language indication shall be associated with
                        a specific media, modality and direction. 

                        

                        It shall be possible to indicate ability to
                        express language in an unspecified language,
                        meaning a default for a region in the associated
                        modality. 

                        

                        It shall be possible to indicate ability to
                        perceive language in an unspecified language,
                        meaning a default for a region in the associated
                        modality. 

                        

                        It shall be possible to indicate use of media
                        without any specific intention to use the medium
                        for language communication. 

                        

                        X.6 Indication of level of preference or
                        capability 

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

                        

                        It shall be possible to indicate an absolute
                        level of preference or capability to use a
                        language, modality, media and direction
                        combination with a coarse grading. 

                        For preference, the grading shall at least be
                        able to indicate strong preference vs can use vs
                        possible fall back usage. 

                        For capability, the grading shall at least be
                        able to indicate good capability vs some
                        capability vs limited capability. 

                        Capability and preference shall use the same
                        coding, the difference is only in the role of
                        the entity providing the indication. Call
                        parties express preferences, service providers
                        express capabilities. 

                        

                        More than one direction/media/modality/language
                        preference or capability can be expressed per
                        level. 

                        

                        It shall be possible for a caller to express if
                        the session should be set up or not if no
                        matching direction/media/modality/language
                        indications are found. 

                        

                        X.7 Type and quality indications 

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

                        It shall be possible to indicate preference and
                        capability of different types of real-time text
                        production: conversational type versus
                        captioning type. Conversational type is
                        generated by the transmitting party in the
                        session, or by a communications agent with
                        moderate requirements on delay. Captioning type
                        is generated as captions to another modality in
                        the same session with low delay from the
                        expression in the other modality. The original
                        modality for captions can be speech or sign
                        language. 

                        

                        It shall be possible to indicate with language
                        indications if it is original or interpreted or
                        artificially created contents. 

                        

                        In order to enable communication with persons
                        who have speech that is weak or hard to
                        understand, the following quality indications
                        can be used: 

                        =C2=A0=C2=A0=C2=A0 -It shall be possible to indicat=
e that the
                        quality of the expressed speech makes it hard to
                        understand. 

                        =C2=A0=C2=A0=C2=A0 -It shall be possible to indicat=
e a
                        capability to undertand speech that is weak or
                        hard to understand. 

                        

                        In order to enable communication with persons
                        who need cognitive support in the form of
                        reminders or notetaking, the following quality
                        indications can be used: 

                        =C2=A0=C2=A0=C2=A0 -It shall be possible to indicat=
e need of
                        reminders or notetaking during a session. 

                        =C2=A0=C2=A0=C2=A0 -It shall be possible to indicat=
e a
                        capability to provide reminders or take notes
                        during a session. 

                        

                        

                        X.8 Details of service indications 

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

                        The user expressing the indications may be a
                        frequent user of an assisting service, that
                        supports the commuication in some often
                        occurring need for modality or language
                        translation. By indicating this service, a
                        receiver of the indication can judge if
                        invocation of that service will support matching
                        of preferences and capabilities. Common assiting
                        service types are relay service and language
                        translation service. 

                        

                        The services are specified with service type,
                        service address, invocation state and languages.
                        

                        Possible service types are: 

                        =C2=A0=C2=A0=C2=A0 Spoken language translation serv=
ice
                        translating between different spoken languages.
                        

                        =C2=A0=C2=A0=C2=A0 Video relay service translating =
between sign
                        language in video and speech in audio. 

                        =C2=A0=C2=A0=C2=A0 Text relay service translating b=
etween text
                        in real-time text and speech in audio.=C2=A0 ( even
                        between text messages and audio exist ) 

                        =C2=A0=C2=A0=C2=A0 Captioned telephony adding real-=
time text in
                        one direction to speech. 

                        =C2=A0=C2=A0=C2=A0 Speech-to-speech adding clear sp=
eech when
                        needed to speech that is weak or hard to
                        understand 

                        =C2=A0=C2=A0=C2=A0 Cognitive support adding reminde=
rs or memory
                        notes to speech conversation ususlly in
                        combination with the speech-to-speech service. 

                        

                        Service address shall be a URI where the service
                        can be reached with one session for provision of
                        the service within the media of that session. 

                        (note that this is different from how most
                        current relay services today work. They often
                        have two call legs, one with an audio call and
                        one with a multimedia call. ) 

                        

                        Invocation state shall indicate if the service
                        is already included in the call, and if so, the
                        media/modality/language indications show the
                        joint capabilities. 

                        Invocation state can also contain a request to
                        the other party to invoke the service if needed
                        to complement the capabilities to achieve a
                        functioning communication. This indication can
                        be provided either by the offering or answering
                        party. 

                        

                        Languages shall be media/modality/language
                        indications in pairs showing the capabilities of
                        the service. 

                        

                        

                        X.9 Use in session establishment and
                        modification 

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

                        

                        The indications shall be included in session
                        offer / answer exchange. 

                        

                        Already specified ways to express
                        media/modality/language shall be possible to use
                        to the extent that they are usable. 

                        That includes media and language tags on SIP
                        level and media specifications and language tags
                        on SDP level. For cases when these existing
                        means imply limitations, these limitations shall
                        be explained. 

                        

                        The method for identification of language
                        preferences and capabilities in this
                        specification is intended mainly for rapid
                        ad-hoc session establishment and not intended to
                        have the same ambitions as CLUE has for planned
                        telepresence sessions. 

                        

                        The indications included in the offer shall
                        represent the preferences and capabilities of
                        the offering party. 

                        

                        The indications included in the answer shall
                        represent the preferences and capabilities of
                        the answering party actually planned to be used
                        in the session. 

                        

                        

                        

                        X.10 Security 

                        ----------- 

                        It shall be possible to hide the preference and
                        capability indications from unintended
                        inspection. 

                        

                        X.11 Not covered characteristics 

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

                        Many aspects of a conversation are not covered
                        by the indications specified here. 

                        Examples are: 

                        =C2=A0=C2=A0=C2=A0 Gender 

                        =C2=A0=C2=A0=C2=A0 Expertize area 

                        

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

                        

                        /Gunnar

                        

                        

                        
Den 2015-07-22 kl. 10:24, skrev Henning
                          Schulzrinne:

                        

                        

                          
We talked about some examples
                            of cases as being "center" and "=
corner":
                            


                            

                            
(1) "center": customer trying to
                              indicate that they prefer to speak Spanish
                              when contacting call center;

                            
caller indicating preference for ASL
                              when calling an emergency number

                            


                            

                            
(2) "corner": simultaneous
                              interpretation case where somebody wants
                              to receive both Spanish and English;
                              complex ordering of preferences ("I am a
                              native speaker of English; fluent in
                              Spanish and can read a menu in Swedish";
                              "I can understand (orally) Latin, but no=
t
                              speak it"; "I rate my preference fo=
r
                              English, Spanish and Swedish as 9, 7 and
                              3.5")

                            


                            

                            
There's obviously no problem if the
                              corner case happens to work, but no extra
                              effort (syntax, complexity) will be
                              expended to make them work. The
                              center-corner cut-off may also differ for
                              routing and intra-UAS (SDP) cases since it
                              seems reasonable to assume that routing is
                              more coarse-grained and has less
                              information about the current (right now),
                              precise capabilities of the end point.

                            


                            

                            
Henning

                          

                          


                            
On Wed, Jul 22,
                              2015 at 4:03 AM, Paul Kyzivat <pkyzivat@=
alum.mit.edu>
                              wrote:

                              
On 7/22/15
                                3:46 AM, Brian Rosen wrote:

                                

                                
 We will
                                  explicitly limit to the 80% cases, and
                                  we will document use cases in a work
                                  group wiki.=C2=A0 We=E2=80=99re not going=
 to try to
                                  cover corner cases.

                                

                                

                                What does that mean? What is and isn't =
a
                                corner case?

                                

                                =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,

                                =C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

                                

_______________________________________________

                                SLIM mailing list

                                SLIM@ietf.org

                                https://www.ietf.org/mailm=
an/listinfo/slim

                              

                            

                            

                          

                          

                          

                          

                          
____________________________________________=
___
SLIM mailing list
SLIM@ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/slim


                        

                        

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

                          

                      
_______________________________________________

                          SLIM mailing list

                          SLIM@ietf.org

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

                        

                  

                

                

              

            

            

            _______________________________________________

            SLIM mailing list

            SLIM@ietf.or=
g

            https://www.ietf.org/mailman/listinfo/slim=


            

          

        

        

      

    

    

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

  



_______________________________________________

SLIM mailing list

SLIM@ietf.org

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





--001a113ecbbaa70148051b7c94f6--


From nobody Wed Jul 22 13:34:10 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136A91B2BDB for ; Wed, 22 Jul 2015 13:34:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.521
X-Spam-Level: 
X-Spam-Status: No, score=-1.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=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 04Qqn9ELfEvS for ; Wed, 22 Jul 2015 13:34:06 -0700 (PDT)
Received: from mail-qk0-f174.google.com (mail-qk0-f174.google.com [209.85.220.174]) (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 72AF51B2C8F for ; Wed, 22 Jul 2015 13:33:58 -0700 (PDT)
Received: by qkdv3 with SMTP id v3so161164289qkd.3 for ; Wed, 22 Jul 2015 13:33:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=LBActdDl5h+gJg8R/q6gMyIIqpq8qNvhexAcF+Kjx3Y=; b=kSCK8wfjX7zj0E08mh9r9/lciUxbh25g8yBbWK4CVVf2riHC1fVurXbAUw9unGdqbg j2z3qXcdqsX7ckxi8RN/WHypNjHgBgxhccMHiC4ms5RtAxYqgfRo3wEcuZBiZRmWvU3l vwoJ5HLM7YTCeaEmJZ7z2E6eRNI2I+DZ8fciy7aFPaE4qpUQ6j89h2oq020xMUr1K/nI k2O+UBkUM+vrHwD7jCVJNmyaxGDlbpjWSHkyjcelT5FZ3LRFX63qztxW1sJqxaE2ryQj 9wGFBDUKyTtk+tDqYPJSun1duSjh6nFR21X3tp8tbM4KMAu3JjAelsBs07jgNUt/aDu3 mt0w==
X-Gm-Message-State: ALoCoQlArgHejwvih0GB7r8EbkY7I6El7Xpk+SM0AaNNXH+PgTD8MA3+9COP4oFP3ZJNjVFhHbrL
X-Received: by 10.140.82.18 with SMTP id g18mr6613998qgd.41.1437597237676; Wed, 22 Jul 2015 13:33:57 -0700 (PDT)
Received: from mrichards3-ltw7.cis.neustar.com (neustargw.va.neustar.com. [209.173.53.233]) by smtp.gmail.com with ESMTPSA id j102sm1276365qkh.46.2015.07.22.13.33.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Jul 2015 13:33:57 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: Brian Rosen 
In-Reply-To: <55AFF322.4040006@omnitor.se>
Date: Wed, 22 Jul 2015 22:33:39 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <4883075B-A9D2-4808-8E85-18DE06A13921@brianrosen.net>
References: <9874942B-DB5E-4092-8C2B-7E159437B491@standardstrack.com> <43B9F9AD-52C2-451A-9A50-B206FFAE3568@brianrosen.net> <55AF4E6A.3060401@alum.mit.edu>  <55AF59C7.605@omnitor.se>   <55AFF322.4040006@omnitor.se>
To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= 
X-Mailer: Apple Mail (2.2102)
Archived-At: 
Cc: slim@ietf.org, Henning Schulzrinne 
Subject: Re: [Slim] Notes from lunch? + Requirements
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jul 2015 20:34:08 -0000

First of all, I don=E2=80=99t think we need requirements for our =
original task.

We agreed we would develop use cases, which we would document in the =
work group wiki to guide our work.

Inline for some comments, but I don=E2=80=99t think we=E2=80=99re =
negotiating requirements.

> On Jul 22, 2015, at 9:46 PM, Gunnar Hellstr=C3=B6m =
 wrote:
>=20
> If the requirements I proposed were too complex, can we then get =
proposals for what to delete from them.
>=20
> Compared to the current real-time SLIM draft, I can see the following =
differences:
>=20
> X.4 Service indications is added. I did that because of two issues: 1. =
the problem of describing a couple of types of relay service users in =
language and modality preference terms, and therefore instead providing =
the opportunity to tell what kind of relay service the user is a regular =
user of. 2. The problem in a multi-national, multi-language situation =
for an answering part to know how to find a suitable assisting service =
to invoke, and therefore introducing a service hint in the coding.=20
I don=E2=80=99t think we need complex relay service indications.  I =
think just specifying the languages desired for each modality, in order, =
is sufficient.  If you say =E2=80=9CASL video=E2=80=9D, english audio =
and french text, you are weird, but we know how to handle you.  I think =
we will have to augment the IANA registry of language tags to add the =
other assistive modalities needed, just as we have =E2=80=9CASL=E2=80=9D. =
 I think you =E2=80=9Crequest" captioned english, just like you request =
american sign language , but with a different tag, and on a different =
media stream. =20

>=20
> X.6 Priority. I suggest another priority indication than the current =
draft. The current draft has just priority within each medium, while I =
see a need for priority levels between media. Instead I suggest     only =
three priority levels instead of the draft now specifying an unlimited =
positional order of priority within each medium. =20
I don=E2=80=99t see a need to have priority between media. I think those =
are corner cases.  i think the current proposal of an ordered list is =
simple, and unambiguous.

>=20
> X.7 The type and quality indications were added, inspired by the =
discussion mainly from the e-mail draft discussion.
I probably wasn=E2=80=99t paying attention to those threads, so I =
can=E2=80=99t comment
>=20
> X.8 is details of the service indications, briefly introduced in X.4.
>=20
> The requirements aim at allowing quite general terminals, e.g. using =
IMS, call services that may be located in other countries having no =
previous business agreement, such as an IMS user from one country =
visiting another country and calling emergency services there.
I think routing will have to handle roaming scenarios. I=E2=80=99m =
willing to discuss how we do that.  I=E2=80=99m not at all ready to =
decide on mechanisms yet.

>=20
> Is that to hope too much? Do you suggest that persons with specific =
other modality needs than two-way speech will always need to be =
registered with service providers who are devoted to their needs?
No.  First of all, this is a routing issue, and thus is not in scope for =
the first document set.  I think we have to handle cases where the =
origination end chooses =E2=80=9Ctranscoding=E2=80=9D services and when =
the termination end chooses them.  The SDP offer/answer should work =
after the routing is completed sucessfully.

Brian


From nobody Wed Jul 22 14:30:30 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CDB1B2E9E for ; Wed, 22 Jul 2015 14:30:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level: 
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 NtKjoS0c3_nn for ; Wed, 22 Jul 2015 14:30:27 -0700 (PDT)
Received: from bin-vsp-out-01.atm.binero.net (vsp-authed01.binero.net [195.74.38.224]) (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 BD6B61B2B91 for ; Wed, 22 Jul 2015 14:30:26 -0700 (PDT)
X-Halon-ID: eed192a0-30b8-11e5-8489-005056917a89
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.43.70] (unknown [2.67.176.197]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Wed, 22 Jul 2015 23:30:53 +0200 (CEST)
To: Brian Rosen 
References: <9874942B-DB5E-4092-8C2B-7E159437B491@standardstrack.com> <43B9F9AD-52C2-451A-9A50-B206FFAE3568@brianrosen.net> <55AF4E6A.3060401@alum.mit.edu>  <55AF59C7.605@omnitor.se>   <55AFF322.4040006@omnitor.se> <4883075B-A9D2-4808-8E85-18DE06A13921@brianrosen.net>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <55B00B6B.6000004@omnitor.se>
Date: Wed, 22 Jul 2015 23:30:19 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <4883075B-A9D2-4808-8E85-18DE06A13921@brianrosen.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: slim@ietf.org, Henning Schulzrinne 
Subject: Re: [Slim] Notes from lunch? + Requirements
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jul 2015 21:30:29 -0000

Den 2015-07-22 kl. 22:33, skrev Brian Rosen:
> First of all, I don’t think we need requirements for our original task.
I think we do. I noticed that our target drifted during the discussions, 
and the use cases were too few and coarse to really indicate what we 
needed.

I see that you propose that we could propose new subtags or other coding 
options to be added to the language tag registry. I think that can be a 
fruitful way to solve some of the needs, so let us keep that in mind.

/Gunnar
>
> We agreed we would develop use cases, which we would document in the work group wiki to guide our work.
>
> Inline for some comments, but I don’t think we’re negotiating requirements.
>
>> On Jul 22, 2015, at 9:46 PM, Gunnar Hellström  wrote:
>>
>> If the requirements I proposed were too complex, can we then get proposals for what to delete from them.
>>
>> Compared to the current real-time SLIM draft, I can see the following differences:
>>
>> X.4 Service indications is added. I did that because of two issues: 1. the problem of describing a couple of types of relay service users in language and modality preference terms, and therefore instead providing the opportunity to tell what kind of relay service the user is a regular user of. 2. The problem in a multi-national, multi-language situation for an answering part to know how to find a suitable assisting service to invoke, and therefore introducing a service hint in the coding.
> I don’t think we need complex relay service indications.  I think just specifying the languages desired for each modality, in order, is sufficient.  If you say “ASL video”, english audio and french text, you are weird, but we know how to handle you.  I think we will have to augment the IANA registry of language tags to add the other assistive modalities needed, just as we have “ASL”.  I think you “request" captioned english, just like you request american sign language , but with a different tag, and on a different media stream.
That would be to fulfill the requirements for type of service in the 
text media stream. So your example indicate that parts of the 
requirements chapter are suitable.


>   
>
>> X.6 Priority. I suggest another priority indication than the current draft. The current draft has just priority within each medium, while I see a need for priority levels between media. Instead I suggest     only three priority levels instead of the draft now specifying an unlimited positional order of priority within each medium.
> I don’t see a need to have priority between media. I think those are corner cases.  i think the current proposal of an ordered list is simple, and unambiguous.
Right. I tried to express a first preference and a second. Then it is 
essential to be able to indicate either priority on 2-3 explicit levels, 
or a priority relation between media. That would enable coding for: I 
prefer to use ASL but can accept to use English real-time text. If we 
drop this possibility to have indications of acceptable fall back 
situations, we can probably simplify the requirements a bit.

>
>> X.7 The type and quality indications were added, inspired by the discussion mainly from the e-mail draft discussion.
> I probably wasn’t paying attention to those threads, so I can’t comment
You proposed type=captioned English above.
And I picked up the discussion on indicating if a medium had original or 
human or automatic translation, and saw some use of it also for the 
real-time case. But that can be dropped as well.
>> X.8 is details of the service indications, briefly introduced in X.4.
>>
>> The requirements aim at allowing quite general terminals, e.g. using IMS, call services that may be located in other countries having no previous business agreement, such as an IMS user from one country visiting another country and calling emergency services there.
> I think routing will have to handle roaming scenarios. I’m willing to discuss how we do that.  I’m not at all ready to decide on mechanisms yet.
>
>> Is that to hope too much? Do you suggest that persons with specific other modality needs than two-way speech will always need to be registered with service providers who are devoted to their needs?
> No.  First of all, this is a routing issue, and thus is not in scope for the first document set.  I think we have to handle cases where the origination end chooses “transcoding” services and when the termination end chooses them.  The SDP offer/answer should work after the routing is completed sucessfully.
/Gunnar
>
> Brian
>

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


From nobody Wed Jul 22 15:01:16 2015
Return-Path: 
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58FE71B2D10 for ; Wed, 22 Jul 2015 15:01:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 31UcRqyNmO4p for ; Wed, 22 Jul 2015 15:01:08 -0700 (PDT)
Received: from p3plwbeout03-04.prod.phx3.secureserver.net (p3plsmtp03-04-2.prod.phx3.secureserver.net [72.167.218.216]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 975D71A1A9B for ; Wed, 22 Jul 2015 15:01:08 -0700 (PDT)
Received: from localhost ([72.167.218.244]) by p3plwbeout03-04.prod.phx3.secureserver.net with bizsmtp id va181q0025GyNsw01a18XW; Wed, 22 Jul 2015 15:01:08 -0700
X-SID: va181q0025GyNsw01
Received: (qmail 5209 invoked by uid 99); 22 Jul 2015 22:01:08 -0000
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Originating-IP: 208.51.143.189
User-Agent: Workspace Webmail 5.15.0
Message-Id: <20150722150106.665a7a7059d7ee80bb4d670165c8327d.886f20f161.wbe@email03.secureserver.net>
From: "Doug Ewell" 
To: "Brian Rosen" , "=?UTF-8?Q?Gunnar=5FHellstr=C3=B6m?=" 
Date: Wed, 22 Jul 2015 15:01:06 -0700
Mime-Version: 1.0
Archived-At: 
Cc: slim@ietf.org, Henning Schulzrinne 
Subject: Re: [Slim] =?utf-8?q?Notes_from_lunch=3F_+_Requirements?=
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Selection of Language for Internet Media 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jul 2015 22:01:14 -0000

Brian Rosen 
 wrote:=0A=0A> I think we will have t=
o augment the IANA registry of language tags to=0A> add the other assistive=
 modalities needed, just as we have =E2=80=9CASL=E2=80=9D.=0A=0AIs this a s=
uggestion to add variant subtags for modality to the Language=0ASubtag Regi=
stry, or to create a second, SLIM-specific registry for=0Amodality?=0A=0ARe=
member that ASL and the other 140-plus sign languages are in the LSR=0Abeca=
use linguists consider them to be true languages. This is not the=0Acase fo=
r things like "Signed Spoken English," which are not in the LSR.=0A=0ABCP 4=
7 doesn't include modality in its scope -- this was a conscious=0Adecision =
during the development of RFC 4646 and 5646 -- so a=0ASLIM-specific registr=
y of modalities seems appropriate.=0A=0A--=0ADoug Ewell | http://ewellic.or=
g | Thornton, CO =F0=9F=87=BA=F0=9F=87=B8=0A