From nobody Wed Mar 1 05:34:18 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A5F1295DD for ; Wed, 1 Mar 2017 05:34:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xOdQix99XRd for ; Wed, 1 Mar 2017 05:34:14 -0800 (PST) Received: from mail-qk0-x241.google.com (mail-qk0-x241.google.com [IPv6:2607:f8b0:400d:c09::241]) (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 76F33129577 for ; Wed, 1 Mar 2017 05:34:14 -0800 (PST) Received: by mail-qk0-x241.google.com with SMTP id u188so10563800qkc.3 for ; Wed, 01 Mar 2017 05:34:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=jpWfexxy/UXR5cbQnysxP8/3Fh0/G7ZDf97wBUhCAhw=; b=D+gHTaXNYF9T4gkEpAO2M/K7JWmmsgfFS6PvCggLJow4O0q4UqgjBsTBLPiV9qAZwp sB++VT6sg+di0Mwn1XXycoSyEx3p5MDB0tF+HhY4A02sztukR1PLUwyN5CTGKZyzae9/ UJr4b25t4jMkGGMpcLvmtTdkQRpIE7cUu1LuKE8Te+ploOZ8BclW6slSD7tTl9dm2fh+ 3YDcthotW+r7Zu99hBnKW9I5jJdHT324XcuCPjtUYVikr6zpJBgPLJT8xYOgZEYaUrcw znQxDqDvhpqzvjOzu8Y80PqLnuT+Ngiqx3ltcE1viAUdRwYmPJEVcqDDcgjxjAl1nFoB feRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=jpWfexxy/UXR5cbQnysxP8/3Fh0/G7ZDf97wBUhCAhw=; b=gfeWkrG19t0zM2DiRTLWwrWpcNZ0FSLhI2m+dVK5IklBsA+QQSaHMguT7BXyXE7fyt OocZS0gLA/fqHTgLbuZ1UV51HJR6i7oXLa91gdPY9Ug41rV3U2HVPvTuq22ZTkomZ/4R 7+wireDbhD6x1uCzaHPqV5FN/3S336Lj5sWEnFPt+W+x9waijMLcdaNXYcxq6Dh1+sQV n7Q6MWdWVpu0D9LF6jAIWh1G5N0lpkaYmPfKkc924vG5HbGMBGkQbSTNYmtKEsYSQn2s 75jfIZgF3QXsdP7cywUl89yCTJnxEINbEY8KlY3wnoobe0norI4O8q+YInA0jx1ZO0F/ Gonw== X-Gm-Message-State: AMke39nBk9v1i7stukMykymPozseFvfNShulJBcM+2vZFzd2qcElPC/3pdqCZ50OtvYqyw== X-Received: by 10.200.4.5 with SMTP id v5mr9416507qtg.54.1488375253431; Wed, 01 Mar 2017 05:34:13 -0800 (PST) Received: from [10.96.43.71] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id 19sm1024763qtv.9.2017.03.01.05.34.12 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 01 Mar 2017 05:34:12 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_DA4A8662-2C82-4E74-B004-017785D707F6" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: Date: Wed, 1 Mar 2017 08:34:11 -0500 Message-Id: <3710F834-0FB4-4D17-8E91-043624EF73E8@brianrosen.net> References: <148782279664.31054.8793649134696520241.idtracker@ietfa.amsl.com> <49fd730e-6e90-1a49-eae8-80f8b1285a76@omnitor.se> <83152ba7-c3fb-25d8-f97d-59c7840cad56@omnitor.se> <4b36f347-955e-e2b9-12f2-f426d47d3d33@omnitor.se> <7f844aaa-17ce-2ab7-0602-a999a40235de@omnitor.se> <825fa638-b223-d716-6a3c-238903a37b92@omnitor.se> To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= X-Mailer: Apple Mail (2.3124) Archived-At: Cc: slim@ietf.org, "Phillips, Addison" , Randall Gellens , Natasha Rooney , Bernard Aboba Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-07.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 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, 01 Mar 2017 13:34:17 -0000 --Apple-Mail=_DA4A8662-2C82-4E74-B004-017785D707F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I haven=92t commented on this thread much, but I agree with Randall. I am opposed to a protocol document saying anything about human = interface. The answering device may be an automaton, and there could be = very good reasons to not tell the human which languages/media are not = the least preferred. =20 Designing good user interfaces is very hard, the participants on this = list are not experts, and we should not offer advice on human factors in = our documents. It is sufficient to transport the information across the = wire. Brian > On Mar 1, 2017, at 2:26 AM, Gunnar Hellstr=F6m = wrote: >=20 > Hi Randall,=20 > Den 2017-03-01 kl. 02:08, skrev Randall Gellens: >> Hi Gunnar,=20 >>=20 >> I'm starting a new message to cut out the huge amount of quoting.=20 >>=20 >> Your proposal is that text be added that advises the calling client = to place an asterisk on the least-preferred language/media, and advises = the answering client to indicate to the answering human which = language/media is not the least preferred (did not have an asterisk in = the offer), is that accurate?=20 > Yes, with slight rewording to: > "text that advises the offering client to place an asterisk on the = least-preferred language/media indications, and advises the answering = client to indicate to the answering human which language/media are not = the least preferred (did not have an asterisk in the offer)" >=20 > The inclusion of the "indications" is just to assure that it is clear = that it does not need to be just one indication that gets the asterisk . > The last part sounds awkward, but matches technically what the lack of = an asterisk means. I inherited the inverted logic for the asterisk from = its already defined non-denial meaning.=20 > If you are considering wording for the draft, I suggest that you = straighten the logic to say "which language/media are most preferred = (did not have an asterisk in the offer)" >=20 > It does also not need to be an "answering human" that gets this = indication and makes use of it for guidance on how to answer the call. = It can just as well be e.g. a multi-modal answering machine or some = other application interacting with human language. I am not sure if = "answering party" is more appropriate and can be considered including = such automata. =20 >=20 > Thanks, > Gunnar >=20 >=20 > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim --Apple-Mail=_DA4A8662-2C82-4E74-B004-017785D707F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I haven=92t commented on this thread much, but I agree with = Randall.

I am = opposed to a protocol document saying anything about human interface. =  The answering device may be an automaton, and there could be very = good reasons to not tell the human which languages/media are not the = least preferred.  

Designing good user interfaces is very hard, the participants = on this list are not experts, and we should not offer advice on human = factors in our documents.  It is sufficient to transport the = information across the wire.

Brian

On Mar 1, 2017, at 2:26 AM, Gunnar Hellstr=F6m = <gunnar.hellstrom@omnitor.se> wrote:

=20 =20
Hi Randall,
Den 2017-03-01 kl. 02:08, skrev = Randall Gellens:
Hi Gunnar,

I'm starting a new message to cut out the huge amount of quoting.

Your proposal is that text be added that advises the calling client to place an asterisk on the least-preferred language/media, and advises the answering client to indicate to the answering human which language/media is not the least preferred (did not have an asterisk in the offer), is that accurate?
Yes, with slight rewording to:
"text that advises the offering client to place an = asterisk on the least-preferred language/media indications, = and advises the answering client to indicate to the answering human which language/media are not the least preferred (did not have an asterisk in the offer)"

The inclusion of the "indications" is just to assure that it is clear that it does not need to be just one indication that gets the asterisk .
The last part sounds awkward, but matches technically what the lack of an asterisk means. I inherited the inverted logic for the asterisk from its already defined non-denial meaning.
If you are considering wording for the draft, I suggest that you straighten the logic to say "which language/media are = most preferred (did not have an asterisk in the offer)"

It does also not need to be an "answering human" that gets this indication and makes use of it for guidance on how to answer the call. It can just as well be e.g. a multi-modal answering machine or some other application interacting with human language. I am not sure if "answering party" is more appropriate and = can be considered including such automata. 

Thanks,
Gunnar


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

= --Apple-Mail=_DA4A8662-2C82-4E74-B004-017785D707F6-- From nobody Wed Mar 1 08:05:33 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 920271295BC for ; Wed, 1 Mar 2017 08:05:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hanTAcJSAsT for ; Wed, 1 Mar 2017 08:05:29 -0800 (PST) Received: from bin-vsp-out-02.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59DCF1294ED for ; Wed, 1 Mar 2017 08:05:29 -0800 (PST) X-Halon-ID: e0362c64-fe98-11e6-af93-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Wed, 1 Mar 2017 17:05:22 +0100 (CET) To: Brian Rosen References: <148782279664.31054.8793649134696520241.idtracker@ietfa.amsl.com> <49fd730e-6e90-1a49-eae8-80f8b1285a76@omnitor.se> <83152ba7-c3fb-25d8-f97d-59c7840cad56@omnitor.se> <4b36f347-955e-e2b9-12f2-f426d47d3d33@omnitor.se> <7f844aaa-17ce-2ab7-0602-a999a40235de@omnitor.se> <825fa638-b223-d716-6a3c-238903a37b92@omnitor.se> <3710F834-0FB4-4D17-8E91-043624EF73E8@brianrosen.net> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Wed, 1 Mar 2017 17:05:20 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <3710F834-0FB4-4D17-8E91-043624EF73E8@brianrosen.net> Content-Type: multipart/alternative; boundary="------------DADA6B61A8A7766607F3E1BC" Archived-At: Cc: slim@ietf.org, Bernard Aboba , Randall Gellens , Natasha Rooney , "Phillips, Addison" Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-07.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 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, 01 Mar 2017 16:05:32 -0000 This is a multi-part message in MIME format. --------------DADA6B61A8A7766607F3E1BC Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Den 2017-03-01 kl. 14:34, skrev Brian Rosen: > I haven’t commented on this thread much, but I agree with Randall. > > I am opposed to a protocol document saying anything about human > interface. The answering device may be an automaton, and there could > be very good reasons to not tell the human which languages/media are > not the least preferred. Yes, we discussed this before and limited us to expressions like the one in chapter 1. " Both sides should be aware of which language was negotiated. " That is as much as we need to say. The need is equal for the languages, the modalities and the preferences. If the answering instance has registered capability in spoken English, French or Greek, and only Greek matches what the caller has indicated, the answering instance need to become aware of that so that the call can be started in the proper way in spoken Greek. Also if the caller indicates a preference for receiving written English, or at lower preference spoken English, and the answering instance is capable of both, the answering instance need to become aware of the preferenceso that the call can be started in the way that results in the most successful start in written English. My minimal wording proposal in issue 12 was: "The asterisk should be attached to attributes with languages of lower preference to be matched if such difference can be specified. Thereby the location of the asterisk can be used to support the decision on which languages to use in the call." This is not user interface specification, and likely as far as we should go in order to not specify user interface more for this preference indication than we do for the other language and preference indicators. I wonder what Randall had in mind by the recent question about what my words meant. Regards Gunnar > > Designing good user interfaces is very hard, the participants on this > list are not experts, and we should not offer advice on human factors > in our documents. It is sufficient to transport the information > across the wire. > > Brian > >> On Mar 1, 2017, at 2:26 AM, Gunnar Hellström >> > wrote: >> >> Hi Randall, >> Den 2017-03-01 kl. 02:08, skrev Randall Gellens: >>> Hi Gunnar, >>> >>> I'm starting a new message to cut out the huge amount of quoting. >>> >>> Your proposal is that text be added that advises the calling client >>> to place an asterisk on the least-preferred language/media, and >>> advises the answering client to indicate to the answering human >>> which language/media is not the least preferred (did not have an >>> asterisk in the offer), is that accurate? >> Yes, with slight rewording to: >> "text that advises the *offering* client to place an asterisk on the >> least-preferred language/media *indications*, and advises the >> answering client to indicate to the answering human which >> language/media are not the least preferred (did not have an asterisk >> in the offer)" >> >> The inclusion of the "indications" is just to assure that it is clear >> that it does not need to be just one indication that gets the asterisk . >> The last part sounds awkward, but matches technically what the lack >> of an asterisk means. I inherited the inverted logic for the asterisk >> from its already defined non-denial meaning. >> If you are considering wording for the draft, I suggest that you >> straighten the logic to say "*which language/media are most preferred >> (did not have an asterisk in the offer)*" >> >> It does also not need to be an "answering human" that gets this >> indication and makes use of it for guidance on how to answer the >> call. It can just as well be e.g. a multi-modal answering machine or >> some other application interacting with human language. I am not sure >> if "*answering party*" is more appropriate and can be considered >> including such automata. >> >> Thanks, >> Gunnar >> >> >> _______________________________________________ >> 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 --------------DADA6B61A8A7766607F3E1BC Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Den 2017-03-01 kl. 14:34, skrev Brian Rosen:

I haven’t commented on this thread much, but I agree with Randall.

I am opposed to a protocol document saying anything about human interface.  The answering device may be an automaton, and there could be very good reasons to not tell the human which languages/media are not the least preferred. 
Yes, we discussed this before and limited us to expressions like the one in chapter 1. " Both sides
   should be aware of which language was negotiated. "

That is as much as we need to say. The need is equal for the languages, the modalities and the preferences.
If the answering instance has registered capability in spoken English, French or Greek, and only Greek matches what the caller has indicated, the answering instance need to become aware of that so that the call can be started in the proper way in spoken Greek.
Also if the caller indicates a preference for receiving written English, or at lower preference spoken English, and the answering instance is capable of both, the answering instance need to become aware of the preferenceso that the call can be started in the way that results in the most successful start in written English.

My minimal wording proposal in issue 12 was:

"The asterisk should be attached to attributes with languages of lower
  preference to be matched if such difference can be specified. Thereby
  the location of the asterisk can be used to support the decision on
  which languages to use in the call."

This is not user interface specification, and likely as far as we should go in order to not specify user interface more for this preference indication than we do for the other language and preference indicators.

I wonder what Randall had in mind by the recent question about what my words meant.

Regards
Gunnar


Designing good user interfaces is very hard, the participants on this list are not experts, and we should not offer advice on human factors in our documents.  It is sufficient to transport the information across the wire.

Brian

On Mar 1, 2017, at 2:26 AM, Gunnar Hellström <gunnar.hellstrom@omnitor.se> wrote:

Hi Randall,
Den 2017-03-01 kl. 02:08, skrev Randall Gellens:
Hi Gunnar,

I'm starting a new message to cut out the huge amount of quoting.

Your proposal is that text be added that advises the calling client to place an asterisk on the least-preferred language/media, and advises the answering client to indicate to the answering human which language/media is not the least preferred (did not have an asterisk in the offer), is that accurate?
Yes, with slight rewording to:
"text that advises the offering client to place an asterisk on the least-preferred language/media indications, and advises the answering client to indicate to the answering human which language/media are not the least preferred (did not have an asterisk in the offer)"

The inclusion of the "indications" is just to assure that it is clear that it does not need to be just one indication that gets the asterisk .
The last part sounds awkward, but matches technically what the lack of an asterisk means. I inherited the inverted logic for the asterisk from its already defined non-denial meaning.
If you are considering wording for the draft, I suggest that you straighten the logic to say "which language/media are most preferred (did not have an asterisk in the offer)"

It does also not need to be an "answering human" that gets this indication and makes use of it for guidance on how to answer the call. It can just as well be e.g. a multi-modal answering machine or some other application interacting with human language. I am not sure if "answering party" is more appropriate and can be considered including such automata. 

Thanks,
Gunnar


_______________________________________________
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
--------------DADA6B61A8A7766607F3E1BC-- From nobody Wed Mar 1 09:47:20 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCE7A129630 for ; Wed, 1 Mar 2017 09:47:17 -0800 (PST) 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: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvbOF7AwtoyE for ; Wed, 1 Mar 2017 09:47:16 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5CC12962B for ; Wed, 1 Mar 2017 09:47:16 -0800 (PST) Received: from [192.168.2.201] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 1 Mar 2017 09:36:40 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <148782279664.31054.8793649134696520241.idtracker@ietfa.amsl.com> <49fd730e-6e90-1a49-eae8-80f8b1285a76@omnitor.se> <83152ba7-c3fb-25d8-f97d-59c7840cad56@omnitor.se> <4b36f347-955e-e2b9-12f2-f426d47d3d33@omnitor.se> <7f844aaa-17ce-2ab7-0602-a999a40235de@omnitor.se> <825fa638-b223-d716-6a3c-238903a37b92@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Wed, 1 Mar 2017 09:47:01 -0800 To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , slim@ietf.org, Natasha Rooney , Bernard Aboba , "Phillips, Addison" 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 Archived-At: Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-07.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 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, 01 Mar 2017 17:47:18 -0000 At 8:26 AM +0100 3/1/17, Gunnar Hellstr=F6m wrote: > Hi Randall, > > Den 2017-03-01 kl. 02:08, skrev Randall Gellens: > >> Hi Gunnar, >> >> I'm starting a new message to cut out the huge amount of quoting. >> >> Your proposal is that text be added that=20 >> advises the calling client to place an=20 >> asterisk on the least-preferred=20 >> language/media, and advises the answering=20 >> client to indicate to the answering human=20 >> which language/media is not the least=20 >> preferred (did not have an asterisk in the=20 >> offer), is that accurate? >> > Yes, with slight rewording to: > "text that advises the offering client to place=20 > an asterisk on the least-preferred=20 > language/media indications, and advises the=20 > answering client to indicate to the answering=20 > human which language/media are not the least=20 > preferred (did not have an asterisk in the=20 > offer)" > > The inclusion of the "indications" is just to=20 > assure that it is clear that it does not need=20 > to be just one indication that gets the=20 > asterisk . > The last part sounds awkward, but matches=20 > technically what the lack of an asterisk means.=20 > I inherited the inverted logic for the asterisk=20 > from its already defined non-denial meaning. > If you are considering wording for the draft, I=20 > suggest that you straighten the logic to say=20 > "which language/media are most preferred (did=20 > not have an asterisk in the offer)" > > It does also not need to be an "answering=20 > human" that gets this indication and makes use=20 > of it for guidance on how to answer the call.=20 > It can just as well be e.g. a multi-modal=20 > answering machine or some other application=20 > interacting with human language. I am not sure=20 > if "answering party" is more appropriate and=20 > can be considered including such automata. Hi Gunnar, Thanks for clarifying, I think I understand your=20 proposal in detail now. After thinking it over,=20 I still think this would be better done in a new=20 draft, because (a) it is advice on a way of using=20 the mechanism to convey additional information;=20 (b) it would be good for the group to discuss the=20 proposal and work through various cases (e.g.,=20 what if the offering client is not going to=20 include an asterisk, what if there is more than=20 one most-preferred language); and (c) it would be=20 good for the group to decide if this meets your=20 need. A new draft, especially one that will be either=20 Informational or BCP, can be done fairly quickly.=20 It could be quite short, perhaps only a page or=20 two of real text plus the boilerplate text. I am=20 happy to help with it. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Build a system that even a fool can use, and only a fool will want to use it. From nobody Wed Mar 1 09:50:43 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1021412962C for ; Wed, 1 Mar 2017 09:50:42 -0800 (PST) X-Quarantine-ID: <27ZawF1jWKje> 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: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27ZawF1jWKje for ; Wed, 1 Mar 2017 09:50:41 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id E96E0129621 for ; Wed, 1 Mar 2017 09:50:40 -0800 (PST) Received: from [192.168.2.201] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 1 Mar 2017 09:40:05 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <3710F834-0FB4-4D17-8E91-043624EF73E8@brianrosen.net> References: <148782279664.31054.8793649134696520241.idtracker@ietfa.amsl.com> <49fd730e-6e90-1a49-eae8-80f8b1285a76@omnitor.se> <83152ba7-c3fb-25d8-f97d-59c7840cad56@omnitor.se> <4b36f347-955e-e2b9-12f2-f426d47d3d33@omnitor.se> <7f844aaa-17ce-2ab7-0602-a999a40235de@omnitor.se> <825fa638-b223-d716-6a3c-238903a37b92@omnitor.se> <3710F834-0FB4-4D17-8E91-043624EF73E8@brianrosen.net> X-Mailer: Eudora for Mac OS X Date: Wed, 1 Mar 2017 09:50:36 -0800 To: Brian Rosen , 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-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Cc: slim@ietf.org, "Phillips, Addison" , Natasha Rooney , Bernard Aboba Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-07.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 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, 01 Mar 2017 17:50:42 -0000 At 8:34 AM -0500 3/1/17, Brian Rosen wrote: > I haven't commented on this thread much, but I agree with Randall. > > I am opposed to a protocol document saying=20 > anything about human interface. The answering=20 > device may be an automaton, and there could be=20 > very good reasons to not tell the human which=20 > languages/media are not the least preferred. > > Designing good user interfaces is very hard,=20 > the participants on this list are not experts,=20 > and we should not offer advice on human factors=20 > in our documents. It is sufficient to=20 > transport the information across the wire. Hi Brian, Gunnar's proposal is now a means of conveying=20 additional information that can be used by the UI=20 but does not discuss UI. However, I think this=20 is better done in a new Informational (or maybe=20 BCP) draft that offers advice to implementers and=20 can discuss the various use cases. >> On Mar 1, 2017, at 2:26 AM, Gunnar Hellstr=F6m=20 >> <gunnar.hellstrom@omnitor.se>=20 >> wrote: >> >> Hi Randall, >> >> Den 2017-03-01 kl. 02:08, skrev Randall Gellens: >> >>> Hi Gunnar, >>> >>> I'm starting a new message to cut out the huge amount of quoting. >>> >>> Your proposal is that text be added that=20 >>> advises the calling client to place an=20 >>> asterisk on the least-preferred=20 >>> language/media, and advises the answering=20 >>> client to indicate to the answering human=20 >>> which language/media is not the least=20 >>> preferred (did not have an asterisk in the=20 >>> offer), is that accurate? >>> >> Yes, with slight rewording to: >> "text that advises the offering client to=20 >> place an asterisk on the least-preferred=20 >> language/media indications, and advises the=20 >> answering client to indicate to the answering=20 >> human which language/media are not the least=20 >> preferred (did not have an asterisk in the=20 >> offer)" >> >> The inclusion of the "indications" is just to=20 >> assure that it is clear that it does not need=20 >> to be just one indication that gets the=20 >> asterisk . >> The last part sounds awkward, but matches=20 >> technically what the lack of an asterisk=20 >> means. I inherited the inverted logic for the=20 >> asterisk from its already defined non-denial=20 >> meaning. >> If you are considering wording for the draft,=20 >> I suggest that you straighten the logic to say=20 >> "which language/media are most preferred (did=20 >> not have an asterisk in the offer)" >> >> It does also not need to be an "answering=20 >> human" that gets this indication and makes use=20 >> of it for guidance on how to answer the call.=20 >> It can just as well be e.g. a multi-modal=20 >> answering machine or some other application=20 >> interacting with human language. I am not sure=20 >> if "answering party" is more appropriate and=20 >> can be considered including such automata. >> >> Thanks, >> Gunnar >> >> _______________________________________________ >> 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: --------------- There are two kinds of lawyers, those who know the law and those who know the judge. From nobody Wed Mar 1 14:06:50 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82319129588 for ; Wed, 1 Mar 2017 14:06:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecYxdX66r8Kr for ; Wed, 1 Mar 2017 14:06:47 -0800 (PST) Received: from bin-vsp-out-03.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 111FA1294AB for ; Wed, 1 Mar 2017 14:06:46 -0800 (PST) X-Halon-ID: 5ac8af61-fecb-11e6-9c99-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Wed, 1 Mar 2017 23:06:42 +0100 (CET) To: Randall Gellens , slim@ietf.org, Natasha Rooney , Bernard Aboba , "Phillips, Addison" References: <148782279664.31054.8793649134696520241.idtracker@ietfa.amsl.com> <49fd730e-6e90-1a49-eae8-80f8b1285a76@omnitor.se> <83152ba7-c3fb-25d8-f97d-59c7840cad56@omnitor.se> <4b36f347-955e-e2b9-12f2-f426d47d3d33@omnitor.se> <7f844aaa-17ce-2ab7-0602-a999a40235de@omnitor.se> <825fa638-b223-d716-6a3c-238903a37b92@omnitor.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <9084ad5c-a3d1-68e1-879b-af759c463fd1@omnitor.se> Date: Wed, 1 Mar 2017 23:06:38 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-07.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 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, 01 Mar 2017 22:06:49 -0000 Den 2017-03-01 kl. 18:47, skrev Randall Gellens: > At 8:26 AM +0100 3/1/17, Gunnar Hellström wrote: > >> Hi Randall, >> >> Den 2017-03-01 kl. 02:08, skrev Randall Gellens: >> >>> Hi Gunnar, >>> >>> I'm starting a new message to cut out the huge amount of quoting. >>> >>> Your proposal is that text be added that advises the calling client >>> to place an asterisk on the least-preferred language/media, and >>> advises the answering client to indicate to the answering human >>> which language/media is not the least preferred (did not have an >>> asterisk in the offer), is that accurate? >>> >> Yes, with slight rewording to: >> "text that advises the offering client to place an asterisk on the >> least-preferred language/media indications, and advises the answering >> client to indicate to the answering human which language/media are >> not the least preferred (did not have an asterisk in the offer)" >> >> The inclusion of the "indications" is just to assure that it is >> clear that it does not need to be just one indication that gets the >> asterisk . >> The last part sounds awkward, but matches technically what the lack >> of an asterisk means. I inherited the inverted logic for the asterisk >> from its already defined non-denial meaning. >> If you are considering wording for the draft, I suggest that you >> straighten the logic to say "which language/media are most preferred >> (did not have an asterisk in the offer)" >> >> It does also not need to be an "answering human" that gets this >> indication and makes use of it for guidance on how to answer the >> call. It can just as well be e.g. a multi-modal answering machine or >> some other application interacting with human language. I am not sure >> if "answering party" is more appropriate and can be considered >> including such automata. > > Hi Gunnar, > > Thanks for clarifying, I think I understand your proposal in detail > now. After thinking it over, I still think this would be better done > in a new draft, because (a) it is advice on a way of using the > mechanism to convey additional information; (b) it would be good for > the group to discuss the proposal and work through various cases > (e.g., what if the offering client is not going to include an > asterisk, what if there is more than one most-preferred language); and > (c) it would be good for the group to decide if this meets your need. Randall, Good that you understand it now. I realize that this kind of added rules for an already existing parameter could be specified in an additional draft. Especially since it has no impact on the current meaning of the asterisk. I still think it is best to add the few words needed now. The preference indication is so severely unbalanced without it, in that only preference between languages in the same modality can be specified. I am afraid that it can be seen as a discrimination against those who would need to specify preference between different modalities in order to tget equal opportunities to get smoothly performed calls through, but cannot. You are right that there are situations that will not be explained if we accept my little extra sentence or something similar. That is true also for the currently specified indications. We have said that we nearly only specify the indications and not how the negotiation shall be performed. It can be a topic for a BCP to advice on how the negotiation could be performed both with the currently specified language and in-media preferences and with the additional preference between media. We could discuss e.g. the case when two same spoken languages are specified but with the opposite preference order by the offeror and answering party. A decision must be taken, because the protocol says that oly one language per media and direction may be indicated in the answer, and also that the answering instance need to become aware of which language it shall produce. I do not say that we need to resolve this case. It can be discussed in a BCP, and indicated that additional policy may be applied for solving that kind of undefined cases. Similarily, there will be situations with the additional use of the asterisk that will be good to provide extra information for in a BCP. The preference indication is very rough, with only two levels. So there wil of course be situations when the users will wonder how to set their profile, and cases when the negotiation will be hard to assign a well motivated result. But we have said that we want to have the specification on this rough level. The two cases that you bring up can have this treatment: 1. If the calling user want to get the call denied if no languages match, then the user must make a decision if that preference is more important to specify than the preference between modalities. In order to keep complexity low, I do not think that we should specify how to code both preferences. 2. If there are more than one most-preferred language. I understand this as for example a user is equally happy to use French sign language as spoken French, and can also, but on lower preference level write French text. That would be indicated by an asterisk on the French text, and the answering party having all these three capabilities may omit the French text from the answer but keep the others. Then the answering user select one of the spoken French and French Sign Language for its start of the call, knowing that the caller will be approximately equally happy with the call in both these cases. Was that the case you thought about for the second case? I understand that you wanted to check more than these two cases and discuss them with the WG, so the above is just a start. We can do more cases if you want, but I do not think we need any lengthy discussion that would delay the current draft. > > > A new draft, especially one that will be either Informational or BCP, > can be done fairly quickly. It could be quite short, perhaps only a > page or two of real text plus the boilerplate text. I am happy to > help with it. > Tanks, Gunnar -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Wed Mar 1 15:49:15 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749AC129417 for ; Wed, 1 Mar 2017 15:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=realtimetext.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AX4x61tlYRDD for ; Wed, 1 Mar 2017 15:49:11 -0800 (PST) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::8]) (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 AD44C128DF6 for ; Wed, 1 Mar 2017 15:49:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1488412148; l=8325; s=domk; d=realtimetext.org; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:From:To:References:Subject:Reply-To; bh=IOcAexNGCe81DuIA7G9mQKWJFNOOScTBmrjEJ/16OaI=; b=yzK36rU+tq2OXdVLNnCXJr88Rrw1tmZSZPr9KTzI5+yFGlY3v+l37CQIntWRMk/yFj 4FsTxegLUYhT02P2nYZ3ZV5zMYNilOgjMBP2ZrwjFhKFmqIy9O8lRbse2DUfTAgGCr/2 DLOunXD6T8LtynhOaBdM0QZpqEQ4Hv0RKAIS4= X-RZG-AUTH: :LX4KelWsW+3xSJJIkwZSBiHL/ghnhZXt77aKzZJz2lzFCSL5Vcj0jP3MsKJGpfKONDSU/Br4yw9iUlBiHAZV5yXXBu0Lr6J/HuDylQ== X-RZG-CLASS-ID: mo00 Received: from MacBookPro-0020FC300A3E.local ([2601:601:c880:2428:ad75:242d:dcc:fdac]) by smtp.strato.com (RZmta 39.13 AUTH) with ESMTPSA id R00f54t21Nn2Iyv (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Thu, 2 Mar 2017 00:49:02 +0100 (CET) References: <148782279664.31054.8793649134696520241.idtracker@ietfa.amsl.com> <49fd730e-6e90-1a49-eae8-80f8b1285a76@omnitor.se> <83152ba7-c3fb-25d8-f97d-59c7840cad56@omnitor.se> <4b36f347-955e-e2b9-12f2-f426d47d3d33@omnitor.se> <7f844aaa-17ce-2ab7-0602-a999a40235de@omnitor.se> <825fa638-b223-d716-6a3c-238903a37b92@omnitor.se> <9084ad5c-a3d1-68e1-879b-af759c463fd1@omnitor.se> To: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= , Randall Gellens , slim@ietf.org, Natasha Rooney , Bernard Aboba , "Phillips, Addison" From: Arnoud van Wijk Organization: R3TF Message-ID: <37ff1070-b985-3998-b1fc-a17cf3815fa0@realtimetext.org> Date: Wed, 1 Mar 2017 15:49:01 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <9084ad5c-a3d1-68e1-879b-af759c463fd1@omnitor.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-07.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: arnoud.vanwijk@realtimetext.org List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 23:49:13 -0000 Hi all, I have been reading the draft and trying to follow the discussions so far. Randall, this is a very interesting draft and very useful to indicate the different language preferences in a call. The first thing that I noticed is that I would not be able to select my language preference to e.g. send spoken English and if not possible then to send English in RTT. At the same time I do have the preference to receive RTT in English and if not possible then to receive the video so I can (try to )lipread the other person. So, the ability to set a language preference between different modalities instead of only language preferences within one modality is quite essential for many users who have a limited or no ability to use a certain modality. For example a user prefers to receive ASL but if that is not possible then receive RTT is fine. Sending ASL and if not possible send RTT. But skip audio. So, how can we indicate the language preferences in sending and receiving modalities/different media instead of only the selection of language within one modality/media? I read Gunnar's proposal to use the asterisk to indicate the least preferred media. I think it is an excellent idea since it won't require any changes except the proposed rewording > "text that advises the offering client to place an asterisk on the > least-preferred language/media indications, and advises the answering > client to indicate to the answering human which language/media are not > the least preferred (did not have an asterisk in the offer)" and then as mentioned by Gunnar a BCP could expand on all the use cases. And how to answer such offers as a relay center, emergency center or any other system that is able to invoke a relay operator in case the preferred language modality/media is not possible. That are my observations and insights so far. cheers Arnoud On 01/03/2017 14:06, Gunnar Hellström wrote: > Den 2017-03-01 kl. 18:47, skrev Randall Gellens: >> At 8:26 AM +0100 3/1/17, Gunnar Hellström wrote: >> >>> Hi Randall, >>> >>> Den 2017-03-01 kl. 02:08, skrev Randall Gellens: >>> >>>> Hi Gunnar, >>>> >>>> I'm starting a new message to cut out the huge amount of quoting. >>>> >>>> Your proposal is that text be added that advises the calling >>>> client to place an asterisk on the least-preferred language/media, >>>> and advises the answering client to indicate to the answering human >>>> which language/media is not the least preferred (did not have an >>>> asterisk in the offer), is that accurate? >>>> >>> Yes, with slight rewording to: >>> "text that advises the offering client to place an asterisk on the >>> least-preferred language/media indications, and advises the >>> answering client to indicate to the answering human which >>> language/media are not the least preferred (did not have an asterisk >>> in the offer)" >>> >>> The inclusion of the "indications" is just to assure that it is >>> clear that it does not need to be just one indication that gets the >>> asterisk . >>> The last part sounds awkward, but matches technically what the lack >>> of an asterisk means. I inherited the inverted logic for the >>> asterisk from its already defined non-denial meaning. >>> If you are considering wording for the draft, I suggest that you >>> straighten the logic to say "which language/media are most preferred >>> (did not have an asterisk in the offer)" >>> >>> It does also not need to be an "answering human" that gets this >>> indication and makes use of it for guidance on how to answer the >>> call. It can just as well be e.g. a multi-modal answering machine or >>> some other application interacting with human language. I am not >>> sure if "answering party" is more appropriate and can be considered >>> including such automata. >> >> Hi Gunnar, >> >> Thanks for clarifying, I think I understand your proposal in detail >> now. After thinking it over, I still think this would be better done >> in a new draft, because (a) it is advice on a way of using the >> mechanism to convey additional information; (b) it would be good for >> the group to discuss the proposal and work through various cases >> (e.g., what if the offering client is not going to include an >> asterisk, what if there is more than one most-preferred language); >> and (c) it would be good for the group to decide if this meets your >> need. > Randall, > Good that you understand it now. > I realize that this kind of added rules for an already existing > parameter could be specified in an additional draft. Especially since > it has no impact on the current meaning of the asterisk. > I still think it is best to add the few words needed now. The > preference indication is so severely unbalanced without it, in that > only preference between languages in the same modality can be > specified. I am afraid that it can be seen as a discrimination against > those who would need to specify preference between different > modalities in order to tget equal opportunities to get smoothly > performed calls through, but cannot. > > You are right that there are situations that will not be explained if > we accept my little extra sentence or something similar. > That is true also for the currently specified indications. We have > said that we nearly only specify the indications and not how the > negotiation shall be performed. It can be a topic for a BCP to advice > on how the negotiation could be performed both with the currently > specified language and in-media preferences and with the additional > preference between media. We could discuss e.g. the case when two same > spoken languages are specified but with the opposite preference order > by the offeror and answering party. A decision must be taken, because > the protocol says that oly one language per media and direction may be > indicated in the answer, and also that the answering instance need to > become aware of which language it shall produce. > I do not say that we need to resolve this case. It can be discussed in > a BCP, and indicated that additional policy may be applied for solving > that kind of undefined cases. > > Similarily, there will be situations with the additional use of the > asterisk that will be good to provide extra information for in a BCP. > The preference indication is very rough, with only two levels. So > there wil of course be situations when the users will wonder how to > set their profile, and cases when the negotiation will be hard to > assign a well motivated result. But we have said that we want to have > the specification on this rough level. > > The two cases that you bring up can have this treatment: > > 1. If the calling user want to get the call denied if no languages > match, then the user must make a decision if that preference is more > important to specify than the preference between modalities. In order > to keep complexity low, I do not think that we should specify how to > code both preferences. > > 2. If there are more than one most-preferred language. I understand > this as for example a user is equally happy to use French sign > language as spoken French, and can also, but on lower preference level > write French text. That would be indicated by an asterisk on the > French text, and the answering party having all these three > capabilities may omit the French text from the answer but keep the > others. Then the answering user select one of the spoken French and > French Sign Language for its start of the call, knowing that the > caller will be approximately equally happy with the call in both these > cases. Was that the case you thought about for the second case? > > I understand that you wanted to check more than these two cases and > discuss them with the WG, so the above is just a start. We can do more > cases if you want, but I do not think we need any lengthy discussion > that would delay the current draft. > > >> >> >> A new draft, especially one that will be either Informational or BCP, >> can be done fairly quickly. It could be quite short, perhaps only a >> page or two of real text plus the boilerplate text. I am happy to >> help with it. >> > Tanks, > > Gunnar > From nobody Wed Mar 1 18:19:22 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D66312945B for ; Wed, 1 Mar 2017 18:19:20 -0800 (PST) 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: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDt39vsbkxYo for ; Wed, 1 Mar 2017 18:19:06 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 44416129411 for ; Wed, 1 Mar 2017 18:19:03 -0800 (PST) Received: from [192.168.2.201] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 1 Mar 2017 18:08:23 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <37ff1070-b985-3998-b1fc-a17cf3815fa0@realtimetext.org> References: <148782279664.31054.8793649134696520241.idtracker@ietfa.amsl.com> <49fd730e-6e90-1a49-eae8-80f8b1285a76@omnitor.se> <83152ba7-c3fb-25d8-f97d-59c7840cad56@omnitor.se> <4b36f347-955e-e2b9-12f2-f426d47d3d33@omnitor.se> <7f844aaa-17ce-2ab7-0602-a999a40235de@omnitor.se> <825fa638-b223-d716-6a3c-238903a37b92@omnitor.se> <9084ad5c-a3d1-68e1-879b-af759c463fd1@omnitor.se> <37ff1070-b985-3998-b1fc-a17cf3815fa0@realtimetext.org> X-Mailer: Eudora for Mac OS X Date: Wed, 1 Mar 2017 18:18:57 -0800 To: arnoud.vanwijk@realtimetext.org, Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , slim@ietf.org, Natasha Rooney , Bernard Aboba , "Phillips, Addison" 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 Archived-At: Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-07.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 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 Mar 2017 02:19:20 -0000 Hi Arnoud, At 3:49 PM -0800 3/1/17, Arnoud van Wijk wrote: > I have been reading the draft and trying to follow the discussions so far= =2E Please check version -08, the most current. > Randall, this is a very interesting draft and=20 > very useful to indicate the different language=20 > preferences in a call. > > The first thing that I noticed is that I would=20 > not be able to select my language preference to=20 > e.g. send spoken English and if not possible=20 > then to send English in RTT. At the same time I=20 > do have the preference to receive RTT in=20 > English and if not possible then to receive the=20 > video so I can (try to )lipread the other=20 > person. > > So, the ability to set a language preference=20 > between different modalities instead of only=20 > language preferences within one modality is=20 > quite essential for many users who have a=20 > limited or no ability to use a certain modality. > > For example a user prefers to receive ASL but=20 > if that is not possible then receive RTT is=20 > fine. Sending ASL and if not possible send RTT.=20 > But skip audio. > > So, how can we indicate the language=20 > preferences in sending and receiving=20 > modalities/different media instead of only the=20 > selection of language within one modality/media? This has been discussed extensively within the=20 SLIM WG, and I do not wish to replay the entire=20 debate. The short answer is that you do not=20 indicate preferences between media, you request=20 all media/languages you are comfortable using,=20 and the callee accepts those it supports. The=20 draft has now closed IETF last call, so it is=20 rather far along to reopen an issue that has=20 already had extensive debate. Obviously, if you=20 feel the group has missed something that was not=20 included in the previous discussions, please=20 point this out. > I read Gunnar's proposal to use the asterisk=20 > to indicate the least preferred media. I think=20 > it is an excellent idea since it won't require=20 > any changes except the proposed rewording > >> "text that advises the offering client to=20 >> place an asterisk on the least-preferred=20 >> language/media indications, and advises the=20 >> answering client to indicate to the answering=20 >> human which language/media are not the least=20 >> preferred (did not have an asterisk in the=20 >> offer)" > and then as mentioned by Gunnar a BCP could=20 > expand on all the use cases. And how to answer=20 > such offers as a relay center, emergency center=20 > or any other system that is able to invoke a=20 > relay operator in case the preferred language=20 > modality/media is not possible. > > That are my observations and insights so far. Thank you, I appreciate it. Your observations=20 will be more meaningful after you have read=20 through the list archive for the various emails=20 discussing language preference; if after having=20 done so you feel that the group has missed=20 something, please let us know. > On 01/03/2017 14:06, Gunnar Hellstr=F6m wrote: >> Den 2017-03-01 kl. 18:47, skrev Randall Gellens: >>> At 8:26 AM +0100 3/1/17, Gunnar Hellstr=F6m wrote: >>> >>>> Hi Randall, >>>> >>>> Den 2017-03-01 kl. 02:08, skrev Randall Gellens: >>>> >>>>> Hi Gunnar, >>>>> >>>>> I'm starting a new message to cut out the huge amount of quoting. >>>>> >>>>> Your proposal is that text be added that=20 >>>>> advises the calling client to place an=20 >>>>> asterisk on the least-preferred=20 >>>>> language/media, and advises the answering=20 >>>>> client to indicate to the answering human=20 >>>>> which language/media is not the least=20 >>>>> preferred (did not have an asterisk in the=20 >>>>> offer), is that accurate? >>>>> >>>> Yes, with slight rewording to: >>>> "text that advises the offering client to=20 >>>> place an asterisk on the least-preferred=20 >>>> language/media indications, and advises the=20 >>>> answering client to indicate to the=20 >>>> answering human which language/media are not=20 >>>> the least preferred (did not have an=20 >>>> asterisk in the offer)" >>>> >>>> The inclusion of the "indications" is just=20 >>>> to assure that it is clear that it does not=20 >>>> need to be just one indication that gets the=20 >>>> asterisk . >>>> The last part sounds awkward, but matches=20 >>>> technically what the lack of an asterisk=20 >>>> means. I inherited the inverted logic for=20 >>>> the asterisk from its already defined=20 >>>> non-denial meaning. >>>> If you are considering wording for the=20 >>>> draft, I suggest that you straighten the=20 >>>> logic to say "which language/media are most=20 >>>> preferred (did not have an asterisk in the=20 >>>> offer)" >>>> >>>> It does also not need to be an "answering=20 >>>> human" that gets this indication and makes=20 >>>> use of it for guidance on how to answer the=20 >>>> call. It can just as well be e.g. a=20 >>>> multi-modal answering machine or some other=20 >>>> application interacting with human language.=20 >>>> I am not sure if "answering party" is more=20 >>>> appropriate and can be considered including=20 >>>> such automata. >>> >>> Hi Gunnar, >>> >>> Thanks for clarifying, I think I understand=20 >>> your proposal in detail now. After thinking=20 >>> it over, I still think this would be better=20 >>> done in a new draft, because (a) it is advice=20 >>> on a way of using the mechanism to convey=20 >>> additional information; (b) it would be good=20 >>> for the group to discuss the proposal and=20 >>> work through various cases (e.g., what if the=20 >>> offering client is not going to include an=20 >>> asterisk, what if there is more than one=20 >>> most-preferred language); and (c) it would be=20 >>> good for the group to decide if this meets=20 >>> your need. >> Randall, >> Good that you understand it now. >> I realize that this kind of added rules for an=20 >> already existing parameter could be specified=20 >> in an additional draft. Especially since it=20 >> has no impact on the current meaning of the=20 >> asterisk. >> I still think it is best to add the few words=20 >> needed now. The preference indication is so=20 >> severely unbalanced without it, in that only=20 >> preference between languages in the same=20 >> modality can be specified. I am afraid that it=20 >> can be seen as a discrimination against those=20 >> who would need to specify preference between=20 >> different modalities in order to tget equal=20 >> opportunities to get smoothly performed calls=20 >> through, but cannot. >> >> You are right that there are situations that=20 >> will not be explained if we accept my little=20 >> extra sentence or something similar. >> That is true also for the currently specified=20 >> indications. We have said that we nearly only=20 >> specify the indications and not how the=20 >> negotiation shall be performed. It can be a=20 >> topic for a BCP to advice on how the=20 >> negotiation could be performed both with the=20 >> currently specified language and in-media=20 >> preferences and with the additional preference=20 >> between media. We could discuss e.g. the case=20 >> when two same spoken languages are specified=20 >> but with the opposite preference order by the=20 >> offeror and answering party. A decision must=20 >> be taken, because the protocol says that oly=20 >> one language per media and direction may be=20 >> indicated in the answer, and also that the=20 >> answering instance need to become aware of=20 >> which language it shall produce. >> I do not say that we need to resolve this=20 >> case. It can be discussed in a BCP, and=20 >> indicated that additional policy may be=20 >> applied for solving that kind of undefined=20 >> cases. >> >> Similarily, there will be situations with the=20 >> additional use of the asterisk that will be=20 >> good to provide extra information for in a=20 >> BCP. The preference indication is very rough,=20 >> with only two levels. So there wil of course=20 >> be situations when the users will wonder how=20 >> to set their profile, and cases when the=20 >> negotiation will be hard to assign a well=20 >> motivated result. But we have said that we=20 >> want to have the specification on this rough=20 >> level. >> >> The two cases that you bring up can have this treatment: >> >> 1. If the calling user want to get the call=20 >> denied if no languages match, then the user=20 >> must make a decision if that preference is=20 >> more important to specify than the preference=20 >> between modalities. In order to keep=20 >> complexity low, I do not think that we should=20 >> specify how to code both preferences. >> >> 2. If there are more than one most-preferred=20 >> language. I understand this as for example a=20 >> user is equally happy to use French sign=20 >> language as spoken French, and can also, but=20 >> on lower preference level write French text.=20 >> That would be indicated by an asterisk on the=20 >> French text, and the answering party having=20 >> all these three capabilities may omit the=20 >> French text from the answer but keep the=20 >> others. Then the answering user select one of=20 >> the spoken French and French Sign Language for=20 >> its start of the call, knowing that the caller=20 >> will be approximately equally happy with the=20 >> call in both these cases. Was that the case=20 >> you thought about for the second case? >> >> I understand that you wanted to check more=20 >> than these two cases and discuss them with the=20 >> WG, so the above is just a start. We can do=20 >> more cases if you want, but I do not think we=20 >> need any lengthy discussion that would delay=20 >> the current draft. >> >>> >>> >>> A new draft, especially one that will be=20 >>> either Informational or BCP, can be done=20 >>> fairly quickly. It could be quite short,=20 >>> perhaps only a page or two of real text plus=20 >>> the boilerplate text. I am happy to help=20 >>> with it. >>> >> Tanks, >> >> Gunnar -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Life is a long lesson in humility. --James M. Barrie From nobody Wed Mar 1 18:21:09 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE8E0129651 for ; Wed, 1 Mar 2017 18:21:07 -0800 (PST) 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: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1W_kDZ03tVD for ; Wed, 1 Mar 2017 18:21:06 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id B79751295DA for ; Wed, 1 Mar 2017 18:21:06 -0800 (PST) Received: from [192.168.2.201] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 1 Mar 2017 18:10:27 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <9084ad5c-a3d1-68e1-879b-af759c463fd1@omnitor.se> References: <148782279664.31054.8793649134696520241.idtracker@ietfa.amsl.com> <49fd730e-6e90-1a49-eae8-80f8b1285a76@omnitor.se> <83152ba7-c3fb-25d8-f97d-59c7840cad56@omnitor.se> <4b36f347-955e-e2b9-12f2-f426d47d3d33@omnitor.se> <7f844aaa-17ce-2ab7-0602-a999a40235de@omnitor.se> <825fa638-b223-d716-6a3c-238903a37b92@omnitor.se> <9084ad5c-a3d1-68e1-879b-af759c463fd1@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Wed, 1 Mar 2017 18:21:02 -0800 To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , slim@ietf.org, Natasha Rooney , Bernard Aboba , "Phillips, Addison" 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 Archived-At: Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-07.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 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 Mar 2017 02:21:08 -0000 Hi Gunnar, At 11:06 PM +0100 3/1/17, Gunnar Hellstr=F6m wrote: > Den 2017-03-01 kl. 18:47, skrev Randall Gellens: >> At 8:26 AM +0100 3/1/17, Gunnar Hellstr=F6m wrote: >> >>> Hi Randall, >>> >>> Den 2017-03-01 kl. 02:08, skrev Randall Gellens: >>> >>>> Hi Gunnar, >>>> >>>> I'm starting a new message to cut out the huge amount of quoting. >>>> >>>> Your proposal is that text be added that=20 >>>> advises the calling client to place an=20 >>>> asterisk on the least-preferred=20 >>>> language/media, and advises the answering=20 >>>> client to indicate to the answering human=20 >>>> which language/media is not the least=20 >>>> preferred (did not have an asterisk in the=20 >>>> offer), is that accurate? >>>> >>> Yes, with slight rewording to: >>> "text that advises the offering client to=20 >>> place an asterisk on the least-preferred=20 >>> language/media indications, and advises the=20 >>> answering client to indicate to the answering=20 >>> human which language/media are not the least=20 >>> preferred (did not have an asterisk in the=20 >>> offer)" >>> >>> The inclusion of the "indications" is just=20 >>> to assure that it is clear that it does not=20 >>> need to be just one indication that gets the=20 >>> asterisk . >>> The last part sounds awkward, but matches=20 >>> technically what the lack of an asterisk=20 >>> means. I inherited the inverted logic for the=20 >>> asterisk from its already defined non-denial=20 >>> meaning. >>> If you are considering wording for the=20 >>> draft, I suggest that you straighten the=20 >>> logic to say "which language/media are most=20 >>> preferred (did not have an asterisk in the=20 >>> offer)" >>> >>> It does also not need to be an "answering=20 >>> human" that gets this indication and makes=20 >>> use of it for guidance on how to answer the=20 >>> call. It can just as well be e.g. a=20 >>> multi-modal answering machine or some other=20 >>> application interacting with human language.=20 >>> I am not sure if "answering party" is more=20 >>> appropriate and can be considered including=20 >>> such automata. >> >> Hi Gunnar, >> >> Thanks for clarifying, I think I understand=20 >> your proposal in detail now. After thinking=20 >> it over, I still think this would be better=20 >> done in a new draft, because (a) it is advice=20 >> on a way of using the mechanism to convey=20 >> additional information; (b) it would be good=20 >> for the group to discuss the proposal and work=20 >> through various cases (e.g., what if the=20 >> offering client is not going to include an=20 >> asterisk, what if there is more than one=20 >> most-preferred language); and (c) it would be=20 >> good for the group to decide if this meets=20 >> your need. > Randall, > Good that you understand it now. > I realize that this kind of added rules for an=20 > already existing parameter could be specified=20 > in an additional draft. Especially since it has=20 > no impact on the current meaning of the=20 > asterisk. > I still think it is best to add the few words=20 > needed now. The preference indication is so=20 > severely unbalanced without it, in that only=20 > preference between languages in the same=20 > modality can be specified. I am afraid that it=20 > can be seen as a discrimination against those=20 > who would need to specify preference between=20 > different modalities in order to tget equal=20 > opportunities to get smoothly performed calls=20 > through, but cannot. > > You are right that there are situations that=20 > will not be explained if we accept my little=20 > extra sentence or something similar. > That is true also for the currently specified=20 > indications. We have said that we nearly only=20 > specify the indications and not how the=20 > negotiation shall be performed. It can be a=20 > topic for a BCP to advice on how the=20 > negotiation could be performed both with the=20 > currently specified language and in-media=20 > preferences and with the additional preference=20 > between media. We could discuss e.g. the case=20 > when two same spoken languages are specified=20 > but with the opposite preference order by the=20 > offeror and answering party. A decision must be=20 > taken, because the protocol says that oly one=20 > language per media and direction may be=20 > indicated in the answer, and also that the=20 > answering instance need to become aware of=20 > which language it shall produce. > I do not say that we need to resolve this case.=20 > It can be discussed in a BCP, and indicated=20 > that additional policy may be applied for=20 > solving that kind of undefined cases. > > Similarily, there will be situations with the=20 > additional use of the asterisk that will be=20 > good to provide extra information for in a BCP.=20 > The preference indication is very rough, with=20 > only two levels. So there wil of course be=20 > situations when the users will wonder how to=20 > set their profile, and cases when the=20 > negotiation will be hard to assign a well=20 > motivated result. But we have said that we want=20 > to have the specification on this rough level. > > The two cases that you bring up can have this treatment: > > 1. If the calling user want to get the call=20 > denied if no languages match, then the user=20 > must make a decision if that preference is more=20 > important to specify than the preference=20 > between modalities. In order to keep complexity=20 > low, I do not think that we should specify how=20 > to code both preferences. > > 2. If there are more than one most-preferred=20 > language. I understand this as for example a=20 > user is equally happy to use French sign=20 > language as spoken French, and can also, but on=20 > lower preference level write French text. That=20 > would be indicated by an asterisk on the French=20 > text, and the answering party having all these=20 > three capabilities may omit the French text=20 > from the answer but keep the others. Then the=20 > answering user select one of the spoken French=20 > and French Sign Language for its start of the=20 > call, knowing that the caller will be=20 > approximately equally happy with the call in=20 > both these cases. Was that the case you=20 > thought about for the second case? > > I understand that you wanted to check more than=20 > these two cases and discuss them with the WG,=20 > so the above is just a start. We can do more=20 > cases if you want, but I do not think we need=20 > any lengthy discussion that would delay the=20 > current draft. > >> >> >> A new draft, especially one that will be=20 >> either Informational or BCP, can be done=20 >> fairly quickly. It could be quite short,=20 >> perhaps only a page or two of real text plus=20 >> the boilerplate text. I am happy to help with=20 >> it. I see your point, however, my view is that this=20 is best covered in a separate draft. As I said=20 above, the draft can be completed very quickly if=20 it is Informational (or even BCP), clear and not=20 controversial. I am happy to help. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The highlight of the annual Computer Bowl occurred when Bill Gates, who was a judge, posed the following question to the contestants: "What contest, held via Usenet, is dedicated to examples of weird, obscure, bizarre, and really bad programming?" After a moment of silence, Jean-Louis Gassee (ex-honcho at Apple) hit his buzzer and answered "Windows." --Recounted by Adam C. Engst From nobody Sat Mar 4 09:25:51 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE7E1294E5 for ; Sat, 4 Mar 2017 09:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QR6Vx5niU2X2 for ; Sat, 4 Mar 2017 09:25:45 -0800 (PST) Received: from bin-vsp-out-03.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 706411289B0 for ; Sat, 4 Mar 2017 09:25:44 -0800 (PST) X-Halon-ID: 95632e2a-00ff-11e7-9c99-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Sat, 4 Mar 2017 18:25:37 +0100 (CET) References: <148639487217.18865.13611191877947090796.idtracker@ietfa.amsl.com> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <8c077967-589d-9795-b1eb-19dccef05fe7@omnitor.se> Date: Sat, 4 Mar 2017 18:25:31 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <148639487217.18865.13611191877947090796.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------545A701A794458AF2C6D2D77" Archived-At: Cc: slim@ietf.org, draft-ietf-slim-negotiating-human-language@ietf.org, slim-chairs@ietf.org, Natasha Rooney , alexey.melnikov@isode.com, bernard.aboba@gmail.com Subject: Re: [Slim] Last Call: (Negotiating Human Language in Real-Time Communications) to Proposed Standard X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 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, 04 Mar 2017 17:25:48 -0000 This is a multi-part message in MIME format. --------------545A701A794458AF2C6D2D77 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit The discussions after the LC seems to have ceased, and it would be good to come to conclusions on where we are with the draft-ietf-slim-negotiating-human-language and what the next steps are. I have below made a summary of where we are in the discussions and in the text in version -08 of the draft. I hope this can help the process. The IETF last call was issued on version -06 on 2017-02-06. I issued a list of 8 observed issues in: https://www.ietf.org/mail-archive/web/slim/current/msg00726.html It was also accompanied by an edited draft. so let us start with these issues and number the topics a - b- c this time, and then walking through all comments: ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- *a) 1. Inexact wording about the syntax of the new attributes in Sections 5 and 5.2.* The optional asterisk was not shown in the syntax description early in section 5.2. This lack was also noted by Dale Worley in the NITs summary for section 5.2 in: https://www.ietf.org/mail-archive/web/slim/current/msg00766.html The response was to delete the syntax presentation in section 5.2. I do not think that was the best solution because it was the only place where the syntax of the whole attribute was presented, but I have accepted it. A number of other small issues with the syntax descriptions in 5.2 and 5.3 were noted and have been corrected in version -08. The remaining issue is a minor one. *Status: No conclusion yet if it was a good decision to delete the syntax description from section 5.2. * -------------------------------------------------------------------------------------------------------------------------------- *b) 2. Reminiscense of earlier syntax.* Also noted by Dale in the nits for section 5.2 in https://www.ietf.org/mail-archive/web/slim/current/msg00766.html *Status: This is sorted out in version -08* ---------------------------------------------------------------------------------------------------------- *c). 3. Inexact wording about O/A procedure in section 5.2* The answers are called "accepted language", but within paranthesis it ismentioned that it is only in most cases that it is selected from theoffer. More suitable is then to just call it just "language": *Status: Sorted out in version -08* ----------------------------------------------------------------------------------------------- *d) 4. Inexact note at end of section 5.2.* The note at end of 5.2 has a short discussion about accepted media as ifit should possibly be influenced by the matching languages. *Status: Sorted out in version -08* --------------------------------------------------------------------------------- *e) 5. Make use of the asterisk modifier on media level with session scope**also for media level purposes.* The asterisk modifier optionally appended on attribute values has in theoriginal -06 draft only a session effect. Instead of specifying a separate session levelattribute, it is proposed that the asterisk gets an expanded definition,so that its placement conveys meaning of value for the successfullanguage negotiation.It has been discussed in the SLIM WG that the specification lacks twofunctions, required by the specifications by other bodies who arewaiting for the results of SLIM real-time work. (e.g. 3GPP TS 22.228 andETSI TR 103 201). 3GPP TS 22.228 requires "The system should be able tonegotiate the user's desired language(s) and modalities, per mediastream and/or session, in order of preference." The most urgent of these functions can be fulfilled in a simple butsufficient way by extending the meaning of the asterisk. That is thepossibility to indicate a difference in preference between languages indifferent modalities.Earlier discussions on this topic has not resulted in a sufficientlysimple mechanism. The extended use of the asterisk proposed here isintended to introduce the required simplification, and yet meet the mosturgent needs. The unusual definition of the asterisk parameter is also noted by Dale in https://www.ietf.org/mail-archive/web/slim/current/msg00766.html technical comment D, saying: "the fact that the current proposal seems to require (but does not directly specify) the coordinated absence/presence of an asterisk on all of the repetitions of humintlang-send or humintlang-recv is a warning that the syntax doesn't represent the semantics as well as it might." Doug Ewell asked if this was an effort to reopen an issue that the WG had rejected. The question and its answer are seen in : https://www.ietf.org/mail-archive/web/slim/current/msg00754.html A dramatically reduced version of the proposal for the solution of indication of preference between languages in different media was introduced by me in item 12 of https://www.ietf.org/mail-archive/web/slim/current/msg00786.html saying: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 12. 5.3 -------------old text----------------- 5.3 No Language in Common -------------new text---------------- 5.3 Preference parameter ------------end of change 1 in 5.3--------------- -------------old text-in 5.3, secondparagraph------------------------------- The mechanism for indicating this preference is that, in an offer, if the last character of any of the 'humintlang-recv' or 'humintlang- send' values is an asterisk, this indicates a request to not fail the call. --------------------------new text------------------------------- The mechanism for indicating this preference is that, in an offer, if the last character of any of the 'humintlang-recv' or 'humintlang- send' values is an asterisk, this indicates a request to not failthe call. The asterisk should be attached to attributes with languages of lower preference to be matched if such difference can be specified. Thereby the location of the asterisk can be used to support the decision on which languages to use in the call. ---------------------------end of change 2 in5.3--------------------------------------Motivation: There has not yet been any conclusion for my proposal no 5in the IETF LC comments of Feb 12.This is a dramatically reduced version that may be easier to accept atthis stage, still covering one of the missing functionalities in the draft.The asterisk is used as a preference parameter in the attributes.Thereby the proposed title change on 5.3With this additional rule about where the asterisk(s) are placed, theanswering parties get good clues about the preferences betweenalternatives presented by the offeror. The chance to set up calls withsatisfied users increase dramatically compared to letting the answeringparty select by chance between alternatives. - - - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - A discussion about the meaning and use of this indication has occurred in: https://www.ietf.org/mail-archive/web/slim/current/msg00803.html Brian was concerned over wording questions from Randall introducing UI dependency in: https://www.ietf.org/mail-archive/web/slim/current/msg00804.html The current proposal has no wording about UI, it only in section 1 states the fact that the parties need to become aware of the language negotiation outcome in order to be able to start the call in appropriate language(s) and modality(ies) Arnoud has supported the need in: https://www.ietf.org/mail-archive/web/slim/current/msg00809.html ***Status: Not resolved. *Randall has answered that he understands the intention and use of this indication, but prefers to handle it in an additional draft. I still claim that the current draft would need this function to meet urgent requirements. *Further discussed i issue n) below.* --------------------------------------------------------------------------------------------------- *f) 6. The cases in the "Silly states" section 5.4 are not all silly. * Change the name of thesection to "5.4 Unusual indications" The section contains too weak specification about what to do with theunusual indications. This is also noted by Bernard in: https://www.ietf.org/mail-archive/web/slim/current/msg00728.html " In particular, I would like the specification to describe: a. What it means when a spoken language tag is included for a video stream. Is this to be interpreted as a request for captioning? b. What it means when a signed language tag is included for an audio stream. Is the meaning of this "undefined" and if so, should it be ignored? c. What it means when a signed language tag is included for a text stream. If some of these scenarios are not defined, the specification can say "this combination does not have a defined meaning" or something like that. The discussion provided explanations of what all four unusual combinations mean, and considered that only the following were practical: Spoken language in video media is an indication of a view of a speaker, when it is of importance for language perception. Written language in video media is an indication of text captions embedded in video, either as integrated video overlay or as a text component in a conglomerate coding declared as m=video. A discussion took place under subject "IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)", noting that there is a problem to differentiate the indication of written language in video and spoken language in video. The use of the "Zxxx" Script subtag was discussed for indication of non-written content (=spoken) language in video, or a script subtag for written language in video. The use of these discriminating mechanisms were discouraged by Addison in: https://www.ietf.org/mail-archive/web/slim/current/msg00757.html Considering this resistance, we agreed to only keep the possibility to indicate the view of the speaker in video of the four possible unusual cases. The others are documented as undefined. But Bernard has an unanswered question in: https://www.ietf.org/mail-archive/web/slim/current/msg00730.html *"Assuming that we go that way, how would captioning be negotiated?"* That is not solved for captioning by text overlay technologies in video, and I think we need to agree if we can ignore that usage. Indicating captioning is also not solved in general, because it is a requirement for simultaneous use of languages in two media in contrast to all other indications that have mainly been about alternatives. I return to that topic at the end of this summary. *Status: Solved except that captions in video is left undefined and that decision needs to be confirmed, and that indication of captions and other simultaneous use of language and media needs to be discussed**. * ----------------------------------------------------------------------------------------------------------- *g) 7. Examples section 5.5 requires expansion ** * The examples section 5.5 was very brief, but got well extended in version -08. However, Dale requested that it should contain an example of the request to see the speaker, in the 5.5 part of: https://www.ietf.org/mail-archive/web/slim/current/msg00766.html *Status: Good expansion of examples done, but example of request to see speaker is requested by the reviewer but not yet included.* ------------------------------------------------------------------------------------------------------------ *h). 8. Include more fields for attribute registration from 4566bis in section 6.*** *Status: Resolved exept that "Mux" is spelled "MUX" in version -08. The author has been provided a note about that.* --------------------------------------------------------------------------------------------------------------- *i) Should use of the expression "spoken/written language tag" be reworded?* Addison discouraged from use of the expression "spoken/written language tag" in: https://www.ietf.org/mail-archive/web/slim/current/msg00757.html Yet, the expression appeared in section 5.4 of version -08. *S**tatus: Addison should be consulted if the current use is acceptable, and if not, a rewording should be made.* ----------------------------------------------------------------------------------------------------- *j.) The syntax of the attribute is questioned.* Dale notes in the Gen-ART review nits section D of https://www.ietf.org/mail-archive/web/slim/current/msg00766.html That: "D. Use the Accept-Language syntax It seems to me that it would better to use the Accept-Language syntax for the attribute values. This allows (1) specifiying the quality of language experience, allowing clear description of bilingualism, (2) a unified method of specifying whether or not arbitrary languages are acceptable, and (3) abbreviating SDP descriptions." The syntax and semantics of the asterisk parameter is also questioned by Paul Kyziwat in: https://www.ietf.org/mail-archive/web/slim/current/msg00758.html Randall has answered in : https://www.ietf.org/mail-archive/web/slim/current/msg00769.html saying that the WG wanted to have asimple solution, not introducing q-values and other comlexities. There has not been any further discussion on the proposal to use the Accept-Language syntax. It could solve both the neeed for preference indication to be valid between media and solve the need for indication of simultaneous use of language/media by just a little additional usage rule that the q-value has scope over the whole SDP, and that equal q-value for languages in the same direction means a request or capability to use these languages simultaneously ( e.g. needed to resolve the captioning issue ). *Status: Using the Accept-Language syntax should be considered as a way to both clean up and shorten syntax, and a way to solve the need for indication of simultaneous use and of preference between language in different media.* --------------------------------------------------------------------------------------------------- *k.) Shortening of the attribute names.* Dale proposed shortening of the long attribute names and also introducing attributes for symmetric use of languages in both directions, in nits C and E of: https://www.ietf.org/mail-archive/web/slim/current/msg00766.html The shortening to "hlang-" was accepted, and is used in version -08. The combination to bidirectional attributes was noted in answer on E in: https://www.ietf.org/mail-archive/web/slim/current/msg00769.html *Status: Partly accepted and implemented in version -08. No interest expressed to go further.* ------------------------------------------------------------------------------------------------------ *l). Call failure * Dale proposed that the call failure should be more strictly specified in nits A of https://www.ietf.org/mail-archive/web/slim/current/msg00766.html This was accepted and after some discussion, the SIP returns and reason code and text was drafted and included in v - 08. *Status: Done* --------------------------------------------------------------------------------------------------------------------------- *m). New issues because of changed wording in version -07* Version -07 was published on 2017-02-23. It was found to have a number of mainly minor editorial issues summarised in: https://www.ietf.org/mail-archive/web/slim/current/msg00786.html They are all resolved in version -08, except the wider issue 12 that is identical to item e) above that is also summarised in issue n) below. *Status: Resolved except issue 12 - handled under n) below.* ---------------------------------------------------------------------------------------------------------- *n). Indication of preference between media, and of simultanous versus alternative languages.* This is a summary of the remaining issues related to items e), f), j) and m) above. Issue e) proposes changes to enable indication of preference for language in different media. Issue f) requests possibility to indicate request or offering of text captions of spoken language. Issue j) proposes use of the Accept-Language syntax, that could both solve the functional needs of e) and f) and sort out the syntax and semantics problems of the asterisk parameter. Issue m) just indicates that issue e) is not yet resolved. Randall has proposed to resolve the functional needs in a new draft, and not accept the Accept-Language syntax. I have proposed a simple way to resolve issue e) - the preference between media, at the same time improving the definition of the semantics of the asterisk parameter. No real solution to issue f) - the simultaneity indication has been discussed. Issue j) - the proposal to use the Accept-Language syntax can potentially be used to resolve issues e) and f). Discussion: Issue e) says that there is a need to be able indicate which of a set of language/media indications are more preferred alternatives than others. Examles are: 1. A want to get written English in text, A can as a less preferred alternative accept to get spoken English. An answering party B who can will then respond with written text and get good satisfaction, while another answering user B without text capability will answer in spoken English and have a possibility for a reasonably successful call. Without this indication, the first answering party may have answered with spoken English that will result in less satisfied users. 2. Prefer to receive text, and can accept to receive spoken language. When answering party can use text, that will be satisfied, otherwise soken language will be used. 3. Prefer to use spoken language in both directions, and can accept to use sign language in video in both directions. Answering party has a clear indication of why both spoken and written is indicated and can answer accordingly. 4. Prefer to use sign language in both directions and can accept to use written language in both directions. Sign language users will use sign language, others will use text. 5. Prefer to send sign language and receive text (deaf-blind user), can accept to receive text. In a call with a person with similar prefeences, text will be used both ways, otherwise sign one way and text the other. etc. Issue f) requires a way to indicate use of captioning and other situations where use of simultaneous languages in different modalities are needed: 1. Preference for hearing spoken language and simultaneously read written language in text. ( captioning) . The time is approaching when this can be provided automatically, but also traditionally by a manned service. 2. Preference for hearing spoken language and simultaneously seeing the speaker in video. (lip-reading). Easily and naturally provided once the need i known. 3. Preference for seeing sign language and simultaneously hear spoken language in audio. ( for multiple users at the terminal ) One of the streams is provided by an interpreter. 4. Preference for hearing spoken language and simultaneously view written language in video. (captioning if we accept to specify text as overlay on video) Some of these can be acceptable also if just one of the language/media combinations can be provided, but is much more preferred if both can be provided together. In other cases it is essential to get both simultaneously. There is a need to differentiate in the indication that this preference for getting the languages together is preferred. Alternative coding proposals: 1. Preference between language/modality 1.1 Based on draft -08, add the coding of an asterisk last in an attribute to mean lower preference for a lanugage/media combination than the one(s) without an asterisk. 1.2. Change to the Accept-Language syntax and let the q-values have scope over the whole SDP. 1.3. Introduce a new a=modality attribute on media level, with parameters: , , 2. Preference for simultaneous languages vs alternative languages: 2.1. Based on draft -08, add another notation to the use of the asterisk, e.g. an optional character to be used together with the asterisk to mark media that are wanted together. (ugly) 2.2. Use the Accept-Language syntax and add the usage rules that q-values with less than .1 difference mean languages with a preference to be used together. Higher differences indicate that they are alternatives. Thereby it is both possible to indicate simultaneity and preference if the simultaneity cannot be satisfied. 2.3. Add to the new a=modality attribute a third, optional parameter [simultaneity] with value any single letter, indicating a preference for having that modality simultaneously with another modality indicated with the same value in the [simultaneity] parameter. Without this parameter, the modalities are alternatives. * **Status: Not solved. Conclusion needed on how to handle these issues e, f, and j, both regarding which solution and what procedure to take to apply it. * ----------------------------------------------------------------------------------------------------------------------------------- *Summary: There are issues left to handle in items a, e, f, g, i, j and n. *Regards Gunnar ** Den 2017-02-06 kl. 16:27, skrev The IESG: > The IESG has received a request from the Selection of Language for > Internet Media WG (slim) to consider the following document: > - 'Negotiating Human Language in Real-Time Communications' > as Proposed > Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2017-02-20. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > 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 > handled by a 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 a solution using new SDP stream > attributes. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > The document contains these normative downward references. > See RFC 3967 for additional information: > draft-saintandre-sip-xmpp-chat: Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat (None - ) > Note that some of these references may already be listed in the acceptable Downref Registry. > > -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------545A701A794458AF2C6D2D77 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: base64 PGh0bWw+DQogIDxoZWFkPg0KICAgIDxtZXRhIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNl dD13aW5kb3dzLTEyNTIiDQogICAgICBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiPg0KICA8 L2hlYWQ+DQogIDxib2R5IGJnY29sb3I9IiNGRkZGRkYiIHRleHQ9IiMwMDAwMDAiPg0KICAg IDxwPlRoZSBkaXNjdXNzaW9ucyBhZnRlciB0aGUgTEMgc2VlbXMgdG8gaGF2ZSBjZWFzZWQs IGFuZCBpdCB3b3VsZA0KICAgICAgYmUgZ29vZCB0byBjb21lIHRvIGNvbmNsdXNpb25zIG9u IHdoZXJlIHdlIGFyZSB3aXRoIHRoZQ0KICAgICAgZHJhZnQtaWV0Zi1zbGltLW5lZ290aWF0 aW5nLWh1bWFuLWxhbmd1YWdlIGFuZCB3aGF0IHRoZSBuZXh0IHN0ZXBzDQogICAgICBhcmUu PC9wPg0KICAgIDxwPkkgaGF2ZSBiZWxvdyBtYWRlIGEgc3VtbWFyeSBvZiB3aGVyZSB3ZSBh cmUgaW4gdGhlIGRpc2N1c3Npb25zDQogICAgICBhbmQgaW4gdGhlIHRleHQgaW4gdmVyc2lv biAtMDggb2YgdGhlIGRyYWZ0LiBJIGhvcGUgdGhpcyBjYW4gaGVscA0KICAgICAgdGhlIHBy b2Nlc3MuPC9wPg0KICAgIDxwPlRoZSBJRVRGIGxhc3QgY2FsbCB3YXMgaXNzdWVkIG9uIHZl cnNpb24gLTA2IG9uIDIwMTctMDItMDYuPC9wPg0KICAgIDxwPkkgaXNzdWVkIGEgbGlzdCBv ZiA4IG9ic2VydmVkIGlzc3VlcyBpbjo8YnI+DQogICAgICA8YSBjbGFzcz0ibW96LXR4dC1s aW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL3NsaW0vY3VycmVudC9tc2cwMDcyNi5odG1sIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsLWFyY2hpdmUvd2ViL3NsaW0vY3VycmVudC9tc2cwMDcyNi5odG1sPC9hPqCgDQogICAg ICA8YnI+DQogICAgICBJdCB3YXMgYWxzbyBhY2NvbXBhbmllZCBieSBhbiBlZGl0ZWQgZHJh ZnQuPGJyPg0KICAgIDwvcD4NCiAgICA8cD5zbyBsZXQgdXMgc3RhcnQgd2l0aCB0aGVzZSBp c3N1ZXMgYW5kIG51bWJlciB0aGUgdG9waWNzIGEgLSBiLSBjDQogICAgICB0aGlzIHRpbWUs IGFuZCB0aGVuIHdhbGtpbmcgdGhyb3VnaCBhbGwgY29tbWVudHM6PC9wPg0KICAgIDxwPi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPGJyPg0KICAgIDwvcD4NCiAgICA8cHJlIHN0eWxlPSJjb2xvcjog cmdiKDAsIDAsIDApOyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1saWdhdHVy ZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogMjsgdGV4dC1hbGlnbjog c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aWRvd3M6 IDI7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 IG1hcmdpbjogMGVtOyI+PGI+YSkgIDEuIEluZXhhY3Qgd29yZGluZyBhYm91dCB0aGUgc3lu dGF4IG9mIHRoZSBuZXcgYXR0cmlidXRlcyBpbiBTZWN0aW9ucyA1IGFuZCA1LjIuPC9iPg0K VGhlIG9wdGlvbmFsIGFzdGVyaXNrIHdhcyBub3Qgc2hvd24gaW4gdGhlIHN5bnRheCBkZXNj cmlwdGlvbiBlYXJseSBpbiBzZWN0aW9uIDUuMi4gDQpUaGlzIGxhY2sgd2FzIGFsc28gbm90 ZWQgYnkgRGFsZSBXb3JsZXkgaW4gdGhlIE5JVHMgc3VtbWFyeSBmb3Igc2VjdGlvbiA1LjIg aW46DQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NsaW0vY3VycmVudC9tc2cwMDc2Ni5odG1s Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NsaW0vY3VycmVudC9t c2cwMDc2Ni5odG1sPC9hPg0KDQpUaGUgcmVzcG9uc2Ugd2FzIHRvIGRlbGV0ZSB0aGUgc3lu dGF4IHByZXNlbnRhdGlvbiBpbiBzZWN0aW9uIDUuMi4gSSBkbyBub3QgdGhpbmsgdGhhdCB3 YXMgdGhlIGJlc3Qgc29sdXRpb24gYmVjYXVzZSBpdCB3YXMgdGhlIG9ubHkgcGxhY2Ugd2hl cmUgdGhlIHN5bnRheCBvZiB0aGUgd2hvbGUgYXR0cmlidXRlIHdhcyBwcmVzZW50ZWQsIGJ1 dCBJIGhhdmUgYWNjZXB0ZWQgaXQuIA0KQSBudW1iZXIgb2Ygb3RoZXIgc21hbGwgaXNzdWVz IHdpdGggdGhlIHN5bnRheCBkZXNjcmlwdGlvbnMgaW4gNS4yIGFuZCA1LjMgd2VyZSBub3Rl ZCBhbmQgaGF2ZSBiZWVuIGNvcnJlY3RlZCBpbiB2ZXJzaW9uIC0wOC4gDQoNClRoZSByZW1h aW5pbmcgaXNzdWUgaXMgYSBtaW5vciBvbmUuDQoNCjxiPlN0YXR1czogTm8gY29uY2x1c2lv biB5ZXQgaWYgaXQgd2FzIGEgZ29vZCBkZWNpc2lvbiB0byBkZWxldGUgdGhlIHN5bnRheCBk ZXNjcmlwdGlvbiBmcm9tIHNlY3Rpb24gNS4yLiA8L2I+DQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQo8Yj5iKSAyLiBSZW1pbmlzY2Vuc2Ugb2YgZWFybGllciBzeW50YXguPC9iPg0KQWxz byBub3RlZCBieSBEYWxlIGluIHRoZSBuaXRzIGZvciBzZWN0aW9uIDUuMiBpbg0KPGEgY2xh c3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbC1hcmNoaXZlL3dlYi9zbGltL2N1cnJlbnQvbXNnMDA3NjYuaHRtbCI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zbGltL2N1cnJlbnQvbXNnMDA3NjYuaHRt bDwvYT4NCg0KPGI+U3RhdHVzOiBUaGlzIGlzIHNvcnRlZCBvdXQgaW4gdmVyc2lvbiAtMDg8 L2I+DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCjwvcHJlPg0KICAgIDxwcmUgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBmb250 LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3Bh Y2luZzogbm9ybWFsOyBvcnBoYW5zOiAyOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdpZG93czogMjsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgbWFyZ2luOiAwZW07Ij4N CjxiPmMpLiAzLiBJbmV4YWN0IHdvcmRpbmcgYWJvdXQgTy9BIHByb2NlZHVyZSBpbiBzZWN0 aW9uIDUuMjwvYj4NCjx0dCBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zdHls ZTogbm9ybWFsOyBmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBu b3JtYWw7IG9ycGhhbnM6IDI7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAy OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+ VGhlIGFuc3dlcnMgYXJlIGNhbGxlZCAiYWNjZXB0ZWQgbGFuZ3VhZ2UiLCBidXQgd2l0aGlu IHBhcmFudGhlc2lzIGl0IGlzPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ oDwvc3Bhbj48L3R0Pjx0dCBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zdHls ZTogbm9ybWFsOyBmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBu b3JtYWw7IG9ycGhhbnM6IDI7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAy OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+ bWVudGlvbmVkIHRoYXQgaXQgaXMgb25seSBpbiBtb3N0IGNhc2VzIHRoYXQgaXQgaXMgc2Vs ZWN0ZWQgZnJvbSB0aGU8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj6gPC9z cGFuPjwvdHQ+PHR0IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgb3JwaGFuczogMjsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IDI7IHdv cmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij5vZmZl ci4gTW9yZSBzdWl0YWJsZSBpcyB0aGVuIHRvIGp1c3QgY2FsbCBpdCBqdXN0ICJsYW5ndWFn ZSI6DQoNCjxiPlN0YXR1czogU29ydGVkIG91dCBpbiB2ZXJzaW9uIC0wODwvYj4NCg0KDQoN CjwvdHQ+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KPGI+ ZCkgIDQuIEluZXhhY3Qgbm90ZSBhdCBlbmQgb2Ygc2VjdGlvbiA1LjIuPC9iPg0KDQo8L3By ZT4NCiAgICA8dHQgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc3R5bGU6IG5v cm1hbDsNCiAgICAgIGZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgZm9udC12YXJp YW50LWNhcHM6IG5vcm1hbDsNCiAgICAgIGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IDI7DQogICAgICB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7DQogICAgICB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3aWRvd3M6IDI7IHdvcmQtc3BhY2luZzogMHB4Ow0KICAgICAgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+VGhlIG5vdGUgYXQgZW5kIG9mIDUuMiBo YXMgYQ0KICAgICAgc2hvcnQgZGlzY3Vzc2lvbiBhYm91dCBhY2NlcHRlZCBtZWRpYSBhcyBp ZjxzcGFuDQogICAgICAgIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPqA8L3NwYW4+ PC90dD48dHQgc3R5bGU9ImNvbG9yOg0KICAgICAgcmdiKDAsIDAsIDApOyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsNCiAgICAgIGZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj aW5nOg0KICAgICAgbm9ybWFsOyBvcnBoYW5zOiAyOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsNCiAgICAgIHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFj ZTogbm9ybWFsOyB3aWRvd3M6IDI7DQogICAgICB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+aXQgc2hvdWxkDQogICAgICBwb3NzaWJseSBi ZSBpbmZsdWVuY2VkIGJ5IHRoZSBtYXRjaGluZyBsYW5ndWFnZXMuPGJyPg0KICAgICAgPGJy Pg0KICAgICAgPGI+U3RhdHVzOiBTb3J0ZWQgb3V0IGluIHZlcnNpb24gLTA4PC9iPjxicj4N CiAgICA8L3R0Pg0KICAgIDxwcmUgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBmb250LXZh cmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyBvcnBoYW5zOiAyOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6 IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdpZG93czogMjsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgbWFyZ2luOiAwZW07Ij4tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KPC9wcmU+DQogICAgPGI+PHR0IHN0eWxlPSJj b2xvcjogcmdiKDAsIDAsIDApOyBmb250LXN0eWxlOiBub3JtYWw7DQogICAgICAgIGZvbnQt dmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsN CiAgICAgICAgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg b3JwaGFuczogMjsNCiAgICAgICAgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOw0KICAgICAgICB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3aWRvd3M6IDI7IHdvcmQtc3BhY2luZzogMHB4Ow0KICAgICAgICAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7Ij5lKaAgNS4gTWFrZSB1c2Ugb2YgdGhlIGFzdGVyaXNrDQog ICAgICAgIG1vZGlmaWVyIG9uIG1lZGlhIGxldmVsIHdpdGggc2Vzc2lvbiBzY29wZTxzcGFu DQogICAgICAgICAgY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+oDwvc3Bhbj48L3R0 PjwvYj48dHQNCiAgICAgIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXN0eWxl OiBub3JtYWw7DQogICAgICBmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7DQogICAgICBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiAyOw0KICAgICAgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOw0KICAgICAgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAyOyB3b3JkLXNwYWNpbmc6IDBweDsNCiAgICAg IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPjxiPmFsc28gZm9yIG1lZGlhIGxl dmVsIHB1cnBvc2VzLjwvYj48YnI+DQogICAgPC90dD48dHQgc3R5bGU9ImNvbG9yOiByZ2Io MCwgMCwgMCk7IGZvbnQtc3R5bGU6IG5vcm1hbDsNCiAgICAgIGZvbnQtdmFyaWFudC1saWdh dHVyZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsNCiAgICAgIGZvbnQt d2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IDI7DQog ICAgICB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7DQogICAgICB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IDI7IHdvcmQt c3BhY2luZzogMHB4Ow0KICAgICAgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+ VGhlIGFzdGVyaXNrIG1vZGlmaWVyIG9wdGlvbmFsbHkNCiAgICAgIGFwcGVuZGVkIG9uIGF0 dHJpYnV0ZSB2YWx1ZXMgaGFzIGluIHRoZTxzcGFuDQogICAgICAgIGNsYXNzPSJBcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPqA8L3NwYW4+PC90dD48dHQgc3R5bGU9ImNvbG9yOg0KICAgICAg cmdiKDAsIDAsIDApOyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1saWdhdHVy ZXM6IG5vcm1hbDsNCiAgICAgIGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOg0KICAgICAgbm9ybWFsOyBvcnBoYW5zOiAy OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsNCiAgICAgIHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IDI7DQogICAgICB3 b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+b3Jp Z2luYWwgLTA2DQogICAgICBkcmFmdCBvbmx5IGEgc2Vzc2lvbiBlZmZlY3QuIDwvdHQ+PHR0 IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOw0KICAgICAgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7DQogICAgICBmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzoNCiAg ICAgIG5vcm1hbDsgb3JwaGFuczogMjsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50 OiAwcHg7DQogICAgICB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd2lkb3dzOiAyOw0KICAgICAgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsiPkluc3RlYWQgb2YNCiAgICAgIHNwZWNpZnlpbmcgYSBzZXBh cmF0ZSBzZXNzaW9uIGxldmVsPHNwYW4NCiAgICAgICAgY2xhc3M9IkFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+oDwvc3Bhbj48L3R0Pjx0dCBzdHlsZT0iY29sb3I6DQogICAgICByZ2IoMCwg MCwgMCk7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9y bWFsOw0KICAgICAgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6DQogICAgICBub3JtYWw7IG9ycGhhbnM6IDI7IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4Ow0KICAgICAgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMjsNCiAgICAgIHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij5hdHRyaWJ1dGUs IGl0DQogICAgICBpcyBwcm9wb3NlZCB0aGF0IHRoZSBhc3RlcmlzayBnZXRzIGFuIGV4cGFu ZGVkIGRlZmluaXRpb24sPHNwYW4NCiAgICAgICAgY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+oDwvc3Bhbj48L3R0Pjx0dCBzdHlsZT0iY29sb3I6DQogICAgICByZ2IoMCwgMCwg MCk7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFs Ow0KICAgICAgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6DQogICAgICBub3JtYWw7IG9ycGhhbnM6IDI7IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4Ow0KICAgICAgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMjsNCiAgICAgIHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij5zbyB0aGF0IGl0cw0K ICAgICAgcGxhY2VtZW50IGNvbnZleXMgbWVhbmluZyBvZiB2YWx1ZSBmb3IgdGhlIHN1Y2Nl c3NmdWw8c3Bhbg0KICAgICAgICBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj6gPC9z cGFuPjwvdHQ+PHR0IHN0eWxlPSJjb2xvcjoNCiAgICAgIHJnYigwLCAwLCAwKTsgZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7DQogICAgICBm b250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt c3BhY2luZzoNCiAgICAgIG5vcm1hbDsgb3JwaGFuczogMjsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7DQogICAgICB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAyOw0KICAgICAgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPmxhbmd1YWdlDQogICAgICBuZWdvdGlh dGlvbi48L3R0Pjx0dCBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zdHlsZToN CiAgICAgIG5vcm1hbDsgZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBmb250LXZh cmlhbnQtY2Fwczogbm9ybWFsOw0KICAgICAgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogMjsNCiAgICAgIHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsNCiAgICAgIHdoaXRl LXNwYWNlOiBub3JtYWw7IHdpZG93czogMjsgd29yZC1zcGFjaW5nOiAwcHg7DQogICAgICAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij5JdCBoYXMgYmVlbiBkaXNjdXNzZWQg aW4gdGhlIFNMSU0NCiAgICAgIFdHIHRoYXQgdGhlIHNwZWNpZmljYXRpb24gbGFja3MgdHdv PHNwYW4NCiAgICAgICAgY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+oDwvc3Bhbj48 L3R0Pjx0dCBzdHlsZT0iY29sb3I6DQogICAgICByZ2IoMCwgMCwgMCk7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOw0KICAgICAgZm9udC12 YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6DQogICAgICBub3JtYWw7IG9ycGhhbnM6IDI7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0 LWluZGVudDogMHB4Ow0KICAgICAgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdpZG93czogMjsNCiAgICAgIHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij5mdW5jdGlvbnMsDQogICAgICByZXF1aXJlZCBi eSB0aGUgc3BlY2lmaWNhdGlvbnMgYnkgb3RoZXIgYm9kaWVzIHdobyBhcmU8c3Bhbg0KICAg ICAgICBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj6gPC9zcGFuPjwvdHQ+PHR0IHN0 eWxlPSJjb2xvcjoNCiAgICAgIHJnYigwLCAwLCAwKTsgZm9udC1zdHlsZTogbm9ybWFsOyBm b250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7DQogICAgICBmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzoNCiAgICAg IG5vcm1hbDsgb3JwaGFuczogMjsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw cHg7DQogICAgICB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg d2lkb3dzOiAyOw0KICAgICAgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsiPndhaXRpbmcgZm9yDQogICAgICB0aGUgcmVzdWx0cyBvZiBTTElN IHJlYWwtdGltZSB3b3JrLiAoZS5nLiAzR1BQIFRTIDIyLjIyOCBhbmQ8c3Bhbg0KICAgICAg ICBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj6gPC9zcGFuPjwvdHQ+PHR0IHN0eWxl PSJjb2xvcjoNCiAgICAgIHJnYigwLCAwLCAwKTsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250 LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7DQogICAgICBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzoNCiAgICAgIG5v cm1hbDsgb3JwaGFuczogMjsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 DQogICAgICB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lk b3dzOiAyOw0KICAgICAgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsiPkVUU0kgVFIgMTAzDQogICAgICAyMDEpLiAzR1BQIFRTIDIyLjIyOCBy ZXF1aXJlcyAiVGhlIHN5c3RlbSBzaG91bGQgYmUgYWJsZSB0bzxzcGFuDQogICAgICAgIGNs YXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPqA8L3NwYW4+PC90dD48dHQgc3R5bGU9ImNv bG9yOg0KICAgICAgcmdiKDAsIDAsIDApOyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudC1saWdhdHVyZXM6IG5vcm1hbDsNCiAgICAgIGZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOg0KICAgICAgbm9ybWFs OyBvcnBoYW5zOiAyOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsNCiAg ICAgIHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6 IDI7DQogICAgICB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyI+bmVnb3RpYXRlIHRoZQ0KICAgICAgdXNlcidzIGRlc2lyZWQgbGFuZ3VhZ2Uo cykgYW5kIG1vZGFsaXRpZXMsIHBlciBtZWRpYTxzcGFuDQogICAgICAgIGNsYXNzPSJBcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPqA8L3NwYW4+PC90dD48dHQgc3R5bGU9ImNvbG9yOg0KICAg ICAgcmdiKDAsIDAsIDApOyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1saWdh dHVyZXM6IG5vcm1hbDsNCiAgICAgIGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQt d2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOg0KICAgICAgbm9ybWFsOyBvcnBoYW5z OiAyOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsNCiAgICAgIHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IDI7DQogICAg ICB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+ c3RyZWFtIGFuZC9vcg0KICAgICAgc2Vzc2lvbiwgaW4gb3JkZXIgb2YgcHJlZmVyZW5jZS4i IDwvdHQ+PHR0IHN0eWxlPSJjb2xvcjogcmdiKDAsDQogICAgICAwLCAwKTsgZm9udC1zdHls ZTogbm9ybWFsOyBmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7DQogICAgICBmb250 LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3Bh Y2luZzoNCiAgICAgIG5vcm1hbDsgb3JwaGFuczogMjsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7DQogICAgICB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd2lkb3dzOiAyOw0KICAgICAgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPlRoZSBtb3N0DQogICAgICB1cmdlbnQgb2Yg dGhlc2UgZnVuY3Rpb25zIGNhbiBiZSBmdWxmaWxsZWQgaW4gYSBzaW1wbGUgYnV0PHNwYW4N CiAgICAgICAgY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+oDwvc3Bhbj48L3R0Pjx0 dCBzdHlsZT0iY29sb3I6DQogICAgICByZ2IoMCwgMCwgMCk7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOw0KICAgICAgZm9udC12YXJpYW50 LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6DQog ICAgICBub3JtYWw7IG9ycGhhbnM6IDI7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu dDogMHB4Ow0KICAgICAgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdpZG93czogMjsNCiAgICAgIHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7Ij5zdWZmaWNpZW50IHdheQ0KICAgICAgYnkgZXh0ZW5kaW5n IHRoZSBtZWFuaW5nIG9mIHRoZSBhc3Rlcmlzay4gVGhhdCBpcyB0aGU8c3Bhbg0KICAgICAg ICBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj6gPC9zcGFuPjwvdHQ+PHR0IHN0eWxl PSJjb2xvcjoNCiAgICAgIHJnYigwLCAwLCAwKTsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250 LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7DQogICAgICBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzoNCiAgICAgIG5v cm1hbDsgb3JwaGFuczogMjsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 DQogICAgICB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lk b3dzOiAyOw0KICAgICAgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsiPnBvc3NpYmlsaXR5IHRvDQogICAgICBpbmRpY2F0ZSBhIGRpZmZlcmVu Y2UgaW4gcHJlZmVyZW5jZSBiZXR3ZWVuIGxhbmd1YWdlcyBpbjxzcGFuDQogICAgICAgIGNs YXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPqA8L3NwYW4+PC90dD48dHQgc3R5bGU9ImNv bG9yOg0KICAgICAgcmdiKDAsIDAsIDApOyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudC1saWdhdHVyZXM6IG5vcm1hbDsNCiAgICAgIGZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOg0KICAgICAgbm9ybWFs OyBvcnBoYW5zOiAyOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsNCiAg ICAgIHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6 IDI7DQogICAgICB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyI+ZGlmZmVyZW50DQogICAgICBtb2RhbGl0aWVzLjwvdHQ+PHR0IHN0eWxlPSJj b2xvcjogcmdiKDAsIDAsIDApOyBmb250LXN0eWxlOg0KICAgICAgbm9ybWFsOyBmb250LXZh cmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7DQog ICAgICBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBo YW5zOiAyOw0KICAgICAgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl eHQtdHJhbnNmb3JtOiBub25lOw0KICAgICAgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dz OiAyOyB3b3JkLXNwYWNpbmc6IDBweDsNCiAgICAgIC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsiPiBFYXJsaWVyIGRpc2N1c3Npb25zIG9uIHRoaXMNCiAgICAgIHRvcGljIGhh cyBub3QgcmVzdWx0ZWQgaW4gYSBzdWZmaWNpZW50bHk8c3Bhbg0KICAgICAgICBjbGFzcz0i QXBwbGUtY29udmVydGVkLXNwYWNlIj6gPC9zcGFuPjwvdHQ+PHR0IHN0eWxlPSJjb2xvcjoN CiAgICAgIHJnYigwLCAwLCAwKTsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQt bGlnYXR1cmVzOiBub3JtYWw7DQogICAgICBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBm b250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzoNCiAgICAgIG5vcm1hbDsgb3Jw aGFuczogMjsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7DQogICAgICB0 ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAyOw0K ICAgICAgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDsiPnNpbXBsZQ0KICAgICAgbWVjaGFuaXNtLiBUaGUgZXh0ZW5kZWQgdXNlIG9mIHRoZSBh c3RlcmlzayBwcm9wb3NlZCBoZXJlIGlzPHNwYW4NCiAgICAgICAgY2xhc3M9IkFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+oDwvc3Bhbj48L3R0Pjx0dCBzdHlsZT0iY29sb3I6DQogICAgICBy Z2IoMCwgMCwgMCk7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWxpZ2F0dXJl czogbm9ybWFsOw0KICAgICAgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6DQogICAgICBub3JtYWw7IG9ycGhhbnM6IDI7 IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4Ow0KICAgICAgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMjsNCiAgICAgIHdv cmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij5pbnRl bmRlZCB0bw0KICAgICAgaW50cm9kdWNlIHRoZSByZXF1aXJlZCBzaW1wbGlmaWNhdGlvbiwg YW5kIHlldCBtZWV0IHRoZSBtb3N0PHNwYW4NCiAgICAgICAgY2xhc3M9IkFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+oDwvc3Bhbj48L3R0Pjx0dCBzdHlsZT0iY29sb3I6DQogICAgICByZ2Io MCwgMCwgMCk7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWxpZ2F0dXJlczog bm9ybWFsOw0KICAgICAgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6 IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6DQogICAgICBub3JtYWw7IG9ycGhhbnM6IDI7IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4Ow0KICAgICAgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMjsNCiAgICAgIHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij51cmdlbnQg bmVlZHMuPC90dD4NCiAgICA8cHJlIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgZm9udC12 YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgb3JwaGFuczogMjsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50 OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aWRvd3M6IDI7IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IG1hcmdpbjogMGVtOyI+DQpU aGUgdW51c3VhbCBkZWZpbml0aW9uIG9mIHRoZSBhc3RlcmlzayBwYXJhbWV0ZXIgaXMgYWxz byBub3RlZCBieSBEYWxlIGluDQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NsaW0vY3VycmVu dC9tc2cwMDc2Ni5odG1sIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L3NsaW0vY3VycmVudC9tc2cwMDc2Ni5odG1sPC9hPiANCnRlY2huaWNhbCBjb21tZW50IEQs IHNheWluZzoNCiJ0aGUgZmFjdCB0aGF0IHRoZSBjdXJyZW50IHByb3Bvc2FsIHNlZW1zIHRv IHJlcXVpcmUgKGJ1dA0KZG9lcyBub3QgZGlyZWN0bHkgc3BlY2lmeSkgdGhlIGNvb3JkaW5h dGVkIGFic2VuY2UvcHJlc2VuY2Ugb2YgYW4NCmFzdGVyaXNrIG9uIGFsbCBvZiB0aGUgcmVw ZXRpdGlvbnMgb2YgaHVtaW50bGFuZy1zZW5kIG9yDQpodW1pbnRsYW5nLXJlY3YgaXMgYSB3 YXJuaW5nIHRoYXQgdGhlIHN5bnRheCBkb2Vzbid0IHJlcHJlc2VudCB0aGUNCnNlbWFudGlj cyBhcyB3ZWxsIGFzIGl0IG1pZ2h0LiINCg0KRG91ZyBFd2VsbCBhc2tlZCBpZiB0aGlzIHdh cyBhbiBlZmZvcnQgdG8gcmVvcGVuIGFuIGlzc3VlIHRoYXQgdGhlIFdHIGhhZCByZWplY3Rl ZC4NClRoZSBxdWVzdGlvbiBhbmQgaXRzIGFuc3dlciBhcmUgc2VlbiBpbiA6DQo8YSBjbGFz cz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsLWFyY2hpdmUvd2ViL3NsaW0vY3VycmVudC9tc2cwMDc1NC5odG1sIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NsaW0vY3VycmVudC9tc2cwMDc1NC5odG1s PC9hPg0KIA0KQSBkcmFtYXRpY2FsbHkgcmVkdWNlZCB2ZXJzaW9uIG9mIHRoZSBwcm9wb3Nh bCBmb3IgdGhlIHNvbHV0aW9uIG9mIGluZGljYXRpb24gb2YgcHJlZmVyZW5jZSBiZXR3ZWVu IGxhbmd1YWdlcyBpbiBkaWZmZXJlbnQgbWVkaWEgd2FzIGludHJvZHVjZWQgYnkgbWUgaW4g aXRlbSAxMiBvZg0KPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zbGltL2N1cnJlbnQvbXNnMDA3 ODYuaHRtbCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zbGltL2N1 cnJlbnQvbXNnMDA3ODYuaHRtbDwvYT4NCnNheWluZzoNCi0gLSAtIC0gLSAtIC0gLSAtIC0g LSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0g LQ0KMTIuICA1LjMNCi0tLS0tLS0tLS0tLS1vbGQgdGV4dC0tLS0tLS0tLS0tLS0tLS0tDQo1 LjMgTm8gTGFuZ3VhZ2UgaW4gQ29tbW9uDQotLS0tLS0tLS0tLS0tbmV3IHRleHQtLS0tLS0t LS0tLS0tLS0tDQo1LjMgUHJlZmVyZW5jZSBwYXJhbWV0ZXINCi0tLS0tLS0tLS0tLWVuZCBv ZiBjaGFuZ2UgMSBpbiA1LjMtLS0tLS0tLS0tLS0tLS0NCg0KPHR0IHN0eWxlPSJjb2xvcjog cmdiKDAsIDAsIDApOyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1saWdhdHVy ZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogMjsgdGV4dC1hbGlnbjog c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3aWRvd3M6IDI7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4tLS0tLS0tLS0tLS0tb2xkIHRleHQtaW4gNS4zLCBz ZWNvbmQ8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj6gPC9zcGFuPjwvdHQ+ PHR0IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFu czogMjsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IDI7IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij5wYXJhZ3JhcGgtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC90dD4NClRoZSBtZWNoYW5pc20gZm9yIGlu ZGljYXRpbmcgdGhpcyBwcmVmZXJlbmNlIGlzIHRoYXQsIGluIGFuIG9mZmVyLCBpZg0KdGhl IGxhc3QgY2hhcmFjdGVyIG9mIGFueSBvZiB0aGUgJ2h1bWludGxhbmctcmVjdicgb3IgJ2h1 bWludGxhbmctDQpzZW5kJyB2YWx1ZXMgaXMgYW4gYXN0ZXJpc2ssIHRoaXMgaW5kaWNhdGVz IGEgcmVxdWVzdCB0byBub3QgZmFpbCB0aGUgY2FsbC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tbmV3IHRleHQtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGUgbWVj aGFuaXNtIGZvciBpbmRpY2F0aW5nIHRoaXMgcHJlZmVyZW5jZSBpcyB0aGF0LCBpbiBhbiBv ZmZlciwgaWYNCiAgIHRoZSBsYXN0IGNoYXJhY3RlciBvZiBhbnkgb2YgdGhlICdodW1pbnRs YW5nLXJlY3YnIG9yICdodW1pbnRsYW5nLQ0KPHR0IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAs IDApOyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1h bDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogMjsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3aWRvd3M6IDI7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7Ij5zZW5kJyB2YWx1ZXMgaXMgYW4gYXN0ZXJpc2ssIHRoaXMgaW5kaWNh dGVzIGEgcmVxdWVzdCB0byBub3QgZmFpbDxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPqA8L3NwYW4+PC90dD48dHQgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBmb250 LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3Bh Y2luZzogbm9ybWFsOyBvcnBoYW5zOiAyOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdp ZG93czogMjsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsiPnRoZSBjYWxsLjwvdHQ+DQpUaGUgYXN0ZXJpc2sgc2hvdWxkIGJlIGF0dGFjaGVk IHRvIGF0dHJpYnV0ZXMgd2l0aCBsYW5ndWFnZXMgb2YgbG93ZXINCnByZWZlcmVuY2UgdG8g YmUgbWF0Y2hlZCBpZiBzdWNoIGRpZmZlcmVuY2UgY2FuIGJlIHNwZWNpZmllZC4gVGhlcmVi eQ0KdGhlIGxvY2F0aW9uIG9mIHRoZSBhc3RlcmlzayBjYW4gYmUgdXNlZCB0byBzdXBwb3J0 IHRoZSBkZWNpc2lvbiBvbg0Kd2hpY2ggbGFuZ3VhZ2VzIHRvIHVzZSBpbiB0aGUgY2FsbC4N Cjx0dCBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zdHlsZTogbm9ybWFsOyBm b250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhh bnM6IDI7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAyOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+LS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tZW5kIG9mIGNoYW5nZSAyIGluPHNwYW4gY2xhc3M9IkFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+oDwvc3Bhbj48L3R0Pjx0dCBzdHlsZT0iY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3Jt YWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IDI7IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd2lkb3dzOiAyOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyI+NS4zLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS08c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4gDQo8L3NwYW4+PC90dD48 dHQgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u dC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5z OiAyOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMjsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPk1vdGl2YXRpb246IFRo ZXJlIGhhcyBub3QgeWV0IGJlZW4gYW55IGNvbmNsdXNpb24gZm9yIG15IHByb3Bvc2FsIG5v IDU8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4NCqA8L3NwYW4+PC90dD48 dHQgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u dC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5z OiAyOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMjsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPmluIHRoZSBJRVRGIExD IGNvbW1lbnRzIG9mIEZlYiAxMi48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNl Ij6gPC9zcGFuPjwvdHQ+PHR0IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXN0 eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgZm9udC12YXJp YW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgb3JwaGFuczogMjsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6 IDI7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 Ij5UaGlzIGlzIGEgZHJhbWF0aWNhbGx5IHJlZHVjZWQgdmVyc2lvbg0KoHRoYXQgbWF5IGJl IGVhc2llciB0byBhY2NlcHQgYXQ8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNl Ij6gPC9zcGFuPjwvdHQ+PHR0IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXN0 eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgZm9udC12YXJp YW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgb3JwaGFuczogMjsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6 IDI7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 Ij50aGlzIHN0YWdlLCBzdGlsbCBjb3ZlcmluZyBvbmUgb2YgdGhlIG1pc3NpbmcNCmZ1bmN0 aW9uYWxpdGllcyBpbiB0aGUgZHJhZnQuPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+oDwvc3Bhbj48L3R0Pjx0dCBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IG9ycGhhbnM6IDI7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lk b3dzOiAyOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4OyI+VGhlIGFzdGVyaXNrIGlzIHVzZWQgYXMgYSBwcmVmZXJlbmNlIHBhcmFtZXRlciAN CmluIHRoZSBhdHRyaWJ1dGVzLjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PqA8L3NwYW4+PC90dD48dHQgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc3R5 bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBmb250LXZhcmlh bnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyBvcnBoYW5zOiAyOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czog Mjsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsi PlRoZXJlYnkgdGhlIHByb3Bvc2VkIHRpdGxlIGNoYW5nZSBvbiA1LjM8c3BhbiBjbGFzcz0i QXBwbGUtY29udmVydGVkLXNwYWNlIj6gPC9zcGFuPjwvdHQ+PHR0IHN0eWxlPSJjb2xvcjog cmdiKDAsIDAsIDApOyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1saWdhdHVy ZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogMjsgdGV4dC1hbGlnbjog c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3aWRvd3M6IDI7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij5XaXRoIHRoaXMgYWRkaXRpb25hbA0KoHJ1bGUgYWJv dXQgd2hlcmUgdGhlIGFzdGVyaXNrKHMpIGFyZSBwbGFjZWQsIHRoZTxzcGFuIGNsYXNzPSJB cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPqA8L3NwYW4+PC90dD48dHQgc3R5bGU9ImNvbG9yOiBy Z2IoMCwgMCwgMCk7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWxpZ2F0dXJl czogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiAyOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdpZG93czogMjsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsiPmFuc3dlcmluZyBwYXJ0aWVzIGdldCBnb29kIGNsdWVz IA0KYWJvdXQgdGhlIHByZWZlcmVuY2VzIGJldHdlZW48c3BhbiBjbGFzcz0iQXBwbGUtY29u dmVydGVkLXNwYWNlIj6gPC9zcGFuPjwvdHQ+PHR0IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAs IDApOyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1h bDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogMjsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3aWRvd3M6IDI7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7Ij5hbHRlcm5hdGl2ZXMgcHJlc2VudGVkIGJ5IHRoZSBvZmZlcm9yLiBU aGUgY2hhbmNlIA0KdG8gc2V0IHVwIGNhbGxzIHdpdGg8c3BhbiBjbGFzcz0iQXBwbGUtY29u dmVydGVkLXNwYWNlIj6gPC9zcGFuPjwvdHQ+PHR0IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAs IDApOyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1h bDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogMjsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3aWRvd3M6IDI7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7Ij5zYXRpc2ZpZWQgdXNlcnMgaW5jcmVhc2UgZHJhbWF0aWNhbGx5IGNv bXBhcmVkIHRvIGxldHRpbmcgDQp0aGUgYW5zd2VyaW5nPHNwYW4gY2xhc3M9IkFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+oDwvc3Bhbj48L3R0Pjx0dCBzdHlsZT0iY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3Jt YWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IDI7IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd2lkb3dzOiAyOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyI+cGFydHkgc2VsZWN0IGJ5IGNoYW5jZSBiZXR3ZWVuIGFsdGVybmF0 aXZlcy48L3R0Pg0KLSAtIC0gLSAtIC0gLSAtLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAt IC0gLSAtIC0gLSAtIC0gLSAtIC0NCg0KQSBkaXNjdXNzaW9uIGFib3V0IHRoZSBtZWFuaW5n IGFuZCB1c2Ugb2YgdGhpcyBpbmRpY2F0aW9uIGhhcyBvY2N1cnJlZCBpbjoNCjxhIGNsYXNz PSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWwtYXJjaGl2ZS93ZWIvc2xpbS9jdXJyZW50L21zZzAwODAzLmh0bWwiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2xpbS9jdXJyZW50L21zZzAwODAzLmh0bWw8 L2E+DQpCcmlhbiB3YXMgY29uY2VybmVkIG92ZXIgd29yZGluZyBxdWVzdGlvbnMgZnJvbSBS YW5kYWxsIGludHJvZHVjaW5nIFVJIGRlcGVuZGVuY3kgaW46DQo8YSBjbGFzcz0ibW96LXR4 dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL3NsaW0vY3VycmVudC9tc2cwMDgwNC5odG1sIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL3NsaW0vY3VycmVudC9tc2cwMDgwNC5odG1sPC9hPg0KVGhl IGN1cnJlbnQgcHJvcG9zYWwgaGFzIG5vIHdvcmRpbmcgYWJvdXQgVUksIGl0IG9ubHkgaW4g c2VjdGlvbiAxIHN0YXRlcyB0aGUgZmFjdCANCnRoYXQgdGhlIHBhcnRpZXMgbmVlZCB0byBi ZWNvbWUgYXdhcmUgb2YgdGhlIGxhbmd1YWdlIG5lZ290aWF0aW9uIG91dGNvbWUgaW4gb3Jk ZXINCqB0byBiZSBhYmxlIHRvIHN0YXJ0IHRoZSBjYWxsIGluIGFwcHJvcHJpYXRlIGxhbmd1 YWdlKHMpIGFuZCBtb2RhbGl0eShpZXMpICANCkFybm91ZCBoYXMgc3VwcG9ydGVkIHRoZSBu ZWVkIGluOg0KPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zbGltL2N1cnJlbnQvbXNnMDA4MDku aHRtbCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zbGltL2N1cnJl bnQvbXNnMDA4MDkuaHRtbDwvYT4NCjxiPg0KPC9iPjxiPlN0YXR1czogTm90IHJlc29sdmVk LiA8L2I+UmFuZGFsbCBoYXMgYW5zd2VyZWQgdGhhdCBoZSB1bmRlcnN0YW5kcyB0aGUgaW50 ZW50aW9uIGFuZCANCnVzZSBvZiB0aGlzIGluZGljYXRpb24sIGJ1dCBwcmVmZXJzIHRvIGhh bmRsZSBpdCBpbiBhbiBhZGRpdGlvbmFsIGRyYWZ0LiBJIHN0aWxsIA0KY2xhaW0gdGhhdCB0 aGUgY3VycmVudCBkcmFmdCB3b3VsZCBuZWVkIHRoaXMgZnVuY3Rpb24gdG8gbWVldCB1cmdl bnQgcmVxdWlyZW1lbnRzLiANCjxiPkZ1cnRoZXIgZGlzY3Vzc2VkIGkgaXNzdWUgbikgYmVs b3cuPC9iPg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCg0KPGI+ZikgIDYuIFRoZSBjYXNlcyBpbiB0aGUgIlNpbGx5IHN0YXRlcyIg c2VjdGlvbiA1LjQgYXJlIG5vdCBhbGwgc2lsbHkuDQo8L2I+DQo8L3ByZT4NCiAgICA8dHQg c3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc3R5bGU6IG5vcm1hbDsNCiAgICAg IGZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDsNCiAgICAgIGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IG9ycGhhbnM6IDI7DQogICAgICB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6 IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7DQogICAgICB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3aWRvd3M6IDI7IHdvcmQtc3BhY2luZzogMHB4Ow0KICAgICAgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyI+QzwvdHQ+PHR0IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsDQog ICAgICAwKTsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBu b3JtYWw7DQogICAgICBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyBsZXR0ZXItc3BhY2luZzoNCiAgICAgIG5vcm1hbDsgb3JwaGFuczogMjsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7DQogICAgICB0ZXh0LXRyYW5zZm9y bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAyOw0KICAgICAgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPmhhbmdlIHRo ZSBuYW1lDQogICAgICBvZiB0aGU8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNl Ij6gPC9zcGFuPjwvdHQ+PHR0DQogICAgICBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsg Zm9udC1zdHlsZTogbm9ybWFsOw0KICAgICAgZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9y bWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOw0KICAgICAgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogMjsNCiAgICAgIHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsN CiAgICAgIHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMjsgd29yZC1zcGFjaW5nOiAw cHg7DQogICAgICAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij5zZWN0aW9uIHRv PC90dD4NCiAgICA8cHJlIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgZm9udC12YXJpYW50 LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v cm1hbDsgb3JwaGFuczogMjsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aWRvd3M6IDI7IHdvcmQtc3BhY2luZzogMHB4OyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IG1hcmdpbjogMGVtOyI+IjUuNCBVbnVz dWFsIGluZGljYXRpb25zIiANCjx0dCBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IG9ycGhhbnM6IDI7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lk b3dzOiAyOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4OyI+VGhlIHNlY3Rpb24gY29udGFpbnMgdG9vIHdlYWsgc3BlY2lmaWNhdGlvbiBhYm91 dCB3aGF0IHRvIGRvIHdpdGggdGhlPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+oDwvc3Bhbj48L3R0Pjx0dCBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFy aWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IG9ycGhhbnM6IDI7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dz OiAyOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyI+dW51c3VhbCBpbmRpY2F0aW9ucy48L3R0Pg0KVGhpcyBpcyBhbHNvIG5vdGVkIGJ5IEJl cm5hcmQgaW46DQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NsaW0vY3VycmVudC9tc2cwMDcy OC5odG1sIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NsaW0vY3Vy cmVudC9tc2cwMDcyOC5odG1sPC9hPg0KIg0KIEluIHBhcnRpY3VsYXIsIEkgd291bGQgbGlr ZSB0aGUgc3BlY2lmaWNhdGlvbiB0byBkZXNjcmliZTogDQphLiBXaGF0IGl0IG1lYW5zIHdo ZW4gYSBzcG9rZW4gbGFuZ3VhZ2UgdGFnIGlzIGluY2x1ZGVkIGZvciBhIHZpZGVvIHN0cmVh bS4gDQpJcyB0aGlzIHRvIGJlIGludGVycHJldGVkIGFzIGEgcmVxdWVzdCBmb3IgY2FwdGlv bmluZz8NCmIuIFdoYXQgaXQgbWVhbnMgd2hlbiBhIHNpZ25lZCBsYW5ndWFnZSB0YWcgaXMg aW5jbHVkZWQgZm9yIGFuIGF1ZGlvIHN0cmVhbS4NCklzIHRoZSBtZWFuaW5nIG9mIHRoaXMg InVuZGVmaW5lZCIgYW5kIGlmIHNvLCBzaG91bGQgaXQgYmUgaWdub3JlZD8NCmMuIFdoYXQg aXQgbWVhbnMgd2hlbiBhIHNpZ25lZCBsYW5ndWFnZSB0YWcgaXMgaW5jbHVkZWQgZm9yIGEg dGV4dCBzdHJlYW0uDQpJZiBzb21lIG9mIHRoZXNlIHNjZW5hcmlvcyBhcmUgbm90IGRlZmlu ZWQsIHRoZSBzcGVjaWZpY2F0aW9uIGNhbiBzYXkNCiJ0aGlzIGNvbWJpbmF0aW9uIGRvZXMg bm90IGhhdmUgYSBkZWZpbmVkIG1lYW5pbmciIG9yIHNvbWV0aGluZyBsaWtlIHRoYXQuDQoN ClRoZSBkaXNjdXNzaW9uIHByb3ZpZGVkIGV4cGxhbmF0aW9ucyBvZiB3aGF0IGFsbCBmb3Vy IHVudXN1YWwgY29tYmluYXRpb25zDQqgbWVhbiwgYW5kIGNvbnNpZGVyZWQgdGhhdCBvbmx5 IHRoZSBmb2xsb3dpbmcgd2VyZSBwcmFjdGljYWw6DQpTcG9rZW4gbGFuZ3VhZ2UgaW4gdmlk ZW8gbWVkaWEgaXMgYW4gaW5kaWNhdGlvbiBvZiBhIHZpZXcgb2YgYSBzcGVha2VyLA0KoHdo ZW4gaXQgaXMgb2YgaW1wb3J0YW5jZSBmb3IgbGFuZ3VhZ2UgcGVyY2VwdGlvbi4NCldyaXR0 ZW4gbGFuZ3VhZ2UgaW4gdmlkZW8gbWVkaWEgaXMgYW4gaW5kaWNhdGlvbiBvZiB0ZXh0IGNh cHRpb25zIGVtYmVkZGVkDQqgaW4gdmlkZW8sIGVpdGhlciBhcyBpbnRlZ3JhdGVkIHZpZGVv IG92ZXJsYXkgb3IgYXMgYSB0ZXh0IGNvbXBvbmVudCBpbiBhIA0KY29uZ2xvbWVyYXRlIGNv ZGluZyBkZWNsYXJlZCBhcyBtPXZpZGVvLiANCg0KQSBkaXNjdXNzaW9uIHRvb2sgcGxhY2Ug dW5kZXIgc3ViamVjdCANCiJJRVRGIGxhc3QgY2FsbCBmb3IgZHJhZnQtaWV0Zi1zbGltLW5l Z290aWF0aW5nLWh1bWFuLWxhbmd1YWdlIChTZWN0aW9uIDUuNCkiLCANCm5vdGluZyB0aGF0 IHRoZXJlIGlzIGEgcHJvYmxlbSB0byBkaWZmZXJlbnRpYXRlIHRoZSBpbmRpY2F0aW9uIG9m IHdyaXR0ZW4gbGFuZ3VhZ2UNCmluIHZpZGVvIGFuZCBzcG9rZW4gbGFuZ3VhZ2UgaW4gdmlk ZW8uDQpUaGUgdXNlIG9mIHRoZSAiWnh4eCIgU2NyaXB0IHN1YnRhZyB3YXMgZGlzY3Vzc2Vk IGZvciBpbmRpY2F0aW9uIG9mIG5vbi13cml0dGVuIA0KY29udGVudCAoPXNwb2tlbikgbGFu Z3VhZ2UgaW4gdmlkZW8sIG9yIGEgc2NyaXB0IHN1YnRhZyBmb3Igd3JpdHRlbiBsYW5ndWFn ZSBpbiB2aWRlby4NClRoZSB1c2Ugb2YgdGhlc2UgZGlzY3JpbWluYXRpbmcgbWVjaGFuaXNt cyB3ZXJlIGRpc2NvdXJhZ2VkIGJ5IEFkZGlzb24gaW46DQo8YSBjbGFzcz0ibW96LXR4dC1s aW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL3NsaW0vY3VycmVudC9tc2cwMDc1Ny5odG1sIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsLWFyY2hpdmUvd2ViL3NsaW0vY3VycmVudC9tc2cwMDc1Ny5odG1sPC9hPg0KDQpDb25z aWRlcmluZyB0aGlzIHJlc2lzdGFuY2UsIHdlIGFncmVlZCB0byBvbmx5IGtlZXAgdGhlIHBv c3NpYmlsaXR5IHRvIGluZGljYXRlIA0KdGhlIHZpZXcgb2YgdGhlIHNwZWFrZXIgaW4gdmlk ZW8gb2YgdGhlIGZvdXIgcG9zc2libGUgdW51c3VhbCBjYXNlcy4gVGhlIG90aGVycw0KoGFy ZSBkb2N1bWVudGVkIGFzIHVuZGVmaW5lZC4NCg0KQnV0IEJlcm5hcmQgaGFzIGFuIHVuYW5z d2VyZWQgcXVlc3Rpb24gaW46DQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NsaW0vY3VycmVu dC9tc2cwMDczMC5odG1sIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L3NsaW0vY3VycmVudC9tc2cwMDczMC5odG1sPC9hPg0KPC9wcmU+DQogICAgPGI+PGZvbnQg ZmFjZT0iSGVsdmV0aWNhLCBBcmlhbCwgc2Fucy1zZXJpZiIgc2l6ZT0iKzEiPiI8c3Bhbg0K ICAgICAgICAgIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6IDEyLjhw eDsgZm9udC1zdHlsZToNCiAgICAgICAgICBub3JtYWw7IGZvbnQtdmFyaWFudC1saWdhdHVy ZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6DQogICAgICAgICAgbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOw0KICAgICAgICAgIHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u ZTsNCiAgICAgICAgICB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsg ZGlzcGxheTogaW5saW5lICENCiAgICAgICAgICBpbXBvcnRhbnQ7IGZsb2F0OiBub25lOyI+ QXNzdW1pbmcgdGhhdCB3ZSBnbyB0aGF0IHdheSwgaG93DQogICAgICAgICAgd291bGQgY2Fw dGlvbmluZyBiZSBuZWdvdGlhdGVkPzxzcGFuDQogICAgICAgICAgICBjbGFzcz0iQXBwbGUt Y29udmVydGVkLXNwYWNlIj4gIjwvc3Bhbj48L3NwYW4+PC9mb250PjwvYj48YnI+DQogICAg PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiAmcXVvdDtU aW1lcyBOZXcNCiAgICAgIFJvbWFuJnF1b3Q7OyBmb250LXNpemU6IDEyLjhweDsgZm9udC1z dHlsZTogbm9ybWFsOw0KICAgICAgZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBm b250LXZhcmlhbnQtY2Fwczogbm9ybWFsOw0KICAgICAgZm9udC13ZWlnaHQ6IG5vcm1hbDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogMjsNCiAgICAgIHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsNCiAgICAg IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMjsgd29yZC1zcGFjaW5nOiAwcHg7DQog ICAgICAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGRpc3BsYXk6IGlubGluZSAh aW1wb3J0YW50OyBmbG9hdDoNCiAgICAgIG5vbmU7Ij48c3BhbiBjbGFzcz0iQXBwbGUtY29u dmVydGVkLXNwYWNlIj48L3NwYW4+PC9zcGFuPjxmb250DQogICAgICBmYWNlPSJIZWx2ZXRp Y2EsIEFyaWFsLCBzYW5zLXNlcmlmIiBzaXplPSIrMyI+PHNwYW4gc3R5bGU9ImNvbG9yOg0K ICAgICAgICByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTogMTIuOHB4OyBmb250LXN0eWxlOiBu b3JtYWw7DQogICAgICAgIGZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgZm9udC12 YXJpYW50LWNhcHM6IG5vcm1hbDsNCiAgICAgICAgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7DQogICAgICAgIHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs Ow0KICAgICAgICB3b3JkLXNwYWNpbmc6IDBweDsgZGlzcGxheTogaW5saW5lICEgaW1wb3J0 YW50OyBmbG9hdDogbm9uZTsiPjxzcGFuDQogICAgICAgICAgY2xhc3M9IkFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+PGJyPg0KICAgICAgICAgIFRoYXQgaXMgbm90IHNvbHZlZCBmb3IgY2Fw dGlvbmluZyBieSB0ZXh0IG92ZXJsYXkgdGVjaG5vbG9naWVzDQogICAgICAgICAgaW4gdmlk ZW8sIGFuZCBJIHRoaW5rIHdlIG5lZWQgdG8gYWdyZWUgaWYgd2UgY2FuIGlnbm9yZSB0aGF0 DQogICAgICAgICAgdXNhZ2UuPGJyPg0KICAgICAgICAgIEluZGljYXRpbmcgY2FwdGlvbmlu ZyBpcyBhbHNvIG5vdCBzb2x2ZWQgaW4gZ2VuZXJhbCwgYmVjYXVzZQ0KICAgICAgICAgIGl0 IGlzIGEgcmVxdWlyZW1lbnQgZm9yIHNpbXVsdGFuZW91cyB1c2Ugb2YgbGFuZ3VhZ2VzIGlu IHR3bw0KICAgICAgICAgIG1lZGlhIGluIGNvbnRyYXN0IHRvIGFsbCBvdGhlciBpbmRpY2F0 aW9ucyB0aGF0IGhhdmUgbWFpbmx5DQogICAgICAgICAgYmVlbiBhYm91dCBhbHRlcm5hdGl2 ZXMuPGJyPg0KICAgICAgICAgIEkgcmV0dXJuIHRvIHRoYXQgdG9waWMgYXQgdGhlIGVuZCBv ZiB0aGlzIHN1bW1hcnkuPGJyPg0KICAgICAgICAgIDxicj4NCiAgICAgICAgICA8Yj5TdGF0 dXM6IFNvbHZlZCBleGNlcHQgdGhhdCBjYXB0aW9ucyBpbiB2aWRlbyBpcyBsZWZ0DQogICAg ICAgICAgICB1bmRlZmluZWQgYW5kIHRoYXQgZGVjaXNpb24gbmVlZHMgdG8gYmUgY29uZmly bWVkLKAgYW5kIHRoYXQNCiAgICAgICAgICAgIGluZGljYXRpb24gb2YgY2FwdGlvbnMgYW5k IG90aGVyIHNpbXVsdGFuZW91cyB1c2Ugb2YNCiAgICAgICAgICAgIGxhbmd1YWdlIGFuZCBt ZWRpYSBuZWVkcyB0byBiZSBkaXNjdXNzZWQ8L2I+PGI+LqA8L2I+IDxicj4NCiAgICAgICAg PC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PGJyPg0KoC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgPGJyPg0KICAgIDxiPmcpoCA3LiBF eGFtcGxlcyBzZWN0aW9uIDUuNSByZXF1aXJlcyBleHBhbnNpb24NCiAgICA8L2I+PGI+PGJy Pg0KICAgIDwvYj48YnI+DQogICAgVGhlIGV4YW1wbGVzIHNlY3Rpb24gNS41IHdhcyB2ZXJ5 IGJyaWVmLCBidXQgZ290IHdlbGwgZXh0ZW5kZWQgaW4NCiAgICB2ZXJzaW9uIC0wOC48YnI+ DQogICAgSG93ZXZlciwgRGFsZSByZXF1ZXN0ZWQgdGhhdCBpdCBzaG91bGQgY29udGFpbiBh biBleGFtcGxlIG9mIHRoZQ0KICAgIHJlcXVlc3QgdG8gc2VlIHRoZSBzcGVha2VyLCBpbiB0 aGUgNS41IHBhcnQgb2Y6PGJyPg0KICAgIDxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRl eHQiIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2xpbS9j dXJyZW50L21zZzAwNzY2Lmh0bWwiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2 ZS93ZWIvc2xpbS9jdXJyZW50L21zZzAwNzY2Lmh0bWw8L2E+PGJyPg0KICAgIDxicj4NCiAg ICA8Yj5TdGF0dXM6IEdvb2QgZXhwYW5zaW9uIG9mIGV4YW1wbGVzIGRvbmUsIGJ1dCBleGFt cGxlIG9mIHJlcXVlc3QNCiAgICAgIHRvIHNlZSBzcGVha2VyIGlzIHJlcXVlc3RlZCBieSB0 aGUgcmV2aWV3ZXIgYnV0IG5vdCB5ZXQgaW5jbHVkZWQuPC9iPjxicj4NCiAgICA8YnI+DQog ICAgPGJyPg0KICAgIDxwcmUgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc3R5 bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBmb250LXZhcmlh bnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyBvcnBoYW5zOiAyOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdpZG93czogMjsgd29yZC1zcGFjaW5nOiAwcHg7 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgbWFyZ2luOiAwZW07Ij4tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KPGI+ aCkuICA4LiBJbmNsdWRlIG1vcmUgZmllbGRzIGZvciBhdHRyaWJ1dGUgcmVnaXN0cmF0aW9u IGZyb20gNDU2NmJpcyBpbiBzZWN0aW9uIDYuPC9iPjxiPg0KPC9iPg0KPGI+U3RhdHVzOiBS ZXNvbHZlZCBleGVwdCB0aGF0ICJNdXgiIGlzIHNwZWxsZWQgIk1VWCIgaW4gdmVyc2lvbiAt MDguIFRoZSBhdXRob3IgaGFzIGJlZW4gcHJvdmlkZWQgYSBub3RlIGFib3V0IHRoYXQuPC9i Pg0KPC9wcmU+DQogICAgPHByZSBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFy aWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IG9ycGhhbnM6IDI7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2lkb3dzOiAyOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBtYXJnaW46IDBlbTsiPi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PC9wcmU+DQogICAgPGJyPg0KICAgIDxiPmkpIKAgoCBTaG91bGQgdXNlIG9mIHRoZSBleHBy ZXNzaW9uICJzcG9rZW4vd3JpdHRlbiBsYW5ndWFnZSB0YWciDQogICAgICBiZSByZXdvcmRl ZD88L2I+PGJyPg0KICAgIEFkZGlzb24gZGlzY291cmFnZWQgZnJvbSB1c2Ugb2YgdGhlIGV4 cHJlc3Npb24gInNwb2tlbi93cml0dGVuDQogICAgbGFuZ3VhZ2UgdGFnIiBpbjoNCiAgICA8 cHJlIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFu czogMjsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aWRvd3M6IDI7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7IG1hcmdpbjogMGVtOyI+PGEgY2xhc3M9Im1vei10eHQtbGlu ay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl Yi9zbGltL2N1cnJlbnQvbXNnMDA3NTcuaHRtbCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bC1hcmNoaXZlL3dlYi9zbGltL2N1cnJlbnQvbXNnMDA3NTcuaHRtbDwvYT4NCg0KWWV0LCB0 aGUgZXhwcmVzc2lvbiBhcHBlYXJlZCBpbiBzZWN0aW9uIDUuNCBvZiB2ZXJzaW9uIC0wOC4N Cg0KPGI+UzwvYj48Yj50YXR1czogQWRkaXNvbiBzaG91bGQgYmUgY29uc3VsdGVkIGlmIHRo ZSBjdXJyZW50IHVzZSBpcyBhY2NlcHRhYmxlLCBhbmQgaWYgbm90LCBhIHJld29yZGluZyBz aG91bGQgYmUgbWFkZS48L2I+DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo8Yj5qLikgVGhlIHN5bnRheCBvZiB0aGUgYXR0cmlidXRlIGlz IHF1ZXN0aW9uZWQuPC9iPg0KDQpEYWxlIG5vdGVzIGluIHRoZSBHZW4tQVJUIHJldmlldyBu aXRzIHNlY3Rpb24gRCBvZg0KPC9wcmU+DQogICAgPGEgY2xhc3M9Im1vei10eHQtbGluay1m cmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9z bGltL2N1cnJlbnQvbXNnMDA3NjYuaHRtbCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1h cmNoaXZlL3dlYi9zbGltL2N1cnJlbnQvbXNnMDA3NjYuaHRtbDwvYT48YnI+DQogICAgPGJy Pg0KICAgIDxwcmUgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyBvcnBoYW5zOiAyOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdpZG93czogMjsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgbWFyZ2luOiAwZW07Ij5UaGF0Og0KIkQuIFVz ZSB0aGUgQWNjZXB0LUxhbmd1YWdlIHN5bnRheA0KSXQgc2VlbXMgdG8gbWUgdGhhdCBpdCB3 b3VsZCBiZXR0ZXIgdG8gdXNlIHRoZSBBY2NlcHQtTGFuZ3VhZ2Ugc3ludGF4DQpmb3IgdGhl IGF0dHJpYnV0ZSB2YWx1ZXMuICBUaGlzIGFsbG93cyAoMSkgc3BlY2lmaXlpbmcgdGhlIHF1 YWxpdHkgb2YNCmxhbmd1YWdlIGV4cGVyaWVuY2UsIGFsbG93aW5nIGNsZWFyIGRlc2NyaXB0 aW9uIG9mIGJpbGluZ3VhbGlzbSwgKDIpDQphIHVuaWZpZWQgbWV0aG9kIG9mIHNwZWNpZnlp bmcgd2hldGhlciBvciBub3QgYXJiaXRyYXJ5IGxhbmd1YWdlcyBhcmUNCmFjY2VwdGFibGUs IGFuZCAoMykgYWJicmV2aWF0aW5nIFNEUCBkZXNjcmlwdGlvbnMuIg0KDQpUaGUgc3ludGF4 IGFuZCBzZW1hbnRpY3Mgb2YgdGhlIGFzdGVyaXNrIHBhcmFtZXRlciBpcyBhbHNvIHF1ZXN0 aW9uZWQgYnkgUGF1bCBLeXppd2F0IGluOg0KPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVl dGV4dCIgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zbGlt L2N1cnJlbnQvbXNnMDA3NTguaHRtbCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNo aXZlL3dlYi9zbGltL2N1cnJlbnQvbXNnMDA3NTguaHRtbDwvYT4NCg0KUmFuZGFsbCBoYXMg YW5zd2VyZWQgaW4gOg0KPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zbGltL2N1cnJlbnQvbXNn MDA3NjkuaHRtbCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zbGlt L2N1cnJlbnQvbXNnMDA3NjkuaHRtbDwvYT4NCnNheWluZyB0aGF0IHRoZSBXRyB3YW50ZWQg dG8gaGF2ZSBhc2ltcGxlIHNvbHV0aW9uLCBub3QgaW50cm9kdWNpbmcgcS12YWx1ZXMgYW5k IG90aGVyIGNvbWxleGl0aWVzLg0KPC9wcmU+DQogICAgPGJyPg0KICAgIFRoZXJlIGhhcyBu b3QgYmVlbiBhbnkgZnVydGhlciBkaXNjdXNzaW9uIG9uIHRoZSBwcm9wb3NhbCB0byB1c2Ug dGhlDQogICAgQWNjZXB0LUxhbmd1YWdlIHN5bnRheC4gSXQgY291bGQgc29sdmUgYm90aCB0 aGUgbmVlZWQgZm9yIHByZWZlcmVuY2UNCiAgICBpbmRpY2F0aW9uIHRvIGJlIHZhbGlkIGJl dHdlZW4gbWVkaWEgYW5kIHNvbHZlIHRoZSBuZWVkIGZvcg0KICAgIGluZGljYXRpb24gb2Yg c2ltdWx0YW5lb3VzIHVzZSBvZiBsYW5ndWFnZS9tZWRpYSBieSBqdXN0IGEgbGl0dGxlDQog ICAgYWRkaXRpb25hbCB1c2FnZSBydWxlIHRoYXQgdGhlIHEtdmFsdWUgaGFzIHNjb3BlIG92 ZXIgdGhlIHdob2xlIFNEUCwNCiAgICBhbmQgdGhhdCBlcXVhbCBxLXZhbHVlIGZvciBsYW5n dWFnZXMgaW4gdGhlIHNhbWUgZGlyZWN0aW9uIG1lYW5zIGENCiAgICByZXF1ZXN0IG9yIGNh cGFiaWxpdHkgdG8gdXNlIHRoZXNlIGxhbmd1YWdlcyBzaW11bHRhbmVvdXNseSAoIGUuZy4N CiAgICBuZWVkZWQgdG8gcmVzb2x2ZSB0aGUgY2FwdGlvbmluZyBpc3N1ZSApLiCgIDxicj4N CiAgICCgoKAgPGJyPg0KICAgIDxiPlN0YXR1czogVXNpbmcgdGhlIEFjY2VwdC1MYW5ndWFn ZSBzeW50YXggc2hvdWxkIGJlIGNvbnNpZGVyZWQgYXMNCiAgICAgIGEgd2F5IHRvIGJvdGgg Y2xlYW4gdXAgYW5kIHNob3J0ZW4gc3ludGF4LCBhbmQgYSB3YXkgdG8gc29sdmUgdGhlDQog ICAgICBuZWVkIGZvciBpbmRpY2F0aW9uIG9mIHNpbXVsdGFuZW91cyB1c2UgYW5kIG9mIHBy ZWZlcmVuY2UgYmV0d2Vlbg0KICAgICAgbGFuZ3VhZ2UgaW4gZGlmZmVyZW50IG1lZGlhLjwv Yj48YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08 YnI+DQogICAgPGI+ay4pIFNob3J0ZW5pbmcgb2YgdGhlIGF0dHJpYnV0ZSBuYW1lcy48L2I+ PGJyPg0KICAgIERhbGUgcHJvcG9zZWQgc2hvcnRlbmluZyBvZiB0aGUgbG9uZyBhdHRyaWJ1 dGUgbmFtZXMgYW5kIGFsc28NCiAgICBpbnRyb2R1Y2luZyBhdHRyaWJ1dGVzIGZvciBzeW1t ZXRyaWMgdXNlIG9mIGxhbmd1YWdlcyBpbiBib3RoDQogICAgZGlyZWN0aW9ucywgaW4gbml0 cyBDIGFuZCBFIG9mOjxicj4NCiAgICA8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0 IiBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NsaW0vY3Vy cmVudC9tc2cwMDc2Ni5odG1sIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL3NsaW0vY3VycmVudC9tc2cwMDc2Ni5odG1sPC9hPjxicj4NCiAgICBUaGUgc2hvcnRl bmluZyB0byAiaGxhbmctIiB3YXMgYWNjZXB0ZWQsIGFuZCBpcyB1c2VkIGluIHZlcnNpb24g LTA4Lg0KICAgIDxicj4NCiAgICBUaGUgY29tYmluYXRpb24gdG8gYmlkaXJlY3Rpb25hbCBh dHRyaWJ1dGVzIHdhcyBub3RlZCBpbiBhbnN3ZXIgb24gRQ0KICAgIGluOjxicj4NCiAgICA8 YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NsaW0vY3VycmVudC9tc2cwMDc2OS5odG1sIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NsaW0vY3VycmVudC9tc2cwMDc2 OS5odG1sPC9hPjxicj4NCiAgICA8YnI+DQogICAgPGI+U3RhdHVzOiBQYXJ0bHkgYWNjZXB0 ZWQgYW5kIGltcGxlbWVudGVkIGluIHZlcnNpb24gLTA4LiBObw0KICAgICAgaW50ZXJlc3Qg ZXhwcmVzc2VkIHRvIGdvIGZ1cnRoZXIuPC9iPjxicj4NCiAgICA8YnI+DQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQogICAgPGI+bCku IENhbGwgZmFpbHVyZSA8L2I+PGJyPg0KICAgIERhbGUgcHJvcG9zZWQgdGhhdCB0aGUgY2Fs bCBmYWlsdXJlIHNob3VsZCBiZSBtb3JlIHN0cmljdGx5DQogICAgc3BlY2lmaWVkoCBpbiBu aXRzIEEgb2Y8YnI+DQogICAgPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zbGltL2N1cnJlbnQv bXNnMDA3NjYuaHRtbCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9z bGltL2N1cnJlbnQvbXNnMDA3NjYuaHRtbDwvYT48YnI+DQogICAgPGJyPg0KICAgIFRoaXMg d2FzIGFjY2VwdGVkIGFuZCBhZnRlciBzb21lIGRpc2N1c3Npb24sIHRoZSBTSVAgcmV0dXJu cyBhbmQNCiAgICByZWFzb24gY29kZSBhbmQgdGV4dCB3YXMgZHJhZnRlZCBhbmQgaW5jbHVk ZWQgaW4gdiAtIDA4Ljxicj4NCiAgICA8YnI+DQogICAgPGI+U3RhdHVzOiBEb25lPC9iPjxi cj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiAgICA8Yj5tKS4gTmV3IGlzc3VlcyBiZWNhdXNl IG9mIGNoYW5nZWQgd29yZGluZyBpbiB2ZXJzaW9uIC0wNzwvYj48YnI+DQogICAgPGJyPg0K ICAgIFZlcnNpb24gLTA3IHdhcyBwdWJsaXNoZWQgb24gMjAxNy0wMi0yMy48YnI+DQogICAg SXQgd2FzIGZvdW5kIHRvIGhhdmUgYSBudW1iZXIgb2YgbWFpbmx5IG1pbm9yIGVkaXRvcmlh bCBpc3N1ZXMNCiAgICBzdW1tYXJpc2VkIGluOjxicj4NCiAgICA8YSBjbGFzcz0ibW96LXR4 dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL3NsaW0vY3VycmVudC9tc2cwMDc4Ni5odG1sIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL3NsaW0vY3VycmVudC9tc2cwMDc4Ni5odG1sPC9hPjxicj4N CiAgICA8YnI+DQogICAgVGhleSBhcmUgYWxsIHJlc29sdmVkIGluIHZlcnNpb24gLTA4LCBl eGNlcHQgdGhlIHdpZGVyIGlzc3VlIDEyIHRoYXQNCiAgICBpcyBpZGVudGljYWwgdG8gaXRl bSBlKSBhYm92ZSB0aGF0IGlzIGFsc28gc3VtbWFyaXNlZCBpbiBpc3N1ZSBuKQ0KICAgIGJl bG93Ljxicj4NCiAgICA8YnI+DQogICAgPGI+U3RhdHVzOiBSZXNvbHZlZCBleGNlcHQgaXNz dWUgMTIgLSBoYW5kbGVkIHVuZGVyIG4pIGJlbG93LjwvYj48YnI+DQogICAgPGJyPg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4N CiAgICA8YnI+DQogICAgPGI+bikuIEluZGljYXRpb24gb2YgcHJlZmVyZW5jZSBiZXR3ZWVu IG1lZGlhLCBhbmQgb2Ygc2ltdWx0YW5vdXMNCiAgICAgIHZlcnN1cyBhbHRlcm5hdGl2ZSBs YW5ndWFnZXMuPC9iPjxicj4NCiAgICA8YnI+DQogICAgVGhpcyBpcyBhIHN1bW1hcnkgb2Yg dGhlIHJlbWFpbmluZyBpc3N1ZXMgcmVsYXRlZCB0byBpdGVtcyBlKSwgZiksDQogICAgaikg YW5kIG0pIGFib3ZlLiA8YnI+DQogICAgPGJyPg0KICAgIElzc3VlIGUpIHByb3Bvc2VzIGNo YW5nZXMgdG8gZW5hYmxlIGluZGljYXRpb24gb2YgcHJlZmVyZW5jZSBmb3INCiAgICBsYW5n dWFnZSBpbiBkaWZmZXJlbnQgbWVkaWEuPGJyPg0KICAgIElzc3VlIGYpIHJlcXVlc3RzIHBv c3NpYmlsaXR5IHRvIGluZGljYXRlIHJlcXVlc3Qgb3Igb2ZmZXJpbmcgb2YNCiAgICB0ZXh0 IGNhcHRpb25zIG9mIHNwb2tlbiBsYW5ndWFnZS48YnI+DQogICAgSXNzdWUgaikgcHJvcG9z ZXMgdXNlIG9mIHRoZSBBY2NlcHQtTGFuZ3VhZ2Ugc3ludGF4LCB0aGF0IGNvdWxkIGJvdGgN CiAgICBzb2x2ZSB0aGUgZnVuY3Rpb25hbCBuZWVkczxicj4NCiAgICBvZiBlKSBhbmQgZikg YW5kIHNvcnQgb3V0IHRoZSBzeW50YXggYW5kIHNlbWFudGljcyBwcm9ibGVtcyBvZiB0aGUN CiAgICBhc3RlcmlzayBwYXJhbWV0ZXIuPGJyPg0KICAgIElzc3VlIG0pIGp1c3QgaW5kaWNh dGVzIHRoYXQgaXNzdWUgZSkgaXMgbm90IHlldCByZXNvbHZlZC4gPGJyPg0KICAgIDxicj4N CiAgICBSYW5kYWxsIGhhcyBwcm9wb3NlZCB0byByZXNvbHZlIHRoZSBmdW5jdGlvbmFsIG5l ZWRzIGluIGEgbmV3IGRyYWZ0LA0KICAgIGFuZCBub3QgYWNjZXB0IHRoZSBBY2NlcHQtTGFu Z3VhZ2Ugc3ludGF4Ljxicj4NCiAgICBJIGhhdmUgcHJvcG9zZWQgYSBzaW1wbGUgd2F5IHRv IHJlc29sdmUgaXNzdWUgZSkgLSB0aGUgcHJlZmVyZW5jZQ0KICAgIGJldHdlZW4gbWVkaWEs IGF0IHRoZSBzYW1lIHRpbWUgaW1wcm92aW5nIHRoZSBkZWZpbml0aW9uIG9mIHRoZQ0KICAg IHNlbWFudGljcyBvZiB0aGUgYXN0ZXJpc2sgcGFyYW1ldGVyLjxicj4NCiAgICBObyByZWFs IHNvbHV0aW9uIHRvIGlzc3VlIGYpIC0gdGhlIHNpbXVsdGFuZWl0eSBpbmRpY2F0aW9uoCBo YXMgYmVlbg0KICAgIGRpc2N1c3NlZC48YnI+DQogICAgSXNzdWUgaikgLSB0aGUgcHJvcG9z YWwgdG8gdXNlIHRoZSBBY2NlcHQtTGFuZ3VhZ2Ugc3ludGF4IGNhbg0KICAgIHBvdGVudGlh bGx5IGJlIHVzZWQgdG8gcmVzb2x2ZSBpc3N1ZXMgZSkgYW5kIGYpLjxicj4NCiAgICA8YnI+ DQogICAgoERpc2N1c3Npb246PGJyPg0KICAgIElzc3VlIGUpIHNheXMgdGhhdCB0aGVyZSBp cyBhIG5lZWQgdG8gYmUgYWJsZSBpbmRpY2F0ZSB3aGljaCBvZiBhDQogICAgc2V0IG9mIGxh bmd1YWdlL21lZGlhIGluZGljYXRpb25zIGFyZSBtb3JlIHByZWZlcnJlZCBhbHRlcm5hdGl2 ZXMNCiAgICB0aGFuIG90aGVycy48YnI+DQogICAgRXhhbWxlcyBhcmU6PGJyPg0KICAgIDEu IEEgd2FudCB0byBnZXQgd3JpdHRlbiBFbmdsaXNoIGluIHRleHQsIEEgY2FuIGFzIGEgbGVz cyBwcmVmZXJyZWQNCiAgICBhbHRlcm5hdGl2ZSBhY2NlcHQgdG8gZ2V0IHNwb2tlbiBFbmds aXNoLqAgQW4gYW5zd2VyaW5nIHBhcnR5IEIgd2hvDQogICAgY2FuIHdpbGwgdGhlbiByZXNw b25kIHdpdGggd3JpdHRlbiB0ZXh0IGFuZCBnZXQgZ29vZCBzYXRpc2ZhY3Rpb24sDQogICAg d2hpbGUgYW5vdGhlciBhbnN3ZXJpbmcgdXNlciBCIHdpdGhvdXQgdGV4dCBjYXBhYmlsaXR5 IHdpbGwgYW5zd2VyDQogICAgaW4gc3Bva2VuIEVuZ2xpc2ggYW5kIGhhdmUgYSBwb3NzaWJp bGl0eSBmb3IgYSByZWFzb25hYmx5IHN1Y2Nlc3NmdWwNCiAgICBjYWxsLjxicj4NCiAgICBX aXRob3V0IHRoaXMgaW5kaWNhdGlvbiwgdGhlIGZpcnN0IGFuc3dlcmluZyBwYXJ0eSBtYXkg aGF2ZSBhbnN3ZXJlZA0KICAgIHdpdGggc3Bva2VuIEVuZ2xpc2ggdGhhdCB3aWxsIHJlc3Vs dCBpbiBsZXNzIHNhdGlzZmllZCB1c2Vycy4gPGJyPg0KICAgIDIuIFByZWZlciB0byByZWNl aXZlIHRleHQsIGFuZCBjYW4gYWNjZXB0IHRvIHJlY2VpdmUgc3Bva2VuDQogICAgbGFuZ3Vh Z2UuoKAgV2hlbiBhbnN3ZXJpbmcgcGFydHkgY2FuIHVzZSB0ZXh0LCB0aGF0IHdpbGwgYmUN CiAgICBzYXRpc2ZpZWQsIG90aGVyd2lzZSBzb2tlbiBsYW5ndWFnZSB3aWxsIGJlIHVzZWQu PGJyPg0KICAgIDMuIFByZWZlciB0byB1c2Ugc3Bva2VuIGxhbmd1YWdlIGluIGJvdGggZGly ZWN0aW9ucywgYW5kIGNhbiBhY2NlcHQNCiAgICB0byB1c2Ugc2lnbiBsYW5ndWFnZSBpbiB2 aWRlbyBpbiBib3RoIGRpcmVjdGlvbnMuIEFuc3dlcmluZyBwYXJ0eQ0KICAgIGhhcyBhIGNs ZWFyIGluZGljYXRpb24gb2Ygd2h5IGJvdGggc3Bva2VuIGFuZCB3cml0dGVuIGlzIGluZGlj YXRlZA0KICAgIGFuZCBjYW4gYW5zd2VyIGFjY29yZGluZ2x5Ljxicj4NCiAgICA0LiBQcmVm ZXIgdG8gdXNloCBzaWduIGxhbmd1YWdlIGluIGJvdGggZGlyZWN0aW9ucyBhbmQgY2FuIGFj Y2VwdCB0bw0KICAgIHVzZSB3cml0dGVuIGxhbmd1YWdlIGluIGJvdGggZGlyZWN0aW9ucy4g U2lnbiBsYW5ndWFnZSB1c2VycyB3aWxsDQogICAgdXNlIHNpZ24gbGFuZ3VhZ2UsIG90aGVy cyB3aWxsIHVzZSB0ZXh0LiA8YnI+DQogICAgNS4gUHJlZmVyIHRvIHNlbmQgc2lnbiBsYW5n dWFnZSBhbmQgcmVjZWl2ZSB0ZXh0IChkZWFmLWJsaW5kIHVzZXIpLA0KICAgIGNhbiBhY2Nl cHQgdG8gcmVjZWl2ZSB0ZXh0LqAgSW4gYSBjYWxsIHdpdGggYSBwZXJzb24gd2l0aCBzaW1p bGFyDQogICAgcHJlZmVlbmNlcywgdGV4dCB3aWxsIGJlIHVzZWQgYm90aCB3YXlzLCBvdGhl cndpc2Ugc2lnbiBvbmUgd2F5IGFuZA0KICAgIHRleHQgdGhlIG90aGVyLjxicj4NCiAgICA8 YnI+DQogICAgZXRjLiA8YnI+DQogICAgPGJyPg0KICAgIElzc3VlIGYpIHJlcXVpcmVzIGEg d2F5IHRvIGluZGljYXRlIHVzZSBvZiBjYXB0aW9uaW5nIGFuZCBvdGhlcg0KICAgIHNpdHVh dGlvbnMgd2hlcmUgdXNlIG9mIHNpbXVsdGFuZW91cyBsYW5ndWFnZXMgaW4gZGlmZmVyZW50 DQogICAgbW9kYWxpdGllcyBhcmUgbmVlZGVkOjxicj4NCiAgICA8YnI+DQogICAgMS4gUHJl ZmVyZW5jZSBmb3IgaGVhcmluZyBzcG9rZW4gbGFuZ3VhZ2UgYW5kIHNpbXVsdGFuZW91c2x5 IHJlYWQNCiAgICB3cml0dGVuIGxhbmd1YWdlIGluIHRleHQuICggY2FwdGlvbmluZykgLqCg IFRoZSB0aW1lIGlzIGFwcHJvYWNoaW5nDQogICAgd2hlbiB0aGlzIGNhbiBiZSBwcm92aWRl ZCBhdXRvbWF0aWNhbGx5LCBidXQgYWxzbyB0cmFkaXRpb25hbGx5IGJ5IGENCiAgICBtYW5u ZWQgc2VydmljZS48YnI+DQogICAgMi4gUHJlZmVyZW5jZSBmb3IgaGVhcmluZyBzcG9rZW4g bGFuZ3VhZ2UgYW5kIHNpbXVsdGFuZW91c2x5IHNlZWluZw0KICAgIHRoZSBzcGVha2VyIGlu IHZpZGVvLqCgIChsaXAtcmVhZGluZykuoCBFYXNpbHkgYW5kIG5hdHVyYWxseQ0KICAgIHBy b3ZpZGVkIG9uY2UgdGhlIG5lZWQgaSBrbm93bi48YnI+DQogICAgMy4gUHJlZmVyZW5jZSBm b3Igc2VlaW5nIHNpZ24gbGFuZ3VhZ2UgYW5kIHNpbXVsdGFuZW91c2x5IGhlYXINCiAgICBz cG9rZW4gbGFuZ3VhZ2UgaW4gYXVkaW8uoCAoIGZvciBtdWx0aXBsZSB1c2VycyBhdCB0aGUg dGVybWluYWwgKaCgoA0KICAgIE9uZSBvZiB0aGUgc3RyZWFtcyBpcyBwcm92aWRlZCBieSBh biBpbnRlcnByZXRlci48YnI+DQogICAgNC4gUHJlZmVyZW5jZSBmb3IgaGVhcmluZyBzcG9r ZW4gbGFuZ3VhZ2UgYW5kIHNpbXVsdGFuZW91c2x5IHZpZXcNCiAgICB3cml0dGVuIGxhbmd1 YWdlIGluIHZpZGVvLiAoY2FwdGlvbmluZyBpZiB3ZSBhY2NlcHQgdG8gc3BlY2lmeSB0ZXh0 DQogICAgYXMgb3ZlcmxheSBvbiB2aWRlbymgIDxicj4NCiAgICA8YnI+DQogICAgU29tZSBv ZiB0aGVzZSBjYW4gYmUgYWNjZXB0YWJsZSBhbHNvIGlmIGp1c3Qgb25lIG9mIHRoZQ0KICAg IGxhbmd1YWdlL21lZGlhIGNvbWJpbmF0aW9ucyBjYW4gYmUgcHJvdmlkZWQsIGJ1dCBpcyBt dWNoIG1vcmUNCiAgICBwcmVmZXJyZWQgaWYgYm90aCBjYW4gYmUgcHJvdmlkZWQgdG9nZXRo ZXIuIEluIG90aGVyIGNhc2VzIGl0IGlzDQogICAgZXNzZW50aWFsIHRvIGdldCBib3RoIHNp bXVsdGFuZW91c2x5LiBUaGVyZSBpcyBhIG5lZWQgdG8NCiAgICBkaWZmZXJlbnRpYXRlIGlu IHRoZSBpbmRpY2F0aW9uIHRoYXQgdGhpcyBwcmVmZXJlbmNlIGZvciBnZXR0aW5nIHRoZQ0K ICAgIGxhbmd1YWdlcyB0b2dldGhlciBpcyBwcmVmZXJyZWQuPGJyPg0KICAgIDxicj4NCiAg ICBBbHRlcm5hdGl2ZSBjb2RpbmcgcHJvcG9zYWxzOjxicj4NCiAgICAxLiBQcmVmZXJlbmNl IGJldHdlZW4gbGFuZ3VhZ2UvbW9kYWxpdHk8YnI+DQogICAgMS4xIEJhc2VkIG9uIGRyYWZ0 IC0wOCwgYWRkIHRoZSBjb2Rpbmcgb2YgYW4gYXN0ZXJpc2sgbGFzdCBpbiBhbg0KICAgIGF0 dHJpYnV0ZSB0byBtZWFuIGxvd2VyIHByZWZlcmVuY2UgZm9yIGEgbGFudWdhZ2UvbWVkaWEg Y29tYmluYXRpb24NCiAgICB0aGFuIHRoZSBvbmUocykgd2l0aG91dCBhbiBhc3Rlcmlzay4g PGJyPg0KICAgIDxicj4NCiAgICAxLjIuIENoYW5nZSB0byB0aGUgQWNjZXB0LUxhbmd1YWdl IHN5bnRheCBhbmQgbGV0IHRoZSBxLXZhbHVlcyBoYXZlDQogICAgc2NvcGUgb3ZlciB0aGUg d2hvbGUgU0RQLjxicj4NCiAgICA8YnI+DQogICAgMS4zLiBJbnRyb2R1Y2UgYSBuZXcgYT1t b2RhbGl0eSBhdHRyaWJ1dGUgb24gbWVkaWEgbGV2ZWwsIHdpdGgNCiAgICBwYXJhbWV0ZXJz OiAmbHQ7bW9kYWxpdHkmZ3Q7LCAmbHQ7ZGlyZWN0aW9uJmd0OywgJmx0O3ByZWZlcmVuY2Um Z3Q7DQogICAgPGJyPg0KICAgIDxicj4NCiAgICAyLiBQcmVmZXJlbmNlIGZvciBzaW11bHRh bmVvdXMgbGFuZ3VhZ2VzIHZzIGFsdGVybmF0aXZlIGxhbmd1YWdlczo8YnI+DQogICAgPGJy Pg0KICAgIDIuMS4gQmFzZWQgb24gZHJhZnQgLTA4LCBhZGQgYW5vdGhlciBub3RhdGlvbiB0 byB0aGUgdXNlIG9mIHRoZQ0KICAgIGFzdGVyaXNrLCBlLmcuIGFuIG9wdGlvbmFsIGNoYXJh Y3RlciB0byBiZSB1c2VkIHRvZ2V0aGVyIHdpdGggdGhlDQogICAgYXN0ZXJpc2sgdG8gbWFy ayBtZWRpYSB0aGF0IGFyZSB3YW50ZWQgdG9nZXRoZXIuICh1Z2x5KTxicj4NCiAgICCgPGJy Pg0KICAgIDIuMi4gVXNlIHRoZSBBY2NlcHQtTGFuZ3VhZ2Ugc3ludGF4IGFuZCBhZGQgdGhl IHVzYWdlIHJ1bGVzIHRoYXQNCiAgICBxLXZhbHVlcyB3aXRoIGxlc3MgdGhhbiAuMSBkaWZm ZXJlbmNlIG1lYW4gbGFuZ3VhZ2VzIHdpdGggYQ0KICAgIHByZWZlcmVuY2UgdG8gYmUgdXNl ZCB0b2dldGhlci4gSGlnaGVyIGRpZmZlcmVuY2VzIGluZGljYXRlIHRoYXQNCiAgICB0aGV5 IGFyZSBhbHRlcm5hdGl2ZXMuoCBUaGVyZWJ5IGl0IGlzIGJvdGggcG9zc2libGUgdG8gaW5k aWNhdGUNCiAgICBzaW11bHRhbmVpdHkgYW5kIHByZWZlcmVuY2UgaWYgdGhlIHNpbXVsdGFu ZWl0eSBjYW5ub3QgYmUgc2F0aXNmaWVkLjxicj4NCiAgICA8YnI+DQogICAgMi4zLiBBZGQg dG8gdGhlIG5ldyBhPW1vZGFsaXR5IGF0dHJpYnV0ZSBhIHRoaXJkLCBvcHRpb25hbCBwYXJh bWV0ZXINCiAgICBbc2ltdWx0YW5laXR5XaCgIHdpdGggdmFsdWUgYW55IHNpbmdsZSBsZXR0 ZXIsIGluZGljYXRpbmcgYQ0KICAgIHByZWZlcmVuY2UgZm9yIGhhdmluZyB0aGF0IG1vZGFs aXR5IHNpbXVsdGFuZW91c2x5IHdpdGggYW5vdGhlcg0KICAgIG1vZGFsaXR5IGluZGljYXRl ZCB3aXRoIHRoZSBzYW1lIHZhbHVlIGluIHRoZSBbc2ltdWx0YW5laXR5XQ0KICAgIHBhcmFt ZXRlci6goCBXaXRob3V0IHRoaXMgcGFyYW1ldGVyLCB0aGUgbW9kYWxpdGllcyBhcmUNCiAg ICBhbHRlcm5hdGl2ZXMuPGJyPg0KICAgIDxiPjxicj4NCiAgICA8L2I+PGI+U3RhdHVzOiBO b3Qgc29sdmVkLiBDb25jbHVzaW9uIG5lZWRlZCBvbiBob3cgdG8gaGFuZGxlIHRoZXNlDQog ICAgICBpc3N1ZXMgZSwgZiwgYW5kIGosoCBib3RoIHJlZ2FyZGluZyB3aGljaCBzb2x1dGlv biBhbmQgd2hhdA0KICAgICAgcHJvY2VkdXJlIHRvIHRha2UgdG8gYXBwbHkgaXQuPGJyPg0K ICAgICAgPGJyPg0KICAgIDwvYj48YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4N CiAgICA8YnI+DQogICAgPGJyPg0KICAgIDxiPlN1bW1hcnk6IFRoZXJlIGFyZSBpc3N1ZXMg bGVmdCB0byBoYW5kbGUgaW4gaXRlbXMgYSwgZSwgZiwgZywgaSwNCiAgICAgIGogYW5kIG4u PGJyPg0KICAgICAgPGJyPg0KICAgIDwvYj5SZWdhcmRzPGJyPg0KICAgIDxicj4NCiAgICBH dW5uYXI8YnI+DQogICAgPGI+PC9iPjxicj4NCiAgICA8ZGl2IGNsYXNzPSJtb3otY2l0ZS1w cmVmaXgiPkRlbiAyMDE3LTAyLTA2IGtsLiAxNjoyNywgc2tyZXYgVGhlDQogICAgICBJRVNH Ojxicj4NCiAgICA8L2Rpdj4NCiAgICA8YmxvY2txdW90ZQ0KY2l0ZT0ibWlkOjE0ODYzOTQ4 NzIxNy4xODg2NS4xMzYxMTE5MTg3Nzk0NzA5MDc5Ni5pZHRyYWNrZXJAaWV0ZmEuYW1zbC5j b20iDQogICAgICB0eXBlPSJjaXRlIj4NCiAgICAgIDxwcmUgd3JhcD0iIj4NClRoZSBJRVNH IGhhcyByZWNlaXZlZCBhIHJlcXVlc3QgZnJvbSB0aGUgU2VsZWN0aW9uIG9mIExhbmd1YWdl IGZvcg0KSW50ZXJuZXQgTWVkaWEgV0cgKHNsaW0pIHRvIGNvbnNpZGVyIHRoZSBmb2xsb3dp bmcgZG9jdW1lbnQ6DQotICdOZWdvdGlhdGluZyBIdW1hbiBMYW5ndWFnZSBpbiBSZWFsLVRp bWUgQ29tbXVuaWNhdGlvbnMnDQogICZsdDtkcmFmdC1pZXRmLXNsaW0tbmVnb3RpYXRpbmct aHVtYW4tbGFuZ3VhZ2UtMDYudHh0Jmd0OyBhcyBQcm9wb3NlZA0KU3RhbmRhcmQNCg0KVGhl IElFU0cgcGxhbnMgdG8gbWFrZSBhIGRlY2lzaW9uIGluIHRoZSBuZXh0IGZldyB3ZWVrcywg YW5kIHNvbGljaXRzDQpmaW5hbCBjb21tZW50cyBvbiB0aGlzIGFjdGlvbi4gUGxlYXNlIHNl bmQgc3Vic3RhbnRpdmUgY29tbWVudHMgdG8gdGhlDQo8YSBjbGFzcz0ibW96LXR4dC1saW5r LWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86aWV0ZkBpZXRmLm9yZyI+aWV0ZkBpZXRmLm9y ZzwvYT4gbWFpbGluZyBsaXN0cyBieSAyMDE3LTAyLTIwLiBFeGNlcHRpb25hbGx5LCBjb21t ZW50cyBtYXkgYmUNCnNlbnQgdG8gPGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRl ZCIgaHJlZj0ibWFpbHRvOmllc2dAaWV0Zi5vcmciPmllc2dAaWV0Zi5vcmc8L2E+IGluc3Rl YWQuIEluIGVpdGhlciBjYXNlLCBwbGVhc2UgcmV0YWluIHRoZQ0KYmVnaW5uaW5nIG9mIHRo ZSBTdWJqZWN0IGxpbmUgdG8gYWxsb3cgYXV0b21hdGVkIHNvcnRpbmcuDQoNCkFic3RyYWN0 DQoNCg0KICAgVXNlcnMgaGF2ZSB2YXJpb3VzIGh1bWFuIChuYXR1cmFsKSBsYW5ndWFnZSBu ZWVkcywgYWJpbGl0aWVzLCBhbmQNCiAgIHByZWZlcmVuY2VzIHJlZ2FyZGluZyBzcG9rZW4s IHdyaXR0ZW4sIGFuZCBzaWduZWQgbGFuZ3VhZ2VzLiAgV2hlbg0KICAgZXN0YWJsaXNoaW5n IGludGVyYWN0aXZlIGNvbW11bmljYXRpb24gKCJjYWxscyIpIHRoZXJlIG5lZWRzIHRvIGJl IGENCiAgIHdheSB0byBuZWdvdGlhdGUgKGNvbW11bmljYXRlIGFuZCBtYXRjaCkgdGhlIGNh bGxlcidzIGxhbmd1YWdlIGFuZA0KICAgbWVkaWEgbmVlZHMgd2l0aCB0aGUgY2FwYWJpbGl0 aWVzIG9mIHRoZSBjYWxsZWQgcGFydHkuICBUaGlzIGlzDQogICBlc3BlY2lhbGx5IGltcG9y dGFudCB3aXRoIGVtZXJnZW5jeSBjYWxscywgd2hlcmUgYSBjYWxsIGNhbiBiZQ0KICAgaGFu ZGxlZCBieSBhIGNhbGwgdGFrZXIgY2FwYWJsZSBvZiBjb21tdW5pY2F0aW5nIHdpdGggdGhl IHVzZXIsIG9yIGENCiAgIHRyYW5zbGF0b3Igb3IgcmVsYXkgb3BlcmF0b3IgY2FuIGJlIGJy aWRnZWQgaW50byB0aGUgY2FsbCBkdXJpbmcNCiAgIHNldHVwLCBidXQgdGhpcyBhcHBsaWVz IHRvIG5vbi1lbWVyZ2VuY3kgY2FsbHMgYXMgd2VsbCAoYXMgYW4NCiAgIGV4YW1wbGUsIHdo ZW4gY2FsbGluZyBhIGNvbXBhbnkgY2FsbCBjZW50ZXIpLg0KDQogICBUaGlzIGRvY3VtZW50 IGRlc2NyaWJlcyB0aGUgbmVlZCBhbmQgYSBzb2x1dGlvbiB1c2luZyBuZXcgU0RQIHN0cmVh bQ0KICAgYXR0cmlidXRlcy4NCg0KDQoNCg0KVGhlIGZpbGUgY2FuIGJlIG9idGFpbmVkIHZp YQ0KPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zbGltLW5lZ290aWF0aW5nLWh1bWFu LWxhbmd1YWdlLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1zbGltLW5lZ290aWF0aW5nLWh1bWFuLWxhbmd1YWdlLzwvYT4NCg0KSUVTRyBkaXNjdXNz aW9uIGNhbiBiZSB0cmFja2VkIHZpYQ0KPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4 dCIgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1z bGltLW5lZ290aWF0aW5nLWh1bWFuLWxhbmd1YWdlL2JhbGxvdC8iPmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2xpbS1uZWdvdGlhdGluZy1odW1hbi1s YW5ndWFnZS9iYWxsb3QvPC9hPg0KDQoNCk5vIElQUiBkZWNsYXJhdGlvbnMgaGF2ZSBiZWVu IHN1Ym1pdHRlZCBkaXJlY3RseSBvbiB0aGlzIEktRC4NCg0KDQpUaGUgZG9jdW1lbnQgY29u dGFpbnMgdGhlc2Ugbm9ybWF0aXZlIGRvd253YXJkIHJlZmVyZW5jZXMuDQpTZWUgUkZDIDM5 NjcgZm9yIGFkZGl0aW9uYWwgaW5mb3JtYXRpb246IA0KICAgIGRyYWZ0LXNhaW50YW5kcmUt c2lwLXhtcHAtY2hhdDogSW50ZXJ3b3JraW5nIGJldHdlZW4gdGhlIFNlc3Npb24gSW5pdGlh dGlvbiBQcm90b2NvbCAoU0lQKSBhbmQgdGhlIEV4dGVuc2libGUgTWVzc2FnaW5nIGFuZCBQ cmVzZW5jZSBQcm90b2NvbCAoWE1QUCk6IE9uZS10by1PbmUgVGV4dCBDaGF0IChOb25lIC0g KQ0KTm90ZSB0aGF0IHNvbWUgb2YgdGhlc2UgcmVmZXJlbmNlcyBtYXkgYWxyZWFkeSBiZSBs aXN0ZWQgaW4gdGhlIGFjY2VwdGFibGUgRG93bnJlZiBSZWdpc3RyeS4NCg0KDQo8L3ByZT4N CiAgICA8L2Jsb2NrcXVvdGU+DQogICAgPGJyPg0KICAgIDxwcmUgY2xhc3M9Im1vei1zaWdu YXR1cmUiIGNvbHM9IjcyIj4tLSANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpHdW5uYXIgSGVsbHN0cvZtDQpPbW5pdG9yDQo8YSBjbGFzcz0ibW96LXR4 dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86Z3VubmFyLmhlbGxzdHJvbUBvbW5p dG9yLnNlIj5ndW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iuc2U8L2E+DQorNDYgNzA4IDIwNCAy ODg8L3ByZT4NCiAgPC9ib2R5Pg0KPC9odG1sPg0K --------------545A701A794458AF2C6D2D77-- From nobody Mon Mar 6 18:47:45 2017 Return-Path: X-Original-To: slim@ietf.org Delivered-To: slim@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 801BB129A99; Mon, 6 Mar 2017 18:47:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Mahesh Jethanandani To: X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148885485450.15073.6095850267163523164.idtracker@ietfa.amsl.com> Date: Mon, 06 Mar 2017 18:47:34 -0800 Archived-At: Cc: slim@ietf.org, ietf@ietf.org, draft-ietf-slim-negotiating-human-language.all@ietf.org Subject: [Slim] Review of draft-ietf-slim-negotiating-human-language-08 X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 02:47:34 -0000 Reviewer: Mahesh Jethanandani Review result: Has Nits I have reviewed this document as part of the Operational directorate’s ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments. Document reviewed:  draft-ietf-slim-negotiating-human-language-08 Status: Ready with comments. Summary: This document adds new SDP media-level attributes so that when establishing interactive communication sessions ("calls"), it is possible to negotiate (communicate and match) the caller's language and media needs with the capabilities of the called party. The document is short and easy to read. And it seems to have considered many aspects of trying to negotiate a common human language or capability. This review looks at the document more from a operator or management perspective. Operational considerations: >From a operations perspective, there may be a need to troubleshoot the interface that sets up the negotiated human language. Identifying consistent methods of information that should be counted by both parties will go a long way in debugging a problem. For example, in this case, it would be helpful to start by collecting how many requests were made, how many found a language or medium in common and how many were rejected because a common match was not found. Management considerations: The old adage says, “Anything that can be configured, can also be misconfiguredâ€, unless that is somehow made less possible by providing default values, modes or parameters. This can be something that can be defined using a data model in YANG. I assume that the default behavior of receiving a SDP attribute that one does not support, results in a throw away of that particular attribute, and not the whole message, if combined with other attributes. Is this documented somewhere? If not, what does the deployment scenario look like, particularly with existing solutions? What is the impact on network operations if for example either the translator or relay agent fails? How would that impact the negotiation? Also, what is the test, both active and passive for the correct operation? Is there a counter being maintained for both correct and incorrect negotiation. Goes back to the question of what counters are being maintained. Such counters should include values that enable isolation of faults. For example, if negotiation fails, what are the more specific counters that isolate what within the negotiation failed? Fault Management: In addition to collection information on how the negotiation is working, it is important to be able to propagate both fault and health indicators to a management application. Such information needs to be documented. Accounting Management: Finally, it is always helpful to collect information on utilization from capacity, trend analysis, cost allocation, auditing and billing perspective. Idnits: A run of idnits came out clean. From nobody Tue Mar 7 02:17:54 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96A7F129421 for ; Tue, 7 Mar 2017 02:17:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4slN06VldLAU for ; Tue, 7 Mar 2017 02:17:49 -0800 (PST) Received: from bin-vsp-out-02.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54DDD12946E for ; Tue, 7 Mar 2017 02:17:49 -0800 (PST) X-Halon-ID: 4de0d9ec-031f-11e7-af93-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Tue, 7 Mar 2017 11:17:43 +0100 (CET) To: Mahesh Jethanandani , ops-dir@ietf.org References: <148885485450.15073.6095850267163523164.idtracker@ietfa.amsl.com> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <20633096-1dfa-1c01-9591-3c2fb66efa30@omnitor.se> Date: Tue, 7 Mar 2017 11:17:37 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <148885485450.15073.6095850267163523164.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: slim@ietf.org, ietf@ietf.org, draft-ietf-slim-negotiating-human-language.all@ietf.org Subject: Re: [Slim] Review of draft-ietf-slim-negotiating-human-language-08 X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 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 Mar 2017 10:17:52 -0000 Mahesh, Your review brings up interesting aspects. I can provide some initial responses, Den 2017-03-07 kl. 03:47, skrev Mahesh Jethanandani: > Reviewer: Mahesh Jethanandani > Review result: Has Nits > > I have reviewed this document as part of the Operational > directorate’s ongoing effort to review all IETF documents being > processed by the IESG. These comments were written with the intent of > improving the operational aspects of the IETF drafts. Comments that > are not addressed in last call may be > included in AD reviews during the IESG review. Document editors > and WG chairs should treat these comments just like any other last > call comments. > > Document reviewed: draft-ietf-slim-negotiating-human-language-08 > > Status: > > Ready with comments. > > Summary: > > This document adds new SDP media-level attributes so that when > establishing interactive communication sessions ("calls"), it is > possible to negotiate (communicate and match) the caller's language > and media needs with the capabilities of the called party. > > The document is short and easy to read. And it seems to have > considered many aspects of trying to negotiate a common human language > or capability. This review looks at the document more from a operator > or management perspective. > > Operational considerations: > > >From a operations perspective, there may be a need to troubleshoot the > interface that sets up the negotiated human language. Identifying > consistent methods of information that should be counted by both > parties will go a long way in debugging a problem. For example, in > this case, it would be helpful to start by collecting how many > requests were made, how many found a language or medium in common and > how many were rejected because a common match was not found. > > Management considerations: > > The old adage says, “Anything that can be configured, can also be > misconfiguredâ€, unless that is somehow made less possible by providing > default values, modes or parameters. This can be something that can be > defined using a data model in YANG. > > I assume that the default behavior of receiving a SDP attribute that > one does not support, results in a throw away of that particular > attribute, and not the whole message, if combined with other > attributes. Is this documented somewhere? If not, what does the > deployment scenario look like, particularly with existing solutions? In section 5 of RFC 4566 the SDP specification, it is said: "An SDP parser MUST ignore any attribute it doesn't understand." In a real world, the deployment will be gradual, so many times, either the caller UA or the callee UA will not understand these attributes. Some possible default actions are mentioned in the draft for cases when there are no settings or no support in either end, but the draft is not intended to provide exact solutions for the negotiation, but rather only provide a protocol for conveying indications sufficient for performing the negotiation. > > What is the impact on network operations if for example either the > translator or relay agent fails? How would that impact the > negotiation? The draft does not intend to dictate how and by what party a language/modality gap is detected, so that a translating agent or modality conversion relay service will be desired and invoked in the call. The intention is to make such detection and invocation possible, at least regarding relay services. The natural way of using the mechanism of the draft is that each party involved in the call setup will modify the hlang attributes to indicate the joint capabilities and preferences of the so far involved parties. If invocation of a party fails, its modification of the hlang attributes does not take place and the answer will then not likely contain a satisfying set of languages for the offering party. This may be a case when the paranthesis in this sentence in section 5.2 comes into play: "In an answer, 'hlang-send' is the language the answerer will send when using the media (which in most cases is one of the languages in the offer's 'hlang-recv'), and 'hlang-recv' is the language the answerer expects to receive in the media (which in most cases is one of the languages in the offer's 'hlang-send')." If the answering party was the one who intended to invoke the translation or relaying if needed, then it can also deny the call if that is indicated as a preference in the incoming call. These details belong to the negotiation mechanism that was not intended to be described in detail in the draft. > > Also, what is the test, both active and passive for the correct > operation? Is there a counter being maintained for both correct and > incorrect negotiation. Goes back to the question of what counters are > being maintained. Such counters should include values that enable > isolation of faults. For example, if negotiation fails, what are the > more specific counters that isolate what within the negotiation > failed? > > Fault Management: > > In addition to collection information on how the negotiation is > working, it is important to be able to propagate both fault and health > indicators to a management application. Such information needs to be > documented. > > Accounting Management: > > Finally, it is always helpful to collect information on utilization > from capacity, trend analysis, cost allocation, auditing and billing > perspective. Interesting aspects. Let us see what others say about what we can include at this stage and what should be brougth up in follow-up documents. /Gunnar > > Idnits: > > A run of idnits came out clean. > > > > _______________________________________________ > 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 Tue Mar 7 07:39:58 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B608312962B for ; Tue, 7 Mar 2017 06:22:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.91 X-Spam-Level: X-Spam-Status: No, score=-2.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gsmasso.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lqFZX7V5oX1 for ; Tue, 7 Mar 2017 06:21:44 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0085.outbound.protection.outlook.com [104.47.2.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0379A12949E for ; Tue, 7 Mar 2017 06:18:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=GSMASSO.onmicrosoft.com; s=selector1-gsma-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=J9DoCP1bJDlWYMV7Gm3VYTyJjmbq4Yy4ttcithp79Z8=; b=T8xowmD7gMV2Nixzj8jLes4vjiDhRBBr/BboLsDFjIp0GyF6RJb9iszxdkyYL64AO3AcWWlKelLVH4w6tlAfAA6ihNnPLMdEA/2MP6REcj2SRltF6VyZZ9O55CBxvl+vSZ8PXnxLkyKvECfzzrCkFbi1UNqtpPPDJSMnku/DoCs= Received: from HE1PR04MB3113.eurprd04.prod.outlook.com (10.171.196.31) by HE1PR04MB3113.eurprd04.prod.outlook.com (10.171.196.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Tue, 7 Mar 2017 14:18:06 +0000 Received: from HE1PR04MB3113.eurprd04.prod.outlook.com ([10.171.196.31]) by HE1PR04MB3113.eurprd04.prod.outlook.com ([10.171.196.31]) with mapi id 15.01.0947.020; Tue, 7 Mar 2017 14:18:06 +0000 From: Natasha Rooney To: Randall Gellens Thread-Topic: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-07.txt Thread-Index: AQHSkvuosMicw1+KUkOljenWkhIsJqGJdU6A Date: Tue, 7 Mar 2017 14:18:06 +0000 Message-ID: <52E633F6-FBBB-48FF-9759-6E566914CDE6@gsma.com> References: <148782279664.31054.8793649134696520241.idtracker@ietfa.amsl.com> <49fd730e-6e90-1a49-eae8-80f8b1285a76@omnitor.se> <83152ba7-c3fb-25d8-f97d-59c7840cad56@omnitor.se> <4b36f347-955e-e2b9-12f2-f426d47d3d33@omnitor.se> <7f844aaa-17ce-2ab7-0602-a999a40235de@omnitor.se> <825fa638-b223-d716-6a3c-238903a37b92@omnitor.se> <9084ad5c-a3d1-68e1-879b-af759c463fd1@omnitor.se> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) authentication-results: randy.pensive.org; dkim=none (message not signed) header.d=none; randy.pensive.org; dmarc=none action=none header.from=gsma.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [146.198.144.67] x-ms-office365-filtering-correlation-id: 2b937847-7a3d-44cd-b0ba-08d46564c63b x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:HE1PR04MB3113; x-microsoft-exchange-diagnostics: 1; HE1PR04MB3113; 7:wo8dprd9LYWdtEaylSKfGyE7H1T8A1rPbmjQvXgUePmoxLFicaxUxGZ3Zg+v6VmBqpecJXxFlnE0ukp5vG70j6ZeVtHuapach1e22igZJgyBuXFN9oY0GpojAcMHSCYrMbfRplaoVihy+fuYOJgAtEyDKArNP9IZH9kn4RwEtvqTqefesrUGBdli3SclGwrLG3HAt1CxhZiHlEYq2iKBWxPI1ZR7MzG/8AT4kzOoit8ao7Ly3GvS42YA+LVygau0ZIgQgOW6odDDv0UZ2zkZt0miBeULIyo72J2h8yBliAuZTKbQ4L5ieURZsvEmFAy1QhafhXDq/Vir1UwuFTcTwQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123558025)(20161123564025)(6042181)(6072148); SRVR:HE1PR04MB3113; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB3113; x-forefront-prvs: 0239D46DB6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(377454003)(377424004)(53754006)(24454002)(83716003)(68736007)(4326008)(6246003)(106116001)(106356001)(561944003)(38730400002)(8676002)(2950100002)(86362001)(2900100001)(110136004)(54906002)(236005)(82746002)(39060400002)(25786008)(6436002)(77096006)(6486002)(230783001)(53546006)(33656002)(5890100001)(6512007)(6506006)(229853002)(36756003)(50986999)(122556002)(54896002)(5660300001)(3280700002)(7736002)(66066001)(76176999)(99286003)(93886004)(57306001)(8936002)(53936002)(102836003)(6116002)(3846002)(2906002)(50226002)(189998001)(81166006)(3660700001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB3113; H:HE1PR04MB3113.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_52E633F6FBBB48FF97596E566914CDE6gsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Mar 2017 14:18:06.1299 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB3113 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: HE1PR04MB3113.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 146.198.144.67 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: HE1PR04MB3113.eurprd04.prod.outlook.com Archived-At: Cc: "slim@ietf.org" , "Phillips, Addison" , =?utf-8?B?R3VubmFyIEhlbGxzdHLDtm0=?= , Bernard Aboba Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-07.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 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 Mar 2017 14:22:03 -0000 --_000_52E633F6FBBB48FF97596E566914CDE6gsmacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJ4oCZdmUgYmVlbiBjYXRjaGluZyB1cCBvbiB0aGUgZGlzY3Vzc2lvbnMgYWZ0 ZXIgYSBsb25nIGJ1c2luZXNzIHRyaXAgLSBzbyBtYW55IGFwb2xvZ2llcyBmb3IgdGhlIGxhdGUg cmVzcG9uc2UuDQoNClRoZSBpZGVhIG9mIHdvcmtpbmcgb24gR3VubmFy4oCZcyBzdWdnZXN0aW9u cyB3aXRoaW4gYSBzZXBhcmF0ZSBkcmFmdCBzZWVtcyBsaWtlIGEgZ29vZCBpZGVhOyBpdCBkb2Vz buKAmXQgZGVsYXkgdGhlIGN1cnJlbnQgZHJhZnTigJlzIHByb2dyZXNzIG5vciBkb2VzIGl0IGln bm9yZSBhIGdvb2QgcHJvcG9zYWwuIEl0IHNlZW1zIHBlb3BsZSBhcmUgb2sgd2l0aCB0aGlzIGRl Y2lzaW9uLCBzbyBsZXTigJlzIGRvIHRoYXQuDQoNCkd1bm5hciAtIGlmIHlvdSB3YW50IHRvIG1h a2UgYSBzdGFydCBvbiB0aGlzIHRoYXQgd291bGQgYmUgZmFiOyBSYW5kYWxsIGhhcyBvZmZlcmVk IHN1cHBvcnQgZm9yIHRoaXMgc28gd2UgY2FuIHJlbHkgb24gaGltIGZvciB0ZXh0IGFuZCByZXZp ZXcuDQoNCk5hdGFzaGENCg0KTmF0YXNoYSBSb29uZXkgfCBJbnRlcm5ldCBFbmdpbmVlcmluZyBE aXJlY3RvciB8IEludGVybmV0IGFuZCBXZWIgVGVhbSB8IFRlY2hub2xvZ3kgfCBHU01BIHwgbnJv b25leUBnc21hLmNvbTxtYWlsdG86bnJvb25leUBnc21hLmNvbT4gfCArNDQgKDApIDc3MzAgMjE5 IDc2NSB8IEB0aGlzTmF0YXNoYSB8IFNreXBlOiBucm9vbmV5QGdzbS5vcmc8bWFpbHRvOm5yb29u ZXlAZ3NtLm9yZz4NCg0KT24gMiBNYXIgMjAxNywgYXQgMDI6MjEsIFJhbmRhbGwgR2VsbGVucyA8 cmcraWV0ZkByYW5keS5wZW5zaXZlLm9yZzxtYWlsdG86cmcraWV0ZkByYW5keS5wZW5zaXZlLm9y Zz4+IHdyb3RlOg0KDQpIaSBHdW5uYXIsDQoNCkF0IDExOjA2IFBNICswMTAwIDMvMS8xNywgR3Vu bmFyIEhlbGxzdHLDtm0gd3JvdGU6DQoNCkRlbiAyMDE3LTAzLTAxIGtsLiAxODo0Nywgc2tyZXYg UmFuZGFsbCBHZWxsZW5zOg0KQXQgODoyNiBBTSArMDEwMCAzLzEvMTcsIEd1bm5hciBIZWxsc3Ry w7ZtIHdyb3RlOg0KDQogSGkgUmFuZGFsbCwNCg0KIERlbiAyMDE3LTAzLTAxIGtsLiAwMjowOCwg c2tyZXYgUmFuZGFsbCBHZWxsZW5zOg0KDQogSGkgR3VubmFyLA0KDQogSSdtIHN0YXJ0aW5nIGEg bmV3IG1lc3NhZ2UgdG8gY3V0IG91dCB0aGUgaHVnZSBhbW91bnQgb2YgcXVvdGluZy4NCg0KIFlv dXIgcHJvcG9zYWwgaXMgdGhhdCB0ZXh0IGJlIGFkZGVkIHRoYXQgYWR2aXNlcyB0aGUgY2FsbGlu ZyBjbGllbnQgdG8gcGxhY2UgYW4gYXN0ZXJpc2sgb24gdGhlIGxlYXN0LXByZWZlcnJlZCBsYW5n dWFnZS9tZWRpYSwgYW5kIGFkdmlzZXMgdGhlIGFuc3dlcmluZyBjbGllbnQgdG8gaW5kaWNhdGUg dG8gdGhlIGFuc3dlcmluZyBodW1hbiB3aGljaCBsYW5ndWFnZS9tZWRpYSBpcyBub3QgdGhlIGxl YXN0IHByZWZlcnJlZCAoZGlkIG5vdCBoYXZlIGFuIGFzdGVyaXNrIGluIHRoZSBvZmZlciksIGlz IHRoYXQgYWNjdXJhdGU/DQoNCiBZZXMsIHdpdGggc2xpZ2h0IHJld29yZGluZyB0bzoNCiAidGV4 dCB0aGF0IGFkdmlzZXMgdGhlIG9mZmVyaW5nIGNsaWVudCB0byBwbGFjZSBhbiBhc3RlcmlzayBv biB0aGUgbGVhc3QtcHJlZmVycmVkIGxhbmd1YWdlL21lZGlhIGluZGljYXRpb25zLCBhbmQgYWR2 aXNlcyB0aGUgYW5zd2VyaW5nIGNsaWVudCB0byBpbmRpY2F0ZSB0byB0aGUgYW5zd2VyaW5nIGh1 bWFuIHdoaWNoIGxhbmd1YWdlL21lZGlhIGFyZSBub3QgdGhlIGxlYXN0IHByZWZlcnJlZCAoZGlk IG5vdCBoYXZlIGFuIGFzdGVyaXNrIGluIHRoZSBvZmZlcikiDQoNCiBUaGUgaW5jbHVzaW9uIG9m IHRoZSAiaW5kaWNhdGlvbnMiIGlzIGp1c3QgdG8gYXNzdXJlIHRoYXQgaXQgaXMgY2xlYXIgdGhh dCBpdCBkb2VzIG5vdCBuZWVkIHRvIGJlIGp1c3Qgb25lIGluZGljYXRpb24gdGhhdCBnZXRzIHRo ZSBhc3RlcmlzayAuDQogVGhlIGxhc3QgcGFydCBzb3VuZHMgYXdrd2FyZCwgYnV0IG1hdGNoZXMg dGVjaG5pY2FsbHkgd2hhdCB0aGUgbGFjayBvZiBhbiBhc3RlcmlzayBtZWFucy4gSSBpbmhlcml0 ZWQgdGhlIGludmVydGVkIGxvZ2ljIGZvciB0aGUgYXN0ZXJpc2sgZnJvbSBpdHMgYWxyZWFkeSBk ZWZpbmVkIG5vbi1kZW5pYWwgbWVhbmluZy4NCiBJZiB5b3UgYXJlIGNvbnNpZGVyaW5nIHdvcmRp bmcgZm9yIHRoZSBkcmFmdCwgSSBzdWdnZXN0IHRoYXQgeW91IHN0cmFpZ2h0ZW4gdGhlIGxvZ2lj IHRvIHNheSAid2hpY2ggbGFuZ3VhZ2UvbWVkaWEgYXJlIG1vc3QgcHJlZmVycmVkIChkaWQgbm90 IGhhdmUgYW4gYXN0ZXJpc2sgaW4gdGhlIG9mZmVyKSINCg0KIEl0IGRvZXMgYWxzbyBub3QgbmVl ZCB0byBiZSBhbiAiYW5zd2VyaW5nIGh1bWFuIiB0aGF0IGdldHMgdGhpcyBpbmRpY2F0aW9uIGFu ZCBtYWtlcyB1c2Ugb2YgaXQgZm9yIGd1aWRhbmNlIG9uIGhvdyB0byBhbnN3ZXIgdGhlIGNhbGwu IEl0IGNhbiBqdXN0IGFzIHdlbGwgYmUgZS5nLiBhIG11bHRpLW1vZGFsIGFuc3dlcmluZyBtYWNo aW5lIG9yIHNvbWUgb3RoZXIgYXBwbGljYXRpb24gaW50ZXJhY3Rpbmcgd2l0aCBodW1hbiBsYW5n dWFnZS4gSSBhbSBub3Qgc3VyZSBpZiAiYW5zd2VyaW5nIHBhcnR5IiBpcyBtb3JlIGFwcHJvcHJp YXRlIGFuZCBjYW4gYmUgY29uc2lkZXJlZCBpbmNsdWRpbmcgc3VjaCBhdXRvbWF0YS4NCg0KSGkg R3VubmFyLA0KDQpUaGFua3MgZm9yIGNsYXJpZnlpbmcsIEkgdGhpbmsgSSB1bmRlcnN0YW5kIHlv dXIgcHJvcG9zYWwgaW4gZGV0YWlsIG5vdy4gIEFmdGVyIHRoaW5raW5nIGl0IG92ZXIsIEkgc3Rp bGwgdGhpbmsgdGhpcyB3b3VsZCBiZSBiZXR0ZXIgZG9uZSBpbiBhIG5ldyBkcmFmdCwgYmVjYXVz ZSAoYSkgaXQgaXMgYWR2aWNlIG9uIGEgd2F5IG9mIHVzaW5nIHRoZSBtZWNoYW5pc20gdG8gY29u dmV5IGFkZGl0aW9uYWwgaW5mb3JtYXRpb247IChiKSBpdCB3b3VsZCBiZSBnb29kIGZvciB0aGUg Z3JvdXAgdG8gZGlzY3VzcyB0aGUgcHJvcG9zYWwgYW5kIHdvcmsgdGhyb3VnaCB2YXJpb3VzIGNh c2VzIChlLmcuLCB3aGF0IGlmIHRoZSBvZmZlcmluZyBjbGllbnQgaXMgbm90IGdvaW5nIHRvIGlu Y2x1ZGUgYW4gYXN0ZXJpc2ssIHdoYXQgaWYgdGhlcmUgaXMgbW9yZSB0aGFuIG9uZSBtb3N0LXBy ZWZlcnJlZCBsYW5ndWFnZSk7IGFuZCAoYykgaXQgd291bGQgYmUgZ29vZCBmb3IgdGhlIGdyb3Vw IHRvIGRlY2lkZSBpZiB0aGlzIG1lZXRzIHlvdXIgbmVlZC4NClJhbmRhbGwsDQpHb29kIHRoYXQg eW91IHVuZGVyc3RhbmQgaXQgbm93Lg0KSSByZWFsaXplIHRoYXQgdGhpcyBraW5kIG9mIGFkZGVk IHJ1bGVzIGZvciBhbiBhbHJlYWR5IGV4aXN0aW5nIHBhcmFtZXRlciBjb3VsZCBiZSBzcGVjaWZp ZWQgaW4gYW4gYWRkaXRpb25hbCBkcmFmdC4gRXNwZWNpYWxseSBzaW5jZSBpdCBoYXMgbm8gaW1w YWN0IG9uIHRoZSBjdXJyZW50IG1lYW5pbmcgb2YgdGhlIGFzdGVyaXNrLg0KSSBzdGlsbCB0aGlu ayBpdCBpcyBiZXN0IHRvIGFkZCB0aGUgZmV3IHdvcmRzIG5lZWRlZCBub3cuIFRoZSBwcmVmZXJl bmNlIGluZGljYXRpb24gaXMgc28gc2V2ZXJlbHkgdW5iYWxhbmNlZCB3aXRob3V0IGl0LCBpbiB0 aGF0IG9ubHkgcHJlZmVyZW5jZSBiZXR3ZWVuIGxhbmd1YWdlcyBpbiB0aGUgc2FtZSBtb2RhbGl0 eSBjYW4gYmUgc3BlY2lmaWVkLiBJIGFtIGFmcmFpZCB0aGF0IGl0IGNhbiBiZSBzZWVuIGFzIGEg ZGlzY3JpbWluYXRpb24gYWdhaW5zdCB0aG9zZSB3aG8gd291bGQgbmVlZCB0byBzcGVjaWZ5IHBy ZWZlcmVuY2UgYmV0d2VlbiBkaWZmZXJlbnQgbW9kYWxpdGllcyBpbiBvcmRlciB0byB0Z2V0IGVx dWFsIG9wcG9ydHVuaXRpZXMgdG8gZ2V0IHNtb290aGx5IHBlcmZvcm1lZCBjYWxscyB0aHJvdWdo LCBidXQgY2Fubm90Lg0KDQpZb3UgYXJlIHJpZ2h0IHRoYXQgdGhlcmUgYXJlIHNpdHVhdGlvbnMg dGhhdCB3aWxsIG5vdCBiZSBleHBsYWluZWQgaWYgd2UgYWNjZXB0IG15IGxpdHRsZSBleHRyYSBz ZW50ZW5jZSBvciBzb21ldGhpbmcgc2ltaWxhci4NClRoYXQgaXMgdHJ1ZSBhbHNvIGZvciB0aGUg Y3VycmVudGx5IHNwZWNpZmllZCBpbmRpY2F0aW9ucy4gV2UgaGF2ZSBzYWlkIHRoYXQgd2UgbmVh cmx5IG9ubHkgc3BlY2lmeSB0aGUgaW5kaWNhdGlvbnMgYW5kIG5vdCBob3cgdGhlIG5lZ290aWF0 aW9uIHNoYWxsIGJlIHBlcmZvcm1lZC4gSXQgY2FuIGJlIGEgdG9waWMgZm9yIGEgQkNQIHRvIGFk dmljZSBvbiBob3cgdGhlIG5lZ290aWF0aW9uIGNvdWxkIGJlIHBlcmZvcm1lZCBib3RoIHdpdGgg dGhlIGN1cnJlbnRseSBzcGVjaWZpZWQgbGFuZ3VhZ2UgYW5kIGluLW1lZGlhIHByZWZlcmVuY2Vz IGFuZCB3aXRoIHRoZSBhZGRpdGlvbmFsIHByZWZlcmVuY2UgYmV0d2VlbiBtZWRpYS4gV2UgY291 bGQgZGlzY3VzcyBlLmcuIHRoZSBjYXNlIHdoZW4gdHdvIHNhbWUgc3Bva2VuIGxhbmd1YWdlcyBh cmUgc3BlY2lmaWVkIGJ1dCB3aXRoIHRoZSBvcHBvc2l0ZSBwcmVmZXJlbmNlIG9yZGVyIGJ5IHRo ZSBvZmZlcm9yIGFuZCBhbnN3ZXJpbmcgcGFydHkuIEEgZGVjaXNpb24gbXVzdCBiZSB0YWtlbiwg YmVjYXVzZSB0aGUgcHJvdG9jb2wgc2F5cyB0aGF0IG9seSBvbmUgbGFuZ3VhZ2UgcGVyIG1lZGlh IGFuZCBkaXJlY3Rpb24gbWF5IGJlIGluZGljYXRlZCBpbiB0aGUgYW5zd2VyLCBhbmQgYWxzbyB0 aGF0IHRoZSBhbnN3ZXJpbmcgaW5zdGFuY2UgbmVlZCB0byBiZWNvbWUgYXdhcmUgb2Ygd2hpY2gg bGFuZ3VhZ2UgaXQgc2hhbGwgcHJvZHVjZS4NCkkgZG8gbm90IHNheSB0aGF0IHdlIG5lZWQgdG8g cmVzb2x2ZSB0aGlzIGNhc2UuIEl0IGNhbiBiZSBkaXNjdXNzZWQgaW4gYSBCQ1AsIGFuZCBpbmRp Y2F0ZWQgdGhhdCBhZGRpdGlvbmFsIHBvbGljeSBtYXkgYmUgYXBwbGllZCBmb3Igc29sdmluZyB0 aGF0IGtpbmQgb2YgdW5kZWZpbmVkIGNhc2VzLg0KDQpTaW1pbGFyaWx5LCB0aGVyZSB3aWxsIGJl IHNpdHVhdGlvbnMgd2l0aCB0aGUgYWRkaXRpb25hbCB1c2Ugb2YgdGhlIGFzdGVyaXNrIHRoYXQg d2lsbCBiZSBnb29kIHRvIHByb3ZpZGUgZXh0cmEgaW5mb3JtYXRpb24gZm9yIGluIGEgQkNQLiBU aGUgcHJlZmVyZW5jZSBpbmRpY2F0aW9uIGlzIHZlcnkgcm91Z2gsIHdpdGggb25seSB0d28gbGV2 ZWxzLiBTbyB0aGVyZSB3aWwgb2YgY291cnNlIGJlIHNpdHVhdGlvbnMgd2hlbiB0aGUgdXNlcnMg d2lsbCB3b25kZXIgaG93IHRvIHNldCB0aGVpciBwcm9maWxlLCBhbmQgY2FzZXMgd2hlbiB0aGUg bmVnb3RpYXRpb24gd2lsbCBiZSBoYXJkIHRvIGFzc2lnbiBhIHdlbGwgbW90aXZhdGVkIHJlc3Vs dC4gQnV0IHdlIGhhdmUgc2FpZCB0aGF0IHdlIHdhbnQgdG8gaGF2ZSB0aGUgc3BlY2lmaWNhdGlv biBvbiB0aGlzIHJvdWdoIGxldmVsLg0KDQpUaGUgdHdvIGNhc2VzIHRoYXQgeW91IGJyaW5nIHVw IGNhbiBoYXZlIHRoaXMgdHJlYXRtZW50Og0KDQoxLiBJZiB0aGUgY2FsbGluZyB1c2VyIHdhbnQg dG8gZ2V0IHRoZSBjYWxsIGRlbmllZCBpZiBubyBsYW5ndWFnZXMgbWF0Y2gsIHRoZW4gdGhlIHVz ZXIgbXVzdCBtYWtlIGEgZGVjaXNpb24gaWYgdGhhdCBwcmVmZXJlbmNlIGlzIG1vcmUgaW1wb3J0 YW50IHRvIHNwZWNpZnkgdGhhbiB0aGUgcHJlZmVyZW5jZSBiZXR3ZWVuIG1vZGFsaXRpZXMuIElu IG9yZGVyIHRvIGtlZXAgY29tcGxleGl0eSBsb3csIEkgZG8gbm90IHRoaW5rIHRoYXQgd2Ugc2hv dWxkIHNwZWNpZnkgaG93IHRvIGNvZGUgYm90aCBwcmVmZXJlbmNlcy4NCg0KMi4gSWYgdGhlcmUg YXJlIG1vcmUgdGhhbiBvbmUgbW9zdC1wcmVmZXJyZWQgbGFuZ3VhZ2UuIEkgdW5kZXJzdGFuZCB0 aGlzIGFzIGZvciBleGFtcGxlIGEgdXNlciBpcyBlcXVhbGx5IGhhcHB5IHRvIHVzZSBGcmVuY2gg c2lnbiBsYW5ndWFnZSBhcyBzcG9rZW4gRnJlbmNoLCBhbmQgY2FuIGFsc28sIGJ1dCBvbiBsb3dl ciBwcmVmZXJlbmNlIGxldmVsIHdyaXRlIEZyZW5jaCB0ZXh0LiBUaGF0IHdvdWxkIGJlIGluZGlj YXRlZCBieSBhbiBhc3RlcmlzayBvbiB0aGUgRnJlbmNoIHRleHQsIGFuZCB0aGUgYW5zd2VyaW5n IHBhcnR5IGhhdmluZyBhbGwgdGhlc2UgdGhyZWUgY2FwYWJpbGl0aWVzIG1heSBvbWl0IHRoZSBG cmVuY2ggdGV4dCBmcm9tIHRoZSBhbnN3ZXIgYnV0IGtlZXAgdGhlIG90aGVycy4gVGhlbiB0aGUg YW5zd2VyaW5nIHVzZXIgc2VsZWN0IG9uZSBvZiB0aGUgc3Bva2VuIEZyZW5jaCBhbmQgRnJlbmNo IFNpZ24gTGFuZ3VhZ2UgZm9yIGl0cyBzdGFydCBvZiB0aGUgY2FsbCwga25vd2luZyB0aGF0IHRo ZSBjYWxsZXIgd2lsbCBiZSBhcHByb3hpbWF0ZWx5IGVxdWFsbHkgaGFwcHkgd2l0aCB0aGUgY2Fs bCBpbiBib3RoIHRoZXNlIGNhc2VzLiAgIFdhcyB0aGF0IHRoZSBjYXNlIHlvdSB0aG91Z2h0IGFi b3V0IGZvciB0aGUgc2Vjb25kIGNhc2U/DQoNCkkgdW5kZXJzdGFuZCB0aGF0IHlvdSB3YW50ZWQg dG8gY2hlY2sgbW9yZSB0aGFuIHRoZXNlIHR3byBjYXNlcyBhbmQgZGlzY3VzcyB0aGVtIHdpdGgg dGhlIFdHLCBzbyB0aGUgYWJvdmUgaXMganVzdCBhIHN0YXJ0LiBXZSBjYW4gZG8gbW9yZSBjYXNl cyBpZiB5b3Ugd2FudCwgYnV0IEkgZG8gbm90IHRoaW5rIHdlIG5lZWQgYW55IGxlbmd0aHkgZGlz Y3Vzc2lvbiB0aGF0IHdvdWxkIGRlbGF5IHRoZSBjdXJyZW50IGRyYWZ0Lg0KDQoNCg0KQSBuZXcg ZHJhZnQsIGVzcGVjaWFsbHkgb25lIHRoYXQgd2lsbCBiZSBlaXRoZXIgSW5mb3JtYXRpb25hbCBv ciBCQ1AsIGNhbiBiZSBkb25lIGZhaXJseSBxdWlja2x5LiBJdCBjb3VsZCBiZSBxdWl0ZSBzaG9y dCwgcGVyaGFwcyBvbmx5IGEgcGFnZSBvciB0d28gb2YgcmVhbCB0ZXh0IHBsdXMgdGhlIGJvaWxl cnBsYXRlIHRleHQuICBJIGFtIGhhcHB5IHRvIGhlbHAgd2l0aCBpdC4NCg0KSSBzZWUgeW91ciBw b2ludCwgaG93ZXZlciwgbXkgdmlldyBpcyB0aGF0IHRoaXMgaXMgYmVzdCBjb3ZlcmVkIGluIGEg c2VwYXJhdGUgZHJhZnQuICBBcyBJIHNhaWQgYWJvdmUsIHRoZSBkcmFmdCBjYW4gYmUgY29tcGxl dGVkIHZlcnkgcXVpY2tseSBpZiBpdCBpcyBJbmZvcm1hdGlvbmFsIChvciBldmVuIEJDUCksIGNs ZWFyIGFuZCBub3QgY29udHJvdmVyc2lhbC4gIEkgYW0gaGFwcHkgdG8gaGVscC4NCg0KLS0NClJh bmRhbGwgR2VsbGVucw0KT3BpbmlvbnMgYXJlIHBlcnNvbmFsOyAgICBmYWN0cyBhcmUgc3VzcGVj dDsgICAgSSBzcGVhayBmb3IgbXlzZWxmIG9ubHkNCi0tLS0tLS0tLS0tLS0tIFJhbmRvbWx5IHNl bGVjdGVkIHRhZzogLS0tLS0tLS0tLS0tLS0tDQogIFRoZSBoaWdobGlnaHQgb2YgdGhlIGFubnVh bCBDb21wdXRlciBCb3dsIG9jY3VycmVkIHdoZW4gQmlsbCBHYXRlcywNCndobyB3YXMgYSBqdWRn ZSwgcG9zZWQgdGhlIGZvbGxvd2luZyBxdWVzdGlvbiB0byB0aGUgY29udGVzdGFudHM6DQogICJX aGF0IGNvbnRlc3QsIGhlbGQgdmlhIFVzZW5ldCwgaXMgZGVkaWNhdGVkIHRvIGV4YW1wbGVzIG9m IHdlaXJkLA0Kb2JzY3VyZSwgYml6YXJyZSwgYW5kIHJlYWxseSBiYWQgcHJvZ3JhbW1pbmc/Ig0K ICBBZnRlciBhIG1vbWVudCBvZiBzaWxlbmNlLCBKZWFuLUxvdWlzIEdhc3NlZSAoZXgtaG9uY2hv IGF0IEFwcGxlKQ0KaGl0IGhpcyBidXp6ZXIgYW5kIGFuc3dlcmVkICJXaW5kb3dzLiINCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLVJlY291bnRlZCBieSBBZGFtIEMu IEVuZ3N0DQoNCg0KVGhpcyBlbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGFyZSBpbnRlbmRlZCBm b3IgdGhlIGFib3ZlIG5hbWVkIG9ubHkgYW5kIG1heSBiZSBjb25maWRlbnRpYWwuIElmIHRoZXkg aGF2ZSBjb21lIHRvIHlvdSBpbiBlcnJvciB5b3UgbXVzdCB0YWtlIG5vIGFjdGlvbiBiYXNlZCBv biB0aGVtLCBub3IgbXVzdCB5b3UgY29weSBvciBzaG93IHRoZW0gdG8gYW55b25lOyBwbGVhc2Ug cmVwbHkgdG8gdGhpcyBlbWFpbCBvciBjYWxsICs0NCAyMDcgMzU2IDA2MDAgYW5kIGhpZ2hsaWdo dCB0aGUgZXJyb3IuDQo= --_000_52E633F6FBBB48FF97596E566914CDE6gsmacom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0id29yZC13cmFw OiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVh azogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkhpIGFsbCwNCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPknigJl2ZSBiZWVuIGNhdGNoaW5n IHVwIG9uIHRoZSBkaXNjdXNzaW9ucyBhZnRlciBhIGxvbmcgYnVzaW5lc3MgdHJpcCAtIHNvIG1h bnkgYXBvbG9naWVzIGZvciB0aGUgbGF0ZSByZXNwb25zZS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoZSBpZGVhIG9mIHdvcmtpbmcg b24gR3VubmFy4oCZcyBzdWdnZXN0aW9ucyB3aXRoaW4gYSBzZXBhcmF0ZSBkcmFmdCBzZWVtcyBs aWtlIGEgZ29vZCBpZGVhOyBpdCBkb2VzbuKAmXQgZGVsYXkgdGhlIGN1cnJlbnQgZHJhZnTigJlz IHByb2dyZXNzIG5vciBkb2VzIGl0IGlnbm9yZSBhIGdvb2QgcHJvcG9zYWwuIEl0IHNlZW1zIHBl b3BsZSBhcmUgb2sgd2l0aCB0aGlzIGRlY2lzaW9uLCBzbyBsZXTigJlzIGRvIHRoYXQuPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5HdW5u YXIgLSBpZiB5b3Ugd2FudCB0byBtYWtlIGEgc3RhcnQgb24gdGhpcyB0aGF0IHdvdWxkIGJlIGZh YjsgUmFuZGFsbCBoYXMgb2ZmZXJlZCBzdXBwb3J0IGZvciB0aGlzIHNvIHdlIGNhbiByZWx5IG9u IGhpbSBmb3IgdGV4dCBhbmQgcmV2aWV3LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+TmF0YXNoYSZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6 IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KTmF0YXNoYSBSb29uZXkgfCBJbnRlcm5ldCBFbmdpbmVlcmluZyZuYnNwO0RpcmVj dG9yIHwgSW50ZXJuZXQgYW5kIFdlYiBUZWFtIHwmbmJzcDtUZWNobm9sb2d5IHwgR1NNQSB8Jm5i c3A7PGEgaHJlZj0ibWFpbHRvOm5yb29uZXlAZ3NtYS5jb20iIGNsYXNzPSIiPm5yb29uZXlAZ3Nt YS5jb208L2E+Jm5ic3A7fCAmIzQzOzQ0ICgwKSA3NzMwIDIxOSZuYnNwOzc2NSB8IEB0aGlzTmF0 YXNoYSB8IFNreXBlOiZuYnNwOzxhIGhyZWY9Im1haWx0bzpucm9vbmV5QGdzbS5vcmciIGNsYXNz PSIiPm5yb29uZXlAZ3NtLm9yZzwvYT48L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj5PbiAyIE1hciAyMDE3LCBhdCAwMjoyMSwgUmFuZGFsbCBHZWxsZW5zICZsdDs8YSBocmVm PSJtYWlsdG86cmcmIzQzO2lldGZAcmFuZHkucGVuc2l2ZS5vcmciIGNsYXNzPSIiPnJnJiM0Mztp ZXRmQHJhbmR5LnBlbnNpdmUub3JnPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFw cGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ SGkgR3VubmFyLDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkF0IDExOjA2IFBNICYjNDM7 MDEwMCAzLzEvMTcsIEd1bm5hciBIZWxsc3Ryw7ZtIHdyb3RlOjxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPkRlbiAyMDE3LTAzLTAx IGtsLiAxODo0Nywgc2tyZXYgUmFuZGFsbCBHZWxsZW5zOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPkF0IDg6MjYgQU0gJiM0MzswMTAwIDMvMS8xNywgR3Vu bmFyIEhlbGxzdHLDtm0gd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+Jm5ic3A7SGkgUmFuZGFsbCw8YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQombmJzcDtEZW4gMjAxNy0wMy0wMSBrbC4gMDI6MDgsIHNrcmV2IFJh bmRhbGwgR2VsbGVuczo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIiBjbGFzcz0iIj4mbmJzcDtIaSBHdW5uYXIsPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KJm5ic3A7SSdtIHN0YXJ0aW5nIGEgbmV3IG1lc3NhZ2UgdG8gY3V0IG91dCB0aGUg aHVnZSBhbW91bnQgb2YgcXVvdGluZy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJz cDtZb3VyIHByb3Bvc2FsIGlzIHRoYXQgdGV4dCBiZSBhZGRlZCB0aGF0IGFkdmlzZXMgdGhlIGNh bGxpbmcgY2xpZW50IHRvIHBsYWNlIGFuIGFzdGVyaXNrIG9uIHRoZSBsZWFzdC1wcmVmZXJyZWQg bGFuZ3VhZ2UvbWVkaWEsIGFuZCBhZHZpc2VzIHRoZSBhbnN3ZXJpbmcgY2xpZW50IHRvIGluZGlj YXRlIHRvIHRoZSBhbnN3ZXJpbmcgaHVtYW4gd2hpY2ggbGFuZ3VhZ2UvbWVkaWEgaXMgbm90IHRo ZSBsZWFzdCBwcmVmZXJyZWQgKGRpZCBub3QgaGF2ZQ0KIGFuIGFzdGVyaXNrIGluIHRoZSBvZmZl ciksIGlzIHRoYXQgYWNjdXJhdGU/PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9ibG9j a3F1b3RlPg0KJm5ic3A7WWVzLCB3aXRoIHNsaWdodCByZXdvcmRpbmcgdG86PGJyIGNsYXNzPSIi Pg0KJm5ic3A7JnF1b3Q7dGV4dCB0aGF0IGFkdmlzZXMgdGhlIG9mZmVyaW5nIGNsaWVudCB0byBw bGFjZSBhbiBhc3RlcmlzayBvbiB0aGUgbGVhc3QtcHJlZmVycmVkIGxhbmd1YWdlL21lZGlhIGlu ZGljYXRpb25zLCBhbmQgYWR2aXNlcyB0aGUgYW5zd2VyaW5nIGNsaWVudCB0byBpbmRpY2F0ZSB0 byB0aGUgYW5zd2VyaW5nIGh1bWFuIHdoaWNoIGxhbmd1YWdlL21lZGlhIGFyZSBub3QgdGhlIGxl YXN0IHByZWZlcnJlZCAoZGlkIG5vdCBoYXZlIGFuIGFzdGVyaXNrIGluDQogdGhlIG9mZmVyKSZx dW90OzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwO1RoZSBpbmNsdXNpb24gb2Yg dGhlICZxdW90O2luZGljYXRpb25zJnF1b3Q7IGlzIGp1c3QgdG8gYXNzdXJlIHRoYXQgaXQgaXMg Y2xlYXIgdGhhdCBpdCBkb2VzIG5vdCBuZWVkIHRvIGJlIGp1c3Qgb25lIGluZGljYXRpb24gdGhh dCBnZXRzIHRoZSBhc3RlcmlzayAuPGJyIGNsYXNzPSIiPg0KJm5ic3A7VGhlIGxhc3QgcGFydCBz b3VuZHMgYXdrd2FyZCwgYnV0IG1hdGNoZXMgdGVjaG5pY2FsbHkgd2hhdCB0aGUgbGFjayBvZiBh biBhc3RlcmlzayBtZWFucy4gSSBpbmhlcml0ZWQgdGhlIGludmVydGVkIGxvZ2ljIGZvciB0aGUg YXN0ZXJpc2sgZnJvbSBpdHMgYWxyZWFkeSBkZWZpbmVkIG5vbi1kZW5pYWwgbWVhbmluZy48YnIg Y2xhc3M9IiI+DQombmJzcDtJZiB5b3UgYXJlIGNvbnNpZGVyaW5nIHdvcmRpbmcgZm9yIHRoZSBk cmFmdCwgSSBzdWdnZXN0IHRoYXQgeW91IHN0cmFpZ2h0ZW4gdGhlIGxvZ2ljIHRvIHNheSAmcXVv dDt3aGljaCBsYW5ndWFnZS9tZWRpYSBhcmUgbW9zdCBwcmVmZXJyZWQgKGRpZCBub3QgaGF2ZSBh biBhc3RlcmlzayBpbiB0aGUgb2ZmZXIpJnF1b3Q7PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KJm5ic3A7SXQgZG9lcyBhbHNvIG5vdCBuZWVkIHRvIGJlIGFuICZxdW90O2Fuc3dlcmluZyBo dW1hbiZxdW90OyB0aGF0IGdldHMgdGhpcyBpbmRpY2F0aW9uIGFuZCBtYWtlcyB1c2Ugb2YgaXQg Zm9yIGd1aWRhbmNlIG9uIGhvdyB0byBhbnN3ZXIgdGhlIGNhbGwuIEl0IGNhbiBqdXN0IGFzIHdl bGwgYmUgZS5nLiBhIG11bHRpLW1vZGFsIGFuc3dlcmluZyBtYWNoaW5lIG9yIHNvbWUgb3RoZXIg YXBwbGljYXRpb24gaW50ZXJhY3Rpbmcgd2l0aCBodW1hbiBsYW5ndWFnZS4gSQ0KIGFtIG5vdCBz dXJlIGlmICZxdW90O2Fuc3dlcmluZyBwYXJ0eSZxdW90OyBpcyBtb3JlIGFwcHJvcHJpYXRlIGFu ZCBjYW4gYmUgY29uc2lkZXJlZCBpbmNsdWRpbmcgc3VjaCBhdXRvbWF0YS48YnIgY2xhc3M9IiI+ DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpIaSBHdW5uYXIsPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KVGhhbmtzIGZvciBjbGFyaWZ5aW5nLCBJIHRoaW5rIEkgdW5kZXJzdGFu ZCB5b3VyIHByb3Bvc2FsIGluIGRldGFpbCBub3cuICZuYnNwO0FmdGVyIHRoaW5raW5nIGl0IG92 ZXIsIEkgc3RpbGwgdGhpbmsgdGhpcyB3b3VsZCBiZSBiZXR0ZXIgZG9uZSBpbiBhIG5ldyBkcmFm dCwgYmVjYXVzZSAoYSkgaXQgaXMgYWR2aWNlIG9uIGEgd2F5IG9mIHVzaW5nIHRoZSBtZWNoYW5p c20gdG8gY29udmV5IGFkZGl0aW9uYWwgaW5mb3JtYXRpb247IChiKSBpdCB3b3VsZA0KIGJlIGdv b2QgZm9yIHRoZSBncm91cCB0byBkaXNjdXNzIHRoZSBwcm9wb3NhbCBhbmQgd29yayB0aHJvdWdo IHZhcmlvdXMgY2FzZXMgKGUuZy4sIHdoYXQgaWYgdGhlIG9mZmVyaW5nIGNsaWVudCBpcyBub3Qg Z29pbmcgdG8gaW5jbHVkZSBhbiBhc3Rlcmlzaywgd2hhdCBpZiB0aGVyZSBpcyBtb3JlIHRoYW4g b25lIG1vc3QtcHJlZmVycmVkIGxhbmd1YWdlKTsgYW5kIChjKSBpdCB3b3VsZCBiZSBnb29kIGZv ciB0aGUgZ3JvdXAgdG8gZGVjaWRlIGlmDQogdGhpcyBtZWV0cyB5b3VyIG5lZWQuPGJyIGNsYXNz PSIiPg0KPC9ibG9ja3F1b3RlPg0KUmFuZGFsbCw8YnIgY2xhc3M9IiI+DQpHb29kIHRoYXQgeW91 IHVuZGVyc3RhbmQgaXQgbm93LjxiciBjbGFzcz0iIj4NCkkgcmVhbGl6ZSB0aGF0IHRoaXMga2lu ZCBvZiBhZGRlZCBydWxlcyBmb3IgYW4gYWxyZWFkeSBleGlzdGluZyBwYXJhbWV0ZXIgY291bGQg YmUgc3BlY2lmaWVkIGluIGFuIGFkZGl0aW9uYWwgZHJhZnQuIEVzcGVjaWFsbHkgc2luY2UgaXQg aGFzIG5vIGltcGFjdCBvbiB0aGUgY3VycmVudCBtZWFuaW5nIG9mIHRoZSBhc3Rlcmlzay48YnIg Y2xhc3M9IiI+DQpJIHN0aWxsIHRoaW5rIGl0IGlzIGJlc3QgdG8gYWRkIHRoZSBmZXcgd29yZHMg bmVlZGVkIG5vdy4gVGhlIHByZWZlcmVuY2UgaW5kaWNhdGlvbiBpcyBzbyBzZXZlcmVseSB1bmJh bGFuY2VkIHdpdGhvdXQgaXQsIGluIHRoYXQgb25seSBwcmVmZXJlbmNlIGJldHdlZW4gbGFuZ3Vh Z2VzIGluIHRoZSBzYW1lIG1vZGFsaXR5IGNhbiBiZSBzcGVjaWZpZWQuIEkgYW0gYWZyYWlkIHRo YXQgaXQgY2FuIGJlIHNlZW4gYXMgYSBkaXNjcmltaW5hdGlvbiBhZ2FpbnN0DQogdGhvc2Ugd2hv IHdvdWxkIG5lZWQgdG8gc3BlY2lmeSBwcmVmZXJlbmNlIGJldHdlZW4gZGlmZmVyZW50IG1vZGFs aXRpZXMgaW4gb3JkZXIgdG8gdGdldCBlcXVhbCBvcHBvcnR1bml0aWVzIHRvIGdldCBzbW9vdGhs eSBwZXJmb3JtZWQgY2FsbHMgdGhyb3VnaCwgYnV0IGNhbm5vdC48YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpZb3UgYXJlIHJpZ2h0IHRoYXQgdGhlcmUgYXJlIHNpdHVhdGlvbnMgdGhhdCB3 aWxsIG5vdCBiZSBleHBsYWluZWQgaWYgd2UgYWNjZXB0IG15IGxpdHRsZSBleHRyYSBzZW50ZW5j ZSBvciBzb21ldGhpbmcgc2ltaWxhci48YnIgY2xhc3M9IiI+DQpUaGF0IGlzIHRydWUgYWxzbyBm b3IgdGhlIGN1cnJlbnRseSBzcGVjaWZpZWQgaW5kaWNhdGlvbnMuIFdlIGhhdmUgc2FpZCB0aGF0 IHdlIG5lYXJseSBvbmx5IHNwZWNpZnkgdGhlIGluZGljYXRpb25zIGFuZCBub3QgaG93IHRoZSBu ZWdvdGlhdGlvbiBzaGFsbCBiZSBwZXJmb3JtZWQuIEl0IGNhbiBiZSBhIHRvcGljIGZvciBhIEJD UCB0byBhZHZpY2Ugb24gaG93IHRoZSBuZWdvdGlhdGlvbiBjb3VsZCBiZSBwZXJmb3JtZWQgYm90 aCB3aXRoIHRoZQ0KIGN1cnJlbnRseSBzcGVjaWZpZWQgbGFuZ3VhZ2UgYW5kIGluLW1lZGlhIHBy ZWZlcmVuY2VzIGFuZCB3aXRoIHRoZSBhZGRpdGlvbmFsIHByZWZlcmVuY2UgYmV0d2VlbiBtZWRp YS4gV2UgY291bGQgZGlzY3VzcyBlLmcuIHRoZSBjYXNlIHdoZW4gdHdvIHNhbWUgc3Bva2VuIGxh bmd1YWdlcyBhcmUgc3BlY2lmaWVkIGJ1dCB3aXRoIHRoZSBvcHBvc2l0ZSBwcmVmZXJlbmNlIG9y ZGVyIGJ5IHRoZSBvZmZlcm9yIGFuZCBhbnN3ZXJpbmcgcGFydHkuIEENCiBkZWNpc2lvbiBtdXN0 IGJlIHRha2VuLCBiZWNhdXNlIHRoZSBwcm90b2NvbCBzYXlzIHRoYXQgb2x5IG9uZSBsYW5ndWFn ZSBwZXIgbWVkaWEgYW5kIGRpcmVjdGlvbiBtYXkgYmUgaW5kaWNhdGVkIGluIHRoZSBhbnN3ZXIs IGFuZCBhbHNvIHRoYXQgdGhlIGFuc3dlcmluZyBpbnN0YW5jZSBuZWVkIHRvIGJlY29tZSBhd2Fy ZSBvZiB3aGljaCBsYW5ndWFnZSBpdCBzaGFsbCBwcm9kdWNlLjxiciBjbGFzcz0iIj4NCkkgZG8g bm90IHNheSB0aGF0IHdlIG5lZWQgdG8gcmVzb2x2ZSB0aGlzIGNhc2UuIEl0IGNhbiBiZSBkaXNj dXNzZWQgaW4gYSBCQ1AsIGFuZCBpbmRpY2F0ZWQgdGhhdCBhZGRpdGlvbmFsIHBvbGljeSBtYXkg YmUgYXBwbGllZCBmb3Igc29sdmluZyB0aGF0IGtpbmQgb2YgdW5kZWZpbmVkIGNhc2VzLjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClNpbWlsYXJpbHksIHRoZXJlIHdpbGwgYmUgc2l0dWF0 aW9ucyB3aXRoIHRoZSBhZGRpdGlvbmFsIHVzZSBvZiB0aGUgYXN0ZXJpc2sgdGhhdCB3aWxsIGJl IGdvb2QgdG8gcHJvdmlkZSBleHRyYSBpbmZvcm1hdGlvbiBmb3IgaW4gYSBCQ1AuIFRoZSBwcmVm ZXJlbmNlIGluZGljYXRpb24gaXMgdmVyeSByb3VnaCwgd2l0aCBvbmx5IHR3byBsZXZlbHMuIFNv IHRoZXJlIHdpbCBvZiBjb3Vyc2UgYmUgc2l0dWF0aW9ucyB3aGVuIHRoZSB1c2VycyB3aWxsDQog d29uZGVyIGhvdyB0byBzZXQgdGhlaXIgcHJvZmlsZSwgYW5kIGNhc2VzIHdoZW4gdGhlIG5lZ290 aWF0aW9uIHdpbGwgYmUgaGFyZCB0byBhc3NpZ24gYSB3ZWxsIG1vdGl2YXRlZCByZXN1bHQuIEJ1 dCB3ZSBoYXZlIHNhaWQgdGhhdCB3ZSB3YW50IHRvIGhhdmUgdGhlIHNwZWNpZmljYXRpb24gb24g dGhpcyByb3VnaCBsZXZlbC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGUgdHdvIGNh c2VzIHRoYXQgeW91IGJyaW5nIHVwIGNhbiBoYXZlIHRoaXMgdHJlYXRtZW50OjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCjEuIElmIHRoZSBjYWxsaW5nIHVzZXIgd2FudCB0byBnZXQgdGhl IGNhbGwgZGVuaWVkIGlmIG5vIGxhbmd1YWdlcyBtYXRjaCwgdGhlbiB0aGUgdXNlciBtdXN0IG1h a2UgYSBkZWNpc2lvbiBpZiB0aGF0IHByZWZlcmVuY2UgaXMgbW9yZSBpbXBvcnRhbnQgdG8gc3Bl Y2lmeSB0aGFuIHRoZSBwcmVmZXJlbmNlIGJldHdlZW4gbW9kYWxpdGllcy4gSW4gb3JkZXIgdG8g a2VlcCBjb21wbGV4aXR5IGxvdywgSSBkbyBub3QgdGhpbmsgdGhhdCB3ZSBzaG91bGQNCiBzcGVj aWZ5IGhvdyB0byBjb2RlIGJvdGggcHJlZmVyZW5jZXMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KMi4gSWYgdGhlcmUgYXJlIG1vcmUgdGhhbiBvbmUgbW9zdC1wcmVmZXJyZWQgbGFuZ3Vh Z2UuIEkgdW5kZXJzdGFuZCB0aGlzIGFzIGZvciBleGFtcGxlIGEgdXNlciBpcyBlcXVhbGx5IGhh cHB5IHRvIHVzZSBGcmVuY2ggc2lnbiBsYW5ndWFnZSBhcyBzcG9rZW4gRnJlbmNoLCBhbmQgY2Fu IGFsc28sIGJ1dCBvbiBsb3dlciBwcmVmZXJlbmNlIGxldmVsIHdyaXRlIEZyZW5jaCB0ZXh0LiBU aGF0IHdvdWxkIGJlIGluZGljYXRlZCBieSBhbiBhc3Rlcmlzaw0KIG9uIHRoZSBGcmVuY2ggdGV4 dCwgYW5kIHRoZSBhbnN3ZXJpbmcgcGFydHkgaGF2aW5nIGFsbCB0aGVzZSB0aHJlZSBjYXBhYmls aXRpZXMgbWF5IG9taXQgdGhlIEZyZW5jaCB0ZXh0IGZyb20gdGhlIGFuc3dlciBidXQga2VlcCB0 aGUgb3RoZXJzLiBUaGVuIHRoZSBhbnN3ZXJpbmcgdXNlciBzZWxlY3Qgb25lIG9mIHRoZSBzcG9r ZW4gRnJlbmNoIGFuZCBGcmVuY2ggU2lnbiBMYW5ndWFnZSBmb3IgaXRzIHN0YXJ0IG9mIHRoZSBj YWxsLCBrbm93aW5nDQogdGhhdCB0aGUgY2FsbGVyIHdpbGwgYmUgYXBwcm94aW1hdGVseSBlcXVh bGx5IGhhcHB5IHdpdGggdGhlIGNhbGwgaW4gYm90aCB0aGVzZSBjYXNlcy4gJm5ic3A7Jm5ic3A7 V2FzIHRoYXQgdGhlIGNhc2UgeW91IHRob3VnaHQgYWJvdXQgZm9yIHRoZSBzZWNvbmQgY2FzZT88 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJIHVuZGVyc3RhbmQgdGhhdCB5b3Ugd2FudGVk IHRvIGNoZWNrIG1vcmUgdGhhbiB0aGVzZSB0d28gY2FzZXMgYW5kIGRpc2N1c3MgdGhlbSB3aXRo IHRoZSBXRywgc28gdGhlIGFib3ZlIGlzIGp1c3QgYSBzdGFydC4gV2UgY2FuIGRvIG1vcmUgY2Fz ZXMgaWYgeW91IHdhbnQsIGJ1dCBJIGRvIG5vdCB0aGluayB3ZSBuZWVkIGFueSBsZW5ndGh5IGRp c2N1c3Npb24gdGhhdCB3b3VsZCBkZWxheSB0aGUgY3VycmVudCBkcmFmdC48YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBIG5ldyBkcmFmdCwgZXNwZWNpYWxseSBvbmUgdGhhdCB3 aWxsIGJlIGVpdGhlciBJbmZvcm1hdGlvbmFsIG9yIEJDUCwgY2FuIGJlIGRvbmUgZmFpcmx5IHF1 aWNrbHkuIEl0IGNvdWxkIGJlIHF1aXRlIHNob3J0LCBwZXJoYXBzIG9ubHkgYSBwYWdlIG9yIHR3 byBvZiByZWFsIHRleHQgcGx1cyB0aGUgYm9pbGVycGxhdGUgdGV4dC4gJm5ic3A7SSBhbSBoYXBw eSB0byBoZWxwIHdpdGggaXQuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPGJyIGNsYXNzPSIiPg0KSSBzZWUgeW91ciBwb2ludCwgaG93ZXZlciwgbXkgdmlldyBp cyB0aGF0IHRoaXMgaXMgYmVzdCBjb3ZlcmVkIGluIGEgc2VwYXJhdGUgZHJhZnQuICZuYnNwO0Fz IEkgc2FpZCBhYm92ZSwgdGhlIGRyYWZ0IGNhbiBiZSBjb21wbGV0ZWQgdmVyeSBxdWlja2x5IGlm IGl0IGlzIEluZm9ybWF0aW9uYWwgKG9yIGV2ZW4gQkNQKSwgY2xlYXIgYW5kIG5vdCBjb250cm92 ZXJzaWFsLiAmbmJzcDtJIGFtIGhhcHB5IHRvIGhlbHAuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KLS0gPGJyIGNsYXNzPSIiPg0KUmFuZGFsbCBHZWxsZW5zPGJyIGNsYXNzPSIiPg0KT3Bp bmlvbnMgYXJlIHBlcnNvbmFsOyAmbmJzcDsmbmJzcDsmbmJzcDtmYWN0cyBhcmUgc3VzcGVjdDsg Jm5ic3A7Jm5ic3A7Jm5ic3A7SSBzcGVhayBmb3IgbXlzZWxmIG9ubHk8YnIgY2xhc3M9IiI+DQot LS0tLS0tLS0tLS0tLSBSYW5kb21seSBzZWxlY3RlZCB0YWc6IC0tLS0tLS0tLS0tLS0tLTxiciBj bGFzcz0iIj4NCiZuYnNwOyZuYnNwO1RoZSBoaWdobGlnaHQgb2YgdGhlIGFubnVhbCBDb21wdXRl ciBCb3dsIG9jY3VycmVkIHdoZW4gQmlsbCBHYXRlcyw8YnIgY2xhc3M9IiI+DQp3aG8gd2FzIGEg anVkZ2UsIHBvc2VkIHRoZSBmb2xsb3dpbmcgcXVlc3Rpb24gdG8gdGhlIGNvbnRlc3RhbnRzOjxi ciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZxdW90O1doYXQgY29udGVzdCwgaGVsZCB2aWEgVXNl bmV0LCBpcyBkZWRpY2F0ZWQgdG8gZXhhbXBsZXMgb2Ygd2VpcmQsPGJyIGNsYXNzPSIiPg0Kb2Jz Y3VyZSwgYml6YXJyZSwgYW5kIHJlYWxseSBiYWQgcHJvZ3JhbW1pbmc/JnF1b3Q7PGJyIGNsYXNz PSIiPg0KJm5ic3A7Jm5ic3A7QWZ0ZXIgYSBtb21lbnQgb2Ygc2lsZW5jZSwgSmVhbi1Mb3VpcyBH YXNzZWUgKGV4LWhvbmNobyBhdCBBcHBsZSk8YnIgY2xhc3M9IiI+DQpoaXQgaGlzIGJ1enplciBh bmQgYW5zd2VyZWQgJnF1b3Q7V2luZG93cy4mcXVvdDs8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDstLVJlY291bnRlZCBieSBBZGFtIEMuIEVuZ3N0PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsc2Fucy1zZXJpZjtmb250LXNpemU6MTFweDtj b2xvcjojOTk5OTk5OyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTogQXJp YWwsc2Fucy1zZXJpZjtjb2xvcjojOTk5OTk5OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogQXJp YWw7IG1zby1mYXJlYXN0LXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tYmlkaS1mb250LWZh bWlseTogJnF1b3Q7QXJpYWwmcXVvdDs7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZh cmVhc3QtbGFuZ3VhZ2U6IEVOLUdCOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiPlRoaXMNCiBl bWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGFyZSBpbnRlbmRlZCBmb3IgdGhlIGFib3ZlIG5hbWVk IG9ubHkgYW5kIG1heSBiZSBjb25maWRlbnRpYWwuIElmIHRoZXkgaGF2ZSBjb21lIHRvIHlvdSBp biBlcnJvciB5b3UgbXVzdCB0YWtlIG5vIGFjdGlvbiBiYXNlZCBvbiB0aGVtLCBub3IgbXVzdCB5 b3UgY29weSBvciBzaG93IHRoZW0gdG8gYW55b25lOyBwbGVhc2UgcmVwbHkgdG8gdGhpcyBlbWFp bCBvciBjYWxsICYjNDM7NDQgMjA3IDM1NiAwNjAwDQogYW5kIGhpZ2hsaWdodCB0aGUgZXJyb3Iu IDwvc3Bhbj48L3A+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_52E633F6FBBB48FF97596E566914CDE6gsmacom_-- From nobody Tue Mar 7 07:41:56 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8405A1294A5 for ; Tue, 7 Mar 2017 06:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.91 X-Spam-Level: X-Spam-Status: No, score=-2.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gsmasso.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id affzbnsbYMQZ for ; Tue, 7 Mar 2017 06:32:19 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0085.outbound.protection.outlook.com [104.47.2.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 371711294BF for ; Tue, 7 Mar 2017 06:18:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=GSMASSO.onmicrosoft.com; s=selector1-gsma-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5kMBNfJBFODFqziagAWWTg8NQ1r/KE8753aPH6Ii90c=; b=Ox8eOjlDZxL68t+V6xSwrAVDy0E7qbS+8HslprosInsPFMoACM2pj2RobDA8lBvlPJn80oXxpKkRuFkM8tomxxCatnlP5jh9Th5yIurkyrOaq8yT1wuLZt3hS4FBIxbupahT8tZU/8l0q90E+SR3TWh5nnQa/7PJdXXQOpW10OY= Received: from HE1PR04MB3113.eurprd04.prod.outlook.com (10.171.196.31) by HE1PR04MB3113.eurprd04.prod.outlook.com (10.171.196.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Tue, 7 Mar 2017 14:18:05 +0000 Received: from HE1PR04MB3113.eurprd04.prod.outlook.com ([10.171.196.31]) by HE1PR04MB3113.eurprd04.prod.outlook.com ([10.171.196.31]) with mapi id 15.01.0947.020; Tue, 7 Mar 2017 14:18:05 +0000 From: Natasha Rooney To: "slim@ietf.org" Thread-Topic: Email length Thread-Index: AQHSl02jYZZQEFIKykKsZpqP4cMOWA== Date: Tue, 7 Mar 2017 14:18:05 +0000 Message-ID: <2C51A01A-F273-4854-A2CF-BFD943B81068@gsma.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=gsma.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [146.198.144.67] x-ms-office365-filtering-correlation-id: 6e311fe8-1aa8-47a5-66b9-08d46564c5d0 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:HE1PR04MB3113; x-microsoft-exchange-diagnostics: 1; HE1PR04MB3113; 7:2/9q3Z7L/JSfGo72VYZtI3gcmC5o4SEHbtAl11gKTkgI/JzpZDbIohakSi6mPGaUtnbTBIa+ij/B3cVB8/i3bBPz1mm0fQ02vd4YQawBlD8EpWQkhymJo7tjmi6Ngp3gkx56VQI/pPcoR6luctxCEJSS3YQzGuXZH5RMiapl/D9ZOq+TjF+hzInoRYkPAeSvPJb/2mRV5Dm7pUsTANEBBdPiHe182+LJULrlWhaY1/94fVmt/n0OniTlKtXZnWRDqrq+Epbg9UMGJZOnObtwmW0Tc4Sq4thBL6JpMGiSzxcgmUCw8ePpk98T1+5azbHCT9Yr4xHokucVnTB+XWZUxQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123558025)(20161123564025)(6042181)(6072148); SRVR:HE1PR04MB3113; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB3113; x-forefront-prvs: 0239D46DB6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(5640700003)(450100001)(106116001)(38730400002)(8676002)(86362001)(7116003)(2900100001)(110136004)(236005)(6916009)(25786008)(6436002)(77096006)(6486002)(33656002)(5890100001)(6512007)(6506006)(36756003)(50986999)(2501003)(122556002)(54896002)(5660300001)(3280700002)(7736002)(66066001)(221733001)(99286003)(8936002)(53936002)(2351001)(102836003)(6116002)(3846002)(2906002)(50226002)(189998001)(1730700003)(81166006)(3480700004)(3660700001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB3113; H:HE1PR04MB3113.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_2C51A01AF2734854A2CFBFD943B81068gsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Mar 2017 14:18:05.5518 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB3113 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: HE1PR04MB3113.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 146.198.144.67 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: HE1PR04MB3113.eurprd04.prod.outlook.com Archived-At: Subject: [Slim] Email length X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 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 Mar 2017 14:32:33 -0000 --_000_2C51A01AF2734854A2CFBFD943B81068gsmacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Guys - some emails on our list are exceeding in length. Can we please try t= o limit the amount we are writing and make our points accurately and succin= ctly. Thanks! Natasha Natasha Rooney | Internet Engineering Director | Internet and Web Team | Te= chnology | GSMA | nrooney@gsma.com | +44 (0) 7730 = 219 765 | @thisNatasha | Skype: nrooney@gsm.org This email and its attachments are intended for the above named only and ma= y be confidential. If they have come to you in error you must take no actio= n based on them, nor must you copy or show them to anyone; please reply to = this email or call +44 207 356 0600 and highlight the error. --_000_2C51A01AF2734854A2CFBFD943B81068gsmacom_ Content-Type: text/html; charset="us-ascii" Content-ID: <41474A1C0050ED41808ABC9ECD93D488@eurprd04.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Guys - some emails on our list are exceeding in length. Can we please try t= o limit the amount we are writing and make our points accurately and succin= ctly. 

Thanks!

Natasha 

Natasha Rooney | Internet Engineering Director | Internet and Web Team= | Technology | GSMA | nrooney@gsma.com | +44 (0) 7730 219 765 | @thisNata= sha | Skype: nrooney@gsm= .org

This email and its attachments are intended for the above named only and may be= confidential. If they have come to you in error you must take no action ba= sed on them, nor must you copy or show them to anyone; please reply to this= email or call +44 207 356 0600 and highlight the error.

--_000_2C51A01AF2734854A2CFBFD943B81068gsmacom_-- From nobody Tue Mar 7 09:54:47 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 824EC129474; Tue, 7 Mar 2017 09:54:46 -0800 (PST) X-Quarantine-ID: <7YkpsM9pDH0X> 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: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YkpsM9pDH0X; Tue, 7 Mar 2017 09:54:45 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 8AAA512945A; Tue, 7 Mar 2017 09:54:45 -0800 (PST) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 7 Mar 2017 09:43:06 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <20633096-1dfa-1c01-9591-3c2fb66efa30@omnitor.se> References: <148885485450.15073.6095850267163523164.idtracker@ietfa.amsl.com> <20633096-1dfa-1c01-9591-3c2fb66efa30@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Tue, 7 Mar 2017 09:54:42 -0800 To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , Mahesh Jethanandani , ops-dir@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 Archived-At: Cc: slim@ietf.org, ietf@ietf.org, draft-ietf-slim-negotiating-human-language.all@ietf.org Subject: Re: [Slim] Review of draft-ietf-slim-negotiating-human-language-08 X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 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 Mar 2017 17:54:46 -0000 At 11:17 AM +0100 3/7/17, Gunnar Hellstr=F6m wrote: >> Finally, it is always helpful to collect information on utilization >> from capacity, trend analysis, cost allocation, auditing and billing >> perspective. > Interesting aspects. Let us see what others say=20 > about what we can include at this stage and=20 > what should be brougth up in follow-up=20 > documents. This is an operational and implementation issue=20 which is out of scope of the draft. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Isn't it strange that the same people that laugh at gypsy fortune tellers take economists seriously? From nobody Tue Mar 7 12:44:59 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA0C012959B for ; Tue, 7 Mar 2017 12:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIHhW_GZ0vJk for ; Tue, 7 Mar 2017 12:44:54 -0800 (PST) Received: from bin-vsp-out-02.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE208129428 for ; Tue, 7 Mar 2017 12:44:53 -0800 (PST) X-Halon-ID: e80712ad-0376-11e7-af93-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Tue, 7 Mar 2017 21:44:48 +0100 (CET) To: Natasha Rooney , Randall Gellens References: <148782279664.31054.8793649134696520241.idtracker@ietfa.amsl.com> <49fd730e-6e90-1a49-eae8-80f8b1285a76@omnitor.se> <83152ba7-c3fb-25d8-f97d-59c7840cad56@omnitor.se> <4b36f347-955e-e2b9-12f2-f426d47d3d33@omnitor.se> <7f844aaa-17ce-2ab7-0602-a999a40235de@omnitor.se> <825fa638-b223-d716-6a3c-238903a37b92@omnitor.se> <9084ad5c-a3d1-68e1-879b-af759c463fd1@omnitor.se> <52E633F6-FBBB-48FF-9759-6E566914CDE6@gsma.com> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Tue, 7 Mar 2017 21:44:41 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <52E633F6-FBBB-48FF-9759-6E566914CDE6@gsma.com> Content-Type: multipart/alternative; boundary="------------6DEE22C9DDB24F2708B54D72" Archived-At: Cc: "slim@ietf.org" , "Phillips, Addison" , Bernard Aboba Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-07.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 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 Mar 2017 20:44:57 -0000 This is a multi-part message in MIME format. --------------6DEE22C9DDB24F2708B54D72 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, Den 2017-03-07 kl. 15:18, skrev Natasha Rooney: > Hi all, > > I’ve been catching up on the discussions after a long business trip - > so many apologies for the late response. > > The idea of working on Gunnar’s suggestions within a separate draft > seems like a good idea; it doesn’t delay the current draft’s progress > nor does it ignore a good proposal. It seems people are ok with this > decision, so let’s do that. > > Gunnar - if you want to make a start on this that would be fab; > Randall has offered support for this so we can rely on him for text > and review. Well, I am trying to convince you that we should do the opposite. To include a lightweight solution on the need for preference indication between modalities. Because without it the draft is unbalanced and does not meet its own declared requirements and is discriminating against persons with disabilities. And the simple solution also motivates why we have the asterisk as a parameter on media level, while with the current functional description it should rather be defined as an attribute on session level. But Bernard has during LC requested a solution also on the indication of a need for captions, and that is not as easily done as an extension on the current hlang coding. If you read my summary of the LC comments and resolutions on March 4, you may have seen in item n) by the end three different principles for solution of both the preference between modalities and the simultaneity indication needed for captions. One of the three solution principles is based on that we accept Dale's proposal to change coding of the attribute to be similar to the Accept-Language syntax. That is probably the cleanest solution. So even if we let the current draft go to publication without these two functionalities, we need to select a principle for the extensions and make sure that the draft is in line with the extensions. We should have a discussion on the three solution principles and decide which one to use. Regards /Gunnar > > Natasha > > Natasha Rooney | Internet Engineering Director | Internet and Web Team > | Technology | GSMA | nrooney@gsma.com | +44 > (0) 7730 219 765 | @thisNatasha | Skype: nrooney@gsm.org > > >> On 2 Mar 2017, at 02:21, Randall Gellens > > wrote: >> >> Hi Gunnar, >> >> At 11:06 PM +0100 3/1/17, Gunnar Hellström wrote: >> >>> Den 2017-03-01 kl. 18:47, skrev Randall Gellens: >>>> At 8:26 AM +0100 3/1/17, Gunnar Hellström wrote: >>>> >>>>> Hi Randall, >>>>> >>>>> Den 2017-03-01 kl. 02:08, skrev Randall Gellens: >>>>> >>>>>> Hi Gunnar, >>>>>> >>>>>> I'm starting a new message to cut out the huge amount of quoting. >>>>>> >>>>>> Your proposal is that text be added that advises the calling >>>>>> client to place an asterisk on the least-preferred >>>>>> language/media, and advises the answering client to indicate to >>>>>> the answering human which language/media is not the least >>>>>> preferred (did not have an asterisk in the offer), is that accurate? >>>>>> >>>>> Yes, with slight rewording to: >>>>> "text that advises the offering client to place an asterisk on >>>>> the least-preferred language/media indications, and advises the >>>>> answering client to indicate to the answering human which >>>>> language/media are not the least preferred (did not have an >>>>> asterisk in the offer)" >>>>> >>>>> The inclusion of the "indications" is just to assure that it is >>>>> clear that it does not need to be just one indication that gets >>>>> the asterisk . >>>>> The last part sounds awkward, but matches technically what the >>>>> lack of an asterisk means. I inherited the inverted logic for the >>>>> asterisk from its already defined non-denial meaning. >>>>> If you are considering wording for the draft, I suggest that you >>>>> straighten the logic to say "which language/media are most >>>>> preferred (did not have an asterisk in the offer)" >>>>> >>>>> It does also not need to be an "answering human" that gets this >>>>> indication and makes use of it for guidance on how to answer the >>>>> call. It can just as well be e.g. a multi-modal answering machine >>>>> or some other application interacting with human language. I am >>>>> not sure if "answering party" is more appropriate and can be >>>>> considered including such automata. >>>> >>>> Hi Gunnar, >>>> >>>> Thanks for clarifying, I think I understand your proposal in detail >>>> now. After thinking it over, I still think this would be better >>>> done in a new draft, because (a) it is advice on a way of using the >>>> mechanism to convey additional information; (b) it would be good >>>> for the group to discuss the proposal and work through various >>>> cases (e.g., what if the offering client is not going to include an >>>> asterisk, what if there is more than one most-preferred language); >>>> and (c) it would be good for the group to decide if this meets your >>>> need. >>> Randall, >>> Good that you understand it now. >>> I realize that this kind of added rules for an already existing >>> parameter could be specified in an additional draft. Especially >>> since it has no impact on the current meaning of the asterisk. >>> I still think it is best to add the few words needed now. The >>> preference indication is so severely unbalanced without it, in that >>> only preference between languages in the same modality can be >>> specified. I am afraid that it can be seen as a discrimination >>> against those who would need to specify preference between different >>> modalities in order to tget equal opportunities to get smoothly >>> performed calls through, but cannot. >>> >>> You are right that there are situations that will not be explained >>> if we accept my little extra sentence or something similar. >>> That is true also for the currently specified indications. We have >>> said that we nearly only specify the indications and not how the >>> negotiation shall be performed. It can be a topic for a BCP to >>> advice on how the negotiation could be performed both with the >>> currently specified language and in-media preferences and with the >>> additional preference between media. We could discuss e.g. the case >>> when two same spoken languages are specified but with the opposite >>> preference order by the offeror and answering party. A decision must >>> be taken, because the protocol says that oly one language per media >>> and direction may be indicated in the answer, and also that the >>> answering instance need to become aware of which language it shall >>> produce. >>> I do not say that we need to resolve this case. It can be discussed >>> in a BCP, and indicated that additional policy may be applied for >>> solving that kind of undefined cases. >>> >>> Similarily, there will be situations with the additional use of the >>> asterisk that will be good to provide extra information for in a >>> BCP. The preference indication is very rough, with only two levels. >>> So there wil of course be situations when the users will wonder how >>> to set their profile, and cases when the negotiation will be hard to >>> assign a well motivated result. But we have said that we want to >>> have the specification on this rough level. >>> >>> The two cases that you bring up can have this treatment: >>> >>> 1. If the calling user want to get the call denied if no languages >>> match, then the user must make a decision if that preference is more >>> important to specify than the preference between modalities. In >>> order to keep complexity low, I do not think that we should specify >>> how to code both preferences. >>> >>> 2. If there are more than one most-preferred language. I understand >>> this as for example a user is equally happy to use French sign >>> language as spoken French, and can also, but on lower preference >>> level write French text. That would be indicated by an asterisk on >>> the French text, and the answering party having all these three >>> capabilities may omit the French text from the answer but keep the >>> others. Then the answering user select one of the spoken French and >>> French Sign Language for its start of the call, knowing that the >>> caller will be approximately equally happy with the call in both >>> these cases. Was that the case you thought about for the second case? >>> >>> I understand that you wanted to check more than these two cases and >>> discuss them with the WG, so the above is just a start. We can do >>> more cases if you want, but I do not think we need any lengthy >>> discussion that would delay the current draft. >>> >>>> >>>> >>>> A new draft, especially one that will be either Informational or >>>> BCP, can be done fairly quickly. It could be quite short, perhaps >>>> only a page or two of real text plus the boilerplate text. I am >>>> happy to help with it. >> >> I see your point, however, my view is that this is best covered in a >> separate draft. As I said above, the draft can be completed very >> quickly if it is Informational (or even BCP), clear and not >> controversial. I am happy to help. >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself only >> -------------- Randomly selected tag: --------------- >> The highlight of the annual Computer Bowl occurred when Bill Gates, >> who was a judge, posed the following question to the contestants: >> "What contest, held via Usenet, is dedicated to examples of weird, >> obscure, bizarre, and really bad programming?" >> After a moment of silence, Jean-Louis Gassee (ex-honcho at Apple) >> hit his buzzer and answered "Windows." >> --Recounted by Adam C. Engst > > This email and its attachments are intended for the above named only > and may be confidential. If they have come to you in error you must > take no action based on them, nor must you copy or show them to > anyone; please reply to this email or call +44 207 356 0600 and > highlight the error. > -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------6DEE22C9DDB24F2708B54D72 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi,


Den 2017-03-07 kl. 15:18, skrev Natasha Rooney:
Hi all,

I’ve been catching up on the discussions after a long business trip - so many apologies for the late response.

The idea of working on Gunnar’s suggestions within a separate draft seems like a good idea; it doesn’t delay the current draft’s progress nor does it ignore a good proposal. It seems people are ok with this decision, so let’s do that.

Gunnar - if you want to make a start on this that would be fab; Randall has offered support for this so we can rely on him for text and review.
Well, I am trying to convince you that we should do the opposite. To include a lightweight solution on the need for preference indication between modalities.
Because without it the draft is unbalanced and does not meet its own declared requirements and is discriminating against persons with disabilities. And the simple solution also motivates why we have the asterisk as a parameter on media level, while with the current functional description it should rather be defined as an attribute on session level.

But Bernard has during LC requested a solution also on the indication of a need for captions, and that is not as easily done as an extension on the current hlang coding. If you read my summary of the LC comments and resolutions on March 4, you may have seen in item n) by the end three different principles for solution of both the preference between modalities and the simultaneity indication needed for captions.  One of the three solution principles is based on that we accept Dale's proposal to change coding of the attribute to be similar to the Accept-Language syntax.  That is probably the cleanest solution. So even if we let the current draft go to publication without these two functionalities, we need to select a principle for the extensions and make sure that the draft is in line with the extensions. 

We should have a discussion on the three solution principles and decide which one to use. 

Regards
/Gunnar


 

Natasha 

Natasha Rooney | Internet Engineering Director | Internet and Web Team | Technology | GSMA | nrooney@gsma.com | +44 (0) 7730 219 765 | @thisNatasha | Skype: nrooney@gsm.org

On 2 Mar 2017, at 02:21, Randall Gellens <rg+ietf@randy.pensive.org> wrote:

Hi Gunnar,

At 11:06 PM +0100 3/1/17, Gunnar Hellström wrote:

Den 2017-03-01 kl. 18:47, skrev Randall Gellens:
At 8:26 AM +0100 3/1/17, Gunnar Hellström wrote:

 Hi Randall,

 Den 2017-03-01 kl. 02:08, skrev Randall Gellens:

 Hi Gunnar,

 I'm starting a new message to cut out the huge amount of quoting.

 Your proposal is that text be added that advises the calling client to place an asterisk on the least-preferred language/media, and advises the answering client to indicate to the answering human which language/media is not the least preferred (did not have an asterisk in the offer), is that accurate?

 Yes, with slight rewording to:
 "text that advises the offering client to place an asterisk on the least-preferred language/media indications, and advises the answering client to indicate to the answering human which language/media are not the least preferred (did not have an asterisk in the offer)"

 The inclusion of the "indications" is just to assure that it is clear that it does not need to be just one indication that gets the asterisk .
 The last part sounds awkward, but matches technically what the lack of an asterisk means. I inherited the inverted logic for the asterisk from its already defined non-denial meaning.
 If you are considering wording for the draft, I suggest that you straighten the logic to say "which language/media are most preferred (did not have an asterisk in the offer)"

 It does also not need to be an "answering human" that gets this indication and makes use of it for guidance on how to answer the call. It can just as well be e.g. a multi-modal answering machine or some other application interacting with human language. I am not sure if "answering party" is more appropriate and can be considered including such automata.

Hi Gunnar,

Thanks for clarifying, I think I understand your proposal in detail now.  After thinking it over, I still think this would be better done in a new draft, because (a) it is advice on a way of using the mechanism to convey additional information; (b) it would be good for the group to discuss the proposal and work through various cases (e.g., what if the offering client is not going to include an asterisk, what if there is more than one most-preferred language); and (c) it would be good for the group to decide if this meets your need.
Randall,
Good that you understand it now.
I realize that this kind of added rules for an already existing parameter could be specified in an additional draft. Especially since it has no impact on the current meaning of the asterisk.
I still think it is best to add the few words needed now. The preference indication is so severely unbalanced without it, in that only preference between languages in the same modality can be specified. I am afraid that it can be seen as a discrimination against those who would need to specify preference between different modalities in order to tget equal opportunities to get smoothly performed calls through, but cannot.

You are right that there are situations that will not be explained if we accept my little extra sentence or something similar.
That is true also for the currently specified indications. We have said that we nearly only specify the indications and not how the negotiation shall be performed. It can be a topic for a BCP to advice on how the negotiation could be performed both with the currently specified language and in-media preferences and with the additional preference between media. We could discuss e.g. the case when two same spoken languages are specified but with the opposite preference order by the offeror and answering party. A decision must be taken, because the protocol says that oly one language per media and direction may be indicated in the answer, and also that the answering instance need to become aware of which language it shall produce.
I do not say that we need to resolve this case. It can be discussed in a BCP, and indicated that additional policy may be applied for solving that kind of undefined cases.

Similarily, there will be situations with the additional use of the asterisk that will be good to provide extra information for in a BCP. The preference indication is very rough, with only two levels. So there wil of course be situations when the users will wonder how to set their profile, and cases when the negotiation will be hard to assign a well motivated result. But we have said that we want to have the specification on this rough level.

The two cases that you bring up can have this treatment:

1. If the calling user want to get the call denied if no languages match, then the user must make a decision if that preference is more important to specify than the preference between modalities. In order to keep complexity low, I do not think that we should specify how to code both preferences.

2. If there are more than one most-preferred language. I understand this as for example a user is equally happy to use French sign language as spoken French, and can also, but on lower preference level write French text. That would be indicated by an asterisk on the French text, and the answering party having all these three capabilities may omit the French text from the answer but keep the others. Then the answering user select one of the spoken French and French Sign Language for its start of the call, knowing that the caller will be approximately equally happy with the call in both these cases.   Was that the case you thought about for the second case?

I understand that you wanted to check more than these two cases and discuss them with the WG, so the above is just a start. We can do more cases if you want, but I do not think we need any lengthy discussion that would delay the current draft.



A new draft, especially one that will be either Informational or BCP, can be done fairly quickly. It could be quite short, perhaps only a page or two of real text plus the boilerplate text.  I am happy to help with it.

I see your point, however, my view is that this is best covered in a separate draft.  As I said above, the draft can be completed very quickly if it is Informational (or even BCP), clear and not controversial.  I am happy to help.

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
  The highlight of the annual Computer Bowl occurred when Bill Gates,
who was a judge, posed the following question to the contestants:
  "What contest, held via Usenet, is dedicated to examples of weird,
obscure, bizarre, and really bad programming?"
  After a moment of silence, Jean-Louis Gassee (ex-honcho at Apple)
hit his buzzer and answered "Windows."
                                        --Recounted by Adam C. Engst

This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email or call +44 207 356 0600 and highlight the error. 


-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------6DEE22C9DDB24F2708B54D72-- From nobody Tue Mar 7 14:01:48 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D2C129473 for ; Tue, 7 Mar 2017 14:01:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOFY5B7NFB2a for ; Tue, 7 Mar 2017 14:01:44 -0800 (PST) Received: from bin-vsp-out-03.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50F5D1204D9 for ; Tue, 7 Mar 2017 14:01:43 -0800 (PST) X-Halon-ID: a409a3c3-0381-11e7-9c99-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Tue, 7 Mar 2017 23:01:39 +0100 (CET) To: "slim@ietf.org" From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <084a066e-ea68-d614-58e1-08c904f477ea@omnitor.se> Date: Tue, 7 Mar 2017 23:01:32 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------12B87158F0975CBF6CA9F948" Archived-At: Subject: [Slim] Extended functionality for the real-time language negotiation X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 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 Mar 2017 22:01:47 -0000 This is a multi-part message in MIME format. --------------12B87158F0975CBF6CA9F948 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit This is a slightly improved extract from the summary of the LC period for the real-time SLIM draft about two discussed functionality extensions. (Some of the examples had copy-paste errors.) The intention is to discuss this topic as far as needed to decide if any or both these functionality enhancements could go into the current draft before publication, and if not included then decide if any changes are required in the current draft in order to accommodate for the extensions. (see the summary sent on March 4 for e.g. references to the other summary points. ---------------------------------------------------------------------------------------------------------- *n). Indication of preference between media, and of simultanous versus alternative languages.* This is a summary of the remaining issues related to items e), f), j) and m) above. Issue e) proposes changes to enable indication of preference for language in different media. Issue f) requests possibility to indicate request or offering of text captions of spoken language. Issue j) proposes use of the Accept-Language syntax, that could both solve the functional needs of e) and f) and sort out the syntax and semantics problems of the asterisk parameter. Issue m) just indicates that issue e) is not yet resolved. Randall has proposed to resolve the functional needs in a new draft, and not accept the Accept-Language syntax. I have proposed a simple way to resolve issue e) - the preference between media, at the same time improving the definition of the semantics of the asterisk parameter. No real solution to issue f) - the simultaneity indication has been discussed. Issue j) - the proposal to use the Accept-Language syntax can potentially be used to resolve issues e) and f). Discussion: Issue e) says that there is a need to be able indicate which of a set of language/media indications are more preferred alternatives than others. Examples are: 1. A want to get written English in text, A can as a less preferred alternative accept to get spoken English. An answering party B who can use text will then respond with written text and get good satisfaction, while another answering user C without text capability will answer in spoken English and have a possibility for a reasonably successful call. Without this indication, the first answering party B may have seen the spoken and written alternatives as true equal preference alternatives and answered with spoken English that will result in less satisfied users. 2. A Prefer to receive spoken language, and can accept to receive text. When answering party B can use spoken language, that will be satisfied, otherwise written language will be used. 3. A Prefer to use spoken language in both directions, and can accept to use sign language in video in both directions. Answering party B has a clear indication of why both signed and written is indicated and can answer according to its capabilities trying to satisfy the preference for spoken language. 4. A Prefer to use sign language in both directions and can accept to use written language in both directions. Sign language users will use sign language, others will use text. 5. Prefer to send sign language and receive text (deaf-blind user), can accept to send text. In a call with a person with similar prefeences, text will be used both ways, otherwise sign one way and text the other. etc. Issue f) requires a way to indicate use of captioning and other situations where use of simultaneous languages in different modalities are needed: 1. Preference for hearing spoken language and simultaneously read written language in text. ( captioning) . The time is here when this can be provided automatically in some settings, but also traditionally by a manned service. 2. Preference for hearing spoken language and simultaneously seeing the speaker in video. (lip-reading). Easily and naturally provided once the need is known. 3. Preference for seeing sign language and simultaneously hear spoken language in audio. ( for multiple users at the terminal ) One of the streams is provided by an interpreter. 4. Preference for hearing spoken language and simultaneously view written language in video. (captioning if we accept to specify text as overlay on video, otherwise it is same as number 1.) Some of these can be acceptable also if just one of the language/media combinations can be provided, but is much more preferred if both can be provided together. In other cases it is essential to get both simultaneously. There is a need to differentiate in the indication that this preference for getting the languages together is preferred. Alternative coding proposals: 1. Preference between language/modality 1.1 Based on draft -08, add the coding of an asterisk last in an attribute to mean lower preference for a lanugage/media combination than the one(s) without an asterisk. example m=audio a=hlang-recv:en* m=text a=hlang-recv:en Audio and text are alternatives and text preferred 1.2. Change to the Accept-Language syntax and let the q-values have scope over the whole SDP. m=video 51372 RTP/AVP 31 32 a=hlang-recv:ase;q=0.9 a=hlang-send:ase;q=0.9 m=text 49250 RTP/AVP 98,99 a=hlang-send:en;q=0.5,*;q=0.1 a=hlang-recv:en;q=0.5,*;q=0.1 Sign language is higher preferred than text. 1.3. Introduce a new a=modality attribute on media level, with parameters: , , example: m=text a=modality:written,recv,hi a=hlang-recv:en* m=audio a=modality:spoken,recv,med a=hlang-recv:en* 2. Preference for simultaneous languages vs alternative languages: 2.1. Based on draft -08, add another notation to the use of the asterisk, e.g. an optional character to be used together with the asterisk to mark media that are wanted together. (ugly) example: m=audio a=hlang-recv:en*$c m=text a=hlang-recv:en$c The $ is a simultaneity indication, the c is a groouping indicator telling that all modalities marked with the $c are wanted together. (we might be able to restrict the indication to just one set of languages that are wanted simultaneously. 2.2. Use the Accept-Language syntax and add the usage rules that q-values with less than .1 difference mean languages with a preference to be used together. Higher differences indicate that they are alternatives. Thereby it is both possible to indicate simultaneity and preference if the simultaneity cannot be satisfied. m=audio 51372 RTP/AVP 0 a=hlang-recv:ase;q=0.5 a=hlang-send:ase;q=0.5 m=text 49250 RTP/AVP 98,99 a=hlang-send:en;q=0.51,*;q=0.1 a=hlang-recv:en;q=0.51,*;q=0.1 The q-values differences are within 0.1 so it is a preference for getting both together, but if that is not possible, text is preferred. 2.3. Add to the new a=modality attribute a fourth, optional parameter [simultaneity] with value any single letter, indicating a preference for having that modality simultaneously with another modality indicated with the same value in the [simultaneity] parameter. Without this parameter, the modalities are alternatives. m=text a=modality:written,recv,hi,d a=hlang-recv:en* m=audio a=modality:spoken,recv,hi,d a=hlang-recv:en* * * ***Status: Not solved. Conclusion needed on how to handle these issues e, f, and j, both regarding which solution and what procedure to take to apply it.* I have a slight preference for solution 1.2 and 2.2 , Your views? Regards Gunnar -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------12B87158F0975CBF6CA9F948 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

This is a slightly improved extract from the summary of the LC period for the real-time SLIM draft about two discussed functionality extensions. (Some of the examples had copy-paste errors.)

The intention is to discuss this topic as far as needed to decide if any or both these functionality enhancements could go into the current draft before publication, and if not included then decide if any changes are required in the current draft in order to accommodate for the extensions.

(see the summary sent on March 4 for e.g. references to the other summary points.

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

n). Indication of preference between media, and of simultanous versus alternative languages.

This is a summary of the remaining issues related to items e), f), j) and m) above.

Issue e) proposes changes to enable indication of preference for language in different media.
Issue f) requests possibility to indicate request or offering of text captions of spoken language.
Issue j) proposes use of the Accept-Language syntax, that could both solve the functional needs
of e) and f) and sort out the syntax and semantics problems of the asterisk parameter.
Issue m) just indicates that issue e) is not yet resolved.

Randall has proposed to resolve the functional needs in a new draft, and not accept the Accept-Language syntax.
I have proposed a simple way to resolve issue e) - the preference between media, at the same time improving the definition of the semantics of the asterisk parameter.
No real solution to issue f) - the simultaneity indication  has been discussed.
Issue j) - the proposal to use the Accept-Language syntax can potentially be used to resolve issues e) and f).

 Discussion:
Issue e) says that there is a need to be able indicate which of a set of language/media indications are more preferred alternatives than others.
Examples are:
1. A want to get written English in text, A can as a less preferred alternative accept to get spoken English.  An answering party B who can use text will then respond with written text and get good satisfaction, while another answering user C without text capability will answer in spoken English and have a possibility for a reasonably successful call.
Without this indication, the first answering party B may have seen the spoken and written alternatives as true equal preference alternatives and answered with spoken English that will result in less satisfied users.
2. A Prefer to receive spoken language, and can accept to receive text.   When answering party B can use spoken language, that will be satisfied, otherwise written language will be used.
3. A Prefer to use spoken language in both directions, and can accept to use sign language in video in both directions. Answering party B has a clear indication of why both signed and written is indicated and can answer according to its capabilities trying to satisfy the preference for spoken language.
4. A Prefer to use  sign language in both directions and can accept to use written language in both directions. Sign language users will use sign language, others will use text.
5. Prefer to send sign language and receive text (deaf-blind user), can accept to send text.  In a call with a person with similar prefeences, text will be used both ways, otherwise sign one way and text the other.

etc.

Issue f) requires a way to indicate use of captioning and other situations where use of simultaneous languages in different modalities are needed:

1. Preference for hearing spoken language and simultaneously read written language in text. ( captioning) .   The time is here when this can be provided automatically in some settings, but also traditionally by a manned service.
2. Preference for hearing spoken language and simultaneously seeing the speaker in video.   (lip-reading).  Easily and naturally provided once the need is known.
3. Preference for seeing sign language and simultaneously hear spoken language in audio.  ( for multiple users at the terminal )    One of the streams is provided by an interpreter.
4. Preference for hearing spoken language and simultaneously view written language in video. (captioning if we accept to specify text as overlay on video, otherwise it is same as number 1.) 

Some of these can be acceptable also if just one of the language/media combinations can be provided, but is much more preferred if both can be provided together. In other cases it is essential to get both simultaneously. There is a need to differentiate in the indication that this preference for getting the languages together is preferred.

Alternative coding proposals:
1. Preference between language/modality
1.1 Based on draft -08, add the coding of an asterisk last in an attribute to mean lower preference for a lanugage/media combination than the one(s) without an asterisk.
example
m=audio
a=hlang-recv:en*
m=text
a=hlang-recv:en

Audio and text are alternatives and text preferred

1.2. Change to the Accept-Language syntax and let the q-values have scope over the whole SDP.    


 m=video 51372 RTP/AVP 31 32
 a=hlang-recv:ase;q=0.9
 a=hlang-send:ase;q=0.9


 m=text 49250 RTP/AVP 98,99
 a=hlang-send:en;q=0.5,*;q=0.1
 a=hlang-recv:en;q=0.5,*;q=0.1

Sign language is higher preferred than text.

 



1.3. Introduce a new a=modality attribute on media level, with parameters: <modality>, <direction>, <preference>    
example:

m=text
a=modality:written,recv,hi
a=hlang-recv:en*
m=audio
a=modality:spoken,recv,med
a=hlang-recv:en*



2. Preference for simultaneous languages vs alternative languages:

2.1. Based on draft -08, add another notation to the use of the asterisk, e.g. an optional character to be used together with the asterisk to mark media that are wanted together. (ugly)   example:

m=audio
a=hlang-recv:en*$c
m=text
a=hlang-recv:en$c

The $ is a simultaneity indication, the c is a groouping indicator telling that all modalities marked with the $c are wanted together. (we might be able to restrict the indication to just one set of languages that are wanted simultaneously.


2.2. Use the Accept-Language syntax and add the usage rules that q-values with less than .1 difference mean languages with a preference to be used together. Higher differences indicate that they are alternatives.  Thereby it is both possible to indicate simultaneity and preference if the simultaneity cannot be satisfied.

 m=audio 51372 RTP/AVP 0
 a=hlang-recv:ase;q=0.5
 a=hlang-send:ase;q=0.5


 m=text 49250 RTP/AVP 98,99
 a=hlang-send:en;q=0.51,*;q=0.1
 a=hlang-recv:en;q=0.51,*;q=0.1

The q-values differences are within 0.1 so it is a preference for getting both together, but if that is not possible, text is preferred.


2.3. Add to the new a=modality attribute a fourth, optional parameter [simultaneity]   with value any single letter, indicating a preference for having that modality simultaneously with another modality indicated with the same value in the [simultaneity] parameter.   Without this parameter, the modalities are alternatives.

m=text
a=modality:written,recv,hi,d
a=hlang-recv:en*
m=audio
a=modality:spoken,recv,hi,d
a=hlang-recv:en*



Status: Not solved. Conclusion needed on how to handle these issues e, f, and j,  both regarding which solution and what procedure to take to apply it.

I have a slight preference for solution 1.2 and 2.2 ,

Your views?

Regards
Gunnar
-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------12B87158F0975CBF6CA9F948-- From nobody Fri Mar 10 10:25:58 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4843512969F for ; Fri, 10 Mar 2017 10:25:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=realtimetext.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SufjnRS-miXZ for ; Fri, 10 Mar 2017 10:25:54 -0800 (PST) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::8]) (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 80A321296A7 for ; Fri, 10 Mar 2017 10:25:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1489170352; l=19432; s=domk; d=realtimetext.org; h=Content-Type:In-Reply-To:MIME-Version:Date:From:To:References: Subject:Reply-To; bh=+3YAkFaDUT0VjuDekzwp9NdY7frwz9/ARct9bGzuTJk=; b=xf6meEobUbJ27N4Ly+87MWQYwWIv/T6qyO06BKutfV3UF1RTx1X3XIj0bwgtLEwfBs jCQ2ag23+dvvSyYh1ncipmpwnLINNBAufrbE5pmiPQcvZBJlEMpn9jifTIw7mw0nsjpH ReOEeueWrp90bD8q66X4nQ9X39Lk+YL6H09H8= X-RZG-AUTH: :LX4KelWsW+3xSJJIkwZSBiHL/ghnhZXt77aKzZJz2lzFCSL5Vcj0jP3MsKJGpfKONDSU/Br4yw9iVw00EQZQ5NuAL3xC2govv1b1ZsI= X-RZG-CLASS-ID: mo00 Received: from MacBookPro-0020FC300A3E.local ([2601:601:c880:2428:d9a8:77a6:bb58:27f9]) by smtp.strato.com (RZmta 40.1 AUTH) with ESMTPSA id g02051t2AIPmA8R (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Fri, 10 Mar 2017 19:25:48 +0100 (CET) References: <084a066e-ea68-d614-58e1-08c904f477ea@omnitor.se> To: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= , "slim@ietf.org" From: Arnoud van Wijk Organization: R3TF Message-ID: <60797269-4dad-5f48-3184-b8fbca42c30c@realtimetext.org> Date: Fri, 10 Mar 2017 10:25:46 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <084a066e-ea68-d614-58e1-08c904f477ea@omnitor.se> Content-Type: multipart/alternative; boundary="------------EA7ECDC335B85E64F0F5E77B" Archived-At: Subject: Re: [Slim] Extended functionality for the real-time language negotiation X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: arnoud.vanwijk@realtimetext.org List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 18:25:57 -0000 This is a multi-part message in MIME format. --------------EA7ECDC335B85E64F0F5E77B Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Gunnar, I also prefer solution 1.2 and 2.2 I like the use of q values here. I think that is better then adding a new attribute. Good proposal. /Arnoud On 07/03/2017 14:01, Gunnar Hellström wrote: > > This is a slightly improved extract from the summary of the LC period > for the real-time SLIM draft about two discussed functionality > extensions. (Some of the examples had copy-paste errors.) > > The intention is to discuss this topic as far as needed to decide if > any or both these functionality enhancements could go into the current > draft before publication, and if not included then decide if any > changes are required in the current draft in order to accommodate for > the extensions. > > (see the summary sent on March 4 for e.g. references to the other > summary points. > > ---------------------------------------------------------------------------------------------------------- > > *n). Indication of preference between media, and of simultanous versus > alternative languages.* > > This is a summary of the remaining issues related to items e), f), j) > and m) above. > > Issue e) proposes changes to enable indication of preference for > language in different media. > Issue f) requests possibility to indicate request or offering of text > captions of spoken language. > Issue j) proposes use of the Accept-Language syntax, that could both > solve the functional needs > of e) and f) and sort out the syntax and semantics problems of the > asterisk parameter. > Issue m) just indicates that issue e) is not yet resolved. > > Randall has proposed to resolve the functional needs in a new draft, > and not accept the Accept-Language syntax. > I have proposed a simple way to resolve issue e) - the preference > between media, at the same time improving the definition of the > semantics of the asterisk parameter. > No real solution to issue f) - the simultaneity indication has been > discussed. > Issue j) - the proposal to use the Accept-Language syntax can > potentially be used to resolve issues e) and f). > > Discussion: > Issue e) says that there is a need to be able indicate which of a set > of language/media indications are more preferred alternatives than others. > Examples are: > 1. A want to get written English in text, A can as a less preferred > alternative accept to get spoken English. An answering party B who > can use text will then respond with written text and get good > satisfaction, while another answering user C without text capability > will answer in spoken English and have a possibility for a reasonably > successful call. > Without this indication, the first answering party B may have seen the > spoken and written alternatives as true equal preference alternatives > and answered with spoken English that will result in less satisfied > users. > 2. A Prefer to receive spoken language, and can accept to receive > text. When answering party B can use spoken language, that will be > satisfied, otherwise written language will be used. > 3. A Prefer to use spoken language in both directions, and can accept > to use sign language in video in both directions. Answering party B > has a clear indication of why both signed and written is indicated and > can answer according to its capabilities trying to satisfy the > preference for spoken language. > 4. A Prefer to use sign language in both directions and can accept to > use written language in both directions. Sign language users will use > sign language, others will use text. > 5. Prefer to send sign language and receive text (deaf-blind user), > can accept to send text. In a call with a person with similar > prefeences, text will be used both ways, otherwise sign one way and > text the other. > > etc. > > Issue f) requires a way to indicate use of captioning and other > situations where use of simultaneous languages in different modalities > are needed: > > 1. Preference for hearing spoken language and simultaneously read > written language in text. ( captioning) . The time is here when this > can be provided automatically in some settings, but also traditionally > by a manned service. > 2. Preference for hearing spoken language and simultaneously seeing > the speaker in video. (lip-reading). Easily and naturally provided > once the need is known. > 3. Preference for seeing sign language and simultaneously hear spoken > language in audio. ( for multiple users at the terminal ) One of > the streams is provided by an interpreter. > 4. Preference for hearing spoken language and simultaneously view > written language in video. (captioning if we accept to specify text as > overlay on video, otherwise it is same as number 1.) > > Some of these can be acceptable also if just one of the language/media > combinations can be provided, but is much more preferred if both can > be provided together. In other cases it is essential to get both > simultaneously. There is a need to differentiate in the indication > that this preference for getting the languages together is preferred. > > Alternative coding proposals: > 1. Preference between language/modality > 1.1 Based on draft -08, add the coding of an asterisk last in an > attribute to mean lower preference for a lanugage/media combination > than the one(s) without an asterisk. > example > m=audio > a=hlang-recv:en* > m=text > a=hlang-recv:en > > Audio and text are alternatives and text preferred > > 1.2. Change to the Accept-Language syntax and let the q-values have > scope over the whole SDP. > > m=video 51372 RTP/AVP 31 32 > a=hlang-recv:ase;q=0.9 > a=hlang-send:ase;q=0.9 > > > m=text 49250 RTP/AVP 98,99 > a=hlang-send:en;q=0.5,*;q=0.1 > a=hlang-recv:en;q=0.5,*;q=0.1 > > Sign language is higher preferred than text. > > > > > > 1.3. Introduce a new a=modality attribute on media level, with > parameters: , , > example: > > m=text > a=modality:written,recv,hi > a=hlang-recv:en* > m=audio > a=modality:spoken,recv,med > a=hlang-recv:en* > > > > 2. Preference for simultaneous languages vs alternative languages: > > 2.1. Based on draft -08, add another notation to the use of the > asterisk, e.g. an optional character to be used together with the > asterisk to mark media that are wanted together. (ugly) example: > > m=audio > a=hlang-recv:en*$c > m=text > a=hlang-recv:en$c > > The $ is a simultaneity indication, the c is a groouping indicator > telling that all modalities marked with the $c are wanted together. > (we might be able to restrict the indication to just one set of > languages that are wanted simultaneously. > > > 2.2. Use the Accept-Language syntax and add the usage rules that > q-values with less than .1 difference mean languages with a preference > to be used together. Higher differences indicate that they are > alternatives. Thereby it is both possible to indicate simultaneity > and preference if the simultaneity cannot be satisfied. > > m=audio 51372 RTP/AVP 0 > a=hlang-recv:ase;q=0.5 > a=hlang-send:ase;q=0.5 > > > m=text 49250 RTP/AVP 98,99 > a=hlang-send:en;q=0.51,*;q=0.1 > a=hlang-recv:en;q=0.51,*;q=0.1 > > The q-values differences are within 0.1 so it is a preference for getting both together, but if that is not possible, text is preferred. > > > 2.3. Add to the new a=modality attribute a fourth, optional parameter > [simultaneity] with value any single letter, indicating a preference > for having that modality simultaneously with another modality > indicated with the same value in the [simultaneity] parameter. > Without this parameter, the modalities are alternatives. > > m=text > a=modality:written,recv,hi,d > a=hlang-recv:en* > m=audio > a=modality:spoken,recv,hi,d > a=hlang-recv:en* > > > * > * > > ***Status: Not solved. Conclusion needed on how to handle these issues > e, f, and j, both regarding which solution and what procedure to take > to apply it.* > > I have a slight preference for solution 1.2 and 2.2 , > > Your views? > > Regards > 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 --------------EA7ECDC335B85E64F0F5E77B Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi Gunnar,

I also prefer solution 1.2 and 2.2

I like the use of q values here. I think that is better then adding a new attribute.


Good proposal.


/Arnoud



On 07/03/2017 14:01, Gunnar Hellström wrote:

This is a slightly improved extract from the summary of the LC period for the real-time SLIM draft about two discussed functionality extensions. (Some of the examples had copy-paste errors.)

The intention is to discuss this topic as far as needed to decide if any or both these functionality enhancements could go into the current draft before publication, and if not included then decide if any changes are required in the current draft in order to accommodate for the extensions.

(see the summary sent on March 4 for e.g. references to the other summary points.

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

n). Indication of preference between media, and of simultanous versus alternative languages.

This is a summary of the remaining issues related to items e), f), j) and m) above.

Issue e) proposes changes to enable indication of preference for language in different media.
Issue f) requests possibility to indicate request or offering of text captions of spoken language.
Issue j) proposes use of the Accept-Language syntax, that could both solve the functional needs
of e) and f) and sort out the syntax and semantics problems of the asterisk parameter.
Issue m) just indicates that issue e) is not yet resolved.

Randall has proposed to resolve the functional needs in a new draft, and not accept the Accept-Language syntax.
I have proposed a simple way to resolve issue e) - the preference between media, at the same time improving the definition of the semantics of the asterisk parameter.
No real solution to issue f) - the simultaneity indication  has been discussed.
Issue j) - the proposal to use the Accept-Language syntax can potentially be used to resolve issues e) and f).

 Discussion:
Issue e) says that there is a need to be able indicate which of a set of language/media indications are more preferred alternatives than others.
Examples are:
1. A want to get written English in text, A can as a less preferred alternative accept to get spoken English.  An answering party B who can use text will then respond with written text and get good satisfaction, while another answering user C without text capability will answer in spoken English and have a possibility for a reasonably successful call.
Without this indication, the first answering party B may have seen the spoken and written alternatives as true equal preference alternatives and answered with spoken English that will result in less satisfied users.
2. A Prefer to receive spoken language, and can accept to receive text.   When answering party B can use spoken language, that will be satisfied, otherwise written language will be used.
3. A Prefer to use spoken language in both directions, and can accept to use sign language in video in both directions. Answering party B has a clear indication of why both signed and written is indicated and can answer according to its capabilities trying to satisfy the preference for spoken language.
4. A Prefer to use  sign language in both directions and can accept to use written language in both directions. Sign language users will use sign language, others will use text.
5. Prefer to send sign language and receive text (deaf-blind user), can accept to send text.  In a call with a person with similar prefeences, text will be used both ways, otherwise sign one way and text the other.

etc.

Issue f) requires a way to indicate use of captioning and other situations where use of simultaneous languages in different modalities are needed:

1. Preference for hearing spoken language and simultaneously read written language in text. ( captioning) .   The time is here when this can be provided automatically in some settings, but also traditionally by a manned service.
2. Preference for hearing spoken language and simultaneously seeing the speaker in video.   (lip-reading).  Easily and naturally provided once the need is known.
3. Preference for seeing sign language and simultaneously hear spoken language in audio.  ( for multiple users at the terminal )    One of the streams is provided by an interpreter.
4. Preference for hearing spoken language and simultaneously view written language in video. (captioning if we accept to specify text as overlay on video, otherwise it is same as number 1.) 

Some of these can be acceptable also if just one of the language/media combinations can be provided, but is much more preferred if both can be provided together. In other cases it is essential to get both simultaneously. There is a need to differentiate in the indication that this preference for getting the languages together is preferred.

Alternative coding proposals:
1. Preference between language/modality
1.1 Based on draft -08, add the coding of an asterisk last in an attribute to mean lower preference for a lanugage/media combination than the one(s) without an asterisk.
example
m=audio
a=hlang-recv:en*
m=text
a=hlang-recv:en

Audio and text are alternatives and text preferred

1.2. Change to the Accept-Language syntax and let the q-values have scope over the whole SDP.    

 m=video 51372 RTP/AVP 31 32
 a=hlang-recv:ase;q=0.9
 a=hlang-send:ase;q=0.9


 m=text 49250 RTP/AVP 98,99
 a=hlang-send:en;q=0.5,*;q=0.1
 a=hlang-recv:en;q=0.5,*;q=0.1

Sign language is higher preferred than text.

 



1.3. Introduce a new a=modality attribute on media level, with parameters: <modality>, <direction>, <preference>    
example:

m=text
a=modality:written,recv,hi
a=hlang-recv:en*
m=audio
a=modality:spoken,recv,med
a=hlang-recv:en*



2. Preference for simultaneous languages vs alternative languages:

2.1. Based on draft -08, add another notation to the use of the asterisk, e.g. an optional character to be used together with the asterisk to mark media that are wanted together. (ugly)   example:

m=audio
a=hlang-recv:en*$c
m=text
a=hlang-recv:en$c

The $ is a simultaneity indication, the c is a groouping indicator telling that all modalities marked with the $c are wanted together. (we might be able to restrict the indication to just one set of languages that are wanted simultaneously.


2.2. Use the Accept-Language syntax and add the usage rules that q-values with less than .1 difference mean languages with a preference to be used together. Higher differences indicate that they are alternatives.  Thereby it is both possible to indicate simultaneity and preference if the simultaneity cannot be satisfied.

 m=audio 51372 RTP/AVP 0
 a=hlang-recv:ase;q=0.5
 a=hlang-send:ase;q=0.5


 m=text 49250 RTP/AVP 98,99
 a=hlang-send:en;q=0.51,*;q=0.1
 a=hlang-recv:en;q=0.51,*;q=0.1

The q-values differences are within 0.1 so it is a preference for getting both together, but if that is not possible, text is preferred.


2.3. Add to the new a=modality attribute a fourth, optional parameter [simultaneity]   with value any single letter, indicating a preference for having that modality simultaneously with another modality indicated with the same value in the [simultaneity] parameter.   Without this parameter, the modalities are alternatives.

m=text
a=modality:written,recv,hi,d
a=hlang-recv:en*
m=audio
a=modality:spoken,recv,hi,d
a=hlang-recv:en*



Status: Not solved. Conclusion needed on how to handle these issues e, f, and j,  both regarding which solution and what procedure to take to apply it.

I have a slight preference for solution 1.2 and 2.2 ,

Your views?

Regards
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

--------------EA7ECDC335B85E64F0F5E77B-- From nobody Fri Mar 10 10:46:22 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40511294C5 for ; Fri, 10 Mar 2017 10:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRVxgOX8F6FI for ; Fri, 10 Mar 2017 10:46:16 -0800 (PST) Received: from mail-qk0-x244.google.com (mail-qk0-x244.google.com [IPv6:2607:f8b0:400d:c09::244]) (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 1BE0A12942F for ; Fri, 10 Mar 2017 10:46:16 -0800 (PST) Received: by mail-qk0-x244.google.com with SMTP id v125so29203084qkh.1 for ; Fri, 10 Mar 2017 10:46:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=9Qtsq04pWWg22eGsp8/IvFlUXuMs4s4HVPCvmgAS2K0=; b=mP31DN58P9R2FKRkQxUIlcITc/j6xhRK/BJ7XXdp3rpwRcW/PQkTSLMXq1ZasDjMXI GLr1/rlQ821zVdVK3ACmATZbIQLA1N371YJ/SWD1GM5GbAtRiwNVG5+MjPB2+96EL5Iv +K1+wBCikxrE0OL3lys0hM64Y1PUAOAxTJhdVJhhzVxMKVLiEGul825e2UKhktw3JfDi 9wte1E94Ne0OMoSr+SRyJj3m7DUZ/Qv9fQjLDbb2vYbj5UlxsVJL6msgJULDjCYjOvqC Z6iqU9uZHalB+Jb6bdlLw2JxST+n3xBuytollehuLMaaO71mclXOZvwGUUQuwPpgK3Ux UWbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=9Qtsq04pWWg22eGsp8/IvFlUXuMs4s4HVPCvmgAS2K0=; b=oJTaVnmfasCFCriN/1RQrg7xF7JjVTFzSOOYjClDV8V4dFcvR7KTj6kqUJSpQHYKbG RsZ/IThu/0/OP/VnF8tQdTyuvoR3eexOQO+/vcWAKrW4GXgZqQyE6cCKXcf4JxuYPi1a gZVm0HxSPCfI1fDAuq/+qolDuB+121ZLF+AmTTESLvVtvRLPFatj6kj7DkOUBK1iGAUk WpLqjowug8dkbhMtJOUZAHyh/l5PgIkl9VSe2AbCOw76T4Y2XsOMdenKyww+EjPvgnZC YW2vrZF5/iW7LI5Yg3pa5MNFur6SixjDwF6YEJK1/b5zvZ5k+fdEc6Wgd44qrQsCdbmB cc3Q== X-Gm-Message-State: AMke39lfeXmNzbULBUxbghuk5koKFuq+u+yzaNg+PdsNweWB0Sl/bC/c+4Q1HyW0+XAjvQ== X-Received: by 10.200.52.161 with SMTP id w30mr21103194qtb.69.1489171575025; Fri, 10 Mar 2017 10:46:15 -0800 (PST) Received: from [10.96.43.71] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id r60sm6861690qtd.53.2017.03.10.10.46.13 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 10 Mar 2017 10:46:14 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_2E787662-1C1A-4A14-AE5E-2B0B371D1EBF" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: <60797269-4dad-5f48-3184-b8fbca42c30c@realtimetext.org> Date: Fri, 10 Mar 2017 13:46:12 -0500 Message-Id: References: <084a066e-ea68-d614-58e1-08c904f477ea@omnitor.se> <60797269-4dad-5f48-3184-b8fbca42c30c@realtimetext.org> To: arnoud.vanwijk@realtimetext.org X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "slim@ietf.org" , =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= Subject: Re: [Slim] Extended functionality for the real-time language negotiation X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 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 Mar 2017 18:46:20 -0000 --Apple-Mail=_2E787662-1C1A-4A14-AE5E-2B0B371D1EBF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 We seem to be running in circles. The work group has discussed the idea of indicating media & language = combination preferences and DECLINED, at this time to do that. We = decided our first effort would be to label language preferences per = media, with no cross media preferences. That doesn=92t mean we won=92t = ever do it. It means our first document on SDP negotiation won=92t = cover that case. Yet you keep trying to get it in the current document. I don=92t want to revisit our decision, and I don=92t want to see any = linkage between media in this document. I accept there are requirements = to have such linkages, but think there are many. many uses for a simpler = mechanism such as what the current document discusses. If you want to write a draft that proposes an extension to the current = mechanism, please write it, and I=92ll review it. But I would like to = see this document published with the simple per-media preference. Brian > On Mar 10, 2017, at 1:25 PM, Arnoud van Wijk = wrote: >=20 > Hi Gunnar, >=20 > I also prefer solution 1.2 and 2.2 >=20 > I like the use of q values here. I think that is better then adding a = new attribute.=20 >=20 > Good proposal. >=20 >=20 > /Arnoud >=20 >=20 > On 07/03/2017 14:01, Gunnar Hellstr=F6m wrote: >> This is a slightly improved extract from the summary of the LC period = for the real-time SLIM draft about two discussed functionality = extensions. (Some of the examples had copy-paste errors.)=20 >> The intention is to discuss this topic as far as needed to decide if = any or both these functionality enhancements could go into the current = draft before publication, and if not included then decide if any changes = are required in the current draft in order to accommodate for the = extensions.=20 >> (see the summary sent on March 4 for e.g. references to the other = summary points. >> = --------------------------------------------------------------------------= -------------------------------- >>=20 >> n). Indication of preference between media, and of simultanous versus = alternative languages. >>=20 >> This is a summary of the remaining issues related to items e), f), j) = and m) above.=20 >>=20 >> Issue e) proposes changes to enable indication of preference for = language in different media. >> Issue f) requests possibility to indicate request or offering of text = captions of spoken language. >> Issue j) proposes use of the Accept-Language syntax, that could both = solve the functional needs >> of e) and f) and sort out the syntax and semantics problems of the = asterisk parameter. >> Issue m) just indicates that issue e) is not yet resolved.=20 >>=20 >> Randall has proposed to resolve the functional needs in a new draft, = and not accept the Accept-Language syntax. >> I have proposed a simple way to resolve issue e) - the preference = between media, at the same time improving the definition of the = semantics of the asterisk parameter. >> No real solution to issue f) - the simultaneity indication has been = discussed. >> Issue j) - the proposal to use the Accept-Language syntax can = potentially be used to resolve issues e) and f). >>=20 >> Discussion: >> Issue e) says that there is a need to be able indicate which of a set = of language/media indications are more preferred alternatives than = others. >> Examples are: >> 1. A want to get written English in text, A can as a less preferred = alternative accept to get spoken English. An answering party B who can = use text will then respond with written text and get good satisfaction, = while another answering user C without text capability will answer in = spoken English and have a possibility for a reasonably successful call. >> Without this indication, the first answering party B may have seen = the spoken and written alternatives as true equal preference = alternatives and answered with spoken English that will result in less = satisfied users.=20 >> 2. A Prefer to receive spoken language, and can accept to receive = text. When answering party B can use spoken language, that will be = satisfied, otherwise written language will be used. >> 3. A Prefer to use spoken language in both directions, and can accept = to use sign language in video in both directions. Answering party B has = a clear indication of why both signed and written is indicated and can = answer according to its capabilities trying to satisfy the preference = for spoken language. >> 4. A Prefer to use sign language in both directions and can accept = to use written language in both directions. Sign language users will use = sign language, others will use text.=20 >> 5. Prefer to send sign language and receive text (deaf-blind user), = can accept to send text. In a call with a person with similar = prefeences, text will be used both ways, otherwise sign one way and text = the other. >>=20 >> etc.=20 >>=20 >> Issue f) requires a way to indicate use of captioning and other = situations where use of simultaneous languages in different modalities = are needed: >>=20 >> 1. Preference for hearing spoken language and simultaneously read = written language in text. ( captioning) . The time is here when this = can be provided automatically in some settings, but also traditionally = by a manned service. >> 2. Preference for hearing spoken language and simultaneously seeing = the speaker in video. (lip-reading). Easily and naturally provided = once the need is known. >> 3. Preference for seeing sign language and simultaneously hear spoken = language in audio. ( for multiple users at the terminal ) One of the = streams is provided by an interpreter. >> 4. Preference for hearing spoken language and simultaneously view = written language in video. (captioning if we accept to specify text as = overlay on video, otherwise it is same as number 1.) =20 >>=20 >> Some of these can be acceptable also if just one of the = language/media combinations can be provided, but is much more preferred = if both can be provided together. In other cases it is essential to get = both simultaneously. There is a need to differentiate in the indication = that this preference for getting the languages together is preferred. >>=20 >> Alternative coding proposals: >> 1. Preference between language/modality >> 1.1 Based on draft -08, add the coding of an asterisk last in an = attribute to mean lower preference for a lanugage/media combination than = the one(s) without an asterisk.=20 >> example >> m=3Daudio >> a=3Dhlang-recv:en*=20 >> m=3Dtext >> a=3Dhlang-recv:en >>=20 >> Audio and text are alternatives and text preferred=20 >> 1.2. Change to the Accept-Language syntax and let the q-values have = scope over the whole SDP. =20 >> m=3Dvideo 51372 RTP/AVP 31 32 >> a=3Dhlang-recv:ase;q=3D0.9 >> a=3Dhlang-send:ase;q=3D0.9 >>=20 >>=20 >> m=3Dtext 49250 RTP/AVP 98,99 >> a=3Dhlang-send:en;q=3D0.5,*;q=3D0.1 >> a=3Dhlang-recv:en;q=3D0.5,*;q=3D0.1 >>=20 >> Sign language is higher preferred than text. >> =20 >>=20 >>=20 >> 1.3. Introduce a new a=3Dmodality attribute on media level, with = parameters: , , =20 >> example: >> m=3Dtext >> a=3Dmodality:written,recv,hi >> a=3Dhlang-recv:en* >> m=3Daudio >> a=3Dmodality:spoken,recv,med >> a=3Dhlang-recv:en* >>=20 >>=20 >> 2. Preference for simultaneous languages vs alternative languages: >>=20 >> 2.1. Based on draft -08, add another notation to the use of the = asterisk, e.g. an optional character to be used together with the = asterisk to mark media that are wanted together. (ugly) example:=20 >> m=3Daudio >> a=3Dhlang-recv:en*$c=20 >> m=3Dtext >> a=3Dhlang-recv:en$c >>=20 >> The $ is a simultaneity indication, the c is a groouping indicator = telling that all modalities marked with the $c are wanted together. (we = might be able to restrict the indication to just one set of languages = that are wanted simultaneously.=20 >>=20 >> 2.2. Use the Accept-Language syntax and add the usage rules that = q-values with less than .1 difference mean languages with a preference = to be used together. Higher differences indicate that they are = alternatives. Thereby it is both possible to indicate simultaneity and = preference if the simultaneity cannot be satisfied. >>=20 >> m=3Daudio 51372 RTP/AVP 0 >> a=3Dhlang-recv:ase;q=3D0.5 >> a=3Dhlang-send:ase;q=3D0.5 >>=20 >>=20 >> m=3Dtext 49250 RTP/AVP 98,99 >> a=3Dhlang-send:en;q=3D0.51,*;q=3D0.1 >> a=3Dhlang-recv:en;q=3D0.51,*;q=3D0.1 >>=20 >> The q-values differences are within 0.1 so it is a preference for = getting both together, but if that is not possible, text is preferred.=20= >>=20 >> 2.3. Add to the new a=3Dmodality attribute a fourth, optional = parameter [simultaneity] with value any single letter, indicating a = preference for having that modality simultaneously with another modality = indicated with the same value in the [simultaneity] parameter. Without = this parameter, the modalities are alternatives. >> m=3Dtext >> a=3Dmodality:written,recv,hi,d >> a=3Dhlang-recv:en* >> m=3Daudio >> a=3Dmodality:spoken,recv,hi,d >> a=3Dhlang-recv:en* >>=20 >>=20 >>=20 >> Status: Not solved. Conclusion needed on how to handle these issues = e, f, and j, both regarding which solution and what procedure to take = to apply it. >>=20 >> I have a slight preference for solution 1.2 and 2.2 ,=20 >> Your views? >> Regards >> 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 > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim --Apple-Mail=_2E787662-1C1A-4A14-AE5E-2B0B371D1EBF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 We seem to be running in circles.

The work group has discussed the idea = of indicating media & language combination preferences and DECLINED, = at this time to do that.  We decided our first effort would be to = label language preferences per media, with no cross media preferences. =  That doesn=92t mean we won=92t ever do it.  It means our = first document on SDP negotiation won=92t cover that case.

Yet you keep trying to = get it in the current document.

I don=92t want to revisit our decision, = and I don=92t want to see any linkage between media in this document. =  I accept there are requirements to have such linkages, but think = there are many. many uses for a simpler mechanism such as what the = current document discusses.

If you want to write a draft that proposes an extension to = the current mechanism, please write it, and I=92ll review it.  But = I would like to see this document published with the simple per-media = preference.

Brian


On Mar 10, 2017, at 1:25 PM, Arnoud van Wijk <arnoud.vanwijk@realtimetext.org> wrote:

=20 =20

Hi = Gunnar,

I also prefer solution 1.2 and 2.2

I like the use of q values here. I think that is better then adding a new attribute.


Good proposal.


/Arnoud



On 07/03/2017 14:01, Gunnar Hellstr=F6m= wrote:

This is a = slightly improved extract from the summary of the LC period for the real-time SLIM draft about two discussed functionality extensions. (Some of the examples had copy-paste errors.)

The intention is to discuss this topic as far as = needed to decide if any or both these functionality enhancements could go into the current draft before publication, and if not included then decide if any changes are required in the current draft in order to accommodate for the extensions.

(see the summary sent on March 4 for e.g. = references to the other summary points.

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

n). Indication of preference between media, and of simultanous versus alternative languages.

This is a summary of the remaining issues related to items e), f), j) and m) above.

Issue e) proposes changes to enable indication of preference for language in different media.
Issue f) requests possibility to indicate request or offering of text captions of spoken language.
Issue j) proposes use of the Accept-Language syntax, that could both solve the functional needs
of e) and f) and sort out the syntax and semantics problems of the asterisk parameter.
Issue m) just indicates that issue e) is not yet resolved.

Randall has proposed to resolve the functional needs in a new draft, and not accept the Accept-Language syntax.
I have proposed a simple way to resolve issue e) - the preference between media, at the same time improving the definition of the semantics of the asterisk parameter.
No real solution to issue f) - the simultaneity indication  = has been discussed.
Issue j) - the proposal to use the Accept-Language syntax can potentially be used to resolve issues e) and f).

 Discussion:
Issue e) says that there is a need to be able indicate which of a set of language/media indications are more preferred alternatives than others.
Examples are:
1. A want to get written English in text, A can as a less preferred alternative accept to get spoken English.  An answering party B who can use text will then respond with written text and get good satisfaction, while another answering user C without text capability will answer in spoken English and have a possibility for a reasonably successful call.
Without this indication, the first answering party B may have seen the spoken and written alternatives as true equal preference alternatives and answered with spoken English that will result in less satisfied users.
2. A Prefer to receive spoken language, and can accept to receive text.   When answering party B can use spoken = language, that will be satisfied, otherwise written language will be = used.
3. A Prefer to use spoken language in both directions, and can accept to use sign language in video in both directions. Answering party B has a clear indication of why both signed and written is indicated and can answer according to its capabilities trying to satisfy the preference for spoken language.
4. A Prefer to use  sign language in both directions and = can accept to use written language in both directions. Sign language users will use sign language, others will use text.
5. Prefer to send sign language and receive text (deaf-blind user), can accept to send text.  In a call with a person = with similar prefeences, text will be used both ways, otherwise sign one way and text the other.

etc.

Issue f) requires a way to indicate use of captioning and other situations where use of simultaneous languages in different modalities are needed:

1. Preference for hearing spoken language and simultaneously read written language in text. ( captioning) .   The = time is here when this can be provided automatically in some settings, but also traditionally by a manned service.
2. Preference for hearing spoken language and simultaneously seeing the speaker in video.   (lip-reading).  = Easily and naturally provided once the need is known.
3. Preference for seeing sign language and simultaneously hear spoken language in audio.  ( for multiple users at the = terminal )    One of the streams is provided by an = interpreter.
4. Preference for hearing spoken language and simultaneously view written language in video. (captioning if we accept to specify text as overlay on video, otherwise it is same as number 1.) 

Some of these can be acceptable also if just one of the language/media combinations can be provided, but is much more preferred if both can be provided together. In other cases it is essential to get both simultaneously. There is a need to differentiate in the indication that this preference for getting the languages together is preferred.

Alternative coding proposals:
1. Preference between language/modality
1.1 Based on draft -08, add the coding of an asterisk last in an attribute to mean lower preference for a lanugage/media combination than the one(s) without an asterisk.
example
m=3Daudio
a=3Dhlang-recv:en*
m=3Dtext
a=3Dhlang-recv:en

Audio and text are = alternatives and text preferred

1.2. Change to the Accept-Language syntax and = let the q-values have scope over the whole SDP.    

=
 m=3Dvideo 51372 RTP/AVP 31 32
 a=3Dhlang-recv:ase;q=3D0.9
 a=3Dhlang-send:ase;q=3D0.9


 m=3Dtext 49250 RTP/AVP 98,99
 a=3Dhlang-send:en;q=3D0.5,*;q=3D0.1
 a=3Dhlang-recv:en;q=3D0.5,*;q=3D0.1

Sign language is higher preferred than text.

 



1.3. Introduce a new a=3Dmodality attribute on media level, with parameters: <modality>, <direction>, <preference>    
example:

m=3Dtext
a=3Dmodality:written,recv,hi
a=3Dhlang-recv:en*
m=3Daudio
a=3Dmodality:spoken,recv,med
a=3Dhlang-recv:en*



2. Preference for simultaneous languages vs alternative languages:

2.1. Based on draft -08, add another notation to the use of the asterisk, e.g. an optional character to be used together with the asterisk to mark media that are wanted together. = (ugly)   example:

m=3Daudio
a=3Dhlang-recv:en*$c
m=3Dtext
a=3Dhlang-recv:en$c

The $ is a simultaneity = indication, the c is a groouping indicator telling that all modalities marked with the $c are wanted together. (we might be able to restrict the indication to just one set of languages that are wanted simultaneously.


2.2. Use the Accept-Language syntax and add the usage rules that q-values with less than .1 difference mean languages with a preference to be used together. Higher differences indicate that they are alternatives.  Thereby it is both possible to = indicate simultaneity and preference if the simultaneity cannot be satisfied.

=
 m=3Daudio 51372 RTP/AVP 0
 a=3Dhlang-recv:ase;q=3D0.5
 a=3Dhlang-send:ase;q=3D0.5


 m=3Dtext 49250 RTP/AVP 98,99
 a=3Dhlang-send:en;q=3D0.51,*;q=3D0.1
 a=3Dhlang-recv:en;q=3D0.51,*;q=3D0.1

The q-values differences are within 0.1 so it is a preference for =
getting both together, but if that is not possible, text is preferred.=20=


2.3. Add to the new a=3Dmodality attribute a fourth, optional parameter [simultaneity]   with value any single = letter, indicating a preference for having that modality simultaneously with another modality indicated with the same value in the [simultaneity] parameter.   Without this parameter, = the modalities are alternatives.

m=3Dtext
a=3Dmodality:written,recv,hi,d
a=3Dhlang-recv:en*
m=3Daudio
a=3Dmodality:spoken,recv,hi,d
a=3Dhlang-recv:en*



Status: = Not solved. Conclusion needed on how to handle these issues e, f, and j,  both regarding which solution and what procedure to take to apply it.

I have a slight preference for solution 1.2 and 2.2 ,

Your views?

Regards
Gunnar
--=20
-----------------------------------------
Gunnar Hellstr=F6m
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288


_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/m=
ailman/listinfo/slim

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

= --Apple-Mail=_2E787662-1C1A-4A14-AE5E-2B0B371D1EBF-- From nobody Fri Mar 10 14:54:23 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E28129480 for ; Fri, 10 Mar 2017 14:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8elMNc-Yb1H for ; Fri, 10 Mar 2017 14:54:17 -0800 (PST) Received: from bin-vsp-out-03.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16A0912947F for ; Fri, 10 Mar 2017 14:54:16 -0800 (PST) X-Halon-ID: 7ad2fe28-05e4-11e7-9c99-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Fri, 10 Mar 2017 23:54:12 +0100 (CET) To: Brian Rosen , arnoud.vanwijk@realtimetext.org References: <084a066e-ea68-d614-58e1-08c904f477ea@omnitor.se> <60797269-4dad-5f48-3184-b8fbca42c30c@realtimetext.org> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Fri, 10 Mar 2017 23:54:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C7837D0DB31582831871E191" Archived-At: Cc: "slim@ietf.org" Subject: Re: [Slim] Extended functionality for the real-time language negotiation X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 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 Mar 2017 22:54:21 -0000 This is a multi-part message in MIME format. --------------C7837D0DB31582831871E191 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Brian, Earlier we ran in circles around these functional requirements and their possible inclusion in the current draft. Not this time. I started to analyze what the mentioned functional extensions would mean, and tried to come up with possible ways to code them. Since Dale in the review also recommended us to switch to use the syntax similar to the Accept-Language, I took that as one base for the extension alternatives. That led to the three possible extension variants for each functional extension, and a brief analysis of them. The analysis is valid both if we make them as extensions after publication of our initial draft, or if it is decided that one or both functionalities can be included now. The planned extensions might be allowed to influence the current draft even if the extensions themselves are not included. The conclusion of my analysis was then that it would be easier to create the extensions if the coding of the current functionality moved to the syntax similar to Accept-Language. It is not going in circles to discuss and decide if we shall take the step to change the coding to satisfy both Dales' recommendations and my analysis. Please look at the extension discussion below and comment which one you prefer, or propose yet other altenatives. It is a separate discussion, but It is also true that I want to see the functional extensions included in the initial publication, and I do not see the value in publishing something without functions we know are needed. While we keep in discussing this I see projects moving on using private solutions for the functionality we discuss, causing risks for interoperability problems in the future. I think it is a failure to not solve the functional needs. They are real and urgent and solving them is the only politically correct way to act. /Gunnar Den 2017-03-10 kl. 19:46, skrev Brian Rosen: > We seem to be running in circles. > > The work group has discussed the idea of indicating media & language > combination preferences and DECLINED, at this time to do that. We > decided our first effort would be to label language preferences per > media, with no cross media preferences. That doesn’t mean we won’t > ever do it. It means our first document on SDP negotiation won’t > cover that case. > > Yet you keep trying to get it in the current document. > > I don’t want to revisit our decision, and I don’t want to see any > linkage between media in this document. I accept there are > requirements to have such linkages, but think there are many. many > uses for a simpler mechanism such as what the current document discusses. > > If you want to write a draft that proposes an extension to the current > mechanism, please write it, and I’ll review it. But I would like to > see this document published with the simple per-media preference. > > Brian > > >> On Mar 10, 2017, at 1:25 PM, Arnoud van Wijk >> > > wrote: >> >> Hi Gunnar, >> >> I also prefer solution 1.2 and 2.2 >> >> I like the use of q values here. I think that is better then adding a >> new attribute. >> >> >> Good proposal. >> >> >> /Arnoud >> >> >> >> On 07/03/2017 14:01, Gunnar Hellström wrote: >>> >>> This is a slightly improved extract from the summary of the LC >>> period for the real-time SLIM draft about two discussed >>> functionality extensions. (Some of the examples had copy-paste errors.) >>> >>> The intention is to discuss this topic as far as needed to decide if >>> any or both these functionality enhancements could go into the >>> current draft before publication, and if not included then decide if >>> any changes are required in the current draft in order to >>> accommodate for the extensions. >>> >>> (see the summary sent on March 4 for e.g. references to the other >>> summary points. >>> >>> ---------------------------------------------------------------------------------------------------------- >>> >>> *n). Indication of preference between media, and of simultanous >>> versus alternative languages.* >>> >>> This is a summary of the remaining issues related to items e), f), >>> j) and m) above. >>> >>> Issue e) proposes changes to enable indication of preference for >>> language in different media. >>> Issue f) requests possibility to indicate request or offering of >>> text captions of spoken language. >>> Issue j) proposes use of the Accept-Language syntax, that could both >>> solve the functional needs >>> of e) and f) and sort out the syntax and semantics problems of the >>> asterisk parameter. >>> Issue m) just indicates that issue e) is not yet resolved. >>> >>> Randall has proposed to resolve the functional needs in a new draft, >>> and not accept the Accept-Language syntax. >>> I have proposed a simple way to resolve issue e) - the preference >>> between media, at the same time improving the definition of the >>> semantics of the asterisk parameter. >>> No real solution to issue f) - the simultaneity indication has been >>> discussed. >>> Issue j) - the proposal to use the Accept-Language syntax can >>> potentially be used to resolve issues e) and f). >>> >>> Discussion: >>> Issue e) says that there is a need to be able indicate which of a >>> set of language/media indications are more preferred alternatives >>> than others. >>> Examples are: >>> 1. A want to get written English in text, A can as a less preferred >>> alternative accept to get spoken English. An answering party B who >>> can use text will then respond with written text and get good >>> satisfaction, while another answering user C without text capability >>> will answer in spoken English and have a possibility for a >>> reasonably successful call. >>> Without this indication, the first answering party B may have seen >>> the spoken and written alternatives as true equal preference >>> alternatives and answered with spoken English that will result in >>> less satisfied users. >>> 2. A Prefer to receive spoken language, and can accept to receive >>> text. When answering party B can use spoken language, that will be >>> satisfied, otherwise written language will be used. >>> 3. A Prefer to use spoken language in both directions, and can >>> accept to use sign language in video in both directions. Answering >>> party B has a clear indication of why both signed and written is >>> indicated and can answer according to its capabilities trying to >>> satisfy the preference for spoken language. >>> 4. A Prefer to use sign language in both directions and can accept >>> to use written language in both directions. Sign language users will >>> use sign language, others will use text. >>> 5. Prefer to send sign language and receive text (deaf-blind user), >>> can accept to send text. In a call with a person with similar >>> prefeences, text will be used both ways, otherwise sign one way and >>> text the other. >>> >>> etc. >>> >>> Issue f) requires a way to indicate use of captioning and other >>> situations where use of simultaneous languages in different >>> modalities are needed: >>> >>> 1. Preference for hearing spoken language and simultaneously read >>> written language in text. ( captioning) . The time is here when >>> this can be provided automatically in some settings, but also >>> traditionally by a manned service. >>> 2. Preference for hearing spoken language and simultaneously seeing >>> the speaker in video. (lip-reading). Easily and naturally provided >>> once the need is known. >>> 3. Preference for seeing sign language and simultaneously hear >>> spoken language in audio. ( for multiple users at the terminal ) >>> One of the streams is provided by an interpreter. >>> 4. Preference for hearing spoken language and simultaneously view >>> written language in video. (captioning if we accept to specify text >>> as overlay on video, otherwise it is same as number 1.) >>> >>> Some of these can be acceptable also if just one of the >>> language/media combinations can be provided, but is much more >>> preferred if both can be provided together. In other cases it is >>> essential to get both simultaneously. There is a need to >>> differentiate in the indication that this preference for getting the >>> languages together is preferred. >>> >>> Alternative coding proposals: >>> 1. Preference between language/modality >>> 1.1 Based on draft -08, add the coding of an asterisk last in an >>> attribute to mean lower preference for a lanugage/media combination >>> than the one(s) without an asterisk. >>> example >>> m=audio >>> a=hlang-recv:en* >>> m=text >>> a=hlang-recv:en >>> >>> Audio and text are alternatives and text preferred >>> >>> 1.2. Change to the Accept-Language syntax and let the q-values have >>> scope over the whole SDP. >>> >>> m=video 51372 RTP/AVP 31 32 >>> a=hlang-recv:ase;q=0.9 >>> a=hlang-send:ase;q=0.9 >>> >>> >>> m=text 49250 RTP/AVP 98,99 >>> a=hlang-send:en;q=0.5,*;q=0.1 >>> a=hlang-recv:en;q=0.5,*;q=0.1 >>> >>> Sign language is higher preferred than text. >>> >>> >>> >>> >>> >>> 1.3. Introduce a new a=modality attribute on media level, with >>> parameters: , , >>> example: >>> >>> m=text >>> a=modality:written,recv,hi >>> a=hlang-recv:en* >>> m=audio >>> a=modality:spoken,recv,med >>> a=hlang-recv:en* >>> >>> >>> >>> 2. Preference for simultaneous languages vs alternative languages: >>> >>> 2.1. Based on draft -08, add another notation to the use of the >>> asterisk, e.g. an optional character to be used together with the >>> asterisk to mark media that are wanted together. (ugly) example: >>> >>> m=audio >>> a=hlang-recv:en*$c >>> m=text >>> a=hlang-recv:en$c >>> >>> The $ is a simultaneity indication, the c is a groouping indicator >>> telling that all modalities marked with the $c are wanted together. >>> (we might be able to restrict the indication to just one set of >>> languages that are wanted simultaneously. >>> >>> >>> 2.2. Use the Accept-Language syntax and add the usage rules that >>> q-values with less than .1 difference mean languages with a >>> preference to be used together. Higher differences indicate that >>> they are alternatives. Thereby it is both possible to indicate >>> simultaneity and preference if the simultaneity cannot be satisfied. >>> >>> m=audio 51372 RTP/AVP 0 >>> a=hlang-recv:ase;q=0.5 >>> a=hlang-send:ase;q=0.5 >>> >>> >>> m=text 49250 RTP/AVP 98,99 >>> a=hlang-send:en;q=0.51,*;q=0.1 >>> a=hlang-recv:en;q=0.51,*;q=0.1 >>> >>> The q-values differences are within 0.1 so it is a preference for getting both together, but if that is not possible, text is preferred. >>> >>> >>> 2.3. Add to the new a=modality attribute a fourth, optional >>> parameter [simultaneity] with value any single letter, indicating >>> a preference for having that modality simultaneously with another >>> modality indicated with the same value in the [simultaneity] >>> parameter. Without this parameter, the modalities are alternatives. >>> >>> m=text >>> a=modality:written,recv,hi,d >>> a=hlang-recv:en* >>> m=audio >>> a=modality:spoken,recv,hi,d >>> a=hlang-recv:en* >>> >>> >>> * >>> * >>> >>> ***Status: Not solved. Conclusion needed on how to handle these >>> issues e, f, and j, both regarding which solution and what >>> procedure to take to apply it.* >>> >>> I have a slight preference for solution 1.2 and 2.2 , >>> >>> Your views? >>> >>> Regards >>> 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 >> >> _______________________________________________ >> 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 --------------C7837D0DB31582831871E191 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Brian,

Earlier we ran in circles around these functional requirements and their possible inclusion in the current draft.

Not this time.

I started to analyze what the mentioned functional extensions would mean, and tried to come up with possible ways to code them.

Since Dale in the review also recommended us to switch to use the syntax similar to the Accept-Language, I took that as one base for the extension alternatives.

That led to the three possible extension variants for each functional extension, and a brief analysis of them.

The analysis is valid both if we make them as extensions after publication of our initial draft, or if it is decided that one or both functionalities can be included now.

The planned extensions might be allowed to influence the current draft even if the extensions themselves are not included.

The conclusion of my analysis was then that it would be easier to create the extensions if the coding of the current functionality moved to the syntax similar to Accept-Language.

It is not going in circles to discuss and decide if we shall take the step to change the coding to satisfy both Dales' recommendations and my analysis.

Please look at the extension discussion below and comment which one you prefer, or propose yet other altenatives.


It is a separate discussion, but It is also true that I want to see the functional extensions included in the initial publication, and I do not see the value in publishing something without functions we know are needed. While we keep in discussing this I see projects moving on using private solutions for the functionality we discuss, causing risks for interoperability problems in the future. I think it is a failure to not solve the functional needs. They are real and urgent and solving them is the only politically correct way to act.


/Gunnar



Den 2017-03-10 kl. 19:46, skrev Brian Rosen:
We seem to be running in circles.

The work group has discussed the idea of indicating media & language combination preferences and DECLINED, at this time to do that.  We decided our first effort would be to label language preferences per media, with no cross media preferences.  That doesn’t mean we won’t ever do it.  It means our first document on SDP negotiation won’t cover that case.

Yet you keep trying to get it in the current document.

I don’t want to revisit our decision, and I don’t want to see any linkage between media in this document.  I accept there are requirements to have such linkages, but think there are many. many uses for a simpler mechanism such as what the current document discusses.

If you want to write a draft that proposes an extension to the current mechanism, please write it, and I’ll review it.  But I would like to see this document published with the simple per-media preference.

Brian


On Mar 10, 2017, at 1:25 PM, Arnoud van Wijk <arnoud.vanwijk@realtimetext.org> wrote:

Hi Gunnar,

I also prefer solution 1.2 and 2.2

I like the use of q values here. I think that is better then adding a new attribute.


Good proposal.


/Arnoud



On 07/03/2017 14:01, Gunnar Hellström wrote:

This is a slightly improved extract from the summary of the LC period for the real-time SLIM draft about two discussed functionality extensions. (Some of the examples had copy-paste errors.)

The intention is to discuss this topic as far as needed to decide if any or both these functionality enhancements could go into the current draft before publication, and if not included then decide if any changes are required in the current draft in order to accommodate for the extensions.

(see the summary sent on March 4 for e.g. references to the other summary points.

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

n). Indication of preference between media, and of simultanous versus alternative languages.

This is a summary of the remaining issues related to items e), f), j) and m) above.

Issue e) proposes changes to enable indication of preference for language in different media.
Issue f) requests possibility to indicate request or offering of text captions of spoken language.
Issue j) proposes use of the Accept-Language syntax, that could both solve the functional needs
of e) and f) and sort out the syntax and semantics problems of the asterisk parameter.
Issue m) just indicates that issue e) is not yet resolved.

Randall has proposed to resolve the functional needs in a new draft, and not accept the Accept-Language syntax.
I have proposed a simple way to resolve issue e) - the preference between media, at the same time improving the definition of the semantics of the asterisk parameter.
No real solution to issue f) - the simultaneity indication  has been discussed.
Issue j) - the proposal to use the Accept-Language syntax can potentially be used to resolve issues e) and f).

 Discussion:
Issue e) says that there is a need to be able indicate which of a set of language/media indications are more preferred alternatives than others.
Examples are:
1. A want to get written English in text, A can as a less preferred alternative accept to get spoken English.  An answering party B who can use text will then respond with written text and get good satisfaction, while another answering user C without text capability will answer in spoken English and have a possibility for a reasonably successful call.
Without this indication, the first answering party B may have seen the spoken and written alternatives as true equal preference alternatives and answered with spoken English that will result in less satisfied users.
2. A Prefer to receive spoken language, and can accept to receive text.   When answering party B can use spoken language, that will be satisfied, otherwise written language will be used.
3. A Prefer to use spoken language in both directions, and can accept to use sign language in video in both directions. Answering party B has a clear indication of why both signed and written is indicated and can answer according to its capabilities trying to satisfy the preference for spoken language.
4. A Prefer to use  sign language in both directions and can accept to use written language in both directions. Sign language users will use sign language, others will use text.
5. Prefer to send sign language and receive text (deaf-blind user), can accept to send text.  In a call with a person with similar prefeences, text will be used both ways, otherwise sign one way and text the other.

etc.

Issue f) requires a way to indicate use of captioning and other situations where use of simultaneous languages in different modalities are needed:

1. Preference for hearing spoken language and simultaneously read written language in text. ( captioning) .   The time is here when this can be provided automatically in some settings, but also traditionally by a manned service.
2. Preference for hearing spoken language and simultaneously seeing the speaker in video.   (lip-reading).  Easily and naturally provided once the need is known.
3. Preference for seeing sign language and simultaneously hear spoken language in audio.  ( for multiple users at the terminal )    One of the streams is provided by an interpreter.
4. Preference for hearing spoken language and simultaneously view written language in video. (captioning if we accept to specify text as overlay on video, otherwise it is same as number 1.) 

Some of these can be acceptable also if just one of the language/media combinations can be provided, but is much more preferred if both can be provided together. In other cases it is essential to get both simultaneously. There is a need to differentiate in the indication that this preference for getting the languages together is preferred.

Alternative coding proposals:
1. Preference between language/modality
1.1 Based on draft -08, add the coding of an asterisk last in an attribute to mean lower preference for a lanugage/media combination than the one(s) without an asterisk.
example
m=audio
a=hlang-recv:en*
m=text
a=hlang-recv:en

Audio and text are alternatives and text preferred

1.2. Change to the Accept-Language syntax and let the q-values have scope over the whole SDP.    

 m=video 51372 RTP/AVP 31 32
 a=hlang-recv:ase;q=0.9
 a=hlang-send:ase;q=0.9


 m=text 49250 RTP/AVP 98,99
 a=hlang-send:en;q=0.5,*;q=0.1
 a=hlang-recv:en;q=0.5,*;q=0.1

Sign language is higher preferred than text.

 



1.3. Introduce a new a=modality attribute on media level, with parameters: <modality>, <direction>, <preference>    
example:

m=text
a=modality:written,recv,hi
a=hlang-recv:en*
m=audio
a=modality:spoken,recv,med
a=hlang-recv:en*



2. Preference for simultaneous languages vs alternative languages:

2.1. Based on draft -08, add another notation to the use of the asterisk, e.g. an optional character to be used together with the asterisk to mark media that are wanted together. (ugly)   example:

m=audio
a=hlang-recv:en*$c
m=text
a=hlang-recv:en$c

The $ is a simultaneity indication, the c is a groouping indicator telling that all modalities marked with the $c are wanted together. (we might be able to restrict the indication to just one set of languages that are wanted simultaneously.


2.2. Use the Accept-Language syntax and add the usage rules that q-values with less than .1 difference mean languages with a preference to be used together. Higher differences indicate that they are alternatives.  Thereby it is both possible to indicate simultaneity and preference if the simultaneity cannot be satisfied.

 m=audio 51372 RTP/AVP 0
 a=hlang-recv:ase;q=0.5
 a=hlang-send:ase;q=0.5


 m=text 49250 RTP/AVP 98,99
 a=hlang-send:en;q=0.51,*;q=0.1
 a=hlang-recv:en;q=0.51,*;q=0.1

The q-values differences are within 0.1 so it is a preference for getting both together, but if that is not possible, text is preferred.


2.3. Add to the new a=modality attribute a fourth, optional parameter [simultaneity]   with value any single letter, indicating a preference for having that modality simultaneously with another modality indicated with the same value in the [simultaneity] parameter.   Without this parameter, the modalities are alternatives.

m=text
a=modality:written,recv,hi,d
a=hlang-recv:en*
m=audio
a=modality:spoken,recv,hi,d
a=hlang-recv:en*



Status: Not solved. Conclusion needed on how to handle these issues e, f, and j,  both regarding which solution and what procedure to take to apply it.

I have a slight preference for solution 1.2 and 2.2 ,

Your views?

Regards
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

_______________________________________________
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
--------------C7837D0DB31582831871E191-- From nobody Mon Mar 13 16:46:01 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1037F129AA2 for ; Mon, 13 Mar 2017 16:46:00 -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: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6efid1KiDW5 for ; Mon, 13 Mar 2017 16:45:58 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id E0849129673 for ; Mon, 13 Mar 2017 16:45:57 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 13 Mar 2017 16:47:13 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <084a066e-ea68-d614-58e1-08c904f477ea@omnitor.se> <60797269-4dad-5f48-3184-b8fbca42c30c@realtimetext.org> X-Mailer: Eudora for Mac OS X Date: Mon, 13 Mar 2017 16:45:51 -0700 To: Brian Rosen , arnoud.vanwijk@realtimetext.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 Archived-At: Cc: "slim@ietf.org" , Gunnar =?iso-8859-1?Q?Hellstr=F6m?= Subject: Re: [Slim] Extended functionality for the real-time language negotiation X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 23:46:00 -0000 I agree with Brian. The draft defines a very=20 simple mechanism, as agreed in the WG. The draft=20 has been through WG discussion, WG last call, and=20 IETF last call. I would object to reopening the=20 draft to add q-values or anything else. We can advance the current draft and start work=20 on a more complex mechanism. This would mean we=20 have something that is simple and useful=20 published. Or we can revert the draft back into=20 the WG, and spend months discussing it. Not only=20 would this needlessly add major delay to the=20 draft, but there is a real risk that we all get=20 sick of it and the AD shuts down the WG. At 1:46 PM -0500 3/10/17, Brian Rosen wrote: > We seem to be running in circles. > > The work group has discussed the idea of=20 > indicating media & language combination=20 > preferences and DECLINED, at this time to do=20 > that. We decided our first effort would be to=20 > label language preferences per media, with no=20 > cross media preferences. That doesn't mean we=20 > won't ever do it. It means our first document=20 > on SDP negotiation won't cover that case. > > Yet you keep trying to get it in the current document. > > I don't want to revisit our decision, and I=20 > don't want to see any linkage between media in=20 > this document. I accept there are requirements=20 > to have such linkages, but think there are=20 > many. many uses for a simpler mechanism such as=20 > what the current document discusses. > > If you want to write a draft that proposes an=20 > extension to the current mechanism, please=20 > write it, and I'll review it. But I would like=20 > to see this document published with the simple=20 > per-media preference. > > Brian > > >> On Mar 10, 2017, at 1:25 PM, Arnoud van Wijk=20 >> <arnoud.vanwijk@realtimetext.org>= =20 >> wrote: >> >> Hi Gunnar, >> >> I also prefer solution 1.2 and 2.2 >> >> I like the use of q values here. I think that=20 >> is better then adding a new attribute. >> >> >> Good proposal. >> >> >> /Arnoud >> >> >> >> On 07/03/2017 14:01, Gunnar Hellstr=F6m wrote: >> >>> This is a slightly improved extract from the=20 >>> summary of the LC period for the real-time=20 >>> SLIM draft about two discussed functionality=20 >>> extensions. (Some of the examples had=20 >>> copy-paste errors.) >>> >>> The intention is to discuss this topic as far=20 >>> as needed to decide if any or both these=20 >>> functionality enhancements could go into the=20 >>> current draft before publication, and if not=20 >>> included then decide if any changes are=20 >>> required in the current draft in order to=20 >>> accommodate for the extensions. >>> >>> (see the summary sent on March 4 for e.g.=20 >>> references to the other summary points. >>> >>>=20 >>> ------------------------------------------------------------------------= ---------------------------------- >>> >>> n). Indication of preference between media,=20 >>> and of simultanous versus alternative=20 >>> languages. >>> >>> This is a summary of the remaining issues=20 >>> related to items e), f), j) and m) above. >>> >>> Issue e) proposes changes to enable=20 >>> indication of preference for language in=20 >>> different media. >>> Issue f) requests possibility to indicate=20 >>> request or offering of text captions of=20 >>> spoken language. >>> Issue j) proposes use of the Accept-Language=20 >>> syntax, that could both solve the functional=20 >>> needs >>> of e) and f) and sort out the syntax and=20 >>> semantics problems of the asterisk parameter. >>> Issue m) just indicates that issue e) is not yet resolved. >>> >>> Randall has proposed to resolve the=20 >>> functional needs in a new draft, and not=20 >>> accept the Accept-Language syntax. >>> I have proposed a simple way to resolve issue=20 >>> e) - the preference between media, at the=20 >>> same time improving the definition of the=20 >>> semantics of the asterisk parameter. >>> No real solution to issue f) - the=20 >>> simultaneity indication has been discussed. >>> Issue j) - the proposal to use the=20 >>> Accept-Language syntax can potentially be=20 >>> used to resolve issues e) and f). >>> >>> Discussion: >>> Issue e) says that there is a need to be able=20 >>> indicate which of a set of language/media=20 >>> indications are more preferred alternatives=20 >>> than others. >>> Examples are: >>> 1. A want to get written English in text, A=20 >>> can as a less preferred alternative accept to=20 >>> get spoken English. An answering party B who=20 >>> can use text will then respond with written=20 >>> text and get good satisfaction, while another=20 >>> answering user C without text capability will=20 >>> answer in spoken English and have a=20 >>> possibility for a reasonably successful call. >>> Without this indication, the first answering=20 >>> party B may have seen the spoken and written=20 >>> alternatives as true equal preference=20 >>> alternatives and answered with spoken English=20 >>> that will result in less satisfied users. >>> 2. A Prefer to receive spoken language, and=20 >>> can accept to receive text. When answering=20 >>> party B can use spoken language, that will be=20 >>> satisfied, otherwise written language will be=20 >>> used. >>> 3. A Prefer to use spoken language in both=20 >>> directions, and can accept to use sign=20 >>> language in video in both directions.=20 >>> Answering party B has a clear indication of=20 >>> why both signed and written is indicated and=20 >>> can answer according to its capabilities=20 >>> trying to satisfy the preference for spoken=20 >>> language. >>> 4. A Prefer to use sign language in both=20 >>> directions and can accept to use written=20 >>> language in both directions. Sign language=20 >>> users will use sign language, others will use=20 >>> text. >>> 5. Prefer to send sign language and receive=20 >>> text (deaf-blind user), can accept to send=20 >>> text. In a call with a person with similar=20 >>> prefeences, text will be used both ways,=20 >>> otherwise sign one way and text the other. >>> >>> etc. >>> >>> Issue f) requires a way to indicate use of=20 >>> captioning and other situations where use of=20 >>> simultaneous languages in different=20 >>> modalities are needed: >>> >>> 1. Preference for hearing spoken language and=20 >>> simultaneously read written language in text.=20 >>> ( captioning) . The time is here when this=20 >>> can be provided automatically in some=20 >>> settings, but also traditionally by a manned=20 >>> service. >>> 2. Preference for hearing spoken language and=20 >>> simultaneously seeing the speaker in video.=20 >>> (lip-reading). Easily and naturally provided=20 >>> once the need is known. >>> 3. Preference for seeing sign language and=20 >>> simultaneously hear spoken language in audio.=20 >>> ( for multiple users at the terminal ) One=20 >>> of the streams is provided by an interpreter. >>> 4. Preference for hearing spoken language and=20 >>> simultaneously view written language in=20 >>> video. (captioning if we accept to specify=20 >>> text as overlay on video, otherwise it is=20 >>> same as number 1.) >>> >>> Some of these can be acceptable also if just=20 >>> one of the language/media combinations can be=20 >>> provided, but is much more preferred if both=20 >>> can be provided together. In other cases it=20 >>> is essential to get both simultaneously.=20 >>> There is a need to differentiate in the=20 >>> indication that this preference for getting=20 >>> the languages together is preferred. >>> >>> Alternative coding proposals: >>> 1. Preference between language/modality >>> 1.1 Based on draft -08, add the coding of an=20 >>> asterisk last in an attribute to mean lower=20 >>> preference for a lanugage/media combination=20 >>> than the one(s) without an asterisk. >>> example >>> m=3Daudio >>> a=3Dhlang-recv:en* >>> m=3Dtext >>> a=3Dhlang-recv:en >>> >>> Audio and text are alternatives and text preferred >>> >>> 1.2. Change to the Accept-Language syntax and=20 >>> let the q-values have scope over the whole=20 >>> SDP. >>> >>> m=3Dvideo 51372 RTP/AVP 31 32 >>> a=3Dhlang-recv:ase;q=3D0.9 >>> a=3Dhlang-send:ase;q=3D0.9 >>> >>> >>> m=3Dtext 49250 RTP/AVP 98,99 >>> a=3Dhlang-send:en;q=3D0.5,*;q=3D0.1 >>> a=3Dhlang-recv:en;q=3D0.5,*;q=3D0.1 >>> >>> Sign language is higher preferred than text. >>> >>> >>> >>> >>> >>> 1.3. Introduce a new a=3Dmodality attribute on=20 >>> media level, with parameters: ,=20 >>> , >>> example: >>> >>> m=3Dtext >>> a=3Dmodality:written,recv,hi >>> a=3Dhlang-recv:en* >>> m=3Daudio >>> a=3Dmodality:spoken,recv,med >>> a=3Dhlang-recv:en* >>> >>> >>> >>> 2. Preference for simultaneous languages vs alternative languages: >>> >>> 2.1. Based on draft -08, add another notation=20 >>> to the use of the asterisk, e.g. an optional=20 >>> character to be used together with the=20 >>> asterisk to mark media that are wanted=20 >>> together. (ugly) example: >>> >>> m=3Daudio >>> a=3Dhlang-recv:en*$c >>> m=3Dtext >>> a=3Dhlang-recv:en$c >>> >>> The $ is a simultaneity indication, the c is=20 >>> a groouping indicator telling that all=20 >>> modalities marked with the $c are wanted=20 >>> together. (we might be able to restrict the=20 >>> indication to just one set of languages that=20 >>> are wanted simultaneously. >>> >>> >>> 2.2. Use the Accept-Language syntax and add=20 >>> the usage rules that q-values with less than=20 >>> .1 difference mean languages with a=20 >>> preference to be used together. Higher=20 >>> differences indicate that they are=20 >>> alternatives. Thereby it is both possible to=20 >>> indicate simultaneity and preference if the=20 >>> simultaneity cannot be satisfied. >>> >>> m=3Daudio 51372 RTP/AVP 0 >>> a=3Dhlang-recv:ase;q=3D0.5 >>> a=3Dhlang-send:ase;q=3D0.5 >>> >>> >>> m=3Dtext 49250 RTP/AVP 98,99 >>> a=3Dhlang-send:en;q=3D0.51,*;q=3D0.1 >>> a=3Dhlang-recv:en;q=3D0.51,*;q=3D0.1 >>> >>> The q-values differences are within 0.1 so it=20 >>> is a preference for getting both together,=20 >>> but if that is not possible, text is=20 >>> preferred. >>> >>> >>> 2.3. Add to the new a=3Dmodality attribute a=20 >>> fourth, optional parameter [simultaneity]=20 >>> with value any single letter, indicating a=20 >>> preference for having that modality=20 >>> simultaneously with another modality=20 >>> indicated with the same value in the=20 >>> [simultaneity] parameter. Without this=20 >>> parameter, the modalities are alternatives. >>> >>> m=3Dtext >>> a=3Dmodality:written,recv,hi,d >>> a=3Dhlang-recv:en* >>> m=3Daudio >>> a=3Dmodality:spoken,recv,hi,d >>> a=3Dhlang-recv:en* >>> >>> >>> >>> Status: Not solved. Conclusion needed on how=20 >>> to handle these issues e, f, and j, both=20 >>> regarding which solution and what procedure=20 >>> to take to apply it. >>> >>> I have a slight preference for solution 1.2 and 2.2 , >>> >>> Your views? >>> >>> Regards >>> Gunnar >>> -- >>> ----------------------------------------- >>> Gunnar Hellstr=F6m >>> Omnitor >>> gunnar.hellstrom@omnitor.se >>> +46 708 204 288 >>> >>> >>> _______________________________________________ >>> SLIM mailing list >>> SLIM@ietf.org >>>=20 >>> 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 -- 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 Tue Mar 14 04:02:12 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEAE612943B for ; Tue, 14 Mar 2017 04:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gsmasso.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVf84UdTODhv for ; Tue, 14 Mar 2017 04:02:05 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40043.outbound.protection.outlook.com [40.107.4.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC940129535 for ; Tue, 14 Mar 2017 04:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=GSMASSO.onmicrosoft.com; s=selector1-gsma-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fxPavT2lBN2QS2cTeDHmHZyYFEb2W2XD+XiumUJ7p8k=; b=X1mzZGWQMQd/C1rWjhVHEjQBGolOFbDpowUW2Cd3imMAlEpzFifrlzXQLjWrB2BWMcPEu9+SUkFqjuC0XjE7QoXDjNJhJfL72zN312XerelgXhItVHqVo+U1CvcC6FIotTBv10JojN/xWwnwiSXaPQq5nx2v8fTDbzc9nblxy9Y= Received: from HE1PR04MB3113.eurprd04.prod.outlook.com (10.171.196.31) by HE1PR04MB3113.eurprd04.prod.outlook.com (10.171.196.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Tue, 14 Mar 2017 11:02:02 +0000 Received: from HE1PR04MB3113.eurprd04.prod.outlook.com ([10.171.196.31]) by HE1PR04MB3113.eurprd04.prod.outlook.com ([10.171.196.31]) with mapi id 15.01.0947.022; Tue, 14 Mar 2017 11:02:02 +0000 From: Natasha Rooney To: Randall Gellens Thread-Topic: [Slim] Extended functionality for the real-time language negotiation Thread-Index: AQHSl45tj3XHCrxq9EGVI7oeYSQZkKGOaFsAgAAFtQCABQq3gIAAvOyA Date: Tue, 14 Mar 2017 11:02:02 +0000 Message-ID: <642B8F42-1648-4B22-AB14-45980A2104A2@gsma.com> References: <084a066e-ea68-d614-58e1-08c904f477ea@omnitor.se> <60797269-4dad-5f48-3184-b8fbca42c30c@realtimetext.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) authentication-results: randy.pensive.org; dkim=none (message not signed) header.d=none; randy.pensive.org; dmarc=none action=none header.from=gsma.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [146.198.144.67] x-ms-office365-filtering-correlation-id: 58a87c6e-1b95-4d25-eefc-08d46ac98b37 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:HE1PR04MB3113; x-microsoft-exchange-diagnostics: 1; HE1PR04MB3113; 7:X5LA+DAJzAdtutqwaZSuJzraeWe+oZb74wnO4fSXnUmVJngjSNOA7IXO1nlH/siWWlv4Zk12HHEeyfXj3s+qULJImRb1rAEWE/1KdmM4IEHDeeEEWlWblTP0b6bDHxttTnsKFAavqj7Ltqn3kQSDNYe63e3PgvaD5zVAdzK/uMCuoWNiHT2JJkCxSCqPEAdKQb0nvm0gb7090bKfrrZ4d26F17yCkU5YBeWRybVQjWiOMB1ujcPdJyZX7yf4+XrjETsHiHzhOv0XhIVI3f6tO82f6vpBUNsS9jgNmc4uqmZ3RHN3Mcbkk7RBM0v9Bq6rgCZxoNF8LV2IFIfnB8j1cg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123558025)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(6072148); SRVR:HE1PR04MB3113; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB3113; x-forefront-prvs: 02462830BE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39450400003)(51444003)(24454002)(377454003)(561944003)(6246003)(7736002)(81166006)(93886004)(122556002)(86362001)(50226002)(5660300001)(57306001)(33656002)(53546007)(54896002)(5890100001)(236005)(6306002)(6512007)(2900100001)(54906002)(8676002)(53936002)(3846002)(110136004)(102836003)(38730400002)(6116002)(4326008)(7906003)(99286003)(3660700001)(50986999)(229853002)(8936002)(106116001)(3280700002)(6506006)(76176999)(2906002)(189998001)(6436002)(66066001)(2950100002)(25786008)(6486002)(77096006)(36756003)(606005)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB3113; H:HE1PR04MB3113.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_642B8F4216484B22AB1445980A2104A2gsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2017 11:02:02.1502 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB3113 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: HE1PR04MB3113.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 146.198.144.67 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: HE1PR04MB3113.eurprd04.prod.outlook.com Archived-At: Cc: "arnoud.vanwijk@realtimetext.org" , "slim@ietf.org" , =?utf-8?B?R3VubmFyIEhlbGxzdHLDtm0=?= , Brian Rosen Subject: Re: [Slim] Extended functionality for the real-time language negotiation X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 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, 14 Mar 2017 11:02:10 -0000 --_000_642B8F4216484B22AB1445980A2104A2gsmacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TXlzZWxmIGFuZCBCZXJuYXJkIGFyZSBkaXNjdXNzaW5nIHRoaXMgc2l0dWF0aW9uIGN1cnJlbnRs eSBpbiBhbiBlZmZvcnQgdG8gc29sdmUgdGhlIG91dHN0YW5kaW5nIGlzc3VlcyBhbmQgZ2V0IHRo ZSBkcmFmdCBwdXNoZWQgdGhyb3VnaC4gV2UgaGF2ZSBoZWFyZCBvcGluaW9ucyBmcm9tIGEgbnVt YmVyIG9mIHBlb3BsZSwgd2hpY2ggaXMgZ3JlYXQuIFdl4oCZbGwgZ2V0IGJhY2sgdG8gZXZlcnlv bmUgc2hvcnRseSBvbiBob3cgd2Ugd2lsbCBwcm9jZWVkLg0KDQpOYXRhc2hhIFJvb25leSB8IElu dGVybmV0IEVuZ2luZWVyaW5nIERpcmVjdG9yIHwgSW50ZXJuZXQgYW5kIFdlYiBUZWFtIHwgVGVj aG5vbG9neSB8IEdTTUEgfCBucm9vbmV5QGdzbWEuY29tPG1haWx0bzpucm9vbmV5QGdzbWEuY29t PiB8ICs0NCAoMCkgNzczMCAyMTkgNzY1IHwgQHRoaXNOYXRhc2hhIHwgU2t5cGU6IG5yb29uZXlA Z3NtLm9yZzxtYWlsdG86bnJvb25leUBnc20ub3JnPg0KDQpPbiAxMyBNYXIgMjAxNywgYXQgMjM6 NDUsIFJhbmRhbGwgR2VsbGVucyA8cmcraWV0ZkByYW5keS5wZW5zaXZlLm9yZzxtYWlsdG86cmcr aWV0ZkByYW5keS5wZW5zaXZlLm9yZz4+IHdyb3RlOg0KDQpJIGFncmVlIHdpdGggQnJpYW4uICBU aGUgZHJhZnQgZGVmaW5lcyBhIHZlcnkgc2ltcGxlIG1lY2hhbmlzbSwgYXMgYWdyZWVkIGluIHRo ZSBXRy4gIFRoZSBkcmFmdCBoYXMgYmVlbiB0aHJvdWdoIFdHIGRpc2N1c3Npb24sIFdHIGxhc3Qg Y2FsbCwgYW5kIElFVEYgbGFzdCBjYWxsLiAgSSB3b3VsZCBvYmplY3QgdG8gcmVvcGVuaW5nIHRo ZSBkcmFmdCB0byBhZGQgcS12YWx1ZXMgb3IgYW55dGhpbmcgZWxzZS4NCg0KV2UgY2FuIGFkdmFu Y2UgdGhlIGN1cnJlbnQgZHJhZnQgYW5kIHN0YXJ0IHdvcmsgb24gYSBtb3JlIGNvbXBsZXggbWVj aGFuaXNtLiAgVGhpcyB3b3VsZCBtZWFuIHdlIGhhdmUgc29tZXRoaW5nIHRoYXQgaXMgc2ltcGxl IGFuZCB1c2VmdWwgcHVibGlzaGVkLiAgT3Igd2UgY2FuIHJldmVydCB0aGUgZHJhZnQgYmFjayBp bnRvIHRoZSBXRywgYW5kIHNwZW5kIG1vbnRocyBkaXNjdXNzaW5nIGl0LiAgTm90IG9ubHkgd291 bGQgdGhpcyBuZWVkbGVzc2x5IGFkZCBtYWpvciBkZWxheSB0byB0aGUgZHJhZnQsIGJ1dCB0aGVy ZSBpcyBhIHJlYWwgcmlzayB0aGF0IHdlIGFsbCBnZXQgc2ljayBvZiBpdCBhbmQgdGhlIEFEIHNo dXRzIGRvd24gdGhlIFdHLg0KDQpBdCAxOjQ2IFBNIC0wNTAwIDMvMTAvMTcsIEJyaWFuIFJvc2Vu IHdyb3RlOg0KDQpXZSBzZWVtIHRvIGJlIHJ1bm5pbmcgaW4gY2lyY2xlcy4NCg0KVGhlIHdvcmsg Z3JvdXAgaGFzIGRpc2N1c3NlZCB0aGUgaWRlYSBvZiBpbmRpY2F0aW5nIG1lZGlhICYgbGFuZ3Vh Z2UgY29tYmluYXRpb24gcHJlZmVyZW5jZXMgYW5kIERFQ0xJTkVELCBhdCB0aGlzIHRpbWUgdG8g ZG8gdGhhdC4gIFdlIGRlY2lkZWQgb3VyIGZpcnN0IGVmZm9ydCB3b3VsZCBiZSB0byBsYWJlbCBs YW5ndWFnZSBwcmVmZXJlbmNlcyBwZXIgbWVkaWEsIHdpdGggbm8gY3Jvc3MgbWVkaWEgcHJlZmVy ZW5jZXMuICBUaGF0IGRvZXNuJ3QgbWVhbiB3ZSB3b24ndCBldmVyIGRvIGl0LiAgSXQgbWVhbnMg b3VyIGZpcnN0IGRvY3VtZW50IG9uIFNEUCBuZWdvdGlhdGlvbiB3b24ndCBjb3ZlciB0aGF0IGNh c2UuDQoNCllldCB5b3Uga2VlcCB0cnlpbmcgdG8gZ2V0IGl0IGluIHRoZSBjdXJyZW50IGRvY3Vt ZW50Lg0KDQpJIGRvbid0IHdhbnQgdG8gcmV2aXNpdCBvdXIgZGVjaXNpb24sIGFuZCBJIGRvbid0 IHdhbnQgdG8gc2VlIGFueSBsaW5rYWdlIGJldHdlZW4gbWVkaWEgaW4gdGhpcyBkb2N1bWVudC4g IEkgYWNjZXB0IHRoZXJlIGFyZSByZXF1aXJlbWVudHMgdG8gaGF2ZSBzdWNoIGxpbmthZ2VzLCBi dXQgdGhpbmsgdGhlcmUgYXJlIG1hbnkuIG1hbnkgdXNlcyBmb3IgYSBzaW1wbGVyIG1lY2hhbmlz bSBzdWNoIGFzIHdoYXQgdGhlIGN1cnJlbnQgZG9jdW1lbnQgZGlzY3Vzc2VzLg0KDQpJZiB5b3Ug d2FudCB0byB3cml0ZSBhIGRyYWZ0IHRoYXQgcHJvcG9zZXMgYW4gZXh0ZW5zaW9uIHRvIHRoZSBj dXJyZW50IG1lY2hhbmlzbSwgcGxlYXNlIHdyaXRlIGl0LCBhbmQgSSdsbCByZXZpZXcgaXQuICBC dXQgSSB3b3VsZCBsaWtlIHRvIHNlZSB0aGlzIGRvY3VtZW50IHB1Ymxpc2hlZCB3aXRoIHRoZSBz aW1wbGUgcGVyLW1lZGlhIHByZWZlcmVuY2UuDQoNCkJyaWFuDQoNCg0KT24gTWFyIDEwLCAyMDE3 LCBhdCAxOjI1IFBNLCBBcm5vdWQgdmFuIFdpamsgPDxtYWlsdG86YXJub3VkLnZhbndpamtAcmVh bHRpbWV0ZXh0Lm9yZz5hcm5vdWQudmFud2lqa0ByZWFsdGltZXRleHQub3JnPG1haWx0bzphcm5v dWQudmFud2lqa0ByZWFsdGltZXRleHQub3JnPj4gd3JvdGU6DQoNCkhpIEd1bm5hciwNCg0KSSBh bHNvIHByZWZlciBzb2x1dGlvbiAxLjIgYW5kIDIuMg0KDQpJIGxpa2UgdGhlIHVzZSBvZiBxIHZh bHVlcyBoZXJlLiBJIHRoaW5rIHRoYXQgaXMgYmV0dGVyIHRoZW4gYWRkaW5nIGEgbmV3IGF0dHJp YnV0ZS4NCg0KDQpHb29kIHByb3Bvc2FsLg0KDQoNCi9Bcm5vdWQNCg0KDQoNCk9uIDA3LzAzLzIw MTcgMTQ6MDEsIEd1bm5hciBIZWxsc3Ryw7ZtIHdyb3RlOg0KDQpUaGlzIGlzIGEgc2xpZ2h0bHkg aW1wcm92ZWQgZXh0cmFjdCBmcm9tIHRoZSBzdW1tYXJ5IG9mIHRoZSBMQyBwZXJpb2QgZm9yIHRo ZSByZWFsLXRpbWUgU0xJTSBkcmFmdCBhYm91dCB0d28gZGlzY3Vzc2VkIGZ1bmN0aW9uYWxpdHkg ZXh0ZW5zaW9ucy4gKFNvbWUgb2YgdGhlIGV4YW1wbGVzIGhhZCBjb3B5LXBhc3RlIGVycm9ycy4p DQoNClRoZSBpbnRlbnRpb24gaXMgdG8gZGlzY3VzcyB0aGlzIHRvcGljIGFzIGZhciBhcyBuZWVk ZWQgdG8gZGVjaWRlIGlmIGFueSBvciBib3RoIHRoZXNlIGZ1bmN0aW9uYWxpdHkgZW5oYW5jZW1l bnRzIGNvdWxkIGdvIGludG8gdGhlIGN1cnJlbnQgZHJhZnQgYmVmb3JlIHB1YmxpY2F0aW9uLCBh bmQgaWYgbm90IGluY2x1ZGVkIHRoZW4gZGVjaWRlIGlmIGFueSBjaGFuZ2VzIGFyZSByZXF1aXJl ZCBpbiB0aGUgY3VycmVudCBkcmFmdCBpbiBvcmRlciB0byBhY2NvbW1vZGF0ZSBmb3IgdGhlIGV4 dGVuc2lvbnMuDQoNCihzZWUgdGhlIHN1bW1hcnkgc2VudCBvbiBNYXJjaCA0IGZvciBlLmcuIHJl ZmVyZW5jZXMgdG8gdGhlIG90aGVyIHN1bW1hcnkgcG9pbnRzLg0KDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCm4pLiBJbmRpY2F0aW9uIG9mIHBy ZWZlcmVuY2UgYmV0d2VlbiBtZWRpYSwgYW5kIG9mIHNpbXVsdGFub3VzIHZlcnN1cyBhbHRlcm5h dGl2ZSBsYW5ndWFnZXMuDQoNClRoaXMgaXMgYSBzdW1tYXJ5IG9mIHRoZSByZW1haW5pbmcgaXNz dWVzIHJlbGF0ZWQgdG8gaXRlbXMgZSksIGYpLCBqKSBhbmQgbSkgYWJvdmUuDQoNCklzc3VlIGUp IHByb3Bvc2VzIGNoYW5nZXMgdG8gZW5hYmxlIGluZGljYXRpb24gb2YgcHJlZmVyZW5jZSBmb3Ig bGFuZ3VhZ2UgaW4gZGlmZmVyZW50IG1lZGlhLg0KSXNzdWUgZikgcmVxdWVzdHMgcG9zc2liaWxp dHkgdG8gaW5kaWNhdGUgcmVxdWVzdCBvciBvZmZlcmluZyBvZiB0ZXh0IGNhcHRpb25zIG9mIHNw b2tlbiBsYW5ndWFnZS4NCklzc3VlIGopIHByb3Bvc2VzIHVzZSBvZiB0aGUgQWNjZXB0LUxhbmd1 YWdlIHN5bnRheCwgdGhhdCBjb3VsZCBib3RoIHNvbHZlIHRoZSBmdW5jdGlvbmFsIG5lZWRzDQpv ZiBlKSBhbmQgZikgYW5kIHNvcnQgb3V0IHRoZSBzeW50YXggYW5kIHNlbWFudGljcyBwcm9ibGVt cyBvZiB0aGUgYXN0ZXJpc2sgcGFyYW1ldGVyLg0KSXNzdWUgbSkganVzdCBpbmRpY2F0ZXMgdGhh dCBpc3N1ZSBlKSBpcyBub3QgeWV0IHJlc29sdmVkLg0KDQpSYW5kYWxsIGhhcyBwcm9wb3NlZCB0 byByZXNvbHZlIHRoZSBmdW5jdGlvbmFsIG5lZWRzIGluIGEgbmV3IGRyYWZ0LCBhbmQgbm90IGFj Y2VwdCB0aGUgQWNjZXB0LUxhbmd1YWdlIHN5bnRheC4NCkkgaGF2ZSBwcm9wb3NlZCBhIHNpbXBs ZSB3YXkgdG8gcmVzb2x2ZSBpc3N1ZSBlKSAtIHRoZSBwcmVmZXJlbmNlIGJldHdlZW4gbWVkaWEs IGF0IHRoZSBzYW1lIHRpbWUgaW1wcm92aW5nIHRoZSBkZWZpbml0aW9uIG9mIHRoZSBzZW1hbnRp Y3Mgb2YgdGhlIGFzdGVyaXNrIHBhcmFtZXRlci4NCk5vIHJlYWwgc29sdXRpb24gdG8gaXNzdWUg ZikgLSB0aGUgc2ltdWx0YW5laXR5IGluZGljYXRpb24gIGhhcyBiZWVuIGRpc2N1c3NlZC4NCklz c3VlIGopIC0gdGhlIHByb3Bvc2FsIHRvIHVzZSB0aGUgQWNjZXB0LUxhbmd1YWdlIHN5bnRheCBj YW4gcG90ZW50aWFsbHkgYmUgdXNlZCB0byByZXNvbHZlIGlzc3VlcyBlKSBhbmQgZikuDQoNCiBE aXNjdXNzaW9uOg0KSXNzdWUgZSkgc2F5cyB0aGF0IHRoZXJlIGlzIGEgbmVlZCB0byBiZSBhYmxl IGluZGljYXRlIHdoaWNoIG9mIGEgc2V0IG9mIGxhbmd1YWdlL21lZGlhIGluZGljYXRpb25zIGFy ZSBtb3JlIHByZWZlcnJlZCBhbHRlcm5hdGl2ZXMgdGhhbiBvdGhlcnMuDQpFeGFtcGxlcyBhcmU6 DQoxLiBBIHdhbnQgdG8gZ2V0IHdyaXR0ZW4gRW5nbGlzaCBpbiB0ZXh0LCBBIGNhbiBhcyBhIGxl c3MgcHJlZmVycmVkIGFsdGVybmF0aXZlIGFjY2VwdCB0byBnZXQgc3Bva2VuIEVuZ2xpc2guICBB biBhbnN3ZXJpbmcgcGFydHkgQiB3aG8gY2FuIHVzZSB0ZXh0IHdpbGwgdGhlbiByZXNwb25kIHdp dGggd3JpdHRlbiB0ZXh0IGFuZCBnZXQgZ29vZCBzYXRpc2ZhY3Rpb24sIHdoaWxlIGFub3RoZXIg YW5zd2VyaW5nIHVzZXIgQyB3aXRob3V0IHRleHQgY2FwYWJpbGl0eSB3aWxsIGFuc3dlciBpbiBz cG9rZW4gRW5nbGlzaCBhbmQgaGF2ZSBhIHBvc3NpYmlsaXR5IGZvciBhIHJlYXNvbmFibHkgc3Vj Y2Vzc2Z1bCBjYWxsLg0KV2l0aG91dCB0aGlzIGluZGljYXRpb24sIHRoZSBmaXJzdCBhbnN3ZXJp bmcgcGFydHkgQiBtYXkgaGF2ZSBzZWVuIHRoZSBzcG9rZW4gYW5kIHdyaXR0ZW4gYWx0ZXJuYXRp dmVzIGFzIHRydWUgZXF1YWwgcHJlZmVyZW5jZSBhbHRlcm5hdGl2ZXMgYW5kIGFuc3dlcmVkIHdp dGggc3Bva2VuIEVuZ2xpc2ggdGhhdCB3aWxsIHJlc3VsdCBpbiBsZXNzIHNhdGlzZmllZCB1c2Vy cy4NCjIuIEEgUHJlZmVyIHRvIHJlY2VpdmUgc3Bva2VuIGxhbmd1YWdlLCBhbmQgY2FuIGFjY2Vw dCB0byByZWNlaXZlIHRleHQuICAgV2hlbiBhbnN3ZXJpbmcgcGFydHkgQiBjYW4gdXNlIHNwb2tl biBsYW5ndWFnZSwgdGhhdCB3aWxsIGJlIHNhdGlzZmllZCwgb3RoZXJ3aXNlIHdyaXR0ZW4gbGFu Z3VhZ2Ugd2lsbCBiZSB1c2VkLg0KMy4gQSBQcmVmZXIgdG8gdXNlIHNwb2tlbiBsYW5ndWFnZSBp biBib3RoIGRpcmVjdGlvbnMsIGFuZCBjYW4gYWNjZXB0IHRvIHVzZSBzaWduIGxhbmd1YWdlIGlu IHZpZGVvIGluIGJvdGggZGlyZWN0aW9ucy4gQW5zd2VyaW5nIHBhcnR5IEIgaGFzIGEgY2xlYXIg aW5kaWNhdGlvbiBvZiB3aHkgYm90aCBzaWduZWQgYW5kIHdyaXR0ZW4gaXMgaW5kaWNhdGVkIGFu ZCBjYW4gYW5zd2VyIGFjY29yZGluZyB0byBpdHMgY2FwYWJpbGl0aWVzIHRyeWluZyB0byBzYXRp c2Z5IHRoZSBwcmVmZXJlbmNlIGZvciBzcG9rZW4gbGFuZ3VhZ2UuDQo0LiBBIFByZWZlciB0byB1 c2UgIHNpZ24gbGFuZ3VhZ2UgaW4gYm90aCBkaXJlY3Rpb25zIGFuZCBjYW4gYWNjZXB0IHRvIHVz ZSB3cml0dGVuIGxhbmd1YWdlIGluIGJvdGggZGlyZWN0aW9ucy4gU2lnbiBsYW5ndWFnZSB1c2Vy cyB3aWxsIHVzZSBzaWduIGxhbmd1YWdlLCBvdGhlcnMgd2lsbCB1c2UgdGV4dC4NCjUuIFByZWZl ciB0byBzZW5kIHNpZ24gbGFuZ3VhZ2UgYW5kIHJlY2VpdmUgdGV4dCAoZGVhZi1ibGluZCB1c2Vy KSwgY2FuIGFjY2VwdCB0byBzZW5kIHRleHQuICBJbiBhIGNhbGwgd2l0aCBhIHBlcnNvbiB3aXRo IHNpbWlsYXIgcHJlZmVlbmNlcywgdGV4dCB3aWxsIGJlIHVzZWQgYm90aCB3YXlzLCBvdGhlcndp c2Ugc2lnbiBvbmUgd2F5IGFuZCB0ZXh0IHRoZSBvdGhlci4NCg0KZXRjLg0KDQpJc3N1ZSBmKSBy ZXF1aXJlcyBhIHdheSB0byBpbmRpY2F0ZSB1c2Ugb2YgY2FwdGlvbmluZyBhbmQgb3RoZXIgc2l0 dWF0aW9ucyB3aGVyZSB1c2Ugb2Ygc2ltdWx0YW5lb3VzIGxhbmd1YWdlcyBpbiBkaWZmZXJlbnQg bW9kYWxpdGllcyBhcmUgbmVlZGVkOg0KDQoxLiBQcmVmZXJlbmNlIGZvciBoZWFyaW5nIHNwb2tl biBsYW5ndWFnZSBhbmQgc2ltdWx0YW5lb3VzbHkgcmVhZCB3cml0dGVuIGxhbmd1YWdlIGluIHRl eHQuICggY2FwdGlvbmluZykgLiAgIFRoZSB0aW1lIGlzIGhlcmUgd2hlbiB0aGlzIGNhbiBiZSBw cm92aWRlZCBhdXRvbWF0aWNhbGx5IGluIHNvbWUgc2V0dGluZ3MsIGJ1dCBhbHNvIHRyYWRpdGlv bmFsbHkgYnkgYSBtYW5uZWQgc2VydmljZS4NCjIuIFByZWZlcmVuY2UgZm9yIGhlYXJpbmcgc3Bv a2VuIGxhbmd1YWdlIGFuZCBzaW11bHRhbmVvdXNseSBzZWVpbmcgdGhlIHNwZWFrZXIgaW4gdmlk ZW8uIChsaXAtcmVhZGluZykuICBFYXNpbHkgYW5kIG5hdHVyYWxseSBwcm92aWRlZCBvbmNlIHRo ZSBuZWVkIGlzIGtub3duLg0KMy4gUHJlZmVyZW5jZSBmb3Igc2VlaW5nIHNpZ24gbGFuZ3VhZ2Ug YW5kIHNpbXVsdGFuZW91c2x5IGhlYXIgc3Bva2VuIGxhbmd1YWdlIGluIGF1ZGlvLiAoIGZvciBt dWx0aXBsZSB1c2VycyBhdCB0aGUgdGVybWluYWwgKSAgICBPbmUgb2YgdGhlIHN0cmVhbXMgaXMg cHJvdmlkZWQgYnkgYW4gaW50ZXJwcmV0ZXIuDQo0LiBQcmVmZXJlbmNlIGZvciBoZWFyaW5nIHNw b2tlbiBsYW5ndWFnZSBhbmQgc2ltdWx0YW5lb3VzbHkgdmlldyB3cml0dGVuIGxhbmd1YWdlIGlu IHZpZGVvLiAoY2FwdGlvbmluZyBpZiB3ZSBhY2NlcHQgdG8gc3BlY2lmeSB0ZXh0IGFzIG92ZXJs YXkgb24gdmlkZW8sIG90aGVyd2lzZSBpdCBpcyBzYW1lIGFzIG51bWJlciAxLikNClNvbWUgb2Yg dGhlc2UgY2FuIGJlIGFjY2VwdGFibGUgYWxzbyBpZiBqdXN0IG9uZSBvZiB0aGUgbGFuZ3VhZ2Uv bWVkaWEgY29tYmluYXRpb25zIGNhbiBiZSBwcm92aWRlZCwgYnV0IGlzIG11Y2ggbW9yZSBwcmVm ZXJyZWQgaWYgYm90aCBjYW4gYmUgcHJvdmlkZWQgdG9nZXRoZXIuIEluIG90aGVyIGNhc2VzIGl0 IGlzIGVzc2VudGlhbCB0byBnZXQgYm90aCBzaW11bHRhbmVvdXNseS4gVGhlcmUgaXMgYSBuZWVk IHRvIGRpZmZlcmVudGlhdGUgaW4gdGhlIGluZGljYXRpb24gdGhhdCB0aGlzIHByZWZlcmVuY2Ug Zm9yIGdldHRpbmcgdGhlIGxhbmd1YWdlcyB0b2dldGhlciBpcyBwcmVmZXJyZWQuDQoNCkFsdGVy bmF0aXZlIGNvZGluZyBwcm9wb3NhbHM6DQoxLiBQcmVmZXJlbmNlIGJldHdlZW4gbGFuZ3VhZ2Uv bW9kYWxpdHkNCjEuMSBCYXNlZCBvbiBkcmFmdCAtMDgsIGFkZCB0aGUgY29kaW5nIG9mIGFuIGFz dGVyaXNrIGxhc3QgaW4gYW4gYXR0cmlidXRlIHRvIG1lYW4gbG93ZXIgcHJlZmVyZW5jZSBmb3Ig YSBsYW51Z2FnZS9tZWRpYSBjb21iaW5hdGlvbiB0aGFuIHRoZSBvbmUocykgd2l0aG91dCBhbiBh c3Rlcmlzay4NCmV4YW1wbGUNCm09YXVkaW8NCmE9aGxhbmctcmVjdjplbioNCm09dGV4dA0KYT1o bGFuZy1yZWN2OmVuDQoNCkF1ZGlvIGFuZCB0ZXh0IGFyZSBhbHRlcm5hdGl2ZXMgYW5kIHRleHQg cHJlZmVycmVkDQoNCjEuMi4gQ2hhbmdlIHRvIHRoZSBBY2NlcHQtTGFuZ3VhZ2Ugc3ludGF4IGFu ZCBsZXQgdGhlIHEtdmFsdWVzIGhhdmUgc2NvcGUgb3ZlciB0aGUgd2hvbGUgU0RQLg0KIG09dmlk ZW8gNTEzNzIgUlRQL0FWUCAzMSAzMg0KIGE9aGxhbmctcmVjdjphc2U7cT0wLjkNCiBhPWhsYW5n LXNlbmQ6YXNlO3E9MC45DQoNCg0KIG09dGV4dCA0OTI1MCBSVFAvQVZQIDk4LDk5DQogYT1obGFu Zy1zZW5kOmVuO3E9MC41LCo7cT0wLjENCiBhPWhsYW5nLXJlY3Y6ZW47cT0wLjUsKjtxPTAuMQ0K DQpTaWduIGxhbmd1YWdlIGlzIGhpZ2hlciBwcmVmZXJyZWQgdGhhbiB0ZXh0Lg0KDQoNCg0KDQoN CjEuMy4gSW50cm9kdWNlIGEgbmV3IGE9bW9kYWxpdHkgYXR0cmlidXRlIG9uIG1lZGlhIGxldmVs LCB3aXRoIHBhcmFtZXRlcnM6IDxtb2RhbGl0eT4sIDxkaXJlY3Rpb24+LCA8cHJlZmVyZW5jZT4g ICAgIGV4YW1wbGU6DQoNCm09dGV4dA0KYT1tb2RhbGl0eTp3cml0dGVuLHJlY3YsaGkNCmE9aGxh bmctcmVjdjplbioNCm09YXVkaW8NCmE9bW9kYWxpdHk6c3Bva2VuLHJlY3YsbWVkDQphPWhsYW5n LXJlY3Y6ZW4qDQoNCg0KDQoyLiBQcmVmZXJlbmNlIGZvciBzaW11bHRhbmVvdXMgbGFuZ3VhZ2Vz IHZzIGFsdGVybmF0aXZlIGxhbmd1YWdlczoNCg0KMi4xLiBCYXNlZCBvbiBkcmFmdCAtMDgsIGFk ZCBhbm90aGVyIG5vdGF0aW9uIHRvIHRoZSB1c2Ugb2YgdGhlIGFzdGVyaXNrLCBlLmcuIGFuIG9w dGlvbmFsIGNoYXJhY3RlciB0byBiZSB1c2VkIHRvZ2V0aGVyIHdpdGggdGhlIGFzdGVyaXNrIHRv IG1hcmsgbWVkaWEgdGhhdCBhcmUgd2FudGVkIHRvZ2V0aGVyLiAodWdseSkgICBleGFtcGxlOg0K DQptPWF1ZGlvDQphPWhsYW5nLXJlY3Y6ZW4qJGMNCm09dGV4dA0KYT1obGFuZy1yZWN2OmVuJGMN Cg0KVGhlICQgaXMgYSBzaW11bHRhbmVpdHkgaW5kaWNhdGlvbiwgdGhlIGMgaXMgYSBncm9vdXBp bmcgaW5kaWNhdG9yIHRlbGxpbmcgdGhhdCBhbGwgbW9kYWxpdGllcyBtYXJrZWQgd2l0aCB0aGUg JGMgYXJlIHdhbnRlZCB0b2dldGhlci4gKHdlIG1pZ2h0IGJlIGFibGUgdG8gcmVzdHJpY3QgdGhl IGluZGljYXRpb24gdG8ganVzdCBvbmUgc2V0IG9mIGxhbmd1YWdlcyB0aGF0IGFyZSB3YW50ZWQg c2ltdWx0YW5lb3VzbHkuDQoNCg0KMi4yLiBVc2UgdGhlIEFjY2VwdC1MYW5ndWFnZSBzeW50YXgg YW5kIGFkZCB0aGUgdXNhZ2UgcnVsZXMgdGhhdCBxLXZhbHVlcyB3aXRoIGxlc3MgdGhhbiAuMSBk aWZmZXJlbmNlIG1lYW4gbGFuZ3VhZ2VzIHdpdGggYSBwcmVmZXJlbmNlIHRvIGJlIHVzZWQgdG9n ZXRoZXIuIEhpZ2hlciBkaWZmZXJlbmNlcyBpbmRpY2F0ZSB0aGF0IHRoZXkgYXJlIGFsdGVybmF0 aXZlcy4gIFRoZXJlYnkgaXQgaXMgYm90aCBwb3NzaWJsZSB0byBpbmRpY2F0ZSBzaW11bHRhbmVp dHkgYW5kIHByZWZlcmVuY2UgaWYgdGhlIHNpbXVsdGFuZWl0eSBjYW5ub3QgYmUgc2F0aXNmaWVk Lg0KDQogbT1hdWRpbyA1MTM3MiBSVFAvQVZQIDANCiBhPWhsYW5nLXJlY3Y6YXNlO3E9MC41DQog YT1obGFuZy1zZW5kOmFzZTtxPTAuNQ0KDQoNCiBtPXRleHQgNDkyNTAgUlRQL0FWUCA5OCw5OQ0K IGE9aGxhbmctc2VuZDplbjtxPTAuNTEsKjtxPTAuMQ0KIGE9aGxhbmctcmVjdjplbjtxPTAuNTEs KjtxPTAuMQ0KDQpUaGUgcS12YWx1ZXMgZGlmZmVyZW5jZXMgYXJlIHdpdGhpbiAwLjEgc28gaXQg aXMgYSBwcmVmZXJlbmNlIGZvciBnZXR0aW5nIGJvdGggdG9nZXRoZXIsIGJ1dCBpZiB0aGF0IGlz IG5vdCBwb3NzaWJsZSwgdGV4dCBpcyBwcmVmZXJyZWQuDQoNCg0KMi4zLiBBZGQgdG8gdGhlIG5l dyBhPW1vZGFsaXR5IGF0dHJpYnV0ZSBhIGZvdXJ0aCwgb3B0aW9uYWwgcGFyYW1ldGVyIFtzaW11 bHRhbmVpdHldIHdpdGggdmFsdWUgYW55IHNpbmdsZSBsZXR0ZXIsIGluZGljYXRpbmcgYSBwcmVm ZXJlbmNlIGZvciBoYXZpbmcgdGhhdCBtb2RhbGl0eSBzaW11bHRhbmVvdXNseSB3aXRoIGFub3Ro ZXIgbW9kYWxpdHkgaW5kaWNhdGVkIHdpdGggdGhlIHNhbWUgdmFsdWUgaW4gdGhlIFtzaW11bHRh bmVpdHldIHBhcmFtZXRlci4gICBXaXRob3V0IHRoaXMgcGFyYW1ldGVyLCB0aGUgbW9kYWxpdGll cyBhcmUgYWx0ZXJuYXRpdmVzLg0KDQptPXRleHQNCmE9bW9kYWxpdHk6d3JpdHRlbixyZWN2LGhp LGQNCmE9aGxhbmctcmVjdjplbioNCm09YXVkaW8NCmE9bW9kYWxpdHk6c3Bva2VuLHJlY3YsaGks ZA0KYT1obGFuZy1yZWN2OmVuKg0KDQoNCg0KU3RhdHVzOiBOb3Qgc29sdmVkLiBDb25jbHVzaW9u IG5lZWRlZCBvbiBob3cgdG8gaGFuZGxlIHRoZXNlIGlzc3VlcyBlLCBmLCBhbmQgaiwgIGJvdGgg cmVnYXJkaW5nIHdoaWNoIHNvbHV0aW9uIGFuZCB3aGF0IHByb2NlZHVyZSB0byB0YWtlIHRvIGFw cGx5IGl0Lg0KDQpJIGhhdmUgYSBzbGlnaHQgcHJlZmVyZW5jZSBmb3Igc29sdXRpb24gMS4yIGFu ZCAyLjIgLA0KDQpZb3VyIHZpZXdzPw0KDQpSZWdhcmRzDQpHdW5uYXINCi0tDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KR3VubmFyIEhlbGxzdHLDtm0NCk9tbml0 b3INCjxtYWlsdG86Z3VubmFyLmhlbGxzdHJvbUBvbW5pdG9yLnNlPmd1bm5hci5oZWxsc3Ryb21A b21uaXRvci5zZTxtYWlsdG86Z3VubmFyLmhlbGxzdHJvbUBvbW5pdG9yLnNlPg0KKzQ2IDcwOCAy MDQgMjg4DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NClNMSU0gbWFpbGluZyBsaXN0DQo8bWFpbHRvOlNMSU1AaWV0Zi5vcmc+U0xJTUBpZXRmLm9y ZzxtYWlsdG86U0xJTUBpZXRmLm9yZz4NCjxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NsaW0+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zbGltDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClNMSU0g bWFpbGluZyBsaXN0DQo8bWFpbHRvOlNMSU1AaWV0Zi5vcmc+U0xJTUBpZXRmLm9yZzxtYWlsdG86 U0xJTUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2xp bQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N ClNMSU0gbWFpbGluZyBsaXN0DQpTTElNQGlldGYub3JnPG1haWx0bzpTTElNQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zbGltDQoNCg0KLS0NClJhbmRh bGwgR2VsbGVucw0KT3BpbmlvbnMgYXJlIHBlcnNvbmFsOyAgICBmYWN0cyBhcmUgc3VzcGVjdDsg ICAgSSBzcGVhayBmb3IgbXlzZWxmIG9ubHkNCi0tLS0tLS0tLS0tLS0tIFJhbmRvbWx5IHNlbGVj dGVkIHRhZzogLS0tLS0tLS0tLS0tLS0tDQpZb3UgbmV2ZXIgZmluaXNoIGEgcHJvZ3JhbSwgeW91 IGp1c3Qgc3RvcCB3b3JraW5nIG9uIGl0Lg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KU0xJTSBtYWlsaW5nIGxpc3QNClNMSU1AaWV0Zi5vcmc8bWFp bHRvOlNMSU1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NsaW0NCg0KDQpUaGlzIGVtYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgYXJlIGludGVuZGVkIGZv ciB0aGUgYWJvdmUgbmFtZWQgb25seSBhbmQgbWF5IGJlIGNvbmZpZGVudGlhbC4gSWYgdGhleSBo YXZlIGNvbWUgdG8geW91IGluIGVycm9yIHlvdSBtdXN0IHRha2Ugbm8gYWN0aW9uIGJhc2VkIG9u IHRoZW0sIG5vciBtdXN0IHlvdSBjb3B5IG9yIHNob3cgdGhlbSB0byBhbnlvbmU7IHBsZWFzZSBy ZXBseSB0byB0aGlzIGVtYWlsIG9yIGNhbGwgKzQ0IDIwNyAzNTYgMDYwMCBhbmQgaGlnaGxpZ2h0 IHRoZSBlcnJvci4NCg== --_000_642B8F4216484B22AB1445980A2104A2gsmacom_ Content-Type: text/html; charset="utf-8" Content-ID: <9F55FB4BEF2AE4489822F6F5472D86F9@eurprd04.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KTXlzZWxmIGFuZCBCZXJuYXJkIGFy ZSBkaXNjdXNzaW5nIHRoaXMgc2l0dWF0aW9uIGN1cnJlbnRseSBpbiBhbiBlZmZvcnQgdG8gc29s dmUgdGhlIG91dHN0YW5kaW5nIGlzc3VlcyBhbmQgZ2V0IHRoZSBkcmFmdCBwdXNoZWQgdGhyb3Vn aC4gV2UgaGF2ZSBoZWFyZCBvcGluaW9ucyBmcm9tIGEgbnVtYmVyIG9mIHBlb3BsZSwgd2hpY2gg aXMgZ3JlYXQuIFdl4oCZbGwgZ2V0IGJhY2sgdG8gZXZlcnlvbmUgc2hvcnRseSBvbiBob3cgd2Ug d2lsbCBwcm9jZWVkLiZuYnNwOzxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0 eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNp emU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsg Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0 bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4 OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsiPg0KPGJyIGNsYXNzPSIiPg0KTmF0YXNoYSBSb29uZXkgfCBJbnRlcm5ldCBFbmdp bmVlcmluZyZuYnNwO0RpcmVjdG9yIHwgSW50ZXJuZXQgYW5kIFdlYiBUZWFtIHwmbmJzcDtUZWNo bm9sb2d5IHwgR1NNQSB8Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOm5yb29uZXlAZ3NtYS5jb20iIGNs YXNzPSIiPm5yb29uZXlAZ3NtYS5jb208L2E+Jm5ic3A7fCAmIzQzOzQ0ICgwKSA3NzMwIDIxOSZu YnNwOzc2NSB8IEB0aGlzTmF0YXNoYSB8IFNreXBlOiZuYnNwOzxhIGhyZWY9Im1haWx0bzpucm9v bmV5QGdzbS5vcmciIGNsYXNzPSIiPm5yb29uZXlAZ3NtLm9yZzwvYT48L2Rpdj4NCjwvZGl2Pg0K PGJyIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj5PbiAxMyBNYXIgMjAxNywgYXQgMjM6NDUsIFJhbmRhbGwgR2VsbGVucyAm bHQ7PGEgaHJlZj0ibWFpbHRvOnJnJiM0MztpZXRmQHJhbmR5LnBlbnNpdmUub3JnIiBjbGFzcz0i Ij5yZyYjNDM7aWV0ZkByYW5keS5wZW5zaXZlLm9yZzwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJy IGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPkkgYWdyZWUgd2l0aCBCcmlhbi4gJm5ic3A7VGhlIGRyYWZ0IGRlZmluZXMgYSB2 ZXJ5IHNpbXBsZSBtZWNoYW5pc20sIGFzIGFncmVlZCBpbiB0aGUgV0cuICZuYnNwO1RoZSBkcmFm dCBoYXMgYmVlbiB0aHJvdWdoIFdHIGRpc2N1c3Npb24sIFdHIGxhc3QgY2FsbCwgYW5kIElFVEYg bGFzdCBjYWxsLiAmbmJzcDtJIHdvdWxkIG9iamVjdCB0byByZW9wZW5pbmcgdGhlIGRyYWZ0IHRv IGFkZCBxLXZhbHVlcyBvciBhbnl0aGluZyBlbHNlLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCldlIGNhbiBhZHZhbmNlIHRoZSBjdXJyZW50IGRyYWZ0IGFuZCBzdGFydCB3b3JrIG9uIGEg bW9yZSBjb21wbGV4IG1lY2hhbmlzbS4gJm5ic3A7VGhpcyB3b3VsZCBtZWFuIHdlIGhhdmUgc29t ZXRoaW5nIHRoYXQgaXMgc2ltcGxlIGFuZCB1c2VmdWwgcHVibGlzaGVkLiAmbmJzcDtPciB3ZSBj YW4gcmV2ZXJ0IHRoZSBkcmFmdCBiYWNrIGludG8gdGhlIFdHLCBhbmQgc3BlbmQgbW9udGhzIGRp c2N1c3NpbmcgaXQuICZuYnNwO05vdCBvbmx5IHdvdWxkIHRoaXMgbmVlZGxlc3NseQ0KIGFkZCBt YWpvciBkZWxheSB0byB0aGUgZHJhZnQsIGJ1dCB0aGVyZSBpcyBhIHJlYWwgcmlzayB0aGF0IHdl IGFsbCBnZXQgc2ljayBvZiBpdCBhbmQgdGhlIEFEIHNodXRzIGRvd24gdGhlIFdHLjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCkF0IDE6NDYgUE0gLTA1MDAgMy8xMC8xNywgQnJpYW4gUm9z ZW4gd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSIgY2xhc3M9IiI+V2Ugc2VlbSB0byBiZSBydW5uaW5nIGluIGNpcmNsZXMuPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhlIHdvcmsgZ3JvdXAgaGFzIGRpc2N1c3NlZCB0aGUgaWRl YSBvZiBpbmRpY2F0aW5nIG1lZGlhICZhbXA7IGxhbmd1YWdlIGNvbWJpbmF0aW9uIHByZWZlcmVu Y2VzIGFuZCBERUNMSU5FRCwgYXQgdGhpcyB0aW1lIHRvIGRvIHRoYXQuICZuYnNwO1dlIGRlY2lk ZWQgb3VyIGZpcnN0IGVmZm9ydCB3b3VsZCBiZSB0byBsYWJlbCBsYW5ndWFnZSBwcmVmZXJlbmNl cyBwZXIgbWVkaWEsIHdpdGggbm8gY3Jvc3MgbWVkaWEgcHJlZmVyZW5jZXMuICZuYnNwO1RoYXQg ZG9lc24ndA0KIG1lYW4gd2Ugd29uJ3QgZXZlciBkbyBpdC4gJm5ic3A7SXQgbWVhbnMgb3VyIGZp cnN0IGRvY3VtZW50IG9uIFNEUCBuZWdvdGlhdGlvbiB3b24ndCBjb3ZlciB0aGF0IGNhc2UuPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KWWV0IHlvdSBrZWVwIHRyeWluZyB0byBnZXQgaXQg aW4gdGhlIGN1cnJlbnQgZG9jdW1lbnQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSSBk b24ndCB3YW50IHRvIHJldmlzaXQgb3VyIGRlY2lzaW9uLCBhbmQgSSBkb24ndCB3YW50IHRvIHNl ZSBhbnkgbGlua2FnZSBiZXR3ZWVuIG1lZGlhIGluIHRoaXMgZG9jdW1lbnQuICZuYnNwO0kgYWNj ZXB0IHRoZXJlIGFyZSByZXF1aXJlbWVudHMgdG8gaGF2ZSBzdWNoIGxpbmthZ2VzLCBidXQgdGhp bmsgdGhlcmUgYXJlIG1hbnkuIG1hbnkgdXNlcyBmb3IgYSBzaW1wbGVyIG1lY2hhbmlzbSBzdWNo IGFzIHdoYXQgdGhlIGN1cnJlbnQgZG9jdW1lbnQgZGlzY3Vzc2VzLjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCklmIHlvdSB3YW50IHRvIHdyaXRlIGEgZHJhZnQgdGhhdCBwcm9wb3NlcyBh biBleHRlbnNpb24gdG8gdGhlIGN1cnJlbnQgbWVjaGFuaXNtLCBwbGVhc2Ugd3JpdGUgaXQsIGFu ZCBJJ2xsIHJldmlldyBpdC4gJm5ic3A7QnV0IEkgd291bGQgbGlrZSB0byBzZWUgdGhpcyBkb2N1 bWVudCBwdWJsaXNoZWQgd2l0aCB0aGUgc2ltcGxlIHBlci1tZWRpYSBwcmVmZXJlbmNlLjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkJyaWFuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+T24gTWFy IDEwLCAyMDE3LCBhdCAxOjI1IFBNLCBBcm5vdWQgdmFuIFdpamsgJmx0OyZsdDs8YSBocmVmPSJt YWlsdG86YXJub3VkLnZhbndpamtAcmVhbHRpbWV0ZXh0Lm9yZyIgY2xhc3M9IiI+bWFpbHRvOmFy bm91ZC52YW53aWprQHJlYWx0aW1ldGV4dC5vcmc8L2E+Jmd0OzxhIGhyZWY9Im1haWx0bzphcm5v dWQudmFud2lqa0ByZWFsdGltZXRleHQub3JnIiBjbGFzcz0iIj5hcm5vdWQudmFud2lqa0ByZWFs dGltZXRleHQub3JnPC9hPiZndDsNCiB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQpIaSBHdW5uYXIsPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSSBhbHNvIHByZWZlciBz b2x1dGlvbiAxLjIgYW5kIDIuMjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkkgbGlrZSB0 aGUgdXNlIG9mIHEgdmFsdWVzIGhlcmUuIEkgdGhpbmsgdGhhdCBpcyBiZXR0ZXIgdGhlbiBhZGRp bmcgYSBuZXcgYXR0cmlidXRlLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCkdvb2QgcHJvcG9zYWwuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KL0Fybm91ZDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCk9uIDA3LzAzLzIwMTcgMTQ6MDEsIEd1bm5hciBIZWxsc3Ryw7Zt IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiIGNsYXNzPSIiPlRoaXMgaXMgYSBzbGlnaHRseSBpbXByb3ZlZCBleHRyYWN0IGZyb20gdGhl IHN1bW1hcnkgb2YgdGhlIExDIHBlcmlvZCBmb3IgdGhlIHJlYWwtdGltZSBTTElNIGRyYWZ0IGFi b3V0IHR3byBkaXNjdXNzZWQgZnVuY3Rpb25hbGl0eSBleHRlbnNpb25zLiAoU29tZSBvZiB0aGUg ZXhhbXBsZXMgaGFkIGNvcHktcGFzdGUgZXJyb3JzLik8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQpUaGUgaW50ZW50aW9uIGlzIHRvIGRpc2N1c3MgdGhpcyB0b3BpYyBhcyBmYXIgYXMgbmVl ZGVkIHRvIGRlY2lkZSBpZiBhbnkgb3IgYm90aCB0aGVzZSBmdW5jdGlvbmFsaXR5IGVuaGFuY2Vt ZW50cyBjb3VsZCBnbyBpbnRvIHRoZSBjdXJyZW50IGRyYWZ0IGJlZm9yZSBwdWJsaWNhdGlvbiwg YW5kIGlmIG5vdCBpbmNsdWRlZCB0aGVuIGRlY2lkZSBpZiBhbnkgY2hhbmdlcyBhcmUgcmVxdWly ZWQgaW4gdGhlIGN1cnJlbnQgZHJhZnQgaW4gb3JkZXIgdG8NCiBhY2NvbW1vZGF0ZSBmb3IgdGhl IGV4dGVuc2lvbnMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KKHNlZSB0aGUgc3VtbWFy eSBzZW50IG9uIE1hcmNoIDQgZm9yIGUuZy4gcmVmZXJlbmNlcyB0byB0aGUgb3RoZXIgc3VtbWFy eSBwb2ludHMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCm4pLiBJbmRpY2F0aW9uIG9mIHByZWZlcmVuY2UgYmV0d2VlbiBtZWRpYSwgYW5kIG9mIHNp bXVsdGFub3VzIHZlcnN1cyBhbHRlcm5hdGl2ZSBsYW5ndWFnZXMuPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KVGhpcyBpcyBhIHN1bW1hcnkgb2YgdGhlIHJlbWFpbmluZyBpc3N1ZXMgcmVs YXRlZCB0byBpdGVtcyBlKSwgZiksIGopIGFuZCBtKSBhYm92ZS48YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpJc3N1ZSBlKSBwcm9wb3NlcyBjaGFuZ2VzIHRvIGVuYWJsZSBpbmRpY2F0aW9u IG9mIHByZWZlcmVuY2UgZm9yIGxhbmd1YWdlIGluIGRpZmZlcmVudCBtZWRpYS48YnIgY2xhc3M9 IiI+DQpJc3N1ZSBmKSByZXF1ZXN0cyBwb3NzaWJpbGl0eSB0byBpbmRpY2F0ZSByZXF1ZXN0IG9y IG9mZmVyaW5nIG9mIHRleHQgY2FwdGlvbnMgb2Ygc3Bva2VuIGxhbmd1YWdlLjxiciBjbGFzcz0i Ij4NCklzc3VlIGopIHByb3Bvc2VzIHVzZSBvZiB0aGUgQWNjZXB0LUxhbmd1YWdlIHN5bnRheCwg dGhhdCBjb3VsZCBib3RoIHNvbHZlIHRoZSBmdW5jdGlvbmFsIG5lZWRzPGJyIGNsYXNzPSIiPg0K b2YgZSkgYW5kIGYpIGFuZCBzb3J0IG91dCB0aGUgc3ludGF4IGFuZCBzZW1hbnRpY3MgcHJvYmxl bXMgb2YgdGhlIGFzdGVyaXNrIHBhcmFtZXRlci48YnIgY2xhc3M9IiI+DQpJc3N1ZSBtKSBqdXN0 IGluZGljYXRlcyB0aGF0IGlzc3VlIGUpIGlzIG5vdCB5ZXQgcmVzb2x2ZWQuPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KUmFuZGFsbCBoYXMgcHJvcG9zZWQgdG8gcmVzb2x2ZSB0aGUgZnVu Y3Rpb25hbCBuZWVkcyBpbiBhIG5ldyBkcmFmdCwgYW5kIG5vdCBhY2NlcHQgdGhlIEFjY2VwdC1M YW5ndWFnZSBzeW50YXguPGJyIGNsYXNzPSIiPg0KSSBoYXZlIHByb3Bvc2VkIGEgc2ltcGxlIHdh eSB0byByZXNvbHZlIGlzc3VlIGUpIC0gdGhlIHByZWZlcmVuY2UgYmV0d2VlbiBtZWRpYSwgYXQg dGhlIHNhbWUgdGltZSBpbXByb3ZpbmcgdGhlIGRlZmluaXRpb24gb2YgdGhlIHNlbWFudGljcyBv ZiB0aGUgYXN0ZXJpc2sgcGFyYW1ldGVyLjxiciBjbGFzcz0iIj4NCk5vIHJlYWwgc29sdXRpb24g dG8gaXNzdWUgZikgLSB0aGUgc2ltdWx0YW5laXR5IGluZGljYXRpb24gJm5ic3A7aGFzIGJlZW4g ZGlzY3Vzc2VkLjxiciBjbGFzcz0iIj4NCklzc3VlIGopIC0gdGhlIHByb3Bvc2FsIHRvIHVzZSB0 aGUgQWNjZXB0LUxhbmd1YWdlIHN5bnRheCBjYW4gcG90ZW50aWFsbHkgYmUgdXNlZCB0byByZXNv bHZlIGlzc3VlcyBlKSBhbmQgZikuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7 RGlzY3Vzc2lvbjo8YnIgY2xhc3M9IiI+DQpJc3N1ZSBlKSBzYXlzIHRoYXQgdGhlcmUgaXMgYSBu ZWVkIHRvIGJlIGFibGUgaW5kaWNhdGUgd2hpY2ggb2YgYSBzZXQgb2YgbGFuZ3VhZ2UvbWVkaWEg aW5kaWNhdGlvbnMgYXJlIG1vcmUgcHJlZmVycmVkIGFsdGVybmF0aXZlcyB0aGFuIG90aGVycy48 YnIgY2xhc3M9IiI+DQpFeGFtcGxlcyBhcmU6PGJyIGNsYXNzPSIiPg0KMS4gQSB3YW50IHRvIGdl dCB3cml0dGVuIEVuZ2xpc2ggaW4gdGV4dCwgQSBjYW4gYXMgYSBsZXNzIHByZWZlcnJlZCBhbHRl cm5hdGl2ZSBhY2NlcHQgdG8gZ2V0IHNwb2tlbiBFbmdsaXNoLiAmbmJzcDtBbiBhbnN3ZXJpbmcg cGFydHkgQiB3aG8gY2FuIHVzZSB0ZXh0IHdpbGwgdGhlbiByZXNwb25kIHdpdGggd3JpdHRlbiB0 ZXh0IGFuZCBnZXQgZ29vZCBzYXRpc2ZhY3Rpb24sIHdoaWxlIGFub3RoZXIgYW5zd2VyaW5nIHVz ZXIgQyB3aXRob3V0IHRleHQgY2FwYWJpbGl0eQ0KIHdpbGwgYW5zd2VyIGluIHNwb2tlbiBFbmds aXNoIGFuZCBoYXZlIGEgcG9zc2liaWxpdHkgZm9yIGEgcmVhc29uYWJseSBzdWNjZXNzZnVsIGNh bGwuPGJyIGNsYXNzPSIiPg0KV2l0aG91dCB0aGlzIGluZGljYXRpb24sIHRoZSBmaXJzdCBhbnN3 ZXJpbmcgcGFydHkgQiBtYXkgaGF2ZSBzZWVuIHRoZSBzcG9rZW4gYW5kIHdyaXR0ZW4gYWx0ZXJu YXRpdmVzIGFzIHRydWUgZXF1YWwgcHJlZmVyZW5jZSBhbHRlcm5hdGl2ZXMgYW5kIGFuc3dlcmVk IHdpdGggc3Bva2VuIEVuZ2xpc2ggdGhhdCB3aWxsIHJlc3VsdCBpbiBsZXNzIHNhdGlzZmllZCB1 c2Vycy48YnIgY2xhc3M9IiI+DQoyLiBBIFByZWZlciB0byByZWNlaXZlIHNwb2tlbiBsYW5ndWFn ZSwgYW5kIGNhbiBhY2NlcHQgdG8gcmVjZWl2ZSB0ZXh0LiAmbmJzcDsmbmJzcDtXaGVuIGFuc3dl cmluZyBwYXJ0eSBCIGNhbiB1c2Ugc3Bva2VuIGxhbmd1YWdlLCB0aGF0IHdpbGwgYmUgc2F0aXNm aWVkLCBvdGhlcndpc2Ugd3JpdHRlbiBsYW5ndWFnZSB3aWxsIGJlIHVzZWQuPGJyIGNsYXNzPSIi Pg0KMy4gQSBQcmVmZXIgdG8gdXNlIHNwb2tlbiBsYW5ndWFnZSBpbiBib3RoIGRpcmVjdGlvbnMs IGFuZCBjYW4gYWNjZXB0IHRvIHVzZSBzaWduIGxhbmd1YWdlIGluIHZpZGVvIGluIGJvdGggZGly ZWN0aW9ucy4gQW5zd2VyaW5nIHBhcnR5IEIgaGFzIGEgY2xlYXIgaW5kaWNhdGlvbiBvZiB3aHkg Ym90aCBzaWduZWQgYW5kIHdyaXR0ZW4gaXMgaW5kaWNhdGVkIGFuZCBjYW4gYW5zd2VyIGFjY29y ZGluZyB0byBpdHMgY2FwYWJpbGl0aWVzIHRyeWluZw0KIHRvIHNhdGlzZnkgdGhlIHByZWZlcmVu Y2UgZm9yIHNwb2tlbiBsYW5ndWFnZS48YnIgY2xhc3M9IiI+DQo0LiBBIFByZWZlciB0byB1c2Ug Jm5ic3A7c2lnbiBsYW5ndWFnZSBpbiBib3RoIGRpcmVjdGlvbnMgYW5kIGNhbiBhY2NlcHQgdG8g dXNlIHdyaXR0ZW4gbGFuZ3VhZ2UgaW4gYm90aCBkaXJlY3Rpb25zLiBTaWduIGxhbmd1YWdlIHVz ZXJzIHdpbGwgdXNlIHNpZ24gbGFuZ3VhZ2UsIG90aGVycyB3aWxsIHVzZSB0ZXh0LjxiciBjbGFz cz0iIj4NCjUuIFByZWZlciB0byBzZW5kIHNpZ24gbGFuZ3VhZ2UgYW5kIHJlY2VpdmUgdGV4dCAo ZGVhZi1ibGluZCB1c2VyKSwgY2FuIGFjY2VwdCB0byBzZW5kIHRleHQuICZuYnNwO0luIGEgY2Fs bCB3aXRoIGEgcGVyc29uIHdpdGggc2ltaWxhciBwcmVmZWVuY2VzLCB0ZXh0IHdpbGwgYmUgdXNl ZCBib3RoIHdheXMsIG90aGVyd2lzZSBzaWduIG9uZSB3YXkgYW5kIHRleHQgdGhlIG90aGVyLjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCmV0Yy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQpJc3N1ZSBmKSByZXF1aXJlcyBhIHdheSB0byBpbmRpY2F0ZSB1c2Ugb2YgY2FwdGlvbmlu ZyBhbmQgb3RoZXIgc2l0dWF0aW9ucyB3aGVyZSB1c2Ugb2Ygc2ltdWx0YW5lb3VzIGxhbmd1YWdl cyBpbiBkaWZmZXJlbnQgbW9kYWxpdGllcyBhcmUgbmVlZGVkOjxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCjEuIFByZWZlcmVuY2UgZm9yIGhlYXJpbmcgc3Bva2VuIGxhbmd1YWdlIGFuZCBz aW11bHRhbmVvdXNseSByZWFkIHdyaXR0ZW4gbGFuZ3VhZ2UgaW4gdGV4dC4gKCBjYXB0aW9uaW5n KSAuICZuYnNwOyZuYnNwO1RoZSB0aW1lIGlzIGhlcmUgd2hlbiB0aGlzIGNhbiBiZSBwcm92aWRl ZCBhdXRvbWF0aWNhbGx5IGluIHNvbWUgc2V0dGluZ3MsIGJ1dCBhbHNvIHRyYWRpdGlvbmFsbHkg YnkgYSBtYW5uZWQgc2VydmljZS48YnIgY2xhc3M9IiI+DQoyLiBQcmVmZXJlbmNlIGZvciBoZWFy aW5nIHNwb2tlbiBsYW5ndWFnZSBhbmQgc2ltdWx0YW5lb3VzbHkgc2VlaW5nIHRoZSBzcGVha2Vy IGluIHZpZGVvLiAobGlwLXJlYWRpbmcpLiAmbmJzcDtFYXNpbHkgYW5kIG5hdHVyYWxseSBwcm92 aWRlZCBvbmNlIHRoZSBuZWVkIGlzIGtub3duLjxiciBjbGFzcz0iIj4NCjMuIFByZWZlcmVuY2Ug Zm9yIHNlZWluZyBzaWduIGxhbmd1YWdlIGFuZCBzaW11bHRhbmVvdXNseSBoZWFyIHNwb2tlbiBs YW5ndWFnZSBpbiBhdWRpby4gKCBmb3IgbXVsdGlwbGUgdXNlcnMgYXQgdGhlIHRlcm1pbmFsICkg Jm5ic3A7Jm5ic3A7Jm5ic3A7T25lIG9mIHRoZSBzdHJlYW1zIGlzIHByb3ZpZGVkIGJ5IGFuIGlu dGVycHJldGVyLjxiciBjbGFzcz0iIj4NCjQuIFByZWZlcmVuY2UgZm9yIGhlYXJpbmcgc3Bva2Vu IGxhbmd1YWdlIGFuZCBzaW11bHRhbmVvdXNseSB2aWV3IHdyaXR0ZW4gbGFuZ3VhZ2UgaW4gdmlk ZW8uIChjYXB0aW9uaW5nIGlmIHdlIGFjY2VwdCB0byBzcGVjaWZ5IHRleHQgYXMgb3ZlcmxheSBv biB2aWRlbywgb3RoZXJ3aXNlIGl0IGlzIHNhbWUgYXMgbnVtYmVyIDEuKQ0KPGJyIGNsYXNzPSIi Pg0KU29tZSBvZiB0aGVzZSBjYW4gYmUgYWNjZXB0YWJsZSBhbHNvIGlmIGp1c3Qgb25lIG9mIHRo ZSBsYW5ndWFnZS9tZWRpYSBjb21iaW5hdGlvbnMgY2FuIGJlIHByb3ZpZGVkLCBidXQgaXMgbXVj aCBtb3JlIHByZWZlcnJlZCBpZiBib3RoIGNhbiBiZSBwcm92aWRlZCB0b2dldGhlci4gSW4gb3Ro ZXIgY2FzZXMgaXQgaXMgZXNzZW50aWFsIHRvIGdldCBib3RoIHNpbXVsdGFuZW91c2x5LiBUaGVy ZSBpcyBhIG5lZWQgdG8gZGlmZmVyZW50aWF0ZSBpbg0KIHRoZSBpbmRpY2F0aW9uIHRoYXQgdGhp cyBwcmVmZXJlbmNlIGZvciBnZXR0aW5nIHRoZSBsYW5ndWFnZXMgdG9nZXRoZXIgaXMgcHJlZmVy cmVkLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkFsdGVybmF0aXZlIGNvZGluZyBwcm9w b3NhbHM6PGJyIGNsYXNzPSIiPg0KMS4gUHJlZmVyZW5jZSBiZXR3ZWVuIGxhbmd1YWdlL21vZGFs aXR5PGJyIGNsYXNzPSIiPg0KMS4xIEJhc2VkIG9uIGRyYWZ0IC0wOCwgYWRkIHRoZSBjb2Rpbmcg b2YgYW4gYXN0ZXJpc2sgbGFzdCBpbiBhbiBhdHRyaWJ1dGUgdG8gbWVhbiBsb3dlciBwcmVmZXJl bmNlIGZvciBhIGxhbnVnYWdlL21lZGlhIGNvbWJpbmF0aW9uIHRoYW4gdGhlIG9uZShzKSB3aXRo b3V0IGFuIGFzdGVyaXNrLjxiciBjbGFzcz0iIj4NCmV4YW1wbGU8YnIgY2xhc3M9IiI+DQptPWF1 ZGlvPGJyIGNsYXNzPSIiPg0KYT1obGFuZy1yZWN2OmVuKjxiciBjbGFzcz0iIj4NCm09dGV4dDxi ciBjbGFzcz0iIj4NCmE9aGxhbmctcmVjdjplbjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CkF1ZGlvIGFuZCB0ZXh0IGFyZSBhbHRlcm5hdGl2ZXMgYW5kIHRleHQgcHJlZmVycmVkPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KMS4yLiBDaGFuZ2UgdG8gdGhlIEFjY2VwdC1MYW5ndWFn ZSBzeW50YXggYW5kIGxldCB0aGUgcS12YWx1ZXMgaGF2ZSBzY29wZSBvdmVyIHRoZSB3aG9sZSBT RFAuICZuYnNwOyZuYnNwOzxiciBjbGFzcz0iIj4NCiZuYnNwO209dmlkZW8gNTEzNzIgUlRQL0FW UCAzMSAzMjxiciBjbGFzcz0iIj4NCiZuYnNwO2E9aGxhbmctcmVjdjphc2U7cT0wLjk8YnIgY2xh c3M9IiI+DQombmJzcDthPWhsYW5nLXNlbmQ6YXNlO3E9MC45PGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7bT10ZXh0IDQ5MjUwIFJUUC9BVlAgOTgsOTk8 YnIgY2xhc3M9IiI+DQombmJzcDthPWhsYW5nLXNlbmQ6ZW47cT0wLjUsKjtxPTAuMTxiciBjbGFz cz0iIj4NCiZuYnNwO2E9aGxhbmctcmVjdjplbjtxPTAuNSwqO3E9MC4xPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KU2lnbiBsYW5ndWFnZSBpcyBoaWdoZXIgcHJlZmVycmVkIHRoYW4gdGV4 dC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQoxLjMuIEludHJvZHVjZSBhIG5ldyBh PW1vZGFsaXR5IGF0dHJpYnV0ZSBvbiBtZWRpYSBsZXZlbCwgd2l0aCBwYXJhbWV0ZXJzOiAmbHQ7 bW9kYWxpdHkmZ3Q7LCAmbHQ7ZGlyZWN0aW9uJmd0OywgJmx0O3ByZWZlcmVuY2UmZ3Q7ICZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO2V4YW1wbGU6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K bT10ZXh0PGJyIGNsYXNzPSIiPg0KYT1tb2RhbGl0eTp3cml0dGVuLHJlY3YsaGk8YnIgY2xhc3M9 IiI+DQphPWhsYW5nLXJlY3Y6ZW4qPGJyIGNsYXNzPSIiPg0KbT1hdWRpbzxiciBjbGFzcz0iIj4N CmE9bW9kYWxpdHk6c3Bva2VuLHJlY3YsbWVkPGJyIGNsYXNzPSIiPg0KYT1obGFuZy1yZWN2OmVu KjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCjIuIFByZWZlcmVuY2UgZm9yIHNpbXVsdGFuZW91cyBsYW5ndWFnZXMgdnMgYWx0ZXJuYXRp dmUgbGFuZ3VhZ2VzOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjIuMS4gQmFzZWQgb24g ZHJhZnQgLTA4LCBhZGQgYW5vdGhlciBub3RhdGlvbiB0byB0aGUgdXNlIG9mIHRoZSBhc3Rlcmlz aywgZS5nLiBhbiBvcHRpb25hbCBjaGFyYWN0ZXIgdG8gYmUgdXNlZCB0b2dldGhlciB3aXRoIHRo ZSBhc3RlcmlzayB0byBtYXJrIG1lZGlhIHRoYXQgYXJlIHdhbnRlZCB0b2dldGhlci4gKHVnbHkp ICZuYnNwOyZuYnNwO2V4YW1wbGU6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KbT1hdWRp bzxiciBjbGFzcz0iIj4NCmE9aGxhbmctcmVjdjplbiokYzxiciBjbGFzcz0iIj4NCm09dGV4dDxi ciBjbGFzcz0iIj4NCmE9aGxhbmctcmVjdjplbiRjPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KVGhlICQgaXMgYSBzaW11bHRhbmVpdHkgaW5kaWNhdGlvbiwgdGhlIGMgaXMgYSBncm9vdXBp bmcgaW5kaWNhdG9yIHRlbGxpbmcgdGhhdCBhbGwgbW9kYWxpdGllcyBtYXJrZWQgd2l0aCB0aGUg JGMgYXJlIHdhbnRlZCB0b2dldGhlci4gKHdlIG1pZ2h0IGJlIGFibGUgdG8gcmVzdHJpY3QgdGhl IGluZGljYXRpb24gdG8ganVzdCBvbmUgc2V0IG9mIGxhbmd1YWdlcyB0aGF0IGFyZSB3YW50ZWQg c2ltdWx0YW5lb3VzbHkuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KMi4yLiBVc2UgdGhlIEFjY2VwdC1MYW5ndWFnZSBzeW50YXggYW5kIGFkZCB0aGUgdXNhZ2Ug cnVsZXMgdGhhdCBxLXZhbHVlcyB3aXRoIGxlc3MgdGhhbiAuMSBkaWZmZXJlbmNlIG1lYW4gbGFu Z3VhZ2VzIHdpdGggYSBwcmVmZXJlbmNlIHRvIGJlIHVzZWQgdG9nZXRoZXIuIEhpZ2hlciBkaWZm ZXJlbmNlcyBpbmRpY2F0ZSB0aGF0IHRoZXkgYXJlIGFsdGVybmF0aXZlcy4gJm5ic3A7VGhlcmVi eSBpdCBpcyBib3RoIHBvc3NpYmxlIHRvIGluZGljYXRlIHNpbXVsdGFuZWl0eQ0KIGFuZCBwcmVm ZXJlbmNlIGlmIHRoZSBzaW11bHRhbmVpdHkgY2Fubm90IGJlIHNhdGlzZmllZC48YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDttPWF1ZGlvIDUxMzcyIFJUUC9BVlAgMDxiciBjbGFz cz0iIj4NCiZuYnNwO2E9aGxhbmctcmVjdjphc2U7cT0wLjU8YnIgY2xhc3M9IiI+DQombmJzcDth PWhsYW5nLXNlbmQ6YXNlO3E9MC41PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KJm5ic3A7bT10ZXh0IDQ5MjUwIFJUUC9BVlAgOTgsOTk8YnIgY2xhc3M9IiI+DQom bmJzcDthPWhsYW5nLXNlbmQ6ZW47cT0wLjUxLCo7cT0wLjE8YnIgY2xhc3M9IiI+DQombmJzcDth PWhsYW5nLXJlY3Y6ZW47cT0wLjUxLCo7cT0wLjE8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQpUaGUgcS12YWx1ZXMgZGlmZmVyZW5jZXMgYXJlIHdpdGhpbiAwLjEgc28gaXQgaXMgYSBwcmVm ZXJlbmNlIGZvciBnZXR0aW5nIGJvdGggdG9nZXRoZXIsIGJ1dCBpZiB0aGF0IGlzIG5vdCBwb3Nz aWJsZSwgdGV4dCBpcyBwcmVmZXJyZWQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KMi4zLiBBZGQgdG8gdGhlIG5ldyBhPW1vZGFsaXR5IGF0dHJpYnV0ZSBhIGZv dXJ0aCwgb3B0aW9uYWwgcGFyYW1ldGVyIFtzaW11bHRhbmVpdHldIHdpdGggdmFsdWUgYW55IHNp bmdsZSBsZXR0ZXIsIGluZGljYXRpbmcgYSBwcmVmZXJlbmNlIGZvciBoYXZpbmcgdGhhdCBtb2Rh bGl0eSBzaW11bHRhbmVvdXNseSB3aXRoIGFub3RoZXIgbW9kYWxpdHkgaW5kaWNhdGVkIHdpdGgg dGhlIHNhbWUgdmFsdWUgaW4gdGhlIFtzaW11bHRhbmVpdHldIHBhcmFtZXRlci4NCiAmbmJzcDsm bmJzcDtXaXRob3V0IHRoaXMgcGFyYW1ldGVyLCB0aGUgbW9kYWxpdGllcyBhcmUgYWx0ZXJuYXRp dmVzLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCm09dGV4dDxiciBjbGFzcz0iIj4NCmE9 bW9kYWxpdHk6d3JpdHRlbixyZWN2LGhpLGQ8YnIgY2xhc3M9IiI+DQphPWhsYW5nLXJlY3Y6ZW4q PGJyIGNsYXNzPSIiPg0KbT1hdWRpbzxiciBjbGFzcz0iIj4NCmE9bW9kYWxpdHk6c3Bva2VuLHJl Y3YsaGksZDxiciBjbGFzcz0iIj4NCmE9aGxhbmctcmVjdjplbio8YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpTdGF0dXM6IE5vdCBzb2x2 ZWQuIENvbmNsdXNpb24gbmVlZGVkIG9uIGhvdyB0byBoYW5kbGUgdGhlc2UgaXNzdWVzIGUsIGYs IGFuZCBqLCAmbmJzcDtib3RoIHJlZ2FyZGluZyB3aGljaCBzb2x1dGlvbiBhbmQgd2hhdCBwcm9j ZWR1cmUgdG8gdGFrZSB0byBhcHBseSBpdC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJ IGhhdmUgYSBzbGlnaHQgcHJlZmVyZW5jZSBmb3Igc29sdXRpb24gMS4yIGFuZCAyLjIgLDxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCllvdXIgdmlld3M/PGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KUmVnYXJkczxiciBjbGFzcz0iIj4NCkd1bm5hcjxiciBjbGFzcz0iIj4NCi0tPGJy IGNsYXNzPSIiPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnIg Y2xhc3M9IiI+DQpHdW5uYXIgSGVsbHN0csO2bTxiciBjbGFzcz0iIj4NCk9tbml0b3I8YnIgY2xh c3M9IiI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOmd1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5zZSIg Y2xhc3M9IiI+bWFpbHRvOmd1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5zZTwvYT4mZ3Q7PGEgaHJl Zj0ibWFpbHRvOmd1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5zZSIgY2xhc3M9IiI+Z3VubmFyLmhl bGxzdHJvbUBvbW5pdG9yLnNlPC9hPjxiciBjbGFzcz0iIj4NCiYjNDM7NDYgNzA4IDIwNCAyODg8 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NClNMSU0gbWFp bGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpTTElNQGlldGYub3Jn IiBjbGFzcz0iIj5tYWlsdG86U0xJTUBpZXRmLm9yZzwvYT4mZ3Q7PGEgaHJlZj0ibWFpbHRvOlNM SU1AaWV0Zi5vcmciIGNsYXNzPSIiPlNMSU1AaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KJmx0 OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2xpbSIgY2xh c3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zbGltPC9hPiZndDs8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NsaW0iIGNsYXNz PSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2xpbTwvYT48YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4N ClNMSU0gbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpTTElN QGlldGYub3JnIiBjbGFzcz0iIj5tYWlsdG86U0xJTUBpZXRmLm9yZzwvYT4mZ3Q7PGEgaHJlZj0i bWFpbHRvOlNMSU1AaWV0Zi5vcmciIGNsYXNzPSIiPlNMSU1AaWV0Zi5vcmc8L2E+PGJyIGNsYXNz PSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zbGlt IiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NsaW08L2E+ PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnIgY2xhc3M9IiI+DQpTTElNIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxh IGhyZWY9Im1haWx0bzpTTElNQGlldGYub3JnIiBjbGFzcz0iIj5TTElNQGlldGYub3JnPC9hPjxi ciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2xpbSIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z bGltPC9hPjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCi0tIDxiciBjbGFzcz0iIj4NClJhbmRhbGwgR2VsbGVuczxiciBjbGFzcz0iIj4N Ck9waW5pb25zIGFyZSBwZXJzb25hbDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ZmFjdHMgYXJlIHN1c3Bl Y3Q7ICZuYnNwOyZuYnNwOyZuYnNwO0kgc3BlYWsgZm9yIG15c2VsZiBvbmx5PGJyIGNsYXNzPSIi Pg0KLS0tLS0tLS0tLS0tLS0gUmFuZG9tbHkgc2VsZWN0ZWQgdGFnOiAtLS0tLS0tLS0tLS0tLS08 YnIgY2xhc3M9IiI+DQpZb3UgbmV2ZXIgZmluaXNoIGEgcHJvZ3JhbSwgeW91IGp1c3Qgc3RvcCB3 b3JraW5nIG9uIGl0LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KU0xJTSBtYWls aW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86U0xJTUBpZXRmLm9yZyIgY2xh c3M9IiI+U0xJTUBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NsaW08YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8cCBzdHlsZT0iZm9udC1mYW1pbHk6 IEFyaWFsLHNhbnMtc2VyaWY7Zm9udC1zaXplOjExcHg7Y29sb3I6Izk5OTk5OTsiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLHNhbnMtc2VyaWY7Y29sb3I6Izk5 OTk5OTsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IEFyaWFsOyBtc28tZmFyZWFzdC10aGVtZS1m b250OiBtaW5vci1sYXRpbjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICZxdW90O0FyaWFsJnF1b3Q7 OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBFTi1HQjsg bXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj5UaGlzDQogZW1haWwgYW5kIGl0cyBhdHRhY2htZW50 cyBhcmUgaW50ZW5kZWQgZm9yIHRoZSBhYm92ZSBuYW1lZCBvbmx5IGFuZCBtYXkgYmUgY29uZmlk ZW50aWFsLiBJZiB0aGV5IGhhdmUgY29tZSB0byB5b3UgaW4gZXJyb3IgeW91IG11c3QgdGFrZSBu byBhY3Rpb24gYmFzZWQgb24gdGhlbSwgbm9yIG11c3QgeW91IGNvcHkgb3Igc2hvdyB0aGVtIHRv IGFueW9uZTsgcGxlYXNlIHJlcGx5IHRvIHRoaXMgZW1haWwgb3IgY2FsbCAmIzQzOzQ0IDIwNyAz NTYgMDYwMA0KIGFuZCBoaWdobGlnaHQgdGhlIGVycm9yLiA8L3NwYW4+PC9wPg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_642B8F4216484B22AB1445980A2104A2gsmacom_-- From nobody Tue Mar 14 15:29:14 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238181315DF for ; Tue, 14 Mar 2017 15:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eb7TnxbMg-kP for ; Tue, 14 Mar 2017 15:29:09 -0700 (PDT) Received: from bin-vsp-out-02.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D1AE1315CE for ; Tue, 14 Mar 2017 15:29:09 -0700 (PDT) X-Halon-ID: a0196b43-0905-11e7-af93-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Tue, 14 Mar 2017 23:29:01 +0100 (CET) To: Brian Rosen , arnoud.vanwijk@realtimetext.org References: <084a066e-ea68-d614-58e1-08c904f477ea@omnitor.se> <60797269-4dad-5f48-3184-b8fbca42c30c@realtimetext.org> Cc: "slim@ietf.org" From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Tue, 14 Mar 2017 23:28:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------67D46D7CD960A9D5AB2E3BE9" Archived-At: Subject: Re: [Slim] Extended functionality for the real-time language negotiation X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 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, 14 Mar 2017 22:29:13 -0000 This is a multi-part message in MIME format. --------------67D46D7CD960A9D5AB2E3BE9 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Another method than the ones proposed below in 2.1, 2.2 and 2.3 for satisfying the request for coding of captions could be to use the -t subtag. This is a discussion independent of the issue if we include a solution on this need in the current draft or another. -t means transformed content. Its use is specified in RFC 6497. The format is approximately [presented language]-t-[source language] Application rules could be defined for the use of -t. A proposal: -t indicates that the content is transformed from a source. That makes it possible to produce it approximately simultaneously with the source. Thus from a sender, the indication of a language with -t subtag indicates a preparedness to provide this language simultaneously with languages in other media. From a receiver, it indicates a preference for receiving this language simultaneously with any language provided in other media. When -t subtag is not included. it means that languages in different media for the same direction are instead alternatives to select from When the language indicated as source in a -t subtag appears in another media in the same direction, it indicates that both the source language and the transformed language can be provided together or are desired together. Captioning of spoken language is one example for use of this indication. Captioning with translation from another spoken language is another similar use. Spoken interpretation of a sign language is another use, when there is a preference to both see the signing person and have the spoken language interpretation in audio. Regards Gunnar Den 2017-03-10 kl. 23:54, skrev Gunnar Hellström: > > Brian, > > Earlier we ran in circles around these functional requirements and > their possible inclusion in the current draft. > > Not this time. > > I started to analyze what the mentioned functional extensions would > mean, and tried to come up with possible ways to code them. > > Since Dale in the review also recommended us to switch to use the > syntax similar to the Accept-Language, I took that as one base for the > extension alternatives. > > That led to the three possible extension variants for each functional > extension, and a brief analysis of them. > > The analysis is valid both if we make them as extensions after > publication of our initial draft, or if it is decided that one or both > functionalities can be included now. > > The planned extensions might be allowed to influence the current draft > even if the extensions themselves are not included. > > The conclusion of my analysis was then that it would be easier to > create the extensions if the coding of the current functionality moved > to the syntax similar to Accept-Language. > > It is not going in circles to discuss and decide if we shall take the > step to change the coding to satisfy both Dales' recommendations and > my analysis. > > Please look at the extension discussion below and comment which one > you prefer, or propose yet other altenatives. > > > It is a separate discussion, but It is also true that I want to see > the functional extensions included in the initial publication, and I > do not see the value in publishing something without functions we know > are needed. While we keep in discussing this I see projects moving on > using private solutions for the functionality we discuss, causing > risks for interoperability problems in the future. I think it is a > failure to not solve the functional needs. They are real and urgent > and solving them is the only politically correct way to act. > > > /Gunnar > > > > Den 2017-03-10 kl. 19:46, skrev Brian Rosen: >> We seem to be running in circles. >> >> The work group has discussed the idea of indicating media & language >> combination preferences and DECLINED, at this time to do that. We >> decided our first effort would be to label language preferences per >> media, with no cross media preferences. That doesn’t mean we won’t >> ever do it. It means our first document on SDP negotiation won’t >> cover that case. >> >> Yet you keep trying to get it in the current document. >> >> I don’t want to revisit our decision, and I don’t want to see any >> linkage between media in this document. I accept there are >> requirements to have such linkages, but think there are many. many >> uses for a simpler mechanism such as what the current document discusses. >> >> If you want to write a draft that proposes an extension to the >> current mechanism, please write it, and I’ll review it. But I would >> like to see this document published with the simple per-media preference. >> >> Brian >> >> >>> On Mar 10, 2017, at 1:25 PM, Arnoud van Wijk >>> >> > wrote: >>> >>> Hi Gunnar, >>> >>> I also prefer solution 1.2 and 2.2 >>> >>> I like the use of q values here. I think that is better then adding >>> a new attribute. >>> >>> >>> Good proposal. >>> >>> >>> /Arnoud >>> >>> >>> >>> On 07/03/2017 14:01, Gunnar Hellström wrote: >>>> >>>> This is a slightly improved extract from the summary of the LC >>>> period for the real-time SLIM draft about two discussed >>>> functionality extensions. (Some of the examples had copy-paste >>>> errors.) >>>> >>>> The intention is to discuss this topic as far as needed to decide >>>> if any or both these functionality enhancements could go into the >>>> current draft before publication, and if not included then decide >>>> if any changes are required in the current draft in order to >>>> accommodate for the extensions. >>>> >>>> (see the summary sent on March 4 for e.g. references to the other >>>> summary points. >>>> >>>> ---------------------------------------------------------------------------------------------------------- >>>> >>>> *n). Indication of preference between media, and of simultanous >>>> versus alternative languages.* >>>> >>>> This is a summary of the remaining issues related to items e), f), >>>> j) and m) above. >>>> >>>> Issue e) proposes changes to enable indication of preference for >>>> language in different media. >>>> Issue f) requests possibility to indicate request or offering of >>>> text captions of spoken language. >>>> Issue j) proposes use of the Accept-Language syntax, that could >>>> both solve the functional needs >>>> of e) and f) and sort out the syntax and semantics problems of the >>>> asterisk parameter. >>>> Issue m) just indicates that issue e) is not yet resolved. >>>> >>>> Randall has proposed to resolve the functional needs in a new >>>> draft, and not accept the Accept-Language syntax. >>>> I have proposed a simple way to resolve issue e) - the preference >>>> between media, at the same time improving the definition of the >>>> semantics of the asterisk parameter. >>>> No real solution to issue f) - the simultaneity indication has >>>> been discussed. >>>> Issue j) - the proposal to use the Accept-Language syntax can >>>> potentially be used to resolve issues e) and f). >>>> >>>> Discussion: >>>> Issue e) says that there is a need to be able indicate which of a >>>> set of language/media indications are more preferred alternatives >>>> than others. >>>> Examples are: >>>> 1. A want to get written English in text, A can as a less preferred >>>> alternative accept to get spoken English. An answering party B who >>>> can use text will then respond with written text and get good >>>> satisfaction, while another answering user C without text >>>> capability will answer in spoken English and have a possibility for >>>> a reasonably successful call. >>>> Without this indication, the first answering party B may have seen >>>> the spoken and written alternatives as true equal preference >>>> alternatives and answered with spoken English that will result in >>>> less satisfied users. >>>> 2. A Prefer to receive spoken language, and can accept to receive >>>> text. When answering party B can use spoken language, that will >>>> be satisfied, otherwise written language will be used. >>>> 3. A Prefer to use spoken language in both directions, and can >>>> accept to use sign language in video in both directions. Answering >>>> party B has a clear indication of why both signed and written is >>>> indicated and can answer according to its capabilities trying to >>>> satisfy the preference for spoken language. >>>> 4. A Prefer to use sign language in both directions and can accept >>>> to use written language in both directions. Sign language users >>>> will use sign language, others will use text. >>>> 5. Prefer to send sign language and receive text (deaf-blind user), >>>> can accept to send text. In a call with a person with similar >>>> prefeences, text will be used both ways, otherwise sign one way and >>>> text the other. >>>> >>>> etc. >>>> >>>> Issue f) requires a way to indicate use of captioning and other >>>> situations where use of simultaneous languages in different >>>> modalities are needed: >>>> >>>> 1. Preference for hearing spoken language and simultaneously read >>>> written language in text. ( captioning) . The time is here when >>>> this can be provided automatically in some settings, but also >>>> traditionally by a manned service. >>>> 2. Preference for hearing spoken language and simultaneously seeing >>>> the speaker in video. (lip-reading). Easily and naturally provided >>>> once the need is known. >>>> 3. Preference for seeing sign language and simultaneously hear >>>> spoken language in audio. ( for multiple users at the terminal >>>> ) One of the streams is provided by an interpreter. >>>> 4. Preference for hearing spoken language and simultaneously view >>>> written language in video. (captioning if we accept to specify text >>>> as overlay on video, otherwise it is same as number 1.) >>>> >>>> Some of these can be acceptable also if just one of the >>>> language/media combinations can be provided, but is much more >>>> preferred if both can be provided together. In other cases it is >>>> essential to get both simultaneously. There is a need to >>>> differentiate in the indication that this preference for getting >>>> the languages together is preferred. >>>> >>>> Alternative coding proposals: >>>> 1. Preference between language/modality >>>> 1.1 Based on draft -08, add the coding of an asterisk last in an >>>> attribute to mean lower preference for a lanugage/media combination >>>> than the one(s) without an asterisk. >>>> example >>>> m=audio >>>> a=hlang-recv:en* >>>> m=text >>>> a=hlang-recv:en >>>> >>>> Audio and text are alternatives and text preferred >>>> >>>> 1.2. Change to the Accept-Language syntax and let the q-values have >>>> scope over the whole SDP. >>>> >>>> m=video 51372 RTP/AVP 31 32 >>>> a=hlang-recv:ase;q=0.9 >>>> a=hlang-send:ase;q=0.9 >>>> >>>> >>>> m=text 49250 RTP/AVP 98,99 >>>> a=hlang-send:en;q=0.5,*;q=0.1 >>>> a=hlang-recv:en;q=0.5,*;q=0.1 >>>> >>>> Sign language is higher preferred than text. >>>> >>>> >>>> >>>> >>>> >>>> 1.3. Introduce a new a=modality attribute on media level, with >>>> parameters: , , >>>> example: >>>> >>>> m=text >>>> a=modality:written,recv,hi >>>> a=hlang-recv:en* >>>> m=audio >>>> a=modality:spoken,recv,med >>>> a=hlang-recv:en* >>>> >>>> >>>> >>>> 2. Preference for simultaneous languages vs alternative languages: >>>> >>>> 2.1. Based on draft -08, add another notation to the use of the >>>> asterisk, e.g. an optional character to be used together with the >>>> asterisk to mark media that are wanted together. (ugly) example: >>>> >>>> m=audio >>>> a=hlang-recv:en*$c >>>> m=text >>>> a=hlang-recv:en$c >>>> >>>> The $ is a simultaneity indication, the c is a groouping indicator >>>> telling that all modalities marked with the $c are wanted together. >>>> (we might be able to restrict the indication to just one set of >>>> languages that are wanted simultaneously. >>>> >>>> >>>> 2.2. Use the Accept-Language syntax and add the usage rules that >>>> q-values with less than .1 difference mean languages with a >>>> preference to be used together. Higher differences indicate that >>>> they are alternatives. Thereby it is both possible to indicate >>>> simultaneity and preference if the simultaneity cannot be satisfied. >>>> >>>> m=audio 51372 RTP/AVP 0 >>>> a=hlang-recv:ase;q=0.5 >>>> a=hlang-send:ase;q=0.5 >>>> >>>> >>>> m=text 49250 RTP/AVP 98,99 >>>> a=hlang-send:en;q=0.51,*;q=0.1 >>>> a=hlang-recv:en;q=0.51,*;q=0.1 >>>> >>>> The q-values differences are within 0.1 so it is a preference for getting both together, but if that is not possible, text is preferred. >>>> >>>> >>>> 2.3. Add to the new a=modality attribute a fourth, optional >>>> parameter [simultaneity] with value any single letter, indicating >>>> a preference for having that modality simultaneously with another >>>> modality indicated with the same value in the [simultaneity] >>>> parameter. Without this parameter, the modalities are alternatives. >>>> >>>> m=text >>>> a=modality:written,recv,hi,d >>>> a=hlang-recv:en* >>>> m=audio >>>> a=modality:spoken,recv,hi,d >>>> a=hlang-recv:en* >>>> >>>> >>>> * >>>> * >>>> >>>> ***Status: Not solved. Conclusion needed on how to handle these >>>> issues e, f, and j, both regarding which solution and what >>>> procedure to take to apply it.* >>>> >>>> I have a slight preference for solution 1.2 and 2.2 , >>>> >>>> Your views? >>>> >>>> Regards >>>> 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 >>> >>> _______________________________________________ >>> 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 -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------67D46D7CD960A9D5AB2E3BE9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Another method than the ones proposed below in 2.1,  2.2 and 2.3 for satisfying the request for coding of captions could be to use the -t subtag.

This is a discussion independent of the issue if we include a solution on this need in the current draft or another.

-t means transformed content. Its use is specified in RFC 6497.   The format is approximately  [presented language]-t-[source language]

Application rules could be defined for the use of -t. 

A proposal:  -t indicates that the content is transformed from a source. That makes it possible to produce it approximately simultaneously with the source. Thus from a sender, the indication of a language with -t subtag indicates a preparedness to provide this language simultaneously with languages in other media. From a receiver, it indicates a preference for receiving this language simultaneously with any language provided in other media.

When -t subtag is not included. it means that languages in different media for the same direction are instead alternatives to select from

When the language indicated as source in a -t subtag appears in another media in the same direction, it indicates that both the source language and the transformed language can be provided together or are desired together.

Captioning of spoken language is one example for use of this indication.

Captioning with translation from another spoken language is another similar use.

Spoken interpretation of a sign language is another use, when there is a preference to both see the signing person and have the spoken language interpretation in audio.

Regards


Gunnar



Den 2017-03-10 kl. 23:54, skrev Gunnar Hellström:

Brian,

Earlier we ran in circles around these functional requirements and their possible inclusion in the current draft.

Not this time.

I started to analyze what the mentioned functional extensions would mean, and tried to come up with possible ways to code them.

Since Dale in the review also recommended us to switch to use the syntax similar to the Accept-Language, I took that as one base for the extension alternatives.

That led to the three possible extension variants for each functional extension, and a brief analysis of them.

The analysis is valid both if we make them as extensions after publication of our initial draft, or if it is decided that one or both functionalities can be included now.

The planned extensions might be allowed to influence the current draft even if the extensions themselves are not included.

The conclusion of my analysis was then that it would be easier to create the extensions if the coding of the current functionality moved to the syntax similar to Accept-Language.

It is not going in circles to discuss and decide if we shall take the step to change the coding to satisfy both Dales' recommendations and my analysis.

Please look at the extension discussion below and comment which one you prefer, or propose yet other altenatives.


It is a separate discussion, but It is also true that I want to see the functional extensions included in the initial publication, and I do not see the value in publishing something without functions we know are needed. While we keep in discussing this I see projects moving on using private solutions for the functionality we discuss, causing risks for interoperability problems in the future. I think it is a failure to not solve the functional needs. They are real and urgent and solving them is the only politically correct way to act.


/Gunnar



Den 2017-03-10 kl. 19:46, skrev Brian Rosen:
We seem to be running in circles.

The work group has discussed the idea of indicating media & language combination preferences and DECLINED, at this time to do that.  We decided our first effort would be to label language preferences per media, with no cross media preferences.  That doesn’t mean we won’t ever do it.  It means our first document on SDP negotiation won’t cover that case.

Yet you keep trying to get it in the current document.

I don’t want to revisit our decision, and I don’t want to see any linkage between media in this document.  I accept there are requirements to have such linkages, but think there are many. many uses for a simpler mechanism such as what the current document discusses.

If you want to write a draft that proposes an extension to the current mechanism, please write it, and I’ll review it.  But I would like to see this document published with the simple per-media preference.

Brian


On Mar 10, 2017, at 1:25 PM, Arnoud van Wijk <arnoud.vanwijk@realtimetext.org> wrote:

Hi Gunnar,

I also prefer solution 1.2 and 2.2

I like the use of q values here. I think that is better then adding a new attribute.


Good proposal.


/Arnoud



On 07/03/2017 14:01, Gunnar Hellström wrote:

This is a slightly improved extract from the summary of the LC period for the real-time SLIM draft about two discussed functionality extensions. (Some of the examples had copy-paste errors.)

The intention is to discuss this topic as far as needed to decide if any or both these functionality enhancements could go into the current draft before publication, and if not included then decide if any changes are required in the current draft in order to accommodate for the extensions.

(see the summary sent on March 4 for e.g. references to the other summary points.

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

n). Indication of preference between media, and of simultanous versus alternative languages.

This is a summary of the remaining issues related to items e), f), j) and m) above.

Issue e) proposes changes to enable indication of preference for language in different media.
Issue f) requests possibility to indicate request or offering of text captions of spoken language.
Issue j) proposes use of the Accept-Language syntax, that could both solve the functional needs
of e) and f) and sort out the syntax and semantics problems of the asterisk parameter.
Issue m) just indicates that issue e) is not yet resolved.

Randall has proposed to resolve the functional needs in a new draft, and not accept the Accept-Language syntax.
I have proposed a simple way to resolve issue e) - the preference between media, at the same time improving the definition of the semantics of the asterisk parameter.
No real solution to issue f) - the simultaneity indication  has been discussed.
Issue j) - the proposal to use the Accept-Language syntax can potentially be used to resolve issues e) and f).

 Discussion:
Issue e) says that there is a need to be able indicate which of a set of language/media indications are more preferred alternatives than others.
Examples are:
1. A want to get written English in text, A can as a less preferred alternative accept to get spoken English.  An answering party B who can use text will then respond with written text and get good satisfaction, while another answering user C without text capability will answer in spoken English and have a possibility for a reasonably successful call.
Without this indication, the first answering party B may have seen the spoken and written alternatives as true equal preference alternatives and answered with spoken English that will result in less satisfied users.
2. A Prefer to receive spoken language, and can accept to receive text.   When answering party B can use spoken language, that will be satisfied, otherwise written language will be used.
3. A Prefer to use spoken language in both directions, and can accept to use sign language in video in both directions. Answering party B has a clear indication of why both signed and written is indicated and can answer according to its capabilities trying to satisfy the preference for spoken language.
4. A Prefer to use  sign language in both directions and can accept to use written language in both directions. Sign language users will use sign language, others will use text.
5. Prefer to send sign language and receive text (deaf-blind user), can accept to send text.  In a call with a person with similar prefeences, text will be used both ways, otherwise sign one way and text the other.

etc.

Issue f) requires a way to indicate use of captioning and other situations where use of simultaneous languages in different modalities are needed:

1. Preference for hearing spoken language and simultaneously read written language in text. ( captioning) .   The time is here when this can be provided automatically in some settings, but also traditionally by a manned service.
2. Preference for hearing spoken language and simultaneously seeing the speaker in video.   (lip-reading).  Easily and naturally provided once the need is known.
3. Preference for seeing sign language and simultaneously hear spoken language in audio.  ( for multiple users at the terminal )    One of the streams is provided by an interpreter.
4. Preference for hearing spoken language and simultaneously view written language in video. (captioning if we accept to specify text as overlay on video, otherwise it is same as number 1.) 

Some of these can be acceptable also if just one of the language/media combinations can be provided, but is much more preferred if both can be provided together. In other cases it is essential to get both simultaneously. There is a need to differentiate in the indication that this preference for getting the languages together is preferred.

Alternative coding proposals:
1. Preference between language/modality
1.1 Based on draft -08, add the coding of an asterisk last in an attribute to mean lower preference for a lanugage/media combination than the one(s) without an asterisk.
example
m=audio
a=hlang-recv:en*
m=text
a=hlang-recv:en

Audio and text are alternatives and text preferred

1.2. Change to the Accept-Language syntax and let the q-values have scope over the whole SDP.    

 m=video 51372 RTP/AVP 31 32
 a=hlang-recv:ase;q=0.9
 a=hlang-send:ase;q=0.9


 m=text 49250 RTP/AVP 98,99
 a=hlang-send:en;q=0.5,*;q=0.1
 a=hlang-recv:en;q=0.5,*;q=0.1

Sign language is higher preferred than text.

 



1.3. Introduce a new a=modality attribute on media level, with parameters: <modality>, <direction>, <preference>    
example:

m=text
a=modality:written,recv,hi
a=hlang-recv:en*
m=audio
a=modality:spoken,recv,med
a=hlang-recv:en*



2. Preference for simultaneous languages vs alternative languages:

2.1. Based on draft -08, add another notation to the use of the asterisk, e.g. an optional character to be used together with the asterisk to mark media that are wanted together. (ugly)   example:

m=audio
a=hlang-recv:en*$c
m=text
a=hlang-recv:en$c

The $ is a simultaneity indication, the c is a groouping indicator telling that all modalities marked with the $c are wanted together. (we might be able to restrict the indication to just one set of languages that are wanted simultaneously.


2.2. Use the Accept-Language syntax and add the usage rules that q-values with less than .1 difference mean languages with a preference to be used together. Higher differences indicate that they are alternatives.  Thereby it is both possible to indicate simultaneity and preference if the simultaneity cannot be satisfied.

 m=audio 51372 RTP/AVP 0
 a=hlang-recv:ase;q=0.5
 a=hlang-send:ase;q=0.5


 m=text 49250 RTP/AVP 98,99
 a=hlang-send:en;q=0.51,*;q=0.1
 a=hlang-recv:en;q=0.51,*;q=0.1

The q-values differences are within 0.1 so it is a preference for getting both together, but if that is not possible, text is preferred.


2.3. Add to the new a=modality attribute a fourth, optional parameter [simultaneity]   with value any single letter, indicating a preference for having that modality simultaneously with another modality indicated with the same value in the [simultaneity] parameter.   Without this parameter, the modalities are alternatives.

m=text
a=modality:written,recv,hi,d
a=hlang-recv:en*
m=audio
a=modality:spoken,recv,hi,d
a=hlang-recv:en*



Status: Not solved. Conclusion needed on how to handle these issues e, f, and j,  both regarding which solution and what procedure to take to apply it.

I have a slight preference for solution 1.2 and 2.2 ,

Your views?

Regards
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

_______________________________________________
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

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------67D46D7CD960A9D5AB2E3BE9-- From nobody Tue Mar 14 23:46:22 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA2FF1295EB for ; Tue, 14 Mar 2017 23:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibAMgCYBsA8A for ; Tue, 14 Mar 2017 23:46:17 -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 972C11295A0 for ; Tue, 14 Mar 2017 23:46:16 -0700 (PDT) X-Halon-ID: 12f28aed-094b-11e7-af93-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Wed, 15 Mar 2017 07:46:10 +0100 (CET) References: <084a066e-ea68-d614-58e1-08c904f477ea@omnitor.se> <60797269-4dad-5f48-3184-b8fbca42c30c@realtimetext.org> Cc: "slim@ietf.org" From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Wed, 15 Mar 2017 07:46:01 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C99DB21BA5D3A7F687C0EB1D" Archived-At: Subject: Re: [Slim] Extended functionality for the real-time language negotiation X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 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, 15 Mar 2017 06:46:20 -0000 This is a multi-part message in MIME format. --------------C99DB21BA5D3A7F687C0EB1D Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit This is an amended overview of possible solutions to the functionality extensions for the slim real-time draft. It includes the alternative to use the language subtag -t- to indicate transformed language and thereby enable simultaneity. The selected solutions can be included in the current draft or specified in a separate draft. If it is specified in a separate draft, the current draft needs to be checked and possibly adjusted so that it allows the selected syntax of the extensions. The letters e) f) etc refer to the summary of issues from LC. *Indication of preference between media, and of simultanous versus alternative languages.* Discussion: Issue e) says that there is a need to be able to indicate which of a set of language/media indications are more preferred alternatives than others. Examples are: 1. A user A want to get written English in text, A can as a less preferred alternative accept to get spoken English. An answering party B who can use text will then respond with written text and get good satisfaction, while another answering user C without text capability will answer in spoken English and have a possibility for a reasonably successful call. Without this indication, the first answering party B may have seen the spoken and written alternatives as true equal preference alternatives and answered with spoken English that will result in less satisfied users. 2. A prefer to receive spoken language, and can accept to receive text. When answering party B can use spoken language, that will be satisfied, otherwise written language will be used. 3. A prefer to use spoken language in both directions, and can accept to use sign language in video in both directions. Answering party B has a clear indication of why both signed and written is indicated and can answer according to its capabilities trying to satisfy the preference for spoken language. 4. A prefer to use sign language in both directions and can accept to use written language in both directions. Sign language users will use sign language, others will use text. 5. A prefer to send sign language and receive text (deaf-blind user) and can accept to send text. In a call with a person with similar preferences, text will be used both ways, otherwise sign one way and text the other. etc. Issue f) requires a way to indicate use of captioning and other situations where use of simultaneous languages in different modalities are needed: 1. Preference for hearing spoken language and simultaneously read written language in text. ( captioning) . The time is here when this can be provided automatically in some settings, but also traditionally by a manned service. 2. Preference for hearing spoken language and simultaneously seeing the speaker in video. (lip-reading). Easily and naturally provided once the need is known. 3. Preference for seeing sign language and simultaneously hear spoken language in audio. ( for multiple users at the terminal ) One of the streams is provided by an interpreter. 4. Preference for hearing spoken language and simultaneously view written language in video. (captioning if we accept to specify text as overlay on video, otherwise it is same as number 1.) Some of these can be acceptable also if just one of the language/media combinations can be provided, but is much more preferred if both can be provided together. In other cases it is essential to get both simultaneously. There is a need to differentiate in the indication that this preference for getting the languages together is preferred. Alternative coding proposals: 1. Preference between modalities 1.1 Based on draft -08, add the coding of an asterisk last in an attribute to mean lower preference for a lanugage/media combination than the one(s) without an asterisk. example where audio and text are alternatives and text preferred m=audio a=hlang-recv:en* m=text a=hlang-recv:en 1.2. Change to the Accept-Language syntax and let the q-values have scope over the whole SDP. Example where sign language is higher preferred than text. m=video 51372 RTP/AVP 31 32 a=hlang-recv:ase;q=0.9 a=hlang-send:ase;q=0.9 m=text 49250 RTP/AVP 98,99 a=hlang-send:en;q=0.5,*;q=0.1 a=hlang-recv:en;q=0.5,*;q=0.1 1.3. Introduce a new a=modality attribute on media level, with parameters: , , example: m=text a=modality:written,recv,hi a=hlang-recv:en* m=audio a=modality:spoken,recv,med a=hlang-recv:en* 2. Preference for simultaneous languages vs alternative languages: 2.1. Based on draft -08, add another notation to the use of the asterisk, e.g. an optional character to be used together with or without the asterisk to mark media that are wanted together. (ugly) example: m=audio a=hlang-recv:en*$c m=text a=hlang-recv:en$c The $ is a simultaneity indication, the c is a grouping indicator telling that all modalities marked with the $c are wanted together. (we might be able to restrict the indication to just one set of languages that are wanted simultaneously.) 2.2. Use the Accept-Language syntax for the hlang attributes and add the usage rules that q-values with less than .1 difference mean languages with a preference to be used together. Higher differences indicate that they are alternatives. Thereby it is both possible to indicate simultaneity and preference if the simultaneity cannot be satisfied. m=audio 51372 RTP/AVP 0 a=hlang-recv:ase;q=0.5 a=hlang-send:ase;q=0.5 m=text 49250 RTP/AVP 98,99 a=hlang-send:en;q=0.51,*;q=0.1 a=hlang-recv:en;q=0.51,*;q=0.1 The q-values differences are within 0.1 so it is a preference for getting both together, but if that is not possible, text is preferred. 2.3. Add to the new a=modality attribute from solution 1.3 a fourth, optional parameter [simultaneity] with value any single letter, indicating a preference for having that modality simultaneously with another modality indicated with the same value in the [simultaneity] parameter. Without this parameter, the modalities are alternatives. Use this solution together with solution 1.3 Example: Indicate that written English and spoken English are desired together but the call shall not be denied if that combination is not possible, and then written English is preferred. m=text a=modality:written,recv,hi,d a=hlang-recv:en m=audio a=modality:spoken,recv,hi,d a=hlang-recv:en* The "d" is a grouping identifier. 2.4. Use the -t- subtag for transformed content on a language indication defined in RFC 6497 as an indication that this language can be provided or is desired together with a language in another modality. Use this indication together with solution 1.1 Example: Indicate that written English and spoken English are desired together and written English expected to be transformed. but the call shall not be denied if that combination is not possible, and then written English is preferred. m=text a=hlang-recv:en-t-en m=audio a=hlang-recv:en* The -t- indicated with the -recv direction shall not be understood that the indicated language needs to be transformed. It is just an expectation that enables it to be provided simultaneously. My judgement of the alternatives: I have a slight preference for solutions 1.2 and 2.2 because they are logically cleanest , but they require that we accept the LC review proposal to move to the Accept-Language syntax. 1.1 and 2.4 are easily added to the syntax of the current draft and have sufficient functionality for most cases. 1.3 and 2.3 cause more work and longer SDP 2.1 is ugly and kept here just for reference. Gunnar -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------C99DB21BA5D3A7F687C0EB1D Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

This is an amended overview of possible solutions to the functionality extensions for the slim real-time draft.

It includes the alternative to use the language subtag -t- to indicate transformed language and thereby enable simultaneity.

The selected solutions can be included in the current draft or specified in a separate draft. If it is specified in a separate draft, the current draft needs to be checked and possibly adjusted so that it allows the selected syntax of the extensions.

The letters e) f) etc refer to the summary of issues from LC.

Indication of preference between media, and of simultanous versus alternative languages.

 Discussion:
Issue e) says that there is a need to be able to indicate which of a set of language/media indications are more preferred alternatives than others.
Examples are:
1. A user A want to get written English in text, A can as a less preferred alternative accept to get spoken English.  An answering party B who can use text will then respond with written text and get good satisfaction, while another answering user C without text capability will answer in spoken English and have a possibility for a reasonably successful call.
Without this indication, the first answering party B may have seen the spoken and written alternatives as true equal preference alternatives and answered with spoken English that will result in less satisfied users.
2. A prefer to receive spoken language, and can accept to receive text.   When answering party B can use spoken language, that will be satisfied, otherwise written language will be used.
3. A prefer to use spoken language in both directions, and can accept to use sign language in video in both directions. Answering party B has a clear indication of why both signed and written is indicated and can answer according to its capabilities trying to satisfy the preference for spoken language.
4. A prefer to use  sign language in both directions and can accept to use written language in both directions. Sign language users will use sign language, others will use text.
5. A prefer to send sign language and receive text (deaf-blind user) and can accept to send text.  In a call with a person with similar preferences, text will be used both ways, otherwise sign one way and text the other.

etc.

Issue f) requires a way to indicate use of captioning and other situations where use of simultaneous languages in different modalities are needed:

1. Preference for hearing spoken language and simultaneously read written language in text. ( captioning) .   The time is here when this can be provided automatically in some settings, but also traditionally by a manned service.
2. Preference for hearing spoken language and simultaneously seeing the speaker in video.   (lip-reading).  Easily and naturally provided once the need is known.
3. Preference for seeing sign language and simultaneously hear spoken language in audio.  ( for multiple users at the terminal )    One of the streams is provided by an interpreter.
4. Preference for hearing spoken language and simultaneously view written language in video. (captioning if we accept to specify text as overlay on video, otherwise it is same as number 1.) 

Some of these can be acceptable also if just one of the language/media combinations can be provided, but is much more preferred if both can be provided together. In other cases it is essential to get both simultaneously. There is a need to differentiate in the indication that this preference for getting the languages together is preferred.

Alternative coding proposals:
1. Preference between modalities
1.1 Based on draft -08, add the coding of an asterisk last in an attribute to mean lower preference for a lanugage/media combination than the one(s) without an asterisk.
example where audio and text are alternatives and text preferred
m=audio
a=hlang-recv:en*
m=text
a=hlang-recv:en


1.2. Change to the Accept-Language syntax and let the q-values have scope over the whole SDP.   

Example where sign language is higher preferred than text.

 m=video 51372 RTP/AVP 31 32
 a=hlang-recv:ase;q=0.9
 a=hlang-send:ase;q=0.9


 m=text 49250 RTP/AVP 98,99
 a=hlang-send:en;q=0.5,*;q=0.1
 a=hlang-recv:en;q=0.5,*;q=0.1
1.3. Introduce a new a=modality attribute on media level, with parameters: <modality>, <direction>, <preference>    

example:

m=text
a=modality:written,recv,hi
a=hlang-recv:en*
m=audio
a=modality:spoken,recv,med
a=hlang-recv:en*


2. Preference for simultaneous languages vs alternative languages:

2.1. Based on draft -08, add another notation to the use of the asterisk, e.g. an optional character to be used together with or without the asterisk to mark media that are wanted together. (ugly)   example:

m=audio
a=hlang-recv:en*$c
m=text
a=hlang-recv:en$c

The $ is a simultaneity indication, the c is a grouping indicator telling that all modalities marked with the $c are wanted together. (we might be able to restrict the indication to just one set of languages that are wanted simultaneously.)


2.2. Use the Accept-Language syntax for the hlang attributes and add the usage rules that q-values with less than .1 difference mean languages with a preference to be used together. Higher differences indicate that they are alternatives.  Thereby it is both possible to indicate simultaneity and preference if the simultaneity cannot be satisfied.

 m=audio 51372 RTP/AVP 0
 a=hlang-recv:ase;q=0.5
 a=hlang-send:ase;q=0.5


 m=text 49250 RTP/AVP 98,99
 a=hlang-send:en;q=0.51,*;q=0.1
 a=hlang-recv:en;q=0.51,*;q=0.1

The q-values differences are within 0.1 so it is a preference for getting both together, but if that is not possible, text is preferred.


2.3. Add to the new a=modality attribute from solution 1.3 a fourth, optional parameter [simultaneity]   with value any single letter, indicating a preference for having that modality simultaneously with another modality indicated with the same value in the [simultaneity] parameter.   Without this parameter, the modalities are alternatives. Use this solution together with solution 1.3

Example: Indicate that written English and spoken English are desired together but the call shall not be denied if that combination is not possible, and then written English is preferred.

m=text
a=modality:written,recv,hi,d
a=hlang-recv:en
m=audio
a=modality:spoken,recv,hi,d
a=hlang-recv:en*

The "d" is a grouping identifier.

2.4. Use the -t- subtag for transformed content on a language indication defined in RFC 6497 as an indication that this language can be provided or is desired together with a language in another modality. Use this indication together with solution 1.1 

Example: Indicate that written English and spoken English are desired together and written English expected to be transformed.  but the call shall not be denied if that combination is not possible, and then written English is preferred.

m=text
a=hlang-recv:en-t-en
m=audio
a=hlang-recv:en*

The -t- indicated with the -recv direction shall not be understood that the indicated language needs to be transformed. It is just an expectation that enables it to be provided simultaneously.

My judgement of the alternatives:
I have a slight preference for solutions 1.2 and 2.2 because they are logically cleanest , but they require that we accept the LC review proposal to move to the Accept-Language syntax.
1.1 and 2.4 are easily added to the syntax of the current draft and have sufficient functionality for most cases.
1.3 and 2.3 cause more work and longer SDP
2.1 is ugly and kept here just for reference.


Gunnar




 

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------C99DB21BA5D3A7F687C0EB1D-- From nobody Tue Mar 28 13:01:55 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF8B1295EA for ; Tue, 28 Mar 2017 13:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gsmasso.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4s0T1K8mu9-b for ; Tue, 28 Mar 2017 13:01:50 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30067.outbound.protection.outlook.com [40.107.3.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A5EE1275AB for ; Tue, 28 Mar 2017 13:01:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=GSMASSO.onmicrosoft.com; s=selector1-gsma-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pJo4zOoGJgHmBVGgOzzlIXOf+4ThIXkIEa1TPNa9d9k=; b=anC04/0EmT16GU5jf2zdf/MflvnnP4YAuv+CcOeYKgj11uNNgWiftdBWOU/hXTKd2RZTr4Z2CyJRCQcRqu901bWqlSlWtfar5gKeWhGeJ0u5MJJjQyQZGYyIOvxtLLKTmh3WHv9gsRlaYEsa0nrArh0elCSwVpL5NDasKpSv6Hc= Received: from HE1PR04MB3113.eurprd04.prod.outlook.com (10.171.196.31) by HE1PR04MB3113.eurprd04.prod.outlook.com (10.171.196.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.14; Tue, 28 Mar 2017 20:01:48 +0000 Received: from HE1PR04MB3113.eurprd04.prod.outlook.com ([10.171.196.31]) by HE1PR04MB3113.eurprd04.prod.outlook.com ([10.171.196.31]) with mapi id 15.01.0991.020; Tue, 28 Mar 2017 20:01:48 +0000 From: Natasha Rooney To: "slim@ietf.org" Thread-Topic: Ticket 29 Thread-Index: AQHSp/4i40Ovw/MLeEugnzNWbS46Yw== Date: Tue, 28 Mar 2017 20:01:48 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=gsma.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:67c:370:128:1cb0:602e:1795:f680] x-microsoft-exchange-diagnostics: 1; HE1PR04MB3113; 7:EjIoAK8BN6NQ95STjtLlr7mdXTAeZqgZl2sRuGhWVDixtXvr49tK/BSGlyEJHqX3SMqE1jOs9PeXQzHHI0NOWzcynwuoa1gSdr+zxkSjcQKOfl78WXKTKHq7TxlfpqCl8K3qyyvFUbP5zG7nef51wM/S9dfZwU1CPIKUKCjvGD7bboditBZBsw5qtG1PVPRIIxXTQSe20+LJtI4qyEz5Etfyz+hT9+gTENS+kZCivvTXhhcv0+Q6yXFISTeF71PJ9wG+vADSrEFNxR24luyhfBjNKeDoQXoIWbrwvriWLuW3G1Rh29m2j0NWTSFtgu4k+cv259Eap/Hi7RXHJT7VCA== x-ms-office365-filtering-correlation-id: 2cc69a86-e008-45e3-3ec0-08d4761544bc x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423065)(201703031133071); SRVR:HE1PR04MB3113; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040440)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(201703131423065)(201702281528065)(201703061421065)(201703061406065)(20161123558025)(20161123564025)(20161123560025)(20161123555025)(6072148); SRVR:HE1PR04MB3113; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB3113; x-forefront-prvs: 0260457E99 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39400400002)(39840400002)(39410400002)(39450400003)(53754006)(25786009)(99286003)(50226002)(2501003)(8676002)(53936002)(6512007)(8936002)(236005)(5660300001)(1730700003)(54896002)(7116003)(6306002)(50986999)(5640700003)(7906003)(6916009)(81166006)(6436002)(606005)(7736002)(2351001)(38730400002)(110136004)(5890100001)(6506006)(3280700002)(86362001)(33656002)(2900100001)(36756003)(102836003)(77096006)(6116002)(3660700001)(6486002)(2906002)(57306001)(122556002)(189998001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB3113; H:HE1PR04MB3113.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_FBE23F9838C54AEEAD09808188AF9C0Bgsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2017 20:01:48.4820 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB3113 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: HE1PR04MB3113.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 2001:67c:370:128:1cb0:602e:1795:f680 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: HE1PR04MB3113.eurprd04.prod.outlook.com Archived-At: Subject: [Slim] Ticket 29 X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 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, 28 Mar 2017 20:01:53 -0000 --_000_FBE23F9838C54AEEAD09808188AF9C0Bgsmacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpCZXJuYXJkIGFuZCBJIGFyZSBnb2luZyB0aHJvdWdoIG9wZW4gaXNzdWVzIG9u IHRoZSBkcmFmdHMgdG9kYXkgYXQgSUVURjk4LiBXaXRoIHJlZ2FyZHMgdG8gdGlja2V0IDI5LCB3 ZSB3b3VsZCBsaWtlIHRvIGtub3cgaWYgdGhlcmUgaXMgd29ya2luZyBncm91cCBzdXBwb3J0IGZv ciB0aGUgZm9sbG93aW5nIGNoYW5nZT8gUGxlYXNlIGxvb2sgYXQgdGhlIHRpY2tldCBpZiB5b3Ug cmVxdWlyZSBtb3JlIGluZm86DQpodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9zbGltL3RpY2tl dC8yOQ0KDQoqKioqKioqKiBTdWdnZXN0ZWQgQ2hhbmdlICoqKioqKioqKg0KU2VjdGlvbiA2IGhh cyB0aGUgZm9ybSBmb3IgYXR0cmlidXRlIHJlZ2lzdHJhdGlvbiBieSBJQU5BLiBUaGVyZSBhcmUg YSBjb3VwbGUgb2YgZmllbGRzIG1pc3NpbmcgdGhhdCB3aWxsIGJlIGltcG9ydGFudCBmb3IgdXNl IG9mIHRoZSBzcGVjaWZpY2F0aW9uIGluIHRoZSBXZWJSVEMgZW52aXJvbm1lbnQuIEluY2x1ZGUg dGhlc2UgZmllbGRzIGlmIHRoYXQgaXMgYWxsb3dhYmxlIGFjY29yZGluZyB0byBjdXJyZW50IElB TkEgcHJvY2VkdXJlcyBhbmQgaWYgdGhhdCBkb2VzIG5vdCBkZWxheSB0aGUgcHVibGljYXRpb24g b2YgdGhpcyBkcmFmdC4gVGhlc2UgZmllbGRzIGFyZSBuZWVkZWQgZm9yIHVzZSBvZiB0ZXh0IG1l ZGlhIGluIFdlYlJUQy4NCg0KQ2hhbmdlIHN1Z2dlc3RlZDoNCg0KIlVzYWdlIExldmVsOiBtZWRp YSINCnRvOg0KIlVzYWdlIExldmVsOiBtZWRpYSwgZGNzYShzdWJwcm90b2NvbCnigJ0NCg0KSW5z ZXJ0IGluIHR3byBsb2NhdGlvbnMgaW4gdGhlIHJlZ2lzdHJhdGlvbiBmb3JtczoNCiJNdXggQ2F0 ZWdvcnk6IE5PUk1BTOKAnQ0KDQoNClRoaXMgZW1haWwgYW5kIGl0cyBhdHRhY2htZW50cyBhcmUg aW50ZW5kZWQgZm9yIHRoZSBhYm92ZSBuYW1lZCBvbmx5IGFuZCBtYXkgYmUgY29uZmlkZW50aWFs LiBJZiB0aGV5IGhhdmUgY29tZSB0byB5b3UgaW4gZXJyb3IgeW91IG11c3QgdGFrZSBubyBhY3Rp b24gYmFzZWQgb24gdGhlbSwgbm9yIG11c3QgeW91IGNvcHkgb3Igc2hvdyB0aGVtIHRvIGFueW9u ZTsgcGxlYXNlIHJlcGx5IHRvIHRoaXMgZW1haWwgb3IgY2FsbCArNDQgMjA3IDM1NiAwNjAwIGFu ZCBoaWdobGlnaHQgdGhlIGVycm9yLg0K --_000_FBE23F9838C54AEEAD09808188AF9C0Bgsmacom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5IaSBhbGws PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij5CZXJuYXJkIGFuZCBJIGFyZSBnb2luZyB0aHJvdWdoIG9wZW4gaXNzdWVzIG9uIHRoZSBkcmFm dHMgdG9kYXkgYXQgSUVURjk4LiBXaXRoIHJlZ2FyZHMgdG8gdGlja2V0IDI5LCB3ZSB3b3VsZCBs aWtlIHRvIGtub3cgaWYgdGhlcmUgaXMgd29ya2luZyBncm91cCBzdXBwb3J0IGZvciB0aGUgZm9s bG93aW5nIGNoYW5nZT8gUGxlYXNlIGxvb2sgYXQgdGhlIHRpY2tldCBpZiB5b3UgcmVxdWlyZSBt b3JlIGluZm86PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxhIGhyZWY9Imh0dHBzOi8vdHJhYy5pZXRm Lm9yZy90cmFjL3NsaW0vdGlja2V0LzI5IiBjbGFzcz0iIj5odHRwczovL3RyYWMuaWV0Zi5vcmcv dHJhYy9zbGltL3RpY2tldC8yOTwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPioqKioqKioqIFN1Z2dlc3RlZCBDaGFuZ2UgKioqKioq KioqPC9kaXY+DQpTZWN0aW9uIDYgaGFzIHRoZSBmb3JtIGZvciBhdHRyaWJ1dGUgcmVnaXN0cmF0 aW9uIGJ5IElBTkEuIFRoZXJlIGFyZSBhIGNvdXBsZSBvZiBmaWVsZHMgbWlzc2luZyB0aGF0IHdp bGwgYmUmbmJzcDtpbXBvcnRhbnQgZm9yIHVzZSBvZiB0aGUgc3BlY2lmaWNhdGlvbiBpbiB0aGUg V2ViUlRDIGVudmlyb25tZW50LiBJbmNsdWRlIHRoZXNlIGZpZWxkcyBpZiB0aGF0IGlzIGFsbG93 YWJsZSZuYnNwO2FjY29yZGluZyB0byBjdXJyZW50IElBTkEgcHJvY2VkdXJlcyBhbmQNCiBpZiB0 aGF0IGRvZXMgbm90IGRlbGF5IHRoZSBwdWJsaWNhdGlvbiBvZiB0aGlzIGRyYWZ0LiBUaGVzZSBm aWVsZHMgYXJlJm5ic3A7bmVlZGVkIGZvciB1c2Ugb2YgdGV4dCBtZWRpYSBpbiBXZWJSVEMuPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQ2hhbmdlIHN1Z2dlc3RlZDo8YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPiZxdW90O1VzYWdlIExldmVsOiBtZWRpYSZx dW90OzxiciBjbGFzcz0iIj4NCnRvOjxiciBjbGFzcz0iIj4NCiZxdW90O1VzYWdlIExldmVsOiBt ZWRpYSwgZGNzYShzdWJwcm90b2NvbCnigJ08L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KSW5zZXJ0IGluIHR3byBsb2NhdGlvbnMgaW4gdGhlIHJlZ2lzdHJhdGlvbiBmb3Jtczo8 YnIgY2xhc3M9IiI+DQomcXVvdDtNdXggQ2F0ZWdvcnk6IE5PUk1BTOKAnTwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxwIHN0eWxlPSJmb250LWZhbWlseTogQXJp YWwsc2Fucy1zZXJpZjtmb250LXNpemU6MTFweDtjb2xvcjojOTk5OTk5OyI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsc2Fucy1zZXJpZjtjb2xvcjojOTk5OTk5 OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogQXJpYWw7IG1zby1mYXJlYXN0LXRoZW1lLWZvbnQ6 IG1pbm9yLWxhdGluOyBtc28tYmlkaS1mb250LWZhbWlseTogJnF1b3Q7QXJpYWwmcXVvdDs7IG1z by1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEVOLUdCOyBtc28t YmlkaS1sYW5ndWFnZTogQVItU0EiPlRoaXMNCiBlbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGFy ZSBpbnRlbmRlZCBmb3IgdGhlIGFib3ZlIG5hbWVkIG9ubHkgYW5kIG1heSBiZSBjb25maWRlbnRp YWwuIElmIHRoZXkgaGF2ZSBjb21lIHRvIHlvdSBpbiBlcnJvciB5b3UgbXVzdCB0YWtlIG5vIGFj dGlvbiBiYXNlZCBvbiB0aGVtLCBub3IgbXVzdCB5b3UgY29weSBvciBzaG93IHRoZW0gdG8gYW55 b25lOyBwbGVhc2UgcmVwbHkgdG8gdGhpcyBlbWFpbCBvciBjYWxsICYjNDM7NDQgMjA3IDM1NiAw NjAwDQogYW5kIGhpZ2hsaWdodCB0aGUgZXJyb3IuIDwvc3Bhbj48L3A+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_FBE23F9838C54AEEAD09808188AF9C0Bgsmacom_-- From nobody Tue Mar 28 13:14:35 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1041412896F for ; Tue, 28 Mar 2017 13:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.697 X-Spam-Level: X-Spam-Status: No, score=-4.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gsmasso.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8NPQ_iEnsyX for ; Tue, 28 Mar 2017 13:14:33 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0043.outbound.protection.outlook.com [104.47.0.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B95F41294E7 for ; Tue, 28 Mar 2017 13:14:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=GSMASSO.onmicrosoft.com; s=selector1-gsma-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OS7fhe+97IVh9LgyzDeuc1wh04Qw/NJ7cQW885InuEg=; b=DzVf47y2/LRj6SvjQKPJQORacRMbQtrxOsPUVgidfGsvCbGjPpdjWgRelYmXdKloxQsx9FtftlKkw9UQN097F0z0yR1vXiI4CjPrKMVNP3a3Rkd7Z/C2R8X21E0JX0t5a6YNfAK+vQ032W5UPUtETIlFL8El82u79slPRtAEO2g= Received: from HE1PR04MB3113.eurprd04.prod.outlook.com (10.171.196.31) by HE1PR04MB3116.eurprd04.prod.outlook.com (10.171.196.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.14; Tue, 28 Mar 2017 20:14:28 +0000 Received: from HE1PR04MB3113.eurprd04.prod.outlook.com ([10.171.196.31]) by HE1PR04MB3113.eurprd04.prod.outlook.com ([10.171.196.31]) with mapi id 15.01.0991.020; Tue, 28 Mar 2017 20:14:28 +0000 From: Natasha Rooney To: "slim@ietf.org" Thread-Topic: Ticket 31 Thread-Index: AQHSp//n7vfIp6J5Q0iwIJ1VjG8dow== Date: Tue, 28 Mar 2017 20:14:28 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=gsma.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:67c:370:128:1cb0:602e:1795:f680] x-microsoft-exchange-diagnostics: 1; HE1PR04MB3116; 7:d6wk3vWdvQ2G7y2DKjXPxZe4F9Xy/uIaUH6+WIU4IfmmpVE2XHmfw5YhPhGZuM7mv00ae2Zq2n1n3Jo+56AQN+VfS+kgyQCyU6IKbYzZr5iSFWD0G7gNtup1Am9Ae8zerytSLRB3+N/io8dq+C3RXWnVdQcIX2wfKv+rRH8a9SxSSX/TRyrb7N7kw4gl+W3tsv7DH8hdJ89I0D15749VM8cgs47HAy3unW9lz89xgzsMfFZiHUYMWUwDSlVK99lJLd+e343+CGh/eVZRD9G/aM+qvUtnRfU1rIiaeZkyjpfNcvxAaRGg2DOnkFWfFJ/rGto9sVrPUZE0J63E8IdmaQ== x-ms-office365-filtering-correlation-id: 73d02959-4c2d-4f07-080e-08d4761709cd x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423065)(201703031133071)(201702281549065); SRVR:HE1PR04MB3116; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(1591387915157); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040440)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(201703131423065)(201702281528065)(201703061421065)(201703061406065)(20161123560025)(20161123562025)(20161123555025)(20161123558025)(20161123564025)(6072148); SRVR:HE1PR04MB3116; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB3116; x-forefront-prvs: 0260457E99 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39400400002)(39450400003)(39410400002)(39840400002)(53754006)(3660700001)(36756003)(2906002)(33656002)(5640700003)(110136004)(38730400002)(50986999)(99286003)(2351001)(53936002)(5660300001)(54896002)(6512007)(6306002)(50226002)(81166006)(3280700002)(102836003)(6116002)(236005)(1730700003)(8676002)(8936002)(7116003)(122556002)(57306001)(6916009)(606005)(86362001)(6436002)(5890100001)(189998001)(6486002)(77096006)(2900100001)(7736002)(2501003)(25786009)(7906003)(6506006); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB3116; H:HE1PR04MB3113.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_ED43F3A48DDE4D0196477C34F25B47ABgsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2017 20:14:28.6309 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB3116 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: HE1PR04MB3113.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 2001:67c:370:128:1cb0:602e:1795:f680 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: HE1PR04MB3116.eurprd04.prod.outlook.com Archived-At: Subject: [Slim] Ticket 31 X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 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, 28 Mar 2017 20:14:35 -0000 --_000_ED43F3A48DDE4D0196477C34F25B47ABgsmacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable https://trac.ietf.org/trac/slim/ticket/31#comment:1 Hi all! The ticket review continues! Ticket 31 addresses whether there is a need fo= r a SIP code response for a call failure. Checking the IANA SIP registry is= does not seem like there is a response code for language negotiation failu= re. Shall we request that a new one be added, if so, what should it be? https://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-pa= rameters-7 Thanks! Natasha Rooney | Internet Engineering Director | Internet and Web Team | Te= chnology | GSMA | nrooney@gsma.com | +44 (0) 7730 = 219 765 | @thisNatasha | Skype: nrooney@gsm.org This email and its attachments are intended for the above named only and ma= y be confidential. If they have come to you in error you must take no actio= n based on them, nor must you copy or show them to anyone; please reply to = this email or call +44 207 356 0600 and highlight the error. --_000_ED43F3A48DDE4D0196477C34F25B47ABgsmacom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
https://trac.ietf.org/trac/slim/ticket/31#comment:1

Hi all!

The ticket review continues! Ticket 31 addresses whether th= ere is a need for a SIP code response for a call failure. Checking the IANA= SIP registry is does not seem like there is a response code for language n= egotiation failure. Shall we request that a new one be added, if so, what should it be?

https://www.iana.org/assignments/sip-para= meters/sip-parameters.xhtml#sip-parameters-7

Thanks!

Natasha Rooney | Internet Engineering Director | Internet and Web Team= | Technology | GSMA | nrooney@gsma.com | +44 (0) 7730 219 765 | @thisNata= sha | Skype: nrooney@gsm= .org

This email and its attachments are intended for the above named only and may be= confidential. If they have come to you in error you must take no action ba= sed on them, nor must you copy or show them to anyone; please reply to this= email or call +44 207 356 0600 and highlight the error.

--_000_ED43F3A48DDE4D0196477C34F25B47ABgsmacom_-- From nobody Tue Mar 28 13:31:43 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5853A129A16 for ; Tue, 28 Mar 2017 13:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.796, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nc4v9uekpAkE for ; Tue, 28 Mar 2017 13:31:38 -0700 (PDT) Received: from smtp01.icann.org (smtp01.icann.org [192.0.46.81]) (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 8427D129590 for ; Tue, 28 Mar 2017 13:31:37 -0700 (PDT) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp01.icann.org (Postfix) with ESMTP id BC955E056F; Tue, 28 Mar 2017 20:31:36 +0000 (UTC) Received: by request3.lax.icann.org (Postfix, from userid 48) id 807C6C205D2; Tue, 28 Mar 2017 20:31:36 +0000 (UTC) RT-Owner: sabrina.tanamal From: "Sabrina Tanamal via RT" Reply-To: drafts-expert-review-comment@iana.org In-Reply-To: References: Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #949701 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: sabrina.tanamal@icann.org CC: draft-ietf-slim-negotiating-human-language@tools.ietf.org, slim@ietf.org, bernard.aboba@gmail.com, nrooney@gsma.com Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Tue, 28 Mar 2017 20:31:36 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Slim] [IANA #949701] expert review for draft-ietf-slim-negotiating-human-language (sdp-parameters) X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 20:31:40 -0000 Bernard and Natasha, We're forwarding this message to you based on our conversation at the IANA Services desk. Please contact Adam Roach and Flemming Andreasen for additional information. Thank you, Sabrina ---- From: "Adam Roach" CC: "mmusic-chairs@tools.ietf.org" , "mmusic@ietf.org" , slim@ietf.org To: draft-ietf-slim-negotiating-human-language@tools.ietf.org Date: Tue, 7 Mar 2017 13:03:00 -0600 Subject: SDPDIR Review: Review of draft-ietf-slim-negotiating-human-language-08 Download (untitled) / with headers text/plain 3.9KiB Authors of draft-ietf-slim-negotiating-human-language -- I have reviewed this document on behalf of the SDP directorate [1]. Please wait for direction from your document shepherd or AD before posting a new version of the draft. It is my opinion that the document, as presently written, is too ambiguous to publish, for the reasons explained below. Aside -- I have a concern that negotiating language in SDP rather than SIP makes it necessary for proxies to look into SDP to make routing decisions, which is a pretty substantial layer violation (keep in mind, for example, that SIP was originally envisioned to contain S/MIME encrypted bodies, which would render the SDP unreadable by proxies). However, I note that section 5.1 indicates that this has issue been litigated in the working group already, and that it chose to do things in the way documented in the current draft. Leaving the layering issue aside, I find the proposed syntax to be confusing and potentially ambiguous. In particular, the draft does not address what it would mean if an implementation added "*" to the end of some language attributes, but omitted it from others; and, at the same time, it does not preclude senders from doing so. Additionally, the descriptive text doesn't have any explanation that adjacent language tag pairs are somehow related to each other; however, there is an example whose accompanying text makes a strong implication that such pairing is intended: Hide quoted text > An offer requesting spoken Spanish both ways (most preferred), spoken > Basque both ways (second preference), or spoken English both ways > (third preference). The offer further requests that the call proceed > even if the callee does not support any of the languages: > > m=audio 49250 RTP/AVP 20 > a=hlang-send:es* > a=hlang-recv:es* > a=hlang-send:eu* > a=hlang-recv:eu* > a=hlang-send:en* > a=hlang-recv:en* Until this example, I would have assumed that an es/en pairing would be okay here; but the text implies that this would not be allowed. While en/es isn't necessarily a good example, I'll point out that I've seen a number of in-person conversations in which one person spoke Norwegian while the other spoke Swedish, with little apparently difficulty conversing. The document needs more text that talks about how send and receive languages are paired (is the example actually correct?), or it needs to make clear that such pairing is not part of the mechanism. It also needs clearer rules around use of "*", including specification of the intended behavior when its presence is inconsistent with a media section. I'll note that much of this can be fixed if the syntax is collapsed so that each media section can have at most one hlang-send and one hlang-receive, each of which contain a list of one or more languages that can be sent or received. This is also much more consistent with the way SDP attributes are used in general. The presence of a "*" token on that line would indicate the "call should happen even without matching languages" characteristic; since there is only one place to add this indicator, the ambiguity of some lines indicating it and others not disappears. The preceding example would collapse to: m=audio 49250 RTP/AVP 20 a=hlang-send:es eu en * a=hlang-recv:es eu en * ...and the example text would be revised to remove the implication that *sending* "es" necessarily implies *receiving* "es". I'll further note that the majority of SDP libraries I've worked with would make accessing the all-on-one-line format easier than one-line-per-language as well. To be clear: the issues I find problematic are (1) ambiguity around use of "*", and (2) the implication of pairing adjacent attributes with each other in the example without any parallel specification text. My proposed change is intended to be helpful, although there are clearly other solutions that address the issues I have identified. /a ____ [1] https://www.ietf.org/iesg/directorate/sdp.html From nobody Tue Mar 28 14:57:03 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6F0129644 for ; Tue, 28 Mar 2017 14:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMzsq1yC3J2d for ; Tue, 28 Mar 2017 14:56:58 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0122.outbound.protection.outlook.com [104.47.0.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B01F129689 for ; Tue, 28 Mar 2017 14:56:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RngN/MAX/LS7p78VBgmG9EzDS/YxhHiZVEDCq5YMI0s=; b=nr07Fv4gunind27YEVvU/f6kScEoQNTIcSdaqmUmSwv2z66prH6nimqCyQnHxv7NrG79We0ZDIHzo/tqXg4NVf9OtVdc8JpirNEwtanspCAhbI2KbqwnO4sjIbqQRZsFPCcyWz8HlWR17085rgBthSpM9Tft3q8MugM5RVbPjLo= Received: from DB5PR07MB1480.eurprd07.prod.outlook.com (10.165.212.10) by DB5PR07MB1479.eurprd07.prod.outlook.com (10.165.212.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Tue, 28 Mar 2017 21:56:54 +0000 Received: from DB5PR07MB1480.eurprd07.prod.outlook.com ([fe80::f8ee:4cd:212f:cfc4]) by DB5PR07MB1480.eurprd07.prod.outlook.com ([fe80::f8ee:4cd:212f:cfc4%14]) with mapi id 15.01.1005.010; Tue, 28 Mar 2017 21:56:54 +0000 From: "Drage, Keith (Nokia - GB)" To: Natasha Rooney , "slim@ietf.org" Thread-Topic: Ticket 31 Thread-Index: AQHSp//n7vfIp6J5Q0iwIJ1VjG8do6Gqyfow Date: Tue, 28 Mar 2017 21:56:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gsma.com; dkim=none (message not signed) header.d=none;gsma.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.212.6] x-microsoft-exchange-diagnostics: 1; DB5PR07MB1479; 7:zGBdrzh3xjOh06sCtdhRdZdj5Am1zwNfyO4WkG/HgbuR/IL+YRc+UQbcZxH0IE5InLblBAhM/uQZRzA/Kw5dQ+rS7sRS9ORt+0dZnM0UkHOG/K8YystP/YOyr4ieb2QmM0FSFF4pIrqJcXD1JPMcxrSc84xfTsJ0Rvz4rygf4LgsT+Z4p3jsF5S5hhPE2rLQXQ5vlndBTiuo58nZPdF4CW2fRM86SHI8e9PyAgh+79jNEmLW3pWgwcEORN9pTMsb3L5ZFCMItX5f9vAq6z5C6xU6ytgiqISupfUeRwbYHLB1t9LZHRpzT4Y9zxyVXfghgcBoI0F+9wpIjmG9+dKAdQ== x-ms-office365-filtering-correlation-id: 9577e278-6aec-4e78-089b-08d47625591f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:DB5PR07MB1479; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155)(1591387915157); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123558025)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(6072148)(6042181); SRVR:DB5PR07MB1479; BCL:0; PCL:0; RULEID:; SRVR:DB5PR07MB1479; x-forefront-prvs: 0260457E99 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(53754006)(7696004)(2900100001)(74316002)(7116003)(7906003)(7736002)(81166006)(8936002)(8676002)(5660300001)(25786009)(86362001)(76176999)(54356999)(50986999)(66066001)(53546009)(2950100002)(790700001)(6246003)(2501003)(33656002)(5250100002)(5890100001)(38730400002)(99286003)(54896002)(606005)(9686003)(236005)(55016002)(229853002)(6436002)(6506006)(8666007)(6306002)(53936002)(3846002)(6116002)(3660700001)(3280700002)(2906002)(189998001)(102836003); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB1479; H:DB5PR07MB1480.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB5PR07MB14808670759DE5AE7AD5818AF7320DB5PR07MB1480eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2017 21:56:54.6225 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB1479 Archived-At: Subject: Re: [Slim] Ticket 31 X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 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, 28 Mar 2017 21:57:01 -0000 --_000_DB5PR07MB14808670759DE5AE7AD5818AF7320DB5PR07MB1480eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable What has failed. If this is failure to negotiate a session description using SDP, then that = is not directly a SIP failure, and does not directly merit an individual SI= P response code. So SIP defines a general error for an SDP failure, which is a 488, where RF= C 3261 makes the following requirement: "A UAS rejecting an offer contained in an INVITE SHOULD return a 488 (Not Acceptable Here) response. Such a response SHOULD include a Warning header field value explaining why the offer was rejected. " 606 may also be appropriate in some cases where the UAS considers that all = UAS will have the same problem. Further RFC 3261 goes on to say: " A message body containing a description of media capabilities MAY be present in the response, which is formatted according to the Accept header field in the INVITE (or application/sdp if not present), the same as a message body in a 200 (OK) response to an OPTIONS request. " Of course if you are referring to a failure outside the SDP, then please cl= arify. Regards Keith From: SLIM [mailto:slim-bounces@ietf.org] On Behalf Of Natasha Rooney Sent: 28 March 2017 21:14 To: slim@ietf.org Subject: [Slim] Ticket 31 https://trac.ietf.org/trac/slim/ticket/31#comment:1 Hi all! The ticket review continues! Ticket 31 addresses whether there is a need fo= r a SIP code response for a call failure. Checking the IANA SIP registry is= does not seem like there is a response code for language negotiation failu= re. Shall we request that a new one be added, if so, what should it be? https://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-pa= rameters-7 Thanks! Natasha Rooney | Internet Engineering Director | Internet and Web Team | Te= chnology | GSMA | nrooney@gsma.com | +44 (0) 7730 = 219 765 | @thisNatasha | Skype: nrooney@gsm.org This email and its attachments are intended for the above named only and ma= y be confidential. If they have come to you in error you must take no actio= n based on them, nor must you copy or show them to anyone; please reply to = this email or call +44 207 356 0600 and highlight the error. --_000_DB5PR07MB14808670759DE5AE7AD5818AF7320DB5PR07MB1480eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

What has = failed.

&nbs= p;

If this i= s failure to negotiate a session description using SDP, then that is not di= rectly a SIP failure, and does not directly merit an individual SIP response code.

&nbs= p;

So SIP de= fines a general error for an SDP failure, which is a 488, where RFC 3261 ma= kes the following requirement:

&nbs= p;

“A UAS rejecti=
ng an offer contained in an INVITE SHOULD return a 488

   (Not Acceptable Here) response.  Such a = response SHOULD include a

   Warning header field value explaining why the= offer was rejected.

”

&nbs= p;

606 may a= lso be appropriate in some cases where the UAS considers that all UAS will = have the same problem.

&nbs= p;

Further R= FC 3261 goes on to say:

&nbs= p;

“   =
A message body containing a description of media capabilities MAY be
   present in the response, which is formatted according to =
the Accept
   header field in the INVITE (or application/sdp if not pre=
sent), the
   same as a message body in a 200 (OK) response to an OPTIO=
NS request.

”

&nbs= p;

Of course= if you are referring to a failure outside the SDP, then please clarify.

&nbs= p;

Regards

&nbs= p;

Keith

&nbs= p;

From: = SLIM [mailto:slim-bounces@ietf.org] On Behalf Of Natasha Rooney
Sent: 28 March 2017 21:14
To: slim@ietf.org
Subject: [Slim] Ticket 31

 

 

Hi all!

 

The ticket review continues! Ticket 31 addresses whe= ther there is a need for a SIP code response for a call failure. Checking t= he IANA SIP registry is does not seem like there is a response code for lan= guage negotiation failure. Shall we request that a new one be added, if so, what should it be?

 

https://www.iana.org/assignme= nts/sip-parameters/sip-parameters.xhtml#sip-parameters-7

 

Thanks!


Natasha Rooney | Internet Engineering Director | Internet and Web Team= | Technology | GSMA | nroone= y@gsma.com | +44 (0) 7730 219 765 | @thisNatasha | Skype:=  nrooney@gsm.org

 

This email and its attachments are intended f= or the above named only and may be confidential. If they have come to you i= n error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email or ca= ll +44 207 356 0600 and highlight the error.

--_000_DB5PR07MB14808670759DE5AE7AD5818AF7320DB5PR07MB1480eurp_-- From nobody Tue Mar 28 15:12:28 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C40EB1271DF for ; Tue, 28 Mar 2017 15:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6YGEtFldkTS for ; Tue, 28 Mar 2017 15:12:24 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::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 BE5BB12955A for ; Tue, 28 Mar 2017 15:12:23 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id r69so105177437vke.2 for ; Tue, 28 Mar 2017 15:12:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ILM3kzsc8tC5oLt7m6LXzCHvfJnTtGG4XM9H6CJ7DU8=; b=e+vjuk8BYfpHs8XTnvAFzW21duyYuRuuUwyfdXKAC58OB+mnTA/yHRahq4CooYSGJ0 2dlvuwB21kI7IwdsQ3t0QQlDaxKrybM0bkMx9fWJhrzbbX+Qhob62+fvCsTzl86f7LHT b8phPw+GRcd1xDzWmMd1DVA3tNz5HIXiAZ4QhI8hhFoKtp3M2ot83BatkZolCY/GdgmR L/ogOJbafRPJ9HIb3sfpR51xPZFMF2pRm/1xTuiQHzgcWZFFSbM9V/NPh+7IWZynzPjf QrhcH8hMI9zy3f5tTIjnXEOEGT7QZDHdMcHdjIqhA4m5pHnCaopzfDnp3+OOJLQ5O8bg 8QQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ILM3kzsc8tC5oLt7m6LXzCHvfJnTtGG4XM9H6CJ7DU8=; b=E2w1+MS3reD1pM0qyh2bVpJz9OrF3RtNKE9IWsWpY08SzhCuRdWanp+/LYedl40Xbo tHCydnMumUNDSUOYQdO2Z2TI1J6mbN/egSY4PdGbl/5HPU9nnZvTqiZfBY05ErmLQ4FS vgukxkYOJesHyKPykkiEjtsETn21cJeYvJaT41+L+HeNvxLF32P+JatbnQDRoYr9jENR itp5i6xhOlEmwLdPTu3M6jiVTEIj45uQVCy4ScXZSyZtnmaHaL/Hu0trDH31IGMBzDpe 5AQJNCFOPF36ROGpJUp4rvj6P24l5skitKiBbrdFVi7hwWnaD9FjtKVtFE+drtQ1rdAD r2PQ== X-Gm-Message-State: AFeK/H0PlzLaU5b2BZvmKPPkHnAOBsyjRWEhjhTtryY7E+qHaS67TjmgSwrdoQW3yRBKyyUtGkhWEq6njWpLgg== X-Received: by 10.31.68.130 with SMTP id r124mr13436892vka.72.1490739142653; Tue, 28 Mar 2017 15:12:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.2.120 with HTTP; Tue, 28 Mar 2017 15:12:02 -0700 (PDT) In-Reply-To: References: From: Bernard Aboba Date: Tue, 28 Mar 2017 17:12:02 -0500 Message-ID: To: slim@ietf.org Cc: Randall Gellens Content-Type: multipart/alternative; boundary=001a113534420cfc60054bd1c10e Archived-At: Subject: [Slim] Fwd: [IANA #949701] expert review for draft-ietf-slim-negotiating-human-language (sdp-parameters) X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 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, 28 Mar 2017 22:12:27 -0000 --001a113534420cfc60054bd1c10e Content-Type: text/plain; charset=UTF-8 For some reason, this message did not make its way onto the mailing list. ---- From: "Adam Roach" CC: "mmusic-chairs@tools.ietf.org" , " mmusic@ietf.org" , slim@ietf.org To: draft-ietf-slim-negotiating-human-language@tools.ietf.org Date: Tue, 7 Mar 2017 13:03:00 -0600 Subject: SDPDIR Review: Review of draft-ietf-slim-negotiating- human-language-08 Download (untitled) / with headers text/plain 3.9KiB Authors of draft-ietf-slim-negotiating-human-language -- I have reviewed this document on behalf of the SDP directorate [1]. Please wait for direction from your document shepherd or AD before posting a new version of the draft. It is my opinion that the document, as presently written, is too ambiguous to publish, for the reasons explained below. Aside -- I have a concern that negotiating language in SDP rather than SIP makes it necessary for proxies to look into SDP to make routing decisions, which is a pretty substantial layer violation (keep in mind, for example, that SIP was originally envisioned to contain S/MIME encrypted bodies, which would render the SDP unreadable by proxies). However, I note that section 5.1 indicates that this has issue been litigated in the working group already, and that it chose to do things in the way documented in the current draft. Leaving the layering issue aside, I find the proposed syntax to be confusing and potentially ambiguous. In particular, the draft does not address what it would mean if an implementation added "*" to the end of some language attributes, but omitted it from others; and, at the same time, it does not preclude senders from doing so. Additionally, the descriptive text doesn't have any explanation that adjacent language tag pairs are somehow related to each other; however, there is an example whose accompanying text makes a strong implication that such pairing is intended: Hide quoted text > An offer requesting spoken Spanish both ways (most preferred), spoken > Basque both ways (second preference), or spoken English both ways > (third preference). The offer further requests that the call proceed > even if the callee does not support any of the languages: > > m=audio 49250 RTP/AVP 20 > a=hlang-send:es* > a=hlang-recv:es* > a=hlang-send:eu* > a=hlang-recv:eu* > a=hlang-send:en* > a=hlang-recv:en* Until this example, I would have assumed that an es/en pairing would be okay here; but the text implies that this would not be allowed. While en/es isn't necessarily a good example, I'll point out that I've seen a number of in-person conversations in which one person spoke Norwegian while the other spoke Swedish, with little apparently difficulty conversing. The document needs more text that talks about how send and receive languages are paired (is the example actually correct?), or it needs to make clear that such pairing is not part of the mechanism. It also needs clearer rules around use of "*", including specification of the intended behavior when its presence is inconsistent with a media section. I'll note that much of this can be fixed if the syntax is collapsed so that each media section can have at most one hlang-send and one hlang-receive, each of which contain a list of one or more languages that can be sent or received. This is also much more consistent with the way SDP attributes are used in general. The presence of a "*" token on that line would indicate the "call should happen even without matching languages" characteristic; since there is only one place to add this indicator, the ambiguity of some lines indicating it and others not disappears. The preceding example would collapse to: m=audio 49250 RTP/AVP 20 a=hlang-send:es eu en * a=hlang-recv:es eu en * ...and the example text would be revised to remove the implication that *sending* "es" necessarily implies *receiving* "es". I'll further note that the majority of SDP libraries I've worked with would make accessing the all-on-one-line format easier than one-line-per-language as well. To be clear: the issues I find problematic are (1) ambiguity around use of "*", and (2) the implication of pairing adjacent attributes with each other in the example without any parallel specification text. My proposed change is intended to be helpful, although there are clearly other solutions that address the issues I have identified. /a ____ [1] https://www.ietf.org/iesg/directorate/sdp.html --001a113534420cfc60054bd1c10e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For some reason, this message did not make its way onto th= e mailing list.=C2=A0


----

From:=C2=A0 =C2=A0"Adam Roach" <adam@nostrum.com>
CC:=C2=A0 =C2=A0 =C2=A0"mmusic-chairs@tools.ietf.org" <mmusic-chairs@tools.ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>, slim@ietf.org
To:=C2=A0 =C2=A0 =C2=A0draft-ietf-slim-negotiating-human-language@to= ols.ietf.org
Date:=C2=A0 =C2=A0Tue, 7 Mar 2017 13:03:00 -0600
Subject:=C2=A0 =C2=A0 =C2=A0 =C2=A0 SDPDIR Review: Review of draft-ietf-sli= m-negotiating-human-language-08
Download (untitled)
/
with headers

text/plain 3.9KiB
Authors of draft-ietf-slim-negotiating-human-language --

I have reviewed this document on behalf of the SDP directorate [1].
Please wait for direction from your document shepherd or AD before
posting a new version of the draft.

It is my opinion that the document, as presently written, is too
ambiguous to publish, for the reasons explained below.

Aside -- I have a concern that negotiating language in SDP rather
than SIP makes it necessary for proxies to look into SDP to make
routing decisions, which is a pretty substantial layer violation
(keep in mind, for example, that SIP was originally envisioned to
contain S/MIME encrypted bodies, which would render the SDP
unreadable by proxies). However, I note that section 5.1 indicates
that this has issue been litigated in the working group already, and
that it chose to do things in the way documented in the current draft.


Leaving the layering issue aside, I find the proposed syntax to be
confusing and potentially ambiguous. In particular, the draft does not
address what it would mean if an implementation added "*" to the = end of
some language attributes, but omitted it from others; and, at the same
time, it does not preclude senders from doing so.

Additionally, the descriptive text doesn't have any explanation that adjacent language tag pairs are somehow related to each other; however,
there is an example whose accompanying text makes a strong implication
that such pairing is intended:

Hide quoted text
> An offer requesting spoken Spanish both ways (most preferred), spoken<= br> > Basque both ways (second preference), or spoken English both ways
> (third preference). The offer further requests that the call proceed > even if the callee does not support any of the languages:
>
> m=3Daudio 49250 RTP/AVP 20
> a=3Dhlang-send:es*
> a=3Dhlang-recv:es*
> a=3Dhlang-send:eu*
> a=3Dhlang-recv:eu*
> a=3Dhlang-send:en*
> a=3Dhlang-recv:en*

Until this example, I would have assumed that an es/en pairing would be
okay here; but the text implies that this would not be allowed. While
en/es isn't necessarily a good example, I'll point out that I'v= e seen a
number of in-person conversations in which one person spoke Norwegian
while the other spoke Swedish, with little apparently difficulty conversing= .

The document needs more text that talks about how send and receive
languages are paired (is the example actually correct?), or it needs to
make clear that such pairing is not part of the mechanism. It also needs clearer rules around use of "*", including specification of the i= ntended
behavior when its presence is inconsistent with a media section.

I'll note that much of this can be fixed if the syntax is collapsed so<= br> that each media section can have at most one hlang-send and one
hlang-receive, each of which contain a list of one or more languages
that can be sent or received. This is also much more consistent with the way SDP attributes are used in general. The presence of a "*" tok= en on
that line would indicate the "call should happen even without matching=
languages" characteristic; since there is only one place to add this indicator, the ambiguity of some lines indicating it and others not
disappears. The preceding example would collapse to:

m=3Daudio 49250 RTP/AVP 20
a=3Dhlang-send:es eu en *
a=3Dhlang-recv:es eu en *

...and the example text would be revised to remove the implication that
*sending* "es" necessarily implies *receiving* "es".
I'll further note that the majority of SDP libraries I've worked wi= th
would make accessing the all-on-one-line format easier than
one-line-per-language as well.

To be clear: the issues I find problematic are (1) ambiguity around use
of "*", and (2) the implication of pairing adjacent attributes wi= th each
other in the example without any parallel specification text. My
proposed change is intended to be helpful, although there are clearly
other solutions that address the issues I have identified.

/a

____
[1] https://www.ietf.org/iesg/directorate/sdp.htm= l

--001a113534420cfc60054bd1c10e-- From nobody Tue Mar 28 16:37:14 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C476126D73 for ; Tue, 28 Mar 2017 16:37:13 -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: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-nmWsnIrbhJ for ; Tue, 28 Mar 2017 16:37:11 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9B55E126BFD for ; Tue, 28 Mar 2017 16:37:11 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 28 Mar 2017 16:38:39 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Tue, 28 Mar 2017 16:37:06 -0700 To: Natasha Rooney , "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 Archived-At: Subject: Re: [Slim] Ticket 29 X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 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, 28 Mar 2017 23:37:13 -0000 The revised draft (-08, published 2/26) added "MUX Category: NORMAL" to the IANA registrations. This was per IANA review and my own review of draft-ietf-mmusic-sdp-mux-attributes. The draft did not change ""Usage Level: media". --Randy At 8:01 PM +0000 3/28/17, Natasha Rooney wrote: > Hi all, > > Bernard and I are going through open issues on the drafts today at > IETF98. With regards to ticket 29, we would like to know if there > is working group support for the following change? Please look at > the ticket if you require more info: > > https://trac.ietf.org/trac/slim/ticket/29 > > ******** Suggested Change ********* > Section 6 has the form for attribute registration by IANA. There > are a couple of fields missing that will be important for use of > the specification in the WebRTC environment. Include these fields > if that is allowable according to current IANA procedures and if > that does not delay the publication of this draft. These fields > are needed for use of text media in WebRTC. > > Change suggested: > > "Usage Level: media" > to: > "Usage Level: media, dcsa(subprotocol)" > > Insert in two locations in the registration forms: > "Mux Category: NORMAL" > > This email and its attachments are intended for the above named > only and may be confidential. If they have come to you in error you > must take no action based on them, nor must you copy or show them > to anyone; please reply to this email or call +44 207 356 0600 and > highlight the error. > > > _______________________________________________ > 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: --------------- Children are natural mimics who act like their parents despite every effort to teach them good manners. From nobody Tue Mar 28 16:41:53 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1D5126579 for ; Tue, 28 Mar 2017 16:41: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: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooU1aRuq8PAY for ; Tue, 28 Mar 2017 16:41:49 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id A3B4C126CE8 for ; Tue, 28 Mar 2017 16:41:49 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 28 Mar 2017 16:43:17 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Tue, 28 Mar 2017 16:41:45 -0700 To: Natasha Rooney , "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 Archived-At: Subject: Re: [Slim] Ticket 31 X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 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, 28 Mar 2017 23:41:51 -0000 This has already been discussed on the list and fixed in the draft. The draft added text suggesting which SIP response code to use, and added a SIP warning code to the IANA registry. IANA was informed of the change. The current draft includes in Section 5.3: If the call is rejected due to lack of any languages in common, it is suggested to use SIP response code 488 (Not Acceptable Here) or 606 (Not Acceptable) [RFC3261] and include a Warning header field [RFC3261] in the SIP response. The Warning header field contains a warning code of [TBD: IANA VALUE, e.g., 308] and a warning text indicating that there are no mutually-supported languages; the text SHOULD also contain the supported languages and media. Example: Warning: [TBD: IANA VALUE, e.g., 308] proxy.example.com "Incompatible language specification: Requested languages not supported. Supported languages are: es, en; supported media are: audio, text." And in Section 6.2 (within the IANA Considerations section): 6.2. Warn-Codes Sub-Registry of SIP Parameters IANA is requested to add a new value in the warn-codes sub-registry of SIP parameters in the 300 through 329 range that is allocated for indicating problems with keywords in the session description. The reference is to this document. The warn text is "Incompatible language specification: Requested languages not supported. Supported languages and media are: [list of supported languages and media]." --Randy At 8:14 PM +0000 3/28/17, Natasha Rooney wrote: > https://trac.ietf.org/trac/slim/ticket/31#comment:1 > > Hi all! > > The ticket review continues! Ticket 31 addresses whether there is a > need for a SIP code response for a call failure. Checking the IANA > SIP registry is does not seem like there is a response code for > language negotiation failure. Shall we request that a new one be > added, if so, what should it be? > > > https://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-7 > > Thanks! > > > Natasha Rooney | Internet Engineering Director | Internet and Web > Team | Technology | GSMA > | nrooney@gsma.com | +44 (0) 7730 219 765 > | @thisNatasha | Skype: nrooney@gsm.org > > This email and its attachments are intended for the above named > only and may be confidential. If they have come to you in error you > must take no action based on them, nor must you copy or show them > to anyone; please reply to this email or call +44 207 356 0600 and > highlight the error. > > > _______________________________________________ > 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: --------------- If Richard Branson had worn a pair of steel-rimmed glasses, a double-breasted suit and shaved off his beard, I would have taken him seriously. As it was I couldn't.... --Lord King, Chairman, British Airways From nobody Tue Mar 28 16:54:18 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE3812708C for ; Tue, 28 Mar 2017 16:54:16 -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: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CyosxKaSEZG7 for ; Tue, 28 Mar 2017 16:54:14 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 55CA4126D73 for ; Tue, 28 Mar 2017 16:54:14 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 28 Mar 2017 16:55:41 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Tue, 28 Mar 2017 16:54:10 -0700 To: adam@nostrum.com, Flemming Andreasen , bernard.aboba@gmail.com, nrooney@gsma.com From: Randall Gellens Cc: slim@ietf.org, draft-ietf-slim-negotiating-human-language@tools.ietf.org 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 Archived-At: Subject: Re: [Slim] [IANA #949701] expert review for draft-ietf-slim-negotiating-human-language (sdp-parameters) X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 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, 28 Mar 2017 23:54:16 -0000 At 8:31 PM +0000 3/28/17, Sabrina Tanamal via RT wrote: > Bernard and Natasha, > > We're forwarding this message to you based on our conversation at > the IANA Services desk. Please contact Adam Roach and Flemming > Andreasen for additional information. > > Thank you, > > Sabrina > > ---- > > From: "Adam Roach" > CC: "mmusic-chairs@tools.ietf.org" > , "mmusic@ietf.org" > , slim@ietf.org > To: draft-ietf-slim-negotiating-human-language@tools.ietf.org > Date: Tue, 7 Mar 2017 13:03:00 -0600 > Subject: SDPDIR Review: Review of > draft-ietf-slim-negotiating-human-language-08 > Download (untitled) > / > with headers > > text/plain 3.9KiB > Authors of draft-ietf-slim-negotiating-human-language -- > > I have reviewed this document on behalf of the SDP directorate [1]. > Please wait for direction from your document shepherd or AD before > posting a new version of the draft. > > It is my opinion that the document, as presently written, is too > ambiguous to publish, for the reasons explained below. > > Aside -- I have a concern that negotiating language in SDP rather > than SIP makes it necessary for proxies to look into SDP to make > routing decisions, which is a pretty substantial layer violation > (keep in mind, for example, that SIP was originally envisioned to > contain S/MIME encrypted bodies, which would render the SDP > unreadable by proxies). However, I note that section 5.1 indicates > that this has issue been litigated in the working group already, and > that it chose to do things in the way documented in the current draft. Negotiation in SDP vs SIP was extensively debated for a couple of years, and Flemming was part of that discussion. The WG explicitly decided to take routing out of scope to advance the simple proposal in the draft. > Leaving the layering issue aside, I find the proposed syntax to be > confusing and potentially ambiguous. In particular, the draft does not > address what it would mean if an implementation added "*" to the end of > some language attributes, but omitted it from others; and, at the same > time, it does not preclude senders from doing so. The draft explicitly says that an asterisk need only be appended to any attribute value: An asterisk appended to any value indicates a request by the caller to not fail the call if there is no language in common. ... The mechanism for indicating this preference is that, in an offer, if the last character of any of the 'hlang-recv' or 'hlang-send' values is an asterisk, this indicates a request to not fail the call. The called party MAY ignore the indication, e.g., for the emergency services use case, regardless of the absence of an asterisk, a PSAP will likely not fail the call; some call centers might reject a call even if the offer contains a language with an asterisk. > Additionally, the descriptive text doesn't have any explanation that > adjacent language tag pairs are somehow related to each other; however, > there is an example whose accompanying text makes a strong implication > that such pairing is intended: > > Hide quoted text >> An offer requesting spoken Spanish both ways (most preferred), spoken >> Basque both ways (second preference), or spoken English both ways >> (third preference). The offer further requests that the call proceed >> even if the callee does not support any of the languages: >> >> m=audio 49250 RTP/AVP 20 >> a=hlang-send:es* >> a=hlang-recv:es* >> a=hlang-send:eu* >> a=hlang-recv:eu* >> a=hlang-send:en* >> a=hlang-recv:en* I'm not following what you mean. There is no grouping or pairing nor restrictions on which languages can be used with which others. The draft presents a simple mechanism to enable basic language negotiation with media, it does not attempt to capture the rich complexity of human interactions or polylinguism. > Until this example, I would have assumed that an es/en pairing would be > okay here; but the text implies that this would not be allowed. While > en/es isn't necessarily a good example, I'll point out that I've seen a > number of in-person conversations in which one person spoke Norwegian > while the other spoke Swedish, with little apparently difficulty conversing. > > The document needs more text that talks about how send and receive > languages are paired (is the example actually correct?), or it needs to > make clear that such pairing is not part of the mechanism. It also needs > clearer rules around use of "*", including specification of the intended > behavior when its presence is inconsistent with a media section. > > I'll note that much of this can be fixed if the syntax is collapsed so > that each media section can have at most one hlang-send and one > hlang-receive, each of which contain a list of one or more languages > that can be sent or received. This is also much more consistent with the > way SDP attributes are used in general. The presence of a "*" token on > that line would indicate the "call should happen even without matching > languages" characteristic; since there is only one place to add this > indicator, the ambiguity of some lines indicating it and others not > disappears. The preceding example would collapse to: > > m=audio 49250 RTP/AVP 20 > a=hlang-send:es eu en * > a=hlang-recv:es eu en * > > ...and the example text would be revised to remove the implication that > *sending* "es" necessarily implies *receiving* "es". > > I'll further note that the majority of SDP libraries I've worked with > would make accessing the all-on-one-line format easier than > one-line-per-language as well. > > To be clear: the issues I find problematic are (1) ambiguity around use > of "*", and (2) the implication of pairing adjacent attributes with each > other in the example without any parallel specification text. My > proposed change is intended to be helpful, although there are clearly > other solutions that address the issues I have identified. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- People that are really very weird can get into sensitive positions and have a tremendous impact on history. --then U.S. Vice President Dan Quayle From nobody Wed Mar 29 12:19:03 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74996129438 for ; Wed, 29 Mar 2017 12:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEHOwRJYZkdg for ; Wed, 29 Mar 2017 12:18:58 -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 4150412953B for ; Wed, 29 Mar 2017 12:18:58 -0700 (PDT) X-Halon-ID: 8bfca0c6-14b4-11e7-b144-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Wed, 29 Mar 2017 21:18:53 +0200 (CEST) To: slim@ietf.org References: From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Wed, 29 Mar 2017 21:18:37 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] Ticket 29 X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 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, 29 Mar 2017 19:19:01 -0000 Den 2017-03-29 kl. 01:37, skrev Randall Gellens: > The revised draft (-08, published 2/26) added "MUX Category: NORMAL" > to the IANA registrations. This was per IANA review and my own review > of draft-ietf-mmusic-sdp-mux-attributes. Right. but the spelling should be: Mux Category: NORMAL > > > The draft did not change ""Usage Level: media". Right. There is a draft for transport of real-time text in a WebRTC data channel, so the addition of likely ",dsca(t140)" will be needed eventually, but I think we need to wait with that addition until the draft is approved and the subprotocol name surely assigned. /Gunnar > > > --Randy > > At 8:01 PM +0000 3/28/17, Natasha Rooney wrote: > >> Hi all, >> >> Bernard and I are going through open issues on the drafts today at >> IETF98. With regards to ticket 29, we would like to know if there is >> working group support for the following change? Please look at the >> ticket if you require more info: >> >> https://trac.ietf.org/trac/slim/ticket/29 >> >> >> ******** Suggested Change ********* >> Section 6 has the form for attribute registration by IANA. There are >> a couple of fields missing that will be important for use of the >> specification in the WebRTC environment. Include these fields if that >> is allowable according to current IANA procedures and if that does >> not delay the publication of this draft. These fields are needed for >> use of text media in WebRTC. >> >> Change suggested: >> >> "Usage Level: media" >> to: >> "Usage Level: media, dcsa(subprotocol)" >> >> Insert in two locations in the registration forms: >> "Mux Category: NORMAL" >> >> This email and its attachments are intended for the above named only >> and may be confidential. If they have come to you in error you must >> take no action based on them, nor must you copy or show them to >> anyone; please reply to this email or call +44 207 356 0600 and >> highlight the error. >> >> >> _______________________________________________ >> 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 Mar 30 02:14:48 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66DB9128B4E for ; Thu, 30 Mar 2017 02:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yB0xELue7yh3 for ; Thu, 30 Mar 2017 02:14:43 -0700 (PDT) Received: from bin-vsp-out-02.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A257128DE5 for ; Thu, 30 Mar 2017 02:14:42 -0700 (PDT) X-Halon-ID: 4c6c48a3-1529-11e7-b144-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Thu, 30 Mar 2017 11:14:37 +0200 (CEST) To: drafts-expert-review-comment@iana.org References: Cc: slim@ietf.org, bernard.aboba@gmail.com, nrooney@gsma.com, draft-ietf-slim-negotiating-human-language@tools.ietf.org From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <7b110177-5bc9-ac41-5819-ec5354a4dced@omnitor.se> Date: Thu, 30 Mar 2017 11:14:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] [IANA #949701] expert review for draft-ietf-slim-negotiating-human-language (sdp-parameters) and issue 37 X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 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, 30 Mar 2017 09:14:46 -0000 I notice that the comments and solution proposal on the syntax concerns from the IANA review has a lot in common with Issue 34. https://trac.ietf.org/trac/slim/ticket/34 Both propose a one-line format for all languages in one media and direction, and both are puzzled by the diffuse placement rules for the asterisk parameter. A solution could be searched on these together. Gunnar Den 2017-03-28 kl. 22:31, skrev Sabrina Tanamal via RT: > Bernard and Natasha, > > We're forwarding this message to you based on our conversation at the IANA Services desk. Please contact Adam Roach and Flemming Andreasen for additional information. > > Thank you, > > Sabrina > > ---- > > From: "Adam Roach" > CC: "mmusic-chairs@tools.ietf.org" , "mmusic@ietf.org" , slim@ietf.org > To: draft-ietf-slim-negotiating-human-language@tools.ietf.org > Date: Tue, 7 Mar 2017 13:03:00 -0600 > Subject: SDPDIR Review: Review of draft-ietf-slim-negotiating-human-language-08 > Download (untitled) > / > with headers > > text/plain 3.9KiB > Authors of draft-ietf-slim-negotiating-human-language -- > > I have reviewed this document on behalf of the SDP directorate [1]. > Please wait for direction from your document shepherd or AD before > posting a new version of the draft. > > It is my opinion that the document, as presently written, is too > ambiguous to publish, for the reasons explained below. > > Aside -- I have a concern that negotiating language in SDP rather > than SIP makes it necessary for proxies to look into SDP to make > routing decisions, which is a pretty substantial layer violation > (keep in mind, for example, that SIP was originally envisioned to > contain S/MIME encrypted bodies, which would render the SDP > unreadable by proxies). However, I note that section 5.1 indicates > that this has issue been litigated in the working group already, and > that it chose to do things in the way documented in the current draft. > > > Leaving the layering issue aside, I find the proposed syntax to be > confusing and potentially ambiguous. In particular, the draft does not > address what it would mean if an implementation added "*" to the end of > some language attributes, but omitted it from others; and, at the same > time, it does not preclude senders from doing so. > > Additionally, the descriptive text doesn't have any explanation that > adjacent language tag pairs are somehow related to each other; however, > there is an example whose accompanying text makes a strong implication > that such pairing is intended: > > Hide quoted text >> An offer requesting spoken Spanish both ways (most preferred), spoken >> Basque both ways (second preference), or spoken English both ways >> (third preference). The offer further requests that the call proceed >> even if the callee does not support any of the languages: >> >> m=audio 49250 RTP/AVP 20 >> a=hlang-send:es* >> a=hlang-recv:es* >> a=hlang-send:eu* >> a=hlang-recv:eu* >> a=hlang-send:en* >> a=hlang-recv:en* > Until this example, I would have assumed that an es/en pairing would be > okay here; but the text implies that this would not be allowed. While > en/es isn't necessarily a good example, I'll point out that I've seen a > number of in-person conversations in which one person spoke Norwegian > while the other spoke Swedish, with little apparently difficulty conversing. > > The document needs more text that talks about how send and receive > languages are paired (is the example actually correct?), or it needs to > make clear that such pairing is not part of the mechanism. It also needs > clearer rules around use of "*", including specification of the intended > behavior when its presence is inconsistent with a media section. > > I'll note that much of this can be fixed if the syntax is collapsed so > that each media section can have at most one hlang-send and one > hlang-receive, each of which contain a list of one or more languages > that can be sent or received. This is also much more consistent with the > way SDP attributes are used in general. The presence of a "*" token on > that line would indicate the "call should happen even without matching > languages" characteristic; since there is only one place to add this > indicator, the ambiguity of some lines indicating it and others not > disappears. The preceding example would collapse to: > > m=audio 49250 RTP/AVP 20 > a=hlang-send:es eu en * > a=hlang-recv:es eu en * > > ...and the example text would be revised to remove the implication that > *sending* "es" necessarily implies *receiving* "es". > > I'll further note that the majority of SDP libraries I've worked with > would make accessing the all-on-one-line format easier than > one-line-per-language as well. > > To be clear: the issues I find problematic are (1) ambiguity around use > of "*", and (2) the implication of pairing adjacent attributes with each > other in the example without any parallel specification text. My > proposed change is intended to be helpful, although there are clearly > other solutions that address the issues I have identified. > > /a > > ____ > [1] https://www.ietf.org/iesg/directorate/sdp.html > > _______________________________________________ > 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